You already know it...getting useful code from a coding agent takes more than choosing a model. You need to give it a clear task, decide what it can access, keep parallel work organized, and review the result. That's where RepoPrompt comes in and levels you up. This release improves those parts of the workflow, from revising a prompt before submission to recovering a session when you return to work.

You already use a coding agent and the reason to try RepoPrompt is the workspace around it: a place to coordinate compatible agents, prepare their context, consult other models, and inspect their work. RepoPrompt users already get it, and version 1.7.0 makes that workflow easier to manage as your tasks grow beyond a single conversation.

NEW: Control which environment variables reach each provider​

A development shell can accumulate credentials and endpoint settings for several services. Those variables may be useful to one provider and unnecessary—or confusing—to another.

The new opt-in provider environment filtering lets you name ambient variables to withhold from newly started provider processes, then add per-provider exceptions for the variables a connection actually needs. The same filtering applies to provider probes and headless launches.

For an engineer switching between providers, this offers a more deliberate setup than starting every agent with the same inherited environment. You can keep a shared development shell while tailoring which named variables reach each provider process.

The rules apply to new processes after you save them. They do not change running processes or your interactive terminal, and they do not isolate credential files or other resources available to your macOS user.

Read Provider environment filtering for configuration and exceptions.

NEW: Approve external MCP connections for the current app run​

MCP makes it possible to use RepoPrompt's tools from an external coding client. Connection admission matters because a familiar client name alone does not establish which program is connecting.

With Strict connection approval enabled, RepoPrompt ignores built-in and saved client-name approvals and requires admission for the current app run. Approved connections can reconnect within that run. Agents started inside RepoPrompt do not need this external-client prompt.

This gives you a clearer checkpoint when connecting external tools to your workspace. Compared with relying on remembered client names, you can review the connection you initiated and its available executable information before admitting it. Connection admission remains separate from workspace-operation approvals and the agent's own permissions.

See Connection Management.

NEW: Delegate coordination with explicit boundaries​

Parallel agents become useful when their tasks are distinct and their results are easy to bring together. They also create administrative work: naming sessions, grouping investigations, tracking progress, and arranging separate checkouts.

Version 1.7.0 expands Overseer coordination with delegation scopes for session organization and other permitted actions. You can ask an overseer to group completed investigations, pin the active implementation, or archive finished work. A scope defines which sessions it covers, what actions it permits, and its limits.

Nested delegation lets an authorized overseer give another session a narrower coordination scope. That scope cannot expand its parent's capabilities, membership, or limits. With the required authority, an overseer can also create or bind worktrees for target sessions and prepare integration. Merge application still goes through the target session's user review.

For a change spanning a backend, client, and test suite, this means you can delegate more of the coordination instead of manually relaying every update between independent agent conversations. Quieter routine check-ins also reduce the noise around that work. You still decide the boundaries and review integration.

Explore session organization and nested delegation and worktree operations for linked agents.

NEW: Improve the task before the agent starts​

A rough prompt often mixes the desired outcome, implementation guesses, and constraints. Discovering that ambiguity after an agent has edited several files is an expensive time to clarify it.

Re-prompt uses a separate model to revise the draft in your composer. In normal review mode, the first Send rewrites the request; you review or edit the result, then send it to the execution agent. The rewriter can offer a clarification question, and you can configure its model and rewrite guidance.

For example, you can ask the rewriter to preserve acceptance criteria and file paths while separating required changes from open questions. This adds a review point before execution instead of making the coding agent infer every constraint from an informal request. It is especially useful when you know what should change but have not yet organized the brief.

The rewriting provider receives your message and supporting metadata, with recent chat excerpts included when enabled. It does not receive file contents, attachments, Git output, or tool results as part of that rewriting request. Review the draft for assumptions before sending it.

See Re-Prompter for review mode, optional automatic sending, clarification, and guidance settings.

NEW: Make model and effort decisions fit the task​

