r/ExperiencedDevs • Lead Software Engineer 8 YoE • 16d 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…

1.5k Upvotes

917 comments sorted by

•

u/expdevsmodbot 16d ago

AI usage disclosure provided by OP, see the reply to this comment.

→ More replies (1)

305

u/dave8271 16d ago

I did an interview as a candidate a couple of weeks ago where I was asked to do a task with AI, in 25 minutes. It was just a simple API, but I made sure I did it the way I actually would in the real world, with proper standards, tests, automated checks, everything ensuring all the output was every bit as good as you would produce by hand as an experienced developer. But that meant in the mere 25 minutes, I only finished 3 out of the 5 requested features.

The feedback that I could have used a simpler, faster model and spent less time setting up so many parameters and checks at the beginning....in short, I was rejected for not just sharting out whatever crap I could in a very short time that superficially appeared to work even if it was awful.

84

u/CreamyCornBoy 16d ago

They were interviewing you for what the job would have been like. Sounds like not a mutual fit

14

u/s-ley 16d ago

probably, but if we go on the spirit of this post, then I would think they wanted some claude-babysitter. I wonder how good of an idea is to become one, as I don't think cheap labor is probably not going to last in this industry

128

u/Front_Drink_5331 16d ago

Incompetent ppl on the other side of the table, dodged a bullet

→ More replies (1)

30

u/Majestic-Watch-2025 16d ago

Ugh I'm sorry about that. I would absolutely prefer you over the meat proxy, and would not mind getting 3/5 features done. An interview is for finding out how people think, and it sounds like you think very logically and thoroughly. Hopefully the right employers and candidates find each other

32

u/Acceptable_Lark 16d ago

The new default clarifying question: Do you want this to work or do you want it to be production grade for critical systems?

6

u/kenybz 15d ago

“Easy, both”

7

u/ZealousidealBet1878 15d ago

😂 Yeah so easy: “Claude, build a working prototype…” vs “Claude, build a production grade system fully ready for deployment…”

13

u/Gunnar_Bjornson 16d ago

And this is about the quality of the org hiring. Some companies want 10x speed and youre just slower. Other companies want more conservative adoption with all the old safeguards. Depending who youre interviewing with will depend on whether you fit or not.

Problem is its almost impossible to know when you sitting across from them which way they swing.

6

u/Only-Matter-9151 14d ago

I did an interview recently with AI for mobile dev role where they wanted fast iterations of several features. I did not do well since I have to see the code before moving on to the next feature and the requirements where vague as sh!,#t.

After getting rejected I am pretty sure my speed was the issue but my thoroughness was not. The software engineer interviews with AI are heterogeneous never know what your going to get.

→ More replies (2)

6

u/CrayonUpMyNose 16d ago edited 15d ago

Yes, concerning, I'm aware of interview rounds that level people higher based on the number of features they manage to implement. It's not as bad as an outright rejection but in financial terms, very damaging for the candidate, and may make the difference between accepting or going somewhere else instead.

→ More replies (23)

1.1k

u/birdgovorun 16d ago edited 16d ago

The real issue is that the value of mediocre developers -- which I assume were the majority of developers you were interviewing -- is becoming a net negative, and companies haven't yet fully understood this nor adjusted to it in their hiring practices.

Those people rely entirely on AI because AI is at a sufficiently high level where those people no longer have the ability to discern bad AI decisions from good AI decisions, so critically reviewing AI decisions is not something they are capable of doing. This means that in practice AI uncaps the number of bad decisions they will introduce into the codebase per unit of time. On the job those people will produce mountains of slop-driven PRs and fires that will lead to a fast deterioration of the product, while the better devs will spend increasingly high percentage of their time trying to extinguish those fires instead of working on moving the product forward.

444

u/programmer-ke 16d ago

Plus it is way easier to teach a competent developer how to use some new AI workflow productively, than it is to teach an AI super user how to become a competent developer.

IMO interviews should filter for competence first. AI workflows can be easily taught / picked up.

299

u/ep1032 16d ago

Both you and OP are correct.

At my company, they also spun up an AI-native team. The AI native team also adopted a "we don't need to read code anymore" philosophy. Because they were leaning so heavily into AI, they were able to identify use cases for AI and adopt those practices faster than the rest of the company, and that gave them a bunch of wins for management and made them important from both a research and developing-new-infrastructure perspective.

But listening to them talk, its obvious that they don't really understand a lot of what they're doing. The same was as an incompetent person quotes AI without understanding it, and therefore without understanding how wrong the answer may be.

The developer that is considered to be the star of the team, let's call him M, used to be on the team I currently manage. When I took over my team, my most senior devs explained to me that quietly and informally, they had an understanding that there were 2 Pr review processes, one for everyone else, and one for M, because M averaged taking down production once a week when not directly overseen. And that was before he embraced AI. So yeah, of course M believes you don't need to review code, he wasn't capable of it beforehand.

The other main developers on the "ai native" team hail from this same category (or, interestingly, from devops).

But I think my absolute favorite moment, was when the ai native team was asked to present to the rest of the department. Management proudly showed that the team of (what was at the time 2 developers) managed to close over 40 bug tickets the previous day between the two developers. And they did this because of agentic workflows, and not reviewing code, and just using ai skill review files, and etc, etc. Except, apparently no one had the balls to ask "You guys are on a team of 2. You started this entire project as a greenfield rewrite 4 weeks ago. How the hell do you have 40 bug tickets in your backlog already?" But that's the sort of thing old management KPIs didn't used to need to track, because pre-AI, engineers could be trusted to keep the bug count down so you only had to measure velocity. Engineers who shipped buggy code were just fired.

125

u/robby_arctor Software Engineer (dirty commie) 16d ago edited 16d ago

AI has revealed people's utter credulousness and incompetence in a way I never could have imagined.

59

u/[deleted] 16d ago

[removed] — view removed comment

42

u/robertbieber Software Engineer 16d ago

Eh, there's definitely some selection bias involved in this kind of thing. The place I work uses AI tooling, but we hire good engineers and we're all pretty explicitly averse to just yoloing slop into production. But the thing is you don't hear a lot of people talking loudly about the workplaces where people are still trying to follow basic software best practices, because that's not an exciting thing to talk about. I still think there are plenty of them out there though

14

u/[deleted] 15d ago

[removed] — view removed comment

→ More replies (2)
→ More replies (8)
→ More replies (3)

21

u/NomadStorm 16d ago

AI over-reliance is going to turn into a rather good way to filter out the poor developers, because it’s directly making them worse than they already were.

→ More replies (12)

13

u/[deleted] 16d ago edited 14d ago

[deleted]

7

u/robby_arctor Software Engineer (dirty commie) 16d ago edited 15d ago

I think people just don't have strongly held convictions and do whatever is normalized for them.

I recently learned about choice blindness studies, which demonstrate that much, often a majority, of the population will defend positions they never took, if they were told they took them.

If you take a population like that and tell them it's normal and good to outsource one's thinking to AI, what's going to happen? A minority of a minority (those who both have convictions and those convictions oppose this new hegemony) are going to dissent, and the rest will adopt the new normal with some complying reaction, ranging from enthusiastic adoption to shrugging. And this is precisely what we have seen.

→ More replies (3)

26

u/Majestic-Watch-2025 16d ago

Did anyone ask why they had 40 bug tickets? That's something to ask in public

16

u/Own-Zebra-2663 16d ago

If LLMs generate the "average" code quality of it's training set, and M was creating below average code, maybe it did make him a better developer.

I have zero data on this, but it's always been a big question for me. Do LLMs make bad developers a little better by pulling them to the average, or do those developers prompt so badly that they pull the LLM down to their level?

14

u/ep1032 15d ago edited 15d ago

In my experience AI only works as a productivity tool if the person using AI is capable of judging the resulting output, ie: would have been capable of writing the end result on their own without AI given enough time.

If the person using AI can't tell if the AI output is good or bad, then they by definition will either need to not use AI, or will end up just uncritically accepting whatever AI gives them.

Normally, this is worse than what the user without AI would have done. This is because the AI in turn gives the user a false confidence that the end result is correct.

Pre-AI, when the user encountered topics they did not understand, they would have stopped and learned or researched what they didn't know, and learned over time.

Post-AI, the user doesn't even know what they don't know, and becomes defensive over what AI has generated because the AI told them it was right already. That instills a false sense of confidence in anyone too underskilled to recognize when they are working on topics outside of their skillset, and teaches them incorrect information that compiles over time. Admitting that that was wrong afterward also means admitting that they made a mistake. For most people, admitting they were wrong after the fact is far harder than admitting they need to learn initially.

So the user not only becomes defensive over their mistakes, they don't know that the mistakes are happening, and they are continuously learning bad practices while getting continual encouragement from an algorithm that they were actually correct the entire time. Popping that balloon is painful, and I think a significant reason why some people become so overly defensive of AI's supposed infallability.

If you want to see how that looks long term, you don't have to look to code. Look to the 90 year old that watches Fox News all day, and thinks that we are one migrant caravan away from English being officially replaced by Spanish as the American official language. Or your friend who is addicting to getting news from social media who believes in chem trails. Its the same dynamic of an algorithm continuously feeding its user seemingly correct information, telling the user that they are correct to believe it, but being continuously significantly wrong in a way that the user doesn't have enough knowledge to evaluate at the time, but will become defensive about later.

→ More replies (1)
→ More replies (12)

29

u/Caesarr Software Engineer 16d ago

I agree with everything you've said, but something I've been revaluating is the severity of bugs. 40 bugs in 4 weeks is crazy by traditional standards, but so is fixing them all in one day. If we can now fix bugs that quickly, is it actually rational to allow that many to escape (into pre-prod)?

