DEV Community: Praveen Govindaraj

Nobody Will Fund the Harness, and That's Rational

Praveen Govindaraj — Fri, 30 Oct 2026 12:11:37 +0000

Chapter 16 - Team Topologies, public goods, and the economics of code review

The Agentic Development Lifecycle - @praveen govindaraj

Nobody Will Fund the Harness, and That's Rational
Chapter 16 of The Agentic Development Lifecycle — Team Topologies, public goods, and the economics of code review.
Your organization has a platform team, a developer productivity budget, and AI coding agents. Yet code reviews are still slow, and humans must inspect every change to decide whether it's safe.
The bottleneck hasn't disappeared. It's moved from writing code to verifying it.
And one reason it stays there is simple: everyone uses the harness, but nobody owns the economics of building it.
The harness is a public good
An agentic development harness includes the tests, validation rules, execution environments, and evidence that help teams trust AI-generated changes.
A good harness lets reviewers focus on exceptions instead of repeatedly checking routine properties.
So why doesn't every team invest in one?
Because the benefits are shared, while the costs fall on whoever builds it.
One team might spend weeks developing reusable validation infrastructure. Other teams benefit, but the original team pays the engineering cost.
Nobody needs to be selfish or incompetent for this to happen. The incentives alone can produce it.
A shared harness is a public good inside an organization. Asking teams to care more won't fix the funding problem.
More code doesn't mean more throughput
Coding agents can produce changes faster than humans can review them.
When that happens, the queue moves downstream. Reviewers face more pull requests, larger diffs, and more evidence to evaluate.
This is where Brooks's law offers a useful lens: adding producers to a constrained system doesn't automatically increase throughput.
The chapter discusses research reporting a 2.09× increase in per-capita throughput alongside roughly doubled reviewer load in the studied setting. These figures aren't universal constants, but they illustrate the challenge.
If review capacity doesn't keep pace with code production, faster generation can simply create a larger review queue.
Who should own the harness?
Three common approaches have predictable weaknesses:
• Nobody owns it: Teams duplicate tools and develop inconsistent standards.
• Every team owns everything: Teams repeatedly solve the same infrastructure problems.
• A central team owns everything: The platform team becomes a queue that other teams must wait on.
A more balanced model separates responsibilities:
• Platform teams build reusable templates and shared capabilities.
• Stream-aligned teams own the harness instances used for their products.
• Enabling teams help teams establish reliable practices and become self-sufficient.
The goal is shared infrastructure without creating permanent dependence on a central team.
Advisory checks aren't enough
Consider two automated checks.
One posts a comment saying a change may violate a rule. A human must investigate and decide what happens next.
The other blocks the change until the violation is resolved.
Both detect problems, but only the second can prevent routine issues from entering the review queue.
An advisory bot adds review work. A trusted blocking check can remove it.
Blocking checks must be reliable, understandable, and properly maintained. Otherwise, false positives create frustration and teams find ways around them.
Measure whether automation reduces human review effort—not how many comments or checks it produces.
Tokens are measured. Review time often isn't.
AI usage can be measured in tokens, API calls, and compute costs. Human review is harder to track.
A team might reduce code-generation costs while increasing the time reviewers spend reconstructing context and verifying results.
A complete view of agentic development must consider both:
• What does it cost to produce a change?
• What does it cost to verify that change?
• How much human attention is needed before it ships?
The objective isn't to eliminate human judgment. It's to stop spending expert attention on routine properties that trustworthy automation can verify.
Two practical steps

Sample automated decisions. Independently audit a sample of changes that pass the harness. Use the results to identify gaps and determine whether the checks deserve the trust placed in them.
Make ownership explicit. Name the people responsible for shared infrastructure, maintenance, and incorrectly failing checks. Allocate time for improvement instead of treating maintenance as invisible work. Shared benefits require an explicit ownership model. Try this week: name the owner Choose one harness your team depends on and write down who owns it. Ask: • Who maintains its shared capabilities? • Who owns the product-specific configuration? • Who fixes unreliable checks? • How do we know it's reducing review work? If nobody can answer, you've found an organizational bottleneck. The takeaway Agentic development isn't just about getting AI to write code. It's about building systems that let people trust that code without manually reconstructing every detail. The harness may benefit everyone, but it won't maintain itself.

📖 Read Chapter 16: Team Topologies and Review Economics.

Your turn
Who owns the harness where you work—the platform team, individual product teams, or nobody in particular?

Share your experience in the comments, and follow along as I explore The Agentic Development Lifecycle, one chapter at a time.

Everyone's at Level 1, and it unlocks nothing

Praveen Govindaraj — Fri, 30 Oct 2026 11:01:24 +0000

Chapter 15 - A maturity model sorted by what depends on what, not by what's cheap
The Agentic Development Lifecycle - @praveen govindaraj

Most teams adopting AI coding agents start by creating an AGENTS.md file. They document coding conventions, explain the architecture, and tell agents which tests to run.
It's useful—but how do you know the agent actually follows those instructions?

In a study of 2,853 software repositories, 90.6% had context files, while only 0.9–3.2% had hooks that can run checks during an agent's editing workflow.
Almost everyone had shared instructions. Very few had mechanisms to enforce or observe agent behaviour.
We've mistaken the easiest step for the first step on a mandatory maturity ladder.

