DEV Community: Johan Schuijt

Pi is a really nice agent

Johan Schuijt — Fri, 31 Jul 2026 16:32:50 +0000

I have always built my own working environment. I use nvim, customized through plugins. I use ergodox keyboards with a keymap that probably makes sense only to me. Oh, and I use Arch, by the way. Not because everyone should manage their computer this way, but because I want my tools to adapt to how I work—not the other way around.

There is an entirely reasonable alternative: let somebody else assemble the system, maintain it, and decide how its parts fit together. That removes responsibility and lets you concentrate on the work. The tradeoff is that you can only work within boundaries designed for the whole market. An open ecosystem lets you draw those boundaries yourself.

For years, I have assembled my development environment from tools people shared on the internet. That ecosystem has given me more than software. I have learned from the code, documentation, and ideas that other people published freely.

For about a year, Claude Code was an exception. I had used Anthropic’s coding harness since its early beta, its models were among the best for programming, and the whole thing did its job well. I had no reason to look elsewhere.

Then, in early 2026, Anthropic restricted Claude subscription credentials to its own products, preventing third-party harnesses from using them. API access remained available, but was metered separately.

The change clarified what Claude Max was: not a general model subscription, but a subscription to Anthropic’s products. That did not suit how I wanted to work. I wanted a harness I could shape myself, so I started looking for an open-source alternative.

It extends itself

I found what I wanted in the pi coding agent. Pi starts with a deliberately small core: read, write, edit, and bash. Everything else—extensions, skills, prompt templates, themes, and packages—is pluggable. It feels more like the open ecosystem I came from than a product trying to anticipate every workflow. Pi even encourages you to ask the agent to build extensions for itself, and ships comprehensive documentation and examples to support it. The tool is designed to help you build the tool.

Having used coding agents since their early days, I already had a good idea of where they struggled. The largest gap was exploration: building a global understanding of a codebase instead of accumulating a fragmented collection of files and snippets. I followed pi’s philosophy and resisted recreating every feature I had left behind. I would add only small, sharp tools for problems I had actually seen.

Tool descriptions are instructions: they tell the model what it can call, when to call it, and how to structure the call. Adding more tools therefore adds more instructions and more competing choices. In ManyIFEval, models became steadily less reliable as they were asked to follow more simultaneous instructions. LongFuncEval found the same pattern in function calling. There is no universal cliff or safe number. The practical rule is simply to keep the active surface as small as the work allows, and make every tool earn its place.

What I've built

Over the past six months, I've converged on this minimal set of extensions:

fork — lets one Pi session hand a focused task to another. Each sub-agent starts with a fresh context in its own tmux window, reports its result to the parent, and remains available for review or revisions. For coding tasks that can run in parallel, fork can give each child an isolated Git worktree on its own branch.

trace — gives Pi three deterministic ways to navigate code: outline maps the definitions in a file or directory, def retrieves a complete definition by name, and callers finds call sites to inspect. Tree-sitter provides the syntax trees, while SQLite caches the resulting index. callers is deliberately simple: it finds call-shaped syntax without resolving imports or types, so it also works on incomplete and broken source.

scry — lets Pi search the web. Its single web_search tool returns links with enough context for the agent to decide what to open, and can restrict searches to recent results.

mine — lets Pi read those pages. Its web_fetch tool opens a URL in Chrome, waits for JavaScript to render, dismisses cookie banners, and extracts the main content as clean markdown. Using a browser rather than a simple HTTP request makes client-rendered sites work too.

So far, I haven't needed anything else.

Working with and building agents has taught me where they struggle and what kinds of support they need. That knowledge shaped these extensions and has been as valuable as the tools themselves. It has also shaped what I deliberately left out.

Explore, then validate

Every codebase is unfamiliar to an agent. Before it can make useful changes, it needs orientation: a high-level map of what is defined where, so it can decide what to inspect instead of reconstructing the architecture through a long sequence of grep searches.

A language server appears to be the obvious solution, but it solves two different problems: code navigation and diagnostics. Language servers are designed to power an entire interactive editor, with a broad set of continuously available semantic features. That makes them complex and slow, while an agent usually needs much less.

To build an overview, syntax trees are enough. Tree-sitter produces them on demand and is designed to return useful results even when the source contains syntax errors. Exploration does not require every result to be semantically exact; it needs to point the agent toward the right code.

Diagnostics are different. They need to be precise, but the agent needs them only when it is ready to check its work. It can explicitly run the formatter, linter, type checker, and tests, while a Git pre-commit hook guarantees that those checks happen before a change is committed.

