×
![Modal Image]()
Across our engineering teams, we see different ways of working with agents. One engineer keeps a 40-line rules file. Another types everything from scratch. One switches models by task; one uses the same tool for everything. Both kinds ship. The difference shows up 3 months later, in code review.
That’s the normal first phase of adoption, and it’s fine. It stops being fine when every engineer uses the agent differently and the team inherits the spread: inconsistent code patterns, duplicated prompting effort, different review standards, undocumented decisions, test quality that depends on who was typing, and lessons that stay inside 1 person’s chat history.
Giving 1 developer a fleet of agents feels like peak productivity, and it’s the AI-era version of The Mythical Man-Month. Fred Brooks’s point was that adding capacity to software work doesn’t make delivery faster on its own, because software depends on coordination and shared understanding. Parallel agents without shared alignment scale merge conflicts, duplicated decisions, and review load.
At Amplified we’re not claiming to have solved this on every project. We are further along than we were, and this article is what got us there: consistency where it matters, in context, constraints, testing, review, ownership, and approval boundaries, and freedom everywhere else.
The agent has moved well past implementation for us: debugging, technical discovery, PR review, and now operational work, from CI failures and deployment scripts to cloud configuration and incident debugging. That widens the risk. A bad frontend refactor breaks a page. A bad infrastructure change takes down production, leaks data, or quietly raises the cloud bill for months.
So the question we stopped asking was “which AI tool should we use for everything?” The one we ask now is “which tool, model, workflow, and context strategy fits this task?” A UI cleanup, a backend refactor, a DevOps investigation, a migration, and a PR review are different risk classes, and we stopped pushing them through 1 workflow.
The question we stopped asking, and the one we ask now
Some of that is tool choice, and some of it is model choice, which gets its own section below. Most of it is a process: the same review expectations, testing behavior, security boundaries, ownership rules, and approval habits across every repo, so the agent’s output is reviewable no matter who ran it.
Engineers carry a lot of implicit project knowledge: how files are structured, which service owns a behavior, which component library to use, what runs before merge, which actions need approval. People learn it through onboarding and code review. The agent needs it written down.
The split we settled on: repo-wide behavior in AGENTS.md, product context in PRODUCT.md, design standards in DESIGN.md, and stack-specific execution in skills. AGENTS.md is the operating contract, and it defines the floor: use the package manager already in the repo, don’t hand-edit generated files, respect ownership boundaries, don’t revert unrelated changes, run targeted verification, never take a risky action without approval. The failure mode is turning it into a junk drawer. If every framework guideline, UI preference, auth caveat, and deployment note ends up in 1 file, the signal drops and the agent’s attention with it.
Skills carry the task-specific judgment. Matt Pocock’s.claude directory is one example of how task-specific guidance can be structured: /tdd keeps the agent in a red-green-refactor loop, while /diagnose follows a reproduce, hypothesize, instrument, fix sequence. In our case, skills cover areas such as design-system usage, migrations, API lookup, and deployment.
The skill that paid for the whole idea was the component lookup. In our audits, the agent kept hallucinating UI component props, and every one became a broken build. A skill that makes it read the actual component exports before writing JSX ended those failures. We built the skill, and it has run on every UI task since.
Every time someone tells the agent “not like that, in this repo we do it this way,” that is skill material.
A DESIGN.md does the same for visual work. Without persistent design memory, every visual task is a fresh prompt: cleaner, more polished, more modern. With one, the agent has stable constraints on typography, spacing, density, color, interaction patterns, and accessibility, and a definition of what good means for this product.
The other thing skills gave us is less noise. Not every rule belongs in every conversation. Loading context only when a task needs it keeps the agent sharp, and it’s a large part of why the harness matters as much as the model: a coding agent is the model plus the prompt, the file-access layer, the shell, the planner, the diff editor, the test runner, the retry policy, and the permission model. Artificial Analysis‘s coding-agent benchmark shows the same model behaving differently across agent environments, which matches what we see on real projects.
Token price is easy to compare and engineering cost isn’t. The number we care about is cost per accepted change, and it adds up more than the API bill.
What an accepted change costs
A cheap model gets expensive when it needs many turns, produces noisy diffs, or keeps missing the failing test. A more expensive model can be the cheaper one if it lands a small, correct patch on the first run.
So model choice is per task, and it lines up with Andrej Karpathy‘s idea of jagged intelligence: frontier models have sharp peaks in verifiable domains and surprising valleys elsewhere. We run a portfolio. Fast, cheap models take classification, summaries, changelog drafts, and low-risk questions. Mid-tier coding models take routine patches and test updates. Frontier reasoning models are reserved for complex debugging, architecture-sensitive changes, and high-risk review, where a wrong answer costs more than the latency.
Benchmarks help us shortlist and never decide. Artificial Analysis’s LLM leaderboard tracks intelligence, price, speed, latency, and context window, and its Coding Agent Index measures repository Q&A, patch generation, and terminal use. Then we still evaluate on our own repos, with our own review path and a rollback plan. A model that’s strong in chat can be a poor coding agent, and one that writes plausible code can fail at shell work.
The agent performs better when the project already has clear patterns. It infers from the surrounding code, so it reinforces inconsistency where it finds it and accelerates good practice where that’s what’s there. Early in a project we lay the foundation by hand: structure, core components, naming, service boundaries, utility and testing patterns, design-system usage, API conventions. John Ousterhout‘s deep modules matter here too. Many tiny files with tangled dependencies give the agent nowhere to draw a test boundary; simple interfaces over complex internals give it something to imitate.
Migrations are where the agent has earned the most. They’re repetitive, bounded, and full of small decisions that need to be made the same way far too many times. We split the work in 2. Judgment work stays with engineers: target design, rollout strategy, customer risk, compatibility, what must not change. Execution work goes to the agent: finding call sites, rewriting similar code across files, generating adapters, updating tests, chasing edge cases.
The first prompt in a migration is never “migrate us to the new stack.” It’s a short brief (current state, target state, non-goals, compatibility, risk areas, verification, rollout) and then: inventory every use of the old system, group the findings by approach, and do not edit files yet. The inventory is the first deliverable. It turns a codebase-wide effort into a reviewable map, and it forces the team to name the risk before code moves. Engineers still supervise the behavior-sensitive parts: routing, caching, rendering modes, middleware order, form semantics, environment loading, anything that passes local tests and still changes production.
Infrastructure gets a harder line. The agent stays near the checklist and away from the button. It reads a failing CI log, finds the first meaningful error, compares against the last passing run, and proposes a fix. It drafts Terraform, runs format and validate, produces a plan, explains a cloud CLI command, compares staging and production config, and writes rollback notes. Applying the plan, changing production permissions, running destructive SQL, deploying, or touching secrets requires a person, every time.
The most expensive thing we found is what we call the 85% Trap.
The 85% Trap
In an audit of a 78-session feature build, 15% of the sessions contributed directly to the feature. The other 85% was downstream recovery: bug remediation, repeated validation cycles, PR churn, and rework caused by assumptions that drifted between sessions. None of that showed up in anyone’s velocity number. All of it showed up in the calendar.
The way out is a loop. Use the agent on real work. Notice the repeated failure. Find the root cause. Convert the lesson into a rule, a checklist, a skill, a permission boundary, or a runbook update. Reuse it on the next task. If the agent changes the wrong layer twice, add a layer-boundary rule. If it invents helpers, add a simplicity rule. If it skips tests, add a verification rule. If it commits without asking, add a permission rule. If it misunderstands a new technology, write a skill.
Skills only work if they live close to the code and move with it. When the routing pattern changes, the skill changes. When a generated client moves, the skill moves. A stale verification command inside a skill is worse than no skill, because the agent will follow it confidently.
Review norms close the loop. Consistency comes from verifying the agent better rather than trusting it more: smaller PRs, a note on which parts were agent-assisted, generated tests checked, security and permission review, manual QA where it matters. Validation scales with risk, so documentation and UI cleanup move fast while authentication, billing, production data, and infrastructure get explicit approval.During debugging, the agent separates evidence from inference: ‘error rate rose after a new version reached production’ is evidence; ‘the deploy is a likely contributor’ is a guess, and it says so.
The baseline we’re working toward includes: instruction files, reusable rules and skills, review and testing expectations, approval requirements for risky actions, model selection guidance, infrastructure safety boundaries, conventions for MCP and external tooling, and a rule for when to reset a drifting conversation. Experimentation stays welcome on top of that. The goal is predictability in the parts that hurt when they vary.
For a founder choosing a partner, the useful question isn’t “do you use AI?” It’s “how do you use it safely, consistently, and responsibly?” At Amplified the answer is the engineering process around the agent: written rules, human review, tests that mean something, risk tiers, approval boundaries, and code that stays maintainable after we hand it over. The productivity is real, and the part that lasts is turning 1 engineer’s good habit into something the whole team can trust.
Experienced engineers still set the bar for quality, safety, and maintainability, and the agent gives a disciplined team more reach. That’s the whole series in 1 sentence.
If your team’s agent work drifts between engineers, send us a rule file or a retro and we’ll tell you what we’d standardize first. Let's build together.
