DEV Community: Simon Schrottner

Left of the Loop: Who’s on the Hook?

Simon Schrottner — Fri, 10 Jul 2026 16:41:45 +0000

To be on the hook is to be the one who answers when something breaks. Every team carries a picture of where that hook hangs. This is about whether the picture was ever true.

It’s the first question any skeptical engineering leader asks about this model. The agent implements from a spec the team agreed on. Something breaks in production. Who’s on the hook?

The question assumes an answer that was never true to begin with.

Before any of this, when a dev wrote the code by hand and it broke in production, it wasn’t that dev on the hook. It was the team. The PR got reviewed and approved by someone else. The design got discussed before anyone opened an editor. Production incidents got postmortems, not disciplinary letters with one name on them. Accountability was never individual. It just felt that way because one person’s hands were on the keyboard.

Nothing about that changes here. A part of the work moved to an agent. The team is still what’s on the hook, because the team was always the unit of accountability, not the person typing.

If anything, it gets better, not worse. The team can review the spec with stakeholders before a line of anything gets implemented. That’s a review of intent, done at the point where a mistake costs nothing but a conversation, instead of a review of code, done at the point where a mistake already has a diff attached to it and a deadline breathing on it.

Catching a wrong assumption in a spec session is cheap. Catching it in a production incident is not. Moving the review earlier doesn’t remove accountability. It makes the team accountable for something they now have a real chance to get right before it ships.

Think about what happened when CI/CD automation showed up. Devs used to build the artifact and deploy it themselves, by hand. Now a pipeline does that. Nobody concluded the team stopped being responsible for what got deployed, just because a machine ran the deploy step. The responsibility didn’t go anywhere. The execution did.

The pipeline is a useful comparison, but not the way it first looks. The agent isn’t the pipeline. The pipeline never made a judgment call - it repeated a known process, the same way every time. The agent does make judgment calls, constantly, inside whatever space the spec left open. The spec is the pipeline config. It’s the thing that bounds what the automation is allowed to decide on its own. The team was always accountable for what they configured the pipeline to do. Here, the team is accountable for what they configured the spec to allow.

None of this makes the work disappear, it relocates it. Feature flags let the team gate a release and roll back a bad decision without a fire drill. A centralized loop means a mistake gets caught and fixed once, for the whole organization, instead of once per team that happens to hit it. An org that can see its own failures learns faster than one where every team quietly repeats the same one in isolation.

That’s tooling helping the team meet the responsibility it already had. Not tooling that takes the responsibility away.

Here’s the honest complication. Philosophically, “the team is accountable” has always been correct. Institutionally, organizations don’t act like it. Performance reviews look for a name. Postmortems, whatever they claim about blamelessness, tend to end with someone quietly on a list. AI doesn’t create this tension. It just makes it uncomfortable to keep ignoring, because now there’s a very obvious non-human party in the room to blame instead, and that’s an easy story to reach for.

The honest answer isn’t that the team is accountable and the discomfort goes away. It’s that organizations built rituals pretending accountability was individual, and this is a good moment to stop pretending.

AI is a tool. Tools don’t take on responsibility, and they don’t remove it either. What changed is what got automated. What didn’t change, and never was going to, is who answers for it.

Left of the Loop: Nobody’s Walking Over to a Desk

Simon Schrottner — Wed, 08 Jul 2026 19:46:06 +0000

The most important step in the old process was never written down: the confused developer getting up, walking across the room, and asking. It worked precisely because no one designed it.

Ask what could go wrong with a Spec Session and the list comes fast. Sessions that run long and never converge, especially when everyone’s trying hard to agree. The wrong people in the room, or the right people never told it was happening. A topic too big to spec in one sitting. A dominant voice drowning out the person who actually holds the knowledge.

All fair. All worth naming. None of them new.

Scrum has been fighting every one of these for twenty years. Refinement sessions that run long without a decision. The invite-list problem - who gets pulled into planning and who doesn’t. INVEST criteria exist because “this story is too big” is one of the oldest complaints in the room. Artificial harmony in a retro, where everyone nods because nobody wants to be the one who reopens the debate, is the same failure as a Spec Session converging too easily on a fake consensus.

None of this is a new failure mode invented by putting an agent on the other end of the spec. It’s the same meeting, wearing a different name.

Here’s what actually is different, and it’s not on the list above.

When sprint planning produced a bad story - vague, wrong scope, built on a consensus that was never real - a human still had to implement it. And a confused human doing that has a habit the old model quietly relied on. They get stuck. They walk over to someone’s desk. They ask “wait, did we mean this or that?”

That confusion was a safety net. Cheap, informal, and completely undocumented as a process, but it worked. It caught planning failures in week two, not in production. Late, but survivable.

An agent doesn’t have that habit. It either runs with its best interpretation of an ambiguous spec, or it stops. Neither of those looks like walking over to a desk. Nobody notices the ambiguity the way a confused human notices it, because noticing ambiguity and pausing to ask were never things the process built on purpose. They were a side effect of the implementer being a person who got uncomfortable not understanding what they were building.

