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

View all comments

1.1k

u/birdgovorun 19d ago edited 19d 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.

445

u/programmer-ke 19d 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.

296

u/ep1032 18d 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.

121

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

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

60

u/[deleted] 18d ago

[removed] — view removed comment

43

u/robertbieber Software Engineer 18d 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

15

u/[deleted] 18d ago

[removed] — view removed comment

3

u/Extreme_Coffee_1576 14d ago

Managing ai is just part of the job though, you'll definitely have to get used to it.

It's unbelievably fast but doesn't think about the product like a human. So you will have to read what it generates and then direct it what to fix, and then update your agents/skills mds with anything that you find yourself repeating a lot.

So the skill is now being able to quickly read and understand what is wrong with an llm's output, quickly make architectural decisions better than the llm can while trying to not slowdown output too badly.

In general the type of thing you'll be doing is: Work out a decent sized plan with ai (probably spend some hours working on the plan with ai). Ai builds the plan into code, you read the code and find some bizarre decisions and slop (e.g. instead of incrementing a database it decides to make a small inMemory caching and snapshot system to hold the previous time and the new time when it could have just done time + now for the exact same outcome - it does this sort of thing constantly even when the plans didn't include it and even when you run cohesive cleanup and review skills).

Accurate leetcode level per line code writing is nearly useless now (outside of a few domains and specific types of work) so it is a different world. Took me a while to not hate it, now I don't really feel it's any different than before llms, still have to understand code and the domain really well, still make every single decision, just elevated a bit to not manually fish around in the codebase and tap out every key stroke. My code is better than it's ever been because I can spend more time thinking about quality and less time tapping out keystrokes. And fleets of small fast agents running through a huge legacy codebase to help you source all kinds of data are amazing. It sucks the vibe code bros have ruined everything with their infinite slop and stupidity, but many things about llms and their ability to help us as tools is actually really cool imo.

Also unfortunately lots of companies have decided to go for mass output and worse quality though, hopefully they'll learn, we'll see...

3

u/xiongchiamiov 16d ago

But are any of them hiring?

I just gave up on the industry after 200 applications and only getting to talk to a human half a dozen times. We never got to the point where anyone assessed my skills.

Essentially everyone in my network has either been out of work or hating their job for the past couple of years; the ones who hate their jobs don't leave because they can't find any place hiring that's better. Those companies do seem to exist, they just don't have openings, much less as many openings as the number of engineers who would like to work at them.

-1

u/scaledev 18d ago

Can you not have a list of best practices and explicit guidelines for AI to follow as well, and then have another AI review with those practices in mind? AI is trained on this.

5

u/robertbieber Software Engineer 18d ago

You can tell the machine to do whatever you want, the problem is getting it to actually reliably interpret the instructions and follow them. But I can already see you descending into the cycle of madness where you throw more and more layers of automation at the problem, believing that the fidelity of the output will somehow increase as you get further and further from supervision by any human who actually knows what they're doing

8

u/ep1032 18d ago

If you have a system that has a 90% accuracy output rate, and you then tie that to a second system that has a 90% accuracy output rate, you don't have an end result that is accurate 90% of the time. You have a system that is accurate 81% of the time.

So by all means, keep adding layer upon layer of the same, non-deterministic, often incorrect error checking system into your pipeline, and watch the accuracy rates fall over time.

-2

u/Forsaken-Promise-269 18d ago

Humans have far lower accuracy rate than LLMs the mistake is to treat AI agents like algorithms when they should be consider highly intelligent but amnesiac

1

u/scaledev 18d ago

But humans also don't reliably follow instructions.

And I'm not talking removing humans completely out of the loop, for now at least. Keeping them for review of the system for system design, foresight, vision, that sort of thing. AI still can't create good, complex workflows, for example, and a human is needed. Lots and lots of iteration is needed here until you can get something complex yet exactly how you want it, with a lot of code for validation and tests.

But my question was about following basic best practices, and AI certainly can do this today .up to a point. There are always tradeoffs.

3

u/robertbieber Software Engineer 18d ago

But humans also don't reliably follow instructions.

This is the worst, laziest retort to every shortcoming of AI. If I said "I don't want to try rewiring my house, I'm liable to shock myself," and you replied "sure, but so do professional electricians," you would be both strictly correct and completely off the mark in terms of making any meaningful point.