Maturity Is About Feedback Loops A context file can tell an agent to run tests, but it cannot guarantee that tests run. Instructions describe expected behaviour; they don't enforce it. Maturity is about which feedback loops a team can actually close. Consider a simple workflow:
An agent changes a file.
A type checker runs.
The check detects an error.
The workflow blocks the change and provides feedback.
Now imagine recording failures, identifying recurring problems, and introducing controls to prevent them.
That's the difference between detecting individual failures and learning systematically.
The maturity model defines five levels:
• Level 0: Individual AI-assisted development.
• Level 1: Shared context files and conventions.
• Level 2: Blocking checks, sensors, and execution traces.
• Level 3: Controls introduced in response to recurring failures.
• Level 4: Reusable harness templates adopted by other teams.
Each level represents a capability the organisation can demonstrate—not simply another tool it has installed.
The Conventional Ladder Is Backwards
The usual progression sounds logical: document conventions, automate them, collect evidence, improve controls, and share the resulting system.
But does every capability depend on the previous one?
Consider a blocking type check. It can run during an agent's editing workflow without an AGENTS.md file.
The context file might help the agent understand errors, but it isn't a technical prerequisite for the check.
Level 1 is not a prerequisite for Level 2.
So why is Level 1 so common?
Because it's cheap. Writing a Markdown file takes minutes. Building reliable checks requires integration, maintenance, and decisions about what should block a change.
We've confused the order in which practices are adopted with the order in which they depend on one another.
If your team is stuck polishing context files, it may be time to move sideways rather than keep climbing the assumed ladder.
Start With a Blocking Check
For many teams, a practical next step is integrating a reliable computational check into the agent's editing workflow.
Start with something relevant to your codebase, such as a type checker or suitable test suite.
Where appropriate, a failed check should prevent the change from proceeding until the problem is addressed.
Compare these approaches:
Instruction: "Remember to run the type checker."
Enforcement: The workflow runs the type checker and blocks the change if it fails.
The first depends on the agent following instructions. The second introduces an independent mechanism for detecting a class of failure.
Checks aren't perfect, but a useful blocking check changes what the system can demonstrate.
Checks Need Evidence
Blocking checks help prevent failures, but they don't automatically help teams learn from recurring problems.
Suppose an agent repeatedly introduces the same defect. Your team adds a check to catch it.
Months later, is the problem still occurring? Is the check effective? Are other failures going unnoticed?
Without useful records, these questions are difficult to answer.
That's why Level 2 includes sensors and trace capture. Sensors observe what happens; traces preserve execution information and outcomes for later investigation.
At Level 3, teams use this evidence to introduce controls in response to recurring failures.
They should also be able to remove controls when they're no longer justified.
A team that only adds safeguards may accumulate unnecessary complexity.
Maturity means learning from evidence, not endlessly adding restrictions.
Level 4 Is an Organisational Decision
At Level 4, teams create reusable harness templates that other teams can consume.
This can prevent everyone from rebuilding the same development infrastructure independently.
But reuse becomes harder when teams have different frameworks, deployment models, and service architectures.
A template proves its value when a team that didn't create it can actually use it.
Level 4 requires the organisation to limit the variety of service architectures it supports.
This isn't just a tooling decision. It's an architectural and management decision about how much variation the organisation is willing to maintain.
What Maturity Doesn't Buy You
A mature development lifecycle can detect mechanical failures faster and more cheaply. It cannot guarantee that the team is building the right software.
If requirements are incomplete or misunderstood, a system can pass its checks and still produce the wrong outcome.
Automated tests verify encoded expectations; they don't guarantee those expectations capture everything users need.
Better tooling also doesn't automatically make high-impact changes safe to delegate. Engineering judgment remains essential.
Maturity improves how failures are detected and handled. It doesn't eliminate the need to decide whether the system is doing the right thing.
Assess Your Team
Answer these eight questions using evidence from your repositories and workflows:
Do you have shared, version-controlled agent context?
Can checks block changes during the agent edit cycle?
Do those checks produce observable outcomes?
Are execution traces and sensor outcomes stored somewhere queryable?
Have you introduced a control in response to recurring failures?
Have you removed a control and documented why?
Has another team consumed a harness template it didn't create?
Do you measure harness coverage against drills that actually fired?
Answer based on what your team can demonstrate today—not what it intends to implement.
Assess maturity for a particular class of work, too. A low-risk internal tool and a high-impact service may require different levels of control.

Final Thoughts
You don't need to perfect every context file before introducing automated checks. Nor must every capability follow a prescribed sequence.
Identify the feedback loop your team is missing. For many teams, that means starting with a blocking check and a trace store.
Don't optimise for climbing the ladder. Optimise for closing the next useful feedback loop.

Read the Full Chapter
📖 Chapter 15: The Maturity Model
Next: Chapter 16 — Team Topologies and the Economics of Review.
Your turn: Which maturity level is your team at, honestly? Are you still improving context files, or have you started closing the feedback loops that let your system observe, learn, and improve?

Stop Counting PRs. Measure the Queue.

Praveen Govindaraj — Fri, 30 Oct 2026 10:44:40 +0000

Chapter 14 - What to measure when your team delegates to agents
The Agentic Development Lifecycle - @praveen govindaraj

Stop Counting PRs. Measure the Queue.
AI agents can generate code faster than your team can review it. So how do you measure real productivity?

A team hit its merged-PR target, but pull requests grew by a third.
Nobody cheated. The metric simply rewarded output instead of outcomes.
When code generation becomes cheap, review capacity becomes the constraint.

Measure the queue
Instead of counting pull requests alone, track:
• Review wait time: Time from PR creation to first human review.
• Incoming PRs: How much work enters the queue.
• Batch size: Whether changes are becoming harder to review.
If arrivals increase slightly but waiting time rises sharply, your review process may be approaching saturation.
Fewer, larger PRs won't necessarily fix the problem. They can reduce the item count while leaving the actual review workload unchanged.
Measure delegation quality
Track a few additional metrics:
• First-pass acceptance: How often agent changes are accepted without human edits.
• Rework rate: How often merged agent-authored code needs subsequent changes.
• Harness coverage: Whether controls for known failure modes have been tested.
• Cost per accepted change: Include compute, tokens, and human review time.

Keep the four DORA metrics, too: deployment frequency, lead time for changes, change failure rate, and time to restore service.
Be cautious with metrics such as lines of code generated, PR counts, and self-reported “time saved.” They can look impressive without proving that delivery has improved.

Try this week
For four weeks, track incoming PRs alongside time to first human review.
Record PR size, too, so fewer but larger changes don't disguise the workload.

Watch how waiting time responds when arrivals increase. If the queue grows faster than the incoming work, investigate review capacity before asking agents to produce more.
Measure the constraint, not the output.

📖 Read the full chapter: Chapter 14: Metrics for Delegation
I'm exploring The Agentic Development Lifecycle one chapter at a time, in plain words.

Discussion: What AI productivity metric does your team track—and does it measure delivered value or just generated output?

ai #softwaredevelopment #devops #productivity

Your agent is at "A2"? Prove it: ask it to merge.

Praveen Govindaraj — Fri, 30 Oct 2026 10:35:15 +0000

Chapter 13 - Autonomy is set by harnessability × blast radius, never by enthusiasm

The Agentic Development Lifecycle - Chapter 13 - Part III — The Lifecycle

Your AI Agent Is at A2? Prove It: Ask It to Merge.
Autonomy is determined by harnessability × blast radius, not by how confidently you instruct an AI agent.
You say your coding agent operates at A2. It can complete tasks, run tests, and open pull requests for human review.
But here's a simple question:
Can it merge its own pull request?
If yes, your agent may have more authority than your policy allows.

The Autonomy Ladder

Higher isn't always better. A dependency update might be suitable for A4, while a payment-system change may require A0 or A1.
Autonomy should depend on the type of work, not one global setting.
Instructions Aren't Controls
Telling an agent not to merge isn't enough if it has merge permissions.
Real controls include:
• Restricting repository permissions.
• Isolating agent workspaces.
• Protecting production credentials.
• Requiring CI checks before merging.
• Preventing agents from modifying their own security boundaries.
Don't just tell an agent what it shouldn't do. Remove its ability to do it.
What Determines the Autonomy Ceiling?

Two factors matter:

Harnessability: How reliably can your tests, types, boundaries, and automated checks detect or prevent mistakes?
Blast radius: How much damage could a mistake cause? Strong verification doesn't automatically justify high autonomy when the potential impact is severe. Blast radius can veto higher autonomy. For ordinary feature development, A2 may remain the sensible ceiling when automated checks cannot reliably verify intended behaviour. Where A4 Makes Sense A4 is promising for low-risk, mechanically verifiable tasks, such as: • Dependency updates. • Formatting and linting. • Dead-code removal. • Documentation generation. • Mechanical migrations with equivalence checks. • Architectural drift detection. These tasks offer opportunities for continuous automation without giving agents unrestricted authority over consequential changes.

Try This
Take an agent you classify as A2 and give it a harmless task in an isolated repository.
Ask it to make the change, run tests, and open a pull request.

Then check:
• Can it merge?
• Can it push directly to shared branches?
• Can it access unnecessary credentials?
• Can it modify the checks that constrain it?
Ask what the agent can do—not just what you've instructed it to do.
If it can merge despite your A2 policy, fix the permission boundary before granting more autonomy.
The goal isn't maximum autonomy. It's the right amount of autonomy for each task, enforced by real controls.