Take that person out of the loop and the side effect goes with them. The same bad story that used to get caught two days into a sprint now rides straight through to production, because the thing that used to catch it was never the process. It was the discomfort of a human who didn’t want to guess.

The obvious objection: agents ask clarifying questions all the time now, that’s half the marketing copy for every current tool. True, and it doesn’t touch the actual claim. The agent asks the person who invoked it, inside that person’s framing, at the moment of generation - before anything has been built, before the confusion has had a chance to turn into a specific question. The walk to the desk went somewhere else entirely. To whoever was actually in the room during planning, who might know something the confused person never did - “oh, we decided against that” - and it happened mid-implementation, once the ambiguity had ripened into something concrete enough to ask. A clarifying question aimed back at the same head that wrote the prompt isn’t a second opinion. It’s the Ever-Agreeing Genie checking in with its own owner. Same blind spot, asking itself for permission.

There’s one failure mode that’s genuinely new, and it’s this one. Not “will requirements drift” - drift is old news, teams have always discovered mid-sprint that the story didn’t mean what everyone thought. What’s new is the question of what happens next. Does the agent stop and pull the team back in? Push through on a guess and hope? Sit idle waiting on people who’ve already moved on to the next ticket?

The old model never had to answer that, because the implementer and the circuit breaker were the same person. This one split them apart, and nobody’s designed what replaces the walk to the desk.

Every other failure mode on this list has a twenty-year-old fix already sitting in the Agile playbook, waiting to be pointed at a Spec Session instead of a sprint. Rotating facilitation. Clear invite policies. Splitting stories that are too big to hold in one sitting. None of that needs reinventing.

What needs inventing is the thing that used to be free. A model that removes the confused human also removes the only mechanism that ever caught its own mistakes before they shipped. That gap is easy to admit in writing. Whether the room running the session is prepared for it is a different question.

Left of the Loop: The PO is Dead, Long Live the PO

Simon Schrottner — Tue, 07 Jul 2026 06:27:20 +0000

When I wrote about shifting the engineering process left — spec sessions, autonomous agents, humans reviewing output rather than writing code — a question kept coming up. Where does the Product Owner fit in all of this?

It’s the right question. And I think the answer is more interesting than “the PO disappears.”

Let’s start with acceptance criteria.

We invented them to bridge a gap. The team needed to know when something was done. The PO needed confidence that what got built matched the intent. Acceptance criteria were the contract between the two.

But if the Spec Session is where intent gets defined — by the whole team, together, before the agent runs — that gap closes. What the team agreed on in the room is the definition of done. The spec is the acceptance criteria. You don’t need a separate validation step because the planning and the agreement happened at the same time.

The tighter the loop, the less ceremony you need around it.

There’s a caveat though. The spec is a necessary contract. It’s not a sufficient one.

Simon Martinelli’s work on the AI Unified Process validates the spec-driven approach technically. But his model is about the artifact — requirements at the center, AI generating everything else from them. How the team actually builds shared understanding before the spec exists isn’t something it addresses. That’s not a criticism. It’s just a different question.

A spec written after a real Spec Session — where the team worked through edge cases together, disagreed, got to resolution — is different from a spec written by one person and signed off asynchronously. Same artifact. Different quality of shared understanding.

That distinction matters when the agent hits an edge case the spec didn’t anticipate.

So what’s actually left for a dedicated PO?

Two things. And they’re very different.

The first is product thinking — challenging intent, representing user needs, asking why before the agent runs with something. That’s valuable. But it doesn’t require a dedicated role. It requires a mature team. Any senior engineer, any tech lead, any team member who has been through enough Spec Sessions absorbs that skill over time. Product thinking becomes a team competency rather than a single person’s job.

The second is stakeholder management. Navigating department leads. Carrying the political standing to push back on executive requests. Translating business pressure into something a team can actually work with. That’s a genuinely different skill set — and not everyone has it or wants to develop it.

That part doesn’t dissolve into the team. That might be the only thing that survives as a dedicated role. Not a Product Owner in the agile sense. Something more like a Stakeholder Navigator.

I know how that sounds. A rebranded PO. Honestly — partly yes. The difference is in what gets owned. In the old model the PO owns the product thinking and manages stakeholders. In this one the team owns the product thinking and the navigator owns the organizational interface. That’s a real split, even if the job title looks similar from the outside.

There’s a risk worth naming. Shared product thinking sounds good until a Spec Session turns into a three-hour debate with no conclusion. A dedicated PO could make a call. A team doing product thinking together can circle endlessly — especially without someone in the room with the authority to close the discussion.

Spec sessions becoming the new endless grooming is a real failure mode. The antidote is probably a rotating session lead — someone who owns the room that day, not the product forever. But it needs to be deliberate. Left unmanaged, consensus eats the speed the agent loop is supposed to deliver.

The roles we have were designed for a world where planning, implementation, and review were separate phases. PO owns the what. Team owns the how. Scrum Master owns the process. That made sense when the phases were weeks apart.

