This article is not a launch announcement. It's a build-in-public note about what I'm building, why I chose this scope and what I'm deliberately leaving out.Aria is a family of two specialized coding agents: Aria Code for Next.js, Nest.js, and Node.js projects, and Aria Py for Python projects. Both are open source. Both are terminal-native. Both are built around one idea that I'll explain below.
- Both are open source.
- Both are terminal-native.
Both are built around one idea:
Predictable by default.
This is not a launch post. It’s a build-in-public note about what I’m building, why I chose this scope, and what I’m deliberately leaving out.
The core idea: predictable over smart
If I had to compress Aria’s design into one line, it would be this: Predictable over smart.
In practice, that means:
- every destructive action produces a preview before execution
- every destructive action supports --dry-run
- every destructive action supports --yes for automation and CI
- every action is logged locally
- destructive behavior is explicit, not hidden behind convenience
I want Aria to be fast enough to be useful, but transparent enough to be trusted. And one boundary matters more than any other:
Aria will never hide destructive actions behind automation.
For example, aria db migrate may help update schema.prisma, but it will never run Prisma migration commands against your database on your behalf.
- Not with --yes.
- Not with --force.
- Not ever.
If a command touches your database, production infrastructure, or anything else you cannot safely roll back with a normal code workflow, Aria should stop at the point where the user can still make the final call. That means:
- Aria can update files
- Aria can show diffs
- Aria can suggest the exact command to run
- Aria does not execute irreversible database migration commands for you
This is not because running migrations is technically difficult. It isn’t. It’s because the failure mode is too expensive:
“I lost data and I’m not sure why.” That is not a failure mode I want to build into a tool I use myself. What Aria will do differently. This is not a list of “features nobody else has.” Most of these ideas exist somewhere already. What matters is the combination and the defaults.Scope-honest, not universal. Aria Code is for:
Nest.js, Next.js, Prisma, Node.js
It is not trying to be the best tool for Ruby, Go, PHP, Rust, or Python. If you run it on a Python project, the answer should be simple: use Aria Py. Specialization is not a limitation here. It is what makes the prompts, tools, and repo understanding sharper.
Prisma-aware database assistance
Aria Code’s database features are intentionally scoped to Prisma. That means:
- aria db schema parses and renders schema.prisma
- aria db ask answers questions over the schema and can generate Prisma Client code
- aria db explain analyzes Prisma query usage in code and suggests performance improvements
- aria db migrate proposes changes to schema.prisma, previews them, and can apply file changes with confirmation
What it does not do:
- it does not run migration commands automatically
- it does not connect to your database
- it does not become a generic text-to-SQL assistant by default
A clean mutation contract across commands
Every command that can modify state should follow the same contract:
1. produce a mutation summary
2. preview the change
3. ask for confirmation unless explicitly bypassed
4. apply atomically
5. log the mutation
This should be true for:
- aria patch
- aria upgrade deps
- aria upgrade prisma
- aria db migrate
future mutation-capable commands.
Plan mode vs build mode
Some commands are read-only by design:
- aria ask
- aria plan
- aria review
- aria explore
These should run in a mode that cannot mutate anything, even if the model tries. Other commands can operate in build mode, but still under the preview and confirmation contract. This distinction should be enforced at runtime, not just described in docs.
Local history as part of the product
Every session should be written to a local SQLite history database. That is useful for:
- debugging
- traceability
- understanding why a command behaved a certain way
- answering “what did Aria actually do yesterday?”No hidden cloud state.
No telemetry requirement.
No vague “trust the agent” model.
Provider choice without provider chaos
Aria Code is designed to work with multiple providers from the start, including:
- Anthropic
- OpenAI
- Ollama
- MiMo
- MiniMax
- Mistral
- Qwen
- DeepSeek
OpenRouter-compatible models
That gives a practical mix of:
- premium hosted models
- local/private workflows
- cheaper or more accessible model options
- room for experimentation
The goal is not “support everything on day one.” The goal is provider flexibility without turning the product into provider chaos.
No cloud-hosted mode
Aria runs locally. No hosted workspace. No SaaS layer. No remote state.Links- Aria github.com/ariacodeai/- npm: @ariacode/cli- Site: ariacode.run
Aria is open source and MIT licensed.