📖 Read the full chapter: Chapter 13 — The Autonomy Ladder
Next: measuring autonomy and harnessability across your engineering organisation.

Your turn: What level is your coding agent really at—and if it's A2, can it merge?

Two Loops: One Builds Your Code, One Improves Your AI Agent Chapter 12 of The Agentic Development Lifecycle

Praveen Govindaraj — Wed, 28 Oct 2026 17:22:40 +0000

An AI coding agent makes a mistake. You fix the code, rerun the tests, and move on.
Then it makes the same mistake next week.
You fix it again.
A few days later, another agent repeats it.
At some point, you have to ask a different question:
What if the problem isn't the code the agent generates, but the system that tells it how to generate it?
That question gets to the heart of the Agentic Development Lifecycle (ADLC).
The idea is simple: building software with AI agents requires two feedback loops—not just one.
🔄 One Loop Builds. One Loop Steers.
The first loop produces software changes. The second improves the system responsible for producing them.
Think of them as two connected engineering processes:
• Inner loop: Turns a task into a verified software change.
• Outer loop: Uses evidence from completed work to improve the agent's instructions, context, tools, and controls.
The inner loop helps you ship code.
The outer loop helps you avoid repeating the same mistakes.

This distinction matters because an agentic workflow is not a static pipeline. Instructions become outdated. Context retrieval misses important details. Tests fail to catch defects. Controls accumulate until they contradict one another.
Your harness is an engineered system, too. It needs maintenance and improvement just like your application.

The Inner Loop: From Intent to Integration The ADLC inner loop has six phases:
Intent — Define what needs to change and what success means.
Ground — Gather the relevant code, context, and evidence.
Decompose — Break the task into manageable steps.
Generate — Produce a candidate implementation.
Verify — Check the result against acceptance criteria.
Integrate — Incorporate the accepted change into the wider system. The order matters. Intent, grounding, and decomposition narrow the space of possible solutions. Generation introduces variety: the agent may produce several plausible approaches, not all of them correct. Verification and integration then reduce that variety to an acceptable change.

Here's the important debugging lesson:
When an agent produces bad code, don't immediately blame the model.
Ask yourself:
• Was the task clear enough to evaluate?
• Did the agent have the right context?
• Was the task broken down sensibly?
• Were the acceptance criteria strong enough?
A failure during generation may have started much earlier.
Fix the earliest weak point in the process, not just the latest visible symptom.

The Outer Loop: Stop Fixing the Same Problem Imagine an agent repeatedly misunderstands a particular module. You could add a reminder to individual prompts. You could ask reviewers to pay closer attention. You could manually correct every generated patch. But those responses treat every occurrence as a separate incident. The outer loop asks: What should we change in the harness so this failure becomes less likely next time? Maybe the agent needs better repository context. Maybe retrieval is returning irrelevant files. Perhaps a verification step is missing. The team investigates the pattern, improves the relevant part of the harness, and observes whether the change helps. That's the outer loop at work. But there's a catch: the inner loop can operate much faster than a human team can inspect every result. If you only collect evidence during occasional retrospectives, you may discover a recurring problem long after it has become expensive. The solution is automated sensing. Capture execution traces. Record verification results. Track recurring failure patterns. Surface important changes in agent behaviour. Humans can still make the consequential decisions. But collecting the evidence shouldn't depend entirely on someone remembering to do it.
No Evidence, No Learning The two loops connect through artefacts—the records produced as work moves through the lifecycle. Start with five: • Task specifications and acceptance criteria • Context and retrieved information provided to the agent • Execution traces and tool usage • Verification results • Human corrections, approvals, and interventions Why bother? Because one failed test might be an isolated mistake. The same failure across dozens of tasks could indicate a deeper problem with the harness. Without records, those failures may look unrelated. With records, you can investigate the pattern and improve the system. This is more than debugging. It's how the development process learns. A lifecycle without artefacts has no outer loop. It may have tests, reviews, and retrospectives. But without evidence feeding back into changes to the harness, the system isn't systematically improving how it produces software.
Seven Rules for a Better ADLC The ADLC model also gives teams seven practical prohibitions:
Don't generate before intent is checkable. If success can't be evaluated, the agent has no reliable target.
Don't merge based solely on a test the generator authored. Verification needs independent strength.
Don't fix recurring defects only at the instance. Investigate the harness.
Don't add controls without a date, named failure mode, and retirement criterion. Avoid accumulating permanent safeguards without clear purpose.
Don't increase autonomy without evidence. Consider whether the harness can manage the risk and the potential blast radius.
Don't automatically trust artefacts an agent reads. Treat them as potentially untrusted instructions.
Don't mandate generation throughput. More generated code doesn't necessarily mean more useful, verified software. These rules challenge a common mistake: measuring agent productivity by how much code it produces. A workflow can generate code faster while producing more defects, weaker verification, and additional review work. The goal isn't maximum output. The goal is reliable engineering outcomes.
Autonomy Needs Two Ladders There's one more distinction worth remembering: specification strength and agent authority are not the same thing. Specification strength describes how clearly the task, context, and acceptance criteria are defined. Agent authority describes how much freedom the agent has to act. An agent might have a precise specification but very limited authority. Or it might have broad permissions while working from vague instructions. Neither dimension automatically fixes the other. Giving an agent more authority doesn't make an unclear task safer. Writing a detailed specification doesn't automatically make every autonomous action appropriate.

Autonomy isn't simply a switch you turn on.
It's a capability you expand when the surrounding system can support it.
🛠️ Try This With Your Team
You don't need to rebuild your entire workflow to get started.
Choose one AI-assisted development process and begin recording:
• What the agent was asked to do
• What context it received
• What actions it took
• Which checks ran and what they found
• Where a human had to intervene
Then look for recurring patterns.
Choose one problem, change one part of the harness, and measure whether the outcome improves.
That's your first practical outer loop:
Capture evidence → Find a pattern → Improve the harness → Measure the result.
The Takeaway
The inner loop builds software.
The outer loop improves the system that builds it.
Without the first, nothing gets shipped. Without the second, the same weaknesses can keep returning—even as your agents become faster and more capable.
The objective isn't to remove human judgement. It's to build a workflow that gives people reliable evidence and a systematic way to improve the system.
📖 Read the full chapter: Chapter 12 — The ADLC Model
Next up: Chapter 13 — The Autonomy Ladder, exploring how to increase an agent's authority without getting ahead of the system's ability to control it.
💬 Question for you: Does your team have an outer loop, or are you fixing each AI-generated problem as it appears?
If you're building reliable AI-assisted engineering workflows, follow along as we explore the ADLC one chapter at a time.

The allowlist made the attack easier - Chapter 11 - Why you can't secure an agent by telling it what not to do

Praveen Govindaraj — Wed, 28 Oct 2026 14:00:08 +0000

Your AI agent’s attack surface is everything it reads.

In traditional software, attackers often need write access to compromise a system.

With AI agents, sometimes all they need is to write an issue comment.
A malicious instruction can hijack an agent and exploit the tools, credentials, and permissions it already has.

