Being a software engineer these days is weird. We used to think that we were the stars of the global economy, impossible to hire without crazy perks and ridiculous packages, but then the Zero Interest Rate Period ended and we realized it was all a mirage bought with cheap money. Now, everyone from high school students to CTOs are opining about whether anyone should even study Computer Science anymore, since we’re all going to be replaced with chatbots soon.

Needless to say, this is all kind of ridiculous. Yes, there was wild speculation on stupid ideas (remember NFTs?), and stupid speculation on wild ideas (goodnight, Metaverse, we hardly knew ye), over-hiring and over-firing, a glut of engineers on the market, and somehow I still can’t fill my open reqs (seriously – if you’re in the Boston area, please get in touch). But nothing quite seems to match the current dissonance around LLMs.

The thing I find fascinating is that among the technical AI boosters, there are two completely different conversations, and two completely different consensuses. On the one hand you have executives. These are people who used to be technical, and still think of themselves as technical, but haven’t shipped production code in a decade. They use AI tools for hours every day – coming up with ideas, summarizing documents, writing throwaway prototypes, visualizing data, getting coaching – and find them incredibly useful. It saves them hours of work, obviating the need for them to exercise technical muscles they haven’t used in years. Why, they wonder, doesn’t everyone do this?

On the other hand, you have technical contributors who need to ship production code. These are people who care about quality, operational excellence, maintainability, and complexity. I talk to a lot of these people, both at my company and when getting together with friends, and the feedback has all been along pretty similar lines. LLMs are good for coming up with ideas, summarizing documents, writing throwaway prototypes, and visualizing data. The quality is low (“like an over-eager freshman intern”), they sometimes fail catastrophically[1], and they generate PR reviews I’ve heard described as “automated bikeshedding.” But if you need something quick and dirty, something that you’re going to throw away, boilerplate, or automated documentation for some code, then it can provide some value – as long as you keep your expectations low.[2] Why, they wonder, is my CTO telling me to use this on production code?

The interesting thing to me is that the executives are using the tools in exactly the same way the engineers believe it can be used effectively. The problem is that the executives then extrapolate to production use cases. After all, how much harder could it be?

I’m reminded of the following passage from The Mythical Man-Month:

One occasionally reads newspaper accounts of how two programmers in a remodeled garage have built an important program that surpasses the best efforts of large teams. And every programmer is prepared to believe such tales, for he knows that he could build any program much faster than the 1000 statements/year reported for industrial teams. Why then have not all industrial programming teams been replaced by dedicated garage duos? One must look at what is being produced.

The Mythical Man-Month, Fred Brooks

Brooks goes on to explain that the garage duo has created a functional program that can run on the developer’s system. They have not created a product that has automated tests and documentation, that’s been tested on a wide variety of systems, that can be run, tested, and maintained by other engineers. It doesn’t have well-defined interfaces, accept non-happy path data and input, work in coordination with other system components, or generally work for anyone other than the engineers who built it, on the dev machines they built it on.

Writing production code is a fundamentally different exercise. You can build a throwaway prototype in a fraction of the time it takes to build an actual product that can be maintained long-term. Production code must be created with more care – you can’t just vibe code your way to operational excellence. People who are responsible for delivering production code understand this, but for some reason the executives – who used to deliver production code – no longer do. It’s strange, and the gulf between these consensuses has become so wide that it’s creating a toxic environment.

In a recent post, Anil Dash described a tech culture in which the majority view was being suppressed and hidden from decision makers out of fear:

One of the reasons we don’t hear about this most popular, moderate view on AI within the tech industry is because people are afraid to say it. Mid-level managers and individual workers who know this is the common-sense view on AI are concerned that simply saying that they think AI is a normal technology like any other, and should be subject to the same critiques and controls, and be viewed with the same skepticism and care, fear for their careers. People worry that not being seen as mindless, uncritical AI cheerleaders will be a career-limiting move in the current environment of enforced conformity within tech, especially as tech leaders are collaborating with the current regime to punish free speech, fire anyone who dissents, and embolden the wealthy tycoons at the top to make ever-more-extreme statements, often at the direct expense of some of their own workers.

The Majority AI View, Anil Dash

As with any difference in perspective, the only way to get to a common understanding is through honest and open conversation, which is precisely what’s being shut down in the current environment. If you don’t have a sense of psychological safety – the confidence that you can express your truth without repercussions – then it’s very easy to check out and go along to get along. Which, aside from the fact that a lack of psychological safety feels stressful all the time, also means that you’re stuck in the position of either pretending to use the tools as instructed (“oh yeah, 30% of my production code[3] was totally generated by AI”), or actually doing it and vibe coding your way to major outages.

We need to bridge the gap. We need to have the conversation. And we need to get back to a place where talking through differences of opinion on technical topics doesn’t feel like a high-stakes, career-limiting move.

---

[1] My favorite hallucination was the time I threw together a quick and dirty bash script to pull down some data from AWS. A colleague asked Cursor to do the same thing, and – in the same amount of time – came up with a beautifully formatted table of detailed, annotated data. Especially breathtaking was the fact that Cursor had made up all the data (it didn’t know how to get access to the AWS account, so it “improvised”). If I hadn’t already pulled the data with my bash one-liner, we might have made decisions based on fantasies generated by spicy autocomplete. Needless to say, this experience didn’t dampen my colleague’s enthusiasm for LLMs.

[2] I believe that I’ve made my position on AI clear – here, here, here, and here. I’m not suddenly becoming an AI booster. This post is about the conversation we aren’t having.

[3] Does anyone actually believe this?