Choosing a model, choosing its reasoning effort, and managing remaining plan usage are related decisions, but they are not the same decision.

Version 1.7.0 adds decision-service choices for Model Router and Auto Effort in Agent Decisions, revises new-task defaults, improves usage balancing, and updates available model choices. It also bundles Codex 0.164.0.

Model Router can choose an eligible execution model and initial effort for a new task. Auto Effort can choose reasoning effort for eligible turns while keeping your selected model. Optional local usage balancing considers connected plans' remaining allowances and reset times, with policies for approaching limits, pacing usage, or using expiring quota first.

If your workflow currently means manually switching agents or changing effort for each task, these controls can reduce that repeated setup. You can use routing where it helps and keep explicit choices where predictability matters. Established sessions and explicit model pins retain their targets; routing does not replace the model on every follow-up. Decision services receive task excerpts, so review their data-sharing settings as well as their recommendations.

Read Model Router and Agent Decisions and Auto Effort. Providers & Models remains the reference for supported connections and model availability.

NEW: Give Oracle the evidence it needs​

Sometimes the best next step is a second opinion on the implementation. For UI work, that opinion may need a screenshot. For a requirements question, it may need the document itself.

Version 1.7.0 broadens file-attachment support for app-backed Oracle consultations, including images through oracle_send. Supported inputs include images, UTF-8 text, and PDFs where the selected route supports native documents. Grouped consultations also have clearer responses and guidance for inspecting each Oracle's answer and status.

This makes it easier to ask another model about the same evidence your coding task depends on, without manually translating a screenshot into prose or copying each response between separate chats. You can compare findings, identify disagreements, and bring the useful conclusions back to the execution agent.

Attachment support depends on the route, and grouped consultations send the originals to each Oracle, increasing total usage. Attachments belong to that consultation turn; continuations do not automatically resend them.

See Oracle file attachments and the oracle_send reference.

NEW: Move between active tasks from the keyboard​

When several agents are running, the next useful action is often to answer a question, stop a run, or review a finished task.

The updated keyboard controls let you remap shortcuts, focus the composer, stop the current run, reopen the last stashed session, and jump to sessions needing attention. By default, Command+L focuses the composer, Command+. stops the current run, Shift+Command+T reopens the last stashed session, and Shift+Command+A cycles through sessions with unseen completed, failed, or waiting badges in the current window.

For engineers juggling multiple conversations, these controls reduce the navigation between noticing a task and acting on it. You can move through the work that needs review without checking every conversation in turn.

Review and customize them in Keyboard Shortcuts.

NEW: Return to work with less recovery overhead​

Version 1.7.0 improves restoration of sessions, worktrees, and windows, reduces repetitive MCP approval, and includes fixes for interrupted processes, Git reads, diff context, and background indexing.

These improvements matter when an engineering task lasts longer than one sitting. Returning to the relevant conversation and checkout helps you pick up the investigation; reliable Git reads and diff context help you assess what actually changed. The benefit is less time reconstructing your working state around the agent.

After an interruption, still inspect the latest session result and repository state before continuing. A restored conversation does not by itself establish that an interrupted operation completed.

See Session History, Worktrees, and MCP connection approval.

Get RepoPrompt CE 1.7.0​

Download the release and try it on a task where coordination matters: a refactor with an independent review, a UI change that needs visual evidence, or several investigations that should run in separate worktrees.

Computer Use setup: In the official build, Computer Use requires an OpenAI-signed Codex executable. Choose a compatible local executable in Settings → Codex CLI → Advanced, then restart RepoPrompt. Ordinary Codex conversations continue to use the included runtime.

Download RepoPrompt CE 1.7.0 and read the release notes, browse the full changelog from 1.6.0 to 1.7.0, or open the 1.7.0 documentation changelog.

I am happy to announce that RepoPrompt Community Edition is now live on GitHub! The current release version download is at github.com/repoprompt/repoprompt-ce/releases and the code is available at github.com/repoprompt/repoprompt-ce.

