Co-founder @starslingdev 💫 Previously NFLX, META and many startups
Joined November 2012
- Tweets215
- Following645
- Followers843
- Likes324
Code verification is expanding in two directions.
1. Deterministic CI is becoming more precise and accurate.
Vibe coded unit tests will be replaced by formal verification methods like TLA+, SMT, BMC and Coq
If the state machine itself is executable, you don't need an agent to translate code to TLA+ to verify it. The runtime that executes it verifies it.
I'm working on something called UniKon (universal constructor, shortened the Japanese way): a multiplayer workshop where agents build apps that are malleable and self-improving as you (or agents) use them. Any agent can join over MCP, and they all work on the same state.
UniKon app runs on Temper runtime (by @nerdsane): every app is an executable statechart of policy-controlled state machines. Agents write them, Temper verifies and executes them.
Powered by @tensorlake for persistent scalable sandboxes, @tursodatabase for durable storage, with @datadoghq watching it all and paging @bot directly.
This is my factory for building UniKon, a bit meta, it itself is a UniKon app that runs the SDLC for UniKon. Every agent working on UniKon for me shares this app as a tool and keeps evolving it toward what it needs. It's a machine tool for tools, hence "universal constructor".`
Daniel Worku retweeted
Faster runners make CI jobs faster. They don't make you run fewer of them.
Where CI time actually goes (and the fix for each):
1. Compute: the job itself. Faster machines help here.
2. Waiting: queues from concurrency caps. A faster machine doesn't shorten a queue.
3. Setup: checkout, installs, cache restores. Shallow checkouts and warm caches.
4. Redundant work: runs for commits you already replaced, the full suite for a docs change. cancel-in-progress, path filters, affected tests only.
5. Idle time: fixed sleeps, healthchecks that wait on an open port instead of a ready database.
Most teams only fix #1. The bigger wins are usually in 2–5, and they live in your workflow files, not your hardware.
Levels of CI - a full guide for making your GitHub Actions cheaper and faster 👇🏾
Level 1: use Actions cache
cache every dependency install, keyed on the lockfile so it actually hits.
🔗 Docs: docs.github.com/en/actions/r…
🔗 Agent prompt: starsling.dev/best-practices…
Level 2: swap runners
get faster, cheaper machines by changing the runs-on label. Your workflows, triggers, and checks stay exactly as they are.
🔗 Runner comparison: starsling.dev/compare
🔗 Right-size runners: starsling.dev/best-practices…
🔗 Cut queue time: starsling.dev/best-practices…
🔗 Runners that automatically adapt: starsling.dev/blog/adaptive-…
Level 3: optimize your tests and workflows
cache dependencies and builds, split long suites across parallel jobs, skip work a change can't affect, cancel runs a newer push replaced.
Skills:
🔗 ci-speedup (@starslingdev): github.com/starslingdev/skil…
🔗 ci-cd-and-automation (@addyosmani): github.com/addyosmani/agent-…
🔗 test-audit (@steipete): github.com/openclaw/openclaw…
Posts and guides:
🔗 18 best practices (agent-friendly): starsling.dev/best-practices…
🔗 16 optimization recipes (agent-friendly): starsling.dev/github-actions…
🔗 Where your CI money goes (prompt): starsling.dev/github-actions…
🔗 Why your CI is slow (prompt): starsling.dev/github-actions…
Do all the above, or just let StarSling agents ship PRs like these for you: starsling.dev/products/runne…
Level 4: switch CI engines
Meta and Google built Buck2 (buck2.build) and Bazel (bazel.build) for aggressive caching and test selection, so each PR runs only the tests relevant to its change. A custom engine controls the whole execution layer, which gives you a much larger surface to optimize.
Options for engines:
🔗 Dagger (dagger.io)
🔗 Buildkite (buildkite.com)
🔗 Depot CI (depot.dev/products/ci)
🔗 CircleCI (circleci.com)
🔗 GitLab CI (docs.gitlab.com/ci/)
Level 5: throw out CI engines entirely
A few different approaches are being discussed that were never possible pre-AI. This is the future:
1. Agent-driven test selection.
"My plan is to let codex decide which tests actually need to run and drastically nix CI and run tests hourly." @steipete (xitter.cf/steipete/status/210430…)
2. CI after merge with auto-remediation.
"have something that is running actual functional tests off of your master branch on a cron, and then if any regressions occur, automatically have an LLM bisect and figure out the bug and then patch it..." @yacineMTB (xitter.cf/yacineMTB/status/21043…)
3. Agents replace CI: a verification agent that writes just-in-time tests for each change. @Meta's research: engineering.fb.com/2026/02/1…
Most teams are somewhere between Level 2 and 3. Figure out which level you're at and give your agent this full post:
starsling.dev/blog/levels-of…
Protip: buy a machine and self-host Github Actions, if you don't run lots of CI jobs concurrently.
My top picks for a mini under $3k are:
x64 - Minisforum w/ Ryzen 9 9950x3d
arm64 - Mac Mini w/ M5 Pro chip
We're always there when CI load or speed is too much for that.
We should start a GitHub Actions money challenge 💰
Tell your agent to make your CI faster with the skills and prompts on our website.
Anthropic's CI playbook (give this to your agent)
@AnthropicAI's CI jobs grew 25x in six months, so they built their own test selection system.
The same ideas work on GitHub Actions:
1. Run only affected tests: Anthropic picks each change's tests from past results and package relevance. On GHA, use the dependency graph from Turborepo, Nx, Bazel, Gradle, Vitest or Jest on PRs.
2. Keep the full suite where it counts: run everything on main and in the merge queue, so skipped tests still get caught before deploy.
3. Skip workflows a change can't affect: path filters, plus job-level ifs so required checks don't hang waiting.
4. Run CI once per change: drop the push + pull_request double trigger, and stop rerunning on things like PR title edits unless a check reads them.
5. Bound flaky jobs: a hung job can hold a runner for 6 hours by default. Set timeout-minutes from the job's own run history.
Anthropic's merges went from about 2,500 a day in May to over 30,000 in September, and their advice is to "assume your architecture will be at a 25x load within two quarters" 📈
Get these and 70+ more CI optimizations:
starsling.dev/blog/anthropic…
We are reaching an enlightened age of code verification.
I’ve said it before. Deterministic CI will focus on high-signal methods like formal verification, AST linters, perf profiling, etc.
Vibe coded unit tests are cooked.
pstack v0.15.27 ships with a new skill /create-formal-verification-skill!
it's still in beta, and similar to /create-verification-skill, this is a meta-skill that creates a new skill and formal verification suite based on the characteristics you want to verify. for example, you may want to model state machines and systems with concurrency using TLA+, or use kani in rust to check for undefined behavior.
if you're new to formal verification, think of it as mathematically proving properties and invariants (something that must always be true) or "laws" of your system. usually, this means modeling your programs in a separate language like with TLA+ and then running the solver on that spec. newer approaches like with kani and @bendlang take a different approach where there is no separate language: you write kani in rust, and bend in bend (it's also a programming language, and the proofs are written as laws and expressed in its type system).
historically formal verification never reached mainstream status because of the difficulty in modeling and writing proofs. it's quite difficult to model your business requirements and keep them in sync! but i expect that we will see more innovation in formal verification in the future as being able to formally verifiy that the code does what you intended gives your agents superpowers in writing correct software.
in the meantime though, i've been experimenting with modeling our code with TLA+ and have already found several bugs with the skill created by /create-formal-verification-skill.
try it out and let me know how it goes!
That feeling when you learn StarSling has GPU-based CI runners
starsling.dev/products/gpu-r…
Chinese bride gifts her partner a flagship GPU at wedding — he breaks down in tears
She handed him an ASUS ROG Astral RTX 5090 that costs around $12,000
The future of software is epic.
Introducing Adaptive Compute ⚡️
Up to 2.3x faster GitHub Actions, with no workflow changes.
Intelligent routing, instant failover and temporary resource boosts. (+25% vCPU and +50% RAM)
starsling.dev/blog/adaptive-…
Introducing Afterburner 🚀
It checks CPU and memory pressure every second and boosts the size of the VM running the job.
After pressure passes, resources return to the baseline.
Same Github Actions runner label. Same per-minute price.
The result: 1.53–2.32x faster than GitHub-hosted runners.
Public results using real CI tasks from the @mastra repo are linked in the post:
ALT Faster GitHub Actions at every price. Adaptive Compute, combining Afterburner and Sandbox Router, is 1.53–2.32× faster than GitHub-hosted runners in these benchmarks. Price per job versus runtime for 2, 4 and 8 vCPU runners: GitHub-hosted is white, StarSling Legacy is cyan, and StarSling (Adaptive Compute) is gold. Points are geometric means of median TypeScript and Rust results, n=5, October 13, 2026.
Daniel Worku retweeted
Notice how getting faster runners was just the first of 15 moves @linear made.
A lot of companies make the mistake of only swapping runners and then expecting the CI bottleneck to go away.
We take a different approach @starslingdev - faster runners is the foundation, with agents that then do the real work to optimize your actual tests and workflows.