The uncomfortable lessons from agentic security:
• 🔓 Prompt injection is structural. Better instructions alone won’t solve it.
• 🛡️ Belief isn’t a security boundary. An agent can be persuaded to ignore its rules.
• 🔑 Scope capabilities by effect, not by name. An approved command isn’t necessarily a safe command.
• 🚫 Remove unnecessary access. Don’t tell an agent to protect secrets—avoid exposing those secrets in the first place.
• 🔍 Track provenance. An issue comment, a tool response, and a trusted instruction shouldn’t become indistinguishable text.
The core principle:
Don’t tell it. Take it away.
In Chapter 11 of The Agentic Development Lifecycle, I explore real-world attack mechanisms, why allowlists can fail, and why structural controls offer a stronger defence than prompts alone.

📖 Read Chapter 11 — Verification & Security:
The Agentic Development Lifecycle — Chapter 11

💬 Challenge: What’s the most dangerous permission your AI coding agent has—and does it actually need it?

DevCommunity #AI #AgenticAI #AppSec #CyberSecurity #SoftwareEngineering #LLMSecurity

A 1972 Paper Is the Best AI Safety Tool You're Not Using Chapter 10 - Parnas, information hiding, and the harnessable codebase

Praveen Govindaraj — Wed, 28 Oct 2026 13:51:20 +0000

A 1972 paper might be one of the most practical tools for building safer AI agents.
In 1972, David Parnas argued that software modules should hide design decisions that are likely to change.
More than five decades later, that idea has a new job: making codebases safer for AI agents to work in.
Here’s why it matters.
🤖 1. Agents don’t just need context. They need boundaries.
Giving an agent more files, documentation, and instructions doesn’t automatically make its changes safer.
A module with a clear interface and hidden implementation details gives the agent a smaller, more reliable surface to reason about.
But a leaky abstraction changes everything. The interface may look simple while hidden state, locking requirements, retries, or undocumented assumptions determine whether a change is actually safe.
The agent can be confident and still be wrong.
🏗️ 2. Small modules don’t solve every problem.
Limiting module size, interfaces, and dependency fan-out helps contain implementation changes.
But what happens when a widely used interface changes?
Now the agent may need to understand every caller that depends on it.
The cost of a change isn’t determined only by the size of the module being edited. It also depends on how many other parts of the system rely on its contract.
Sometimes, duplication is safer than extracting a shared abstraction—especially when caller relationships are difficult to discover reliably.
🛡️ 3. Make invalid changes impossible, not merely discouraged.
There’s a hierarchy to building agent-harnessable software:

Make it impossible: Use types, APIs, and module boundaries to prevent invalid states and dependencies.
Detect it deterministically: Use tests, linters, type checks, and architectural fitness functions.
Judge it probabilistically: Use AI reviewers where judgment is genuinely needed.
Assert and hope: Rely on prompts, context files, and written principles. Documentation still matters. But a rule enforced by the build is stronger than a rule an agent must remember. A practical experiment for this week: Choose one architectural boundary in your codebase. For example: The domain layer must not import the database layer. Turn that principle into a rule that fails the build when violated. You’ve moved one architectural decision out of the agent’s memory and into the system itself. That’s the shift: from asking an agent to behave correctly to designing a codebase where correctness is easier to preserve. One important caveat: this is a structural argument, not yet proof of a causal relationship. The hypothesis deserves to be tested, not treated as settled science. Question for developers: Which module in your codebase would you least trust an AI agent to modify—and is the problem the code itself, or the boundaries around it? 📖 Read Chapter 10 of The Agentic Development Lifecycle: https://neam-lang.github.io/The-Agentic-Development-Lifecycle/chapters/10-structural-engineering.html Next: What happens when an attacker starts testing those boundaries?

Stop Writing Architecture Docs for Your Agent. Give It a Map. Chapter 9 - Why a code graph is the one kind of guidance that doesn't go stale

Praveen Govindaraj — Wed, 28 Oct 2026 13:44:05 +0000

🚀 The Bottleneck Moved: Your AI Coding Agent Needs Better Engineering, Not Just Better Prompts
We keep giving AI coding agents more instructions.
More AGENTS.md files. More architecture docs. More guardrails. More rules.
But are we making agents better—or just making them work harder to understand our codebases?
Two ideas from The Agentic Development Lifecycle offer a different way forward.
🗺️ 1. Stop writing architecture docs. Give your agent a map.
Ask an agent to find every call site of a function.
Grep finds references. But can you tell what it missed?
A code graph helps agents navigate relationships between functions, modules, and dependencies instead of repeatedly reconstructing them from raw text.
Research highlighted in the book reports that LocAgent found the right file 92.7% of the time while reducing cost by about 86%. RepoGraph improved all four agents it was added to.
The takeaway isn't that graphs are magic.
It's that some context should be generated from code, kept fresh, and made queryable—not manually maintained in paragraphs that eventually go stale.
🧪 2. Stop assuming your guardrails work. Break them on purpose.
Your harness has lint checks, test gates, permission boundaries, and repository rules.
Great. When did one of them last catch the failure it was designed to prevent?
Borrow an idea from mutation testing: deliberately trigger the failure a control should catch, in a safe environment, and verify that it fires.
If it doesn't, fix it.
If controls overlap, reconsider whether both are needed.
If a control no longer earns its place, retire it.
A harness that only accumulates rules eventually becomes expensive theatre.
It needs two arms: one to install controls and another to retire them.
🛠️ Try this week:
→ Replace one manually maintained architecture paragraph with information generated directly from your code.
→ Pick one agent guardrail and deliberately trigger the failure it's supposed to catch.
Small experiments. Better engineering. More reliable agents.
The bigger lesson?
Building with AI isn't just about generating code faster. It's about creating an environment where agents can find the right context, operate within meaningful boundaries, and demonstrate that their output meets the requirements.
📖 Explore the chapters:
Chapter 8 — Harness Engineering II: The Steering Loop
https://neam-lang.github.io/The-Agentic-Development-Lifecycle/chapters/08-harness-engineering-the-steering-loop.html
Chapter 9 — Graph Engineering
https://neam-lang.github.io/The-Agentic-Development-Lifecycle/chapters/09-graph-engineering.html
Part of The Agentic Development Lifecycle — one chapter at a time, in plain words.
💬 Developer question: What's the bigger challenge in your AI coding workflow today: helping the agent understand your codebase, or making sure its output is actually correct?

AgenticAI #AIEngineering #SoftwareEngineering #CodingAgents #DevTools #LLM

Fire Drills for Your AI Harness 🔥 - Chapter 8 - The only way to know a control works is to break things on purpose

Praveen Govindaraj — Wed, 28 Oct 2026 13:37:21 +0000

Your AI coding agent has a harness. It has system instructions, tool permissions, validation scripts, automated tests, and guardrails designed to prevent it from doing something stupid.
Great.
Now, one question: When was the last time you deliberately tried to break those guardrails?
If the answer is "never," you don't know whether your harness works. You know only that you've configured it.
There's a difference.
As AI agents take on more of the software development lifecycle, we're moving beyond the question of how to make agents generate code faster. We're facing a harder engineering problem: how do we build development systems that remain reliable when their primary worker can generate an enormous variety of code and behaviours?
The answer isn't to keep adding rules.
It's to build a harness that can prove its controls work, detect when they stop working, and retire them when they're no longer useful.
Let's look at how to do that.

