Large Language Models (LLMs) have considerably augmented our software/game development workflows, and as the frontier models improve, they only do more for us. Yet still, prompting is both an art and a science we need to master to get the most out of them. Simple changes in our code bases require little thought. How about complex systems or major refactors? Even capable models and the best developer tools can leave us wanting.

It never hurts to take some pages out of the tried and tested engineering playbook: plan first, build second. In practice, this means using a smarter, often more expensive, model as an "architect" that writes a plan in a Markdown file and then feeding that file to an often cheaper "builder" model to implement it. The result? More accurate changes that saves time for both the developer and the model. Let's get into it, starting with the plan.

Crafting the Right Plan

When planning, you want to use a reasoning model. Think Claude 4 Opus, Open AI o3/o4-mini, Gemini 2.5, or DeepSeek R1 if you prefer open source. Let's say I'm migrating from Unity's legacy input system to their new one in a game. We can start our plan with some research on the topic:

You're an expert Unity developer that's helping me plan a migration from the old input system, to the new one. What does that entail? What are best practices?

You would likely get useful information like installing the necessary package, configuring your settings and creating new scripts and resources.

If you're using tools like Coplay, Windsurf or Cline, you have a huge advantage - they're embedded in the project! They have access to the relevant context to create a specific plan for your code.

You can ask your AI copilot to flag all scripts that use the old input system:

What scripts currently use the legacy input system? What GameObjects are they attached to?

The right tool can search your project and compile all the objects that will be affected by this change. AI copilots also allow you to manually add context by highlighting files and folders of interest, so you can catch anything that the LLM may have missed out on.

Note: What if you don't use those tools? Start using them! They'll save time. You can manually share context with an LLMs to make them more effective (think copy and pasting files into ChatGPT), but it can be very time consuming for large projects.

Once you have a discussion with the model that covers the relevant details, explicitly prompt the model for a plan:

Based on our conversations, write a product requirements document and execution plan in an Input-Migration.md file.

Answer if you're at least 95% confident. Ask any clarifying questions before you write and I'll do my best to help.

The last sentence is a neat trick we learned - your answers can remove ambiguity and help the model craft the exact UX you desire.

We use Markdown because it's easy for models to create and read. It's also easy for us to read! Be sure to review what the model intends to do, making any changes as necessary.

Time To Execute

With our markdown crafted, let's open a new chat. Why? The context window. While some models have large context windows allowing them to process a lot of data, LLMs are generally less performant on long input sequences.

From there, you simply need to prompt the model to read the Markdown file we just created:

Read Input-Migration.md and systematically execute the plan it contains.

That's it! With the details document you created, feel free to use a non-reasoning model for this step, like Claude 3.7 or GPT-4.1. They're cheaper to use, but with our well detailed plan, they have the right information to do the right things.

The Grass Is Greener, But Not All Green

While beneficial, this strategy is time consuming. The bulk of work is loaded into defining the problem and architecting the solution. You won't see meaningful progress until the design phase is complete, and your agent is building. If you're someone who prefers to see more immediate feedback, this won't work for you. This also isn't necessary for small scale changes.

Furthermore, planning is best done with the smartest reasoning models. At the time of writing, Claude 4 Opus and OpenAI's o3 are exceptional at this activity. However, these capable models can be costly:

Lastly, this exercise doesn't guarantee perfection. It's important to set realistic expectations when working with AI tools. Getting 90-95% there isn't total success, but it's an exceptional head start.

Keep in mind that this strategy isn't about small tasks, or costs savings. It's about getting LLMs to tackle huge refactors and complicated features. Getting them to do exactly what you want across multiple files, folders and systems. In those situations, this approach's benefits far outweigh the costs!

Conclusion

The best developers we've worked with had the ability to do two things: think deeply and execute narrowly. By thinking deeply, we mean they critically analyzed a problem, understood the core issue and how it impacts others, and used those reflections to craft a solution. By executing narrowly, we mean they kept changes within scope, used their specialized knowledge of the project, infrastructure and organization to bring the feature to users in the most sensible way possible.

With an LLM as a collaborator, it's easier for you to think deeply about a topic and scope the necessary changes for maximum effectiveness. With the hard work done, you can then get the LLM to execute the plan with high precision. Take it for a spin on your next monster PR! And if you're interested in seeing how well this works in Unity, try the plan and execute strategy with Coplay.