Microsoft named its AI development workflow Hypervelocity Engineering. Every named theirs Compound Engineering. Different vendors, different branding, and underneath both of them, the same move: compress the unit of engineering work and hand the ceremony to agents.
Look at the two loops side by side and they rhyme for four words straight.
HVE: Research, Plan, Implement, Review.
Compound Engineering: idea, brainstorm, plan, work, review, compound.
Four words, near enough identical. The fifth word is where they stop rhyming, and the fifth word is the whole argument.
The loop I actually run
I run the Compound Engineering loop daily in Claude Code, so I'll start with what I know first-hand.
Every's own framing of the economics is blunt: roughly 80% of the effort is planning and review, 20% is execution. A good brainstorm makes the plan sharper. A good plan makes execution small. A good review catches the pattern, not just the bug. And a good compound note means the next agent doesn't relearn the same lesson from scratch.
That last part is the one that matters. /ce-compound closes the loop. It's an explicit, forced step: document what was learned, write it back into the system, so the next cycle starts with better context than this one did. Skip it and the loop is just fast. Run it and the loop gets smarter every time it runs.
Where HVE stops
Microsoft's HVE Core ships a prompt library built on RPI: Research, Plan, Implement, Review. It's a serious piece of engineering, 34 agents, 68 instructions, 40 prompts, 3 skills, and its own documentation is honest about what kind of thing it is: a pipeline, moving "Uncertainty to Knowledge to Strategy to Working Code to Validated Code."
Read that sentence again. It ends at Validated Code. There's no arrow pointing back to the start.
Nothing in the named RPI workflow turns this cycle's lessons into next cycle's starting conditions. It researches, it plans, it implements, it reviews, and it stops. That's not a criticism dressed up as an observation. It's what the documentation says it does.
To be fair to it, HVE's wider lifecycle isn't entirely loop-free. Its own guide describes loops elsewhere: Review feeds back into Implementation for rework, Delivery loops back for the next sprint, Operations loops back to Discovery for the next iteration. Those are real feedback paths. None of them is the one this post is about. They loop the process back to an earlier stage. They don't write this cycle's lesson into the next cycle's starting context, automatically, as a required step. That's a narrower, more specific claim than "HVE has no loops anywhere," and it's the one that actually holds up.
"But doesn't Microsoft already call this compounding?"
Fair question, and I want to answer it directly instead of pretending nobody would ask it.
A Microsoft engineer, writing in the official Microsoft Azure Medium publication, described HVE in almost exactly this language: development "stops feeling like a sequence of isolated sprints. It becomes something more like a compounding system, where every new app inherits a stronger foundation."
She's not wrong. Something does compound in HVE. It's just not the thing Compound Engineering compounds.
What she's describing is a library compounding. Teams hand-author more skills, more prompts, more instructions over time, the shared pile gets bigger, and the next project inherits a bigger pile to draw from. That's real, and it's exactly what HVE's memory agent and a hand-written copilot-instructions.md file produce. Someone writes it. The agent reads it. The library grows because people keep feeding it.
Compound Engineering does something narrower and more specific: cycle compounding. Every single unit of work, automatically, writes back what it learned, whether anyone remembers to or not. That's the difference between a document you maintain and a system that updates itself. HVE gives you the first. Compound Engineering gives you the second.
Microsoft isn't unaware of the gap, either. HVE's own guide marks memory as "cross-cutting" and "available at every stage but not tied to any single phase." Ambient and optional is a weaker property than required and automatic. A retrospective that only runs when someone remembers to invoke it is the retrospective that quietly stops happening.
Scrum isn't dying. It's being hollowed out
There's a popular video making the rounds titled "Agile Scrum is dead." It's a sharp explainer, and it gets most of this right, but the headline overstates the discontinuity.
What actually dies is the ceremony: story points, planning poker, backlog refinement meetings, standups, retrospectives, the Scrum Master role. What survives, in both HVE and Compound Engineering, is the agile principle set: ship working software, iterate, keep talking to the customer, respond to change.
HVE keeps the enterprise lifecycle scaffold around that principle set. Its guide still lists a Sprint Planning stage, an agile-coach agent, a backlog manager, TPM and Business Program Manager roles. The human ceremony inside those stages gets automated away, but the scaffold stays standing. That's agile squared, not agile abolished, and it's exactly what you'd expect a platform vendor to ship. Nobody selling into regulated enterprises was ever going to say "your scrum process is obsolete." They shipped "your scrum process, now with agents in every box."
Compound Engineering drops the scaffold too. When the loop is a day or two instead of two to four weeks, and one developer is orchestrating a small team of agents, the sprint stops having a job.
Story points make the point sharper than the sprint does. Points exist to forecast human throughput across a multi-week iteration. When the loop is a day and an agent does the execution, you don't estimate the agent in story points. The unit the whole ceremony was built to forecast is gone, not because someone declared it obsolete, but because the thing it was measuring stopped existing.
But the cadence isn't the headline. The retrospective is. In both models, the human retro meeting dies. The difference is what replaces it. Compound Engineering keeps the retro's function and automates it, every cycle, without fail. That automated retro has a name. It's the compound step. It's exactly the step HVE cut.
The architect's takeaway
Judge any AI-assisted engineering workflow with one question: does this cycle make the next one measurably cheaper? If yes, you've built something that compounds. If no, you've built something that's merely fast.
Here's the trap if you skip that question. A team adopts HVE, ships noticeably faster in month one, and a quarter later is making the same class of mistake it made before the switch. Nothing closed the loop. Speed went up. Learning stayed flat. That's not a failed rollout. That's the tool working exactly as documented, which is the problem.
HVE is good, disciplined engineering, and a sane way to bring agents into a regulated enterprise without breaking every existing process around it. None of this is a teardown. The honest version of the critique is narrow: it accelerates your process without changing its shape, and out of the box, it does not make your team compound.
You can add the missing step yourself. A memory convention, a compound ritual, something invoked at the end of every single loop without exception. But you have to know it's missing first, and the vendor packaging is not going to be the thing that tells you. A hand-maintained copilot-instructions.md file feels like it's doing that job. It isn't. It's a document you have to remember to update, not a system that updates itself.
Open your own workflow and find the step where this cycle teaches the next one something it didn't already know. If you can't point to it, you're automating. You're not compounding.
