DEV Community: Simon Schrottner

Left of the Loop: The Phoenix

Simon Schrottner — Sun, 26 Jul 2026 18:49:36 +0000

Herodotus wrote of a bird that lived five hundred years in Arabia, and when its life came to an end, it did not wait to be surprised by death. It built its own nest of cinnamon and myrrh, set the nest and itself alight, and let a new bird rise from what the fire left behind.

The Hestia argued for tending a fire that must never go out. That’s true, and it isn’t the whole truth. Teams end. People leave. Companies get acquired, reorganized, shut down, and five years from now some part of this whole model will probably look as dated as the practices it was written to replace. No amount of tending prevents that.

Pretending otherwise is its own kind of Alexandria, a slow decline dressed up as continuity, right up until the fire goes out anyway and nobody chose the moment. The bird in Herodotus doesn’t get caught by surprise. It builds the pyre itself. Chooses the moment, gathers what matters, and burns deliberately, trusting that what rises afterward carries the shape of what came before, not because the fire preserved the old bird whole, but because starting over was never the same thing as starting from nothing.

That’s the part tending alone can’t promise. A team that’s about to be split up can hand its shared model to whoever inherits the work on purpose, the way a rep in the Boule carries a decision back instead of leaving it to travel however it happens to travel. A team about to lose its most experienced person can spend the weeks before that departure making sure the framing, not just the conclusions, made it into someone else’s head, the way the Mimesis argued a junior actually learns. None of that stops the ending. It decides what the ending leaves behind.

This series doesn’t get to end with a fire that never goes out. Nothing does. It gets to end with the only thing actually inside anyone’s control. Build the pyre on purpose. Choose what goes into the fire.

References

The Myth of the Phoenix: Rebirth and Renewal: Greek Mythology, on Herodotus’s original account of the bird’s five-hundred-year cycle
Phoenix: Immortal Firebird of Rebirth in Egyptian and Greek Lore: on the nest of cinnamon and myrrh, and the bird’s Egyptian origins in the Bennu

Left of the Loop: The Hestia

Simon Schrottner — Fri, 24 Jul 2026 20:29:27 +0000

A hearth fire required no priest, no temple, no calendar date. It required a fire and a household. When a city sent settlers to found a colony, they didn’t design a new fire from scratch. They carried an ember from the one already burning at home.

The same fifty representatives who ran the Boule’s business for their ten days in charge also tended the city’s public fire. Not a separate role. The rotating council that produced shared decisions was, without anyone treating it as a coincidence, also the body responsible for keeping the flame that never went out. Eighteen posts have circled one argument without me saying it plainly. Worth doing that now, once, before this series closes.

