I expected my first project using agentic development to feel smooth and easy to pick up from day one. After all, I read Atomic’s agentic playbook and stayed up to date on the latest trends and models.
But when I started, I suddenly had more questions than answers.
Do I need to design this whole system upfront? How many specs should we have before we start writing code? Are we moving back to waterfall?!
My first hurdle had little to do with whether the tools could write code. I was struggling to determine how much of the product needed to exist “on paper” before I could ask an agent to build anything.
The hard part is getting past the blank page.
The first thing that got me moving was gathering the context we already had.
I gave the agent a transcript of the entire kickoff meeting, a Figma Make design, and several useful agent skills passed down from previous Atomic projects. The transcript contained the client’s language and decisions. The design gave the agent a visible target. The skills brought in practices other teams had already worked out. Then as a team, we built out an initial set of product specs.
Together, those materials gave me a useful starting point, even though the design of the whole system was far from complete.
That changed how I thought about the spec. I didn’t need to predict every decision we would make during the project. I needed to give the agent enough context to take a meaningful first step without filling every gap with its own assumptions.
It’s a playbook with room to adapt.
Atomic’s Agentic Engineering for Teams playbook describes a cycle of Definition, Planning, Implementation, and Review. Definition and implementation happen in parallel, with short iterations keeping the team’s understanding close to the software being produced.
That structure is helpful, especially when agents can generate code faster than a team can review and absorb it. But every team still has to find its own working cadence.
A detailed playbook can create pressure to get every artifact and ceremony exactly right before beginning. That pressure fed my early anxiety. Agile judgment still matters. Specs need to remain living documents that change as the team learns, and the process needs to respond to the project rather than becoming a set of rules we follow mechanically.
The playbook’s introduction makes a similar point: the fundamentals of agile software development still hold. Agents make clear direction, reliable tests, and team coordination more valuable because they can turn an unclear instruction into a large amount of incorrect code very quickly.
The work was always building the right thing
Some of my initial panic came from feeling as though my job had changed out from under me.
Writing code has been such a visible part of software development that it is easy to mistake it for the whole job. In reality, the job has always been to help the team build the right thing. That means understanding the problem, making good technical decisions, noticing gaps, and checking that the finished product behaves the way it should.
Agentic development made that division clearer. The agent could do much more of the “typing”, but it still needed direction. It could build what we described at remarkable speed. We were still responsible for deciding whether we had described the right thing.
Then the application started taking shape.
Once the agent built out the frontend from the design, adding the expected functionality became much easier.
The blank page was gone. We had something concrete to inspect, question, and improve. Features that had existed only in our initial plans began appearing in the application in large chunks.
The pace surprised me. We were moving toward the finish line faster than we had expected and much faster than I could have imagined before these tools existed.
This was the point when the tools stopped feeling theoretical. Given a clear design, enough context, and defined behavior, the agent could produce substantial working software. The early uncertainty gave way to a series of visible wins.
We all need to become testers.
That speed creates a new temptation. When an application takes shape quickly, it can feel finished quickly.
The core workflow might be present. The screens might match the design. The expected interactions might work. That polished first impression can hide corner cases, missing behavior, and assumptions nobody thought to put in the spec.
The time the agent saved gave us room to look for those gaps. That meant trying unexpected paths, comparing the product against the design and requirements, tightening acceptance criteria, and asking what could go wrong outside the happy path.
Testing becomes part of the daily engineering work, not something reserved for the end of implementation. The playbook’s Review phase reflects that need: teams have to probe risks and test the integrated product frequently enough to keep their understanding from falling behind the code.
Agents can help write and run tests, but humans still need to decide what deserves testing. We have to recognize suspicious behavior, find the assumptions buried in a feature, and judge whether the result solves the client’s problem.
The process needs to fit the project.
This experience also left me skeptical of treating agentic development as a single process that every project should adopt in exactly the same way.
Some work begins with enough context to define and delegate a useful slice. Other work needs more exploration before a good spec is possible. The amount of definition should match the uncertainty of the problem.
The same applies to team cadence. The playbook gives us a shared model and vocabulary, but teams still need to decide how many specs they need, how large each one should be, and when they know enough to start building. Those answers may change even within one project. One tool that can help with this is the Definition Strategy chooser, a tool my team consulted several times throughout the project to make sure we remained strategically aligned.
On my next agentic project, I’ll spend less time staring at an empty spec and wondering whether I need to design the whole system. I’ll begin with the context we already have, define the smallest useful slice we can verify, let the agent build it, and use the time it gives back to test what we made.