What do devs, homemakers, architects, and pilots have in common? They’ve all had part of their job automated, and it changed how they work.
Atomic Object is adopting agentic engineering, a delivery process where AI agents write much of the code. I’m a Quality Analyst (QA) on a large project team with several streams of work, and I’ve been figuring out what that means for my job.
Agentic delivery is generating a lot of software a lot faster, and I’m having to change the way I work to keep up. I used to develop my understanding of the client’s software and the stories mapping the new work over time, across layers. Now I have to understand the context, the work and the shared vocabulary much quicker.
So I looked for other jobs that went through automation and how the automation impacted those “displaced” by it. Three of them had lessons for me.
The Spin Cycle (Washing Machines Increased and Shifted the Work)
Picture laundry before the washing machine. You had a few shirts. You filled the washtub, scrubbed each shirt on the washboard, rinsed it, wrung it out, hung it to dry and maybe ironed it. It took a long time and a lot of effort. But when you were done with those few shirts, you were done.
The washing machine saved a huge amount of effort. It didn’t give people their time back. For full-time homemakers, housework fell only about six hours a week between 1900 and 1965. The work shifted in two ways.
First, somebody has to keep an eye on the washer. Leave the clothes in it and they get smelly and moldy, so you have to get them into the dryer. At the washtub, you never stepped away from the job. All the clothes were ready to dry when you finished the task of cleaning the clothes, so you never had to remember to come back to it.
Second, the volume went up. Historian Ruth Schwartz Cowan found that once washing got easier, the standard for clean clothes rose. More loads went through, and every load came out needing to be folded and put away.
That’s what working with agents feels like. I start work with an agent, step away and have to remember to come back. Because each task is easier, there are more of them: more projects at once, more kinds of work at the same time and less time on each to go deep.
Not everything an agent hands back is something I asked for. It’s taken me a while to tame agents so every request doesn’t come back with the output plus a laundry list of questions, changes and flags I never asked for, and I can’t always tell which are valid. So sorting is part of the job now. Before anything the AI flags becomes a bug, I decide whether the problem is realistic. Where I can, I have the AI build the fix on a local branch, and I test it. I already know the steps to reproduce the problem, so the tested fix goes right into the bug. When I don’t have enough context to judge, I ask my tech leads, who don’t mind helping me make that call.
Pencils Before Pixels (Keep the Early Sketches)
Architects went through their own version of this when computers took over drafting. Computer-aided design (CAD) software now produces the finished drawings: the precise plans, with every measurement and note, that builders work from. Michael Graves accepted computers for that work, but he argued that early sketches should stay by hand, because drawings “are part of the thought process.” The sketch is where he worked out what the building needed to be.
I see this on my team. Developers and I write out or draw the logic and scenarios by hand, take a photo, and give it to AI.
My early sketch is a test map. It shows what I’ll cover, where the data comes from, what I’ll compare it against and what I expect. Agents help me build it by reading the old code to find the options and where inputs come in.
Test scenarios are generated as part of the spec. I also take my own pass. I talk through what I expect the feature to do and record it as a transcript. Then I compare my transcript with the generated scenarios and look at the differences. That lets me plan testing before the code exists, and it raises questions as I go.
The test map raises a question I keep coming back to: agents pull the information in, but do I know enough about the right output to judge whether it’s accurate?
Take a Left at Albuquerque (Watch Your Situational Awareness)
In a 2014 NASA-led study, 16 airline pilots flew a Boeing 747 simulator with less automation than usual. Their hand-flying skills mostly held up. What faded was keeping track of where the plane was, deciding what came next and noticing when an instrument failed. Pilots have to stay engaged the whole flight to handle the parts of the job they still own.
Situational awareness is what I struggle with most. I’m on several projects. I can ask the knowledge base to summarize what changed, but I’m not engaged the way I used to be. A summary tells me where the project is. It doesn’t give me the sense of direction I had when I was in the work every day.
It’s like looking at a map instead of being there, knowing the route and the direction I’m going. Maybe my map-reading skills have to change. I need to get better at reading a situation from outside it and getting back in the pilot’s seat.
Having AI summarize meeting transcripts helps me quickly get my bearings again. Transcripts show what was said and who said it, even in meetings I missed. I can find an old answer and confirm it’s still accurate without tracking someone down again. I haven’t solved situational awareness yet, but that helps.
Same Job, New Shape (What the Three Have in Common)
The homemaker still did the laundry, just more of it, balancing wash and dry cycles with new chores in between. That’s the way I’m balancing multiple agents running in my work now. The architect still sketched, because that’s where the design logic got worked out. The pilot still flew, because staying engaged was the only way to handle what the automation couldn’t. In each case, some work moved, some work grew and some skills faded when nobody used them. Each of them had to focus on the part of the job they still owned.
That’s where we are with agents. You could run the agents and take whatever they produce. Right now, for a business-critical app, that’s too much risk. Without the right guidance, the right review, the right context and the right questions at the right time, there are too many mistakes. Maybe we’ll get better at giving context and AI will get better at receiving it, and the gap will close.
Atomic’s agentic delivery process accepts a different amount of risk for each piece of work, depending on how precise the result has to be, how much the team can learn before building and how costly it would be to change direction afterward. We have the same number of unknowns we always did. We just find them at a different point. We build prototypes on assumptions, learn from them and then scrap a little (or a lot) of the work once we have the right questions and the right information. The direction we set early doesn’t have to be exact; honing in is part of the work.
For me, the part of the job I still own is asking questions up front. In my next post, I’ll share six questions I ask early to point the work in the right direction.
What has agentic delivery shifted in your work, and where are you putting your focus?
Written and illustrated with the assistance of Claude Opus 5.5.