Atomic’s
Agentic Engineering for Teams describes how work moves through a product backlog, definition, planning, implementation, and review when agents do much of the building. While working with a small team during a Research, Design, and Planning (RDP) engagement, I started paying attention to a smaller decision inside that process: how much authorship we give AI over each artifact.
Background
We recorded our meetings and saved the transcripts in a shared knowledge base. Everyone on the team had a record of what was said, and our agents could refer to the actual words used in the room.
From there, it would have been easy to automate the rest. An AI could summarize each meeting. Another agent could turn the summaries into backlog items. An implementation agent could read those items and start building.
Problem
AI made each handoff faster, but the final result became harder for the team to recognize and own. Small changes in vocabulary, scope, and intent travel through the workflow before the team catches them. For example, a meeting summary introduces vocabulary nobody used. A backlog item turns an open question into a decision. Generic concerns about input validation or security become horizontal implementation work the team never chose for this MVP. The implementation gets divided into domains that nobody discussed and that developers struggle to recognize in the code.
Even so, every artifact can still look organized and accurate. The chain may even trace cleanly from the meeting summary to the backlog to the implementation. But it contains conclusions no one remembers making, based on statements pulled out of context. The result lands in an uncanny valley, polished enough to accept and unfamiliar enough that nobody feels much ownership over it.
AI made each handoff faster, but the final result became harder for the team to recognize and own.
The products we deliver are shaped by the judgments and decisions we make as software consultants. As we research, discuss, and solve problems with teammates and clients, we build a connection to the result. That process is a big part of why I enjoy building software. When I let AI make too many of those judgments, I risk losing my connection to the success or failure of the work.
I think Atomic’s principles of Curiosity, Craft, and Care offer a way to decide where AI belongs. AI can speed up the work in all three. The artifact’s purpose should determine how much authorship we hand over in exchange for that speed. I am comfortable letting AI produce disposable options. However, I stay close to artifacts that commit the team to a decision. I want a person to write the artifacts that carry a relationship.
Curiosity: Chase the Questions
Curiosity is where you can let it rip. Research, test, build, or vibe-code a proof of concept. Ask an agent to explore several approaches or help you understand how pieces might work together. These outputs help you ask better questions without committing the team to a direction.
The transcripts in our knowledge base were useful here. An agent could search the source material, pull together related comments, and return the exact words people used. A team member could then check the agent’s inference against the original statement and the surrounding conversation. The agent found and organized the evidence. A person decided whether the inference held up in context. I am comfortable giving AI a large role in this work because most of the output is temporary. We can throw away a weak idea, test another one, and keep moving
Craft: Own the Choices
The work changes once an artifact starts committing the team to a direction. A backlog item shapes what gets built. An implementation plan creates boundaries in the code. Those decisions need the judgment of someone who understands the product, the client, the current phase, and the codebase.
We wrote our backlog items ourselves. The titles, descriptions, and acceptance criteria used vocabulary already familiar to the team. You could read an item and recognize the product we had been discussing with the client.
Agents still had a role in planning. They could propose, compare, and challenge implementation approaches. A developer guided the work alone or with a pairing partner, kept the plan grounded in our shared domain language, and steered it toward one vertical slice that fit the scope of the current phase.
Those implementation plans went into a separate section or comment dedicated to agent guidance. The backlog item remained a concise description for the people planning and discussing the product. The agent got the technical detail it needed without turning the human-facing backlog into an implementation manual.
Care: Stay Hands-On
By comparison, some artifacts carry more than information. A meeting summary tells your teammates what you heard and what you believe the group decided. A client update represents the team’s understanding, confidence, and relationship with the client.
We wrote those messages ourselves. Our meeting summaries went into Slack using language everyone understood and had already accepted. Updates to the client kept the same communal and personal tone.
LLMs cannot care, plain and simple. Care comes from someone who understands the work and takes pride in it. You can describe your standards to an agent and give it skills that encode them, but the agent cannot take pride in meeting those standards or accept responsibility when the work falls short.
You can still delegate plenty of artifacts and code. Direct involvement matters most when an artifact commits other people, speaks for your team, or becomes something you will have to explain and support.
As a result, our backlog became easier to consume. Messages within the team and to the client sounded like they came from people who had been in the room. Developers understood the vocabulary, the scope, and the codebase they were guiding agents to build.
By the time work reaches a client or user, you should be able to explain why it works the way it does, which tradeoffs you made, and why you are willing to put your name on it.
