I Tried Turning an Android Phone Into a Real Development Machine

I’ve always found it a little strange that our phones are powerful enough to run increasingly capable AI models, but actually building software on them still feels like an afterthought.

You can open a terminal. You can SSH into a machine. You can use a cloud IDE. You can install Termux.

But none of these really feel like sitting down at a development workstation.

That’s what made me start building Atlan.

Atlan is an open-source, AI-native development environment designed around the idea that a phone should be able to do more than just display your code.

It should be able to work on it.

The idea was simple

I didn't want to build another mobile code editor.

There are already plenty of those.

I wanted something closer to a development cockpit.

Something where I could open my phone, pick a project, talk to an AI coding agent, see the application it's working on, inspect the terminal, review code, run autonomous jobs, build an APK, and jump into the underlying terminal whenever I wanted.

So the basic loop became:

Tell the agent what you want → let it work → see what it built → feed errors back to it → verify → ship.

And ideally, I shouldn't have to leave the same screen to do any of that.

What Atlan actually is

Atlan is a Node.js server with a browser-based PWA sitting on top of it.

On Android, the intended local setup is:

Android → Termux → Ubuntu proot → Node.js → Atlan

The interface is available locally at 127.0.0.1:4589.

That architecture might sound slightly ridiculous at first.

It is.

But it also gives us something interesting: the phone gets a real Linux userland underneath the UI, while Atlan can provide a much more approachable interface on top.

And you can still drop down to the actual terminal whenever you want.

The GUI isn't supposed to hide the machine from you.

It's supposed to make the machine easier to use.

The cockpit

The current interface is split into several pieces:

• Chat
• Preview
• Editor
• Terminal
• Fleet
• Build
• Doctor

There is also Atlan itself — a little canvas-rendered character that reacts to what's happening in the system.

It isn't just an animated mascot.

Its state is connected to the application.

When nothing is happening, it's calm.

When agents are running, it changes state.

When something needs attention, it can become alarmed.

When something finishes successfully, it can become proud.

It's a small thing, but I wanted the environment to feel like an actual place rather than a collection of disconnected developer utilities.

The part I care about most: the agent isn't just a chatbot

This was probably the biggest architectural decision.

Atlan doesn't treat AI as a text box where you ask questions about code.

The primary Claude integration uses the Claude Agent SDK and maintains a warm, persistent session.

That means the agent can actually work with the project:

• read files
• edit files
• run commands
• build things
• inspect errors
• interact with tools

And the session stays alive between turns.

That matters more than it sounds.

A cold-started CLI on every message is noticeably different from having a persistent development session.

The current implementation gets roughly 1.3 seconds to the first token on a warm session in my measurements, compared with roughly 7 seconds for a cold start.

That makes the whole thing feel much less like repeatedly launching an AI tool and much more like having an agent sitting inside the workspace.

But I didn't want Atlan to depend on one AI provider

Claude is the primary agent integration, but I wanted the rest of the system to stay relatively model-agnostic.

Atlan currently has two different concepts here.

There are agents that actually have hands, and there are brains that can provide model responses.

The agent side can work with tools such as:

• Claude Code
• Codex
• Gemini CLI
• and other CLI-based engines

Then there is an OpenAI-compatible adapter for API-based models.

That currently covers providers including:

• Gemini
• OpenAI
• DeepSeek
• Kimi
• Grok
• Mistral
• Groq
• Together
• OpenRouter
• Fireworks
• Cohere
• local llama-server

This distinction is intentional.

A model that can answer a question is not automatically an agent that can safely modify your project.

Atlan tries to make that distinction visible instead of pretending every model has the same capabilities.

Preview was another important piece

One of the most annoying parts of AI-assisted development is the feedback loop.

An agent changes something.

You run the application.

Something breaks.

You copy the error.

You paste it back into the agent.

Then you explain what you see.

Then you repeat.

I wanted to remove as much of that loop as possible.

