ZylCode — Developer Preview

The Engineering OS that shows its work.

ZylCode is a developer preview being built to turn software-development instructions into verifiable engineering work — repository intelligence, approval-gated execution, and an evidence ledger behind every claim. It is in pre-release development, and its Developer Preview waitlist is open.

DevelopingPre-releaseWaitlist openJoin the Developer Preview View source
What it does

From instruction to reviewable deliverable

ZylCode is Zylvex's software creation platform: it understands a repository, plans the work, runs bounded agents against a defined task, and produces artefacts, tests and evidence a person can review. The point is not speed for its own sake — it is a change you can justify.

Working

Repository intelligence

Symbol and dependency navigation with 12 typed query methods, and index freshness (fresh, stale, reindexing) surfaced from the command line, the desktop application and HTTP — so the agent works from what the repository actually contains.

Working

Structured task graphs

The factory turns validated intent into durable, dependency-aware task graphs with persisted claims and human approval gates. A blocked gate stays blocked — it is never simulated away.

Working

Approval-gated execution

Agent work runs inside declared bounds: a defined task, a defined surface, a defined stopping point, and a person approving before anything irreversible happens.

Working

Tests and evidence

Tests run and their results are recorded, and every claim is backed by a hash-chained evidence ledger — so a reviewer can inspect what was checked instead of taking a summary on faith.

Working

Provider routing with failover

Requests walk the whole configured provider chain with failover before degrading offline, and can run on provider keys you supply yourself.

Working

A published capability grade

Every capability carries one explicit grade in a public registry, so partial work is reported as partial. That discipline is what lets this page be specific without overpromising.

How it works

The agent journey, end to end

One path runs through the whole product — the same journey the Developer Preview page lists as working and test-covered.

  1. 01

    Describe the task

    Start from an instruction in plain language — what should exist, or what should change.

  2. 02

    Gather ranked context

    ZylCode reads the repository and ranks the context the change actually touches — structure, conventions, dependencies — instead of flooding a prompt with the whole tree.

  3. 03

    Plan with explicit scope

    A structured plan states what will change and what stays out of scope, before any tool runs.

  4. 04

    Execute under approval

    Registered tools run inside their bounds and pause at human approval gates. Work that reaches a gate waits for a person.

  5. 05

    Verify

    Tests and configured checks run against the result, and their outcomes are recorded as evidence rather than summarised away.

  6. 06

    Review the artefacts

    You receive diffs, files and an evidence record to inspect. The output is an offer to review — a run nobody checked has not delivered anything.

One workstream inside ZylCode

N-ATLAS integration — component, not product

Natlas connects ZylCode to N-ATLAS, a Nigerian multilingual language model, as a first-class provider behind its own dedicated transport seam. It sits inside ZylCode rather than beside it: it is component architecture — one workstream, never the whole product.

What is built

A provider transport, configuration and authentication boundary, request and response handling, typed errors that are never coerced to success, intent interpretation into a validated task graph, and a factory handoff — with a developer SDK and an interactive playground alongside it.

What is verified

The architecture is implemented and covered by committed tests. A genuine N-ATLAS round trip was captured on 7 October 2026, and a controlled bridge endpoint was verified healthy on 8 October 2026. Endpoint capacity is quota-limited — a stated limit, not a claim that the integration is finished.

Why N-ATLAS specifically

Multilingual behaviour matters for Nigerian developer tooling, so the workstream includes a validation harness covering Yoruba and Nigerian Pidgin comprehension alongside English.

Competition history, stated exactly

The workstream prepared an entry for the public N-ATLAS Challenge, problem statement PS1 (Developer Infrastructure), under the Innovation & Enterprise track. On 8 October 2026 it reached a release candidate: its competition test suite passed 61 of 61 without credentials, and a beta tester quickstart was written so an outsider can reproduce the run. The submission window closed on 12 October 2026. No award, selection, endorsement or outcome is claimed, and this workstream does not make ZylCode generally available — it is not in the product user interface and no ZylCode download exists.

Technical architecture

A sequence of components, not a black box

The product is described as the components it is built from, in the order work flows through them — derived from the repository's public governance documents, its graded capability registry, and the Developer Preview page.

Surfaces

A desktop application, a command-line interface and an HTTP surface reach the same capability three ways. The product is local-first and evidence-first.

Repository index

Symbols and dependencies are indexed with freshness tracked per query surface, so context is retrieved — not guessed.

Factory task graphs

Durable job lifecycle and store: dependency-aware plans with persisted claims and approval gates that outlive a single session.

Agent loop

Prompt, context, plan, approval-gated tool execution, verification, completion — an explicit protocol rather than a free-running loop.

Tool runner

