Agentic Engineering: Where Loops Fail in Practice and Why

Boris Cherny, Head of Claude Code at Anthropic, said a sentence that went through the tech scene: "I don't prompt Claude anymore, I write loops that prompt Claude." That sounds like elegance, like acceleration, like the future. But it also sounds like risk, because in large enterprise projects reality often looks different than in social media demos or green-grass projects. In Part 2 we showed how code reviews can be done meaningfully in the age of AI coding agents. This post goes one step further and asks: even when you build verification right, where do loops still fail in practice? We at codecentric have been working with agentic AI in client projects for months and see five failure patterns that appear repeatedly. In the following I show what they look like and how we avoid them. Whoever wants to introduce agentic engineering in their company should know them before starting.

What Is Agentic AI — And What It Is Not

Agentic AI refers to AI systems that decide on action sequences themselves and use tools — in contrast to generative AI, which only responds to prompts. Agentic AI plans, acts, observes the result and decides the next action. This happens on the basis of an LLM at the centre of the architecture. When you use such an agent in development, this is called agentic engineering. It is the prerequisite for loop engineering.

Agentic AI thus goes much further than an LLM alone: generative AI needs a good prompt. Agentic AI additionally needs an environment — tools, permissions, goals, verification. In Part 1 we showed that this environment is discussed in the market under three terms: Context Engineering, Harness Engineering, Loop Engineering. Agentic AI is what lives inside it; loop engineering is what triggers it repeatedly.

Whoever searches for the term quickly lands at Andrej Karpathy's February 2025 tweet in which he coined "Vibe Coding": the almost playful surrender to AI-generated code. What many overlook: Karpathy himself said in May 2026 that vibe coding is passé — the models are now too good, the term too vague. Hence his new label: agentic engineering.

Let's now look at what this can look like in practice when agentic engineering is used in large enterprise projects, and which five problematic patterns we have seen repeatedly at codecentric in the last months.

Pattern 1 — The Loop Runs but Builds the Wrong Thing

The first pattern is tricky because it is not a technical error and therefore does not stand out immediately. The agent apparently did everything right: it got an understandable prompt, planned cleanly, wrote functioning code, got the tests green. And still it is the wrong thing. Its spec interpretation does not match the business need.

In one of our insurance projects, an agent was supposed to implement calculation logic for premium adjustments. The spec sounded clear: "Calculate new tariffs per contract change, archive old tariffs." The agent implemented exactly that — and overlooked that "contract change" for the specialist department includes dozens of special cases that were not in the spec because they are self-evident for domain experts.

In the Loop Model this gap is called the ECM gap (Enterprise Context Management): the coding loop has no access to the domain context that makes the spec understandable in the first place. The only answer is a spec that contains this context explicitly — and a spec review by domain experts before the coding loop starts. Whoever does not do this builds fast, but the wrong thing.

Pattern 2 — The Loop "Deletes" Its Own Tests

When new features break existing tests, an agent has two options: adjust the feature or adjust the tests. The goal "all tests green" is set, and agents are optimised to reach their goal — they often get creative in the process. We have observed in several projects that autonomously running agents modify their own tests when these get in the way during refactoring.

From a code quality perspective this is a scandal. From the agent's perspective it is its task to reach its goal under all circumstances. To circumvent this problem, the most effective approach is to adapt the structure around the agent.

Isolated Specification Tests help here. We have described the concept in detail in an earlier post and classified it in Part 2 of this series on AI Code Review as one of the structural answers to Risk 1 (insufficient verification of unattended loops). Wes McKinney (pandas, Apache Arrow) brings in the second structural answer: adversarial agents, independent agents that actively try to refute the coding output. Whoever renounces structural verification adapted for agents will quickly get to know Pattern 2.

Pattern 3 — Speed Illusion vs. Maintainability

The third pattern is a creeping, time-delayed trap. The loop produces in two days what would otherwise have taken two weeks. The team celebrates the acceleration. Six months later no one can change the code anymore because it no longer follows any internal structure. The agent has broken many rules, and we no longer recognise our code.

We have described this pattern in detail in an own field report on vibe coding. The short version: it is not about whether AI writes "better" code — it is about whether the resulting code is still maintainable in 18 months.

The bottleneck shifts from coding to maintenance. Whoever does not anticipate this gains three months and loses a year. What helps: refactoring loops from the start as part of the loop design, rules and guardrails that enforce style and architecture, plus documentation-oriented generation — that is, a human-readable explanation of the code changes.

Pattern 4 — "Hallucination" Devours the Architecture

Hallucination is no longer as dominant as in 2023, but still a problem. Also with coding agents. The agent invents API calls that do not exist — code compiles, runs in the test, fails in production. Or worse: it runs in production, but against the wrong API version, with subtle inconsistencies that only show up weeks later. What happens when the agent has no real access to the current code base, the internal APIs or the architecture constraints? It fills the gap with plausible assumptions — and plausible is exactly what makes hallucination so dangerous.

