Blitzy logo
OverviewUse-casesSecurity
Company
DocsBlogVideos
Pricing
OverviewUse-casesSecurity
Company
DocsBlogVideos
Pricing

Taking the Long and Less Traveled Road is the Only Path to Autonomy

May 06, 2026 • Brian Elliott • 10 min read

Taking the Long and Less Traveled Road is the Only Path to Autonomy

Yesterday we announced that Blitzy has raised a $200 million growth round at a $1.4 billion valuation.

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

Brian all hands

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.

Asset inside blog for raise

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

More from the blog

View all
How Blitzy Optimized Our GTM Team

How Blitzy Optimized Our GTM Team

Jun 04, 2026 • Carly Levinsohn • 3 min read

A Quick Blitzy Chat:  3 Codebases’ Takes on Prompting

A Quick Blitzy Chat: 3 Codebases’ Takes on Prompting

May 28, 2026 • Carly Levinsohn • 7 min read

Frequently asked questions

What is Blitzy?

toggle button

Blitzy enables development teams to transform six-month software projects into six-day turnarounds using Blitzy OS, an agentic platform that enables thousands of AI Agents to 'think' and cooperate for hours to bulk build software with precision. The platform builds everything AI can deliver in a precise manner, around 80% of any roadmap or new product, supplemented with a human engineering guide to complete the remaining 20% needed for production. With over 27 patents and counting, Blitzy is actively hiring PhDs and senior developers in Cambridge, MA who have a passion for building AI that leverages 'System 2 Thinking' to solve problems at inference.

Who is Blitzy for?

toggle button

Enterprises that aim to dramatically accelerate their software development velocity, development agencies with enterprise clients, development teams with complex existing products, and individuals looking to accelerate their own velocity on complex builds.

How does Blitzy's technology work?

toggle button

Our patent-pending code ingestion framework maps a curated selection of robust, reliable, and secure open source software libraries that we track by version and update frequently. Combined with our proprietary code generation technology that specializes on enforcing enterprise-class software policies, Blitzy far exceeds the utility of typical chatbots and co-pilots in creating production-ready software at scale.

Is Blitzy a coding co-pilot?

toggle button

Nope. Blitzy surpasses traditional co-pilots with its ability to autonomously generate nearly-complete code repositories, not just snippets. It features a daily-refreshed knowledge base, avoiding the pitfalls of outdated information. Blitzy's proprietary codebase representation system enables deep understanding of generated code, offering highly contextual and relevant suggestions for your entire repository.

What's my role in Blitzy's development process?

toggle button

Your team is responsible for bringing the requirements, and as an approver during the technical specification stage. We ask you to edit/approve the Technical Specification. The document is editable, so you can edit and approve to get exactly what you had in mind.

How does Blitzy decide which tasks to delegate to human developers?

toggle button

Blitzy's multi-agent system is meticulously and rigorously trained to know what it can accomplish, and what needs to be left for the human engineers. This ensures you only receive quality code and have a clear picture of remaining tasks.

Does Blitzy do more than just autonomous code generation?

toggle button

Yes. Blitzy is a comprehensive platform that provides end-to-end development assistance. We support the entire development lifecycle by taking descriptive inputs and generating software requirements documents, technical design, code structure, and generative code within repos for your product.

Is this high quality and secure?

toggle button

Quality and security matter deeply to us — and they were our biggest frustration with the copilots already on the market. That frustration is what led us to build something different: a system designed to meet enterprise standards from the start. Every piece of work passes through multiple QA agents that review each other's output before any code reaches you, so what you receive is held to a consistent quality bar rather than the variable output typical of single-pass code generation. We deliver production-grade code repositories. As with any code entering your environment — written by humans or AI — your team should still run its own QA, QC, and security testing before deployment. We build to a high standard and give your reviewers a strong starting point; final validation stays with the team that owns the production environment.

What is the typical cost of your solution?

toggle button

