[hibikir]

You don't even have to go outside engineers. I have teammates that get very little out of Claude Code because the way they integrate their own knowledge doesn't allow them to think of what Claude might not know. They'd say a task was impossible with the tooling, and I'd get instant answers, because I understand what is weird internal business logic sitting 6 repos away, and what is knowledge claude has by default. I can commit Claude.md files for them, but I have to include EVERYTHING, because otherwise they'll let Claude make assumptions and waste minutes, if not hours.

It's a big part of what, in my experience, is separating the very good engineer from the iffy one: Do you have a good mental model, and can you put yourself in the shoes of people sitting in a different mental model? It makes you a better dev, and even more so when it comes to AI tools, which have their own kind of alien brain.

[gcanyon]

Coding LLMs are distilling developers. It's like the old experiment where you have someone write down the steps to make pancakes and they don't tell you to crack the eggs before adding them to the batter: it takes a particular mindset to be able to make a model of what is supposed to happen and deconstruct that to the level appropriate for implementation.

Until now, the actual act of writing code: terminology, syntax, etc. was a significant hurdle, and that underlying mindset was a very useful, but missing in a surprisingly large number of developers, skill.

Now with LLMs doing the work of "translate this into code," increasingly the only thing that matters is that exact ability. And developers that don't have it or can't develop it won't be developers for long.

[rimliu]

or when LLMs won't be able to run on non-existing money any more the scenario will be the opossite.

[ohmahjong]

Thanks for putting into words what I have been seeing a lot at work and haven't been able to put my finger on. We tend to have quite diverse _workflows_ between devs at my company, and success seems to correlate with injecting better context earlier in the process.

I like to chat with Claude about how to approach a given problem, bring in extra context, etc, before even really drafting up a plan, while other people dive into implementation immediately and go on wild goose chases.

90% of the time we end up in the same place in roughly the same amount of time, and there are obviously tradeoffs to spending more time planning vs implementing. I'm oversimplifying as well.

[acron0]

I couldn't agree more. Socratic methodologu, domain modelling, systems thinking, pipes-and-arrows problem solving etc. These are the skills that get real work done in coding agents these days.