Large language models and coding agents are changing software development at a pace that is arguably unprecedented in our industry. We have seen substantial shifts before, technology moving from assembly language to higher-level languages, from native code to virtual machines, process from waterfall to agile, architecture from on-premises to cloud. The transition to agent-assisted and agent-driven development belongs in that category.
There is increasing evidence that implementation itself is becoming progressively commoditised for a wide range of software problems. In March 2025, Anthropic’s CEO Dario Amodei predicted that AI would be writing 90% of code within 3 to 6 months, and essentially all of it within 12. Our own use broadly aligns with this prediction - whether the exact timing proves correct or not for you, the directional claim has definitely held up. For well-specified tasks, from simple CRUD endpoints to data transformations and rich front-ends, modern coding agents already produce production-quality output with minimal direct implementation effort from developers. This capability is only going to expand. The statement that “coding is solved” is provocative and not literally true, but it is closer to true for more classes of work than many have as yet absorbed.
What remains unsolved is everything around the code: deciding what to build, expressing it precisely enough that an agent, reliably and repeatedly, produces the right thing, verifying it behaves correctly, integrating it with, or updating, existing systems, and maintaining the reasoning and knowledge so the next change can be made safely. That is where work on agents has moved.
In contrast, the rise of “vibe coding” has arguably created confusion and resulted in a loss of credibility around what professional software engineering should look like in the age of coding agents. I do not think that vibe coding is the direction we are headed in. While informal experimentation is valuable for prototypes and exploratory work, production systems with real security, integrity, operational and reliability requirements still demand disciplined engineering processes and professional product managers and developers.
The question is no longer simply whether an LLM can write code - increasingly, it can. The challenge, right now, is how organisations can build reliable, repeatable and auditable products that make effective use of agentic software development to accelerate productivity reliably.
This article describes the approach we have evolved internally over the last 2.5 years and why we believe specifications, issue context and decision history are becoming the new source code layer for product and software engineering.
The Two Phases of LLM Adoption
Our own adoption of LLMs for software development began in 2023. Looking back, the evolution has occurred in two distinct stages.
1. Coding Assistance
Initially, LLMs acted primarily as developer assistants. Useful, sometimes extremely useful, but they did not fundamentally change delivery velocity. Typical usage patterns included:
Web Search Alternative: In the early stages, LLMs often replaced traditional search workflows by providing contextual answers and richer guidance faster than manually searching documentation or Stack Overflow.
Discrete Assistance: LLMs became increasingly useful for focused implementation tasks: individual functions, SQL queries, algorithms, data transformations, test scaffolding and refactoring suggestions.
Review and Analysis: LLMs also proved valuable for high-level code review: surfacing security concerns, architectural inconsistency, performance issues, coding-standard violations and common anti-patterns.
During this stage, the developer remained unquestionably in the driving seat. The LLM was an accelerator and a quality check.
2. The Agentic Evolution
In late 2025, the dynamic changed dramatically with the increasing capabilities of models and agents that were able to execute long-running tasks reliably.
Coding agents quickly evolved from simple LLMs assisting developers to increasingly performing the majority of implementation work. The transition happened surprisingly quickly. What had been 20% agent-generated code became 80%. Further improvements in early 2026 from all major model providers accelerated this shift again and, with effective processes, agentic coding has now often exceeded 95% sustainably. They have also opened the door to tasks that would have been considered “too complex/expensive/risky”. The important qualifier here, though, is “with effective processes”.
Without that critical process discipline, high levels of agent-generated code rapidly produce systems that are difficult to understand, maintain or trust. Not because the code quality itself is necessarily poor (it is often inconsistent and confused), but because the organisation loses visibility into why decisions were made, what assumptions existed, what constraints applied, what trade-offs were accepted and what the intended behaviour actually was. This is the challenge with pure vibe coding.
This distinction matters enormously. Our experience is that effective use of agentic coding depends on shifting how we think about the artifacts that are tracked and the processes used to create and consume them. It mirrors previous evolutions seen in the industry.
We Have Seen This Pattern Before
There is a useful historical analogy here, and while not exact there are many parallels with where agentic development is working and where not.
Early systems programming involved directly manipulating machine instructions and processor operands, often in hex. Developers reasoned at an extremely low level of abstraction, working directly with the physical processor operations.
Assemblers then introduced a slightly higher level of abstraction, providing symbolic representations that were mechanically translated into machine code, making it simpler to understand and maintain programs.
Higher-level languages such as Fortran, Pascal, C and C++ then abstracted development further. Developers no longer thought primarily in machine instructions. They worked in increasingly expressive abstractions while compilers (or interpreters) generated the lower-level implementation details - the machine code.
Initially, developers inspected compiler output. Inline assembly was a common feature of many compilers used where performance was critical. Compiler optimisation was not that capable, but over time this improved dramatically and developers stopped inspecting compiler output at all. Compilers became better than all but the best developers at generating efficient machine code.
The same pattern has repeated with JVM-based systems and .NET intermediate languages, which delivered higher abstractions through managed runtimes that brought in capabilities like improved memory management and JIT compilation.
JIT compilation is also interesting because it is, to some extent, non-deterministic: the optimisations applied depend on instrumentation captured at runtime, potentially producing different output code on different machines under different circumstances. A type of limited non-determinism we have all accepted.
Today, very few developers inspect intermediate bytecode or lower-level machine code in normal workflows.
The important observation, however, is this:
As abstraction levels increase, developers progressively stop concerning themselves with lower implementation layers and instead focus on higher-order intent. Through the previous iterations this has been some form of “source code”.
We believe agentic software development simply represents another major abstraction shift that is occurring on the same continuum - so this raises the question - “What is source code in the agentic age?”
The Critical Difference
There is, however, one major difference between traditional compilation and LLM-driven development. Historically, developers managed the source code artifact - the highest-level intent. Arguably specification documents existed as well, but were often unmanaged. Compilers generated the implementation artifacts and that generated output was reproducible and therefore considered disposable.
With coding agents today, many teams are doing the reverse. They are managing generated code in source control (now an implementation artifact), but losing or discarding the higher-level intent including the reasoning process and the decision context, and treating conversations with the agent as ephemeral.
If we follow the previous evolutions, this is a critical mistake. The enduring engineering artifact is no longer just the implementation code itself. The real source code layer in this agentic world will have to consist of specifications, constraints, decisions, test intent, architectural guidance, operational considerations, issue diagnostics and acceptance criteria, all held as managed artifacts.
As capabilities of agents improve, and trust in them increases, we think the generated code will increasingly become an implementation artifact derived from that higher-level intent - the same as with previous transitions. The direction of travel is becoming increasingly clear, and if we are to maintain productivity and knowledge we cannot keep actively throwing away the context that defined the output artifacts.
Adapting Development Practices for Coding with Agents
The first step is redefining what “source code” means in an increasingly agent-driven environment. Our conclusion has been that specifications and issue descriptions must become first-class engineering artifacts, version controlled alongside the source code itself. This is consistent with what is expressed elsewhere as “spec-driven development.”
Specifications as code
Specifications are now being used for new features, enhancements, architectural changes and larger refactors. These are stored as Markdown documents within the repository and linked to roadmap items where appropriate.
We have found that a markdown template with the following sections covers the needs.
# Background
# Objective
# Non-Goals
# Functional Requirements
# UX Considerations
# Security Considerations
# Auditability and Observability
# Test Strategy
# References
# Decisions
# Implementation Plan
# Summary
The process matters as much as the document itself. Different parties get involved with different sections, starting with product managers and bringing in engineering, UX, test teams and deployment teams as the document develops. Clear ownership of sections is important. Importantly, the specification is discussed iteratively between parties and with an LLM before implementation begins. The document can reference other artifacts, especially design systems, coding standards and architectural patterns. This discussion focuses on missing requirements, edge cases, security concerns, operational impacts, migration risks, testing approaches and performance implications. The resulting conclusions are recorded back into the specification.
From an engineering perspective, the implementation plan is especially important, relying on everything that has gone before as well as the existing system. We typically ask the agent itself to generate and maintain an implementation checklist within the document, or as a separate document, for example:
- [ ] Create migration
- [ ] Update API contract
- [ ] Implement service layer
- [ ] Add observability metrics
- [ ] Add integration tests
- [ ] Update user documentation
This gives several benefits: progress tracking, resumability, intermediate commits, auditable implementation history and reduced context drift, ultimately giving more flexibility and less uncertainty.
The actual implementation step then becomes relatively simple: a clean agent context is created and the coding agent is asked to implement the specification according to the documented plan.
As implementation progresses, additional questions and decisions may emerge. These are added back into the specification, building on the single source of truth, and at the end the agent can summarise its actions back into the document.
At completion, code exists, tests exist, decisions exist, context exists and the rationale exists. The specification becomes a durable engineering artifact that is fully managed. Changes to functionality can be handled as new features in a new document, or by amending an existing specification and asking the agent to provide a new plan in a subsection of the document.
Issues as Code
Any serious software will encounter production issues originating from customer reports, monitoring alerts, performance degradation, exceptions, integrity failures or security concerns.
Adopting a similar workflow to the specifications above, we increasingly ask the LLM to diagnose the issue rather than immediately jumping into code. The agent is provided with substantial context: stack traces, logs, SQL queries made, monitoring data, exception telemetry and the code itself.
Modern models are remarkably effective at root cause analysis across large codebases, particularly when explicitly instructed to identify underlying causes rather than local symptom suppression.
Once diagnosis is complete, we ask the agent to generate or update the GitHub issue with: root cause analysis, proposed remediation, test considerations, rollout considerations and an implementation plan.
At that point, the issue itself becomes a source artifact. Implementation then follows the same specification-driven process.
The key objective throughout is preserving engineering knowledge rather than attempting to reconstruct intent later from a fragmented commit history.
Testing, Review and Verification
Automated testing becomes more important, however. Our experiments have found directing agents using test-driven development to be a poor fit, but comprehensive automated testing is vital. The testing strategy, acceptance criteria and critical edge cases belong in the specification itself. Fortunately agents make great use of testing frameworks especially when given rich context from the specification. Explicit test intent, realistic integration testing strategies, regression checks, security scanning and observability validation can all be incorporated in the main agentic loop, or as separate sub-agents.
Code review has also evolved. Historically, review happened after implementation and “local” testing. But when the majority of code is generated by an agent, manual inspection of every implementation detail becomes increasingly difficult to scale effectively - and back to the proposition above, the output of the agent is going to be increasingly disposable.
Instead, if trust in agentic coding output is increasing, then the value of review naturally shifts earlier in the process. The specification itself becomes reviewable by product teams, engineering leads, security teams, QA, services and operations. This broadens participation and improves alignment significantly, and we are seeing greater benefits.
Human review still matters, especially for security-critical systems, complex architectural changes, regulatory requirements and data integrity concerns.
But review increasingly focuses on intent, constraints, behaviour, risk and verification rather than line-by-line implementation mechanics.
In many ways this resembles the old Extreme Programming observation: if code review is valuable, close collaborative pairing is often more valuable. Today, the “pair” is increasingly a developer with domain expertise alongside a highly capable coding agent.
Outcomes
The productivity gains, when the process is right, are very real. Not incremental improvements, but order-of-magnitude changes in delivery capability - not just speed.
It is the ability to iterate on ideas faster, reduce coordination overhead and preserve engineering intent more effectively. It is the ability for a small team to credibly modernise a legacy platform. It is the ability for a product manager to interrogate a specification with the same agent that will implement it.
It is, ultimately, a shift from optimising for code production to optimising for product direction, and we will see new classes of products and solutions coming to the market as a result.
What Happens to Developers?
We do not believe software engineering disappears, but the role does change. As with every abstraction shift before it, the primary working language of developers moves higher.
The emphasis shifts further toward system design, product reasoning, specification quality, constraint definition, risk analysis, operational thinking, verification and human coordination. Arguably these are all things a great (senior) developer does anyway, but they will become much more explicit.
One of the most positive, and most underappreciated, consequences of this shift is the convergence of product and engineering. The separation between the two functions was always somewhat artificial, a result of practical necessity rather than principles. Engineers managed the implementation detail, product managers managed the user and market context, and translation between the two was where most software organisations lost time and lost intent. The changes due to agents have the potential to dissolve much of that boundary.
A product manager working in a specification-driven workflow can now interrogate, simulate, prototype and refine their thinking with the same agent that will ultimately implement the work. They are no longer dependent on engineering availability to test whether an idea is technically coherent, or what its implications might be. Their work becomes richer, faster and far more grounded in reality. Data-driven decisions become easier and trials lower cost.
An engineer working in the same environment finds the inverse. Product context becomes a first-class input to their daily work rather than a brief handed across a boundary. Decisions that used to be deferred until implementation, causing rework, are now made deliberately and visibly, often in direct conversation with the product owner and captured in the specification itself.
This is not the merging of two roles into one.
It is two disciplines that have always belonged closer together finally finding a common working surface that lets them collaborate at the right level of abstraction, equally valuable to both parties. Product managers develop sharper technical and verification intuition. Engineers develop sharper product judgement. Both roles become much more effective, and the organisation gets faster and better-aligned decisions in return.
For organisations willing to embrace it, this convergence is one of the most exciting opportunities to come out of the entire transition.
If AI Agents unlock our ability to implement, then the key questions become less about “Can/How do we implement this?” and more about “What should we build, why should we build it, and how do we verify it behaves correctly?” That shift is truly profound.
Business Impacts
An order-of-magnitude increase in engineering productivity changes business strategy substantially. Different categories of companies will likely respond differently.
Legacy Businesses
In reality this is probably the largest category. These are existing companies that typically carry multiple product lines, acquired platforms, large existing customer bases, significant technical debt and complex migration challenges.
Historically, modernisation programmes have often been prohibitively expensive and risky.
Coding agents materially change that equation.
Large-scale refactoring, platform convergence and product revitalisation become far more achievable.
Profitable SaaS Businesses
These organisations often already have strong margins, cloud-native architectures, a single-product focus and large backlogs.
For them, the opportunity may not primarily be cost reduction. Instead, it may be faster market expansion, greater experimentation, broader feature coverage and improved customer responsiveness.
The strategic question becomes whether increased productivity is harvested as profit or reinvested into accelerated innovation.
Not Yet Profitable Businesses
Earlier stage companies may choose to use productivity gains primarily to control costs.
This may reduce required team sizes in some cases.
At the same time, dramatically lower implementation costs also reduce barriers to entry and enable entirely new classes of startups to emerge.
Historically, abstraction shifts have expanded software creation overall rather than reducing it.
There is little reason to believe this transition will be different.
Conclusion
We believe the industry is currently in an intermediate transition phase.
Many teams are still treating generated code as the primary artifact while discarding the intent that created it. Others are generating more output without first asking whether they are building the right thing and discovering that more code does not equal more progress.
That is unlikely to remain the dominant model.
The organisations that scale effectively with coding agents will be those that preserve intent, treat specifications as durable assets, capture decisions explicitly, automate verification aggressively, shift review earlier into the process, treat implementation increasingly as a generated concern, and strengthen product direction rather than dilute it.
The code still matters today.
But increasingly, the specification is becoming the true source.