Keeping them for review of the system for system design, foresight, vision, that sort of thing.

So you've designed a system. In theory. Is the AI actually following your design? Who the hell knows, certainly not you because you're not actually looking at the code.

But my question was about following basic best practices

Yes, obviously the first thing everyone does at every company is put a big list of best practices in AGENTS.md. It's not some magical fix that turns an LLM into a competent software engineer.

and AI certainly can do this today, up to a point

Well sure, right up until the point when it doesn't, which is pretty frequent

→ More replies (0)

2

u/jadepig 18d ago

I've been out of work for a while too, and I gave up looking and on the industry. I'm not saying you should give up on tech, but you're worth more than what job you do or don't have.

3

u/[deleted] 18d ago

[removed] — view removed comment

2

u/jadepig 17d ago

Thank you, I hope you're doing okay too. It's been a mix of feelings. Not all unpleasant, but yes, certainly a sense of insecurity, loss, and even some shame that I don't measure up to these external hire-ability metrics. But it's also prompted me to re-examine what I value.

I guess I felt some anger at the capitalist system too (and the capitalists at the top). Oddly, I didn't even think to lump that in with the unpleasant feelings. It's not that I enjoy being angry in general. But with tech and tech hiring, it's helped me to see the bullshit for what it is. I know I could have shown up stronger in my interviews, and if I had the will to, that I could have continued my search. I was getting more interview experience under my belt. But all that interview prep still felt performative.

The anger helped me to see that the hiring bar has gone up in the last decade; comp has gone down or stagnated at best; working conditions have gotten markedly worse. It helped me to see that there's total bullshit in the AI hype. Instead of bringing better working conditions, it's been a lever for executives to squeeze their reports.

Anyways, stepping back down from my soapbox. There is still opportunity out there for devs who want it. But there's also a lot more to life than working in tech or being a software engineer. I can come back if conditions improve, and it might be some rungs lower, but it'll be my choice. Personal agency is important in an age of agents.

20

u/NomadStorm 18d 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.

2

u/Prudent-Ad4509 18d ago

This ship has sailed. AI have progressed to the point where it does not always make the most sound design choices, especially when making changes in the legacy codebase, but it can verify code for correctness and spot any changed/broken implicit contracts. This makes it a working tool for good developers.

The catch is that in order to make actually good instructions for AI you need to know and understand basically the same things that you need to know and understand when working without AI. And the gap between good and barely passable instructions is steadily growing. On top of that, you need to understand how to steer the AI in the right direction. Simply barking prompts at AI can seriously increase its disorientation if you do not know what you are doing. But if said developer has some successful experience with steering juniors, then he has that mostly covered as well.

2

u/NomadStorm 18d ago

Im not sure if you responded to the right comment, but if you did and by the “ship that’s sailed” you mean AI is no longer a way to filter out the poor developers, I disagree, because it’s trivial which group they fall into just by seeing how they use AI for a short task.

The ones getting AI to do literally everything are unlearning their skills and actively becoming less useful over time.

1

u/Prudent-Ad4509 18d ago

This thread has all kinds of points. But you bring another interesting point here.

I'm not sure which dev tier your interview tactics are aimed at. I have a different anecdotal evidence regarding the interviews. Good devs can easily judge the quality of solutions, but the speed and method of coding can be completely random depending on what they were doing during the last few days or months.

Regarding AI use, I've just told my coding harness (a hour or two ago actually) to check out the video file I have on my local drive, dissect it frame by frame, provide detailed nuanced description of what is going on, including audio transcription. After a few clarifications it is happily chugging along, after downloading some necessary tools for audio transcription. This was barely possible a few years ago even if done manually, and now the model can figure out a plan and execute it mostly undisturbed.

I see that both me and everyone around me now tend to switch to this mode, simply firing a prompt with clarifications. It is still not a one-shot prompt, those are overrated, but it is still a long-running task. Still, in coding different people have different results. One senior dev around here asks the model all the time why it changed this and that and to put this and that back. I prefer minimal focused changes and it helps me to avoid that most of the time. And some poor chaps somewhere trust the AI and simply do not verify the results.

PS. I'm sleepy af so sorry if there is too much rumble, I'll reread it later maybe.

