AI has changed how we
build software

Most teams are shipping faster than ever. A capable engineer with the right tools can build in an afternoon what used to take a week. The execution layer is moving quickly. Everything around it isn't.

The way teams collaborate on code was designed for a world where writing software required years of training and a carefully configured local environment. Clone the repo. Install the dependencies. Learn Git. Get access. That process made sense once. It doesn't anymore.

Gatekeeping the work

Every product team has people who understand the product deeply. The product manager who knows exactly what the copy should say. The designer who spotted the layout bug. The support lead who's seen the same broken flow a hundred times. The CEO who wants to change one line.

None of them can do anything about it directly. They have to ask a developer.

Not because the change is technically complex. Because the tools were built for developers, by developers, and nobody has changed that assumption.

There's a spectrum to what happens in a codebase. At one end: infrastructure, architecture, the things where judgment and experience genuinely matter and mistakes are expensive. Developers belong there. At the other end: content, UI copy, configuration, small surface-level changes that don't require deep technical knowledge to get right.

Right now the whole codebase is optimised for one end of that spectrum. Everyone else is locked out entirely. That's what Picnic changes.

What we're building

The goal for phase one is simple: working in a codebase should feel like working in a Google Doc.

Zero local setup. No Git commands to memorise. Open a file, make a change, send it for review. A product manager, a designer, a support lead, anyone on the team should be able to do that on their own, without asking for help.

Central to how this works is the concept of a Picnic branch. Instead of prototyping an idea in Figma or some separate tool disconnected from the actual product, you spin up a Picnic branch and make your changes directly in the codebase. It's sandboxed, you can't break anything, there's no Git knowledge required, and it costs nothing to throw away. But because it lives in the real codebase, it has all the business logic and context that a Figma file never will. It might get handed to a developer to finish and merge. It might get discarded. Either way, you've explored the idea in the place where it actually has to work, and that changes the quality of the conversation entirely.

The complexity doesn't disappear. It moves to a layer where it belongs, away from the people who shouldn't have to deal with it.

Phase two is further out. A fully cloud-based engineering workbench where agents build, test, and iterate on software without any local environment at all. Not a layer on top of existing infrastructure. Something designed from scratch to be cloud-native, horizontally scalable, with careful abstractions built on top of the foundations that work.

That's what autonomous software development actually needs. The pieces exist. The right abstractions don't yet.

We're holding Picnic loosely. It might be the wrong abstraction and we're completely open to that. What we're less open to is not experimenting at all. The tooling and workflows we've inherited are being questioned right across the industry, and that questioning is overdue. Picnic is one answer. There will likely be others. We probably won't end up with one ubiquitous tool that solves this for everyone.

What does seem clear is that the current moment calls for more opinionated workflows, not fewer. A lot of what's emerging right now is deliberately unopinionated, which makes sense for experimentation. But for junior developers and non-technical contributors, an unopinionated workflow isn't freedom. It's just friction of a different kind. Eventually these workflows need to calcify into something more structured. Something with a point of view about how work should get done.

That's what Picnic is trying to be. Opinionated enough to give people guardrails. You can't accidentally break production, you can't bypass a review, the path forward is always clear. But without narrowing what's actually possible. The capability is broad. The safeguards just make sure it stays safe to use it.

Why now

AI made this possible. It also made it urgent.

As more of the execution layer gets automated, the question of who has meaningful access to a codebase and how much friction sits between an idea and a shipped change becomes a bigger factor, not a smaller one.

The teams that figure this out will move faster. The ones that don't will feel it.