ARC is a company building the tools that make spec-as-source development practical for backend teams on AWS. The ARC platform is a complete pipeline — you author a production-grade OpenAPI specification in ARCitect, then generate a working AWS backend from it with ARC Code Reactor.

The spec is the source of truth, the code is a build output, and everything downstream of the contract — handlers, infrastructure, tests, docs — is derived, not maintained.

Our goal is to allow teams to ship software quickly and confidently, without sacrificing quality. We do this by enabling creation of production-grade specs, solving spec drift, and automating the majority of foundational code that all backend systems require. For more on spec drift and how we solve it, see Spec-Driven Development →

ARCitect is the AI-native editor where your spec lives. It turns natural-language intent into validated, production-grade OpenAPI — catching inconsistencies as you work, keeping your data model and API contract in sync, and producing specs that Code Reactor can generate from cleanly.

You can start your first spec in minutes and have a production-grade document ready in about thirty. ARCitect validates in real time, surfaces drift before it compounds, and ensures the spec you hand off to Code Reactor is clean enough to generate from without iteration. ARCitect is currently in open beta.

Join the ARCitect beta →

ARC Code Reactor is the generation pipeline that turns validated specs into complete AWS backends in a single deterministic pass. One run produces TypeScript handlers, DynamoDB access patterns, CDK infrastructure, IAM configuration, contract tests, CI/CD pipelines, and documentation — all derived from the same spec, all regenerating together when the spec changes.

Spec-driven development is an approach where your API contract — typically an OpenAPI spec — is the single source of truth for your backend system, not a byproduct of it. Instead of writing code first and generating documentation afterward (if at all), you design and commit to your API interface before implementation begins.

The spec defines what endpoints exist, what they accept, what they return, what errors they produce, and under what authentication model they operate. Everything downstream — the implementation, the tests, the mocks, the SDKs, the documentation — is derived from that contract.

In practice, this means your openapi.yaml (or TypeSpec, or AsyncAPI, or Protobuf) is the artifact you version, review, and protect. It owns the source of truth for your interface layer. Code is generated or constrained by it — not the other way around.

Code-first means you write implementation code and generate a spec (or docs) from it afterward — through annotations, decorators, or introspection. The code is authoritative; the spec is a reflection.

Design-first means you author the spec explicitly before any implementation exists. The spec is authoritative; the code conforms to it.

Dimension	Code-First	Design-First
Source of truth	Implementation	Specification
API review surface	Code diffs	Spec diffs
Consumer contract	Emergent	Explicit
Drift risk	Low (spec regenerated)	High (if unenforced)
Design quality	Tends toward implementation shape	Tends toward consumer needs

Neither approach is universally superior. Code-first excels at speed; design-first excels at contract quality and consumer experience. ARC is designed for teams who have chosen design-first and need enforcement to make it stick.

Teams don't adopt spec-driven development all at once. There's a natural maturity progression, and each level closes a specific gap:

Level	Name	Gap Closed
Level 0	Spec-Adjacent	No gap closed — spec exists but isn't authoritative
Level 1	Design-First	Closes the design gap — spec is authored before code
Level 2	Contract-Enforced	Closes the drift gap — CI rejects divergence from the spec
Level 3	Source-Derived	Closes the authorship gap — implementation is generated from the spec

ARC is designed to bring teams to Level 3.

This is the most common objection — and it's worth taking seriously. Spec-authoring friction is real if you're writing raw YAML from scratch. The honest answer is: yes, there's an upfront cost, and it's worth it after the second integration.

A few things change that calculus:

• AI integrated spec editors streamline the process. ARCitect combines agentic workflows within an integrated IDE to easily write production-grade specs starting directly from natural language. The ARCitect agent helps you turn the next idea into spec, and the integrated IDE means no more painstakingly editing YAML files.
• Context orchestration and validation. ARCitect provides context orchestration at the system level, ensuring the entire spec is consistent and coherent. It does this by creating an internal model of the service and validating structured data. By combining structured validation with the ARCitect agent, we are able to guarantee that specs are valid.

It's also important to acknowledge one fact: this is not extra work.