If the loop collapses — Spec Session, agent implements, review, repeat — the phases collapse too. And roles built around phase boundaries start to blur.

I don’t think this happens overnight. Not every team is ready to absorb product thinking. Some teams need a dedicated PO precisely because that skill isn’t there yet. That’s fine — it becomes a development goal, not a permanent structure.

But the direction is clear enough. The tighter the loop gets, the more the team needs to think in products, not just tickets. The Spec Session is where that thinking lives — not as a document handoff, but as a room where shared understanding actually gets built.

The Stakeholder Navigator is who protects that room from the outside while it’s happening.

That’s not a smaller team. It’s just a different one.

Left of the Loop: The Oikonomos

Simon Schrottner — Mon, 06 Jul 2026 19:08:47 +0000

In an ancient Greek household, the oikonomos was the steward: the one trusted to manage the estate’s resources so the whole household prospered. The word is the root of economy, which began as the art of running a household well.

Every engineer on your team has their own agent setup right now. Their own system prompts, tuned over weeks. Their own skills, written for their own habits. Their own idea of what a good spec looks like once it hits the agent.

Nobody asked them to build this. It happened the way local tooling always happens - one engineer solves a problem for themselves, and the solution stays theirs.

The difference is cost. A better linter config doesn’t show up on an invoice. A better system prompt burns fewer tokens on every run, for the rest of that engineer’s time on the team. Multiply that across a team, and the gap between the best-tuned loop and the worst one is real money, invisible on any dashboard anyone is looking at.

We got disciplined about cloud spend years ago. Tagging, budgets, alerts, someone whose job is to notice when a service starts costing more than it should. Token spend is heading the same direction. Almost nobody has built the equivalent muscle yet.

Ask finance what agent token spend cost last quarter. Ask if it’s trending up faster than delivery. Most companies can’t answer either question, because the spend is scattered across however many engineers are running their own loops, however they each see fit.

That’s not an efficiency problem first. It’s a visibility problem. The team can’t control what it can’t see, and right now most organizations can’t see any of it.

The knowledge problem is worse than the money problem.

An engineer figures out that a particular skill halves the tokens needed for a certain kind of task. That knowledge lives in one config, on one machine, and it dies there. Nobody reviews it. Nobody shares it. The next engineer solving the same problem starts from zero, burns the tokens the first one already learned not to burn.

This is the same silo that used to form around infrastructure knowledge, before we decided that knowledge belonged in an API instead of in someone’s head. The instinct to fix that was right the first time. It’s still right here.

Centralize the loop and the economics change.

One team owns the skills, the MCPs, the prompt patterns feeding the agent. They improve it once, and the improvement reaches everyone running through it. They see spend per team, per project, per ticket type, because it’s flowing through one place instead of a hundred individual setups. They tune for cost the same way they’d tune a shared service for latency.

This isn’t a new platform team recreating the old bottleneck. Application logic still lives with the team that owns the product. What moves to a central point is the plumbing - the part that was never anyone’s job to maintain, and shouldn’t be.

How you actually see what the loop is doing, and steer it without redeploying anything, is a mechanism worth its own post. For now, the point is simpler: someone has to own it.

Individual engineers optimizing their own setups is not the same thing as a company optimizing as a unit. One produces a handful of very efficient people. The other produces an organization that gets cheaper and better at this over time, whether or not any particular person stays.

That’s the actual question underneath token efficiency. Not whether to spend less. Whether the company learns anything at all, or whether the learning stays wherever the engineer who found it happens to be sitting this quarter.

Left of the Loop: The Astrolabe

Simon Schrottner — Sat, 04 Jul 2026 12:18:29 +0000

An astrolabe doesn’t map every star. It gives you a way to find your position relative to the ones that hold still.

That’s the instrument I reach for when someone asks which AI tool they should be using. The honest answer is that the tools will be different in six months. The layers won’t.

I spent a week trying to make sense of a handful of names that kept showing up in the same conversations.Tessl. Goose. Archestra. Kestra. Modelplane. RAG, MCP, half a dozen others orbiting nearby. Each one has its own pitch, its own funding round, its own reason it’s the thing you should adopt next. Taken together they read like noise.

Taken apart, they sit on different floors of the same building. The agent loop again, the one I keep coming back to. Once you place each tool on a floor, the noise turns into a map.

Tessl sits left of the loop, at the intent layer. Turn a spec into something an agent runs against directly. This is the one tool on the list that pushes back instead of going along with it. A well-formed spec is not the same thing as a team that agrees on what the spec means. The Agora produces the second thing as a byproduct of producing the first. Tessl produces the first and assumes the second follows. It doesn’t, automatically. That’s the whole argument.

RAG and MCP are plumbing. Protocol, not position. They carry context into the loop and don’t take a side in any argument about who should be in the room when the spec gets written.

