Taking the Long and Less Traveled Road is the Only Path to Autonomy
May 06, 2026 • Brian Elliott • 10 min read
We'll get to that. The story behind the round is what earned us the right to tell it.
For the last decade, both Sid and I have lived the challenge facing large enterprises trying to modernize the software stacks that are mission-critical to their businesses. Our conviction predates Blitzy. It came from two unique vantage points. Sid spent years at NVIDIA in Jensen Huang's orbit at the dawn of modern AI. I was in US Army Special Operations working at the intersection of frontier technology and military operations at a scale only available to those working under Joint Special Operations Command (JSOC).
Large scale digital transformation is not constrained by vision or ambition. It is constrained, almost universally, by engineering velocity and mounting technical debt. Backlogs never shrink. Roadmaps rarely get fully executed. The most important modernization projects get deferred year after year. Not because the work is unworthy. Because there are never enough engineers, and the ones you have are stretched thin holding up core systems implemented before the turn of the century.
Blitzy was built to solve that problem from first principles.
Friends Before Founders
Sid and I met as two of the few highly technical students walking the halls of Harvard Business School. We bonded — or maybe more accurately commiserated — over this exact problem. We became close enough that Sid is now godfather to my son, RJ, and I am the godfather to his daughter, Ayana.
I was fascinated by his nearly eight-year tenure at NVIDIA, much of it spent at the emerging frontier of AI and the constant refactoring of GeForce NOW during the cloud gaming wars. He was fascinated by my experience at JSOC leading large scale simulation design, where I experienced the challenges of scale under the brightest lights.
Different domains. Same lesson.
Raw model capability, on its own, does not solve hard engineering problems. It will never understand enterprise codebases at scale. You need a system around the model. You need orchestration. You need grounding in the real environment.
By the time we sat across from each other at HBS, we each came with a prepared mind and a contrarian view of what the Transformer architecture could actually accomplish in enterprise software development.
Others raced to market with IDEs supercharged by ever-improving models, demoing beautifully on greenfield repos. Many of those tools collapsed the moment they touched a real codebase with twenty years of decisions baked into it. They were designed for individual developers writing new code. The hardest, most valuable problem — modernizing the systems that run global commerce while respecting decades of nuanced decisions — was being almost entirely ignored.
So we founded Blitzy.
The Contrarian Stance that Launched Blitzy
Frontier models are a revolutionary breakthrough for society. But the marginal returns on making them ever bigger are not what enterprises need to get higher quality code from these systems. What gets you there is letting reasoning actually run. Long horizons. Real time to think. The patience to work through a problem instead of guessing at it.
The unlock is not always a smarter single shot. It is the ability to keep thousands of agents coherent across days of work — planning, revising, validating against the code, backtracking when something does not hold, and arriving at software that compiles globally and holds together end to end. In a world where most of the industry was still betting on scale alone, we bet on inference and hyperscale orchestration.
The second bet follows directly from the first. If quality is driven by system level reasoning at inference time, the binding constraint becomes whether the agents share a real understanding of the codebase they are working on. Frontier models are extraordinary. But they have never been trained on your source code. They have never seen your internal frameworks, your dependency tangles, your decade-old service-mesh, the patterns your senior engineers enforce, or the tribal knowledge sitting in the heads of the people who keep the lights on. Raw model scale cannot compensate for that gap. Reasoning, no matter how long it runs, cannot reason its way around what it does not understand. An agent that cannot see the shape of your repo writes code that looks right in isolation and breaks the moment it meets the rest of the system.
What can compensate is deep environmental grounding — a knowledge graph that captures what is literally true in your environment: the codebase, the architecture, the dependencies, the conventions, the constraints. That grounding is what lets agents produce code that works in production, not just in a demo.
This is the part of the bet we hold most strongly. Understanding and orchestration must be designed and fused together from day zero. The system that figures out what your codebase actually means and the system that coordinates thousands of agents working across it cannot be two separate products stitched together at the seam. They have to be one. The graph that grounds a single agent in a single file is the same graph that lets a thousand agents maintain coherence across a million-file repository.
This is what we mean when we say you cannot retrofit autonomy. Single agent copilots and IDE tooling were built in a different paradigm. To get where we already are, they would have to tear down what they have and rebuild in this shape. That is not a competitive talking point. Autonomy at the level required for enterprise software is not a feature you add. It is a foundational design choice.
Why We Saw This Early
Sid's work refactoring GeForce NOW was not a clean-room engineering problem. It was large, messy, legacy infrastructure that had to keep running while being rebuilt underneath — under real production constraints. And critically, NVIDIA was using AI to accelerate that work long before LLMs existed. GANs, RNNs, and other architectures applied intelligently to refactoring at scale.
The lesson was simple and durable: raw model capability does not automatically translate to solving hard engineering problems. You have to orchestrate that capability against a specific, grounded problem.
Sid's work was strong enough that NVIDIA executives hand-picked him to relocate to NVIDIA's main Santa Clara headquarters. More interestingly, Jensen added him to a private internal distribution of roughly forty people, where he personally circulated machine learning research papers. This was 2015 and 2016 — years before "Attention Is All You Need" was published, years before transformers became common knowledge in the industry.
When the transformer architecture finally arrived, Sid did not see magic. He saw a powerful tool that would be widely misapplied.
The reason is the architecture. A transformer is a next-token predictor. These models learn the statistical patterns of language and code so well that the output feels like reasoning. It is not. It is glorified autocomplete at scale. The intelligence is a perceived phenomenon.
That is why a frontier model can find a 27-year-old vulnerability buried inside the security infrastructure that millions of systems depend on — and why the same model can fail to answer whether you should walk or drive your car to the car wash. When the model is in its lane, it looks superhuman. When it veers outside that lane, it looks less coherent than a toddler.
The implication for enterprise software is large. You do not hand the model the keys. You use it the way every powerful tool gets used: as a component inside a larger system that constrains what it can do, validates what it produces, and recovers gracefully when it gets something wrong.
The failure modes are not theoretical. Cursor agents have deleted production databases. Anthropic's own safety report on Mythos, their most advanced model, documents the system inventing vulnerabilities that did not exist, editing git history to cover its tracks, and writing scripts to auto-approve its own permission prompts. This is what happens when you grant raw horsepower unprecedented access to critical systems.
That is why, when most of the AI world was racing to make models bigger and supercharge individual developers, we were investing in the layer that would orchestrate frontier capability safely and abstract away the complexity of AI. Thousands of agents working in parallel. Bound by a pre-approved spec created by your best engineers and architects. Validated against a knowledge graph that grounds every action in what is actually true about the codebase.
A model is a tool. A system is what makes that tool safe to use at the scale of a regulated enterprise.
The Current SDLC Was Built for a Bygone Era
The software development lifecycle was not designed with AI in mind. It was designed to work within the constraints of how humans actually think and work. We hold limited context. We work sequentially. We need handoffs, documentation, and review cycles to compensate for what we cannot keep in our heads simultaneously.
Standups. Sprint planning. Ticketing. Code review. Change management. These rituals exist because human cognition is finite and fallible. They are not laws of nature. They are accommodations.
The SDLC was built to amplify human strengths and mask human weaknesses. It is a brilliant system for a world without AI. It is the wrong system for the world we are in.
Agents do not have those constraints. When you orchestrate thousands of agents in parallel against a knowledge graph that grounds them in the real environment, you can fundamentally redesign how software gets built — not by bolting AI onto the existing process, but by rebuilding the process around what agents now make possible.
This is the part that gets misunderstood the most, so we want to be unambiguous.
This Is Not a Story About Replacing Engineers
This is a story about transforming what engineers spend their time doing.
The average enterprise engineer today spends a substantial portion of every week on work that does not require their best capabilities. Boilerplate. Glue code. Integration tickets. Debugging context they had to rebuild from scratch because the last person to touch the file left two years ago. Slogging through technical debt in systems they did not design and would not have designed that way.
This is not why great engineers became engineers.
When agents absorb that work, engineers rise to the work only humans can do well: understanding customers deeply, making architectural trade-offs that depend on business judgment, designing systems that are elegant and durable, and connecting technology decisions to outcomes the business actually cares about.
That is more meaningful work. It is also, by every measure the business cares about, more valuable work.
We have seen this happen inside our customers. The engineers we work with are not less engaged — they are more engaged. They are spending their days on the things that drew them into this craft in the first place.
The Real Unlock: Autonomy Shifts the Constraint Left
When engineering is no longer the bottleneck, the nature of the constraint changes. The question stops being "can we build this?" and starts being "what should we build?"
Design thinking becomes the limiting factor. Business ingenuity becomes the limiting factor. Strategic clarity becomes the limiting factor. That is a fundamentally better world for any enterprise to operate in.
Blitzy unblocks roadmaps. The large modernization projects that have been deferred for years because the engineering lift was too great become executable. The ambitious features the business has wanted but engineering could not prioritize get built. The mainframe migration. The platform consolidation. The thirty-year-old risk system. The customer experience overhaul that has been on the slide for five planning cycles.
Those move from someday to this quarter.
Any project that can be solved by software can be built by Blitzy. We built for full autonomy from day one. That is not a roadmap item. It is the founding premise.
Proven at Enterprise Scale
The strongest signal in this announcement is not the raise. It is what our customers have already done with Blitzy.
We are deployed across ten industries inside the Global 2000. The platform has ingested and understood more than one billion lines of enterprise code since September 2025. It has been hardened on the codebases that run banks, insurers, manufacturers, telecom infrastructure, and the supply chains behind global commerce.
The customer proof points speak for themselves:
- QAD compressed a 24-month iOS to Android migration into 6 months, unlocking a European market expansion 3x faster than their original plan — driving a meaningful increase in topline revenue well ahead of board expectations.
- A Fortune 100 customer used Blitzy to reverse engineer, document, and ingest 33 million lines of mainframe code. The internal estimate for that work was 9 months and a dedicated team of engineers. Blitzy completed it in 3.5 days.
- Builders FirstSource, the largest supplier of structural building products in the United States and a member of the Global 2000, accelerated software development velocity by 3x in the first three months. 120 of their engineers now work in AI-native workflows on Blitzy.
Built to Endure