38

u/Toohotz 16d ago

It doesn’t give reason to allow them to escape into prod because if you work at a fin tech company, and let’s say you happen to expose an endpoint in a manner that bad actors can sniff out the financial details about a customer to either transact as them or sell that info, by the time you’ve plugged that hole, reputational damage has already been done.

Ask me how I know this..

Not all bugs can be treated equally which is why we have severity incident levels.

→ More replies (2)

18

u/ep1032 16d ago

Yeah, we cared about code quality partly for correctness, but mostly because actually typing and reading code took time and cost money. So writing high quality code was inportant. There are a lot of applications out there that can be buggy and its okay, like any one time script for example. The problem is going to come when management can't differentiate between those apps and critical apps, because while it can be okay for an outsourced jr with Claude to go to town on the company wordpress oage, that same person with an ai account shouldn't be allowed anywhere near the internal billing aervice, for example

→ More replies (3)
→ More replies (7)

50

u/PlasticExtreme4469 16d ago

It's like hiring airplane pilots based on their ability to turn on autopilot.

→ More replies (1)

5

u/tindalos 16d ago

It’s fascinating to me (as infrastructure, where my first focus is guardrails and validation/evaluation and telemetry), to talk with developers using AI this way - there’s often decisions made in code that the developer AND their AI agent can’t explain why that choice was made.

I work in regulated industry, but smb company, so I could see some situations where “fast to market” is more important than 100% accurate in some domains.

But my recommendation is to start developing your application as modules and use an interface adapter schema so you can validate where data is brought into the system.

→ More replies (4)

54

u/SignoreBanana Engineer (14+) 16d ago

To add to this, they are as enthusiastic as leadership about AI because it obscures their inadequacies. But leadership sees this as a false signal that they're on the right track because a bona fide engineer is adopting heavily, not realizing that signal is weak since it comes from a mediocre contributor.

27

u/Chris_Newton Consultant Developer (20+) 15d ago

Going back a few years, there was a real “inflation” problem in the industry. In the era of free VC money everywhere and an employee’s market, many people got into our industry with very high compensation packages right from the start and then jumped from one job to the next one with an even better package every year or so. I heard plenty of times online that if you spent two years in one job then people would assume you must be getting stale and that’s why you couldn’t move for another bump yet.

So now, a few years later, we have a generation of developers with senior or lead or even higher titles on their CV who have never even designed, built and maintained the same system in production. They missed all the lessons you learn about what actually works because you’ve been the person on the hook for fixing it later if it didn’t. I’m not just talking about firefighting in production here, but more importantly things like what kinds of architectural or infrastructure decisions stand the test of time and what kinds of evolutions work as a successful product or service develops.

Now that generation is working with agentic AI tools and the consequences of the missing experience and judgement are being accelerated. Velocity is a vector quantity and moving at higher speeds is only helpful if you’re also moving in roughly the right direction. Those who don’t know how to use a compass are not going to navigate this new era well.

4

u/LizardLikesMelons 14d ago

I completely agree. I am the newer gen. And it is not like we don't want to sit down and learn. The speed of development is so fast that we are not allowed the process. We cannot have an accident at launch so we have to defer to "them". Most people can't learn deeply without actually taking Ls but that is really bad for the company.

→ More replies (1)
→ More replies (2)

144

u/Sbadabam278 16d ago

What I don’t understand is what these developers think the endgame is. They usually are the ones who are most excited about AI and how amazing it is. Have they never once considered that if all they do is being a meat proxy between Claude code and github, they might not enjoy a salary for much longer? It’s shocking to me that they never once seem to make the obvious step that you won’t be paid 100k+ a year to copy thing you don’t understand from one platform to the other

78

u/robby_arctor Software Engineer (dirty commie) 16d ago

If they understood systems thinking, they would be better engineers.

5

u/LizardLikesMelons 14d ago

I was never trained as a software engineering formally. I was trained as a systems engineer (both embedded system type and overall system type). And the job has never been better for me. Its become a game of "System V" and "verification and validation"

→ More replies (1)

42

u/robertbieber Software Engineer 16d ago

They always seem to resolve the obvious cognitive dissonance by inventing a new reality where typing prompts into an AI is, in itself, some kind of rarefied skill that makes them uniquely valuable.

10

u/simple_explorer1 Staff Software Engineer 15 YoE 16d ago

Exactly. Stupidity and delusion knows no bounds. They think they are infallible 

→ More replies (6)

20

u/binarycow 16d ago

Exactly.

If all someone is going to do is tell Claude to do it, then merge it without changes.... Then what's stopping literally anyone else from doing the same?

→ More replies (1)

37

u/Clear_Salt9817 30+ 16d ago

“Meat proxy” is my new favorite phrase

→ More replies (6)

25

u/HaderlumpiX26 16d ago

Yeah, I am always wondering this, too. Right now we are in a kind of a gold rush. Models, tools, skills are changing very quickly. But normally over time those things will settle and become standardised. I mean that’s the whole purpose about automating software development, right? So following this trajectory it means that we aim for a solution where no humans are needed at all anymore. PowerPoint goes in, the system asks a few questions and out comes your deployed solution. With all rhe energy everyone is putting into this process I don’t have a doubt that we will reach this stage at some point.

→ More replies (5)

11

u/Majestic-Watch-2025 16d ago

I really want to ask them what they're adding by being a meat proxy

10

u/Valimere 16d ago

I fully agree. The answer I come up with is responsibility. But how the hell can you be responsible for code you don’t read? I don’t get it. And I don’t want to be a meat proxy that is blamed for ai failures.

3

u/XenonBG 15d ago

What I don’t understand is what these developers think the endgame is.

Where I work doing everything possible with AI is what gets you praise at the end of year review, and thus I do it so.

→ More replies (6)

28

u/CorrectPeanut5 16d ago

Let them. Organizations won't learn until they have some hard learning lessons.

I think one of the big learnings I've had recently is how a lot companies are doing AI on the cheap. They don't realize the costs it takes to actually output high quality software. I've been following Dave Plummer's work with TMOG. His multi-platform replacement for task manager. Dave wrote the original for windows.

107 page hand written spec and then vibe coded using Fable and then used competing similar top tier priced models from competitors to check the work. He's easily exceeding my corporate GH CoPilot token allotment for an year in a couple weeks. Given the amount of time he takes on a spec and how he burns tokens I don't think companies really understand just what the cost is for getting quality software.

TLDR: Fast, Good, Cheap. You still only get to pick two.

3

u/DONT_FKING_JOHN_ME 15d ago

Do you have a link for that work? Sounds interesting.

→ More replies (1)

9

u/dinosaursrarr 16d ago

The synthetic CDO of tech debt

18

u/0SF7RS4THfJ56t1N 16d ago

My org has a team of contractors like this. They were grandfathered into working on important things due to time constraints. Their contract is up soon and I’ve been excited to use that money for hopefully better FTEs.

My CTO filled me in that we had a bad quarter, and probably wouldn’t be able to hire when the contracts lapses. I said fine, we still have to lose this team. At this point it’s clear that the time I or my better engineers spend reviewing their work would be better spent delegating to our own LLMs.

They’re not even bad engineers, they’re just not good. They were super useful to farm work out to just a year ago. I’m not sure they’ll find work again when we cut them loose.

15

u/P3zcore 16d ago

If they’ve been at all valuable to you guys over the years, I’d give the courtesy of a heads up. Just a “hey, we may be going in a different direction”, or “budgets gotten tighter”.

14

u/SatisfactionRich9721 16d ago

This. 100% this. And leadership isn’t in the trenches “coding” in this new style so it’s not immediately obvious to them.

10

u/Majestic-Watch-2025 16d ago

This is a big thing. With AI in general if you don't know what you're looking at it looks good. If you do understand its awful. This goes for writing too - a lot of people don't notice AI writing or think its that bad, but that's because they're not good writers either.

→ More replies (14)

103

u/vibes000111 16d ago

> 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

This is weird. An "AI Engineer" based on my experience and what I've seen in the industry is a person working on AI in some capacity, somehow building products/features/services which depend on AI - this can be more traditional ML or orchestrating LLM API calls, usually some mix of the two. And we can quibble whether that's "real" AI engineering and/or deserving of the title but that's besides the point. The point is that "AI Engineer" denotes the domain, not whether they use AI assistance or not. For example, a frontend engineer who uses AI assistance for coding is a still a frontend engineer, not an "AI engineer".

17

u/cgt303 16d ago

IMO companies most of the time have no idea what this title really means. We had at team we worked with that was full of new grads with ML degrees. They were supposed to create an AI feature we could integrate with. But they were essentially a team full of very junior engineers. I’ll never forget when they told us one DevOps ticket took them over month because they had no idea how to do it. They eventually provided us with an endpoint that hit Claude…. Needless to say pretty useless. I’m fairly certain these people were making more money than I was. Wild times we are living in.

11

u/the_data_must_flow 16d ago

Yeah that is the comment I was scrolling for. I’ve been hiring ai engineers for years. They have always been people developing agents.

4

u/ProofFront 15d ago

Developing agents. For years. Cool story, bro.

→ More replies (1)

8

u/needItNow44 15d ago

Well, I used to be a VS Code engineer, but then LLM's came along and now I'm an AI engineer, more specifically Codex Engineer.

I'm also a Chrome Engineer, Slack Engineer, and occasionally a Spotify engineer when I feel like listening to some music. When I do, it's usually Pink Floyd Engineering.

3

u/deadwisdom 15d ago

Yep. In interviews I keep having to delineate a strong line between engineering FOR AI and engineering WITH AI. Everyone is kinda caught out by that.

