I don’t think this scales. We recently have been doing “spec driven development” and we are committing the specs and prompts to our repo, alongside the generated code. At the beginning it seems fine: you wanna change something, you update the spec and ask the machine to regenerate the code. Easy. Over time, though, you have hundreds if not thousands if spec files in MD. It’s all English prose. There is duplication and subtle inconsistencies. It’s difficult to search for sections of a spec. Do you create a new file for this new requirement or update an existing one? What level of detail is enough here? Should I hint the machine about using the “saga” pattern or just let it know that we are dealing with non atomic transactions distributed across services? Etc. When a colleague opens a PR updating a spec, it’s hard to suggest objective changes (at least with code, you can demonstrate the presence of bugs… not so much with English prose. Sometimes I feel like a lawyer)

All in all, it seems as if maintenance of english prose is way worse than maintenance of actual code in big enough systems. You not only need to review the spec but also review the generated code. It’s painful

So I'm not sure why people going "chop, chop" and "nah make it more red and bigger" is a useful signal of much of anything.

No, the future is a complex "gate" that checks, weighs and measures everything before it gets committed --- a local (or remote) "CI" but... more granular and far more specific and turned to the needs of the project you work on.

The only artifacts outside of code that I don't explicitly end-date are user-story style requirements documents that I periodically revisit with the AI to make sure they're up to date.

One of the most annoying things I've seen AI do is accidentally pull in old requirements and start building off of them.

Pi.dev has a feature where you can export the session as a html file and look at it later. I foresee that potentially you could store this in the same Git repository and get the benefit of reviewing how a particular code change came about during a session with an agent.

I guess the next step would be having the coding agent save that session context automatically in a folder in the git repository rather than requiring a human to export it.

This startup also seems to be operating in a similar space to tangled.org - moving code repos into a decentralised hosting environment.

In the interest of not just being a hater and suggesting an alternative though: if you're implementing a feature (whether yourself or with the agent) have the agent write a spec for the feature and commit THAT. Now you have a nicely organized thing that AI's or people can consume which captures all the intent of the session log with much less noise.

One possible shape is something like unison-lang's CAS AST model:

https://www.unison-lang.org/docs/the-big-idea/

This model has some significant downsides for humans, but less so for automatons. It eliminates some major problems of software development like merge conflicts, dependency hell, etc.

Did they understand the coming issues (reviews), but just came up with a completely wrong hypothesis (session logs)? I mentioned it in another comment some time ago, I think the biggest issue in VCS software arises from the combination of two separate ones...

  - A (technical): Reviews are currently not part of the VCS

  - B (cultural): The amount of merged source code currently grants for higher authority/ownership of a code base than the review/verification of that code

Isn't this the idea behind Yegg's "Beads"?

Matt Pocock’s “grill-me” skill is a nice example of this idea: https://github.com/mattpocock/skills/tree/main/skills/produc...

Verbose slop is painful to review, and it's dangerous to accept unreviewed code from a stranger.

For a maintainer it's way easier to tell their own agent to reimplement the same idea. It's still slop, but done their way, under their supervision.

For popular projects agent-made pull requests become a DoS attack. I wouldn't be surprised if projects start refusing to accept unsolicited PRs and switch to "don't call us, we'll call you". You could have an agent scanning forks of your projects to find what bugs users are fixing and what features they're adding, and use it as a roadmap, without the pressure of accepting any particular commit as-is.

I'd also like to move away from a binary merged-not-merged divide. Projects may have a stable manually-reviewed core that should be protected from agents messing it up, while allowing the sloppy parts to churn however LLMs like it.

Ex-GitHub CEO launches a new developer platform for AI agents - https://news.ycombinator.com/item?id=46961345 - Feb 2026 (577 comments)

The engineering practices in general are lacking. Not tests nor assumptions validation ever, unless explicitly asked.

Wasn't there an article on HN that went by in the last few weeks about someone actually implementing this, and it just made things worse on every metric?

Pre-AI people periodically wanted version control to be tracking every keystroke and I, along with a lot of other people, feel like they never successfully articulated exactly what we're supposed to get out of that. Session history seems like the same thing. A prompt history, maybe. But I don't want every bit of an AI's musing any more than I want every last stray through that passes through a developer's head either, and for the same reason in both cases: A finite mind has room for only so much stuff.

It is not a viable strategy for a finite mind, be it human or AI, to just "stuff everything into it and expect improvement to result". The first thing that finite mind will need to do to get any value out of it is to extract it into some much, much smaller and less detail-rich summarized version. Which is pretty close to what we already have, except without needing to burn AI time on the process. We have spent decades honing techniques for reducing cognitive load. The AIs benefit from them too, and make them more important than ever, not obsoleted.

Sure, it isn't exactly what we have today. But I think this is a case of the exceptions looming too large in our mind, precisely because they are exceptions. Yes, I've had a handful of cases in my career where I've wondered what were they thinking, and not just as a criticism, but as an actual question. But it's rare, and in the end, not necessarily all that valuable compared to questions like "what is the code doing" and "what is passing through the code that gets this thing done to it". In the vast majority of cases, the code is already only and exactly what I need.

The fact we have this code artifact that is a gateway and a checkpoint through which "intention" does not pass is a positive good thing and is one of the subtle reasons that people miss that makes both large-scale human software development and the current trend of AI-based software development possible in the first place. The highly effective process of trimming down all of this stuff into an artifact that has an extremely-precisely specified function and doesn't need external support from humans or process or history is an amazingly wonderful thing. Larding down the codebase with vast, vast quantities of very fluffy data that is only quite rarely useful is a positive step backwards, not forwards.

An Entirely New Git Hosting Network

https://entire.io/blog/an-entirely-new-git-hosting-network

(https://news.ycombinator.com/item?id=48833019)

That’s the commit message. If something is not immediately clear from the title and the diff, you write it it in the commit description, like this:

https://cgit.freebsd.org/src/commit/?id=ed7e0ebfa20e7e798d2e...

If you can’t summarize your changes in a similar manner, that usually means you don’t understand the code and shouldn’t push it to other people.