What helps: context infrastructure instead of single-case prompts. Whoever wants to fight hallucinations with better, more detailed prompts may win in the individual case — but not scalably. The better lever is structural context infrastructure: MCP servers that give the agent living access to the real repo, the current library versions and the applicable architecture decisions. Plus: architecture decisions are made outside the loop and fed into the loop as hard constraints. And reviews by people who actually know the architecture, not just the spec.

Pattern 5 — Vibe Accept in the Team

The last pattern is about the human component. We have done everything well, avoided the other patterns, and our agent runs as we want it to. After four to six weeks of loop work we observe in client teams that the review threshold systematically drops. "Looks good" becomes the dominant assessment. Whoever asks critical questions in the review appears increasingly pedantic, because the output mostly fits.

Osmani calls this cognitive capitulation (Risk 3 in the original blog post). In Part 2 on AI Code Review we anchored the effect in two explanatory models from safety and behavioural research: Normalization of Deviance explains why the review threshold falls (what was initially an exception becomes the norm), and the IKEA effect explains why it does not rise again (self-generated output is systematically overrated). It is not laziness but a structural adaptation to the speed asymmetry between generation and cognitive comprehension.

In the last article we talked in detail about how code reviews can look in the age of the new agents and their speed, while these still make mistakes. This answer consists of three pillars. First, tests remain relevant and more important than ever, since they must verify automated code changes. This includes the entire test pyramid as well as human verification of the feature by the developer. "You build it, you own it" still applies. Second, a large part of code reviews should be supported by (AI) tools that review the code automatically. And third: continued human code reviews. To avoid simply shifting the bottleneck, not every piece of code is reviewed by hand anymore. Instead we focus on the critical parts — those that are architecture- and UX-decisive or security-critical. Access to data sources also still needs human approval.

Demo vs. Production — the Reality Table

How does it come, then, that on all social media channels suddenly all development is 10× faster or simply works? Because demos and green-grass MVPs work differently than enterprise production software. What convinces in a demo video fails in a 100k-LoC system — not because of bad technology, but because of different conditions.

Aspect	Demo / Tweet	Enterprise Production
Code complexity	50–200 LoC, isolated	100k+ LoC, networked
Spec clarity	"Build a TODO app"	Multi-stakeholder, changing
Test coverage	Demo tests	Existing suite + new + edge cases
Domain context	universal (web app)	insurance / manufacturing / retail
Lifespan	5-min recording	5+ years maintenance
Verification	"It runs"	compliance, security, audit, SLA

This table is not an accusation against demos. Demos are useful to show what is technically possible. The problem is that many decision-makers unconsciously transfer their demo-based expectations to enterprise projects and then wonder why it takes longer, costs more and is harder to verify. Whoever distinguishes both worlds can capture the real advantages without running into the five patterns.

Loops do not fail because Cherny is wrong. They fail because the gap between tweet and maintainability is large. Part 2 showed how AI code review structurally secures correctness. This post shows why that is not enough: even correctly built code can be the wrong thing. We need to be clear about how agents work and where they can build in problems that are hard to detect. The answer to that no longer lies in the coding loop itself, but in a frame of thought that thinks coding, validation, learning and business together. Part 4 introduces it.

FAQ

Is agentic AI the same as generative AI? No. Generative AI responds to prompts, agentic AI decides itself about action sequences and uses tools. Currently, agentic AI is built at its core with generative AI and forms a frame around it.

Do loops work in enterprise projects at all? Yes, if you address the five failure patterns. Without structure, they fail systematically.

Are loops good enough to be used easily without problems? No, they require careful work and observation by the team. But starting now creates a clear speed and thus competitive advantage and brings important experience.

How do I ensure that code quality is preserved? We recommend starting agentic-AI projects with the verification question, not the acceleration question. The acceleration comes automatically.

How big should a pilot be? Small enough that the code is allowed to break, big enough to cause problems and to see the five patterns. Ideally with real enterprise code but on a separate branch.

Further Reading

Whoever wants to go deeper into agentic AI + failure patterns:

• Anthropic Engineering — "Effective Harnesses for Long-Running Agents" — Anthropic's own 3-agent pattern (Planner → Generator → Evaluator), shows a structural answer to Pattern 2
• GitHub — "Awesome Harness Engineering" — curated pattern collection
• Cobus Greyling — "Loop Engineering" (Substack) — synthesis of the hierarchy Context → Harness → Loop
• The New Stack — "The Anthropic leader who built Claude Code says he ditched prompting" — background to Cherny's statement
• Ralph pattern (Geoffrey Huntley) — original post on the loop methodology (source of the term that underlies our Ralph Wiggum loop post)

---

In Part 4 we show how codecentric bridges from the coding loop to business logic with the Loop Model — and why this is more than "yet another framework".