I’m still looking for a generic agent interaction protocol (to make it worth building around) and thought ACP might be it. But (and this is from a cursory look) it seems that even OpenCode, which does support ACP, doesn’t use it for its own UI. So what’s wrong with it and are there better options to hopefully take its place?
I've started using OpenCode for some things in a big window because its side-by-side diff is great.
The best option will always be in-memory exchanges. Right now I am still using the pi RPC, and that also involves a bit of conversion, but it’s much lighter.
https://github.com/search?q=repo%3Arcarmo%2Fagentbox%20codex...
Before Pi, I actually preferred Mistral Vibe’s UX
I was curious about your project, but the sloppy usage of even the most basic terms kind of makes me not to want to dive deeper, how could I even trust it does what it says on the tin, if apparently we don't even have a shared vocabulary?
and you can build cool stuff on top of it too!
Pleased to meet you!
For me, it just didn’t compare in quality with Claude CLI and OpenCode. It didn’t finish the job. Interesting for extending, certainly, but not where my productivity gains lie.
Now I can just make my own that does exactly what I want and need, nothing more and nothing less. It's just for me, it's not a SaaS or a "start-up" I'm the CEO of.
I dislike many things about Claude Code, but I'll pick subagents as one example. Don't want to use them? Tough luck. (AFAIK, it's been a while since I used CC, maybe it is configurable now or was always and I never discovered that.)
With Pi, I just didn't install an extension for that, which I suspect exists, but I have a choice of never finding out.
With Emacs modes like agent-shell.el available and growing, why not invest in learning a tool that is likely to survive and have mindshare beyond the next few months?
And if there’s any feature codex has that you want, just have pi run codex in a tmux session and interrogate it how said feature works, and recreate it in pi.
The extensibility is really nice. It was easy to get it using my preferred issue tracker; and I've recently overridden the built-in `read` and `write` commands to use Emacs buffers instead. I'd like to override `edit` next, but haven't figured out an approach that would play to the strengths of LLMs (i.e. not matching exact text) and Emacs (maybe using tree-sitter queries for matches?). I also gave it a general-purpose `emacs_eval`, which it has used to browse documentation with EWW.
Let me also drop a link to the Pi Emacs mode here for anyone who wants to check it out: https://github.com/dnouri/pi-coding-agent -- or use: M-x package-install pi-coding-agent
We've been building some fun integrations in there like having RET on the output of `read`, `write`, `edit` tool calls open the corresponding file and location at point in an Emacs buffer. Parity with Pi's fantastic session and tree browsing is hopefully landing soon, too. Also: Magit :-)
The implementation is pretty terrible: a giant string of vibe-coded Emacs Lisp is sent to emacsclient, which performs the actions and sends back a string of JSON.
It's been interesting to iterate on the approach: watching the LLM (in my case Claude) attempting to use the tools; noticing when it struggles or makes incorrect assumptions; and updating the tool, documentation and defaults to better match those expectations.
I've also written some Emacs Lisp which opens Pi and tells it to "Action the request/issue/problem at point in buffer '<current-buffer>'" https://github.com/Warbo/warbo-emacs-d/blob/a13a1e02f5203476...
It feels similar to the file-watching provided by Aider (which uses inotify to spot files containing `# AI!` or `# AI?`), which I've previously used with FIXME and TODO comments in code; but it also works well in non-file things, e.g. error messages and test failures in `shell-mode`, and issues listed in the Emacs UI I wrote for the Artemis bug tracker (Claude just gets the issue number from the current line, and plugs that into a Pi extension I made for Artemis :-) )
Pi appears to have a smaller, less “pre-made” ecosystem, but with more flexibility, enthusiasm and extensibility.
Is this correct? Should I look towards Pi over OpenCode? What are the UI options?
Honestly, it's been a dream, I have it running in a docker-sandbox with access to a single git repo (not hosted) that I am using for varied things with my business.
Try it out, it's super easy to setup. If you use docker sandbox, you can just follow what is necessary for claude, spin up the sandbox, exit out, exec into it with bash and switch to Pi.
I looked a bit into the reasoning for Pi’s design (https://mariozechner.at/posts/2025-11-30-pi-coding-agent/#to...) and, while it does seem to do a lot of things very well around extensibility, I do miss support for permissions, MCP and perhaps Todos and a server mode. OpenCode seems a lot more complete in that regard, but I can well imagine that people have adapted Pi for these use cases (OpenClaw seems to have all of these). So it’s definitely not out of the race yet, but I still appreciate OpenCodes relative seeming completeness in comparison.
> I do miss support for permissions,
As soon as your agent can write and execute code, your permissions are just a security theater. If you care, just do proper sandboxing. If not, there are extensions for that.
> MCP
Again, Pi is extensible.
pi install pi-mcp-adapter
Now, you can connect to any mcp.
> and perhaps Todos
At least 10 different todo extensions. Pick which one you like. If you don't like any of them, ask Pi to write one for you.
> and a server mode.
Pi has rpc mode, which is a kind of server. If that's not enough, you could extend it.
> OpenCode seems a lot more complete in that regard,
Yes, but good luck working with Opencode if you don't like their plan-mode. Or todo support. And MCP. You pay their cost in complexity and tokens even if you don't use them or you don't like how they work.
> but I can well imagine that people have adapted Pi for these use cases (OpenClaw seems to have all of these). So it’s definitely not out of the race yet, but I still appreciate OpenCodes relative seeming completeness in comparison.
There's also an oh-my-pi fork if you want an out-of-the-box experience. Still, in my experience, nothing beats Pi in terms of customizability. It's the first piece of software that I can easily make completely to my liking. And I say that as a decade old Emacs user.
https://github.com/can1357/oh-my-pi
More of a batteries included version of pi.
I have this in my shell rc.
# bun
export BUN_INSTALL="$HOME/.bun"
export PATH="$BUN_INSTALL/bin:$PATH"
alias my-omp= "bun/Users/aravindhsampathkumar/ai_playground/oh-my-pi/packages/coding-agent/src/cli.ts"
1. git pull origin main
2. bun install
3. bun run build:native
every time I pull changes from upstream.
Until yesterday, this process was purely bliss - my own minimal custom system prompt, minimal AGENTS.md, and self curated skills.md. One thing I was wary of switching from pi to oh-my-pi was the use of Rust tools pi-native using NAPI. The last couple of days whatever changes I pulled from upstream is causing the models to get confused about which tool to use and how while editing/patching files. They are getting extremely annoyed - I see 11 iterations of a tool call to edit a damn file and the model then resorted to rewriting the whole file from memory, and we al know how that goes. This may not be a bug in oh-my-pi per se. My guess is that the agent developed its memory based on prior usage of the tools and my updating oh-my-pi brought changes in their usage. It might be okay if I could lose all agent memory and begin again, but I dont want to.
I'm going to be more diligent about pulling upstream changes from now on, and only do when I can afford a full session memory wipe.
Otherwise, the integrations with exa for search, LSP servers on local machine, syntax highlighting, steering prompts, custom tools (using trafilatura to fetch contents of any url as markdown, use calculator instead of making LLM do arithmetic) etc work like a charm. I haven't used the IPython integration nor do I plan to.
I am building my own assistant as an AI harness - that is definitely getting sandboxed to run only as a VM on my Mac.
Went from codex/claude code -> opencode -> pi -> oh-my-pi
It's just an opinionated fork, either you like it or you don't. I personally really like it.
You can open a grid of windows inside vscode too and it comes back up exactly as it was on reload.
Think of it more like directing a coworker or subcontractor via text chat. You tell them what you want and get a result, then you test it if it's what you want and give more instructions if needed.
I literally just fixed a maintenance program on my own server while working my $dayjob. ssh to server, start up claude and tell it what's wrong, tab away. Then I came back some time later, read what it had done, tested the script and immediately got a few improvement ideas. Gave them to Claude, tabbed out, etc.
Took me maybe 15 minutes of active work while chatting on Slack and managing my other tasks. I never needed to look at the code at any point. If it works and tests pass, why do I care what it looks like?
In my own experience I cannot blindly accept code without even looking at it even for a few moments because I've had many situations where the code was simply doing the wrong things... including tests are completely wrong and testing the wrong assumptions.
So yah, even when I review trivial changes I still look at the diff view to see if it makes sense. And IDEs make code review a lot easier than diff.
Btw, this experience is not from lack of trying. We use coding agent extensively (I would assume more than the typical org looking at our bill) and while they are certainly very, very helpful and I cannot describe how much effort they are really saving us, there is absolutely zero chance of pushing something out without reviewing it first - same applies for code written by AI agent or a coworker.
CLI within VSCode is workable but most of my VSCode envs are within a docker container. This is a pattern that I'm moving more and more away from as agents within a container kind of suck.
I agree. I tried Gemini CLI for a while, and didn't like how separate I felt from the underlying files: rather than doing minor cleanup myself, the activation energy of switching to a separate editor and opening the same files was too high, so I'd prompt the LLM to it instead. Which was often an exercise in frustration, as it would take many rounds of explanation for such tiny payoffs; maybe even fiddling with system prompts and markdown files, to try and avoid wasting so much time in the future...
I've been using Pi for a few weeks now, and have managed to integrate it quite deeply into Emacs. I run it entirely via RPC mode (JSON over stdio), so I don't really know (or care) about its terminal UI :-)
Because then you need to make an extension for every IDE. Isn't it better to make a CLI tool with a server, and let people make IDE extensions to communicate with it?
Claude Code has an update every few days. Imagine now propagating those changes to 20+ IDEs.
This is quite nice — I do think there’s a version of pi’s design choices which could live in a static harness, but fully covering the same capabilities as pi without a dynamic language would be difficult. (You could imagine specifying a programmable UI, etc — various ways to extend the behavior of the system, and you’d like end up with an interpreter in the harness)
At least, you’d like to have a way to hot reload code (Elixir / Erlang could be interesting)
This is my intuition, at least.
I'm super on board the rust train right now & super loving it. But no, code hot loading is not common.
Most code in the world is dead code. Most languages are for dead code. It's sad. Stop writing dead code (2022) was no where near the first, is decades and decades late in calling this out, but still a good one. https://jackrusher.com/strange-loop-2022/
But Rust can dynamically link with dylib but I believe it's still unstable.
It can also dynamically load with libloading.
No serialization/JSON-RPC layer between a TS CLI and Elixir server. TS TUI libraries utilities are really nice (I rewrote the Elixir-based CLI prototype as it was slowing me down). Easy to extend with custom tools without having to write them in Elixir, which can be intimidating.
But you're right that Erlang's computing vision lends itself super well to this problem space.
The first issue I had was to figure out the schema of the models.json, as someone who hadn't used the original pi before. Then I noticed the documented `/skill:` command doesn't exist. That's also hard to see because the slash menu is rendered off screen if the prompt is at the bottom of the terminal. And when I see it, the selected menu items always jumps back to the first line, but looks like he fixed that yesterday.
The tool output appears to mangle the transcript, and I can't even see the exact command it ran, only the output of the command. The README is overwhelmingly long and I don't understand what's important for me as a first time user and what isn't. Benchmarks and code internals aren't too terribly relevant to me at this point.
I looked at the original pi next and realized the config schema is subtly different (snake_case instead of camelCase). Since it was advertised as a port, I expected it to be a drop-in replacement, which is clearly not the case.
All in all it doesn't inspire confidence. Unfortunate.
Edit: The original pi also says that there is a `/skill` command, but then it is missing in the following table: https://github.com/badlogic/pi-mono/tree/main/packages/codin...
The `/skill` command also doesn't seem registered when I use pi. What is going on? How are people using this?
Edit2: Ah, they have to be placed in `~/.pi/agent/skills`, not `~/.pi/skills`, even though according to the docs, both should work: https://github.com/badlogic/pi-mono/tree/main/packages/codin...
This is exhausting.
It looks 100% vibe coded by someone who’s a complete neophyte.
Their agent mail was great & very early in agent orchestration. Code agent search is amazing & will tell you what's happening in every harness. Their Franktui is a ridiculously good rust tui. They have project after project after project after project and they are all so good.
Didn't know they had a rust Pi. Nice.
It’s clear it was 100% written by Claude using sub-agents which explains the many classes with 5000 lines of rust in a single file.
It’s a huge buggy mess which doesn’t run on my Mac.
If you’re a rust engineer and want a good laugh, go take a look at the agent.rs, auth.rs, or any of the core components.
Caring about taste in coding is past now. It's sad :( but also something to accept.
Looks like a lot of nonsensical commits.
First of all it wouldn't build, I have to mess around with git sub-modules to get it building.
Then trying to use it. First of all the scrolling behavior is broken. You cannot scroll properly when there are lots of tool outputs, the window freezes. I also ended up with lots of weird UI bugs when trying to use slash commands. Sometimes they stop the window scrolling, sometimes the slash commands don't even show at all.
The general text output is flaky, how it shows results of tools, the formatting, the colors, whether it auto-scrolls or gets stuck is all very weird and broken.
You can easily force it into a broken state by just running lots of tool calls, then the UI just freezes up.
But just try it and see for yourself...
Don't hate me aha and no, there is no reason other than I can
It seems stange also that even Steinberger in his interviews is not giving pi the proper attribution.
pi plugins support adding hooks at every stage, from tool calls to compaction and let you customize the TUI UI as well. I use it for my multi-tenant Openclaw alternative https://github.com/lobu-ai/lobu
If you're building an agent, please don't use proprietary SDKs from model providers. Just stick to ai-sdk or pi agent.
("Limited experimentation" = a few months ago I threw $10 into the Anthropic console and did a bit of vibe coding and found my $10 disappeared within a couple of hours).
If so, that would support your concern, it does kinda sound like they're selling marginal Claude Code / Gemini CLI tokens at a loss. Which definitely smells like an aggressive lockin strategy.
Anthropic docs is intentionally not clear about how 3P tools are defined, is it calling Claude app or the Anthropic API with the OAuth tokens?
https://yepanywhere.com/subscription-access-approaches/
Captures the ai-sdk and pi-mono.
In an ideal world we would have a pi-cli-mono or similar, like something that is not as powerful as pi but gives a least common denominator sort of interface to access at least claude/codex.
ACP is also something interesting in this space, though I don't honestly know how that fits into this story.
Wondering if you wanted a similar interface (though a GUI not just CLI) where it's not for coding what would you call that?
Same idea cycle through models, ask question, drag-drop images, etc...
"harness" fits pretty nicely IMO. It can be used as a single word, and it's not too semantically overloaded to be useful in this context.
For me I'm looking to stick with Python so will whip something up with Tkinter later for the desktop GUI aspect although I still like Electron/JS primarily.
EDIT: Thank you to both responders. I'll just try the two options out then.
Fwiw the janky `claude -p` approach you described is actually pretty solid once you stop fighting it, the simplicity is the feature I think.
That's how the pi-coding-agent Emacs package interacts with pi; and it's how I write automated tests for my own pi extensions (along with a dummy LLM that emits canned responses).
If you want bags of features, rather clone oh-my-pi somewhere, and get your agent to bring in bits of it a time, checking, reviewing, customising as you go.
https://github.com/elyase/awesome-personal-ai-assistants?tab...
Nearly all of its value is facilitating your interaction with the LLM, the tools it can use, and how it uses them.
Qwen3.5 released a couple of days ago but I'm not that RAM rich
Does anyone have an idea as to why this would be a feature? don't you want to have a discussion with your agent to iron out the details before moving onto the implementation (build) phase?
In any case, looks cool :)
EDIT 1: Formatting EDIT 2: Thanks everyone for your input. I was not aware of the extensibility model that pi had in mind or that you can also iterate your plan on a PLAN.md file. Very interesting approach. I'll have a look and give it a go.
As for subagents, Pi has sessions. And it has a full session tree & forking. This is one of my favorite things, in all harnesses: build the thing with half the context, then keep using that as a checkpoint, doing new work, from that same branch point. It means still having a very usable lengthy context window but having good fundamental project knowledge loaded.
There are already multiple implementations of everything.
With a powerful and extensible core, you don't need everything prepackaged.
https://github.com/badlogic/pi-mono/tree/main/packages/codin...
I really like the customization aspect of it and you can build tools on fly and even switch model mid session
There’s another project here called oh my pi has anyone here tried it
No plan mode. Write plans to files, or build it with extensions, or install a package. No built-in to-dos. Use a TODO.md file, or build your own with extensions. No background bash. Use tmux. Full observability, direct interaction.
This is very important to have control and ownership.
Pi is not for everyone, but the ones eventually want to have tools like (read, bash, edit, write, grep, find, ls) as building blocks.
Here’s an example config: https://github.com/earendil-works/gondolin/blob/main/host/ex...
Note that if you sandbox to literally just the working directly, pi itself wont run since pretty much every linux application needs to be able to read from /usr and /etc
ChatGPT $20/month is alright but I got locked out for a day after a couple hours. Considering the GitHub pro plus plan.
Eg some form of comprehensive planning/spec workflow is best modeled as an extension vs natively built in. And the extension still ends up feeling “native” in use
pi.dev domain graciously donated by exe.dev
Open source: https://github.com/isagawa-co/isagawa-kernel
There's something in the default Codex harness that makes it fight with both arms behind its back, maybe the sandboxing is overly paranoid or something.
With Pi I can one-shot many features faster and more accurately than with Codex-cli.
It seems pretty well done: when I added permission requests to the `bash` tool, the "Are you sure y/N" requests started appearing just like they were native to Emacs.
The prompt shown is
"Who's your daddy and what does he do?"
Is this a joke or tech? Is the author a dev or a clown?
This coding agent certainly couldn't give a fuck.
Anyway, even if you give your agent permission, there's no secure way to know whether what they're asking to is what they'll actually do, etc.
Pi supports permission popups, but doesn't use them by default. Their example extensions show how to do it (add an event listener for `tool_call` events; to block the call put `block: true` in its result).
> there's no secure way to know whether what they're asking to is what they'll actually do
What do you mean? `tool_call` event listeners are given the parameters of the tool call; so e.g. a call to the `bash` tool will show the exact command that will execute (unless we block it, of course).
After my max sub expired I decided to try Kimi on a more open harness, and it ended up being one of the worst (and eye opening experiences) I had with the agentic world so far.
It was completely alienating and so much 'not for me', that afterwards I went back and immediately renewed my claude sub.
Where did you get this perspective from?
> I thought pi and its tools were supposed to be minimal and extensible. So why is a subagent extension bundling six agents I never asked for that I can’t disable or remove?
Why do you think a random subagents extension is under the same philosophy as pi?
Your blog post says little about pi proper, it's essentially concerned with issues you had with the ecosystem of extensions, often made by random people who either do or do not get the philosophy? Why would that be up to pi to enforce?
Pi ships with docs that include extensions and the agent looks there for inspiration if you ask it to build a custom extension.
Looking at what others publish is useful!
Here's the problem with Claude Code: it acts like it's got security, but it's the equivalent of a "do not walk on grass" sign. There's no technical restrictions at play, and the agent can (maliciously or accidentally) bypass the "restrictions".
That's why Pi doesn't have restrictions by default. The logic is: no matter what agent you are using, you should be using it in a real sandbox (container, VM, whatever).
Within days people become used to just hitting accept and allowlisting pretty much everything. The agents write length scripts into shell scripts or test runners that themselves can be destructive but they immediately allowlisted.
edit: You're not making it sound easy at all. I don't have to build anything with the other agents.
Back to my original point: Claude Code gives you a false feeling of security, Pi gives you the accurate feeling of not having security.
In the meantime, the codex/cc defaults are better for me.
Yep. This is why I've been going "Hell, no!" and will probably keep doing so.
We know that a lack of control over their environment makes animals, including humans, depressed.
The software we use has so much of this lack of control. It's their way, their branding, their ads, their app. You're the guest on your own device.
It's no wonder everyone hates technology.
A world with software that is malleable, personal, and cheap - this could do a lot of good. Real ownership.
The nerds could always make a home with their linux desktop. Now everyone can. It'll change the equation.
I'm quite optimistic for this future.
Building it exactly to my design specs, giving it only the tool calls I need, owning all the data it stores about me for RAG, integrating it to the exact services/pipelines I care about... It's nothing short of invigorating to have this degree of control over something so powerful.
In a couple of days work, I have a discord bot that's about as useful as chatgpt, using open models, running on a VPS I manage, for less than $20/mo (including inference). And I have full control over what capabilities I add to it in the future. Truly wild.
Is this really that different to programming? (Maybe you haven't programmed before?)
> It's nothing short of invigorating to have this degree of control over something so powerful
I'm a SWE w/ >10 years, and you're right, this part has always been invigorating.
I suppose what's "new" here is the drastically reduced amount of cognitive energy I need build complex projects in my spare time. As someone who was originally drawn to software because of how much it lowered the barrier to entry of birthing an idea into existence (when compared to hardware), I am genuinely thrilled to see said barrier lowered so much further.
Sharing my own anecdotal experience:
My current day job is leading development of a React Native mobile app in Typescript with a backend PaaS, and the bulk of my working memory is filled up by information in that domain. Given this is currently what pays the bills, it's hard to justify devoting all that much of my brain deep-diving into other technologies or stacks merely for fun or to satisfy my curiosity.
But today, despite those limitations, I find myself having built a bespoke AI agent written from scratch in Go, using a janky beta AI Inference API with weird bugs and sub-par documentation, on a VPS sandbox with a custom Tmux & Neovim config I can "mosh" into from anywhere using finely-tuned Tailscale access rules.
I have enough experience and high-level knowledge that it's pretty easy for me to develop a clear idea of what exactly I want to build from a tooling/architecture standpoint, but prior to Claude, Codex, etc., the "how" of building it tended to be a big stumbling block. I'd excitedly start building, only to run into the random barriers of "my laptop has an ancient version of Go from the last project I abandoned" or "neovim is having trouble starting the lsp/linter/formatter" and eventually go "ugh, not worth it" and give up.
Frankly, as my career progressed and the increasingly complex problems at work left me with vanishingly less brain-space for passion projects, I was beginning to feel this crushing sense of apathy & borderline despair. I felt I'd never be able make good on my younger self's desire to bring these exciting ideas of mine into existence. I even got to the point where I convinced myself it was "my fault" because I lacked the metal to stomach the challenges of day-to-day software development.
Now I can just decide "Hmm.. I want an lightweight agent in a portable binary. Makes sense to use Go." or "this beta API offers super cheap inference, so it's worth dealing with some jank" and then let an LLM work out all the details and do all the troubleshooting for me. Feels like a complete 180 from where I was even just a year or two ago.
At the risk of sounding hyperbolic, I don't think it's overstating things to say that the advent of "agentic engineering" has saved my career.
Using Vultr for the VPS hosting, as well as their inference product which AFAIK is by far the cheapest option for hosting models of these class ($10/mo for 50M tokens, and $0.20/M tokens after that). They also offer Vector Storage as part of their inference subscription which makes it very convenient to get inference + durable memory & RAG w/ a single API key.
Their inference product is currently in beta, so not sure whether the price will stay this low for the long haul.
What other models do they offer? The web page is very light on details
Probelm is, to be able to do what you're describing, you still need the source code and the permission to modify it. So you will need to switch to the FOSS tools the nerds are using.
It means normies will finally see value in open source beyond just being free. They'll choose it over closed source alternatives.
This, too, makes a brighter future.
There is OSS you are not allowed to modify etc.
This timeline sucks, I don't want to live in a future where Anthropic and OpenAI are the arbiters of what we can and cannot do.
Strip away the ads, the data harvesting, add back the power features, and we'll be happy again. I'm more willing than ever to pay a one-time fee good software. I've started donating to all the free apps I use on a regular basis.
I don't want to own my own slop. That doesn't help me. Use your AI tools to build out the software if you want, but make sure it does a good job. Don't make me fiddle with indeterministic flavor-of-the-month AI gents.
It is true for me with Linux. I code for a living and I can't change anything because I can't even build most software -- the usual configure/make/make install runs into tons of compiler errors most of the time.
Loss of control is an issue. I'm curious if AI tools will change that though.
The Big Tech slop can only be fixed in one way, and actually it's really predictable and will work - we need to fix the laws so that they put the rights and flourishing of human beings first, not the rights and flourishing of Big Tech. We need to fix enforcement because there are so many times that these companies just break the law and they get convicted but they get off with a slap on the wrist. We need to legislate a dismantling of barriers to new entrants in the sectors they dominate. Competition for the consumer dollar is the only thing that can force them to be more honest. They need to see that their customers are leaving for something better, otherwise they'll never improve.
But our elected officials have crafted laws and an enforcement system which make 'something better' impossible (or at least highly uneconomical).
Parallel to this if open source projects can develop software which is easier for the user to change via a PR, they totally should. We can and should have the best of both worlds. We should have the big companies producing better "boxed" software. Plus we should have more flexibility to build, tweak and run whatever we want.
Regulation enforcement against the anti-market behaviors would bring a lot of good.
Putting too much power in any centralized authority - company or government - seems to lead to oppression and unhealthy culture.
Fair markets are the neatest trick we have. They put the freedom of choice in the hands of the individual and allow organic collaboration.
The framing should not be government vs company. But distributed vs centralized power. For both governance and commerce.
The entire world right now suffers from too much centralized power. That comes in the form of both corporate and government. Power tends to consolidate until the bureaucracy of the approach becomes too inefficient and collapses under its own weight. That process is painful, and it's not something I enjoy living through.
If you see through that lens, it has explaining power for the problems of both the EU countries and the US.
Yes, which is why this model of development is basically dead-in-the-water in terms of institutional adoption. No large firm or government is going to allow that.
Red Hat? I don't think they are involved in the moves to FOSS for government agencies, mostly because they're American, and the ones who are currently moving quickly (in the government world at least) are the ones who aren't American and what to get rid of their reliance on American infrastructure and software.
I haven't had a single need to visit the US, and I still have zero needs for it. If I need to read subway ads to understand how a company is connected to FOSS, I think I'll skip that and continue using and working with companies who make that clear up front :) Thanks for the offer though!
I build my own inspired by Beads, not quite as you're describing, but I store todo's in a SQLite database (beads used SQLite AND git hooks, I didn't want to be married to git), and I let them sync to and from GitHub Issues, so in theory I can fork a GitHub repo, and have my tool pull down issues from the original repo (havent tried it when its a fork, so that's a new task for the task pile).
https://github.com/Giancarlos/guardrails/issues
You can see me dogfeeding my tool to my tools codebase and having my issues on the github for anyone to see, you can see the closed ones. I do think we will see an increase in local dev tooling that is tried and tested by its own creators, which will yield better purpose driven tooling that is generic enough to be useful to others.
I used to use Beads for all my Claude Code projects, now I just use GuardRails because it has safety nets and works without git which is what I wanted.
I could have forked Beads, but the other thing is Beads is a behemoth of code, it was much easier to start from nothing but a very detailed spec and Claude Code ;)
Yet, the first impact on FOSS seems to be quite the opposite: maintainers complaining about PRs and vulnerability disclosures that turn out to be AI hallucinations, wasting their time. It seems to be so bad that now GitHub is offering the possibility of turning off pull requests for repositories. What you present here is an optimistic view, and I would be happy for it to be correct, but what we've seen so far unfortunately seems to point in a different direction.
With that said, we are all dealing with AI still convincingly writing code that doesn't work despite passing tests or introducing hard to find bugs. It will be some time until we iron that out fully for more reliable output I suspect.
Unfortunately we won't be able to stop humans thinking they are software engineers when they are not now that the abstraction language is the human language so guarding from spam will be more important than ever.
I use a lot of my own software. Most of it is strictly worse both in terms of features and bugs than more intentional, planned projects. The reason I do it is because each of those tools solve my specific pain points in ways that makes my life better.
A concrete example: I have a personal dashboard. It was written by Claude in its entirety. I've skimmed the code, but no more than that. I don't review individual changes. It works for me. It pulls in my calendar, my fitbit data, my TODO list, various custom reminders to work around my tendency to procrastinate, it surfaces data from my coding agents, it provides a nice interface for me to browse various documentation I keep to hand, and a lot more.
I could write a "proper" dashboard system with cleanly pluggable modules. If I were to write it manually I probably would because I'd want something I could easily dip in and out of working on. But when I've started doing stuff like that in the past I quickly put it aside because it cost more effort than I got out of it. The benefit it provides is low enough that even a team effort would be difficult to make pay off.
Now that equation has fundamentally changed. If there's something I don't like, I tell Claude, and a few minutes - or more - later, I reload the dashboard and 90% of the time it's improved.
I have no illusions that code is generic enough to be usable for others, and that's fine, because the cost of maintaining it in my time is so low that I have no need to share that burden with others.
I think this will change how a lot of software is written. A "dashboard toolkit" for example would still have value to my "project". But for my agent to pull in and use to put together my dashboard faster.
A lot of "finished products" will be a lot less valuable because it'll become easier to get exactly what you want by having your agent assemble what is out there, and write what isn't out there from scratch.
> you download a skill file that tells a coding agent how to add a feature
This is suggesting a my_feature.md would be a way of sharing and improving software in the future, which I think is mostly a bad thing.
But also, note that skills can carry scripts with them, so they are definitely also more than a my_feature.md.
Maintainers won’t have to deal with an endless stream of PRs. Now people will just clone your library the second it has traction and make it perfect for their specific use case.
Cherry pick the best features and build something perfect for them. They’ll be able to do things your product can’t, and individual users will probably find a better fit in these spinoffs than in the original app.
https://github.com/rbren/personal-ai-devbox
It's because you put 2by4's in place of the shocks, you absolute muppet. And then they either give them a massive bill to fix it properly or politely show them out.
Same will happen in self-modifying software. Some people are self-aware enough to know that "I made this, it's my problem to fix", some will complain to the maker of the harness they used and will be summarily shown the door.
It’s going to be very likely that once something is patched is to be considered as diverged and very hard to upgrade