Hypervelocity Engineering - Part 1

Introduction

Over the last two years, most of the AI conversations I’ve been part of have revolved around “doing AI”. Very few have been about how we change the way we work, so that AI becomes part of how engineering teams actually deliver, repeatably, safely, and at scale.

Microsoft has put a name on its answer to that question: Hypervelocity Engineering (HVE). Alongside it sits HVE Core, an open-source toolkit of agents, instructions, and skills that puts the approach into practice.

As someone who has spent a career writing code, then moving into infrastructure, pipelines, and platforms, and then back to full stack development, I think this is one of the more interesting shifts to come along in a while. For me, it’s less about making engineers faster, as plenty of tools already promise that, and more about the fact that it starts to productionise a way of working. In my opinion, the more of that way of working we hand to AI, the more the human judgement around it matters.

So the question is; how do we take advantage of that pace, without losing the judgement that makes the work valuable in the first place?

Over this series I’ll share my perspective on where this is heading:

Part 1:

• Culture or toolkit? What Hypervelocity Engineering and HVE Core are
• Where they fit, and how they help
• What it doesn’t replace, and why judgement matters more than ever

Part 2:

• Methods as Code: from virtualisation, to DevOps, to cloud, to agentic playbooks

A Culture, or a Toolkit?

Before getting into the detail, there’s a question I think is worth posing early on.

We’ve been here before. Agile started as a manifesto, a set of values about how teams work together. DevOps started as a culture, breaking down the wall between the people who build software and the people who run it. Both were ways of working first. However, over time both also became job titles, certifications, and in many cases, products you could buy. I’m sure many of us have seen organisations stand up a “DevOps team” or run an “Agile transformation”, without necessarily changing how the work actually gets done.

I’m not saying that’s all bad, roles and tooling are often how a way of working scales. But when the tooling becomes the goal, the culture tends to get lost along the way.

So with HVE, the question I keep coming back to is; is this a culture, or a toolkit?

In my opinion, it’s both, and that’s exactly why the distinction between HVE and HVE Core matters.

HVE vs. HVE Core - Methodology and Toolkit

The first thing worth clearing up is that HVE and HVE Core are not the same thing.

• Hypervelocity Engineering (HVE) is the methodology. A way of working where AI carries context, standards, and process through every stage of delivery, from discovery and design thinking, through planning and implementation, to review and delivery.
• HVE Core is the adaptable toolkit. A reference implementation of that methodology that organisations can install, fork, and shape into their own.

Microsoft is refreshingly upfront about this. The HVE Core README describes it as highly opinionated and rapidly evolving, and recommends treating it as a source of patterns rather than a production dependency, with guidance on forking and building an implementation you own. Personally, I’d go a step further and say this is actually where the value is. The methodology is the part that will last, whereas the toolkit is a starting point for codifying your organisation’s own version of it.

Microsoft describes HVE in a number of ways across its documentation, but in my opinion, Hypervelocity Engineering would be defined as:

“A way of working where AI carries the context, standards, and process of engineering, so that people can spend their time on the decisions that actually matter.”

The Methodology - Research, Plan, Implement

At the heart of HVE is a simple, structured loop known as RPI - Research, Plan, Implement - with Review closing it out. Rather than asking an agent to “build the feature”, work is broken into deliberate phases:

• Research - gather the evidence, constraints, and context before deciding anything.
• Plan - turn that research into a reviewable plan that a human can challenge.
• Implement - execute the approved plan, following the organisation’s standards.
• Review - validate the output against the plan, the standards, and the intent.

Wrapped around RPI is a broader nine-stage lifecycle, from setup and discovery through product definition, decomposition, sprint planning, implementation, review, and delivery, to operations. Design thinking methods feed into it, along with security, responsible AI, and supply chain planning.

The Toolkit - HVE Core

HVE Core is how that methodology shows up in your editor or terminal:

• Agents for specialised tasks - research, planning, implementation, review, security planning, backlog management, and more.
• Instructions that automatically apply roughly 80 engineering standards based on the files you’re working in.
• Skills that package reusable workflows, from creating ADRs to drafting incident runbooks.

The principle behind it, in Microsoft’s words, is “AI carries the rules, humans keep the judgment." It’s a line that I think sums up the approach well, and one I’ll keep coming back to throughout this post.

