A team ships a billing feature in two days. It used to take two weeks. The coding agent wrote the code, generated the tests, all CI checks passed, and the release shipped on schedule. Three months later, an enterprise customer notices that partial refunds are calculated under a rule nobody in finance ever approved.

The agent hit an ambiguity in the spec, made an assumption, wrote a test to assert its own assumption, and passed it. Nobody recorded the decision. Nobody knew it had happened.

That's the trap with AI-native delivery. Coding agents can turn a plain-English prompt into working code, tests, and documentation in minutes. Spec-driven development (SDD) is supposed to keep them on the rails. The upside is real enough--McKinsey tracked nearly 300 public companies and found top performers posting 16-30% gains in productivity and 31-45% gains in software quality.

Yet most companies are stuck at level two: using AI as an autocomplete for individual tasks. Full end-to-end delivery is still rare. The difference isn't the tooling--everyone can buy the same Claude, Codex, or Cursor licenses. The difference is what happens when the spec meets reality.

At Tintash, we build software and AI systems. We ran into these traps early, watched them break client delivery, and built an internal framework called hGATE to stop them. The failures consistently cluster in three places: the frameworks, the staffing model, and how you handle legacy systems.

Frameworks: memory and drift

Tools like GitHub's Spec Kit and Amazon's Kiro do the initial job well. They give agents a structured spec broken into discrete tasks. McKinsey rightly lists mastering spec-driven development as a requirement for operating at scale.

The trouble starts on the second revision.

An agent only knows what fits in its current context. If the reasoning behind an earlier decision wasn't written down, the next agent session will happily undo it without knowing anything was lost. Ask an agent to implement partial refunds without specifying whether multiple refunds are allowed against one invoice, and the model will invent a rule on the spot.

Worse, when the same agent writes both the implementation and the tests, it validates its own assumptions. We've seen agents write logic containing a subtle bug, then write a test that matches the buggy behavior word-for-word. Everything passes CI. The pull request looks immaculate.

A human reviewer helps, but reviewing code against an incomplete spec can't tell you whether the business actually approved the behavior. Over time, even a carefully drafted spec drifts away from the running codebase.

Anthropic's documentation for Claude Code recommends solid practices: maintain a project memory file, have the agent interview the engineer before writing specs, and spin up a second agent in a fresh context to review the first one's work. These help. But Anthropic also notes, plainly, that instructions in a project file are advisory: the agent may not always follow them. Across thousands of developer sessions, advisory rules don't hold. Guards have to be structural, not polite suggestions in a prompt.

Closing these gaps requires four operating disciplines:

  1. Record decisions as artifacts. The agent documents what was decided and why in persistent files every subsequent session reads. Memory lives in the repository, not the session context.
  2. Keep intent with people. The agent questions the spec on edge cases before generating code, and a business owner approves the resulting rules. Autonomy should scale with the cost of getting the decision wrong.
  3. Validate, don't just verify. Verification asks whether the code compiles and passes tests. Validation traces code and tests back to behavior a human approved.
  4. Update the spec with every change. Identify affected behaviors, update the spec, prune dead code, and reconcile manual hotfixes before the next agent session touches the files.

In hGATE, we turned those disciplines into a fixed pipeline across three standard engineering practices:

  • Domain-driven design (DDD). Divide the system into bounded contexts with strict interfaces. This keeps the agent's context window small and stops changes in one module from rippling into another.
  • Behavior-driven development (BDD). Express business rules as plain-language scenarios that a business owner approves before any code is generated.
  • Test-driven development (TDD). Turn approved scenarios into tests first. Then--and only then--let the agent write code to pass those tests.

Because tests come from human-approved scenarios rather than agent-written code, the test suite acts as an objective contract. If an agent hallucinates a rule, the tests fail.

We should be upfront about where hGATE is today: it isn't magic. It sharply cuts the tokens wasted reading irrelevant code and keeps generation focused, but it doesn't reduce the base compute cost of running frontier models. Tooling for existing platforms is still early. And until our automated enforcement tooling ships, some checks still depend on engineers remembering to follow the protocol.

Staffing: judgment doesn't scale with compute

Every safeguard above requires a human: someone to approve business rules, answer edge-case questions, and review architectural trade-offs.

