An observation on the distance between producing software and taking responsibility for it.
Imagine an engineer reaching the end of a working day with ten thousand new lines of code and surprisingly little time spent typing. An AI agent has implemented a feature, added tests, and prepared the changes for review. On a dashboard, the day might look exceptional. Inside the team, the most difficult questions may still be unanswered.
Does the feature solve the right problem? What assumptions are hidden inside it? Can another engineer maintain it? What happens when it encounters something the tests never anticipated?
The code exists. Its value still has to be established.
That distinction is where I would begin any conversation about productivity in software development with AI. Once a machine can produce substantial amounts of code from a relatively small amount of human instruction, the visible size of the output becomes a less reliable account of the work behind it.
Even without AI, counting lines was an imperfect way to understand engineering. A careful simplification might remove hundreds of lines and improve a system. A rushed implementation might add thousands and leave everyone else with more to maintain. Agents make this weakness harder to overlook: the same increase in repository activity can represent useful progress, unnecessary complexity, or unfinished work arriving at someone else's desk.
A dashboard can count all three with equal enthusiasm.
This creates a particular temptation for organizations. The things that are easiest to count can begin to stand in for the things they actually want. Commits, completed tickets, and merged pull requests offer clean numbers. Reliability, sound judgment, and the decision to avoid an unnecessary feature are harder to display in a weekly report.
Yet a metric can be accurate and still invite the wrong conclusion. Twenty merged pull requests tell us something about the movement of changes through a repository. They do not, by themselves, tell us how difficult the work was, how much human effort it required, or whether customers are better off because of it.
Consider a team that cuts implementation time in half. If the changes then spend longer waiting for review, the customer may receive them no sooner. If reviewers have to investigate unfamiliar assumptions across larger volumes of generated code, some of the apparent saving has moved into a different part of the process. If defects emerge after release, another part of the cost arrives later.
The relevant question becomes how long it takes to turn an intention into a dependable result, including the work required after the first convincing version appears.
This is also why deployment frequency needs context. Frequent releases can reflect a healthy delivery process. Their meaning changes when accompanied by repeated rollbacks, incidents, or growing maintenance difficulty. Speed matters because it helps a team deliver something useful. It loses much of that meaning when the team must repeatedly repair what it has just delivered.
I find it more useful to think of productivity as a sequence of connected questions. What did the tools cost? How did the work move through implementation, review, and testing? What reached production? How reliably did it operate? What improved for the people using it?
Each question checks the answer to the one before it. Increased AI usage may explain a larger bill. Faster implementation may explain a fuller review queue. Neither establishes a return on the investment until we understand what happened downstream.
The same reasoning applies to tokens. Consumption records the resources used to pursue an outcome. It cannot tell us whether the outcome was worth pursuing, whether the approach was efficient, or whether a simpler change would have done the job. An engineer who reaches a sound result with fewer iterations may demonstrate better judgment than one who keeps an agent busy all afternoon.
This brings us to a more personal question: who deserves credit?
Suppose an agent produces an entire implementation. Mechanical authorship is one part of the story. Someone may still have identified the problem, understood the existing system, set the constraints, rejected an attractive but unsuitable approach, and decided what evidence would justify a release. Other people may have reviewed the change, tested its behavior, or taken responsibility for operating it.
Those contributions deserve to remain visible. Attributing every generated line to the person who initiated the session would obscure the machine's role. Attributing the whole achievement to the machine would obscure the human decisions that made the result useful. Giving all the credit to either would also risk overlooking the team that made the change safe to ship.
Knowing where code came from helps establish this history. It does not settle its value. A record of agent activity can identify an authoring process; it cannot, on its own, explain who exercised good judgment or who prevented an expensive mistake.
There is an important limit here, too. Business outcomes belong to systems and teams. Revenue, customer satisfaction, and reliability can inform an assessment of engineering work, but assigning them neatly to one person risks replacing one misleading number with another. A fair evaluation needs room for context: the difficulty of the assignment, the quality of the decisions, the contribution of colleagues, and the consequences over time.
My reading of this shift is that engineering credit should follow a fuller account of contribution. It should recognize the person who defines the right problem, the reviewer who catches a false assumption, and the engineer who makes a system easier to change next month. It should also recognize effective use of an agent when that use produces a result the team can understand and sustain.
This is a direction for evaluation, rather than a claim that every organization has already adopted it.
Typing less can coexist with demanding engineering work. Choosing what a system should do, deciding what evidence to trust, and accepting responsibility for a release require judgment even when the implementation arrives quickly. The challenge is to make that judgment visible without reducing it to another activity counter.
At the end of that imagined working day, the ten thousand lines are still there. The more revealing conversation begins when someone asks what they changed for the user—and whether the team is ready to live with them.