What I learned shipping the Hefty beta with an AI coding partner

Hefty is in open beta. Hefty is a local-first AI agent that controls your computer, automates workflows, and manages files. This piece is not advice. It is a report from the build: what I learned making Hefty from scratch with AI as my primary coding partner. Some of it lines up with what I wrote in The New Rules. Some of it surprised me.

Where this comes from

I have been shipping code for 27 years. I hold a PhD in engineering, I have published in IEEE and Springer on distributed systems and neural models, and I was lead architect at Spain’s largest social network, a platform of more than 10 million users. Most recently, I helped build Anyone, the world’s largest distributed privacy network.

That background matters for what follows. I am not a newcomer dazzled by AI autocomplete. I have built production infrastructure at scale, and I am telling you the AI-assisted production line is real. It is just not real in the way most people think.

The plan, and where it stands

The plan for Hefty was three steps:

• make something people want to see;
• make something people want to use;
• make something people want to pay for.

I am at step 2. The beta is live, the focus group is active, and the feedback loop is running.

What two years of experimenting taught me

After two years of experimenting with different approaches, here is where I have landed: the fundamentals have not changed as much as people think.

You still need a solid software production line. A new class of development tools has arrived, yes. But the end product is still a form of expression that depends on the human operator. How much, and in what way, remains the human’s call.

I have built everything from VOD platforms to IoT analytics to virtual world engines. The production process matters more than the tools. The tools just got faster.

I wrote about this in The New Rules: when implementation speed approaches zero, thinking speed becomes everything. That turned out to be literally true in my own build process. The decades of architectural instincts I had built up did not become less valuable with AI. They became the bottleneck - in the best possible way.

Phase A: specification-driven core development

Phase A took two weeks of pure spec-refine-code-refine-spec loops.

Week 1 was for designing the core: the main architectural decisions, the domain language, the component map, and qualitative guides for the program lifecycle. This is where experience pays compound interest. Knowing which abstractions will hold up under real usage is not something you can prompt your way into.

Week 2 was for building the main features: the GUI, MCP integration, the API layer, the cognition flow (enrichment and context management), and activity streaming. The result was a somewhat working agent with a chat interface, a UI, and a solid program shell. The velocity was about two full iterations per week, from nothing to a running agent.

The key was that specification work and coding were interleaved, not sequential. Each code iteration informed the next spec revision. Each spec revision reshaped the code. The AI builder made this loop fast enough to be practical. What would have taken a month of back-and-forth happened in days.

Phase B: user-driven refinement

As soon as there was something to show, I changed the development flow. A focus group came in, and the loop became observe (use it), define (demand for change), apply (change the program), observe again. Four weeks ran at the same two-iterations-per-week pace, now fueled by real user feedback.

What I did not expect was the sheer volume of improvement opportunities that became visible once real people touched the product. Alongside the regular feature iteration, I was constantly slotting in directed cleanup: consistency passes, consolidation, and simplification of the source code.

This maps directly to what I have been writing in The New Rules: when AI can generate any feature, curation outranks creation. The hard work was not building features. It was deciding which improvements actually mattered and keeping the code base coherent while moving fast. That is judgment work. It comes from years of maintaining systems at scale, not from a well-crafted prompt.

Why there are no automated tests yet

I skipped automated testing for the early phases. Deliberately.

I know how that sounds from someone with a PhD and published work on quality assessment. Two reasons drove the call:

• velocity of change - the source code was transforming so rapidly that tests would have been constant maintenance overhead with minimal return;
• limited need for correctness - at this stage of product development, directional accuracy matters more than precision.

During these initial phases, I threw out about four early prototypes just to flesh out the initial design scaffold. Component layouts, streaming and execution flows, cognition scope, diagonal integrations for maintenance tasks - all of it went through major rewrites.

My thesis: it is easier to untangle code with an experienced reviewer and an AI partner than to manage a comprehensive test suite through multiple architectural transitions. This goes against conventional wisdom. But conventional wisdom was written for a world where rewriting code was expensive. When your AI builder can restructure an entire module in minutes, the calculus changes.

The tests are coming. The architecture is stabilizing, and wide-reaching changes are dropping off. Forcing tests early would have slowed me down for no real safety gain.

What happens next

The iterative process stays the same: observe, define, apply. But each step gets more automated, with less human oversight. The program is mature enough now that the production line itself needs an upgrade: more guardrails, more automation, more confidence in the change process.

I have been tracking the same pattern across the industry. As AI implementation speed approaches zero, the bottleneck shifts up the stack. First it was coding speed. Then it was decision speed. Now it is process design.

I will report back with more details in a couple of weeks.

Try the beta

Hefty is in open beta. It runs locally, it is privacy-first, and you bring your own LLM or an API key. The beta is free to try and available on Linux, macOS, and Windows.

If you are building software with AI tools right now, I would love to hear how your process compares. The production line is the product - everything else is just output.