Agentic Alienation

For the past couple of months, I’ve been perfecting a code factory. I develop a plan with an LLM like Anthropic’s Fable, review it myself, and have another agent review the plan. Then the factory decomposes the plan into small chunks that can be worked on in parallel. There are adversarial reviews, code quality enforcement scripts that must pass before merging new code, and an independent code review agent that prevents merges until all issues are resolved. My agents do nearly all the implementation work after planning. They even use a browser or terminal to hammer on the new feature, find bugs, and fix them without any human intervention.

By the time the factory is finished, the result has passed the same quality checks I would expect from work I wrote myself. I do not have to take its quality on faith. I can see what passed and what failed.

Once the factory starts, my only role is to answer questions. My AGENTS.md instructs the agents to offer long-term solutions alongside smaller patches. I choose, and they go back to work. Most recently, the factory built an automation called “meeting prep.” Every morning, it reviews my calendar and searches Google Drive for information about the people and topics on it. A report brings me up to speed before the conversation.

The meeting report gives me time back. But building useful software used to give me something too. Before the factory, implementing a feature meant spending hours moving between my code editor, terminal, and browser. I would encounter bugs while writing it, follow them into parts of the system I hadn’t expected to touch, and gradually develop a mental picture of how everything fits together. Now I can start the factory, leave my computer, and return to a finished pull request. The result may be better, but the experience is almost entirely gone.

I am proud of designing the factory, but the flatness is easiest to notice when I open a completed pull request. I recognize the result, but not the path that led to it. I can explain what I asked for, but I have no memory of the decisions that turned the plan into code.

Without that history, much of the joy of building is missing. What am I doing anymore? I feel less like a builder than an advisor to a system that builds for me.

I haven’t automated myself out of the loop. I’ve automated myself out of the experience of making.

Recognizing that loss has not made it easy to stop. Whenever the factory sits idle, I think about what else it could be doing.

Agentic alienation

My factory still needs me to choose its goals and judge its results. Every feature it finishes leaves me with decisions about what to accept, change, or build next. I remain responsible for the work, even as I participate in less of it. What sustains the judgment, curiosity, and concern I am supposed to bring to those decisions?

I used to be a middle school teacher, and I could imagine myself using AI to prepare a lesson for students who keep adding the denominators when they add fractions. An agent could review their work and prepare a lesson using measuring cups to show why two halves make a whole. I might use the lesson and find that the students improve. Preparing it myself would have required me to work out what made the wrong answers seem right to them and choose an example that might help. The agent would have taken over that opportunity to investigate. I could still learn from what happened in the classroom, but the students’ success would not by itself tell me what I had learned. An agent can make the work better without making the worker better.

There is an important objection to my account: overseeing can be satisfying, creative work. Directors, architects, editors, conductors, and managers create through delegation. They hold a coherent intention, make important decisions, and respond when difficulties arise. In these cases, delegation is the work.

A director does not need to operate the camera or perform every role to author a film. The actors and crew bring questions, problems, and possibilities while the film is taking shape. My factory pushes delegation further: it often resolves implementation questions before I know they exist. I can reopen a decision and ask for changes. What I cannot recover is the experience of discovering the problem and working toward that first solution.

Choosing to delegate is itself an exercise of agency. I built the factory, choose its goals, and decide whether to accept its results. I choose the ends, while it chooses many of the means. What has narrowed is my participation in the judgments made while the work unfolds. I retain the authority to direct it, but I have arranged the process so that I rarely need to exercise that authority during implementation. Being “in the loop” says little about what I actually do there.

That arrangement can make sense for a particular task. Repeated across the work I care about, it can also leave me with fewer opportunities to practice the judgment on which my direction depends. I call this agentic alienation: remaining responsible for work while becoming separated from its product, its process, the capabilities it develops, or the relationships it sustains. Alienation is a relationship before it is a feeling. A person can enjoy the speed while understanding less, exercising fewer skills, or working less directly with other people.

