Short answer: not anymore.
Until roughly the end of last year, yes, you did. I still remember building prototypes at Yandex Games in mid-2025, when I was still telling the LLM which JS functions to write and how to fix the CSS. But between October and December, Anthropic and OpenAI released models that are so good that looking at, reading and understanding code became completely unnecessary. And when I say "completely," I really mean it.
Today, the vast majority of developers on the vast majority of projects program in English. Not in Python or TypeScript, but in plain human language. Of course, there are corner cases and nuances. But even there, what matters is deep knowledge of the product, not writing code by hand. If you can frame the task and explain those nuances to the model, it will very likely handle it without you.
What you need instead of code
Understanding the logic is enough. Understanding architecture and testing is highly desirable. Or at least use skills that tell the model HOW it should work.
Your job is to describe the properties of the system: what it's made of and how it works. In case A, the product does B, and that must always hold. The product's logic must match your own product logic.
If the code is covered by tests and does what you intended, but some corner case was missed, it will surface and get fixed. If anyone hopes to write bug-free code, I have bad news for them: bug-free code doesn't exist. Reading code doesn't protect you from bugs. Tests and fixes do.
What it takes to build a product
- Know what you're building. Or be ready to walk this path for a long time, figuring things out and correcting course as you go.
- Be able to describe the product. How it should look and work. What rules it follows. Be prepared to write or talk a lot. A. Lot. All the code the model writes comes from your description.
- Understand the architecture. Backend, frontend, database, how they connect and how it all gets deployed to the server. Which external services you depend on: payments, cloud, email.
- The bigger the product, the deeper the layer. What objects and modules make up the backend and frontend, where the sources of truth live, how to test it all properly. You need this so the model doesn't invent a new solution every time in key parts of the product, doesn't spawn new data stores that later drift apart, and covers all cases with tests, not just the ones that came to mind. Otherwise, as the product grows, everything starts falling apart.
- Documentation the model maintains itself. The model reads code brilliantly, but it doesn't know about past decisions, sources of truth or object boundaries. That isn't always visible in the code, so it needs to live in documentation. Then the model knows where to look. By default, models write documentation for themselves, in technical language. I ask the model to keep a separate, up-to-date file describing the architecture in plain words, at the level of a product manager or designer.
Notice: none of these points says "read the code," "debug" or "figure out how it works."
You don't need to know everything above right away. If you're building something big enough, you'll run into all of it yourself and realize what you're missing. That said, understanding it up front will save you a lot of time along the way. That's why developers have a huge advantage here: they know what a well-built system looks like.
What about design?
This is trickier: models see design only through the abstraction of code. But they already handle it surprisingly well, especially with a ready-made design system. In almost all my projects I use shadcn as the foundation: it scales well and looks good. If design isn't your strength, or you just want to save time, try Claude Design. Given an existing structure and a couple of finished screens, it builds new ones quickly and neatly. Provided, of course, that you describe exactly what you want. Ideally in full detail.
But in design, taste and empathy for the user are what matter, and designers have an obvious advantage here. The code inside can be ugly and still work, and no one will ever see it. But everyone sees the landing page and the interface. People judge a book by its cover, and the audience's standards here are very high. Develop your taste, look at good design. Developing taste and making good design with an LLM is much faster than learning to make the same design with your own hands. It doesn't take years of practice.
Bottom line
Try building. Become the Builders of your own products, or of the products you work on. To me, this already looks like a pretty obvious future.
A few months from now, this post may well be completely outdated. New models will come out that are smarter and more autonomous. You won't need to think about the system's internals even at the level of architecture and details. It will be enough to understand how it should work and what problems it should solve. Only your product vision and your drive to build it will matter.
The product trio is giving way to the product solo.