The case started with a claim that sounded almost too simple. Companies were bolting AI onto a process built for a world where implementation was slow, instead of asking what changes when it isn’t.A Fool with a Tool argued the team was never overhead, it was the check on intent before an agent burns its budget on the wrong thing.The PO is Dead and The End of the Craftsman followed the same thread into roles and craft, both landing on the same place. The work didn’t disappear. It moved earlier, into the room where the team decides what’s actually worth building. That room got a name and a shape.The Agora described what happens inside it.The Trireme argued it needs a minimum structure, three functions, not three job titles, to avoid becoming one person narrating their own assumptions back to themselves.The Gymnasion went back and filled a gap the room had been quietly assuming away the whole time, whether everyone walking into the Agora actually shared a tested picture of what the agent could do, or just a collection of untested guesses that happened to sound like agreement.The Ever-Agreeing Genie and Nobody’s Walking Over to a Desk both named what’s missing once the room gets skipped, a colleague who disagrees for reasons you hadn’t considered, and a habit of getting stuck that used to catch bad specs before they shipped. None of that works if nobody can see what the loop is doing or answer for what it produces.Who’s on the Hook argued accountability was always the team’s, never the individual’s, agents didn’t change that.The Kybernetes and The Astrolabe were about the mechanics underneath, seeing the loop’s own state and knowing which layer a given tool actually belongs to.The Oikonomos made the same argument about money that Alexandria made about knowledge, both quietly disappearing into whichever individual happened to be closest when the value got created. Understanding surviving contact with people who weren’t in the room turned out to be its own problem.The Alexandria Problem named what AI removed, the medium implementation used to travel through.The Mimesis went further, arguing a junior doesn’t learn from an answer, they learn from watching the question get framed, and that’s the part a spec can never carry.The Metron closed that arc by asking what any of this is actually for, arguing most teams are measuring speed when they should be measuring whether the problem got solved. And then the room stopped being enough.The Boule asked what happens when a decision needs more than one team’s worth of people, landing on representation instead of a bigger meeting.The Pheme asked what happens after that room agrees, arguing understanding travels two ways, one designed, one that can’t be designed at all, only made more likely by whether the trust was already there. Created in a room. Refined by people willing to disagree with the person who framed it. Shared with whoever wasn’t there. Valued as the actual output, not the code. Strengthened by a structure that can’t collapse into one head narrating itself. Preserved past the person who built it. Measured by whether the problem is actually gone. Scaled past a single room. Eight stages. One thing missing.

None of the previous eighteen posts asked what keeps it going after all of that is true. A team can do every one of these things once, get the spec right, catch the disagreement, teach the junior, measure the right thing, and still lose it eighteen months later. Not because anything broke. Because nobody was tending it, and a fire nobody tends still goes out, quietly, the same way Hestia’s hearth needed no dramatic failure to go dark, just neglect long enough. This is the part I actually believe, more than any single mechanism in any single post. Shared understanding isn’t a deliverable. It’s not a thing you build once, hand to the organization, and move on from. It’s a fire. It needs someone returning to it, not because a process demands it, but because the household would feel wrong without it. The whole argument of this series, from the first post to this one, has been a bet that organizations willing to keep tending that fire will outlast the ones who let implementation abundance convince them the tending was never necessary. Cheaper to generate code doesn’t mean cheaper to understand why it exists. Faster to ship doesn’t mean faster to agree on what shipping something even means. The teams that treat the room, the disagreement, the teaching, the measuring as one continuous act of tending, rather than a checklist to complete once, are the ones this whole model was written for.

When a Greek city founded a colony, nobody handed the settlers a document describing fire. They carried an ember. Something already alight, capable of becoming the new city’s own flame the moment it landed, not a copy of the old one, a continuation of it. That’s what scaling actually looks like, when it works. Not a bigger Agora, not a heavier framework borrowed from somewhere else. Someone carrying something already alive into a room that doesn’t have it yet, and trusting it to catch. The Pheme ended on the idea that the signal isn’t whether the mechanism works, it’s that it stops being needed. I’d add one thing to that. The mechanism disappearing doesn’t mean the fire stopped needing tending. It means the tending finally looks like nothing at all, a team returning to the same room, the same disagreement, the same question, because that’s simply what the household does now. No priest. No temple. No calendar date. Just a fire, and the people willing to keep it. Which holds for exactly as long as there’s a household left to keep it in.

References

Hestia: Wikipedia overview of the goddess and the civic role of the hearth fire
Hestia: The Quiet Power of the Greek Hearth: Spoken Past, on the prytaneis, the rotating council committee that tended the public hearth
Hestia: Mythopedia, on colonists carrying fire from the mother city’s hearth to found a new one

Left of the Loop: The Pheme

Simon Schrottner — Wed, 22 Jul 2026 10:59:09 +0000

Pausanias, walking through Athens centuries after the Boule had done its daily work, recorded something easy to miss. An altar to Pheme stood in the agora itself, near where the decisions got made, honoring not a ceremony but a thing that just happened on its own. Talk. Report. Whatever moved from one mouth to the next once the room had spoken.

