For most of my career, I had a decent sense for answering two questions: how much work is ready to go, and how long is it going to take?
I could look at a healthy backlog with a couple of weeks of estimated stories, do some math, and give a pretty good guess of what the next two weeks would hold. Then I started leading projects where agents do most of the building, and those instincts stopped firing.
The backlog wasn’t a tidy stack of pointed stories. There was no comfortable velocity baseline to lean on. Work that would have taken days was almost done before I finished describing it, and other work I’d have called trivial turned out to be the hard part. My old sense of pace was just… gone. If you’re leading an agentic development project and feel like it’s taking some time to get your bearings, you aren’t alone.
For decades, almost everything we built our process around assumed the same thing: that implementation was the slow, expensive part. The cadenced stakeholder meeting, the careful handoff to developers, the story points, and the velocity charts — all of it existed to manage the cost and risk of writing code. When writing code gets cheap and fast, the habits we’re accustomed to no longer fit. The constraint moves upstream – to you – and you’ll need to form new habits to adapt to the change.
This post is about some of the human habits I’m building to adapt to our new way of working. I’m not going to say much about the agents themselves. I want to talk about how _you_, the person on the loop, can change the way you work.
1. Build small, fast decision loops.
When definition becomes the bottleneck, waiting for a decision is a huge momentum killer. Waiting on an answer about an edge case. Waiting to find out whether the client wants the nice-to-have or just the must-have. In the old rhythm, those questions didn’t need immediate answers. I was conditioned to save my big questions up and bring them to the next stakeholder meeting. A two-day wait for an answer was a rounding error against several weeks of build. Building with agents compresses the build timeline and compresses your decision loops.
So…what actually changes here? In my experience, I felt myself making more decisions about product details at a faster pace than I was used to before. Agents require a LOT of specificity when it comes to edge cases, error handling, and what to do in the odd scenarios that used to come up mid-sprint. For instance, imagine you’re adding a simple sort and filter feature set to a data-rich table on your portal. Easy, right? So, we’ll work with our agent on creating the product spec.
Here are some questions you might see your agent ask when you’re defining the work:
Clear behavior
Lean: per-column `Clear filter` is required on every column that has a filter; one page-level `Clear all filters` action that resets column filters, the above-table Search if present, and any page-local toggles owned by the page spec. Sort and pagination position are not reset.
Empty/loading/error states
Lean: Loading = skeleton rows in place, headers + filter controls remain operable. Empty-filtered = “No data matches your filter criteria.” inline where rows would render; Clear-all stays visible. Empty-unscoped (no data exists at all in scope) = a distinct message (“No data available.”). Error = inline retry, headers preserved.
Accessibility.
Lean: keyboard-operable filter controls (open/close, arrow navigation in option lists, Esc to close, Enter to apply selection), focus indicators per `ui-guidelines`, screen-reader announcement of active filter count and active sort column/direction.
From here, you respond to the agent and confirm its “Leans”, or assumptions, tell it what it got wrong, and further refine the ask before you can get the feature built. Often, these decisions can be made with good judgment and do not require consensus-building or stakeholder input. However, instead of being spread out over a two week sprint, or surfaced in standups/Slack messages / ad-hoc huddles, or just resolved by a thoughtful engineer, you’ll address them all in a single afternoon as you document the feature. Now, multiply that list of questions by 10, layer in some roles & permissions, and sprinkle in a touch of subject matter expertise.
Questions grow more complicated and nuanced, and you’ve got to get things unstuck fast to keep your team moving. This is where your small, fast decision loops will serve you well. Simple habits to get started:
- Set expectations about decision-making and meeting cadences with your stakeholders early on in the project. I’m finding that more frequent, short decision reviews are best.
- Reflect often on what decisions you can make yourself vs what *really* needs stakeholder input. Trust your instincts and optimize for speed, even if it feels uncomfortable sometimes. The fastest path is often taking an opinionated stance, soliciting feedback, and adjusting as needed. That work is just happening at a different point in the build process.
2. Get comfortable working in the repo.
For my whole career, I’ve been in the room while the developers coordinated their pull requests and shepherded code from their laptops out to Staging and beyond. I was adjacent to the repo. I was never _in_ it.
Now, product specs, design references, and other context files all live in the repo alongside the code, which means that by extension, so do I. Most of what I commit is context for agents. I’ve even opened a handful of PRs for design changes on real projects, and when I do touch code, my developers review my PRs before anything lands in the codebase. I’m not pretending to be an engineer. I’m making sure the context that the team and the agents are working from is current, accurate, and in the one place everyone already looks.
Getting Familiar
On a recent project, my workflow looked like this: prototype a concept in Figma Make, demo it with stakeholders to pressure-test the flows and edge cases, surface and capture all of the decisions that need to be made while our agent is taking notes. Then, I update the repo with the revised design references, add in the transcript from the review call, and work with the agent to refine product specs to capture what was just decided. The more deliberately you pressure-test a design in stakeholder review conversations, the better the context you bring back.
As you work with your agents on the product specs and get familiar with the decisions you need to make, you’ll get a better feel for the types of questions you need to surface earlier during the definition work. The harder part is that managing all of this context is itself a job, and it’s a job that gets dramatically harder with more people. With one or two humans, you can hold the whole picture in your head. Add a few more and the risk of misalignment compounds fast.
Getting Started
For my first few agentic development projects, my teams were small (1-2 developers). Simple habits to get started:
- Record your calls, and make sure your transcripts are stored somewhere secure.
- Batch-process your updates. Give yourself time to process design revisions, transcript uploads, and spec refinements in a single work session. This will take longer than you think!
- Practice using Github. There’s lots of [great resources out there to get started](https://docs.github.com/en/get-started/start-your-journey/hello-world) and you can go a long way with the basics.
3. Plan on a physical board.
My planning lives on a physical board, in the room, with colorful sticky notes that I move with my actual human hands. Part of the reason is that the digital tools I used to rely on are built around the question I can no longer answer: “How long will this feature take?” I needed to stop asking it. Most of the complexity that used to bloat our estimates and drive teams a little crazy has moved upstream, into definition.
By the time work reaches implementation, the honest question usually isn’t, “How long?” The question is, “Is this blocked or not?” A board organized around _blocked vs. moving_ tells me more than a burndown chart would. For a small team, we optimized for flow and throughput. The board gave me a quick vibe check on whether there was enough queued up to keep development moving. In addition, the physical board provided an easy, visible surface I could review with project stakeholders and discuss priorities.
Sure, you could get the same effect with a digital board. HOWEVER. The bigger reason for the physical board is human.
Our planning board offered a shared ritual and an anchor in the space. It serves as a place where the small, co-located core gathers around. And after a day of watching work scroll past on a screen faster than I can read it, there’s something steadying about standing up, stepping away from the monitor, and moving a card with my hand. Don’t underestimate that.
Getting Started
Here are some simple habits to get started.
- Start with a basic kanban board if you don’t know where to begin. Get some sticky notes and a marker. You likely don’t have to build this habit from scratch. You just have to dust it off.
- Find the cadence that works best for your team. At Atomic, we’re working in twice-weekly planning sprints.
Final Thoughts
The judgment, the taste, the “knowing when the output is wrong,” the “keeping the team focused on the same goal” — that’s still the job. None of this is the work disappearing. Early in my career, a team member called me “the glue.” I still think that’s the right metaphor for leading delivery on agentic development projects. The glue just sets faster now, and it holds together a smaller, tighter team.