This is now the active development home for RepoPrompt. It is the place to open issues, contribute pull requests, follow architectural work, and experiment with the app's agent-first future.

When I first started building RepoPrompt, it was just a simple tool for copy-pasting codeblocks into Claude. But as we wrestled with token budgets, prompt compilation, and file structures, we soon stumbled into the broader world of context engineering.

Today, it has evolved into an extremely capable multi-agent orchestration tool. This was achieved by inverting traditional harness design, making the Model Context Protocol (MCP) server the primary agent so that the underlying CLI harnesses can be swapped out or upgraded seamlessly.

This version of the app has been designed specifically to thrive in the age of open source driven by coding agents. This means that many of the legacy features you might traditionally think of RepoPrompt for have been removed to maximize the potential of its tools for parallel agents. As a community, we've stripped the legacy baggage to focus on speed, context density, and raw agentic performance.

I have worked hard to turn RepoPrompt's source code into a lean codebase that is easy to hack on, easy to extend, and shaped around the way coding agents now work. The project includes a build system designed to scale to parallel coding agents, along with a one-click installer that compiles and installs the app.

While this is still a Mac native app, the project structure was completely redesigned to shed the need for Xcode, taking heavy inspiration from Peter Steinberger's work. You can now build, run, and contribute using standard command-line tools without having to deal with the complexities of .xcodeproj files.

Core work is already underway to split the project into focused packages, isolate the core, and make cross-platform versions easier to build without starting from a completely new codebase. You can follow that work in pull request #118.

The repository also borrows from Mario Zechner's pragmatic example of keeping a list of approved contributors, but adds a twist where all previous customers who opted in are automatically whitelisted. It is my way of saying thank you for supporting this project.

I really think this repo can serve as a learning baseline for many to build novel agent experiences without having to maintain complete, complex harnesses. If you are looking for RepoPrompt Classic, the archived code is available here and it remains available as a standalone download here. Classic preserves the original Xcode-based app and its IDE mode as a reference point for inspiration, experimentation, and bringing useful ideas back into Community Edition.

Start by exploring​

You do not need to arrive with a finished contribution. Fork the project, explore it with your coding agent, and use the technology inside it to create your own tools, workflows, or entirely new experiences.

Issues, focused pull requests, experiments, and curious exploration are all welcome. The goal is not just to preserve RepoPrompt as it exists today, but to make it a foundation that other people can build on.

As I have said previously, my new adventure at OpenAI is taking me away from active involvement in this project. The entire RepoPrompt community has been wonderful from the very start, and I look forward to all of you stewarding the next generation of RepoPrompt.

If you want to get involved with development, please join the amazing RepoPrompt Discord community!

Let's build the future of agentic coding together.

July 16th, 2024. That was the day I shipped my first build of RepoPrompt to testers who found their way to my TestFlight through a Reddit post about automating copy-pasting.

Back then, very few coding tools existed that could really take advantage of AI. Cursor limited models to 32k token context windows, and file edits required dedicated edit models that broke down on files more than a few hundred lines long. And yet, if you pasted some files into ChatGPT, it was clear that models could greatly accelerate the work of coding.

Back in June of that year, Anthropic shipped Claude Sonnet 3.5. It was the first model to consistently deliver usable code, follow instructions competently, and support a context window large enough to start scaling model understanding to production codebases. It wasn’t obvious back then because reliable file editing was still a bit of a mirage. Tool calling was primitive, and your best bet was spoon-feeding the model with the right context and copy-pasting the results back into your files by hand.

This obviously sucked, so early RepoPrompt was focused on both of those problems. While it wasn’t 100% reliable, I’m pretty proud of how well it worked by the fall of 2024.

When reasoning changed the workflow​

Enter December 2024. A couple months after announcing o1 Preview, OpenAI released o1 Pro on ChatGPT, and boy did it change everything.

