Writing Code Is the Easy Part; Everything Else Is Harder#

AI can write software. But building a good product takes much more than writing code.

Imagine asking an AI to build you a flawless Netflix. You describe the interface, the features, video playback, and everything else you expect from the application. After a while, you have something that looks remarkably close to what you imagined and perhaps works surprisingly well. Have you built Netflix? Obviously not. Yet much of the debate about AI and the future of software developers seems to assume that if a machine can generate applications from instructions, developing software will eventually lose its value.

It is true that AI is changing programming. It can generate code, automate tasks, and build prototypes in far less time than it used to take. There is little point in denying that transformation. But there is an important difference between writing a program and building a product that solves a real problem, works reliably, and remains useful over time. Confusing the two means reducing software development to just one part of the process.

The Work Beyond the Code#

A product begins long before we open a code editor. First, we need to understand the problem we want to solve, who experiences it, and whether our proposed solution is worth pursuing. Then come decisions about design, architecture, data, security, testing, installation, and maintenance. We also need to consider what happens when something breaks, when requirements change, or when a technically sound solution turns out to be too complicated for the people who are supposed to use it.

If we also want to turn that product into a business, other questions arise: finding customers, communicating the value of the solution, setting a price, and covering the costs of maintaining it. None of these tasks guarantees success, but ignoring them can cause even technically excellent software to fail. We might even discover that we do not need to build an entire application at all, because a much simpler solution would solve the problem. Knowing what not to build is part of the job, too.

Consider Netflix again. Creating a video player is one thing; running a service with an enormous catalogue, global distribution, compatibility across numerous devices, payments, recommendations, and licensing agreements is something else entirely. Some of that complexity is technical, but other aspects depend on infrastructure, financial resources, commercial agreements, and organisational decisions. AI can help with many of these tasks, but it cannot eliminate the conditions required for a product to exist and operate in the real world.

What AI Really Changes#

Artificial intelligence lowers the barriers to creating software, but it also changes where we need to focus our efforts. If a tool can generate a function in seconds, spending hours writing it manually may no longer make sense. However, we still need to verify that it does what it is supposed to do, that it introduces no errors, and that it fits into the rest of the system. A prototype might work during a demonstration and fail when used with real data, on another device, or under conditions nobody anticipated.

Delegating work to AI does not mean we can stop taking responsibility for the result. The more code a tool generates, the more important it becomes to know how to review, test, and integrate its output. Technical knowledge remains valuable, even if some of its value shifts from writing every line to understanding the system, identifying problems, and making sound decisions. Experience does not necessarily disappear; the way we use it changes.

Nor can we assume that the job market will remain untouched. Some tasks will be automated, certain roles will evolve, and some projects will require fewer people. But that does not mean building good products will become automatic. The point is not to prove that AI will never replace a particular task, but to understand which needs will remain and how we can address them more effectively with the tools available.

An Opportunity to Build Better Things#

This is where I think things get interesting. For a long time, turning an idea into reality has required a considerable amount of technical work, even before we know whether the idea makes sense. AI can reduce that cost, allowing someone working alone to experiment with more solutions, learn new technologies, and develop projects that would previously have required much more time or outside help. It does not guarantee that the ideas will be good or the projects successful, but it expands what we can attempt.

The opportunity is not to produce ever-larger applications or compete with a machine by writing more code. It is to use that capability to solve specific problems worth solving: a tool for a small community, an application that works offline, a program that simplifies a professional task, or a solution that larger platforms have little incentive to develop. We do not need to invent a revolutionary technology or attract millions of users. Sometimes, solving a small but genuine problem well is more valuable than adding dozens of features to a product nobody needs.

This also changes how we learn and work. Programming remains an important foundation, but it should be complemented by knowledge of system design, testing, maintenance, and, above all, an understanding of the problems we want to solve. If our goal is to develop our own products, we also need to learn how to investigate needs, evaluate alternatives, and find out whether people actually benefit from what we build. We do not need to master everything from day one. We can start with small projects, use AI to help us move faster, and acquire the knowledge we need as real problems arise.

Artificial intelligence does not make software development worthless; it forces us to reconsider where its value lies. Writing code may become increasingly cheap, but deciding what to build, for whom, under which constraints, and for what purpose remains a much broader challenge than generating instructions for a machine.

When writing code is no longer the main bottleneck, the important question is no longer who can program the fastest, but who knows what is worth building, how to build it well, and why.