What If AI Removes the Friction That Makes Good Engineers?
Leonard Thiele
SubscribeSign in
What If AI Removes the Friction That Makes Good Engineers?
Leonard Thiele<br>Jul 29, 2026
Share
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.<br>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.<br>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.<br>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.<br>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.<br>We took pride in our work.<br>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.<br>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.<br>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”.<br>That describes many of the best engineers I have worked with.<br>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.<br>This intuition senior engineers have is the expression of craftsmanship. They have developed judgment.<br>But that is my concern: How do we develop that intuition and judgment in engineers who are learning our craft right now?<br>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.<br>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.<br>This is why “just write a perfect spec first” has never completely worked.<br>Some things can only be understood while building.<br>AI removes friction
Most conversations about AI programming treat friction as something like:<br>"Friction is bad. AI removes friction. Therefore, AI is good."<br>And a lot of the time, that is true.<br>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.<br>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.<br>This type of friction made us grow as engineers.<br>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.<br>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...