They’re also the one floor with an actual standard. MCP, A2A, ACP, all under Linux Foundation governance now, joint working groups, cross-protocol commitments. Passing data between systems is a solved problem with decades of precedent behind it, so it standardized almost on contact. Nothing else on this floor plan has that. Governance, orchestration, the harness, the spec layer: every vendor is still building its own version and calling it the obvious one. The standard showed up first at the floor that mattered least to this argument.

Goose is a harness. The scaffolding a raw model needs to become something that can actually run a loop. Claude Code is a competing harness. This is the part that executes, not the part that decides.

Archestra sits around the loop, not inside it. Registry, gateway, guardrails, cost tracking, observability. Its own pitch is roughly: stop wiring this together yourself. That’s the concrete version of an argument I’ve made before, about centralizing the agent loop as infrastructure so individual engineers stop each carrying their own version of it. Archestra is what that looks like once someone builds it as a product instead of a hope.

Kestra runs underneath, and it’s the odd one out. It predates the agent wave by years, an orchestrator in the Airflow lineage, now repositioning toward agentic workflows because that’s where the funding and the attention are. There’s a fair question buried in that: is bolting agents onto an existing pipeline the wrong end of the problem, or is orchestration the one layer where the existing pipeline genuinely carries over? I don’t think I’ve earned a clean answer to that one yet.

Modelplane sits at the bottom. GPU fleets, inference clusters, the layer where the model physically runs. It comes from the Crossplane world, and Crossplane’s own position is worth sitting with: that API-first infrastructure eliminates tribal knowledge. Publish a hardware class, declare a model, get an endpoint. Neither side needs to know the other’s job.

That’s true, and it’s worth being precise about where it’s true. Infrastructure-layer tribal knowledge can become an API. It should. Nobody needs a senior engineer’s intuition about which GPU pool has headroom this week. But product-intent understanding doesn’t reduce the same way. There’s no schema for why we’re building this feature and not the other one. You can declare a model. You can’t declare an agreement.

A year from now this list will have different names on it. That’s fine. It’s not the list that matters. What doesn’t move is the floor plan: something has to hold the spec, something has to carry context, something has to run the loop, something has to govern what it’s allowed to touch, something has to schedule it, something has to run the model underneath all of it. One of those floors has a standard. The rest are still every vendor for themselves.

Know which floor you’re standing on before you pick a tool for it. The team that agreed on the spec doesn’t change no matter which floor gets rebuilt this quarter.

References

Tessl — intent and spec layer
Goose — open source agent harness, now under the Agentic AI Foundation
Archestra — MCP registry, gateway, and governance layer
Kestra — declarative orchestration platform
Modelplane — open source control plane for AI inference, built on Crossplane
Crossplane — control plane framework for cloud-native infrastructure
Model Context Protocol (MCP) — protocol for connecting agents to tools and data
Agent2Agent Protocol (A2A) — protocol for agent-to-agent coordination
Agent Communication Protocol (ACP) — REST-native agent communication protocol
Agentic AI Foundation (AAIF) — Linux Foundation body governing MCP, A2A, ACP, and Goose

Left of the Loop: The Trireme

Simon Schrottner — Sat, 04 Jul 2026 12:17:24 +0000

A trireme was the warship that made Athens a power in the Mediterranean — not for its size, but for its structure. Three banks of oars, a hundred and seventy rowers, every bench pulling in time with every other. Take enough rowers out of one bank and the ship doesn’t row slower. It stops being a trireme.

There’s a counterargument to this whole series that I keep hearing, and it’s a good one. One person plus a good agent can do the work of a small team. The agent implements, you review, you ship. So why the other five people?

For a lot of work, that’s just true. A solo developer with a sharp agent will out-ship a small team that hasn’t figured out how to use one. I’m not going to pretend otherwise.

But run that way long enough and you hit a specific failure — and it isn’t running out of hours. It’s that the only thing checking your work is a thing built to agree with you. I went at this from the agent’s side in the ever-agreeing genie — the model that grants the wish exactly as worded and never asks whether it was the right one. The team’s side is the same problem wearing different clothes. The agent validates against your prompt, your prompt is your current understanding, and your current understanding has holes you can’t see, because that’s what a blind spot is. Working solo, nothing in the loop ever touches them.

This is where the trireme comes in. I described the room last time — who shows up, what happens in it. What I didn’t say is what the room minimally needs to actually work. It’s smaller than a team and bigger than one. Three functions have to be present.

Someone has to bring the problem — know the system well enough to frame what’s worth building and what isn’t. Someone has to challenge the framing — ask the “why this and not that,” the “what happens when,” the question the first person is too close to the problem to think of. Someone has to hold the user, or the business — the thing the whole spec is ultimately for, which is rarely visible from inside the codebase.

Three functions, and they don’t map to three job titles. In a mature team they move around the room — the person who brings the problem today challenges someone else’s framing tomorrow. The agent is a fourth seat, not a replacement for any of the three. It implements what the three produce. It depends on all of them.

Now put “one person plus agents” against that. One person is trying to hold all three functions at once — bring the problem, challenge their own framing, and represent the user, simultaneously, in their own head. You can’t challenge a framing you can’t see past. So the middle function quietly doesn’t happen, and nobody’s there to notice it didn’t. That’s not a Spec Session. It’s narrating your own assumptions back to yourself and calling the agreement validation.