The Boule left one question open on purpose. The room reaches agreement. What happens to it after. That’s a different mechanism from the one that produces agreement in the first place. Not one mechanism, either. Two, and neither one is right on its own. One is deliberate, a rep going back and re-running the reasoning with their own team, not just handing over the outcome. The other is what happens whether anyone designs for it or not, understanding moving through the ordinary texture of the work, a standup mention, a line in a PR, nobody scheduling any of it.

Pheme was the Greek personification of report, rumor, talk that moves through a city whether anyone wanted it to or not. Hesiod’s warning about her is specific: once enough people have repeated something, it stops being possible to kill, even if it started wrong. That’s exactly how a cross-team decision drifts. Not because someone lied. Because it got retold enough times that the retelling became the thing everyone remembers, and nobody can point back to what the room actually agreed. The deliberate path is close to what Mimesis already argued a junior needs, watching the framing, not just receiving the answer. Costs time. Preserves the why. Feels like an institution because it is one, a small session inside the team, triggered by a decision that came from somewhere else. The organic path is closer to what Nobody’s Walking Over to a Desk already named from the other direction. The confused developer getting up and asking was never a process either. It worked precisely because no one had to design it. Both work. I don’t think one is secretly correct and the other a fallback. Which one actually carries a decision depends on the team, and picking a favorite here would be exactly the prescription this series has been arguing against.

The interesting one is the second, because it’s the one you can’t build directly. You can mandate a mini Spec Session. Put it on a template, make it a step, require the rep to run it. That’s the institutional path, and it works the way institutions work, through the ceremony being enforced until it’s not needed anymore, or until it is needed and gets skipped anyway. You can’t mandate the other one. Culture doesn’t take instructions. The moment you formalize it, it stops being it. What you can do is build the room where it’s more likely to happen on its own. A team with enough trust already built passes a decision along the way gossip actually spreads in Hesiod’s telling, easily, without anyone authorizing it. A team without that trust doesn’t, no matter how good the Boule session was. Propagation was never really about the mechanism. It was about whether there was already enough trust for something to travel through. That’s the part worth sitting with. If it’s culture and not process, it doesn’t register as overhead. It doesn’t get logged as a ceremony anyone resents. It just is, the same way a healthy team doesn’t experience code review as bureaucracy, they experience it as how the team works. And because it’s not enforced, it doesn’t decay the way enforced things decay the moment nobody’s watching. It optimizes on its own, because it isn’t fighting anyone’s calendar to survive.

Here’s the honest cost. Pheme doesn’t check for accuracy. She spreads whatever gets said, true or distorted, faster the more people repeat it. An organic culture of understanding-transfer isn’t automatically a good one. It’s just a fast one. The institutional path trades speed for a checkpoint, someone re-runs the reasoning, and a wrong read has a chance to surface before it spreads. The organic path trades that checkpoint for speed, and gets nothing in return unless the safe space itself is the kind where being wrong out loud costs nothing. Which means the thing that makes organic propagation trustworthy was never the absence of process. It’s the presence of something harder to build than process ever was.

I don’t think this resolves into a recommendation. Build the institution if the trust isn’t there yet. Let it go organic once it is, and notice when that’s happened, because that’s usually the point where the ceremony starts feeling like it’s in the way rather than helping. An altar to Pheme in the middle of the agora wasn’t there because Athens administered rumor. It was there because they’d noticed it was already happening, and decided it was worth acknowledging rather than controlling. The signal isn’t that the mechanism works. It’s that it’s no longer needed.

References

Pheme: Wikipedia overview of the goddess as personification of rumor, report, and fame
Pheme & Ossa: Theoi Greek Mythology, Hesiod’s account of talk as self-perpetuating once spoken, and Pausanias’s record of her altar in the Athenian agora

Left of the Loop: The Boule

Simon Schrottner — Mon, 20 Jul 2026 13:23:09 +0000

