For most of the history of software, scheduling was sacrosanct. You had to plan before anyone touched a keyboard, because the cost of building something wrong can be so punishing, especially for startups, that getting it right beforehand was the only rational strategy.
Implementation was expensive, engineering time was short, and once the team decided on an approach, changing direction could set you back months.
The entire apparatus of modern software development, the roadmaps, the prioritization frameworks, the quarterly planning rituals, grew in response to this single economic fact.
This fact is no longer true and most engineering organizations have not achieved this.
AI coding tools have lowered the cost of turning an idea into working software. Things that used to take weeks to complete can now be researched in hours.
You can ask an agent to prototype three competing approaches overnight and discard the two that don’t hold up when you wake up in the morning.
Instead of a slide deck, you can challenge the assumption with a running demo. The economics have been reversed: planning and process used to be cheaper than construction, and now construction is cheaper than the meetings you have to hold to decide what to build or how to build it.
This changes everything about how engineering teams work. There is no such thing as a perfect plan anymore, and even if there is, the time it takes to develop one means you’ve already lost out to someone just starting out.
Horse Synthesiswe decided to test this idea in the most direct way possible. Every quarter our product, engineering and R&D teams meet in London to plan the next three months of work.
Historically, we would spend most of this time in rooms analyzing, discussing and prioritizing. The goal was to come up with a plan good enough to justify the cost of implementation.
During our last meeting, we changed the sequence. We replaced the first two days of planning with a hackathon. 200 people from engineering, product, design, legal, research and talent created 70 teams and built in exactly 28 hours.
The brief was simple: take an idea, build it, turn the result into a two-minute demo video. No detailed specifications, no excessive planning – just build.
What happened surprised us.
One of the winning teams, a group of five engineers completely rebuilt our video editor from scratch. The video editor provides a PowerPoint-like interface through which users of our platform create videos AI avatars.
Engineers delivered a complete reimagining of the product, focusing on interactivity, branching narratives, and multi-avatar storytelling.
This was not an outlier; The same pattern emerged across all 70 teams: When they focus on people and remove friction, they can move faster than anyone expected.
The lesson from this experience is that enforcement is no longer a constraint, but a judgment.
This may go against the operating assumption that most engineering leaders work with for their entire careers. We’ve spent years building organizations optimized for execution: how many features are shipped, how many story points are completed, how quickly the backlog is reduced.
But when construction becomes cheaper, the bottleneck moves upward. The hard part is that there is no more code to write. Instead, it’s about knowing what code is worth writing in the first place.
When I say judgement, I mean four specific things. First, the ability to help product managers solve the right customer problem faster requires distinguishing between what is intellectually interesting and what is actually important to users and the business.
Second, define what “great” looks like before you start, because if you can’t articulate that standard, you won’t know it when you see it.
Third, it’s about knowing that something is good enough to put in front of the user, not perfect, not polished, just good enough to learn. And finally, being able to kill ideas quickly.
When you can try many things in parallel, the most valuable skill is to let go of what doesn’t work, rather than falling in love with your first attempt because it costs too much to produce.
Over the next few years, the best engineering teams won’t win on code output, they’ll win on taste.
This has real implications for how we think about the engineering role itself. We move from being builders to orchestrators. AI agents can now handle large parts of the development process end-to-end.
An engineer’s job is increasingly to pick the right problems, review the results, and rapidly iterate. Spend less time writing each line and more time directing systems that write lines for you.
Some people consider it a threat. I think it’s the other way around. The tedious parts of engineering, the boilerplate, the repetitive wiring, the never really interesting work, is what gets automated first.
What remains is the work that engineers always want to spend more time on: deeply understanding the problem, developing elegant solutions, making the tough calls about what to build and what to throw away. Art is distilled to its essence.
At Synthesia, we take responsibility for this change. We track the use of AI coding tools like Claude Code and Codex throughout the week and measure how quickly teams can go from idea to prototype to user feedback. The important metric now is not the volume of code produced, but the speed of the learning cycle.
The direction we’re headed is what I call auto mode development: tight loops from prototype to user testing and refinement to shipping. Agile is replaced by something faster, where the gap between having an idea and testing it with reality is reduced to almost nothing.
So the important question for every engineering leader reading this is now “can we build it?” not. This question has been answered. With a small team and the right tools, you can build almost anything, pretty quickly.
Now the question is: what to build? And do you have the judgment to know?
