AI Didn’t Make You Lazy. It Made the Hamster Wheel Obvious.
We have spent decades confusing effort with meaning, friction with craft, and exhaustion with value. Then AI removed some of that friction—and some of us discovered we had no idea what we wanted beyond the wheel.
“AI made me lazy.”
I keep seeing this confession.
AI made me stop thinking. AI made me stop learning. AI made me care less about my work. AI turned me into a hamster on a wheel, feeding tickets into a machine and checking whatever came out the other side.
I believe the feeling.
I reject the verdict.
AI can absolutely make it easier to avoid thinking. It can generate enough plausible-looking work that you begin accepting answers before you understand the questions. A workplace can use it to strip ownership from skilled people, turn developers into exhausted quality-control operators, and call the resulting misery “innovation.”
That is real.
But when your work becomes an endless cycle of moving tickets from one column to another, I am not convinced AI created the hamster wheel.
I think it made the wheel impossible to ignore.
And I think some of us have developed what I can only describe as Repetitive Stress Stockholm Syndrome.
It is the attachment we form to the repetitive strain that once proved we were useful.
We defend the tasks that exhaust us because we have spent years using them as evidence that we deserve to be here. We become emotionally attached to the friction because overcoming that friction has become part of our identity. We call the wheel our craft because we became very, very good at running on it.
Then somebody automates part of the wheel.
Suddenly, the motion stops.
The open door feels less like freedom and more like unemployment.
The silence feels less like opportunity and more like failure.
And rather than ask what we could do outside the cage, we blame the thing that opened it.
I Believe You. Stop Anyway.
Let me be clear about something before I go any further.
When someone says AI is damaging their mental health, separating them from their work, or making them feel intellectually diminished, I believe them.
Stop using it.
You do not owe a tool your well-being. You do not owe an employer your participation in a workflow that is making you miserable. You are allowed to draw a boundary around the parts of your craft that you need to perform yourself.
Walking away may be the healthiest and most principled decision available to you.
But a personal boundary is not a universal theory.
“This relationship with AI harmed me” is a powerful and important statement.
“AI inevitably makes people lazy, careless, and worse at their craft” is a much larger claim.
That is where I disagree.
Tools shape our behaviour, but they do not independently author our values. AI can amplify passivity, but it can also amplify curiosity. It can accelerate careless production, but it can also accelerate testing, documentation, accessibility work, experimentation, teaching, and the ridiculous little projects we have been postponing for years.
It can help you run faster on the wheel.
It can also help you get off.
The difference is not merely the model.
The difference is what you believe your work is for.
The Wheel Was Never the Work
Back when I worked in an agency, compiling software sometimes meant waiting.
The build would start, the computer would become occupied, and I would head to the kitchen for a coffee.
While I was there, I would talk to people.
I would ask a junior developer how a problem was going. I would make sure they felt supported rather than merely supervised. I would hear what another person was building and realize that two projects shared the same underlying problem. I would check whether advertising metrics were moving in the right direction, whether server logs looked healthy, whether backups were running, and whether someone had quietly become stuck without feeling comfortable enough to say so.
The compiler was working.
So I did something else.
Something human.
I was not failing to work because my hands were not touching the keyboard. I was participating in the wider system around the code. I was listening, teaching, learning, connecting, noticing, and supporting.
The pause created room for leadership.
Today, I can automate some of the things I used to check manually. I can make monitoring more dependable. I can make testing more repeatable. I can make deployments less dramatic. I can allow an agent to perform a first pass on a repetitive implementation while I investigate the parts that are less obvious.
That does not leave me with nothing to do.
It lets me go further.
It gives me more time to sit with a junior and ask why they chose a particular architecture. It gives me more time to test the assumptions underneath a feature instead of merely confirming that the feature appears to work. It lets me explain the history behind a decision, the tradeoffs we made, and the mistakes I would rather they not have to repeat.
A faster build did not make me less of a developer.
It made me more available as a human.
The pause was never the problem.
The question was always what I chose to do with it.
Automation Creates Space, Not Purpose
Automation does not create meaning.
It creates space.
What fills that space depends on the person, the workplace, and the incentives surrounding the tool.
A company can take the three hours an employee saves and reward them with six more hours of tickets. It can measure every improvement as an opportunity to raise the quota. It can use AI to increase throughput without giving employees more autonomy, more time to think, or any greater participation in deciding what should be built.
That is not liberation.
That is Taylorism with tokens.
A faster wheel is still a wheel.
If AI reduces your work to feeding requirements into a machine, reviewing more output than any person can meaningfully understand, and accepting responsibility for decisions you were never given time to examine, the resulting alienation is not imaginary.
But I would place the blame more carefully.
The problem is not simply that a machine wrote code.
The problem is that the workplace decided code volume was the purpose.
It treated your judgment as a bottleneck, your curiosity as inefficiency, and your craft as nothing more than the conversion of tickets into output. AI did not invent that philosophy. It inherited it, accelerated it, and made its emptiness much more visible.
That visibility can be terrifying.
It can also be useful.
There is an old, intentionally rude saying:
If you’re bored, then you’re boring.
I do not use that line to sneer at depression, exhaustion, or burnout.
Burnout is not laziness. Depression is not a failure of imagination. Sometimes what looks like boredom is a nervous system finally collapsing after years of surviving on urgency. Sometimes the first responsible use of reclaimed time is to do absolutely nothing.
Take the nap.
Sit outside.
Play with your children.
Make a coffee and stare through a window without turning the experience into a productivity exercise.
Rest is not stagnation.
Recovery is not a failure to capitalize on efficiency.
But once you have rested—once the adrenaline has left your body and the silence no longer feels like danger—the empty space still asks a question:
What do you care about when nobody is assigning it to you?
That is a difficult question.
The hamster wheel never required an answer.
“I’m Done” Is a Sin
To say “I’m done here” while working on a website is nearly a sin in my mentorship.
Not because everything must be polished forever.
Not because every employee should donate unlimited unpaid labour to an employer.
Not because software can never be released until it achieves some imaginary state of perfection.
“I’m done” bothers me because it often means:
It worked once, on my machine, under the conditions I expected, so I stopped looking.
The page renders.
Wonderful.
Did you navigate it with only a keyboard?
Did you test it with a screen reader?
Did you zoom it to 400 percent?
Did you check text spacing, reflow, focus visibility, reduced motion, forced colours, touch target size, error messaging, and the reading order?
Did you run the IBM Equal Access Accessibility Checker? Did you continue beyond the automated results with manual inspection, keyboard testing, and screen-reader verification—the broader testing process IBM itself recommends?
Did you hit 100 where automated scores exist, and then remember that a perfect automated score is not a certificate proving that every human can use what you made?
Did you test a slow connection?
Did you try malformed input?
Did you try malicious input?
Did you turn off JavaScript?
Did you inspect the dependency tree?
Did you read the logs?
Did you ask someone unlike you to use it without coaching them through the experience?
Can you explain the architecture to a junior developer?
Can that junior change it safely six months from now?
Are you confident enough to let me red-team it right now?
Because I will.
And if I can break everything you just made, you are going to rebuild it—but this time without the inaccessible interaction, the hidden assumption, the security flaw, or the brittle dependency that made the failure possible.
That is not punishment.
That is learning.
Failure reveals where confidence outran understanding.
A release is not a declaration that learning has ended. It is a timestamp. It is a stable point from which we continue.
Continuous Integration.
Continuous Deployment.
Continuous Improvement.
The first two are technical practices.
The third is a way of being.
I do not believe in finished.
I believe in stable enough to release, responsible enough to defend, observable enough to understand, and humble enough to improve.
If you are not improving, you are stagnating.
I know more about blood clots than I ever wanted to know, so forgive the metaphor: remaining still for too long can hurt you. The same is true when we immobilize our creative muscles because nobody has placed another ticket in front of us.
There is always another question.
You just have to go looking for it.
You Can’t Know What You Don’t Know
One of the principles I return to constantly is this:
You can’t know what you don’t know—unless you go looking for the things you don’t know.
A bad AI workflow collapses inquiry.
You ask for a feature. The model produces something. The tests pass. You merge it. The ticket disappears. Nobody asks what assumptions were made because asking would slow down the machine.
A good AI workflow expands inquiry.
The implementation appears quickly, so you use the reclaimed time to ask better questions.
What happens under latency?
What happens under load?
Which output contexts are unsafe?
Which users were excluded from the original requirement?
What happens when the translation is twice as long?
What happens when a person cannot use a mouse?
What happens when a screen reader encounters the dynamic update?
What data are we retaining?
What did we add to the supply chain?
Which dependency will become tomorrow’s incident?
What part of this solution is technically correct but miserable to maintain?
What would an attacker try first?
What would a junior developer misunderstand?
Can I explain every decision without asking the model to explain its own output back to me?
Then—and this is important—do not ask AI every one of those questions and accept whatever it says.
Go investigate.
Measure.
Read the documentation.
Trace the code.
Talk to users.
Use the assistive technology.
Break the build.
Read the standard.
Reproduce the failure.
Ask another person with different experience what you missed.
AI can help you draw a map.
It cannot walk the territory on your behalf.
The goal is not to preserve toil for the spiritual purity of toil.
The goal is to preserve curiosity, comprehension, judgment, and responsibility.
Care Is Not Measured in Keystrokes
I agree with the idea that good software is cared for.
Where I disagree is with the assumption that care resides in the act of manually typing every line.
A hand-written bug is not artisanal.
An inaccessible interface is not more human because a person personally typed every <div>.
A vulnerable authentication flow does not become craftsmanship because its author refused autocomplete.
A beautiful piece of software can be created manually and carelessly. An AI-assisted project can be built slowly, deliberately, and with extraordinary attention to the people who will depend on it.
Care is not keystroke count.
Care is attention.
Care is understanding the problem before racing toward a solution.
Care is recognizing that the requirement you were handed may be incomplete.
Care is choosing a boring architecture because the clever one will punish the next maintainer.
Care is testing the path that will never appear in the product demo.
Care is writing documentation for the person who will arrive after you.
Care is acknowledging when you do not understand something.
Care is refusing to ship what you cannot responsibly defend.
Authorship is not the number of characters you entered into an editor.
Authorship is ownership of the decisions and their consequences.
That responsibility does not disappear because a model proposed the implementation.
The agent may propose.
I answer for what ships.
That means I should treat generated work like a pull request from an extraordinarily fast, surprisingly capable, confidently unreliable stranger.
I do not merge what I cannot explain.
I do not ship what I cannot test.
I do not let generation speed outrun comprehension.
I do not outsource responsibility.
If I cannot explain how my software works without asking the same model that produced it, something has gone wrong.
But that is evidence that I delegated too far.
It is not proof that every use of the tool inevitably ends there.
Failure Is the Curriculum
I have watched mentors fail their mentees by making everything too easy.
They answer every question immediately. They repair every mistake before the junior experiences its consequences. They provide the final code without explaining what made the first attempt fragile. They turn mentorship into an answer-delivery service.
The mentee becomes faster.
They do not necessarily become stronger.
AI is exceptionally good at becoming an answer-delivery service.
It is eager. It is available. It rarely becomes impatient. It can produce a confident response before the learner has finished forming the question.
Used carelessly, it can rob someone of the productive struggle required to develop judgment.
But that is not an argument against assistance.
It is an argument for better teaching.
A good mentor does not merely give the answer.
A good mentor asks:
Why?
What else did you consider?
What assumption are you making?
How would you prove that?
What happens when it fails?
Can you make the failure happen deliberately?
Can you explain this without the vocabulary I used?
What would change your mind?
Sometimes a good mentor says:
No.
Try again.
Failure is not the opposite of progress.
Failure is instrumentation.
A failed test tells us something.
A failed design exposes an assumption.
A broken deployment teaches us which safeguards were imaginary.
A first attempt that collapses under pressure gives us a map of what we did not yet understand.
People need opportunities to fail gracefully—to experience consequences that are real enough to teach and safe enough not to destroy them.
We do not owe every junior developer the exact injuries we endured as an admission price to the profession.
The goal is not to preserve suffering.
The goal is to preserve discovery.
Answers are becoming cheap.
Judgment remains expensive.
Mentorship is not the transfer of answers.
It is the transfer of standards, attention, curiosity, and care.
And this is where AI has changed my understanding of mentorship.
I used to think mentorship meant helping a junior developer stand up faster. Giving them access to my experience at a fraction of the pain it took me to acquire it.
I still believe that.
But I now see mentorship as something larger.
Mentorship is philanthropy.
It is the decision to take what life taught you—through failures, outages, inaccessible systems, difficult clients, complicated teams, and years of experimentation—and package that knowledge so someone else can begin farther ahead.
AI gives an individual more capacity to document, demonstrate, test, translate, explain, and distribute that knowledge.
One experienced person can reach farther than before.
Not because the machine possesses the experience.
Because the human finally has enough leverage to share it.
Disability Taught Me What Automation Is For
One of my favourite things to do when I have downtime is inventory every annoying little problem I encounter and ask whether I can build my own fix.
I have been doing that for decades.
As a person with disabilities and a persistent need for accessibility, automation has never been an abstract debate about whether developers should type faster.
It has often meant removing a stupid barrier between me and the thing I am actually trying to accomplish.
Sometimes the barrier is small enough that nobody else notices it.
Sometimes the workaround is too specific to justify a commercial product.
Sometimes the problem only becomes visible after you have lived with it every day.
So I build something.
For years, many of those tools remained private.
I used them myself. I adapted them to my own work. I hesitated to publish them because publishing creates a different standard. A private tool can know its only user. A public tool must survive different machines, different workflows, different assumptions, different mistakes, and people determined to use it in ways you never imagined.
Public work invites ridicule.
It invites comparison.
It invites someone to find the test case you missed, the optimization you never considered, and the validation you assumed nobody needed.
AI did not remove that responsibility.
It gave me more capacity to meet it.
It helped me formalize ideas that had lived primarily in my head. It helped me generate adversarial cases, scrutinize documentation, review repetitive surfaces, and prepare work for people beyond me.
It gave me enough confidence to publish tools I might otherwise have kept private—not because it guaranteed perfection, but because it helped me build a stronger process for receiving imperfection in public.
Sandwich Hime came from that instinct.
I encountered a boundary in my Go work that frustrated me: the place where visible HTML, predictable compilation, accessibility concerns, reviewability, and ordinary tooling began to pull apart.
So I built the thing I needed.
AI did not invent the problem.
It did not give me the instinct that the problem mattered.
It did not live through my disability.
It did not spend years supporting juniors, handling production failures, explaining technical constraints to nontechnical people, or learning what happens when a system that appears fine excludes the person trying to use it.
I did.
AI helped me interrogate the solution, strengthen it, document it, and place it in front of other people.
My experience supplied the reason.
The model supplied leverage.
Those are not the same contribution.
And as models become increasingly capable of imitating the surface of competence, lived perspective becomes more—not less—important.
The model can produce code-shaped text.
It cannot have needed the accommodation.
It cannot feel the humiliation of being shut out by a careless interface.
It cannot understand why a tiny friction becomes unbearable when it is repeated hundreds of times by someone already rationing their energy.
It cannot care about a junior developer.
It cannot carry responsibility for the user harmed by a decision.
It cannot know which problem is worth solving until a human life makes that problem visible.
Unique human perspective is not decorative material added after generation.
It is the source of the requirements.
The Dangers Are Real
None of this means the concerns surrounding AI are imaginary.
We should be asking difficult questions about resource use, training data, consent, labour displacement, surveillance, accuracy, accessibility, concentrated power, and who absorbs the risk when a system fails.
We should question mandates that force workers to use tools they do not trust.
We should reject the idea that faster output is automatically social progress.
We should be deeply suspicious when companies promise liberation while measuring only whether fewer people can produce more work.
We should establish places where AI does not belong.
We should be able to say that a workflow is degrading our understanding, weakening our craft, or damaging our mental health.
We should be able to stop.
But “AI made me lazy” is not an analysis of all those harms.
It is a description of one relationship with a tool inside a particular system of incentives.
Tools can deskill people.
So can jobs.
A developer can spend years manually closing repetitive tickets without meaningfully expanding their judgment. A person can type every line themselves and still become stagnant. Familiar struggle can produce mastery, but repetition alone is not growth.
Sometimes repetition simply makes repetition feel safe.
AI accelerates whatever system it enters.
It can accelerate curiosity or apathy.
It can accelerate mentorship or exploitation.
It can accelerate careful research or confident nonsense.
It can accelerate accessibility work or generate inaccessible sludge at unprecedented scale.
It can increase human agency or give management a more efficient way to erase it.
The question cannot simply be whether AI was present.
We need to ask:
Who chose the workflow?
Who owns the time that was saved?
Who bears responsibility for the output?
Who is allowed to challenge it?
Who profits from the speed?
Who is excluded?
What knowledge is being lost?
What new knowledge could be pursued?
Which decisions must remain human?
And what are we trying to make more efficient in the first place?
Efficiency is not a moral good without an object.
Making exploitation more efficient is not progress.
Making care more efficient might be.
Your Skills Were Never Just the Output
I understand why people feel invalidated.
We built identities around skills that took years to acquire. Then a machine appeared capable of producing a recognizable imitation of the output in seconds.
That is destabilizing.
It forces an uncomfortable question:
If the machine can produce the code, what was I for?
But perhaps we confused the most visible evidence of our skill with the entirety of our value.
The code was never the whole job.
The code was the artifact left behind by a much larger process.
You recognized a problem.
You understood the context.
You negotiated conflicting needs.
You selected constraints.
You anticipated consequences.
You understood the people who would use the result.
You made ethical decisions, whether you named them as ethical decisions or not.
You integrated the work into a living system.
You answered when it broke.
You taught someone else how to maintain it.
You noticed when the requirement itself was wrong.
You cared.
AI may participate in producing the artifact.
It does not erase the life that taught you how to judge it.
Your experience has not been invalidated.
It has become steering input.
That may be a less visible role than typing every line, and our workplaces are often terrible at recognizing invisible value. But invisible does not mean unimportant.
Context matters more when output is cheap.
Judgment matters more when plausible answers are abundant.
Taste matters more when variation is effortless.
Responsibility matters more when generation is immediate.
Human experience matters more when the machine has none.
What Will You Do With Ten Hours?
Suppose AI gave you ten hours back every week.
What would you do with them?
Would you mentor someone?
Would you finally read the source code underneath the abstraction you have used for years?
Would you audit the accessibility of the product everyone insists is finished?
Would you threat-model the feature that shipped under deadline pressure?
Would you talk to the people using what you built?
Would you improve the documentation?
Would you learn a language outside your professional comfort zone?
Would you contribute upstream?
Would you build the strange little tool you have been privately sketching for six years?
Would you make art?
Would you sew something?
Would you play a game?
Would you sit with your partner?
Would you spend the afternoon with your children?
Would you sleep?
All of those are valid.
The point is not to transform every reclaimed minute into additional output.
That is just the hamster wheel wearing leisurewear.
The point is that the minute becomes available for conscious choice.
AI did not make me lazy.
It gave me room.
Sometimes I use that room to build.
Sometimes I use it to teach.
Sometimes I use it to investigate the thing nobody asked me to investigate.
Sometimes I use it to prepare work for the public that I was once too afraid to release.
Sometimes I use it to recover.
Sometimes I use it to be with my family.
The value is not that I fill every second.
The value is that I can decide what belongs there.
That is the part the hamster wheel never taught us.
Come Break What I Built
I warmly invite technical and nontechnical people alike to bring their perspectives to my work.
Test it.
Question it.
Red-team it.
Try to make it fail.
Tell me where it excludes you.
Tell me which assumption only made sense from inside my own life.
Tell me what your experience reveals that mine could not.
I would rather be corrected in public than protected by private perfectionism.
I would rather release something useful, listen carefully, and improve it than keep it hidden until I can pretend it is finished.
I no longer believe mentorship ends at the boundary of a team, a workplace, or a formal title.
We now have the capacity to reach farther.
To teach more openly.
To turn private accommodations into public tools.
To let more people begin from the lessons we fought to learn.
To combine human perspectives that would otherwise never meet.
That is not the end of craft.
That is craft becoming social.
Repetitive Stress Stockholm Syndrome is what happens when we mourn the wheel because we mistook its motion for a life.
The wheel made us tired.
It also made us feel necessary.
Now it is slowing down, and we are being forced to confront the terrifying possibility that our value was never supposed to come from how much repetitive strain we could endure.
So ask yourself:
What would you be doing if you had more time?
What would you learn if upward mobility were accessible?
What would you make if failure were survivable?
Who would you help if your schedule were not consuming every useful part of you?
Who were you hoping you would become once you finally had enough room?
The room may already be here.
The machine can help us move.
It cannot decide what is worth moving toward.
That remains—gloriously, terrifyingly, and uniquely—human.