Hacker News Reader

Comment by kaydub | Hacker News Reader

Because juniors don't know when they're being taken down a rabbit hole. So they'll let the LLM go too deep in its hallucinations.

I have a Jr that was supposed to deploy a terraform module I built. This task has been hanging out for a while so I went to check in on them. They told me the problem they're having and asked me to take a look.

Their repo is a disaster, it's very obvious claude took them down a rabbit hole just from looking. When I asked, "Hey, why is all this python in here? The module has it self contained" and they respond with "I don't know, claude did that" affirming my assumptions.

They lack the experience and they're overly reliant on the LLM tools. Not just in the design and implementation phases but also for troubleshooting. And if you're troubleshooting with something that's hallucinating and you don't know enough to know it's hallucinating you're in for a long ride.

Meanwhile the LLM tools have taken away a lot of the type of work I hated doing. I can quickly tell when the LLM is going down a rabbit hole (in most cases at least) and prevent it from continuing. It's kinda re-lit my passion for coding and building software. So that's ended up in me producing more and giving better results.

View on HN

> I don't know, claude did that

I'm the type of reviewer that actually reads code and asks probing questions, and I've heard this from junior and senior devs alike. It's maddening how people say this with a straight face and expect to keep their jobs. If people are pushing code they don't understand, they're liability to their team, product, and employer.

It is going to happen with higher frequency - buckle up!

"I don't know Claude did that" isn't a bad thing in and of itself... If someone is spending a bunch of time on code that Claude could have done and easily verified it was correct, they are going to move slower and produce less useful things of value than someone who cares about reading every line of code.

Any situation where you’re submitting under your signature code to production without knowing what it does should be at the very least cause for a talk.

I’m kinda shocked that this even has to be said.

If you don't understand you code how you can be sure it's correct? You actually are pushing it into your colleagues who will verify and fix the code later.

Testing.

The only thing that changed with AI is that the narrative went from "you can't always know perfectly what every part of the program does" to "don't even try".

Sad reality is test engineers headcount over last years was cut even more than developers. Most companies see testing as obstacle and unnecessary costs and has no will to invest into testing.

But the LLM writes the tests too. Probably even made some private methods public so it can test them, because you asked it to write a comprehensive test suite. It’s a beautiful self-jerk circle of shitty code based on wrong assumptions proven by correct tests testing shitty code based on wrong assumptions…

Or the wonderful loop of "These test steps are still failing, let's try something simpler and remove the failing tests. Great! The tests are passing now!"

To be fair, even if you understand it that's doesn't mean it will work well.

You, sir, have "executive" written all over you.

Savage

If you "don't know" then how could you have "easily verified it was correct"?

I think they were claiming claude easily verified it? i.e. they have total faith in claude to not mess up

That's an interesting claim. I wonder how they would come to believe that.

The policeman says to the judge, on the stand "I don't know why my sworn affidavit says that, your honor. But I can write twice as many affidavits now so it's all for the best."

> If someone is spending a bunch of time on code that Claude could have done and easily verified it was correct, they are going to move slower and produce less useful things of value.

This is the future fellow greybeards. We will be shunned for being try-hards, and when it turns out we were right?... Well no one likes a know it all.

If it’s easily verified as correct, then you should have verified its correctness before bringing it to someone more senior and asking for their help, and so you should be able to explain why it is there when they ask.

Why do we need them then? If they're some dumb passthrough I can just replace them with a background agent

The rank disrespect of somebody asking you to review something they haven't even looked at is eye watering.

I feel like AI-induced brain-rot of engineers is inevitable. Unless we see AI leapfrog into something close to AGI in the future (certainly not ruling this out), I think there will be very lucrative careers available to engineers who can maintain a balanced relationship with AI.

I just felt this recently. I was sent some code for me to put into prod, a long running service. And in one func, which returned an error (Go) but still called "os.Exit" in each error handler rather then returning.

