To me, engineering craftsmanship is the care that goes into deciding what to build and owning every line of the result. The current market is trying to prove that AI made code cheap to produce. Judgment and the risk of accountability still cost what they always did, because judgment only forms when you put real effort into creating. Skip the effort, and the craft gets scarce.

I've been trying to find the time to put my thoughts on engineering craftsmanship into a post: what I believe it really is, and what it means to me.

Last October I gave a talk with the same title at Patras Tech Talk (slides). This post picks up where the talk left off, one year later.

I am old enough to remember how software engineers treated software before the mass adoption of Large Language Models (LLMs). It was a period when people were truly intrigued by new ideas, and the limits of hardware pushed them to find creative ways to move technology forward without compromising quality.

It was a time when smart, passionate and dedicated engineers were necessary for a product to truly succeed.

They invented new frameworks, new paradigms and new languages. They spent countless hours, across many different mediums, discussing and co-authoring Request for Comments (RFC) documents, the specs that laid the foundation of what we call technology today.

From small companies to big ones, many individuals, scattered across every level of their organizations, shared one common goal: to design and deliver efficient, well-crafted software they could be proud of, software that either improved people's lives or inspired other engineers to grow their craft.

But today, that time is long gone.

Generative chaos

AI has been adopted explosively across many markets. I don't mean traditional artificial intelligence, but the huge demand for, and supply of, LLMs and LLM wrappers. As a result, we live in a time where theories like the dead internet theory are becoming more and more plausible.

Most content is now either generated or augmented by AI. People rely heavily on LLM tools to automate their work, to do things they couldn't do before, or to "improve" the quality of their work.

Companies found new metrics to track, mostly vanity ones like tokens used and lines of code (produced by AI, this time). That pressure has forced employees at every level to rely on AI to some extent. It is now hard to tell what is generated and what isn't, and that has changed how people interact with each other.

The vibe era and the Dunning-Kruger effect

In the talk I called this the vibe era. Low-code, no-code and now AI-code dropped the barrier of entry to writing code to almost nothing. We can now produce a lot of code really fast, often with limited understanding of what it does, and the push for speed has never been higher.

We got lazy. We always wanted to be lazy, and LLMs looked like a way out of hard work. Or maybe they are a way to amplify our Dunning-Kruger effect, the bias where people with limited skill in an area overestimate their ability in it. A tool that answers every question with confidence makes it very easy to feel competent without being competent.

Pushing the responsibility to the recipient

With so much of our work shifted to LLMs, a hard battle starts: reviewing the work.

In the past, writing code took time. There was a ceiling on how much code one developer could write in a day. Writing several variations of an implementation just to decide which one worked best was expensive.

So people spent more time thinking, planning and designing their idea on paper. By the time they started implementing, the result was usually good, because so much of the thinking had happened early. They also knew their implementation details well, because they had designed them.

But the moment the effort needed to produce quick variations dropped, surprisingly, so did the thinking. People spent more time prompting for more variations and delegated every part of their work they could. They refactored heavily, iterated aggressively and kept generating until something looked like it worked.

The thinking moved to whoever has to review the result. A pull request that took minutes to generate can take far longer to review properly, and the reviewer now carries the responsibility the author skipped.

The culture decay

The damage reaches past the code. We are slowly but steadily losing mentorship, architecture and intent: the senior engineer explaining why, the design that holds a system together, the reason behind each decision. AI is taking away our effort, and effort is where most of that was learned.

AI also amplifies chaos built on unstable foundations. A model will build on top of a bad design as readily as on a good one, and much faster than any team could. Craftsmanship gets replaced by convenience.

One year later

Since I gave that talk, LLMs have improved quite a bit. In the same year, software engineers have grown huge dependencies on them, to the point where many are unable to do their own work well without them. The effort moved to the model, and the skill followed it.

I watched it happen in my own work

When I first tried to integrate AI into my own workflow, I watched the quality of my own work drop, and it dropped together with the effort I was putting in. Less effort to produce the work meant less thinking about the work, and the result showed it.

That convinced me the problem was what I had stopped doing.

Judgment is earned by effort

Judgment only shows up when you put enough effort into creating something. When the effort is reduced, judgment is allowed to be poor, and nothing in the process stops it.

That is why I think craftsmanship is becoming scarce. Producing code got faster. Whether it got cheaper is yet to be proven, except maybe in the short term. Knowing whether the code is right still costs effort, the same effort AI makes easy to skip. The habits we rely on to keep code maintainable on fast-moving projects depend on that effort too.

How we work now

None of this means we shouldn't use AI. We use it every day at Programium, on our own code and on the custom software and AI features we build for clients. What changed is where the thinking happens:

  • We think the idea through on paper or in a doc before anyone writes a prompt.
  • Nothing ships unless we can explain how and why it works.
  • Tests define what correct means, whoever or whatever wrote the code. More on that in automated testing as a first-class citizen.
  • Core logic, and anything on unfamiliar ground, gets written by hand on purpose, so the skill stays sharp.

As many others have said before me, the awesome part of using tools like LLMs is that they reduce the effort you spend on things that don't matter in your role: the things you shouldn't be trying to be the best at, not the ones you should. Use them to become better, not worse.

The call to craft

This is how I closed the talk:

  • Don't be lazy. Take ownership.
  • Keep writing software.
  • Keep trying, failing, and trying again.
  • Take pride in your work.
  • All effort, no matter how small, moves you forward.
  • AI might look convenient, but it's far from perfect.

With discipline comes experience. With experience comes clarity. With clarity comes quality. With quality comes pride. And with all of the above comes craftsmanship.