Loren Stewart, an engineer working on Every’s Slack agent, has built himself a software factory that can produce a new feature while he goes about his day. But handing off the coding also meant losing the trial and error that helped him learn and made the work satisfying. In today’s piece, he turns to Karl Marx’s theory of alienation to understand that loss and considers when to automate, when to supervise, and when to do the work himself. I think many of us will recognize this question, whether or not we write code.—Kate Lee
Was this newsletter forwarded to you? Sign up to get it in your inbox.
For the past couple of months, I’ve been perfecting a code factory.
I develop a plan with an LLM, 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. My agents do nearly all the implementation work after planning. They use a browser and terminal to hammer out the new features, find bugs, review other agents’ work, and fix resulting issues. Changes go in only after they pass automated checks and a separate agent reviews and approves every issue.
I can start my factory, go about my day, and return to a new feature or an entire app. The result may be better than what I would have written myself. It certainly arrives faster.
Before the code factory, implementing a feature meant spending hours moving between tools. I would grab the wrong piece of code because its name looked like the one I wanted. Tracking down my mistake would take me into a part of the codebase I had not intended to touch, and I would come out with a better picture of how the parts of the system fit together. The agents take those detours now, and I see only where they end up. I’ve automated myself out of the experience of making.
Many engineers call these systems software factories: Agents do specialized jobs in an organized sequence, like workers on an assembly line. But the resemblance may go further than we intended. More than 150 years ago, Karl Marx described how factory workers became estranged from the things they made. His account helped me understand what I missed most about making things myself and what I could change to get some of it back.
A virtual summit for the new, new CFO
The era of the builder CFO is here. They are vibe coding deal desks, wrangling MCPs to deliver never-before-seen automations, setting up agent swarms to triage invoices, and imagining other inventive ways to methodically deploy agentic intelligence across finance workflows.
Traceable by Chargebee is a virtual event dedicated to documenting this shift. Join CFOs, controllers, finance engineers, and founders as they share field notes on the rise of the AI-native finance org. Featuring leaders from Public.com, Campfire, Sphere, Every, and other frontier teams.
Four forms of alienation
Marx wrote in the mid-19th century about laborers in industrial factories, including textile mills, where machines were transforming how people worked. He described how workers could become disconnected from what they made, the act of making it, their own abilities, and one another. I see versions of each in my factory.
The product. Marx’s mill worker did not own the cloth he wove, nor the factory in which he wove it. I own every line my factory produces, but there is a large difference between owning something and making it your own.
In August, I reviewed the factory’s work on a new feature meant to help agents coordinate more complex projects. The coding agents building the feature had touched 42 files and added about 3,000 lines of code. Somewhere during development they had decided that part of the design should be “content-light,” and I could not tell you what that meant in practice. I could explain the plan I developed with the agent, but I didn’t know the small decisions that turned the plan into code.
I owned every one of those lines, and I was reading a stranger’s work.
The activity. Marx wrote that the worker “feels at home when he is not working, and when he is working he does not feel at home.”
I used to be the worker at my computer, working through problems myself. Now I’m more like the factory owner: I set the work in motion and inspect the result. In between, the agent implements the code, an activity that holds the frustration of false starts and pings of satisfaction after getting something to run. I am not unhappy at work. I am simply not there.
The capacities. Work changes the person who does it. A feature is practice made external; through working on one we develop skill, confidence, and judgment. Marx saw knowledge and skill become part of the factory’s machinery, while workers had less occasion to exercise their own. My software factory depends on my judgment, but it is not designed to develop me. It produces quality software, and if it needs my attention during implementation, that is probably a design flaw. When I write code by hand now, I notice that I’m out of practice.
Other people. In Marx’s factory, workers stood side by side , and dealt mostly with the machine. My colleagues and I each have software factories of our own, and we risk dealing more with those systems than with one another.
If I want to remove code that seems redundant, I might ask a coworker why it exists. They tell me about a failure from last year that affected a customer, and as we talk we discover that part of the code is still necessary and part can go. I leave with a better answer, and my coworker has seen that I will ask before removing something I don’t understand. I have seen that they can reconsider an old decision without treating the question as an attack.
An agent could retrieve the same history and recommend the same change. But my coworker and I would have missed a small occasion to learn to trust each other.
Three ways to run the factory
My situation is very different from that of Marx’s mill workers, who couldn’t redesign the mill. I built my factory and can change how it runs. I’ve handed it work that once challenged me, taught me, and gave me satisfaction, measuring success by how little it needed me. To take some of that work back, 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. At this point in my career, I won’t lose much if I delegate the routine operations I have written 1,000 times. For these tasks, I’m fine with relying on the standards built into the factory’s workflow.
Close supervision is for a complex system I want to understand. A checkpoint comes before the agent commits to important decisions, with enough explanation and room to experiment that I can work through them myself. I might trace what happens when one branch of parallel work fails or a task never reports completion. 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.
Manual work is for problems I want to work through myself, because I want to learn a new pattern or technology, or simply for the joy of writing code. For the code I don’t write, I can still close some of the distance. I often ask an agent to write checks for the parts I want to understand, then use a debugging tool to follow the code step by step. The check might pass, but I still have to figure out how the code works and what the check missed. A check can stand in for my judgment or help me develop it.
Some work will take longer this way. 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.
An idle factory is okay
The steam engine did not get tired, and the mill owners noticed. Marx called it an “economic paradox”: that the machine that could have ended the long working day became a reason to extend it. An idle machine was money lost.
My factory can keep writing code while I sleep, and when it sits idle, I think about what else it could be doing. But I can choose which work I want to wake up to already finished and which I want to be involved in. My factory will always be able to do more than me. I can decide when I have done enough.
Loren Stewart is an engineer at Every, where he works on Every’s Slack agent.
Stop explaining AI to your team and start showing them. Every Agent does the work in Slack, where everyone can see it, so one good workflow quickly becomes the whole team’s.
