[endorphine]

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

[snarf21]

Yeah, 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.

[biglost]

Our leader wrote himself a great prompt to fill up Tickets in jira with useless text too and our boss is happy like if he won the lottery. Now instead of ugly but short useful texts now i have yo read a fucking eassay!!!

[andai]

Nah, you know how it works? You're not supposed to read it!

Encoding Process

One sentence in -> Several paragraphs out

Decoding Process

Several paragraphs in -> One sentence out

[Muromec]

You were supposed to feed it back into the lying machine to dustill the content from the vapor, not read it. You are not AI native worker and should be kicked out of the otherwise great performing team

[yieldcrv]

Better than dealing with a PM though

Like look, your boss was happy, so the blockade away from your boss that your PM provides is solved

So just write an agent to summarize and read the room like the 200 EQ mastermind that it is, compared to your 0 EQ engineer brain, and move on

AI writing tickets, AI reading tickets, AI writing code from said tickets

only ones affected are middle management and site reliability engineers, poof we can write complex backend scripts too now

[fragmede]

No you don't. Feed the essay to Claude and ask it to summarize it for you, or just use the Jira MCP and have Claude or codex take the ticket, use the GitHub MCP to get it the source, have it go work on the ticket, have it generate the code, generate some unit tests, then you go literally yell at your computer using Wispr Flow or some other transcription software to tell Claude how to fix the mess it made, and then you after you've cleaned it up, you submit the PR.

When ChatGPT first came out three years ago, we joked about Devin and having an AI coworker, but I was just given 5 tickets to work on before break, and damned if AI didn't take a well scoped ticket and just did it before I even finished reading that very tightly scoped ticket.

[davely]

While I personally find that generative AI has helped me be more productive and even boosted my ability to learn things, I really _dislike_ that we’ve normalized this behavior:

Whether a Jira ticket, an email, a yearly review, we feed bullet points into a black box to get a bunch of fluffy text. On the other end, we feed the fluffy text into the black box to get bullet points.

We’re killing penguins because we’re somehow afraid to just send the simplified bullet points to each other in the first place.

[abustamam]

New career path unlocked — reverse prompt engineering — trying to determine what someone prompted the AI given the slop they put into a ticket

[dejj]

Plot twist: this universe (planet) was created in order to reverse engineer what the prompt of the previous one was.

[tremon]

It's not that much of a twist, given that it was basically the plot of THGTTG.

[CGamesPlay]

THGTTG was actually just an early version of the prompt. "What do you get if you multiply six by nine?"

[fragmede]

42

[rTX5CMRXIfFG]

I think you’re kidding but some LinkedIn influencer will come across this and preach that it’s serious

[colechristensen]

You close the ticket and ping the manager of the nontechnical person submitting the ticket. Then you have a discussion with management about the arrangement and expectations. If it doesn't go well you polish your resume.

[shermantanktop]

That sounds like good advice for someone 1) in a less hierarchical organization, and 2) during a period when jobs are easy to get.

[colechristensen]

Or someone who

1) has the savings such that they aren't a wage slave (applies to any income level)

2) has any dignity

People willingly put themselves in situations where they have no autonomy and no options by living their entire lives paycheck to paycheck or close enough to not make a difference.

[shermantanktop]

That’s a pretty judgmental take. The only people with dignity in your formulation are independently wealthy.

If I stomped out the door as soon as I had to curb my tongue, I would never build the social and reputational capital required to be effective on bigger projects, and those are fun (to me).

[godelski]

We're in tech and this shit is happening in big tech companies. Yes, there's many of us who are not getting those wages but every one of them is independently wealthy.

Regardless, you are not a slave. Have a backbone. If you do not stand up for yourself you make it harder for others to do so. Your actions don't just affect you.

[teaearlgraycold]

Your manager should be on their ass for wasting your time.

[snarf21]

Worse 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]

I was going to joke to GP "jokes on you, management is in on it" but apparently it was no joke

[baxtr]

There is also another way to view this:

People who have a sloppy/lazy way of working are exposed more quickly by this.

[dmurvihill]

Got this kind of crap from multiple tickets I filed with GitHub

[xnx]

Unfortunately, junior behavior exists in many with "senior" titles. Especially since "senior" is often given to those 2 years out of school.

[theshrike79]

A coworker had this anecdote decades ago.

There's a difference between 10 years of experience and 1 year of experience 10 times.

YOE isn't always a measurement of quality, you can work the same dead-end coding job for 10 years and never get more than "1 year" of actual experience.

[stephen_cagle]

You know, this is kind of a funny take at some level. Like, for any surgery, you want the doctor who has done the same operation 10 times, not the one who has 10 years of "many hat doctoring" experience.

I'm not really arguing anything here, but it is interesting that we value breadth over (hopefully) depth/mastery of a specific thing in regards to what we view as "Senior" in software.

[lokar]

You want the Dr who has done the operation 10 times, and learned something each time, and incorporated that into their future efforts. You probably don’t want a Dr who will do their 11th surgery on you exactly the way they did the first.

This is what that saying is about

[stephen_cagle]

Fair enough. I guess I am making a bit of a straw-man in that I feel I just don't buy the idea that doing the same thing 10 times over the course of 10 years is somehow worse than doing different things over the course of 10 years. They are signals, and depending on what we are attempting, they just mean different expected outcomes. One isn't necessarily worse than another, but in this case it seems to be implying it is the distinction between Midlevel and Senior.

