AI Doesn’t Make Compiler Theory Obsolete. It Makes You Its Bottleneck
AI now writes any compiler in no time. The problem is no longer building one, it’s seeing that you need it.
SMARTER THAN THE AI
AI Doesn’t Make Compiler Theory Obsolete. It Makes You Its Bottleneck
AI now writes any compiler in no time. The problem is no longer building one, it’s seeing that you need it.

Some time ago I argued that universities should keep teaching compiler techniques, not because students would ever have to write compilers, but because those techniques have far broader practical applications. Yet today AI seems to have buried that argument: it knows all the theory and can do it for us. But has it killed the argument? Or has it supercharged it?
Old argument, new excuse
I wrote that article precisely because I was starting to see universities dropping compiler techniques from their syllabus. The argument seemed solid: writing compilers is very niche knowledge, needed only in a handful of applications. From that point of view, most programmers in the future would never write a compiler in their entire life.
Naturally, I disagreed. Writing a compiler, like a C or JavaScript compiler, is one thing, but everything you can do with compiler theory is another. Limiting its application only to writing a programming language compiler was too narrow. This theory offers more than just performing very advanced processing on user text, it can also help simplify code and make it more readable.
Yet, with the AI shadow, now the argument that you do not need to know how to build compilers seems to be gaining strength. We have AI that knows all of compiler theory and can write the text-processing code for us.
But… is it a valid argument or an excuse?
Uses nobody suggested
To show this more easily, I will show you one of the uses I put compiler theory to.
I had a small calculator exercise for students. I gave them the tests and they had to implement them. There were many cases, and each test could look something like this:
test('Simple addition', () => {
const calculator = new Calculator();
calculator.press(4);
calculator.addition();
calculator.press(2);
calculator.equals();
expect(calculator.getDisplay()).equals('6');
});
The test is readable, but it is hard to follow. Multiply it by forty or more and you quickly lose track of what is there and what is not. But by leaning a little on compiler knowledge, I can write a small function that acts as the user and checks everything:
test('Simple addition', () => {
runCase('4 + 2 = [6]');
});
Much more readable, right? And it can be improved even further, because instead of having 40 tests I could make a table:
test.each([
'[0] # display starts at zero',
'1 [1] # pressing a digit shows it',
'12 [12] # digits concatenate',
'4 + 2 = [6] # a basic sum',
'5 × 3 = [15] # product works the same',
'7 - 9 = [-2] # negative results',
'9 ÷ 0 = [Error] # division by zero errors',
'2 + 3 × 4 = [14] # respects precedence',
])('%s', runCase);
Anyway, I trimmed some cases, but… you can tell the difference, can’t you? Can you imagine what this would look like going case by case?
So another use I have relied on a lot is configuring dependencies between different modules and pieces of software. For example, we could programmatically write something like:
const system = new System();
system.createModule('A');
system.createModule('B');
system.createModule('C');
system.createModule('D');
system.connect('A', 'B');
system.connect('A', 'C');
system.connect('B', 'C');
system.connect('C', 'D');
Or, instead, using a bit of compiler theory magic we could write something like:
const system = compileSystem(`
A -> B -> C -> D
A -> C
`);
Clear, right? With the first, to know what it is doing you often need pencil and paper to reconstruct the graph. With the second, you see the graph. And implementing the second is ridiculously simple: split lines and then split on ‘->’.
And there are many more cases like these. In some, you do not even need to write the compiler because it already exists. Many configurations can be plain YAML. One example would be configuring an ECS, an entity component system, typical of video games, which can grow and adapt effortlessly with a YAML file:
goblin:
extends: enemy
health: 30
damage: 5
ai: aggressive
drops: [gold, dagger]
resistances: [poison]
So, before moving on: how many of these things does AI offer you?
But AI makes this even more necessary
AI could be the ultimate compiler: it understands almost any language and knows how to interpret it. Except for one detail: it does not always get it right. And that is precisely one of the biggest problems for all of us who are automating things with AI and need to use it for repetitive tasks: it is not deterministic. Today it does it well, tomorrow it makes a mess.
So we find ourselves sailing a sea with two very separate kinds of language: on one side we use natural language to communicate with the AI, and on the other, we have to write code to control or even assist the AI. Natural language and code. And the problem is that if we need to make changes to the latter, either we will have to ask the AI, or we will have to dig in and understand the code it wrote.
Well, it does not have to be that way.
Take Gherkin as an example. Gherkin is a natural-looking language, but one where every sentence has been pre-programmed and performs a very specific action. It is meant for testing and lets you read and understand how systems work. And because it is programmed, it is a deterministic language that will always run the same way.
Scenario: User withdraws cash from ATM
Given john's balance is $200
When john withdraws $100 from the ATM
Then john's balance should be $100
True, it would be a wonderful language to ask the AI to use so we could instruct it deterministically, but there is no reason to limit ourselves to that.
Gherkin is for testing, and it is a tool for any business. But we do more than that. We can have rules written in a language closer to what we need, or simpler. We can have business rules, but also guardrails, or even living written specifications. And all of it tailored to our needs. Things where a single glance tells us what they do and that we can change, all without setting determinism aside.
A third language that is not code, is not natural language, but is deterministic.
It just could be something like:
rule "refund window":
when order.status is "delivered"
and days_since(order.delivered_at) <= 30
then allow refund
else deny "refund window expired"
guardrail "no medical advice":
if response mentions [diagnosis, dosage, prescription]
then block and escalate to human
The AI would construct and maintain the code to run this, and also design the kind of language that we need.
But just one more time, how often does AI offer to do this for us?
We are the bottleneck
Here we come back to the thesis of the article. How many of these things does AI offer? Generally none.
AI has incredible power and a very rich body of theoretical knowledge, but none of it is any use if we do not know how to exploit it.
And we arrive again at a somewhat absurd position where, in fact, even if the AI knows the theory, if we do not know it, we cannot use it.
But luckily we no longer need to know all the theory. Knowing what is possible and how it can help us is enough. So it is no longer about knowing how to do it, but knowing what we can ask for. And once we know that, we can benefit from what the AI knows.
One prompt away
Coming back to the original discussion, where universities were considering removing compiler courses, doing so is still not advisable. Perhaps there is no longer any need to teach it in the same depth, but students do need to know about it. And curiously, AI itself requires that we know what is possible.
And like this, there are many other things. AI holds an impressive amount of knowledge, but much of it is hidden in its latent space. All of it is waiting for the prompt that will wake it up. But that is just it: it is all one prompt away, if we know what to prompt.

Thanks for the read. I usually like to write stories to think about how we understand and apply software engineering, and to make us think about what we could improve. If you liked the article, don’t forget to clap, comment and share. For more insights and discussions, explore my most successful stories on Medium, or just check out my book where I tackle both code and coder struggles.
Previously published about compilers:
메타데이터
- post_id
- d4e6be5e7ef1
- slug
- ai-doesnt-make-compiler-theory-obsolete-it-makes-you-its-bottleneck-d4e6be5e7ef1
- url
- https://medium.com/@drpicox/ai-doesnt-make-compiler-theory-obsolete-it-makes-you-its-bottleneck-d4e6be5e7ef1
- canonical_url
- https://medium.com/@drpicox/ai-doesnt-make-compiler-theory-obsolete-it-makes-you-its-bottleneck-d4e6be5e7ef1
- author_url
- https://medium.com/@drpicox
- status
- ok
- fetched_at
- 2026-09-14 01:12:41