Overview

In my previous post on using AI to write software, I was of the opinion that we should manually write interfaces and allow an agent to fill in the details. This would give the programmer more control over how an application gets structured instead of letting the agent run wild.

My opinion has now changed over the last 3 months. I've stopped writing code by hand completely. Instead I write a few lines (maybe) of example code and give a quick skim over the generated code. I'll explain the techniques I'm using that make this work.

In this post we will be creating a compiled desktop application in the form of a... calculator! It needs to fit in a long blog post, so it's intentionally small and will only have basic features. Nothing too fancy.

I'll be interleaving my thoughts, explanatory things, and snippets from the interactive session with the agent. The snippets will use colored blocks so you can easily identify messages coming and going.

Mission: Impossible

The first thing we need is a plan. And not just any plan, but one that accurately captures what we actually want. Let's try a naive prompt first:

My current LLM of choice responded with this (and a complete opinionated plan on everything else too):

Yeah, no. A web browser is a big dependency so we are already in hallucination land. Anyway, I know that I want a compiled desktop application, not a web app. We could start the plan by saying "use Rust", but that doesn't generalize very well. The agent will still make all the other choices, and it might even end up with a web app using something like Tauri.

Continuing the session:

So this sort-of works. However, the wall of text contains a bunch of assumptions and things that I either don't want or didn't get to choose. We need to play whack-a-mole in order to eventually get to a point where the plan seems reasonable.

Mission: Possible

Instead of spamming the agent going back-and-forth trying to nail down all the things that we want, let's instead tell it to ask us questions about it in a new session:

For the most part, models are trained on basically the entire internet and every book ever written (more or less), so it should be able to figure out what needs to be clarified before implementing. Here is the response:

Now this is something we can work with! It asks questions about the design and we can choose from some options, or add our own options, or ignore some. This will help us get closer to what we want, and as a bonus we might think of something while reviewing the options.

The model responded pretty comprehensively. I've omitted a lot of details here to keep it short:

  calculator/
  ├── Cargo.toml
  ├── src/
  │   ├── main.rs          # App entry, window setup
  │   ├── app.rs           # eframe App trait impl (UI)
  │   ├── engine.rs        # Calculator logic (pure, no UI)
  │   └── error.rs         # Error types (divide-by-zero, overflow)
  └── tests/
      └── engine_tests.rs   # Unit tests for calculator logic

The great thing about the "Ask clarifying questions" trick is that the model is more likely to continue asking questions, as we can see at the end of this response.

Planception

The proposed plan is a high-level plan. It covers the goal of the app and it's overall structure. Depending on complexity, it may also have a flowchart showing how data flows through the application. However, this is not enough to proceed with implementation.

What we should do next is:

1. Write this plan so we have it for later
2. Create a "detailed plan"

We may have multiple "detailed" plans, so we keep this high-level plan around to load into the context of each session. That way the agent can see the overall design along with the detailed section that it's been assigned.

The plan has 4 milestones and we need to split it up into multiple individual implementation phases. Usually the milestones/phases are already split appropriately by the model, but since this app is so small I think we can combine milestone 1 & 2.

The "detailed plan" needs to be created as you go for each phase. You cannot pre-generate all the detailed plans up-front, and you cannot tell an agent autonomously generate the detailed plans either. This is for two reasons:

1. The implementation of one phase can have unforeseen effects on later phases depending on the implementation.
2. The detailed plan itself might have issues that we want to address.

Here is how to generate a detailed plan:

The "detailed" plan should contain some code samples. Depending on model and harness combination, you may get some snippets with "// TODO", or you may get full implementations of large chunks of code. If you don't get any code in the detailed plan, then also add to the prompt:

Include code snippets in the detailed implementation.

Here are my thoughts for why I think each part is needed in the detailed plan:

Reasoning

Agents will sometimes pick an easy implementation over a complex one. Like when using a trait for something trivial that could be a free function, the agent will occasionally just remove the trait because it's "over-engineered" (That's from the reasoning trace).

Acceptance criteria

This gives the agent something it can check to ensure that the implementation is what we expected. It might write tests or just evaluate what it wrote. If you have very specific acceptance criteria you want to include, then list it as part of the plan generation request. If it's incompatible with the original plan, then we'll find it out soon.

Code snippets

We are going to have the model review the plan, so it needs some code snippets to work with.

After a short time:

