The most interesting thing I have built with AI in the last few weeks is not a single project.
It is the way several small projects started helping each other.
I have been working on SWE Forge, swe-forge-pi-subagents, SelfContext, and a growing collection of custom AI agent skills. They are different repositories with different jobs, but each iteration leaves something behind that makes the next iteration easier.
A better context for brainstorming. A reusable skill. A workflow that removes repetitive decisions. A clearer opinion about what I trust AI to do and what I still want to review myself.
That is the part of AI productivity people tend to underestimate. It is not only about asking a model to write code faster. It is about building a loop where your context, tools, habits, and software start to compound.
The Projects Are Not the Point
I am not trying to write a tour of everything I built recently. Those projects deserve their own articles, with more detail about the ideas behind them, the architecture, and the parts that are still rough.
The more interesting story is what happened between them.
I was surprised by the amount of work and experimentation I was able to do every week. Not because I suddenly became ten times more productive, and I am not going to invent a percentage to make this sound more impressive. The evidence is much more practical: ideas that would have stayed in a notes file now become small implementations, and the setup for the next idea is better than the setup for the previous one.
I spend less time rebuilding the same context, deciding how to structure the same kind of work, or remembering the same delivery steps. More of my time goes into deciding what is worth building and whether the result is good enough.
That is a real productivity gain, even if it is difficult to put in a neat chart.
The Baseline Keeps Moving
I have been working with AI since ChatGPT came out. Since then, I have tried to understand what I can trust, what I should verify, and where the tools still fall apart when the problem is less convenient than a demo.
Every new model release changes the baseline. Things that felt unreliable become normal. Workflows that needed constant supervision become possible to automate. At the same time, new capabilities create new ways to produce convincing nonsense, usually faster than before.
The current state is very different from where we started, and we are still maturing in several directions at once. Models are improving, but so are the tools around them: context handling, local inference, coding harnesses, structured workflows, approvals, and evaluation.
The important change for me is that AI is no longer one product or one interface. It is a very large menu.
There are models, coding harnesses, editors, platforms, local runtimes, agent frameworks, and open-source experiments everywhere. I have used or explored parts of OpenCode, Codex, Claude Code, Pi, Hermes Agent, Cursor, Grok Build, and plenty of smaller projects. I am not looking for one universal winner. Different tools make different tradeoffs, and sometimes the useful part is understanding why they made those choices.
That menu is exciting, but it also changes the question. The scarce resource is not access to another tool. It is having a good enough mental model to decide what belongs in your workflow.
Build the Version That Fits Your Workflow
I like understanding how things work behind the scenes. Open-source projects make that easier than ever. You can read how different people solve the same problem, compare the boundaries they chose, borrow the ideas that make sense, and then apply your own taste.
You do not need to build everything from scratch. You can build the small, opinionated version of the part that matters to you.
That is what I have been doing. Not trying to compete with the most advanced cloud platforms or recreate every feature in every coding agent. I want workflows that fit the way I work, that I can inspect when something goes wrong, and that I can refine when I learn something new.
There are already platforms with more sophisticated multi-agent orchestration than anything I am building. That is great. This is not a competition with them. A general solution can be useful for many people, while a smaller personal solution can be better for one very specific workflow.
I also do not mean that I have eliminated every dependency. I still use models, harnesses, and platforms. But I am less dependent on somebody else’s decisions about how my work should be planned, reviewed, or delivered. I understand more of the loop, and I own the parts that are important to me.
I keep coming back to the projects themselves because they make this loop visible. They are not the story on their own. They are evidence of a workflow that keeps getting better.
SWE Forge is a good example. It is a portable, opt-in, Git-native workflow layer that turns a ticket into validated changes, readable commits, and one reviewable pull request. It inspects the repository, chooses the smallest useful execution setup, breaks work into cohesive steps, validates the result, and runs a fresh review before delivery.
The optional swe-forge-pi-subagents package gives Pi a bounded child-agent primitive that SWE Forge can use when a specialist worker is actually useful. It is deliberately not another workflow engine or orchestrator. The workflow remains in SWE Forge, and the child agent has a narrow job and a structured result.
That distinction matters to me. I am not trying to hide complexity behind a large system that promises to do everything. I am trying to make the important boundaries visible and automate the parts that I have already decided how I want to handle.
A Better Brainstorming Partner
Before I implement something, I often use SelfContext to think through the idea.
SelfContext keeps selected personal context in portable Markdown, so the AI tool I already use can reason from relevant history, goals, decisions, constraints, and evidence instead of starting from zero every time. It is not a chatbot or a replacement harness. It is a context layer around the workflow I already have.
That context makes a bigger difference than I expected.
If I am brainstorming a project, I do not have to explain my preferred technologies for an MVP, how I usually think about product and UX, what kind of tradeoffs I accept, what I am trying to learn, or which ideas I have already rejected. I can give the system the context I have chosen to keep and ask it to challenge an idea from there.
This does not make the model magically understand me. It gives the conversation a better starting point.
A brainstorming session often ends with a small roadmap, a sharper idea, or a description detailed enough to implement. That is where the next part of the loop starts.
From a Rough Idea to a Pull Request
Once I have a direction, I can use the PR mode of SWE Forge:
/swe-forge pr <ticket>The ticket still needs to be detailed. AI has not removed the need to think clearly about what should be built. A vague ticket can now become a very organized mistake, complete with tests and a pull request. That makes unclear instructions more expensive, because the system can plan, edit, test, and review a large change before you notice what was missing.
What SWE Forge removes is a different kind of friction. It manages the workflow around the implementation: repository discovery, task decomposition, specialist roles when they are useful, validation, independent or contradictory review, branch naming, commits, pull-request details, and the boundaries around delivery.
It can take more tokens than asking one agent to change a file. That is intentional. Planning, validation, and review have a cost. I still think the result is worth it because I trust the work more when I understand the process that produced it, and because I can keep refining that process after every use.
Most recent changes in these projects have been made through this kind of workflow, including changes to SWE Forge itself. It is not a finished product, and it was not even a polished alpha when I started using it. I keep finding rough edges, adjusting the policies, and learning which parts need more structure and which parts should stay simple.
Lately it has become stable enough for me to use across personal projects. That is a much more useful milestone than calling it complete.
The Work Starts Compounding
The compounding effect is not mysterious. Each project leaves behind a reusable piece of leverage.
- SelfContext gives me a better starting point for thinking.
- A brainstorming session produces a clearer roadmap or ticket.
- SWE Forge turns that ticket into a structured implementation and review workflow.
- The skills repository captures focused ways of working that can be loaded when a task needs them.
- Every completed change gives me more evidence about what to automate, what to validate, and what should remain under my control.
The next project does not start from the same blank page.
The custom skills are a good example of this. A skill can capture a quality bar, a way of reviewing a change, or a focused approach to a recurring problem without turning every prompt into a massive instruction dump. As I notice a pattern in how I work, I can turn part of that pattern into something reusable.
The same happens with the workflow itself. At first I had to think about every branch name, commit message, validation step, and pull-request description. Now those decisions are part of a process I can inspect and improve instead of repeating manually every time.
This is where productivity becomes more than output per hour. It is the ability to keep exploring ideas without lowering the quality bar or paying the full setup cost for every experiment.
Speed without quality is just a faster way to create work you will regret. The useful part is getting faster while keeping enough structure to trust what comes out.
The Useful Part Is Owning the Loop
A lot of AI discussion still focuses on the model as if the model were the whole product. Which one is smarter? Which one has the biggest context window? Which one can run for the longest time without supervision?
At some point, it starts to sound like sports commentary for model names.
Those questions matter, but they are only one part of the system.
The impact also comes from everything around the model: the context it receives, the tools it can use, the boundaries it has to respect, the way work is reviewed, and what gets kept for the next iteration. That is where personal workflows become interesting.
You can use a general solution and get very far. There are plenty of excellent tools available now. But when you understand your own work well enough, you can build smaller versions of the things you need and make them fit your preferences instead of adapting your whole process to somebody else’s product.
That kind of ownership is valuable even when the project stays small. You can see behind the scenes. You can disagree with the defaults. You can change the workflow when your needs change. And you can carry the lessons into the next project.
AI is not only making me faster at producing output. It is helping me build a personal system where context, skills, and workflows compound, as long as I keep the judgment, keep reviewing, and keep owning the important parts.
Keep building, my friends.