On Losing Engineering Culture

I've been thinking about engineering culture lately, and I'm not sure I like where things are heading. This might come across as the kind of complaint you'd expect from someone who's been in the industry long enough to start sentences with "back in my day," but I think there's something real happening here that's worth writing about.

When I talk about engineering culture, I mean something specific: thinking from first principles, solving problems instead of mindlessly completing tickets, developing a deep understanding of the technologies you work with, and maintaining a genuine commitment to improvement — both of yourself as a specialist and of the projects and codebases you touch. It's the difference between being a craftsperson and being an assembly line worker.

Push and Pull

Engineering culture almost never existed in isolation from business. Business pays for the endeavour, after all. Unless you're doing open source work, where you have the freedom to approach things purely from an engineering perspective — though that's generally unpaid, which creates its own set of constraints.

What we had, historically, was a kind of healthy push and pull. Business wants everything done cheaper, faster, and better, preferably at once. That's unreasonable, but that's just what business is. And engineering was always in a relatively strong position in this negotiation because a company's engineers were the only ones who could actually implement what business wanted. The buck stopped with them. They decided how things got done and why.

This tension was actually productive. Engineering couldn't justify delving extremely deep into problems that didn't exist, and business couldn't just push for feature after feature in the most hands-off way possible. Both sides kept each other honest.

The main escape valve for business was to hire people who didn't care, or to outsource work to companies that only cared about matching the formal on-paper requirements. But people who don't care don't produce the best work, so people who did care still had real value. There are also entire industries where you simply can't afford to not care about quality, or where legal requirements prevent outsourcing sensitive work.

Things are Changing

With the onset of AI, this balance is shifting. AI amplifies the cheap and fast qualities of work in a way that doesn't require outsourcing or replacing your team — just pressuring the existing team more. This gives business significantly more leverage against engineering than it had before. Quality matters less when you can produce so much more volume and then just throw it away and regenerate if something stops working.

Vibe coding adds to this dynamic. I want to be clear: bringing more people into programming and engineering is genuinely a good thing. But vibe coding also, in my opinion, promotes not caring. Some vibe coders might care deeply, but they often lack the fundamental understanding of technologies or engineering culture that would tell them what to care about. You can't maintain standards you've never learned.

I've encountered some genuinely nonsensical situations at work. Product managers vibe code a solution in three hours and then ask why engineering needs three weeks to implement the same thing. They don't recognise the process: the focus on quality, the time needed for team coordination, testing with QA, security audits, documentation. And they consider this to be a legitimate argument for pushing engineering on deadlines. This kind of pressure even makes some people who previously cared start caring less, which is perhaps the saddest part.

Here's something I've been trying to understand: how do people stay productive when they've stopped caring about the craft? This is where vibe coding offers something I've heard being called "dopamine coding."

Having a solution materialise from nothing, watching it work and become quickly visible and interactive in your dev environment — this definitely produces dopamine for many people, maybe even every developer? I understand the appeal. When I use AI for throwaway code that genuinely doesn't matter, it does feel good to have the work magically done for me.

But for me, at actual work, it tends to work in an anxiety-inducing way. I can't guarantee the quality of the solution. I don't know in what ways it might break. Inspecting AI-generated code is considerably more mentally draining than reviewing code written by a colleague because there's no underlying intent I can reason about, no mental model of the author's approach I can build up over time.

So this "fast" dopamine of vibe coding replaces the "slow" dopamine of enjoying the quality of your craft and deeply engaging with engineering culture. It's not that one kind of satisfaction is inherently better than the other, but they lead to very different outcomes.

I don't mean to suggest that all AI-assisted coding is bad. I'm one of those people who genuinely enjoys thinking through a solution and manually writing neat, simple, readable code. But there are cases — menial tasks, throwaway scripts, quick prototypes — where it genuinely doesn't matter. AI is here to stay, and that's probably fine.

What concerns me is that it feels like AI is replacing rather than adding. Replacing competent solutions with quick ones. Completing whatever is written in the ticket as fast as possible, instead of figuring out the actual problem and solving it well. Letting AI work with technologies without understanding why or how they work. Throwing away and regenerating instead of improving.

This feels like losing engineering culture.

Ways Ahead

People who care about engineering seem to have a few paths. Some burn out and switch to the fast dopamine of AI vibe coding because at least that provides some sense of satisfaction from the work. Others leave to seek places where people still care.

Those places exist. Open source is one option, though it generally doesn't pay, so you need another source of income. Some startups and smaller companies maintain teams that deeply care about their craft and the quality of what they produce. From what I've heard, companies like Stripe, Shopify, or 37signals fit this description. But they're a fairly small fraction of the industry overall.

I think what matters most is protecting yourself and the culture from burnout by connecting with other engineers who care. This could be online communities or colleagues at work. The goal is to keep the flame of engineering culture lit and share the craft with others who might become interested. It sounds a bit dramatic when I put it that way, but I think there's something to it.