For most of the history of software development, progress has come from moving developers to higher levels of abstraction.
Assembly language freed programmers from thinking directly in machine instructions. Higher-level programming languages made software more understandable and portable. Functions and modular programming allowed us to break complex systems into manageable components. Object-oriented programming changed how we structured those components and thought about relationships between them. Modern IDEs, code completion, frameworks, libraries, cloud platforms, and CI/CD pipelines each removed another layer of mechanical work. It also made the process closer to how humans think, organize and express their tasks.
Coding agents represent another such shift; however, this one goes one-step further.
After more than 20 years working across the software development lifecycle, I see coding agents as being at least as significant as the arrival of modern IDEs, higher-level programming languages, and object-oriented programming.
AI agents are here, and now we have to think about who or what actually writes the code, how we organize the work around coding, and what should be the role of humans.
This means that the important question is no longer: How much code can AI write?
The more important question is: What should the software development lifecycle look like when writing code is no longer the scarce resource?
We are moving up another level of abstraction
Consider how strange modern programming would appear to someone writing assembly code decades ago. A programmer once had to understand a long sequence of low-level instructions simply to perform an operation that today may be represented by something as simple as:
print("Hello")
We did not become worse programmers because we stopped manually controlling every instruction. We moved up the abstraction stack. We made things more 'human-like' so that we can think about our design and our plan in human terms instead of computer instructions.
The same transition is happening again.Today, I can tell a coding agent what I want a component to accomplish. The agent can inspect an existing codebase, determine which files need to change, write the implementation, execute tests, identify problems, and revise its work.
OpenAI now describes Codex as capable of moving from an issue to tested, review-ready code, including planning changes, writing code, running tests, and preparing pull requests. Its newer tooling is increasingly designed around developers supervising multiple agents rather than interacting with one autocomplete system. This is fundamentally different from code completion. The developer is increasingly specifying intent rather than syntax.
I see this directly in my own work. I currently use tools including Codex, Muse, and Copilot to build applications and automation. Tasks that would previously have taken me weeks can sometimes be accomplished in hours. I am still fully engaged, but I am not writing proper syntax and instructions, I am making decisions and providing direction. It's up to me to decide what should be built, how components should work together, whether the result solves the original problem, which compromises are acceptable, and when the system is ready to move forward. AI is reducing the amount of time I spend producing code while increasing the importance of the decisions surrounding that code.
That distinction is critical.
Lines of code are becoming a meaningless measure of productivity
One of the mistakes I see organizations making is measuring this transformation using the metrics of the old world. Developers may proudly point out that an agent generated thousands of lines of code in minutes. Executives may ask:
- What percentage of our developers are using coding agents?
- Which coding assistants have we deployed
- How many AI-generated lines of code are we producing?
- How much faster are developers coding?
These numbers may tell us something about adoption, but they tell us very little about actual value we are delivering to customers. If an agent generates 10,000 lines of unnecessary code, the fact that it did so in thirty seconds is not a productivity improvement. It might have created a large technical debt, much faster.
The important unit of measurement should increasingly become customer value delivered, not code produced.
- How quickly can we move from a validated need to a meaningful capability in production?
- How reliably does that capability work?
- Did it improve the customer's experience?
- Did it increase revenue, reduce cost, eliminate friction, improve reliability, or enable something that was previously uneconomical?
Velocity should not mean how quickly we manufacture code. It should mean how quickly we deliver meaningful outcomes.
Requirements become more important, not less
There is an irony in software development: humans are often remarkably imprecise about what they want. A business stakeholder explains an idea to a developer, leaves out a dozen details, and assumes the developer understands what was intended. Sometimes, the the developer does understand if they are experienced. Humans fill gaps surprisingly well because we share context, organizational history, assumptions, and common sense. If there is a product manager in the mix, they typically help define these requirements and make them more precise for software development, but still, the receiver is human (developer) and they can fill a lot of the gaps.
Agents make the weakness of this process much more visible. An agent can execute an ambiguous instruction perfectly and still produce completely the wrong thing. This is why I believe another class of agents will become increasingly important before coding even begins. Their job will be to challenge requirements and understanding of the problem.
They can ask:
- What happens if this condition occurs?
- What permissions should this user have?
- What should happen when this API fails?
- What does success mean?
- What are the acceptance criteria?
- What assumptions are being made?
- What edge cases have not been considered?
The result should be requirements and specifications that are much more precise than what many development teams work with today. That does not mean humans surrender responsibility for requirements. Quite the opposite. The human responsibility moves upward. Humans should spend less time worrying about whether every minor edge case has been manually documented and more time determining:
- Are we solving the right problem?
- Are we building the right thing?
- How will we know whether it worked?
Agents can help make the specification complete. Humans must remain accountable for making the purpose correct.
Architecture becomes more valuable
I am far less comfortable turning architectural decisions completely over to agents. Agents are excellent at explaining architecture options, identifying patterns, comparing technologies, discussing tradeoffs, and helping architects explore alternatives, but architecture is not simply a technical decision. A local optimization can be completely rational for one component while being disastrous for the larger system.
An agent working within one repository or one part of a larger application may not fully appreciate organizational constraints, future product direction, integration dependencies, regulatory obligations, operational history, or the long-term economics of a decision.
This is where experienced software architects, senior developers, and product leaders become increasingly important.
They understand patterns. More importantly, they understand anti-patterns.
They recognize decisions that look attractive today but create scalability, reliability, maintainability, or performance problems two years from now.
Interestingly, emerging evidence supports this separation between direction and execution. Anthropic analyzed roughly 400,000 Claude Code sessions and found that humans generally made most of the planning decisions while the agent made most of the execution decisions. Greater human domain expertise was also associated with greater success.
That points toward a model I expect we will see repeatedly:
Humans determine what and why.
Agents increasingly determine how.
Coding itself will become a smaller part of being a developer
This may be uncomfortable, but I believe that manually writing code will eventually become a much smaller part of a professional developer's work. That does not mean software development disappears. It means typing code becomes less valuable. We have seen this repeatedly in technology. Knowing how to operate a typewriter was once an important professional skill. I personally took courses to learn how to type by going to a class with 20 other students and everyone of us had a type writer in front of us. It was serious stuff! Data entry was once an entire occupational category. Word processors, databases, automation, and now voice interfaces progressively reduced the value of manually entering information.
Software development is going through its own version of this transition. A developer does not need to understand every machine instruction executed when calling a function. Likewise, future developers may not need to manually implement every method in order to understand a system deeply.
Instead, their value will come increasingly from their ability to:
Decompose problems,
Understand systems,
Make architectural decisions,
Define constraints,
Recognize bad implementations,
Validate outcomes,
Understand business requirements,
Manage costs,
Manage tradeoffs,
and direct agents effectively.
In other words, developers move further up the abstraction stack. The best developers may actually become more valuable, because expertise allows them to direct agents better. The scarce resource changes from the ability to produce code to the ability to exercise judgment over enormous amounts of code that can now be produced cheaply.
Testing may become more important than coding
This is where I am considerably more cautious about today's agents. I am currently building applications using them, and I regularly see situations where automated tests pass but something obvious is still wrong. Agents can create extensive tests. They can create unit tests, integration tests, mocks, and automated validation; and yet they can miss something a human notices immediately. This is why I strongly believe AI-generated code should face more scrutiny, not less.
When code becomes inexpensive to create, verification becomes more valuable. Also, I would not rely exclusively on the same agent that wrote the code to prove that the code is correct. I expect mature AI-native development environments to use independent agents as adversarial reviewers.
One agent builds the solution. Another reviews the implementation. Another attempts to break it. Another examines security. Another validates requirements. Another looks for performance or scalability problems.
The architecture already exists conceptually. Multi-agent systems can assign different roles or perspectives to different models, and research increasingly focuses on orchestrators that delegate work across specialized agents. However, humans should continue to remain involved as well. At least for the foreseeable future, a person using an application can still identify obvious usability failures, logical errors, or contextual problems that automated tests miss.
The future of QA is therefore not:
AI testing instead of human testing.
It is:
AI testing + adversarial AI testing + automated validation + targeted human judgment.
When producing code becomes nearly free, proving that the software does the right thing becomes the expensive and important part.
Governance has to be designed into the system
Allowing agents to participate deeply in software development also creates an obvious problem. They can take actions, they can modify files, run commands, access systems, interact with repositories, and potentially touch production infrastructure. That demands the same kind of thinking enterprises have historically applied to human access and segregation of duties.
We would never sensibly give every developer unrestricted access to every production system merely because it was convenient. Agents should not be treated differently.
An organization needs to define:
which repositories an agent can access,
which commands it can execute,
which environments it can modify,
which data it can see,
whether it can create or approve pull requests,
whether it can deploy,
what requires human approval,
what activity must be logged,
and how actions are audited afterward.
This is increasingly how agent security is being approached in practice. OpenAI describes controls around access boundaries, human approval requirements, allowed systems, and agent telemetry when deploying coding agents internally. Anthropic has similarly emphasized containment through sandboxes, virtual machines, network controls, and carefully designed permission systems.
There is an important lesson here for enterprise leaders.
Govern the agent's capability, not merely its output.
For example, an agent may be permitted to:
identify a production defect → reproduce it → develop a fix → execute tests → prepare a pull request.
But a human may still be required to understand and approve the change before production deployment.
Over time, some classes of low-risk changes will probably become fully autonomous, but organizations should earn that autonomy based on evidence rather than declaring it on day one.
AI could reduce technical debt, or manufacture it at extraordinary speeds
There are two very different futures for technical debt. In one, coding agents continuously inspect systems. They identify obsolete dependencies. They find vulnerabilities. They update libraries. They detect duplicated code. They identify undocumented components. They discover performance problems. They propose refactoring. They continuously reduce the entropy that accumulates in every long-lived software system.
That future is exciting.
However, unfortunately, there is also another one, where agents generate enormous amounts of code that nobody fully understands. Features accumulate rapidly. Architecture becomes inconsistent. Tests validate individual components while systemic complexity quietly grows. The organization wakes up several years later with millions of lines of technically functional software that nobody wants to touch.
AI makes both futures possible.
This is why architecture, standards, automated verification, and continuous technical-debt management must become foundational parts of an AI-native SDLC.
Agents should not merely be used to generate new software. They should be continuously tasked with improving the software we already have.
Software teams will become smaller and roles will begin to merge
If agents take over more execution, team structure inevitably changes. I can imagine a future product team consisting primarily of four capabilities:
- Product leadership to understand customers, define outcomes, and determine what should be built.
- Architecture and senior engineering to establish technical direction and ensure the system remains coherent.
- Design and user experience to make sure what we build actually works for people.
- Delivery and operations to ensure software can be deployed, observed, secured, and operated reliably.
The traditional boundaries between roles may become much less rigid. In smaller organizations, an unusually capable individual may perform several of these functions while supervising multiple agents. That creates one of the opportunities I find most exciting about this transition.
AI coding dramatically changes the economics of entrepreneurship
For years, technology has progressively democratized capabilities that were once available only to large enterprises. Consider CRM. There was a time when sophisticated customer management systems required significant infrastructure, specialized teams, and large budgets. I worked for such a company where each CRM deployment was a multi-month endeavor with millions of dollars in investment.
Cloud software and SaaS changed all that. Companies such as Salesforce turned enterprise-class capability into something much smaller organizations could consume as a service. Any mom and pop shop could have a CRM, a sales process and build dashboards to monitor their sales, acquisition, retention, etc.
AI-assisted software development may create an even larger shift. A startup founder no longer necessarily needs a large engineering team to experiment with a sophisticated product. A small company can potentially build software with a level of sophistication that previously required substantially more capital and headcount. A capable founder who understands product, technology, design, and architecture can increasingly orchestrate agents to build an entire world-ready application.
This does not eliminate the advantages of large organizations, but it lowers one of the barriers protecting them. The same capability that allows an enterprise engineering team to deliver more software also allows four people to compete with forty, and in some cases, perhaps one person to compete with four. That is not simply a productivity improvement. It changes the economics of who can build technology companies.
The biggest mistake would be treating agents as developer replacements
This is where I believe many executives risk drawing the wrong conclusion. If an agent can generate code ten times faster than a developer, the obvious spreadsheet calculation is: “We need fewer developers.”
That may capture some short-term cost savings while missing the much larger opportunity. Coding agents should initially be understood as capability multipliers.
The question leaders should ask is not:
How many developers can this replace?
It is:
What could our best developers accomplish if execution stopped being their primary constraint?
- Could they finally modernize legacy systems?
- Could they eliminate technical debt?
- Could they experiment with ten product ideas rather than one?
- Could smaller teams own products end to end?
- Could product managers prototype ideas before putting them on the engineering roadmap?
- Could engineers spend more time understanding customers and less time writing boilerplate?
The organizations that simply reduce headcount may become cheaper versions of themselves. The organizations that redesign how software gets created may become fundamentally different companies.
The SDLC itself needs to change
The traditional software development lifecycle is usually described as something resembling:
Requirements → Design → Development → Testing → Deployment → Maintenance
Those stages will not disappear completely, but I expect their boundaries to blur substantially. When agents can plan, build, test, review, monitor, and modify software continuously, it makes less sense to treat these activities as discrete handoffs.
I believe an AI-native SDLC will look more like this:
Intent → Plan → Architect → Govern → Execute → Verify → Observe → Improve
Intent
Why are we building this? What customer or business problem are we solving? What outcome should change?
This remains fundamentally human.
Plan
What should the solution contain? What assumptions need testing? What are the requirements, dependencies, economics, risks, and measures of success?
Humans and agents collaborate heavily here.
Architect
How should the system fit together? Which patterns should guide it? What constraints must be respected? Agents advise.
Humans retain accountability for the larger system.
Govern
Which agents should perform which work? What models are economically appropriate? What data and systems may they access? Which actions require approval?
This becomes a new first-class SDLC discipline.
Execute
Agents perform an increasing share of implementation: generating code, configuration, tests, documentation, migrations, and infrastructure.
Verify
Independent agents, automated systems, and humans attempt to prove the implementation correct.
Observe
Production behavior, customer outcomes, reliability, security, costs, and unintended consequences are continuously monitored.
Improve
Agents and humans use those observations to refine the product continuously.
The loop then begins again. This lifecycle is less linear than the SDLC we grew up with. Planning, development, testing, maintenance, and optimization increasingly happen concurrently. That may ultimately be the most important consequence of agentic software development.
Humans move from execution toward judgment
I would summarize the division of responsibilities simply:
In an AI-native software organization, humans should be responsible for vision, architecture, judgment, and outcomes, while agents should increasingly be responsible for execution.
That does not make humans less important. It makes certain human capabilities much more important. Understanding the business, understanding the customer, recognizing a bad idea, making tradeoffs, designing coherent systems, knowing when the output is technically correct but strategically wrong, taking accountability for what gets deployed, etc. etc.
These are not incidental skills surrounding programming. They are becoming the core skills of software development.
What software development may look like in 2031
Imagine a business leader five years from now describing a new product idea. Before a single line of application code is produced, agents help explore the idea.
- They challenge assumptions.
- They model alternative architectures.
- They develop requirements.
- They estimate implementation options and operating costs.
- They identify regulatory and security considerations.
- They propose incremental delivery plans.
- They model which agents and models should perform different parts of the work.
- The human team reviews that plan and determines whether the opportunity is worth pursuing.
Only then does execution begin. Agents build the first increment. Other agents test and attack it. Humans evaluate whether it solves the intended problem. Telemetry shows how it performs. The team adjusts the direction. The next increment begins. The software evolves through a continuous conversation between human intent and machine execution.
That future does not eliminate software engineering. It may finally separate software engineering from the act of typing software. I believe that will prove to be as fundamental a transition as moving from machine instructions to high-level programming languages.
Every major advance in programming has allowed humans to express increasingly complex intentions with less mechanical effort. Coding agents are simply the next abstraction layer.
Except this time, the abstraction layer can think.