AI coding tools are not just helping engineers write code faster. They are changing what it means to be a good software engineer.
An engineer reviews a payment feature written by an AI agent. The code looks clean. The routes are in place, and the automated tests pass. But the engineer notices a serious problem: the retry path does not keep the payment request's idempotency key. In plain terms, if the database records a charge but the response times out, an automatic retry could charge the customer twice.
This example shows the difference between code that looks correct and software that can be trusted.
For a clear, routine task, AI can now produce scaffolding, application routes, and a first set of tests in minutes. It has reduced the time needed to create a plausible first version of many features. But more code does not automatically mean better software.
That is the central tension of AI-assisted engineering. AI makes useful code cheaper to produce. It also makes fragile, insecure, and poorly understood code cheaper to produce. As implementation becomes faster, engineering performance will depend less on the amount of code a team generates and more on its ability to verify, integrate, and safely operate each change.
This shifts the value of human work. Judgment, verification, and accountability become more important. Here, judgment has a practical meaning: choosing the right problem, understanding the constraints, selecting a suitable design, deciding what evidence is enough to trust the change, and taking responsibility for what happens in production.
What AI is changing
AI tools now do much more than complete a line of code. Repository-aware agents can read a codebase, plan changes across several files, run commands, inspect failed tests, and try again.
Their measured capability has improved quickly. By early 2026, leading systems were resolving issues in the high-70% range on SWE-bench Verified, a benchmark built from real GitHub issues. But benchmark scores have limits. The tools, test harnesses, and evaluation methods have changed over time. Passing benchmark tests also does not mean a change would pass a real code review or work safely in production.[1]
The impact also depends on the type of software being built. In general application development, teams may spend less time producing a first implementation and more time reviewing and integrating it. In embedded, regulated, and safety-critical systems, an incorrect change can cause safety, legal, or operational harm. Those systems need much stronger validation, traceability, and human accountability.
AI can compress execution, but it does not remove decisions about intent, trade-offs, constraints, and acceptable risk. An agent may implement a requested feature. It should not be assumed to know every relevant business rule or organizational priority. Nor should it have final authority over the trade-offs an organization accepts.
For some work, engineers are moving from direct implementation toward specifying, supervising, and validating agent-produced changes. This requires clear requirements and success criteria but it also requires enough technical understanding to recognize when the proposed solution is wrong.
Craft is moving from output to trusted change
Good engineering has never been only about typing speed or syntax. Design, testing, maintainability, and operations have always mattered. Even so, hiring and productivity systems have often rewarded visible output: tickets closed, pull requests merged, or features delivered.
AI makes those measures even less useful. When a tool can generate large amounts of code quickly, code volume says little about the value or quality of the work.
There are warning signs in current research. GitClear, a software-analytics vendor, analyzed 211 million changed lines of code. In its dataset, lines classified as copied rose from 8.3% in 2021 to 12.3% in 2024. Lines classified as moved fell from about 24% to 9.5%.[2] These patterns may point to more duplication and less reuse. However, the study is observational: it does not prove that AI caused the changes, and its measures are not complete definitions of software quality.
DORA's findings also show why simple productivity stories are risky. Its 2024 report found that greater AI adoption was associated with lower delivery throughput and stability. In 2025, AI adoption was positively associated with throughput, but the negative relationship with stability remained.[3][4] These are correlations, not proof that AI caused either outcome. Still, they support an important idea: producing changes faster does not guarantee that an organization can deliver them safely.
The useful unit of engineering productivity is therefore not code produced. It is a change that has been understood, verified, integrated, and operated successfully.
The human skills that matter more
Problem framing
AI can help discover requirements and suggest options. Humans and organizations must still decide which problems are worth solving.
An underspecified request such as “build a payments service” may produce convincing code while leaving important questions unanswered. Who is allowed to make a payment? How are duplicate requests handled? What happens during a partial failure? What must be logged? Who owns the service? How can a failed release be rolled back?
A strong engineer asks these questions before trusting the implementation.
Systems thinking
AI-generated code can pass local tests while making the wider system worse. A new utility might work but sit in the wrong architectural layer. A feature might duplicate an existing capability. A database change might be correct on its own but create new load, coupling, or failure modes elsewhere.
Systems thinking means understanding how components interact, where state lives, how data crosses boundaries, and how the system behaves when something fails. This context is often what separates a working code fragment from a sound engineering change.
Verification and debugging
AI-generated changes can include invented APIs, incorrect assumptions, and logic errors. They may also pass weak tests. If the same model writes both the code and the tests, both may reflect the same mistaken understanding of the requirement.
Verification must cover more than unit tests. Engineers may need to check dependency and license risks, exposure of secrets or proprietary code, security boundaries, observability, rollout and rollback plans, and ownership after the original agent session is gone.
Research shows that AI assistance does not translate into the same productivity gain in every setting. In an early-2025 randomized study, METR found that 16 experienced open-source developers took 19% longer on familiar, complex tasks when they could use AI tools. A later study with newer tools showed some evidence of faster work, but selection problems made the result difficult to interpret.[5][6] The careful conclusion is not that AI always slows developers. It is that benchmark performance does not automatically become real-world productivity on complex, context-heavy work.
Judgment is not a permanent safe area for humans. AI is already helping with code review, threat modeling, debugging, and architecture proposals. As these capabilities improve, engineers may spend less time producing the first analysis and more time deciding whether an AI-generated analysis is sound. Human value cannot rest on the assumption that AI will stop at implementation. It rests on understanding the system, weighing trade-offs in context, deciding what evidence is enough, and remaining accountable for the result.
Security and domain knowledge
Security failures often hide in business rules rather than syntax. In Veracode's benchmark of 80 task templates across four languages and four vulnerability classes, 45% of generated results failed the benchmark's security tests.[7] This does not mean 45% of all production AI code is insecure. It does show that plausible code can still fail important security checks.
Authorization and business logic are especially difficult because correctness depends on the application's rules. Repeated AI edits can also remove a security check that was correct in an earlier version. Engineers need tests that capture those rules, not only tests that confirm the happy path.
The apprenticeship problem
AI may also change how engineers learn.
Junior engineers have traditionally built experience through bounded work: fixing bugs, adding tests, reading existing modules, and implementing small features. These tasks were not merely cheap labor. They helped engineers learn how a codebase works and how small decisions create later consequences.
If agents take over more routine implementation, some of those learning opportunities may shrink before organizations have designed replacements. Companies cannot simply ask junior engineers to show senior judgment earlier. Judgment is not learned from principles alone. It grows through implementation, debugging, incidents, code review, and living with earlier trade-offs.
This creates a paradox: AI increases the value of judgment while automating some of the work through which judgment has traditionally developed.
Organizations will need deliberate apprenticeship paths. Early-career engineers should remain close to code and production. They should review generated changes, investigate incidents, trace failures across services, participate in design discussions, and operate what the team ships. AI can support this learning, but it should not remove contact with consequences.
What engineering leaders should change
Buying AI coding tools is not an engineering strategy. AI creates leverage only when a team's ability to verify changes grows with its ability to generate them. Otherwise, faster coding can produce review queues, operational risk, and a less coherent codebase.
Platform teams can help by creating “paved roads”: approved components, secure defaults, architectural rules, and automated checks that guide both humans and agents toward safer changes.
Accountability must also be real. When an agent creates a pull request, a named person should have the context, authority, and time to reject or redesign it. For a high-risk change, the review evidence should include:
- The requirement and risk level
- Test results and important assumptions
- Security and dependency checks
- Observability changes
- The rollout and rollback plan
- A named owner
Organizations should also examine where time saved in coding is lost later. The new bottleneck may be review, integration, security approval, testing, deployment, or incident response.
Lines of code and raw output volume are poor primary measures of productivity, especially when machines can generate both cheaply. No single replacement metric is enough. Leaders should consider delivery speed alongside reliability, maintainability, recovery time, customer outcomes, and the amount of avoidable rework.
Judgment as the scarce capability
The lasting human responsibility in AI-assisted development is not writing every line. It is deciding when a software change is trustworthy and remaining accountable when that decision is wrong.
This does not mean engineering automatically becomes a more elevated craft. If engineers are reduced to approving changes they do not understand, the craft becomes weaker. Engineering becomes richer only when people remain close enough to implementation and production to question, improve, and own what the tools produce.
As first-pass code becomes cheaper, the bottleneck moves to deciding whether a change is needed, whether it fits the system, and whether the evidence is strong enough to trust it.
When code becomes cheap, judgment becomes the craft.