Preserving Your Craft in an AI-First World

---

A few months ago, I watched a mid-level engineer on my team debug a production incident. The service was returning intermittent 502 errors. He opened his AI assistant, described the symptoms, and got back a suggestion to increase the timeout on the upstream gateway. He applied the fix, deployed it, and the errors stopped.

Two days later, the errors came back — worse. The real issue was a connection pool leak caused by a retry loop that never released sockets. The gateway timeout change had merely masked the symptom long enough for the pool to refill.

When I sat with him and asked him to walk through the connection lifecycle, he couldn't. Not because he was a weak engineer — he was sharp, thoughtful, and genuinely capable. But because he had spent two years leaning on AI tools to fill the gaps in his understanding. The tool had been so consistently good enough that he'd never needed to build the mental model himself.

That incident crystallized something I'd been noticing for a while: we are in the early stages of a craft erosion problem, and most engineers don't recognise it while it's happening.

The Craftsman's Dilemma

There's a useful question from the philosophy of technology: when a tool does the work, does the craftsperson still need to understand the trade?

A cabinetmaker who uses a CNC router still needs to understand wood grain, joint strength, and structural integrity. The machine executes the cuts, but the human decides what to cut, why, and what to do when the machine gives an unexpected result. If the cabinetmaker loses that underlying knowledge, they become an operator — someone who feeds inputs and accepts whatever comes out.

The Swiss watchmaking tradition has a version of this principle too: even in an era of precision machinery, master watchmakers are trained on hand tools first. The reason isn't nostalgia. It's that understanding the mechanism at the manual level is what gives you the judgment to diagnose problems that the machinery can't explain.

Software engineering is facing the same inflection point. AI can generate code, write tests, draft architecture docs, and suggest deployment strategies. These tools are genuinely valuable — I use them every day. The question is whether we're quietly deskilling ourselves in the process.

The Calculator Effect

In the 1970s, when electronic calculators became cheap enough for classrooms, educators raised a concern: if students always have a calculator, will they lose the ability to do arithmetic? Decades later, the answer is a qualified yes. Most adults today struggle with mental arithmetic that would have been unremarkable for their grandparents.

Was that a disaster? Mostly no. Calculators freed cognitive capacity for higher-order thinking, and that trade-off was worth making. But there's a subtle cost: when you don't understand the fundamentals, you lose your intuition for when the calculator gives you a wrong answer.

The engineering equivalent is already visible. I see it in code reviews where engineers can't explain the algorithmic complexity of the code they submitted. In architecture discussions where someone proposes a design from ChatGPT but can't defend why it's appropriate for their specific system constraints. In incident responses where engineers paste error logs into AI tools rather than forming hypotheses and narrowing the search space themselves.

The calculator effect in software engineering isn't about losing the ability to write a for-loop by hand. It's about losing debugging intuition, architectural judgment, and system-level thinking — the skills that distinguish a senior engineer from someone who operates an AI tool.

What AI Cannot Replace

Let me be specific about the capabilities that remain stubbornly, irreducibly human.

System thinking. The ability to hold a mental model of how dozens of services, databases, queues, and caches interact — and to predict the second and third-order consequences of a change. AI can describe individual components in isolation, but it cannot hold the full context of your system's history, its political constraints, its undocumented quirks, and the institutional knowledge accumulated from three years of incidents.

Debugging intuition. That instinct that says "this feels like a race condition" before you have any evidence to support the hypothesis. It comes from years of pattern recognition across hundreds of bugs in dozens of systems. AI can suggest possible causes from a list. It lacks the contextual judgment to know which hypothesis is worth pursuing first in your system, right now.

Architecture judgment. Knowing when microservices are the right call and when they're over-engineering for your team's current size and skill distribution. Understanding that the textbook-correct solution will be unmaintainable given your operational reality. This requires wisdom built from experience — including the experience of having made the wrong architectural call and living with the consequences.

User empathy. Understanding that the API consumer is a frustrated frontend developer at 2 AM trying to ship before a deadline. Designing error messages, response formats, and documentation with that human reality in mind. AI generates technically correct interfaces. Humans design humane ones.

These aren't soft skills. They're the hardest skills in engineering, and they're built through years of deliberate, sometimes uncomfortable experience that AI shortcuts bypass entirely.

The Deliberate Practice Framework

I've started advocating for what I call "analog engineering hours" — intentional, scheduled blocks of time where you code without AI assistance.

This isn't Luddism. I use AI tools every day and they make me measurably more productive. But I've learned to recognise the difference between productivity and learning. When I use AI to generate a database migration, I ship faster. When I write it myself, I notice edge cases, think through rollback strategies, and deepen my understanding of the schema's evolution. Both have value. Neither replaces the other.

Here's the framework:

Weekly: Two hours of analog code. Pick a task that genuinely stretches your current understanding — not boilerplate, but something that forces you to read documentation, reason through trade-offs, and debug your own mistakes. The goal isn't the output. It's the muscle memory of working through problems from first principles.

Monthly: One small project end-to-end without AI. A CLI tool. A data pipeline. A caching layer. Something complete enough that you encounter the real-world complexity that AI always smooths over in demos. The artifact doesn't matter. The thinking process does.

During incidents: Turn off AI completely. Incidents are the ultimate learning accelerator. The pressure of a production outage forces you to build exactly the mental models that AI erodes. If you paste the error into an AI assistant, you get a suggested fix. If you trace the problem yourself, you get understanding — and that understanding protects you in the next incident, and the one after that.

The athletes who perform best under pressure train without equipment assistance. The same principle applies here.

Understanding vs. Generating

There's a distinction I want every engineer to internalize: generating code and understanding code are completely different cognitive activities.

When AI generates a solution, you receive an output. When you understand that solution, you can explain why it works, predict where it will fail, modify it confidently under pressure, and teach it to someone else. If you can't do all four of those things, you don't understand the code — you're hosting it.

I apply a simple test to AI-generated code before I accept it: could I explain this to a junior engineer without referencing the AI prompt or the original conversation? If the answer is no, I don't merge it. I either rewrite it in a way I genuinely understand, or I spend the time to learn why the AI's approach works before accepting it.

This isn't optional discipline. It's the difference between an engineer who uses AI and a human clipboard.

The Senior Engineer's Shifting Role

If you're a senior or staff engineer, your role has shifted significantly — whether you've formally acknowledged it or not.

You're no longer the person who writes the most code or writes it the fastest. AI has commoditised raw code production in ways that will only accelerate. Your value now lies in curation and direction: deciding what to build, evaluating whether AI-generated solutions are architecturally sound, catching the subtle mistakes that pass code review but cause incidents six months later, and developing the judgment in junior engineers that no AI tool can develop for them.

Think of yourself as an editor-in-chief, not a journalist. The journalists — AI tools, junior engineers using AI — produce volume. You provide judgment, taste, and quality control. You see the story arc that connects individual pieces into a coherent, maintainable system.

This means investing more time in code review, architecture review, and mentorship. Less time in heads-down coding. Stronger opinions about design patterns, system boundaries, and operational excellence. Being the person in the room who asks "what happens when this fails at 3 AM?" when everyone else is focused on the happy path.

Building a Learning Discipline That Compounds

The engineers who thrive in five years are building a learning discipline today. Here's what I recommend:

Read source code, not just documentation. Pick an open-source project you depend on and read its internals. Understand how your ORM actually manages connections. Trace how your framework handles middleware chaining. This builds the deep understanding that no AI summary can replicate.

Write explanations of things you think you already understand. The act of writing exposes gaps with ruthless efficiency. If you can't explain your authentication flow from first principles, you've just found your next learning target.

Teach others. Mentoring junior engineers is the most selfish thing you can do for your own growth. Their questions will reveal your blind spots. Their confusion will force you to articulate concepts you've been taking for granted.

Invest in fundamentals that don't deprecate. Networking, operating systems, database internals, distributed systems theory — these don't go out of date. While the tools change every year, the principles underneath have been stable for decades. Every hour invested in the layer that doesn't deprecate pays dividends across every new tool that appears above it.

The Promise I'd Make to You

I'm not worried about AI replacing engineers. I'm worried about engineers replacing themselves — by outsourcing so much of their thinking to AI that they become unable to function without it, precisely when the stakes are highest.

The engineers who will thrive are not the ones who use AI the most. They're the ones who use AI strategically while maintaining the independent ability to reason about software systems. They treat AI as a lever — a tool that amplifies existing strength — not a crutch that compensates for understanding they never built.

Your craft is not the code you write. Your craft is the judgment, taste, and understanding you bring to every technical decision. AI cannot take that from you. But you can give it away, one lazy shortcut at a time.

Protect it deliberately.

Key Takeaways

• The calculator effect is real. Over-reliance on AI erodes debugging intuition, architectural judgment, and system thinking — the exact skills that define senior engineers. Recognise this before it becomes a problem.
• Practice analog engineering. Intentionally code without AI assistance weekly. Incidents without AI assistance are your highest-leverage learning opportunities.
• Understanding ≠ generating. Apply the "teach it back" test to every piece of AI-generated code before you merge it. If you can't explain it, you don't own it.
• Senior engineers are now editors. Your value is in curation, direction, and judgment — not raw code output. Invest accordingly.
• Invest in fundamentals that don't deprecate. The principles underneath the tools outlast every framework and model release.
• Your next step this week: Identify one area where you've been consistently relying on AI without fully understanding the output. Schedule two hours this week to work through that problem type without AI assistance. You'll know within an hour whether there's a gap you need to close.