The Boule was a council of five hundred, fifty chosen from each of ten tribes. It didn’t replace the Assembly. It prepared what the Assembly would decide, and carried the city’s business in the space between full gatherings.

Trireme answered a narrower question than it looked like it was answering. Three functions, one team, agent as the fourth participant. Fine for a room small enough to fit around one spec. But most engineering organizations aren’t one team. They’re several, each with its own Agora, each producing its own shared understanding, and none of that automatically holds together at the seams. I don’t have this figured out. Nobody’s run it long enough to know what breaks. This is a theory, not a report from the field.

The lazy answer is a bigger room. Take the Agora, invite every team, run one enormous Spec Session. That’s the Ekklesia, not the Boule, and the Ekklesia is exactly the failure mode Nobody’s Walking Over to a Desk already named. Too many people, no real decision, everyone nodding toward a consensus that isn’t real. Scale the room and you don’t get more shared understanding. You get a meeting that can’t end. LeSS was built on the idea that scaling shouldn’t mean adding layers on top of Scrum, it means figuring out how to apply the same principles at a larger scale, as simply as possible. I respect the instinct. SAFe took the opposite route, adding program and portfolio layers, release trains, and formal planning events to coordinate many teams at once. Both exist because someone already tried to solve exactly this problem with structure. I don’t think either is the answer here. Neither was solving the problem underneath the problem.

Room size isn’t the constraint. Ownership is. Who fixes the bug when three teams touched the feature. Who’s accountable when the spec that shipped was agreed on by people who don’t sit in any of the affected teams.Who’s on the Hook already argued the team is the unit of accountability, not the individual. Cross-team work asks the same question one level up, and doesn’t have as clean an answer yet. Here’s the shape I keep landing on, provisionally. Each team sends representatives to the cross-team session. Two, not one. A single rep is a single point of failure for what their team actually meant, the same risk a spec carries when only one person wrote it. Two gives the room a chance to surface disagreement the rep’s own team hadn’t fully resolved yet, before it gets exported as a decision on that team’s behalf. A stakeholder manager, likely a PM, gives direction: what’s actually in scope for this cross-team decision, what isn’t. That’s the Boule. Not the whole team, not one person speaking for everyone. The original Boule drew fifty representatives from each of ten tribes, distributed roughly by population, so every part of the city had a proportional voice without needing the whole citizenry in the room. Its central job wasn’t to decide policy itself. It drafted the matters that would go before the full Assembly, and the Assembly voted on what the Boule had already shaped. That distinction is the one worth keeping. The Boule produces alignment, not accountability. Accountability still lives where it always did, in the team that has to carry what shipped. Which means a session isn’t done when the room agrees. It’s done when what the room agreed on can be handed back to each team as something that team can actually own, not a directive arriving from outside, but a commitment they can be on the hook for. If a cross-team decision can’t decompose back into team-owned work, the session didn’t finish its job. It just moved the ambiguity somewhere less visible.

What it produces still has to get back to the people who weren’t in the room. That’s not a Boule problem. It’s a different mechanism entirely. Call it decision formation versus decision propagation. The Boule is formation, a smaller room producing the same currency a single-team Spec Session produces, shared understanding, just among representatives. Propagation is what happens after. How that understanding reaches everyone who wasn’t there. The Amphictyony model, independent governments, each keeping full autonomy, cooperating only where they share something specific, might be closer to how propagation should work than anything resembling a hierarchy. Whether it needs its own institution, or can grow organically with a gate that checks it actually landed, is the next question. It’s its own post, not a paragraph inside this one.

I keep coming back to the same tension. Fast, but with shared understanding intact. Less back-and-forth between teams, not more process wrapping the back-and-forth in ceremony. The Boule doesn’t resolve that tension. It’s a shape that might hold it better than a bigger Agora would, and better than borrowing a scaling framework built for a different problem. If this fails, it won’t be because the room was the wrong size. It will be because ownership never made it back to the teams that had to carry it.