[KronisLV]

> I just don't buy the idea that doing the same thing 10 times over the course of 10 years is somehow worse than doing different things over the course of 10 years.

I always read it as making the same mistakes as you initially did and either failing to learn from them or not even trying to improve. Maybe you haven’t even explored enough approaches to see what actually works and what doesn’t and most importantly, in which circumstances.

For example, someone might do CI/CD with manually created pipelines in Jenkins (the web UI variety) with stuff like JDK configured directly on the runner nodes. They might never have written a Jenkinsfile, or tried out Docker for builds and therefore are slow and have to deal with brittle plugins and environment configuration. They might also be unaware of how GitHub Actions could benefit them, or the more focused approach of GitLab CI or even how nice Woodpecker CI can be, especially for simpler setups.

[coldtea]

>Fair enough. I guess I am making a bit of a straw-man in that I feel I just don't buy the idea that doing the same thing 10 times over the course of 10 years is somehow worse than doing different things over the course of 10 years.

Different things doesn't need to mean "different domains" which is how you read it.

It can be "things revealing different aspect/failure cases of the same domain" too.

If someone has done the same narrow kind of CRUD app 10 times, they're not CRUD-app experts - they never seen lots of different aspects of CRUD apps.

[NDizzle]

I want the doctor who has performed the operation and was still with the hospital in 6m, 12m, 18m, 24m to see the results of the operations that they performed.

Not the one who does a few operations and is never around to see the results of their decisions and actions.

[3acctforcom]

Ops vs Dev

Situational Leadership gets into this. You want a really efficient McDonalds worker who follows the established procedure to make a Big Mac. You also want a really creative designer to build your Big Mac marketing campaign. Your job as a manager is figuring out which you need, and fitting the right person into the right job.

[abustamam]

Agreed. Meanwhile, many job postings out there looking for 10x full-stack developers who have deep experience in database, server, front end, devops, etc.

I think the concept of Full-stack dev is fine, but expecting them to know each part of the stack deeply isn't feasible imo.

[theshrike79]

Expert Generalists are a thing: https://martinfowler.com/articles/expert-generalist.html

BUT they're completely wasted if you just use them to turn JIRA tickets into end to end features =)

[gopher_space]

“This person is incurious” would be more apt but also more likely to apply to everyone else in the room too.

Didn’t Bruce Lee famously say he fears the man who’s authored one API in ten thousand different contexts?

[xarope]

for context, he was referring to a physical methodology, which requires a lot of training and knowledge of usage application.

As analogy, I don't think you'd treat "using API XYZ 10,000 times" the same as "serving an ace in tennis, 10,000" times.

[WalterBright]

I once asked an obstetrician how she could tell the sex of a fetus with those ultrasound blobs. She laughed and said she'd seen 50,000 of those scans.

[theshrike79]

If we extrapolate the Dr example:

There is the one doctor who learned one way to do the operation at school, with specific instruments, sutures etc. and uses that for 1000 surgeries.

And then there's the curious one who actively goes to conferences, reads publications and learns new better ways to do the same operation with invisible sutures that don't leave a scar or tools that are allow for more efficient operations, cutting down the time required for the patient to be under anaesthesia.

Which one would you hire for your hospital for the next 25 years?

[akho]

The one with the smaller cemetery.

[gpderetta]

This is not really a doctor that has done the same operation 10 times. This is a doctor that jumped form hospital to hospital 10 times and probably never actually stayed long enough to be entrusted to do an operation in any hospital.

[NumberCruncher]

My favourite saying is: "dumb people get old too".

[teaearlgraycold]

When interviewing candidates I'm always shocked and a little depressed talking to someone with a pumped up resume and 15 years in the field when I realize they can't do much at all.

[ludicity]

Yeah, I run into this a lot too, hah. It's depressing but also pretty funny when you've got enough distance from it. My favorite was an ex-girlfriend working in HR interviewed a candidate with 15 years of experience, and was told to ask him to solve FizzBuzz in a language of his choice.

(This is obviously a silly test for various reasons, but she was following orders.)

She called me later that day because the guy couldn't do it, so he instead blew the fuck up at HR and accused them of ambushing him with a super complex interview question. From his reaction, she thought that the company had tricked her into making totally unreasonable demands of someone who hasn't had a month to prepare.

God knows what the hell that guy did at his previous role.

PS: I have laughed every time I've seen your username for the past year, and can't remember if I've told you this before.

[teaearlgraycold]

> PS: I have laughed every time I've seen your username for the past year, and can't remember if I've told you this before.

You haven't but thanks :D

[godelski]

Jean-Lukewarm Picard, they call him

[ChrisMarshallNY]

I'm constantly working on stuff I don't know (the Xcode window behind this browser window is full of that kind of code). I have found LLMs are a great help in pushing the boundaries.

It's humbling, but I do tend to pick up a lot of stuff.

https://littlegreenviper.com/miscellany/thats-not-what-ships...

[theshrike79]

There are a definitely few ulcer-inducing events in my past that would've taken me an afternoon to fix with a current SOTA LLM vs 2+ weeks of swearing, crying and stressing out.

[ChrisMarshallNY]

When I come upon an issue, I pretty much immediately copy/paste the code into an LLM, with a description of the context, symptoms, and desired outcome.

