Somewhere in the last few years, "good at your job" and "good at your craft" quietly stopped meaning the same thing for software engineers, and alm...
For further actions, you may consider blocking this person and/or reporting abuse
This is something I think about a lot actually.
For me the danger isn’t AI writing code. It’s getting into the habit of handing off the thinking the second something becomes difficult.
There’s a huge difference between using AI to move faster through work you understand and using it to avoid ever sitting with a problem long enough to understand it.
I actually think learning how to use these tools without letting them replace your own curiosity, debugging instincts, and willingness to investigate things is becoming a skill in itself.
The productivity boost is real. I just don’t think productivity should be confused with learning.
YES. This is exactly the part I keep circling back to.
I’m not scared of AI writing code. I’m scared of getting so used to instant answers that the second I hit friction my brain goes “eh, hand it off.” 😭
Because that friction is usually where the learning actually is. The weird bug. The thing that makes no sense. The 45 minutes of staring at logs until something finally clicks and suddenly you understand the system differently than you did before.
I use AI constantly, so this isn’t me pretending the answer is “just code everything manually.” Absolutely not lol. I think the skill now is knowing when AI is accelerating understanding and when it’s replacing it.
That line gets blurry really fast when productivity is rewarded immediately and understanding only proves its value later.
And I love how you phrased this: curiosity, debugging instincts, and willingness to investigate are becoming skills we have to actively protect. That’s basically the whole thing for me. 💚
Exactly. I think that “knowing when AI is accelerating understanding and when it’s replacing it” is the part people are still figuring out.
I’ve definitely caught myself asking AI something I probably could have solved if I’d just sat with it for another 10 minutes. And sometimes I deliberately make myself stop and investigate first, because I don’t want to train myself out of that instinct.
The weird part is that AI can absolutely make you better at learning too, if you use it to explain, challenge, or help you investigate instead of just handing you the answer. It really comes down to how you use the shortcut.
This is a really important discussion. I don't think the biggest risk is AI writing code, but losing the habit of struggling with problems before asking for an answer.
Debugging, reading unfamiliar code, and figuring out why something works are the moments where engineering intuition is built. AI can remove a lot of friction, but if we remove all the friction, we might also remove some of the learning process.
The goal shouldn't be choosing between AI and fundamentals. It should be using AI as a tool while still keeping the thinking part of engineering alive.
yesss this is exactly the distinction I was trying to get at. I’ve noticed the biggest learning happens when I resist immediately asking AI to fix something and spend some time understanding why it broke first. I still use AI heavily, but I’m trying to make sure it accelerates the work without replacing the part where I build the mental model.
Exactly. I think the interesting part is that the goal isn't to keep struggling just for the sake of struggling. Sometimes the fastest way to learn is to struggle first, build your own mental model, and then use AI to challenge it, explain another approach, or help you move faster.
That changes the role of AI from “solve this for me” to “help me think through this.”
For me, that's a much healthier way to use it as an engineer.
The economic trap here is that management metrics track flow rather than capital stock. Closing tickets faster registers immediately as higher labor productivity, while the erosion of system intuition is an unbooked depreciation expense. Organizations effectively borrow against future incident response capacity to inflate current velocity. The cost only shows up during an outage or major refactor that lands outside the model's training distribution, when the firm suddenly discovers that nobody on call holds the actual state transitions in their head.
Yess this is such a good way to frame it. “Unbooked depreciation expense” especially gets at something I was struggling to articulate.
The scary part is that the dashboard can look better while the system’s human knowledge is quietly getting worse. More tickets closed, shorter cycle times, higher output — all measurable immediately. But “how many people actually understand why this system behaves the way it does?” usually isn’t measured at all.
And like you said, you don’t discover that debt until the abstraction breaks: a weird production incident, a major migration, or a problem the model hasn’t effectively seen before.
That makes me think engineering orgs probably need to start treating maintained human understanding as infrastructure, not just assume it naturally comes along with shipping code. Really appreciate this perspective.
Writing small code batches is always my way to remember myself that I haven't forgotten the basics. It's comforting to have rules you can actually check. The judgment-based stuff is where I still feel lost, like 'don't over-engineer' when I honestly can't tell yet where the line is. Btw the Scrum example was spot on. Is there a way you'd teach judgment to someone early on, other than 'you'll get it with time'?
Honestly I think judgment can be taught earlier than we usually admit, but probably not as a list of rules. What helped me was learning to ask questions like: “What problem am I solving?”, “What happens if I don’t build this?”, and “Can I explain why this complexity exists?”
I’m still developing that instinct too. I think the trick is getting lots of small opportunities to make a decision, see the consequence, and then reflect on whether the extra complexity actually bought you anything.
That’s probably why small projects have taught me so much. the feedback loop is short enough that I can actually see when I’ve over-engineered something 😅
I agree that you can definitely get more tasks completed but at the prise of not actually knowing what was actually done looking at the bigger picture and you can easily lose focus and tracking your progress can get really "cloudy" because of using too much AI to multi-task everything.
This is a really interesting perspective. I especially agree with the difference between being productive and actually improving our engineering skills.
AI can help us move much faster, but if we always skip the struggle of understanding and debugging a problem ourselves, we may also skip some of the learning that comes with it.
Finding that balance is probably one of the most important skills for developers working with AI.
That’s exactly the tension I was trying to get at. AI can compress the time between “I have an idea” and “it works” like crazy, but that same compression can remove the part where we actually build the mental model underneath it.
I don’t think the answer is using AI less so much as being intentional about where we refuse to outsource the struggle, debugging, tracing why something broke, explaining the code back to ourselves, etc.
The goal should be faster and better, not faster instead of better. Appreciate you reading 💚
I think we’re heading in a direction similar to how hand-woven crafts were replaced by machine-made products.
Machines can produce far more, faster and more consistently, but the result often becomes standardized — the same patterns, the same designs, and sometimes a blandness that comes from optimizing for scale.
Hand-woven work is slower and harder to produce, but it carries creativity, uniqueness, and the human touch.
I wonder if AI-assisted engineering will create a similar trade-off: much higher productivity, but potentially less originality and deeper craftsmanship if we stop developing those skills ourselves.