Are people’s bosses really making them use AI tools?

I’ve heard similar stories from friends in other industries too. Copywriters, finance, and more. Basically “use AI or else”. Also from friends at agencies not in development where people will do “research” using GPT and then go to the client and say something along the lines of “our user research suggest that this idea is good because ‘reason GPT gave them’”. It’s so disheartening.

i’m pretty pro-ai

but if it weren’t for the whole “market can stay irrational longer than you can stay solvent”, i’d be placing some big bets against companies doing it that way

the way my bosses encourage AI use is by giving us an account to use copilot (only recently), and by having ~weekly discussions on new things in AI, talking about articles people have read, talking about how new models respond to similar questions, etc. and we’re not required to use it for code (but the code is required to call the API. because that’s what we’re working on)

i find the reductionist arguments against AI (“stochastic parrot”, “regurgitating, not creating”, etc.) uncompelling. if there’s some dumb mistake i made in my code, and it recognizes it because the mistake is common, and fixes are common, it still found a bug in my code. i don’t care if it used creativity or analysis to find it

i also think that the “ask claude before you ask me” line could be reasonable, or not, depending on the mindset. i’ve seen people do this, and they were explicit that it was a replacement for the rubber duck. it might come up with an answer, but the real purpose is so that you workshop the thought a little in your mind before asking

Interesting article.

In $CURRENT_JOB we have a conservative approach (maybe some will say too conservative) with AI, and the last time I asked we can use external AI tools like ChatGPT but we can’t use integrated AI tools like Cursor, and also there is no incentive to use AI yet (for example, no premium subscription from the company). We are slowly adopting AI more, for example some PRs now have Copilot enabled, and I think it is inevitable that eventually Cursor or something similar will be allowed.

It is a company where most engineers have lots of experience (10+ years is really common for Engineers here), and most people still do things old school, but we are still experimenting with AI. For example, this morning I solved something that would take me probably 1~2 hours to fix since it was a new codebase that I had no familiarity in 10 minutes thanks to ChatGPT, and since the code is basically a script that does not directly go to production, I felt safe to trust the code from ChatGPT (of course I did some review before posting it).

But at the same time I was tasked to create a new architeture for a new feature that we need to implement, and I did it in the old school way, zero input from any LLM tool.

Thank you for the read! I really appreciate the advice about navigating all of this too.

I see a lot of people are having trouble believing that there are bosses who enforce the use of AI. There are. The market staying irrational longer than you can stay solvent, as @kokada said, is part of it. But the other part, which I think is lost on a lot of fortunate programmers who made enough good career choices, is that the baseline that AI is replacing in some of these organisations is in fact not that low. Adoption of word-soup-as-a-service tools isn’t driven primarily by degrading standards, it’s driven by existing standards of practice which A”I” fits at a lower price but roughly equivalent performance.

See, this struck a familiar and very bad chord:

I spoke with a developer working in the science industry who told me, “I saw your post on Bluesky about bosses encouraging AI use. Mine does but in a really weird way. We’re supposed to paste code into ChatGPT and have it make suggestions about structure, performance optimisations”

I am sure I’d be livid if this happened to me. It’s not a hypothetical. It’s happened to me before ChatGPT was a thing.

Just before ChatGPT came out with a bang I worked in a large project (think 20-year codebase that was still on a roll, so lots of greenfield code that needed not to upset OS/2 code) with a very nicely-cut review procedure, which I was quite enthusiastic about when I saw it written out on paper. Organisational realities meant that real life was not quite like the paper; ultimately, it boiled down to most of us just not having enough time, and we coped with that however we could.

Evaluation encouraged review visibility though, so the least experienced people quickly found that the easiest way to cope was to just throw bullshit at the wall and see what sticks. Code “reviews” ended up being about things like the i in a two-line for loop being an insufficiently descriptive variable name, or mindless recitations of the internal coding standard, like the proverbial “no gratuitous comments, code should be as self-explanatory as possible” line slapped on every single comment in the file (including the license header because when you’re just hitting Ctrl+V you’re not gonna read everything…).

This got you a good setup for yearly eval whereas, unsurprisingly, not meeting deadlines got you in trouble, especially if the problem was, err, code quality – after all, that’s why the code was bogged down in review, no? It was usually unproductive to try and argue with any of the review notes, legit or not. It’s not like you can argue with the notion that variable names have to be descriptive, after all. Since it took less time to make all those pointless changes than to explain why they’re not necessary, at one point everyone recognised it was more productive to say fuck it and fuck you and fuck your entire existe thank you very much for the review, make all requested changes, and hope QA catches the actual bugs down the line.

Using ChatGPT for review gives you… exactly that. The first time I fed my code into a LLM with a generic “review this code” prompt it gave me exactly that kind of review. LLMs actually yield better results. They sometimes catch legit bugs, after all. Whereas in that fifth circle of bullshit review hell, even superficial bugs escaped notice, because everyone just tried to maximize the amount of review notes they left, so anything more significant than forgetting to de-allocate a chunk in one of the increasingly rare non-RAII portions never got flagged. Real bugs, the kind that are made shallow only by enough eyes, remained untouched because everyone was hunting commas, not bugs.

Plus, if you “explain” a LLM why one of the review points is wrong or redundant, and it makes some sense, you can actually get the little bot to back off. Whereas a sophomoric reviewer will argue you to kingdom come that a function must have a single return statement even if it means three nesting levels, and then five chunks later insist that you must revise your code because no method should have more than two nesting levels.

The sad reality, which those of us with some experience doing actual code reviews never managed to convey up the management chain past a certain level, was that these ended up being a net negative. In the diff frenzy that followed these “review” sessions, we ended up introducing at least two CVE-worthy bugs, via things like use-after-frees, just by merging or copy-pasting things in a hurry – which, unsurprisingly, passed reviews with flying colours and “good job”s because all the variables had nice names and the code had been converted to use whatever recent C++ feature had been recently highlighted on Reddit.

This is the niche that AI tools are filling. Not careful reviews, conducted by people in well-managed teams that enforce code quality through disciplined scrutiny of code, based on the notion that more analyses, from more perspectives, by people with diverse backgrounds, can reveal bugs that sit in a single programmer’s blind spot.

The niche it’s filling is bullshit reviews that have to be conducted because internal merge procedures say no merge until two people sign off on the code.

They can be bullshit for a lot of reasons: because internal procedures demand two sign-offs, but don’t ensure that the people who are supposed to provide it actually have the time to acquire the domain expertise they need to examine the code and then to actually examine it. Or because problems are ill-specced to the point where they don’t know what’s a bug and what’s a feature, so the best they can do is play human Coverity and hope for the best. Or because people, consciously or not, try to game the system.

But ultimately everyone knows they’re bullshit and the whole “engineering” activity is structured in a way that doesn’t allow for real reviews. So if you can get exactly the same kind of bullshit that you got before (or, realistically, even better), but faster… why not?

You can do that even with good intentions. I have a friend who does that precisely in order to get the “you don’t seem to have too much review activity” MBAs off her back: she copy-pastes a page’s worth of slop and then spends that meager half-hour allotted for “review” looking into the parts that look sensitive or suspicious, or at least stress-testing it a bit. Everyone on the team knows that’s what’s happening; everyone does it, and they literally tell each other which notes they can ignore. That way, they manage to get some actual review activity going.

I am not saying this is sound industrial practice, heavens, it’s terrifying. But it’s not a recent development brought by VC “disruption” and sold by gifted snake oil salesmen. There is in fact a real market demand for this sort of crap, both formal (as in implemented top-down) and informal (as in people surreptitiously copy-pasting stuff into ChatGPT).