It will usually home right in on the bug, or will give me a good starting point.

It's also really good at letting me know if this behavior is a "commonly encountered" one, with a summary of ways it's addressed.

I've probably done that at least a dozen times, today. I guess I'm a rotten programmer.

[theshrike79]

I've completed actual features by saying "look up issue ABBA-1234 and create a plan to implement it" to Claude.

Then I wait, look through the plan and tell it to implement and go do something else.

After a while I check the diffs and go "huh, yea, that's how I would've done it too", commit and push.

[farhanhubble]

There's a gut feeling that comes from having gotten your hands dirty enough that tells you if the LLM is being smart or spitting out bullshit.

[code_for_monkey]

I feel like ive been stuck in that cycle, and I know its partially just me being in my head about my career, but I really have been basically doing CRUD apps for a decade. Ive made a lot of front end forms, Ive kept up on the latest frameworks and trends, but at the core it really hasnt been dramatically different.

[theshrike79]

If you really distill it, I've been doing API Glue for about a quarter century.

I connect to a 3rd party API with shitty specs and inconsistent output that doesn't follow even their spec, swear a bit and adjust my estimates[0]. Do some business stuff with it and shove it to another API.

But I've done that now in ... six maybe seven different languages and a few different frameworks on top of that. And because both sides of the API tend to be a bit shit, there's a lot of experience in defensive coding and verification - as well as writing really polite but pointed Corporate Emails that boil down to "it's your shit that's broken, not ours, you fix it".