References

LeSS (Large-Scale Scrum): Craig Larman and Bas Vodde’s framework for scaling Scrum through simplification rather than additional layers
Scaled Agile Framework (SAFe): the more structured alternative, adding program and portfolio-level coordination
Boule (ancient Greece): Wikipedia background on the council’s structure under Cleisthenes’ reforms
Council of Five Hundred: Britannica, on the Boule’s agenda-setting role relative to the Ekklesia

Left of the Loop: The Gymnasion

Simon Schrottner — Sat, 18 Jul 2026 09:57:17 +0000

Before a young Athenian took his full place in the city, he spent two years in the ephebeia. Training happened in the gymnasion, organized by tribe, the same tribes that would later send him to represent them in the Boule itself. Nobody handed him full standing first and hoped the judgment would follow.

This should have been post seven. It’s showing up as sixteen because the gap only became visible once the room was real enough to test against.The Agora described what a Spec Session does. It never asked whether everyone walking into that room shares an accurate picture of what the agent can actually do. Most rooms don’t. Someone watched a demo and thinks the agent can do anything. Someone else got burned by a bad output three weeks ago and doesn’t trust it with anything real. Nobody’s intuition has been tested against the same tasks, and the spec that comes out of that room ends up too ambitious or too conservative depending on whose untested belief happened to speak first. That gap has a name in Athens. The gymnasion existed because nobody was handed a place in the city first and expected to develop judgment on the job.

The ephebeia ran two years, training built around a specific fact. Physical readiness and civic judgment weren’t taught in separate places. They happened in the same space, under the same supervisors, organized by the same tribal groupings that would later structure how the city actually governed itself. The same word, gymnasion, ended up naming both the training ground for eighteen-year-olds and the buildings where Plato and Aristotle did their most serious thinking. Academy and Lyceum were gymnasia first. Nobody separated the trial from the reflection. The trial was how the reflection got earned. That’s the part worth taking seriously. Testing a tool and understanding a tool were never two different activities. The testing is how the understanding gets built. A team that reads documentation about what an agent can do has a description. A team that spent real hours running it against real tasks, watching where it held up and where it quietly produced something wrong, has judgment. Only one of those is worth anything in a room where the team is about to commit to a spec on the assumption the agent can deliver it.

The tribal detail matters more than it looks like it should. The people who’d eventually need to agree across team boundaries had already been building shared calibration together, in low-stakes conditions, before any of it counted. Most teams skip straight to the Agora. Someone adopts a tool, forms an opinion fast, usually from a handful of unrepresentative early tries, and that opinion becomes the room’s working assumption whether or not anyone else has verified it.Nobody’s Walking Over to a Desk already named what happens when a team has no habit of surfacing a wrong assumption before it ships. This is the same failure, earlier in the pipeline. The wrong assumption isn’t about the spec this time. It’s about what the tool can even do, and it gets baked in before the Spec Session starts, because nobody built a space to find out first. It’s also the same failure the Mimesis described from the other direction: a junior watching someone frame a question learns something documentation can’t teach them. Calibration on a tool is the same kind of learning. It doesn’t transfer by being described. It transfers by being done, and often by getting stuck, which turns out not to be a cost of the exercise but the mechanism doing the actual work.

There’s an honest complication here, the same one that always shows up when a system requires access before it grants judgment. Gymnasia weren’t open to everyone. Access was a privilege before it was a rite of passage, and pretending otherwise flatters the metaphor more than the history. The equivalent risk here is real. Calibration takes time, and not every team gets given time to spend on trial before being expected to produce a spec. That’s rarely a moral failing on the team’s part. It’s usually a budget line, a deadline, or a leadership team impatient to see the agent already producing something billable. A gymnasion nobody can afford to use isn’t a gymnasion. It’s a gate.

