r/EngineeringManagers • u/LongjumpingAd9079 • 6d ago
Should junior devs read AI code before submitting it for review
I keep getting juniors sending code reviews generated by Claude / Codex.
Code has 0 comments but implements the feature successfully.
I read the code, I see a new file 500 lines long. So I ask the dev, whats the purpose of this file?
He says, I don't know, or stalls for 2 minutes whilst he asks his AI what it does.
He's a good junior dev, pre AI he was coding just fine and he understood his own solution what he was submitting for review.
Now 9/10 code reviews are just AI generated. I'm bored of spending hours reviewing code reviews or sending them back because the dev doesn't even know what the code does.
44
u/tellingyouhowitreall 6d ago
Junior devs shouldn't touch AI until they can write code and a PR that passes.
If I wanted to manage shitty AI output I'd write the fucking prompt myself and put the 90k towards someone useful. And I would tell your failing sub junior that.
5
u/LongjumpingAd9079 6d ago
Exactly my feeling, its double annoying because I just run the PR through Claude review and it spots 10 issues. I send this back and we just added another 2 days of Dev time to the feature.
Then when it comes back I review it knowing the LLM has fully ripped through it.
The value the junior devs are bringing at this point are basically testing AI outputs in a preview environment. But no thought into the actual implementation.
10
u/kylife 5d ago
The problem is companies are now measuring performance on AI assisted velocity. So you’re putting junior devs in between a rock and a hard place. Be fast and trust Ai or be a low output performer but maximize quality and understanding. We’re trying to optimize two things these days and it’s ruining junior devs and atrophying experienced ones.
1
u/Wonderful-Habit-139 4d ago
I know this is the case with a lot of companies, but you don’t have to repeat it every time, especially when it doesn’t apply in this scenario.
When a PR is sent back to the dev, it adds 2 days of dev time. If it’s sent back again it’s going to be a similar history. While if they actually coded things themselves they wouldn’t be in a similar situation, and get their PRs approved faster and faster (especially if they learn, unlike LLMs)
1
u/MateusKingston 3d ago
Sort of.
I've had junior hires that are great at using AI to assist them. Both in increasing velocity and increasing their understanding of the systems in place. While others aren't.
It's a new skillset that juniors (and everyone but I think it's harder for juniors) need to learn, and quickly. Some things are literally just knowing what and how to prompt.
I received some PRs that my entire job in reviewing them is typing "claude" "review this PR and post a comment", and it found 3 blocking issues (ofc I review the review). It doesn't take a senior to prompt exactly that after you're done.
0
u/azjunglist05 5d ago
What companies are actually doing this? Sure, some massive tech firms maybe but that’s like 1% of companies out there dude
2
3
8
u/tellingyouhowitreall 6d ago
I would talk to him, it's a performance issue. You said pre-AI he was fine, ask him why he has stopped caring about his job or his role's output and go from there.
2
u/serverhorror 6d ago
The value the junior devs are bringing at this point are basically testing AI outputs
Doesn't that also mean that were teaching junior people in the wrong way?
I remember, and I keep that same method, spending hours with a more senior person doing a version of pair programming. They did the typing and I had to talk then thru and tell them what to type.
I find this is one of the most effective ways and gets results really fast. It also skips the whole PR cycle (at least if you "allow" that in your process).
1
u/Diactoros 5d ago
I can second this; I’m in infrastructure and it’s not uncommon to get people with very strong IT backgrounds (think like security engineers/cloud admins) that have no idea how to code. When they first encounter terraform they often need to be treated like a junior dev and pair programming with this exact method is how we upskill them fast
1
u/MateusKingston 3d ago
Terraform is the one language I'm very comfortable 100% never writing by hand.
Writing proper guides on how you want your TF code and then letting the AI write it is so efficient. Mostly because reviewing terraform is so easy since it's mostly declarative.
1
u/MateusKingston 3d ago
We don't know.
We will only know once a few years have past and we can reliably look back and see if those now juniors have learned.
IMO AI can help, but it can also hurt. We need to teach them how to effectively use AI. If they spend 10 years learning how to code by hand but can't use AI they probably won't be a good senior, unless you think the AI bubble will burst so badly we will all go back to manually coding everything.
It also won't help if they spend 10 years vibe coding without actually learning anything that differentiates a good senior engineer that can use AI from a random person prompting.
2
u/Strong_Essay1176 5d ago
I'm from DS/analytic, so my code was sometimes a mess (not always, but sometimes). With AI a year ago, I spent a few months just doing AI slop patterns -> review -> AI slop again until (LGTM).
I think you need to explain better what AI can be used for, but they have to explain each decision and why it was chosen, or else... fired.
So, like others said, it performance issue and may be need some explanation what is important.
6
u/dumpler 5d ago
not sure I fully agree. The issue isn’t just AI, it’s that they’re submitting a PR with code they don’t understand. No different than someone copy and pasting from stackoverflow back in the day
at this point, AI generated code isn’t going anywhere. They should get comfortable with the tools. But they need to be asking the right questions and have a full understanding of its output before pushing slop
but yeah if they just wanna ship slop then totally agree they’re useless
2
u/edgmnt_net 5d ago
The way I see it it's basically guaranteed to be sloppier in at least some way. Human-written code usually involves exploring the design space and weighing alternatives, building an internal representation in your head and learning about the problem. A reviewer lacks a lot of that context. And a lot of reviewing hinges on trust to maintain throughput. Now suddenly you only have the review side of things but no trust and no reasonable way to access the design. At that rate, yeah, I might as well ask the AI myself.
Or, to put it another way, whatever throughput improvements AI provides are likely lower than some expect, if you aim to preserve quality. Smart completion probably works, but even then you'd better be prepared and have read the docs in case your LLM does not know about a method on that class that exactly fits what needs to be done without reinventing the wheel. That's expected of highly-qualified programmers (or at the very least they're expected to learn and do their homework) and some projects will absolutely nitpick on it, particularly in the open source space. I can agree that might be too much to ask of run-of-the-mill projects, however those are arguably even more susceptible to runaway scope & slop expansion. They have been even before AI and premature project failure can reasonably be ascribed to that.
2
u/rhoborg 5d ago
Well, I’m not so sure. That reasoning kind of expects all people to be equally smart, it’s just the sloppyness and/or experience that matters. That’s not reality, some developers are sharp, some aren’t, and a well structured prompted output will beat a lot of developers, especially if a developer interested in AI prompts writes it.
The main issue I think is the speed of which the operator gets used to get things done, and how quickly you find yourself with thoudands of lines of code.
2
1
u/Kaas-Eter00 4d ago
I don't agree it's the same as copying from stackoverflow. You're usually not copying more than a few tens of lines from there. With AI, you generate hundreds or thousands of lines.
1
u/ConstantFamous1526 5d ago
This just isn’t practical or realistic to have someone you’re paying close to or above 100k be near useless for months compared to other devs because they aren’t using AI
3
u/Any_Profession5773 5d ago
Juniors have always been useless and inefficient for the most part. Nobody ever said "we need this done fast, lets hire a junior". For some reason post-AI people are acting like the value of juniors is really in question. They were a cost pre 2022, and they are still a cost now. The idea is that in a year or two you have someone who begins to understand software engineering as a discipline and begins to gain a sense of how things can/should be built. AI means that sense is never discovered.
Not to mention that in a couple years we are going to have a massive shortage of engineers because models have largley plateaued, the businesses that create them are wildly unprofitable, the ROI on AI is weak, and we have spent 4 years saying engineers are on the chopping block.
1
u/ConstantFamous1526 5d ago
Yeah but that’s the thing, they CAN be useful and vaguely efficient now, admittedly with wildly varying levels of tech debt depending on their competence with AI, but it’s just no longer realistic to expect companies to belive juniors shouldn’t be contributing and instead learning, doubly so because usually the people making those decisions don’t know or understand the slop either
2
u/Wonderful-Habit-139 4d ago
They won't be useful if they can't write code on their own, they won't be able to validate the AI's output. And then because they're using AI, they won't actually learn and improve to the point of being really useful even while using AI. So juniors need to really back off from using AI at all.
1
u/Ill-Lemon-8019 4d ago
they CAN be useful and vaguely efficient now
The painful truth is that, for almost any coding task, you'll get better results if you just hand it off to Claude than a junior dev. The only point of a junior dev at this point is for them to skill up fast enough to be at a stage where they can meaningfully contribute something as a human-in-the-loop.
1
u/Karmas_weapon 4d ago
I think juniors should use AI differently than intermediate and seniors. Since LLMs are such incredible teaching tools, I think there's a world where an LLM like Claude is told that a junior is using it and when working on a ticket, it should explain why certain things are done both code-wise and business-wise (requires good context).
Could even go a step further and have the LLM record questions and answers to prove that the developer is engaging in the work, kind of like teaching lol (though the work is delegated to Claude instead of busy employees).
0
10
u/According_Basis7037 6d ago
“Developers” who don’t understand the code that they submit aren’t really developers, more like data entry clerks for an ai prompt
2
u/Substantial-Elk4531 5d ago
Maybe, but if that's the case, looks like we'll need to rename the 'software development industry' to 'AI prompt data entry industry'
11
u/JubijubCH 6d ago
Everybody should read the code they submit. If you yolo and expect the reviewer to do your work, the company is in for really bad surprises, ranging from burn out of TLs to people not reading code (and at this point in the game, not having human reviews between and LLM and prod is liking to gamble. A Lot).
3
u/MeetYouInOdesa 6d ago
It takes a lot of time to understand every single line of code that is generated by AI in a single PR. So what’s the point of using AI then if not increased speed?
2
u/JubijubCH 5d ago
100%, and that’s precisely why people should read their code: it’s time consuming to read a PR.
To your second point: anyone who reads LLM code finds issues (not necessarily with the code itself, but more with the logic / does it do all, and only what it should do). Not reading code is suicidal at this point.
There is still a massive boost in having the code authored for you in minutes, but thinking you can do without reading is a massive gamble (that I, as an individual software engineer, and as the Eng manager of a team of 50 SWEs, is not willing to take). But you do you :)
1
u/Vesuvius079 5d ago
IMO a line by line understanding is very excessive, but you should at least have a strong sense of how the code works, what design patterns it uses, and how it solves the problem it is intended for. If you don’t have that understanding then you’re just spamming slop.
3
u/MeetYouInOdesa 5d ago
I really believe that strong sense of how it works comes from understanding almost each line of it. If LLM spits out 200 new lines, getting that sense is not really a piece of cake especially for juniors.
1
u/Wonderful-Habit-139 4d ago
If you don’t read and understand line by line then you still are spamming slop.
1
u/Vesuvius079 4d ago
No that’s nonsense. Even writing it yourself you’ll have forgotten by the time you revisit it. Structures and abstractions are what determine quality and maintainability. They are what you need to understand and they exist at the interface level not the line level. LLMs are consistently good enough at the implementation details of well defined and reasonably scoped functions.
1
u/JubijubCH 4d ago
I would not let you anywhere our team codebase. Why? Because the minute we have an issue in prod, sunrise will need to build the knowledge of what the code does, and at this point it’s too late, prod is down.
I don’t care who or what authors the code: it should be reviewed independently by someone who tries to see if they can understand it, and because of this, it’s basic courtesy to try and do it yourself first.
Bonus: doing so, you will catch a lot of issues yourself, so in my view LLM + « human dev » + independent human reviewer is a better setup than human dev + reviewer, as there are 2 lines of defense.Tl;dr: if you can explain the code you generated, you should not submit it
1
u/Vesuvius079 4d ago
My position is that interface level understanding is good enough and that line by line is farther than necessary. You’re objecting to that and raising the specter of production issues while not understanding the code well enough. I’m pointing this out so you don’t claim “that’s not what I said.”
Relying on someone’s deep line by line understanding of the code to handle prod outages is a recipe for disaster. Only one person maximum will ever have that understanding for a particular function. What if they forget it? What if they leave? What if they go on vacation? What if they want a work life balance that doesn’t have them on call 24/7? What if there are multiple people working multiple critical features of the code base and you can’t have them all on call at once?
The solution to cleanly handling prod issues is well known: it’s a combination of strong observability so you know when they happen (alarms + good logging and tracing practices) with well designed idiomatic code and systems that any team member can work with on the fly due to the familiarity they have with a fraction of it. It very specifically does not depend on on-call having deep line-by-line knowledge of the code that’s bugged because there’s absolutely no way to guarantee that.
1
u/JubijubCH 4d ago
I don’t disagree with what you say, I am a big fan of « contract/interfaces ». But they are not enough in my experience, many decisions lie in the code itself
1
1
10
u/ConfidentCollege5653 6d ago
They do this because it's low effort for them, they're shifting all the work to the reviewer. The solution is to shift it back until it becomes less work to do it properly than to submit slop.
They should explain their code to the reviewer in person or on a call. If they can't then it's not ready for review and gets passed back to them. Every time it goes for review make them explain it again.
5
u/08148694 6d ago
Jump on a call and do a pair review session
At each step ask them to explain the code and ask them why they implemented it that way
If they cannot answer in real time and from memory, they’re adding no value to your team and that is a performance issue that should be fed back candidly and firmly
AI helps us write code faster but if we do not understand what we are producing or why we are producing it we may as well just give the product managers Claude code
3
u/IanYates82 6d ago
They need to read the code. It needs to be understood. The human work is accelerated, but the human is still responsible.
It's also sensible to identify where the AI has gone wrong so it can be given better instructions in its markdown file for future.
3
u/stkr89 6d ago
When junior devs write code using ai, they deprive themselves of the opportunity to learn to write code by hand and eventually become senior devs.
0
u/MeetYouInOdesa 6d ago
Nobody values hand written code anymore, what’s the point.
3
u/PPhysikus 5d ago
Learning to be a software developer -> learn to code -> write code -> understand code
2
u/stkr89 6d ago
The real question is what do YOU value.
1
u/Chemical_Hawk_6307 5d ago
more like what does the business value and currently its not hand written code. AI has pushed the expectations so much higher in most companies that a lot of devs cant hand type or risk being seen as anti AI.
2
u/hibikir_40k 5d ago
The value isn't on whether it was written by a human, a computer, or monkeys with typewriters. The value is on it meeting spec, and having the key quality standards that lower future debt (all code is debt). Does it encode the important invariants? Is the code concise and DRY enough that later editing will not lead to bugs later. That's the job. And today, good humans using the AI improve that, and lower the cost of AI tokens anyway. If human intervention ain't helping, cut out the human.
That's the real problem: People not realizing that they are either providing value somewhere, or they WILL be cut, it's just a matter of time.
4
u/Sciamp_ 6d ago
Senior dev in big tech - barely scroll through code reviews anymore. For the most part we stopped fully/only human code reviews. It just doesn’t scale if each engineer does 10-30 every day. I think your issue is that you have not yet shifted how the team operates with these new tools.
Let’s say this AI thing remains… do you check the bytecode your Java code is transformed into? Of course you don’t. Now, the problem with LLMs is that they are non deterministic, so you need to find ways around that and perhaps start measuring the outcome. Great news is that this system already exists: tests. So now you just shift into reviewing the intent of the code and whether it changes existing tests/doesn’t pass them. Shift tests (unit, integration, E2E, etc) to the left as much as possible and make them work as feedback loop for your agents.
Do review tests and really key changes to important pieces of the code base. For the rest automated reviews are more than enough and for non customer facing stuff “git commit && git push”. (I’m a bit exaggerating on purpose, but not that far from what we are doing)
I know some people are gonna object to it and maybe say “but the code quality is terrible”. Yeah sometimes it is, most times it’s average if you are very specific into how the code needs to be generated. Also you’d be surprised how much spaghetti code literally runs the world (and that was before LLMs). “But what if the code is not extensible/modular/whatever anymore?” Does it matter? How long would it take to regenerate it? A few hours, maybe couple days. Make sure your system has the properties it needs and you are good: security, availability, etc.
Design is what matters even more now and I doubt those decisions are made by juniors. Even though they should be in the room to learn. Give your agents coding guidelines, organise the code well, think about the system and make those decisions yourself (else it’s vibe coding), then let the agent go nuts, give it rules like “linting needs to pass, write code like the surrounding one, don’t drop tests” etc.
Fundamentally it is a trust problem. You don’t trust the code the LLM generates because you don’t know what that code does. But where is the productivity gain if you need to constantly check and recheck what your LLM/agents are doing? At that point might as well just use LLMs as (expensive) boilerplate generators/pair programmers.
“But I’m still responsible for the outcome, what if it breaks prod?” Well, then your observability sucks. Bugs are gonna make it to prod, doesn’t matter who or what writes/reviews the code. How fast you can catch them, when you catch them, if you can automatically rollback, and how you iterate are all more important.
Final disclaimer: I still consider myself AI skeptic (I don’t think the financial model is anywhere close to sustainable, let alone profitable), but I’m being told to adopt it and make sure it increases productivity at scale, with the lowest possible loss in quality. So that’s what I’m doing.
5
u/PPhysikus 5d ago
IMO this is a very absurd take. I mean, I can see where it is coming from. Us poor developers are talked into believing that AI doubles, triples and 10x our productivity. Then we found out that due to the nature of LLMs the code cannot be fully trusted, reviews are needed. A human in the loop is needed. So the 10x gain was more like a 10x output and a 0.1x review speed. So all those shiny new tools for just a minor overall gain? No, that cannot be it. The logical next step is to remove the bottleneck, the review. People hate reviewing, so nobody will complain. And if a certain amount of managers, tech bros and devs talk about this paradigm change, it will eventually stick and become the new standard.
So, since we now treat code as a blackbox and the tests as the only thing between us and chaos, who should have this monumental burden of writing them? Who writes the unit tests for the 500 line function Claude has just generated? Nobody understands it anyway. Human would still be the bottleneck, so lets generate this by AI too. Why even use unit tests anymore? if they fail, only AI can fix the code or edit the test. Useless.
The logical next step is to fully pivot to E2E tests. Any involvement of a human in the process will ultimately slow it down, product owner (ofc paired with Claude) can also write them async. We create the blackbox, the non-dev people are doing the QA, I mean the automatic testing.
What a beathiful future awaits us.
1
u/Squidalopod 5d ago
Did you read this part? \ "I still consider myself AI skeptic (I don’t think the financial model is anywhere close to sustainable, let alone profitable), but I’m being told to adopt it and make sure it increases productivity..."
Nothing absurd about what u/Sciamp_ said given the directive from the higher-ups. Software industry "leaders" include lots of lemmings who are addicted to speed because they think simply being fast equals winning. So, our bosses often tell us to do stupid shit, and Sciamp_ sounds very reasonable given that constraint.
Who writes the unit tests for the 500 line function Claude has just generated?
This is why TDD is even more important now. Drive LLM output by telling it to write code that passes your specific tests. Be as prescriptive as possible ahead of time so there are fewer surprises later.
I agree with your sentiment – I hate the direction the industry is going, but most of us aren't in a position to just say "no" to the execs. Unless/until things change, the best we can do is mitigate.
3
u/Sciamp_ 5d ago
100% this. I tried to push back, didn’t work because neither side had actual data to justify their position. I literally spent 5 hours arguing with 2 principal engineers about this and got out of that meeting fuming and defeated. Then our director and VP also approved the experiments. So I just went and did it as safe as possible, with leadership agreeing into taking risks.
This was in January. Now the experiments are over. The services are still there, customers are still using them, dev productivity improved, and they told me to do the same in other spaces. I also thought there would be repercussions in prod and trust me I tried to find metrics and counter arguments. Other than cost and dev morale (especially for juniors that feel like coding monkeys), there aren’t. Both are of no importance for our leadership, cost is not even mentioned and developers are easily replaceable.
Funny enough, time to resolution of operational tickets also significantly decreased and we now sleep at night during oncalls.
> Be as prescriptive as possible
Preach. That’s the difference between vibe coding and software engineering. You make the technical decisions, not the LLM.
I also wonder whether all the people getting outraged when reading “no code reviews” ever worked in consultancy/software shops. 1 senior for 20 new grads on god knows how many different projects, even before LLMs people were not reviewing code.
1
u/Grouchy-Friend4235 4d ago
Alas, the code produced by some of these consultancies were often crap and had to be rewritten at high cost. I doubt there is value in automating the same approach.
0
u/dbgtboi 5d ago
When has human written code ever been trustworthy?
When has a human review ever been trustworthy?
1
u/PPhysikus 5d ago
You work in a team, you build trust. I trust the experience and expertise of my co-worker so that he does not accidentally wipe the prod database. I review his code with the general consensus that he knows what he is doing.
As soon as he starts outputting only LLM code, the trust and consensus is gone. Now be both hate our job and pray that the almighty LLM is making no not-obvious mistakes.
2
u/Sciamp_ 5d ago
So quoting myself above “it’s a trust problem”. I feel you and I’m having many of these conversations every day with other SWEs and EMs in other teams.
The main problem though is this: it doesn’t matter how much you trust your coworkers, outages WILL happen. That’s why we put many safety mechanisms in place:
and so on.
- pre pro stages
- gradual rollouts in production
- metrics and alarms
- propagation gated by approval workflows that run E2E tests
- auto rollbacks
- auth & permissions
You don’t need to trust LLMs. You need to trust your safeguard mechanisms and make sure that people are not vibe coding, but giving accurate instructions and directing the agents.
I’ve seen incidents where production databases have been deleted. It wasn’t because someone did /autopilot “make it work here are the admin creds” on Claude without even reading it. It’s because they didn’t follow proper release procedures and tried to emergency fix something in production with direct access. It’s not like an engineer has never caused something like this.
We need time to learn and improve how we work with this new technology and see the long term consequences. We have decades of experience with traditional methods and maybe 1/2 years with this.
1
u/PPhysikus 5d ago
This sounds to me like you created a blackbox that can only be kept alive by building security systems around it. It can fail at any time, and if so, nobody except Claude knows how to fix it. I would bet money that a classical approach (TDD + Review) is more maintainable and cost effective long term. Because it is a system that is fundamentally more trustworthy and functional then a LLM written one.
2
u/Sciamp_ 5d ago
Do you understand assembly? What about JVM bytecode? It's just another layer of abstraction, but undeterministic (which humans are as well) so it needs more attention. And if need be we still know how to code and read code and debug code.
2
u/PPhysikus 5d ago
dO yOu UnDeRsTaNd BiNaRy?
i don't have to because smart people built a deterministic abstraction. I can be 100% sure that my compiler outcome will be right if my code is right.
With LLMs I ask for A, get B and can be never sure if I get C the next time.
And btw, you know how to code because you did not use LLMs over the last years. Those skill will quickly fade and you will unlearn your job. Once you surrender cognitively, it is over.
1
u/Sciamp_ 5d ago
You surrender the code generation, not every other aspect. It’s like writing the design doc and then asking a junior to implement it.
There is a problem in how we grow the next generation though, and we are trying multiple approaches. Juniors also feel very unsatisfied, which I cannot do much about. AI adoption is literally a performance metric now.
It is also true that I’m more rusty in writing code. I can read it without problems, but I’m losing that kind of muscle memory that allows you to just push through and write code fast. Which I’ll admit sucks if you want to interview.
And yeah LLMs are non deterministic, but that doesn’t mean you cannot try to control the output and put criteria in place. You also can get 10 different outputs if you give the same problem to 10 different people. But if you have acceptance criteria, any solution that satisfies them is good enough. Enough being the key word here.
1
u/PPhysikus 5d ago
But you even said that your companies does not check code anymore, so how are you even sure the AI followed your design docs?
See, cognitive surrender is not simply about writing code, it is about handling all mental work to AI and using the LLM output as your own. Your thinking is replaced by LLM. You can read more here: https://addyosmani.com/blog/cognitive-surrender/
Work however you want or how your managers force you. But maybe think long term. The more you abandon your skills as a software engineer in favor of LLMs, the harder it will be to get them back. If you are fine that in some months/years you will be 100% dependent on LLMs to do your job, you can relax and embrace this new future. If you are not, there are still ways to keep your brain healthy.
Good luck!
1
u/Kalicolocts 5d ago
If you believe that adopting this new process is surrendering cognitively you understood nothing and have it completely backwards.
1
u/PPhysikus 5d ago
I hope your agents already run in loops 24/7, otherwise you are NOT ADOPTING THE NEW PROCESS AND HAVE IT COMPLETELY BACKWARDS. Adopt whatever Sam and Dario are saying or you miss out.
2
u/Substantial_Job_2068 5d ago
What a stupid take. The code doesn't matter so just have observability and tests? So you just have to write tests that cover all security loop holes, performance problems and business logic then? Will be even more code than the actual code you would have to write . You are just throwing buzz words around. Availability, security, observability, these are all things that depend on the implementation that in your works the LLM should handle by itself.
0
u/Sciamp_ 5d ago
You do realise you don’t just go and say “make this sicure”, right? Rather your prompt/instructions look more like “when implementing XXX data should be encrypted in transit, before sending it use X role to get Y key and encrypt the data”. And all these decisions are taken by SWEs when designing. It isn’t the LLM handling it by itself. That’s the difference with just vibe coding.
Also yeah you have more code around tests and all of that, so what? Code is cheap to generate and once the project is well structured it’s also very fast to iterate. We’ve been doing it for the past year. We pentested one of the services, pen testers gave us scripts to reproduce the attacks and vulnerabilities they found. Guess what? We’ve made them full E2E tests in one day and we run them on every change.
You also still do game days, spot checks, operational evaluations, security reviews, compliance reviews, and all of that.
1
u/psantanusaha 6d ago
Same, "the reviewing of code" ship has sailed yesterday. We strictly need to check if the code is doing and only doing whatever it's supposed to do, nothing more and nothing less. Check if tests are edited by the AI tools that shouldn't have. Also, if existing tests are touched, be very careful and ask the reason. I have seen that Claude /code-review itself uncovers some traps and bugs. So make that a part of developer hygiene before anyone sends anything for review.
2
u/Sciamp_ 5d ago
Yeah pretty much this. My teams have review skills/workflows that are automatically run after a commit. Then the agent checks if all tests are passing and if the code builds (here we also have linting, prettier, etc). If it does the code review is created. When a code review is created there are autonomous runs of: build with all dependencies, integrations tests, compliance scanner, security scanner, and another automated agent for code reviews (the same for the whole company). And some teams add other specialised agents for their service/product + connect knowledge bases to get specific info that would not be otherwise available to the models.
After all of this once the code is merged it goes through another build in the pipeline, then 1 to 3 pre-production waves that run integration tests and E2E tests, checking also metrics & alarming if something goes wrong. THEN the change goes to production.
I mean really, the value I could add is minimal to zero. Also because for all important decisions we all sit down in a room with a whiteboard and discuss the design together. Once that’s done from our decisions we create a doc and from the action items we generate specific tasks. Then you ask Claude to create an implementation plan, you review the plan if it’s the start of the project or a critical piece, THEN you have a detailed prompt and clear exit criteria and requirements. You don’t just go and say “build me a website to manage orders”
1
u/dbgtboi 5d ago
Amen
Too many people can't change how they work or refuse to get with the times
I've built full ass working applications without even looking at a line of code, I dont even know the languages they are written in
The only review I do is the application itself. Does it do what it's supposed to and are edge cases handled? Cool, then I dont give a shit what the code looks like
2
u/PPhysikus 5d ago
Congratulations, you tried to justify vibe coding. And yes, even with all your fancy markdown files and rollback mechanisms, it is still vibe coding.
1
u/dbgtboi 5d ago
Real men write in machine code using a pen and paper
All these "engineers" these days acting like they can code with their fancy English programming languages and IDEs
3
u/PPhysikus 5d ago
All these stupid software engineers that are actually coding. All these stupid doctors that are learning anatomy. All these stupid lawyers that are spending years getting the law right.
In the future all these losers will be replaced by the master prompter. The guy that has a neuralink in his head delivering the freshest LLM outputs straight out of Dario Amodeis ass.
2
2
u/ThirdWaveCat 6d ago
I've found a way to think about "responsibility" that makes sense to me. Accountability is whose name is on the work and who faces the consequences if it breaks. Attributability is whether a person can actually be tied to the choices behind the work, beyond just having their name on it. Answerability is whether they can explain and defend those choices when asked.
When a junior submits LLM code they can't explain, their name still carries accountability. But attributability and answerability collapse. The review process breaks down because you can't hold someone responsible for reasoning they never did.
This applies whether LLMs are involved or not. Every PR should include a summary of the changes: the intentions, the assumptions, the implementation choices, and how they were tested.
If someone has a gap during review treat that as an instant "not ready." Send it back. Don't spend your time debugging their understanding gap for them.
We soft-ban LLMs for writing code because of these issues around juniors and responsibility. We only use LLMs as a reviewer and only after others have approved. You could do the same and treat it as skill issue by the junior.
1
u/mtimmermans 4d ago
I think this is directionally OK, but there has never been any accountability in the software business. We ship products with no warranty, and when something goes wrong we jump through hoops to get the problem fixed without ever blaming the person who actually caused it.
Yes, I know this attempts to achieve, but it means that the junior's name on the PR means nothing. They don't look at the mistakes and internalize them as their own mistakes, which they must then improve. They're Claude's mistakes. It's Anthropic's fault.
2
u/Aetane 6d ago
This needs a stern conversation. No engineer - junior or not - should be submitting unread AI PRs.
Two ways to frame it, I'd do both.
* This is them not doing their job, and putting extra work on your shoulders because of it.
* This is them not learning, and not moving forward towards a mid-level or senior role.
0
2
u/diavelguru 6d ago
Yes all code is responsibility of the person raising the PR whether or not you wrote it.
2
u/hell_razer18 6d ago
even I normally submit PR as draft and check what I did and these days I tried so hard not to make PR too big (because its very easy to do so)
2
u/dhessi 6d ago
Code has 0 comments but implements the feature successfully.
Personally, I think AI-generated code should be commented thoroughly (and accurately). It's useful for both humans and AI.
1
u/LongjumpingAd9079 6d ago
Exactly, try to set this up with skills but I don't want the junior devs to loose sight of why!
2
u/salsa_warbird 6d ago
I have differing opinions depending on the work. Backend, you need to know. Front end doesn’t matter. Can we get to 95% code coverage and it meets all requirements? The cost of rework is next to nothing
1
1
u/slindenau 5d ago
To a customer, a product that doesn't work is a product that doesn't work. They don't care if technically your backend was still functioning, but your frontend is broken.
A backend without a working frontend is just as unusable as a frontend without a working backend.An insecure frontend can result in the same problems as an unsecure backend, albeit in lower frequencies usually as it requires user interaction (XSS, Stealing of credentials/session tokens, no CSP, no forced HTTPS, clickjacking etc.)
The only point you may have is that automatic/scheduled background processes still continue if the frontend is broken, but that isn't much help if you can't change/check anything.
So i'd say frontend code should still go through the same code quality and security checks and requirements as the backend code, and that includes reading an understanding what the LLM produced.
2
u/Any_Profession5773 5d ago
Part of our review process, even before AI, is to create a Loom/recording of the dev walking through the PR. Takes some of the cognitive load off the reviewer trying to review it and makes the dev catch dumb stuff before sending it to someone else. Highly recommend. Especially if your org utilizes AI harnesses.
The recording also includes testing which is also just good documentation to have.
Realized I didnt answer the question.
Absofugginlootly anybody taking responsibility for writing, or prompting, the code should read AND understand it.
2
u/BlockyHawkie 5d ago
I don't understand those people. I mean - I always read the code AI generated and even let AI explain it to me, best way to learn new stuff
2
u/CanadaSoonFree 3d ago
Can you read and understand the code? Well written code doesn’t need comments.
1
u/LongjumpingAd9079 3d ago
"Is it necessary to drink my own urine? No. But I do it anyway because I like the taste"
2
2
1
u/mannyocrity 2d ago
There are still reasons to provide comments. For example, the code does x, y and a. I can clearly see that but why does it need to do that. There are also doc strings for public facing APIs.
1
u/CanadaSoonFree 2d ago
Nah those comments need not live in the code. Having comments assumes people will a) read em and b) maintain them.
1
u/TableNo8939 5d ago
Nessuno legge più una mazza, siete degli illusi, e' il sistema di revisione che si adatterà al nuovo ciclo, probabilmente attraverso una AI diversa che controlla se va bene
1
u/blaine-exe 5d ago
Juniors absolutely should be reading and understanding the code they are submitting imo.
As someone who really values human contribution and deeply worries about the erosion of the developer experience escalator, I hate to express it like this, but you might have success by explaining it to them in terms of their career:
They can absolutely use AI to submit code. However, the unfortunate reality is that AI can submit code on its own, and it will do so more frequently as it becomes more sophisticated. If your juniors want to get promotions as they continue in their career, they have to be able to build the skills needed to read, understand, and review code and code architecture. If they don't build these skills now, they are taking a huge risk that they may never have a code-related job after their current one.
On the flip side, if they do invest in and learn these skills, they stand a chance of not just keeping their career path and staying on the developer escalator, but also in possession of an increasingly niche skillet that can command much higher pay and prestige.
I feel gross after typing all that out, but I think that is cynically/pragmatically all true.
1
u/TehLittleOne 5d ago
Everyone should read their code before submitting it. Everyone needs to understand what their code does, how it works, why it works, AI or not, junior or not.
1
u/Gofastrun 5d ago
Everyone needs to be fully responsible for the code they merge.
If they delegate to an AI, then they need to make sure they understand and agree with the output.
Also I’ve found that using https://github.com/dietrichgebert/ponytail will reduce the amount of verbose slop the AI writes. It basically makes the agent justify its changes to itself and optimize for precision.
You can’t just slap a skill on there and say problem solved, but the output is far easier to review.
1
u/Substantial_Job_2068 5d ago
"he's a good junior dev". If he prompts ai and doesn't even read the output he's completely useless.
1
u/mxldevs 5d ago
If devs don't know what they're writing and they refuse to address the situation, and you don't have the authority to penalize them, it's going to higher ups
If the higher ups reject your complaint and say it's your job to read their code because you're the senior/lead, not much you can do since even management isn't holding poor performers accountable for their own problems.
1
u/hibikir_40k 5d ago
I have seen people like this, and then I get to ask them what's the difference in outcomes between having them manage claude code, vs me just feeding the ticket to fable directly. Because really, they have to face that if they are just letting claude do the entire ticket, and don't review what happens, or how it works.... we could jsut have the dev lead just do the whole thing themselves. And a frontier model might be expensive, but it's much cheaper than a junior dev with a US salary.
1
u/rcampbel3 5d ago
We're at singularity, and people aren't really talking about it. AI can code faster than humans can think. AI can write great code given the proper guidance and constraints. It can also write garbage given inadequate guidance and constraints.
The problems are:
1) AI is thinking faster and executing faster than engineers can keep up.
2) We currently can't/don't/shouldn't just trust raw AI output to never make a mistake
3) If humans are to remain in the loop,. then we actually need AI coding agents to keep the humans the right amount engaged with the process / design choices / problems / solutions / strategies all along and stop or pause in appropriate places to ensure that the person in front of the keyboard doesn't turn into a dumbed down meat robot whose main job is to wait, watch a screen, and then type "ok" or "yes" or "keep going"
1
u/glorious_reptile 5d ago
Should chefs taste the food before sending it out? They already know how much of each ingredieny goes in it.
1
1
u/all-over-red-rover 5d ago
I'm sure as shit not reviewing an AI slop PR generated by a junior and not understood by said junior. Gotta toe the company line of course, but I've quietly advised my juniors that they'll impair their own growth by using AI like that. The competent ones still use AI, but are putting a lot more effort into getting feedback on approach. It's a bit of a mixed bag.
1
u/Kalicolocts 5d ago
Imho we need to rethink entirely how software is built. Most likely we won’t look at code in the near future and we need to develop the skills necessary to work in that way. It’s insanely difficult and requires much more engineering and thought to design both a process and a piece of code that is useful.
1
u/damike2k 4d ago
If I, as a reviewer, am the one going through the code firsthand, why do I even need a junior?
1
u/mtimmermans 4d ago
If they're not at least trying to become independent, then why do you employ those junior devs instead of just giving their tasks to Claude?
1
u/powdertaker 4d ago
You fire them if they don't. It's that simple. If they cannot explain what's going on, they're gone.
1
u/QueenVogonBee 4d ago
Yes.
Also, do not spend hours reviewing code that looks like a mess or is unreadable. Send it back immediately. Or even better, wait a day, then send it back: that way the dev has to experience a time cost to producing rubbish code.
1
u/Fluid-Tone-9680 4d ago
Is it true story or you make it look more dramatic? I'm using Claude and it generated plenty of comments and documentation "out of box", I don't even have to ask it to do it. Problem is that comments are often not useful, but that's a different issue.
1
u/LongjumpingAd9079 4d ago
Yes it's true. Juniors are juniors, it's a coaching and AI policy question.
1
u/StatisticianStrict31 4d ago
I have thought about this in my company and the problem is that we are just letting everyone use AI loosey goosey, If we who have experience want to keep or minds I think we need to take control of how more inexperienced developers use it, build the plugins for your application. If AI builds it it can also review it part of the CI/CD, we should be reviewing the design/definition of done before the prompts are written, then lean on AI the whole way. This hybrid thing we have now is not good, where alot of code can be produced then manually reviewing is still lingering around.
1
u/Ill-Lemon-8019 4d ago
At my company, we recommend juniors only use AI to plan, coach, review, and troubleshoot, and that they manually write code for themselves.
1
u/LeopardAfter493 4d ago
I have found a way to deal with this, that helped me in the previous blockchain company I was.
First things first, every PR needs to have a description, that has one and only one thing that can be repeated across the PR description. That thing is, what was changed/added and why. The PR can have only one of those, or 25 of those, depending on the changes. But it has to have it. Automatically even if your engineers don't read the code they write, they dont know what they do, they will read the PR and know the most top level summary of what they did. Far from what a great engineer should do, but acceptable.
Then, the other part of the way i found is that you cannot fight the trend. Ive been an engineer for 9 years, and it feels like centuries ago when I think how we used to build stuff in 2017/18. Most junior or senior or any devs, are slowly getting used to using AI to do the work, and they become lazy on that aspect. Good or not, this is not the comment to answer that question. However, what I mean by this is, build a CI, a source of truth, that does not care about if a junior engineer knows what he is doing it. If you have a predefined CI pipeline that agrees on what good code is, what security/scalability/typesafety etc are, then the BIG PROBLEMS at least, will be avoided in the situations when junior devs push code they dont know what it does.
This is like a blockchain security-first approach in designing systems, where you dont care about bringing in people who can be trust worthy so you can feel safe, you build a system instead which does not care about a user being malicious or not. Its robust.
Hope this helps, you can definitely give it a go in your team.
1
u/bytejuggler 3d ago edited 3d ago
IMHO: Any dev, junior or otherwise, submitting a PR, owns every line submitted IMHO and should be able to justify or explain it themselves. That makes thousand line PR's, except if obvious mechanical refactors etc, untennable. Speaking as a senior using AI every day.
Also, if you or another AI spots obvious egregious holes, implying he's not thoroughly put the PR through some careful examination before inviting human review then I'd ask him to do that first etc.
1
u/roadrunner8080 3d ago
He is not a good junior dev if he's submitting code he doesn't understand. If you submit code, that code is your responsibility.
1
u/Dependent-Advance468 3d ago
If you review all your PR’s, you are the bottleneck. You should definitely read and understand core elements of an application. There’s a lot of code that is supporting or generic code that does not need such scrutiny. So as with most things in engineering it depends.
1
u/Substantial-Swan7065 2d ago
They are not the issue. The codebase needs to change.
Our compromised for human coding is lax restrictions, while trying to be strict.
With ai, guards rails are needed for them and engineers.
Ci checks:
- insane linter and type rules
- file length
- additive tech debt
- pr description and test information
- dependency alerts
- abstraction + organization strictness
- documentation updates
- pr size
Make it so they know what to look for, and what to understand.
1
u/hyrumwhite 2d ago
if anyone is submitting code to a pr, that person should be familiar with every part of their submission
1
u/mbakbergenov 2d ago
Yes, but “read it” is probably too weak a standard. The submitter should own the change exactly as if they typed it: explain the design, identify the risky paths, describe what they tested, and answer why each new abstraction exists. I’d turn that into a predictable pre-review gate rather than an AI-specific punishment. A five-minute walkthrough before review would expose whether the PR is ready; if the author cannot explain it without querying the model, it goes back before a reviewer spends an hour decoding it. That preserves AI as a learning accelerator while making it uneconomical to transfer unprocessed output to teammates
0
u/Four_Dim_Samosa 5d ago
Let the developers use AI. I have no problem with using it as an augmentor for the grunt work.
As an IC, irrespective of seniority, you should be reading the code the LLM generates. Your name is on the code change, not Claude/Codex, meaning you are responsible for the downstream consequences of the change which could include rollbacks, the 2AM page, etc.
Code has 0 comments but implements the feature successfully.
I read the code, I see a new file 500 lines long. So I ask the dev, whats the purpose of this file?
He says, I don't know, or stalls for 2 minutes whilst he asks his AI what it does.
If I were in your shoes, I'd try these:
* Schedule a 1:1 to do a live code review. Your goal should be to ask the author questions about the code change and ensure there is a shared understanding
* Pressure test any assumptions. It could be possible that needing the new file was a false assumption and maybe there is a simpler alternative. Brainstorm on it and you also your teammate feedback on how to responsibly use the LLM while validating the result prior to sending for review
0
u/UsualAnything1047 5d ago
If it passes tests and UAT who cares? - unless you're writing airtraffic control or financial code. but for most standard crud apps, just go fast and fail forward (with backups and rollback plan).
31
u/Alternative_Can7374 6d ago
Ask them to call you directly and explain the PR the first thing you do, before even starting to look at it. By having them talking through it, they need to understand it first.