For most of the history of software, planning was sacred. You had to plan before anyone touched a keyboard, because the cost of building the wrong thing could be so punishing, especially for startups, that getting it right upfront was the only rational strategy.
Implementation was expensive, engineering time was scarce, and changing direction once the team had committed to an approach could set you back months.
The entire apparatus of modern software development, the roadmaps, the prioritization frameworks, the quarterly planning rituals, grew up as a response to that single economic fact.
That fact is no longer true, and most engineering organizations haven’t caught up.
AI coding tools have collapsed the cost of turning an idea into working software. What used to take weeks of implementation can now be explored in hours.
You can ask an agent to prototype three competing approaches overnight, and throw away the two that don’t hold up when you wake up in the morning.
You can challenge an assumption with a working demo instead of a slide deck. The economics have inverted: planning and process used to be cheaper than building, and now building is cheaper than the meetings you’d hold to decide what to build or how to build it.
This changes everything about how engineering teams should operate. There is no such thing as a perfect plan anymore, and even if there were, the time it would take to produce one means you’ve already lost to someone who just started building.
At Synthesia, we decided to test this idea in the most direct way we could. Every quarter, our product, engineering, and R&D teams come together in London to plan the next three months of work.
Historically, we’d spend most of that time in rooms analyzing, debating, and prioritizing. The goal was to emerge with a plan that was good enough to justify the cost of implementation.
During our most recent meeting, we flipped the sequence. We replaced the first two days of planning with a hackathon. 200 people from across engineering, product, design, legal, research, and talent formed 70 teams and built for 28 hours straight.
The brief was simple: take an idea, build it, turn the result into a two-minute demo video. No detailed specs, no over-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 where users of our platform create videos with AI avatars.
The engineers delivered a full end-to-end reimagining of the product, focused on interactivity, branching narratives, and multi-avatar storytelling.
This wasn’t an outlier; across all 70 teams, the same pattern emerged: when you give people focus and remove friction, they can move far faster than anyone expected.
The lesson we took from this experiment is that execution is no longer the constraint, judgement is.
This might contradict the operating assumption that most engineering leaders have been working with for their entire careers. We have spent years building organizations optimized for execution throughput: how many features shipped, how many story points completed, how quickly the backlog shrinks.
But when building becomes cheap, the bottleneck moves upstream. The hard part is no longer getting the code written. Instead, it is 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 address the right customer problem faster, which requires distinguishing between what’s intellectually interesting and what actually matters to users and to the business.
Secondly, defining what “great” looks like before you start, because if you can’t articulate that standard, you won’t recognize it when you see it.
Thirdly, it’s about knowing when something is good enough to put in front of a user, not perfect, not polished, just sufficient to learn from. And finally, being able to kill ideas quickly.
When you can try many things in parallel, the most valuable skill becomes letting go of the ones that aren’t working, rather than falling in love with your first attempt because it costs so much to produce.
The best engineering teams in the next few years will not win on code output, they’ll win on taste.
This has real implications for how we think about the engineering role itself. We are moving from being builders to being orchestrators. AI agents can now execute large parts of the development process end to end.
The engineer’s job increasingly becomes choosing the right problems, reviewing outputs, and iterating at speed. Less time writing every line and more time directing systems that write lines for you.
Some people find this threatening. I think it’s the opposite. The tedious parts of engineering, the boilerplate, the repetitive wiring, the work that was never actually the interesting part, that’s what gets automated first.
What remains is the work that engineers have always wished they could spend more time on: understanding the problem deeply, designing elegant solutions, making the hard calls about what to build and what to throw away. The craft gets distilled to its essence.
We’re holding ourselves accountable to this shift at Synthesia. We’re tracking week-over-week usage of AI coding tools like Claude Code and Codex, and we’re measuring how quickly teams can move from idea to prototype to user feedback. The metric that matters now is the speed of the learning loop, not the volume of code produced.
The direction we’re headed is what I’d call auto-mode development: tight loops from prototype to user testing to shipping to refinement. Agile is being replaced by something faster still, something where the gap between having an insight and testing it against reality shrinks to nearly nothing.
So the question that matters for every engineering leader reading this is no longer “can we build this?” That question has been answered. You can build almost anything, remarkably fast, with a small team and the right tools.
The question now is: what should you build? And do you have the judgement to know?