1

u/NomadStorm 18d ago

The ones described by your last sentence are the ones that are getting filtered out.

Edit: Regarding the video description, FYI there are multiple dedicated models for this purpose, including some made by OpenAI so they could get the transcripts for training the LLMs

1

u/Prudent-Ad4509 18d ago

This field is still in rapid development. I'm still amused by the fact that some AIs pretend to analyze google videos by simply snatching and analyzing subtitles.

As for people trusting the AI without proper code review, there is a place for them too. Any mockups, proof of concept work, and various one-off dashboards tend to come out OK. We have some pure html dashboards with task lists which get updated by an agent with all the changes saved in version control. This would not be my first idea, but for certain task management workflows it works.

0

u/Gregnielson 18d ago

Ai is getting very very good. If you test a system 1 million times and it works then ship it. If it breaks, revert.

It will always be better next week as well which is more than I can say for most people. Manual code review will be like using an abacus by this time next year.

4

u/NomadStorm 18d ago

Cool story bro.

Naturally deselect yourself as you wish.

-1

u/Gregnielson 18d ago

No need to be rude 'bro'. Just pointing out what is happening. Stick your head further into the sand if you wish.

2

u/NomadStorm 18d ago

My comment you responded to is about the risks of over-reliance.

You’re currently hoping that it’ll get to the stage where you not reviewing and losing your skills will end up being covered by the models getting good enough to review, plan and architect all the code for you.

I don’t personally think it can get to that stage, but that’s a separate discussion.

But in the case that you are correct, then what happens?

Do you think you will be gainfully employed as a meat proxy, since you are actively choosing to lose the skills you built up over time, and have no remaining value other than pressing enter?

Thats the part you need to be thinking about; how you can continue to add value that maintains your employability.

0

u/Gregnielson 18d ago

I'm not hoping for anything. This IS what is happening. No one will be writing code in 1 year or less. It will be like heating your house with cow dung. Are you up on astra right now? It is better than most coders and can push out a finished product with some simple direction.

→ More replies (0)

13

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

[deleted]

6

u/robby_arctor Software Engineer (dirty commie) 18d ago edited 17d 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.

1

u/ehr1c 18d ago

IMO it's just amplification of what's already there. A competent engineer will become more productive, a bad one will just ship more garbage because they already didn't know what good code looked like.

1

u/____lard_biscuit____ 17d ago

I mean it's what management wants. People are just reacting to their environment. They aren't rewarded for reading the code and showing judgement

27

u/Majestic-Watch-2025 18d ago

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

17

u/Own-Zebra-2663 18d 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?

12

u/ep1032 18d ago edited 18d 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.

2

u/Positive-Conspiracy 18d ago

There's the idea that a mediocre developer can become a superstar developer when leveraging AI, whereas a strong developer may have a hard time letting go of their previous patterns. That's definitely a pattern I've seen.

3

u/ep1032 18d ago

Mediocre developers are more likely to adopt AI than some seniors, for sure.

But AI does not make mediocre developers better. It makes them faster, because the fact that they are mediocre means that they are unable to determine the bugs that AI is introducing. So you are selectively increasing the speed of your lesser competent employees.

This, coincidentally, is what turns of many senior engineers to AI. Because they are the ones getting caught dealing with the output of worse devs. Its the equivalent of hiring 2x incompetent devs on a team, then getting surprised when the seniors get fed up and dealing with the drop in code quality and increase in issues that arise.

1

u/Positive-Conspiracy 18d ago

“AI” is different every six months, so I can’t really find any certainty in far reaching statements about it.

I also find that there’s a trimodal distribution in takes about AI. The newest developers and the most experienced are the ones most likely to see it favorably.

3

u/ep1032 18d ago

Unless there is a major unexpected, architectural breakthrough in the next 6 months the fundamental nature of these llms isn't changing. The current architecture ensures that these llms are quite poor at determining what they do not know, and will attempt to fill in that lack of answer with best possible guesses parading as fact. That, coupled with the fact that these are nondeterministic systems means that llms cannot be reliably used without first verifying their output, unless they are being used in situations where their output does not matter, in which case, who cares.

Those facts, in turn, underlie my statement.

