Enterprise technology leaders have heard two competing claims this year. One says AI can modernize core systems in months. The other says AI-written code cannot be trusted near the systems that run the business.

Both are partly right. Speed and safety are not a trade-off that has to be accepted. But achieving both on long-running systems requires a different first step than most modernization plans assume.

Our CTO, Navin Budhiraja, recently described how we run an AI-native SDLC, in which every control runs on every change and named people sign off at key points. This post extends that view to existing systems. It draws on recent industry research, the leading delivery frameworks and my own experiments on publicly available codebases, and it addresses one question: what changes when the starting point is code that has been in production for years, or even decades?

Adoption is near-universal. Results are not.

Published estimates of AI's productivity impact vary widely, and the variation itself is the most instructive finding.

The Faros data is the most telling. Developers completed more work and merged nearly twice as many pull requests, yet the organization delivered no faster. The additional output accumulated where AI does not help: review queues, approval meetings and release boards.

DORA's research explains the spread. AI acts as an amplifier: in a mature engineering environment it accelerates delivery, and in a fragile one it accelerates the fragility.

The gain came from the environment, not the model

One benchmark result illustrates the point. On a widely used test of real-world bug fixing, AI systems resolved about 2% of problems in late 2023. By April 2026, the best systems resolved about 78%.

Over the same period, models answering in a single pass plateaued near 20%. The gain came from the system built around the model: an agent that reads the files, runs the tests, observes failures and iterates.

The implication for technology leaders is direct. A lower-cost model in a well-engineered environment can outperform a frontier model in a poor one. The environment, not the model, is the primary investment.

The bottleneck has also moved. Writing code was once the expensive middle of delivery. Agents have compressed it sharply, but they have not compressed deciding what to build or verifying what was built. These are organizational constraints rather than technical ones, and they now set the pace.

The real barrier is verifiability, not age

I expected earlier-generation languages and complex architecture to be the main obstacles for an AI agent in the codebases I experimented on. They weren't.

The main obstacle was the absence of any way for the agent to confirm that a change was correct. Several patterns recurred:

• Test commands that report success without executing a single test. A pipeline built on them would report green indefinitely.
• Significant portions of code excluded from the build, making it impossible to tell what is still in use.
• Builds that succeed only on one specific machine, with dependencies pointing to locations that no longer exist.
• Multi-year modernization efforts that moved substantial code to modern platforms while adding few or no tests. In some cases, test coverage declined.

The last pattern is the most significant. These efforts delivered real value, separating business logic and removing platform dependencies, yet the systems emerged no more verifiable than before.

Modernization doesn't produce verifiability as a byproduct. It has to be an explicit goal.

The most useful measure of how hard a system will be to modernize is therefore not its age, but whether an agent can verify its work against it. By that measure, some relatively recent code is just as challenging, and it is worth assessing the whole application portfolio on that basis.

Verification comes before acceleration

Organizations typically adopt AI in stages. An engineer first works with a single agent and reviews all of its output. Next, several agents work in parallel on separate tasks. Over time, as automated checks prove reliable, agents take on recurring, well-defined work, with people supervising the process rather than every line.

Each stage beyond the first depends on an automated way to check the work: tests, a reliable build and an end-to-end run against a real environment. Without it, every change requires human review, and a codebase remains at a single supervised agent regardless of the tooling available.

This is where Navin's post and this one connect. Our delivery model applies layered defenses and a set of named, centrally owned rules to every change. Those controls need something to run against, and many long-running systems do not yet provide it.

For these systems, the verification loop is not a stage in the process. It is the precondition for the process. Building it is the first deliverable, not preparation for the real work.

Migration also changes the nature of intent. In new development, intent is authored: a team decides what the software should do and checks that it does so. In migration, intent must be recovered from the code, and the question is more demanding. Does the new system behave exactly as the original did, including behaviors nobody intended but downstream processes now depend on?

Recovered intent is not a specification. It is a set of hypotheses with confidence levels and open questions, and it requires review by domain experts. The before-and-after check turns those hypotheses into evidence. This matters most in real-time and device-facing systems, where failures are often silent: output continues, plausibly, with something missing.

"Migration" is five different jobs

"Migration" can describe five quite different undertakings. The role of AI differs in each, as does the evidence that the work succeeded.

