It was 2021 when they gave my access to Codex to GPT-3. An excited afternoon later I felt like an audience to a marketing gimmick as the code was buggy, it added imports without using them and the list continues.
Today is March 2026, Claude Code, Codex & Cursor are commonly used terms for software development. Spotify’s engineering team. We are in the middle of another one right now. Except this time, the shift is not about a new platform or a new data source. It is about who — or what — is writing the code.
The Shift That Changed Everything
Here is what happened. In 2023, AI coding assistants helped developers write code faster — autocomplete on steroids. In 2024, AI agents started writing entire features — you describe what you want, the agent builds it. By 2025, AI agents are building complete applications — from architecture to deployment — with humans reviewing rather than writing.
This is not a subtle change. It is a fundamental inversion of the development workflow.
In the old model, humans wrote code and used AI as a tool. In the new model, AI agents write code and humans provide direction, review output, and make judgment calls. Anthropic’s 2026 Agentic Coding Report describes it as “constant collaboration” — AI handles implementation, humans focus on architecture and product decisions.
The problem? We do not have an engineering discipline for this yet.
What Goes Wrong Without One
I learned this the hard way. My first attempt at building a production application with AI agents went something like this:
- Wrote a detailed prompt describing the system
- Told Claude Code to build it
- Got back a codebase that looked impressive
- Discovered, over the next two weeks, that it was full of subtle problems
The problems were not syntax errors or crashes. They were worse — the kind of “almost right” issues that Martin Fowler’s team at ThoughtWorks found are the #1 failure mode of AI-generated code. 66% of developers cite it as their biggest frustration.
The architecture was reasonable but inconsistent. Module A assumed one data model, Module B assumed a slightly different one. The naming conventions drifted between files. The test strategy was thorough in some areas and nonexistent in others. The agent had made hundreds of micro-decisions, each locally reasonable, that did not add up to a coherent system.
CodeRabbit’s data quantifies the problem: AI-generated code has 1.7x more issues than human code, 3x more readability problems, and approximately 8x more excessive I/O patterns. These are not minor differences.
Why Prompting Is Not Enough
The obvious response is “write better prompts.” And yes, prompt quality matters enormously. But prompting alone does not solve the problem for the same reason that writing better requirements documents does not solve all software engineering problems.
The issue is not the quality of individual instructions. It is the absence of systems that ensure consistency, enforce constraints, verify output, and maintain coherence across a complex build.
Consider the parallel with traditional software engineering. We do not just write code — we have CI/CD pipelines, code review processes, linting rules, type checking, test suites, architecture decision records, and deployment strategies. These are the engineering systems that turn individual code contributions into reliable software.
Agent-driven development has almost none of this. Most teams are still in the “write a prompt and hope for the best” phase. The few that have progressed further are discovering the same patterns independently.
What Is Agentic Engineering?
Agentic Engineering is the discipline of designing systems, processes, and knowledge structures that enable AI agents to build software autonomously and reliably.
It is not just “prompting.” It is not “vibe coding.” It is engineering — with the same rigor you would apply to building a CI/CD pipeline or designing a microservices architecture — applied to the question: how do you make an AI agent a reliable software engineer?
The key word is “reliable.” Anyone can get an AI agent to produce code. The hard part is getting it to produce code that is consistent, correct, maintainable, and aligned with your product values — every time, not just on the first attempt.
Why Now?
Three things converged in 2025 that made Agentic Engineering both necessary and possible:
1. Agents Got Good Enough to Build Real Systems
Frontier models in 2025 can hold enough context, follow complex instructions, and produce code of sufficient quality that building complete applications with them is viable. Not perfect — but viable. The gap between “this almost works” and “this works” is now closeable with engineering discipline rather than fundamental model improvements.
2. The Tooling Caught Up
Claude Code, GitHub Copilot Workspace, Cursor, Windsurf — the agentic development tools matured from experiments to daily drivers. Features like CLAUDE.md entry points, hooks for deterministic enforcement, skills for domain-specific knowledge, and subagents for parallelized work give us the building blocks for engineering systems around agents.
3. The Failure Modes Became Clear
A year of production use has taught the community where agents fail:
- Context degradation: 65% of developers cite missing context as the top cause of poor AI code quality (Stack Overflow 2026)
- Compounding mistakes: Long-running agent sessions accumulate errors that cascade (Martin Fowler / ThoughtWorks)
- Assumption-filling: Agents fill knowledge gaps with plausible-sounding defaults instead of asking (OpenAI’s Harness Engineering)
- False success claims: Agents sometimes declare success despite failures (multiple sources)
- Self-review blindness: The same agent that wrote code is bad at reviewing it (Anthropic, CodeRabbit)
These failure modes are not random. They are predictable and addressable — but only with engineering systems designed to catch them.
The Patterns I Have Found
Over the past year, I have been developing and testing a set of Agentic Engineering patterns. Each one addresses a specific failure mode of agent-driven development. This series walks through all of them:
Each pattern is independent — you can adopt any of them without the others. But together, they form what I believe is the beginning of a coherent engineering discipline for the agentic era.
The Human Role Changes — It Does Not Disappear
I want to be clear about something: Agentic Engineering does not eliminate the need for human engineers. It changes what human engineers do.
In the agentic model, humans are responsible for:
- Architecture and product decisions — the one-way doors that shape everything downstream
- Knowledge curation — building and maintaining the knowledge stores that agents consume
- Quality oversight — reviewing agent output, interpreting verification reports, making judgment calls
- Guardrail definition — deciding what the agent must never do, not just what it should do
The analogy I keep coming back to is the shift from hand-coding assembly to using compilers. Compilers did not eliminate programmers — they elevated what programmers worked on. Agentic Engineering does the same thing. The agent handles implementation. The human handles intent.
Who This Series Is For
If you are an engineer, architect, or technical leader who is:
- Building production software with AI agents (not just prototypes)
- Frustrated by the “almost right” quality of agent-generated code
- Looking for repeatable processes instead of ad-hoc prompting
- Trying to figure out how human oversight scales as agent capability grows
Then this series is for you. I do not claim to have all the answers — Agentic Engineering is still a young discipline, and these patterns will evolve. But the problems are real, and waiting for perfect solutions means falling behind teams that are figuring it out now.
Next Up : Part 2 – Knowledge First Development