For the past several years, I’ve generally approached a new, more capable model the same way: give it more of the work. More context, more responsibility, a bigger task, and another set of instructions about how I expect it to operate.
That habit followed me into GPT-6 Astra. I wanted it to understand the project, plan the changes, write the code, fix the tests, review the result, and work through the backlog. I also expected it to preserve everything that was already working and follow the operating procedures I’ve accumulated along the way.
Meanwhile, I kept seeing people one-shotting things. I got hung up on that. I wanted the large prompt and the impressive result, even though most of my work involves existing projects with existing decisions, unfinished integrations, and users who care whether the thing still works tomorrow.
To those of you who follow me and have listened to me groaning since Astra came out, I owe you an apology. I was still stuck in “Man make fire” mode: give a more powerful model a bigger prompt and expect everything to work better. I feel a little dumb that it took me this long to reconsider the assignment.
Asking Eisenhower to storm the beach
It’s like asking Eisenhower to storm the beaches of Normandy himself. His strength was in planning the operation, coordinating the forces, and putting the right people in position to carry it out. Having him personally lead the charge would take him away from the work where he could contribute the most.
That’s how I’d been assigning work to Astra. I had the general down in the foxhole doing every individual task while also expecting it to keep the whole operation in its head. I should have been giving it responsibility for the plan, the assignments, and the follow-through.
In Codex, I’m now using Astra to understand the project, establish the plan, divide the work, and review what comes back. I’ve used Astra up to Extra High reasoning for this. It delegates implementation to GPT-5.6 Sol, generally at Medium reasoning, in batches of three to five independent tasks.
That division is working better for me. It gives Astra a place to maintain the larger picture while each implementation task has a smaller, clearer job.
For a backlog with several independent pieces, I’m getting useful work back faster. I still handle small changes in one task when delegation would create more coordination work than it saves.
Start with the project as it exists
The planning step has become much more concrete.
I give Astra the repository instructions, the architecture documentation, and the issue backlog. I ask it to inspect the code and identify what is implemented, what partially exists, and what has only been described in a document.
That last distinction comes up constantly. A module can exist without anything calling it. A database table can exist without a usable feature. A passing fixture can tell you something useful without proving that a real user can complete the workflow.
I also want the plan to account for the progress we’ve already made. If we’ve spent days getting the interface right, the next task should preserve that work. A reference product or a fresh design document is not permission to start redesigning the app.
Before delegation, I want to know which tasks can proceed independently and which ones share a dependency. Three agents changing the same database migration or API contract would give me three competing answers to reconcile.
Here is a planning prompt I would use:
Read the repository instructions, architecture documents, and live
issue backlog. Inspect the actual implementation and affected callers.
Do not assume an issue title or an existing module proves behavior.
Map the remaining work in dependency order. Identify three to five
independent assignments. For each, define:
- The user-visible or operational outcome.
- The scope and the files or interfaces it owns.
- The existing decisions and guardrails that apply.
- The checks and evidence required for completion.
- Any dependency or product decision that prevents it from starting.
Preserve the current UI and unrelated work. Use existing issues where
they cover the work. Ask about consequential product choices, and
continue independent work while those questions are open.
I’m asking Astra to do the reading and coordination that make the smaller assignments useful. I don’t want to break one vague request into five vague requests.
Put the rules into each assignment
I’ve spent a lot of time writing guardrails and standard operating procedures. Some came from ordinary preferences. Others came from watching a tool make a change I absolutely did not ask for.
Those rules include preserving unrelated changes, reading the architecture before changing it, using the existing design system, running the right local checks, and keeping product decisions with me. They also define when a change can be merged and what must remain a draft.
With the delegated approach, Astra translates those rules into a handoff that applies to the particular job.
For a terminology change, the task might be allowed to update visible text, accessibility labels, and current user documentation. It still needs to preserve layout, navigation, API routes, stored fields, and internal identifiers that carry compatibility requirements.
For a database diagnostic, the assignment might explicitly forbid creating a missing database, running migrations against retained data, or changing a recorded checksum. The completion check needs to prove that the inspected data was preserved.
For an old integration branch, the task might be to extract the remaining useful code onto current main. That does not authorize replaying old interface changes or restoring behavior that has already been replaced.
That example batch gives each task a distinct scope and its own pull request, which makes the work easier to review.
The delegation prompt looks something like this:
Delegate the ready implementation assignments to GPT-5.6 Sol using
Medium reasoning. Start three tasks and expand to five only when
the additional work is independent.
Give each task the relevant documents and code references, a clear
scope, the applicable repository instructions, and an isolated branch.
Coordinate shared files, migrations, and interface changes before
allowing those assignments to run concurrently.
Each task must inspect its affected flow, implement the smallest
complete change, run the relevant local checks, and open a focused PR.
UI changes require rendered inspection as well as automated tests.
The PR must state what changed, what was verified, and what remains
unverified. In this repo, do not enable or trigger GitHub CI.
Preserve unrelated work. If the requested model or required capability
is unavailable, report that rather than silently substituting.
I’m using local checks in that example because that is how my repositories are configured. The point is to carry your actual rules into the assignment, including the ones that differ from a generic development workflow.
Astra still has to follow those rules. Delegation adds responsibility for checking the handoff and the returned work.
Finish the pull request workflow
I had to correct another part of the process after the first assignments came back.
The delegated work had produced pull requests, but they were sitting open after I had authorized merging verified changes. I had to make the follow-through explicit.
From my side, that meant the app preview still showed the old behavior. Work had been done, but the workflow had stopped before I could review the updated app.
I want Astra to read the actual diff, check the verification evidence, resolve findings, and run any missing checks. When the change is ready and merging is authorized, it should complete the merge, verify that it landed, and make sure the preview reflects it.
While that happens, the next independent assignments can begin. Work that depends on the pending change needs to wait for the contract or the merge it actually requires.
I also want Astra to preserve the exceptions. If I asked for a draft, keep it a draft. If a product decision is still mine to make, don’t bury it in an implementation detail. If a test needs a physical device or a real external action, say what is missing instead of treating a mock result as acceptance.
Add a check-in that does useful work
In Codex, I can also have Astra schedule short follow-ups to keep the delegated work moving through the backlog. Its description was: “A quiet 15-minute coordination check will keep reviews, merges, and subsequent work moving.”
That check can look for completed tasks awaiting review, tasks blocked by a shared dependency, and idle tasks that can take the next issue. It can also reconcile what the issue tracker says with what was actually merged.
The schedule needs an end condition. Otherwise, I’ve created a process that keeps telling me it exists.
This is how I would make the review and continuation behavior explicit:
Review completed assignments against their original scope and the
actual code diff. Check their test evidence and inspect rendered UI
changes. Fix findings and run any missing checks before merging.
Merging ordinary verified PRs is already authorized. Complete that
workflow, verify the merge, and update the preview. Honor explicit
draft-only, product-decision, and external-action approval boundaries.
Start the next dependency-ready assignments while other completed
work is under review. Update the existing issue tracker with evidence.
Create a scheduled check-in every 15 minutes and verify it is active.
At each check, inspect completed, blocked, and idle tasks. Review
ready work and assign the next authorized issue where possible.
Notify me about meaningful completion, failures, or a decision I need
to make. Stay quiet when nothing changed. Stop the schedule when
the scoped backlog is complete or only items requiring my input
remain. List those remaining items without calling them complete.
This is also why a report that says “done” is not enough for me. I want to know whether that means implemented locally, tested, opened as a pull request, merged, or available in the version I’m using.
What I can say about the speed
The improvement is visible in how much work can move at once. Instead of waiting for one conversation to finish each part of the job in sequence, I can have three to five independent tasks producing changes while Astra maintains the plan and handles review.
I haven’t timed a controlled comparison. Three to five concurrent tasks tells you how I’m running the work; it doesn’t establish an equivalent reduction in elapsed time. A shared dependency can stop several tasks, and reviewing poorly scoped changes can consume whatever time parallel execution saved.
That makes the quality of the assignments part of the result. I want clear ownership, useful evidence, and a manageable batch. I can increase concurrency when those pieces are working.
I still make the product calls. I still decide what needs approval. I still want to use the app and see whether the result makes sense. What I’m changing is how much of the planning, assignment, review, and follow-up Astra handles for me.
This is a fresh lesson, and I expect I’ll have more of them. As the models get better, I need to question all my assumptions about how to use them. We’re entering uncharted territory. I want to leave room to think freely and try a different approach when the familiar one keeps getting in the way.
For your next backlog, try three well-defined assignments with a clear completion check for each. Have Astra coordinate them, have Sol implement them, and include review and integration in the original request. Judge the approach by the usable work that reaches you and how often you had to step in to keep it moving.
Start small, think big.