Intro

AI-assisted software development is often described in terms of how much code machines can now produce. But code generation is only a piece of the change. As producing software becomes easier, determining whether that software deserves to be trusted becomes a larger part of the engineering work.

One way to understand this change is to examine three overlapping approaches to AI-assisted software development: vibe coding, agentic engineering, and the Agentic Development Lifecycle (ADLC). These approaches differ in what developers delegate and what they must verify.

The term “vibe coding” describes a practice in which a human builds software by giving an AI natural-language instructions. At this end of the spectrum, getting something working can matter more than ensuring it remains reliable over time.

In agentic engineering, AI serves as a development tool, while a human remains the primary decision-maker. Here, AI-generated code is not treated as a ready-to-use solution, but as a proposal for review and testing.

In ADLC, the agent becomes part of the product and takes responsibility for multi-step engineering tasks. The human role moves further away from writing individual lines of code and toward judgment and verification.

These approaches therefore share one central problem: AI can produce software faster than humans can inspect it manually. The more work is delegated to AI-assisted software, the more important it becomes to decide what to verify and how to verify it. What kind of evidence is needed before developers can trust the outcome? This article uses vibe coding, agentic engineering, and ADLC as three ways of examining that problem. They are not stages every developer needs to progress through; they require different levels and kinds of discipline depending on what is being built. A separate, in-depth post will examine the ADLC itself in greater detail.

Key Takeaways

• AI-assisted development differs in how much work is handed to AI: prompting for working code in vibe coding, delegating specified tasks for structured review in agentic engineering, and building the agent into the product itself in the ADLC. In each case, humans remain accountable.
• Vibe coding is not passé. It can work great for prototypes and low-risk projects. However, when reliability and security matter, it might not be enough.
• AI-assisted software is currently focusing on code verification. As AI makes code generation faster and cheaper, the real value lies in knowing how to review and correct what AI produces.
• More AI-generated code can also mean more risk. Faster generation increases the need for processes that keep code secure and maintainable.
• Spec-driven development adds structure when complexity requires it. It gives both humans and agents a clearer plan and shared context.
• ADLC focuses on behaviour, not just code. When the agent is part of the product, continuous evaluation becomes essential.
• The right level of discipline depends on the potential impact of failure. The goal is not maximum process; it is using enough discipline to match the risks involved.

Vibe Coding Meets the Agent

The vocabulary around AI-assisted development has changed quickly because the work being delegated to AI has changed just as quickly. Following that chronology helps explain why verification has become such a central concern.

February 2025: Introducing vibe coding

Originally, Andrej Karpathy introduced the term "vibe coding" in an X post on February 2, 2025, to describe using natural language to write a prompt that generates code. It marked a turning point in coding, reducing the need for humans to work directly with code and supporting the notion that everyone is a developer. But here is a caveat: as developers move further away from the code, it becomes harder to personally verify what the model has produced. That trade-off matters less for disposable experiments and much more for software others will rely on.

December 2025: changing the workflow

Andrej Karpathy mentioned that his own workflow had changed by December, with agents generating around 80% of the code and only 20% manually edited.

This became possible because AI-assisted software can handle larger, more coherent units of work that often don't require immediate correction. As a result, the vocabulary around AI-assisted programming also began to change. Agents are increasingly described as systems capable of performing multi-step engineering tasks, such as implementing features, refactoring code, researching libraries, writing and running tests, fixing failures, and so on.

February 2026: agentic engineering

By February 2026, agentic engineering had turned into a useful term for the emerging style of development.

Vibe coding still has an important role because, as Karpathy put it, it “raises the floor”: more people can build software without needing the same level of technical expertise. Agentic engineering, meanwhile, “raises the ceiling” by enabling experienced developers to coordinate agents and take on larger, more complex engineering tasks.

April 2026: greater autonomy

