[ToJans]

Whenever I'm rate limited (pro max plan), I stop developing.

For anything but the smallest things I use claude code...

And even then...

For the bigger things, I ask it to propose to me a solution (when adding new features).

It helps when you give proper guidance: do this, use that, avoid X, be concise, ask to refactor when needed.

All in all, it's like a slightly autistic junior dev, so you need to be really explicit, but once it knows what to do, it's incredible.

That being said, whenever you're stuck on an issue, or it keeps going in circles, I tend to rollback, ask for a proper analysis based on the requirements, and fill in the details of necessary.

For the non-standard things (f.e. detect windows on a photo and determine the measurement in centimetres), you still have to provide a lot of guidance. However, once I told it to use xyz and ABC it just goes. I've never written more then a few lines of PHP in my life, but have a full API server with an A100 running, thanks to Claude.

The accumulated hours saved are huge for me, especially front-end development, refactoring, or implementing new features to see if they make sense.

For me it's a big shift in my approach to work, and I'd be really sad if I have to go back to the pre-AI area.

Truth to be told, I was a happy user of cline & Gemini and spent hundreds of dollars on API calls per month. But it never gave me the feeling Claude code gave me, the reliability for this thing is saving me 80% of my time.

[dontlaugh]

I still don’t get why I should want that.

I’ve mentored and managed juniors. They’re usually a net negative in productivity until they are no longer juniors.

[quesera]

My current working theory is this:

People who enjoy mentoring juniors are generally satisfied with the ROI of iterating through LLM code generation.

People who find juniors sort-of-frustrating-but-part-of-the-job-sometimes have a higher denominator on that ROI calc, and ask themselves why they would keep banging their head against the LLM wall.

The first group is probably wiser and more efficient at multiplying their energies, in the long term.

I find myself in the second group. I run tests every couple months, but I'm still waiting for the models to have a higher R or a lower I. Any day now.

[aniforprez]

It's the complete opposite for me. I enjoy the process of mentoring juniors and am usually sought out for a lot of little issues like fixing git workflows or questions on how a process works. Working with an LLM is absolutely not what I want to do because I'd much rather mentees actually learn and ask me less and less questions. My experience with AI so far is that it never learns at all and it has never felt to me like a human. It pretends to be contrite and apologises for mistakes but it makes those mistakes anyway. It's the worst kind of junior who repeats the same mistake multiple times and doesn't bother committing those to memory.

[quesera]

You're right, I'm probably lumping the first group over-broadly, since I understand them less well.

It would make sense for there to be subgroups within the first group. It sounds like you prioritize results (mentee growth, possibly toward long-term contribution), and it's also likely that some people just enjoy the process of mentoring.

[moomoo11]

I'm cynical person, and IME the former are some of the most annoying and usually the worst engineers I've met.

Most people who "mentor" other people (like, make it a pride and distinction part of their identity) are usually the last people you want to take advice from.

Actual mentors are the latter group, who juniors seek out or look up to.

In other words, the former group is akin to those people on YouTube who try to sell shitty courses.

[quesera]

That's the extreme end of the first-group spectrum, but I definitely agree that they exist!

[ToJans]

It depends... I've worked with hundreds of juniors & seniors during my consulting days.

I've had ups and downs in this situation, but on most cases it's about showing the light to a path forward.

In most cases, the software development was straightforward, and most of the coaching was about a how to behave in the organisation they were functioning in.

One can only have so many architecture/code quality reviews, typically we evacuated the seniority of the devs on their ability to cope with people (colleagues, bosses, clients, ...)

We did have a few very bright technical people as well, but those were about 10 on a 2000-person company.

The reason I explicitly mentioned the slightly autistic junior person, is because I've worked with one, who was about to be fired, because other people had issues dealing with him.

So I moved desks, sat next to him for over a month, and he ended up becoming the champion for one of the projects we were doing, because he was very bright, precise and had a huge memory, which mattered a lot in that context.

Other stories are similar, once they were about to throw out a colleague because he was taking days to do something that should have taken a few hours max. So I say next to him, to see what he was doing.

Turned out he was refactoring all the code his feature touched because he couldn't stand bad code. So we moved him to quality control, and last time I checked he was thriving...

I guess what I'm saying is that -just like with people -, you need to find a good modus operandi, and have matching expectations, but if you can figure it out, it will pay off dividends.