Karl Marx gives us a useful way to organize this problem. In 1844, he described four relationships through which wage laborers became alienated from their work. My situation is very different, but those relationships help clarify what has changed:

1. Our relationship to the product of our work
2. Our relationship to the activity of producing it
3. Our relationship to our creative and purposive capacities
4. Our relationship to others

I adapt these relationships as ownership, engagement, development, and connection. Marx’s account concerns wage labor under conditions very different from my own. I choose to use the factory, own its output, and can change how it works. The comparison does not make these situations equivalent. What I borrow is a way to examine how work can become foreign to the person doing it.

Calling this dissatisfaction would name how I feel, but leave open what has changed. The relationships direct me toward an answer: I may possess the result without understanding it, supervise the activity without experiencing it, or depend on abilities I no longer practice. Delegation need not produce these separations. Marx helps me ask when it does, and why ownership and control alone may not prevent them.

Ownership: Can understanding make generated work ours?

The first separation Marx describes is between the worker and the product of their work. My relationship to the products of my factory is unusual. I own them, requested them, and can change them. Someone could object that I do not really own the factory because the model at its center belongs to Anthropic, but I could run a capable open-weight model on a powerful computer in my home, and the problem would remain. I would own the engine, the pipeline, and every line of output without any guarantee that those lines felt like mine.

There is a difference between owning something and making it our own. Philosophers sometimes call the second kind of relationship appropriation. We make something our own when we understand it well enough to question it, change it, and recognize our own judgment in it.

I do not have to write every line of code myself, but I do have to understand the feature well enough to explain how it works, why it was built this way, and what would happen if I changed it. Legal and practical ownership gives me the right to use or modify the output, but understanding can give me a relationship to it. Building my code factory was an act of authorship, but authorship over the factory does not necessarily give me the same relationship to each feature it produces.

We can develop this relationship without being part of the original creative process. When I read a book and underline text, talk back to the author in the margins, and connect passages from different chapters, I become more at home with the ideas. I can explain where I agree with the author and where an argument seems to fail. The book remains the author’s creation, but I have something to say about it that is my own.

I could develop a similar relationship to the lesson the agent prepared. Why did the measuring cups help? What does pouring two half-cups into a whole cup show that the written equation does not? If a student still added the denominators, could I change the explanation? The lesson would become something I could work with, question, and adapt. I would not need to have devised it myself to make it my own.

It is easy to believe that we understand something until we try to explain it in writing. Once we begin writing, gaps and missing connections become difficult to ignore. For my code factory, I might explain how data moves through the system or why one architectural choice was made instead of another. The point is to reconstruct the explanation from my own mental model, where I can see what is missing.

I want to be careful here, because I can already hear myself deciding that documentation is the answer and then spinning up an agent to write it, at which point I would be approving a description of code I do not understand and reproducing the whole problem one layer up. The purpose is to discover whether the responsible person can explain the work from their own mental model. Vagueness, missing steps, and an inability to answer questions reveal where the work remains foreign.

Understanding can make the finished work less foreign. I can question it, change it, and recognize where I agree with its choices. But becoming familiar with a result afterward is a different experience from making it. I can understand the code and still miss having written it. Of the separations I have called agentic alienation, this one is the easiest to repair. Understanding closes some of the distance between me and the product. The next one is harder.

Engagement: What happens to the act of making?

Marx’s second relationship concerns the activity of work itself. In my factory, I plan and initiate the work, the agent performs it, and then I inspect the result. “The agent performs it” can contain hours of activity that I would once have experienced myself. I can describe the inputs and outputs and almost nothing in between, which is a strange thing to admit about a system I built. That interval used to contain the false starts, small discoveries, and occasional satisfaction of finally getting something to work. This is agentic alienation in its plainest form. I am responsible for the activity and absent from it.

As a teacher, I would still have a classroom to walk into. I imagine asking a student how they arrived at two fourths and hearing, “I added the tops, so I added the bottoms.” There is a logic to the answer. I could try the measuring cups, ask another question, and wait while the student thinks. What happened next would depend on what they said. Preparing the lesson and teaching it offer different occasions for discovery; automating the first leaves the second open. It might even give me more energy for it. My factory goes further by automating the implementation as well as much of the investigation around it. The important question is how much of the activity I value remains for me to experience.

