Introducing Rethrow

Introduction

Over the last four years, AI has made building software radically accessible. Anyone with an idea can now open a browser, describe what they want in plain language, and watch a working application take shape in hours instead of months. Andrej Karpathy, Co-founder of OpenAI and current pre-training research lead at Anthropic, called this new way of building software “vibe coding” in February 2025, and the term has since been added to the Merriam-Webster dictionary:

Vibe coding: the act or practice of using an artificial intelligence system to generate computer code in a given programming language.

A quick note before we go further: this post is a deeper, more technical look at what we are building. If you are a non-technical builder, you are not expected to know every term here. We think it is worth diving deep at least once, because it is the clearest way to understand what Rethrow is, how we are positioning the platform going forward, and why it matters.

Despite the efficiency gains of vibe coding, there is still a wide gap between a prototype that demos well and a workload capable of running in production, and that gap is where most vibe-coded apps stall. We call this the vibe coding cliff: the moment the excitement of watching your app take shape gives way to the feeling that the ground has dropped out from under you. Rethrow is building the bridge from the cliff to the cloud, whether you are migrating an existing app or starting a new one in Studio.

At launch, the platform will pair the simplicity of vibe coding with the ownership of production-grade cloud infrastructure, delivering a consistent, agent-orchestrated path where builders can both migrate an existing app and build something new, without becoming a cloud engineer in the process. We are also building Rethrow to be extensible from day one, with maximum support for source platforms, target platforms, and your preferred agent harness. This post is the story of how we got here, the problem we intend to solve over the next 2+ years, our core design principles, and where we are headed next.

How we got here

We’ve learned a lot in 2026. Here are some milestones as we wrap up Q3:

1. Dec 2025

   Presented at AWS re:Invent, then left AWS after more than five years as a Senior Solutions Architect to research and build software full-time.

2. Jan 2026

   Incorporated the company, set up the foundations, and started studying the latest AI capabilities and the limitations of traditional vibe-coding platforms.

3. Feb 2026

   Joined AWS Activate and dove into the emerging AI protocols shaping the modern tech stack, including MCP, ACP, A2A, and AP2, along with the growing ecosystem of commercial and open-source agent harnesses.

4. Mar 2026

   Participated in the AWS Global AI Hackathon, where thousands of builders worldwide used Amazon Bedrock, Bedrock AgentCore, and other native building blocks.

5. Apr 2026

   Exhibited at Startup Grind Global Conference in Palo Alto with a different product idea. During the conference, we kept meeting non-technical founders building on vibe-coding platforms who were struggling to reach production.

6. May 2026

   Pivoted and began building the agent-orchestrated migration engine. At the time we called the product Vibe2Cloud, which would later become Rethrow AI.

7. Jun 2026

   Joined the Launchpad Tech Ventures summer startup accelerator, where the vision expanded from agent-orchestrated migrations to also include a builder studio for shipping features against dedicated cloud infrastructure.

8. Jul 2026

   Accepted as an AWS Kiro Developer Ambassador and presented an early version of the agent-orchestrated migration architecture on a Kiro livestream, highlighting how we use Kiro CLI in headless (non-interactive) mode on ephemeral GitHub Actions Runners to facilitate AWS migrations using a deterministic agentic loop.

9. Aug 2026

   Graduated Launchpad and moved into Launchpad Ignite for ongoing advisory and go-to-market support, while continuing to build version one on AWS. Built the first version of Studio, a browser interface to vibe code against cloud infrastructure.

10. Sep 2026

    Vibe2Cloud rebrands as Rethrow AI, with extensibility as a core tenet at launch: multi-source, multi-target, and multi-harness. Began building the multi-harness control plane for Studio and extending target cloud support to all major cloud providers.

Why the name?

For most of Q2 and Q3, the product name was “Vibe2Cloud”, which was intentionally literal and described the first problem we wanted to solve: moving applications from vibe-coding platforms to cloud infrastructure. As the product evolved, the name started to feel narrow compared to the long-term vision.

