I’m starting to form a conspiracy theory that the “let AI write the email” concept is, in itself, an ad for AI. Not for people writing them (they are easy to convince), but now the people reading them have a bunch of bullshit to deal with. The best tool is an LLM summary to undo the LLM bullshit. They get double the usage from people (well, if the manager gets many subordinates to do this, it’s well more than double), and nothing of value was added.

Having seen a code base written by humans over ten years, it’s overrated.

mostly joking.

You should try it yourself. See what it can, see what it can’t instead of just arguing with your boss about something you don’t really know anything about

And then you can actually bring the facts to your boss.

Have you been to one of the workshops? It CAN be very useful when used right, setting up an MCP server pointing at internal docs/best practices made a huge difference etc.

Any criticism of AI you give will have a lot more weight if it comes from a base of knowledge. That means learning how it does (and doesn’t) work so you can critique it without coming across as “that anti AI guy”.

Make sure you go through everyone else’s PRs carefully and pull out all the stupid AI stuff, it’s great fun ripping them to shreds sometimes.

My advice is to stick to making specific observations as not to sound hyperbolic.

Yet at the same time what is needed is a counter-narrative to “AI can do the job”. My observation is the industry cycles between agile and waterfall development and people (who are the loudest) are using AI to do waterfall development. This is a bad idea for the same reasons waterfall development is bad: trying to write a spec that covers all situations is counterproductive.

The alternative I see is that we borrow from Agile and treat AI as a pair developer that you outsource small (or largely repetitive) tasks to. This is not vibe coding nor is it TDD as you are still actively developing all levels of the code, but your feedback loop (OODA) is kept short.

I think you’re gonna have to kill them

Remind them that copyright cannot be enforced on anything AI-written.

I am making similar experiences, but is is not as bad as you are describing it yet. We have a new member in the team who is not a developer by himself, but he has gotten the task to make our way of working more professional (we are mainly scientists and not primarily software engineers, so that’s a good thing).

His first task was to create programming guidelines and standards. He created 8 pages of LLM generated text and example non sense code. He honestly put a lot of effort in it, but of course there are a lot of things in it that are wrong. But the worst thing is the wall of text. You are nailing it - it is my task now to go through this whole thing and extract the relevant information. It sucks. And I am afraid that soon I will need to review more and more low quality MRs generated by people who have little experience in programming.

Our internal slack channels contain more and more AI-written posts, which makes me think: Thank you for throwing this wall of text on me and n other people. Now, n people need to extract the relevant information, so you are able to “save time” not writing the text yourself. Nice!!!

My last software dev employer did this, except with the “voice recording” feature. Instead of composing messages in text in a text chat (because that takes too long), he’d hit the record button and just start talking it out, then send the recording. Easy! Then the team had to download and listen to ~5 minutes of verbal diarrhea, pausing and rewinding for twice that long in an attempt to glean something useful from it. This particular kind of delusion existed before AI.

I had a manager who pushed AI a lot. When he left, all the pressure to use it seemed to die down. So maybe it’s just a couple of people creating this environment and if you can get away with avoiding them it’s better.

The problem with AI code we saw is that often no human has actually looked at it. During reviews you won’t check every line and you’ll have to trust much of the code that seems to do obvious things. But that assumes it was written by a human you also trust. When that human hasn’t reviewed the code either, you end up with code no one in the company has seen (and may not even know how it works).

Two words: malicious compliance.

Any idiot can write code. “Vibe coding” is just the new pasting code from stack overflow. For that matter, a lot of LLM generated code probably came from stack overflow.

Your value as a developer is not in your ability to rapidly pump out code. Your value is in your ability to design and build complex systems using the tools at your disposal.