Branch, not loop

The same ideas apply to context, so I keep agent trajectories short. Long-running sessions eventually fill their context windows. A common response is compaction: replace the earlier conversation with a summary and continue. This keeps the context bounded, but summarization is inherently lossy. Constraints, decisions, and failed approaches can disappear. I think of it as entropy: each rewrite introduces a little more noise.

Instead of repeatedly compressing one conversation, I branch the work. One Pi session remains at the center, carrying the direction and decisions. Research questions branch into fresh agents and return as focused reports for us to discuss. Once the next step is clear, the main agent divides the implementation into chunks, delegates each one, reviews the results, and commits them. It plays much the same role as plan mode in other harnesses: it carries the plan, while the other agents carry only what they need for their task.

On larger jobs, a delegated agent can branch the work again. The shape changes, but the principle does not: each agent gets a focused context, and each result returns through an explicit, reviewable handoff.

These branches have a concrete foundation. The main session and every delegated agent run in separate tmux windows, where they remain available for review and revisions. Parallel coding tasks can also run in isolated Git worktrees. I keep the entire environment inside Ward, a single rootless container that exposes only the parts of the filesystem the agents need. It is not a complete security boundary against an adversary; it limits the blast radius of ordinary mistakes.

Separating the roles also lets me choose a model for each. I use more capable models for the main session, while smaller, faster models handle well-scoped implementation work. Given a clear assignment and the relevant context, those smaller models are surprisingly capable.

The models

Lately I'm mostly using open-weight models from Moonshot, Zhipu, and DeepSeek. These are no longer budget alternatives to the frontier; they are part of it. Kimi K3 currently sits near the top of the Artificial Analysis Intelligence Index, while GLM and DeepSeek remain competitive at API prices often far below those of the leading closed providers. There's also a less obvious reason: these labs release their models, while closed providers do not. If my usage data contributes to training, I would rather that value flow toward models the public can run and build on than remain entirely inside a closed product.

I still keep subscriptions to closed providers. For harder problems, I let models from different families respond to one another—either through sub-agents or by pasting one model's output into another context. They critique and build on each other's work. In my experience, the exchange surfaces ambiguities, edge cases, and bad assumptions that either model might accept on its own.

Models will come and go. What I wanted was an environment that could change with them and with me. That is what I have now, and creating it has given me a satisfaction that no bought software ever could.

Pi gave me a small core I could understand and change. Everything I added came from a problem I had actually encountered. I no longer have to adapt my work to a harness designed for everyone else. I can adapt the harness to my work.

The tool is not the author

Johan Schuijt — Sat, 18 Jul 2026 13:28:02 +0000

When a photographer presses the shutter button, nobody questions who owns the photo. The camera made every technical decision — metering, focus, exposure — using algorithms trained on optical models. The photographer chose what to point it at, when to shoot, and which photo to keep. That's enough. It has been enough since 1884, when the Supreme Court ruled in Burrow-Giles v. Sarony that photography produces copyrightable work, despite being a mechanical process. The human directed it. That settled it.

Now replace "camera" with "language model" and watch the same principle suddenly become controversial.

We've been here before

Before we talk about LLMs, let's be precise about what we're already comfortable with.

Modern smartphone cameras use neural networks to composite multiple exposures into a single image: HDR, night mode, portrait blur are all generated by statistical models. The photographer copyrights the photo. Auto-tune corrects a singer's pitch using a statistical model of frequency distributions. The producer copyrights the song. Machine translation runs a document through a language model that generates entirely new sentences, word choices, and structure in another language. The translator copyrights the result. Procedural generation in video games uses algorithmic models to create terrain, levels, and textures. The studio copyrights all of it.

In every one of these cases, a statistical model transforms human input into output that the human couldn't have produced manually in the same way. And in every case, nobody questions that the human who directed the tool owns the result.

An LLM is the same mechanism. It's a statistical model trained on text, producing output based on learned patterns. The only difference is that it's more general and more capable. If the principle is that statistical modeling disqualifies output from copyright, then it has to apply equally to all of these. To draw a line between "this much statistics is fine" and "this much isn't," you'd have to explain where the threshold sits and why it belongs there.

I don't think that line can be drawn — and I don't think it should be.

Meaning needs direction

