RetrospectiveAgreeing on How We Develop Before Bringing AI Agents into the Team
· PinLog
- #AI Agent
- #협업
- #문서화
While other teams that started at the same time were beginning development, we were still breaking down the structure of our project. We were agreeing on conventions, assigning responsibility, and writing those decisions down. As a team joke, we called it “brain syncing.”
I brought the AI agent practices I had developed while building AlgoSu, my personal algorithm study platform, on my own into this team as well. It meant giving each agent its own role, and writing rules and decisions down in documents the agents read every time they worked.
Having used those practices before, sharing them might sound straightforward. But a team first has to agree on its direction, uncover assumptions people have not voiced, and decide who is responsible for what.
Deciding Alone
In AlgoSu, I could change any part of the project. Even when I delegated work to AI agents, I decided what to build, how far a change should reach, and whether to accept the result.
That did not make development easy. It did make decision-making simpler. A change spanning several areas still needed only my decision. My experience defining agent roles and shared rules in AlgoSu rested on that condition.
Solo project
AlgoSu
- Authority to modify every area
- One person decides direction and scope
- Agents receive the standards I define
Team project
PinLog
- Agree on ownership and responsibilities
- Reconcile different directions
- Share agreed standards and how to use them
In PinLog, identifying work was not enough. I also had to coordinate how it fit with other people's work and who would take it on. A condition I had barely noticed in solo development became much more visible.
Aligning Before Dividing Work
The difficult part was getting the ideas out of everyone's heads and working through them together. We had to reconcile what each person wanted and make tacit knowledge explicit.
Before implementation, we spent time breaking down the structure and agreeing on conventions and responsibilities. This was not a matter of handing over a plan I had decided alone. We were defining the standards we would use together.
We documented what we agreed on, so it would not remain something we understood only during the discussion. We could return to it while developing.
01
Surface ideas
Share directions and assumptions
02
Agree on standards
Define structure, conventions, and ownership
03
Document decisions
Keep agreements available for reference
04
Use them together
Give teammates and agents development context
This flow is a retrospective summary of the experience, not a formal methodology we adopted. We did the coordination we needed and recorded the outcome.
Fewer Re-asked Questions
I noticed the benefit of documentation during development. In earlier team projects, we often asked one another to clarify decisions we had already made.
“What did we decide to do here?”
In PinLog, that question became noticeably less frequent. Checking an agreement did not always require asking someone else. The documentation we had written while defining structure, conventions, and responsibilities was useful at that point.
Earlier team projects
We often asked teammates again about decisions already made
PinLog
Agreements could be checked in the documents, so the question came up noticeably less
While other teams were beginning implementation, we had been creating a reference for our own development work. The clearest sign of its value was hearing that familiar question less often.
AlgoSu Practices for a Team
I applied what I had learned in AlgoSu to let AI agents use these documents as development context. I shared the approach with my teammates, and we were able to use it together.
What went into the documents was different, though. On my own, I could record the structure and standards I had decided. In a team, we first had to align our thinking. Passing something to an agent does not resolve a decision the people involved have not yet agreed on.
The AlgoSu experience helped. But I could not simply carry over the convenience of being the only decision-maker. I could not assume teammates knew what I knew, or change every area based on my judgment alone.
As a solo developer, I had focused on dividing work and verifying results. PinLog made me consider how to coordinate direction and responsibility with other people as well.
What stays with me is not the name of a new tool, but the decline in questions about decisions we had already made. Bringing a practice from solo development into a team took more than explaining how to use it. We first had to make the standards in our heads explicit enough to share.