The not-quite-sure-how-famous adage states that “writing is natures way of letting you know how sloppy your thinking is”. I think this is true whenever you get a chance to review your text before it’s submitted. This is true for both english, and coding. I argue that writing code is an inherent part of design, and people who say that code is just 10% of their time are either astronaut architects, do not undestand design, or are part of highly inefficient organizations.

To desing a system, one must first understand the requirements. If this work has not been done for you, you’ll have to do it yourself. This often includes talking to stakeholders, building a mental model, then trying to find how to solve the problems you’ve identified. In many companies, this is done by Product Managers, and as a developer I do not need to have endless meetings with customers. I believe this is more applicable in larger companies.

Once the requirements are somewhat clear, requirements having a tendency of never being truly clear, it’s time to start thinking of a technical solution. I think at this point it’s a good time to start writing some code. There are two aspects to it: focus on the details and focus on the high-level parts. The details are extremly important because performance and correctness stem from them. Performance part is often ignroed by mutilating Knuth’s words, although even for smaller scales this is the difference between having a single postgres DB, and setting up replicated Kafka clusters just to handle 10K items. The high-level parts are equally important. A well designed interface allows a non-suboptimal implementation as well as extensibility.

To test your ideas at either level of design, you have to write code. Whether it’s the queries to test how actual workloads would behave, or the high level API and how easy it is to implement the desired functionality using it. Just like writing is testing your ideas’ mettle, writing code is to test your fantasies against real hardwae and systems. This means that to actually test your ideas, they need to be implemented.

This is where I disagree with the 10% coding crowd. Coding is just the first step. Linus can quoted saying “talk is cheap, show me the code”. It was true then, it is even more true today. I would merely adapt it to “code is cheap, show me the results”. The thing is, LLMs can do a lot of the testing and performance analysis. Writing a decent benchmark is hard; in fact, much harder than decent CRUD. Nevertheless, even here LLMs can help you. You can quickly prototype benchmarks, create synthetic data, or stitch it into your system. Whenever the results don’t match your understanding of the world, you can easily dive into what’s going on. For correctness, you can, these days just prompt the test cases you think are important. Neither benchmarks nor tests created by LLMs are proof of correctness, but they can often easily spot faults.

I do not think AI generated code can be trusted blindly. This is even truer for design, as models tend to iterate (in the worst way possible) on bad design instead of starting over. But the initial exploration of ideas can be sped up significantly. Ask for a prototype and some benchmarks, and you already have a rough idea of where something is going, whether it’s performance or the interface.

An entirely different aspect is reviewing your ideas. Just as code, LLM review can be worthless, often fixating on paranoid correctness while disregarding readability and performance. Stiil, if I get a “brilliant and elegant” idea, LLMs can often offer a refutation.

In short, I think AI models can speed up a lot of the work a programmer does.

That is not to say that this entire thing has no price. I am a firm believer that what you don’t use atrophies, including your brain and your thinking. Using AI models has a high risk of intellectual complacency. You should pay attention to your thinking, and catch yourself when you’re offloading thinking. Perhaps even then, you’ll atrophy your brain. But at least for some time, you would be faster.