I've been using the Double Diamond for fifteen-odd years. Discover, define, develop, deliver: divergence and convergence, twice over. This year I ran a version of it as a founder on Spades Audio, the per-app audio mixer for macOS that co-founder Sasi and I are building. Somewhere in the middle of that I found the second half of the framework now runs as a loop instead: a goal, a stop condition, iteration until it holds.
I also noticed the Double Diamond had become something you install. There is a SKILL.md for it now. The process I was taught standing at a whiteboard is project knowledge sitting on disk. That should have felt like a demotion. It didn't, it felt like a clarification, because the agents were never running the diamond in the first place. They were running a different shape entirely, and once I could see it properly I could also see which half of my job it had quietly made easy. Two features showed me where the handover happens, and which half of the work is still mine.
The shape the agents run
Addy Osmani calls it loop engineering, and the line he builds it on comes from Peter Steinberger: you shouldn't be prompting coding agents anymore, you should be designing loops that prompt your agents. Boris Cherny puts it more bluntly: his job now is to write loops. The anatomy is five pieces and a memory. Automations fire on a cadence and find the work. Worktrees keep parallel agents off each other's files. Skills write down the project knowledge the agent would otherwise guess at. Connectors let it reach into the tools you already use. Sub-agents split the one that writes from the one that checks, because a model grading its own homework is generous. Underneath all of it sits a state file, markdown or a board, because the model forgets between runs and the repo doesn't.
Put that next to a diamond and the interesting difference isn't tempo, it's where the judgement sits. A diamond opens to find the right problem, closes on a definition, opens again for solutions, closes again to ship, and every one of those closures is a human call made against evidence that is usually partial. A loop doesn't open in that sense at all. A loop begins already converged. You hand it a goal and a condition that can be checked, and it iterates until the condition holds, with a separate model deciding whether the claim is true. It diverges hard inside that fence, across attempts and branches and variants, but it can only do that because someone else already decided what finished means. The loop has no discovery. It inherits one.
So the first diamond is still mine, the second diamond is increasingly a loop. The seam between them is the spec, and the spec is really just a stop condition written in a language a person can argue with.
The feature with no screens
Spades had two features that made this visible, and they broke the shape in opposite directions. The first was extending Siri's audio control into something granular and handing the same capability to any local agent, which meant taking our App Intents and building a set of MCP audio tools. There was no interface to design. The whole surface was language: what the tools are called, how their descriptions read, what the parameters will accept. Those names are the workflow.
So the first diamond ran backwards. We shipped a rough prototype and used real usage as the research instrument, which is a thing you can only do when the cost of a prototype has collapsed. Someone opens Claude, says "drop Spotify to twenty per cent and route the call to my AirPods", and the engine does it. Watching early testers phrase audio intent in plain language, and honestly watching ourselves do it, gave us the shape of the spec inside days rather than after a fortnight of interviews. Synthesis was the quiet win there: I fed session notes and tester asks into Claude, and the patterns came back the same afternoon. The competitive scan behind the original spec took a day, not a fortnight of open tabs.
Then the loop took the second diamond. Every "why can't I also" became a stop condition: a tool signature, a test, an acceptance line. EQ, balance, per-app mic control, playback. The tool list has grown well past the original eight, and almost none of that came from upfront discovery. It came from converged goals handed to a loop that ran until the tests passed and a verifier agreed they had. Apple wiring MCP support into App Intents from the 26.1 betas makes the bet look early, though the part I'd defend is the division: I never once specified how a tool should be implemented, and the loop never once decided what a tool should be called.
The feature that was all fence
Audio presets was the opposite problem, where convergence arrived before we had diverged at all. The idea was simple enough: save an audio configuration as a preset, attach it to a macOS Focus state, let Apple drive the automation. That meant converging on SetFocusFilterIntent, and the API brings its own fence. The app cannot create the link between a preset and a Focus, only the user can, through System Settings. The app cannot ask which Focus is currently active. It only learns which preset was invoked. The activation code also runs in an extension process rather than in the app, so any state both sides need has to live in a shared container.
Ordinarily that's a week of reading documentation and drawing system diagrams. We set a research agent on the API and handed its findings to a coding agent, and had a preliminary presets implementation to poke at while I was still forming an opinion. Almost every design decision then fell straight out of the fence. Because we can't create the link, the first-run experience is an info card that deep-links into System Settings and explains the one step only the user can take, which is a worse experience than the one I wanted and the only honest one available. Because the extension can't ask what's active, the preset has to carry everything it needs rather than reading ambient state, so a preset became a complete configuration rather than a diff. State crosses a process boundary too, so the presets screen shows what was last applied instead of what is currently true, a small distinction that took a while to accept.
Divergence only survived where options genuinely existed, which turned out to be that screen and its copy. Everything else went into a build-ready, test-driven spec carrying the data model, the copy strings and the acceptance criteria in one document, which is exactly the artefact a loop wants. Constraint-heavy work suits loops unusually well, because a fence is already close to a stop condition.
Who writes the stop condition
The reason one method held both features is how the labour splits. Sasi was managing the audio driver, the DSP and the clock sync, careful engineering deliberately isolated so no single feature mishap takes the system down. I was iterating on top through a single service layer, so design churn never destabilises the engine and every prototype tests real behaviour rather than a simulation of it. What's changed is what I hand over. Design mockups have gone from most of my week to maybe a third of it, and the rest is specs and stop conditions and reading what came back.
That's also where being founders rather than a design team inside a client engagement starts to matter, because a stop condition is a product decision wearing engineering clothes. What the free tier gives away, what stays Pro, which feature ships first: these are the conditions the loop runs against, and there's no translation layer between the evidence and the person writing them. The same tester session that reshapes a tool description settles the pricing call. I don't think that collapse is available to everyone, but I do think it explains why this way of working felt natural here and might not elsewhere.
What the loop won't do
Three things get harder as the loop gets better, and Addy Osmani names them well: verification stays yours, your understanding rots if you let it, and the comfortable posture is the dangerous one. The design version is narrower and sharper. A loop can prove that a preset saved and restored correctly across a process boundary. It cannot tell you that the presets screen feels like something a person would want to open twice. Taste has no stop condition, and the moment you write one for it you've stopped exercising it.
So the diamond didn't disappear and it didn't get replaced. It split along a seam that was always there and never load-bearing until now. Discovery lives in real usage, synthesised in an afternoon. Definition is still human, and it's most of the job. Development is a loop running against conditions we write. Delivery is a keep-or-kill call backed by behaviour rather than a workshop wall. The process was never the value; knowing what a thing should be and how it should feel still is. A sharper shape just gets the evidence in front of that instinct sooner, and leaves more of the week for the part only I can do.
Spades is out now at spadesaudio.com, both of those features included.