Extending the Reach of Every Engineer

The real promise of agentic coding is not replacing technical skill. It is helping skilled people carry good judgment further.

The most important question about agentic coding is not how much code an agent can write.

It is what an engineer becomes capable of doing with one.

Those questions may sound similar, but they lead to very different futures. One points toward software factories: more agents, more output, more pull requests, and perhaps a dashboard with an exciting number that turns green during an executive meeting. The other points toward something more human and, I believe, more valuable: engineers with greater range.

Range is the distance between recognizing a worthwhile problem and delivering a responsible solution. It is the ability to cross an unfamiliar codebase, explore several designs, build an experiment, validate the result, and explain the tradeoffs. It is the difference between having a good idea and having enough practical capacity to carry that idea into the world.

That distance has always been constrained by time, specialization, organizational boundaries, and an ever-growing backlog. Agentic coding can change that—but only if we use it to expand individual capability, not subtract the individual from engineering.

From Concentrated Power to Personal Capability

The Industrial Revolution taught us how to concentrate power. Factories brought expensive machinery, specialized labor, and standardized processes together. Railroads moved enormous volumes along fixed tracks and timetables. The productivity model was clear: make the system larger, divide the work more finely, and increase its output.

The automobile was also a product of industrialization. The Model T became broadly affordable because Ford applied interchangeable parts and the moving assembly line to a complex product. Yet the automobile’s impact was different from that of another machine inside the factory.

When the car left the factory, the capability went with the individual.

A train increased the capacity of a transportation network. A car increased the practical range of the person driving it. The driver could choose a destination, change routes, leave on a different schedule, carry an unexpected load, or make a questionable decision involving a roadside diner.

The automobile did not merely make an existing trip faster. It made entirely new trips practical.

That is the useful analogy for agentic coding. Its most consequential effect will not be producing the same software backlog at a higher speed. It will be expanding the set of problems an individual engineer can responsibly take on.

An infrastructure engineer may turn a recurring support problem into a polished self-service workflow. A product engineer may investigate an operational issue without waiting for a specialist. A new team member may map an unfamiliar system in hours instead of weeks.

The value is not simply speed. It is reach.

The Harness Is Where Potential Becomes Leverage

Most conversations about AI coding still focus on the model. Which one reasons better? Which one writes better code? Which one reached the top of a benchmark this week, and will it remain there until at least Thursday?

Models matter. But a model alone is like an engine sitting on a garage floor: impressive, powerful, and not yet a transportation strategy.

The agent harness is what turns that potential into useful engineering work. It connects the model to the repository, documentation, tools, tests, and execution environment. It manages context, permissions, and feedback. It allows an agent to inspect a problem, propose a change, run validation, observe the result, and revise its approach.

In automotive terms, the harness provides the steering, brakes, gauges, mirrors, navigation, and safety systems. It also provides the road rules and, ideally, keeps the vehicle from enthusiastically driving through the wall of the garage.

This is why agentic coding is not merely a procurement decision. Giving everyone access to a model is not the same as giving them a trustworthy way to extend their capabilities.

The engineering environment matters enormously. Reliable tests provide feedback. Repository instructions preserve conventions. Repeatable environments reduce guesswork. Small work units make progress observable. Permission boundaries limit mistakes. Good documentation helps people and agents form accurate mental models.

Google’s DORA research describes AI as an amplifier of an organization’s existing strengths and weaknesses. That finding should be at the center of every leadership conversation about adoption.

Organizations with strong engineering fundamentals can translate agent speed into learning and customer value. Organizations with fragile builds, unclear ownership, inconsistent review, and undocumented systems may simply produce uncertainty faster.

A powerful engine does not repair the road beneath it.

Expertise Is the Force Being Multiplied

I believe agentic coding should be a force multiplier for individuals. That phrase contains an important condition: a multiplier still needs something worth multiplying.

For engineers, that underlying force is not typing speed. It is judgment.

It is the ability to understand a customer’s problem, separate symptoms from causes, recognize constraints, design for change, weigh risk, and take responsibility for an outcome. It is knowing when a technically correct solution is operationally foolish, when a clean abstraction is hiding the business rule that matters, and when the right answer is to remove code instead of generating more of it.

These skills do not become less important as implementation becomes easier. They become the limiting factor.

An agent may produce five plausible designs in the time it once took to implement one. An engineer must still recognize which design fits the system and the organization. An agent may refactor thousands of lines and pass every existing test. An engineer must still ask whether the new boundary is understandable, whether the tests capture the right behavior, and whether tomorrow’s on-call engineer will be able to diagnose it at 2:00 a.m.

The future engineer may write fewer of the characters in a repository. That does not make the role less technical; it raises the level at which technical understanding must operate. When implementation is abundant, clear intent becomes scarce. The ability to verify, simplify, and occasionally say “we should not build this” becomes a competitive advantage.

Judgment is not what remains after coding is automated. Judgment is what makes the automation useful.

We Should Remove Friction, Not Learning

This distinction matters most when we think about developing engineers.

There is a reasonable concern that people who delegate too early will never build the mental models required to evaluate what an agent produces. Someone can follow turn-by-turn navigation for years without learning the shape of the city. Everything works until a bridge closes, the signal disappears, or the cheerful voice suggests turning into a lake.