At this point I really don't care what language I have to use, as long as it isn't Java (which I've heard has come far in the last decade, but old traumas and all that =).

[0] best one yet is the Swedish "standard" for electricity consumption reports, pretty much every field is optional because they couldn't decide and wanted to please every company in on the project. Now write a parser for that please.

[code_for_monkey]

another 'anyone but Java' developer! For me its not even the language or syntax, its the way people code it. Not every line of python ive ever read is gold, but every time i delve into Java code its like the developer was mad, at me specifically.

[nijave]

Reminds me of something I heard at a conference to the effect "10-15 years of <tool> experience is usually a red flag because the only people that have that have been pressing <tool run> button over and over again learning nothing"

[fuzztester]

My dad mentioned the same anecdote to me long ago, except that the context was manufacturing, and the number of years was 20, not 10.

[joquarky]

Experience is knowledge of what not to do.

[theshrike79]

It's the old saying: "$10 for the part, $990 for knowing where to put it"

You get a feel for what works and what doesn't, provided you know the relevant facts. Doing a 10RPS system is completely different than 300RPS. And if the payload is 1kB the problems aren't the same as with the one with a 10MB payload.

And if (when) you're using a cloud environment, which one is cheaper, large data or RPS? It's not always intuitive. We just had our AWS reps do a Tim "The Toolman" Taylor "HUUH?!" when we explained that the way our software works is 95% cheaper to run using S3 as the storage rather than DynamoDB :D

[wseqyrku]

True. I remember myself spending weeks just to figure out what not to do next because I can't afford a redo.

[BadCookie]

Maybe, but the typical person I have worked with in this industry is too smart to do something for 10 years and not learn much during that time.

I am afraid that this “1 year of experience 10 times” mantra gets trotted out to justify ageism more often than not.

[theshrike79]

Depends a lot on the type of software you're doing. Startups will have hungry people willing to learn, more traditional companies won't in the same percentages.

Not all people are curious, they go to school, learn to code and work their job like a normal 9-5 blue collar worker. They go to company trainings, but they don't read Hacker News, don't follow the latest language fads or do personal software projects during nights and weekends. It's just a day job for them that pays for their non-programming hobbies.

I've had colleagues who managed the same ASP+Access DB system for almost a decade, with zero curiosity or interest to learn anything that wasn't absolutely necessary.

We had to drag them to the ASP.NET age, one just wouldn't and stayed back managing the legacy version until all clients had moved to the new stack.

...and I just checked LinkedIn, the non-curious ones are still in the same company, managing the same piece of SaaS as a Software Developer. 20-26 years in the same company, straight from school.

[disgruntledphd2]

> ...and I just checked LinkedIn, the non-curious ones are still in the same company, managing the same piece of SaaS as a Software Developer. 20-26 years in the same company, straight from school.

And honestly, this should be OK. For a lot of people, they work to put food on the table and keep a roof over their head, and our society is structured like this for whatever reasons.

Not everyone needs to be learning and growing all the time. I personally like this, but I've worked with incredibly competent people who just had other interests outside of work, and had no desire to get promoted or work on different things.

Personally, I prefer (often) working with the learning and growing people, but sometimes you can learn a bunch from the stable people as they'll often have lots of hard won lessons caused by staying in the same place for a long time.

[theshrike79]

Some people’s brains are just wired for that.

There are people who are just fine being a cog in a machine doing the same thing all day for years on out.

My family is from a factory town and many of them were literally standing next to a conveyor doing a monotonic task that could’ve done by a robot.

I tried it for one summer job and my brain almost melted from the boredom and monotony.

[abustamam]

I've job hopped a bit. I've gone from junior to senior to lead to mid-level to staff to senior. I have ten years experience.

My career trajectory is wild. At this rate I'll be CTO soon, then back to mid-level.

[Alex_L_Wood]

It also doesn’t help that definition of who “staff engineer” is varies wildly by the company.

[farhanhubble]

Ability is a combination of aptitude, skills, persistence, and exposure. More importantly, intention matters and it show up in the quality of your work. If the intention is to cut corners, no one can stop you from doing shoddy work. Number of years and titles do not matter much if the other parameters are low.

Aptitude paves the way for exploration: learning languages, paradigms, modeling techniques, discovering gotchas and so on. Skills follow from practice and practice requires a tough mindset where you don't give up easily.

So many software engineers learn to code just to pass exams and interviews. They claim they have strong logical reasoning. However, they have only been exposed to ideas and patterns from competitive programming rut. They have never even seen code more complex than a few hundred lines. They haven't seen problems being modeled in different languages. They haven't had the regret of building complex software without enough design. They have not had the disappointment of overengineering solutions. They have never reverse-engineered legacy code. They have never single-stepped in a debugger. All they have learned is to make random changes until "It works on my machine".

Yes, software is complex, disposable, ever-changing and often ugly but that is no excuse for keeping it that way.

[3acctforcom]

Titles in of themselves are meaningless, I've seen a kid hired straight from uni into a "senior" position lol

[SoftTalker]

Title inflation?

[tensor]

IMO 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.

[CodeMage]

What makes this whole thing worse is the concept of "non-terminal" levels, i.e. levels that you're not allowed to stay at indefinitely, which means that you must either get promoted or fired.

I can understand not wanting to let people stay in a junior position forever, but I've seen this taken to a ridiculous extreme, where the ladder starts at a junior level, then goes through intermediate and senior to settle on staff engineer as the first "terminal" position.

Someone should explain to the people who dream up these policies that the Peter Principle is not something we should aim for.

It's even worse when you combine this with age. I'm nearing 47 years old now and have 26 years of professional experience, and I'm not just tired, but exhausted by the relentless push to make me go higher up on the ladder. Let me settle down where I'm at my most competent and let me build shit instead of going to interminable meetings to figure out what we want to build and who should be responsible for it. I'm old enough to remember the time when managers were at least expected to be more useful in that regard.

[lokar]

Yeah, the terminal level, whatever the title (they are just words) need to be the point at which you can handle moderately complex (multi-week) tasks with no supervision.

And honestly, this will depend on the environment and kind of work being done.

[SoftTalker]

If that's what you're looking for you can find it in academia. Universities have no problem paying people to stay around forever without promotion.

Of course the pay won't be great, but the benefits are decent, PTO is usually excellent, and the work environment usually very low stress.

[theshrike79]

I've had calls with Principal Architects who couldn't code themselves out of a wet paper bag.

And according to the company experience chart, they should've been a "thought leader" and "able to instruct senior engineers"

My title? Backend Programmer (20 years of experience). Our unit didn't care about titles because there was a "budget" for title upgrades per business unit and guess which team grabbed all of them =)

[geodel]

Its an epidemic all over in IT departments and s/w industry in general. Nowadays people whose sum total knowledge would be managing some packaged Oracle/SAP software installation are holding title of CTO/SVP/EVP of software organization with thousands of developers.

Since they bring a certain cluelessness and ignorance as honor to whole orgs actual technical expertise among engineers could be detriment to one's jobs and career.

[rglynn]

How many civil engineers or architects know how to put up scaffolding or lay bricks?

That was a little tongue in cheek, but I am genuinely curious what you think the correct approach is? I have seen many teams that do need to have someone overseeing the overall architecture, even if that person isn't writing the code line-by-line.

If you have that capacity baked into "Backend Programmer", then great, but not every team is the same.

Is there something inherently wrong with an "architect" who hasn't written code in a decade but is instructing seniors? One might believe that the answer is self-evident, however, I would argue that the organisational structures we see in the world (functional or otherwise) do not bear this out.

[tguvot]

i am principle architect. last time i wrote code for production was more than 10 years ago. i never touched half of languages that are used in our system

in last week I resolved a few legal/regulatory problems that could have cost company tens of millions of dollars in fines/direct spend/resources and prevented few backend teams from rolling out functionality that could have negative impact on stability/security/performance. I did offer them alternative ways to implement whatever they needed and they accepted it

[xnx]

> IMO tech suffers pretty horrible title inflation

It began with "software engineer"

[jmpeax]

Don't get me started on "software architect".

[tremon]

On classic big waterfall projects, you can find actual architects. Those are the ones drafting interfaces and delineating components/teams before the first source file is even committed.

[9rx]

Even "code monkey" is generous.

[9rx]

> If you reach "senior" after only two years and "principle" after 5, what is left for the next 20 years?

There is nothing left. Not everyone puts in the same dedication towards the craft, of course. It very well might take someone 30 years to reach "principle" (and maybe even never). But 5 years to have "seen it all" is more than reasonable for someone who has a keen interest in what they are doing. It is not like a job dependent on the season, where you only get one each year. In computing, you can see many different scenarios play out in milliseconds. It doesn't need years to go from no experience to having "seen it all".

That is why many in this industry seek management roles as a next step. It opens a new place to find scenarios one has never seen before; to get the start the process all over again.

[Yoric]

Er...

I've been programming since I was 7 and I'm old enough to remember the previous AI summer. Somewhere along the way, I've had impact on a few technologies you have heard of, I've coded at almost all levels from (some very specialized) hardware to Prolog, Idris and Coq/Rocq, with large doses of mainstream languages in-between, and I don't think I'll ever be close to having seen in all.

If anyone tells me that they've seen it all in 5 years, I'm going to suspect them of not paying attention.

[9rx]

The scare quotes are significant. Obviously nobody can ever see it all as taken in its most literal sense. But one can start to see enough that they can recognize the patterns.

If your job is dependent on the weather, one year might be rainy, one year might be drought, one year might be a flood, etc. You need to see them to understand them. But eventually you don't have to need to see the year where it is exceptionally rainy, but not to the point of flood, to be able to make good decisions around it. You can take what you learned in the earlier not-quite-so rainy year and what you learned during the flood year and extrapolate from that what the exceptionally rainy year entails. That is what levels up someone.

Much the same is true in software. For example, once you write a (well-written) automated test in Javascript and perhaps create something in Typescript, you also have a pretty good understanding of what Rocq is trying to do well enough to determine when it would be appropriate for you to use. It would no doubt take much, much longer to understand all of its minutia, but it is not knowledge of intimate details that "senior", "principle", etc. is looking for. It is about being able to draw on past experience to make well-reasoned choices going forward.

[andrewaylett]

Similarly. I have over 20 years of professional experience. I've worked on embedded systems, and with mainframes. I've done (amongst other things) kernel development, compiler (& RTL) development, line-of-business, mobile, server, and web. Code I've written has a MAU on the order of 1% of humanity. Ask me about being a "full stack" developer :).

I've seen a lot. But the more I see, the more I find to see.

[jghn]

The 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]