You're paying the design cost anyway — at best, you're just paying for it in decreased dev velocity in code reviews and reverts, never-ending Slack threads, and Postman collections that rot. At worst, you are paying for it with cancelled projects or production outages. The spec just makes that design cost explicit and version-controlled.

Teams that have adopted spec-first consistently report that the initial investment pays off by the time they need to onboard a new consumer, write integration tests, or generate a client SDK. Those tasks go from multi-day efforts to near-zero-cost automation.

Spec drift is any gap between what your spec says your API does and what it actually does.

• a field documented as required is silently made optional in the handler
• an error response returns a different shape than the spec defines
• a query parameter is added to a route without updating the spec
• a schema type changes from string to number in the database layer but not in the contract

Spec drift is almost always architectural, not behavioral. Teams don't drift because they're careless — they drift because nothing in the development environment prevents it. Code and spec are separate artifacts maintained in parallel by separate humans. When velocity increases, the spec loses.

There are several common drift vectors:

• Response shape drift — a field is added or removed to API input/output without a spec update
• Business logic drift — business logic is modified, breaking previously reliable code
• Auth drift — security schemes evolve in the implementation while the spec stays frozen
• Error code drift — error responses in code differ from what the spec documents

Two forces collided in 2024–2025 that make this a watershed moment: agentic AI coding tools went mainstream, and API surface areas exploded as services became increasingly composable.

Tools like Cursor, GitHub Copilot, AWS Kiro, and Claude Code are now generating large volumes of implementation code — fast. The generation velocity is no longer the bottleneck. The correctness velocity is. When your AI agent writes a handler that diverges from your intended contract, that's a bug that's hard to catch without a ground-truth document to check against.

Additionally: modern architectures have more integration surfaces than ever. A single product might expose a public REST API, internal service APIs, webhook schemas, and event bus contracts. Without a spec-first discipline, each of those becomes a different team's undocumented assumption.

The old argument against spec-first was that it added friction. That friction now looks like structure, and structure is exactly what AI coding tools need to generate reliable output at scale.

This is where spec-driven development goes from "good practice" to force multiplier. AI coding agents are generative — they'll produce whatever output their context window suggests. Without a spec, that output is plausible-looking code that may or may not match your intended interface.

With a spec as context, the dynamic changes entirely:

• Your agent knows the exact request/response shapes before writing a single handler
• It knows what validation is required (required fields, enum constraints, format patterns)
• It knows what error codes to return and under what conditions
• It can generate test scaffolding from the contract directly, not from guesswork
• Contract tests can automatically verify the generated code against the spec

The opposite. AI code generation increases the need for spec-driven enforcement. When a model generates a handler, it produces code that plausibly satisfies the prompt — but plausible and spec-conformant are not the same thing. Without a contract and a CI gate, AI-generated code can drift from the spec just as quietly as hand-written code can, and at higher velocity.

Spec-driven development gives you a verifiable correctness criterion for generated code: the implementation either satisfies the contract or it doesn't. That binary property is precisely what makes AI-assisted generation safe to scale.

We believe in leveraging foundation models and agentic coding tools with the proper context orchestration and guard rails. This allows teams to ship quality quickly. Move fast, break nothing.

Discipline works until it doesn't, and "until it doesn't" tends to arrive at the worst possible time — usually a few weeks before launch, when deadline pressure is high and writing to the handler instead of to the spec is exactly what a tired engineer will do.

Spec drift is not a discipline problem. It's a problem that the architecture either prevents or tolerates. In a world where agents are generating more code faster than humans ever did, the tolerance version stops being viable.

Swagger UI renders your spec as documentation. Spec-driven development treats the spec as the system.

The difference is enforcement. In a pure documentation workflow, your implementation can silently diverge from the spec and ship to production. In a spec-driven workflow, divergence is a CI/CD pipeline failure — the build breaks, the PR can't merge.

The spec isn't a description of your API. It's the contract your code must satisfy on every commit.

Stoplight Studio, Apidog, Scalar, and similar tools are editors for authoring OpenAPI specs. ARCitect overlaps with them on authoring — you can use any of them to write a spec. The difference is what happens next.

