How I Actually Build Software With AI

I usually have two chats open when I work on a serious software project. One helps me decide what should happen, the other carries out the work, and the results come back before I decide what happens next.

One Project, Two Different Jobs

For each project, I keep a standard ChatGPT conversation as the command center. In that command chat, I work through analysis, planning, troubleshooting, product decisions, architecture, prompt preparation, and the questions that do not have clean answers yet. I normally use Very High reasoning there because I want room to examine the problem before committing to an approach.

Then I have a separate Work chat for execution. That is where I direct the repository work, file changes, browser testing, terminal operations, and verification needed to carry a defined job through. I use Astra there and choose the thinking effort for the particular execution.

The distinction is not that one chat thinks, and the other blindly follows orders. Work still has to investigate, reason, and respond to what it finds. The separation is about responsibility. The command chat holds the broader direction. The Work chat gets a specific assignment inside that direction.

In Why I Build This Way, I wrote about the judgment and responsibility behind my AI-assisted development. This is the practical system underneath it: how I organize the work so the next conversation does not quietly turn it into a different project.

I did not sit down one morning and invent a development methodology. This grew out of working on real things, finding problems, correcting them, and getting tired of correcting the same assumptions repeatedly.

The Product Decision Comes Before the Prompt

Before I send anything into Work, I need to know what problem I am actually trying to solve. That sounds obvious until a useful idea starts collecting features simply because the tools make them possible.

Bonumark Stream exists because I wanted short-form publishing on a site I control. I use it for my own stream. That gives me concrete things to judge: writing a post, attaching photos, correcting something, finding an older entry, or seeing whether the interface behaves properly with my actual content.

Only Empowerment has a different purpose. I am building it because my writing and philosophies need a place where people can apply them. Reading about a standard is one thing. Working through a tool that helps you define your own standard or decide your next action is another. Revenue may come later, but it is not the reason I am building it now.

Those purposes change what I choose to build. A feature can be technically impressive and still take the product in the wrong direction. I need to know why it belongs before sending it into Work.

For Bonumark, that includes deciding whether a problem belongs in the application or the theme. A disagreement between two public interaction counts is not something I want hidden with styling. The application needs a consistent answer. The theme should present that answer, not manufacture its own.

This is where I question recommendations, narrow scope, reject additions, and decide what can wait. Sometimes the most useful thing the command chat produces is a clearer instruction not to build something.

The Rules Have to Survive the Conversation

A long conversation can contain a lot of useful history. I still do not want a project depending on someone remembering the right paragraph from several weeks ago.

I keep durable project rules in source documents. Bonumark has architecture, product, release, and versioning rules. My server work has standards for permissions, backups, certificates, and remote access. An Astra effort standard keeps model recommendations consistent.

These documents carry decisions that should not be reopened casually. Bonumark’s database is its runtime source of truth. Application behavior belongs in core. Themes are presentation packages. An upgrade must preserve the owner’s content, settings, media, and custom themes. A versioned package is not automatically a public release.

I keep current project state separate from those durable rules. A rule says how the work must be handled. A checkpoint says where the work actually stands: the branch, the exact source revision, the phase, the tests, the blockers, and what remains unapproved.

Neither document gets to overrule reality. My execution instructions require checking the newest source and the actual environment. An old report is useful history, but it does not prove which files are sitting on a server today. A checkpoint is a place to resume verification, not permission to skip it.

I do not need every conversation pasted into every prompt. I need the relevant rules, a reliable starting point, and enough evidence to understand the next job.

The Handoff Defines the Job

Once the direction is clear, I use the command chat to prepare a kickoff or continuation prompt for Work. The point is to define a job I can evaluate, not find a magical sentence that produces perfect software.

My useful handoffs answer five questions:

Where are we starting? The authoritative source, branch, checkpoint, and environment to inspect.
What should change? The specific problem or milestone this execution owns.
What must remain untouched? Product boundaries, unrelated systems, owner data, and deployment restrictions.
What will count as evidence? The checks, tests, and observed behavior needed to support completion.
What comes back? The changed source or package, verification results, unresolved problems, and updated project state.