Brent Fitzgerald’s “The human is the loop” describes what he misses when that room for discovery disappears from coding. Side projects once gave him a relaxing way to tinker and learn. With agents, they no longer do. He writes, “I often skip the learning to get to the result, and the learning is where the joy happens.” His agents helped him reach the result, but he missed much of what he had enjoyed and gained along the way. An informal survey of developers run by Scott Tolinski of Syntax found that 57.3 percent reported less enjoyment from coding than before they began using AI heavily, while 24.3 percent reported more. The survey figures cited here reflect its August 28, 2026, update, with 3,593 responses. Agents do not alienate everyone who uses them, but Fitzgerald’s experience helps explain what many respondents may be missing.

Some of what I miss does not need further justification. I liked following a bug into an unfamiliar part of the system. I liked having an idea, trying it, and finding out whether it worked. Sometimes I learned something useful. Sometimes I just spent an afternoon absorbed in a problem. Even if my skills never declined, I would still miss that experience.

I’m not arguing for effort as such. Plenty of the effort in my old workflow was tedious, and I don’t miss it. Waiting for a build or fixing the same formatting problem for the fifth time rarely made the day more satisfying. Automating those tasks can give me more time for the parts I enjoy. But when I automate the whole implementation, the interesting problems go with the tedious ones. A finished feature cannot give me back the curiosity I would have felt before I knew how to build it. I can study the solution afterward, but the uncertainty that made it absorbing has already been resolved.

Losing an afternoon’s enjoyment is one thing. Losing the practice through which I became good at the work is another.

Development: What capacities am I exercising?

Work leaves something in the world, but it also leaves something in the person who does it. A feature, lesson, or essay is the external result. Knowledge, confidence, and judgment accumulate in the person through repeated attempts. My factory still depends on my judgment. I need to ask how the work it leaves me will help me develop and sustain that judgment.

Handing off a task here and there is unlikely to matter much, and I would be suspicious of anyone who claimed to feel diminished by delegating a single migration script. What concerns me is the pattern: sitting down to do something by hand after several months and discovering that I am rusty. In the same Syntax survey, 63.4 percent of respondents perceived some diminishment of their skills. Self-reports cannot establish that skill loss has occurred, but the perception still matters: a majority believe agentic work is changing their abilities, not merely their workflows. Repeated delegation makes sense for routine tasks or work that does not intersect with our identities. We need to take greater care with core work, the work that makes us who we are or who we aspire to become.

In Art and Technics, Lewis Mumford, writing about industrial machines decades before anyone imagined agents, shows us that technical power and human development are different measures. He asks us to judge machines by what they do to people. Technology should expand our power without remaking us in its image. We should not be the instruments of agents; agents should be our instruments. This is why he writes, “we must restore primacy to the human person.” His goal is balance, not a rejection of technological progress.

Agents may be unusually well suited to this ideal because they can be directed in ordinary language and adapted to individual purposes. But a system that helps an experienced person work faster may give a beginner fewer opportunities to become experienced. We have to ask what the person will be able to do after using it for a year.

I imagine using the same agent at two points in my teaching career: when I was starting out and after I had gained experience. With experience, I might recognize that a suggested exercise would confuse the class or know which question to ask next. As a new teacher, I could receive the same polished lesson without having that history to draw on. I would still learn from teaching it. But if I rarely worked out why one lesson might help more than another, I would get less practice making the choices I was expected to judge.

As a new teacher using an agent, I could first examine my students’ work and propose an explanation myself. An experienced colleague could ask what led me to that interpretation. After teaching the lesson, I could compare what I expected with what my students actually understood. The agent could help at each stage, but I would have made a judgment and encountered its consequences. Repeated across different lessons and different students, that practice would give me something to draw on when the next unfamiliar mistake appeared.