You 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.

[neighbour]

I'm sympathetic to the title inflation issue but more on the problem of the "engineer" title, not to mention the "scientist" title.

For example, I work in Data & AI and we have:

- data engineer

- analytics engineer

- data scientist

- AI engineer

What I don't know is what's the alternative?

Data Engineers are basically software developers.

Analytics Engineers were Data Analysts or BI Analysts but the job has changed so much that neither of those titles fit.

My opinion is that basically everyone should just be a "Developer" or "Programmer" and then have the area suffixed:

- Data Engineer → Developer (Data Infrastructure)

- Analytics Engineer → Developer (Analytics)

etc.

[Aurornis]

This 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.

[analog31]

Where 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.

[tyrust]

Code 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.

[throwaway314155]

My first job did IRL code reviews with at least two senior devs in the loop. It was both devastating and extremely helpful.

[SoftTalker]

Yeah when we first started, "code review" was a weekly meeting of pretty much the entire dev team (maybe 10 people). Not all commits were reviewed, it was random and the developer would be notified a couple of days in advance that his code was chosen for review so that he could prepare to demo and defend it.

[necovek]

Wow, that's a very arbitrary practice: do you remember roughly when was that?

I was in a team in 2006 where we did the regular, 2-approve-code-reviews-per-change-proposal (along with fully integrated CI/CD, some of it through signed email but not full diffs like Linux patchsets, but only "commands" what branch to merge where).

[SoftTalker]

Around that time frame. We had CI and if you broke the build or tests failed it was your job to drop anything else you were doing and fix it. Nothing reached the review stage unless it could build and pass unit tests.

[marwamc]

This was still practice at $BIG_FINANCE in the couple of years just before covid, although by that point such team reviews were reducing in importance and prominence.

[jopsen]

Doing only IRL code reviews would certainly improve quality in some projects :)

It's probably also fairly expensive to do.

[jghn]

Am old enough that this was status quo for part of my career, and have also been in some groups that did this as a rejection of modern code review techniques.

There are pros & cons to both sides. As you point out it's quite expensive in terms of time to do the in person style. Getting several people together is a big hassle. I've found that the code reviews themselves, and what people get out of them, are wildly different though. In person code reviews have been much more holistic in my experience, sometimes bordering on bigger picture planning. And much better as a learning tool for other people involved. Whereas the diff style online code review tends to be more focused on the immediate concerns.

There's not a right or wrong answer between those tradeoffs, but people need to realize they're not the same thing.

[Ekaros]

I would guess that 3 part code review would actually be most effective. Likely even save on costs. First part is walkthrough on call, next independent review and comments. Then per need an other call over fixes or discussion.

Probably spend more time on it, but would share the understanding and alignment.

[comprev]

Pair programming? That is realtime code review by another human

[stephen_cagle]

And yet... is it? Realtime means real discussion, and opportunity to align ever so slightly on a common standard (which we should write down!), and an opportunity to share tacit knowledge.

It also increases the coverage area of code that each developer is at least somewhat familiar with.

On a side note, I would love if the default was for these code reviews to be recorded. That way 2 years later when I am asked to modify some module that no one has touched in that span, I could at least watch the code review and gleem something about how/why this was architect-ed the way it was.

[lokar]

IMO, a lot of what I think you are getting at should be worked out in design before work starts.

[colinb]

Fagan inspection has entered the room

[ok_dad]

A senior dev should be mentoring and talking to a junior dev about a task well before it hits the review stage. You should discuss each task with them on a high level before assigning it, so they understand the task and its requirements first, then the review is more of a formality because you were involved at each step.

[marwamc]

Also communal RFCs, RFPs, Roadmapping, Architecture/Design Proposals, Design Docs and/or Reviews help socialize/diffuse org standards and expectations.

