Hypervelocity Engineering
A Year on the Front Lines
A year ago, I began documenting a framework our team called Hypervelocity Engineering (HVE) - a deliberate approach to bringing AI into the core of the engineering team. At the time, I argued that velocity is a vector (speed plus direction) and that we needed to “start slow” to build the right foundations responsibly.
Since then, we have hit a massive structural step-change in productivity, driven by a new generation of frontier models: the leap to systems like Opus 4.6 and GPT 5.3 Codex has fundamentally altered the baseline. In a recent two-week stress test to see where these limits now lie, I pushed roughly 60,000 lines of code. My colleague Dan Driscoll documented a similar high-intensity milestone: a 300-commit marathon in the same timeframe.
This Substack is reader-supported. To receive new posts and support my work, consider becoming a free or paid subscriber.
These numbers represent a shift in what a small, focused team can achieve, akin to the transition from manual drafting to CAD. While my team is still in the process of moving toward this new paradigm, my personal “limit testing” over the past few months has clarified what remains evergreen and where the discipline is moving.
Planning is the Work
In my original series, I warned about “merge hell” and “dueling agents” causing ripples across codebases. When you are pushing code at this new volume, those ripples become tidal waves unless you shift the bulk of your effort to an intensive Planning Phase.
Separable Flows of Effort: Success now depends on architecture that is intentionally partitioned into easily separable flows of effort.
Architecture as Intent: We are moving away from “prompt engineering” toward Intent Engineering. The human architect owns the architectural constraints and the “meta-coding”; the AI handles the labor of implementation.
Independence by Design: By spending more time up-front on partitioning, a team of humans and agents can work concurrently without the friction of constant context-collisions.
The Loop Over the Conversation
The most significant change in my style this year is the realization from Dan Driscoll that the loop outperforms the conversation.
In the early days of HVE, we used AI as a “pairing partner” to build intuition and prevent skill erosion. While that remains a vital educational tool, high-volume engineering requires moving the human out of the “inner loop” of syntax and error correction.
Deterministic Feedback: If an agent can run a test, see a linter error, or view a stack trace, it doesn’t need a “conversation” - it needs the system to provide deterministic feedback.
Evaluation Cycles: Before a PR is even opened, the environment should have already validated the code against the team’s standards.
The Closed-Loop Operator: As Dan Driscoll has highlighted, we are moving from a world of “AI as a consultant” to AI as a closed-loop operator.
The Evergreen Kernel: The “Working Agreement”
My original insistence on documenting “ways of working” and design decisions in-repo has become the single most important factor for success. This has evolved into the “Constitution” stack: .cursorrules, CLAUDE.md, and the SpecKit constitution.
AI-Readable Context: These files act as the shared brain for the team, ensuring that every agent and human adheres to the “spirit” of the decisions behind the code.
Standardizing Interaction: Documenting these instructions in a shared resource continually lowers the barrier for new team members and ensures consistency across the codebase.
Prototyping as Production: The “Sacrificial” Method
I’ve applied Design Thinking’s “sacrificial concept” to full-scale engineering.
Alternate Realities: In a high-velocity environment, we can afford to code two alternate, fully functional versions of a feature simultaneously to compare trade-offs.
Synthesis: The team then “mobs” around the working results, identifies the superior patterns, and synthesizes a third, final version.
Learning Flywheels: This creates institutional knowledge that compounds over time, turning the project itself into learning material for the next wave of engineers.
The Next Year of Adaptation
We are currently at the beginning of this acceleration curve. While my team is still maturing into these practices, the capabilities of the models are not standing still. In a future post, I’ll explore how we must adapt as agents move from being repo-aware to being environmentally aware—handling deployment, monitoring, and self-healing in ways we are only beginning to experiment with today.
Hypervelocity Engineering is not about one person doing the work of many. It is about empowering a small team to deliver with the impact of an entire department. By focusing on careful planning, deterministic loops, and sacrificial prototyping, we allow our teams to focus on the high-level architectural decisions and the business value that AI cannot yet articulate.