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.

When the factory is finished, the code has passed the same quality gates I would expect from code I wrote myself. Passing those gates means it meets the requirements I’ve defined. I can inspect the results to see what passed and what failed. From there I can send the code back into the factory if needed.

Before the factory starts, my role is to answer questions as I plan with the agent. My AGENTS.md instructs the agents to offer long-term solutions alongside quicker, but less optimal, patches. The relevant lines:

## Offering Options

- Whenever you present me with options (including `AskUserQuestion`), always include an option that is the best long-term solution, even if it costs more upfront. Label it as the long-term choice so I can weigh it against quicker/cheaper alternatives.

I choose an option, and the agent gets back to work developing our plan. Most recently, I used the factory to build an automation that sends me a morning briefing. The system reviews my calendar, email, tasks, and documents and gathers relevant information to send to me before the day starts. For example, on August 15th my morning briefing reminded me of a bill due September 1 and listed ten email threads that needed a response. Gmail had been unavailable for that run, so the email report did not include emails from the last 24 hours. That was another bug I sent to my factory to fix. It also summarized a Notion page I had edited at 5:47 that morning: the draft of this essay. There was something funny about receiving a machine’s summary of an essay I was writing about what it was like to use that machine.

The briefing saves me time and I enjoy its convenience. But building useful software used to give me joy too. Before the factory, implementing a feature meant spending hours moving between my code editor, terminal, and browser. I would call the wrong function because it looked similar to the function I meant to use. Tracking down the source of my mistake would take me into a part of the codebase I had not intended to touch. After dealing with the mistake, I would come out with a better picture of how the parts of the system fit together. These days I can start my factory, go about my day, and return to a finished pull request. It’s actually even easier than that because my factory sends a notification to my phone when it is finished or has run into issues. I can make fixes, although not very ergonomically, from my phone while I’m out somewhere. I tell an agent what to change, and it makes the changes and continues the workflow. The result may be better than what I would have written myself. It certainly arrives faster, but the experience is almost entirely gone.

What remains feels flat. I don’t feel the same connection to the work, and I don’t have the sense of ownership that I used to.

I spent a lot of time and money building my factory, and once it started working as designed, I felt incredibly proud. But I’m confronted with that flatness when I open a completed pull request. The code usually looks good, but I have no understanding of the assumptions embedded in the code. I can explain the plan I developed with the agent, but I don’t know all the small decisions that turned the plan into code.

In August I opened the agent’s proposed changes, called a pull request, so I could review the code. The agent touched 42 files and added about three thousand new lines of code. The new functionality let me define custom roles that an orchestration model could choose from when directing other agents. From an admin interface, I could import, activate, or roll back each role. Sometime during development, the agent decided the role definitions should be “content-light,” and I could not tell you what that meant in practice.

When I’m not programming by hand and an agent codes and makes small implementation decisions during development, much of the satisfaction of building is missing. What am I doing anymore? I feel more like an advisor than a builder.

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 easier to stop using agents so heavily. Whenever the factory sits idle, I think about what else it could be doing.

Agentic alienation

My factory still needs me. It needs me to initiate new projects. I choose the work, I judge the output, and I can request changes. I remain responsible for the work, even though I haven’t written the code myself. If I’m not doing the work myself, how can I keep my technical judgment sharp?

My past experience as a middle school teacher gives me another way to see the problem. When I taught sixth grade, I had students who added the denominators when adding fractions. I brought in measuring cups to show them how two halves make a whole. If I’d had an agent then, it could have reviewed their work and prepared that lesson, and the students might have improved. Preparing it myself meant working out what made the wrong answers seem right to them. Based on that information, I could choose examples that would help. If the agent had done this for me, I would have missed the process of figuring out what my students needed from me.

An agent can make the work better without making the worker better.

There is an objection to my account thus far: overseeing can be satisfying, creative work. Directors, architects, editors, conductors, and managers delegate as part of their work. They have a vision and a goal. From there, they make decisions and respond to difficulties as they arise. In these cases, delegation is the work.

