AI Output Is Not the Same as Engineering Productivity

Source and AI note: This article is based on Gemini’s Devpractice on YouTube. It was generated and edited with the gpt-5.6-sol model.

AI agents can produce a great deal of work without needing encouragement. That is production: more output becomes available. Engineering productivity asks a harder question. Does the result survive operations, support the next goal, and remain understandable when someone has to repair it?

My current experiments suggest that the gap matters most in complex organizational work. The conclusion is provisional and depends on the task, the person, the quality bar, and how much context the agent receives.

Complex work needs context from somewhere

A small application can often be described within one session. Company work is surrounded by information that is much harder to package: operating history, marketing concerns, leadership decisions, regulations, and changes in the industry.

Imagine an important announcement made in a company meeting. Team members connect it to what their team already knows and begin asking what should change. An agent sees only the announcement and the context supplied with it. To get a comparable response, someone may have to explain the relevant relationships, criteria, and consequences explicitly.

That can work. In my experiments, richer context produced better results. It also consumed more effort and more tokens, so the cost of preparing and maintaining context became part of the engineering work.

Motivation cost becomes specification cost

People need motivation, trust, and communication. Those are real management costs. An agent does not need morale, but it does need facts, constraints, and evaluation criteria stated with care.

Strong teammates can do something more: they expand the problem on their own. They connect a new goal to accumulated experience, notice a consequence that was not assigned, and challenge a direction before it creates the next problem. Current agents can reason well over supplied information, yet I often have to guide that expansion in detail. Writing all of that guidance is work too.

This is not an argument that any person is better than an agent. A teammate who cannot divide work or keeps reasoning in the wrong direction may contribute less. The comparison changes with the people involved and the situation.

Judge the result by the next move

Fast completion is useful, but a project rarely ends at the first goal. Code that reaches today’s target while obstructing tomorrow’s target has raised production and may still have reduced productivity. My quality test is whether the result can be kept over time and whether I could understand and repair it quickly after a failure.

Memory has the same trade-off. People accumulate operating history and form relationships among events naturally. Agent memory can be organized and reviewed, but maintaining it requires deliberate effort, and my experimental results have not always justified that effort.

Some organizations may eventually need fewer people for some kinds of work. A hypothetical team-size example cannot supply a staffing ratio or workforce forecast. Staffing still depends on the work, acceptable quality, costs, and the judgment available inside the team.

The useful distinction for 2026 is therefore modest: agents can raise production, sometimes dramatically, while productivity remains a system property. Context, memory, review, repairability, and the self-directed thinking of capable colleagues still determine whether more output moves the organization forward.