AI SDLC: Who Owns "Done"?

Last week I was in a leadership meeting when the VP of Engineering repeated the question his CFO had asked him the day before:

The question is legitimate, and top tech firms and platforms are answering it with more or less the same playbook: give agents more autonomy, keep more of them running, and get people out of the loop.

At the same time, a second instruction is landing on those same teams: "We need to use AI to ship more, but without breaking production or leaking something we can't take back." Funny, isn't it? Ship faster, better and safer, all at once.

An AI SDLC is a software development lifecycle where agents do most of the implementation and people shift their attention to the gates: intent, specs, verification, and release. The open question for most teams is who defines the criteria those gates check against.

If you lead an engineering team moving to an AI SDLC, this post will help you navigate its challenges and get the most out of it. To get there, let's first take a look at what the companies building the next generation of tools, harnesses and infrastructure for this "AI era" are saying.

The Industry's Answer: Move Human Attention to the Gates¶

In August 2026, Anthropic published its AI-native SDLC playbook (others call it the agentic SDLC, or Agentic Development Life Cycle, ADLC), describing the shape most teams are landing on: "human attention shifts along with the artifacts". People stop reviewing line by line and start reviewing at gates.

Days later, Kiro (Amazon's agentic IDE) published the most explicit version of that playbook I've read so far, including the results it reports from Amazon's own teams. Their opening line is the thesis: software development has split between those who changed how they work with agents and those who only changed their coding tools.

Kiro's framework has ten principles, but these four are the ones I found most valuable:

1. Maximize agent time, minimize your involvement. Stop prompting and waiting. Give the agent a long task with validation built in, let it loop for thirty minutes or overnight, run several in parallel, review asynchronously. The constraint on your output stops being how fast you type and becomes how many agents you can keep meaningfully busy.
   
2. Build your codebase for agents and give them a fast feedback loop. This is shift-left taken seriously. Linters, unit tests, local mocks, the full stack on a laptop, property-based tests derived from the spec, and the agent has access to all of it so it can find and fix its own failures before a person ever looks at the code. Their warning is one I'd underline: faster generation without this investment only means more broken builds.
   
3. Invest in agent context. Steering files, architectural decisions written down, inline commentary kept as persistent memory. The teams that skip this step, they say, keep wondering why the agent repeats the same mistakes.
   
4. Trust the boundaries, not the agent. Constrain what the agent can touch (files, tools, network, credentials), gate only what you can't undo, layer deterministic checks such as SAST and secret scanning, and then let it run unsupervised inside those limits.

Both documents are right about a lot, and the benefits are real. Getting started even looks easy: I strongly recommend you this set of scaffolding skills for each step, that you can also customize for your codebase, then a harness to orchestrate them without losing control and to give each specialized agent the right context.

What neither document defines is who verifies the loop, and by what criteria. They tell you where human attention goes; they don't tell you who exercises it or what "good enough" means for your system. That gap is the one quality engineering has to close, and it's what the rest of this post is about.

🤝 Where I'd Sign¶

About seventy percent of it. "Trust the boundaries, not the agent" is our positioning in different words and "make intent explicit before code" is what we've been calling Intent Review. Kiro itself says this is an engineering investment and not a switch you flip, and that the first weeks feel slower. That's why we insist on a foundation phase before scaling agents. And "measure correctness, not just speed" is a sentence I could have written.

The remaining 30% sits underneath those ten principles, and it's where I think the real leverage is. Let’s drill down on them with these glasses: the bill, the roles, and the loop.

🔍 What's Underneath¶

1. The Bill: This Is Capex, and it Scales with What You Already Operate¶

Code became cheap. The bill didn't disappear; it moved, and it has three line items.

The first is the foundation. Every one of the ten principles asks you to build something before you get anything back: steering files, a codebase agents can navigate, property tests, boundaries, evals. Most teams I met skipped this and bought the licenses instead.

The second grows with your output. Anthropic just published its own numbers, and they tell the story better than I can:

The third is time. Kiro says the first weeks feel slower; behind a security review and a change board, weeks become quarters. And agent time only compounds if the gates answer at the same speed: an agent that finishes at 2am and waits until Monday isn't maximizing anything.

How big the bill gets depends on what you already operate. A startup born with agents has nothing in production to protect. Anyone running a legacy core, a bank being the extreme, changes a system whose rules live in the heads of the people who keep it working. Same playbook; different sequence, cost and risk.

So I'd answer the CFO in his own language. Treat the foundation and the verification infrastructure as capex, amortized over every release that follows. Treat the agents' work on features as opex, measured per change you actually accept. Who staffs each line?

2. The Roles: Developers Own the Harness, Testers Own "Done"¶

The frontier pages describe the developer's shift well, and I'd push it one rung further:

Writing code → reviewing code → reviewing the AI's review → improving the harness that produces the code.

The industry has a name for that top rung now: loop engineering. Design the cycle the agent runs (act, verify against real signals, decide, repeat, stop) instead of writing every instruction by hand. Kiro's tenth principle, "continuously tune your agent setup", is that job, and it's permanent.

Now look for the tester in the same pages. Testing appears as "the tests the agent writes". Domain experts and quality engineers are not in the picture. Anthropic's CI story has a telling detail: the service that decides what gets verified had, in their words, murky ownership. The thing that decides what gets checked had no owner.

That's a problem, because the agent that writes the code also writes the tests, runs them and declares success. The producer is the auditor. OpenAI just showed where that ends: during internal evaluations, an agent exploited a flaw in its own testing interface to copy the reference solution and collect the reward, and agents reasoned about the grader instead of the task.

One of the top labs in the world, and its response was graders that check how a task was done, not only whether. In our work with agents we treat it as a rule: the agent's self-assessment is never evidence. Only deterministic checks or a human validation count.

Every bank already knows this principle as segregation of duties, and Anthropic's playbook applies it at the pull request, where the agent that wrote the code can't approve it. What it leaves open is who decides what the checks should verify in the first place.

This is where I think the frontier framing falls short: very often the tester holds more business knowledge than anyone else on the team. Functional testers spend their days understanding the business logic and what users actually need; when they aren't there, teams end up running UAT with the users, which tells you where the knowledge lives.

In banking, testing is still the bottleneck, and the usual fix is "give me another tester". That scales execution. Agents scale execution better. What doesn't scale is the judgment: which module touches refunds, which rule is regulated, which failure would matter. Anthropic's test selector decides from history and package relevance, which is the right start; someone still has to say what matters if it fails.

So if there has ever been an era where shift-left is possible, it's this one. Everyone talks about designing the loop. We ask who designs the verification inside it: the criteria, what counts as evidence and when to escalate. That is the tester's ladder, and the top of it is a quality engineer:

Executing tests → designing tests → designing the verification inside the loop → owning the criteria and the evidence that make a release defensible.

Developers own the harness; quality engineers own what "done" means."

Those last two rungs are the answer to the CFO. The team doesn't get smaller because agents write code. It changes shape, because someone has to own what "done" means.

3. The Loop: Shift-Left Now Includes Learning¶

Shift-left used to mean testing earlier. With agents it reaches the intent and the spec, before a line of code exists: a quality engineer reviewing an intent for ambiguity, a risk analysis attached to a spec, acceptance criteria and properties written before the agent starts. What moves left is the learning, not just the testing. Every criterion made explicit at the intent is one less thing to discover in a diff.

Anthropic's other piece of advice in the CI post: instrument your services so they become the agent's eyes and ears. Read it from the quality seat and it's the biggest upgrade testers have had in years. The same signals that let an agent hill-climb on a service let a quality engineer see what changed, what it touched and how it behaved last time in production, while testing, not after.

We saw this in a core banking system with hundreds of thousands of programs: turning system traces into plain language gave testers a view of the execution path behind each operation that nobody had while testing before, and verification got more precise because of it. Observability stops being the SRE's dashboard and becomes the evidence layer the criteria are graded against.

Then there's the half nobody designs for. Everything above produces learnings: a criterion a tester made explicit, a boundary that turned out too wide, a module that failed for a reason nobody had written down. Today most of them evaporate at the end of a sprint. They become doubly valuable the moment you can put them back into the harness, a skill, or the context an agent receives, at the moment the agent needs them. A learning is only worth something once it lives where the next decision is made.

That's the direction we're taking with Abstracta Intelligence: quality knowledge that doesn't stay in one head or one sprint, but returns to the loop when it's needed, with an author and a date attached. It deserves a post of its own, and it's my next one.

🧾 The Platforms Are Seeing the Same Thing¶

Almost at the same time as Anthropic's playbook, the CEO of GitLab, published "When code is abundant". His argument comes from the platform side: once implementation becomes cheap, the unit of economics changes. It stops being code produced and becomes the cost of a change you can actually accept. And the line I keep coming back to:

GitLab isn't stating this as a principle; it's the direction of their product. When the company that runs your pipelines decides that acceptance cost, not commits, is the number to optimize, the argument for verification stops being a quality team's opinion.

I'd only add the team's side of the same coin. Cost per accepted change measures what you pay. What you buy with it is trust. So next to every agent-time dashboard I'd put a much simpler question: of everything your agents produced this week, how much did you accept without rework, and could you show the evidence behind it to your regulator, your CISO and your customers?

At Abstracta, we sum it up in a sentence: quality is how we engineer trust.