Ways of Working at the Speed of Thought
Ways of Working at the Speed of Thought
Product talked to a BA. The BA talked to a scrum master. The scrum master scheduled a refinement. Engineers showed up, debated the shape of the feature, poked at the data model, estimated it, and dropped it into the backlog. Eventually — maybe next sprint, maybe next quarter, maybe never — somebody wrote the code.
That was the shape of enterprise software for two decades. We built elaborate coordination machinery around a single hard fact: writing the code was the slow, expensive, error-prone step. Everything else existed to protect that scarce resource.
That fact is no longer true. And most enterprises are still running the coordination machinery for a world that doesn't exist anymore.
The idea-to-code distance has collapsed. Enterprises that keep the old orchestration machinery wrapped around AI-assisted engineers are paying relay-race taxes on a sprint. Invest in platform architecture (what's good for engineers is a force multiplier for agents), analyze your own prompt patterns before you build skills, dismantle ceremonies designed to coordinate humans, and give the restless builders a direct line to the business.
The Relay We Inherited
I don't want to dunk on Scrum. A lot of smart people built those processes for real reasons. When a feature took two months to write, a week of up-front refinement was cheap insurance. When a deploy was a risk event, a release train made sense. When engineers couldn't realistically touch a codebase they hadn't worked in for six months, specialization and handoffs were rational.
So we inherited the relay: product owner → business analyst → scrum master → engineering lead → developer → QA → release. Each handoff added a queue. Each queue added latency. Each ceremony existed to keep the queues from drifting.
None of that was wrong for the world it was built for. It's just wrong for this one.
The Economics Flipped
An engineer working with agent tooling today can take a fuzzy product thought, sketch the design, prototype it against a real dataset, wire it through the stack, write the tests, and open a PR — in an afternoon. Not because they're a superhero. Because the agent takes the mechanical parts off their plate while they stay in the loop on the judgment parts.
I wrote about one version of this after the KOLO AI Hackathon — a small team, one week, a pile of AI tools, shipping something real. That wasn't a stunt. It was a preview.
When idea-to-working-code collapses from weeks to hours, every minute of orchestration overhead you wrap around it is a percentage point of latency tax you didn't used to be paying. The process didn't get worse. The work got faster, and the process stayed the same, and now the process is the long pole.
What's Good for Engineers Is a Force Multiplier for Agents
Here's the architectural point I'd put at the top of every CTO's desk this year: the platform investments that make your engineers effective make your agents dramatically more effective.
An agent turned loose on a tangle of microservices, half-documented internal APIs, drift between staging and prod, and fourteen deploy pipelines will produce garbage. An engineer turned loose on the same tangle will also produce garbage — just slower and with more cursing. It's the same problem.
Things that pay off twice, once for humans and again (larger) for every agent those humans run:
- Monorepo. An agent with the whole stack in its context window reasons about cross-cutting changes the way a senior engineer does. Polyrepo forces the agent to work blind, the same way it forces a human to work blind.
- Typed boundaries and strong contracts. Agents navigate type systems far better than prose. A well-typed interface is documentation an agent can actually act on.
- Docs-as-code, next to the code. If the engineer has to grep README and Notion and Confluence and three Slack threads, so does the agent. Pull that knowledge into the repo.
- Deterministic builds and a real test suite. The test suite is the agent's feedback loop. Flaky tests and nondeterministic builds don't just slow humans down — they make agents unreliable, because they can't tell whether their change broke something or the build was always like that.
Platform work has always been the highest-leverage investment in an engineering org. Agents made it more so. If you had trouble justifying paying down tech debt, the business case got a lot easier: every hour of debt isn't just slowing your engineers, it's taxing every agent-hour they run, forever.
Analyze Your Prompts Before You Build Skills
There's a pattern I see a lot right now: a well-meaning platform team announces they're going to build "internal Claude Code skills" or "golden-path agent templates" or "approved prompt libraries." Six weeks later they ship a catalog nobody uses.
The mistake is building the skills without first watching what your engineers actually prompt.
The duplication in your engineers' real prompts is telling you exactly what's missing from the platform. If thirty engineers are all writing some variant of "add a new endpoint following our auth pattern, wire up the DB migration, add the audit log, and create the integration test," you don't need a skill — you need a generator. If they're all pasting the same six paragraphs of context every session, you don't need a skill — you need that context in a file at the repo root.
I built PromptConduit partly to see this for myself — the raw prompt stream makes the patterns obvious in a way that aggregate dashboards never do. The broader measurement frame, for teams trying to do this at org scale, is in how to measure AI coding assistant productivity.
The loop looks like this:
- Watch the prompts. Aggregate across engineers.
- Find the duplications — the same preamble, the same context-loading dance, the same post-processing step.
- Codify the highest-frequency pattern. A hook, a skill, a template, a generator — whatever fits. The Claude Code hooks guide is a concrete example of how small that investment can be.
- Ship it. Watch the next wave of prompts. Repeat.
Prompts in, platform out. That's the cycle. Do not skip step 1.
Dismantle the Orchestration Overhead
The ceremonies and handoffs in your SDLC all exist for a reason. The question is whether that reason still holds.
A few that I'd interrogate hard:
- The backlog-as-waiting-room. If something has been in the backlog for six months, it is not going to be built. It is a lie you are telling stakeholders. Kill it and free the planning cycles.
- Refinement as translation. Multi-round refinement made sense when engineers needed a carefully pre-chewed spec to start work. An engineer with agent tooling can start from a two-paragraph intent and have a working prototype before the old refinement would have finished. The prototype is a better spec than the spec was.
- Handoffs between product intent and engineering execution. Every hop is a queue. Every queue is latency. Push decision-making to the smallest pair that can own the outcome end-to-end.
- Standing ceremonies on autopilot. Sprint planning for a team that deploys twice a day is theater. Default your ceremonies to opt-in, not opt-out, and watch which ones the team actually keeps.
None of this is about "move fast and break things." It's about noticing that coordination overhead designed to protect a scarce resource is now the scarce resource.
Pair the Curious with the Business
Every org has engineers who are restless right now. They can feel the new speed. They're running agents on the side. They're building internal tools nobody asked for because they see the gap. And they're frustrated that the process around them hasn't caught up — they're producing at one pace and the intake queue is filling at another.
Your leadership job is to find them and free them.
Not with a reorg. Not with a new title. With a pairing. Put the restless engineer next to a business partner who has a real problem. Skip the BA translation layer. Let them extract value together at the new speed, end-to-end. You will be surprised how much value was trapped on the business side waiting for the old intake process to get around to it.
The companion move: find the curious ones. The engineers who are already experimenting, already writing their own skills, already pulling agents into their workflow. Give them air cover, give them a mandate to pull what works into the platform, and give them the authority to delete what doesn't. Curiosity compounds in an org the same way tech debt does — except in the direction you want.
The engineers you want to lean into this are not the ones asking for permission. They're the ones already doing it on their lunch break. Pay attention to who those are.
The Time for Builders
Two truths held together:
The first is that the idea-to-code distance has collapsed, and it is not going back. That's just the new economics. Every quarter that passes, the tooling gets better and the gap widens between organizations that have reshaped around it and ones that haven't.
The second is that enterprise process is hard to change, and the people best positioned to change it — engineering leaders — are also the people most scheduled into the meetings that encode the old shape. It is very possible to spend the next two years running excellent sprint ceremonies while your more nimble competitor ships circles around you.
This is a builder moment. The authors of code-generation machines are the ones who are going to compound. Your job as a leader is not to author all the code yourself. It is to clear the runway for the builders on your team, invest in the platform that multiplies them, kill the ceremonies that slow them down, and put them in the room with the business.
Coding at the speed of thought is already happening. The only question is whether it's happening inside your org chart or around it.