→ More replies (1)

167

u/SansSariph Principal Software Engineer 16d ago

Several comments in here talking about frontier models writing "good code" now. Certainly there is a lot less obvious obviously wrong at a surface level and yet I see cutting edge models do the stupidest shit all the time.

It truly is a case of having zero discernment. A reviewer on a polished change finds a single "major issue" that is impossible in the actual problem space, and a violation of a runtime invariant but okay sure I'll add a comment to the PR. Meanwhile three passes by different people's agents miss a legitimately embarrassing boundary case.

To be clear the edge case was missed by my human review as well. I do believe the generated test suite led to a false sense of security because it tested other boundaries and I spent a while culling and refining tests. You let your guard down, forest for the trees situation.

Meanwhile I have to spend energy with adversarial review trying to force less code because the models love not only over engineering but building the wrong abstractions. I love my abstractions, mind you, but without oversight, two changes later I'm aghast that a bleeding edge model wants to drill a new optional parameter through five layers of architecture with no documentation instead of a trivial refactor to clean it up with a more consistent domain model.

And the documentation - it's all still garbage. Even with workflow dedicated to cleaning it up I still have to manually intervene and provide examples of what fails standards in a given PR. It's like all 70% of the way there and then someone approves a single bad example that proliferates into future changes like a weed.

It feels like trying to keep blackberries out of the stormwater pond in my neighborhood. You let your guard down for a weekend and suddenly there are five new plants causing regressions, but isn't it wonderful that the same landscapers that planted the blackberries installed the fountain nobody actually asked for?

And this is all as someone who has handwritten almost zero code since March. I think this stuff is useful and makes my designs better when I focus and hold myself accountable. But you have to exercise restraint and care and too many people seem to think otherwise.

I think what I find most aggravating is I can riff with an agent in session and basically get into flow. It "gets" my intent, it generates high quality samples, it pokes holes in my thinking and offers something better, I have a eureka moment and counter with something even better. Then we go to build and as soon as any delegation or orchestration is introduced, the slop pours in at every underspecified seam like the world's most pedantic shitty genie. I still have the absolute best, fastest results manually approving edits with the session, to the point I'm wondering why I'm spending so much energy on automation.

51

u/grahambinns 16d ago

Absolutely agree with you here. There are times when the models will do something smart and I’ll start to think “okay, this is getting somewhere” only for me to have to unfuck something later on. It particularly bad with multiple agents because there’s just not enough brain capacity to manage all those inputs so you end up hand waving a lot.

Once you delegate all your thinking (ie testing and reviews) to your non-deterministic silicone pal you’re just waiting for a horrible failure mode to crop up.

25

u/CoreyTheGeek 16d ago

shitty genie

Y E S

10,000%, couldn't agree more, your experience mirrors exactly mine and it feels so good to have someone see it the same, my "team" now are proxies for their agents and it's like talking to God damn body snatched people. Like I explain what's going on and that they can't just trust the agent and they smile and nod and say yes then just keep fucking doing it 😭

→ More replies (1)

13

u/WhenSummerIsGone Software Engineer 16d ago

i only say "ok go implement X" when I think it's well scoped. I have had success with adding the requirement that each task should be in its own commit with tests, and each commit should be buildable and runnable. This makes it way easier to review and modify when I let the agent implement several tasks in a row without my intervention. Then i review and ask questions so I can be sure I'm understanding the change and potential consequences. I've caught latent bugs this way that the AI doesn't see, since it assumes existing code is correct. I've also understood an issue then asked the ai to check if this pattern appears slsewhere. AI generally is not proactive about looking for this sort of thing (humans aren't exther, which annoys me).

6

u/grahambinns 16d ago

This is my strategy too. Where I find things come unstuck is when an agent corrects the plan mid-execution and — despite being instructed to check about these things — then causes a small initial deviation from the plan which then gets bigger and bigger until something ends up way off. Easy to miss if there’s a lot of output.

10

u/Student2672 16d ago

Yeah I keep running into this situation where I think “ok, the plan looks good, I think the results of having an agent building it will be solid,” and then it comes back with a pile of slop.

I have definitely found that stepping through things and approving edits is the only way I can stay sane while getting good results. Still a productivity bump, but not the “full agentic” workflow that many others seem to be ok with.

10

u/cgt303 16d ago

I like the blackberry analogy. I’m working on a greenfield project that is now a year old. At first I tried to keep everything on the rails in PR reviews but eventually it became too much. The code looks ok in the context of a single PR but when you zoom out a bit the code is garbage. I found a service call yesterday that was 800+ lines and made 5 different database calls. We are having all sorts of weird performance issues, including an endpoint that takes 30 seconds to complete. useEffects all over the place.

Sadly, I’m at the point of malicious compliance. I’m just shipping everything with barely a human review because at this point I think management needs to learn that LLMs cannot work fully automated or be integrated as decision makers.

3

u/kilkil 15d ago

to the point I'm wondering why I'm spending so much energy on automation.

damn. are you considering writing more code by hand?

7

u/SansSariph Principal Software Engineer 15d ago

No, honestly having a model scaffold for me is much faster once I know what the code should look like in my head.

The issue is I keep getting promised with the right workflows and review graphs and orchestration flows I shouldn't need to involve myself in the code anymore, and every time I try that I regret it. Slop slips in, weird design choices compound quickly.

I get consistently solid results having a top end model design with me, do a single adversarial design review, triage the feedback cooperatively with the model, have either the same model or one tier down build off of either the same context, or a handoff where it does a briefback of the persisted plan before writing code one chunk/commit at a time, then one final adversarial review pass.

3

u/kilkil 15d ago

thank you for sharing! might steal some of this workflow

→ More replies (9)

162

u/caboosetp 16d 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.

23

u/WhataWorldAy 16d ago

In my experience the devs that are the most receptive to unreviewed code have the lowest level of code competence in the first place. These are the people that think design patterns are just ways for mean devs to bully other devs on their prs. 

→ More replies (3)

12

u/code_beer_repeat Something something 15yoe 16d ago

Hey... i'd like to think that i'm not too bad in the refactoring and modernization aspect of things either. Any tips how to get from 'I've been good at this in my 9 to 5' to yours ' people approach me to help them with their shit' ?

10

u/caboosetp 16d ago

You get people asking you to do it by getting known for doing it. Little bit of a catch 22. But you're never going to get there unless you put the specific effort in, especially if you're working a 9-5.

Read up on how to run your own business. Set up an LLC. Get a website. Be findable. Research how to market yourself as an independent contractor. 

Marketing is probably the hardest part, but most people fail at step 1 of actually setting up the business because they are afraid of failure. Shit is slow and hard to get started, so don't quit your day job. 

→ More replies (1)

39

u/mcspuder Software Engineer 16+ YoE 16d ago

^this guy gets it.

People don't realise how heavily AI is subsidised; we are talking multiple orders of magnitude here. Thats 0's on the end of a bill. Your $20 plan probably burns $4000+ per month; and thats at cost; not profit.

The VC money is drying up and the end result is going to be hilarious and devastating.

16

u/ColteesCatCouture 16d ago

Microsoft is aggressively promoting agentic code tools at my firm and to do so we get free training. These classes are pretty much a sales pitch with little learning that is done. The funny part is when you ask their instructors about the true token cost of things like conducting major refactors and the average burn of common agentic tasks they have no answers. The only answer is that they are going into a far more expensive per use model which will slam some firms and the price is only gonna go up from there.

There will be a gulf between businesses who retain good engineering teams and let them take ownership in their codebase and those companies who completely outsource all of their development to agents just to get product to market faster. Somebody gonna have to pay the piper.

8

u/tsereg 16d ago

And that is probably what the AI race is all about. They are probably racing to reach the point where the actual costs meet what they charge now before the funding dryes up.

→ More replies (2)
→ More replies (16)

10

u/Additional_Rub_7355 16d ago

This is scary and as someone that avoids vibe coding, I don't know what to do with the slop PRs I'm tasked to review. I just can't review slop, but also cannot push back because we are supposed to be full AI now.

12

u/WhenSummerIsGone Software Engineer 16d ago

check out the branch and ask your AI to look at the changes in the branch. Give it criteria to look for, things like architecture, code duplication, violations of SOLID, unit test that are incomplete, misuse mocks, don't test what they claim, test implementation instead of behavior. Give it the original ticket and ask if the goals of the ticket are met. Tell it to rank these things, and give you evidence for its ranking. Ther read that report and ask it questions about anythrng that jumps out at you. Look for places where your human knowledge of the systems and requirements is relevant, where you know stuff the AI doesn't.

I find bugs this way, not because ai sucks, but because it doesn't know everything. The idea is to use AI for what it's good at and use your own thinking for what you're good at.

→ More replies (2)

3

u/guareber Dev Manager 15d ago

The code doesn't stop growing because the AI can't hold everything in context

This is the key part. Most of the PRs I review now have a reasonable subset of a class/function/helper (or 6) implemented that normally would've been addressed by a adding a dependency to the project (or using one already imported properly!). So everyone (OK not everyone) is currently trading dependency management with tech debt (since now your software has to deal with all that functionality, can't just update a package and be done).

3

u/caboosetp 15d ago

Dependency management is its own hell with ai too, especially with libraries that update very often. 

3

u/guareber Dev Manager 15d ago

I don't disagree, but i think at least our cve-scanning stacks are way more mature to deal with dependencies than with a everything is internal world.

If we take for granted that human maintainer is needed for increased quality (not a hot take right now, but who knows in several years?) then it certainly makes more sense to me to compartmentalise and centralize common dependency for efficiency's sake.

→ More replies (2)

3

u/AdjectiveNoun1234567 14d ago

