> 30 minutes of patient, old school troubleshooting

This is also the best way to understand a codebase, and it's quite enjoyable.

I think the models are getting too egotistical. They're so confident of their fixes they won't bother suggesting basic techniques like isolation of the problem by disabling code paths, for example. They'll keep shotgunning less-and-less likely fixes with undiminishing confidence until the code is full of fixes that do nothing. Then they'll double down on why these should be kept.

Are your silver platters producing something faster, better, or cheaper?

Do your silver platters give you some competitive edge? If not, then is the ego problem yours, or your coworkers?

It's the uncanny valley of AI. It's still not quite good enough that you can trust it blindly on a big codebase, so you still have to read and understand everything - which is often harder than just writing it up yourself.

EDIT: don’t get me wrong. I still think AI is incredibly useful for a lot of tasks! But when implementing an architecturally hairy thing, I find it less stressful and equally quick to jump down to the editor level and use AI just for code completion.

When I hear this I do wonder to myself how they're using AI.

For me, as long as I'm properly RPI looping it and not blindly pressing "yes" then it will nearly always reach the solution, usually a fair bit quicker, because it effectively becomes an ideation machine that can keep more thoughts and knowledge in it than my brain can.

However, I'm using it through giving it the context, it has access to the repos, access to the sytems, I'm telling it where the logs are, I have docs to show it what each part of the system is for.

Along with that, it does depend on my own instincts/knowledge for me to read its response and for me to say "no, you've over-thought/engineered this and this is actually the better solution", but its very are nowadays for me that it can't find the 1 liner, as long as I've fed in the right context, mostly pre-done because I've spent a bit of time building out the context tree for the repos/systems in a way that allows it to know what it needs to know.

I'm not doubting that people spin their wheels and couldn't find the one liner, but if its as simple as you say, that does seem like people who aren't great at LLMs along with a lack of instinct/experience.

I guess in essence, I think you can use LLMs in an old school troubleshooting way, and I find it still speeds that up the majority of the time. Its basically how I use it most of the time. And like old-school troubleshooting, if you build out the LLMs context over time, it also grows in capability, as long as its being used as a tool and not blindly trusted.

Should I not assume that most senior developers who are serious about LLMs do this?

I'm seeing this happen in the security space right now. Someone on my team I was helping train and bring along is all of sudden regressing in their understanding of the issues we're working on, and instead focusing on AI tool outputs to do their job for them.

I gave the team an exact solution on a silver platter and they still failed to identify how to go about it

I think what's happening is ... poorly aligned and led engineers [in] this ego inflation feedback loop where they are completely detached from reality

A story about a team of humans with some very human problems.

I it usually doesn't get me in this weird state of mind, but I once spent 6 months (all-in) building a thing that I, once finished, just left alone completely (on disk gathering dust). Weird experience. So I'd say AI physchosis is real.

I've felt that AI can figure out and fix 90% issues, but it rarely does minimal, non invasive fixes. That still requires manual effort. But going from a broad to minimal fix is still a different skillset from actual debugging, so in the the end it does lead to skill atrophy.

Sincerely , I think you're blaming the AI incorrectly there. You just got incompetents on your payroll.

I don't think it's engineers, it's the rest of the org insulating the tech workers from every side of the business

I think LLMs have some of the same risks and benefits of stimulant drugs. They can make you more productive if used effectively as a tool, but they can also delude you into thinking you are better than you are and create a dependence such that you aren't just less productive without the LLM/drug, you fail to be productive at all because you don't know how to function without it.

If the solution is so simple, why claude did not found it? At this point we can assume, it is better than 90% of engineers (including me).

After three decades of outsourcing to lowest bidder, I do not buy that humans are somehow better!

> patient, old school troubleshooting

I usually see similar arguments around systems with major red flags (no docs, poor CI, decade ago no CVS...). And engineers with private stash of workarounds for job security!

Claude does not do anything special.

Or perhaps claude was misconfigured, it had no access to relevant part of system, and it tryied to work within its limitation. Often it means decompiling binaries in desperate loop...