I found these help ground the mentorship and discussions between junior-senior devs. And so even for the enterprising aka proactive junior devs who might start working on something in advance of plans/roadmaps, by the time they present that work for review, if the work followed org architectural and design patterns, the review and acceptance process flows smoothly.

In my juinior days I was taught: if the org doesn't have a design or architectural SOP for the thing you're doing, find a couple of respectable RFCs from the internet, pick the three you like, and implement one. It's so much easier to stand on the shoulders of giants than to try and be the giant yourself.

[groby_b]

I think we've moved on from the times where you brought a printout to the change control board to talk it through.

[SoftTalker]

But are we better off?

[stuaxo]

Git PRs work on async model for reviews.

[DrewADesign]

And 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.

[rootusrootus]

As someone else mentioned, the process is async. But I achieve a similar effect by requiring my team to review their own PRs before they expect a senior developer to review them and approve for merging.

That solves some of the problem with people thinking it's okay to fire off a huge AI slop PR and make it the reviewer's responsibility to see how much the LLM hallucinated. No, you have to look at yourself first, because it's YOUR code no matter what tool you used to help write it.

[muzzio]

Reviewing your own PR is underrated. I do this with most of my meaningful PRs, where I usually give a summary of what/why I'm doing things in the description field, and then reread my code and call out anything I'm unsure of, or explain why something is weird, or alternatives I considered, or anything that I would catch reviewing someone else's PR.

It makes it doubly annoying though whenever I go digging in `git blame` to find a commit with a terrible title, no description and an "LGTM" approval though.

[unbalancedevh]

> requiring my team to review their own PRs before they expect a senior developer to review them

I'm having a hard time imagining the alternative. Do junior developers not take any pride in their work? I want to be sure my code works before I submit it for review. It's embarrassing to me if it fails basic requirements. And as a reviewer, what I want to see more than anything is how the developer assessed that their code works. I don't want to dig into the code unless I need to -- show me the validation and results, and convince me why I should approve it.

I've seen plenty of examples of developers who don't know how to effectively validate their work, or document the validation. But that's different than no validation effort at all.

[rootusrootus]

> Do junior developers not take any pride in their work?

Yes. I have lost count of the number of PRs that have come to me where the developer added random blank lines and deleted others from code that was not even in the file they were supposed to be working in.

I'm with you -- I review my own PRs just to make sure I didn't inadvertently include something that would make me look sloppy. I smoke test it, I write comments explaining the rationale, etc. But one of my core personality traits (mostly causing me pain, but useful in this instance) is how much I loathe being wrong, especially for silly reasons. Some people are very comfortable with just throwing stuff at the wall to see if it'll stick.

[alfons_foobar]

> added random blank lines and deleted others from code that was not even in the file they were supposed to be working in.

Maybe some kind of auto-formatter?

[rootusrootus]

That is my charitable interpretation, but it's always one or two changes across a module that has hundreds, maybe thousands of lines of code. I'd expect an auto-formatter to be more obvious.

In any case, just looking over your own PR briefly before submitting it catches these quickly. The lack of attention to detail is the part I find more frustrating than the actual unnecessary format changes.

[ok_dad]

> Yes. I have lost count of the number of PRs that have come to me where the developer added random blank lines and deleted others from code that was not even in the file they were supposed to be working in.

That’s not a great example of lack of care, of you use code formatters then this can happen very easily and be overlooked in a big change. It’s also really low stakes, I’m frankly concerned that you care so much about this that you’d label a dev careless over it. I’d label someone careless who didn’t test every branch of their code and left a nil pointer error or something, but missing formatter changes seems like a very human mistake for someone who was still careful about the actual code they wrote.

[hoten]

I think the point is that a necessary part of being careful is reviewing the diff yourself end-to-end right before sending it out for review. That catches mistakes like these.

[jjmarr]

Many are just doing SWE for the money.

Their goal is to pass the hot potato to someone else, so they can say in the standup "oh I'm waiting on review" making it not their problem.

[epiccoleman]

> I want to be sure my code works before I submit it for review.

No kidding. I mean, "it works" is table stakes, to the point I can't even imagine going to review without having tested things locally at least to be confident in my changes. The self-review for me is to force me to digest my whole patch and make sure I haven't left a bunch of TODO comments or sloppy POC code in the branch. I'd be embarrassed to get caught leaving commented code in my branch - I'd be mortified if somehow I submitted a PR that just straight up didn't work.

[lokar]

It’s cultural. It always seemed natural to me, until I joined a team that treated review as some compliance checkbox that had nothing to do with the real work.

Things like real review as an important part of the work requires a culture that values it.

[tqian]

Oh junior devs submit PRs that don't fully work all the time.

[theshrike79]

We have an AI doing the first pass PR review using company standards as a prompt.

It catches the worst slop in the first pass easily, as well as typos etc.

[hnthrow0287345]

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

[marcosdumay]

A full-time code reviewer will quickly lose touch with all practical matters and steer the codebase into some unmaintainable mess.

This is not the first time somebody had that idea.

[JohnBooty]

I've often thought this could work if the code reviewer was full-time, but rotated regularly. Just like a lot of jobs do with on-call weeks, or weeks spent as release manager - like if you have 10 engineers, and once every ten weeks it's your turn to be on call.