Fixing the issue was a small matter. But the amount of disrespect I felt, that I looked at it closer then anyone else apparently (which wasn't really all that close at all), when they were ostensibly building this code, that disrespect was just immense.

I'm glad I'm not the only one who gets viscerally irritated when I'm asked to review a PR that was obviously generated. You didn't take the time to write this code, but you expect me to take the time make sure it's correct, which will take far longer than a regular PR because there's no reason to assume an LLM even understood the task. Next time just be honest and ask me to do your work for you.

My boss decided to start putting out a ton of PRs from Devin at one point. I told him I'm spending more time reviewing his PRs than he was saving.

> You didn't take the time to write this code, but you expect me to take the time make sure it's correct

So, I guess there are a couple parts here right? I might not take the time to write the code, but surely I am on the hook to demonstrate that I've tested the code or have very good reason to believe it's correct?

If people are pushing PRs [of any meaningful complexity] without knowing whether they work in the general case that sounds like a failure of process and/or training. For me PRs are about catching edges?

I'll quote from my parent comment:

> somebody asking you to review something they haven't even looked at

The situation you're talking about is not the one we're talking about, so I'm not sure what you're taking issue with.

Stop saying engineer when you mean programmer.

It’s an insult to real engineers.

People making siege engines?

Well no one actually asked you for a review, it's just a stupid checkbox item some boomer added to the list of other useless checkbox items - like group calls where everyone is just reading list of closed tickets we can all read ourselves in jira. This self righteous bullshit makes the whole ordeal even more insufferable.

Consider that your experience may not be universal. Just because your reviews are useless rubber stamps to satisfy "some boomer" does not mean that other shops also have no standards. I get explicitly asked for reviews at work all the time, and I'm expected to actually understand the code and provide useful feedback.

By the way, you don't have to give useless reviews even if your coworkers do. It sounds like your workplace is infected with complacency, but there's no law that says you can't do better.

Code reviews are one of the few ordeals worth doing. They catch problems and transfer knowledge. In a reasonably well run org (it doesn't take much) code reviews are easily a huge net benefit.

As for "reading closed tickets", you are right. It is silly. Alas, in apathetic orgs it is a reliable way to get some people know what is going on some of the time. And that particular ordeal keeps the tickets somewhat in sync with reality.

If you saw the nonsense some of my teammates try to commit, you would have a completely different view on code review. Just off the top of my head in the past 3 months, they have:

  - Written a 1-line function that returns a literal, but they pointlessly made the function async and added a @cache decorator.
  - Used try/catch to catch ALL exceptions, and then just ignored the exception causing code elsewhere to explode.
  - Used try/catch to catch ALL exceptions, and then log that an authentication error happened. Did the request time out? Well the logs now lie to you and say it was an authentication error.
  - Replace a log statement for a very serious error with a logging.warning() because that makes the error no longer show up on our reports.

If code reviews are that useless to you, that must mean either your team is completely homogeneous in terms of skill level and knowledge, or no one is taking the code reviews seriously.

It’s pretty great actually.

We can filter out useless people faster.

The days of easy 400k plus TC are over and only people deserving of that should get it imo.

And btw I worked with idiots before, and I’m sure I will in the future. But there should be less of them.

The correct response to that is "what's your job?"

It's baffling how little awareness some people have.

"What would you say... you do here?"

"get paid to ask claude to do the work of course!"

Pre AI I can understand why you might not know. There have been instances where I find a recipe, take what I need, but there’s some code I can’t understand or find an answer to. But time pressure, so I just add a comment and ask around for ideas.

These days, just ask the llm.

100%. This has in general become a trend across my company. Less so developers, more so everyone else spitting LLM generated content, and asking real people to review and provide feedback. I mean , WTF.

amen.

My interactions with Gemini tend to be fairly slow, but it's because I don't give it any extra permissions, make it research and plan an implementation first, and check each file update one at a time.

So far it has still been a bit more productive for me, though the margin is low. I get more product sork done on the order of 5-15%, I tend to have more test coverage as I focus more heavily on that, and I can focus more often on architecture. The last one is a win for me, I prefer that work and find that I can review code quickly enough to make it worth the tradeoff.

Is there any tool that approve a given PR is easy to review? Or should we use a checklist of function length, cognitive complexity etc?

In certain situations I'd argue it's a calculated risk worth taking. Let's say I'm tasked with adding a much-needed feature to an older legacy application that is built using frameworks and libraries I'm not familiar with, possibly also with with weak docs. If Claude is able to produce a self-contained piece of code that looks correct when you read through it and behaves correctly during (thorough) testing, then it sure has saved me (and my company) a lot of time and effort, even though we are deploying code we may not fully understand.

> they respond with "I don't know, claude did that"

A huge red flag right here. Its ok to not know things, its ok to use LLM to fill the gaps. Its ok to fail. It is in no way ok to not care and only fess up to having a mass of code you have no idea about when your senior reviewer asks you about it. At the very minimum the ask should go the other direction - "I got this generated code and I am not sure I understand what's going on, could you help me to see if that's the right direction" would be acceptable. Just not caring is not.

Unfortunately, the type of work you hate doing is perfect for a junior. Easy tasks to get a hold on the system.

Yup, sounds like a great opportunity to show you’re senior by mentoring.

Which will (sadly) offer you zero extrinsic benefit at almost every job, and will often actually count against you as a waste of time relative to the vast majority of productivity metrics that companies actually use.

Which is unfortunately very true. I think, that in a healthy organization such kind of mentoring requires extremely well defined boundaries and rules. Can I spend 1h of my time explaining basic stuff to a junior, who will then be able to finish his task in 2h instead of 8h? Mathematically this is a win for the company. But economically, maybe that junior dev should be fired.

That's the problem -- except in the rare type of org that thinks past quarterly or annual results and thus values training up a pipeline to be the future seniors -- economically speaking, all the junior devs should be fired, and the simple tasks they can do are the same set of tasks that can be accomplished by a senior at the helm of AI at 10-50x the speed.

There's a lot of benefits you get by mentoring. When you have to teach you're forced to think more deeply about problems, see it from different angles, and revisit questions you had when learning but tabled at that time. That last one is pretty common. There's always questions you have when learning that you have to avoid because you don't have the knowledge to answer yet, because they would take you down too deep a rabbit hole. But later you have the experience to navigate those problems.

Personally, I've learned a ton while teaching. It's given me many new ideas and insights. But I'm obviously not alone in this. Even Feynman talks about how teaching results in better learning

I don't think you have to convince the parent poster or seniors developers in general. You have to convince their employers that this is a valuable use of time.

I interpreted the extrinsic benefits differently, but fair. Still, I think being vocal about this helps. We can put pressure on our managers

Someone mentored you, pay it forward. If you think you got where you are entirely on your own, you need therapy.

Oh come on. Plenty of us here never had any form of direct mentorship at work or otherwise. It's not unusual when you pick up the trade as a hobby in your teens, and in terms of programming and technical skills (which is what we're discussing here), you stopped being a junior before getting your first job.

Myself, I learned from many folks on IRC and ol' phpBB boards, and I helped others on IRC and said phpBB boards in return; almost all of that was before graduating. That, and books, lots of books, and even more time spent just reading code online and writing my own. None of that hardly qualifies as "mentoring".

[flagged]

> If you didn’t go that route, you were still looked at as a junior. Your ego clouds your view.

your ego clouds your response.

He wasn't talking about if he was hired into a jr role, he was talking about the competency, experience, and skills acquired from the years of writing code for passion. If he could write better code, or debug problems faster than your average jr level employee.

Not everyone fits into the tiny bucket you've imagined must hold everyone. The answer could easily be, we hired you because you ticked all the boxes, but no one doing the interview could tell they were completely out classed.

If you’re employed, you’re in a bucket. It’s a cell on a spreadsheet somewhere.

I’ve yet to find a junior dev that had more skills than a junior dev. I’ve seen them try… but they are still a junior dev. If you aren’t a junior dev, then you aren’t. Mentorship has nothing to do with what bucket you’re in.

However, there are specific job duties of senior and higher that are beyond just writing code. One of them is making more seniors. There’s only one way to do that efficiently. Learning. And while you can go read a manual on how to put a Ferrari together, wouldn’t you want to work with a mechanic who has already made dozens of them?

Why do we reject help?

> I’ve yet to find a junior dev that had more skills than a junior dev. I’ve seen them try… [...] If you aren’t a junior dev, then you aren’t.

Funny, I've met plenty of jr devs that were way more competent than some of their peers who've been at the exact same company/division for 4+ years. Which was my point. The world is bigger than you can imagine. There are people with experiences that you couldn't describe, but you write in a way that feels like you want to dismiss them outright as impossible, which does a disservice to everyone involved.

> And while you can go read a manual on how to put a Ferrari together, wouldn’t you want to work with a mechanic who has already made dozens of them?

> Why do we reject help?

I feel like you and I are arguing past each other. To reuse your example: There are plenty of people who have never spent time with a mechanic, but have been spent so much time pouring over every technical manual for the car, that they can out perform guys with years working for Ferrari, while that guy working for Farrari has mentors, he still has to ask for help with most things, and needs to look up a number of the specs. But the person who exclusively taught himself, can do many of the same tasks blindfolded.

No one has said they don't want mentorship, but many were never in a position to have that advantage. But you said that if they think aquired their skills on their own, they need to seek therapy. WTF?

I'm sure you've met plenty of narcissists who have had mentors, but claim they haven't. But it's wrong, insulting and pretty toxic to lump everyone into that same group.

>but you write in a way that feels like you want to dismiss them outright as impossible

I write in a way from wisdom, from experience, the likes of which you describe as indescribable.

Ever heard the term “It takes a village”? You had mentors that you refuse to acknowledge.

>There are plenty of people who have never spent time with a mechanic, but have been spent so much time pouring over every technical manual for the car, that they can out perform guys with years working for Ferrari, while that guy working for Farrari has mentors, he still has to ask for help with most things, and needs to look up a number of the specs.

Except that guy in his garage isn’t working for BMW or Mercedes, he’s a hobbyist that has learned all about his vehicle. There’s a difference. A minor one, but it’s there. The Ferrari mechanic works on ALL Ferrari. Now, you’ll say, but there’s a car guy that can… I’ll save you the trouble. That guy isn’t applying to junior roles, isn’t asking for mentorship, he’s just a car guy. A passion about cars.

Then you’ll say: exactly my point about engineering. Which is right, I never said that it wasn’t possible that someone could selflessly throw hours away teaching themselves through trial, error, and tutorials. There are many paths. What I’m saying is, stop wasting hours and open your mouth and ask for help. There are no stupid questions, only stupid answers. Every scientific breakthrough starts with a question. Every idiot response starts with an answer. Mentorship is asking for guidance with the wisdom to know the difference.

> I write in a way from wisdom, from experience, the likes of which you describe as indescribable.

the likes of me huh?

lmao, ok mate, good job, gg you win! clearly you just better, because obviously, you're built different!

Everyone is looked at as a young person when they are young. I've definitely had "junior" colleagues that "got it" better than my 50yo colleagues. It's possible I shouldn't say that outloud, because skilled youngsters have a tendency to misidentify themselves as being part of that set while the wise youngsters have a tendency to *underestimate* their own capability or insight. But I don't think you can make that same assumption about a senior thinking back to their early years.

I desperately wish, to this day, that I had been in the position to receive mentorship. I basically hang out on HN as a way to gather it where I can. Attended engineering meetups when I was younger as well. But I never had the benefit of working with engineers senior to myself. I was a junior "business employed person" but when you need to make a roof you do what you can and learn the hard way even if there's no other humans to show you how to make a proper roof. Luckily, you can receive mentorship not just online, but through books, or even just studying the craft of others...but you take what you can get.

Receiving mentorship is such a gift, and as I approach the end of my career, I am still hungry for it, and harboring some degree of wistful envy for those that receive mentorship as an engineer. I've had many great mentors, but my for the most part, engineering mentors have never seen my face, heard my voice, or known my name, and certainly not for the first decade of my professional career as a software developer, where I didn't have any other developers to work with.

You see, the issue is you’re framing your mentorship (or lack thereof) on a very specific topic, that you are already well versed in. Why would someone give you advice in your field? You probably already know…

Mentorship is about more than just “don’t use strings directly in your squeal”, it’s about navigating the organization. Filing proper TPS reports. Encouraging refactoring. Having empathy when shit goes south. Coffee talks. Hikes. Walks. Getting to know them as a person and giving them life advice.

My best mentor taught me, if you keep looking under rocks, all you’ll find is dirt. Look up.

Of course. And I thought I acknowledged that mentorship is many things and there are many things that we need to grow as individuals. I've had a lot of great mentors in my life.

I still think you've missed the point. You can be grateful for the many gifts you've received and still wish to have had engineering guidance from a trusted mentor. There is not enough time in a life to go down every single rabbit hole; it's nice to have experienced people accurately point out where the rabbit holes are. Non-engineers are not equipped to help spot engineering rabbit holes; they might even tell you that engineering itself is ultimately a pointless rabbit hole.

But even then...that's just my own experience and my own wishes for my past self. I try to give what I wish I had had, of course.. think that's what drives most mentorship, and maybe that's the point you're trying to make, that mentorship is given out of that wistful feeling of wishing you had received advice/help and passing along the lessons that took you too long to find.

But still, if your role is getting stuck alone in the server room or whatever with a team of people who don't understand or respect what you do, good luck.

The point I was trying to make (and maybe failed because I got too focused on my own experience) is that really, not everyone gets mentors, even of the broader sort that you're referring to (which I might say are more accurately called friends or peers). But even if we widen the scope of what mentorship is, it's also perfectly reasonable for field-specific mentorship to be a cultural expectation for software engineering. I think it's a good thing to expect this of each other, and to encourage explicitly making space for the practice.

But again, however you want to widen the scope of what mentorship is, not everyone is getting it. The reason people look under rocks is because they don't know where to look. Or they do know where to look but also know they have blind spots and don't know how to get them addressed. "Look up" is nice and all, but it's a bit rude and distracting when you're trying to build something and need help understanding the foundation below your feet. Sometimes you don't need someone telling you to look up, you need help seeing where to look closer.

15 years later when the folks you mentored are sitting on hiring panels, it doesn’t seem so bad.

Obviously that’s not why I did it, but I am not unhappy about it either.

Mentorship is unfortunately broken because gone are the days of apprenticeships.

If you find a great mentor, do everything you can to learn quickly then jump ship to big tech and cash in.

This is kind of sad. I'm probably missing context here, but surely it's not necessary to rush out of a good working relationship with a good mentor. The most important things you'll learn from a good mentor can't be learned in a rush (like prioritization, project management, how to be a good mentor...).

In any case, I would replace 'jump ship' with 'pay it forward.'

A great mentor won’t waste their time on someone cynically using their time to cash out at Meta. Such a person can just get a CS degree and launch into Amazon for that.

Big Tech are just the IT enterprises of the modern day. It’s not where the action is and that experience is not so hot on the CV when it comes to early stage development.

Depends on the country, they are pretty much alive across many European countries.

Here are two examples,

A German site to search for technical schools with apprenticeship,

https://www.ausbildung.de/

The same for Portugal

https://www.escolasprofissionais.com/

There's also not much in it for the mentor other than the warm glow in the heart.

There's unfortunately a crack epidemic.

Try to quickly become a drug dealer and cash in.

---

Chef's kiss. I'd like to thank people like you for where we are.

>do everything you can to learn quickly then jump ship to big tech and cash in.

Yeah, don’t do this. Great way to ruin your reputation as a dollar chaser and be exiled to the consulting wastelands. Burning bridges takes minutes. Building them takes years.

Mentoring is a different kind of work than coding. Like senior+ level in some companies, it's just faux management - people work, with all the expectations and responsibilities of the non-technical track, but none of the status and privileges.

>How'd you get so good at debugging and navigating code you've never seen before?

>Because I spent a couple internships and a whole year as a junior debugging, triaging and patching every single issue reported by other developers and the QA team

Was I jealous that the full time and senior devs got to do all the feature work and architecture design? Yes. Am I a better developer having done that grind? Also yes.

100%. I shouldn't have done the architecture work on any meaningful scale early on, but I was always interested. My early roles were largely me being able to architect smaller pieces in a larger plan, building some architecture skills while learning larger patterns that worked and thought processes along the way.

I'd recommend that approach to anyone working with more junior devs.

That makes sense. When Claude Code suggests a bad approach, I kind of shrug it off and suggest a different approach. I don't think of it like a negative because I basically go through a similar process of ideation before I implement a feature and I typically discard ideas before arriving at the right one so Claude Code is part of the ideation process for me. The code it produces gives me a clear idea about how complex/ugly the solution will be. I know what 'ugly' looks like.

I imagine a junior might actually jump at the first solution because they don't have any other arrows in their quiver so-to-speak. The LLM is acting like the engineering manager but it's actually really bad at that.

The LLM is like a stereotypical programmer with 0 common sense. The kind who can produce good code but you have to micromanage every single decision. It's terrible if you put it in charge. It doesn't have any opinions about architecture or code quality so it just follows the structure of the existing code base... There's a tendency towards increasing complexity, more hacks more chaos.

It often tries to hack/cheat its way to a solution. It requires a constant effort to maintain order.

It’s like having a malicious mentor. But the frequency of which I’m bailing on reviews on the first line due to stupid stuff that has made it to a commit is quite stunning.

“Oh I thought that would be useful at some point so I just committed it.”

Beating it into developers that they need to review their own work they submit before asking someone else to waste time is the best way I’ve found so far.

> I don't know, claude did that

also likes to blame shop accidents on the table saw

The deciding factor for being able to effectively utilize LLMs and dodge hallucinations is ability to read code and intuition for how a solution should look. I think juniors are especially hesitant to just dig into understanding some source code unless they have no other choice, e.g. preferring to wait on email response from the author of the code over piecing things together.

This makes LLM tools so tempting, you don't even have to wait on the email response anymore! But of course, this is basically going in blind, and it's no wonder that they end up in hallucination mazes.

The problem with beginners going down the wrong path has always been there, but AI lets them go much further than before.

No amount of “own the code you generate” policies will prevent the rise of “I don’t know, the AI wrote it” excuses in the LLM era. What’s more likely is that reviewers will be flooded with unvetted, generated code. Over time, this can lead to reviewer fatigue and a gradual decline in rigor. If the trend continues, the impact could be significant once the most experienced engineers begin to retire.

If they dont know what every line does, it shouldn’t be ready for review - regardless of if they or AI wrote it initially

>I don't know, claude did that

Instant dismissal.

Honestly I made similar mistakes back before AI as a junior developer, by just copy/pasting code or confusing two things.

I think a lot of the problems lies in their prompting. AI is usually at its worst when just saying «deploy terraform module». And off it goes spitting out code.

What they should have done as juniors was to have a conversation about the topic and task first. «Help me understand …» learning and planning is especially important with LLM coding.

I don't write terribly complex things: Just data processing pipelines for neuroimaging, but I know I get good results because I take time being specific in my prompts, saying what I want, but also what I don't want, suggesting certain tools, what options I want available, how I want logs, etc. I really does help it to know what you want and relaying that with an effortful prompt.

Reply on news.ycombinator.com