What if AI removes the friction that makes good engineers?

Leonard Thiele

Jul 29, 2026

A few years ago, implementing authentication, debugging an unfamiliar library, or building a small personal website might have taken hours or days. Today, we can describe the task to an AI and watch it implement something impressive in minutes.

By using LLMs in software engineering we have recently removed an extraordinary amount of friction from creating software. Sure, most of it was tedious, but some of it may have actually been necessary.

I’m thinking about this while reading The Craftsman by Richard Sennett. He describes craftsmanship with a simple definition: the desire to do a job well for its own sake.

I remember discussions about clever ways to inject dependencies, a cleaner TypeScript generic, or whether a small low-level optimisation was actually necessary. At first, these seemed like unimportant details, but they could improve things like security, performance, or stability in the long run. We also cared about them for a simpler reason: we wanted to do a good job.

We knew our code would be reviewed immediately and maintained by someone else in the future. That created discussions about naming, comments (if we couldn’t avoid them) and architectures that should intuitively make sense. Simply knowing that another human would read the code often led to rewrites before even getting feedback.

We took pride in our work.

That never meant doing everything ourselves or doing everything manually. Every programmer has copied from a book, from similar code, or from a Stack Overflow question answer.

A craftsperson does not refuse power tools just to spend hours doing something a machine could do in seconds. The connection I see is not about some obsessive form of purity, but about the relationship between the work and the person. Between the code and the software engineer.

While being fully absorbed in the process, an engineer obviously also cares about the result of his work. We notice details that an untrained eye might overlook. We stay with a problem longer than we can rationally justify because it still “doesn’t feel right”.

That describes many of the best engineers I have worked with.

They care because a badly designed API will confuse every engineer who has to use it. Because a badly named function will cause someone to make the wrong assumption a year later. Because they know they may be the person recovering the system when it fails at 3am in the morning.

This intuition senior engineers have is the expression of craftsmanship. They have developed judgment.

But that is my concern: How do we develop that intuition and judgment in engineers who are learning our craft right now?

One of Sennett’s main arguments is that thinking and making cannot be split. He argues that “when the head and the hand are separated”, understanding suffers. As software engineers, we experience this constantly.

You begin implementing what feels like a clear requirement and discover that nobody has decided what should happen when a user belongs to two organisations. You write the service, look at it, and realise that you still do not understand the problem fully.

This is why “just write a perfect spec first” has never completely worked.

Some things can only be understood while building.

AI removes friction

Most conversations about AI programming treat friction as something like:

"Friction is bad. AI removes friction. Therefore, AI is good."

And a lot of the time, that is true.

There is so much friction in programming that most people give it up quickly after they finally decided that they wanted to give it a try. We all know the wall you eventually break through after years of programming, when things start to make sense and the work feels much more effortless.

Of course, all the boilerplate remains… Memorising APIs, countless data transformations, repetitive tests, or googling specific configurations. I’m happy to automate all of that.

But there is another kind of friction. Breaking a problem into smaller parts during, what feels like, a 6 hour refinement session. Reading a system you did not design (especially libraries). Debugging a production issue. Tracing an object through several services. Understanding why something works in one environment and fails in another.

This type of friction made us grow as engineers.

AI does not only remove the tedious friction of programming. It can also remove the friction through which we develop judgment. The actual learning. In how we currently use AI tools, we rarely distinguish between “useless friction” and “formative friction”. Vibe coding accidentally removes both.

Without that friction, we don’t develop the same understanding or judgment. But we can still get the exhilarating and, honestly, somewhat addicting feeling of increased output. We get the sense of having built something without having gone through the real experience and pain of building it.

The apprentice has become the foreman

Imagine a junior engineer asking an AI agent to implement a new authentication flow. A few minutes later, they receive changes across fifteen files. A new middleware, new endpoints, database changes, and updated screens.

Now the engineer has to decide whether this solves the problem and then if it is good enough to commit. To judge the work, they need to understand the system boundaries, whether the database model still makes sense, what vulnerabilities the change might introduce, and what will happen in every relevant edge case etc.

In other words, the AI has done the junior part of the task and left the human with the senior part. While the human is still junior. That, of course, will lead to problems.

Traditionally, an apprentice moved gradually from observation to instruction, then to repetition, and eventually to increasingly difficult independent work.

That took years and thousands of hours. Responsibility expanded with judgment.

We have now given the apprentice a team of extremely fast and competent workers and said: “You are the supervisor now. Please check their work”. That is an unprecedented amount of leverage.