A director doesn’t need to operate the camera or perform every role to author a film. The actors and crew bring the director questions, problems, and suggestions while the film is taking shape. My factory pushes delegation further because it often resolves implementation questions before I know they exist. I can ask for changes when the work is complete, but I wasn’t there to work through those decisions as they came up.

Choosing to delegate is an exercise of agency. I built the factory. When I set it to work, I choose its goals, and upon completion I decide whether to accept the code. I choose the ends, while it chooses many of the means. What is being hollowed out is my participation in the judgments made while the work unfolds. I have the authority to direct the factory’s work, 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.

Automating one task, fine. But if the allure of speed, or my own laziness, motivates me to automate much of the work I care about, I’m left with fewer chances to practice the judgment required to competently assess the work of an agent. I call this agentic alienation: being responsible for work yet separated from its product, its process, the capabilities it develops, or the relationships it sustains.

Alienation is a relationship, but you can feel it too. A person can enjoy the speed and ease of having work handled for them while also understanding less, exercising fewer skills, and working less directly with other people.

Karl Marx gives me a four-pronged approach for analyzing this problem. In 1844, he described four relationships through which wage laborers became alienated from their work:

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 reframe these relationships as ownership, engagement, development, and connection. My situation is very different from that of Marx’s laborers. I own and choose to use the factory. I also own the output, and I can modify the factory to my liking. What I borrow from Marx is a way to examine how work can become foreign to the person doing it.

Calling alienation dissatisfaction would name a feeling but obscure the real changes in my relationship to work. The four relationships reveal the concrete conditions that have changed, and these changes sometimes carry with them particular emotions like dissatisfaction. But those emotions are not what defines alienation, and they vary from person to person. Alienation describes how I can possess an output without understanding it, supervise an activity without experiencing it, depend on skills I no longer practice, or work alongside people without really working with them. Delegation does not necessarily 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?

Marx’s first relationship describes the separation of the worker from the product of their work. The relationship I have with the products of my factory is unusual. I own them, requested them, and can change them. Someone might object that I don’t really own the factory, because the model that powers it belongs to Anthropic. But I could run a powerful open-weight model on my own computer, and the problem would remain. I would own the engine powering the factory, the factory itself, and every line of output. None of this would guarantee that those lines felt like mine.

There is a large difference between owning something and making it your own. Philosophers call the process of ‘making something your own’ appropriation. Appropriation can happen when we can explain how something works, question its design, and competently change it.

To appropriate an agent’s code, I don’t need to rewrite 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 ownership gives me the right to use or modify the output, but understanding can give me a personal relationship to it. I authored my code factory, but authorship of the factory doesn’t give me the same relationship to the features it produces.

The divergence between implementation and understanding isn’t a problem I’ve invented. Noam Segal and Lenny Rachitsky’s 2026 survey of tech workers found people living it. As one respondent put it, “I feel like I don’t think hard enough anymore—I just follow Claude. I don’t fully understand what I merge.”

There are ways to close this gap. 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 and how I agree with the author and where an argument doesn’t convince me. The book remains the author’s creation, but I have something to say about it that is my own.

As a teacher, I could use a similar method for retaining a relationship with a lesson created by an agent. I would have to ask: “Why did the measuring cups help? What does pouring two half-cups into a whole cup show that fractions on a whiteboard do not? If a student continued to add the denominators, could I change the explanation?” The lesson would become something I could work with. I could question it before taking it to the students, and question it after getting responses from the students. In this case, writing the lesson doesn’t have to be a requirement for understanding its strategies and judging its effectiveness. This is the exact process teachers should follow when using other teachers’ lesson plans or lesson plans included in the district-purchased curriculum.

We often believe we understand something until we try to articulate it in writing. This has been happening to me on and off as I write this very essay. Speech is forgiving because most audiences are forgiving, but the written word exposes us. Once we begin writing, gaps and missing connections are apparent. For my code factory, I might explain how and why data moves through the system the way it does, or the trade-offs among varying architectural choices. The point is to articulate something in terms of my own mental model. It’s through the activity of articulation that we appropriate the work. Appropriation is not a passive activity.

I can already hear someone suggesting that documentation is the solution. If I were to spin up an agent to write the docs for a feature, I would be approving a description of code I still haven’t grasped myself. The problem of appropriation would then be shifted one layer up. The goal is that the responsible person should be able to explain the work from their own mental model. Vagueness, missing steps, and an inability to answer questions reveal where the work remains foreign.