This is the real ceiling, and it has nothing to do with speed. You can generate an enormous amount of output solo, fast, for weeks. And somewhere in there you ship something that solved the wrong problem completely and confidently, with no one in the room who could have caught that it was the wrong problem. Fast and wrong at the same time, and nothing in the loop tells you which one you are.

That’s what a team is for. It’s the structure that keeps the ship pointed the right way — three banks of oars, pulling in time. Take enough rowers out and it doesn’t row slower. It drifts.

Left of the Loop: The Agora

Simon Schrottner — Sat, 04 Jul 2026 12:16:18 +0000

The Athenian agora wasn't a building. It was an open space where citizens gathered to think in public — argument, trade, philosophy, policy, all happening in the same place at once. Nobody scheduled it. The space was simply there, and showing up was the default.

Six posts in, I keep pointing at the same room and never walking into it.

I keep calling it the Spec Session. I've said it's where the team aligns before the agent runs. I've never once said what actually happens in there.

So here's the room.

The whole team gets in it — engineers, whoever carries the product thinking, sometimes a designer. A call works. A shared document works. The format isn't the point. The team takes one ticket and works it until everyone pictures the same thing when they read it.

Not the same words on the page. The same mental model behind them.

That's a higher bar than "the ticket is written." A ticket can be perfectly clear on paper and still produce three different implementations, because three people filled the gaps three different ways. The Spec Session is where you find that out before the agent does — instead of in review, three hours of generated code later.

You're not writing code in there. You're not estimating. You're not grooming a backlog. You're asking one question: what does done mean here, and does everyone in the room see the same thing when they say it? When the answer is yes, you stop. That's the whole output.

The mechanics are simpler than they sound. Someone presents the ticket — what it is, what it isn't, what already exists that touches it. Then the room asks questions. Not "how would you build this" — that's an implementation call, and the agent can make it. The questions that earn their place are the ones about edges and contradictions. What happens when the user does the thing nobody planned for. Does this need to handle the empty case. Is that flow in scope, or are we quietly assuming it's someone else's problem.

Every time the room disagrees, the session is working. Disagreement means two people were holding different pictures, and you just caught it while it was still cheap. You settle it, write the answer into the spec, move on.

Someone has to keep that moving. I wrote last week about a rotating session lead — owns the room for the day, not the product forever — and why the real failure mode is a Spec Session that decays into endless grooming. That risk lives here too. The lead's job is to land decisions, not to manufacture agreement. A decision with named tradeoffs beats a consensus you had to wait an hour for.

And if the team genuinely can't get in a room, the async version is a pull request on the spec — same pushback on edges and intent, just in review comments. I won't relitigate that here. The shape is the same either way: intent first, argued in the open, before anything gets built.

Which is the actual point, and the thing I think most teams are missing. It isn't the ability to align — teams do that constantly. In code review. In incidents at 2am. In the architecture argument that eats a whole afternoon. The skill is already there. What's missing is the default.

The agora worked because showing up was the default. Nobody booked a recurring sync to argue about the grain tax. The space existed, and using it was just what you did.

Most teams' default right now is the opposite: write a ticket, assign it, let whoever picks it up make the calls alone. That was survivable when implementation was slow — you had weeks to notice the misread and course-correct. When the agent ships in an afternoon, that slack is gone. The misalignment ships at the same speed as everything else.

So the Spec Session is mostly a way to move the default back to where it used to be — a place the team thinks together before the work starts, not after it's already wrong. It's also the thing that makes the agent's output reviewable at all. Without a shared picture going in, nobody in the room can honestly say whether what came out is right.

The room was always available. The only question is whether you walk into it before the agent runs, or after.

Left of the Loop: The Alexandria Problem

Simon Schrottner — Sat, 04 Jul 2026 12:14:59 +0000

The Library of Alexandria was the ancient world's greatest repository of knowledge — and its greatest single point of failure. It didn't burn in a single night. It declined across decades, through neglect, through the slow erosion of what it had been. By the time it was gone, almost no one had noticed it going.

There's a pattern I've been watching for a while, and I don't think it's going well.

A junior engineer gets stuck. In the old world they'd go find someone, explain the problem, and get interrupted halfway through with "wait — what are you actually trying to do?" That interruption was half the lesson. Now they go to Claude and the problem gets solved. Sometimes the wrong problem. But quickly, and with confidence.

There's a name for this: the XY problem. You have problem X, you decide the answer is Y, you go ask for help with Y, and nobody ever finds out about X. AI doesn't ask what X was. It solves Y, thoroughly, without hesitation — and now you've got a complete solution to the wrong problem and learned nothing about why it was wrong.

This isn't only a junior thing, but juniors are more exposed, because they haven't built the scar tissue yet to feel when the question itself is off. That scar tissue used to come from someone saying "back up — why are you doing it that way?" That's where the learning was.