Your harness needs a feedback loop Consider a familiar scenario. You ask an AI coding agent to implement a feature. It modifies a file outside the intended scope. You investigate and add a restriction to prevent the same thing from happening again. A few days later, the agent makes another out-of-scope change. You add another instruction. Then another check. Eventually, your AGENTS.md, tool configuration, CI pipeline, and validation scripts contain a growing collection of rules intended to prevent past mistakes. But are these controls actually effective? The underlying engineering principle is straightforward: when a failure repeats, improve the system that allowed it to happen. This is the essence of the steering loop described by Birgitta Böckeler in the context of harness engineering. Instead of repeatedly fixing individual failures, you use each failure as feedback to improve the environment in which the agent operates. For example: • If the agent repeatedly edits generated files, restrict write access or introduce a validation check. • If it forgets to run tests, make test execution part of the workflow rather than relying on instructions. • If it introduces breaking API changes, add compatibility checks to the relevant validation stage. • If it repeatedly violates architectural boundaries, enforce those boundaries through dependency rules or static analysis. The objective is to turn recurring mistakes into system-level improvements. However, there is a hidden problem. Every time you encounter a failure, you might add another control. Over time, the harness becomes more complicated, slower, and harder to maintain. A feedback loop that only adds controls eventually becomes technical debt. The missing operation: retire controls A mature harness needs two operations:
Install: Introduce a control when a meaningful failure or risk justifies it.
Retire: Remove a control when it becomes redundant, ineffective, or disproportionately expensive. Imagine a repository with three checks that all enforce overlapping formatting rules. Perhaps an earlier script was introduced before the team adopted a modern formatter. The old script remains in CI. Developers maintain it. Every pull request pays its execution cost. Yet it provides no meaningful protection beyond what the current formatter already guarantees. That's a candidate for retirement. The same principle applies to agent-specific controls. A restriction introduced to compensate for an old architectural weakness may become unnecessary after the architecture changes. A harness should evolve with the system it governs. Insert Figure 8.1 here. Figure 8.1, from Chapter 8: The steering loop includes a retirement path, allowing controls to be removed as well as installed.
You cannot write a guardrail for every possible program Here's the fundamental constraint. An AI coding agent can generate an enormous variety of programs, modify different parts of a repository, invoke tools, and combine components in ways that may not have been anticipated. Your harness has a finite set of controls. You cannot enumerate every possible implementation and write a specific rule for each one. This is where Ashby's law of requisite variety becomes useful. In simplified terms, a regulator needs sufficient variety in its responses to manage the disturbances it faces. Applied to agentic software development, this suggests an important strategy: reduce the range of behaviours the agent is permitted to produce or execute. Instead of trying to anticipate every possible mistake, constrain the space in which mistakes can occur. Consider two approaches to an AI coding agent. Approach A: Broad permissions, extensive guardrails The agent can execute arbitrary shell commands, modify any file, install packages, access credentials, and interact with external services. You then attempt to control the risks with instructions, scripts, and post-execution checks. Approach B: Narrow permissions, targeted guardrails The agent receives access only to the tools and directories required for its task. Sensitive operations require explicit approval. Changes must pass automated validation before they can be accepted. The second approach reduces the amount of behaviour your harness must regulate. This is the practical value of least privilege in agentic development. A tool permission is not merely a security setting. It is a way to reduce the number of actions your system must safely accommodate. For developers building agentic workflows, this means thinking carefully about: • Which files an agent can read and modify. • Which commands it can execute. • Which external services it can access. • Which operations require human approval. • Which outputs must pass validation before they are accepted. The goal is not to eliminate agent autonomy. It is to make autonomy operate inside a clearly defined boundary.
Put each control at the cheapest effective layer Once you've defined the boundaries, the next question is where to enforce them. A useful engineering principle is to detect failures as early as possible, using the cheapest effective mechanism. For example, suppose an agent introduces an invalid dependency. You could discover it during a full integration test, after several minutes of execution. Or you could reject it immediately through a dependency policy check. Both controls might catch the problem, but the earlier check is usually cheaper. A practical validation architecture might look like this:

These layers complement one another.
A formatter cannot establish that business logic is correct. Unit tests cannot prevent an agent from accessing a secret it should never have been able to read.
Each control should address a clearly identified risk.
Make drift detection automatic
There's another important detail: some failures emerge gradually.
A workflow that was reliable last month may become less reliable as dependencies change, repository conventions evolve, or new tools are introduced.
If drift detection depends on a developer remembering to investigate, it will inevitably be inconsistent.
Instead, schedule periodic checks.
Depending on your environment, these might include:
• Checking whether required CI jobs are still present.
• Detecting changes to protected configuration files.
• Identifying outdated or duplicated validation rules.
• Monitoring recurring agent failures.
• Verifying that permission boundaries still match the intended architecture.
The important property is that the scan runs because it is scheduled, not because somebody has already noticed a problem.
Automation turns drift detection from an occasional reaction into a repeatable engineering practice.

Passing CI doesn't mean the agent did the right thing This is where things get interesting. Your agent can produce code that compiles, passes linting, satisfies type checks, and clears the existing test suite. And the feature can still be wrong. Perhaps the implementation mishandles an edge case. Perhaps it violates an unstated business requirement. Perhaps it technically satisfies the acceptance criteria while breaking a workflow that the tests never covered. This is the difference between verifying implementation constraints and validating intended behaviour. Both matter. For agentic development, human-defined acceptance tests are particularly valuable because they establish what the software is expected to do independently of the agent's chosen implementation. For example, suppose an agent implements a payment retry mechanism. The code compiles. The tests confirm that retries occur after a failed request. But what happens if the payment provider processes the transaction successfully and the response times out? A simplistic retry implementation might charge the customer twice. A meaningful acceptance test would verify the required behaviour under that failure condition, including the handling of duplicate requests. The test evaluates the outcome that matters, rather than simply checking that the code follows a particular pattern. Keep the evaluation independent Where practical, separate the information used to guide implementation from the checks used to evaluate the final result. If an agent sees every hidden test and knows exactly how each one is constructed, it may produce a solution that satisfies those specific checks without correctly addressing the broader requirement. An independent acceptance suite provides an additional evaluation layer. This is not a substitute for good test design. Nor does hiding tests guarantee correctness. It simply reduces the extent to which the implementation can be tailored to a narrow, fully visible checklist. The broader lesson is simple: A harness must control what the agent can do and independently verify what the agent produces. Those are different responsibilities.
Test the tests: introduce controlled failures Now we arrive at the practical technique that ties everything together. Don't just inspect your controls. Deliberately challenge them. Software engineers already use related techniques: • Mutation testing checks whether tests detect deliberate changes to program behaviour. • Fault injection introduces controlled failures to evaluate system responses. • Chaos engineering examines how systems behave under deliberately introduced disruptions. An agentic harness can borrow the same mindset. For each important control, define a failure it is supposed to catch. Then reproduce that failure in a safe, isolated environment and verify the expected response. Example 1: Test a file-permission boundary Control: The agent must not modify files in a protected directory. Drill: In a disposable repository or isolated test environment, attempt to modify a protected file using the same execution path available to the agent. Expected result: The operation is denied, or the change is rejected before it can be accepted. What to inspect: Did the permission boundary actually block the operation? Was the failure reported clearly? Could the agent bypass the restriction through another available tool? The last question is important. A restriction enforced only in the agent's instructions is not equivalent to an operating-system or tool-level permission boundary. Example 2: Test a validation rule Control: CI must reject a particular class of invalid change. Drill: Introduce a known violation into a temporary branch. Expected result: The relevant check detects the violation and fails the pipeline. What to inspect: Did the correct check run? Did it detect the intended failure? Was the failure visible to the developer or agent responsible for remediation? A green pipeline is useful only if the checks that matter are actually executing. Example 3: Test an architectural constraint Control: A particular module must not import an internal implementation from another module. Drill: Introduce a forbidden dependency into a disposable change. Expected result: The architectural check rejects the dependency. What to inspect: Does the check cover the relevant paths and languages? Can the same violation enter through an alternate import mechanism? These exercises are small, targeted experiments. They test the complete path from failure introduction to detection and response. Insert Figure 8.6 here. Figure 8.6, from Chapter 8: Deliberate drills test newly installed controls and help identify existing controls that may be candidates for retirement. Why this is more than testing A normal test asks whether your software behaves as expected. A harness drill asks whether the mechanism responsible for detecting a failure actually detects it. That distinction matters when agents are producing code at a pace that makes manual inspection an increasingly limited defence. If you rely on a control to prevent a class of failures, you need evidence that the control works under relevant conditions. A configuration file that looks correct is not that evidence. A controlled experiment is a much stronger starting point.
Build a control lifecycle, not a pile of guardrails You can turn these ideas into a lightweight engineering practice. Whenever you introduce a significant control, document four things:

The last field is easy to overlook.
Controls often become permanent because nobody defines when they should be reconsidered.
You don't need to remove a control on a fixed schedule. Some safeguards should remain indefinitely. Others may need regular review.
The objective is to make retirement a deliberate engineering decision rather than an operation that never happens.
A simple workflow could be:

Observe a recurring failure or identify a significant risk.
Introduce the smallest effective control.
Define the failure that would demonstrate the control is working.
Run a controlled drill in an isolated environment.
Record the result and investigate any gaps.
Revisit the control when the architecture or risk changes. This approach connects failure analysis, control design, verification, and maintenance. It also prevents your harness from becoming a collection of rules whose original purpose nobody remembers. The takeaway: trust should be earned through evidence As AI agents become more involved in software development, we need to rethink how we evaluate the systems surrounding them. The goal isn't to create the largest possible collection of guardrails. It's to build a system that can constrain agent behaviour, detect important failures, and demonstrate that its safeguards work. That requires three capabilities: Constrain. Reduce the range of actions and outputs the agent can produce. Verify. Test whether controls detect the failures they are designed to catch. Retire. Remove controls that no longer provide sufficient value. The most important shift is from assuming that a control works to collecting evidence that it does. A harness is not reliable because its configuration looks impressive. It becomes more trustworthy when its boundaries are enforced, its failures are observable, and its controls are deliberately tested. And sometimes, the fastest way to discover whether your system is safe is to make it fail on purpose. ________________________________________ 🛠️ Try This: Run Your First Harness Drill Choose one control in your AI development workflow. It could be a protected-file rule, a CI check, a dependency restriction, or a test designed to catch a recurring coding error. Then run this small experiment:
Define the failure. Write down the specific behaviour the control should prevent or detect.
Create a safe test case. Reproduce that failure in a disposable branch, repository, or isolated environment.
Trigger the control. Introduce the violation using the same relevant execution path that your agent or development workflow uses.
Observe the response. Confirm that the control fires, the failure is reported, and the workflow responds as intended.
Record the evidence. Document what happened, including any unexpected behaviour or bypasses. If the control works, you have evidence that it works under the conditions you tested. If it doesn't, you've found a gap before relying on it during real development. One drill. One control. One assumption replaced with evidence. That's a good place to start. ________________________________________ 📖 Read the Full Chapter This post is a practical introduction to the ideas in Chapter 8 of The Agentic Development Lifecycle. Read the complete chapter for the deeper discussion of the steering loop, Ashby's law, control placement, and deliberate drills. Read Chapter 8: Harness Engineering II — The Steering Loop 💬 Join the Discussion Has any of your AI agent checks ever actually fired? Have you deliberately tested whether your agent's guardrails work, or are you relying on the configuration and hoping for the best? I'd love to hear about a control that caught a real failure—or one that looked reassuring until you challenged it. Share your experience in the comments. Next in the series: continuing the journey through The Agentic Development Lifecycle, one chapter at a time. — Praveen Govindaraj

The Agentic Development Lifecycle - We wrote 29 rules for every check we built

Praveen Govindaraj — Tue, 27 Oct 2026 17:47:38 +0000

Chapter 7 - Guides assert, sensors observe, and we bought the wrong one

We wrote 29 rules for every check we built. That ratio says something about how we build AI agents.

Birgitta Böckeler gives us a useful equation:
Agent = Model + Harness

You may not control the model. But you do control the harness around it.
And that’s where things get interesting.

There are two ways to influence an AI coding agent:
🧭 Guides tell the agent what to do before it acts.
Examples: AGENTS.md, CLAUDE.md, coding conventions, and instructions.
📡 Sensors check what happened after it acts.
Examples: linters, type checks, tests, and automated reviews.
Both matter. But they don’t offer the same kind of protection.
A guide says, “Please follow this rule.”
A blocking sensor says, “This change cannot proceed until the rule is satisfied.”

We examined 2,853 GitHub repositories using agentic coding tools. Context files appeared in 90.6% of repositories, while hooks appeared in just 0.9–3.2%, depending on the tool.
In Claude Code repositories, the ratio was roughly 29 context-file repositories for every repository with hooks.
Why the gap?

Writing a rule in a Markdown file takes minutes.
Building a check that runs automatically, blocks a bad edit, and has someone responsible for maintaining it takes much more effort.
This isn’t simply a matter of developer discipline. It’s a cost gradient.
But it points to an important engineering opportunity: move more checks into the agent’s edit loop.
Don’t just tell the agent what good code looks like. Give it fast, deterministic feedback when the code falls short.
Start small:
• Run a syntax check.
• Add a type check.
• Run fast unit tests.
• Block the edit when a critical check fails.
One useful blocking check can be more valuable than another page of instructions.
Try this: Pick one recurring mistake in your AI-assisted workflow. Can you turn it into a check that blocks the bad edit before it lands?

📖 This is the idea behind Chapter 7 of The Agentic Development Lifecycle: Guides and Sensors.

Read the chapter: https://neam-lang.github.io/The-Agentic-Development-Lifecycle/chapters/07-harness-engineering-guides-and-sensors.html

Question for developers: In your AI coding setup, what’s the ratio of written rules to automated checks?

AIEngineering #AgenticAI #SoftwareEngineering #CodingAgents #DeveloperTools

The Agentic Development Lifecycle - The Four Pillars

Praveen Govindaraj — Tue, 27 Oct 2026 17:34:08 +0000

Your context window is a budget, not a bucket - Chapter 6 · Why giving your agent more context can make it worse

Why giving your AI coding agent more context can make it perform worse
When an AI coding agent gets stuck, the instinct is usually to give it more context.
More files. More documentation. More conversation history. A longer CLAUDE.md or AGENTS.md. Maybe the entire repository.
The assumption is simple: if the agent knows more, it should make better decisions.
But experiments suggest otherwise.
In one SWE-agent experiment, showing the agent a relevant file in a 100-line window produced an 18.0% success rate. Showing the entire file dropped that to 12.7%.
The agent had more information. Its performance got worse.
This is one of the most important lessons in building reliable AI coding workflows:
Your context window is a budget, not a bucket.
The goal isn't to give an agent as much information as possible. It's to give it the right information at the right time.