Application portfolios rarely fit a single pattern. Triage, assigning each application its pattern before work begins, converts an application count into a set of economic profiles. That is the basis of a credible plan.

A further finding: the most significant blockers are often not architectural. In the codebases I examined, what prevented operation on modern infrastructure was mundane. Builds could not be reproduced, applications emitted no health signals for an orchestrator to monitor, and release packages were assembled from files that could not be traced to source.

None of these is resolved by decomposing a system into microservices. In one case, the system was already distributed, with clean plugin boundaries and its own high-speed transport between instances; what it lacked was packaging and operational tooling. When a microservices rewrite is proposed as the path to modernization, it is worth asking whether the real constraints are build reproducibility, observability and supply chain. That work rarely appears in a plan framed as "break it into services."

The economics: what compounds, and how to know early

Headline comparisons, such as a large team over years versus a small team over months, are persuasive but do not decompose. If a program overruns, they cannot show which component moved. Three principles make the economics manageable:

• Environments drive the timeline, not application count. Investment in access, tooling and checks pays off across every application in the same environment, and must be repeated in a new one. Ten applications in one environment can cost less than three spread across three.
• The second application should cost substantially less than the first. This happens only if reusable assets, such as discovery methods, migration playbooks and check patterns, are captured deliberately during the first. Nothing compounds by accident.
• Cost per migrated application should be measured at a held check pass rate. That is, cost per application while before-and-after checks continue to pass at the same rate. Cost alone can be lowered by reducing verification, and in migration those failures are rarely visible.

Discovery cost is a reliable early indicator. By the fourth or fifth application, it should be materially lower than for the first; if not, reuse is not working, and that becomes visible months before the budget shows it. Rework is the second indicator: if it rises while cost falls, quality is being traded away.

Proving a human was in the loop

"Human in the loop" is a common commitment. Auditors and regulators increasingly ask for proof.

Navin described the human sign-offs in our process, where named individuals accept what gets built, approve the design and clear security. The specific gates vary with the work; the principle does not. Accountability remains with people, because after an incident, "the system routed it" is not an acceptable answer.

The more subtle requirement is making those gates provable. Consider two statements:

• "We have a policy that a human reviews every change." That's a claim about behavior.
• "The system cannot produce a merge without a recorded approval." That's a control.

A person's diligence cannot be audited. A system that refuses to proceed without an approval record, and logs every blocked attempt, can be. In a migration, where an error may surface months later in a system that runs a plant, a payment network or a supply chain, that evidence is what allows speed without added risk.

How we do this at Hang Ten

Our Hobie Platform applies one assurance standard to everything we deliver. Much of our work is new development, where it lets customers ship quickly without relaxing any control. The same platform and controls apply when we modernize systems that have served the business for decades. Those engagements add one prerequisite: a way for the system to check its own work.

A typical modernization engagement proceeds in five steps:

1. Triage the portfolio, sorting each application into its migration pattern and economic profile.
2. Recover intent from the code, with the customer's domain experts confirming what the system really does.
3. Build the before-and-after checks, so every change can be verified automatically.
4. Migrate in phases, under the same controls and human sign-offs as new development.
5. Capture what we learn as reusable assets, so each application costs less than the one before.

For leaders weighing whether AI can accelerate modernization without adding risk, three questions are a useful starting point:

• Which systems in the portfolio can check their own work today, and which cannot?
• How many distinct environments, rather than applications, does the portfolio span?
• When an auditor asks who approved a change, can the system answer on its own?

If these questions resonate, we would welcome a conversation. Speed and safety are not a trade-off. They need to be built in the right order.

Sources

• Budhiraja, N. An AI-native SDLC that raises the assurance bar while shortening the cycle. Hang Ten, Aug 2026
• Claxton, L. The AI-Native SDLC Playbook. Anthropic, Aug 2026
• Cherny, B. Steps of AI Adoption. Jul 2026
• Medisetty, U.K. Running a Software Factory Efficiently at Uber Scale. Uber Engineering, Aug 2026
• Kordick, J. The Realities of Application Modernization with Agentic AI. Microsoft, Jan 2026
• Agentic AI in the SDLC. arXiv:2604.26275
• Peng et al. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590
• McKinsey & Company. Unleashing developer productivity with generative AI. 2023
• METR. 2025 developer productivity study, and Changing our Developer Productivity Experiment Design, Feb 2026
• DORA. 2025 State of AI-assisted Software Development
• Faros AI. The AI Productivity Paradox