As an industry, software engineering has not yet been forced to reckon with the consequences of “vibe coding.” The consequences being A.) the increasing number of breaches that will occur due to poor security practices and B.) the completely unmanageable mountain of technical debt. A lot of us have been here before. Particularly on the tech debt front. If you’ve ever been on a project where the product team continually pushes to release features as fast as possible, everything else be damned, then you know what I mean. Creating new code is easy. Maintaining old code is hard.

Everything starts out great. The team keeps blowing through milestones. Everyone on the business side is happy. Then, a couple years into the project, strange things start happening. It’s kind of innocuous at first. Seemingly easy tickets take longer to complete than they used to. The PR change logs get longer and longer. Defect rates skyrocket. Eventually, new feature development grinds to a halt and the product team starts frantically asking, “what the hell is going on?”

A question to which maybe one or two of the more, senior devs respond, "Well, uh, we have a lot of technical debt. I mean A LOT. We’re having to spend tons of time refactoring just to make minor changes. And of course, unplanned refactoring tends to introduce bugs.

The product team gets an expression on their face like Wyle E. Coyote as the shadow of a falling ACME anvil closes in around him. At this moment, they have two choices. Option A.) develop a plan to mitigate the existing tech debt and realign the dev teams objectives to help prevent this situation again by focusing on quality over quantity. Option B.) ignore the problem and try to ram feature development back on track by sheer force of will.

Only one of these options will achieve meaningful outcome and it’s not “B”. Unfortunately, in my experience that’s often the chosen option. The product team does not understand that while Option A impedes feature development, it’s only temporary. Option B impedes feature development permanently.

We’re going to see a very similar cycle with vibe coding. It just takes time to materialize. Personally, I think the tech debt for vibe codes projects will be compounded due to the sheer verbosity of LLM’s and the fact that no one actually understands a vibe coded project well enough to fix it.

That said, these issues are rooted in hubris and ignorance. Failure to appreciate the “engineering” part of software engineering. This is not something you alone can change.

The AI hype is going to disappear. Probably sooner than later. Just like every other tech hype cycle before it. But, LLM’s are probably here to stay so we have to make the best of it. I don’t usually use LLM’s for code generation. There are better tools for that already. I do use them frequently for research. Honestly, using an LLM with search incorporated is often a lot faster than scouring dozens of websites to figure out how to do something. You still have to take the information with a grain of salt as much as you would with anything on the Internet because LLM’s have no understanding of the text they spit out and will feed you incorrect information without missing a beat.

If I were you, I would focus on quality over quantity. Closing tickets faster is pointless if you’re introducing a bunch of new bugs. If your bosses don’t know that already, they will learn it soon enough.

Our internal slack channels contain more and more AI-written posts, which makes me think: Thank you for throwing this wall of text on me and n other people. Now, n people need to extract the relevant information, so you are able to “save time” not writing the text yourself. Nice!!!

I think this is one of your best bets as far as getting a real policy change. Bring it up, mention that posts like that may take less time to “write”, but that they’re almost always obnoxiously verbose, contain paragraphs that say essentially nothing, and take far longer to read than a hand-typed message would. The argument that one person is saving time at the expense of dozens (?) of people losing time may carry a lot of weight, especially if these bosses are in and read the same Slack channel.

Past that I’d just let things go as they are, and take every opportunity to point out when AI made a problem, or made a problem more difficult to solve (while downplaying human-created problems).

For centuries, we spent less effort consuming content than it took to produce the content.

Good teammates and content producers understand that their content needs to have an intrinsic value and benefits beyond the mere existence of content.

If you make your team 10x slower by sending LLM generated 10 page content instead of a one liner, you are actively hindering the team.

Efficiency is not just production of content (slop or not), but the overall system. That’s why the corpo speak has always been such a waste. Too many words to say nothing in a mandatory all-hands. Now the dial is up to 11 with the same time waste everywhere

Step 1, update your resume.

Step 2, follow your boss’ instructions until it all breaks.

Step 2.5, document everything so be can’t blame you later.

Step 3, go have a beer; you don’t get paid enough to give a shit.