More context doesn't automatically mean better results Consider how you debug an unfamiliar codebase. You probably don't read every source file before fixing a bug. You start with the error, identify the relevant module, inspect its dependencies, and follow the evidence. You narrow the problem before expanding your investigation. AI agents need a similar discipline. Every model call receives a context payload: the instructions, relevant code, conversation history, tool results, and other information available for that decision. The size of the context window tells you how much information the model can receive. It doesn't tell you how much information it can use effectively. In the SWE-agent experiment, the results looked like this:

Showing too little information can hurt performance. But showing everything can hurt, too.
This is not an argument for always using shorter prompts. It's an argument for being deliberate about what goes into them.

Context has two failure modes
When an agent performs poorly, context problems generally fall into two broad categories.
Context starvation
The agent doesn't have enough information to complete the task.
For example:
• It edits a function without seeing its callers.
• It changes an API without seeing the expected response format.
• It modifies a test without understanding the production behavior.
• It follows a coding convention that the repository no longer uses.
The solution is to provide the missing information.
Context dilution
The agent has the necessary information, but it is surrounded by so much unrelated material that the relevant details become harder to use.
For example:
• A simple bug fix comes with the entire conversation history.
• A small refactor includes documentation for unrelated modules.
• A coding task begins with thousands of tokens of general instructions.
• Tool output overwhelms the actual error or result the agent needs to inspect.
The solution is to remove noise and make relevant information easier to find.
These problems need opposite remedies. Adding more context may fix starvation while making dilution worse.
A practical diagnostic
When an agent produces a poor result, try a simple experiment:
Reduce the context payload by roughly half and rerun the task.
• If performance improves or stays about the same, the original context may have contained unnecessary information.
• If performance gets worse, the removed information may have been important.
This isn't a universal benchmark or a substitute for controlled evaluation. It's a useful debugging technique for understanding whether your agent needs more information or better information selection.
Bigger context windows don't eliminate the problem
Model context windows have grown significantly. That makes it possible to include more code, documentation, tool output, and history in a single request.
But greater capacity doesn't guarantee that every additional token is useful.
Research into long-context behavior has documented limitations commonly described as the lost-in-the-middle effect: information can be harder to use when it appears in certain positions within a long input.
Chroma's Context Rot study examined 18 models and reported declining reliability as input length increased across several tasks. The study is useful evidence of the problem, although it comes from a company that sells vector database technology and should be considered alongside other evidence.
The practical takeaway is straightforward:
A model's maximum context length is a capacity limit, not a recommended prompt size.
Think of it like memory in a software system. Having more available memory doesn't mean every object should remain in memory forever. Good systems still manage what they load, retain, cache, and discard.
The same principle applies to AI agents.
Four ways to manage context
If context is a budget, how should we spend it?
There are four useful techniques.
A. Compact the context
Long-running agents accumulate information:
• Previous decisions
• Intermediate reasoning summaries
• Tool results
• Failed attempts
• Old instructions
• Repeated descriptions of the task
Some of that information is valuable. Some is no longer relevant.
Compaction means preserving the important state while removing unnecessary detail.
For example, instead of retaining a long debugging conversation, keep a concise summary:
Task:
Fix incorrect pagination in the customer API.

Findings:

The database query returns the correct number of rows.
The bug is in the page-offset calculation.
Existing tests cover page 1 but not page 2.

Files:

src/api/customers.ts
tests/customers.test.ts

Next step:
Add a regression test for page 2, then correct the offset calculation.
This gives the next model call a useful starting point without carrying every previous interaction forward.
The key is to preserve facts, decisions, constraints, and next steps—not every detail of the journey.
B. Offload large tool outputs
Tools can return far more information than an agent needs.
A repository search might return hundreds of matches. A test command might produce thousands of lines. A log file might contain one useful error buried in repetitive output.
Instead of inserting everything into the model's context, keep the full output outside the conversation and expose a smaller, relevant result.
For example:
Test suite: 248 tests
Passed: 247
Failed: 1

Failing test:
tests/customers.test.ts::pagination_returns_second_page

Relevant error:
Expected customer ID 21, received customer ID 1.
If the agent needs more detail, it can fetch the relevant section.
This is the principle behind tool-output offloading: store the full result, but bring only the necessary portion into context.
C. Use progressive disclosure
Don't load every instruction, document, or tool description at the beginning of every task.
Start with a small amount of general guidance. Let the agent discover more specific information when the task requires it.
For example, a repository might contain:
AGENTS.md
docs/
architecture.md
testing.md
deployment.md
database.md
The root AGENTS.md can explain the project's structure and point the agent toward specialized documents.
A database task can load database.md. A deployment task can load deployment.md.
This keeps the initial context focused while making deeper information available on demand.
The distinction matters: good context engineering doesn't mean hiding information forever. It means avoiding unnecessary information before it becomes relevant.
D. Reset the context when the task changes
Long-running conversations can accumulate outdated assumptions, completed work, failed experiments, and irrelevant details.
Sometimes summarizing the existing conversation isn't enough. Starting a fresh model call with a concise handoff is cleaner.
Think of an engineer handing work to a teammate at the end of a shift.
The handoff should include:
• What has been completed
• What remains unresolved
• Which files have changed
• What has been tested
• Which decisions must not be revisited
• What the next step should be
The new agent doesn't need the entire history. It needs the current state of the work.
Reset the conversation, not the project's knowledge.
Keep durable information in files, tests, issue descriptions, and other artifacts that survive the context reset.

Your AGENTS.md can become a source of noise Repository-level context files are now common in AI-assisted development. Files such as AGENTS.md, CLAUDE.md, and copilot-instructions.md can help agents understand a codebase without repeatedly rediscovering its conventions. But they can also accumulate stale or redundant guidance. A useful instruction file might explain: • How to run tests • Where important modules live • Which conventions are mandatory • What generated files must not be edited • Where to find specialized instructions An unhelpful one might include pages of generic advice, duplicate documentation, outdated commands, and rules that contradict the codebase. The problem gets worse when agents maintain these files by rewriting them wholesale. Repeated regeneration can gradually erase specific details, simplify important exceptions, or replace concrete instructions with generic summaries. A safer approach is incremental maintenance:
Read the existing file.
Identify the specific information that has changed.
Update only the relevant section.
Preserve useful details and exceptions.
Remove instructions only when they are demonstrably obsolete or redundant. Edit context files. Don't casually regenerate them. Treat them like maintained source code, not disposable prompt text.
Context engineering has a limit Better context selection is important, but it isn't the entire solution to reliable AI development. Eventually, an agent needs more than instructions about the codebase. It needs a system that helps it act correctly and verify its work. That means thinking about three related areas: • Context engineering: What information should the agent receive? • Harness engineering: What tools, constraints, and feedback loops govern its actions? • Environment and repository structure: How can the system make correct actions easier and mistakes easier to detect? A carefully written AGENTS.md cannot compensate for missing tests. A larger context window cannot make an unreliable tool reliable. A detailed instruction cannot guarantee that a change works. Context helps the agent make decisions. The surrounding development system helps those decisions become dependable results. That is where the next stage of agentic development begins. Try this in your repository Pick a coding agent you use regularly and inspect its main context file—perhaps AGENTS.md or CLAUDE.md. Try this small experiment:
Make a copy of the file.
Remove roughly one-third of the instructions that are generic, duplicated, outdated, or irrelevant to most tasks.
Keep essential constraints, commands, architecture notes, and project-specific conventions.
Run the same representative coding task with the original and reduced versions.
Compare the resulting code, test outcomes, and unnecessary tool calls. Don't optimize for the shortest possible file. Optimize for the most useful instructions per token. If performance drops, investigate what important information was removed. If performance stays the same or improves, you've found context that may not have been earning its place.

