Managing AI Like a Team, Not a Tool
At ten in the evening my business website went live: DNS cut over, forms tested, Search Console verified. I wrote almost none of the code. An AI assistant did, coordinated by an even stranger arrangement: parts of the work were done by a second, smaller AI that the first one had set up on my machine a week earlier.
The internet is full of guides on agentic AI workflows. Most of them are tool tours. What I have not seen much of is someone saying what it is actually like to run this stack for real work, with real money and a real name on the domain. So here is my honest version, told the only way I know how to tell it: as a project manager.
Because that is the real finding. After sixteen years of delivery work I can say the thing that made AI productive for me was not clever prompting. It was treating AI the way I treat a team.
Chapter one: hire the assistant, build its memory
I started by building a personal assistant on top of a coding agent: my calendar, inbox triage, job search pipeline, daily briefs. The first week taught me the lesson every practitioner eventually posts about: context is everything. An AI with no memory is a brilliant contractor with amnesia, re-learning your world every morning at your expense.
So the first real deliverable was not automation. It was memory: a plain-text wiki the assistant maintains, one page per person, project, and decision, plus an operating manual that tells it how I work. Every session reads from it, every session writes back to it. Boring. Also the single highest-leverage thing I built all month.
The second deliverable was a habit, not a feature. After every piece of work, we run a retrospective, and the lessons get distilled into reusable skills: little playbooks the assistant loads next time the same kind of work shows up. A mistake becomes a rule; a rule becomes a checklist; the checklist runs automatically forever. Teams call this organizational knowledge. It compounds the same way here.
Chapter two: the assistant hires a junior
Cloud model tokens are expensive, and most of a working day is not judgment. It is summarizing, classifying, extracting, reformatting. You do not send your architect to do data entry.
So I had the assistant set up a local AI on my own machine: two small open models running for free, around the clock. We gave them the jobs you would give a bright junior: condense this long email thread, tag these transactions, draft a rough translation, write this flat piece of logic.
Then we managed them like juniors, and this is where the PM lens pays off:
- Bounded work only. The local models never touch decisions, tools, or anything a human will read in my voice. Their output is a draft by definition.
- Tests before trust. When a local model writes code, the assistant writes the test suite first and the junior iterates until it passes. The senior reads the test results, not every line.
- Vote on judgment calls. Anything judgment-shaped runs three times; if the answers do not agree, it escalates to the senior model. No majority, no merge.
The economics work exactly like team economics. The senior stays on the problems that need seniority, the junior grinds through volume at near-zero cost, and the interface between them is a contract, not vibes.
Chapter three: the team ships a real product
Then we pointed the whole stack at something with stakes: goecomaz.com, the website for my web-services side business. Real customers will read every word, so this was the test of whether an AI team can meet a real definition of done.
Two management practices carried the project.
First, gates. Big work does not start until I have seen a plan: the approach, the cost, and two or three options with a recommendation. I approve, then the team executes. Every time I skipped this and let the AI run ahead on guesses, I paid for it in rework. The same discipline that protects a human team from a wandering sponsor protects an AI team from a wandering one-person board, which is me.
Second, review rounds with teeth. The first drafts of the site copy were grammatically perfect and completely lifeless, the way AI writing usually is. It took eight rounds of feedback to teach the assistant my standard: open with the customer's actual pain, kill the tidy three-item feature lists, prefer a plain word with weight over a correct word with none. Those eight rounds became a permanent review skill, so every future page starts where the last one ended. That is the compounding again.
The result: a live business site, on-page SEO done in one evening, contracts researched and templated, total tooling cost close to zero. And every process we invented on that project now runs my personal site too, including the system that generated the thumbnail on this very post.
What I would tell another PM
Five principles survived contact with reality:
- Gate the big work. Plan, cost, and options before execution. AI moves fast in the wrong direction just as happily as in the right one.
- Define done as what the end user experiences. The AI saying it deployed is a status report. A stranger's phone rendering the page correctly is done. Verify on production, every time.
- Run retrospectives and bank the lessons. An AI without retros stays a tool. An AI whose lessons become reusable playbooks starts behaving like a team that gets better every sprint.
- Delegate by cost profile. Give bounded, verifiable work to the cheap junior; keep judgment, taste, and anything customer-facing with the senior. Put tests at the boundary.
- Trust, then verify anyway. My assistant once looked at 189 old pages, read only the metadata, and declared them junk. They were a 182-page knowledge base I had spent months writing. One skeptical question saved it, and the near-miss became a rule: never kill a body of work without opening a sample. The AI does the work. The verification is still mine.
None of this needed a bigger model. It needed the same things every delivery has ever needed: memory, gates, reviews, retros, and someone accountable for the definition of done. If you already know how to run projects, you already know how to run AI. The team just got a lot cheaper, and it never sleeps. See also why projects fail: the causes have not changed, and they apply to AI-built projects too.
Nguyễn Hải Nam
Nguyễn Hải Nam
Project Management Lead. 16+ years from code to delivery. PMP®. Writing here about project management and engineering.