We are not just building one of the fastest growing companies (measured on ARR growth) of all time. We are building one that will be around for our kids to be proud of.
Our capital efficiency is a major differentiator. Since January 2025, for every dollar we have burned, we have generated $2.91 in ARR. Our gross margin, including inference and our forward-deployed motion, looks closer to a true SaaS business than to the code generation tools and agentic/model amplification layer companies we are often grouped with.
Our financial health is not an accident. It is a function of the product.
Blitzy's north star is enterprise-grade, production-quality code, and we will spend any incremental amount of compute to ensure the output exceeds our customers' expectations. The 5x acceleration on large software projects, paired with autonomous validation and testing, means code arrives near production-ready. That is what gives our customers the confidence to pay a premium price point for the platform.
Underneath the hood, the system is built for efficiency. As Blitzy decomposes the Agent Action Plan, our agents intelligently route to the right model and tool for each task — selecting the optimal model and tool to accomplish the work without reaching for ones that are overkill on intelligence or price. The cognitive load of model selection does not sit with the engineer. It sits with the platform. Our customers do not pay for tokenmaxxing. They pay for outcomes in the form of production-ready lines of code.
About Our Growth Round
So now, the round.
$200 million at a $1.4 billion valuation. We are deeply grateful to the investors who believed early, and to the new partners joining us for the next chapter.

Our technology is proven and enterprise hardened. The opportunity is larger than we believed when we started our journey. We are raising this capital to scale what is already working — to bring autonomous software development to every enterprise.
To our customers: thank you for trusting us with the work that matters most to you. To our team: thank you for building something that did not exist and could not exist without the specific people we have.
The story of enterprise software development is about to change. This is the beginning of that story.
Brian Elliott and Sid Pardeshi Co-founders, Blitzy