Where Does It Fit?

Not Just a GitHub Copilot Thing

HVE Core is packaged first and foremost for GitHub Copilot, as a VS Code extension and a Copilot CLI plugin. It would be easy to read it as “a Copilot add-on”, however, I think that undersells it a little.

Its building blocks are plain markdown: agent definitions, instruction files, and skills that follow the open Agent Skills specification. The methodology itself, research before planning, plans before code, standards carried by the system rather than by memory, has nothing to do with any one vendor.

As a concept, HVE applies to any agentic harness. Whether your teams are working in GitHub Copilot, Claude Code, Codex, or whatever arrives next quarter, the same pattern holds: codify the context, the standards, and the steps, and let the harness execute them.

For me, this is the most interesting part of the shift. The value starts to move away from the tool itself and into the codified method that sits on top of it.

How Does It Help?

In practice, I see three big wins:

• Conversations start further along. Instead of walking into a workshop with a blank whiteboard, you walk in with researched context, a draft plan, and a set of options to discuss, which in my experience makes those early sessions far more productive.
• Consistency across teams. Standards, security requirements, and architecture practices get applied because the workflow carries them, not because someone remembered the wiki page.
• Accelerated design thinking. The discovery and framing work, often the slowest and least structured part of delivery, gets structure and momentum without losing the human-centred part.

Across the Lifecycle

HVE’s sweet spot is the build. Across its nine stages, from discovery and design thinking through planning, implementation, review, and delivery, it brings structure and pace to the work that has traditionally been the slowest to get moving.

There is some operational coverage too, such as incident-response runbooks, documentation upkeep, and structured root cause research. However, the centre of gravity is clear: getting from idea to delivered change faster, and more consistently.

What It Doesn’t Replace

This is the part I feel most strongly about.

As delivery gets faster, the cost of a bad decision arguably goes up rather than down, because you reach the consequences of that decision much sooner. HVE can accelerate the work, but it can’t decide which direction the work should be heading.

If HVE brings the method and the problem brings the context, someone still needs to sit in the middle and apply judgement. The skills that I think matter more than ever are:

• Problem framing - knowing the difference between the problem you were given and the problem that actually needs solving.
• Architecture trade-offs - non-functional requirements, cost, risk, and the “it depends” that no agent can resolve without context.
• Organisational context - the history, politics, and unwritten constraints that never make it into a repository.
• Trust and alignment - bringing stakeholders with you, and having the credibility to say “no”.
• Ownership - being accountable for the outcome, especially when the agent is confidently wrong.

I don’t see the consultant and architect skill set being automated away, if anything it’s becoming more concentrated. The bottleneck is shifting from typing to thinking, which, in my opinion, is exactly where experienced technologists should want it to be.

It’s also why we’re seeing new operating models emerge around this way of working, such as the forward deployed engineer: people who carry a codified method into a real problem and own what comes out of it. More on that in Part 2.

Final Thoughts

While parts of this post are largely informational, writing it has reinforced for me just how quickly AI-assisted engineering is maturing, moving from individual productivity hacks towards a productionised way of working. For me, the key takeaways are:

• Separate the methodology from the toolkit - HVE is the way of working; HVE Core is a starting point you should adapt, fork, and own. Otherwise we risk repeating the “buy DevOps” mistake.
• Think harness-agnostic - the value lives in the codified method, not the tool executing it.
• Invest in judgement - codified methods make teams faster, but experienced people deciding where to point them is where the real velocity comes from.

We started this post by asking how we take advantage of the pace AI brings, without losing the judgement that makes the work valuable. Whilst that question hasn’t been fully answered here, I’m hoping it has highlighted that the methodology and the people applying it matter just as much as the tooling.

There’s also a level above all of this. HVE codifies how a team engineers, but what about codifying how an organisation solves problems, and scaling that across many teams? That’s where I’ll take things in Part 2, with Methods as Code. It also aligns closely with something we’ve been building at LAB3 over the past three months, so watch this space.

If you’ve been experimenting with HVE, or something similar within your own teams, I’d love to hear how it’s going.

Hypervelocity can accelerate the work, but it’s still up to us to decide which way to point it.