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.

Two words: malicious compliance.

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).

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.

Learn how AI works, what it is good at, and how to build trust to minimize bugs.

You will be less efficient than other coders using it responsibly if you're not using it. It WILL be another tool you're expected to know.

Tldr; Be cautious and use the LLM to increase your test coverage and start with low risk basics.

AI is inevitable in many fields but as usual people expect way too much from it. It's a tool, not a magic wand. I agree with you that it is useful and even powerful when used by somebody that understands when it is useful. But it is dangerous when wielded by somebody that doesn't. As others have said, let your boss vibe code themselves into a corner and leave them to vibe code themselves out of it. They will try to deflect that it is your job to solve it though so you better come up with a strategy to handle that. Be sure to have more people on your side in this venture.

Secondarily, install a chatbot with the instructions to derive essence as a bullet list from your boss wall of texts. If they make their life easier with LLM, so can you. If there are misunderstandings it's either all just ghosts in the machine or a failure from your boss to communicate clearly.

My teamleads too. They tried to sell a whole application that they vibecoded and marketik strategie was "fully ai generated!"

Honestly, this is what I would do in your situation:

1. Update your resume and start responding to LinkedIn messages and possibly looking at least possibly.
2. Take those workshops for LLMs, there might be useful stuff to learn there, auto-completion, code search and examples of how to use certain features are very good uses of LLMs.
3. Don't be overly vocal about it, but point at issues when you see them, e.g. those large messages that you're expected to read point out how they're way longer than need to be and how using LLMs to give you a summary said the wrong thing (even better if you have an actual example of this, by for example invoking TLDR bot or something similar on those messages every time they come up)
4. Look at code that was vibe coded in areas you're working and start creating tickets for the stuff you see, unless they're vetting everything the LLM produces (which would be slower than writing it yourself) there will be issues there, start documenting those. The thing most managers and other "AI enthusiasts" don't get is that LLMs are trained with stack overflow and thousands of random GitHub projects written by inexperienced devs for every one good piece of code, so they have thousands of bad or incomplete examples for every good one. This means they end up not doing things like verifying you're logged in to use an API, sanitize SQL queries, etc. Because when you ask how to do something in stack overflow you will get an answer that is not meant to be used literally things like `query = f"SELECT * FROM {table_name}"`` is an okayish example on how to build queries with validated data, but it's a TERRIBLE example to use with user provided data, but the LLM doesn't know that, it just copy pastes the code that gets things from a table where it needs it.
5. Prepare yourself, using LLM to write code has a short lifespan in most companies, but the damage takes twice as long to clean up. If you stay you will be seen as the naysayer and might even get fired for it, but eventually this will blow up so gigantically that they'll start to regulate or even ban LLMs. And then there will be lots of garbage to clean up. In your shoes I might look elsewhere while possible as I wouldn't want to be associated with the company that had all of their data leaked or similar, because if they're using vibe code in prod it's a matter of when.

Plant the seed of using OpenClaw, but make sure you get no credit for it.. Once it's taken root, make sure you back up as much as you can of everything.

Wait for OpenClaw to inevitably self implode. Panic happens. Point out this is why you didn't trust AI, become hero by having the backups ready so everything's not destroyed.

People who don't know better like AI until it vibes back and bites them.

A popular option is to use vibe code to help run the place into the ground while looking for the next job.

Pretty soon the wave of vibe-shit code is going to be too much to clean up.

Interesting times ahead.

Endure the next year or so, until it pops and there will be a massive need for senior devs for fixing the slop machine.

We're using LLMs at the company I work at and it seems very useful in many cases but sometimes it still doesn't work. I'm a bit worried about the aspect of the code rotting by LLMs generating stuff based on existing code.

My mindset has shifted a bit, now I'm more focused on making stuff easy to find and easy to figure out patterns to use so that the codebase becomes easier to work with. There's some horrible code in the project and the LLM absolutely sucks balls at it but if it's a clean routine job such as making a table with update dialogs and actions to manipulate the data the success rate is >95%.

So yeah, don't trust it, treat it like a junior dev that got straight As in school and has never considered security. Code reviews are now where it's at.

It's hard to be a contrarian in these kinds of positions (I've been there, and it didn't end well), so I wouldn't be too outspoken, but at the same time, try to innocently point out the issues with approaches like this. I would just try to point out the flaws in this approach, the same that we would for any other kind of programming fad - without making it seem like it's an agenda, of course.

For example, any time teams are looking for feedback - code review, retrospectives, etc. - just point out the flaws on why vibe coding is a bad idea and bring it up casually when the time comes. It doesn't hurt to be honest as long as you don't come off as being an ass about it.

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.

I haven't had a similar experience yet, but maybe some if your collegues feel the same way? You could write a letter stating your concerns and let anyone sign who agrees and then send it to your manager. Also, I'd like to add that under German law AI Output can not be copyrighted. You can only claim coownership or something. Maybe that could be interedting to your managers?

It’s all about finding that happy medium. I’m a developer myself that uses it, mainly to write the “mundane” stuff, but I always double check its work. I also have it check mine, and ask for any alternatives it may see - a lot of times they’re helpful, AND I learn them for future use. So maybe just try to push the balance rather than the all-in?

Let him "vibe-code" himself into a problem, then tell him you can't fix the mess he done did.

A small company this level of cooked and immature leadership may not have the resources to recover long term from the damage. Even if the bubble pops on them in a year.

I'd start looking for alternatives now, before it becomes urgent.

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

mostly joking.

I have a similar situation at work. But I'm a designer. Previously I have worked for a company that did research in ai, from a product standpoint where I also had a boss who thought ai can do anything and blamed the workers for not succeeding. Now Im beginning to see the same thing here in my new company. The boss, product manager and a few of the developers (actually those with less ai experience) are driving this motion that ai will just replace everything. I tried to tell them about my experience, but they didn't listen to a designer.

Now this pressure is also coming to the UX team. A few days ago the boss asked me to use ai to reskin a whole app. It was assumed by him that that's a simple thing. Why is it so hard for them to understand it doesn't work like that?

Let me give you a little parable.

There once was a juggler, who could juggle with three balls all day. Then someone from the audience threw a fourth ball, and he kept going. Someone threw a glass, then a flaming torch, and he kept going, occasionally burning his hands. Seeing he could do it, someone throws a machete, and the juggler almost never cuts his fingers keeping all those things in the air. A chainsaw gets added, and an open bottle of bleach, and occasionally the juggler gets his hair caught or spills some bleach, but he keeps going. As he keeps going, people keep adding more and more things. Eventually it's too much, and it all comes crashing down, killing the juggler and several members of the audience and destroying all the objects in the air.

On the next street corner, a juggler stands with three balls. Someone from the audience throws in a fourth. He steps aside and lets it fall to the floor, happily juggling three balls.

Managers using influence to inflate their importance is common. It sounds like they are hoping to head off innovation to protect themselves.

The second aspect is their harnessing of useful idiots. I think critical or practicing objective thinking is being pushed aside at the time when needed most. You probs have to tread carefully and maybe influence people to use their own minds not that of desperate managers. Alternatively set the useful idiots off in competition and watch the fireworks. Not helpful but it is fun.

There always some people are always looking for an easy fix, a way to rise quick, to be a yesman. But for the most they just wanna do a good job. Maybe appeal to the rationally of those people. Trust your brain and skill rather than cult practises.

Vibe coding has its place (prototypes, simple webui), and use of ai for debugging, adding simple features can be effective. Even for more complex stuff it's getting better all the time; but one needs to keep an eye on what it's doing and refactor when things go off the rails (and ai can be a good tool for refactoring).
But ai messages that just make it look like someone is contributing are infuriating. I've responded by booking a meeting with the person who pasted ai slop to review the message because 'I want you to go over that and explain it to us'. And then when they try and start going over irrelevant crap I ask why it's relevant. And when they respond that actually it's from chatgpt and they don't know, if they don't immediately indicate how they realize now it was useless to paste stuff like that, I make sure they know my opinion (in a nice way). I haven't had the same person do it twice.

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.

Agentic use of AI didn't really work well enough until December of last year. The models and tools just improve that fast. Codex/claude (or opencode with the same top models) is what you'd need for it.

You still need to plan and define clear specifications for the model. Spend 80% of your time planning and breaking down the job into steps and it'll be pretty self-going from there.

Of course, this works best for common frameworks and solved problems or logical problems. React/node developers can easily 10x their output, and get it done better than they would by hand.

I'm working more with empirical development, so most of my time goes into studying environments and adapting to it. I get most benefit out of having agents read through logs and figure out what happened. It gets it right maybe half the time, but it's a good rubber ducky even when it goes wrong. I'd say it 2-3xes my output. But I can probably improve my usage, too.

But yeah, code review is where it hurts. If it's slop, it just takes so many rounds to get it right. Even when it's good, it's just so much code to review.

I have limited dev experience, but most Devs at my company utilise AI heavily for generic code generation.

For example, writing out the core functionality, and then having the AI propagate variables, error flags etc.

I like your point that it really should be a "Copilot". (Although ew MSoft.)

I think it's important to continue to experiment with new tools as they improve, and try to use them responsibly.

AI always produces extremely generic, slightly verbose phrases though. So it's important to generate in small enough chunks that you can use the structure it creates and then add the specificity and accuracy for your purpose. And cut out the waste.

Murder.

The best case for AI is that can heroicly solve problems that shouldn't exist in a first place in a well-managed company.

It can structure unstructured data, that should be structured. It can do simple coding where aboslutly no coder could be reached. It can sum up the red tape and produce red tape to meet complience requirement that were where created for the sake of the red tape alone.

If the work is important, it shoudn't be done by AI. If its busy work, it shouldn't exist in a first place. No one would need AI to summarize anything if everything was writen clearly.

And thats best case scenario when you don't count halucynations, errors, edge cases, company specyfic context - things that results in task taking more time after all the "oh it produced something and it looks good at a glance" cloud fall down.

If your company is getting a lot of value from AI than your company is trash.

Tell him that vibecode is barely good enough for a prototype (a demo) and watch if he fires you. Either way is a good outcome.

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.

I work in consulting big corporate, it's AI all the way down.

I work in a GenAI team building mostly LLM powered applications. I use LLMs to work, they can be useful if you pick thr the largest model available. with smaller models it's just a waste of time.

My boss is very technical (theoretically) but he sold his brain to LLMs and do hard vibe coding of whole apps by himself and the pushes the on the team to do bugfixing...

Fun fuct, he always downsize estimates, since "he can do in 1/5 of the time".

yep, welcome!

enjoy the ride, look for a new job, so you're not surprised when the buisness dies due to declining quality or a customer lawsuit suing for damages.

Switch employer.

(hey ich bin bei dir das kann nicht einfach jeder trivial aber aus diversen Gründen habe ich das bereits 2x in den letzten jahren)

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 am not a software developer, but isn't AI code often really hard to maintain, like making changes and improvements down the road?

Maybe you could provide examples of that?

I don't know, I guess I use vibe coding as a shortcut for a one off script or tool that I need. But anything that is going to be maintained long term, I feel like we still need proper developers

Do better than the AI

Give it a honest shot, learn the limits, help your team establishing best practices. Depending on the language, framework and vertical it can be mor e or less autonomous.

It always needs good specs, clear steps, and lots of testing. Some of which can be automated by the AI itself. Make sure you write yourself or strictly review (am besten im vieraugenprinzip) the code that touches anything related to money or safety.

I think you're gonna have to kill them

Adapt