By April 2026, it was becoming clearer what agentic engineering looked like. Agents could do much of the implementation work, but developers still made the important decisions and checked the work. At his April Sequoia talk, for example, Karpathy explicitly described this division of responsibilities. In practice, this meant adding structure around the agent’s work: defining specifications and plans, breaking work into tasks, inspecting suggested changes and diffs, running tests and evaluations, and deciding whether the resulting implementation met the intended requirements.

May 2026: introducing ADLC

The next shift occurs when the agent becomes part of the product itself. At that point, checking an implementation is not enough because the system’s behaviour can vary after deployment. This is the problem that the Agentic Development Lifecycle attempts to address.

Since that moment, various companies have published their own variations on the ADLC concept. For example, LangChain published its ADLC framework in May 2026, describing a continuous Build-to-Test-to-Deploy-to-Monitor cycle. Glean also introduced an enterprise ADLC framework in May 2026.

As approaches to using AI-assisted software evolve over time, teams can produce software faster and in greater volumes than their existing review and testing processes can comfortably keep up with. Let’s take a closer look at where this issue lies.

Why Verification Matters

Several studies show where the quality and security problems in AI-assisted code can appear. Together, they help explain why verification matters as AI takes on more of the development work.

GitClear’s analysis of 211 million lines of code edited between 2020 and 2024 found that the proportion of changed lines associated with refactoring fell from approximately 25% in 2021 to under 10% in 2024. Over the same period, the share of code classified as cloned or copy-pasted rose from about 8.3% to 12.3%. In 2024, GitClear found that copy-pasted code had overtaken refactored code for the first time. That does not mean AI-assisted software caused every instance of duplication. However, AI makes generating new code extremely cheap and therefore popular, even though this code still requires deliberate engineering judgment.

Security tests also deserve attention. Veracode tested over 100 large language models across Java, Python, C#, and JavaScript to find whether most advanced AI systems can write secure code. They found that 45% of code samples failed security tests and introduced OWASP Top 10 vulnerabilities. This rate remained largely unchanged through early 2026, even as models continued to improve on conventional coding benchmarks.

Apiiro, an application security company, analysed code from tens of thousands of repositories and several thousand developers across large enterprise environments and a variety of coding assistants. The data showed that more than 10,000 new security findings were linked to AI-generated code, increasing roughly tenfold between December 2024 and June 2025.

Apiiro also reported that changes were growing larger and more complex while pull request volume fell, making each change harder to review. An agent may produce more code in one pass, but the reviewer still has to understand and verify what it produced.

The problem is even clearer in applications created through the vibe coding approach. Escape.tech’s research team analysed more than 5,600 publicly available applications and identified more than 2,000 vulnerabilities, over 400 secrets, and 175 instances of exposed personally identifiable information. Many of the problems were accessible through public endpoints without authentication, including misconfigured APIs, exposed credentials, and missing database access controls.

Taken together, these studies do not suggest that AI-generated code is necessarily worse than human-written code, but they show why code that looks right isn't necessarily right and needs verification. AI can produce an implementation that seems reasonable and works in the most obvious cases, while still hiding problems beneath the surface. Those problems might be insecure assumptions, poor design choices, or failures that only show up in situations the developer did not initially test. The question, then, is what needs to be checked and how.

That depends on what AI was asked to do in the first place.

Three Rungs of AI-Assisted Software Development

The three rungs are easiest to understand through that verification question. The difference between the three approaches becomes clearer when you look at what the developer hands over to AI and what still needs to be checked afterwards.

Vibe coding

In vibe coding, developers describe what they want and let the model generate the implementation. Most of the process happens through prompts and conversation, with the chat itself becoming the primary record of how the software was built.

The model writes the code and keeps adjusting until it works. For a quick prototype or a small project, that may be enough. The problem usually comes later. Code which seemed fine at first can become hard to understand, fix, or build on once the project grows or someone else has to work with it.

Agentic engineering