Atlan's Preview tab can point at a local development server and display it inside the cockpit.

It also captures console output and errors.

Those errors can automatically become context for the next agent turn.

There is also a snapshot function that captures the application as a real PNG so a vision-capable agent can inspect what is actually on screen.

So instead of:

"Something is wrong with the button."

you can get closer to:

"Here's the application, here's the console error, and here's what the page currently looks like. Fix it."

That is a much more useful development loop.

And then there's the terminal

This sounds trivial, but I really didn't want the GUI to become a prison.

The terminal is backed by tmux.

Atlan renders that session using xterm.js, but you can also attach to the exact same tmux session from Termux.

So you can switch between:

Atlan UI ↔ Termux ↔ tmux

without abandoning the underlying environment.

If you don't like what the GUI is doing, you can just drop down to the terminal.

I think this is important for a developer tool.

A GUI should make things easier.

It shouldn't take away your escape hatch.

Fleet: letting agents work without you

This is where Atlan starts becoming less like an IDE and more like an orchestration environment.

Fleet lets you send jobs to autonomous agents.

You can give an agent a task, a budget, and a profile, then let it work while you do something else.

There are different worker profiles.

For example, Scout is deliberately read-only at the SDK tool level.

Builder and Verifier have more capabilities.

Every run has a token budget and a burn ledger.

There is also a KILL ALL button.

That last one is there for a reason.

I don't think autonomous agents should be treated as magical entities that you just unleash on a repository and hope for the best.

They need boundaries.

They need budgets.

And you need a very obvious way to stop everything.

The interesting part: deterministic verification

One thing I really wanted to avoid was asking an AI to judge another AI's work whenever we could avoid it.

So Atlan has a deterministic checker system.

A structured command can define things like:

• enums
• ranges
• regular expressions
• maximum lengths
• allowed values
• arithmetic relationships

The result is checked by code rather than another model.

For example, if an agent returns:

total = 37

and the input says:

quantity = 5

price = 7

the system doesn't need another AI to decide whether 37 is correct.

It can just calculate:

5 × 7 = 35

and reject the result.

This sounds obvious, but I think it's an important principle for agent systems:

Use models where judgment is required. Use deterministic code wherever judgment isn't required.

The worker hierarchy

That idea eventually grew into the worker hierarchy.

Instead of always throwing the most expensive model at every task, a job can move through different capability levels.

A simplified version looks like:

local model → cheap cloud model → frontier model

The cheaper model does the repetitive work.

Deterministic checkers verify what they can.

If something fails or requires stronger reasoning, the task can escalate.

This is basically the orchestrator-workers pattern, but applied inside the development environment.

The goal isn't to use the biggest model everywhere.

The goal is to use the cheapest model capable of doing each particular piece of work.

Building an Android APK from the same cockpit

This was one of those features that started as "this would be cool" and became surprisingly complicated.

Atlan has a Build tab that can run the Android build pipeline and produce an APK.

The build process has to deal with the fact that we're potentially running on ARM hardware while parts of the Android toolchain expect x86 binaries.

So the pipeline uses a qemu-based aapt2 shim.

The build logs stream back into the cockpit, and generated APKs get unique filenames and visible build stamps so Android's caching doesn't make you wonder whether you just installed an old build.

It isn't glamorous engineering.

But these are exactly the kinds of details that make the difference between a demo and something you can actually use.

Doctor exists because "it works on my machine" is especially bad on a phone

The environment has a lot of moving parts.

Node.

Termux.

proot.

tmux.

JDK.

Android SDK.

aapt2.

Claude authentication.

API keys.

local models.

voice providers.

disk space.

RAM.

So Atlan has a Doctor tab.

Instead of making the user discover every missing dependency through some random error later, Doctor checks the environment and tells you what is actually wrong.

It also separates health questions from security questions.

For example:

Can the agent run?

is a different question from:

How much of the device can the agent reach?

That distinction became increasingly important as Atlan grew.

