The more I work with AI, the more I realize that we, the humans, have become the bottleneck in the code production process. We participate in the loop at least at two critical points: defining the task and checking the results. These two points are now the main areas where we need to optimize how humans and AI talk to each other. In both cases, the languages we use aren’t really fit for the job. On the input side, we use human languages like English to prompt the model. On the output side, the model gives us code in languages originally designed for humans to write by hand. I believe this is exactly where we’ll see new solutions very soon.

I’ll save the topic of how we define tasks for another day. Today, I want to talk about the output—the code itself. Current models can already produce high-quality code if we give them clear instructions and constraints. But they are still trying to produce that code in languages built for people. And people are diverse. Because of this diversity, we’ve created dozens of similar programming languages that solve the same problems in different ways. Even within one language, there are often ten different ways to solve the same task.

Which way is the «right» one? Right now, that’s a subjective choice. If a programmer wants the AI to match their specific style, they end up micromanaging the model, specifying every tiny detail, or iterating until the code looks «right.» Sometimes they just give up and write it themselves. This happens because AI models are optimized for solving the problem in the most pragmatic way possible, which often doesn’t align with human aesthetic choices. AI isn’t afraid of long, monotonous code that human-centric languages try to avoid. Most modern languages are full of «syntax sugar»—shorthand constructions designed simply because people hate typing a lot of code. AI doesn’t have that limitation. Our current languages are optimized for human writing and reading; they simply aren’t optimized for AI.

This creates a massive problem when it’s time to verify the code. A developer spends a lot of time just trying to understand what the model wrote because there are so many ways the AI could have approached the problem. Since reading and checking code is much slower than generating it, this verification stage becomes the ultimate blocker. The human effectively limits the productivity gains we could be getting from the AI’s speed.

I think the solution will be a new programming language designed specifically for AI generation and human inspection. It won’t be a raw bytecode, but a high-level, compact language—perhaps as concise as Go and as readable as Python. It would use English-based notation to describe high-level blocks and operations, which would then be compiled into a platform-specific bytecode, similar to how Java or .NET works. In this system, you wouldn’t necessarily need to check every single detail, but you’d have the ability to perform high-level audits and selective inspections whenever needed.

This language would likely be very compact, with essentially one «correct» way to solve any given task. It would strip away the syntax sugar—which was only there to save us from typing—and focus on high-level abstractions, incorporating the best design patterns we’ve developed as an industry. Ironically, this language will probably be designed by AI itself. Models will learn it through massive datasets created by translating millions of existing code examples into this new format. Whoever establishes this standard first will likely own the new industry standard.

When this happens, all existing systems will suddenly feel like «legacy» code. While the current generation of programmers will continue to maintain old systems, a new, AI-native generation will focus almost entirely on this new way of working. Old languages won’t disappear, but their importance will drop rapidly. We are moving toward a future where writing code in human-optimized languages will seem as inefficient as writing in assembly does today.