After researching brand names we landed on Rethrow, which is derived from a programming concept developers should be familiar with. When software encounters an exception or error, code can be written to catch it, handle it, and then “rethrow” the exception so it keeps moving up the call stack instead of silently failing. In short, rethrows are an important path to debugging and remediating a broken system.

We liked the name, and the metaphor. A vibe-coded application reaches a point where the environment that helped it move quickly is no longer the environment it needs for the next stage on the scaling journey. That does not mean throwing the application away and starting over, it means taking what already works and moving it forward intentionally. The product should keep moving, the builder should keep building, and the underlying environment can (and should) evolve in the process. On our homepage, we illustrate this idea with a simple, programming-inspired snippet:

// your app outgrew the prototypetry {  yourApp.shipFast();} catch (OutgrewThePrototype e) {  rethrow(yourApp)    .onto(dedicatedCloud);   // AWS · GCP · Azure}

The try/catch metaphor behind the name Rethrow.

The vibe coding cliff

Let’s qualify the problem space we are operating in with real data. First, vibe coding is no longer a niche experiment. Developer adoption of AI coding tools now sits around 90%, roughly 41% of new code is AI-generated, and about 63% of the people building with these tools have no professional background in software engineering or cloud architecture. In Y Combinator’s Winter 2025 batch, a quarter of startups were already running on codebases that were roughly 95% AI-generated. Tens of millions of AI-built apps now exist, and the pace is accelerating by the month.

That accessibility is a genuinely good thing. But building the first version and operating a production system are different activities that demand different skills. A working MVP eventually runs into questions that never mattered in a demo:

• Who owns the infrastructure, and where does the source code live?
• How is the application deployed, and how do you roll back?
• How do you control networking, identity, encryption, logging, and access?
• What happens when traffic increases, or when you hit a platform rate limit?
• Can the architecture evolve, and can another engineer or agent pick it up later?
• What happens if you want to leave the platform you started on?

The stakes climb with adoption. Independent analyses have found that a large share of AI-generated code, by some measures close to half, fails basic security testing. Speed without ownership and guardrails is how a promising prototype quietly becomes a production liability. Rethrow exists to help builders cross that gap without giving up the speed that got them there. Our mission is simple:

Build fast. Own what comes next.

Today, a builder who outgrows a vibe-coding platform and needs to migrate to dedicated cloud infrastructure has two broad options, with a third (Rethrow) coming soon:

Three paths from prototype to production, and where Rethrow fits.

What we are building

At launch, there will be two primary ways to use Rethrow:

Migrate an application

At launch, a builder will be able to connect an existing application built on a supported source platform like Lovable, Replit, or Base44. Rethrow migration agents will assess the application, understand the current architecture, prepare the target environment, refactor what needs to change, deploy the application, validate the result, and guide the builder through launch, all in less than an hour. The goal is to turn what has traditionally been a highly manual and technical cloud migration engagement into a repeatable, agent-orchestrated workflow that is multi-source and multi-target from day one. Moving an MVP to the cloud should become as easy as a few clicks in the Rethrow console.

Build an application

With Rethrow Studio, builders will be able to continue developing an application after migrating, or start something completely new, through a familiar browser-based interface that looks and feels like the vibe coding environment they started on. They will be able to prompt, preview, iterate, and publish while the application runs against a dedicated cloud environment and source repository they control, with a fully managed deployment pipeline and a multi-harness control plane that makes the Studio experience truly extensible. While the platform will feel like vibe coding, you will have complete control of the underlying architecture and a powerful builder agent at your fingertips capable of supporting you on the scaling journey.

We are building both parts of the platform around six guiding principles. The first five make an application production-ready, while the sixth, extensibility, reduces friction, increases portability, and sets the company up for being adaptable to future technology shifts.

Principle 01: Ownership

Everything Rethrow produces to create and manage an application will belong to the customer. A migration will land a customer’s application in a dedicated cloud environment and source repository within their control, whether that is an AWS account, GCP project, Azure subscription, or OCI tenancy. After migration, if a customer subscribes to Studio, Rethrow builder agents will operate inside that cloud environment with time-bound and scoped credentials to deliver on expected responsibilities including ongoing deployments, authoring code, and architecture operations upon request.