An LLM on its own produces nothing meaningful. It has no problem to solve, no audience to address, no intent to express. Without a human pointing it at something — a codebase, a reader, a creative vision — its output is inert. It doesn't become a work because tokens were generated. It becomes a work when a human gives it purpose: deciding what to ask for, whether the result is good, and where it fits. The human isn't just claiming authorship. The human is what makes the output a work at all.

This is no different from how authorship has always functioned. A director tells actors what to do and gets credit for the film. A composer specifies notes and an orchestra performs them. The person who directs the work is the author. Authorship has always been about direction and selection, not manual execution of every detail.

This also handles the obvious counterexample. Someone who types one vague sentence and publishes the first output unreviewed has a weak authorship claim — not because AI was involved, but because they barely constituted the work. Minimal direction means the human gave the output almost none of its meaning. The existing copyright framework already makes this distinction. The question has never been "which tool did you use?" — it has always been "did you exercise creative judgment?"

Nothing comes from nothing

If you deny copyright to human-directed LLM output because the model learned from copyrighted material, you have created a principle that applies to humans too. Every programmer learned from existing code: documentation, books, Stack Overflow, other people's repositories. Every writer learned from published work. If learning from copyrighted material taints the output, then human-produced work is equally tainted. Applied consistently, this principle would collapse copyright entirely, because no one creates from nothing.

And consider the alternative. The LLM cannot hold copyright: it has no legal personhood, no rights, no standing. If the human who directed it also cannot hold copyright, then the work belongs to nobody. This isn't a theoretical edge case. It's a legal vacuum where useful work has no owner, no protection, and no incentive structure around it. The entire framework of copyright exists to incentivize creation. If using more capable tools strips you of ownership, that's a perverse outcome that undermines the purpose of the system itself.

It was always about trust

Several open source projects — NetBSD, QEMU, FreeBSD, Gentoo, Forgejo, among others — have restricted or banned AI-assisted contributions. The most common legal justification is the Developer Certificate of Origin, which requires contributors to certify they wrote the code or have the right to submit it, and that it doesn't carry incompatible license obligations.

The concern is genuine: LLMs are trained on code under every license imaginable, and there's no way to inspect whether a particular output closely mirrors something from an incompatible source. Contributors can't make that certification with full confidence.

However, that uncertainty isn't unique to AI. A developer who spent three years working on a proprietary codebase carries patterns, idioms, and sometimes near-verbatim snippets from that work into everything they write afterward. They can't prove their contribution wasn't shaped by proprietary code.

The DCO has never been a proof system. It's a good-faith attestation. When a developer signs Signed-off-by, nobody audits their memory or browsing history. The system runs on trust. If a good-faith attestation is acceptable from a human black box, it should be equally acceptable from someone who used an LLM, reviewed the output, understood it, and is confident it's not reproducing something verbatim. The standard is the same.

The real problem

The honest reason many projects are banning AI contributions isn't copyright or the DCO. It's that they're drowning in low-quality submissions. AI has made it trivially cheap to produce superficially plausible but fundamentally broken code, and maintainers are bearing the cost of reviewing it. That's a real problem, but it's a quality control problem, not a copyright problem, and banning the tool doesn't solve it.

Before LLMs, projects dealt with the same issue on a smaller scale: drive-by pull requests, Hacktoberfest spam, code copied from Stack Overflow without understanding. AI just made low-effort contributions cheaper to produce. The Linux kernel has never banned AI-assisted contributions. Its review process filters for quality regardless of what tools were used. It cares whether you understand the code and can stand behind it. That approach is future-proof in a way that tool bans never will be.

These tools are becoming standard in professional workflows. A policy that assumes you can reliably distinguish "human-written" from "AI-assisted" code is already barely enforceable and will only become less so. Worse, it forces responsible contributors who use these tools productively to either leave or lie about their process. Neither outcome helps the project.

The law is already moving

The principle is sound. And the legal landscape is catching up. The US Copyright Office's January 2025 report affirms that using AI to assist in creation does not bar copyrightability, reserving skepticism only for cases of minimal human involvement. In Thaler v. Perlmutter (affirmed on appeal in 2025, certiorari denied in 2026), the courts ruled that an AI system cannot be named as author, but that case was deliberately filed with no claim of human involvement, and the court explicitly left open the question of human-directed AI output. Allen v. Perlmutter, currently before a federal court in Colorado, is testing exactly that question. In Europe, Italy became the first EU member state to pass a law explicitly regulating authorship of works created with AI assistance.

The remaining legal question isn't whether human-directed AI work can be copyrighted. It's where the minimum threshold of human involvement sits. That's a question about degree, not principle. It's the same question copyright has always asked about every tool.

