The limiting factor in software engineering is no longer the code itself.

      For a significant part of software history, planning was considered essential. You had to plan before anyone began typing, as the consequences of developing the wrong product could be extremely severe, particularly for startups, making accurate initial planning the only logical approach. Implementation costs were high, engineering resources were limited, and changing course after a team had committed could result in months of delays. The entire framework of contemporary software development, including roadmaps, prioritization methods, and quarterly planning rituals, evolved as a response to this fundamental economic reality.

      However, this reality has changed, and many engineering organizations have not adapted. AI coding tools have drastically reduced the cost of transforming ideas into functioning software. What once took weeks of implementation can now be explored in just a few hours. You can request an agent to prototype three different approaches overnight and discard the two that don't hold up when you review them in the morning. Rather than relying on a slide deck to challenge a concept, you can create a working demo. The economics have flipped: planning and processes, which used to be cheaper than building, are now more expensive than the actual building process itself.

      This shift significantly alters how engineering teams should function. The notion of a perfect plan is obsolete, and even if it existed, the time needed to create one would mean that you have already fallen behind someone who has begun building. At Synthesia, we decided to directly test this concept. Each quarter, our product, engineering, and R&D teams gather in London to plan for the upcoming three months. Traditionally, we spent most of that time analyzing, debating, and prioritizing to create a plan that justified the implementation costs.

      During our latest meeting, we reversed that order by replacing the initial two days of planning with a hackathon. Two hundred individuals from across engineering, product, design, legal, research, and talent formed 70 teams and built continuously for 28 hours. The task was straightforward: take an idea, create it, and produce a two-minute demo video. There were no detailed specifications or extensive planning—just build.

      The outcome astonished us. One of the winning teams, consisting of five engineers, completely redesigned our video editor from the ground up. This video editor offers a PowerPoint-like interface for users on our platform to create videos with AI avatars. The engineers provided a full end-to-end reimagining of the product, emphasizing interactivity, branching narratives, and multi-avatar storytelling.

      This was not an isolated incident; a similar pattern appeared across all 70 teams: when you give people clarity and eliminate friction, they can progress much faster than anticipated. The takeaway from this experiment is that execution is no longer the limiting factor; judgment has become the key issue. This might challenge the long-held beliefs of many engineering leaders, who have spent years optimizing organizations for execution efficiency metrics—how many features were launched, how many story points were completed, and how quickly the backlog decreased.

      However, as building becomes less expensive, the bottleneck shifts upstream. The challenge is no longer about getting the code written; it is about determining which code is worth writing initially. By "judgment," I refer to four specific aspects. First, the ability to help product managers quickly address the appropriate customer problem, which necessitates distinguishing between what is intellectually appealing and what genuinely matters to users and the business.

      Secondly, defining what "great" entails before starting because if you cannot articulate that standard, you will not recognize it when you encounter it. Thirdly, it involves knowing when something is sufficiently good to present to a user—not perfect or polished, but adequate for learning. Finally, it requires the capability to eliminate ideas swiftly.

      When experimentation can occur in parallel, the most valuable skill becomes the ability to abandon unsuccessful ideas quickly, rather than becoming attached to the first attempt simply because it was costly to produce. The most successful engineering teams in the coming years will not excel based on code output; they will prosper based on taste.

      This has significant consequences for how we view the engineering role. We are transitioning from being builders to orchestrators. AI agents can now carry out substantial portions of the development process from start to finish. The engineer's role is increasingly focused on selecting the right problems, reviewing outputs, and iterating quickly—spending less time writing every line and more time managing systems that generate code for you.

      Some may view this as a threat, but I believe the opposite is true. The monotonous aspects of engineering, such as boilerplate code, repetitive wiring, and tasks that were never exciting, will be the first to be automated. What remains will be the work engineers have always desired to spend more time on: deeply understanding problems, crafting elegant solutions, and making tough decisions on what to build and what to discard. The craft will be distilled to its essence.

      At Synthesia, we are committed to this transition. We monitor weekly usage of AI coding tools like Claude Code and Codex and assess how quickly