— Abhinav

LLM agents hallucinate by nature, and checking them with a frontier model is slow and expensive. A decision model provides a cheaper option: in a fraction of a second it can check whether an answer is grounded, or settle easy cases before an LLM is called. We tested both uses on two agents we build for enterprise customers: an analytics agent and a coding agent.

TL;DR — two case studies

Analytics: a decision model as a query-plan guardrail

* Hallucination rate: how often a user gets an answer that doesn't match the question or isn't supported by the semantic model. Declines and withheld plans don't count.

Coding: a decision model as a test-dispute router

† A positive is a faulty test that should be retired; a negative is a good test that should be kept. F1 balances catching faulty tests against rejecting good ones.

Conclusions:

• Decision model lifts a non-frontier model to frontier level.
• Hybrid system keeps reasoning LLM accuracy at a fraction of the cost and time.

Decision models and enterprise benchmarks

Method. The decision model in both studies is TypeSafe's jev-1.13.0². Our agents are model-agnostic: switching between Claude Opus 5.5 and the open-weights Qwen3.8 27B.

Public benchmarks test clean, well-posed tasks. Enterprise agents fail on the customer's own data, vocabulary and workflows, so we build our benchmarks around customer use cases:

• A real enterprise schema. The analytics warehouse is modeled on a major bank's, with mock column names and values to protect confidentiality.
• Production workflow on public data. The coding tasks are public NL2Repo-Bench¹, but the workflow is the process we use when implementing solutions in customer environments.

Case study 1: query-plan guardrail (analytics)

The agent answers business questions over the bank-modeled warehouse, through a governed semantic model of revenue, costs, accounts, products, customers, etc. The LLM never writes SQL but turns the question into a small JSON query plan, and a deterministic compiler turns the plan into SQL. Therefore, a wrong answer almost always comes from a wrong plan.

Question: "Total fee revenue from Platinum Status customers in June 2025"

{
  "metrics": ["revenue"],
  "filters": [{"field": "customer.platinum_status", "op": "=", "value": "1"}],
  "time_dimensions": [{"field": "pnl.month_end_date", "date_range": ["2025-06-01", "2025-06-30"]}]
}

Dataset and setups. 62 questions, each run three times: 35 answerable and 27 that should be declined. Two planners, Claude Opus 5.5 and Qwen3.8 27B, get the same prompt, which tells them to return cannot_answer when they can't ground a request. We run each planner alone and with the decision-model guardrail, and Qwen with an Opus 5.5 LLM judge for comparison.

What counts as a hallucination. A plan hallucinates when any part of it isn't backed by the semantic model or the data: usually a filter value the data doesn't hold, or a user's term mapped to the wrong field. Misreading the question also counts, though neither model did. Hallucination rate is the share of the 186 outputs where a hallucinated plan reached the SQL compiler.

Result 1: both planners hallucinate, the frontier model included

An unanswerable output counts as hallucinated when the planner answers instead of declining. On answerable questions the models are close; Opus does better overall as it declined 15 more unanswerable requests.

Result 2: a decision model in front of the answer

The guardrail asks one question per part of the plan in a single call. A plan is withheld if any part scores below 0.6. The LLM judge got the same context and answered true or false.

The decision model caught every invalid filter value on both planners and cut Opus's rate to 2.7%. The results held in every run, and no setup withheld a correct plan.

Takeaway: checked by a decision model, a 27B open model hallucinates six times less than the frontier model alone. An Opus 5.5 judge does slightly better (2.7% vs 4.3%), but takes 12.0 s and about 26k LLM tokens per answer, against 0.28 s and none.

Case study 2: test-dispute adjudicator (coding)

When we build solutions for enterprise customers, the code must meet written requirements that has been signed off. Our SDLC agents turn those requirements into tests before code generation. The tester freezes its tests: the implementer must pass them and can't edit them. When a frozen test keeps failing, an adjudicator either upholds the test (the spec backs it, so the code must change) or rejects it (the spec contradicts it or is silent, or test is faulty; the test is retired). A wrong call on a test therefore is costly, sending the implementer after an impossible target; meanwhile, rejecting a good test drops a requirement. To measure this without exposing customer code, we run the same workflow on NL2Repo-Bench¹.

