Managing AI Like You Manage People
With the release of Claude Opus 4.5 (and the pace of improvement in frontier models), we’ve reached the point where AI coding assistants can handle tasks that would previously require a team of skilled developers. The capabilities are impressive enough that drawing parallels between managing AI agents and managing human teams feels less like a thought experiment and more like practical advice.
As someone who has spent years in engineering management and who has more recently been working extensively with AI coding tools, I’ve noticed that the skills transfer remarkably well in both directions. Here are some patterns that work for both.
Contents
- Documentation as Team Knowledge
- Continuous Improvement Through Retrospectives
- Automated Guardrails and the Dev Loop
- Technical Specifications and Writing Things Down
- Context Management as Cognitive Load Reduction
- Mental Flexibility and Decision-Making
- Looking Forward
Documentation as Team Knowledge
The most effective engineering teams I’ve managed have had copious (but
targeted) documentation: onboarding guides, coding standards, architecture
decision records (ADRs). For AI agents, this manifests as AGENTS.md files that
live in your repository.
The parallels are striking:
- Onboarding docs tell new team members how the codebase works, what
conventions to follow, and where to find things.
AGENTS.mdserves the exact same purpose for AI agents. Since AI agents otherwise start each coding session with a nearly blank slate about your codebase, it can’t be overstated how helpful this is. - Style guides ensure consistency across human contributors. For AI, you specify formatting preferences, naming conventions, and patterns to follow or avoid.
- What we call tribal knowledge often lives in people’s heads and gets
shared through pairing or code review. Writing it down in
AGENTS.mdmakes it accessible to AI agents too. - Meeting notes help humans have more efficient meetings with less repeated discussion of settled topics. They’re equally valuable for AI agents, providing clarity on what the “North Star” is for projects being worked on, and highlighting areas of most recent concern.
Just as you wouldn’t expect a new hire to be productive without proper documentation, you can’t expect an AI agent to work effectively without clear instructions about your codebase’s conventions and constraints.
Continuous Improvement Through Retrospectives
Good teams run retrospectives. They ask: What worked? What didn’t? What should we change? The output often becomes updated process documentation or new team agreements.
With AI agents, the same cycle applies:
- You notice the AI making a repeated mistake or missing context
- You update
AGENTS.mdwith clearer instructions - Future sessions benefit from that improvement
This creates a virtuous cycle where your AI instructions get better over time,
much like how team processes improve through regular retrospectives. I’ve found
myself treating AGENTS.md updates as a form of “retro action item” after most
AI coding sessions, and agents are capable of enough reflection to propose those
updates themselves when asked to do so.
The key insight is that both processes require intentional reflection. You have to actually notice what’s not working and take the time to document the fix rather than just working around it each time.
Automated Guardrails and the Dev Loop
One of the most effective ways to improve any team’s velocity is to automate the boring stuff: linting, formatting, type checking, test running. These tools catch issues before code review, reducing back-and-forth and cognitive load.
For AI agents, these same tools provide even more value:
- Auto-formatting (Oxfmt, Biome, Prettier) means the AI doesn’t need to worry about code style, and neither do you when reviewing its output
- Linting (Oxlint, Biome, ESLint) catches common mistakes that might otherwise require a conversation round-trip to fix
- Type checking ensures the AI’s code actually compiles and integrates correctly
- Running unit tests provides immediate feedback on whether changes broke existing functionality
Each automated check that catches an issue is one fewer back-and-forth cycle with the AI. Since AI interactions have latency costs (and sometimes token costs), this directly translates to faster iteration.
The Dev Loop: Autonomous Iteration
What makes these guardrails truly powerful is when they enable what’s sometimes called the “dev loop” or “closed-loop development”: an autonomous cycle where the AI can write code, run validation, diagnose failures, fix issues, and retry without human intervention between iterations.
Consider a typical workflow without a dev loop: you ask the AI to implement a feature. It writes code. You run the tests. They fail. You paste the error back. The AI proposes a fix. You run the tests again. Still failing. More back-and-forth. Each iteration requires you to be present, running commands, copying output, and providing feedback.
With a well-configured dev loop, the AI can execute that entire cycle
autonomously. It writes code, runs bun run check, sees type errors, fixes
them, runs again, sees test failures, reads the test output, adjusts the
implementation, runs once more, and finally succeeds, all without waiting for
you.
This is transformative for longer tasks. An AI agent can iterate dozens of times in the span of minutes, exploring approaches, hitting dead ends, backtracking, and eventually converging on a solution. Without the dev loop, each of those iterations would require your attention.
The Human Parallel: Ways of Work
Teams have their own version of this: established “ways of work” that let engineers operate autonomously within known boundaries. A senior engineer doesn’t need to ask permission for every decision. They know the coding standards, understand the testing requirements, and can iterate independently until they have something worth reviewing.
Good team process creates the same kind of autonomous loop:
- Engineer picks up a task
- They implement, test locally, and refine
- CI runs automated checks
- If checks fail, they fix and retry
- When everything passes, they open a PR for review
The human isn’t blocked waiting for feedback at every step. They have the tools and knowledge to iterate independently. The same principle applies to AI agents: give them the guardrails and validation tools to iterate autonomously, and they’ll be dramatically more effective.
I’ve noticed that projects with strong automated guardrails tend to have much smoother AI-assisted development. The AI can focus on the actual problem rather than getting tripped up by style inconsistencies or type errors, and it can self-correct when the tools tell it something’s wrong.
A Note on Code Review and Desk Checks
There’s more to say here that I may expand on in a future post, but briefly: code review remains the final guardrail for both human and AI-generated code. Automated checks catch many problems, but the judgment of a human (potentially augmented by a different AI model with enough iterations) is still essential for evaluating design decisions, identifying subtle bugs, and ensuring the code actually solves the right problem.
Similarly, the traditional “desk check” (where you manually walk through scenarios before calling something done) has an AI parallel. Describing integration scenarios or one-off test cases in markdown can be surprisingly effective. Sometimes this works better than reaching for a prescriptive automation framework like Playwright, especially for exploratory validation or scenarios that don’t justify the overhead of formal test automation.
Technical Specifications and Writing Things Down
There’s a reason senior engineers emphasize writing technical specs before diving into implementation. The act of writing clarifies thinking, surfaces edge cases, and creates a shared understanding of what’s being built.
I do have to caveat that there’s certainly a time and a place to do exploratory work with minimal documentation. But if that work turns into a more established product, then it absolutely starts to be worth the time to create documentation.
This applies doubly when working with AI:
- API schemas (OpenAPI, GraphQL schemas, TypeScript types) give the AI precise contracts to work with
- Technical specs help the AI understand not just what to build, but why, and what constraints exist
- Having architecture diagrams and/or explanations provides context that might otherwise require extensive codebase exploration
When I give an AI agent a well-defined spec, the results are dramatically better than when I give vague instructions. This mirrors my experience with human teams: clear requirements lead to better outcomes, and the discipline of writing them down forces you to think through the problem properly.
While AI certainly can reproduce some of this knowledge on demand, it’s very important to keep in mind that usable (and useful) context sizes are currently quite small. As such, concise and informative docs are very imporant to help increase the amount of useful work that can be completed before running out of context.
Context Management as Cognitive Load Reduction
Good managers protect their teams from unnecessary distractions. They filter information, provide relevant context, and shield the team from organizational noise that would reduce focus.
With AI agents, context management is even more critical:
- Trimming context to relevant files and information improves response quality and reduces costs
- Focused problem statements rather than dumping entire codebases lead to better solutions
- Large tasks should be broken into smaller chunks to prevent the AI from getting overwhelmed (and prevents you from getting overwhelmed reviewing massive changes), and allows for better continuity when AI context limits are reached and you have to start a new session or undergo compaction for the current one
- Offloading longer
AGENTS.mdsections into separate runbooks can help keep baseline context short; with an explicit instruction to consult those runbooks when needed, the AI can still solve situational problems (like working on a particular submodule) effectively
Just as you wouldn’t CC your entire team on every email thread, you shouldn’t feed your AI agent every file in your repository. Curate the context thoughtfully.
Mental Flexibility and Decision-Making
Effective managers balance openness to new information with the ability to make decisions and move forward. They’re willing to be proven wrong but don’t endlessly waffle. They examine data, consider options, and then commit to a direction.
Working with AI requires the same disposition:
- Be exploratory: The AI might suggest approaches you hadn’t considered. Sometimes they’re better than your original plan.
- Be willing to be proven wrong: Your initial assumptions about the problem might be incorrect. Let the AI’s analysis (especially when validated with follow-up questions) inform your understanding.
- But still make calls: At some point you need to decide whether to accept the AI’s suggestion, modify it, or reject it. Don’t get stuck in endless iteration.
As they used to say at one of my previous jobs, the sweet spot is confident humility: strong opinions, weakly held.
Looking Forward
We’re at an interesting inflection point. The management practices that work well for human teams are proving to be directly applicable to AI workflows. This suggests that as AI capabilities continue to improve, the skills gap between “good at managing people” and “good at working with AI” will continue to narrow.
It also suggests that investing in these foundational practices pays double dividends: they make your human team more effective today, and they prepare you for increasingly AI-augmented workflows tomorrow.
The engineers and managers who thrive will likely be those who recognize that clear communication, good documentation, automated guardrails, and thoughtful context management aren’t just soft skills or process overhead. They’re the infrastructure that makes both human and artificial intelligence work better.