The loop is moving.
Are you moving with it?

01Where we are: human-in-the-loop

Today, AI is an assistant. You drive every step. You sign off every change. The gain is real, but it has a hard ceiling: one person reading and deciding in the middle of every loop – at human speed.

That made sense while models were unreliable. Today, when they can plan, execute and check their own work? That exact model is the bottleneck.

02Where it’s going: CAO – Continuous Agent Orchestration

With CAO, you move out of the loop and above it. You define intent, constraints and what “good” looks like. Agents break the work down, run in parallel and deliver results – not suggestions. Gates decide whether a change is even allowed to exist. You decide whether it’s worth shipping.

03Three roles, cleanly separated

The mistake: treating “AI” as one big blob that replaces everything. In practice there are three parties, and each is good at something the others fail at. Mix them up? You get either a human bottleneck or an unsupervised slop machine.

04Gates matter more than ever

A model finds many of the patterns CodeQL or Sonar find too. Doesn’t mean the tools are obsolete. It means: they become more valuable. They’re deterministic. Same input = same verdict. Every time. In seconds. For almost nothing. They don’t get tired. You can’t talk them round. They don’t have bad days.

That’s exactly what you want from a minimum bar. CI/CD becomes a continuous, binary gate on every change: Does it build? Do the types hold? Do the tests pass? No known vulns? Or not. Merge or no merge.

Agents are great at clearing that bar – feed them the failures and they fix them. But they’re a poor substitute for being the bar.

And that guaranteed floor is what frees you. When you trust that nothing below the line ships, your attention goes where it belongs: the product. You can go into the details, iterate more, iterate faster – without re-checking the basics every time.

05Where the human belongs: usage approval

With gates guarding the code and agents producing it, line-by-line PR review becomes a side issue. Spot checks, fine. But reading every diff? Doesn’t scale. And mostly duplicates what the tools already verify.

Your approval moves up a level: from “is the code okay?” to “is the product right?”

That means: actually using it. Click through on a real device. Empty state, error state, slow network, absurd input, second user, keyboard only. Ask: how does someone who’s never seen it read that label? Notice what feels off – even when every check is green.

Automation tells you: “works as specified.” Only a person tells you: “works for people.”

06Every corner cut is a step into slop

With agents, you can cut every corner. And each one looks harmless on its own. It’s faster. The output looks plausible. Nothing breaks today.

• Skipping tests “just this once” because the agent said “it works”
• Disabling a lint rule or suppressing a warning instead of fixing the cause
• Merging without clicking through the feature yourself
• Accepting generated code nobody on the team could explain
• Letting architecture drift because every change looked fine on its own
• Shipping the happy path and pushing edge cases to “later”

Every corner = a step into slop. And slop compounds faster than you can generate it.

07A warning: more, faster, more broken

For the first time, most teams are no longer blocked by output. Code, PRs, features – practically on demand. The natural reflex: go all in. More features. Even faster. Even more. Velocity charts look incredible.

Nobody feels that pull harder than the people whose job is to push things forward: dev leads, PMs, stakeholders. Usually the most motivated people in the room. For years, their frustration was capacity. Suddenly capacity seems solved – the whole roadmap reachable this quarter. Every conversation turns into: “What else can we ship?”

And then the product stops making sense. Features overlap. Flows contradict each other. Nobody remembers why anything exists. Every new change builds on a layer nobody really understands. The team didn’t get slower – it just stopped noticing the mess it ships.

The speed is a gift, not a mandate. Use it to build two versions and compare them. To put something in front of real users this afternoon instead of next month. To iterate on the same feature three more times – not just pile the next ten on top.

The lesson is old and still gold: Test. And keep up. Know what you have before you pile on more. Static tools help here too – not as a verdict on individual changes, but as a rough compass. Coverage, complexity, duplication, hotspots show you where the product really stands as something you’d ship, and whether it’s still maintainable: a codebase devs can read, understand and dig into when they have to. Because eventually, someone always has to.

08The better story: the right configuration, right for you