Dataset. From about 180 disputed tests in our runs, we kept 91 from 28 libraries (34 good, 57 faulty). We used 23 for validation, to pick thresholds by F1, and held out 68 for evaluation.

Setups. We have three different setups that receive the same context and questions.

• LLM only: Opus 5.5 with our pipeline's adjudicator prompt.
• Decision model only: one uphold-or-reject question, with a probability for each.
• Opus 5.5 + decision model: the decision model answers first and routes the dispute.

Results

Decision model by itself is unreliable: it judges 60.3% of disputes correctly and finds only 41.9% of faulty tests. However, pairing with Opus, the pair lands one verdict behind Opus alone (91.2% vs 92.6%) with the same precision, while making 47% fewer LLM calls and taking 43% less time.

Where the decision model is reliable

The decision model's score separates good from faulty tests only at the extremes while the faulty tests in the middle band need multi-step reasoning by LLM to catch:

Takeaway: use the decision model's confidence as the routing signal. Let it decide only where its scores are reliable, and send everything in between to a reasoning LLM.

Conclusion

Decision models make fast, reliable calls on simple, checkable cases, while LLMs handle difficult cases through multi-step reasoning. Together, a non-frontier model performs at frontier level, at a fraction of the cost and time.

A decision model doesn't replace the LLM: on its own it judged only 60% of test disputes correctly. Its strength is knowing which cases are easy, and leaving the rest to a model that can reason. That changes how enterprise agents can be built. Reliability no longer has to come from the largest frontier model: a decision model filters out ungrounded answers, and a reasoning LLM does the rest. Because our agents are model-agnostic, customers can choose the LLM and decision model that fit their cost, latency and deployment needs without giving up reliability.

References

¹ J. Ding, S. Long, C. Pu, et al. NL2Repo-Bench: Towards Long-Horizon Repository Generation Evaluation of Coding Agents. arXiv:2512.12730, 2025.
² TypeSafe. Documentation: System One, choice questions, label probabilities.

— Ray

Typing was never really the bottleneck, but it used to fill the day. Now AI coding agents do most of the typing, and what's left is still deciding what to build, saying it precisely, checking that what came back is actually right, and steering the system so tomorrow's output is better than today's.

Here is what that looks like across an ordinary day. But first, what the day used to look like.

Before: the day I used to have

Not long ago, a feature could take me most of a week, and most of that week went to writing code, tests, documentation.

The morning started with standup, then a slow climb back into yesterday's code. Before I could change anything, I had to find where the change belonged. This meant reading through modules, tracing call paths, searching for the function someone renamed last quarter, running into existing bugs, etc. Then came the inner loop, write a few lines, run the tests, read the stack trace, search the docs or somewhere for the error, and try again. Tests and documentation came last.

Review was a queue. I'd open a pull request and wait for a couple of hours and sometimes for over a day for teammates to review it, while they waited on me to review theirs. Many of the comments were about naming, syntax, formatting and missed edge cases. By the time a feature got merged, I'd switched context several times already.

The bottleneck was my own hands and my own attention, one engineer, one task, one branch at a time.

Morning: writing the spec, not the code

Now, my longest focus block of the day now goes to writing plain English. I write the issue the way I'd explain it to a colleague:

• The problem in one sentence, with the failure a user actually hit.
• Acceptance criteria that a test can check.
• The constraints that might not be obvious from the code: what must not change, which past decision this must respect.
• What "done" looks like, including the failure mode, e.g. a missing file must produce a visible error, not a quiet fallback that looks like success.

The acceptance criteria has become the real source code. A vague spec can cost hours of review later, while a precise one costs a little time now as it leaves less room for model assumptions or ambiguity.

Late morning: fan out

A feature breaks into multiple stories. Each one goes to its own agent, in its own isolated worktree, so they can't trip over or override each other. One agent writes the backend implementation, one the tests, one the docs, one does a security pass, etc.

While they run, my job looks a lot like a dispatcher's:

1. Answer the questions they raise.
2. Notice when two of them are about to make conflicting assumptions, and settle it once for both.
3. Resist the urge to jump in and type. If I fix it by hand, the agent learns nothing and the spec stays wrong.

Parallelism is the big win here, multiple concurrent stories in the time one used to take. The less obvious cost is that I now hold multiple streams of context in my head instead of one.

Afternoon: review is the job now

This is where most of my day goes now, and it's the part I've had to re-learn.

