High-Level Languages Hide the Machine. Agents Hide the Engineering. This Is Bad.

Programming is hard.

That was never the bug. That's the job.

A lot of the industry spent years acting like the real problem with software was that too many people had to think too hard about the machine. Then came higher-level languages, bigger frameworks, bigger support layers, and endless convenience layers. Now we have agents on top of that, ready to turn plain English into working-looking output.

People call that progress. Sometimes it is. A lot of the time it is just distance. First we put distance between the programmer and the machine. Now we are putting distance between the programmer and the act of engineering.

That isn't making software safer. It's making it easier for weak engineers to produce more code before anybody notices they don't understand what they built.

The Interview Test

I see this in firmware interviews all the time.

You ask a candidate why you should not use malloc and free in an embedded system. Then you take memory leaks off the table. You say every allocation and every free lines up exactly.

A depressing number of people still say "memory leaks."

That tells you almost everything you need to know. They learned the rule. They never learned the reason.

The people who understand the work talk about fragmentation, timing, recovery, long uptime, and what happens when a system has to keep behaving the same way every time. The bad ones keep repeating the slogan they memorized because that's all they have.

This is what happens when a toolchain, a framework, a language, or now an agent lets somebody get all the way to output without forcing them to understand cost.

What The Languages Did

This is not just about Python. Or C#. Or Java. Or Rust. Pick your favorite argument. The pattern is older than all of them.

Higher-level languages made it easier to stop thinking about the machine. Memory got hidden. Startup cost got hidden. What the program was doing while it ran got hidden. What the finished program was really doing got hidden. In a lot of office software, that trade was acceptable. The machines got bigger. The schedules stayed stupid. People took the deal.

The problem is that habits formed in fat environments don't stay there. They spread. Then those same habits show up in firmware, embedded products, control systems, and other places where the machine still matters.

That's how you end up with firmware engineers asking for a megabyte of RAM and four megabytes of flash to do work that used to fit in a tiny fraction of that. The hardware got roomier, so the discipline got sloppier. Cost didn't disappear. It just got hidden long enough for people to stop respecting it.

What Agents Are Doing Now

Agents are the next step in the same direction.

High-level languages made it easier to write code without understanding the machine. Agents make it easier to build systems without understanding the code.

An inexperienced engineer can now generate drivers, wrappers, control logic, tests, scripts, config files, and whole piles of glue code at a speed that used to require real fluency. The output often looks competent. It compiles. It demos. It even passes quick tests.

That is the danger.

The hard part of engineering was never just producing text that resembles software. The hard part is choosing the right structure, keeping the rules straight, understanding what must never happen, and seeing the failure early enough to avoid building it in. Agents don't remove that work. They make it easier to skip feeling it.

That's why I wouldn't trust a young engineer plus an agent to design anything I'd put in a car, a boat, an oven, a charger, or anything else that can move, lock up, overheat, or hurt someone. Not because the agent writes nothing useful. Because useful isn't the same as safe, and output isn't the same as judgment.

Where Senior Engineers Come From

This also answers the question people keep asking about where senior engineers come from.

They come from years of having to face the machine, the constraints, the ugly failures, and the reasons the rules existed. They come from doing work the slow way long enough to learn what breaks and why. They don't come from living inside comfort layers that keep turning consequences into abstractions.

If younger engineers spend their early years hidden from the machine by the language and hidden from the engineering by the agent, then the pipeline for seasoned judgment gets worse. Not better. Later on, companies act shocked that nobody can think through architecture, timing, failure, startup, memory use, field recovery, or why a simple-looking shortcut is dangerous.

That shouldn't be surprising. We trained people to produce output before they understood consequence.

Pretending Otherwise Makes Bad Software

Programming is hard for reasons that matter.

When tools remove friction by removing contact with those reasons, weaker engineers don't become stronger. They become more productive at generating fragile systems. In easy software that means bloat, slowness, and maintenance pain. In embedded systems it means field failures, mystery bugs, wasted memory, broken updates, bad recovery behavior, and expensive lessons learned far too late.

The machine is still there. The constraints are still there. Reality is still there. Hiding them doesn't beat them.

Before More Output Turns Into More Fragility

If your team is using modern languages and AI tools to increase output faster than engineering judgment, talk with Endvr before speed turns into fragile products.