My factory lets me skip making those judgments during implementation. If it requires my attention, that is probably a design flaw. The factory is designed to produce software. It is not designed to develop me. That is the third separation. The work continues, but the capacities it once exercised in me go unused.

Redux maintainer Mark Erikson has chosen a different and slower approach to agentic coding. “I’m intentionally choosing to limit the workflow to what I can manage in my own head.” His agents research the codebase, help with planning, and implement code changes. The difference is that he takes care to remain involved in directing the work and reviews as much of the code as possible. He accepts a limit on speed in exchange for engagement and understanding.

The stakes are personal as well as professional. Writing code is one of the practices through which I became a developer. It has given me confidence in my ability to take a confusing problem apart and make something useful from it. If I stop writing code, some of my skills will get rusty, and that would be recoverable. But I suspect another loss would be quieter and harder to name, something closer to no longer recognizing myself in my own work. If I haven’t written code for a year, am I still a developer? More importantly, do I still feel like one?

Part of that identity rests on abilities I have practiced for years. Coding by hand exercises sustained attention and the ability to hold abstract patterns in mind, trace logical flows, and create useful abstractions. Other practices might develop those capacities too. Directing agents can demand careful reasoning; reviewing their work can expose mistakes in my own thinking. But those benefits depend on what I actually do. Approving a result because the checks passed gives me less practice than predicting where it might fail and investigating whether I was right.

Professions change, and the goal cannot be to preserve every familiar task. I’m not going to pretend that every developer of the future needs to have spent a weekend chasing a race condition through a logging library. But whatever replaces that weekend has to do the same job of building judgment. Otherwise, we will ask future developers to exercise expertise they were never given the chance to acquire.

Connection: Who am I still working with?

When someone helps us work through a problem, we also find out what it is like to rely on them. Marx’s fourth relationship concerns other people. Work gives us reasons to ask for help, explain ourselves, disagree, and eventually become someone others turn to. Through those exchanges, coworkers become particular people to us. We learn whose caution comes from experience, who will admit when they do not know, and who will stay with a problem when it becomes inconvenient. Agents can change how much of this contact our work requires.

Imagine that I want to remove a check that seems redundant. I ask a coworker why it exists. They tell me about a failure from last year that affected a customer, and I explain why I thought the check could go. As we talk, we discover that part of it is still necessary and part can be simplified. I leave with a better answer, but something else has happened too. My coworker has seen that I will ask before removing something I do not understand. I have seen that they can reconsider an old decision without treating the question as an attack.

An agent could retrieve the history, ask the coworker for an explanation, and bring back the same technical recommendation. It might even do a better job of finding the relevant evidence. But my coworker and I would not have had that exchange. They would have answered a request from a system, and I would have received a report. Over time, fewer encounters like this could leave us knowing more about the code and less about one another. Marx’s fourth relationship is the one I had not expected to feel. Agentic alienation from other people arrives as a coworker I no longer have reasons to talk to.

That difference matters the next time something goes wrong. If I have misunderstood a requirement or introduced a bug, it is easier to bring it to someone who has already responded thoughtfully to my uncertainty. They may also be more willing to tell me when they think I am making a mistake. Trust gives us room to admit a problem before we know how to solve it. A workflow can deliver accurate answers while giving people fewer occasions to establish that trust.

I don’t want to romanticize every Slack thread. A status update can be automated without much loss, and an agent can spare a coworker a question I could have answered by reading the documentation. The useful distinction is what the exchange asks of us. Looking up a fact may require very little of the relationship. Working through a disagreement asks us to listen, reveal our assumptions, and respond to another person’s concerns. An agent can prepare me for that conversation by helping me understand the issue. The conversation still gives us something to do together.

When I taught middle school, I came to see the relationship with each student as the engine of education. Students were more willing to listen, attempt difficult work, and risk a wrong answer when they knew I cared about them. Without that trust, even a well-prepared lesson could struggle to hold their attention or give them a reason to try. If a student explained a wrong answer to me, how I responded mattered beyond that lesson. Taking their reasoning seriously helped show that I cared about their understanding and wanted to help them succeed. An agent could help me prepare, but I would still need to build that relationship with each student.