Reviewing agent-written code isn't like reviewing a colleague's. The syntax is almost always clean. The names are reasonable. The tests pass.

So I've stopped reading top to bottom and started asking questions instead:

• Does it do what the acceptance criteria say, or what they sound like?
• What happens on the unhappy path? Agents write the happy path first and the error path last, if at all.
• Did it change anything I didn't ask for? A one-line fix that also "tidied" three other files is a red flag.
• Are the tests testing behavior, or testing the implementation it just wrote? A test that mocks the exact thing under test proves nothing.

Late afternoon: steering

Every correction I make today is wasted if I have to make it again tomorrow. So part of the new process is turning corrections into durable instructions.

Here's a recent one. I noticed our test coverage had slipped below our target percentage. No single change caused it. The agents were writing tests with every feature, just not quite enough of them, and nobody had told them to check. A slow drift like that is easy to miss when no one is writing the tests by hand.

So we updated our tester agent. It now checks coverage on every change and flags anything that falls below the target, so the gap shows up in review instead of piling up quietly.

This is the closest thing to programming I still do every day. I'm not writing the code. I'm writing the environment the code gets written in. One good sentence in an instruction file can pay off across many future runs.

What changed, and what didn't

The job didn't get easier. It just shifted. Most of the hours that used to go to producing code now go to specifying it, verifying it, and shaping the system that produces it. Along with this comes how productivity gets measured. It can no longer be measured in the amount of code lines or number of tickets closed. Instead, it should be measured in how often the right thing ships and how likely it is for the same mistake to happen twice.

Then and now

Then	Now
Write the code	Write the spec the code is checked against
Debug my own mistakes	Debug plausible answers I didn't write
Review a teammate's PR now and then	Review all or most of the day
Hold one task in my head	Dispatch and track several agents at once
Fix it and move on	Fix it, then teach the system so it stays fixed

What didn't change is that someone still has to know what "right" means, notice when the green checkmark is lying, and own the decision to ship.

End of Day Outcome

Before, a single feature could take a whole week at a minimum. Part of that was the time it took to implement and test each story. The other part was waiting on engineers with other specialties, such as DevOps and QA, and fitting into their schedules. Now, with the help of our SDLC personas, an entire feature can be done in a day. We used to be a full-stack team. Now, every engineer in our team carries a full-stack team of their own.

Here's today's outcome:

• One feature completed end to end
• Three open tech-debt issues addressed on our release workflow
• A larger feature started. Most stories are already implemented. A few remaining stories are blocked on a story in a separate feature. What's left for me is the part that matters the most, taking the time to review, run tests, and verify it does what it's expected to do.

— Stephanie

Much of the noise about AI is people shouting one true thing at people shouting another true thing. These times demand that we hold several truths in our heads at once. Those who learn to do so will build AI's future, and with it, better futures for all of us. I want to share my thoughts stemming from being in and around AI since I was a teenager.

AI in the right hands is already delivering extraordinary improvements. I was recently shocked by a piece of software I built. Years ago I led the development of a software platform that large enterprises rely on. It carried extreme reliability requirements. Building it took a large team several years of hard work. This time, with a frontier coding model, I rebuilt a rough, simplified version of it in a day. When I think about it, I still cannot believe it. AlphaFold predicted the structure of 200 million proteins, work that would have taken hundreds of millions of years at the bench, and earned Demis and colleagues a Nobel Prize. Don Knuth learned that a colleague used a model to find a beautiful solution to a problem he had identified years ago, and publicly softened his doubts about AI. OpenAI announced a team's breakthrough with the Navier Stokes equations, a seminal mathematical challenge that was open for a century+. Successes like this and more are popping up across all walks of life.

AI in the wrong hands can do catastrophic damage. In 2017, long before ChatGPT, hackers leaked EternalBlue, a cyberweapon stolen from the US National Security Agency. Within weeks it powered the WannaCry and NotPetya attacks, crippling hospitals, ports and factories worldwide and causing billions in damage. Soon ordinary criminals were using it. Today's AI models encode much of humanity's knowledge, and social media carries their output to billions of people worldwide. Deepfakes, automated fraud and knowledge repurposed for harm can now spread further and faster than ever.