Adults kept returning to the gymnasia long after the ephebeia ended. It was never a rite of passage you completed once and left behind, a place for men of every age to keep training, keep talking, keep testing themselves against people who’d push back. That detail is the actual point, more than the youth-training origin story. Calibration on a tool isn’t a threshold a team crosses once. Every new model version, every capability jump, every quiet regression resets what’s actually true about what the agent can do. A team running on calibration from six months ago walks into the Agora carrying the same problem the Metron already warned about, measuring against an idea of the tool instead of the tool itself. Confident, coordinated, and wrong about the one thing the whole spec depends on. The room was never the first stop. It just took sixteen posts to notice the door before it that nobody had built.

References

Athenian Ephebeia: How Boys Became Citizens and Soldiers: Spoken Past, on the two-year training program, tribal organization, and its role preceding full civic participation
Gymnasium: World History Encyclopedia, on the gymnasion’s dual role as training ground and intellectual center, and its use by men of all ages
How AI Assistance Impacts the Formation of Coding Skills: Anthropic Research, RCT finding that cognitive effort, including getting stuck, is likely necessary for durable skill mastery, not just faster output

Left of the Loop: The Metron

Simon Schrottner — Thu, 16 Jul 2026 18:34:56 +0000

Metron was the Greek word for a measure: the standard you judge a thing against. It gives us metric, and metronome. Pick the wrong metron and everything you count against it comes out wrong, no matter how carefully you count.

Ask most teams how they know AI adoption is working, and the answer is some version of: we’re shipping more. More PRs, more tickets closed, more velocity on the board.

None of those numbers were ever measuring what people thought they were measuring. They were proxies, and bad ones, for whether the team was creating value. AI didn’t break that. It just made the proxies lie louder.

An agent can produce PRs faster than any team can review them. It can close tickets all day. None of that tells you whether the thing built was worth building, or whether it fixed the actual problem, or whether anyone downstream is better off. Burning tokens isn’t the same thing as creating value. It just looks the same on a dashboard built to reward the first thing.

The same DORA numbers I pointed at earlier are blunt about it: individual output climbs while delivery throughput and stability drop. Same bottleneck, counted at the wrong end.

This is Theory of Constraints in one sentence: speeding up a step that wasn’t the bottleneck doesn’t speed up the system. It just piles more work in front of whatever the real bottleneck is.

Implementation used to be the constraint. Now it isn’t. Review is. Coordination is. Making sure everyone agrees on what “done” even means is. Agents made the fast part faster and left the slow part exactly where it was, except now it’s buried under more output arriving to be reviewed by fewer people who understand any of it.

Measuring individual speed after that shift is measuring the wrong clock. The team can be faster and worse off in the same quarter.

The instinct, when this gets noticed, is to add another skill to the agent. Automate the review step too. Automate the coordination. Whatever’s slow, throw a capability at it.

That doesn’t fix the process. It just moves the bottleneck one step further down and makes it arrive faster. The team is still broken, just broken at a higher velocity.

What actually needs measuring doesn’t increment. Whether the problem the work existed for is gone. Whether the system got easier to change or harder. Whether anyone downstream is better off than before the tickets closed. None of that ticks up once a day on a board, which is exactly why teams reach for velocity instead. Not because it was ever the right measure. Because it was the easy one.

A proxy holds only as long as it tracks the thing it stands for. Agents didn’t break that. They cut the thread between output and value and left the number climbing anyway. Measure that number harder and all you get is more confidence about less.

Left of the Loop: The Mimesis

Simon Schrottner — Tue, 14 Jul 2026 13:09:00 +0000

Mimesis was the Greek word for imitation, and the oldest theory of how we learn: by copying a thing long before we understand it. Understanding, if it comes, comes after.

The End of the Craftsman ended with a promise. The junior question deserved more than a paragraph, I said, and would get its own post later. This is that post.

