Coding Without AI: A Skill Some Are Starting to Miss

A Hacker News user posted a simple but uncomfortable question this week: I haven't written code without AI in a long time and I miss it. How do I get back to it without just defaulting to AI again? The question has few upvotes and no comments yet, but the fact that someone is voicing it aloud says quite a bit about where we stand in May 2026.

It's not a complaint about AI or a call for rejecting technology. It's more like the feeling someone describes after years of using a calculator and suddenly realizing they no longer remember how to do long division. The tool worked so well that it replaced the skill.

What's Behind the Question

The adoption of code assistants has been so rapid and so thorough that for many developers, the natural work cycle already includes Claude Code, GitHub Copilot, or similar tools as an inseparable part of their environment. Not as an optional add-on, but as a layer that's always there. You write, it suggests, you accept, you adjust. The loop becomes automatic.

The problem the thread author describes isn't that AI produces bad code, because in many cases it produces perfectly functional code. The problem is a loss of agency over the process. There's a difference between solving a problem and overseeing how someone else solves it. Both can produce the same result, but the cognitive experience is different, and for some developers that difference matters.

This isn't new in the history of the profession. It's happened before with IDEs versus plain text editors, with frameworks versus hand-written SQL, with dependency managers versus manually copying libraries. Each leap in abstraction has had its defenders and skeptics. What's different now is the speed and depth of the leap: Claude Opus 4.7 with a million token context window can sustain practically any complex project in a single session, making the temptation to delegate almost constant.

Who This Debate Matters For

This kind of reflection doesn't interest everyone equally. For a developer working in a team with tight deadlines, the efficiency that assistant tools provide is a hard argument to counter. No one asks the carpenter to reject the electric saw.

But there are profiles for whom the question carries more weight:

• Developers who are learning: if the model solves the exercise, learning doesn't happen. AI can be a shortcut that closes the learning window right when it should be open.
• Senior developers who want to maintain technical judgment: overseeing a model's output without understanding it well is a form of cognitive debt. If you never write code from scratch again, your ability to evaluate generated code can degrade without you noticing.
• Those who code as a creative or recreational activity: some people code for the pleasure of the problem, not the result. For them, delegating to an agent removes precisely the part that interests them.

Strategies That Usually Come Up in These Discussions

Although the original thread hasn't generated responses yet, this conversation has popped up in variations across different communities. The most common approaches mentioned are:

• Deliberately constrained environments: use an editor without AI extensions, or program in a language or context where models are less useful (assembly, specific platform constraints, offline programming puzzles).
• Personal projects with self-imposed rules: decide in advance that a specific project gets done without assistance, the same way someone might decide to hike a route instead of driving.
• Code katas and exercises: platforms like Exercism or Advent of Code in offline mode. The playful context reduces the urgency to find the answer quickly.
• Reviewing your own old code: rereading and modifying code written years ago, when the habit of delegating didn't exist, can help you get back into the rhythm.

None of these strategies is technically sophisticated. They all mainly require deliberate choice, which is exactly what automation tends to erode.

Opinion

That someone formulates this question in 2026 doesn't suggest that assistant tools are a mistake; it suggests their adoption has been fast enough that some developers haven't had time to consciously decide how they want to integrate them. That deserves more attention than it usually gets.