Hey everyone,
The useful argument for working professionals and newer engineers right now is not which assistant you opened. The useful argument is whether you can still explain the system after the assistant finishes typing — and whether you use AI to learn the system instead of skipping the practice that makes that explanation possible.
Hi, I am Robert Massey, a software engineer and computer science professor with twenty-plus years in the trenches. Software engineering is still the work of engineering solutions with software. Programming remains a practiced skill inside that work. An assistant can shorten the first draft. It cannot complete the practice for you.
What the Anthropic trial actually measured
That distinction got a hard number this year. Anthropic researchers Judy Hanwen Shen and Alex Tamkin ran a randomized trial with 52 mostly junior Python engineers learning Trio, a library none of them already knew. Half used an AI sidebar that could produce the correct code on demand. The other half wrote by hand. On a quiz covering concepts they had used minutes earlier, the AI group averaged 50 percent and the hand-coding group averaged 67 percent, nearly two letter grades apart. The widest gap sat on debugging questions, which remains the skill you need when generated code is wrong. The AI group finished about two minutes faster, and that difference did not reach statistical significance. The sample was small, and the quiz measured immediate comprehension rather than skill six months later. I am not treating one trial as destiny. I am treating it as a warning that matches what I see when people cannot narrate a change they just shipped.
The Next Web later called the junior-engineer version never-skilling: a novice never builds the skill in the first place. Deskilling is the older problem, where practiced experts get rusty. Never-skilling is the awkward one for teams that hire newer engineers and then wonder why on-call feels thin.
How to use AI to learn the system without never-skilling
I am not using this as a reason to ban the tools. I use those assistants on real work. The trial also showed that how you use the assistant mattered more than whether you opened the sidebar. People who scored well asked conceptual questions, requested explanations beside the code, or generated a draft and then interrogated that draft. People who scored poorly delegated the whole task, or handed the assistant the debug loop and waited for a patch. The first group treated the model as a tutor. The second group treated it as a ghostwriter.
Red Hat engineer Andriana Theodorakopoulou made the same practical point on September 7. When steering the prompt costs more energy than writing the logic yourself, take the keyboard back. Treat generated code as code written by someone else until you can defend it. If the assistant always does the difficult part, you stop building the mental model that later lets you catch a bad change. Bad code can be reviewed in a diff. A missing mental model is much harder to notice in a stand-up — the same verification tax shows up when speed outruns understanding.
Workplace examples that keep showing up
Here is a workplace example built from patterns I keep seeing. A newer engineer on a claims eligibility service asks the assistant for retry logic around a downstream payer timeout. The draft arrives with jitter and a max-attempt constant. Two weeks later the on-call rotation sees duplicate eligibility checks at 02:14, because the retry ran inside a request the API gateway was already retrying. Nobody on the thread can explain, without reopening the assistant, where the attempt counter lived or why the idempotency key was missing. The generated code was cheap to produce. The understanding never arrived with the diff.
Here is a second example for working professionals. A reporting engineer needs a census query that excludes observation beds and still counts a patient who transferred units at midnight. The assistant produces a join that compiles and returns a plausible headcount. By afternoon a nurse manager is staring at a double-counted unit, and the engineer cannot say whether the window function or the exclusion list is the liar. That is not a model failure first. That is a skill-practice failure. The person closest to the change never reconstructed the grain of the data before they accepted the draft.
What managers are already signaling
Gartner predicted that through 2026, atrophy of critical-thinking skills from generative AI use would push half of global organizations toward AI-free skills assessments. Treat that figure as a forecast, not a headcount. Managers already want people who can use the tools, and they also want people who can still think when the tools are wrong. Those two wants only look like a contradiction if you assumed the shortcut and the skill were the same road. Leadership commentary keeps adding the same coaching note: seniors still need to hand people real problems once assistants take the starter tasks. That pairs with the same delivery lesson I keep writing about: AI speeds up typing, it does not retire the SDLC.
What you can do this week without turning work into a monastery
Start new work with a conceptual question before you ask for a patch. “What does this library guarantee about cancellation?” is a better first prompt than “write the feature.” If you cannot phrase the concept, you are not ready to evaluate the diff.
Write a five-sentence explanation of the change in your own words before you merge it. If those sentences collapse into “the assistant said this is the standard pattern,” you do not own the change yet. Paste the explanation into the ticket.
Give yourself ten minutes with a failing test or a stack trace before you paste it into chat. Form one concrete hypothesis about the failure, and name the module you would open first. Then use the assistant to challenge that hypothesis, not to skip it. The control group in the Anthropic study hit errors and had to resolve them.
When you are learning a library or protocol you do not already know, write the first version yourself and only then compare it with a generated draft. On familiar boilerplate, let the assistant type. On unfamiliar ground, keep the struggle in your own hands.
If the prompt steering has gone in circles, stop prompting and write the function. Red Hat called that the prompting overhead threshold, and it is a professional habit rather than a purity test.
When the assistant also writes the tests, compute the expected result from the requirement before you look at what the function returned. If the assertion is just the implementation talking to itself, you did not verify behavior. Writing the expected value by hand is a small step, and it is also practice.
What stays true in 2026
None of this means you should pretend 2026 never happened. I want the assistant to take the mechanical work so I can spend more time on design, diagnosis, and the parts of the software lifecycle that still require judgment. That only works if the person still has a system-shaped mental model. Cognitive offloading is fine when you already own the skill. It is expensive when you are still forming it. If you are building calmer personal AI habits at the same time, start with how working professionals can use AI to improve daily life without losing control.
If you are a newer engineer, pick one workflow this week where you ask for an explanation first and a patch second. If you are a working professional leading a team, pick one ticket where someone has to walk the change without the chat log open. The goal is not slower typing. The goal is engineers who can still debug the software they are responsible for.
If this article helped, drop a comment with the first workflow you want to try this week. Support the shenanigans buying me a coffee on Ko-fi, and follow Attune IT on YouTube or me on X.