A recent Proof theme pass for JimLunsford.com had exactly that kind of boundary. The job was to clean up repeated editorial markup, make an explanatory section appropriate to the content type, and remove unnecessary repeated material from paginated archives. It was not permission to redesign the theme, change WordPress content, or deploy to the live site.

Those exclusions mattered as much as the requested changes. I wanted an installable theme package that preserved the design, not a surprise reconstruction of the site.

Legend of the Green Dragon: Resurrection, my modernization of an old browser role-playing game, needs a different handoff. During its Phase 3 work, my continuation instructions have repeatedly required the existing modernization branch and pull request, preserved historical repositories, and no deployment or move into Phase 4. A successful narrow fix does not erase those boundaries.

I want Work to have enough room to solve the assigned problem without asking me to approve every routine step. I do not want it guessing whether a successful test authorizes a release.

For server work, the boundary also has to exist outside the prompt. My operating rules call for site isolation, limited permissions, backups, and verification. Telling an agent to be careful is not a replacement for controlling what it can reach or preserving a way to recover. Direct access makes the work easier, but I still need to know which machine it is connected to and what it is authorized to change.

Inspection Can Change the Plan

A good prompt still has to survive contact with the actual project. One of the clearest examples came while preparing Bonumark’s development site for the next build.

I wanted the environment current, populated, and useful for testing. I had authorized wiping and reseeding the development database if the existing data was useless. But inspection found useful content and federation history, so the work preserved the installation and expanded it instead.

That was the better decision. Disposable test posts and the identity of a federated installation are not the same thing. The existing actor identity, signing key, relationships, configuration, and migration state did not need to be destroyed to get better test data.

The development installation was also compared with the repository. That meant the next failure would not start with guessing which copy of the application was on the server.

Then the site was populated with content that could expose problems: short and long posts, unusual characters, long links, different image shapes, galleries, drafts, scheduling, revisions, comments, Likes, and a completed Profile. The resulting set included 44 published posts and enough content to exercise pagination.

That preparation was not busywork before the real development. It gave later development something concrete to work against.

Passing Tests Have to Mean Something

The populated Bonumark environment found problems that would have been easy to miss on an empty site. One test post had an approved remote reply. The Conversation displayed one comment while the permalink action control displayed zero.

That gave me a reproducible case to bring back to the command chat and a requirement to fix the counting behavior in core.

An emoji-rich post also failed during metadata generation, and the publishing failure could lose the author’s entered text. The readiness pass had not established the exact database cause. It had established the content loss, which needed its own requirement.

I want those distinctions preserved. Finding a defect is not fixing it. Observing a failure is not proving its cause. A useful report says which part is known and which part still needs investigation.

In Resurrection, new specialty tests passed while the broader HTTP suite failed on an existing Transmutation case. That older path expected HTTP 400 and received HTTP 409 after shared validation behavior changed.

The correction restored the older response boundary without weakening the new specialty validation or rewriting the old test just to make the suite green. The supported matrix was then run again. The broader suite caught a regression outside the new feature.

I also need verification that does not depend only on automated tests. Screenshots, browser behavior, actual publishing, upgrade checks, and restore tests answer different questions. A passing syntax check is useful, but it does not tell me whether a writer loses a post when publishing fails.

Tests that cannot be performed stay visible. The Bonumark readiness report left exact phone-viewport acceptance and a full database-import restore test unclaimed. There was no reason to pretend they had passed.

Results Come Back Before the Next Job Goes Out

When Work finishes a pass, I bring the result back into the command chat. That is where we compare the report with the original assignment and ask what the evidence actually supports.

I want to know what changed, what was tested, what failed, what was corrected, what remains blocked, and whether anything crossed the scope boundary. Did the work prove what the summary claims?

In Resurrection, a module passing installation and lifecycle checks did not qualify it as fully certified. A specialty being selected safely did not prove its combat behavior. Those are different claims, and keeping them separate shaped the next execution instead of letting a green result end the discussion.