The projects and institutions making policy today should consider what position they want to be in as this settles. Building policy around the assumption that AI-assisted work isn't copyrightable is building on ground that is already shifting beneath them.

The tool is not the author. The human is.

AI agents are human too

Johan Schuijt — Sun, 07 Dec 2025 13:07:42 +0000

The way we access information online is changing. Sure you can use a web browser and search engines, but if you're like me, you're probably using AI agents to research everything. Having the model automatically fill its context with content from the web is great, however, more and more often it can't. Increasingly, the model is unable to fetch web pages. Why is this happening?

The root cause isn't technical—it's economic. The monetization models on the web rely not on the content itself, but on the ecosystem surrounding it: the ads, recommendations, and engagement features that capture attention alongside the actual information. When people use text-based language models to fetch the content, they don't see ads, don't engage, and don't build brand-loyalty. This defeats most business models on the web. It's traffic that can't be monetized.

Zero-sum cat-and-mouse

Faced with this threat, content producers have reached for a short-sighted solution: blocking these requests. They try to force people back to the old method of using a browser, desperate to keep control over how their content is consumed.

But blocking creates more problems than it solves. First, it degrades the experience for regular browser-based visitors. Some will face CAPTCHA pages: "Verify you are human", every time they visit a website. It can take as little as a couple of extensions to have a non-default browser and end up endlessly proving you are a human.

More importantly, blocking doesn't actually work. There is no identity system baked into HTTP, so circumventing these blocks is very easy. It's so mundane that it’s offered as a professional service, and popular modules exist to make your bot look like a default browser. There simply is no reliable way to block automated scraping while allowing normal use without massively impacting the openness of the web.

This has created an absurd economic dynamic. Content producers pay network operators to block automated traffic. Companies pulling in content pay network operators to circumvent those blocks. It's textbook economic inefficiency: both sides pouring resources into neutralizing each other. In war, the only winner is the arms dealer.

Do you trust me?

What makes this blocking war particularly futile is that the web was never designed for it. The entire web is built on trust and "gentleman's agreements". Websites publish a /robots.txt file to signal what can be automatically scraped, which is just a request and completely unenforceable. These trust based systems are not an exception, they are the rule. Email assumes you won't forge sender addresses, browsers voluntarily identify themselves, and sites trust you won't flood them with requests. The entire web stack is held together by good faith.

In the past we even trusted public networks with our plain-text communication. However, we've learned that trust is not always justified. Now, we usually encrypt our traffic, but still, the system for doing so is built on trust. Instead of trusting everyone not to eaves-drop, we're trusting certified identities. That trust only works one way though: the content consumer trusts the content provider. The web was designed for anonymous browsing. Creating the reverse system, where producers verify the identity of consumers, would mean every site tracks your identity by design. That would destroy privacy altogether.

All the identity systems that currently do exist on the web are tied to specific companies or websites. Our agents can't fetch articles behind the paywall of services we're actually paying for—there's no authentication system that can handle this. Some companies are trying to position themselves as identity brokers, wanting to gate-keep every interaction and turn every website visit into a micro-transaction.

However, I would argue that if we want to keep the web open, while also facilitating a fair exchange of information, we should come up with an open protocol instead.

Human after all

What everyone seems to be forgetting, is that there are actual humans behind most "automated" access. When someone uses an AI agent to research a topic, they're not "a bot", they're a person using a sophisticated tool to navigate information.

Which is actually the realization of Tim Berners-Lee's vision for the Semantic Web: a web that can be processed by machines, to help humans navigate the information more effectively. We are witnessing exactly that, just not through RDF and ontologies, but through the capabilities of language models to parse unstructured content.

So, what now?

Our current trajectory is unsustainable. We're clinging to the "browser-only" web, as if the colorful boxes and branded experiences were the point, rather than the information exchange between humans that the web was meant to facilitate. By blocking AI agents, we're not protecting business models, we're just degrading the web for everyone while the real scrapers continue unimpeded.

Instead of fighting this evolution, we need to recognize that AI agents represent a new, legitimate way for people to interact with content. The question isn't how to stop it, but how to build sustainable business models that work with this new paradigm.

The solution won't come from blocking or from centralized gatekeepers. It will come from re-imagining how we value and exchange information when the interface between human and content is no longer a browser window, but an "intelligent" machine.

Machines parsing content to help humans navigate information. Instead of treating this as a threat, we should see it for what it is: it's what the web was supposed to be.