The value isn't in the code, it's in the system
Writing code has become easy. What's hard and valuable now is assembling a stable system from many parts, fitting it into existing infrastructure, and making the result work for everyone: users, product, security and the business.
Five or ten years ago, being able to write code was a rare and expensive resource. A good engineer was worth their weight in gold, and the very ability to “build software” separated those who could ship a product from those who couldn’t. Today that has changed. AI tools write a large share of the code for the developer, mature frameworks handle the routine out of the box, and finding a team that will “write the code” is easier and cheaper than ever. Yet products haven’t become any easier to get right, and failed projects are no less common. The value has simply moved — to a place where it isn’t always noticed.
Code is no longer the bottleneck
The bottleneck used to be development itself: writing the function, the screen, the service was slow, expensive and demanded rare skill. Now it’s faster and more accessible — almost any engineer can put together a piece of functionality, often half-automatically. That’s good news, but it changes the rules. If almost anyone can write code, then “we can program” stops being an advantage and says almost nothing about whether a working business will come out of it. The bottleneck has moved up a level: from individual lines to how they add up to a stable whole.
The value is in the system, not the components
A modern product isn’t a single program but a living system of dozens of connected parts: web and mobile apps, backend services, databases, integrations with external systems (payments, accounting, logistics), analytics, monitoring, backups, access control and security. Each part on its own is a solvable task. The real difficulty begins where they have to work together: consistently, predictably and without surprises under load. And a system almost never lives in a vacuum — it has to fit into what the company already has: existing infrastructure, legacy systems that can’t be switched off, processes that already run. This level, assembly and integration, is where the core difficulty sits today. And it’s this skill that’s expensive, because it can’t be replaced by AI or by one more pair of hands.
Building the system isn’t enough: it has to satisfy everyone
Even a system that’s technically assembled and working isn’t the result yet. The result arrives when everyone who depends on it is satisfied — and there are usually more of those parties than it seems. Users need it clear, convenient and fast, or they simply leave. Product managers need to evolve it without rewriting half of it. Security needs data and access under control and risks understood. Operations need to support and fix it at three in the morning, not only “while the author is around”. The business needs it all to pay off. The catch is that these needs often conflict: what’s convenient for the user can be hard for security; what’s fast today can be unmaintainable tomorrow. The architect’s job here isn’t to write the most elegant code but to find the balance where the system works, evolves and satisfies everyone at once. That’s work more about negotiation and management than pure engineering.
What this means for founders and investors
From this follows a practical conclusion. When you assess a team, a contractor or a product, the question “can they write code” decides almost nothing today — many can, and more every year. Other questions matter far more. Can they build a system that won’t fall apart at ten times the users? Will it fit into what you already have, or demand tearing everything down and starting over? Won’t it create problems where you don’t expect them — in security, in support, in cost of ownership? More often than not, the real risk of a deal or a project hides exactly at the seams: between services, between teams, between what the business wants and what actually gets built. And that’s where the real value hides too. Code stopped being scarce long ago. What’s scarce is the ability to assemble it into a system that works and satisfies everyone — and that’s what to look for in the people you trust with technology decisions.