The @Polkadot Products Devnet is public.
Tokens have no real value. Chains can reset. You can build and experiment without consequence.
And people are already building some cool things on it.
. @Polkadot biggest opportunity may be making itself invisible.
Users shouldn’t need to understand XCM, JAM, or account models. They should just move assets, use apps, and transact seamlessly.
The best infrastructure hides its complexity.
That’s the real UX race.
DotCode progress update:
Over the past week we've been reworking the execution architecture behind DotCode.
Rather than treating the coding agent as a chatbot that occasionally calls tools, we've rebuilt the runtime around a supervised execution model inspired by the architecture used in today's most capable coding agents.
Several principles have been successfully carried over:
-The agent is treated as an event stream rather than a single response.
-Tool calls, terminal output, filesystem mutations, build logs, and model reasoning all exist as independent events.
-Execution state belongs to the runtime, not the model, and every failure becomes structured context that can be fed back into the agent for repair.
That separation is important, as our coding model should generate software, whilst the runtime should own execution.
Once we adopted that architecture, we started extending it specifically for DotCode:
-Generated projects are now verified before a session can complete.
-Build failures are automatically converted into repair prompts rather than terminating execution.
-Preview servers are health-checked beyond simply detecting an open port, with additional validation around module resolution, runtime imports, and application startup.
-Dependencies are installed by the runtime when required, long-running preview servers are managed independently of the model
-Execution continues even when the underlying model behaves inconsistently.
This matters because DotCode isn't tied to a single frontier model. Different coding models stream differently, expose tools differently, and occasionally report success before a project is actually working.
Instead of assuming perfect model behaviour, DotCode assumes mistakes will happen.
The runtime verifies execution, detects failures, generates repair context, and keeps the engineering session moving until the application reaches a working state.
The execution pipeline is converging on something that looks like this:
Prompt → Sandbox → Agent Event Stream → Tool Execution → Filesystem → Build Verification → Preview Health Checks → Repair Loop → Live Preview → Recoverable Session
The result is a coding environment that becomes progressively less dependent on perfect model behaviour:
-The agent can make mistakes.
-The runtime catches them.
-The session continues.
That's ultimately what DotCode is becoming.
A supervised, private software engineering runtime capable of writing, executing, verifying, repairing, and iterating on software entirely inside Dot's privacy boundary.