In agentic engineering, the unit of work becomes a specified engineering task rather than an individual prompt or piece of code. The agent carries out the task and produces a change for the developer to review.

The developer still needs to ensure the agent built what was requested and that the result works as intended. This gets harder when an agent makes a large change at once, which can drift from the original request, and the amount of code to review makes mistakes easier to miss.

ADLC

ADLC is different because the agent is part of the product people actually use. At this point, checking the code is no longer enough. The agent also needs to perform reliably across the different situations it may encounter. Evaluations help determine whether it actually does. The risks also continue after deployment because the agent’s behaviour can change over time, or a capability can work as intended but become too expensive to operate.

The middle case, aka agentic engineering, raises a practical question: if an agent is going to take on a substantial engineering task, how do we give it enough structure to carry it out without manually directing every line of code? One increasingly common answer is spec-driven development.

The Middle Rung in Practice: Spec-Driven Development

Spec-driven development gives agents more direction before they start writing code. Instead of giving an agent a request and waiting to see what it comes back with, they first spell out what needs to be built, work out a plan, and break that plan into smaller tasks. The agent then follows those steps through to implementation, so developers can catch misunderstandings or questionable decisions before they make it into the finished code.

Two well-known implementations illustrate different ways to package the idea:

• GitHub Spec Kit is an open-source, agent-agnostic toolkit built around a Command-Line Interface (CLI). It deliberately separates the technique from the coding agent: the same workflow can be connected to a wide range of agents, including Claude, Copilot, Gemini, Codex, and others. Developers can run its core process step by step or automate it, with additional commands for clarification, analysis, and quality checklists.
• AWS Kiro takes a more integrated approach to packaging: spec-driven development is built directly into an agentic Integrated Development Environment (IDE). Kiro turns an initial idea into structured requirements, a technical design, and a sequence of implementation tasks. Before implementation proceeds, it runs checkpoints. Its steering files provide persistent project-specific guidance, while agent hooks can automate recurring actions.

Companies promoting spec-driven and agentic development frequently report dramatic acceleration figures. For example, Kiro reports a case in which a project estimated to take 24–32 weeks to reach testing was completed in 5–7 weeks. But this figure is best interpreted as a vendor-reported case study, not as independently established evidence that spec-driven development will produce the same result elsewhere, because the evidence remains difficult to compare across companies and projects. Different teams measure different outcomes, use different baselines, and often combine the effects of better models, improved tools, new workflows, and changes in project scope.

For this framework, the exact speed improvement is less important than what spec-driven development reveals about the evolving development process. As agents take on larger pieces of engineering work, they must turn a vague request into a series of clear decisions and artefacts that can be checked along the way. Developers can use them to understand the assumptions and design choices behind the implementation, while agents gain clearer insight into what they are building and how to proceed. In other words, giving agents more autonomy also means giving their work more structure.

But there is still an important limitation here: the agent is building software that will eventually need to be reviewed and delivered. Once the agent itself becomes part of the delivered product, that is no longer enough. At that point, the agent’s behaviour also needs to be verified after deployment, across different situations and over time. This is where the ADLC becomes necessary.

When the Software Is an Agent: What the ADLC Changes

Traditional software development and agent development share many engineering practices, but they vary in what must ultimately be proven. With conventional deterministic software, developers can generally expect the same system state and input to produce the same result. An agentic product can instead vary its response based on the behaviour of probabilistic models, retrieved context, prompts, available tools, and other changing conditions.

That means a product can have perfectly valid code while the agent built from that code still behaves poorly in a particular situation. ADLC extends verification from asking whether the software implementation works to asking whether the agent behaves acceptably over time.

This is why evaluation takes on a different role. In a conventional SDLC, tests are important artefacts used to establish whether the implementation behaves as expected. In agent development, an evaluation suite is central to defining and measuring what constitutes acceptable behaviour. The objective is to observe behaviour in representative situations, identify failures, improve the system, and ensure those improvements remain intact as the system changes.