Most OpenAPI editors stop at the spec. ARCitect treats the spec as the beginning of the work, not the end of it — it's the front end of a complete pipeline where the spec drives deterministic generation of a working backend. The editor isn't the product; the pipeline is.

These are general-purpose coding agents. They're excellent at what they do, and we use them. But at some point in any system you build, you have to validate that the code does what it's supposed to do — and you cannot chain prompts forever.

spec-kit is a parallel effort on making specifications executable, and we share the underlying thesis. We love projects that promote spec-driven development and help teams ship better software. The difference is scope and target:

• spec-kit is a general framework for the idea
• ARC is a specific pipeline for one stack — AWS serverless backends — and goes deep on that target in ways a general framework cannot

AWS Kiro is a spec-driven AI IDE that generates full-stack application scaffolding from specification documents — a development environment and code generation tool.

While AWS Kiro and ARCitect have similar purposes, there are key differences in implementation.

• ARCitect takes a more structured, validated approach to spec authoring by creating structured documents rather than one-off markdown documents
• Kiro routes code generation tasks to foundation models directly, while ARC leverages Code Reactor for deterministic code generation

Similar to spec-kit, Kiro competes in the AI-assisted development space broadly. ARC is a special purpose tool — making it the right choice when you need systems guaranteed to work, not general code generation.

Speakeasy and Stainless are SDK generators — they take an OpenAPI spec and produce idiomatic client SDKs in multiple languages. They solve the authorship gap for the consumer side of your API: making it easy to call your API, not to implement it.

ARC operates on the implementation side — generating and enforcing the server-side code that fulfills the contract. These aren't competing products; they're complementary. In a mature spec-driven pipeline, ARC generates your Lambda implementation and Speakeasy generates your client SDKs from the same spec.

Contract testing tools like Specmatic and Schemathesis validate that a running service conforms to its spec by exercising it with generated test cases.

• Contract testing is post-hoc — tests run against an implementation that already exists
• ARC enforcement is structural — implementation is generated from the spec, making divergence impossible at the source

ARCitect only requires one thing to get started: an idea. ARCitect will help you define everything you need for a production-grade spec, starting with features and requirements.

If you are further along and already have features or even a complete Product Requirements Document (PRD), ARCitect will use that as starting context.

TypeScript experience is recommended. ARC generates idiomatic TypeScript Lambda handlers — you'll be reading and customizing generated code as part of a normal workflow.

ARC is built for cloud-native backend APIs on AWS — the kind of system that leverages managed AWS services (Lambda, API Gateway, DynamoDB, S3, Secrets Manager) to serve a web app, a mobile app, or another service. If your project is an HTTP API with authenticated users, persistent data, and real business logic, ARC is designed for it.

ARC excels at creating these types of systems today:

• CRUD-heavy application backends — user accounts, content, orders, bookings, anything where most of the work is structured reads and writes against a well-defined data model
• Multi-tenant SaaS backends — tenant isolation, role-based access, API keys, the plumbing every B2B product needs and nobody wants to write from scratch
• Internal tools and admin APIs — back-office systems, dashboards, operational tooling, where correctness matters more than cleverness
• MVPs and prototypes that need to actually work — founder projects where the goal is validating the concept, which requires a login that works, a database that persists, and a deployment that doesn't fall over

If you're not sure whether your project fits, get in touch — we always want to hear from builders.

An ARCitect spec is the best starting point for any software project. The spec can be provided to agents and developers, allowing front-end and back-end teams to work towards a shared goal with a common understanding.

Talk to us. Migrating an existing API is a different use case from greenfield authoring, and we specifically want design partners who are interested in migrating large existing services — the work we'd do together would shape how ARCitect handles imports, reverse-engineering, and incremental adoption.

If you have a real API you want to bring under spec-as-source governance, that's a conversation we want to have.

ARC generates idiomatic TypeScript Lambda handlers organized around a clear architectural pattern. Generated code is readable, extensible, and annotated — not minified boilerplate you never want to touch.

The generated architecture separates concerns into distinct module categories:

• Models — data models with schema validation and access layer
• Operations — business logic wired to spec-defined operation handlers
• Routines — reusable functions for pre-condition checks, common interactions and transactions
• Utils — shared helpers and infrastructure primitives