A registered catalogue of real, executable tools — runnable rather than mocked — invoked only within their declared bounds.

Evidence ledger

Each run records what happened in a hash-chained ledger, so capability claims can be traced back to something checkable.

Provider router

A configured provider chain walked with failover, including dedicated transport seams such as the N-ATLAS workstream below.

How capability is stated

Capability statuses are stated as tested, not as guarantees. Every capability carries one grade drawn from a fixed vocabulary in the public registry — implemented, partial, planned, or awaiting independent acceptance — nothing is recorded at a level its evidence does not support, and a blocked entry is never used as a synonym for finished. Test coverage, implementation and independent acceptance remain three different forms of evidence: passing tests shows behaviour is checked, never that a claim has been independently re-accepted.

Current status

Verified, limited, and not claimed

Status as at 19 October 2026, drawn from the public repository and the Developer Preview page.

Status badges on this page

  • WorkingImplemented and covered by committed tests.
  • LimitedImplemented, with the constraint stated beside it — such as unsigned installers or simulated computer-use automation.
  • Not implementedNot present in the current implementation; named only so the boundary is explicit.
  • Awaiting reviewClaimed, but awaiting independent acceptance — the registry keeps these entries disputed until re-acceptance closes.
  • Not yet availableNot offered: no general release, download, hosted service or published pricing.

Working and test-covered

Working
  • Agent journey: prompt to ranked context to plan to approval-gated execution to verified result.
  • Repository intelligence: typed queries and index freshness across CLI, app and HTTP.
  • Factory × Agent: durable task graphs with human approval gates and persisted claims.
  • Provider routing with full-chain failover, including bring-your-own-key setups.

Stated limits

Limited
  • Installers build locally (NSIS, DMG, DEB, RPM are configured) but are not signed — beta distribution carries operating-system warnings, stated plainly.
  • Computer-use automation is a disclosed simulation, not a live capability.

Awaiting review

Awaiting review
  • Independent re-acceptance of the repository-intelligence claims (Phase 2A) is open: the public registry keeps those entries disputed and itself under correction until re-acceptance closes.

Not claimed

Not yet available
  • No generally-available release, download or hosted service is offered from this site.
  • No pricing, no general-release date, and no certification is claimed.
  • No adoption figures, deployment counts or benchmark results are published.

The public capability registry

As at its audit of 16 September 2026, the repository's capability registry grades 37 capabilities: 22 green, 2 partial, 1 externally blocked and 12 disputed — and it declares itself under correction until independent re-acceptance closes. Inspect the registry on GitHub

Developer Preview

Join the Developer Preview waitlist

The preview is pre-release and invite-only. The waitlist is a first-party Zylvex page hosted outside this site: you leave an email address and hear back when preview seats open — nothing else is sent. Preview access is free; no pricing has been published.

The product detail on this page lives here and keeps working even if the preview page is unreachable.

Pre-release software: capability statuses are stated as tested, not as guarantees.

Questions

Frequently asked

What is ZylCode?

ZylCode is Zylvex's software creation and repository intelligence platform: it reads a repository, plans a change, executes tools under approval gates, and records tests and evidence so a person can review the result. It is in pre-release development alongside the other Zylvex products.

How is it different from a conventional coding assistant?

A conventional assistant ends at a suggestion. ZylCode starts from the repository itself — ranked context, an explicit plan and scope, tools that run only inside declared bounds, and approval before anything irreversible — then finishes with tests run and an evidence record you can inspect.

Is ZylCode released?

No. There is no download and no hosted service on this site. What exists is the Developer Preview waitlist: a first-party Zylvex page, linked from this page, where you can leave an email address to be contacted when invite-only preview seats open. Preview access is free; no pricing has been published.

How does N-ATLAS fit into it?

N-ATLAS, a Nigerian multilingual language model, is connected through Natlas — one integration workstream inside ZylCode with its own transport seam, developer SDK and playground. It is one workstream, never the whole product: the platform itself is repository intelligence, task graphs, approval-gated agents, tests and evidence.

Can developers inspect the source?

Yes. The repository is public on GitHub, including its governance documents and the graded capability registry. Capability statuses are stated as tested, not as guarantees.

How do I register interest?

Use the Developer Preview button on this page. The waitlist asks only for an email address and is hosted by Zylvex on its own page — this site collects nothing.

What should early users understand about its limits?

ZylCode is pre-release. Installers are built but unsigned, so operating systems will warn you; computer-use automation is a disclosed simulation; and independent re-acceptance of some repository-intelligence claims is still open. Nothing here is a fitness guarantee for production use.

Local ZylForge Technical Assistant

Explainable AI Assistant — Antigravity Philosophy for Physical Engineering