Two teams. Same agents. Same models. On paper, the same tools: formatter, linter, type checks, tests, CodeQL, Sonar. Six months later: one is flying, the other is drowning in noise. The difference? Not the tools. How they’re configured, where they run, and how they fit into the environment.

Team 1 bolts the tools on. Formatting only in CI. Every push = a gamble. An agent opens a PR, waits 8 minutes, fails on a trailing comma, reads the log, fixes it, pushes, waits again. Two branches format the same file differently → whitespace collision. Import and key order drift with whoever touched the file last → every PR update conflicts. Keeping PRs current quietly becomes a job. Review threads fill up with style nits. And when a rule gets in the way? Fastest fix (human or agent): switch it off. These are exactly the habits we devs had before AI – just faster and more expensive: CI minutes, tokens and attention spent on things that don’t change what the product does.

Team 2 makes a few decisions once. Writes them down as config. Formatting is canonical and automatic – two people (or two agents) writing the same change → the same bytes. Tools sort imports and keys → parallel branches don’t fight over order. Whitespace and line endings are settled by .editorconfig and .gitattributes. Lint rules that can fix themselves do; the few that remain catch bugs, not taste. A merge queue keeps PRs current with the base branch and reruns the gates → nobody babysits a rebase – and with canonical formatting, updates almost never conflict.

The cheap, obvious fixes happen first, and locally: anything that doesn’t change behaviour, or changes it negligibly at worst. A git hook manager like lefthook turns that into a single file:

# fix what doesn't change behaviour, before it's committed
pre-commit:
  commands:
    fix:
      glob: "*.{js,ts,tsx,json}"
      run: npx biome check --write --no-errors-on-unmatched {staged_files}
      stage_fixed: true

pre-push:
  commands:
    types:
      run: npx tsc --noEmit

Biome here – Prettier, ESLint, Ruff and gofmt work the same way. Install the hooks from the project’s setup script, so agent sandboxes run them too, not just laptops.

The costs follow the same order. Pre-commit fix = milliseconds, zero tokens. A CI round trip for the same trailing comma = minutes of runner time + a full agent turn to read the log and retry – times every PR, every agent, every day.

The subtle part: CI still runs every check. It stays the binding, binary bar. If a hook is ever skipped, the bar still holds. But checks about form rather than function can’t fail anymore – by the time a commit exists, they’ve already been applied. The minimum bar is secured before it’s ever tested. And it creates zero friction: not for people. Not for agents.

Agents write code & features – not formatting. Tools format, sort, flag. People judge the product.

There’s no universal preset to copy. The right config is the one that fits your stack, your repo, your CI budget, your team – decided once, versioned with the code, identical on every laptop, in every agent sandbox and in CI, and fast enough that nobody is ever tempted to bypass it. Get that right, and everyone does what they’re best at: tools do what they were built for. Agents spend their iterations on behaviour. People spend theirs on the product.

09The last mile: one click from “done” to “try it”

Back to that corner: merging without clicking through the feature yourself. Usually not laziness. It’s that trying it is simply harder than it should be. That’s a CI/CD problem, not a discipline problem.

Agents write a feature in minutes. Well-configured gates prove the minimum bar minutes later. Then it reaches a person – and everything stops. To see it: check out the branch, install dependencies, dig up tokens, run migrations, seed data, hope your local setup matches. Local AI tools and skills take away some of the grind, but: context switch. Minutes to hours. A reason to skip it.

That’s where the speed quietly leaks out. Automating the writing gains you nothing if validating stays the bottleneck. Good gates say: “the change is sound.” They can’t say: “it’s right – for your team, for your users.” If the check is expensive, it gets skipped. And the cut corner becomes the process.

Writing a feature in minutes doesn’t make you fast if trying it eats an afternoon.

So: make trying it the cheapest step. Every change gets its own environment, built by the pipeline:

• A link for every change – or an installable build for apps, desktop, CLIs
• Its own data: migrations applied, realistic seed data, test accounts ready
• Secrets & integrations already wired in – nobody passes tokens around
• The same gates & config as prod – just disposable
• Automatic teardown on merge or close
• A notification when it’s ready – not a dashboard you have to watch

Then the loop closes the way it should. Agent done, gates green, you get a ping. Click the link or download the build. Use it like a user. Poke at the edge cases. Decide – ship it, or hand the next steps and focus points back to the agents. Minutes. Not an afternoon. That’s “fast with confidence”: not just fast output. Fast, cheap, honest validation.

10Why AI gets clunky in enterprise workflows

Most large orgs adopt AI the same way: take the existing process – tickets, handoffs, approvals, sprint ceremonies – and give every step an assistant. Feels safe. Demos well. But: the process was designed around human bottlenecks. A system only moves as fast as its slowest gate.

Speeding up single steps in a process built for humans mostly makes the queues longer. The work gets faster. The outcome doesn’t.

My expectation: most companies that go about it this way will struggle to show meaningful improvement. They’ll see islands of productivity, lots of licences, and a delivery speed that looks suspiciously like last year’s. Not because the models aren’t good enough – but because the org was never redesigned to use them.

11Shared memory, different perspectives

Two of those frictions – context in heads, tools built for people – aren’t process problems. They’re infrastructure problems. With infrastructure answers. The first one: memory.

Personal project? Memory is simple: start Claude Code, turn memory on, and it gradually learns the codebase, the conventions, your preferences. One person, one repo – that’s enough.

In an org, that model breaks. Every agent starts from zero. Its own repo. Its own sandbox. Its own session. The agent in the payments service doesn’t know what the checkout team decided last week. The agent in the mobile app doesn’t know the API it calls is being retired. Nobody remembers why two products share a login. Every agent: locally correct, globally lost.

So memory has to become shared infrastructure: available to every agent, at every step, across products & microservices. Product principles. Architecture. Contracts between services. Decisions and their why. Vocabulary. Known pitfalls. So that even an agent in an isolated repo or environment knows: other products exist. What they expect. How it all holds together. The missing piece most multi-repo orgs never had – not even for their people.

And it has to be orchestratable by people. Memory is where people steer at scale: correct a wrong assumption once → every agent stops making it. Shift a priority → every agent sees it. Meaning: owned, reviewable, versioned. Not a heap of chat transcripts nobody can edit.

The key: agents with perspectives. They all read the same memory. But each one focuses on a different aspect. One refines the goalpost. One owns acceptance. One judges usability. One guards the seams. Same facts, different lenses. When they disagree → it surfaces early, in the open, where a person can settle it – instead of late, in prod.

12Guardrails: your taste, written down

Agents can do a lot – which is exactly why they need to know what NOT to do. Every product has its own taste in do’s and don’ts: patterns you use, and ones you’ve banned. Libraries you trust. How errors are handled. What never goes into a log. Which data never leaves a region. How the interface talks to people. When to ask instead of guess.

Those rules deserve the same treatment as your CI/CD tooling: written down. Versioned. Reviewed. Applied everywhere automatically. But with one big difference: lint config = set once, rarely touched. Guardrails live with the product – they change as it matures, as the team learns, as the market and regulation move. They need an owner, a history and a place in the regular conversation.

That last row matters more than it looks. Guardrails should not be exclusive to agents. Written well, they’re the clearest statement of how your team builds – and they hold just as well in a developer’s head. The same page that stops an agent from adding yet another state library reminds a new hire why you don’t – and gives a reviewer something better than “I don’t like it.”

If a rule only lives in a prompt, it isn’t a guardrail – it’s a secret.

Which brings us to the step most orgs miss: the right infrastructure for the architecture. When every team wires up its own agents, every repo ends up with its own copy of the guardrails, its own MCP servers, its own keys, its own idea of what’s “allowed” – drifting apart from day one. Put the shared pieces in one place: one gateway in front of inference (or a proxy in front of it) that every agent and every developer tool goes through.