While Sonnet was capable of writing basic logic, doing frontend, and helping you think through problems, it was fundamentally unable to think through complex algorithms and needed tons of iteration in order to generate code that actually worked.

o1 Pro was different. It reliably crunched through a lot more context. It was slow as heck, but it could one-shot really hard problems, assuming you gave it sufficient context. It was reliable in a way all models that preceded it were not. More importantly, however, it allowed me to start tackling problems that I could not conceive of being able to solve without AI. It was a real early taste of superintelligence, albeit an extremely narrow one that could not check its own work.

Fast forward to February 2025. Claude Code had just shipped, but the Max plan had not, and thus the tool was just a way to light money on fire, especially since Claude at the time could barely edit a few files without spinning out and wreaking havoc. Despite that, it was a glimpse of the potential for fully self-driving coding.

While people were impressed, my RepoPrompt workflow, which was significantly more manual, saved me time and allowed me to reliably edit and grow my codebase, shipping novel features, optimizing performance for enterprise-scale codebases, and keeping bug counts low as the user base grew.

People often talk about the two extremes of working with AI for coding. On one end there is manual code writing, perhaps with some tab-to-complete. On the other, there’s fully agentic automation. In the middle, there’s this underexplored path that I was discovering: manually curating context for models to write targeted file edits you could review without getting overwhelmed.

While that form factor was a bit too clunky for people to really appreciate, the fundamental techniques involved in spoon-feeding reasoning models with curated context continued to produce such outsized gains over naive prompting that I could not ignore them.

Context still matters​

Even though models now excel at navigating your codebase with little guidance, the constraints on context windows and attention continue to mean that the models reason on solutions after only reading small fractions of your codebase. Conversely, if you figure out exactly the right context a model needs to see to solve a problem, you can maximize how many tokens are allocated to solving the problem vs. understanding its scope.

And yet, naive prompting is just so convenient, and it doesn’t require a manual. Much of RepoPrompt’s biggest hurdle to wider adoption has been that complexity, which I struggled to distill down into a set of buttons and knobs users could control without needing a masterclass.

It turns out that with enough iteration on MCP tooling, you can equip any harness with a smart enough model to use these tools that people struggled to understand, and even go down to a level of granularity that remains out of reach save for the most diligent engineers.

Enter the context builder agent. If there’s one thing I could not live without today as I continue to work with agents, it is this: a complete automation of the construction of a dense prompt that maximizes understanding around a problem, without actually trying to solve it.

The magic is then taking this prompt and feeding it to an oracle model that has its tools disabled, to simply reason about the solution with a bird’s-eye view of the codebase. It simply produces better architecture designs, code reviews, and general analysis than naive agent prompting. This may seem counter to the bitter lesson, but it actually scales with model intelligence, and proves to me how early we are in designing optimal architectures for models to do their best work.

I’m always surprised that no one ever copied the context builder agent, because it is by far the most useful tool RepoPrompt ships with, and all workflow prompts in the app depend on it as a brain. It is the number one reason the RepoPrompt codebase has not devolved into unmaintainable slop, as each task that flows through it results in a plan that stems from a deep understanding of the most relevant context in the codebase. It turns out that most problems, even in large codebases, can have their relevant context packaged up into about 120k tokens.

A transition​

Today, RepoPrompt is more capable than ever. Its built-in agent features state-of-the-art multi-agent orchestration tooling and the included workflows make driving it effortless and dependable. Yet, as the steady drum of model progress continues, so grows the volume of well-funded competition in the realm of AI coding.

My passion has always been to drive product, and the need to commercialize that product to keep going has weighed on me since the beginning. Being a bootstrapped founder is relentless, as every subscription you earn might disappear the very next month. While I am absolutely convinced that my tooling drives better results, it’s increasingly challenging to convince someone that they should pay me $15 a month to obtain those gains when they can just prompt their agent to solve problems for them, and it “just works.”