So even on a calculator at phase 1 we have some issues that need to be addressed. This is why I mentioned previously that we need to perform this step manually instead of letting the agent run free all day. These issues will start as "no big deal" and eventually compound as more accumulate in each phase. Resolving them here prevents the debt accumulation from occurring at all.

In this case I'm fine with what the agent recommended. But many times there will be issues where you actually do need to make a critical decision.

Context Control

While the agent does it's thing, we need to talk about context lengths. Your agent harness may have decided to spawn a subagent for the implementation, or maybe you handed off the context to another session, or maybe it's running in the same session. Regardless, you'll eventually run into issues with context length.

Luckily for us, the plan is already split up into milestones or implementation phases. We will use those as checkpoints for clearing out the context.

Since we combined phase 1 and 2, we'll just move on to the next phase immediately:

Now that phase 1 and 2 are done, we can create a checkpoint that details the current implementation status:

That was easy enough.

Next we need to start phase 3. We will again create a detailed plan, have it reviewed, and then begin implementation. You should create a new empty session for this or, perform a handoff:

We don't need to include the extra instructions like the "reasoning" and "acceptance criteria" as before because the agent will be able to figure that out based on whats already in current-progress.md file and the other detailed plan files.

Proper planning can take up a lot of context. So if you are running low (35%+ context utilization) after finalizing the detailed plan, you can launch a new session and have the agent load the plan files. This project is small so we'll continue in the same session:

The Grind

We need to repeat the process for each phase of the plan until the feature/project is implemented. To recap, the steps are:

0. Start with a high-level plan
1. Generate detailed plan (maybe in new session, depending on context availability)
2. Review detailed plan
3. Implement detailed plan (in new session, usually)
4. Update progress file (checkpoint)
5. GOTO (1)

Agents will sometimes automatically update the progress file after completing implementation. But if it fails to do so, just remind it to update the progress file after it's done with a phase.

Pro Tips

Here are a few things that can help with this workflow.

Test-Driven-Development and Behavior-Driven-Development

We can help agents work more effectively by using concepts from TDD and BDD.

Specifically, if we include guidelines in an AGENTS.md file to structure tests in a TDD/BDD way, then the agent will have more context on how the project works and should be able to more effectively implement features. This is because the tests will act as regression tests as the agent makes changes. If the agent breaks something, it will read the failing test, see the name and code that gets ran, and be better equipped with knowledge of the codebase for that specific thing it's touching.

Here is a sample of what you could include in your AGENTS.md:

BDD-Style Tests (Given/When/Then)

Structure tests with clear Given/When/Then comments. Each section should contain actual code.

// DO NOT — no BDD structure, inputs not separated from assertion
fn preview_resolution_full_res() {
    let mut config = AppConfig::default();
    config.preview_divisor = 1;
    let res = config.preview_resolution([1920, 1080]);
    assert_eq!(res, (1920, 1080));
}

// DO — tests meaningful behavior with proper BDD structure
fn preview_resolution_correctly_calculates_with_divisor_of_one() {
    // Given a configuration having a preview_divisor of 1.
    let mut config = AppConfig::default();
    config.preview_divisor = 1;

    // When we calculate the preview resolution.
    let res = config.preview_resolution([1920, 1080]);

    // Then the resolution is the same.
    assert_eq!(res, (1920, 1080));
}

Debtmap

You can use the Debtmap tool to analyze your code. This can help identify locations with high technical debt and then you can have an agent fix it. The tool comes with a "LLM Copy" shortcut that allows you to copy an issue directly to Markdown so an agent can address the problem.

Clippy

We can't forget our good pal Clippy. Since agents write the code now, pedantic should be the only lint level you use. It can be configured in Cargo.toml at the workspace or crate level. Don't forget to allow lints that are being too annoying for your project:

# in a workspace
[workspace.lints.clippy]
pedantic = { level = "warn", priority = -1 }
wildcard_imports = "allow"
# include whatever other lint config you want

# for single crate
[workspace.lints.clippy]
pedantic = { level = "warn", priority = -1 }
wildcard_imports = "allow"

The Calculator

Let's see what it looks like:

I confirmed that it does indeed calculate.

Conclusion

This post showed a method of working with coding agents in a way that allows you to more easily specify requirements for your applications. This is done through having the agent ask clarifying questions. Additionally, detailed plan files are created and reviewed by an agent to find potential problems.