Engineering as a Service

Building is easier than it's ever been. Deciding what to build has never been more important. August engineers no longer build the product. They now control how the product gets built—who can build it, how fast, how reliably—and that's a harder, more leveraged problem. 

The Great Shift in Engineering

The best engineers have traditionally gravitated toward product development because it was the most expensive bottleneck in the company. There was a big gap between knowing what to build and actually building it. The technical skill required here was an engineer's core value proposition. 

That gap is collapsing and the engineer value proposition is changing. 

We know this because we spent the last few months doing what everyone's doing: arming engineers with teams of agents, giving those agents structure, enabling them to verify their outputs. We adopted every tool we could find. Disloyalty was policy. Cursor, Claude Code, Ralph Loops, OpenClaw, we built scaffolding on the frontier of whatever actually worked.

Our engineers were becoming as productive as we could make them, but the work had changed. Most of their day was now spent translating requests into prompts, monitoring agents, and merging PRs. The engineering skill was in the tooling; the day-to-day execution was increasingly mechanical. We started asking ourselves why an engineer needed to be in that loop at all.

We are 25% engineers and 75% go-to-market. Our engineers have optimized themselves 10x, 20x, 100x. But if we can make the rest of the team even a third as effective at product development, they outproduce the engineering team. All they need is the right tool.

Augustus

We set out to create an internal product any employee could use to reliably make changes to the August platform, software that functioned as EaaS. The result was Augustus, a Slack bot that any employee could message to do engineering work. Sales could spin up preview branches from a description. CS could push fixes from a conversation.

To build Augustus, we had to figure out what our engineers contribute beyond writing code. So, we quickly built a v0 and directed our engineers to develop exclusively through Augustus. 

We became way slower. “It can't adjust when it makes mistakes.” “It kind of works, but that's not how I would do it.”

v1 came with several improvements to our agent harness, increasing the rate of one-shots to almost 100% with an engineer prompting it. Then came the next order of issues. “I have to tell it so much.” “It doesn't know the client.”

We were frustrated, but we focused on distilling a problem statement from every frustration. We realized the hard bits were sustained progress on ambiguous tasks, deep product knowledge accumulated over months, and the ability to fold in business context and customer feedback on the fly. 

The two essentials of the product became clear:

• The required context to translate any request into the appropriate engineering task. 

• An agent harness that can consistently and accurately complete most engineering tasks with more or less one prompt.

By v2, we had a good handle on the harness, but it still lacked the right context. Without it, the agent was building in the dark.

Engineering Context

Without the right context, agents were fast and confident and often completely wrong. Our team knew the undocumented quirks of Microsoft's Office.js APIs, how paragraph ID behavior can vary between versions of Word—Augustus didn't. Microsoft's own documentation doesn't mention this. 

This kind of knowledge is born from experience, and it lives everywhere: Slack, emails, meetings, 1am crashouts. We needed to get it all into one place.

On the product side, we decided the best solution would be to carefully curate one source of truth with clear documentation of every current feature as well as all feature development plans. It started out as a mess of unstructured data, and Augustus continuously got lost. Major mistakes were made due to the lack of attention to detail. 

Eventually, we figured out a hierarchical structure that the agent could understand and reliably navigate to understand the product. Then, we applied those learnings to build the business context, creating separate markdown files for each of our clients with must-know information. We developed an agent to enrich each file with the last month of internal slack messages, email threads, and meeting notes about that client.

The hardest part was ensuring the repository was continuously kept up to date. We decided to build our own internal context management app that integrated with Slack, Gmail, Teams, and Notion. It wasn't enough. It still felt like Augustus didn't understand the company the way our engineers did and it felt like a chore to manually force-feed information at every juncture. 

So, we decided to take it one step further. Our company is built on crucial water cooler conversations, and every bit of information matters. We started a company-wide mandate to record every spoken word whether internal or external, online or in person. DJI mics for everyone. Everything was transcribed and stored in Notion. Every employee had our context management app configured to extract information from their respective accounts and augment our company knowledge repo accordingly.

The Harness

As for the agent harness side, we built ours on top of OpenCode. Each coding agent gets its own fully isolated local environment spun up by a single bootstrap script. When a ticket is picked up, the script creates git worktrees, derives a unique instance ID from the branch name, and uses that ID to namespace logs, URLs, processes, and browser sessions. Dependencies are symlinked or installed automatically, and services are launched through Vercel's Portless, which assigns unique subdomains per instance. This means any number of agents can run in parallel on different tickets without any conflicts. A JSON registry tracks every active instance so Augustus can always check the status of all running environments at a glance.

For observability, a Vector sidecar launches alongside each instance, tailing the backend logs and shipping every line to Mezmo with metadata tags for the instance ID, service name, and environment. This per-instance tagging is what makes parallel agents manageable, as you can filter Mezmo to see exactly one agent's logs without noise from the others. For our NextJS repo, we use Axiom's APL language against environment-scoped datasets, letting agents programmatically search for errors or trace requests through the system. 

Much of this was taken from existing literature, but pushing further led to new bottlenecks. On countless occasions, the logs looked perfect but missed important quirks. No one was able to trust the code until we tested the platform ourselves to confirm that everything worked. Everyone's review process was painfully slow. 

Browser verification was clearly non-negotiable for Augustus. We first tried playwright to disappointing results, then we found the perfect solution in Vercel's agent-browser, built for our exact use case. Now, the agent automatically starts a headless browser session and verifies every change through the UI before a PR is created. The agent works in an observe-act loop: it snapshots the page's accessibility tree, interacts using stable element references, and captures screenshots/videos as evidence. Once verification passes and logs are clean, the screenshots and videos are attached to the Linear ticket, pre-commit hooks run, and a PR is opened. A teardown script then reverses everything: killing processes, removing logs, closing the browser, and cleaning up worktrees.

To confirm these changes and enforce our coding standards, an independent PR review agent runs over the code with instructions to verify that the changes were successful and the code is up to par.

At this point, any employee can just check the ticket to confirm the photos/videos match expectations and then merge. A few weeks ago, all PRs were sent to the engineering team for review and 80% required more work. With our engineers spending most of their time solely on Augustus, however, this quickly changed. Today, engineers only review code for 20% of tasks and only 10% require further changes. 

With engineers focused on solving product development for everyone, two things happen: the whole company contributes more to product, and engineering attention compounds into exponential organizational productivity.

Post-Engineering

Last week, one of our sales representatives messaged Augustus to urgently add a new feature in a prospect's custom demo environment. Thirty minutes later, the changes were made, and a demo video was sent back to her. She reviewed the video, confirmed it matched what she needed, and demoed the polished feature to the prospect. No engineer was involved at any point.

This is the new normal at August.

We don't know what an engineering team looks like in six months. The ground is moving fast enough that half of what we've described here might be obsolete by then. 

But Augustus is shipping production code, and the engineers who built it are already working on higher-leverage problems. We wrote this because we think every engineering team is going to face the same question soon: what do you do with your engineers once the code writes itself? This is where we've started.