In our Hobie Platform, the SDLC controls that used to run on a sample now run on every change, and the stage that dominated the timeline has collapsed. Three signatures are still held by people, deliberately.

The controls were priced correctly

The delivery process most enterprises run was designed around one assumption, and it held for twenty years: writing code is the expensive part.

Everything follows from that. Work moves through phases in sequence, each phase belongs to a different group, and between each group sits a handoff: a requirements document to design review, a design to an architecture board, code to a pull request queue, a release to a change advisory meeting.

Those handoffs look like overhead, but they earned their keep. When implementation took six weeks, a two-day wait for architecture review cost you seven percent of the timeline and caught mistakes that would have cost far more.

The controls also assume a person performs every step, and that does not scale by adding volume, so in practice it gets rationed. Teams review what looks risky, sample the rest, and accept that some things get through. That compromise was invisible while the input rate stayed low.

What agents change, and what they leave alone

Agents help in every one of those phases, and in every phase they help with the same half of it. Drafting a requirement, reading a diff, writing a test, deriving a changelog: all of that compresses, and hard. What does not compress is the waiting. Planning waits on a meeting, review waits on a reader, the release board still meets on Thursdays, and a composed test stack takes as long to come up as it ever did.

So three things happen at once, and they compound. The review queue backs up, because the input rate went up by an order of magnitude and the number of reviewers did not. The sampling compromise breaks: reviewing the risky-looking twenty percent was defensible at ten pull requests a week, and at a hundred and fifty a week it means most changes reach production having been read by nobody. Governance costs rise, because every exception still routes through a committee that meets weekly and there are now far more exceptions to route.

The tempting response is to loosen something: approve faster, sample less, move security to a post-merge audit, let the agent that wrote the code confirm the code is fine. Each buys throughput by giving up assurance.

Three commitments

We took the opposite position.

Agent throughput is only worth having if the assurance bar stays exactly where it was.

Every control runs on every change. No sampling. Controls that were rationed because they consumed human attention now execute on every pull request, because they no longer consume it.

Verification is independent of generation. Ask the agent that wrote the feature whether it is good and it will say yes, without lying. Its context holds every rationalisation for why the code is correct, shortcuts included. So review is a separate role, run by agents that carry no memory of writing the change.

Accountability stays with named people. Three signatures at three points, named below. We have no plan to automate any of them, and the reason has nothing to do with how good the models get.

Holding those three lines means the controls become code, living somewhere the application team cannot edit them.

The same six stages, run differently

In plan, agents draft requirements and acceptance criteria as versioned artefacts in the repo. Issue quality is linted, and a person accepts the backlog before anything downstream starts. In design, decisions are recorded as versioned constraints, and conformance is checked on every pull request. In build, agents write code and tests together against standards they cannot switch off, with quality, coverage, secret and vulnerability scanning on every push. In review, five reviewer roles read every diff against those recorded standards. Findings above a severity threshold fail the build, and a person still approves the design. In test, tests run continuously alongside the code plus end-to-end against a deployed stack, and nothing reaches that stack without passing every prior gate. In operate, agents watch deployments, triage runtime errors and track delivery metrics, and findings return to the backlog.

Every stage moves faster, and every stage gains a check harder to skip than the one it replaced. The workflow runs on every change regardless of how much work is already in the queue.

What stays human

Three signatures, at three points in the flow, and none of them is on the table for automation.

Signature one, at plan: the product owner accepts the backlog. An agent can write acceptance criteria that are internally consistent, well-formed and completely wrong about what the business wanted. A linter can check the consistency. Intent has to be checked by the person who wanted the thing.

Signature two, at review: the code reviewer approves the design. The automated controls have already hunted the diff for defects, more thoroughly than a person manages at eleven at night. What the reviewer decides is whether this is the right change, whether it matches the decisions we recorded, and whether we would be content maintaining it.

Signature three, at security: the security reviewer signs off. Scanning finds known vulnerability classes in a diff. It does not reason about what an attacker would do with the feature you just shipped, and knows nothing of your threat model beyond what someone wrote down.

Automated review measures conformance to a recorded standard. The human decides whether the standard still applies to this case. Everything from here is the machinery those signatures sit on top of. The argument for why they stay in human hands comes after it.

Every control is a named rule

Most write-ups of this list a set of tools. We did too, and it aged badly: every vendor swap invalidated the documentation, and any two repositories could pass "the coverage gate" against different definitions of coverage. So the controls are named as policy rules instead, stated once, independent of whatever executes them. Each rule is either operative, forbidding or requiring something, or definitional, fixing what a term means so the same metric cannot be reported from different arithmetic.

Fourteen of them, in four groups. On merge: an approving review on every merged pull request, green CI on the head run, protected branches reachable only through a reviewed pull request, and high or critical findings fixed or justified first. On deploy: nothing to production on a red commit, nothing to production with an open critical finding or dependency alert, semantic-versioning order with no version reused, and no error group resolved without a linked fix release. On findings: no dismissal without explicit human confirmation, active secret alerts rotated without delay, and a remediation deadline that tightens with severity. On compatibility: additive schema changes with no column renamed or dropped in place, no breaking API change without a version bump and deprecation window, and dependencies pinned exactly with committed lockfiles and digest-pinned images.