These relationships are part of what makes work meaningful. In three experiments, people who understood their work as helping someone else reported greater meaningfulness than people performing comparable work for themselves. Work connects us not only through conversation but also through the sense that our effort matters to another person.

A weekly team review could give us room for these exchanges if people bring questions they have not already settled. Agents can gather the evidence beforehand. Then someone has to say, “I think we should remove this check,” someone else has to explain what worries them, and both have to hear the answer. The value is in what they learn about one another while deciding. A meeting spent approving an agent’s conclusions would leave much of that untouched. I want the tools to give us more room for the conversations in which we come to rely on each other.

Hyperproduction: When “you can” becomes “you must”

Marx’s four relationships describe how work can become foreign to the person doing it. Two features of agentic work fall outside them. The first is that the factory does not stop.

Understanding the work, taking part in it, and thinking with other people all take time. The factory can fill that time with more output before I have decided how to spend it. Agents change how much work seems possible. My factory can continue producing after my own attention and energy are exhausted. In fact, I often set the factory to work overnight while I sleep. The more it can do, the harder it becomes to answer a simple question: When have I done enough?

With agents, I can work on multiple things at once. One could fix repository issues while another monitors errors, a third builds a feature, and a fourth updates the documentation. The factory can do all of this at once. I cannot give all of it my full attention at once. But the factory does not care whether it sits idle. I do. Lewis Mumford wrote, “The machine itself makes no demands and holds out no promises: it is the human spirit that makes demands and keeps promises.” Agents make more work possible, but they do not decide that all of it should be done. That pressure comes from employers, markets, and professional culture, and from our own sense that unused capacity is wasted. Among developers on X, a common refrain is that any time without an agent working is wasted time. It is often framed as a joke, but it shows how quickly increased capacity can become an obligation we impose on ourselves.

While I was writing this essay, Fabrizio Rinaldi wrote on X that he had deleted T3 Code from his phone because he “couldn’t resist spinning agents all day long, even when out with friends.” Theo quote-posted him: “Idk if this is a good or bad thing.” In a follow-up reply, he admitted that he had deleted the app multiple times himself and said that he now spent his showers managing agents. The factory no longer stays at the desk. It follows us into our pockets, and time with friends or even a shower can begin to look like unused capacity.

What catches my attention in these stories is how little coercion is needed. No one has to order another run. The work is available, the phone is within reach, and leaving the possibility alone starts to feel harder than acting on it.

In The Burnout Society, Byung-Chul Han calls ours an achievement society. It values initiative, improvement, and output, and its pressure often works through possibility. “You can” sounds like freedom. Often, it is. But in an achievement culture, “can” itself can become coercive when we internalize the demand to realize every possibility. Your boss does not need to demand that every moment be productive if you already make that demand of yourself.

The result is what Han calls an excess of positivity. He is not talking about optimism but about an excess of possible improvement: eat better, lift more, run farther, do more work, start more projects, and communicate more. In the developer culture I inhabit, these can become parts of the same project of self-improvement. None is bad on its own. The pressure comes from feeling that all should be pursued at once and without limit. Agents are a perfect fit for achievement culture because there is almost always another run to start, project to plan, or result to improve.

The demand to realize every possibility extends beyond work. In America, achievement culture asks people to fit in and stand out. We are expected to construct a unique life, improve it continuously, and display the results. This looks like individualism, but it can become another kind of conformity: everyone is expected to be different in recognizable ways. The 10x worker is one version of this ideal, someone whose value comes from producing beyond ordinary human limits. Agents make it seem attainable, which makes its demands harder to dismiss.

This expectation also has a morality. On X, people say someone is “ngmi” (not gonna make it) if they are not using the newest tools, working hard enough, getting in shape, or taking advantage of an opportunity. The judgment is not only that they will accomplish less. They are failing at something they ought to be doing. Someone who is not pushing every new tool is not simply slower; they are unserious about their future.

