Fast Code, Weak Engineers

We are shipping faster than ever.

Every week, I learn about a new model, tool, or supposedly new default; a new way to code and deliver apps, to do the exact same thing we've been doing for about 15 years. Each new tool comes with a promise to be the new default.

I'm not against the use of AI, I use it all the time myself (including in this article), but the fact is that if we stop evolving by delegating all our tasks to automated tools, we are doomed to collective failure.

Indeed, there are many tasks in which these models help us and make our lives easier, as demonstrated by empirical research that evaluated AI coding assistants in real software projects. A recent GitHub Copilot study, covering 15 different development tasks, found significant time savings (up to 50%) in repetitive tasks and simplistic coding, but sharp performance drops in complex tasks with multiple files and in proprietary contexts. Precisely the areas that require high-level reasoning and architectural thinking. Copilot Paper

I've heard about how to get rich with GPT, or how someone built a fully autonomous AI agent developer that works 24/7 for free forever, or even "this is the model that will fully replace humans." However, there are two things I'm sure of: I've never coded so fast before, and I've never produced worse code than I do now.

Okay, but if those tools are so good and can improve my time by avoiding the need to spend hours reading documentation, forums, and testing ways to do things, then why is my code getting worse?

Because we are getting comfortable.

We are outsourcing thinking to tools and calling it productivity. Less hands-on means less intuition. Less struggle means less learning. We no longer debug deeply, trace flows, or wrestle with edge cases. We accept generated answers, paste them, and move on.

Over time, this trains us to be operators, not engineers. Our skills atrophy. Our instincts weaken. When something breaks, we are slower, less confident, and more dependent. Speed grows. Competence shrinks.

Over the years, “laziness” was actually one of the best traits a programmer could have.

We were lazy about manual work, repetitive tasks, and inefficient processes. That discomfort pushed us to build better systems. We wrote complex software to make life simple. We automated chaos. We replaced paperwork, bureaucracy, and human error with logic, code, and structure.

That kind of laziness was creative. It demanded understanding. You had to fully grasp a problem before you could eliminate it. You had to master complexity to hide it.

Today, our laziness is different.

We are not lazy about bad processes anymore. We are lazy about thinking. Lazy about learning. Lazy about mastering fundamentals. Instead of simplifying the world with software, we are simplifying our responsibility as engineers.

We are no longer fighting friction. We are avoiding it.

" A smooth sea never made a skilled sailor. "

In simple terms, here’s what happened.

For decades, we wrote the code. We documented the systems. We debated architecture. We made mistakes, refactored, rewrote, and shipped again. Byte by byte, we built an enormous body of digital knowledge — patterns, abstractions, frameworks, libraries, discussions. Thousands upon thousands of human decisions embedded in code.

With enough hard work, we created something remarkable: tools capable of consuming all that data and generating impressive results through statistical crossing, analysis, and prediction.

That is extraordinary.

But now we face a paradox.

The very systems built from our accumulated effort are becoming comfortable substitutes for the effort itself. Instead of producing new depth, we increasingly remix existing depth. Instead of pushing boundaries, we optimize within them.

We reached a point where what already exists feels sufficient.

And sufficiency is dangerous.

Progress does not stall because tools are powerful. It stalls when creators become passive. When friction disappears completely, so does the incentive to explore beyond what is already known. If we stop struggling, stop questioning, stop building beyond prediction, we risk stagnation — not because AI replaced us, but because we quietly replaced our own drive to create.

The danger is not automation.

The danger is comfort.

And history shows something simple: a smooth sea never made a skilled sailor.

If we want stronger engineers and stronger systems, we must be willing to face rough waters again.

---

I work with teams building production systems and developer tooling. If this topic resonates, you can find more of my work at https://huntermussel.com.