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 (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