Vibe coding/prompt engineering automatically accumulate "technical debt" of spaghetti code and thus with time cause every larger project to fail. Sooner or later you will be asked to fix all that AI mess in your company codebase and when you respond that you are unable to do so without a major, manual rewrite, you will probably get fired. Stay at your job for as long as possible, but start searching for a new position ASAP in an organization that declares up front that they do not intend to use AI for their codebase as a matter of company policy. There are actually companies out there already that make that kind of choice, but it might take a year or two for you to find such a job in the current job market. If all else fails, switch to the Linux kernel/driver development specialty with C/Rust for companies like Canonical.

I can't stop thinking what happened when CASE tools, WYSIWIG, UML, Model Driven Architecture/Development, etc was pushed into devs. I know, it's a different phenomenon (that was a graphical visual push, this keeps the text).

I've recently started using Claude Code, and also expected to not like it (based on using Claude Web to generate some code). I have 17 years of experience.

But it's actually been fantastic. It's challenging in a new way: splitting things down into small enough descriptions that the LLM don't go down a rabbit hole it can't get out of. While also giving high-level guidance to plan for the whole project.

I like UI design, but implementing it is tedious and slow. With Claude I can get a dashboard page done in less than 1 min, from a spec, that I can iterate on. Instead I can focus on the parts I care about, like backend. I need to nudge it to always care about security and storage concerns. I've seen O(n²) loops where O(n) would be sufficient. It keeps making enough mistakes that I'm not exactly out of a job.

The best way to use Claude Code is to write those descriptions and use examples of what you want the output to look like, so take it in small steps and do manual corrections.

However, you need to have seen some good code before using it to make something good. It's just a tool, like compilers and IDEs. I'm pretty happy I don't have to input programs using eight data switches and a latch switch on an Altair 80. And I'm now pretty happy I don't have to care so much about internal API boundaries, because doing a refactoring is one sentence away.

However, I do keep running out of quota after 2-2.5h out of 5h. If I had a company sponsoring this, it would be a no-brainer to use it more.

I’d stay and actually try the vibe coding, but if it’s not working, only a bit.

For example, try deleting one failing unit test and re-generate it with Claude. Then if it turns out mostly worthless, scrap it and restore the original test. Maybe the entire test is correct (and easy to verify), maybe you can take pieces from it, maybe it’s unsalvageable; if it doesn’t save time, write tests manually from then on until the next major AI improvement.

Worst case, CEO fires you for not vibe-coding enough. Best case, you find a way for them to make your life easier. My prediction (based on some but not much experience) is that you spend only a small amount of time trying the AI tools, occasionally they impress you, usually they fail, but even then it’s interesting and fun to see what they do.

EDIT: as for dealing with the spaghetti when others use AI; wait for that to become a problem before quitting over it. And of course you can look for opportunities now.

My company’s CIO was pushing AI hard for a while. Annoyingly, he was pushing it while we still got regular emails from the security/legal teams saying we weren’t allowed to use it yet.

We now have access, but that CIO is also gone and we don’t hear about it much anymore. We still have the tools, and a general AI (for use outside of code) is coming, but the blind hype seems to be gone.

Maybe your leadership will shift, or come back to reality in time.

Personally, I think it’s a red flag when leaders jump on hype trains that hard. They’re so desperately trying to avoid missing the boat that they ignore common sense and risk. Not good.

You’re right to be cautious. Relying solely on “vibe coding” and LLM-generated code can accelerate prototyping, but usually at the cost of long-term maintainability and deep technical understanding. If leadership is actively discouraging best practices like manual testing and code review, that is a red flag, especially for a senior engineer invested in quality and growth.

Personally, I had try to have a candid discussion with your CTO/CEO about your concerns and see if there’s room for a more balanced approach. If it’s clear they’re not interested and you start feeling your skills are stagnating, it’s reasonable to look for a company whose engineering values align better with yours.

Ultimately, AI tools are “just tools.”

> The CEO & CTO are both obsessed with it and promote things like "delete entire unit test file & have claude generate a new one" rather than manually address test failures.

So what are the tests actually for then?

Quit.

How can you trust your economic welfare to be in the hands of people that believe in magic?

Yes, but not without something else lined up – it’s tough out there right now. There are absolutely companies out there with much more sensible AI policies. It is good to have experience with it, it’s a tool in the toolbox, but best to be rid of the starry-eyed marks taken in by the hyperbole.

> "delete entire unit test file & have claude generate a new one" rather than manually address test failures.

First thought, "wat", what if the code is broken, not the tests...

Second thought, if the entire unit test file is getting generated by claude without significant oversight like this suggests... I suppose its probably the tests that are broken.

---

As for your own situation. Looking for a new job because you aren't happy with the process at your current job is completely reasonable.

I'm not sure that you're right that this workflow will cause your technical growth to stall though - the freedom to experiment with strange new (probably ineffective) workflows on someone else's dime might well be beneficial in many ways. But if you're not happy doing this, and you have the skills and network to find a new job, why wouldn't you?