An IDE that won’t take
the AI’s word for it.
Appvecta is an AI-native IDE for mobile engineering, starting with Android and Flutter — a VS Code-family editor, or an extension for the VS Code you already use. It learns how your project is connected, makes the change with your approval, builds and launches it on a real device, drives the real user flow, and reports what passed or failed.
No account · No telemetry in the alpha · Brain features work offline
Stage one of eight: the graph Appvecta builds by reading your code. From here it plans the change, runs it on a device and reports what happened. Concept illustration, not a screenshot of a released product.
How you get it
Phase one · Android (Kotlin/Java) · Flutter on Android
Further mobile platforms are planned after the alpha.
A branded IDE
A Code-OSS distribution — a VS Code-family editor — with the Appvecta extension built in and sensible defaults already set.
Or your own VS Code
The same extension runs in stock VS Code 1.103 or newer. The branded distribution adds branding and defaults; it never becomes required.
A local engine
A process on your machine doing the real work — scanning, the project graph, agents, device control, QA and reports. The editor talks to it over JSON-RPC.
An appvecta CLI
A small command-line tool for debugging and for running the same checks in CI.
Not an Android Studio replacement — no Layout Inspector, no advanced profilers, no Compose Preview and no complete Gradle project modelling.Read why
The loop
Understand, change, run, verify — without leaving the editor.
Appvecta is not an editor with an AI chat box added. It is designed as one closed loop, and every feature exists to keep that loop turning.
Stage 01
Understand
The Brain maps how the project is connected by reading the code — modules, screens, state, repositories, APIs, migrations and tests.
The loop is the product. Everything else supports it.
The problem
Shipping one small change touches eight different tools.
These activities are disconnected today. Appvecta connects them with a persistent, locally stored model of the project.
- 01Understand an unfamiliar architecture
- 02Find every file affected by a feature or bug
- 03Explain project context to an AI assistant, again, every session
- 04Switch between editor, terminal, Android Studio, emulator, logcat and test tools
- 05Tell an agent what to tap, one step at a time
- 06Reproduce failures manually
- 07Collect screenshots and logs by hand
- 08Confirm the AI-generated change did not break a different flow
Six named features
Six features, one closed loop.
The project graph is one of them, not the product. Each feature has a page of its own, written from the product specification rather than summarised from it.
Appvecta Impact
Know what a change breaks before you make it.
Ask for a field on a model and Appvecta is designed to answer with the blast radius, grouped by layer — and to keep what it parsed visually separate from what a model guessed.
- Room migration likely requiredconfidence 0.74
- Printer template may need a new columnconfidence 0.41
Appvecta QA
Evidence you can hand to somebody else.
Every step will record its intent, the selector it used, timings, screenshots, a UI hierarchy excerpt and the relevant log window. Failures are classified — not every failure is an app bug, and the report says which kind it is.
- Device
- Android 10 · API 29
- Variant
- debug · com.example.pos
- Commit
- a41f9c2 · tree dirty
- Result
- 6 passed · 1 flaky · 1 failed
- 1Launch app from a cold startam start -n …/.MainActivity3120ms
- 2Tap "Sign in"resource-id: btn_sign_in480ms
- 3Enter an invalid passwordresource-id: input_password910ms
- 4Assert the inline error is showntext: "Incorrect password"640ms
- 5Enter valid credentialsresource-id: input_password870ms
- 6Assert the ticket list loadstest-tag: ticket_list2260ms
- 7Tap the first tickettest-tag: ticket_row_0520ms
- 8Assert passengerType is renderedtest-tag: passenger_type1180ms
Step 8 · classified: assertion failure
Expected passenger_type to be present. Related components ranked by an impact query: TicketMapper, TicketScreen. Step 6 only passed on retry and is recorded as flaky, not passed.
Appvecta Agent
Bring your own model — or none at all.
The Brain, Run, Device Hub and QA are designed to work with no AI provider configured. When you do want an agent, Appvecta talks to the one you already pay for, through its official interface.
- Claude CodeYour installed, already-logged-in CLI, in its official non-interactive mode
- Codex CLIThe same contract, via its supported streaming interface
- API-compatibleAnthropic Messages, OpenAI-compatible (OpenAI, OpenRouter, Gemini-compatible)
- Ollama / localA local endpoint; degrades to plan-only mode if the model cannot call tools
- Appvecta-hostedLater, as one more provider behind the same interface
The subscription rule. Appvecta will use an existing subscription only through the provider’s own officially supported login or CLI. It never scrapes browser cookies, copies website session tokens, imitates private consumer endpoints, or asks you to paste browser credentials.
brain.search brain.definition brain.callers
brain.dependencies brain.featurePath brain.impact
brain.contextPackUse Appvecta from the agent you already use
The engine will expose the Brain as MCP tools, so Claude Code, Codex, Cursor and others can query your project graph with your own account, from outside Appvecta. These work with no AI provider configured in Appvecta at all.
Security posture
Local by default, and specific about it.
These are design commitments from the specification, not marketing adjectives. The security page has the rest.
Indexing never executes your code
Building the Brain reads files. It never runs Gradle, Flutter or a project script. Only Run, Build and Test execute build logic, and the interface says so first — enforced by an automated test that asserts zero build executions during indexing.
Local by default
The graph, QA plans, runs, evidence and reports live in a .appvecta/ folder in your workspace. There is no Appvecta server in the first release, and no account is required for any local feature.
No telemetry in the alpha
The alpha will ship with no telemetry and no crash reporting. Diagnostic bundles are user-initiated, redacted, and previewed before export.
| Category | Examples | Default |
|---|---|---|
| read-only | adb devices, getprop, file reads | automatic |
| build-test | Gradle assemble/test, flutter build, adb install, am start | automatic after Workspace Trust |
| file-write | patch apply, config write, QA plan save | automatic for one file; asks for multi-file |
| network | provider calls, driver download, dependency installs | asks |
| destructive | pm clear, uninstall, AVD delete, dependency changes, migrations, signing | always askscannot be auto-approved |
Phase 0 spike · 17–18 September 2026
What has actually been measured so far.
Everything else on this site is either an engineering target or a planned capability. These four numbers were observed.
8/8
Steps passed
A real QA run of an eight-step login flow on a physical Android device over USB, with a screenshot captured at every step.
53.6s
Flow duration
End to end, on an Android 10 (API 29) armeabi-v7a device.
176
Automated tests green
Across 29 files, including the extension ↔ engine JSON-RPC handshake verified in CI.
0.95
Detection confidence
Android and Flutter projects identified at 0.95 confidence, and an empty folder correctly returned unsupported — with no Gradle or Flutter execution.
The spike also verified the extension ↔ engine JSON-RPC handshake in CI, discovered a physical Android device over USB alongside a stopped AVD, and confirmed the branded IDE shell builds, launches and reports Appvecta in Help → About.
Who it is for
Built for people who ship mobile apps without a QA department.
Solo Android and Flutter developers
Already using AI coding agents, and tired of re-explaining the project every session.
Small mobile teams
No dedicated QA engineer, but still expected to ship evidence that a flow works.
Maintainers of unfamiliar code
Inheriting a legacy Kotlin or Java project and needing the feature paths fast.
Agencies
Repeatedly building and testing similar mobile workflows across client projects.
POS and enterprise-device teams
A later focus — Android hardware where a flow has to be proven on the device itself.
Release plan
Seven phases to a private alpha.
Phase 0 closed on 18 September 2026. The private alpha is targeted for January 2027.
Phase 0 · Closed
Spike
Closed 18 Sep 2026
Phase 1 · In progress
Foundation and Run
18 Sep – 11 Oct 2026
Phase 2 · Planned
Appvecta Brain v1
12 Oct – 1 Nov 2026
Phase 3 · Planned
Agent runtime
2 – 15 Nov 2026
Phase 4 · Planned
Tests and QA foundation
16 – 29 Nov 2026
Phase 5 · Planned
Guided QA and replay
30 Nov – 13 Dec 2026
Phase 6 · Planned
Hardening and alpha
14 Dec 2026 – 10 Jan 2027
Nothing has shipped yet. That is the honest version.
Appvecta is in active development. Private alpha invitations: the week of 11 January 2027. Registration is not open, and there is no waiting list to join on this site yet — everything above is what is being built, written in the tense it deserves.