A couple of months ago, I was approached by Romain Huet, OpenAI’s head of developer experience, to join his team and help push my vision for building with these models on a scale that I could never achieve on my own. Of course, before agreeing to anything, my first request was to ensure the dedicated users of RepoPrompt, who supported my journey until this point, were taken care of.

While I won’t be able to steward RepoPrompt as I have in the last couple of years, I’m pleased to announce that I’ll soon be releasing RepoPrompt Community Edition, a fully free and open source version of the app that sheds the legacy baggage holding it back from scaling in this next phase of massively parallel agent orchestration. My hope is that all those asking for a Windows port or a mobile app will be able to build on the foundations I’ve laid out and make something truly great.

Moreover, as of the 2.1.32 update, RepoPrompt’s licensing restrictions have been fully removed and all current subscriptions have been cancelled. Transitions like this are never easy, and I’ve done my absolute best to do right by everyone in the RepoPrompt community, and set the project up for a continued flourishing life without my daily involvement.

It’s never been clearer to me that we are still at the very beginning of tapping into the potential of models and agents. Every few months we unlock new capabilities, and as part of my new role, I’ll be working to make these capabilities accessible to everyone.

To the RepoPrompt community that has been with me so far, thank you. I would not be where I am today without you.

Since starting work on RepoPrompt, back in summer 2024, my workflow with AI models has not stopped changing.

One constant through all that change however, has been the importance of maximizing the relevant context fed to the model, given how much context it's able to reliably process.

Understanding Context Windows: Advertised vs. Effective​

That last point is worth clarifying: LLMs have an advertised context window, and then an effective one.

Until this year, models had a precipitous drop when crossing the 32k token barrier.

I'd say right now most models perform admirably in the 64-128k token range, but going beyond that is perilous, as the ability for the model to effectively reason over more context drops dramatically as its intelligence drops proportionally to the context served.

One important consideration for long context reasoning, is the size of the model. In most cases, smaller models struggle a lot more than larger ones with longer context, and I expect that to remain true for a long time to come.

With that said, the battle to getting the most out of LLMs for programming, or any reasoning heavy task, lies almost exclusively in the optimal curation of context, formatted clearly, and paired with a clear task prompt.

The Agent Orientation Problem​

Now, with the importance of context in mind, it's important to understand the different ways of serving problems to LLMs and getting them to make effective changes to your files or code.

Most folks working with AI models in 2025 have probably tried a coding agent, and if you haven't I encourage you do give Claude Code or Codex a download and experiment with what it can do for you.

Coding agents are in some ways miraculous, but they are also fundamentally limited. Understanding why is again related to understanding the importance of context.

When you prompt a coding agent, it must understand your problem, and the code that relates to that problem, from scratch, without any prior knowledge. You may try to accelerate codebase understanding with meticulous rule files, but each rule file you add eats into the available context window, which in turn affects the ability for the model to reason about your problem and the codebase itself.

Sending a prompt to a coding agent to change some code in a fresh context window involves what I've come to call "agent orientation". It's the phase where an agent will search through your code, invoking tools like grep to search for keywords based on what you prompted the model, to find the files related to your problem.

Once those files are found, agents will typically read small slivers of your files to get a cursory understanding of the code, and then start enacting change in them. Better coding agents will read more code before jumping to conclusions, but they will likely also read unrelated code and fill their context window with information that doesn't serve their ability to solve the problem. The more irrelevant context included, the closer we are to hitting that context limit wall that results in diminished intelligence.

All of this stands alongside the agent harness' system prompt, the tools it's provided, any MCP tools you've added (they each come with lengthy definitions), rule files, failed tool calls, and even successful ones, where the call params remain in the context window as the agent works.

By the time the agent understands your problem, it has very likely exceeded the sweet spot of effective context, and will begin trying to solve your problem with degraded intelligence.

The Reasoning Model Limitation​

When considering reasoning models, like GPT-5, the problem is even more nuanced.