That’s where guardrails get applied. That’s where memory gets served. That’s where MCP servers are shared instead of re-implemented in every repo. That’s where access, audit, cost and model choice are managed once. Change a guardrail once → every agent picks it up on its next request. That’s not overhead. That’s what makes 100 agents behave like one team.

13What works instead

Teams that pull off step changes don’t add AI to their workflow – they rebuild the workflow so that people, agents and gates each do what they’re best at.

1. Define intent & acceptance criteria upfront – clear enough that an agent knows when it’s done.
2. Invest in gates before the agents arrive: strict linting, types, tests, CodeQL/Sonar, preview builds on every change.
3. Let tools fix what they can before anything is committed – formatting, whitespace, import/key order – so CI never fails on style and nobody reviews it.
4. Make memory shared infrastructure: principles, architecture, contracts and decisions available to every agent at every step – curated & correctable by people.
5. Write guardrails down like config, but keep them alive – owned, versioned, shared with developers, served from one gateway together with memory & MCP servers.
6. Give agents real, scoped environments – safe to run unattended, easy to throw away.
7. Give every change a preview – a link or installable build, with data & secrets wired in – and a ping when it’s ready, so human review moves from the diff to the product.
8. Small teams & end-to-end ownership – so the loop from idea to shipped doesn’t splinter across handoffs.
9. Measure outcomes, not output: protect time for reflection, watching real users, comparing options side by side – that’s where good becomes great.
10. Start small, end to end: one product, one team, one value stream redesigned properly beats AI sprinkled across 100 unchanged processes.

The more work agents take on, the more the human part – taste, judgement, empathy for the people using the thing, and accountability when it ships – becomes the actual job.

14In practice: the staff engineer

Look, I’m sitting here watching what’s happening in the teams around me right now. And honestly? A year ago I’d have called half of it science fiction.

There’s this senior developer at a mid-sized company near Frankfurt. Last year he was still lead developer. Today? He’s “demoted” himself – officially just “staff engineer” now. No team, no people management, no more sprint plannings to moderate. And he earns considerably more than before. Because he’s finally doing what he’s actually paid for: making architecture decisions. Translating product vision into technical reality. Being experienced enough to say, “This will fail in six months, because …” – and then letting the agents work out the details while he’s already on the next lever.

The guy barely types code anymore. He thinks code. And the agents? They type. In parallel. Ten files at once. Tests included. Documentation along with it. He only reviews the places where experience makes the difference: interfaces between services. Data models that have to survive. The one abstraction that either carries everything or breaks everything.

The three roles weren’t decided in a meeting. They just happened.

Human – intent. Not “writing user stories”. Standing at the whiteboard with the product owner and arguing: “Do we build this now, or do we first pull the technical debt out of the payment module? Because if we don’t, the next feature request blocks us for three months.” The stakeholder wants everything yesterday. The human translates: “Okay, we deliver feature X in two weeks – but only if we do the refactor in the auth service at the same time. Agent, plan that out.”

Agent – build. It gets the brief: “Refactor the auth service and feature X in parallel. Here are the constraints: no breaking changes to the API. Tests must stay green. The migration must be rollback-safe.” And the agent? Starts immediately. Not after sprint start. Not after ticket refinement. Immediately. It writes the migration plan. It writes the tests for the new code before the new code exists. It tries three variants – one with event sourcing, one classic, one hybrid – and puts three PRs in front of the human at 8:30 in the morning: “Option A: safer, two weeks. Option B: faster, technical risk here. Option C: cleanest architecture, but three more days of work.”

Gates – pass/fail. The gates? They don’t sleep. They check every variant. Types, lint, unit, integration, E2E, CodeQL, Sonar, bundle size, a11y. Variant B drops out – the security scan finds something. Variants A and C pass. The human clicks through the previews (built automatically, with real data, real secrets, real everything), tries the edge cases, nods at option C: “Take that one. Merge. Ship.”