Each rule is centrally owned, called identically by every repository, and quotable by name afterwards. The vendor behind it can change without any of that changing. One rule protects the rest: never auto-dismiss a finding is what stops the pipeline optimising itself into uselessness, because an agent that can close its own findings will eventually close the inconvenient ones.

Three layers of defence

A rule says what has to be true, without saying who makes it true. Every one of the fourteen is applied three times over, at three distances from the mistake. The first layer is the generator, writing to the standard so most violations never exist. The second is the reviewer, an independent role raising findings against that same standard. The third is the machine gate, the workflow that fails the build, and the only one of the three that can stop a change. Most people picture only the last, which is also the most expensive place to find out.

All three read the same document. Every agent that writes production code carries eight engineering standards in its own instructions: internationalisation, accessibility at WCAG 2.2 AA, observability with correlation IDs and OpenTelemetry spans, secure-by-default coding, resilience through timeouts and idempotency keys, twelve-factor config and secrets, backward compatibility for API and schema, and supply-chain pinning. They run unconditionally. Only the WCAG level and the observability sink are tuned per project. A single-locale product is still built internationalisation-ready, because retrofitting costs more than doing it once.

The interesting edge is between the first layer and the third. The instruction given to the agent and the checklist used against it come from one document, so when they drift, the drift shows up in the document itself, where it can be fixed.

Two cohorts, and the boundary between them

Up to here the agents have been abstractions. In practice they are a fixed roster of twenty-two, and its shape is what turns independent verification from an intention into something a reader can check.

The dev team cohort is sixteen roles that build the software (discovery, design, build, quality and enablement), working in the codebase with code tools. The process cohort is seven roles that observe and operate the pipeline through its API: delivery metrics, release manager, backlog triage, CI health, incident triage, code review and security. Security is generated into both, because reviewing a diff and triaging a scanner finding are different jobs that share a vocabulary.

The absent edges are the mechanism. An agent cannot mark its own work as passing, because the agent that writes code has no route to the pipeline and the agent that reads the pipeline has no route to the code. Independence here is enforced by which tools each cohort is given, and a tool that was never granted cannot be argued into existence.

Why the human gates stay

That is the machinery. Now the case for keeping those three signatures in human hands, starting with a boundary that is easy to misread. One agent does hold a gate. An orchestrator routes work between roles and signs off phase transitions, but only against exit criteria stated in advance, and it is forbidden from advancing a phase whose criteria are unmet. It can confirm that the tests ran and the reviews exist. Deciding whether that was enough belongs to a person.

There is a tempting argument that the gates are temporary, that they exist because models are not good enough yet and each falls as capability improves. That misreads what they are for. They mark the points where a named person is accountable, and accountability does not transfer to a system that cannot be held to it. When a release causes an incident, the postmortem asks who decided, and "the orchestrator routed it" is not an answer a regulator will accept.

The gates do something less obvious as well. They are where the humans stay fluent. A team that has not read a diff in eight months cannot meaningfully approve one.

— Navin

Hello World — I'm excited to share the launch of Hang Ten (hangtensystem.com), a new endeavor to help enterprises thrive in the age of AI.

AI is upon us all like a massive new wave. And I learned a long time ago that when there are big waves around, it is time to surf. Not just to surf, but to hang ten — to master the wave so well that you can walk all the way to the front of the board and hang your ten toes off the front.

Hang Ten is already helping some of the world's biggest and most important enterprises — like Fresenius, Siemens Energy and others — hang ten on the biggest wave of our lifetimes. Our dream is to help enterprises not just transform with AI, but use it as a force to do what no one could do before.

We're backed by a remarkable group. Mayfield leads our round; Navin Chaddha and I were students together at Stanford and always looked for an excuse to work together. They are joined by Aramco Ventures, the strategic venturing arm of Saudi Aramco, one of the world's largest companies and a key leader in energy and infrastructure, as well as some of Silicon Valley's best-known angels. And I'm privileged that Jerry Yang — also a friend since Stanford — serves on our board. Building Hang Ten with me is the core team I've worked alongside for years: Navin Budhiraja, Sanjay Rajagopalan, Tao Liu, Frank Yu, Pradeep Panicker, Yusuf Safdari and ten other big wave surfers.

Over time I'll share more about Hang Ten and our work. For now I'll say only this: I have seen, firsthand, the dramatic things AI delivers for the people and teams who somehow just know what to do with it — I have watched them, and myself, reach in minutes what could take teams years of toil. And I have seen the far greater number who get none of it, and who often end up causing harm instead. In that gap lies the biggest opportunity of our time.

It is time to ride this wave. If you're a surfrider — someone who lights up at the chance to help businesses solve the hardest problems they face — come build with us.

— Vishal

← Back to home