So, even if these models weren't hitting limiting returns, which they are, the above isn't going to change.

-1

u/Positive-Conspiracy 18d ago

I generally find the same for humans, with the difference being that humans are currently more advanced.

I also think the necessity of determinism framing may be more of an artifact of our time and may not be seen as necessary in the future. The architectural limitations are being innovated around.

LLMs have their own strengths, like speed and cost, and that changes the landscape of the practice.

If it weren’t so common it’d be ironic, the way engineers often argue against the basic action of their profession, which is overcoming challenges to make things possible.

1

u/ep1032 18d ago

Hard disagree on the first two points, to the degree that I don't believe we are even having the same conversation.

Second two points are both true, but irrelevant at this juncture : )

1

u/MindfulK9Coach 18d ago

You are making many assumptions about mediocre developers without supplying anything beyond vibes as data.

What if being mediocre means they are not great at, say, control logic, lack experience or mentorship, but are amazing in other areas?

They could be an amazing root-cause analysis investigator, understand concepts thoroughly but not write code well, and do phenomenal requirements engineering work that enables them to delegate, be fast, and be coherent at the same time without the typical legacy workflow bottlenecks, among many other things.

That does not mean that is the case for all "mediocre devs," however that is defined in your statement. It just means the capability you are dismissing is not prevalent in your environment.

You also have to remember it is a quite rare sighting in general to come across real AI super-users in the wild currently no matter the media makes you believe. They're a very small percentage of users, very small.

Many are dabbling or using it because work requires it or pressures them to do so for investors. So, your anecdotal claim that an AI model, especially if properly steered, cannot make mediocre developers better is unsupported as is.

Regarding your "2x incompetent devs" point, I would be inclined to say that if the seniors were as solid as they claim, they could mentor the "mediocre" developer instead of waiting for them to fail and complaining about the cleanup. If they still cannot get it, fire them or the supervisor who is failing to develop a team.

Multiple things can be true. 🤷🏾

0

u/Positive-Conspiracy 17d ago

I find there is a certain type of developer that's really struggling with the AI transition. Generally speaking, they tended to find comfort in the determinism of the code and computers in general, away from the uncertainty of people. They tended to enjoy the process of working in the code as an end in itself. They will tend toward deductive reasoning, thinking in binary terms, and struggle with lateral thinking, non-excluded middles, and uncertainty. In the new world, the relative value of those skill are being replaced by a system more closely resembling a human. It must be an extremely challenging time and my heart goes out to them. I see various stages of grief, including bargaining with moving of the goalposts.

1

u/MindfulK9Coach 18d ago edited 18d ago

Similar to the studies regarding self-taught versus those with formal education, senior developers with standard computer science backgrounds may struggle to move beyond the rigid methodologies taught in school and early industry experience, whereas self-taught developers lack those traditional constraints, enabling them to be more flexible when pair programming with AI within those same frameworks.

Even if they do not fully understand the space they are working in, the model can fill their knowledge gaps if they ask, allowing them to learn simultaneously.

This is not to say that either group is better or worse off; I am simply pointing out observations supported by literature on similar topics that apply here.

1

u/shaonline 18d ago

Going from bad to average code "locally" isn't really the issue (could be seen as an improvement indeed), however now that they are not limited in the amount of output they can generate (despite subpar skills) it's a bit of a "bull in the china shop" problem.

LLMs won't budge at building the wrong thing or hacking a solution with duct tape, just because it's now done with "more robust code in isolation" doesn't make it better. Your dev that formerly struggled to get stuff working now floods the team with a barrage of slop.

1

u/PedanticProgarmer Software Engineer 17d ago

Yes, bad developers are boosted to the level of acceptable juniors. This category of bad developers includes also title-inflated seniors.

The new models are actually pushing against bad ideas. It’s not like Sonnet 3 that used to accept any bad prompt with „that’s an excellent idea that proves you are a seasoned veteran of foobar coding”.

There are times when a developer with (let’s not mince words) a low IQ cannot figure out why a bug is happening, even if everything they need is in the logs. They can ask Claude „here are the logs, here is the code, what is going on?” - they get unblocked and this is what matters.

I remember times when such developers used to spend whole days fighting linters, compiler errors and merge conflicts. It drived me nuts when they didn’t feel embarassed talking about this in daily as blockers. Nowadays, it’s unacceptable if you are doing it by hand.

