The Frame: Agent and Assistant are Pair Programmers
2 developers sit together at 1 computer. 1 developer acts as the “Driver” who drives the keyboard and actually writes code. 1 Developer acts as the “Navigator” who communicates with the driver through speech. Good pair programming happens when the Navigator is being helpful to the Driver, and the Driver is being helpful to the Navigator. Pair programming goes badly when one or the other isn’t doing their job or one tries to do both.
Thinking of Replit’s AI tools in this structure: Agent is your Driver, Assistant is your Navigator, and when you’re using one you need to act as the other.
This post will give you some tips and tricks for working with Replit’s AI tools in this pair programming frame, which I’ve found help people be more productive in building and shipping software using these tools.
The Goal: Collaborating Productively with the Agent and Assistant
Beyond the specific patterns I’m outlining below (being a good driver/navigator, using rollbacks, taking incremental approaches, boundary setup around driver instructions), there’s a deeper goal: learning to work in tandem with each of these AI tools, not as its supervisor or its underling — but as its collaborator in a pair programming session.
You bring context. You bring taste. You bring that intangible sense of what your code should look like and why. Meanwhile, the AI brings speed, memory, encyclopedic knowledge of syntax or best practices, and an ability to try a dozen approaches in a fraction of your time.
A normal pair programming session will consist of the 2 developers switching roles every 15-30 minutes or after completing a logical unit of work. You should work with Replit’s AIs the same way: navigating for the Agent while it builds a new feature, then driving for the assistant as it recommends strategic approaches or helps refine a feature to your liking.
Versioning Is Your Safety Net
Replit’s Agent and Assistant are designed to keep track of changes at every step. This means you can afford to experiment without fear. The Agent will make a commit before and after every action, and you can revert to the first commit by hitting “rollback”.
If you don’t like what the driver does, rollback. Don’t ask the driver to undo it, just rollback. 99% of the agent chats that go off the rails are some form of asking the agent to undo what it did instead of using the rollback feature. Every single step you take with the agent needs to work, and if it’s too complex an ask to get it to work in a single step you should use the Assistant to break the instruction or problem down into smaller sequential steps that can be, then do those. I cannot possibly emphasize this enough: use the rollback feature!
Working with The Driver (Agent)
The driver actively writes code and implements the immediate tasks at hand. Driver focuses on the tactical aspects of programming and handles the mechanics of typing the code. When it comes to the Agent, this means that every query or interaction you have with the agent is interpreted as an instruction: do this thing, write this code. You’re acting as the Navigator for the agent.
| Good Navigation | Bad Navigation |
|---|---|
| Giving specific, clear instructions on what to do next. | Not watching the driver’s progress. |
| Actively observing and providing feedback. | Ignoring the driver’s questions or requests for clarity. |
| Adjusting instructions based on the driver’s output. | Providing vague or overly broad instructions. |
| Encouraging incremental progress and testing. | Allowing the driver to proceed without checkpoints. |
| Clarifying goals and constraints as needed. | Assuming the driver understands unstated assumptions. |
The Agent Implementation Loop
- You: Provide a concise request (“Build this specific feature”).
- Agent: Immediately starts writing and refactoring code.
- You: Observe what it outputs, test if necessary, and confirm correctness.
The Agent won’t typically wait around to get the entire master plan. It implements first and asks questions along the way. This can be fantastic for momentum—but also requires you to stay vigilant. There are some product improvements coming to agent which will let you do more of a brainstorm, but for now treat every interaction with the agent as an instruction for it to implement, not a question/answer session.
One of the Agent’s strengths is that it can throw out partially working prototypes faster than many of us can, but you need to corral it into the right paths.
Communication Patterns with the Agent
- Clear Instructions, Clear Results. The Agent doesn’t do a deep philosophical debate about the best data structure. It leaps directly to an implementation.
- The Reset Pattern. If you ask for something that ends up incorrect or incomplete, revert to the last good state (checkpoint) rather than trying to fix it step by step in a messy flurry. Again, I cannot possibly emphasize this enough: if the agent does something you don’t like or that doesn’t work, hit rollback, open a new chat thread, and ask again with additional clarity / boundaries in your prompt.
Monitoring the Drive
- Active Observation. As code appears, keep an eye on how it evolves. The Agent will “show its work” in incremental steps in the progress tab. If you don’t understand the code the agent’s writing, there’s a plain text summary of the action at the top normally so you can follow along.
- When to Course-Correct. If you see it heading in a strange direction, do a rollback and refine your instructions rather than to coax it mid-flight.
You should be very clear with your instructions to the Driver. While you can interact with the driver by chatting with him, it’s dangerous because the driver will likely start writing code based off your first instructions. It’s much more effective to deliberately think through what you’re going to say to the Agent, then say it as a clear instruction for him to go off and implement.
The Driver (Agent) has a bias toward writing code to implement the instructions. Whenever you give an instruction to the Driver, you’re fundamentally asking him to write code. If you ask him to “go back or undo what you just did”, he is more than likely going to try doing that by writing more code. If you want the driver to go back, do a rollback. Again, please please please use rollbacks.
Working with The Navigator (Assistant)
The navigator reviews code in real-time, thinks strategically, suggests improvements, and looks up documentation while considering the broader architecture. They can spot potential issues and pitfalls before they arise. When it comes to the Assistant, the most effective way to working with him is as a chat. If the Agent is the hands at the keyboard, the Assistant is the brainstorming partner who stands behind you, thinking out loud.
The Assistant Planning Loop
- You: Pose a question or problem (“Is it better to store these session tokens using a hash map or a database? What are the implications?”).
- Assistant: Suggests possible solutions, diagrams pros and cons, and explains conceptual pitfalls.
- You: Use that insight to decide on an approach and start coding—or pass the instructions to the Agent for direct implementation.
The Navigator doesn’t write code directly, it will tell you what to do or write. It’s there to help you think, to propose potential approaches, to highlight hazards. It’s like a senior dev who’s great at noticing complexities but has promised never to touch the keyboard himself.
- Iterate on the Plan. Ask the Assistant about possible approaches, trade-offs, or best practices.
- Refinement Pattern. Each time an idea runs into trouble, you can come back for a deeper dive or alternative approach.
Building Blocks
The sweet spot is to let the Assistant help define or refine the approach, hand off the implementation tasks to the Agent, then refine what the agent did using the Assistant. You should be an active participant in both roles: learning from the Assistant’s suggestions and the Agents actions to make sure they’re working with you, not against you, as you build your software.
When working with either the Agent or Assistant, break large goals into smaller increments:
- Define a subproblem: “We need a function to parse dates.”
- Explain constraints: “Accounting for all valid formats up to a second resolution, ignoring time zones for now.”
- Implement or Plan: Either let the Agent write the code or get the Assistant’s insight on potential pitfalls.
Stack solutions in a logical order. If you need a parser for date input, do it first. Once that’s stable, move on to building the rest of the feature, step by step.
If your codebase is starting to sprawl, be explicit about what each function, module, or class is supposed to handle when you’re asking the Agent/Assistant to do something. The Agent and Assistant both have context of your codebase, but as the codebase gets bigger they might forget things you know are important.
Working Patterns and Pitfalls
The Rollback Pattern
A recurring theme: it’s easier to revert to what worked than to salvage broken code that’s drifting away from your vision. This is about maintaining code clarity and saving time. Use rollbacks, use rollbacks, use rollbacks!
Overscoping Requests
It’s tempting to say, “Agent, build the entire user authentication system!” But giant leaps often create:
- Inconsistent code
- Unclear architecture
- Debugging nightmares
Instead, keep requests bite-sized. A good pattern is asking the assistant to help you build the plan or instructions for the Agent to implement, then having the Agent implement each step in sequence.
Insufficient Testing
Eager to see big results, you might ask the Agent to implement 3-4 features in succession without testing the app. Don’t. After every step with the Agent, use the Webview to test out that it didn’t break any functionality in your app. The Agent is focused on what you’re asking it to do, it’s your job as the Agent’s Navigator to clarify
Fighting the Agent
Don’t go to war with the AI. If it’s writing code you hate, or it’s picking a weird library, politely roll back, clarify your constraints, and try again.
The “Human Judgment” Factor
Like any powerful tool—compilers, debuggers, or version control—AI can amplify mistakes as it can amplify successes. Your judgment is what keeps it aligned, making sure it’s actually solving your problem rather than just generating code. And a critical component of that judgement is being a good pair programmer, either as the Driver or Navigator, for Replit’s AI while they work with you.
Conclusion
Mastering AI collaboration gives you superpowers. You’ll write more code, faster, while preserving mental bandwidth for creativity, architecture, and problem-solving.
Remember, the Replit Agent and Replit Assistant aren’t mystical beings. They’re abstractions built on top of powerful language models, and like all abstractions, they occasionally leak. You will see them fail or provide strange answers. But once you learn their strengths and limitations—once you see their potential for incremental, test-driven, feedback-oriented collaboration—the horizon opens for new ways of building software.
Let them drive. Let them suggest. Stay curious, keep your mind open, and never hesitate to roll back and try again. It’s not about perfect instructions or perfect code. It’s about thinking with AI, embracing the balance between human creativity and machine collaboration, and discovering what’s possible when we program side by side with our future AI overlords