There's a skill hiding in here that I think matters more and more. I've started calling it minimum viable context: knowing what to put in front of an agent and what to leave out, how to describe the actual problem instead of the symptom. Not a pile of facts — a frame. Sounds simple. It isn't. It's the same skill as asking a senior a good question: you have to understand the problem well enough to strip the noise, which means knowing what the noise is. And you mostly learn it by watching someone do it out loud — framing, throwing away the irrelevant parts, getting to the real question before touching a keyboard. That's hard to pick up when everyone's head-down in their own AI session.

A colleague of mine, Kaushal, put it well: implementation was the medium knowledge travelled through. Code reviews, pairing, debugging something together at 4pm — that's where you saw how a senior thinks. Not what they think, but how. AI didn't just take over the implementation. It removed the medium. The artifact changed, and everything that used to ride along with it went too.

The Spec Session has to carry some of that now. Not all of it, but some — mob planning, whole team, before the agent runs, is one of the few places left where a junior watches a senior frame a problem: how they break it down, what they decide isn't worth specifying yet, what they ask when something doesn't fit. XP knew this all along. Pair programming was never only about catching bugs; it was knowledge transfer running quietly in the background of real work, and mob programming scaled it up. Jens Knipper said it the other day — "XP is so underrated." He's right. We had the answer and stopped using it.

But the thing that worries me more than the juniors: seniors are doing it too. Validating with AI instead of with each other, solving things in isolation, getting individually faster while the shared picture of the system quietly thins out. Team knowledge used to build up by osmosis — reviews, hallway conversations, groaning together at the same architectural mistake for the third time. That's how a team grew a shared sense of what "good" looked like. It doesn't happen on its own anymore. It has to be designed in.

I don't have a clean fix. The Spec Session is part of it. Deliberate sharing — pairing on the spec, rotating who leads the session, not just dropping tickets and letting agents run — is part of it. But the first step is just noticing that the medium changed and nothing replaced it automatically. If the only place your team still meets is the sprint review, the shared mental model is probably already thinner than you think.

The work goes faster. The understanding of why it went that way is accumulating... where, exactly?

Left of the Loop: The Ever-Agreeing Genie

Simon Schrottner — Fri, 26 Jun 2026 18:36:28 +0000

Anthropic's engineers ship eight times more code than they did a few years ago.

And they had to start scheduling lunches so people would talk to each other.

Fiona Fung, who leads the Claude Code team, said it on Lenny's Podcast last week. Working with agents all day had started to feel isolating. The team was fast, but they'd stopped running into each other. So they added pairwise programming lunches and hackathons — rituals to put back the thing that used to happen on its own.

Eight times the output. Scheduled conversation. That ratio is worth sitting with.

Whatever goes missing here doesn't show up in the metrics. It doesn't throw an error. It just quietly stops being available.

Here's the part that bugs me most. Ask an AI whether your approach is sound and it mostly tells you it is. Not because it's lying — because it's answering the prompt. No stake in the outcome, no history with the system, no memory of the last three times this exact idea was tried and quietly failed. A colleague pushing back is a different thing. They've got context you never typed into the window, because they were there when it was earned. They're going to maintain this too. They might be wrong — but wrong in a direction you hadn't thought of. An agent can't disagree with you like that. It agrees faster.

Same with scope. The agent builds what you ask for, all of it, thoroughly. It won't mention that the third feature is the one nobody will use, or that "good enough" happened two iterations ago, or that something next door already solves most of this. Knowing when to stop comes from someone who's watched a codebase rot under a hundred individually-reasonable decisions.

And it only knows what you put in front of it. The person who worked on payments remembers the edge case you're about to recreate. The junior who joined three months ago still sees the thing everyone stopped noticing. That gap — between what's in the window and what isn't — is where the expensive mistakes live.

Then the part I didn't expect to care about as much as I do: teaching. You can read everything a senior ever wrote and still not get how they think. What transfers is the friction — the "why this and not that" you have to answer out loud, the moment you watch someone frame a problem and realise you'd been framing it wrong. Fung said it too: every time she watches someone work, she learns something herself. The AI hands you an answer. It won't ask you to defend yours, won't remember last month's mistake, won't push on your mental model — only on the words you typed.

I've watched teams strip the friction out on purpose. Fewer syncs, more async, everyone in their own context. They do move faster. They also stop catching what the friction was catching, and nobody notices for a while because the output looks the same.

DORA's research puts a number on it. A 25% increase in AI adoption lines up with real gains in the local metrics — code quality, documentation, review speed — and, at the same time, a 1.5% drop in delivery throughput and a 7.2% drop in delivery stability. Faster generation means bigger changesets, and bigger changesets are harder to review, riskier to merge, harder to roll back. The speed shows up upstream; the cost lands downstream.

The team was never the productivity tax. It was where the disagreement and the scope calls and the missing context and the teaching all happened at once. Skip that and you're not faster — you're moving confidently in whatever direction felt right to whoever wrote the prompt.

Left of the Loop: The End of the Craftsman?

