In the previous articles, I argued that AI is just the next abstraction layer, and that the key skill it demands is clear technical communication — the same skill that makes great tech leads and architects. But that’s still abstract. Let me make it concrete.
Because here’s the thing: we already have a well-established workflow for communicating technical intent to other humans. And AI agent workflows are not just similar to it — they’re a direct mirror.
This Is Not a Coincidence
We, humans, do not do this because of AI. We designed AI so it can understand our usual steps. The agent workflow mirrors the human team workflow because that’s what we trained it on. That’s what we optimized it for.
Let me show you what I mean.
The Human Team Workflow
How do we actually do things in a position of, say, a Tech Lead or Team Lead? Let’s trace the typical workflow:
Step 1: Grooming a business request. Who is involved? Product owner, a lead (tech lead or team lead), probably a developer who will be designated to implement this thing or a knowledge keeper for specific functionality. Those people basically create a design document without implementation specifics — a high-level description of what needs to be done and why.
Step 2: Technical decomposition. The lead and a developer break the design into technical tasks — what components to change, what APIs to create, what data models to adjust.
Step 3: Task scheduling. A project manager organizes the work into sprints, sets priorities, estimates timelines.
Step 4: Code review. After development iterations, another developer or the lead examines changes. At this point, the examiner does not implement anything directly — they only look at the final result and evaluate it. Is it good? What needs to be changed? Does it match the original intent?
The AI Agent Workflow
Now look at how modern AI coding tools work:
Step 1: Design document. You describe what you want — the context, the goal, the constraints. This is your “grooming” phase. You’re the product owner and the tech lead in one person.
Step 2: Planning/decomposition. The AI (or you, together with AI) breaks the task into steps — what files to change, what to create, in what order.
Step 3: Execution. The AI works through the plan, implementing step by step.
Step 4: Review. You look at the result. You don’t implement — you evaluate. Does it match your intent? What needs to change?
Same workflow. Same roles. Same sequence. The only difference is that steps 2 and 3 are now done by an AI instead of a human developer.
The Amnesia Problem
But there’s one critical difference between a human teammate and an AI agent: memory.
A human developer on your team remembers your project. They know the architecture. They remember that weird edge case from three months ago. They know that “the payments service” actually means two services because of that legacy split nobody documented.
An AI agent knows nothing. Every conversation starts from zero. It’s a competent developer — but one with complete amnesia about your specific project.
This changes everything about how you should communicate with it:
- They’re competent but don’t remember your project specifics
- They need clear context for each task
- They can do great work if you explain what you want precisely
- They will make assumptions if you leave gaps — and those assumptions might be wrong
The RAG Trap
So here’s where many teams go wrong. They think: “If the problem is amnesia, let’s give it all the memory. RAG, vector databases, persistent context, the entire codebase indexed and searchable.”
And yes — it helps. But it has the same drawbacks as increasing the context window: more information means more potential confusion. Greater knowledge — greater sorrow.
You can give an AI agent access to your entire codebase, all your documentation, all your Jira tickets. But if your prompt is vague and poorly structured — it will hallucinate confidently in ten different directions. More context without better communication is just more noise.
Think about it from the human analogy. If you dump a 500-page wiki on a new developer and say “figure it out” — they won’t. They’ll drown. But if you give them a clear task description, point them to the three relevant files, and explain the constraints — they’ll deliver.
Same with AI.
The Practical Framework
Here’s what actually works. Start treating your AI interactions like you’re onboarding a new team member for every task:
Context first. Before the task, provide the relevant context. Not everything — just what’s needed. Architecture of the specific component. The relevant data models. The constraints that aren’t obvious from the code.
Clear intent. State what you want to achieve, not just what you want to change. “Add a retry mechanism to the payment service because transactions sometimes fail due to network timeouts, and we need at most 3 retries with exponential backoff” is infinitely better than “add retries to payments.”
Constraints explicitly. What should it NOT do? What patterns should it follow? What’s the testing strategy? Don’t assume the AI will infer these from context — it might, but it might not.
Review like a tech lead. When you review the output, don’t just check if it works. Check if it matches your intent. Check if it follows your patterns. Check if it handles the edge cases you care about. This is exactly what you’d do in a code review with a human developer.
Store the Repeating, Vary the Specific
One more practical tip. Start storing common things in markdown files — steering files, documentation, architecture decisions. That way you retain only repeating information as persistent context, and variables — the specifics of each task — will be added as you explain your current goal.
This is not different from onboarding a new team member. You give them docs, you give them context, and then you give them a task. The better your docs and the clearer your task description — the better the result.
The things that don’t change between tasks — your coding standards, your architecture patterns, your testing philosophy — those go into persistent documentation. The things that are unique to each task — the specific requirement, the specific constraints, the specific acceptance criteria — those you communicate fresh each time.
The Developer of the Future
In the end, I want to emphasize this: developers of the future will need not only knowledge of how to develop, but also a skill in explaining what exactly they want from an AI agent.
The irony is beautiful. We spent decades building abstraction layers to avoid explaining things to machines in their language. And now the machines finally learned our language. The developers who will thrive are not the ones who memorize every API — they’re the ones who can explain what they need as clearly as a good tech lead explains a task to their team.
This way you really unlock the full potential of AI agent as a tool in your hands. Not by fighting it. Not by fearing it. By talking to it the way you’d talk to a skilled colleague who just joined your team today.
Top comments (0)