We should not preserve tedious work out of nostalgia. Nobody becomes a better engineer by typing the same configuration block for the hundredth time. Boilerplate, repetitive migrations, and mechanical investigation are excellent candidates for assistance.

But some friction is where learning happens. Debugging develops causal reasoning. Designing under constraints develops judgment. Reading unfamiliar code develops pattern recognition. Responding to production failures teaches lessons that a perfectly summarized incident report cannot fully reproduce.

The leadership challenge is to distinguish between friction that consumes human potential and difficulty that develops it.

Used well, an agent can accelerate learning rather than bypass it. It can trace a request, explain a pattern, compare designs, generate an experiment, or challenge an assumption. The engineer remains engaged in forming and testing a mental model.

Used poorly, the same agent can create the appearance of capability while the person’s ability to reason independently quietly atrophies.

Our goal should not be engineers who can complete tasks only when an agent is present. It should be engineers whose understanding grows because an agent lets them ask more ambitious questions and receive faster feedback.

More Output Is an Incomplete Executive Strategy

The easiest way to misuse agentic coding is to measure it like a factory.

More pull requests. More story points. More lines changed. More tasks completed per engineer. These numbers are visible, countable, and almost perfectly designed to create the wrong incentives.

Code is not inventory. It creates maintenance obligations, cognitive load, operational exposure, and future decisions. Producing it faster may move the constraint downstream to review, integration, security, deployment, or support. Ten agents creating ten times as much code for the same people to understand is not transformation. It is a traffic jam with excellent branding.

The evidence encourages humility. In one controlled study, experienced open-source developers using early-2025 tools took longer on familiar tasks even though they expected to be faster. Later results suggested improvement, but with substantial uncertainty.

This does not mean agentic coding is failing. It means access to a powerful tool and organizational leverage from that tool are different achievements.

Leaders should measure whether agentic coding is increasing useful organizational capacity:

• Are engineers shortening the path from an idea to validated learning?
• Are they eliminating recurring toil rather than merely completing it faster?
• Can individuals safely solve problems that previously required several handoffs?
• Are reliability, security, and maintainability improving alongside delivery speed?
• Is the organization creating more time for architecture, customer understanding, mentoring, and difficult decisions?
• Are successful agent workflows becoming reusable capabilities for the whole team?

These measures are harder than counting generated code. They are also much closer to the reasons we employ engineers in the first place.

The Leadership Opportunity Is to Build for Agency

Agentic coding will not create one universal operating model. The appropriate level of autonomy will depend on the task, the system, and the consequences of being wrong. A documentation update, a database migration, and a production access change should not travel through identical guardrails.

The boundary will move as the technology improves. Better vehicles traveled farther because roads, brakes, laws, training, and maintenance improved alongside engines.

Our job as leaders is to build the conditions in which greater individual range produces better collective outcomes.

That means investing beyond tool licenses. It means creating agent-ready repositories with explicit conventions and acceptance criteria. It means reliable, CI-backed validation; safe execution environments; proportional permission boundaries; visible activity and decision trails; and clear human ownership of scope and release decisions.

It also means turning what individuals learn into durable organizational capability. When an engineer discovers an effective agent workflow, the result should not remain a clever prompt hidden in personal history. The useful context, checks, tools, and decision rules should become part of the team’s shared harness. Individual leverage should compound into a better engineering system.

Most importantly, leaders must resist converting every minute saved into another unit of demand. If all new capacity is immediately filled with more tickets, engineers will experience AI as acceleration without progress. The organization may move faster while leaving no room to think about where it is going.

The dividend should include more space for learning, design, simplification, customer contact, and preventative work. Otherwise, we have used one of the most promising tools of our generation to make the treadmill spin faster.

A Future with More Capable People

I am optimistic about agentic coding because I do not believe human and machine capability form a fixed pie.

The right tools can make people more capable.

The automobile expanded personal mobility without making destinations irrelevant. Spreadsheets expanded our ability to model a business without making financial judgment obsolete. Cloud platforms expanded what small teams could operate without making architecture or reliability someone else’s problem.

Agentic coding belongs in that tradition.

It can give an engineer the reach to cross specialties, test ideas sooner, automate recurring work, understand larger systems, and deliver a level of polish that once required a much larger team. It can lower the practical cost of curiosity. It can allow more people to move from identifying a problem to proving that a solution works.

It will also create weak code, confident mistakes, and new risks. Every meaningful expansion of capability does. The answer is to develop the infrastructure, judgment, and leadership practices that let us use it well.

The future I want is not defined by how many engineers an agent can replace. It is defined by how many more meaningful problems each engineer can understand and solve.

Not fewer capable people. More capable people.

Not software produced without judgment. Judgment extended through better tools.

Not an assembly line that moves faster. An engineering organization in which good people can carry good ideas further.

That is the promise worth building toward.

Suggested sources and further reading

• The Henry Ford: “Exploded Model T”
• Library of Congress: “America on the Road”
• DORA: State of AI-assisted Software Development
• METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
• METR: Update on its developer-productivity experiment
• Anthropic: Building Effective AI Agents
• OpenAI: Introducing Codex