Comment by jon-wood
> which unfortunately I’m becoming increasingly reliant on, even though it’s gotten me into trouble with larger projects
You could… not do this. You know it causes you problems, you consider it unfortunate that you’re becoming more reliant on it, and yet for some reason you’re choosing to continue anyway. Why are you doing that?
In a similar situation here: it's "unfortunate" in one sense but "extremely fortunate" in another sense.
It's unfortunate if you consider your primary craft to be writing code, as those skills can atrophy. It's obviously important to review and understand all material produced by these tools.
It's fortunate if your primary organizational role is "fix problems, communicate technically, and make new things" because of the sheer power of these tools when applied properly.
I've sunk many hours into attempting to "claude-ify" a complex set of applications and services and (IMO) that's a very useful activity.
Why? So that I can use ai-tooling more effectively? Yes. Why also? So that services are more decoupled, more testable, more aligned with good development principles.
It's difficult to inject these workflows in a useful way across multiple levels (code/devops/org) but when it works it's worth it.
My key takeaway was something along the lines of: "if an agent can't understand and work with your codebase, you've got an onboarding problem" (we do).
Disclaimer: mostly standard web tech across Java/Scala/React - aggressively complex k8s layer