There is a paradox playing out in software.
AI is becoming extremely good at producing complex code. It can write thousands of lines in seconds. It remembers every framework, every pattern, every best practice ever published.
Yet the most valuable engineers in the AI era are not the ones using AI to produce more code. They are the ones using AI to produce less code — simpler code, clearer architecture, systems that are easier to change.
The reason is that two old principles just became the most important skills of the next decade.
First principles
First-principles thinking is simple: instead of applying ready-made answers, return to the basic facts of your situation and build the answer from there.
In 2016, I needed an MQTT client for the ESP32. The available libraries were written for systems with plenty of memory. Porting one of them down would have inherited assumptions that no longer held.
Instead, I went back to basic facts — what MQTT actually is, what the ESP32 actually has, what IoT actually needs, what an API actually has to look like. Written from those facts, the result was small, optimized, and simple enough to use in ten minutes. That client became esp-mqtt, the official MQTT component of ESP-IDF. The original design decisions still hold nearly ten years later.
The difference was not coding skill. It was the willingness to reject the ready-made answer and return to basic facts.
This is the kind of judgment AI will accelerate the need for — not reduce. Because AI will always give you the most common best practice, the most-read article, the most-starred framework. AI is a consensus aggregator. It does not know your context.
The only person who knows your context is you. Using that context to reject the ready-made answer is what first-principles thinking is.
KISS — not a slogan, math
KISS — Keep It Simple, Stupid — has been reduced to a sticker on monitors since the 1960s. People have forgotten what it actually means.
What it actually means: complexity has nonlinear cost. Each component you add to a system does not add cost — it multiplies it.
A system with 10 components is not twice as complex as a system with 5. It is 4 to 8 times more complex — because the number of interactions between components grows quadratically.
This is why five-year-old enterprise systems are usually unmaintainable. Not because the code is bad. Because accumulated complexity has exceeded the cognitive capacity of anyone who can hold the whole thing in their head at once.
KISS is not stylistic advice. It is insurance against the exponent of complexity itself.
esp-mqtt is itself an exercise in KISS. The MQTT spec has many optional features — retained messages, will messages, QoS levels, session persistence, keep-alive negotiation, multi-level wildcards, and dozens more. A library that exposes all of them generously would be impossible to fit on an embedded chip with limited RAM. The discipline was the opposite: figure out which features an IoT device actually needs in production, implement those well, and leave the rest out. The library is small because most of it was deliberately not written.
The best engineer I ever worked with had a line: "Anyone can add features. The good ones know what to cut."
In the AI era, that line matters more than ever. AI makes adding terrifyingly easy. One prompt, hundreds of lines of code. One question, ten features proposed.
People without KISS in their heads will use AI to build over-complex systems. Six months later, no one can maintain them — not even AI, because AI does not understand the system any better than you do.
People with KISS in their heads will use AI to do less. AI writes a function, they delete half of it. AI suggests a framework, they choose not to use it. AI creates an abstraction layer, they inline it back.
The resonance — why these two principles together beat AI
First principles helps you reject wrong answers from AI. KISS helps you cut down when AI produces too much.
Together, they produce what AI does not have: judgment.
AI can produce every plausible solution. It cannot pick the right solution for your context. This is not a problem a stronger model will solve — it is a structural problem about information.
To pick the right solution, you need to know:
- The specific context (only you know)
- The real constraints (only you know)
- The long-term goals (only you know)
- The tradeoffs you are willing to accept (only you know)
AI never has enough of this context, however large the model. Because this context lives in your head, in your team's culture, in your customer history, in the small decisions no one writes down.
The engineer who uses AI effectively is not the best prompter. It is the one with the best judgment about when not to listen to AI.
Adaptability — the skill that defines the next decade
There is one more property that connects first principles and KISS with AI: adaptability.
A system built with first principles and KISS has a property that complex systems do not: it can change.
When MQTT 5.0 arrived years after the first version of esp-mqtt, adding support did not require a rewrite — it was an extension of the existing architecture. The simple foundation absorbed the new protocol without breaking.
When requirements change — and they will, every six months in the AI era — simple systems can be refactored. Complex systems have to be rewritten or abandoned.
The pace is accelerating. The best AI model today will not be the best in six months. The hot framework today will be replaced. The question is not "which technology to bet on" — it is "how do you build systems that can adapt to whatever technology comes next."
The answer: build the simplest system that solves the current problem, with assumptions made explicit and challengeable.
Systems like this are not an investment for today. They are an investment for five years from now, when you will have to refactor them four times with four new technologies.
Why AI will reward this way of thinking
Another paradox: AI works best with simple code.
Give AI a complex codebase with thousands of abstractions — AI will produce bugs. Give AI the same codebase with clear structure and few layers — AI will produce correct code.
Engineers who build KISS systems do not just help humans maintain them. They build systems AI can assist with.
In the next five years, teams with simple systems will ship ten times faster than teams with complex systems — not because they are better engineers, but because their AI can help more.
This is the real multiplier of the AI era: not who uses the most AI, but who has the codebase AI understands best.
A test
Before you write your next function, ask:
What basic fact in my context does this function exist for?
If there is no clear answer — the function is dead weight.
Is there a simpler way to solve this problem?
If there is — use the simpler way.
How long would it take a new engineer to understand this system?
If more than a week — the system is past the KISS threshold.
These three questions are not philosophy. They are the math of the complexity exponent meeting the pace of AI change.
Engineers who do not ask these questions will write more code than ever in the next five years. And they will maintain fewer working systems than ever.
Engineers who do ask these questions will write less code. And they will ship the products that matter.
Closing
Two old principles — first principles and KISS — just became the skills that define an engineer in the AI era.
Not because they are new. Because they finally have an amplifier.
AI amplifies good judgment. AI also amplifies bad judgment. The difference between them is not prompting skill — it is the ability to return to basic truths and to know when enough is enough.
The best engineers of the next ten years will not be the ones who know the most frameworks. They will be the ones with the judgment to use AI without being driven by it.
That is the real engineer — not the one who writes code, but the one who decides what code not to write.