The power of a reasoning model is that it can think for many minutes before answering. Since o3 came out, these models have started to be able to call tools from their chain of thought, to gather additional information while reasoning. However, in coding agents, they must use tools to handle file changes, and so unlike research tasks where the model can collect information and then answer after the chain of thought, they have to answer from within the chain of thought, and thus never get the chance to fully utilize their ability to reason.

When you combine this nuance, with the problems outlined above of reading incomplete slices of your codebase before jumping to conclusions, you start to see a pattern of compounding inefficiencies that affect the quality of a model's output, in the name of user convenience.

Reasoning models work best when they think and then act. RepoPrompt's Pro Edit workflow has tuned this by having models reason and then only after output a formatted response that contains all the edits. It turns out that this is also the best way to get a model like GPT-5 Pro to handle files edits. 5-Pro is a special case because, while it can call tools from it's chain of thought, it is not 1 instance of GPT-5, but many. That model does well with calling tools to gather informating, but if you rely on tools to apply edits, it's one of the many strands of GPT-5 handling the edits, rather than the consensus wisdom that comes from the final response.

It's worth noting that there are other flavors of reasoning models, like Claude's Anthropic models that do interleaved thinking, and tool calls. The above doesn't exactly apply to those models. If you're using Deepseek, Grok, Gemini or GPT models however, keep it in mind!

Planning and Discovery: A Better Approach​

Given the limitations of context windows, before making any changes to a codebase, especially above a certain threshold of complexity (could an intern do this in an afternoon with minimal guidance?), it is important to start planning your changes.

Planning can take many forms, but the most common are:

1. Clear outcome oriented specifications → What should the final product do after our changes?
2. Architectural specifications → How should the new code be structured, what parts of the codebase should be affected, and what should the new code do exactly?

Why PRDs Aren't Enough​

Many plan modes focus on the former. This is what you call a PRD (product requirements document). The problem with PRDs is that they leave all the implementation details up to ai model affecting change for you, and they don't solve the issue of agent orientation for each part of the task. You also have to carefully break up your PRD into clear, verifiable sub-tasks, or you'll just start compounding errors and may need to restart the whole process, as a single context window may not be able to fully contain all the changes required.

There's a process called compaction that often runs to alleviate some of this, but every time it runs, the model will lose many important details, including the contents of your files, and will need to rediscover important details, while working from lossy summarizations of the task and work done so far.

With all that said, the most important thing you can spend time preparing for your task is an architectural plan, so that an agent implementing the code required to complete your task encounters as little ambiguity as possible.

The RepoPrompt Workflow​

As of November 2025, here is how I go about this:

Step 1: Discovery with the Context Builder​

RepoPrompt ships with the context builder. It's a powerful agent orchestration engine that connects to either Claude Code or Codex, to take your task description, and then use RepoPrompt's MCP tools to research how your code works in relation to the task provided.

While reading around, it will pull out the most relevant files (and codemaps, which are concise api definitions to give ai models understanding of how to use a type without providing the implementation details). When a complete picture has been found, it will verify the token use of those files, and iterate on the selection to ensure that the final collection of files and codemaps fits within the allocated token budget.

This budget is 60k tokens by default—the upper limit of what you can paste into GPT-5 Pro on ChatGPT's Pro plan before hitting an error. If you find yourself using the built in chat, or other chat apps like ai studio, you are more than welcome to raise this limit. If pasting into an ai agent directly, you probably want to max out around 24-32k tokens.

One of the most powerful tools to help with token budget adherence is file slicing, which allows the context builder agent to pull out only the most relevant parts of a file, so that even massive files can fit within our allocated budget.

Finally, with a complete picture of the task and related files, the agent will leave a handoff prompt that clarifies your instructions with remaining open questions and ambiguities (that you can address directly), while also carefully explaining how the various discovered files relate to each other and to the task.

Importantly the prompt driving this agent takes great pains to ensure the agent running discover is not opinionated about the end solution. This is essential because it prevents the model from including too little context, and for biasing it's solution in the final prompt, which needs to be as factual as possible.