Blitzy uses a two-phase pricing model: evaluation followed by deployment. This structure lets enterprises validate ROI at their preferred scale before committing to organization-wide implementation. The evaluation phase provides three options. Reverse Engineer ($0) offers an initial assessment with complete codebase reverse engineering and understanding up to 100K lines of code; Proof of Concept ($50K for a 2-month term), where Blitzy delivers a guided POC to demonstrate value; or Structured Pilot ($250K for a 6-month term), which fully deploys Blitzy in your environment with 5M lines onboarding and 1.25M lines generation to prove production readiness. Following successful evaluation, organizations choose between three deployment paths. Commercial ($500K typical investment per year) adopts Blitzy on one team to accelerate a defined initiative: the first 20M lines onboarded are included, with additional onboarding at $0.10 per line and generation at $0.20 per line starting at 2.5M lines, plus dedicated infrastructure and SAML-SSO. Enterprise ($5M typical investment per year) rolls Blitzy out across your engineering organization, with onboarding billed at $0.10 per line across the full codebase — a typical engagement onboards 50M lines — and generation at $0.20 per line as needed, adding a Dedicated AI Solutions Consultant, 2 Forward Deployed Engineers, org-wide onboarding and certification, and priority support. Transformation ($50M typical investment per year) supports your largest codebases, with a typical engagement onboarding 500M lines at the same per-line rates, custom deployment, and embedded teams including a Field CTO, a Dedicated AI Solutions Consultant, 6 Forward Deployed Engineers, and 2 Forward Deployed Designers for complete digital transformation. All tiers maintain SOC 2 Type II compliance, ISO 27001 certification, and guarantee no training on your code. Pricing follows a transparent two-rate model: $0.10 per line onboarded for reverse engineering and $0.20 per line generated for forward engineering. Because reverse engineering also produces complete technical documentation of your codebase, onboarding-only engagements are fully supported, and in every tier costs align directly with the value delivered.

After submitting my prompt, Blitzy added functionality in my tech spec that I did not expect. What do I do?

toggle button

The system defaults to taking advantage of all technology upgrades when modernizing or upgrading to the latest technology stack. For example, if you specify an upgrade to Java 21, the system will by default implement virtual threads, as it's generally seen as a superior technical approach. If you do not want this, you must simply tell the system to 'make as few changes as possible to achieve the desired request'. Being as specific as possible about what functionality is (and is not) desired helps yield results that will align with expectations.

What do Blitzy agents rely on as a source of truth to represent my existing codebase?

toggle button

Blitzy agents rely on the actual source code of your existing codebase—not the Tech Spec documentation—when performing refactors or extending functionality. However, an accurate Tech Spec significantly aids the system's efficiency in querying the underlying representation of the code. Therefore, investing time to ensure the Tech Spec reflects the core features of the application will yield expectation-aligned results and will save time with last-mile development.

Can Blitzy work with existing products and code bases?

toggle button

Yes! Blitzy excels at working with existing codebases, using them as a foundation to ensure consistent, high-quality development. The platform enables you to add new features to existing products, generate comprehensive documentation, and tackle technical debt by upgrading legacy systems to state-of-the-art technologies or refactoring complex codebases. Our platform deploys dedicated AI agents that map and understand your codebase before generation, ensuring intelligent, contextualized development that aligns with your existing patterns and standards.

What programming languages does Blitzy support?

toggle button

Blitzy's AI platform works with all programming languages.

How should I structure my prompts for Blitzy?

toggle button

Structure and organization are crucial when prompting Blitzy. The most effective prompts follow our prompting template with clear sections for WHY (vision & purpose), WHAT (core requirements), and HOW (technical details, user experience & implementation priorities). Each section should be detailed but concise, focusing on essential information while providing relevant context. Including structured frameworks and concrete examples - like data models, user stories, or feature templates - helps Blitzy deliver more precise and purposeful solutions.

What information does Blitzy need to compile and run my code?

toggle button

During code generation, Blitzy compiles your codebase and performs runtime validation to ensure the generated code works correctly. To enable this, we require: (1) Internal dependencies - any private packages, libraries, or binaries not publicly available that your code needs to build and run, (2) Environment variables and secrets - API keys, credentials, and configuration values required for compilation and runtime (shared securely through our encrypted UI, never exposed to AI agents), and (3) Build instructions - the specific steps or scripts needed to compile your code, typically found in your README or setup documentation. This information allows Blitzy to replicate your development environment and verify that all generated code functions properly before delivery.

How can I exclude certain files or folders from Blitzy's code generation?

toggle button

Create a .blitzyignore file in your repository's root directory to specify which files or paths Blitzy should exclude during tech-spec generation and code generation. This works similarly to .gitignore - simply list the file patterns, directories, or specific files you want Blitzy to skip, using standard gitignore syntax like *.log, /build/, or config/secrets.json. To ensure Blitzy respects these exclusions, mention in both your codebase context prompt and target state prompt that Blitzy should reference the .blitzyignore file and exclude those paths from processing.

Can I cancel my project/job (code gen) once in progress?

toggle button

At this time, jobs are not cancelable. Once you submit, it consumes the assigned quota.

Build enterprise software in days, not months.

Start buildingTalk to an expert
Blitzy

Blitzy

One Kendall Square,

Cambridge,

MA 02139

© 2026 Blitzy. All rights reserved

Product

  • Overview
  • Use-cases
  • Security
  • Pricing

Company

  • About us
  • Careers

Support

  • Help
  • Service status
  • Trust center

Resources

  • Docs
  • Blog
  • Videos

Social

  • YouTube
  • LinkedIn

Legal

  • Terms of use
  • Privacy policy