A test written by an agent could work differently. I often ask an agent to create focused tests for the behaviors I want to understand, and then I step through the logic with a debugger. A debugger is a small program that allows you to follow code execution and inspect the changing state of an application. This is how I develop my own mental model of how a feature works. The tests do not equal understanding. I need to attentively walk through the logic the tests outline and understand the ‘why’ at every point.

Understanding can make finished work less foreign. But becoming familiar with a result by analyzing it in retrospect 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.

Engagement: What happens to the act of making?

Marx’s second relationship concerns the activity of working. In my factory, I plan and initiate the project, the agent implements the code, and then I inspect the result. “The agent implements the code” can contain hours of activity that I would once have experienced myself. I can describe the inputs, because they are mine, and I can explain the outputs after analysis, but I wasn’t there for what happened in the middle. This is a strange thing to admit about a system I built. That implementation interval used to contain the false starts and the little pings of satisfaction after getting things to work. This is agentic alienation in its plainest form.

I am responsible for the activity yet absent from it.

As a teacher, I would still have a classroom to walk into. After teaching the measuring-cup lesson designed by an agent, I imagine asking a student why they still got two fourths when adding two halves and hearing, “I added the tops, so I added the bottoms.” There is a logic to the answer. I can work with the student from here. Preparing the lesson and teaching it are two different opportunities to work through a problem with my students. Automating the lesson preparation still leaves the subsequent discussion open. 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 the discoveries that happen in the process of coding disappear. Side projects once gave him a relaxing way to tinker and learn. With agents, he began skipping those experiences. He writes, “I often skip the learning to get to the result, and the learning is where the joy happens.” His agents helped him fulfill his goals, but now he misses what he had enjoyed and gained when the process was longer and manual. 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. This doesn’t tell the full story though, because 24.3 percent reported more enjoyment when using agents. The survey figures cited here reflect its August 28, 2026, update, with 3,593 responses. Agents are not inherently alienation machines, but Fitzgerald’s experience helps illustrate what some of those respondents may be missing.

Some of what I miss does not need further justification. I liked following bugs into unfamiliar parts of a system. I liked having an idea and seeing if it worked. Sometimes I learned something useful. Sometimes I just spent an afternoon absorbed in a problem. Agents can remove frustration, but I’ve come to realize that frustration can be a gift. It often precedes learning.

Much of the effort in my old way of working was tedious, and I don’t miss it. Building the same stock functionality (often referred to as CRUD: create a record, read a record, update a record, delete a record) for the thousandth time or fixing the same formatting problem over and over again rarely made the day more satisfying. Automating those tasks can give me more time for the parts I enjoy, like solving novel problems for the needs of a specific business. But when I automate all the work, the interesting problems disappear along with the tedious ones. A finished feature can’t give me back the curiosity I would have felt before I knew how to build something. I can study the output, but the uncertainty is gone. Creating logic from ambiguity is part of what gives me pride as a developer.

Losing an afternoon’s enjoyment is one thing. Losing the practice through which I became a professional is another.

Development: What capacities am I exercising?

Work makes real changes. Ideas and things are the result of work. But work also makes real changes in the person who does it. A feature, lesson, or essay is the external result. Skill, knowledge, confidence, and judgment accumulate in the person through repeated practice. My factory depends on my judgment. I need to ask how the work it leaves for me will help develop and sustain my judgment.

No professional programmer is diminished by delegating some CRUD operations. What concerns me is the pattern of delegation over time. When I write code by hand now, I feel rusty, and I’m actively working against it. In the same Syntax survey, 63.4 percent of respondents perceived some diminishment of their skills. Self-reports can’t establish that skill loss has actually occurred, but the perception of practitioners matters: a majority of respondents believe agentic work is eroding their skills. Repeated delegation makes sense for routine tasks or work that doesn’t support our identities. We need to take 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 abilities without remaking us in its image. In today’s terms, 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.

“One must never let the development of the machine get so far away from its sources in art and handicraft that we could not reinvent the art all over again if its higher secrets were lost.”