Once I accept that standard, an idle factory starts to look like evidence against me. I have the tools. I know what they can do. If I am not using them, what is my excuse? Rest becomes something I have to justify against the work I could have set in motion. This is what makes self-exploitation so powerful. I am not only asking what else I can produce; I am asking what it says about me if I choose not to.

In Han’s account, this excess becomes an engine of burnout. When every possibility for improvement feels like an obligation, people can exhaust themselves trying to achieve everything that appears possible. Agents multiply the possibilities that can become demands.

The agent is doing the implementation, so it is tempting to think this should cost me very little. But every run leaves something waiting for me: a decision, a result to inspect, a change I am now responsible for. Even when nothing needs an immediate answer, I can keep wondering what has finished and what I could start next. The factory works while I rest, but I can spend the rest thinking about the factory.

Among developers, the Syntax survey offers one indication of how that ideal is experienced: it found that 70.6 percent of respondents felt pressure, often or daily, to produce more because AI made it possible. The respondents are not representative of all developers, and the survey does not show that agents caused the pressure. It does show that increased capacity is not always experienced as freedom. When output expands faster than attention, work can continue while accomplishment declines.

This pressure makes each form of agentic alienation harder to repair. Understanding a feature, working through a problem, or talking with a coworker takes time in which the factory could be producing something else. If I judge that time by how much gets finished, the activities that would make the work meaningful begin to look like delays. The output keeps growing, while the time I give to understanding, learning, and working with other people gets squeezed. An agent can tell me when a task is complete. It cannot settle what I should count as enough.

Care: What deserves our attention?

My factory never took my care away. I cared about whether the tests passed, whether the reviews caught mistakes, and how much the system could finish without me. Those were reasonable concerns. But they became the measures by which I judged the whole arrangement. Even my dissatisfaction revealed other concerns that had not gone away: I still wanted to understand the code, enjoy making things, and recognize myself in the work.

Those concerns bring me back to the question running through this essay: what does it mean to give a shit about work when an agent can do so much of it for me? By care I mean something more fundamental than attention or conscientiousness. Care names the way our lives are already at stake for us. We find ourselves involved with people, purposes, and possibilities, living toward some sense of what our lives might become. Much of this directs us before we have put it into words. We cannot step outside care and then decide whether to begin. Even the desire to withdraw reveals something that matters. But we can come to recognize what our care has gathered around, and what it has left in the background. We can try to realign it.

For my factory, that realignment could begin with three modes: full autonomy, close supervision, and manual work. I can delegate gathering material before a meeting so I arrive ready for the conversation. For an unfamiliar architectural decision, I can ask the agent to investigate alternatives and bring them to me before implementing one. Other problems I may work through myself because I want the practice or simply enjoy writing the code. The choice follows what matters in the task, including what it asks of me and what it might give me.

Sometimes this will mean taking longer to finish something the factory could have completed without me. I may choose an afternoon of writing code over another finished feature. That is difficult to defend if output is the only measure, but I no longer think it should be. I want the feature, and I also want a working life I enjoy inhabiting.

These choices require limits. A feature can be finished even if the agent identifies five more improvements. I need room to understand important results before starting another run. Finishing early can also leave time free. I have some freedom to make these choices because I control my factory; a worker whose employer turns every gain in speed into a higher quota has less. Organizations help determine what people can act on by protecting, or crowding out, time to learn and work together.

Writing this essay has been one attempt to realign my care. I gathered sources, developed an outline with a model, drafted the prose, and used the model as an editor. Its suggestions gave me reasons to reconsider passages, but I still had to decide what I meant and whether the revisions said it. That is the part I wanted to keep. The standard was simple: I have to be able to defend every sentence as my own.

My factory can keep writing code while I sleep. What I need to decide is which work I want to wake up to already finished, and which work I want to be there for. The factory’s capacity will keep growing. My attention will still have limits. My factory will always be able to do more. I can decide when I have done enough.