Security is probably the least exciting part to demo

It's also one of the parts I spent a lot of time thinking about.

Atlan binds to loopback by default.

Authentication uses a password with scrypt hashing and an HTTP-only, SameSite session cookie.

API keys stored by Atlan are encrypted using AES-256-GCM.

The application has a Preflight gate that checks whether the instance is actually ready to be exposed.

And there is an important limitation that I don't want to hide:

Bash executed by autonomous workers is not OS-sandboxed when Atlan is running inside Android's proot environment.

The agent's tool profile can restrict what the SDK exposes, but that is not equivalent to a kernel-level sandbox.

I would rather put that sentence in the README and have someone understand the limitation than claim "secure sandboxing" because it sounds better.

On a native Linux host, Atlan can use stronger OS-level confinement where the kernel supports it.

On a phone running proot, the security model is different.

That's a distinction worth making explicit.

The boring stuff ended up mattering a lot

There are currently 838 automated assertions across 25 test suites.

The tests run against a throwaway instance rather than touching the user's real cockpit.

There is also a deliberate distinction between what CI can prove and what a real Android device can prove.

For example, the GitHub runner can't reproduce every property of an Android proot environment.

So the project doesn't pretend that a green CI badge proves everything.

That kind of honesty has become a bit of a design principle for Atlan.

If something is a roadmap item, it should say roadmap.

If something only works under certain conditions, it should say that.

If something isn't actually sandboxed, it should say that too.

It isn't really a "mobile IDE"

The more I worked on Atlan, the less I liked describing it that way.

A mobile IDE implies:

"VS Code, but smaller."

That's not what I'm trying to build.

The more interesting idea is:

What does software development look like when the AI agent is a first-class part of the development environment?

And then:

What happens when that environment lives on a device you carry everywhere?

That's a much more interesting question to me.

The phone becomes the interface.

The terminal is still there underneath.

The agent can work on the project.

The application can be previewed.

Errors can flow back into the agent.

Other agents can work on tasks.

The project can be built.

And when I want to take control, I can.

Where Atlan is right now

Atlan is still very much a work in progress.

The core cockpit is working.

Chat, streaming, persistent sessions, preview, terminal, editor, fleet runs, routines, model switching, APK builds, Doctor, authentication, voice, attachments and the worker hierarchy are all there in various degrees of maturity.

But there are still rough edges.

Android background-process limitations are real.

Low-RAM devices aren't going to magically become workstations.

Some features work better on a native Linux host than inside proot.

And there are still parts of the architecture I'd like to simplify.

That's actually why I'm putting it out there.

I don't want to keep building this in isolation until I decide it's "perfect."

I'd rather have people poke holes in it.

Tell me what's stupid.

Tell me what I got wrong.

Tell me which part you'd actually use and which part is just me being excited about my own architecture.

Why I'm making it open source

Atlan is Apache-2.0 licensed.

Each person runs their own instance, with their own credentials, projects and configuration.

There isn't a shared hosted Atlan account sitting between you and your code.

You can run it locally.

You can run it on a PC or server and use your phone as the client.

Or, if you have a capable Android phone, you can run the whole thing locally through Termux and proot.

That last option is probably the weirdest one.

It's also the one that originally made me want to build this.

What's next?

There are still a lot of things I want to explore.

Better agent orchestration.

Better mobile interaction.

More robust sandboxing on supported hosts.

Better multimodal workflows.

A smoother Android setup.

And eventually, making the whole thing feel less like "a web application running on a phone" and more like a native development environment that happens to live there.

I'm not sure exactly where the idea ends.

That's part of why I'm publishing it now.

If you're interested in AI coding agents, Termux, mobile development environments, local-first developer tools, or just the idea of carrying a development workstation in your pocket, I'd genuinely like to hear what you think.

Atlan is here:

https://github.com/Atlansdaddy/atlan

If you try it, I'd especially love to know:

What would you actually build with this if your development machine was your phone?