Arthur AI, an AI observability and evaluation company, proposes a continuous development flywheel. The idea is to observe real behaviour, turn failures into evals, improve, and lock in the fix so it stays fixed. If production failures become a growing set of real-world examples, they can help identify what the agent needs to keep getting right.

The agent development flywheel is not a universal solution because vendors describe this lifecycle differently. For example, Salesforce separates the inner development loop from the outer loop of continuous supervision and tuning. Glean's enterprise ADLC divides the process into seven stages: Opportunity, Design, Performance, Input, Develop, Launch, and Monitor & Improve.

The approaches differ in their structure and phase names, showing that the ADLC has not yet settled into a typical lifecycle. It remains largely vendor-defined, although there is growing agreement on one point: building and operating an agent are closely connected. The vocabulary is also not standardised, and Gartner’s 2026 survey found that only 17% of organisations had deployed AI agents, even though more than 60% expected to do so within the next two years. The ADLC should therefore be treated as an emerging engineering framework rather than a settled industry standard.

That brings the discussion back to a practical question of how much structure and verification does a particular project actually need?

Choosing Your Rung

Not every project needs the same level of engineering discipline. Treating a weekend project like a production system would add complexity without much benefit. Therefore, a vibe-coded personal expense calculator probably does not need a full ADLC. The requirements are very different for an AI agent that autonomously reviews invoices, decides which ones to pay, and interacts with financial systems. In that case, continuous evaluation, monitoring, permissions, and behavioural testing become much more important.

The first consideration is what happens when something goes wrong. A bug in a personal tool might be annoying, but it is usually cheap and easy to fix, so that vibe coding can be perfectly reasonable. The situation is different when software handles payments, personal data, authentication, infrastructure, or critical business processes. A mistake there can have much more serious consequences. That calls for stronger specifications, testing, reviews, monitoring, and other ways of checking that the system is doing what it should. It does not necessarily mean moving to another rung. It means choosing the practices that make sense for the level of risk.

Next comes reversibility. Can a project be rebuilt from scratch if something goes wrong? If it’s a weekend project, the answer is probably yes. A production system with years of accumulated data, integrations, and users is much harder to replace. The harder a change is to undo, the more planning and review it deserves.

Also, the more people or systems count on the software, the less acceptable it becomes to treat it as good enough to be considered a success. With only one person using a weekend project, it’s reasonably acceptable to take shortcuts that would be rejected in a shared production codebase. If another developer will have to maintain the system six months from now, clear specifications, tests, documentation, and review become much more valuable.

The type of output matters too. If software behaves predictably and produces the same result from the same input, traditional testing and code review may be enough. But that becomes harder when a system can produce different results, rely on models that change over time, incorporate external information, or take actions through external tools. In those cases, testing before release is only part of the job. The system also needs to be evaluated and monitored once it is running.

Seen this way, choosing a rung is not a judgment about how sophisticated a developer or team is. It is a decision about what kind of evidence a particular system needs before its behaviour is trustworthy.

Closing thoughts

AI-assisted software may make it easier to produce code, but that does not make good engineering judgment any less important. As AI takes on more of the coding, developers must focus more on deciding how to verify the results and check whether they actually do the job they were meant to do.

What connects vibe coding, agentic engineering, and ADLC is that they put verification in different places because they deal with different kinds of work. Vibe coding may need little more than checking that something works. The middle rung adds specifications, tests, and review as agents take on larger engineering tasks. ADLC carries verification into production, where the agent’s behaviour must be evaluated over time.

None of these approaches is the destination. The useful questions are what is being built, what could go wrong, and what evidence is needed before the result can be trusted. As AI takes on more of the implementation, a larger part of the developer’s skill lies in answering those questions: knowing what needs to be specified, what needs to be tested and reviewed, where problems are likely to appear, and how much evidence is enough. The advantage is knowing when the software AI produces is actually right for the job and recognising when it is not.