an identity crisis in engineering

Building software by hand was hard but pleasurable. When things didn’t work, we dug into the code and looked it up on the internet. We implemented the solution after we understood; we looked down our nose at the brute-force blind-pastes from StackOverflow. We drew enormous satisfaction from this. Of course, the clout we gained among coworkers for our ability to solve difficult issues didn’t hurt.

Today, many of these qualities are becoming obsolete at work. The tricky bug can be solved by pointing an LLM at it. While there are a few things it can’t do, many parts of our jobs have been replaced by a small conversation with the LLM.

There are two modes in engineering - building and digging. When you built by hand, you struck a balance between both. As you built software, you also had to dig into it. Your brain formed new neural connections and reinforced old pathways. It was a wholesome activity involving exertion and reward. You came out of it with a sense of satisfying fatigue.

There is a well-documented link between effortful work and fulfillment[1]. We value what we struggle to build, and we feel best when we’re making tangible progress on something difficult. For many of us in software, this was a marker of health.

Today, writing software happens entirely in building mode, with the LLM neatly abstracting away all the sweating and the tinkering you once needed to do. Our interaction with “our” code is passive. We consume the code in a review. We ask for walkthroughs, we test. But where is the active effort-reward cycle?

The sense of fulfillment that comes purely from engaging critically is lost. Flow state becomes harder to achieve when the LLM sits between you and the problem. You still have the satisfaction of seeing the end product work. But for those that enjoy digging more than building, this benefit is negligible.

That brings us to the diggers. The diggers don’t actually build. They are more rescue-ops. They derive great joy from digging into code, all sorts of code, provided that it is tricky. Their work on software at companies became trite and repetitive with the same old CRUDs and tired deployment pipelines. So they specialized and became a digger, avoiding boring work and amassing accolades at the same time. This identity of the digger is at stake because of the LLMs. If technical depth was a core part of your identity, this shift can feel jarring. While debugging distributed systems is not its territory yet, guidance from an LLM makes it far easier for the building engineers to solve their own problems. But we all need to get our dopamine somewhere. The engineers that struck a balance between both digging and building are best positioned in today’s arena. Their builder’s side will be satisfied with the quick churning of the LLM, while their digging expertise will help where the LLM fails. Those that did pure building with little digging are on shaky territory. For the newer engineers, this is famously the challenge with AI. It is the diggers that face the biggest challenge in the age of AI. Their builder’s instinct is under-developed. They have no reward pathways linking a working product to fulfillment. Since their identity was tied to being skilled at one thing, seeing that thing become cheap can be very painful. Their roadblock now is not their skills, but their identity. For this group of engineers, using AI generated code can feel like cheating. What’s holding them back is a simple but powerful idea: that going deep on tricky issues is more valuable than solving real problems.

As to how they can get back to enjoying work, there is no straight answer. We will have to wait and see.

[1] The IKEA effect shows we value things more when we struggle to build them. Csikszentmihalyi’s research on flow states shows that deep, challenging work, the kind that stretches your skills just past comfort, produces some of the most satisfying experiences humans can have. Writing code hit both of these notes.