Aristotle had a word for how humans learn a skill before they understand it: mimesis. We watch, we imitate, and only later do we understand what we were doing. A child doesn't learn to speak by studying grammar first. A junior doesn't learn to debug a production system by reading a postmortem. Both copy a move long before they can explain why the move works.

That's the specific thing missing when a junior sits across from an agent instead of a senior. Not knowledge in the abstract. The move itself.

What actually gets copied in an apprenticeship is narrow and specific. Which log line to check first when a request times out. The half-second pause before touching a config file that's been stable for three years. The instinct that an elegant fix is wrong for this particular system, for reasons that have nothing to do with elegance and everything to do with a decision made two years ago that never made it into any document.

None of that is information you could write down and hand over. It's a sequence of attention: where to look first, what to distrust, what "off" feels like before you can name what's wrong. A junior doesn't absorb that from an answer. They absorb it from watching the question get asked.

This is the part a spec can't carry, no matter how well-written. A spec captures what the team decided. It doesn't capture the moment a senior went quiet for a second before answering, because that pause was itself the thing worth learning from.

A junior working next to an agent gets the outcome without the performance that produced it. Clean, fast, and stripped of the one part that was ever going to teach them anything.

Understanding comes after the imitation, not before it. That's the order Aristotle had right, and the order most onboarding plans get backwards. You can't fast-track a junior past the copying phase by giving them better answers faster. You can only give them, or fail to give them, enough moments where the move is visible enough to copy.

Left of the Loop: The Kybernetes

Simon Schrottner — Sun, 12 Jul 2026 10:38:32 +0000

The kybernetes was the helmsman who steered a Greek ship, reading the wind and working the steering-oar to hold a course. The word is the root of two others: govern, and cybernetics, the study of how systems steer themselves.

The Oikonomos ended with a shrug. Someone has to own the loop, I said, and left the how for later. Fair complaint if you actually run one of these things and want to know what "own" means in practice.

It means two things. Seeing what the loop is doing. And being able to change what it does without touching the code.

Most teams get the first one wrong before they even try the second. They add logging after something breaks. A trace here, a dashboard there, built to explain a specific incident after the fact. That's not visibility. That's an autopsy.

OpenTelemetry does something different if you use it the way it's meant to be used. The loop reports on its own state as it runs: what it's calling, what it's costing, how long each step takes, where it's stuck. Not after. While it's happening.

Call it proprioception if the biological framing helps. A body knows where its limbs are without looking. A loop instrumented properly knows its own state without someone digging through logs afterward. The difference between the two is the difference between noticing a problem and being able to prevent one.

Seeing isn't steering. That's the part most people stop at.

OpenFeature is the other half. A flag decides which model handles a given ticket type, how many retries an agent gets before a human sees it, whether a particular team's loop runs a stricter review pass. Change the flag, and the behavior changes immediately. No redeploy, no waiting for the next release cycle.

That's the motor response. The nervous system reacting to what the senses just reported, without needing the whole organism rebuilt first.

Put them together and you get something more specific than "observability" and "feature flags." You get a control plane. The loop still runs on its own: picks up tickets, implements, reviews itself, cycles back. Nobody stands over it approving each step. But every override you'd want already has a hook. Slow it down. Redirect it. Shut a piece of it off. All without touching the thing that's actually running.

That's bounded autonomy, not supervised autonomy. The loop is trusted to run unattended, and trusted precisely because the mechanism to intervene already exists if it's ever needed.

None of this was built for AI cost control, or for agent loops at all. Both tools predate the current wave by years. Which is probably the tell that this isn't really a new problem. Distributed systems needed to see themselves and adjust themselves long before anyone asked an agent to write code. The agent loop just made the need obvious again.

A loop nobody can see and nobody can steer isn't an agent loop. It's a black box with a budget, and eventually a bad one.

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. 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. A steward for the shared resource, minding it so the whole team runs well on it. An oikonomos.

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.