How my agentic coding workflow changed in three months

Three months is apparently enough time for an agentic coding workflow to become a period piece.

On 8 April, I published the workflow I used in OpenCode. By July, I had removed most of the machinery it described from Propulsion.

The original workflow was not a mistake. It gave less capable models the structure they needed to do useful work without charging enthusiastically in the wrong direction. It is still a powerful way to work when a task needs that much control.

The models changed. My workflow had to change with them.

The old workflow was not wrong

The previous version of Propulsion borrowed heavily from Jesse Vincent’s Superpowers. Every software request entered a mandatory pipeline. Feature work went through brainstorming, interrogation, a product requirements document, a detailed plan, phased implementation, and independent review.

That restriction was deliberate. Models were capable, but they needed their hands held. If I gave an agent room to improvise too early, it could make an unconfirmed product decision, bury it inside implementation detail, and produce something impressively complete that nobody had actually asked for.

The pipeline slowed that down. Each stage had an owner, an output, and a completion gate. The model could not quietly skip the awkward decisions and get on with the fun bit.

There is still value in that approach. I would use stronger orchestration for high-risk work, a less capable model, or a team that needs a durable specification and approval trail. The mistake would be turning a useful safety mechanism into a universal ritual.

By July, that ritual had started to feel disproportionate.

New models need less scaffolding

Anthropic released Claude Fable 5 in June. Its announcement talks about longer autonomous work, fewer turns, greater token efficiency, and even tasks that need less scaffolding than previous Claude models.

OpenAI followed with GPT-5.6 in July. OpenAI describes GPT-5.6 doing tool-heavy work with fewer tokens, fewer model round trips, and less guidance. That matches what I have seen in practice.

I now use GPT-5.6 Sol on high reasoning for most of my coding work. I do not need to prescribe every stage before it can inspect a codebase, reason about a trade-off, or decide which tool to use next. Gentle steering is usually enough.

That does not mean instructions stopped mattering. If anything, good context matters more because these models can act on it more effectively. The change is in how much process I need to spell out.

The old question was: how do I make the model obey the workflow?

The better question now is: what context does the model need for this piece of work?

Context is now the main constraint

Every instruction has a cost. It occupies context that could hold the requirement, source code, test output, browser state, or the decisions we make during the conversation.

The old Propulsion workflow loaded a central router and then moved through brainstorm, interrogate, plan, and execute. Those skills brought templates and subagent prompts with them. The new core path is elicit-with-context, followed by implement, which composes the smaller tdd and code-review skills when the work reaches them.

I wrote a small Python script using OpenAI’s tiktoken and its o200k_base encoding to compare both bundles. I counted every Markdown skill, reference, template, asset, and subagent prompt involved in each core path.

That is a 29.5% reduction in the bundled instruction footprint.

It is an illustrative comparison, not a bill. o200k_base is not a universal tokenizer, clients may cache prompts, and supporting references are not necessarily loaded at the same moment. It also says nothing about the tokens generated during the conversation.

Those conversation savings are real in my experience, but much harder to report honestly. No two feature discussions make the same decisions or inspect the same code. What I can say is that removing mandatory documents, hand-offs, and review loops produces less ceremony. That leaves more context for the work, can reduce usage-based cost, and gives me more time to code.

Propulsion stopped owning the whole process

The July rebuild turned Propulsion into a set of independently invocable skills. There is no central skill waiting to intercept every software request. There is no plugin hook forcing the agent through the complete workflow.

For a feature, I normally begin with:

$elicit-with-context Help me work through an idea for <desired outcome>.

Once the request is understood and confirmed, I use:

$implement the request we just confirmed.

That is the recommended path, not a locked door. A clear, low-risk change can start closer to implementation. A bug can go straight to $debug. Architecture work can start with $review-architecture. Research, commits, and pull requests have their own skills.

The important change is ownership. Propulsion no longer decides that every request needs the same process. I decide which skill helps with the problem in front of me, and the model handles the detail inside that boundary.

Human review matters more in this version, not less. The agent can implement and inspect its work, but I still review the working tree before I ask it to commit. Less orchestration is not the same as less judgement.

Short skills work because the model knows the method

The biggest change is not shorter prose for its own sake. It is how the skills use the knowledge already inside the model.

The old skills often explained the behaviour I wanted in detail. The new ones start with a recognised method, principle, or theory, then add only the instructions needed to adapt it to Propulsion.

For example:

• $elicit uses Axel van Lamsweerde’s goal-oriented requirements engineering to refine a request into confirmed decisions.
• $maintain-context applies Eric Evans’s Ubiquitous Language to keep project terminology precise.
• $tdd uses classicist TDD and Kent Beck’s Test Desiderata to choose valuable tests without coupling them to implementation structure.
• $modular-design starts from David Parnas’s information-hiding principle instead of inventing another architecture checklist.

I do not need to teach a frontier model what information hiding means. Naming it precisely nudges the model towards a body of established knowledge. The rest of the skill can concentrate on when to apply it, how it fits this workflow, and what observable result it should produce.

This is the useful trick: replace explanation with a precise leading term when the model already knows the concept. Keep the words that customise behaviour. Remove the ones that merely repeat the textbook.

What Propulsion borrowed from Matt Pocock

Propulsion has moved further away from Superpowers and closer to Matt Pocock’s skills. Matt describes his skills as small, adaptable, and composable. He explicitly encourages developers to make them their own rather than hand control to a framework that owns the process.

At the time of writing, that repository has more than 177,000 GitHub stars. Stars do not prove that a workflow produces good code. They do show that a lot of developers are interested in this lighter, skills-led approach.

Propulsion is heavily based on Matt’s work, but it is not a straight copy. My skills retain a little more structure and steering. They also put more emphasis on established methodologies, original publications, and named engineering principles.

That balance works for me. It may not work for you.

The tools I use now

I still use OpenCode Desktop. Its model choice and straightforward coding workflow remain useful, especially when I want to move between providers without rebuilding my setup.

I also use the new ChatGPT desktop app. The built-in browser has become one of its most useful tools for me. The agent and I can inspect the same page, work across tabs, review local development routes, and use visual annotations while changing a site.

I have not found an equivalent browser workflow in OpenCode at the time of writing. That does not make OpenCode worse at everything. It means I now choose between the two tools based on the task instead of expecting one agent to own my whole development environment.

The same principle applies to skills. Pick the smallest useful tool for the work in front of you.

Build the workflow around your own weaknesses

I still believe the best agentic coding workflow is a personal one. The difference is that it can now be much lighter.

Do not copy Propulsion line for line because it works for me. Watch your own sessions. Notice where the model drifts, which corrections you repeat, where you rush decisions, and which failures cost you time. Then find the established method that addresses that problem and turn the necessary adaptation into a small skill.

Invoke it when it helps. Leave it out when it does not.

Stronger models have not removed the need for judgement, context, or process. They have made it possible to use each one more deliberately. That means fewer tokens spent explaining how to work, less ceremony around the work itself, and more time doing the useful bit.