The takeaway
A bigger context window gives your agent more room. It doesn't automatically give the agent better judgment.
Reliable agentic development requires deliberate choices about what enters the context, what stays outside it, what gets retrieved on demand, and when the agent should start fresh.
Don't ask how much context your agent can hold. Ask which information deserves to be there.
How long is your CLAUDE.md or AGENTS.md today—and when was the last time a human actually edited it?

This post is based on Chapter 6 of The Agentic Development Lifecycle.
Read the full chapter: Context Engineering — The Budget, Not the Bucket

The Agentic Development Lifecycle - Nobody removed six controls

Praveen Govindaraj — Tue, 27 Oct 2026 17:23:35 +0000

Chapter 5 · One thing got cheap, and six safeguards fell with it

Nobody Removed Six Controls: AI Made Writing Code Cheap, Not Safe
One thing got cheaper. Six safeguards quietly went with it.
AI coding agents can generate code, write tests, refactor modules, and implement features faster than ever. But there’s a catch: when writing code becomes cheap, the surrounding engineering practices can start to look unnecessarily expensive.
Code reviews feel like bottlenecks. Design discussions feel slow. Small changes get merged with less scrutiny. Developers begin trusting generated output because it looks plausible.
Nobody explicitly decided to remove engineering safeguards.
The economics changed, and some safeguards disappeared along with the friction they were designed to manage.
That is the problem at the heart of the Agentic Development Lifecycle (ADLC).

The Chesterton’s Fence Problem Imagine finding a fence in the middle of a field. You might think it is pointless. It blocks the way, slows people down, and serves no obvious purpose. So you remove it. Only later do you discover that the fence was keeping livestock out, protecting a boundary, or preventing a problem you had never encountered. Engineering processes often work the same way. A pull request, a design review, a testing requirement, or a release approval can look like overhead when everything goes well. But each may exist to prevent a particular class of failure. AI changes how quickly we can produce code. It does not automatically eliminate the risks those processes were designed to control. Before removing a process, understand which failure it was preventing.
Six Things That Used to Come Along With the Cost of Code When producing code required more time and effort, several useful behaviors often came with the process. As AI reduces that cost, those behaviors need to be protected deliberately.
Effort and care When writing a change takes significant effort, developers have an incentive to think through the problem before implementing it. When an agent can generate several alternatives in seconds, experimentation becomes easier. That is a genuine advantage. But generating more code does not necessarily mean making better decisions. Cheap implementation can encourage unnecessary changes, speculative abstractions, and solutions that solve the wrong problem.
Author intent A developer who writes a change manually often understands why each major decision was made. Generated code can be technically plausible without reflecting the actual intent behind the task. A reviewer may see a clean implementation while missing that the agent interpreted the requirement incorrectly. The important question is no longer just, “Does this code work?” It is also, “Does this code do what we intended?”
Pacing Traditional development naturally creates pauses: writing code, running tests, requesting review, responding to feedback, and preparing a release. Those pauses can provide opportunities to discover mistakes. An agent can move through several of these steps rapidly, making it tempting to compress or bypass the checkpoints. Speed is valuable. Removing every opportunity to reconsider a decision is not.
Trust boundaries AI agents may read repository files, inspect documentation, consume issue descriptions, and act on text supplied by external sources. Not all of that text should be trusted as instructions. A malicious or misleading instruction embedded in an issue, document, or file can attempt to redirect an agent's behavior. This is one reason prompt injection and excessive tool permissions matter in agentic development. A reliable workflow needs explicit boundaries around which instructions an agent may follow and which actions it may take.
Natural cleanup When changes are expensive to produce, developers may be more selective about what they add. When changes are cheap, temporary workarounds, redundant helpers, unnecessary dependencies, and unused abstractions can accumulate quickly. AI can help clean up a codebase, but cleanup does not happen automatically just because code generation has become faster. Teams need explicit checks for unnecessary complexity, duplicated logic, abandoned experiments, and changes that exceed the task's scope.
Learning through small tasks Small coding tasks are often how junior developers build intuition: reading existing code, making a change, seeing the consequences, and learning from review. If agents perform all the routine work, junior developers may lose some of those opportunities. The solution is not to avoid AI. It is to use it in ways that preserve learning: ask for explanations, review alternatives, predict test outcomes, and have developers justify important decisions. The common thread: these benefits were not always documented as separate controls. Some emerged naturally from the cost and pace of doing software work. When that cost changes, teams need to make those benefits intentional.
The Bottleneck Has Moved Suppose an engineer spends four hours implementing a feature and one hour reviewing it. Now imagine an AI agent produces a similar change in ten minutes. The code-writing stage has become much faster. But the team still needs to establish whether the change is correct, secure, maintainable, and aligned with the requirement. The bottleneck moves from producing code to evaluating and governing the result. That changes the economics of software engineering. The goal should not be to preserve every old process exactly as it was. Some manual steps may become unnecessary. Others may need to become stronger or more automated. The key distinction is between a process that was slow because code was expensive and a control that remains necessary because failure is expensive. A slow manual check might be replaceable with a reliable automated test. A security boundary cannot simply be discarded because an agent works quickly. This is the difference between a change in degree and a change in kind. AI changes the degree of effort needed to produce code. It does not change the fundamental need to control risk.
What Should Developers Do Differently? Instead of asking, “How can we remove friction from our AI workflow?”, ask: “What was this friction protecting, and what will protect it now?” Try this simple exercise with your team. For each process gate, document three things:

These are examples, not universal replacements. The right controls depend on your system, threat model, team, and consequences of failure.
The objective is not to add more process for its own sake.
It is to make sure that when a safeguard disappears, its purpose does not disappear with it.

The Real Challenge of Agentic Development AI coding tools are becoming more capable. The next challenge is designing the development lifecycle around that capability. A good agentic workflow must do more than generate working code. It must preserve intent, make decisions reviewable, respect trust boundaries, prevent unnecessary complexity, and help developers become more capable over time. Some old processes will become obsolete. Others will become more important. The hard part is knowing which is which. That is why adopting AI successfully is not just a tooling decision. It is a lifecycle-design decision. ________________________________________

Try This in Your Next Sprint
Choose one process gate your team considers slow or unnecessary.
Ask:

What specific failure was this gate designed to prevent?
Does that failure still exist when AI writes the code?
If we remove or automate the gate, what will provide equivalent protection?
How will we know the new approach is working? Do not remove the gate until you can answer the third question. Continue Reading

This article is based on Chapter 5: “What Actually Breaks” from The Agentic Development Lifecycle.
Read the full chapter: https://neam-lang.github.io/The-Agentic-Development-Lifecycle/chapters/05-what-actually-breaks.html
The next part explores the next step: once we understand which safeguards have been lost, how do we deliberately bring them back into an AI-driven development lifecycle?

Join the Discussion
Which safeguard do you think AI-assisted development teams are most likely to lose first: careful review, author intent, security boundaries, code cleanup, or developer learning?
Share your experience in the comments.
Follow along for more practical ideas on building reliable software with AI agents.