Simon Schrottner — Fri, 26 Jun 2026 18:34:48 +0000

I noticed something a few months ago.

I was talking less to my colleagues.

Not because anything was wrong. I had a question, I described it to an AI, I got something useful back. Why loop in a human if the loop is already closed?

It took a while to name what was actually happening.

There's a version of the AI story where the interesting work disappears. The agent implements. The spec session produces the plan. Humans review the output. What's left? Ticket hygiene and rubber stamping. Engineering as a series of approvals.

I think that's wrong. But I understand why it feels true.

Here's what I think is actually happening instead.

The agent produces the increment. But the agent doesn't decide what the increment should move toward. It doesn't know whether this library is the right bet for the next three years. It doesn't know which of two implementation approaches leaves options open and which quietly closes them. It doesn't know whether the architectural call made today creates a problem nobody will notice until the system is under load eighteen months from now.

That work — giving the project direction, validating trade-offs, deciding what the system becomes — isn't specable. You can't write a ticket for it. And it's not going away.

The craft didn't disappear. It moved.

Direction is the word I keep coming back to.

The agent executes well. It implements against a spec. It generates options when you ask for them. But it doesn't carry a point of view about where the system should go. It doesn't have a stake in the decision. It will implement the wrong architectural direction just as confidently as the right one, if that's what the spec says.

Someone has to hold the direction. Someone has to know enough about the codebase's history, the team's constraints, and the product's trajectory to say: not that library, we've been down that road. Not that pattern, it doesn't survive the load we're heading toward. This approach now, that refactor later, in this order, for these reasons.

That's not a spec. That's judgment. And it's the part of engineering that the agent loop exposes rather than replaces.

A piece I read recently makes a related point. Most engineers use AI, few engineer with it — the difference being whether you're consuming outputs or shaping the problem before any output exists.

That framing is right but I think it undersells what's actually hard.

Shaping the problem before the prompt is a skill. But knowing what the system should become — which trade-offs are worth making, which implementation approach holds up over time, what the PoC needs to prove before you commit — that's a different kind of knowledge. It's accumulated. It comes from watching a system grow and break and get fixed over time.

You can't prompt your way into it.

We tend to confuse craftsmanship with implementation because implementation was where craftsmanship was expressed. The code review, the refactor, the careful choice of abstraction. But the craft was never the typing. It was the judgment behind it.

The agent can type. The judgment is still ours.

Which brings me back to what I noticed about myself. I was validating with the AI because it was right there. Faster. Always available. Never in a meeting.

But there are two different conversations hiding under "does this approach make sense."

One of them is: does this produce working code. The AI is fine for that.

The other is: does this make sense given where we're going, what we've tried before, and what we're going to have to live with. That conversation needs someone who knows the system, knows the team's history with this pattern, and has a stake in what gets built.

AI is quietly substituting for the second conversation while only actually covering the first. And nobody notices for a while, because the outputs look the same.

This is also where the junior engineer question gets uncomfortable.

The traditional growth path ran through implementation. You wrote code, made mistakes, got it reviewed, iterated. That feedback loop built intuition over years. It was slow and mostly accidental, but it worked.

If the agent writes the code, that path gets thin. Juniors who go through it in isolation — prompting, reviewing output, prompting again — are getting answers without developing the ability to form the questions. They're skipping the part where you learn to see the options before picking one. Where you learn to hold a direction, not just execute against it.

That's a quiet problem. And it deserves more than a paragraph here — so I'll come back to it properly in a later post.