By default, Rethrow will provision these environments in our cloud Organization to enforce broad architecture best practices and architectural consistency, however customers will be able to configure workspace settings that enable them to target cloud environments within an owned Organization if they prefer (e.g., their AWS Organization, not ours). With the latter model, Rethrow becomes a migration engine and/or a friendly builder interface and provisioning system that sits on top of their single or multi-cloud environment where workloads run.

Principle 02: Structure

Building fast does not have to mean building in an unstructured fashion. As part of every migration, and every app created in Studio, Rethrow will introduce the structure that production software demands: version-controlled source in Git, infrastructure defined as code using Terraform, repeatable deployment pipelines, agent steering guidance and guardrails, infrastructure monitoring and a resource inventory, ongoing architecture recommendations, cost visibility, and an agentic, spec-driven workflow that captures requirements, design, and tasks for more complex features that require auditability.

We do not expect customers to understand how all of this works, but it will be structured nonetheless. Rather than requiring customers to set all of this up from scratch, most of it will be managed by Rethrow and surfaced to customers via their Studio workspace, and as noted in Principle 1: the customer owns everything. We also intend to introduce features that allow customers to enforce standard architecture patterns and “blueprints” across their workspace (see Principle 03).

Principle 03: Scalability

By default, Rethrow takes an opinionated architecture approach and uses cost-efficient, serverless-first patterns (e.g. Lambda > EC2 and DynamoDB > RDS). This means customers will generally pay in proportion to real usage rather than for idle capacity. As traffic, data, and performance needs change, the underlying architecture can evolve based on their needs. For example, if a customer decides ECS tasks are preferred over Lambda functions for their compute logic to improve performance, their Rethrow agent will have the capabilities and permissions to evolve their architecture within Studio. For most builders starting out on Rethrow, a serverless-first architecture makes the most sense.

Later, we will add capabilities for organizations to set preferred and/or mandatory architecture patterns and “blueprints”, ensuring that builder agents operating within Rethrow Studio adhere to strict architecture requirements. Because the customer owns the cloud environment and it is not shared with other customer workloads, they are never boxed in by a multi-tenant platform where workloads are competing for the same underlying resources. Scaling becomes a property of the infrastructure they own, not a limit set by the platform they happened to start on.

Principle 04: Security

Production software demands real security controls and operational levers, and traditional vibe-coding platforms rarely expose them unless the customer upgrades to expensive Enterprise support plans. Rethrow builds on cloud-native primitives: managed identity, network boundaries, encryption in transit and at rest, least-privilege permissions, scoped credentials for agents, and logging the customer can audit. Since their workload runs in the cloud, customers will be able to optionally take advantage of cloud-native security services like WAF policies, threat detection, API logs, and more, all of which their agent can enable from within Studio on request. Agents that operate on a customer’s cloud infrastructure run inside deliberately narrow boundaries with scoped, short-term credentials specific to that cloud environment, so automation never becomes an open door. Security is treated as a default for every application, not an upgrade to buy later through enterprise support plans.

Principle 05: Reliability

Deployments and rollbacks should be fast, boring, consistent, and repeatable. Rethrow uses managed deployment pipelines, automated validation, and consistent build-and-verify loops for agentic operations, so changes are checked before they reach production and can be rolled back cleanly if something looks wrong. When a customer builds an application with Rethrow, their agent can optionally layer in other cloud capabilities to improve workload resilience posture, such as enabling point-in-time recovery backups for their database, versioning for their S3 buckets, cross-region data replication, and more. The intent is to have standard reliability best practices enabled by default and exposed to customers, with the option to layer in additional protections should they choose to do so.

Principle 06: Extensibility

Extensibility is the principle where we are spending most of our time right now, and we are designing Rethrow so builders have choices at every major boundary.

