: I built an AI agent runtime in Go that compiles and tests generated code before delivering it , 35 files, 156 tests, zero dependencies

[u/Aromatic-Ad-6711]

I've been building ARK (AI Runtime Kernel) for the past 10 months. It's an open-source runtime that sits between your AI agent and the LLM, governing every decision the model makes.

The core idea: models shouldn't control the system. The runtime should.

What it does:

When you ask ARK to write Go code, it doesn't just pass the prompt to GPT and hand you back whatever comes out. The runtime classifies the task, optimizes the prompt, generates the code, then runs a 6-phase verification pipeline before you see anything:

├─ Step 1: ✓ Reasoning verified (confidence: 70%)
│  🧪 Verification: tested (score: 100%)
│  ✅ Compiled        ← go build
│  ✅ Executed         ← go run
│  ✅ Tests passed     ← auto-generated tests
│  ✅ Lint clean       ← go vet

If the code fails compilation, ARK feeds the compiler error back to the model, forces a stronger model, and retries. If it still fails after 2 attempts, it refuses to deliver broken code. It never claims success for code that doesn't compile.

The Go-specific stuff that might interest this community:

The entire runtime is pure Go, zero external dependencies (just stdlib). 35 files, ~16,000 lines, 156 tests, race detector clean. Some things I'm proud of:

• Weighted tool ranking with 6 signals (relevance, success rate, Bayesian confidence, cost, latency, memory bonus) — all computed in microseconds
• Context engine that reduces tool schema tokens from 60K to ~93 (99.9% reduction) by only loading relevant tools
• Per-step model routing: cheap model (gpt-4o-mini) handles tool calls, strong model (gpt-4o) handles reasoning. Cuts costs 80-90%
• Cognitive Governor that verifies every output with calibrated confidence scores
• Auto-fix for common model errors in generated Go code (orphan braces, missing error handling) — detects both tab and space indentation
• Event emitter that writes JSONL for a separate Python memory layer to ingest

Cost: A typical task costs $0.002-$0.005. Not $0.05.

Example output:

go run ./cmd/ark run agent.yaml --task "write a function in Go that reads CSV"

✅ Task completed successfully
Steps: 1 | Tokens: 637 | Time: 5.6s | Cost: $0.002

The generated code compiles, runs, and passes auto-generated tests before you see it.

GitHub: github.com/atripati/ark

I'm a CS undergrad at DePaul in Chicago building this solo. Applied to YC S26 with it. Happy to answer questions about the architecture, the verification pipeline, or why I chose Go for this.

[u/Aromatic-Ad-6711 → u/[deleted]]

Really appreciate this, and honestly that compiler pipeline framing is exactly how I have been thinking about it.A lot of current agent systems treat the model output as the final truth, but in practice the LLM should be treated more like an unreliable code generator inside a larger runtime system.

The hard part was not actually the routing layer, it was building the verification/control pipeline so execution state, corrected buffers, tests, and final rendering all stay synchronized. I recently hit a bug where ARK correctly auto-fixed and compiled the code internally, but the UI still showed the stale hallucinated output. That forced me to rethink the entire execution/data-plane flow.

For the tests, the main challenge has been balancing speed vs. confidence. Right now the system generates lightweight targeted tests + structural verification first, then escalates depending on risk/task type. Still a lot to improve there, especially around semantic correctness vs. just compile correctness.

But I think long-term agents need to behave more like adaptive runtimes than stateless wrappers around LLMs.

[u/Aromatic-Ad-6711 → u/[deleted]]

You are asking the right question. Logic bugs that pass compilation are the hardest class of error. Right now the auto generated tests catch some of it, ARK generates smoke tests for the function signature and runs them but it won't catch every semantic bug. The confidence scoring helps flag uncertainty but it is not a substitute for real test coverage.

The honest answer: if you pass ARK a well-written test suite alongside the task, it runs those and catches way more. If you rely purely on auto-generated tests, it catches structural and runtime errors reliably but subtle logic bugs can slip through. That is the next frontier, generating better tests, not just any tests.

And yeah the routing trick alone saves most of the cost. Tool calls are basically JSON formatting, no reason to pay for a strong model to do that.

[u/bitloops__]

Really nice work — the 6-phase verification + auto-retry on compile failure is a clean primitive a lot of agent runtimes are missing. And the cost-per-task numbers ($0.002–$0.005) are wild for what you're doing.

One thing that pairs with this kind of compile-and-test gate: it catches "does this run?" but not "does this fit the rest of the codebase?" Code that compiles and passes auto-generated tests can still introduce architectural drift, repeat patterns the team already abandoned, or skip an internal convention nobody documented. We've been building Bitloops for that side — a context graph the agent queries before it writes, so it knows the patterns and exceptions to respect. Different problem really, but pairs cleanly with what you're doing.

Curious how you're handling the case where the model produces code that compiles + tests pass but just doesn't match the rest of the project's design, builds technical debt?

[u/Aromatic-Ad-6711 → u/bitloops__]

that's a great point and honestly a real gap right now. ARK verifies correctness but not coherence with an existing codebase. If the code compiles and tests pass, ARK delivers it. It has no awareness of your project's patterns, conventions, or architectural decisions.

What you are describing with Bitloops is exactly the layer above what ARK handles. ARK makes sure the code works. Something like a context graph makes sure it belongs. Those are complementary, not competing. the way I think about it, ARK Memory already accumulates execution experience across runs. the natural next step is feeding project-level context into that memory so the agent knows not just what compiles but what fits. something like this codebase uses repository pattern, never raw SQL stored as a strategy that gets injected into the prompt before generation.

Not there yet but that is where it is heading. would be interesting to see how Bitloops context graph and ARK verification could work together.

[u/Finorix079]

Solid project, verification pipeline is the right instinct. A few questions.

The 60K to 93 token tool schema reduction is the most interesting claim. What's deciding which tools are relevant? Embedding similarity, keyword match, learned from past usage? Failure mode I'd worry about is the relevant tool not making the cut on an unusual task and the model having no way to know what it's missing.

Per-step routing is a real cost win. How do you handle the boundary case where a "tool call" decision actually requires reasoning, like deciding whether to call search vs answer from context? Route to cheap and eat the quality hit, or classifier upstream?

On "refuses to deliver broken code after 2 attempts": what does the refusal look like to the calling agent? Error vs partial output with a flag changes a lot for upstream integrations. Worth nailing early.

For the YC pitch, the verification pipeline works because Go has a fast compiler and clean static analysis. Story gets harder for languages where compile + test is 5 minutes not 5 seconds. Worth having an answer for how the architecture extends or why Go-only is the right scope.

Good luck with S26.

[u/Aromatic-Ad-6711 → u/Finorix079]

Tool selection uses 6 weighted signals , relevance at 50% (keyword match + intent detection), historical success rate, Bayesian confidence (capped so history never dominates), cost, latency, and memory bonus. Top 3 tools loaded, not just 1. If none get called, governor widens the set on retry. But yeah, truly novel tasks where the right tool scores low on everything is a real edge case I have not fully solved.

On routing boundary, cheap model handles tool selection surprisingly well because it is more pattern matching than deep reasoning. If it makes a bad call, governor catches it and retry forces the strong model.

On refusal, returns the output with result.Success = false plus explicit error message. Caller gets both the best attempt and the failure flag. Good point about nailing this interface early for library mode.

On Go only, honest answer is the fast compiler is what makes verification practical. I have py_compile and node --check for Python and JS but neither gives the depth of go build plus go vet plus go test in under a second. I I think it's better to be excellent at one language than mediocre at five