Testing software that runs in someone else's cloud #
Most SaaS companies operate one primary production environment. When an enterprise customer requires software to run inside its own cloud account, the vendor must also build the machinery for deploying, updating, and monitoring that software across infrastructure it does not control.
Alien takes that work off software companies' plates. It helps them ship products into customers' AWS, Google Cloud, or Azure accounts while continuing to manage those deployments. Sensitive data and workloads remain inside the customer's environment without every vendor having to build its own customer-cloud platform.
By absorbing that complexity, Alien inherits a testing problem. Cloud provider is only one variable. A customer might deploy through CloudFormation, Terraform, a white-labeled CLI, or another model. Architectures and configurations differ. Each supported path adds another scenario that must keep working as Alien's product changes.
Alien's answer is a group of AI agents it calls Sims. A Sim is assigned a customer-like scenario, starts in a prepared environment, follows a task through the real product, and reports what happened. The Sims keep exercising Alien's deployment workflows in the background on Islo.
The test surface grows faster than scripts #
"The amount of things that you need to test quickly gets out of hand."
Alon Gubkin, founder and CEO of Alien
Traditional end-to-end tests remain useful. They are a good fit for known paths with deterministic inputs and expected outputs. The challenge is writing and maintaining one script for every meaningful combination as a product expands.
For Alien, those combinations span cloud platforms, deployment models, architectures, permissions, and configuration. Testing a scenario means more than checking whether a function returns the expected value. It means provisioning infrastructure, following a deployment workflow, and observing whether the experience works as a customer would encounter it. The pressure is especially visible in a platform whose job is to make software behave consistently across environments the vendor does not centrally own. A change that works in one deployment path may fail in another because a permission, infrastructure primitive, or operational assumption is different.
Alien wanted to complement its conventional tests with broader, user-shaped work: give an agent a real task, let it operate inside a real environment, and see whether it can complete the scenario from end to end.
Background agents need real engineering environments #
"I wanted agents that could actually operate like background workers, like background employees. Islo was the first one that really clicked."
Alon Gubkin, founder and CEO of Alien
The idea required more than launching a coding agent on a developer's laptop.
Alon wanted agents that could respond to signals from GitHub, support tickets, logs, and customer activity. An agent should be able to create an environment, build and test the relevant software, and keep working after the person who started the task moved on.
Alien tried several cloud-agent products. Some environments were not sufficient for its complex Rust workloads across multiple architectures. Some were slow. Secret handling was another obstacle.
Alien could have assembled the runtime internally on Kubernetes or another virtualization layer. The difficult part was not starting a handful of sandboxes. It was operating them as dependable infrastructure: allocating compute, keeping startup fast, pausing and resuming environments, preserving state, and providing controlled access to secrets.
That work would have pulled Alien's engineers away from the deployment platform they were building.
On Islo, each Sim runs in a persistent, isolated computer with the repository, tools, services, and state it needs. Alien defines the agents, scenarios, and product-specific tasks. The environment can remain available across the workflow and keep working without depending on a developer's laptop.
The first working Sim made the idea real #
"The first time I actually saw a Sim working, the experience was kind of magical. It replaces me actually doing a manual test. Not completely, obviously, but still, it's really impressive."
Alon Gubkin, founder and CEO of Alien
The important phrase is "not completely."
Sims do not eliminate deterministic end-to-end tests or human verification. They add another testing layer. A Sim can interpret a task, move through a workflow, and encounter the product as a user would. Existing tests still protect known contracts, and people still decide whether the evidence is good enough.
The first working Sim mattered because it completed a real test Alon would otherwise have performed himself. It turned the idea from a promising agent demo into an engineering workflow with an observable result.
Different Sims can now take on different scenarios. One might exercise a particular deployment model. Another might test user behavior or look for security issues. Together, they let Alien explore more of its test surface without requiring Alon or another engineer to manually execute every path.
From one trusted Sim to a software factory #
"Two years ago, a working software factory was basically a dream. Software factories are not fully mature yet, but they are getting close. Islo proved to us that they can actually work."
Alon Gubkin, founder and CEO of Alien
A software factory is a system that moves recurring engineering work through agents in prepared environments and returns evidence people can review. It is not one model doing everything. It is the environment, triggers, tasks, checks, feedback, and approval points that make the work dependable enough to run again.
Assaf Ben Josef describes a complete implementation, where work moves through planning, coding, review, verification, and feedback, in How we stopped working for our agents.
Alien's Sims are an early loop in that broader factory. They begin with a concrete environment and task, exercise the real system, and produce an observable result. Alien can add new workflows over time without treating every new agent as a separate experiment.
The practical starting point is deliberately narrow. Choose a workflow with a clear environment, a concrete task, and a result that can be observed. Give the agent a computer capable of running the real system. Keep deterministic tests and human judgment where they are strongest. Expand only after the first workflow earns trust.
Alien did not begin by trying to automate every test or every engineering decision. It began with a scenario Alon would otherwise run by hand. The first Sim worked well enough to make the next one worth building. Each new Sim adds another real path Alien can exercise in the background, and the factory grows one trusted workflow at a time.