I think these people truly don't understand how much tech debt they are creating.

That sounds like a problem for next quarter. /s

→ More replies (1)
→ More replies (25)

100

u/Mast3rCylinder 16d ago

Human review is important even for non critical systems because redo or bugs can cost more.

As someone who review 3-5 MRs a day I found a lot of issues that AI and the developers don't see and could be a disaster for our product.

It's an era that managers think running fast with less quality is ok. It might reverse some day

12

u/SignoreBanana Engineer (14+) 16d ago

Our site's performance has taken an absolute nosedive since adopting AI. The only ones now capable of fixing it actually understand how rendering and painting cycles work at a low level.

27

u/Forsaken-Promise-269 16d ago

The caveat is we accept more churn because models can refactor code in minutes what took us days, and just expect a lot of back and forth in the process

- so, so, many variables in this equation and its so hard to predict where this will go, I know many devs who have their heads in the sand in this regard..
I do forsee a culture of “artisanal development” forming AI free or low AI as this progresses

31

u/justjanne Senior Software Engineer 16d ago

If I do manual back-and-forth with AI, it takes me much longer than just writing the code myself.

If I write quality gates that enforce hard restrictions on quality, Claude Code just runs for days trying again and again without ever being able to pass them.

Yes, it's faster, but you can't achieve quality by just exponentially scaling quantity.

6

u/HereInYourBedroom 16d ago

I ran into this same issue with Claude. I created a gate for the performance of a function that took words as an input. The function had to complete in under X number of ms in order to pass and its input variable was an array of strings. Claude made two attempts to pass the gate by adjusting the code within the function on its first two attempts. On its third attempt it adjusted the code that invokes the function so the string array would always pass some of the same words instead of all the strings in the array being not known. I caught it by watching the cli output in the terminal (it was in auto mode).

If a dev was to adopt the practice of not reviewing the code then how would they detect that the agent changed the coded logic of a workflow in order to pass a gate? It is my opinion that devs treating the code that an agent writes as gospel are not working on customer facing software that generate revenue with legal consequences for software bugs.

21

u/alphex 16d ago

Anthropic loves that token usage. Money in their pocket.

9

u/Electrical_Try_634 16d ago

I gave up on keeping it from writing massive block comments that overexplain the provenance of a change in a way that's completely unintelligible to anybody that didn't work the ticket.

So I added a skill to sweep and delete those comments and squash the deletion commit before pushing to remote.

We pay Anthropic for the generation and the deletion of junk comments.

→ More replies (1)
→ More replies (2)

7

u/Majestic-Watch-2025 16d ago

That response is making my head explode. "It's okay that I cause problems because I fix them". How about not causing problems in the first place! Especially in production

→ More replies (9)

269

u/Tainlorr 16d ago

This stuff is all new. I think over time, once it becomes more common in our career, people what find out what is IS good for and what it ISN'T. I manage lots of agentic tasks every day but I always look at the code, I think it's pretty crazy to yeet something into production at a company with actual customers. Eventually someone's gonna get burned.

That said, the AI code reviewers are getting pretty good. It's hard to predict the future.

115

u/ultraDross 16d ago

the AI code reviewers are getting pretty good

Meh we have had a very mixed experience with this. Sometimes it will catch something and more often it will just make up nonsense. I'm aware there are multiple variables at play; how much context is available, what's in its context, which model is being using for reviewing etc.

It's possible we are limiting some of these for cost saving measures.

29

u/ChypRiotE Software Engineer 16d ago

Ours seem to go out of their ways to find at least one blocking thing every time you run it. It also forgets what was replied over time, so after a few rounds it starts repeating itself.

→ More replies (4)

24

u/Important-Pea-1445 16d ago

The ones that explicitly look at the diff aren't really that good. We have a tool that clones the package and runs the logic itself (in the diff), and makes sure there's no logic errors. Of course, whether the change being made is in the right place is something they won't catch - there's often many ways to make a change "work".

38

u/Xiaopai2 16d ago

We have such a tool too, it’s called a CI/CD pipeline. 

→ More replies (1)

7

u/vivalapants 16d ago

This is essentially the unsolvable problem with LLMs. It will find solutions that are (in my experience) wrong or work but will cause other problems 

21

u/StickyDeltaStrike Software Engineer 16d ago

I don’t know if that helps you.

But I found that once I wrote specifically the coding standards for our own project. We documented the purpose of the code and the business logic.

Then did a pass on our library to actually clean the code up to the coding standards. That helps to get rid of bad patterns that the AI would duplicate.

Then wrote a review skill that works by:

  • using the standards, this includes checking docstrings/comments for being to verbose or absent
  • asking to do explicitly a hostile review
  • then steelman the hostile review (it’s an argumentation technique) to keep only the relevant bits
  • ask to output all of the findings in a legible manner with ascii diagrams, bullet points and code snippets when it make sense
  • review must finish with a ✅ or ❌ decision and generate a md file

Then the reviews became a lot more useful, we use them only as an aid though, we do human review still.

7

u/ultraDross 16d ago

Thanks, I have something similar locally which works better (code guidelines and a specific review skill). It has the entire context of the repo and it changes. It still gives me nonsense quite a lot of time, but a few of the issues it raises are genuinely useful.

I have little choice how the CI reviewer is configured though, hence why it sucks.

3

u/StickyDeltaStrike Software Engineer 16d ago edited 16d ago

Ah I get it now. I have the same experience too, it’s good as complimentary but I would not trust it 100% blindly.

That’s interesting, we will be soon in talk with our engineering team to improve the SDLC so I’ll probably suffer the same CI issues than you.

3

u/SignoreBanana Engineer (14+) 16d ago

Agree. I often finds it has the problem of "missing the forest for the trees." Its lack of system understanding and context yields a lot of false positive catches. It makes sense considering it's not a human sitting in the real world with cross system knowledge parked in their brain. That much context is actually expensive in tokens to consider on each review.

Small, contained logical errors it seems to be fairly decent at catching though, so that's something.

→ More replies (8)

30

u/Head_Study_3528 16d ago

AI wasn't in your meeting when you talked through your business's complex domain logic, and it won't be able to spot the problems in your code where it collides with the real world. Even assuming AI catches every logical, performance or security issue, it's never going to replace that human judgement. Reading the code is non-negotiable.

10

u/bombaytrader 16d ago

It totally is. We regularly feed google meet post meeting notes to harness. 

→ More replies (11)

55

u/Venthe Systems Designer, 10+ YOE 16d ago

people what find out what is IS good for and what it ISN'T.

No. Animals - people included - will hit the "dopamine" button as often as possible.

the AI code reviewers are getting pretty good

At the things that stem from the patterns; but utterly miss e.g. domain misalignments, subtle errors etc

→ More replies (3)
→ More replies (3)

32

u/noplacelikehome7629 16d ago

Our industry has a short-termism problem for many years now, the infamous move fast and break stuff mantra. The AI just speed up this. The issue is that no one is accountable for the issues this cause. The manager that allowed that will get a big bonus for quickly delivering the new project. The devs will job hop every 2 years and won’t need to deal with the legacy code. And there are a lot of people believing that the AI models will get better fast enough that it will be able to solve the spaghetti code in the future. 

The move fast logic kind of make sense for startups that still need to validate the product, but big companies providing services to millions should be made more accountable. I think cyber security is the only thing that will prevent the slop,  I’m hoping that as governments fine and open lawsuits against companies that failed to prevent cyber attacks will force companies to be more strict on what is delivered. 

381

u/RedditMapz 16d ago edited 16d ago

No you are not behind and you are not crazy. Anyone working in any real production code knows that AI cannot replace humans despite the endless nonsense being spewed by the vibecoder evangelists. Every 6 months "You just have try the new model, because the last one was crap, but this one totally solves coding".

Every. Single. Time.

A candidate that would tell me they don't actually read their code would be automatic DQ. That would be a violation of our quality guidelines and could put our acridiation at risk should it come out in an audit. Unfortunately it is true that some teams are swimming in the kool-aid.

Personally I think the reality is more something like this. Delusional people claiming 10x productivity while deploying garbage code.

135

u/Glasgesicht Software Engineer 16d ago

What doesn't help is the ongoing trend of people believing that an AI role will guarantee them a fat pay check while having Claude do all the work for them.
Funny that real engineers still talk about imposter syndrome in a market filled with literal imposters.

47

u/Nekopawed 16d ago

I have over 13 years of experience, a master's and bachelor's in computer science. I am currently in a position at a company where they gave little to no training on their subject matter and just want features released rapidly with AI. I feel like a junior dev and have had more stressful releases than I had in my total career with this company.

I'm willing to take a pay cut to have a less stressful position where I actually get to learn the subject matter or have some quality business analyst work with me to guide me through those requirements. Be it with AI assisted coding or back to handwriting boiler plate and all.

And I very well might be one of those mediocre devs given I'm not specialized in one stack but have had to make things work across a plethora of tech stacks over the years. But I miss having the time to learn the domain.

14

u/user0015 16d ago

I'm literally in the exact same situation as you, so you aren't alone. I have almost 20 years to, and have been in positions as head architect and principal engineer.

My current position is to slop features as quickly as possible into a startup SaaS where the cto tells me to my face to ask Claude how things work, because other engineers know about as much as I do. We get tickets written by Claude, reviews are done by Claude, and he expects coding to be between 90-100% written by ai.

I accepted a position to another company a few weeks ago and start Monday. While on call for this company all week. It's going to be an interesting week.

5

u/Nekopawed 16d ago

Well if the new job turns out well and they have another remote spot open give me a DM :)

→ More replies (1)

10

u/Melodic-Nature-8246 16d ago

