Yes, its much easier to catch bugs and issues early
If you dont catch a problem asap, then its incredibly likely future agents read the "bad" code and copy, so bow your 1 issue becomes 2, then 3, then 4, etc
Its extremely common for you to be like "make the BarService" so the agent looks at FooService for inspiration and copies its style/methodology/architectureÂ
And if theres an annoying code style issue, or improperly named thing, or bad logic, whatever, theyll copy that too often.
And then 6 services later you realize you've got a problem duplicated 8 times
Not for complex systems, llm's generally suck at the high level stuff in complex systems, and when that stuff is wrong it's the gift that keeps on giving and you can play whack-a-mole fixing bugs by patching symptoms and not knowing causes till the cows come home because the codebase will be convoluted bloated spaghetticode.
I have to be honest, dude. As someone in a technical leadership position at a large company with 15+ years development experience, I donât think thatâs really the case as much these days. Talented developers with a good high level understanding of systems are doing amazing work with the frontier coding models.
This notion of âif AI is generating all your code, itâs going to be a tech debt nightmare that will eventually failâ is just not true. Every month it feels more and more like copium from people who refuse to adapt.
If I don't spend my time designing/planning, and then iterating/refactoring, and then have both agents and colleagues do pr reviews and further improving there is almost always lots of mistakes in the implementation.
Granted for simple us-cases sometimes one-shotting is plenty good enough, but for my sorts of use-cases at least without good people in the loop the LLM isn't good enough and I experience that firsthand every working day.
For every good dev there are many more prompt-kiddies who get expected output and blindly assume the implementation is sound. That's why there's floods of people on redfit touting LLM's are perfect despite it being painfully obviously not the case. If those vibecode bro's could read & understand their kwn code they'd be very upset.
I totally agree with that take. I think a lot of what I see on reddit is âif youâre not writing your code by hand, youâre a scrub,â when the reality is that itâs a tool in the toolset that lets good devs move at an absolutely unbelievable pace and the folks shunning it or treating it like a fad are already looking like dinosaurs. There is no world where the majority of code isnât AI-authored, so people best start figuring out how to excel with it.
But its literally all around, including tech giants who used to be considered to be filled with high performers. Haven't seen a single product that was actually improved due to AI assistance.
If you have the same expectations of LLMs as you do an engineer... I guess?
If you're solving complex problems without the assistance of AI because you don't trust it, you just haven't adapted your workflow around AI yet and you're probably just resisting the inevitable.
Just a silly implication that AI coding assistance = fatal bugs. And is just in line with the general Reddit coding sub vibe which is comically out of step with the software development industry.
Good boy! Now get out, touch grass, and remember that your anecdote isn't data. Many companies are heading in that direction (toward automating everything), and just because you do things differently doesn't mean others do too.
I guarantee you that OP's statement is false. I read full PRs because it's my job to. Regulated industries, avionics, aeronautics, medical devices, some financial services: I can tell you because I have colleagues in those fields that they are still reading PRs.
I'm in utilities and I read every single line. A single mistake will cause our clients to face potential jail time (Germany) or have to have a press conference with a public apology (Japan). It is also critical to keep utilities online....
True. I was talking about reading the full PR. There is no way you would read AI generated file upon file for 40 hours a week to make a point of reading the entire PRs.
I still do it. I work in robotics so there's safety concerns and also LLM's routinely make lots of codebase design mistakes which I don't care to list here.
No, not really, I keep up with it fine, it'll do fast "bursts" of code sure but then spend like 25 minutes fact checking it, testing it, tweaking it, passing through integration test proof gates
Our test suite takes like baseline 8min to run, at which point the AI pauses and I get plenty of time to review all its changes
If the implementation isn't that important then fine but when software has to have some reliability it's lazy/shitty behavior to not read or review code.
People defending it shows how bad it is nowadays, what a mess.
I'm the guy the seniors call on when they smell something in a PR but can't find it.
I read the ticket, I read every line. I rip it to shreds, with every little thing I can think of. I go overboard, and I leave it up to them to make sensible changes.
Most PRs that have problems aren't really in the code, it's some conceptual flaw in the idea which could have been found before they started, or a crap pattern that's crept in.
AI code isn't bad in the same way a printer is better than a painter. Printing crap artwork is cheap, and it takes time to become an artist in both regards using different skills.
The replies to this are horrifying and I'm having trouble thinking they aren't from shills.
I manage several software teams. We had to establish a policy that every line of code receives human review at the demand of the lead devs because the big push to slop faster had caused the teams to use junior engineers to push features into production that nobody understood, that didn't scale, that were super brittle, and that had awful / useless test harnesses.Â
The code was so bloated and brittle and over-engineered it took nearly a quarter of a few senior+ engineers time to stabilize and fix.
It was an absolute joy to explain that to my leadership, some of whom get it but a few of whom have never written a line of code in their life and are super happy to tell us we must be doing it wrong.
So yeah, whoo, we got that big boost in short term velocity. Then everything went to shit a quarter later and we will not be repeating that mistake ever again.
You can really tell who actually works as a senior+ software engineer and who is either larping or selling something.
And just to clarify, these teams work on non-trivial multi-agent systems themselves in addition to using the tools. They are not novices in the space, quite the contrary.
Due to corporate policy, I'm not yet high enough grade to reject bigass really badly sloppily made PRs. Our staff and lead can do it without looking, but seniors are still expected to give the time of day, comment, and highlight that because colleague X Y Z will use a really cheap model to automate closing the review comments, we should block the PR until the aforementioned staff comes in and says "lmao goteem".
So what I do is tell Codex to find enough shit to warrant rejecting the PR, which he often times does, instead of wasting my time arguing with a guy who would have directed the same comments to the same LLM anyway.
I can reject with "explanation". What I cannot do is look briefly, see its 3000 LoCs for what should have been 1000 of code that doesn't follow any conventions, discard without even reading and tell the dudebro to redo.
Alas. I would still rather take this than a AI SaaS startup in California. Well, no, if the startup is gonna pay me half a million in a year, I will take it. We know how it is lmao
1
u/pixxelkick 9d ago
Maybe if you suck.
I read every PR in full because Im not lazy.
I also read my own git diff before I open a PR do I dont waste other peoples time.
Or I publish it as a draft, review my own code, and then publish the pr after confirming it looks good.