That would definitely solve the "code reviewer loses touch with reality" issue.

Whether it would be a net reduction in disruption, I don't know.

[necovek]

Doing code review as described (actually diving deep, testing etc) for 10 engineers producing code is likely not going to be feasible unless they are really slow.

In general, back in 2000s, a team I was on employed a simple rule to ensure reviews happen in a timely manner: once you ask for a review, you have an obligation to do 2 reviews (as we required 2 approvals on every change).

The biggest problem was when there wasn't stuff to review, so you carried "debt" over, and some never repaid it. But with a team of 15-30 people, it worked surprisingly well: no interrupts, quick response times.

It did require writing good change descriptions along with testing instructions. We also introduced diff size limits to encourage iterative development and small context when reviewing (as obviously not all 15-30 people had same deep knowledge of all the areas).

[bee_rider]

You could do some interesting layering strategies if you made it half time, for two people. Or maybe some staggered approach: each person does half time, full time, then half time again, with there people going through the sequence at a time. Make each commit require two sign-offs, and you could get a lot of review and maybe even induce some cooperation…

[kaffekaka]

"Interesting" is the word I would use as well, but also cumbersome and complicated.

[jaggederest]

I think it's amenable if you make code review a primary responsibility, but not the only responsibility. I think this is a big thing at staff+ levels, doing more than your share of code review (and other high level concerns, of course).

[kragen]

Linus Torvalds is effectively a full-time code reviewer, and so are most of his "lieutenants". It's not a new idea, as you say, but it works very well.

[sorokod]

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

Can 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.

[postflopclarity]

I do this all the time. I pass my code into "you are a skeptic and hate all the code my student produces: here is their latest PR etc.. etc.."

[osn9363739]

I have devs that do this and we have CI AI code review. Problem is, it always finds something. So the devs that have been in the code base for a while know what to ignore, the new devs get bogged down by research. It's a net benefit as it forces them to learn, which they should be doing. It def slows them down though which goes against some of what I see about the productivity boost claims. A human reviewer with the codebase experience is still needed.

[mywittyname]

Slowing down new developers by forcing them to understand the product and context better is a good thing.

I do agree that the tool we use (code rabbit) is a little too nitpicky, but it's right way more than it's wrong.

[bee_rider]

I don’t use any of these sorts of tools, so sorry for the naive questions…

What sort of thing does it find? Bad smells (possibly known imperfections but least-bad-picks), bugs (maybe triaged), or violations of the coding guides (maybe known and waivered)?

I wonder if there’s a need for something like a RAG of known issues…

[jjmarr]

We do this at work and it's amazing.

[cm2012]

This would probably catch a lot of errors

[immibis]

As I read once: all that little stuff that feels like it stops you from doing your job is your job.

[gottagocode]

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

This is effectively my role (outside of mentoring) as a lead developer over a team of juniors we train in house. I'm not sure many engineers would enjoy a day of only reviewing, me included.

[jms703]

>One of the annoying things engineers have to deal with is stopping whatever they're doing and doing a review

Code reviews are a part of the job. Even at the junior level, an engineer should be able to figure out a reasonable time to take a break and shift efforts for a bit to handle things like code reviews.

[mywittyname]

This sounds good in theory, but in practice, a person capable of doing a good job at this role would also be a good developer whose impact would be greater if they were churning out code. This is a combination of a lead engineer and SDET.

In reality, this ends up being the job given to the weakest person on the team to keep them occupied. And it gives the rest of the team a mechanism to get away with shoddy work and not face repercussions.

Maybe I'm just jaded, but I think this approach would have horrible results.

AI code review tools are already good. That makes for a good first pass. On my team, fixing Code Rabbit's issues, or having a good reason not to is always step 1 to a PR. It catches a lot of really subtle bugs.

[shiandow]

The best way I have of knowing code is correct on all levels is convincing myself I would write it the same way.

Thr only way to be 100% sure is writing it myself. If I know some one reasonable managed to write the code I can usually take some shortcuts and only look at the code style, common gotchas etc.

Of course it wouldn't be the first time I made some erroneous assumptions about how well considered the code was. But if none of the code is the product of any intelligent thought well, I might as well stop reading and start writing. Reading code is 10x harder than writing it after all.

[necovek]

With time and experience, reading code becomes much easier.

And well-written code is usually easy to read and understand too!

The purpose of a code review is, apart from ensuring correctness, to ensure that the code that gets merged is easy to understand! And to be honest, if it's easy to understand, it's easy to ensure correctness too!

The biggest challenge I had was to distinguish between explanations needed to understand the change, and explanations needed to understand the code after it was merged in. And making it clear in my code review questions that whatever question I have, I need code and comments in the code to answer them, not the author to explain it to me (I frequently have already figured out the why, but took me longer than needed): it's not because I did not get it, it's because it should be clearer (finding the right balance between asking explicitly, offering a suggestion, or pitting it as a question to prompt some thinking is non-trivial too).

[Spoom]

Big companies would outsource this position within a year, I guarantee it. It's highly measurable which means it can be "optimized".

[nunez]

This sounds like what unit tests after every commit and e2e tests before every PR are supposed to solve.

[ohwaitnvm]

So pair programming?

[sodapopcan]

Yep, eliminates code reviews altogether. Unfortunately it remains wisely unpopular with perle even saying “AI” can be the pair.

