AI Is Making Developers Rusty
James Pain wrote a short, uncomfortable post about a feeling many people are now circling around: AI is useful, AI is tempting, and AI can quietly make you worse at the things you used to practice every day.
The point is not that AI produces bad text or bad code. Sometimes it does. Sometimes it produces a perfectly serviceable first pass. The sharper problem is that the first pass changes the work. Instead of forming the sentence yourself, you edit a sentence that arrived already dressed up. Instead of holding a program in your head long enough to carve it into functions, you supervise a generated answer. Over time, the muscle you stop using gets weaker.
That is the anxiety underneath Pain’s post. He is not saying, “AI is useless.” He is saying the convenience has a cost, and the cost is personal.
The Trap Is Self-Doubt
The most interesting part of the piece is not the complaint about AI prose sounding synthetic. Everyone has seen that. The important part is the emotional loop around it.
Writing is hard because it exposes taste. Coding is hard because it exposes judgment. When you write the sentence yourself, you must decide what you mean. When you write the code yourself, you must decide which structure is worth committing to. Those decisions create doubt: maybe the article is unclear, maybe the abstraction is wrong, maybe someone better would do it differently.
AI offers a shortcut around that discomfort. Paste the rough thought into a model and it returns something clean. Ask for the implementation and it returns a plausible structure. The immediate feeling is relief. The hard blank page is gone.
But then a second feeling appears: this does not sound like me. This is not quite what I meant. The code works, but I do not understand its shape as well as I would if I had built it piece by piece.
The model does not remove self-doubt. It can feed it. If every uncertain moment becomes a reason to outsource the next move, confidence never gets rebuilt.
Prompting Is Not the Same Exercise
Pain says he spent a year or two prompting instead of writing code by hand, and that he is now teaching himself to code manually again. That sounds dramatic until you map it onto ordinary skill development.
Programming skill is not only knowing syntax. It is the repeated act of turning a vague problem into a concrete model, noticing edge cases, naming the awkward intermediate concepts, debugging your own mistaken assumptions, and developing a feel for when the code is getting heavier than the problem.
AI can participate in that process. It can also skip many of those steps for you.
If you ask a model to generate the implementation before you have formed your own, you may still ship something. You may even ship faster. But you did not practice the same skill. You practiced asking, steering, accepting, rejecting, and reviewing. Those are real skills, but they are not a full replacement for the act of composing the program.
That distinction matters for senior engineers, but it matters even more for juniors. Experienced developers can review AI output against years of scars. They know when an answer is too broad, too clever, too stateful, too magical, or simply pointed at the wrong problem. A newer developer may only see a working answer and miss the hidden lesson: why this shape, why this tradeoff, why this failure mode?
Research Is Starting To Rhyme With The Feeling
This is not just vibes from one blog post. Microsoft Research published a CHI 2025 paper surveying 319 knowledge workers across 936 examples of generative AI use. One finding is especially relevant here: higher confidence in the AI system was associated with less critical thinking, while higher self-confidence was associated with more critical thinking.
That matches the lived loop. When you trust the tool more than yourself, you are more likely to become an editor of its output. When you still trust your own ability to reason, you are more likely to use the tool as something to challenge, verify, and integrate.
METR’s 2025 study of experienced open-source developers found a related productivity mismatch. In a randomized trial with 16 developers working on 246 real tasks in repositories they knew well, allowing AI tools made completion time 19% longer on average. The developers had expected AI to make them faster, and even after the study they still believed it had helped.
That does not prove AI slows everyone down. METR is careful about that. It studied experienced developers, mature open-source projects, and early-2025 tools. But the result is useful because it attacks the most dangerous metric in this conversation: how fast the work feels.
Editing generated work often feels easier than creating from scratch. Easier is not always faster. Faster is not always better. And a tool that reduces effort can also reduce the amount of deliberate practice you get from the task.
The Profession Still Needs People Who Can Read And Write Code
Pain also makes a practical point: even if AI reduces the number of people writing every line manually, software development skills do not disappear. Someone still needs to know what the code means. Someone still needs to read the diff, evaluate the architecture, debug production, identify dead code, and decide whether the implementation is maintainable by people who were not in the chat where it was born.
That is where the “AI will do all the code” story becomes too thin. Software is not text generation with tests attached. It is a long-lived body of decisions. The hard part is not producing lines. The hard part is preserving a system that remains understandable after the first exciting demo.
The HN thread around Pain’s post turned into exactly that debate. Some developers described a familiar review burden: AI can produce working code, but often too much of it, requiring long cleanup sessions. Others argued the opposite: AI helps them move faster in unfamiliar domains because code is just a tool for learning something else. Both can be true.
The difference is whether AI is replacing the thinking you need to keep, or removing friction from work that was never the core skill.
A Healthier AI Workflow
The answer is not to swear off AI. That is neither realistic nor useful. The better rule is to protect the reps that matter.
For writing, make the first outline yourself. Write the ugly version before asking for critique. Use AI to find gaps, pressure-test structure, or suggest alternate phrasings after you know what you are trying to say. Do not let the model decide the point for you.
For coding, sketch the design before generation. Name the invariants. Write the smallest core yourself when the problem is teaching you something important. Ask the model for alternatives, tests, edge cases, or mechanical scaffolding. Then review the result as if you are responsible for carrying it for the next five years.
For learning, avoid asking for the finished answer too early. Ask for hints. Ask for explanations. Ask it to quiz you. Ask it to critique your implementation after you have already struggled with it. The struggle is not waste. It is where the skill forms.
For teams, judge AI work by comprehension, not just output. A developer should be able to explain the diff, delete unnecessary code, identify risks, and modify the result without going back to the model for every step. If the team can only maintain the system by continuing to prompt, the codebase is borrowing understanding from a tool that has no responsibility for the future.
The Real Warning
Pain’s post lands because it names something more specific than “AI slop.” It names a loss of agency. The sadness is not that a model can write code. The sadness is realizing that a thing you once loved doing now feels harder because you stopped doing it.
That is reversible. Skills fade with disuse, but they come back with practice. The important move is noticing the slide early enough to change the workflow.
Use AI. But do not let it take all the reps. Do not give it every blank page, every first draft, every design decision, every debugging session, every moment where your own uncertainty is the doorway into getting better.
The tool should make you stronger. If it is making you dependent, change how you use it.