AI that writes code is the easy part. What matters is a change you can actually ship: built, tested — including on real hardware — and documented before a human ever looks at it. That's what we're building toward. First, what we already have.
What we have today
We've been working hands-on with AI tooling for years, long before it became a product category:
- Self-hosting AI models on our own infrastructure — models running on hardware we control, for use cases where sending source code or test data to a third-party API is not an option.
- Building MCP servers that connect agents to real tooling — build systems, test infrastructure, device labs — instead of demo-grade toy integrations.
- AI-assisted processes for developers and in CI — using AI where it produces verifiable results, wired into the pipeline rather than bolted onto the side of it.
This sits on top of over a decade of running exactly the kind of machinery an AI development platform needs: CI systems that receive events from source hosting, schedule work, run it on real hardware fleets, and report structured results back — in production, continuously, for years.
The distinction matters: these are not ideas on a roadmap. They are capabilities we operate today, and they are the reason we're not approaching agentic development as a clean start.
What we're building
On top of that foundation, we are building an agentic development platform. To be clear about what that means: this is a platform under active development, not a finished product you can buy off the shelf today. What we can offer right now is a genuine head start — the hard parts a clean start would have to solve first are already solved and running in production:
| A clean start would need to build | We already have, in production |
|---|---|
| Integration with source hosting (GitHub, GitLab, Gerrit, Bitbucket) | A decade of forge event integration and automated gating |
| Somewhere to run agent and test workloads | A hardware orchestrator with millions of test executions across shared device labs |
| Validation before review | Pipelines that build, test, and attach evidence to every change |
| A place for it all to run | Self-hosted infrastructure, on-premises, inside your governance boundary |
What remains to be built — the agent applications themselves, the session and review UX around them — is where our development effort is going.
Why we're building it
Every larger software organisation is asking the same question: how do we use AI in development without losing control? The available answers each fail differently:
- Hosted AI development platforms require your source code and credentials in someone else's cloud — a non-starter for regulated, defence-adjacent, or data-sovereignty-sensitive work.
- Assistants inside the editor change nothing about the process: code still arrives at review unvalidated. Worse, an assistant on an employee's machine acts with that employee's full reach — every file share, intranet system, and credential available to a corporate laptop. Nothing separates what the assistant may do from what the employee may do, and none of it leaves a trail your auditors can follow.
- "Vibe-coded" prototypes produce demos fast — that can't be trusted, can't be handed to engineering, and can't safely touch anything real.
The common failure: AI generates output; validation, review, and trust still run on humans.
Where it's heading
The valuable unit is not AI-written code. It is a validated change: built, tested — including on real hardware — and documented before a human ever looks at it.
Agents implement change requests end to end: they write the code, then do what a good engineer would do next — build it, test it on actual devices and in staging environments, iterate on failures, and open a review only once it holds up. The reviewer receives not a proposal to evaluate from scratch but a change with its evidence attached: test results, build logs, and where hardware is involved, captures from the device itself.
Machine effort is spent before human attention. Human attention is spent last, on changes that already hold up. That inversion is the entire economic argument.
Hardware: the difference evidence makes
This is where generic AI platforms stop, and where our experience lies. Software that talks to devices — mobile, embedded, industrial — is not validated by a container in a generic cloud. It is validated by the device.
Agents test on real devices and staging hardware with defined clean state for every run — not a bench device with three months of accumulated modifications. Results are reproducible and attributable to the change; device captures travel with the review. Access is granted per test run under your policies, and agent-initiated testing never interferes with your regular engineering schedule. This builds directly on Schedy, our hardware orchestration platform.
Governance, by design
- Gated promotion. Agents propose; humans approve — under the approval rules you already have.
- Confirmation, not replacement. Your existing CI remains the record of truth: agent validation happens before it, your pipeline confirms after it.
- Attribution throughout. Every agent action — from the first change request through every build, test run, and hardware validation to approval and merge — is attributable and auditable.
- Your perimeter. Hosted by us or on your premises, the trust boundary is identical: source, credentials, devices, and results stay inside it.
Where this stands
We're currentnly bringing the platform up in stages: first agentic code review with evidence, then agent-implemented change requests with pre-review validation. But that build order isn't fixed — the foundation below it is broadly useful, so the sensible starting point depends on what a customer actually needs. If your priority is a different slice of this, the sequence can be shaped around it.
If you're evaluating whether to invest in this direction, be skeptical of anyone offering it as a finished product. A real deployment always involves integration work regardless of vendor maturity: your forge, your hardware lab, your approval gates, your policies. Our claim is not that we have a ready solution — it's that the expensive foundations already exist and are proven in production, so the remaining work is spent on the actual product, not on rebuilding infrastructure underneath it. That's a materially different risk profile from a clean start, and it's the conversation we'd like to have with organisations that want to shape this rather than adopt it late.
Get in touch
Curious how AI fits into your CI or testing setup? Get in touch and tell us what you have in mind.