This blog post is also accessible on Standard Reader.

I took a hike in the woods, and this is what it taught me about B2B SaaS.

Good winds!

I've decided to write a blog post, and it seems I've decided to publish it as well. Softwareing 2026: the main themes here are AI (surprise) and the AT protocol (a decentralized identity and data protocol). If you're here from outside the ATmosphere, I highly recommend you dive in the rabbit hole. It's a community buzzing louder than the frontiers of AI with a fraction of the population and feel-good vibes all around. The dream of the 90's is alive in Portland The ATmosphere.1

Anyways, I've been learning a lot lately. Outside of atproto, everything from databases to data-intensive system design, and crafting a transpiler2 in Rust/Zig/Odin/whatever I hop to next (Gleam??). This is my attempt to form some thoughts around the direction of code work, propagate some optimism, and make a badge sash of links to technologies I've been enjoying lately. I hope you enjoy this and your reading list gets at least one link longer :)

Speech software, when software is beer3

A phrase has echoed around the vibe-circles: "code is free". As a believer and mellow advocate of free software, this sounds great to me!4 Sure it's an exaggeration, or semantically more of an asymptotic thing, but I feel it! I'm just a small down-payment away from having an open model running on some solar powered compute building free software for free. Disregarding how inebriated that software may seem.

Agentic coding is a "great equalizer". With a quality model and harness, making a computer do a thing no longer requires hiring a team of six-figure salaries! When the cost of software goes to zero, I believe it can sustainably prioritize the freedoms of its users instead of recouping investments. When a great equalizer hits the playing field, it makes a lot of pieces fly - nobody was prepared for the eternal sloptember. We're on a Microsoft-subsidized platform for developers, and a world where code is free is gonna need a lot more than that.

's Vouch system felt discouraging at first, like it was going to prevent new developers from contributing to anything. But when it was integrated with the AT protocol it felt different. Built on atproto, a trust system can use backlinks, external activity, and standalone labeling services to appraise the reputation of an identity across all forms of media.5

But this is still just solving for the status-quo. We're in the big '26, we can do better! We don't have to treat everyone else's activity as a telegram. We can stop requiring a hand-written letter before graciously taking someone's work. We can design new ways of sharing code! Right?

Defining software

One of my favorite projects at ATmosphereConf 2026 was a tool for agent work called vit. Vit's mode of development is an open network of specifications rather than a handful of maintenance-intense forks. A repository maintained with vit is made of fragmented specifications (caps) and harness (skills). These primitives exist on an open network that can be easily indexed for discovery, so a "fork" requires no maintenance, and the "source" can pull in any changes it wants to. You'd generate the code just as you would compile the binary for some open source software. Clone a git repo and get someone else's code if you want, but the source is in the specs.

With inference still at a substantial cost, I expect this future to be quite a ways out.6 The concepts of spec-driven-development and skills are already widely spread in the agentic coding realm though, and they've been a great medium for people to quickly brain-dump their vision product-wise and architecture-wise. As development moves towards building software factories and loop engineering, I've found it useful to remember that each tool operates on the same two primitives: the input (prompt)7 and the output (code).

Common SDD builds the prompt: a model uses its expansive collection of the english language to congeal a heap of prolix verbosity in the direction of the user's intent, then a new model reinterprets that into an implementation. Agent-generated english specs have consistently been a lossy process for me, adding false requirements and obfuscating the goal. I've found this even adhering to something like the IETF or W3C's specification style; there will always be room for interpretation.

A spec should minimize interpretation, and be maximally enforceable by the computer. Interface contracts like atproto lexicon, or type systems generally, model the surface area of a program but not the volume of the program itself, and are usually the first changes I look at in code review. At some point we decided modeling data shapes and constraints was worth it for the DX.

Formal methods and semantic definitions can be used to model the behavior of the internal systems, but are much more complex than building a data model. In today's development workflows of rapid iteration and general intelligence they are showing to be a more worthy investment. Building with these tools still takes effort in specifying exactly what you want, but that's really the minimum the task boils down to.

I'm working on figuring out what a stronger layer over vit looks like, building off atproto hypermedia's AT-URIs. A capability still needs a human-readable description, but I think the meat is in the provable contracts it includes. I also think skills could offer a more adaptable triggering interface, and an interface to programmatically build context (replacing wasteful patterns like telling the agent to fetch a URL).

Beyond software

Putting my startup bro cap on now. At CascadiaJS 2026, gave a keynote about agentic experience.

UX gives the power to differentiate products from competitors
DX gives the power to differentiate platforms from competitors
AX gives the power to differentiate platforms, products, and digital experiences

I'd like to assert that AX is about differentiating protocols8. The protocol is what makes the AX of agent-tui (a CLI) better than piping bytes through stdin. It's your product serving MCP, a Terraform provider, a CLI, or a GraphQL API. It's the most accurate definition of an interface available to a digital entity that boils down to tokens in and out, and also implicitly it's how well your product interoperates with others.

If one is building a product and "scaling horizontally to attract more buyers", they are building a platform. Designing for infinite scale means defining a standard interface, a protocol. An agent (harness) is a platform itself, with its own set of interfaces, extensibility, and supported protocols. Therefore, building a good experience for agents means supporting good protocols.

Beyond software, we humans have invented protocols for making all sorts of things efficient. Property leases, insurance, street busking, grocery shopping... The agent experience—the experience for these ephemeral identities—is a universal customer acquisition story. How quickly can you onboard someone new to the industry to your business?

Software are like onions

As someone fairly new to professional software development, my experience with the AT protocol has been excellent onboarding to building web-scale resilient applications. HTTP and the browser standardized hypermedia distribution, and atproto brings web 2.0's user management, data storage, and event stream to the protocol level as well. The permissioned spaces alpha brings primitive access controls to the protocol, leaving things like RBAC and encryption for higher layers. It's also fun when projects layer on other protocols, like how Lexidraw uses Iroh.

To mention one more favorite-technologies-of-late, I've found Datastar to have an excellent model for frontend development. It treats the client as a materialized view in a distributed system9, separating actions from maintaining a live view of the client's state. I think this is how all websites should be built - compressed html from the server, resource state updated over an http SSE connection. If I want a thick local-first sync engine experience, I'd like to install the app, which I should then be able to use fully offline and reconnect as its own node in the distributed system.

It's easy to think of agentic engineering as endgame, to just use what the models know, and to think of these architectural arguments as silly. In my experience it's instead been an accelerant for good ideas10, and brings the conversation down to these important decisions. The tech stack I want to hear now is not your programming language or database choices, but what protocols you integrate. What contracts your architecture holds.

The future of software is a thousand vibe-coded applications. Nodes in all layers of a distributed system, using protocols to authenticate and transfer the data the user needs. I'm excited about the future of software and the internet, and gonna get back to my own little side-projects now. Hopefully I'll have more to share soon.


Words generated by a Human mind, and typed by hand.
☮ Will Garrison