The bottleneck in software engineering is no longer in the coding process.

      For much of software history, planning was regarded as essential. Before anyone could start coding, a thorough plan had to be in place due to the significant risk of developing the wrong product, especially for startups, making accurate initial strategies critical. Implementation costs were high, engineering resources were limited, and shifting directions after the team committed could delay progress by months. The entire framework of modern software development, including roadmaps, prioritization systems, and quarterly planning rituals, evolved to address this economic reality.

      However, this reality has changed, and most engineering teams have yet to adapt. AI coding tools have drastically reduced the costs associated with turning concepts into functional software. Tasks that previously required weeks of implementation can now be pursued in hours. You can instruct an AI to create prototypes of three different approaches overnight and discard the two that don’t perform well by morning. You can validate an assumption through a working demo rather than just a presentation. The economic landscape has flipped: planning and processes used to be less expensive than building, but now the cost of building is lower than holding meetings to determine what and how to create.

      This shift dramatically alters how engineering teams should function. Perfect plans no longer exist, and even if they did, the time required to create one means you’re likely to fall behind those who have already begun building. At Synthesia, we decided to put this notion to the test in a straightforward manner. Each quarter, our teams from product, engineering, and R&D gather in London to organize the upcoming three months of work. Traditionally, we spent the majority of our time in discussions, analyzing and prioritizing to develop a plan deemed sufficient to justify the implementation costs.

      In our latest gathering, we changed the approach. The initial two days of planning were replaced with a hackathon, where 200 individuals from engineering, product, design, legal, research, and talent formed 70 teams to create for 28 consecutive hours. The instruction was simple: take an idea, build it, and produce a two-minute demo video — no extensive specifications, no excessive planning — just build.

      The outcome was surprising. One of the winning teams, consisting of five engineers, entirely rebuilt our video editor from the ground up. This editor offers a PowerPoint-like interface for users on our platform to create videos with AI avatars. The engineers provided a full reimagining of the product, emphasizing interactivity, branching narratives, and multi-avatar storytelling. This was not an isolated case; a similar trend emerged across all 70 teams: when given focus and reduced friction, people can progress much faster than anticipated.

      The key takeaway from this experiment is that execution is no longer the limiting factor; judgment is. This may challenge the longstanding operational assumptions many engineering leaders have held throughout their careers. We have spent years structuring organizations to maximize execution output: tallying features shipped, story points completed, and how quickly the backlog is reduced. However, as the cost of building decreases, the bottleneck shifts upstream. The challenge is no longer in writing code but in deciding which code is worth writing from the very beginning.

      When I refer to judgment, I mean four specific aspects. First, helping product managers identify the correct customer problem more rapidly, which requires differentiating between what is interesting intellectually and what truly matters to users and the business. Second, establishing what “great” looks like ahead of time, since failing to define that standard means you won’t recognize it when it appears. Third, understanding when something is adequate to present to a user — not perfect, not refined, just suitable for learning. Finally, having the capability to swiftly abandon ideas.

      When one can explore numerous options simultaneously, the most valuable skill becomes discarding those that aren’t effective rather than becoming attached to the initial attempt because it took considerable resources to produce. The best engineering teams in the coming years will not excel due to high code output but rather due to their discernment.

      This transformation has significant implications for the engineering role itself. We are shifting from being builders to becoming orchestrators. AI agents can now handle extensive portions of the development process autonomously. The engineer's role is increasingly about selecting the right problems, reviewing the outputs, and iterating quickly—spending less time writing each line and more time managing systems that generate lines for them.

      Some individuals perceive this shift as a threat, but I believe it offers the opposite effect. The monotonous aspects of engineering, such as boilerplate coding and repetitive tasks, which were never the compelling parts, will be automated first. What remains is the work engineers have long wished for: deeply understanding the problems, crafting elegant solutions, and making tough decisions about what to create and what to discard. The essence of the craft is distilled.

      At Synthesia, we are holding ourselves accountable for this evolution. We are monitoring the weekly use of AI coding tools like Claude Code and Codex, and we are assessing how swiftly teams can transition from idea to prototype to user feedback. The critical metric now is the