— Lewis Mumford, Art and Technics, p. 71

Agents may be unusually well suited to Mumford’s ideal because they can be directed in ordinary language and adapted to individual purposes. But his test is demanding. A system that helps an experienced person work faster may give a beginner fewer opportunities to develop their skills. We have to ask whether the people using these systems could still recover the underlying practice, and what they will be able to do after using them for years. Even if coding is eventually considered solved, some individuals will likely still code by hand. These may include programming language designers and people who enjoy programming as a craft. Even when work is automated or mass-produced, some people value the slow, manual process. The key is to make sure this group can continue practicing and that newcomers have opportunities to learn the craft.

I think about this in terms of my first years in the classroom. An experienced teacher can recognize when an exercise in a textbook might confuse the class. A new teacher without experience to draw from might miss this. A better path for me as a novice teacher would be to examine my students’ work first, propose an explanation, teach the lesson, and then compare what I expected with what they actually understood. The agent could help at each stage, but I would have made a judgment and observed its outcome. The important move here is to form my own judgment before asking the agent for help. As long as I remain at the center of the experience, agentic work is less likely to alienate me.

My factory lets me skip the experience of implementation. If it requires my attention and pulls me into its processes, that’s probably a design flaw.

I designed the factory to produce quality software. It isn’t designed to develop me. The work continues, but the capacities I once exercised go unused.

Redux maintainer Mark Erikson has chosen a slow approach to agentic coding. He explains, “I’m intentionally choosing to limit the workflow to what I can manage in my own head.” His agents research the codebase, help him with planning, and implement code changes. His workflow differs from my factory in that he takes care to remain involved in directing the work and reviews as much of the code as possible. He accepts slowness 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 feature request and make something useful out of it. Some of my skills are already rusty, but that is recoverable. I suspect there is another loss that is 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 my identity rests on abilities I have practiced for years. Coding by hand exercises 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, and reviewing their work can expose mistakes in my own thinking. But those benefits depend on my own activity. Approving a result because the checks passed gives me less practice than predicting where it might fail and investigating whether I was right. I need to be doing work myself: tracing the logic, trying a change, investigating a failure, or working out why something behaves as it does. These abilities develop through action and use. The issue is how to work in a way that builds skill and judgment without doing all the work myself.

Professions change, and right now some professions are changing more rapidly than ever. The goal can’t be to preserve every familiar task. I’m not going to pretend that every developer of the future needs to have spent a weekend tracking a performance issue. But whatever replaces that weekend has to build judgment and some kind of skill. Otherwise, we will ask future developers to exercise expertise they were never given the chance to acquire.

Connection: Who am I still working with?

Marx’s fourth relationship concerns other people. When someone helps us with a problem, we find out what it is like to collaborate with them. We develop a relationship and find out what kind of person they are. Are they sensitive, crass, thoughtful, shy? These are things we discover through interaction. Work offers us many opportunities to connect with other people. We should use these opportunities, but sometimes agents get in the way. Agents are convenient and have little social risk. The questions I ask reveal something about who I am to the person answering, for better or for worse. If we always turn to agents, or if we use agents to mediate our communication, we circumvent human connection.

Imagine that I want to remove some code 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 code could be removed. As we talk, together we discover that part of the code is still necessary and part can be simplified or removed. 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 of changes for that file, ask the coworker for an explanation, and bring back the same technical recommendation. It would certainly find evidence more quickly than I could. But my coworker and I would not have had that interaction. They would have answered a request from a system, and I would have received a report. I might know what change to make without having worked through why the code was necessary in the first place. Over time, fewer encounters like this could leave us knowing less about the code and less about one another.

That difference matters when something goes wrong. If I caused a bug, it is easier to turn to coworkers who have worked through issues with me in the past. They may also be more willing to tell me when they think I am making a mistake and work with me when that mistake reaches production and affects customers. Trust gives us room to admit problems and ask for help. The problem is that an agent can deliver accurate answers while giving people fewer occasions to establish trust.

Not every communication is important. 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 a communication asks of us. Looking up a fact may require very little in terms of human relationships. Working through a disagreement means we have to listen, state our assumptions, and respond to another person’s concerns. An agent can prepare me for that conversation by helping me understand the issue, while the conversation itself gives us an opportunity to connect.