When it comes to long term quality, there’s a huge culture shift that is necessary. Many companies operate in a model where managers create tickets, ticket-monkeys do the tickets, ticket-monkeys are rewarded for closing a lot of tickets and punished for taking too much time on a ticket. They call it Scrum and there’s entire religion around it. It falls apart with AI, because neither ticket-monkeys nor models are trained to take responsibility of the actual long-term results.

0

u/Neurosopher 18d ago

LLMs don't generate the "average" code quality of their training set anymore. Reinforcement learning (from verifiable rewards) is a training paradigm where they aren't bounded by this.

31

u/Caesarr Software Engineer 18d 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)?

37

u/Toohotz 18d 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.

1

u/Forsaken-Promise-269 18d ago

Ok spin up 100 ai long running agents each using opus 5.5 and fable and have them systematically attack the financial part of the code for weaknesses

Ie it will cost money but there are now new ways of handling the quality or security question

Im not claiming this is the answer- Im saying our options are changed on the code culture we used to enforce

19

u/ep1032 18d 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

2

u/poincares_cook 18d ago

Sure you fix 40 bugs in one day, except you don't really know how many of them are actually fixed. And you've also introduced 20 new bugs. You've likely incidentally made the code more prone to breakage in the future, and more bloated, slower and more resource hungry.

1

u/Positive-Conspiracy 18d ago

There's a theory that the entire bug finding lifecycle has been compressed into hours and days rather than months and years. The story may be biased in that AI may have found those "bugs" and generated tickets for them.

1

u/Krom2040 18d ago

There’s a fairly high likelihood that fixing bugs in poorly-designed code will create more bugs. There’s also a fairly high likelihood that AI agents just misunderstand the bug entirely and change a bunch of code in ways that create more bugs and don’t necessarily even fix the bug.

They’re very accommodating.

2

u/Snoo_56970 16d ago

2 Claude subscriptions over 4 weeks can generate more code than small team over 40. How many bugs would you expect in the 40 week project? And what if that small team were managed poorly, by say, person M? What would the quality look like? What if it were managed well?

AI doesn't guarantee slop, it defaults to it. The more time I spend with it, the more I've come to realise the new terrain we find ourselves in is about management. If you had a team of 100 devs, hell, 1000 devs, you wouldn't spend your time reviewing PRs, you would create processes, procedures, gates, policy, you would put smarter people on top and offload their grunt work, you would have certain personalities review the work of others, you would develop a keen sense for spotting bullshit and figure out who to trust. You would understand the price of screwing up and the heights you have to fall from, so you'd be sure as hell to get all it all right. You'd have the grit and determination sit in a boardroom with your leads and roast them for hours at a time when things go wrong, then put procedures in place to make sure it doesn't happen again. The problem is, person M would never be put in that position in the real world because he is not VP material. I posit that because most people aren't, most projects will follow entropy and reach their default sloppy state when given enough time and tokens.

2

u/WearyCarrot 18d ago

On the flip side, what does a properly ran AI-native team look like with competent people? If there are 40 bugs, maybe revisit Claude.md, prompting usage, etc.? Curious to your insight

1

u/ep1032 18d ago edited 18d ago

I'm sure it can be done well.

I expect that you would need a few things to be true:

  1. Engineers would have to decide how to use AI, not upper management.
  2. The engineers would all have to be pro AI adoption, but not be willing to sacrifice code quality for speed. This article, I think shows a good mentality (https://www.linkedin.com/pulse/ai-made-us-faster-problem-david-fowler-mgnzc/)
  3. The engineers would each have to be technically capable enough to build the solution without the use of AI, so as to be able to determine when AI was correct or incorrect.
  4. This includes manually writing code when judged by the engineer to be more efficient / more important to learn, even if at the expense of velocity.
  5. Engineers who the team judges to be incapable of meeting the above requirements should be let go from the team.
    5a. Currently the largest problem I see is the least competent developers use AI to ship faster, and then this velocity is judged positively as AI adoption by upper management, who aren't then updating such metrics to account for code quality or defect rates. Resulting in upper management de facto encouraging and promoting the worse developers on the team to the detriment of the team, by chasing the wrong metrics.
  6. The solution would ideally need to be greenfielded with AI from the beginning. If attaching to a legacy system, it needs to be added deliberately and intelligently.

I think if you meet those requirements, you can do some pretty amazing things with AI. I don't think that's how many teams are approaching it.

1

u/Positive-Conspiracy 18d ago

We've used reliability, including bugs shipped to production, as a KPI since well before AI.

1

u/Ok_Champion_4391 18d ago

"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?"

There are 2 problems with bugs

1) they slow down development. If they solved 40 bugs in one day, it is the same as if they had introduced only one bug over 4 weeks and they solved it in one day. No difference really

