Our philosophy
The reason is simple. Code used to be the slow, expensive step, and the whole way of making products was built around it. Now AI writes the code, and changing it costs almost nothing. So everything around it has to be reorganised.
Two ways to develop a product
Why so long? Every link existed to protect against code that was slow and expensive. Mistakes cost weeks, so everything had to be specified, prioritised and coordinated before anyone built.
the code — agents implement in the background. Support, not bottleneck.
Why so short? When code is cheap to write and change, the reason for the links disappears. We can change things directly and let usage correct the course, instead of guessing everything up front.
Five principles
A piece of feedback used to pass through support, a product manager and a specification before it reached whoever built things. Those links existed to ration scarce development capacity.
When capacity is no longer scarce, the links are just noise. We see for ourselves where the user gets stuck, and make product decisions on direct information. The user doesn't decide what we build, but we guess less.
Coding agents do most of the implementation here. What can't be delegated is knowing what's worth building, and how freely the agents can work in each part of the system.
Control isn't reading every line. It's testing, structure, and following the product after launch. That's how we get a different kind of capacity without losing our grip.
Speed isn't about shipping more. It's about how fast something we learn becomes an improvement in the product. If that takes weeks, the decision rests on assumptions that are already stale by the time the user sees the result.
When a change takes hours, earlier choices can be challenged instead of protected. Rebuilds and migrations are no longer separate projects that stop everything else.
Large teams spend much of their time coordinating themselves. When agents take the implementation, the same few people can understand the problem, make the decision and carry it out while the context is fresh.
That's why product understanding and technical judgement weigh more here than how fast someone types code.
A task can be done without the product being good. We measure the work by whether the solution works for the people it's built for, not by the number of closed tickets.
So we take responsibility for the whole: the need, the experience, the workflow and the technology. And we'll happily challenge the problem, not just the specification.
What the work looks like
The code is the dotted ring on the outside. It holds everything up, but it isn't the point. The point is what happens around the user.
Before → Now
because the links existed to ration scarce development capacity. It's no longer scarce.
because when code isn't the bottleneck, choosing right is the hard part.
because a change can be built and tested in hours, not weeks.
because agents can rebuild large parts of a system quickly and systematically.
because less of the work is manual coding that has to be spread across many hands.
because coding itself has become abundant, not scarce.
because agents take the implementation, and people take the direction.
because a task can be solved without the product getting any better.