The Research Was the Work
When an agent takes over more of the typing, a four-craft team spent most of its effort on shared discovery before writing code. The open question here is whether the time that frees up goes back to people or into more scope.
By Andrii Melashchenko and Jessica Gilmore, Manager, AWS Developer Experience
When an agent takes over more of the typing, a team has to figure out what happens to the time it just got back. We spent ours on a question we still haven't settled: does that time go to the people, or does it get quietly absorbed into more work?
Andrii: The Moment That Changed a Spec
Four of us were building a Margo device-side client, software for an open standard for the industrial edge, and came at the same problem from four different crafts: cloud-native, embedded C++, embedded-OS DevOps, and architecture. Each of us carried assumptions the others didn't share, about memory budgets, about release discipline, about what "done" even means for a component none of us owned alone. Before anyone touched an agent, we worked on turning those assumptions into something all four of us, and eventually the agent, could act on without a hallway conversation to fill the gaps.
At one point the embedded C++ developer pushed back on an assumption the cloud-native side had made about storage and I/O on a resource-constrained edge device. With little storage and limited I/O, a workload that is removed has to leave nothing behind, and container images with very large layers are a real cost there, so not every container that runs in the cloud should run on the device. As a result we redefined how a workload is put onto the device and taken off again, and our specification changed with it.
That's the shape of what I want to show you here: not a demo, but a specification that changed because someone from a different craft pushed back on it.
Jessica: Making the Tacit Explicit
What Andrii is describing has a name in organizational-knowledge research: tacit knowledge, the kind an experienced practitioner carries but rarely writes down, becoming explicit. Ikujiro Nonaka called this step externalization, the moment people turn what they know into concepts and documents a team can act on together (Nonaka, 1994 ).
I see this pattern constantly in community work. When experienced builders share what they know with newer practitioners, they almost always discover gaps in their own understanding. The act of explaining forces clarity. A specification written through that process stops being a hand-off document between two people who already understand each other well enough to fill in the blanks by habit. It becomes a shared reference point: the place where four different crafts teach each other what they know, in a form precise enough that a system with no judgment of its own can still act on it correctly.
The interesting part is not that the specification exists. Teams have always written specifications. It is that a team can no longer get away with one that only sounds complete. When the reader is a system that will not stop and ask a clarifying question in the hallway, ambiguity shows up immediately, not three sprints later.
Andrii: Where the Effort Actually Went
Here is the part I can speak to from my own experience: most of our effort went into discovery and architecture, done together, before a single line of production code existed. Nobody kept a record of the split, so I won't put a number on it. Nothing in this section was measured: it is what I saw, and I can't tell you the project was faster overall.
We used Kiro, an AI coding tool from AWS. A disclosure, since one of us works there: I am an AWS Community Builder, Jessica was not part of the project, and AWS did not sponsor or support it.
What the discovery work bought us was a build phase with fewer surprises. The comparison is with my own earlier projects with a similar mix of crafts. There, ambiguity in the specification, disagreements over how to read a standard still in draft, and the surprises that only appear once components meet each other usually didn't surface until the build was already underway. On this project, much of that surfaced earlier, during the discovery work itself. Some of it still reached the build, and it was of two kinds: things that only appeared when the parts met, and the resource limits of the device. Even so, I saw little rework. And the arguments we had in review were about judgment calls, not about what the specification meant.
The same kinds of questions, untied at a different point: earlier projects above, this one below, time running left to right. Some still reach the build. A sketch of what I saw, not data: neither the lengths nor the number of knots mean anything.
Jessica: What Changes for the Specialist
The shift Andrii is describing is not typing getting outsourced. It is a change in which part of a specialist's judgment becomes the scarce resource once typing stops being the bottleneck.
What a practitioner knows from years of building does not transfer into a specification by accident. It has to be drawn out, usually by someone from a different context asking the question the specialist forgot to ask themselves. That is peer learning in its plainest form: not a workshop or a training module, but a review conversation where the hardest questions come from unfamiliar territory.
The same thing happens when people from different specialties review each other's thinking. The value is never in the artifact that comes out the other side, it is in the exchange that produced it. The moment someone stops questioning the output because "the tool wrote it," you lose that exchange. Researchers call this automation bias (Skitka, Mosier & Burdick, 1999 ), and it is the reason review has to stay a real conversation, not a rubber stamp.
None of this means the underlying craft has gotten easier. It means the value of that craft has moved: less time producing the artifact, more time deciding whether it is right.
Andrii: The Bet We're Making
Here is the bet, stated as a bet and not a result: if whatever time the agent frees up goes back into more discovery (the same kind of care we put into this project), the way we work gets steadier. The reasoning is one step long: a question settled in discovery is a question nobody has to settle mid-build, under deadline pressure. So fewer of those late decisions. Not none of them.
The bet fails if we do the opposite: point the agent at more surface area instead of more depth: "token-maxxing," treating how much an agent produces (prompts sent, code generated) as if that quantity were progress. If that is where the freed-up time goes, nothing about our week gets steadier. It just gets busier at a higher volume.
The bet, drawn as an open fork: more depth, or more surface area. Neither channel has water in it yet.
Our own first measures are modest: the team will track planned versus actual hours, hours logged by category (discovery, build, new scope), and a count of out-of-hours interruptions. The first shows how far our estimates were off, the second where the time went, the third whether the week got steadier. None of them shows by itself that freed time went back into discovery, and we have no baseline for any of them, which is why this piece ends on a question: we go first with these three, and we still ask you.
Jessica: The Counter-Argument
I want to take the other side of Andrii's bet seriously, because the evidence so far does not obviously support it. A recent field study of workers who adopted generative AI tools found the opposite of the free-time promise: as tasks got faster, people took on more of them, worked at a faster pace, and extended work into more hours of the day, often without anyone asking them to (Ranganathan & Ye, 2026 ). The pattern is not new. More than a decade earlier, researchers studying mobile email found the same thing: tools meant to give professionals autonomy instead escalated what colleagues expected of their availability (Mazmanian, Orlikowski & Yates, 2013 ).
I see this on my own team. As we have added more tools, we do not do the same work faster. We take on more projects, or we dream bigger on the ones we already have, which creates more expectations. The pace of change has gotten so fast that it is difficult to deliver anything that is not perfect, because our audience now expects that. The tools did not hand us time back. They raised the bar for what counts as good enough.
There is no mechanism by which a faster build phase automatically returns anything to anyone. It returns capacity. And capacity gets allocated by whoever sets expectations for the team, which is rarely the team itself. The condition that decides which way it goes is not the tool. It is whether the people who set scope and deadlines choose to treat the freed time as something to hold for the team or something to spend on more output. Nothing in a faster specification-to-code loop answers that question by itself. Only the decisions made around it do.
Andrii: A Short Reply
I agree with Jessica on the main point: nothing comes back automatically, and I would expect my team to go the way hers did unless someone decides otherwise. The bet depends on the condition she names: that the people who set scope and deadlines hold the freed time. I would ask them to hold it for discovery. I speak here as the architect: I can argue for that choice, but I do not set scope and deadlines myself.
Both: What We're Asking You to Measure
We honestly do not know which way this goes yet. And we are not convinced anyone else does either, no matter how confidently they say it. So what we are asking is simple: if your team is going through this same shift, what would you actually track over a quarter to find out where the time went? Not a goal. Not a strategy. Just one honest measure you could point at your own week and trust the answer.
References
- Nonaka, Ikujiro. "A Dynamic Theory of Organizational Knowledge Creation" . Organization Science, 5(1), 14–37, 1994.
- Skitka, Linda J., Mosier, Kathleen L., and Burdick, Mark. "Does Automation Bias Decision-Making?" . International Journal of Human-Computer Studies, 51(5), 991–1006, 1999.
- Ranganathan, Aruna, and Ye, Xingqi Maggie. "AI Doesn't Reduce Work — It Intensifies It" . Harvard Business Review, February 2026; based on an eight-month ethnographic field study (40+ interviews) at a 200-person technology company, UC Berkeley Haas School of Business. Accessed 2026-10-07.
- Mazmanian, Melissa, Orlikowski, Wanda J., and Yates, JoAnne. "The Autonomy Paradox: The Implications of Mobile Email Devices for Knowledge Professionals" . Organization Science, 24(5), 1337–1357, 2013.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article