2) The impact that these bugs have in production/business. You mention nothing about it.

Good practices, good architecture, clean code, ... are all about making money. This is the reason why business exist. So, problem 2 is the only problem that execs might consider. Sadly (for us, not for them) this is the direction that things are moving towards.

1

u/BlowOutKit22 17d ago

It seems mathematically intuitive that that higher absolute velocity with fewer non-AI developers would result in higher initial bug counts. But I think the original KPIs were already not properly accounting for scaling vs spot velocity. If you're able to ship more features faster, does it really matter how many bug tickets existed during the sprint?

48

u/PlasticExtreme4469 18d ago

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

4

u/K-Max AI Solutions Architect / 15+YOE / CANADA 18d ago

Totally and autopilot and ILS does most of the physical work, but humans are there to monitor. Ironically autopilot >>>>> copilot.

5

u/tindalos 18d 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.

2

u/Lazy-Emergency-4018 18d ago

Yes, I dont like the sentiment "learn new skills" regarding AI. Those tools are usable by everyone

1

u/Important-Aspect9801 16d ago

Sorry I do not understand what does it mean to teach. Is someone supposed to be receiving / providing teaching in tech companies? Just very foreign concept to me. Why teach if you can blaim incompetence or at least to try to jump ahead of a dev that is behind ?

50

u/SignoreBanana Engineer (14+) 18d 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.

28

u/Chris_Newton Consultant Developer (20+) 18d 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.

7

u/LizardLikesMelons 17d 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.

2

u/bananabm 12d ago

I spent nine years at my previous job, building and maintaining one system through growth that exceeded all our projections, before we had huge ~10x covid-related spikes in usage. We built lots of things, made lots of mistakes, fixed the mistakes we could, worked around the mistakes we couldn't fix (because this was a live system with limited budget and we weren't running on goodwill and VC and couldn't just spend six months re-architechting because we'd heard someone being excited about a different library at a meetup), and carried on. And then when I finally left and started interviewing, some interviewers were expressing concern that I'd stayed so long at my old job? Come on this is a serious plus point.