When I taught middle school, I learned that my relationship with each student was the engine of education. I noticed that many students would not even listen in class until we had time one-on-one to establish a relationship. Then they were more likely to listen and participate in class discussions. They became active because they knew I cared about them. An agent could help me prepare, but it could not build that trust for me.

Human relationships are part of what makes work meaningful. In three experiments, people who thought of 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 has a positive impact on someone else.

At my job, a weekly team review could give us room for these exchanges if people bring questions they have not already settled with an agent. Agents can gather the evidence beforehand. Then when someone says, “I think we should remove this check,” someone else has the opportunity to explain what worries them, and everyone hears the answer. The value is in what we learn about one another while deciding. A meeting spent approving an agent’s conclusions elides the useful aspects of having a meeting in the first place. I want the tools to give us more room for 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. The second is that no one is forcing me to keep it running.

Doing the work, or appropriating it, and planning with other people all take time. My factory can accomplish so much with that same amount of time, making non-agentic work feel inefficient. Agents change how much work seems possible. My factory can continue producing after I’m exhausted and can no longer focus. In fact, I have often set the factory to work overnight, a time when I am most certainly tired and without focus. The more my factory can do, the harder it is to answer a simple question: When have I done enough?

With agents, I can multiply the number of ‘workers’ at my disposal by spawning subagents and doing work in parallel. This could be a single large task, or several miscellaneous tasks. In the latter case, one agent could fix known issues, another could monitor errors, a third builds a feature, and a fourth updates the documentation. It is impossible to pay attention to all the work happening in parallel. 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. The pressure to increase throughput comes from employers, markets, professional culture, but perhaps mostly from our own sense that unused capacity is wasted. Among developers on X, a common line is that any time without an agent working is wasted time. It’s often framed as a joke, but it shows that increased capacity can become a self-imposed obligation.

While I was writing this essay, Fabrizio Rinaldi wrote on X that he had deleted T3 Code, an app for running coding agents, 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. Across his books, he describes its demands for sleek, minimal aesthetics of body and home, constant self-representation in digital media, self-optimization, and dedication to work. Its pressure works through possibility. “You can” sounds like freedom. Often, it is. But we are compelled to be free, to actualize the “I can”. In an achievement society, “can” itself becomes coercive because we internalize the demand to realize every possibility. Your boss doesn’t need to push you harder at work if you are already putting the yoke on yourself.

Han calls the compulsion to realize possibilities an excess of positivity. He is not talking about optimism but about an excess of possible improvement and optimization: eat better, lift more, run farther, do more work, start more projects, and post more on X and Instagram. In the developer culture I inhabit, these can become parts of the same project of self-improvement. There is nothing inherently wrong with these activities, except for maybe inserting yourself into the attention economy of social media. The pressure to do more comes from feeling that all these activities should be pursued constantly and without limit. Agents are a perfect fit for achievement culture because there is almost always another feature to build, project to plan, or result to improve.

Achievement culture also asks us to make our self-optimization visible. In America, achievement culture asks people to stand out in their own ‘authentic’ way. Many feel the expectation to assemble a unique life, improve it continuously, and display the results as a social media collage. Few seem to catch the irony of being authentic just like everyone else. For developers, the 100x worker (it used to be 10x before agents entered the scene) is one version of this identity, someone whose value comes from producing beyond ordinary human limits. Agents make it seem attainable, which makes its demands harder to dismiss.

There is a morality to achievement culture. 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 isn’t just that they will accomplish less. It’s that they could be optimizing in a multitude of ways, but choose not to. Who doesn’t want to be a better person?

Once I am seduced by the promise of constant optimization, an idle factory starts to look like a moral failure. I have powerful tools, and I know what they can do for me. What is my excuse for not using them? Rest becomes something I have to justify against the work I could have set in motion. Han describes this as auto-exploitation, all the more effective because the demand feels like my own. I am not only asking what else I can produce; I am asking what it says about me if I choose not to.