Routine boilerplate, CRUD endpoints, and first-draft tests take far fewer hours now. That efficiency is real. The ratio of engineers to output has permanently shifted. The mistake is concluding that junior engineers paired with LLMs can replace senior judgment.

McKinsey put it cleanly: agents "cannot infer business intent." In practice, four responsibilities still belong entirely to experienced engineers:

  • Constraint engineering. A product manager states what the business needs. An engineer translates that into technical boundaries: transaction scopes, consistency models, failure isolation, API contracts, and security boundaries. An agent can propose options, but none has a single right answer.
  • Non-functional standards. Generated code can be functionally correct and still fall over under load, leak memory, or run up an exorbitant cloud bill.
  • Cross-system reasoning. An agent only sees what you load into its context. It doesn't know that altering an event payload breaks an unversioned downstream service two repos away.
  • Production ownership. When an outage hits at 2:00 AM, an agent isn't on call. Someone has to decide whether to roll back, toggle a circuit breaker, or isolate a database deadlock.

Agents amplify whoever directs them. Paired with an experienced engineer, an agent applies sound judgment at machine speed. Without that guidance, it generates confident technical debt at unprecedented volume.

This leads to an uncomfortable truth for software vendors: AI-native delivery delivers the same scope with fewer engineers, but it requires a much higher concentration of senior skill.

We structure delivery around small domain pods. Each pod has a business owner supplying domain intent (often the scarcest resource) and one senior engineer owning architecture, boundaries, and production calls. Execution around them can be heavily automated.

The two common staffing mistakes happen right here:

First, letting go of engineers who know how the platform actually works before their knowledge is captured. Once they're gone, the agent is just encoding guesses, very quickly.

Second, replacing senior engineers with cheaper juniors under the belief that 'the spec does the heavy lifting now.' That saves money on the smallest line item (execution rates) while risking the largest: platform stability in production.

A solid framework and a strong team can still fail if leadership treats adoption as an organizational rollout rather than a domain-by-domain engineering problem.

Greenfield builds are relatively straightforward. The primary hurdle is behavioral: engineers used to discovering architecture while writing code have to define boundaries and approve behaviors upfront. Prove the entire loop on one bounded domain--including shipping one non-trivial change cleanly through the pipeline--before scaling across the team.

Legacy platforms are much harder. Intent lives buried in hundreds of thousands of lines of code, five-year-old Jira tickets, and the heads of three engineers. If you point an agent at a legacy codebase and tell it to write tests matching current behavior, you aren't capturing business requirements. You're enshrining historical bugs as formal specs.

Before automating an existing platform, you have to reconstruct intent domain by domain:

  1. Map the domain. Isolate responsibilities, dependencies, and external contracts.
  2. Extract behavior into plain scenarios. Document what the system actually does on edge cases, especially where documentation is missing.
  3. Separate bugs from features. Have someone who understands the business distinguish intended behavior from historical accidents.
  4. Pin behavior with baseline tests. Lock down the agreed contract before letting an agent touch the code.

This is senior-heavy, unglamorous archaeology. It ships zero new features in sprint one. If leadership doesn't budget for that upfront, the team will cut corners, point agents at unmapped code, and wonder why regressions explode three months later.

Measuring outcomes and costs

In both greenfield and legacy environments, autonomy must be earned domain by domain. Evaluate progress on outcomes rather than adoption metrics: escaped defects, rework cycles, regressions, cycle time, and review hours.

When we evaluate frameworks, we look at whether constraints are explicit before code is generated, whether specs reconcile against running code, and whether tests trace to human-approved intent. The industry hasn't settled on standard benchmarks for these questions. To help fill that gap, Tintash is building Caliber Eval, an open framework to benchmark agentic workflows across domains.

Two financial realities belong in any business plan here:

First, costs shift; they don't vanish. Savings on routine junior coding get offset by senior review time, context management, and model compute bills. A business case based purely on headcount reduction is overstated.

Second, governance is an architectural problem, not a policy memo. You don't govern AI agents with guidelines. You govern them with hard domain boundaries, persistent decision logs, and tests derived strictly from human-approved contracts.

If an agent can't remember why a rule exists, it will eventually rewrite it. And if nobody catches it until an enterprise customer calls, that two-day billing feature didn't actually save any time at all.