It is also an insane way to learn a craft.

You begin with overwhelming complexity and incredible output, and somehow afterwards still need to catch up with the judgment required to control it.

But catching up becomes harder and harder when AI can always offer another shortcut. Another quick dopamine hit. Why spend hours understanding hundreds of lines of generated code when you could prompt it again and immediately build something new?

Leverage grows faster than judgment

AI is often described as an “equaliser”.

I can’t tell you how many Lovable-loving posts from non-technical people I’ve involuntarily seen over the last months. Everyone gets access to the same powerful tools, so even someone without extensive coding experience can now create something that would previously have been far beyond their ability. It looks great. Sometimes.

But quickly prompting something and carefully evaluating an output are very different skills. Even clearly defining the desired result is a skill that needs to be developed. This is why I don’t think AI necessarily reduces the gap between non-technical people and engineers — it can actually increase it (yes, I typed that —, out of protest).

An experienced engineer can progress much further and faster, not only because they can describe the solution better, but because they know how to define constraints, build necessary guardrails, and judge the result.

To an inexperienced engineer, the problem appears magically solved… somehow.

An experienced engineer sees the race conditions, inconsistent patterns, or workarounds that might still be in production four years later. They correct them before committing. Beginners do not know what they have not yet learned. They currently blindly trust the AI to do a good job and hope everything goes well.

In the past, many of those lessons arrived gradually through thousands of hours of “formative friction”. With AI, the gap between output and high-quality output can stay hidden for much longer. Until a real failure exposes it… all at once.

The learning no longer grows slowly with the responsibility. It is delayed until it’s overwhelming and can stall the project and the motivation to build something completely.

Is AI destroying software craftsmanship?

It sometimes feels that way. But I think that conclusion would be too easy.

And it would romanticise a lot of work that was mostly annoying. Craftsmanship has never required us to use the least efficient tool available. But it requires us to put in the necessary work.

The problem begins when we stop caring about the craft.

Software engineering has always evolved with its tools, maybe even faster than most other crafts. It is currently moving away from remembering syntax and manually producing every line. Towards focussing more on understanding systems, defining technical and product constraints, testing assumptions, simplifying unnecessary complexity, and taking responsibility for the output of our tools.

There is a difference between using AI to extend your ability and using it to avoid the actual work.

Useful tests might be something like:

Can you explain why the system was designed this way?

Can you change it when the requirements change?

Can you predict where it is most likely to fail?

Can you debug it when the AI’s mental model is outdated?

Would you be comfortable being called at 3 am when it breaks?

You do not need to write every single line of code yourself to be the craftsman responsible for the result, but you need to be able to at least understand it.

The counter argument

Some people say: ”AI is advancing so fast, you don’t actually need to read the code anymore. It will be solved soon”.

Agents will implement the feature, write the tests, review their own changes, deploy them, monitor production, and fix whatever breaks. Reading generated code may eventually feel as outdated as reading assembly produced by a compiler.

Maybe.

Maybe manually reviewing every function AI generated is only a temporary phase. Maybe the code itself will become a “under-the-hood” detail that fewer and fewer people need and want to understand.

But I don’t think that this will remove the need for judgment. It just moves it away from code to higher level decisions.

Someone still has to decide what “solved” means. If the authentication flow should prioritise security or actually convenience. Or if the system should allow a user to belong to two organisations. Which failure cases are acceptable and not a priority for now etc.

These are not necessarily “coding” questions anymore.

AI may become better and better at answering those. But as long as a human remains responsible for the outcome, that human needs enough judgment to know when the answer is wrong. I don’t think we’ll quickly move to a world where we can say: ”Not my fault, Claude implemented it”.

Maybe one day the entire system will be built, evaluated, and operated by AI, and human judgment will no longer be required. But at this point, none of the previous assumptions will still be valid and we’d need to rethink everything.

The real question

AI-assisted programming is moving way too quickly for us to preserve the learning opportunities accidentally.

We will have to decide which forms of friction are unnecessary and which have educational value. We will also have to find new ways to assess engineers when producing polished-looking code is no longer a good signal of understanding.

Sennett’s craftsman does not prove their skill by rejecting modern tools. They prove it by staying in touch, somehow connected with the work. They notice what feels wrong, question their first assumptions, and then develop the judgment to tell good work from work that just solves the problem somehow.

AI can, in the best case, support that conversation, but it can also end it too early,

[truncated for AI cost control]