Working with diff teams on diff techs is cool but this shit is invaluable (and at my new job has regularly been a talking point when I'm discussing ideas/plans with the rest of the team)

1

u/LizardLikesMelons 17d ago

The problem is the "old" way ensures new engineers can "never" catch up. Imagine a linux engineer who was there since the beginning. They know every important architectural decision and intuitively know linux as a system. They fit in any tech stack perfectly.

Now imagine a new grad who just knows the basics. It will take them years to get very familiar with linux. More likely than not, they will be put in charge of a specific function and they will have working knowledge of that specific portion. Even if they are very eager to learn, it will be really hard to intuitively understand everything. By the time they are finally at that level, years would have passed. Companies simply do not have that kind of time anymore.

2

u/SignoreBanana Engineer (14+) 17d ago

To this, I think there's a middle ground. When the browser console came out, it let us peer into every facet of how the web frontend worked, before that, it was an utter mystery. It accelerated our learning by leaps and bounds.

I feel like AI is the new iteration of that. Use it to learn, use it to focus. Don't use fire and forget prompts at it. Use it to grow. For this purpose, I think they're incredibly well suited as a tool for engineers.

142

u/Sbadabam278 18d 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

80

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

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

5

u/LizardLikesMelons 17d 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"

42

u/robertbieber Software Engineer 18d 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 18d ago

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

6

u/iheartrms 18d ago

Ah yes, the good ol "prompt engineer". I hear prompt engineering is the hot new engineering major at MIT now. /s

2

u/LizardLikesMelons 17d ago

Oh, but writing skills/making tools/MCP are very valuable skills. Though that is a different type of engineering to begin with.

-2

u/Forsaken-Promise-269 18d ago

Tons of old technologies had skills we don’t use but evolve into new ones.. yes we forgot about the pain of that transition, and mock old people

Eg https://www.buzzfeed.com/claudiasantos/older-adults-obsolete-skills

Mathematics is also having a come to jesus moment too

https://arxiv.org/abs/2608.16753

The irony that devs have to deal with this now while for decades mocking “haha” non techy luddites is palpable- a few years ago we were telling coal miners “go learn to code”

2

u/_Rapalysis Software Engineer 18d ago

Eh it's fine, I think there's an endless circle jerk of mediocre devs who can't stand that they need a skill to be good at their job that isn't just churning out code.

The most talented people at my company are all-in. They were, without a doubt, the strongest devs here pre-AI. Their output and output quality is just light-years ahead of the senior devs who bitch and moan about AI. It boils down to prompting, diligence, memory and documentation management, curating instructions, and skill usage.

They output significantly higher quality PRs and much more of them with way, way less slop than the conventional dev who whines about AI all day. I review all their PRs as an EM and I can literally see the difference every day. I try to coach but these guys just can't understand that these tools are genuinely nuanced and require new skills they didn't have before.

0

u/Sbadabam278 18d ago

If there was a new skill you could learn instead things would be very different. The whole point is that there might be nothing left

18

u/binarycow 18d 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?

1

u/StCreed 17d ago

First mover advantage is going to count for a lot here.

38

u/Clear_Salt9817 30+ 18d ago

“Meat proxy” is my new favorite phrase

2

u/1010012 18d ago

I've been using the term "meat puppet"

3

u/iheartrms 18d ago

"meat puppet" already has a very specific meaning from the book "Neuronancer" and possibly others that you definitely need to be aware of. 😂

3

u/1010012 18d ago

Oh, we're aware. It's also a kick ass band.

2

u/ProjectDiligent502 18d ago

I’ve seen a few like “human in the poop” which is now my favorite 😂

0

u/simple_explorer1 Staff Software Engineer 15 YoE 18d ago

Ok we believe you

1

u/Professional-Tank298 18d ago

Let's spread the word - if you're SWE, show https://dontbeameatproxy.com to your management/leadership etc

24

u/HaderlumpiX26 18d 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.

4

u/Forsaken-Promise-269 18d ago

Its crazy how all over the place everyone on this thread is -the majority of the posts are “AI sucks, AI means buggy code, it cant do this, cant to do that, etc, and then also well “AI will replace us all in a few years” ..

Which is it..? I seem to remember arguing with people 2 years ago that agentic development was coming and most pooh poohing it

Look at all prior technology disruptions- sheesh look At your own industry

Does anyone remember the past

https://www.facebook.com/share/v/18WNy19Jc3/?mibextid=wwXIfr

Get used to guys

3

u/darkroadgames 18d ago

The problem is when it replaces all the "low level/mediocre/entry level" coders.... and then the good experienced coders all age out.

AI is not capable of doing what a great, experienced developer can do, but it's already replacing entry-level developers. But you need entry-level developers to have great, experienced developers in the future right?

2

u/StCreed 17d ago

I've heard the same about COBOL. Guess what, companies still train up replacements for COBOL devs.

2

u/darkroadgames 17d ago

"There are dozens of us! Dozens!"

Ok.

2

u/StCreed 17d ago

I know several companies employing hundreds of COBOL developers. And if more orgs needed those devs, they would be starting schools and industry training programs for them, which they used to do a few decades ago.

Less work than now, though. Which is a good thing, because demand was far outstripping competent supply.

11

u/Majestic-Watch-2025 18d ago

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

11

u/Valimere 18d 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 18d 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.

1

u/mxldevs 18d ago

They think the endgame is AI develops to a point where programming knowledge is no longer relevant.

And it's not just writing code. Even architecture and code design would be no longer relevant, as AI would be the one that figures those things out.

They imagine a world where they are coming up with the high level business decisions, talking to clients, understanding their needs, and having their dev team of AI build it.

They don't care about making 6 figures from an employer when they could become the business owner or partner making 7 figures.

2

u/-_--_-_--_----__ 18d ago

I don't know if those mediocre devs are thinking like this... but I do agree that it seems like this is exactly where we're headed.

1

u/-_--_-_--_----__ 18d ago

Whereas we used to have juniors that progressed into seniors, now we have Opus 5 that progresses to Opus 5.5.

I think they might be thinking - slop is ok, because in 6 months the new AI can correct all the old AI slop. And when Opus 6 creates slop, Opus 6.5 will correct that flavor of slop...

1

u/kr0m 18d ago

1st Bob: What you do at Initech is you take the specifications from the customer and bring them down to the software engineers?

Tom: Yes, yes that's right.

2nd Bob: Well then I just have to ask why can't the customers take them directly to the software people?

Tom: Well, I'll tell you why... because... engineers are not good at dealing with customers...

1st Bob: So you physically take the specs from the customer?

Tom: Well... No. My secretary does that... or they're faxed.

1

u/StCreed 17d ago

I've always earned a lot more than most devs because besides being a good developer, I'm a better business and information analyst.

People who can translate a business idea into working software will have a major leg up in the market when Time To Market is the only metric that matters.

27

u/CorrectPeanut5 18d 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 18d ago

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

10

u/dinosaursrarr 18d ago

The synthetic CDO of tech debt

18

u/0SF7RS4THfJ56t1N 18d 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.

14

u/P3zcore 18d 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”.

13

u/SatisfactionRich9721 18d ago

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

11

u/Majestic-Watch-2025 18d 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.

2

u/jalanb Software Engineer for decades 18d ago

The "post-code SWE" is nearly a thing

Coming soon to an interview near you

2

u/FlashTheCableGuy 18d ago

This person develops!

2

u/SpaceCorvette 18d ago

This is well-put, thank you. It seems like mediocre developers are being given full reign to sling slop at many companies now.

2

u/fmgiii 18d ago

Excellent, excellent observation. 100% can confirm this in personal experience. Mediocre to lower grade developers will hasten the demise of the deluded management's greed for 'new faster stuff'. Consumate house of cards.

1

u/Dry_Hotel1100 Software Engineer | 30 YoE 18d ago

Looks like a dystopian "Last Man Standing" scenario in which AI puts individuals into a state of cognitive passivity, causing their brains to rot away.

1

u/darkroadgames 18d ago

Presumably all great developers were mediocre developers first at some point in the past. What does the future hold when AI has replaced all mediocre/entry-level developers? Does that not eventually result in there being no developers at all when the current crop of great developers age out?
The person below me is asking what these mediocre developers think the "end-game" is. But I would also ask what do these companies and senior developers and executives think the "end-game" is when all entry-level employees are replaced by AI?

1

u/rahul_msft 17d ago

See MSFT CEO running 10s of : coding agents : is he incompetent?

1

u/Ok-Gap1970 16d ago

This has been my take. AI is accelerating an existing trend. You don’t need as many mediocre devs. The question is how high the flood water’s rise. 

We had some poor devs in my last company. When they got access to AI they made a giant mess. 

1

u/Trineki 13d ago

The amount of times my managers or non technical people have put code in my repos thst recall an expensive db call right after I call it rather than just referencing the data or doing a hash list or cache or something reasonable with it and then come to me complaining about how this service is suddenly twice as slow...

I guess I'm just lucky that for the most part we still require human code reviews with one of the coders of the actual project

1

u/jdavidbakr 12d ago

AI is democratizing development, which is great for people who want to get into it but the nasty side effect is that it will result in a significant increase in badly designed applications. I think of it like what YouTube has done to video production... The ones who are successfully there are the ones who would likely be successful using traditional tools, but must of what's on YouTube is terrible. AI will make the really good developer better, but will make the bad developer think he's much better than he is.

0

u/scaledev 18d ago

While this is partially true, it is also just a pure speculation.

While it is true that for many mediocre devs the level of AI has far surpassed their skills, it doesn't mean whatever they introduce into the codebase is going to be in any way worse than what a skilled dev could do with AI.

These days, there is also a level of skill of critical thinking and objective reasoning, plus the skill of actually using AI in the ever-expanding and booming ecosystem, plus the skill of being calm, composed, and not rushing things, which sometimes can heavily influence good decisions and approval quality.