This excess becomes an engine of burnout. When we feel obligated to constantly improve and optimize our morning routine and the structure of our day, we can exhaust ourselves. It’s not enough to do our work; we need to constantly improve and, even better, show this improvement, or at least the appearance of it, on social media. Having agents at our disposal exacerbates the feeling that every possible improvement is something we ought to pursue.

When the agent is doing the work, it is tempting to think running it costs me very little. But every task an agent performs leaves something tethering me: a decision, a result to inspect, a change I am now responsible for. Even when nothing needs an immediate answer, I feel the pull of the tether. The factory works while I sit on the couch or drive in a car, but the tether follows me.

The Syntax survey offers an indication of how this pressure is experienced by developers. The survey 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 doesn’t show that agents caused the pressure. The survey does show that the increased capacity introduced by agents is not always experienced as freedom.

The pressure of achievement culture makes each form of agentic alienation harder to repair. Understanding a feature, working through a problem, or talking with a coworker takes time, and employing an agent is a tempting shortcut. If I judge my work by how much time it takes to complete tasks, the activities that make work meaningful look like delays. With agentic work, output keeps growing, while the time I give to understand, learn, and work with other people gets squeezed.

Care: What deserves our attention?

I had spent weeks, perhaps more than two months, working with an agent on the orchestration engine that would power my factory. During that time, I was using my own makeshift process to coordinate the agents, the process I was trying to recreate in a more stable form in my factory. I opened a pull request and checked that all the tests and quality gates had passed. But when I read the code, I couldn’t explain the design. While my agents were working, I had been thinking about what other features I could build on top of the orchestration engine. I was leaning toward building tests that would evaluate how well different models performed in each role on the “factory floor”: planning agent, programmer agent, review agent, and so on. But this pull request pulled me out of my dreams of an even better factory.

My inability to track the logic of the pull request made me question the arrangement I was relying on. What part did I have in my own work process? Using that makeshift process, the agents had built a projection of database state for orchestrating complex tasks. The projection was a map of the current state of the workflow and all its orchestrated subtasks: a graph of nodes, some running sequentially and others in parallel. It held each node’s state and the overall progress of the goal so the system could work out what should run next. It was a lot of code, and its complexity seemed necessary. What I couldn’t account for were the decisions and the reasons for building it this way rather than another. When a task encountered an error, what recovery logic would keep it from blocking the other tasks? How could the system detect runaway nodes that never reported completion? The agent had made those decisions over the course of its work. It had tested the code and run trials of the full workflow, fixing issues as they arose. I envied the persistence and stamina of the agent, and even more so its technical ability. I wanted to understand the design in detail, to appropriate it so that perhaps I could accomplish such a feat myself in the future. There was pleasure in finding something here that I hadn’t known how to build. I wanted to ask questions, try changes, and see whether I could learn to think through the problem differently. But I also worried that I was helping set the pace of a funeral march for the work that had defined my role as a developer.

This leaves me with a question: what does it mean to give a shit about the work an agent does for me?

Care is more than paying attention to something. The tests and quality checks I put the agent’s code through mattered to me because I wanted a working factory. I also wanted to be someone capable of building a complex system like this. Those ambitions made a passing test feel like progress toward both my goal and the kind of person I wanted to be. Within an industry bent on hyperproduction, an idle factory felt like a missed opportunity. I did not experience these concerns as clear ideas in the moment. They appeared as vague compulsions. I had tension in my body, mostly in my chest, and the feeling that I was falling behind. I could choose where to direct my attention, but I was already caught up in concerns that made some things worth attending to.

My envy revealed one of those concerns. I wanted the technical skills I saw embedded in the agent’s design. There was also a sinking feeling, like energy was draining out of me. I pictured the work continuing. There was so much to add and improve but little that needed my direct involvement. My design for the factory was to keep going, hands-free, until a plan was executed or a goal achieved. Where would I fit when the factory took over? I cared about the quality of the factory’s results, and I cared about the person I would become as a result of relying on the factory. What started as a single concern had begun to pull in different directions.

The flatness I described earlier did not mean I had stopped caring. My factory never took my care away. In fact, the factory was the primary object of my care for a time. I had spent weeks building it, sometimes leaving agents working overnight on a factory that would itself work overnight or for days at a time. I built a framework that would produce tests good enough to catch failures. There was an entire subsystem dedicated to reviews that would catch subtle mistakes. Then I had to coordinate these parts so the system could work without my intervention.

