How to mentor vibecoding junior?
Posted by b48cfqz0@reddit | ExperiencedDevs | View on Reddit | 95 comments
Our company‘s culture is a bit toxic and driven by middle management who keep asking us to use AI and manage our time better. As a result, one of the new juniors on our team is using Claude heavily to try to impress us. I want to tell him to slow down and review the code since he doesn’t have any idea what his code is doing. How can I encourage him to take his time and actually read code through line by line? I think AI has its place but overreliance on it frustrates me. I asked him to Ctrl+F in the file and he asked Claude to search it and give him the line number instead. That’s extreme!
Reasonable-Pianist44@reddit
I am tired of these posts. IS this AI?
laueos@reddit
This is a losing battle if management is not balanced. You can only argue with concrete outcomes. Do you have clear code quality standards and code review criteria?
Ok_Individual_5050@reddit
I feel like it's really hard to put "solves the right problems in a maintainable and scalable way" into objective terms and trying to do so is just quite unfair on reviewers
laueos@reddit
Exactly, you need objective terms.
One area to focus on could be architecture. Once documented as architecture decision records you can check if a PR respects or violates such decisions.
Regarding code design you could name a pattern they use, name an advantage and a disadvantage of using it in this case, and ask them for their evaluation of the tradeoffs.
You could also ask: Let’s say we need to change this or that in the future, how many files would we need to touch? How can we reduce the risk to miss something.
Do they extend the public API of a module? Point it out. You can ask: Is there a way that we can stick to the previously leaner interface?
Maybe they duplicate business logic. Would it be better to find a dedicated place for this piece of code?
Ok_Individual_5050@reddit
I know how to do all of this stuff. What I'm saying is it is a huge amount of work tantamount to doing their job for them
laueos@reddit
Through objective review feedback you hold them accountable. You keep a reasonable balance, don’t have to raise everything, but a few things each time, document it well.
I don’t think that is don’t their work for them. It’s healthy review. But I understand your position as I’ve seen sloppy PRs even before AI was a thing. Juniors need to be held accountable and not count on the reviewer to catch issues.
I didn’t say you should provide all answers, but give facts and ask questions. The ball is in their court then.
Helpjuice@reddit
You are in a vibe shop, there is little to no mentoring when the bulk of people there have little to no formal or informal experience in software engineering, computer science and basic troubleshooting.
The goal in these places is to push out slop and make money from it as fast as possible. Your slow down and pay attention approach goes against the grain of these places.
Your only option is to sit back and pray for the best while you study for interviews to get ready for your next job. The person you are probably trying to mentor more than likely has no clue what you are talking about and is just focused on pushing the slop out and getting things done.
Your management doesn't care, as long as the slop is getting pushed out they are happy, anything, and I mean anything slowing that down will only lead to problems for you.
If you want you can attempt to add in human review into the process, but you will need to be specific in what those delays will be for and must have some serious justification in their implementation.
Emergency-Ant-6413@reddit
The company I'm at is literally a "vibe shop". I'm a junior with 1 YOE - how can I really make sure my career is on the right path? Currently leetcoding to prepare for interviews in my freetime, but at my work I'm almost a vibe-coder looking at the pace required from me. It happens that I just get lazy and prefer to let Claude do something and just quickly review, just because I know how quick it is. What I surely learned already is processes, workflows and how things work at big companies, but from technical side, I'm less confident in my skills than at my internship.
On one hand I think - AI is not going anywhere. On the other hand I'm 100% aware that I'm fucking stupid and would learn, understand and remember the pattern better if I've done it by myself, but it would just take me 10x longer than without AI. I'm really lost on this one...
Ok_Individual_5050@reddit
Sorry to shotgun beta with career advice at you, but unless you're going for a FAANG job at one of the big vibe coding shops is learning leet code a good use of your time? You'd almost certainly be better off
All of these things will help you more in your career than leetcode. I am 15 yoe, a lead and earn at the top end of developer salaries for my region and I've never had to leetcode in interviews, even when looking at finance industry stuff.
Emergency-Ant-6413@reddit
I'm doing leetcode to get more confident with some technical interviews. I understand completely what you're saying, but for me without a clear and specific plan I have a hard time trusting the process.
I get that it comes with experience, but I'm pretty sure that currently I'm not necessarily taking the right steps to became a much better engineer. I get praised for getting things done, taking ownership and good communication at work. But I know that without AI all of these would be impossible in such short time. I don't see using AI itself a problem, but in my case I'm much less connected to the code than if there were no Claude.
So I know the stuff you listed would likely help, but these points are vague to me and I'm kinda trying to build a mental system, hence it'd be easier for me to trust and follow.
Btw. Thanks for thorough comment.
Helpjuice@reddit
Well, you are going to be cooked if you stay, low or no skill is the name of the game of where you are so you have to get out before your brain turns to mush. You are on the way to recovery though as the first step is noticing the problem and it looks like you are already prepairing for getting things in order to get out of there.
If you had to do a big tech interview you would get smoked due to not knowing the foundations of your craft. This is what vibe shops push and staying there too long will make it so you can only work at vibe shops.
So the thinking is AI will not be going anywhere but that does not negate the reality that you as a professional should understand the foundation of your craft and not let something that you should not trust do it for you. Trust but verify is how you operate in the professional world.
Not doing so leads to numerous very preventable security, performance, reliability, scaleability, and maintainability problems.
If Claude doesn't know what it did wrong and you don't know what it did wrong and prod is down you are going to be the one trying to fix it not knowing where to start. Or even worse large amounts of compute, storage, bandwidth being used and nobody knowing why or how to deep dive into fixing the problem or creating a new solution without AI can cause an unnecessary amount of time and money.
Also those junior / intern projects normally end up getting turned into production so you have to be able to do your due diligence on them before they get auto moved up in the priority list by management.
Emergency-Ant-6413@reddit
Thanks for a thorough answer. I review and make sure to understand AI generated code 99% of times. But many times, I wouldn't be able to write the same thing myself without Claude. And I feel like actually creating and designing the solution is what makes it "yours", so you really understand it deeply. I reckon that the code I produce with AI is genuinely good, but I genuinely feel like I don't learn because of it.
What steps do you think I should be taking right now (other than changing job ofc). I mean concrete stuff. I cannot go 100% without AI at my work, but I HAVE to do something to get better at my craft.
I remember pre 2023 times, when I was still studying at uni and every time I wrote a piece of code I understood each small part of it, all edge cases etc. This feeling has been gone for me for a while now as I'm detached from the code I push since it's not really mine - I just review.
CodeToManagement@reddit
Need to teach them how to use the tools properly. There’s 2 ways to use Claude to write production code. The good way is to direct it in what you want built and how, the bad way is just describe the feature and let it figure it all out itself.
Need to impart on them that if they can’t explain their code and don’t review it before shipping it then it’s not going to help them get ahead
03263@reddit
At enough level of detail you might as well just use a programming language, the things that we invented to simplify the process of instructing computers on precisely how to execute a program.
CodeToManagement@reddit
So don’t go to that level of detail. The same way we don’t go to the same level of detail as assembly when writing in higher level languages and trust the compiler.
My point is be the one driving the ai actively not passively. Understand where it needs to be directed and where you can give it more leeway to make decisions.
There’s a big difference between using the tool well and creating vibe coded crap.
Ok_Individual_5050@reddit
Having tried this approach myself, it's not faster and you miss important details you'd have picked up on by diving in and doing things yourself..
Master_Addendum3759@reddit
There’s a supremely better 3rd way that I won’t share
13ae@reddit
nah but the 3rd way pales in comparison to the 4th way that only i know about
cockboy_trillionaire@reddit
I just tell it to make no mistakes
thebig77@reddit
You can lead a horse to water or whatever. The junior is going to need the curiosity to level themselves up and no amount of coaching is going to instill that in a person.
I've come across a lot of juniors in my career that don't really care about programming as a craft and just treat it as something to pay the bills, which is fine, as long as they are performing decently at their job.
This was a problem before Claude was around with juniors copy pasting StackOverflow answers without understanding the fix or just general cargo culting.
My advice: not your circus not your monkeys. If you aren't this junior's manager don't sweat it and just move on. They'll either get it or they won't.
b48cfqz0@reddit (OP)
That makes sense but as his peers, we are responsible for the stability of the system that he is vibecoding against, and need to fix errors etc. If the junior can’t be mentored effectively to produce better code/design docs, then how can I better protect myself? Should I be refactoring his code, or reading through it and making notes? It’s tricky because I have my own work to do but we are awash with Jira tickets, some of which will get assigned to this junior
sunburstbox@reddit
block their PRs with constructive comments for code that you think is not good or safe. there's no reason you should pick up the refactoring work. if they're vibe coding bad or dangerous code, they need to learn that they're only creating more work for themselves when the PR gets blocked and that it's in their best interest to have better code.
Sheldor5@reddit
vibe coding takes minutes and then the reviewers take much more to read, understand and most importantly write a lot of comments
vibe coding = offload all your work to the reviewers because fuck you teammates
AggressiveAd5248@reddit
The counter to this is probably unironically to have an ai code reviewer who will scan for common anti patterns and variable names etc
Ok_Individual_5050@reddit
That would work if code review was about spotting anti patterns exclusively but it's not
sanbikinoraion@reddit
That's a start. But better imo to just PRs on "generally illegible here are two examples" and so spending effort on further review until the quality improves
NuclearVII@reddit
No, the counter to this is to normalise "this is AI slop" as an acceptable reason for rejecting a pr.
max123246@reddit
You're not gonna make a meaningful impact by telling a vibe coder that this is AI slop, even if true. You've gotta work with people at the level they are at, if you actually care about better outcomes
NuclearVII@reddit
There is no engaging with a vibe coder period. This person thinks that a glorified autocomplete machine built on plagiarism is the future of your craft. It is the height of contempt for your work that he submits this drivel. There is no amount of engagement with it that makes sense.
Reject it for what it is, not some imagined reasons that are just going directly back into the prompting window.
PressureAppropriate@reddit
...and they go to manager with "NuclearVII is slowing me down with their insistance on code quality!"
You think your manager cares about that right? Wrong...
NuclearVII@reddit
I was, in fact, quoting my department head there. He's the reason why "this is AI generated" is enough to reject a PR outright at my shop.
Y'all need to develop some backbone.
johnpeters42@reddit
Yeah, this absolutely relies on someone higher up the chain who will believe you when you say "this code is shit, it's just rapidly-produced shit".
Sheldor5@reddit
can you imaging the quality of the code and shit ending up in production?
Sw429@reddit
No need to imagine. I see this happening where I work right now. Within my team I can fight back in code reviews, but I can't stop all of the slop being committed across hundreds of devs.
Doesn't help that management has decided we must be using AI constantly to increase our velocity, and they've made it very clear they are tracking the number of PRs. The instability of this approach is already starting to show. I'd be bailing, but I'm not convinced I can find anywhere better right now.
Ok_Individual_5050@reddit
It also creates a huge workload for reviewers because of automation bias. The response to anything other than airtight criticism is "well Claude said this is fine". Sometimes when mentoring juniors "this way is kind of lazy" nerd to be an acceptable comment, as long as it's followed up by more info. Writing an essay justifying every bit of feedback is exhausting
CaleBrle@reddit
I created a Claude skill that notates all my common feedback and best practices. GitHub reviews the pr before I do. I’m so tired of wasting my time to give valuable feedback
sunburstbox@reddit
ah true. then that’d be the one comment i’d personally leave. basically let them know they no one can approve the PR because it’s unreasonably long or complex, and maybe ask that they atleast explain the architecture and reasoning for their decisions to help a reviewer understand it quicker.
Sheldor5@reddit
even on small/average sized PRs the problem is the same
they can output PRs like a machine gun and all the mental work then has to be done by the reviewers
I would simple reject a PR at the first sight of vibe coding with:
"you didn't take any time writing this PR yourself so I won't take any time reviewing it."
sunburstbox@reddit
yeah that's basically the idea, it enforces the bottom line that vibe coded slop will result in a blocked PR. but id want to approach it more constructively so the junior actually feels motivated to ask how to improve rather than just feel rejected and uncomfortable to ask.
supercargo@reddit
Focus on systems and processes to ensure the team responsibilities are met. Doesn’t have to be heavyweight process, but does need to be concrete enough to elevate you above what you “feel” into something you can articulate and show. Put up constructive road blocks (clear docs, cohesive change sets, tests exist and pass, and so on)…if this person can overcome those (not circumvent) then they’ve proven their code is “good enough” whether they understand it or not. If they get completely bogged down then either their progress will stop and it becomes management’s problem (this doesn’t have to be entirely adversarial, give your manager a heads up!), or perhaps they become more receptive to coaching to help them get on track.
b48cfqz0@reddit (OP)
This is a good idea!
manewitz@reddit
Require them to explain or have a conversation about the code in the PR in their own words with a requirement of NO AI for that portion. If that requires them to do it in Google Docs so you can see their writing history is organic, so be it. If they can’t articulate the problem OR how the solution works, it’s too risky for deploy. Loudly flag their code as not ready for QA until this is resolved.
Turn on linters in CI for things like formatting, code smells, presence of tests etc. Hold the line on all merges until you get some intelligible answers out of them or they’re just generating more work for the rest of the team since they can’t contribute when something inevitably breaks.
Assign them learning about the tools you use, VS Code, command line work, etc. so they have at least a minimum competency in operating a computer for development.
Good luck
evergreen-spacecat@reddit
Tell him firmly that he must understand every piece of the code he is producing. No exception. Further, he must be able to not only understand but also be able to reason about each part of the code with respect to your common goals of stability, low risk, architecture etc. No exception. If he asks why, just be clear that there is need for devs who does not understand the tech or the business. If all we need is vibe coding, the product owner that really understands the users could just paste the user story into an agent. I think you need to be really frank here.
jmfsn@reddit
They are responsible for the code they deliver. It's up to them to fix it. If they can't, they are not doing the job and should be let go. They are responsible for it and paid to do it. There's no value in paying a developer that just sends unfiltered AI code into a PR. Anyone can do that by the bucket without being a developer.
jmfsn@reddit
As an add-on, I have always explained to the ones I coached that the deliverable is fully debugged code. That helps frame that kind of conversations.
Playful_Ant_2162@reddit
Unfortunately, the unwritten rule of providing help is that if you are not asked for it, it is rarely wanted. Doing things like taking notes or refactoring his code is great, if he wanted it to learn from it. But otherwise its only use is to cover your own ass and document the ways in which you see that it's a problem. So if there's a way to kill two birds with this approach then great, document things in a way that helps him avoid screwing things up for everyone. But if he hasn't actually asked for it, do whatever you gotta do to get your own work done first, and document his mistakes second. But no matter how you're trying to help or CYA, at he same time you have to be pushing it up the chain, even just a "hey I'm seeing poor quality and I feel that x y or z could happen" or else it's meaningless. What would you do if something did go wrong? "Hey here were my thoughts on this, I tried to tell him and he ignored me"? That you stopped there and let things just blow up for him to learn a lesson? The people with their hands in the pot don't care about lessons, they care about outcomes. Just don't cut your toe off by getting your foot only halfway through the door. If you get involved, it's probably not going to turn out well for you unless you're all-in, because admitting you knew about a problem and didn't take the correct actions is worse than ignorance of it, when he's not your direct responsibility on an organization level.
fragglet@reddit
Then focus on those things. Doing so makes sense because those are firmly in your wheelhouse and your responsibility. Code reviews are a great time to bring this up and in particular you should pay attention to if you have to tell him the same thing multiple times (either within the same review or across multiple reviews) - that's the kind of thing that you can bring to his manager as a clear example of something that needs improvement.
90davros@reddit
The point to make with this junior is that there are projects which can be vibe coded (e.g. internal dev tooling) and there are projects where they can use AI but need to carefully review the output code (e.g. transaction data storage). This sounds like one of the latter. Doing a good job in those cases means not submitting code that you don't personally understand and verify.
Sw429@reddit
I've seen quite a bit of this as well. I think it's because a lot of people receive career advice that going into coding is a good way to make a living, despite not being passionate about it.
It becomes really obvious when I mention some personal hobby coding I did over the weekend and someone is like "ew, why would you ever code outside of work??" Unfortunately, many people who work in this industry don't actually like coding, and therefore will do the bare minimum.
thomyorke2002@reddit
Get a life
Far-Interest-4055@reddit
i had a junior who googled everything and never learned why things worked
TheEnlightenedPanda@reddit
What If I'm their manager? How do I deal with this while the org is pushing AI and asking to reduce estimated effort
Cute_Activity7527@reddit
Turn off AI agent and their subs to claude and copilot.
Give them API spec and python manual so they can sit an type by themselves. Best way to learn is to „do it yourself”.
Then throw them under the bus and say „swim b1tch”. You learn even faster in fire.
Medical_Car5372@reddit
The future is now old man
mustardmayonaise@reddit
I do a “no AI” questionnaire with them on code from time to time. I’m always 100% of the time able to point out an issue with a PR clearly developed by AI. Instead of a comment, I morph into a learning session.
Adventurous-Ad-698@reddit
Let their performance speak for them. Review the code objectively. If it's solid, merge it. If it's genuinely poor code, unreliable, unmaintainable, bug-ridden work, then point it out through the PR inside of the PR. Make the mistakes visible. Decline PRs if its untenable.
At some point, the junior will hit a level where claude isn't going to be performing well enough, and their skills won't be adequate to fill what claude lacks.. Their performance will tank, and management will become aware of it.
Use postmortems to highlight any issues caused by their work, but don't call them out specifically. If management has a problem, they will track down who did the work; trust me.
Dont make fixing them your problem, dont make them dislike you, make the problems visibile to management.
EighteenRabbit@reddit
Do a desk check with him and get him to go over the code and explain what it does and why the choices were made to do it that way.
If he can’t do that then send him back to have Claude explain everything to him until he does understand. If you keep doing this eventually he’ll do that before he opens a PR.
typical_passeng3r@reddit
I hear you and it’s definitely a weird pace to be in where two worlds are colliding.
On one hand you/we’ve learned how this world worked untill recently and on the other hand you have a coworker who’s working in a different way.
Is there no way you can meet in the middle of the road?
Id be curious learn how he’s promoting as prompting can be done in a wide spectrum. Promoting can be done recklessly or it can be done in increments, with a discussion to learn from.
Ultimately you can only do so much even tho it’s part of your responsibility at work. If the coworker does show any sign of curiosity then protect yourself and let him trip on his own.
BigLaddyDongLegs@reddit
You're not gonna like it, but one way to make him think before he codes is to make him write an LLD beforehand so he thinks about the problem first. Doesn't have to be a whole thing, could just be him emailing you his proposed solution before he dives in for you to review and confirm he's thought of everything.
I'm self taught and my first job I was a "vibecoder" (I guess...it wasn't called that back then). I would just leap in and try build it all on the fly. Thought I was great, but it took me realizing when I sat for a few hours first and thought it all through, then the actual coding would take less time and end up way better and cleaner.
He needs to realise that. So make it something you review with him in objectives/performance reviews also
zzzthelastuser@reddit
You are just shifting the problem from ai generated code to ai generated LLDs (followed by ai generated code).
BigLaddyDongLegs@reddit
This is why you need to just meet with him and explain it. And be ready to question it and make sure he understands what he's proposing.
This is also why code review is important and not just a LGTM message from everyone.
We're in a different environment now where code review is really, "Did the person who (wrote) generated the code review it before committing".
It's more like, "coder review" now.
PressureAppropriate@reddit
Exactly, this junior on my team sent me a long ChatGPT generated message on Teams to explain why his ChatGPT generated code was the best thing ever.
Once their brain is fried by LLM abuse I don't think there's a way back home...
For what it's worth, I have since fully embraced AI myself and YOLO all my tasks... It's what management wants and now it's what it gets. Collecting pay checks until the Big Job Collapse...
Maybe he was just ahead of his time?
Available_Award_9688@reddit
Honestly this is probably the most realistic take in the thread.
The curiosity thing can't be taught, either it's there or it isn't. And you're right that this predates Claude by a decade, Stack Overflow copy-paste was the same pattern, Claude just makes it faster and more confident-looking.
The only thing i'd add is that the stakes are higher now. A junior who didn't understand their Stack Overflow paste would at least have some friction from adapting the code. Claude generates something that looks correct, compiles, passes basic review, and ships. The blast radius of not understanding your own code is bigger when the code is more convincing.
Still not your problem to solve if you're not the manager. But worth having the conversation once clearly, documenting that you had it, and moving on.
flavius-as@reddit
Make an agent and a prompt for them and tell them to run the agent against the diff 3 times in a row and fix everything the agent said.
Make the responses given by the agents a requirement to the PRs.
And let them know that you as their technical leader will give them a bad review if they fail to follow process.
flavius-as@reddit
You don't want to deal with all the crap that AI creates.
You want to govern AI and let AI deal with its own crap.
DCON-creates@reddit
I was on a call with my manager and he was using claude... To run the project. Like "Claude, please run the project now" instead of just pressing f5 😭
nkondratyk93@reddit
honestly slowing down won't help if he doesn't know what to look for. the ctrl+f thing is the tell - he's using AI as an oracle, not a tool. thing that worked for me: make him explain the function out loud before running it. if he can't, AI is doing his thinking, not just his typing.
gfivksiausuwjtjtnv@reddit
Tell him he needs to commit a spec to the repo that will be the planning prompt for Claude.
You review the spec before Claude picks it up
kruvii@reddit
Is pair programming still an option?
insidious_concern@reddit
He's already pairing with Claude full time
ultraDross@reddit
Have a threesome with Claude then.
formerlyInspector@reddit
Ask them to read a book
sebf@reddit
I cried. What kind of marketing made this management think that AI gen was going to improve « time management »? This is concerning.
Your Ctrl + F example is also worrying. In my biased opinion, all of the trust in those « magic solutions » have been developed by the AI hype so that those kind of habits developed and they sell more token credits. That’s a circular economy that sell useless, expensive, energy consuming stuff. And strongly make good workers they are obsolete.
sebf@reddit
Make them review senior developers MR, it’s going to be hilarious (no).
moohyunking@reddit
Tell him Make smaller MR
Kaligraphic@reddit
You know, I can have Claude pull a ticket, vibe code its way to a PR, and even respond to review comments. If this junior doesn't offer more than that, they're destined to be replaced by a very small shell script. It might be worth pointing out where humans actually add value in the process.
Foreign_Addition2844@reddit
I dont know. Im torn here. I used to think like this, care about the code base, care about the outcomes, etc. But I have come to learn that most management doesnt give a shit. I have worked at places where the leads of the absolute worst teams with the most buggy code and the most production issues would get raises and promotions, and the people who wrote good, stable, performant code with no issues were treated like they didnt do enough.
I wouldn't waste my time. Its just a paycheck.
BearyTechie@reddit
Did you set expectation and tell him what exactly the code is supposed to do? It doesn't matter if he is using Ctrl+F or asking Claude.
Enthu-Cutlet-1337@reddit
Make him explain the diff before merge; if he cant, the code is probably cargo cult.
hubert_farnsworrth@reddit
Set up some time to review their code. Pair reviewing. Let them go through the code and ask questions on why did they do this and not that. Tradeoffs etc. ask them to add a comment and fix those issues. I think this is how mentoring will look like in the age of AI.
HappyFlames@reddit
Vibe mentor them
Miserable_Heron_9007@reddit
Does he have basic knowledge (data structures, operating system, DB, networking)? In some cases, it's just not possible in a normal way. Most of the time, it's on him.
Basic-Lobster3603@reddit
i have also been thinking the same thing. how do I help teach juniors when the whole company is pushing only vibe coding I don't care if your skills of coding siffer mindset. any time I try to get them to think about a problem it's just my AI said this and my AI said that
I have seen senior level engineers copy/paste cli commands into copilot to run them over their terminal.
Exiled_Exile_@reddit
The Claude search is the point I question if you can mentor him. I've known plenty to use tooling and that's fine.
How well does he take criticism? Is he willing to learn when you leave comments on his prs? has he shown improvement over the course of his employment?
If he's willing to learn and takes criticism ok I think it's worthwhile to have a conversation about ownership. We own all the code we ship at the end of the day. If we trust ai and don't verify we open ourselves up to issues. Read your prs before you ever send them for review. It's saves everyone time and makes you a better engineer.
_vec_@reddit
Pick your battles. The search thing is kind of silly but harmless. The important part is that they understand the code, even if they're reliant on AI to get them there.
Maybe try asking "why did Claude do X" instead of "what does X do" questions. Get them in the habit of actively reading. Maybe try asking how to write a prompt that addresses the problems you find instead of directly asking how to change the code.
fragglet@reddit
Personally I really don't like this idea. Claude is not a real person and it's the engineers who need to be accountable for their code and their decisions, whether they used an LLM or not. If you want to force them to actively read, put them on the spot without an LLM and make them explain their decisions and work. That puts the responsibility on them to properly read and understand what they're submitting.
lepapulematoleguau@reddit
Just don't
Fruloops@reddit
This won't make the problem go away, it'll likely make it worse
brstra@reddit
Ctrl+f? Pff, it should be /
DisastrousMoney9324@reddit
I think you should be more direct and tell him what you expect from him
demosthenesss@reddit
Your example is silly - why do you care so much about ctrl+F vs claude?
Focus on something meaningful. That's certainly a silly reliance but focus on something actually meaningful - "It's important to understand the code we're writing. I don't care if you write it yourself, copy from stack overflow, or use AI to generate it - we need to understand what's being built."
03263@reddit
really
b48cfqz0@reddit (OP)
It’s not just that, it’s questions like “what file were we just on”, basically questions I’m asking during the debugging session get sent straight to the AI during screen share, which gives me a strange out of body experience.
Your suggestion is a good one though! I tried a version of this where I made him walk me through a code review of a large PR. But he, somewhat boldly, said he generated the code with Claude and admitted that he hadn’t the time to understand it :/
Wonderful-Citron-678@reddit
While the end result is the same, it’s pretty stupid to literally spend money on an external service to search a text file…
kevin7254@reddit
I don’t think you can. Seems like a cultural thing at your company. I guess his junior friends do the same, spending time on reviewing and learning makes it seem like he produces less than other people with the same experience.
It fucking wild but that’s how it is.