While he’s deciding, the agents have long started preparing the next thing. Because they have the context. Because they share the memory. Because they know: “Ah, the auth refactor is through – so now I can cleanly wire in the feature flag for the new payment method.”

15What this does to roles

The crazy part: this is already happening. Today. In real companies.

Not in demos. Not in side projects. In production systems that make money.

The regular devs? Many are leaving. Not because they’re bad – because they can only code. And coding is now the cheapest activity in the whole stack. Whoever “just” works through tickets gets replaced. Not by AI – by one senior + agents, getting ten times as much done.

The ones who stay? They become more valuable. Much more valuable. Because their expertise suddenly scales. An architect who used to look after three teams now looks after fifteen – because the agents do the legwork juniors used to do. And the juniors? There are hardly any left. At least not in the classic sense. The junior role is shifting: whoever starts out today doesn’t learn “how do I write a function?” – they learn “how do I phrase intent precisely enough that the agent builds the right thing?” and “how do I tell whether the result is actually good?”

16People still work with people

But – and this is the part all those “AI replaces programmers” articles never get – people still work primarily with people.

Feature prioritisation? An agent can generate a list of 200 tasks for you, neatly estimated, with dependencies, risks and impact scores. Impressive. But which of them do we build now? A human negotiates that with stakeholders. That’s politics. That’s trust. That’s: “Customer X threatens to leave if we don’t deliver feature Y next month – but if we build Y, we break Z for customer A, our biggest source of revenue. What do we do?”

No agent decides that. No agent should decide that.

What the agent can do is tell you: “If we build Y, we break Z here and here – here are the affected tests, here’s the migration effort, here are three options to save Z. Option 1 costs two weeks. Option 2 costs three days, but we need a feature flag. Option 3: we tell customer A they have to migrate – here’s the migration guide I’ve already prepared.”

The human decides. In minutes. Not in two weeks of architecture review meetings.

17Refactor first – with numbers, not gut feeling

Refactoring before a new feature? It used to be: “We’ll do it later. Create a Jira ticket. Forget about it.” Today, the agent analyses the codebase, finds the hotspots and simulates the impact: “If we build feature X without the refactor, the change failure rate in the payment module goes up by 34%. The refactor costs 4 agent-days. Feature X alone, 6 days. Feature X with the refactor, 8 days – but after that, the next feature is 40% faster.” The human looks at the numbers. Nods. “Do the refactor first. I’ll tell the PO feature X comes two days later, but the next three features go faster.”

And while the human explains that to the PO, the agent has already started the refactor. Not “planned” it. Started. Branches created. Tests written. First commits pushed. CI running. Previews ready.

18Not the future: last Tuesday

This isn’t some distant future. It happened last Tuesday. In a team I know. Five people. Two seniors, one mid, two “agent orchestrators” – a new role with its own salary band. They shipped in one week what used to take them six. With better code quality. Because the gates don’t get tired. Because the agents don’t do “quick, quick” but “right, right” – because a human told them what “right” looks like.

And the best part? The senior developers go home happy again. Not because they work less – because they work on the right things. Architecture. Product. Mentoring. The decisions that need experience. The typing? The agents handle it. While the human drinks coffee and argues with the product owner.

The companies that get this? They’re hiring right now. Not “developers”. Architects with agent fleets. And they pay them accordingly.

The companies still “integrating AI assistants into Jira”? Next year they’ll be asking why their velocity didn’t go up – while their best people quit, because somewhere else they’re paid considerably better for exactly the work they actually trained for.

19The new seniority

Up there, it was all YAML configs. Lefthook setups. Gateway architectures for shared memory. Guardrails as code. Preview pipelines that post a clickable link for every PR in Slack.

But honestly? Those are just tools. The real game happens between your ears. And in the conversations at the whiteboard. And in the question you ask yourself every morning:

What’s the lever today that only I can move – and how do I get the agents to build the rest?

That’s the new seniority. Not “I code the fastest”. But: “I know what needs to be built – and I have the army that builds it while I’m already looking for the next lever.”

That’s exactly why I design and build this way.