Step 2: Choose Your Implementation Path​

Once we've run discovery, we will have a resulting prompt that depending on the scope can be used to either directly affect change in your codebase, or can be the seed for a highly detailed architectural plan.

For Modest Changes: XML Pro Edit​

Typically, if the scope of edits (how many files we need to edit) is modest, the best way to handle the change from here is to simply use the XML Pro Edit copy preset or the Pro Edit mode in the built in chat.

Recall that reasoning models work best when they think and then act. With the XML Pro Edit workflow, you hand off your prompt along with all the discovered context and formatting instructions to a model like GPT-5 Thinking or Pro.

Because the model has the full file context up front, it can spend its entire reasoning budget thinking exclusively about the solution—not about what context it needs to gather. It reasons as long as it needs to, then returns the optimal set of minimal changes formatted as an XML response.

RepoPrompt then breaks up this response into per-file change lists that can be implemented in parallel by Claude Code or Codex in a sandbox for you to review before any changes hit your disk. I personally love this workflow for bug fixes, targetted fixes, and enhancing complicated algorithms.

For Large Changes: Architectural Planning​

If the problem is too large for a model to write all required code changes in a single response, you'll want to turn to drafting an architectural plan. Assuming the context builder agent did it's job right, the best way to do this is to set RepoPrompt over to the Plan preset, and then paste the resulting prompt into GPT-5 Pro.

Many coding agents ship with Plan modes at this point, but none of them ensure that the model drafting the plan has a bird's eye view of the complete task related codebase context, and so you will very often get plans that stem from incomplete information. A lot of information is often hidden within the interplay of classes that may not be immediately visible to a model reading only a few lines at a time. Furthermore, coding agent plans stem from a blend of the discovery and planning phases, which results in the model spending too much of it's context window on understanding the problem before being able to reason about a solution.

Using discovery and GPT-5 Pro to generate an architectural plan, is in my opinion the state of the art for complicated change planning. GPT-5 Pro has an incredible ability to break down your architecture, while being incredibly thorough, given it's ability to reason about the entire subset of the affected codebase at once. The one caveat to generating a plan this way is that it may still be too much for one agent to complete without needing to compact.

For Complex Multi-Step Changes: Pair Programming​

If it doesn't all fit in the context window, you can take additional steps to break the plan up, but what works even better is to use the RepoPrompt Pair Programming workflow, which integrates planning and implementation through the most complex of plans, while a driver agent directs the RepoPrompt chat through the implementation.

This keeps the heavy reasoning to the context optimized chat, while the agent driver's job is to break up the plan into achievable pieces, and validate the work done at every step. This workflow remains my preferred one for complex changes, and using it just involves setting the RepoPrompt preset to MCP Pair, before pasting the prompt into your agent of choice.

Unfortunately, the interplay of RepoPrompt and an external coding agent, remains too complicated for many. Rest assured, I am working on ways to make this an integrated workflow so you can benefit from all the best practices described in this article, in an end-to-end automated workflow.

Conclusion​

At the end of the day, once you have an architectural plan in hand, ideally from GPT-5 Pro, 90% of the work is done, assuming you did a good job of defining your task to the discovery model, and it did a good job of serving the right context to GPT-5 Pro. AI models are not perfect, but if you're looking for the best approach to get a high hit rate of well designed working code, this is what I've found works best.

As an engineer working with AI models, your job is to plan out what features make sense to work on, scope them correctly, and review the changes made, to keep a handle on the code being generated. Review each step of this process carefully and don't fully give into the end-to-end automation. Your input still matters a lot!

I hope this article gave you some insight into context windows, and an understanding of why agents and tool calling have their place, but should not always be used for every step of the pipeline. The right combination of one shot responses to maximize reasoning with the right context, alongside the careful act of assembling prompts for discovery, planning, and execution, can make a massive difference in the quality of the code an AI model can generate.