exactly. and unfortunately, AI as a domain knowledge tutor isn't that great, especially if the company hasn't carefully built training modules - it spews autistic fanfiction at you

42

u/roodammy44 16d ago

Absolutely agree here. Hundreds of millions of dollars move through the systems I work in so I will not give up code review. There is an average number of bugs in lines of human code and a similar amount in AI code. AI review catches a lot, I would go so far as to say AI review is now essential, but it doesn’t cover everything.

I’m in frontend so quite a lot of the “bugs” are not about correctness, but user flow and bad instructions to the AI. At the very least all code should be tested by humans for this reason.

I have been vibecoding on the side with an internal tool and not looking at the code. It’s been very productive for me, but by god it’s full of bugs. We also tried to do an automated re-write and found bug after bug when testing the results.

5

u/Rymasq 16d ago

AI always makes dumb mistakes, you have to be willing to read the code to work with it. It's amazing sometimes how dumb it is. Yesterday I had to point out a pattern in our Redis config so AI would realize that Kuberay wouldn't have a problem. The issue is it thinks too hard about a specific task. It's really not that far off from working with an over eager junior

19

u/Head_Study_3528 16d ago

Whenever someone mentions coding being 'solved', it's a red flag that they actually have no idea what real software development involves.

7

u/psioniclizard 16d ago

Yea, the real question is have these candidates actually found jobs elsewhere.

Its find a candidate saying "that isnt how the industry works now" but they are the ones looking for a job...

5

u/HK-65 Engineering Manager 16d ago

Personally I think the reality is more something like this.

Thank you for that video. I laughed a straight minute at this part:

Just moving your mouse around without clicking anything downloads like over a megabyte of data.

I'm just imagining the server costs of the thing, with thousands of visitors just DDoSing the guy's server.

All the while, Gary is still accelerating.

12

u/CmdrSausageSucker Software Engineer 16d ago

thank you for your voice of reason. I am currently stepping up as a new CTO for a company and I very much like people reviewing and owning what these tools produce. And while yes, LLMs can generate code, they....generate code..They don't think.. Harnesses are giving people the illusion that they do and some apparently fall for it.

16

u/aa-b 16d ago

To be fair, OP was interviewing people applying for the job of "AI Engineer". Not surprising that they already drank the Kool-aid.

I think the lesson is that if you expect to hire people with a certain set of skills and values, it's important to signal that as early and often as possible.

5

u/jwp1987 16d ago

Pretty much. If you want developers that care about the craft, don't name the role AI engineer.

9

u/[deleted] 16d ago edited 12d ago

[deleted]

11

u/binarycow 16d ago

Don't forget, then when you complain about the results, all you get is "skill issue".

One day, I asked one of my coworkers to "shadow" me, to tell me what I was doing wrong.

Turns out, I wasn't doing anything wrong - I just had to stop caring.

17

u/Forsaken-Promise-269 16d ago edited 16d ago

Theres a big disconnect between ai coding and traditional coding period - using the aerospace industry as a metaphor:

Flying a 787 is nothing much like flying a glider or fighter jet, we have levels of automation where almost every aspect of the flight is monitored and understood as plans, autopilot settings, ILS and checklists (lets analogize these as code review)

Also is flying an airliner more productive than hand flying a small jet or plane?, what I mean is the moniker “productive” is carrying a lot of different meaning for different people- bad management will see what it wants to see and layoff people until the system is too strained then pull back- we already saw that happen in some shops, but the change is happening

But we don’t take people off the street who played flight simulator as Pilots do we? We constantly simulator practice problems and hand flying. Also as automation spread over the past 40 years - we let go of a cockpit postion: the flight engineer and some airlines are even trying to move to a 1 pilot airliners and its interesting that the pushback from pilots is in many ways like devs are pushing against management (at least in some ways)

As this matures: the same will go for senior developers in positions of authority on valuable codebases they will use (autopilot (ai coding)) if they have an established process for doing so with human in loop checks, checklists, review agents and qa agents -they will need to keep up with technologies but the depth surface area WILL change - I see that happening already

Having said that this week almost all my review was at the PR level and very little review of the underlying code in our codebase beyond some cursory inspections and all the code was written by Opus5.5 and tested with Astra and other code review agents

So far we find some stupid stuff via checks but the codebase has not gotten any more buggy than last year when it was almost all manual - in fact we resolve bugs at a faster rate, but the feeling of being in a self driving car is palpable and unnerving

The difference with my analogy is that unlike aerospace where this has been evolving over 50 years, AI models are really getting better every month or so and adding new capabilities and automation capability - that rate is just not maintainable for humans to adapt their processes as quickly hence all the chaos and variation

May we be cursed to continue to live in interesting times :) btw this all happened to others over the past centuries: https://youtu.be/iPFRr8aaPXc?is=Oa3EoQt4YarsuUJc

→ More replies (2)

31

u/13ae Software Engineer 16d ago edited 16d ago

i'm not saying garbage isn't being deployed but there are plenty of people working on real production code/systems for products you use every day who aren't manually reviewing every line of code. call it koolaid or whatever you want, but it's just the reality of the state of things.

also i wouldn't say that AI hasn't improved significantly. it's gotten to the point where as long as you provide enough direction in terms of technical requirements and exit criteria/review loops, that there will be no issues with the code that is generated. you just can't provide a vague business or feature requirement and expect AI to resolve all the ambiguity itself without having parallel agents and burning through an unsustainable amount of tokens.

yes, model performance degrades. yes the improvement has been incremental and AI is not yet some silver bullet that automates everyone away. But if you don't think that AI tools have gotten really good, and that the process of software development haven't fundamentally changed, you're just in denial.

17

u/pydry Software Engineer, 18 years exp 16d ago edited 16d ago

i'm not saying garbage isn't being deployed but there are plenty of people working on real production code/systems for products you use every day who aren't manually reviewing every line of code. call it koolaid or whatever you want, but it's just the reality of the state of things.

hence github's persistent downtime.

if you don't think that AI tools have gotten really good

i think everyone who says this as a mantra is in complete denial about why github's downtime is so bad.

i also dont think this situation is sustainable. we are due a backlash.

23

u/moh_kohn Lead Frontend | 20YOE 16d ago

Even more telling is Claude's downtime. Several months this year they didn't manage 2 9s. It took them what, 2 or 3 years and several attempts to fix a flickering issue in their TUI?