The command chat is not an independent security audit simply because it is a different conversation. I am still using AI to examine AI-assisted work. Agreement between the chats is not enough. The review needs the actual source, test output, screenshots, or other evidence relevant to the decision, and important claims may need further checks.

Once the result is accepted for what it proves, the checkpoint gets updated. That gives the next execution a source revision and a clear account of what remains. It also prevents completed implementation from being casually retold as a completed release.

Then I decide what goes out next. Sometimes that means another substantial pass. Sometimes it means investigating one failure before touching anything else. Sometimes it means leaving a pull request in draft because the work is better, but the release conditions still have not been met.

The loop is straightforward: analyze, decide, specify, execute, test, review, update the state, and repeat.

Astra Stays. Effort Changes.

Right now, I am sticking with Astra in Work because of the progress I have seen on my projects. I am not switching models just to stretch the allowance.

That is my experience with my workload, not a benchmark or a claim that everyone needs my settings.

What I am adjusting is thinking effort. My command chat is normally where I use Very High reasoning for the broad analysis and decisions. Work gets the effort appropriate to the assignment, which is not necessarily the highest setting just because the project matters to me.

In my Work standard, Low is for narrow mechanical follow-through. Medium is the normal starting point for well-bounded implementation. High is for difficult investigations, security boundaries, and decisions involving several interacting systems. Very High is an escalation for especially difficult reasoning, not a badge I attach to every important milestone.

The useful distinction is between the importance of the project and the uncertainty of the task. Changing known metadata and investigating a combat-state bug may belong to the same repository. They do not ask the model to solve the same kind of problem.

I also do not assume every bad result needs more reasoning. Missing source files, stale instructions, unavailable access, and a broken test environment are problems to identify and fix. Raising the effort setting does not answer them.

I am still learning the right balance. I want the available usage spent on verified progress, not saved so aggressively that I buy myself another round of corrections. I also do not want a difficult investigation keeping every routine follow-up at High out of habit.

The Workflow Has to Survive My Impatience

I can be the biggest source of scope creep in this system. I like building things. Once a project gets moving, there is usually another useful thing I can see immediately.

That is how a defined pass can turn into several jobs with no deliberate stop between them. Writing a boundary into a prompt helps, but I still have to respect it when the result arrives.

Running out of Work usage made that constraint hard to ignore. I had Bonumark and Only Empowerment prompts ready and could not run the heavy executions I wanted. I joked about making a cardboard sign that said I would work for credits. I was only partly joking.

The time was not empty, though. We fixed theme issues on JimLunsford.com, examined search and analytics data, and worked on a Windows launcher. The command chat was still doing meaningful analysis and smaller technical work. It had never been just a waiting room for Work.

The lesson was not that every available minute needs another assignment. It was that I needed to be more deliberate about which jobs actually deserved the heavy execution capacity.

Start With a Job You Can Actually Judge

Someone learning from this does not need copies of every document I have created. The useful starting point is a project small enough to understand, a planning space, an execution space, and a clear way to judge the result.

Describe one real problem. Decide what must stay unchanged. Give the execution the source and access it needs. Define what evidence would show that the change worked. Then review what happened before handing it another job.

As the work grows, write down the decisions that keep coming back. Preserve a checkpoint when losing the current state would create confusion. Add tests around failures worth preventing. Build the supporting structure because the project needs it, not because an elaborate workflow looks impressive.

This still requires technical understanding. I need to recognize when a proposed fix changes the wrong layer, when a deployment could affect real data, and when the evidence is too narrow for the claim. When I do not understand a consequence, that is a reason to investigate before approving it, not a reason to let a confident summary decide for me.

I am not trying to eliminate the messy parts of building software. The Bonumark findings and Resurrection regression are exactly the kinds of things this process needs to handle. The work gets stronger when a failure becomes a clearer requirement, a corrected implementation, and evidence the next pass can use.

Two chats alone do not make that happen. The useful part is what moves between them: a defined job going out and a result I can examine coming back. That is how I keep building without giving the whole project over to whatever the last response happened to recommend.

New Here?

Start Here: Why I Build This Way