[gaigalas]

It does not eliminate code reviews.

In practice, you should have at least one independent reviewer who did not actively worked on the PR.

That reviewer should also download the entire code, run it, make tests fail and so on.

In my experience, it's also good that this is not a fixed role "the reviewer", and a responsability everyone in the team shares (your next task should always be: review someone else's work, only pick a new thing to do if there is nothing to review).

This practice increases quality dramatically.

[sodapopcan]

> It does not eliminate code reviews.

Yes it does. There are many ways to do things, of course, and you can institute that there must be an independent reviewer, but I see this is a colossal waste of time and takes away one of the many benefits of pairing. Switch pairs frequently, and by frequently I really mean "daily," and there is no need for review. This also covers "no fixed responsibilities" you mentioned (which I absolutely agree with).

Again, there are no rules for how things must be done, but this is my experience of three straight years working this way and it was highly effective.

[gaigalas]

Mixed-level pairs (senior/junior), for example, are more about mentoring than reviewing. Those sessions do not qualify for "more than one pair of eyes".

Excited (or maybe even stubborn) developers can often win their pairs by exhaustion, leading to "whatever you want" low effort contributions.

Pairs tend to under-document. They share an understanding they developed during the pairing session and forget to add important information or details to the PR or documentation channels.

I'm glad it has been working for you. Maybe you work in a stellar team that doesn't have those issues. However, there are many scenarios that benefit a lot from an independent reviewer.

[necovek]

Pairing people together on a single task makes that task get done faster, with higher quality. However, when paired together, the people still pick up some of the same biases and hold the same assumptions and context, so it is really worse than having a single author + independent reviewer.

So:

  single author, no review < pair programming, no review < single author + review < pair programming + review

[aslakhellesoy]

Shhh don’t let them know!

[duxup]

It’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).

[reedf1]

it's even worse than that! non-devs are doing it as well

[esafak]

That's what democratization looks like. And the new participants are happy!

[rvz]

…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)

[snowstormsun]

it's even worse than that! bots are doing it as well

[marcosdumay]

Abandon any platform that decides to put bots into your workflow without you telling it to.

Vote with your wallet.

[pydry]

Hopefully 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.

[rootusrootus]

One 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]

Yeah, 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]

My 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.

[tyleo]

There’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.

[throwawaysleep]

Code 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]

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

My 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]

That'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]

Yep, 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.

[necovek]

It can be your problem if the company goes under and you lose your job: you might not be able to pay your mortgage or bills.

If you believe your manager is asking for unreasonable things in what you are an expert in despite you raising these concerns, and it's not clear their manager is in on it, please raise it to their manager!

"I am willing to continue working this way, but I just want to make sure the consequences it could have on the business are clear to everyone here."

[tunesmith]

As 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]

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

2 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.

[TexanFeller]

Even 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.

[acedTrex]

Juniors 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.

[strangattractor]

Not at Meta - their job is to "Move fast and break things". I think people are just doing what they've been told.

[bee_rider]

“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.

[coldtea]

It'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)

[hinkley]

There’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.

[lowkeyokay]

In 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.

[Our_Benefactors]

This 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]

This 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]

I would accept this because it'll increase demand for SWEs and prevent us from losing our jobs.

[necovek]

Obviously, unleash LLM code reviewer with the strictest possible prompt on the change :)

Then innocently say "LLM believes this is bad architecture and should be recreated from scratch."

[lurking_swe]

sounds 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.

[theshrike79]

"You can't polish a turd" =)

[627467]

Just shove a code review agent in the middle. Problem solved

[Edit] man, people dont get /s unless its explicit

[fragmede]

That 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]

Is this startup sitting on any IP other than a bunch of prompts?

[seanmcdirmid]

Don’t accept PRs without test coverage? I mean, LLMs can do those also, but it’s something.

[mullingitover]

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

That 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]

> Your team is being sloppy.

I'm talking about a running joke in the industry, not my team.

[giancarlostoro]

I 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.

[vrighter]

and non-devs as well, nowadays

[BurningFrog]

Really good code reviewing AIs could handle this!

[alphazard]

Quality 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]

Because 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.

[phito]

I find doing my job as best as I can intrinsically rewarding. Even tho I am getting paid peanuts and have to give more than half of those peanuts to my government. I'm that kind of sucker.

[hostyle]

Not 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]

But why do that for the company instead of yourself?

[alphazard]

This 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.

[necovek]

By investing in quality on your job, your job will be easier and take less time. In software, you won't be called in to resolve that incident over the Thanksgiving weekend, and you won't be asked to debug why your system broke after someone committed 10k line diff without any review and without tests.

Be selfish! But be smart! On top of getting the best result for you, this gets the best result for the business too! And businesses know it, and even if they don't reward it proportionally, they do reward it with bonuses and seniority promotions.

[hostyle]

Most people spend maybe 1/4 of their working age life at a job working for someone else. Why would you deliberately sabotage that by checking out mentally and waste all that time on sub-standard work? How do you expect to earn a promotion? You can produce good code at work and even better code at home for yourself. Deliberately producing slop at work will not help anyone.

[ThrowawayR2]

Speaking only for my particular circumstances, the company is the vehicle that I use to do it for myself since it provides specialized facilities and equipment I wouldn't have access to as an individual or a founder. That I get paid for it is merely icing on the cake.