Pippo: Home / Transcript
Pippo: models and efforts
Pippo: Rulebook
Pippo: usages

Inspiration

We are individual freelancers, and coding agents are already a major part of how we work.

At any given time, we may be working across multiple client projects in parallel. Over time, we naturally develop our own way of working — how we structure projects, how we approach tasks, how much an agent should change at once, and how we want certain decisions to be handled.

Some of these preferences are global and apply almost everywhere. Others are completely project-specific.

But while using existing coding agents, we kept facing the same three problems.

The first was assumptions.

When something was unclear, agents often would not ask us what we meant. Instead, they would look at the closest pattern in the project, make an assumption, and continue.

Sometimes that worked. But when it didn't, we ended up spending more time finding and debugging the wrong assumption than the original change should have taken.

The second problem was repeating ourselves.

Because we work across multiple projects, we constantly have preferences that should carry with us. Some might be simple workflow preferences that apply to every project, while others only make sense for one particular client's codebase.

We did not want to keep explaining those things again every time we started a new session, switched projects, or moved to another device.

The third problem was control.

Coding agents can modify files, run commands, and interact with a developer's environment. But most of the time, we are relying on whatever default permission or safety rules the harness provides.

For client work especially, we wanted to define those boundaries ourselves.

These problems led us to build Pippo.

A coding agent that learns how you think — without taking your decisions away from you.

What We Built

Pippo is a collaborative coding agent for desktop and terminal.

Its main goal is not to remove the developer from the process. It is to become better at working with them over time.

When Pippo encounters an important ambiguity, it can ask instead of silently choosing what it thinks is most likely. If the intent is clear, it continues without unnecessary interruptions.

While working, Pippo can also learn preferences and classify them as either project-scoped or global-scoped.

Project-specific knowledge stays with that project. Global preferences can automatically carry across different projects.

For us, this is especially useful because the way we work may remain consistent even when the client or codebase changes.

Global knowledge can also sync across devices, so switching machines does not mean starting from zero again.

Pippo also includes a global and per-project rulebook. Developers can define actions as allow, ask, or deny, and those rules are enforced by the runtime before an action reaches the machine.

This means we do not have to rely entirely on default harness rules and hope they match the requirements of every client project.

Alongside these core features, Pippo supports persistent sessions for each project, parallel subagents, queued messages, reusable skills, and scheduled tasks or reminders that can still run when Pippo is closed.

How We Built It

Pippo runs as a Wails desktop application with a Go-based agent engine.

At the center is an orchestrator that manages context, coordinates parallel subagents, and handles tool execution.

We use Gemini 3.7 Flash through the Google Gen AI SDK for reasoning and agentic decision-making.

Before actions reach the machine, Pippo's runtime evaluates them against the developer's rulebook. Depending on the matching rule, an action can run automatically, require approval, or be denied completely.

For persistence, we use Firestore with Firebase Authentication to sync global-scoped knowledge and settings across devices.

Project-specific knowledge remains local, which allows us to keep project context close to the codebase while still carrying reusable preferences between projects.

The architecture is built around three ideas:

Persistent collaboration
Controlled execution
Local-first privacy

Challenges We Faced

One of the hardest problems was deciding when Pippo should ask and when it should continue.

An agent that asks about every small detail becomes frustrating very quickly. But an agent that always chooses an answer on its own creates exactly the problem we were trying to solve.

We had to find a balance where clarification is used for genuinely ambiguous or consequential decisions, while clear tasks can continue normally.

Memory was another challenge.

Simply storing information is easy. Deciding what should be remembered, where it belongs, and when it should affect future work is much harder.

We had to separate project-specific knowledge from preferences that should follow us across projects and make sure those memories were actually useful during future tasks.

The rulebook introduced another tradeoff.

We wanted strong control over what Pippo could do without creating an approval popup for every command or file operation. Supporting global and project-level allow, ask, and deny rules gave us a practical balance between safety and autonomy.

We also had to bring persistent sessions, memory, parallel agents, scheduling, queued messages, and skills together so they felt like parts of one continuous collaborator rather than unrelated features.

What We Learned

The biggest thing we learned is that more autonomy does not automatically make a better coding agent.

For the kind of work we do, a useful agent needs to understand when it can move forward and when a decision should stay with us.

We also learned how important scope is for memory. A preference that makes sense across every project should not have to be taught repeatedly, while knowledge belonging to one client's codebase should not automatically leak into another.

Most importantly, building Pippo changed our own workflow.

It started as an idea based on frustrations we had with the tools we were already using. But after building it and using it across our work, Pippo started to feel less like another coding tool and more like a partner that already understands how we prefer to work.

This hackathon gave us the reason to finally turn that idea into a working product, and in the process, Pippo has already changed the way we approach our own development work.

That is what we want Pippo to become:

A long-term coding partner that learns, remembers, asks when it should, and respects the boundaries you define.