When my factory finished producing code and the gates were green, that meant a successful day. These were the same measures of good work I had been using for years. I had learned to use them as part of becoming a developer, long before I built the factory. I wrote tests based on the functionality I was creating, so I didn’t forget anything while coding. If a test failed, I still had work to do. Those checks supported judgments I was making as I wrote the code. With the factory, I began relying on the checks to stand in for judgments I wasn’t making during implementation. Some checks enforced standards I had specified, while others tested behaviors the agents themselves had decided to check. I increasingly accepted their results without working through the judgments behind them. The activity of judging had come to appear as a thing. It was a green or red verdict detached from the decisions and assumptions that produced it. That is what I mean here by reification. I could accept the verdict without asking how it had been reached.

I reviewed the code too, but only after an agent specializing in code review had checked it and the issues it found had been fixed. Even then, I couldn’t fully understand the projection’s logic for handling failure, retries, and recovery, so I couldn’t judge those choices myself. The gates showed that it worked under the conditions they checked. My manual tests gave me firsthand evidence that the application behaved as expected in the cases I tried. Over time, my involvement was whittled down to watching for green and manually testing results. I wanted the ability to make those decisions, yet I was measuring success by how little the factory needed me to make them.

Appropriation offers a way to reclaim my judgment. The judgments reified in the checks can become things I question and work with. The decisions and assumptions behind them can be made visible again. When I step through a test with a debugger, question what it checks, and consider what it misses, I am exercising judgment about both the code and the test. The same test can stand in for my judgment or help me develop it.

To some degree I want to be involved in the work, but this requires me to resist the pressure to keep producing. To give my care a role beyond watching for green, I could build three distinct modes into my factory: full autonomy, close supervision, and manual work. Full autonomy is a good fit for tasks like creating my morning briefing. Receiving this briefing every morning is very convenient, although not necessary. It’s a low-stakes task, so automating it was an easy choice. I’m happy to let the agent take that task off my hands. At this point in my career, I won’t lose much if I delegate CRUD operations in the same way. For these tasks, I’m fine with relying on the standards built into the factory’s workflow. The projection, however, calls for close supervision. In this case, I want a checkpoint before the agent commits to important decisions. I want the agent to bring the decision to me with enough explanation and room to experiment that I can work through it myself. A checkpoint where I merely approve its recommendation would leave me in much the same position. I would want to trace what happens when a parallel branch fails or a node never reports completion, then consider whether the recovery behavior makes sense. Could I explain why the proposed design is a good solution and why it was chosen over alternatives? I might have an idea of my own while following the agent’s reasoning, something I wouldn’t have thought to try before seeing its design choice. Other problems I may work through myself because I want to learn a new pattern or technology, or simply for the joy of writing code.

With these three modes, some work will take longer to finish. Not everything would be handed off to the factory or an agent. 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 don’t think it should be. I want the feature, and I also want a life that gives me room to practice the skills that make me who I am. I don’t have time to become everything I want to be. The afternoons I spend doing one kind of work are afternoons I cannot spend becoming someone else. A feature can be finished even if the agent identifies five more improvements, and I need room to understand important results before starting another task. I have some freedom to make these choices because I control my factory, but a person whose employer turns every gain in speed into a higher quota has less.

Writing this essay is one attempt to realign my care. I gather sources and bring them to an agent. We then go back and forth with ideas, and an outline emerges from our conversation. I take that outline and convert it into prose. Along the way I check in with my agents about the clarity of my writing, redundancies, and often to update the outline as new ideas bubble up from the activity of writing. The agent can give me reasons to reconsider a passage, but I decide what I want to express and whether my rewrite expresses it. I keep a fuller account of this on my AI use page. My standard is simple: I have to be able to defend every sentence as my own.

My factory can keep writing code while I sleep, and it often does. What I need to decide is which work I want to wake up to already finished, and which work I want to be involved in. My attention has limits, and my energy is finite. My factory will always be able to do more than me. I can decide when I have done enough.