• Multi-source means Rethrow can ingest applications from multiple development environments and vibe-coding platforms rather than being tied to a single source ecosystem. At launch, we will support the major vibe-coding platforms where builders are already vibe coding and creating MVPs or prototypes to bring their ideas to life. If a customer’s application code lives in a GitHub or GitLab repository, our migration agents can take it from there.
• Multi-target means those applications can move onto the cloud environment that makes sense for the customer. Our current direction includes AWS, Google Cloud (GCP), Microsoft Azure, and Oracle Cloud Infrastructure (OCI) as supported target environments.
• Multi-harness is where the architecture gets especially interesting. At the time of writing we believe we are on track to provide one of the first multi-harness control planes for a vibe coding interface specifically suited for non-technical builders.

Most modern AI development products sit on top of an agent harness. The model itself provides intelligent responses, but the harness turns those responses into something capable of actually working on software. It provides the runtime around the model, including access to files, repositories, commands, tools, permissions, context, and sessions, along with protocols such as MCP and ACP that unlock extensibility.

There are now several strong harnesses in the market, and we do not believe Rethrow should build its own or assume that any single one will be the permanent answer for every customer. Kiro (developed by AWS) is our default harness and has played an important role in Rethrow’s development so far, but different builders and organizations already have relationships with different providers. Some teams may prefer Claude Code. Others may standardize on Codex, Cursor, Factory Droid, or Gemini CLI. Some builders will deliberately prefer open-source options like Goose. And, that’s expected.

We want Rethrow to accommodate the most popular agent harnesses, and intend to launch with a proprietary multi-harness control plane that lets Rethrow Studio work consistently across supported commercial and open-source agent harnesses. The product philosophy is simple:

Rethrow should remain consistent, even when the underlying agent changes.

At launch, customers will be able to securely connect credentials from a preferred provider and use that harness within their Rethrow workspace. For builders who do not want to configure anything, Rethrow will provide a default experience powered by the Kiro harness. This reduces another form of vendor lock-in, lets customers reuse tools and relationships they already have, and keeps Rethrow resilient as the agent ecosystem evolves. Our job is not to win the race to build the best coding agent, it is to build the production layer around those agents and make it easy for non-technical builders to run workloads in the cloud.

What's next

We still have a lot to build, but are making excellent progress. Our migration engine is already built and tested, and we’re over a month into developing the Studio experience. Most of our focus now is on the pieces that turn Rethrow into a complete, multi-tenant platform for launch: the multi-harness control plane that lets Studio run consistently across different agent harnesses, Rethrow Studio itself, and the surrounding systems for identity, billing, credentials, observability, and support that a platform like Rethrow needs to be successful.

One thing we are certain of is that the ecosystem will continue to evolve. Models, harnesses, protocols, developer preferences, and cloud requirements will all look different a year from now, just as they did a year ago. But the application still needs to run somewhere, and getting it from “works on a MVP platform” to “runs securely and reliably in production” will still be difficult, especially for non-technical builders.

The rest of 2026 is beta testing with early adopters, hardening security and scalability, and final testing, with a broader launch targeted for the start of 2027. We would rather take the time to build the architecture correctly than optimize prematurely for a launch date.

A marathon, not a sprint

In conclusion, we have spent all of 2026 researching the agentic landscape, experimenting with emerging tools, protocols, and capabilities, building Rethrow, talking to founders, evaluating cloud patterns, and trying to understand what the next generation of software development is actually going to require. The more time we spend on it, the more convinced I am that we are still very early...

• Vibe coding is changing who can create software.
• Agents are changing how software gets built, and who does what.
• Cloud infrastructure is becoming increasingly programmable.
• Protocols are making agents, tools, and environments interoperable.
• Rethrow sits somewhere in the middle of those trends.

We don’t expect to figure everything out in one release, and we view this as a marathon, not a sprint. The platform will evolve, the ecosystem will evolve, and some of the assumptions we hold today will probably change. That is part of building in a space moving this quickly. What we are trying to keep constant is the philosophy behind the product: builders should be able to move quickly without giving up control of what they create.

We are excited about what Rethrow is becoming, and we are committed to this vision for the foreseeable future. If the problem resonates with you, we’d love to chat!