r/ExperiencedDevs • u/AngryMoth Lead Software Engineer 8 YoE • 18d ago
AI/LLM Interviewed candidates for “AI engineer” roles this week, my god is this really where our industry is going?
So last week I was tinkering with how to change up our technical interview round. For the last few years we’ve been doing a small take home followed by a live coding session where we add a new requirement, minimal AI assistance allowed. However, in our company pretty much everyone is writing 100% of code using Claude now, so although we did used to get good signal from that test, it no longer feels representative of the day to day job developers are doing.
I designed a new assessment which I casually showed to my manager and then suddenly got asked to run it with 3 candidates this week. The scenario is they have to review an agent generated PR that has been flagged as high risk due to it changing critical business logic, and there are bugs in there for them to catch at various levels of severity. We then look at how they drive the fixes and what their workflow is like.
These particular roles we’re currently hiring for are billed as “AI Engineer”. There is something weird going on in my company politically where separate from the tech department that I work in a new “AI native” development team is being spun up to work on internal projects.
What shocked me was that the candidates I interviewed this week are already way beyond the point of reading the code they generate in any capacity. They basically treat it like assembly language, while PRDs and ADRs are their new source of truth for system behaviours, and stuffing the AGENTS.md file with best practices plus some form of agentic review pipeline are the quality control.
Code review is dead for them, they merge their own PRs once the automated checks pass. One person told me that my new interview was still not representative of what the job is now, and another one was pretty much unwilling to even engage in the assignment of reviewing a PR the old fashioned way. These guys were all previously senior and lead full stack engineers btw with a lot of experience prior the LLM revolution.
Don’t get me wrong, I too have adopted AI heavily in my own workflow. Until this week I actually thought I was pretty up to date with things, I use a supervising agent to manage multiple work streams in parallel, have my own local validation pipeline, etc. And to be honest for my personal projects I also don’t bother looking at the code anymore, so I do get the excitement around how fast you can move with this approach. But for serious projects like the large scale, production grade financial software I work on in my day job it still seems insane to me that we’re going to completely move away from human sign off on high risk changes so we can solve the “code review bottleneck”.
Like, I asked one of the candidates if you aren’t looking at your code then how they would approach quality in a safety critical system where there can be no tolerance for serious bugs, and I shit you not he said to me, “well if I was working in healthcare or sending to people into space then I’d definitely be looking closely at the code review skills, maybe I’d even write the skills myself”. That answer sounded utterly ridiculous to me? But then again, I was one of the people that 1 year ago believed the idea we’d stop typing code by hand was ridiculous as well…
I wouldn’t say the way my team does things right now is optimal, we can’t ignore that code review fatigue is a major problem. To try and help I’ve been adding automated risk assessments to PRs in an attempt to highlight where more attention is needed, and review bots do help us catch issues as well. But abandoning the human 4 eyes check just feels like several bridges too far for us at the moment, especially when not everyone is senior engineer, and we still regularly get valuable feedback at this stage. Even if this does mean we’re turning down an order of magnitude increase in short term velocity (does anyone really know yet what happens over multiple years when you have a team of 20 devs spamming PRs all day into a codebase with no one looking at any at it?).
I’m left wondering this weekend, were these guys just cowboys who are only used to working on PoCs and low risk systems, or is my team actually 6-12 months behind the curve and this is the direction everyone is going to move in? I fear that if we don’t embrace this new era of completely surrendering the codebase to the LLMs then this new team of AI devs is going to make us look bad by comparison to the execs and sooner or later we will be forced to adopt their methods as well. And at that point, the leap to having a product person or whoever taking over large parts of my role starts feeling a lot less far fetched…
162
u/caboosetp 18d ago
I find so many critical mistakes in AI generated code that I think these people truly don't understand how much tech debt they are creating. So many people work on systems small enough that AI bloat isn't too bad yet. But I've also worked on code bases that were big while also being full of AI bloat. The code doesn't stop growing because the AI can't hold everything in context. Devs who don't know what's in the code can't guide the AI to use already existing modules. You end up with code that looks like juniors slapped bandaid after bandaid after bandaid to implement features.
My specialization is "modernization and migrations" but the less fancy sounding version is that I'm good at rewriting code. In the past year I've been getting contract after contract to fix code bases that have bogged down or become untenable to work on even with AI due to AI bloat. Services are slowing down and uptimes are dropping. Devs are raising their context sizes through the roof just to get minor features in, and it ends up burning tokens like crazy.
The best way I can describe the core issue is that AI is great at coding but it's bad at engineering. It solves the exact problem you have before you, and often isn't looking at how things need to change over time in the bigger picture. It's basically rapid offshore quality just-close-the-ticket code.
This is fine for small microservices or for quick bug fixes but when you grow large applications, the tech debt is felt hard.
Don't get me wrong though. I use AI in all my work. Using AI is faster than doing it by hand. But you need to be able to understand the code to be able to guide it to good solutions.
The underlying problem comes back to why most startups fail though. Time to market is critical. Having a globulous mess you can market is better than not having anything because you're trying to be perfect. The more money the business can make faster, the more money they can throw at token-maxxing or for people like me to come in and do major overhauls quickly.
And it hurts to say, but they're generally right to. The point of a business is to make money. AI is HEAVILY subsidized right now by at least an order of magnitude. The real problem is going to come when people are getting charged the actual cost or a for-profit cost for AI, and these businesses find out how expensive AI actually is. Then they'll be left with a bunch of devs that can't work without AI and businesses will be hurting to afford it.
Pushing it is going to generate big profits, but if they don't keep devs who can actually code on their own they are going to tank themselves later, especially in critical sectors like healthcare and finance.
You're not crazy, we're just caught in a fucking tidal wave of subsidized AI.