AI by itself does nothing. As Alan Kay says, "the music is not in the piano." In July, AI agents from OpenAI broke out of their sandbox and into Hugging Face's servers and more. What happened was no mystery, and certainly no miracle. It was large model(s) trained on details of exactly such attacks, and a piece of code running over it, let loose onto the world without adequate safeguards. These systems amplify whatever we bring to them: our ingenuity, and equally our negligence. We failed to contain EternalBlue. If we don't learn from Hugging Face, we will have failed again. To make matters worse, the doomsday talk and the sales talk often come from the same people, because describing AI as godlike raises fear and valuations together.

AI is deeply disruptive to India's $300-billion IT services industry, which was built on the coding, testing and support work AI now automates. Yet every enterprise on earth needs help to use AI well: to understand its own business, to transform decades old systems, and take responsibility when things go wrong, as we at Hang Ten see every day. That is a massive opportunity for the industry.

AI urgently needs regulatory oversight. Our modern world runs because of commonsense safeguards and regulations, from our barbers operating scissors on our heads to our buildings and bridges, automobiles and airplanes, what we eat and what we entertain ourselves with, our medicines and our machines, all built with guardrails often put together by organizations of peers.

And yes, AI needs a lot more innovation, fast. AI development has a long way to go. From overcoming hallucinations, which are at the heart of how current LLMs work (as my son Varin and I showed recently), and improving AI's ability to understand the physical world around us, to significantly improving AI's power and computing footprint. We are still in the early innings of AI development.

So our times increasingly are times to understand things more deeply, and to apply our own minds. Humanity has achieved billion-fold improvements before: in my lifetime, computing has become more than a billion times cheaper. Building bridges, skyscrapers, agriculture and more are unimaginably more productive than just a century ago. We can grow our understanding of AI with the same ambition.

AI today has a dangerous concentration of power. A handful of companies control the AI frontier, with barely a few thousand experts building frontier models. With all the talk about pacing the AI frontier, I believe the real frontier is teaching millions how to build this piano and billions how to make music with it.

In the time ahead, perhaps in my lifetime, likely in my children's lifetime, we will see AI systems that can build and do anything we ask. John McCarthy, a great teacher of my life, saw this decades ago. In one of the moments that have shaped me, he said that at a time when we can ask a machine to build us anything, what we ask it to build becomes the frontier. A billion curious minds, fully conversant in what AI is and how it works, making magic with it, magic that may be incomprehensible to us, is what the real frontier is. Yes we must accelerate the frontier, the one between our ears.

— Vishal

Three months ago I wrote in Hello World, that when there are big waves around, it is time to surf. We are up and riding, and today I want to share an update on our work since then.

The best part is our customers. In a few short months we have signed several engagements with some of the world's most important enterprises, delivery is underway on several and a few are already done. Vinod Philip, the CEO of Siemens Gamesa Renewable Energy, said it best in our announcement today: we started working together with a short list of outcomes they needed proven, we delivered with a speed and quality that impressed them, and they have since widened the scope of our work together. For a company this young, there is no greater reward than a customer asking for more. Especially a demanding customer whose requirements of rigor and safety are unparalleled. Our work with all our customers, around the world, has similarly been exhilarating.

What we are doing is the hard, often unglamorous, but fun work of making AI both fast and reliable. Almost everyone in our industry is being asked to choose between the two: ship quickly and hope, or keep the old controls and give up the speed. We refuse that choice. Navin has written about how we do it: every control on every change, verification kept independent of generation, and three signatures that stay firmly in human hands. Reliability is not something we add at the end. It is the thing that makes the speed worth having. It is woven into what we make and indeed into how we work.

And now our investors have joined our customers in rewarding that work. Today we announced an additional $53 million led by Xora, a Temasek-backed fund, with Mayfield and Aramco Ventures participating again, bringing our total to $85 million, five weeks after our first round.

I am especially grateful to Phil and Sofia and the entire Xora team for their extraordinarily warm welcome, and for bringing us into the Temasek ecosystem. They have written about why they invested, Phil's post and Sofia's. There is a deep sense of urgency in Singapore and beyond, about putting AI to work in the real economy, and we feel privileged to be part of it.

So now comes the part I have been looking forward to most: the building. Doing the work, for customers who are counting on us, at a quality we can be proud of. It will be hard, and it will be fun, like catching a wave always is.

We are just getting started. If you're a surfrider, come build with us.

— Vishal

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 (hangten.ai), 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