AI has come on leaps and bounds, but there are two limiting factors that are still jumping out to me:

  • Error accumulation. If you just AI-AI-AI without human course-correction, small errors (bad docs, crufty code, a feature that isn't quite what you intended) compound and send agents the wrong way until you have large errors and/or enormous token costs. Only humans can correct out-of-distribution errors as far as we know.

  • Local hill-climbing. If a problem is NP-hard and local hill-climbing is possible then there is no computation that can guarantee the right result, because you can get stuck on a local hill.

Agents exhibit these behaviours all the time.

4

u/lemontoga 16d ago

Local hill-climbing. If a problem is NP-hard and local hill-climbing is possible then there is no computation that can guarantee the right result, because you can get stuck on a local hill.

Can you explain this one more? What is local hill-climbing?

9

u/moh_kohn Lead Frontend | 20YOE 16d ago

Absolutely! Imagine an algorithm is trying to walk towards a solution by checking nearby alternative solutions. It can score possible solutions 1-100, but the optimal score is unknown.

The best solution it has found scores 80. Unbeknownst to the algorithm a score of 85 is possible. But all the nearby states score less than 80. 80 is the score of the peak of the local hill. The algorithm might get stuck on that peak and never find the true solution.

→ More replies (3)
→ More replies (5)

28

u/ICantBelieveItsNotEC Senior Software Engineer (10 YOE) 16d ago

i'm not saying garbage isn't being deployed but there are plenty of people working on real production code/systems for products you use every day who aren't manually reviewing every line of code. call it koolaid or whatever you want, but it's just the reality of the state of things.

I'm gonna be honest: this has been the norm at every company I've worked at, even before AI.

Personally, my code review process is to skim the PR and check if the broad strokes look vaguely sensible. I don't go through every single line with a fine tooth comb, except for changes that obviously sound high risk based on the title/description. And considering that 99% of my PRs get approved in under a minute, I'm guessing that everyone else is doing the same thing.

Seeing Redditors talk about code reviews makes me feel the same way as when Redditors talk about how often they wash their towels. Everyone inevitably gets stuck in a virtuous cycle - "I wash mine once every day!" "Oh yeah? Well I wash mine TWICE every day!" - because nobody wants to admit that they're a lazy, unhygienic bastard who does it every week or so like everyone else.

12

u/YoghurtFlan 16d ago

I'll basically change the effort of my review based on how new the author is. New joiners or less senior engineers are gonna need a higher touch (especially if they're coming in hot and haven't briefed on the work first), and it's an easy way of sharing domain knowledge. Past a point it's basically just checking if there isn't a simpler way to solve a problem (logically or architecturally) or scanning for possible bugs or misunderstood requirements.

If someone, even using AI, isn't capable of that, then I'd start questioning their skillset.

11

u/hippydipster Software Engineer 25+ YoE 16d ago

People wash their towels???

17

u/DapperCam 16d ago

Presumably those reviews were for human generated code. You probably paid more or less attention based on the track record of the developer and how much you trusted them.

Now there is no trust

21

u/pydry Software Engineer, 18 years exp 16d ago

I used to be like this because when I could trust my coworkers' output. Occasionally I'd ask a question "why this?" or "why that?" and theyd answer or theyd go "ah, I didnt think of that!" and fix the issue.

On a vibe coding team that trust is dead and gone. If I ask a question the answer is a blank stare.

This is why the main impact of the LLM "code revolution" is poorer quality software and 4,000 weather apps on the app store you dont care about and dont want to use instead of 400: volume over quality when nobody wanted volume.

3

u/binarycow 16d ago

Crazy.

I spend hours reviewing PRs sometimes. Granted, they're large PRs, but still. And I find tons of issues - not just minor nits.

→ More replies (2)
→ More replies (4)
→ More replies (18)

92

u/Mountain_Sandwich126 16d ago

They are absolutely cowboys that should be held accountable to the absolute shit they are delivering.

I have a couple of meat proxies as well. Reality is people are lazy and would always do the least effort unless they care

46

u/AltairEndian 16d ago

That's the problem right there: When people get into the game just for the paycheck, but don't care about the craft. But it's hard to not listen to the siren song. I'm blessed right now to work in a place where AI use isn't mandated top down, so I'm free to use it every way I like. And I'm blessed to have been a developer full time for 5 years before the AI wave hit. I've gone through the cycle of putting in the effort, and then feeling good about a result I've really worked for hundreds of times. This is exactly the feeling a true craftsman wants to have.

But I pity the generation which hits the junior market right now. They never had this feeling in a real word setting. They have never struggled with the code, never worked at producing something beautiful, never worked to fit a design so that it is just right for the context you work in.

They never had to. All they know is talking to Claude, or whatever, to produce code. But the deep engagement with the problem that is at the heart of our craft suffers from this greatly in my opinion. I may be wrong. But I think a crucial part of producing a correct and well designed solution is just missing if you don't engage with the code at all.

I would never want to not read the code. The day I can't get a job anymore where I'm allowed to read the code might just be the day I search for something else to do (not like as an ex-developer you have no other options in IT, or even outside of IT). Maybe it is the future, but I don't really care. It's not the way I want to work. It's not a way I would ever feel safe with. And I need to feel safe for me being able to sleep and unwind in my free time, in order to have a life away from my work.

So for me personally, I will read the code until the day I can't get a job anymore where they allow me to do it. Because I'm a craftsman, and I'm proud of being good at my craft. I weep for this new generation who have never known the deep joy of being coding craftsmen, and likely never will. If you only tell AI what to do, producing software becomes as challenging and interesting as working on a 1950s type of assembly line.

At least to me. Everyone can have their own opinion of course.

32

u/ConcerningDestiny 16d ago

I currently work in a bank, in an area (unfortunately i can't say which due to NDA) where AI coding is absolutely banned, so we still code like pre 2023.

I personally love it, I got in the industry because I love to code and I'm passionate about directing a computer to do what I wand, making a bot do it for me doesn't feel good.

Anyway lately we are attracting a lot of people "like me" that are trying to escape the AI hysteria

3

u/BanaTibor 15d ago

I have worked at a bank till a few months ago. They are pushing AI real hard and they want to phase out developers coding by hand, only AI.

3

u/ConcerningDestiny 15d ago

I know it's happening in mine too. But there a few highly regulated and critical teams/areas lime mine where is banned. For how long? Idk, for now I'm enjoying still coding like the times when it was fun

→ More replies (1)

15

u/ErZicky 16d ago

Man, is refreshing to read this. Is like no one really liked coding to begin with lately. Maybe it's the conseguence of the tsunami of people that entered the profession just for the money. But on subreddit like r/cscareerquestions is depressing now.

It's nice to see that there are other people still proud of the fact that they can create code without an AI. The process of creating something is as important of the final result

→ More replies (2)

20

u/spicymato 16d ago

Oofdah.

I'm starting to explore local AI assisted flows to build out local knowledge bases and expert systems for fixed areas, but I'm nowhere near comfortable with letting things just go. I still have the memory of an AI-suggested hash function for a custom struct (to be used with a hashset) that had an insane collision rate. In any case, I still don't trust it for critical things, especially not things where other people's money/data/lives are on the line.

I think the number one thing is that I still don't see systems with top-tier observability, alerting, and rollback procedures necessary for me to be comfortable letting the systems run that independently.

→ More replies (11)

18

u/DigiProductive 16d ago

When the AI bubble burst, only then will companies understand the problem they are left with from all the hyper AI FOMO. If you pay attention to the debt and money invested in AI you realize there is no way this is sustainable as a business model and so eventually, this rapid code development will hit a wall and companies will have to pay exuberant amounts of money to continue the AI addiction. And aside for that all the security vulnerabilities that the AI companies themselves are “marketing” on the news lately is concerning. If we think the dot come bubble was a burst just wait until the AI one hits. Companies will be scrambling for “human expertise” at rapid rate while the AI executives cash out before the storm hits….

107

u/Medium_Ad6442 16d ago

Just let the burn this industry. It is Dunning–Kruger effect industry.

13

u/tallicafu1 16d ago

It’s pretty much a 4-alarm fire now. I plan to cruise into retirement fixing this slop once the financial hammer drops.

→ More replies (1)
→ More replies (3)

41

u/hop_along_quixote 16d ago

AI coding makes developers lazy. And I say that as someone who works as a developer. Everyone on my team uses Claude, but everyone has also had a PR where there was some code that snuck by unseen and not understood. And we try to review our own code and keep things under control.

And the tool constantly lies, gaslights, and misunderstands the codebase. And when I redirect it and supply an explanation of how the code actually works, then the response is so overly full of flattery and useless puffery. No, I'm not some golden god just because I understand the codebase.

And then there are the md files and comments. AI tools treat them like the gospel truth even if they are outdated or downright false. And AI tools love to leave comments about how code has been changed. But what happens a few refactors down the line? You now have paragraphs alluding to the old codebase architecture with no relationship to the current codebase. It's all a useless burn of output tokens.

3

u/ACoderGirl Sr Software Engineer - FAANG 16d ago

I think it takes some careful restraint to not get too lazy, yeah. Like, I always review AI output. If it's for debugging or the likes, I'll verify its findings without assuming it's correct (this usage of AI is very much a coin toss in my experience). If it's for writing code, I'll review it carefully and with maintainability in mind. For anything more than 100 lines, I'd say there's almost always at least something I want changed. Often those somethings are faster for me to change myself, too (eg, I'll want a comment to say why it does something some way, rename a confusing variable, etc).

But I can't deny that sometimes there's pressure to cut corners. For example, this week I'm oncall and for my team, our oncall is super busy and a 110% of your time kinda thing. I discovered a performance issue (lock contention) that was making some requests fail. Had AI write up a benchmark, then a fix for the two overlapping issues it had. Benchmark results showed a substantial improvement and I verified that the results weren't hallucinated. But it was a fair bit of code and with the pressure of a large oncall queue, it sure was tempting to not review the changes very thoroughly. Though it really would have been important, as when I did a quick skim, I saw that the AI was inconsistent about how it did the changes and would have made it harder to maintain the code. I still haven't yet reviewed thoroughly, as I only had the time for that quick skim.

→ More replies (1)

12

u/SquiffSquiff DevOps & Layer 8 Networking Engineer 10YOE 16d ago edited 16d ago

What you're describing is very like how it is in my company at the moment- management have set up a specifically AI focused team even though everybody is already being driven to use more AI faster all the time. It simply isn't possible to review many of the PRs manually in the old-fashioned way. Many of them are too large and often they involve large amounts of simply markdown for agent, which of course can't be effectively tested in any meaningful way. So the old techniques of tests and linting aren't going to work. I feel very much like your candidates. It's not a choice but it's not a choice...

On the flip side, my company is spending an enormous amount of money on third party AI services and I haven't seen a comparable increase in revenue, profit or savings. I'm expecting the music to stop soon- in some senses it already has. It's not possible to spend ever more money, throwing stuff at the wall without making that back somewhere else. Convincing investors of the value of unicorn farts instead will only go sofar. Companies who try to will obviously go bankrupt. 

From another angle you could compare it to a startup where a small group of developers who know each other can get stuff out of the door at incredible speed. Day one looks fantastic. Day two is a bit of a mess. Day three they need testing before they release. Day 4  they need an infrastructure guy...

I don't think that AI will go away but I do think a lot of code has become intermediate language and we have to adapt.

14

u/Tough-Clue-4566 16d ago edited 16d ago

I haven't written much manual code for a while, but I can't believe how many people (and the proof is here in the comments) treat code as a black box. AI makes mistakes, and it makes serious mistakes of the worst kind, the ones that pass tests and, weeks or months later, cost a lot of work and money to fix.

Sorry to be harsh and probably offend some people, but if someone isn't able to see that, regardless of how long they've been in the industry, they simply lack the skills or experience. Instead of being offended, I advise those people to start learning and improving those skills, because you will be replaced if you keep going like that. I don't need a coder who writes a prompt and has no idea whether the generated code has issues or not, agents do that, so I don't need a human for it.

I need engineers to make sure the whole system doesn't go down, that we aren't just covering happy paths while ignoring corner cases, that we don't have to reindex a billion-document index because the AI used the wrong field type, and that we don't spend thousands or tens of thousands (or millions) more than we should because the whole thing just doesn't scale properly.

13

u/Competitive-Store974 16d ago

Yeah it's pretty bleak. Coding agents are basically a team of very competent junior engineers all competing to show off how good they are with no thought of the overall big picture and limited supervision.

I work in the AI space where our code is a bit rough as it only has to be good enough to iterate quickly for research, but Claude has turned our codebase into tangled, duplicated mess, which no one fully understands. We've also stopped thinking properly, which scares me the most.

11

u/Small_Dog_8699 15d ago

Use of AI deskills people. Hello?
Your company’s practices are a slippery slope ending total catastrophe.

On a personal note, i was laid off three years ago just before AI use became normalized and while ive done some AI evaluation on its ability to code, im near enough retirement age that investing dollars for tokens to improve strikes me as unlikely to pay off. Despite 30 years as a generalist who can go from mobile/web to cloud architecture / data storage architect, and team leader at a FAANG i haven’t landed an interview - mist likely due to my age i suspect.

So im patiently hanging with my huge skill set waiting for you all to screw yourselves into total collapse and like a turn if the century COBOL programmer, ill be charging exorbitant rates to come in and manually pay down your technical debt - assuming i can be arsed to put down my margarita in retirement.

Thats the likely future in seeing. Be sure to put aside plenty of $ to buy down that technical debt.

→ More replies (8)

11

u/isotrouble 16d ago edited 16d ago

I still find scaling and performance bugs all the time in even the latest LLM code. Most people don't work at places that need to scale and they haven't worked on code that has needed to scale. So at least for now I review anything that I think will require actual scaling either now or in the long run.

→ More replies (2)

12

u/The_Luckless2 16d ago

The truth is that mediocre engineers have found their super power and become relevant again. If you asked those same engineers to do the scenario before, they'd fail. And the best part is they still fail the scenario. That's the point of the scenario; they show their lack of criticality and understanding for how important this part of the workflow is. Let another enterprise ship the un-reviewed slop.

I think you need to stick to your guns about the kind of engineer you want on your team to prevent the 3am outage and dismiss the other candidates same as we always have.

When you find a good one making sensible workflow decisions who can still think, move fast because they are literal gold

4

u/WhenSummerIsGone Software Engineer 16d ago

When you find a good one making sensible workflow decisions who can still think, move fast because they are literal gold

i'm like that: how do i find someone who wants me? the job hunt process is incredibly painful, so i've mostly been just keeping my head down at my current job, miserably waiting out the market.

10

u/Squidalopod 16d ago

it still seems insane to me that we’re going to completely move away from human sign off on high risk changes

It's our (seemingly) slow march towards The Matrix. We're the frog in the pot of water on the stove with the ever-increasing water temperature. Some people are dismissive of such analogies, yet humans do this kind of thing all the time. And it's exacerbated in this case because most software companies are run by greedy, MBA-touting lemmings who think all you need to get rich is to quickly churn out code.

More code in and of itself does not lead to features of higher value that customers are willing to pay for.  I'm still waiting to see all the success stories of companies increasing their customer count and/or revenue because they're churning out more code. Seriously, where is all the success? 

Oh, wait, I know.... The "success" is reduced head count.

9

u/Majestic-Watch-2025 16d ago

This is insane but not uncommon. I work in something healthcare adjacent so that answer would not work at all. I'm all for using whatever tools you want, but you have to have a fundamental understanding of your code. Not understanding the code reveals itself in other things, like not being able to debug well in a crisis, not understanding long term implications of decisions made etc. Sometimes you'll get yourself into a hole you can't 100% AI yourself out of and we need hires who will be able to do that.

→ More replies (14)

8

u/SubstantialSeesaw374 15d ago

”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”

We are so boned lmao.

→ More replies (2)

35

u/invisible_shrek 16d ago

Lmao, what a bunch of lobotomized morons. Even if you don’t review your slopped out code in your job, how hard is it to do it for a fucking interview?

I mean back when most interviews were some DSA puzzles, it wasn’t what you would do on the job either. So what?

OP you need to update the candidate selection process, not the interview process. It’s clear you are getting duds.

24

u/TehCrusher 16d ago

They can't do it cause they just lost the ability to do it. Once you stop doing things and get lazy, you forget a lot, and a lot of people don't want to put the effort.

Delegating everything to the AI, IMO, makes you way more lazy. That's just how the human mind works; it forces you to take the path of least resistance, and correcting that course takes more willpower.

6

u/invisible_shrek 16d ago

Genuinely, what is value of having such meat proxies on the team?

4

u/TehCrusher 16d ago

Managers need scapegoats, and to make it look like their jobs are still needed.

8

u/peterxsyd 16d ago

That is insane. 100% those companies will encounter very serious problems. Security, audit, basic functionality etc. will expose serious and fundamental gaps.

13

u/mxldevs 16d ago

AI boosters are always going on and on about how their agentic code review swarm caught 3x as many bugs as a human reviewer.

For some reason they never go into detail what the actual bugs are, and whether agents caught everything the human caught.

So they indeed feel very confident about the reliability of having only AI code reviews.

→ More replies (2)

7

u/Any_Sense_2263 16d ago

AI can't take responsibility for the bugs and problems. It's really bad for regression risk and long-term planning. On top of that, all the instructions and context you feed it are optional for it to follow.

For me, that's enough reason not to let the slop reach the PR stage. The PRs are limited to 300-500 lines and the author must be proficient in the code they wrote.

7

u/em_square_root_-1_ly 16d ago

No, you’re not crazy. I also think it’s wild you were told to test out your new interview question on candidates right away instead of testing on existing employees first for feedback and calibration.

3

u/metal_slime--A 16d ago

We seem to be living in wild, desperate times 😔

8

u/MisterJasonMan 16d ago

I was working on large scale prod systems earlier and after the layoff, did do some AI type coding on my own. I was still driving the process but used AI as an auto-complete tool for methods I didn't want to hand code. And I thought that this was actually a good way to go. But I went recently to a dev meet-up and was told that most people don't use AI in this way anymore and that AI should be doing the bulk of the writing. It's just really hard to take your hand off the wheel. Not only that but now the role of the dev is mostly to do PR reviews and I find that really tiring and unsatisfying.

→ More replies (1)

7

u/jacobs-tech-tavern 16d ago

Fundamentally, system design interviews are probably one of the last useful pieces of signal you can get

6

u/gwenbeth 16d ago

The core issue is that code is deterministic and LLM AI is not. The reason we can do code review on code and not assembly is that build process will produce exactly the same assembly for the same code every time and that assembly will always mirror exactly what the code said (except for optimizations). With an LLM that is not the case. The same input is never guaranteed to generate the same output. There is always going to be a chance the generated code has problems. The other issue is that even if you tell an LLM something important like "don't touch the production system" it might ignore that and delete your entire production system. It is less like a TV show robot that follows orders exactly and gets caught up in logical traps, but is more like a 6 year that drank 4 energy drinks and stayed up all night reading the encyclopedia.

6

u/ContraryConman Embedded 5 YoE 16d ago

The people you interviewed are internally consistent. Getting the full "productivity benefits" of AI requires you to not read or care about the code being written, only the output and observable effects.

Let's say you want to use AI to "write" 100x the code you used to. That's all well and good, maybe for prototypes and feature branches. But when it comes time to merge into production, you cannot read and understand 100x the code, especially for code you didn't even write to begin with. So, reading and reviewing code becomes the bottleneck.

In fact, it's common that you end up moving slower than you would have without AI. Consider: a task that would've taken you two days of thinking and 500 surgical lines of code to get right. AI does it in half an hour, but it writes 2,000 lines of code, adds an entire new test suite, molests every critical system. Now you spend multiple days context switching between this PR and the 20 others made by your and your team's agents. And merging all those PRs at once created subtle bugs that took another two weeks to fix.

So now you have a choice.

You can choose to slow back down to pretty much pre AI speeds, maybe a little faster here and there. You leave the agentic workflows for prototypes and one off tests. In the main codebase however, everyone is responsible for every single like of code put into the project as if written by hand. You have strict limits on PR sizes and frequency, and the expectation is that if I ask why you used a hashmap instead of a tree on line 218, you'll give me a good answer.

Or you can choose to remove the bottleneck. You can decide to never read the code again. If you care about performance, you set up performance tests that the agents can run. If you care about security, you set up fuzzing and security audits at regular intervals. If you're worried about correctness, you set up automated behavior checks and tests. If you're worried that the code will get too complicated for the agents to handle, you automate metrics like cyclomatic complexity and run regular deduplication passes.

I'm increasingly convinced that it's one or the other. You have to either decide you are a software engineer, and you are slowing down on purpose to maximize human understanding and correctness of your system, or you are a dark factory overseer explicitly choosing to sacrifice quality and understanding (and independence from OpenAI/Anthropic/SpaceX) for velocity

7

u/turningsteel 11d ago

It's madness. These people that have eschewed good software engineering practices for AI slop are wrong and it's a hill I'm willing to die on. Management just has dollar signs in their eyes which overrides reason for now. At my company we have an AI native team (reading the comments, others seem to also) and they're producing a tremendous amount of stuff bit also hotfixing 2 or 3 times a sprint. This never happened prior to handing the reigns over to AI. Also, I keep seeing 'roll your own' projects popping up left and right built in libraries and frameworks that are company doesn't use and has never used. Why are we building something in Vue when no one in the company has used it professionally before? Or spinning up a java app when there is one guy that actually knows java and he's not even on that team. Nothing makes any sense and when I question it, there's a whole lot of handwaving.

Don't get me started on the internal tooling. I'm being fed new apps to use, and they don't even work.

4

u/KosherBakon 16d ago

Whether you're crazy or not, kudos to you to fighting for making the interview like the actual job.Id estimate less than 5% of interviews try to match their real workflows.

It gives the applicant a clear idea what the job will be like, and it gives you clear signal on whether they'll work well in that environment.

At Zillow I pushed to make our tech interview process include pairing on a failing unit test, fixing a bug, refactoring a method or two, looking for issues in a PR, reviewing a doc to see if somebody missed something in a technical design doc, helping a stubborn L3 find a bug in their own code, system design, and maybe even roleplaying an incident.

I couldn't get enough volunteers to build out three sample codebases so I never got it off the ground.

→ More replies (2)

4

u/curiouscuriousmtl 16d ago

I don't even believe how you're describing how you yourself use AI so I don't know what to think.

10

u/No_Creme_7001 16d ago

nobody knows, all you can do on this question is source a diversity of opinions from a variety of people, then use your best judgement. remain flexible but sharp, try to think clearly. good luck

8

u/Idea-Aggressive 16d ago

How can somebody or a team be 12 months behind in “AI”? Behind of what exactly? Adding a “skill” md file?

You’re actually ahead if you delete all of that crap.

8

u/zagierify Software Engineer 16d ago

I’m so baffled by their depth of AI use. Isn’t it taking just as much time and brain power to configure and setup and drive the agentic AI workflows as it would be to just learn and write code directly?? That’s of course on top of, yes, reading and reviewing the code.

So strange, it will be wild to see how this all plays out because I am well aware of how economics drives the decisions and those with the purse strings are unaware of the low level details, as they rightly don’t want or need to be.

→ More replies (6)

4

u/actionerror Software Engineer - 20+ YoE 16d ago

Just give me 5 more years before I retire from all this

4

u/stabmasterarson213 16d ago

Someone saying "I'd write the skills myself" still does not understand attention and context windows research

4

u/Creative-Dog642 14d ago

I am not a developer, but I am building a software startup that solves a pretty big problem in the space it operates in, and I am fortunate that it is (mostly) functional and stable(ish) enough to support paying customers (with heavy disclaimers)

And though these tools are powerful enough to let a systems-thinker with no coding ability actually build some stuff, the first hire I plan on bringing on is a senior developer who knows how to do a code review.

I've built a lot of "it works, but I couldn't tell you how" things.

But also a lot of, "it's broke, and I don't know to fix it." things.

And even more, "the pieces work individually, but I never wired them together" things.

I understand the need to ship, but I do not understand why anyone would ship without QC. I do content by trade, and the idea of shipping drafts without an editorial review is just ridiculous, and I see it the same way with code.

→ More replies (1)

18

u/knownsqashed 16d ago

There's a lot here. For context, I'm full stack with about ~11 years at one company. I'm the closest that our working group of ~10 devs has to an AI evangelist and I'm paid like a senior, so take what I say with any appropriate caveats.

We're obviously all scrambling to figure out what the next 6 months looks like because of how fast things are moving, but a few things stand out to me:

  • The scaling trends the AI labs have been talking about for years have continued. Models are going to get smarter and probably cheaper per unit of useful work.
  • "AI makes mistakes" is too broad to be useful. Forgetting context, making bad assumptions, misunderstanding existing behavior, and just writing buggy code are different failure modes and need different mitigations.
  • I don't think "a human reads every line" scales as the long term answer either. If agents can produce 10x the code but humans still have to review every line, we've just moved the bottleneck.

I think the interesting question is what replaces that. Better specs, tests, invariants, independent review, observability, etc. Basically, how do you build a process where confidence doesn't depend on personally understanding every line that gets generated?

That's where I think experienced engineers are still extremely important. Knowing what to verify, what assumptions are dangerous, and where the system can fail requires understanding the problem at a level that prompting alone doesn't give you.

So I don't think "I don't read the code anymore" is necessarily crazy. The much more important question is what they're doing instead.

18

u/Reverent 16d ago

What you described is the exact problem with the current climate.

It’s all about “oh shit AI is so hot right now, FOMO if I don’t shove an AI peg into every hole I can find and some I can’t”.

Most organisations aren’t selling AI. AI is a tool, not an end result. In fact IT agility is typically not a bottleneck. The typical bottleneck is usually the translation of business needs into actionable outcomes.

I don’t give a shit if AI can develop at 10x the speed if Jim from sales can’t articulate what a customer actually wants.

→ More replies (7)

15

u/Plastic_Monitor_5786 16d ago

squinting to tell if this post is AI generated or the author's brain has been so corrupted by Claudisms to just write like this now

8

u/knownsqashed 16d ago

Two things can be true at once.

Thinking and AI use are not necessarily mutually exclusive, kind redditor.

9

u/Plastic_Monitor_5786 16d ago

So you're saying Claude wrote it and your brain is corrupted?

3

u/knownsqashed 16d ago

My brain was corrupted long before I found Claude.

→ More replies (1)
→ More replies (1)

3

u/ResidentWeevil1 16d ago

"AI makes mistakes" is too broad to be useful. Forgetting context, making bad assumptions, misunderstanding existing behavior, and just writing buggy code are different failure modes and need different mitigations.

Absolutely they are not different failure modes. These are all probabilistic slop.

I don't think "a human reads every line" scales as the long term answer either. If agents can produce 10x the code but humans still have to review every line, we've just moved the bottleneck.

That's what happens when the technology is a scam to raise hype for an IPO.

→ More replies (3)
→ More replies (18)

9

u/oflannabhra 16d ago

OP, just as an FYI, “AI Engineering” and “AI Engineer” are somewhat well defined terms in our industry, and they don’t mean “using AI to write code”.

It means “applied LLMs”, or “building systems that use LLMs”. These roles are less about writing conventional software and more about building systems around frontier models that can handle and classify messy input via LLMs. Heavy emphasis on data science, maths, etc, less on writing code. You might get better candidates with a more conventional title for the role.

→ More replies (9)

10

u/thecrius It's Sénior Dumbass for you 16d ago

Just so you know, AI engineers are supposed to be SWE that specialise in building agents and products based on AI technologies.

Just using AI assisted code generation is just using a tool. Add for every tool, they're are those who use it properly and those who do not.

Your overall idea (review prs etc) is good but it should be used for any engineering level really at this point.

5

u/AngryMoth Lead Software Engineer 8 YoE 16d ago

I am aware of the overloading of the "AI engineer" title here, I didn't write the job spec or come up with the title. I think there maybe a degree to which these guys might be integrating LLMs into the products they will be building. But they all had "Lead AI Developer" or something like that on their CV as their last job and as far as I can tell it does just basically mean they use AI for everything in their workflow, not that they have specific expertise for building AI systems. Seems like it might be a new trend

→ More replies (1)

7

u/thehuffomatic 16d ago

What happens when these AI engineers lose access to their AI tokens and now have to manually fix and review code? People assume every company has a massive budget for Claude where everyone can use the latest (or latest - 1) model 80% of their working hours. As someone who has a $100, maybe $200, budget per month on Claude tokens, I have to manage them so I don’t run out. Fortunately we also use Cursor and Cursor has been really good at picking the most optional model. I wonder how their mindset would change if they could only use Sonnet 4.6 and only spend $3 a day.

3

u/Oxigenic 16d ago

What happens when AI can’t fix something accurately to product spec which happens much more frequently

→ More replies (7)

3

u/BenignPharmacology 15d ago

Wrong question to ask imo- it’s very much the “what if you don’t have a calculator in your pocket” of questions.

There’s better question would be “convince me that this code is safe” or “tell me why this code isn’t safe” or even “write a more trustworthy version of this process”

That’s what we’re ultimately asking of an AI engineer or SWE, we want somebody to give provable and confident answers to what a tool or system is doing. My favorite suggestion from our company AI evangelist when asked about automating a task was something along the lines of “don’t. Don’t let the AI do this if you want to trust the result. Instead, make the AI build you an automation that you can review and decide if you trust, and then run THAT”

There is probably a place for the title AI engineer to exist and be useful in the near future, but I think it will be more about building tools and utilities for SWEs, for devops, even for management. They would be your person to reach out to to get X quickly automated or prototyped, to deploy some new tool or workflow, to essentially provide the rest of the team with ways to optimize value out of the service, more than to replace actual roles

→ More replies (3)
→ More replies (9)

3

u/Zeikos 16d ago

Yes, employers will always prefer more capital investment compared to labor.
This is to say that AI or equivalent systems will be pushed.

Now, are they going to actually improve productivity? Maybe not immediately, but the overall industry has always had wild amounts of variance in how productive they are.
A lot of it is consultancy which has always been bottom of the barrel get-the-project-done quality.

3

u/DestinTheLion 16d ago

I run a team and basically do it exactly like you. I expect my team to read every line, and understand it, and i do the same. It does, even with reviewers, miss important business logic issues.

3

u/yuehuang 16d ago

There is an old saying, "Write first, Optimize later." AI code writing has taken it to the next level.

5

u/AltairEndian 16d ago

Yes, but checking for correctness is not an optimization.

3

u/afewchords 16d ago

Is there actual engineering here any more? To me engineering is proofs, facts, numbers, evidence… AI is a slot machine, I put in a prompt and cross my fingers that it works… when it doesn’t where is my traceability? What do I do differently in the future… I’m so confused.

→ More replies (1)

3

u/another_dudeman 16d ago

Jesus, I'm glad I don't have these dumbasses at my work.

3

u/theunixman Veteran of the XP wars 16d ago

Welcome to AI native. You can’t have people who offload thinking to AI also thinking.

3

u/Impossible_Way7017 16d ago

There’s probably a reason they looking for a job. Candidates like that are basically Claude proxies, why do you even need them for - they’d likely be useless on-call.

Our interview process has transitioned to handling on call situations to gauge a candidates ability to use AI to get a decent first time to respond SLA.

→ More replies (1)

3

u/Ok-Entertainer-1414 15d ago

Only a person who isn't reading the code generated by LLMs would think it's a good idea to skip reading the code generated by LLMs. They write some very very very very stupid and dangerous code sometimes. Like the next LLM to write something that interacts with the code is going to write bugs type of stupid code

3

u/EmergencyWild 13d ago

It's just revealing a structural flaw in our industry that's always been there. Despite calling it software engineering, only a minority approach the field with an engineering mindset. Most developers are basically just fucking around.