10 ms·
> there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their cow
by endorphine 9mo ago
> there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest.
It's even worse than that: non-junior devs are doing it
as well.
- reedf1 9mo agoit's even worse than that! non-devs are doing it as well
- snowstormsun 9mo agoit's even worse than that! bots are doing it as well
- pydry 9mo agoHopefully once this AI nonsense blows over they'll reach the same realisation they did after the mid 2000s outsourcing craze: that actually you gotta pay for good engineering talent.
- marcosdumay 9mo agoAbandon any platform that decides to put bots into your workflow without you telling it to. Vote with your wallet.
- vernrVingingIt 9mo ago[flagged]
- whattheheckheck 9mo agoWhat process / path do you take to get to such an enlightened state? Like books or experience or anything more about this please?
- vernrVingingIt 9mo agoBachelors in electrical engineering, masters in math; elastic structures applied to modeling electrical systems. Started career in late 90s designing boards for telecom companies network backbones.
- rcbdev 9mo agoThis sounds like the exact kind of profound pseudo-enlightenment that one gets from psychedelics. Of course, it's all electrons in the end. Trying to create a secure, reliable and scalable system that enables many people to work on one code base, share their code around with others and at the end of the day coordinate this dance of electrons across multiple computers, that's where all of these 'useless' layers of abstraction become absolutely necessary.
- vernrVingingIt 9mo agoTry almost 30 years in electrical engineering. I know exactly what those layers of abstraction are used for. Why so many? Jobs making layers of abstraction. But all of them are dev friendly means of modeling memory states for the CPU to watch and transform just so. They can all be compressed into a generic and generalized set of mathematical functions ridding ourselves of the various parser rules to manage each bespoke syntax inherent to each DSL, layers of framework.
- nkohari 9mo ago> I know exactly what those layers of abstraction are used for. Why so many? Jobs making layers of abstraction. This is a perfect example of Chesterson's Fence. Is it true that there are too many levels of abstraction, that YAML configuration files are a pain in the ass, and so on? Yes. But it's because this stuff was created organically, by thousands of people, over decades of time, and it isn't feasible to just start over from first principles. I don't know enough about electrical engineering to speak to it (funny how that works!) but I'm sure there are plenty of cases in EE that just come down to "that's how it's been done forever".
- vernrVingingIt 9mo agoWell starting over from first principles is exactly what the chip design and manufacture industry is doing. We also cannot afford, in non-finance terms, to burn all the resources on conservation of the existing software mess. Automation is making it pretty easy to generalize all the abstraction into math automatically to inform how to evolve the manufacturing process. Using American principles against Americans, it would run afoul of American free speech and agency ideals to dictate chip makers only engage in speech and agency that benefits software engineers. Was in the room 25 years ago being instructed to help offshore hardware manufacturing as it was realized keeping such knowledge and informed workers domestic posed an existential threat to copyright cartels and media censorship interests. It's a long term goal that was set aside during the ZIRP era as everyone was happy making money hand over fist. Guess you all should have paid more attention to politics than believe since it only exists as a socialized theory it isn't real and can safely be ignored. Americans make up a small portion of the 8 billion humans, and software engineers are an even smaller percent of the population. Other nations have rebuilt since the US bombed them to hell. They're not beholden to kowtow to a minority of the overall population. Would recommend you set aside thinking in abstract philosophy puzzles and relate to world via its real physical properties.
- nanomonkey 9mo agoThere are some contradictory claims here. Boilerplate comes when your language doesn't have affordances, you get around this with /abstraction/ which leads to DSLs (Domain Specific Languages). Matrix math is generally done on more than raw bits provided by digital circuits. Simple things like numbers require some amount of abstraction and indirection (pointers to memory addresses that begin arrays). My point is yes, we've gotten ourselves in a complicated tar pit, but it's not because there wasn't a simpler solution lower in the stack.
- iwontberude 9mo agoAnd here I thought people just used computers for the heat
- stephen_cagle 9mo agoI honestly can't tell if you are speaking in metaphor or literally?
- esafak 9mo agoThat's what democratization looks like. And the new participants are happy!
- rvz 9mo ago…Until you tell them to maintain all the technical debt that was generated when it breaks and waste more time and money / tokens on fixing the security issues. A great time to be a vibe coding cleanup specialist (i.e, professional security software engineer)
- BurningFrog 9mo agoReally good code reviewing AIs could handle this!
- throwawaysleep 9mo agoCode review is an unfunded mandate. It is something the company demands while not really doing anything make sure people get rewarded for doing it.
- Aurornis 9mo ago> while not really doing anything make sure people get rewarded for doing it. I don’t know about you, but I get paychecks twice a month for doing things included in my job description.
- georgeburdell 9mo agoMy manager asked me to disable CI and gating code owner reviews “for 2 weeks” 6 months ago so people could commit faster. Just because it is in your job description doesn’t mean it won’t get shoved aside when it’s perceived as the bottleneck for the core mission. Now we have nightly builds that nobody checks the result of and we’re finding out about bugs weeks later. Big company btw
- immibis 9mo agoThat's his right. In capitalism, company owners have the power (which they delegate to managers) to fuck up the company as much as they see fit. On the upside, it means it's their responsibility and not yours. Once you've said it's going to cause horrible problems, and they say do it anyway, and you have a paper trail of this and it's backed up onto your own storage medium, then you just do it and bring popcorn. If you think it'll bankrupt the company, then you have nothing to lose since you have no right to stop a company going bankrupt, so you might as well email your manager's manager's manager first and see if your manager gets fired.
- SchemaLoad 9mo agoYep, who cares. You put your 2 cent in and if the business leaders see otherwise, that's their problem. You get paid on a schedule, if the app crashes and burns because the leaders demanded to remove PR reviews, that's not your problem. Too often I see developers getting personally invested in business outcomes which they don't have a stake in. Getting frustrated when they don't have the final say.
- Aurornis 9mo agoThis mirrors my experience with the texting while driving problem: The debate started as angry complaints about how all the kids are texting while driving. Yet it’s a common problem for people of all ages. The worst offender I knew for years was in her 50s, but even she would get angry about the youths texting while driving. Pretending it’s just the kids and young people doing the bad thing makes the outrage easier to sell to adults.
- jennyholzer2 9mo ago[flagged]
- deleted 9mo ago[deleted]
- hnthrow0287345 9mo ago>It's even worse than that: non-junior devs are doing it as well. This might be unpopular, but that is seeming more like an opportunity if we want to continue allowing AI to generate code. One of the annoying things engineers have to deal with is stopping whatever they're doing and doing a review. Obviously this gets worse if more total code is being produced. We could eliminate that interruption by having someone doing more thorough code reviews, full-time. Someone who is not being bound by sprint deadlines and tempted to gloss over reviews to get back to their own work. Someone who has time to pull down the branch and actually run the code and lightly test things from an engineer's perspective so QA doesn't hit super obvious issues. They can also be the gatekeeper for code quality and PR quality.
- sorokod 9mo ago> One of the annoying things engineers have to deal with is stopping whatever they're doing and doing a review. I would have thought that reviewing PRs and doing it well is in the job description. You latter mention "someone" a few times - who that someone might be?
- bee_rider 9mo agoCan we make an LLM do it? “You are a cranky senior software engineer who loves to nitpick change requests. Here are your coding standards. You only sign off of a change after you are sure it works; if you run out of compute credits before you can prove it to yourself, reject the change as too complex.” Balance things, pit the LLMs against each other.
- cm2012 9mo agoThis would probably catch a lot of errors
- jjmarr 9mo agoWe do this at work and it's amazing.
- postflopclarity 9mo ago
- lowkeyokay 9mo agoIn the company I’m at this is beginning to happen. PM’s want to “prototype” new features and expect the engineers to finish up the work. With the expectation that it ‘just needs some polishing’. What would be your recommendation on how to handle this constructively? Flat out rejecting LLM as a prototyping tool is not an option.
- lurking_swe 9mo agosounds like a culture and management problem. CTO should set clear expectations for his staff and discuss with product to ensure there is alignment. If i was CTO I would not be happy to hear my engineers are spending lots of time re-writing and testing code written by product managers. Big nope.
- Our_Benefactors 9mo agoThis could be workable with the understanding that throwing away 100% of the prototype code is acceptable and it’s primary purpose is as a communication tool, not a technical starting point.
- rootusrootus 9mo agoThis is how I've handled it so far. But that is probably because the PM that does this for me knew going in that they were not going to be generating something I'd want to become responsible for polishing and maintaining. It's basically just a fancier way of doing what they would otherwise use SketchUp for.
- jjmarr 9mo agoI would accept this because it'll increase demand for SWEs and prevent us from losing our jobs.
- jennyholzer2 9mo ago[flagged]
- cpursley 9mo ago
- 627467 9mo agoJust shove a code review agent in the middle. Problem solved [Edit] man, people dont get /s unless its explicit
- fragmede 9mo agoThat startup is called CodeRabbit and damned if it doesn't come up with good suggestions sometimes. Other times you have to overrule it, or more likely create separate PRs for its suggestions, and avoid lumping a bunch of different stuff into a single PR, and sometimes it's stupid and doesn't know what it's talking about, and also misses stuff, so you do still need a human to review it. But if your at all place where LLMs are being used to generate large swaths of functional code, including tests, and human reviewers simply can't keep up, overall it does feels like a step forwards. I can't speak to how well other similar services do, but presumably they're not the only one that does that; CodeRabbit's just the one that my employer has chosen.
- kridsdale3 9mo agoIs this startup sitting on any IP other than a bunch of prompts?
- analog31 9mo agoWhere are the junior devs while their code is being reviewed? I'm not a software developer, but I'd be loath to review someone's work unless they have enough skin in the game to be present for the review.
- stuaxo 9mo agoGit PRs work on async model for reviews.
- DrewADesign 9mo agoAnd even then, in my experience, they work more like support tickets than business email, for which there are loose norms for response time, etc. Unless there’s a specific reason it needs to be urgently handled, people will prioritize other tasks.
- tyrust 9mo agoCode review is rarely done live. It's usually asynchronous, giving the reviewer plenty of time to read, digest, and give considered feedback on the changes. Perhaps a spicy patch would involve some kind of meeting. Or maybe in a mentor/mentee situation where you'd want high-bandwidth communication.
- mullingitover 9mo ago> expects the “code review” process to handle the rest. The LLMs/agents have actually been doing a stellar job with code reviews. Frankly that’s one area that humans rush through, to the point it’s a running joke that the best way to get a PR granted a “lgtm” is to make it huge. I’ve almost never seen Copilot wave a PR through on the first attempt, but I usually see humans doing that.
- distances 9mo agoThat smells of bad team practices. Put a practical limit on PRs sizes as the first step, around 500 lines max is a good rule of thumb in my experience. Larger than that, and the expectation then is a number of small PRs to a feature branch. I rarely see a PR that should pass without comments. Your team is being sloppy.
- mullingitover 9mo ago> Your team is being sloppy. I'm talking about a running joke in the industry, not my team.
- strangattractor 9mo agoNot at Meta - their job is to "Move fast and break things". I think people are just doing what they've been told.
- bee_rider 9mo ago“Move fast and break things” works well when you are a little player in a big world, because you can only perturb the system into so bad a state with you limited resources. Now, they got big, and everything is broken.
- alphazard 9mo agoQuality is not rewarded at most companies, it's not going to turn into more money, it might turn into less work later, but in all likelihood, the author won't be around to reap the benefits of less work later because they will have moved onto another company. On the contrary, since more effort doesn't yield more money, but less effort can yield the same money, the strategy is to contract the time spent on work to the smallest amount, LLMs are currently the best way to do that. I don't see why this has to be framed as a bad thing. Why should anyone care about the quality of software that they don't use? If you wouldn't work on it unless you were paid to, and you can leave if and when it becomes a problem, then why spend mental energy writing even a single line?
- tuyiown 9mo agoBecause nothing can beat productivity of a motivated team building code that they are proud of. The mental energy spent becomes the highest reward. As for profit, it _compounds_ as for every other business. The fact that this is lost as a common knowledge whereas shiny examples arises regularly is very telling. But it is not liked in business because reproducing it requires competence in the industry, and finance deep pockets don’t believe in competence anymore.
- hostyle 9mo agoNot everything is about money. Have you never wanted to be good at something because you enjoy it? Or do something for the love of the craft? Have you heard of altruism?
- Larrikin 9mo agoBut why do that for the company instead of yourself?
- alphazard 9mo agoThis exactly. You have to be honest about why you are building something. If the answer is that you actually want to use it, then yes, quality and maintainability are important. It might even be a good idea to use no AI whatsoever. But if you are building it because doing so is in the long chain of cause and effect that leads to you being fed and having shelter, then you should minimize the amount of your time that is required to produce that end result. Do you get better food, and better shelter if the software is better? It would certainly be nice if that was the case, but it's not. > Not everything is about money. Except for your job, which is primarily about money. Making it take less time, means that you have more time to focus on things that really are not about money.
- rootusrootus 9mo agoOne thing I've pushed developers on my team to do since way before AI slop became a thing was to review their own PR. Go through the PR diff and leave comments in places where it feels like a little explanation of your thought process could be helpful in the review. It's a bit like rubber duck debugging, I've seen plenty of things get caught that way. As an upside, it helps with AI slop too. Because as I see it, what you're doing when you use an LLM is becoming a code reviewer. So you need to actually read the code and review it! If you have not reviewed it yourself first, I am not going to waste my time reviewing it for you. It helps obviously that I'm on a small team of a half dozen developers and I'm the lead, and management hasn't even hinted at giving us stupid decrees like "now that you have Claude Code you can do 10x as many features!!!1!".
- rcxdude 9mo agoYeah, I always think it's kinda rude to throw something to someone else to review without reviewing it yourself, even if you were the one to write it. Looking at it twice yourself can help with catching things even faster than someone else getting up to speed with what you were doing and querying it. Now it seems like with LLMs people are putting code up for review that hasn't even been looked at once.
- SchemaLoad 9mo agoMy coworker does this. PRs with random files from other changes left in, console logs everywhere. Blatent issues everywhere. I find it extremely rude they chuck this stuff at me without even having read it themselves. At least these days I can just chuck the AI reviewer thing on it and throw it back to them.
- seanmcdirmid 9mo agoDon’t accept PRs without test coverage? I mean, LLMs can do those also, but it’s something.
- deleted 9mo ago[deleted]
- acedTrex 9mo agoJuniors aren't even the problem here, they can and should be taught better thats the point. Its when your PEERS do it that its a huge problem.
- tyleo 9mo agoThere’s folks who perform like juniors but have just been in the business long enough to be promoted. Title only loosely tracks skill level and with AI, that may become even more true.
- xnx 9mo agoUnfortunately, junior behavior exists in many with "senior" titles. Especially since "senior" is often given to those 2 years out of school.
- SoftTalker 9mo agoTitle inflation?
- tensor 9mo agoIMO tech suffers pretty horrible title inflation. If you reach "senior" after only two years and "principle" after 5, what is left for the next 20 years? It's pretty ridiculous. But this sort of thing is really typical. The average tenure of someone in tech is probably about 2 years and each year the expectation is to see "big" career progression. Very often "When is my title going to change" is asked literally in the first year performance review.
- jghn 9mo agoThe important thing here is for people to understand that at best titles only indicate relative rank within a company. And even then that's tenuous. Titles are effectively meaningless when comparing outside of a company.
- lokar 9mo agoYou get (finite) periods where several large / influential companies have a reasonably high level of rigor for their own levels, and there is a pretty stable mapping between the companies. One such period seems to have ended sometime around the start of Covid, or a bit before.
- deleted 9mo ago[deleted]
- CodeMage 9mo ago
- snarf21 9mo agoYeah, it is way worse than that. In the past two days, I have had two separate non-engineer team members ask some AI agent how some mobile bug should be fixed and posted the AI response in the ticket as the main content and context and acceptance criteria. I then had to waste my time reading this crap (because this is really all that is in the ticket) before starting my own efforts to understand what the real ask or change in behavior needed is.
- teaearlgraycold 9mo agoYour manager should be on their ass for wasting your time.
- snarf21 9mo agoWorse yet, these were done by the managers of the Marketing team and the Mapping team. Plus, these are high profile issues that (somehow) required getting the CEO involved too! (Obviously there is a lot of dysfunction in our organization, lol.)
- abustamam 9mo agoI was going to joke to GP "jokes on you, management is in on it" but apparently it was no joke
- deleted 9mo ago[deleted]
- abustamam 9mo agoNew career path unlocked — reverse prompt engineering — trying to determine what someone prompted the AI given the slop they put into a ticket
- dejj 9mo agoPlot twist: this universe (planet) was created in order to reverse engineer what the prompt of the previous one was.
- TexanFeller 9mo agoEven worse for me, some of my coworkers were doing that _before_ coding LLMs were a thing. Now LLMs are allowing them to create MRs with untested nonsense even faster which feels like a DDOS attack on my productivity.
- hinkley 9mo agoThere’s a PR on a project I contribute to that is as bad/big as some PRs by problematic coworkers. I’m not saying it’s AI work, but I’m wondering.
- duxup 9mo agoIt’s always the developers who can break / bypass the rules who are the most dangerous. I always think of the "superstars" or "10x" devs I have met at companies. Yeah I could put out a lot of features too if I could bypass all the rules and just puke out code / greenfield code that accounts for the initial one use case ... (and sometimes even leave the rest to other folks to clean up).
- beautiful_zhixu 9mo ago[dead]
- tunesmith 9mo agoAs always, this requires nuance. Just yesterday and today, I did exactly that to my direct reports (I'm director-level). We had gotten a bug report, and the team had collectively looked into it and believed it was not our problem, but that of an external vendor. Reported it to the vendor, who looked into it, tested it, and then pushed back and said it was our problem. My team is still more LLM-averse than me, so I had Codex look at it, and it believed it found the problem and prepared the PR. I did not review or test the PR myself, but instead assigned it to the team to validate, partly for learnings. They looked it over and agreed it was a valid fix for a problem on our side. I believe that process was better than me just fully validating it myself, and part of the process toward encouraging them to use LLM as a tool for their work.
- xyzzy_plugh 9mo ago> I believe that process was better than me just fully validating it myself Why? > and part of the process toward encouraging them to use LLM as a tool for their work. Did you look at it from their perspective? You set the exact opposite example and serve as a perfect example for TFA: you did not deliver code you have proven to work. I imagine some would find this demoralizing. I've worked with a lot of director-level software folk and many would just do the work. If they're not going to do the work, then they should probably assign someone to do it. What if it didn't work? What if you just wasted a bunch of engineering time reviewing slop? I don't comprehend this mindset. If you're supposedly a leader, then lead.
- necovek 9mo ago2 decades ago, so well before any LLMs, our CEO did that with a couple of huge code changes: he hacked together a few things, and threw it over the wall to us (10K lines). I was happy I did not get assigned to deal with that mess, but getting that into production quality code took more than a month! "But I did it in a few days, how can it take so long for you guys?" was not received well by the team. Sure, every case is its own, and maybe here it made sense if the fix was small and testing for it was simple. Personally (also in a director-level role today), I'd rather lead by example and do the full story, including testing, and especially writing automated tests (with LLM's help or not), especially if it is small (I actually did that to fix misuse of mutexes ~12 months ago in one of our platform libraries, when everybody else was stuck when our multi-threaded code behaved as single-threaded code). Even so, I prefer to sit with them and loudly ask questions that I'd be asking myself on the path to a fix: let them learn how I get to a solution is even more valuable, IMO.
- vrighter 9mo agoand non-devs as well, nowadays
- coldtea 9mo agoIt's even worse than that: as long as it somewhat works, managers don't care, if not prefer it (to more slowly developed, more tested, more well architected code)
- giancarlostoro 9mo agoI have said it before on HN using LLMs should 100% justify devs having enough time to test and document the code, and understand it better. The problem I do see though will be management.