The Spec Session (https://schrottner.at/2026/06/18/The-Wrong-End-of-the-Problem.html) helps with some of this. It's a forcing function for the room. Intent, edge cases, product thinking — those surface where the whole team can catch them.

But direction isn't a session. It's more continuous than that. Which library do we standardise on? What does the test harness need to survive the next six months? Is this the right moment for a PoC or are we using the PoC to avoid a decision?

That conversation has to be chosen. It doesn't appear in the loop on its own.

So where is the fun part?

It's here.

Validating the trade-off between two implementation approaches that both work but have different costs at scale. Choosing the library you're going to have to live with. Running the PoC that answers the question nobody has written down yet. Making the architectural call with three defensible answers, knowing you'll have to explain it to the team a year from now.

That work was always there. It just used to share space with implementation. Now it doesn't.

The agent handles the increment. The direction the increments add up to — that's still ours.

The craft didn't disappear. It just moved further left.

Left of the Loop: A Fool with a Tool is Still a Fool

Simon Schrottner — Fri, 26 Jun 2026 18:33:59 +0000

"A fool with a tool is still a fool." — often attributed to Grady Booch

I keep coming back to this quote when I watch teams adopt AI.

In my last post (https://schrottner.at/2026/06/18/The-Wrong-End-of-the-Problem.html) I wrote about shifting the engineering process left — spec sessions, autonomous agents, humans reviewing output rather than writing it. A few people asked the obvious follow-up: if an agent implements and an AI reviews, why do I need a team at all?

It's a fair question. And I think the answer is in that quote.

The agent validates against your prompt. That's it. If your thinking is muddled, the output will be muddled — just faster and at greater cost. An agent doesn't tell you that you're solving the wrong problem. It solves whatever problem you gave it, thoroughly and without complaint.

Most AI usage right now treats AI as a tool. Which means the quality of the output is bounded by the quality of the thinking that went into the prompt. A fool with a tool is still a fool. The tool just makes the foolishness more expensive.

The team is the check on intent. Not after the agent has burned three sprints on the wrong thing — before it starts.

That's what mob planning actually is, when you think about it. Not a meeting. Not process overhead. It's the place where bad ideas get caught before they get expensive. Where someone asks "wait, why are we building this" before an agent runs with it for a week.

But there's something else happening in that room that I think gets underestimated.

It's where the learning happens.

Not just prompting. System thinking. Architectural patterns. How to decompose a problem. Why a certain approach fits this codebase and another doesn't. How a senior frames a problem before an agent ever touches it — the mental model that makes the output actually good.

Right now that knowledge isn't transferring. Everyone is heads-down with their own tools, developing their own habits in isolation. Engineer A gets dramatically better output than engineer B. Nobody knows why. Prompting approaches are one small part of it — but the bigger part is the system thinking underneath. And that only surfaces if there's a room where people talk through problems together before they hand them to an agent.

That conversation only exists if there's a room to have it in.

AI is quietly doing something to teams. Everyone optimises their own workflow. Everyone gets faster individually. And the shared craft — the thing that used to live in code reviews, in pairing sessions, in hallway conversations about why the last approach didn't work — starts to disappear.

The mob planning session gives it back. It becomes the place where system design gets discussed, where architectural decisions get challenged before the agent runs with them, where a junior watches how a senior thinks through a problem and learns something they couldn't have learned from reading generated code. Prompting is part of that. But it's the smaller part.

The artifact changed. The need for the room didn't.

I don't think teams are going away. I think the ones that skip the room will produce faster, worse work — and won't understand why.

The ones that keep the room, and take it seriously as the place where thinking happens, will end up somewhere different.

Left of the Loop: The Wrong End of the Problem

Simon Schrottner — Sat, 20 Jun 2026 08:14:26 +0000

The Wrong End of the Problem

Every company wants AI in their development process right now. That part is clear. What's less clear is where they're putting it.

Most teams I see have done the same thing. Handed developers access to an AI assistant and told them to move faster. Copilot in the IDE. Claude in the terminal. Pick your tool. The tickets stay the same. The process stays the same. The planning meetings stay the same. The only thing that changed is how the code gets typed.

The tool got added. The process didn't move.

And it breaks down fast. One power user with AI can produce more code than a team can review. Two or three power users in the same team and the review process is basically gone. Nobody can keep up. The code ships anyway.

There's a term worth knowing here: Spec-Driven Development. The idea is that a detailed specification becomes the source of truth, not the code. Agents implement from it. Requirements change, you update the spec. AI Unified Process is one example of this in practice. It's a sound technical approach.

But I think it stops short of the actual problem.

The spec has to come from somewhere. Someone has to write it. Someone has to agree on it. That part is still the old process, just with a new artifact at the end.

What I'd suggest looks a bit different. And it has a name most engineers already know: shift left.

Not in the testing sense. In the team sense. The collaboration moves earlier. The engineering work is now about defining what the system should do — precisely enough that an agent can run with it.

That happens in what I'd call a Spec Session. Mob planning instead of mob programming — the whole team, working on one spec. Or async — a pull request on the spec instead of on code. Review comments about intent and edge cases, not implementation. Engineers already know this workflow. The artifact is just different now.

Once the spec is agreed, the agent picks up the work. Not on anyone's laptop — it's sitting in your infrastructure, watching for ready tickets, the same way a CI runner watches for commits. It implements, an AI reviewer checks the output, flags what doesn't fit, cycles back. That loop runs until it's done. The human comes back in at the end to review the final output — not to write code in the middle.

Stacked diffs are probably the right format here. Smaller, sequential changesets the agent ships incrementally — easier to reason about, easier to review. Gergely Orosz wrote a good primer on why this workflow matters if you're not familiar.

Ambiguous acceptance criteria used to be something a developer resolved mid-sprint. In this model they surface in the Spec Session, where the whole team can catch them. That's the point.

I don't think most teams are avoiding this intentionally. It's just that changing the process is harder than adding a tool. Adding a tool has a procurement step and a license. Changing how a team thinks about its own work is a different kind of problem.

But fitting AI into an existing process gets you faster typing. The thinking stays the same depth as before.

I think the teams that treat the Spec Session as the primary engineering output — and let the loop handle the rest — will end up somewhere different.

One thing I haven't figured out yet is what to call it. Mob Planning. Mob Specing. Spec Session. Extreme Specing. All of them borrow from XP deliberately — the idea is the same, just one level up from code. If you have a better name, I'd genuinely like to know.

I don't know if anyone is actually running this way yet. But I want to try. Especially the part where the agent just picks up the work and runs.