Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.trykode.xyz/llms.txt

Use this file to discover all available pages before exploring further.

kode golf is a competitive optimization command: you point it at a single source file, and it spins up three isolated git worktrees that each attempt a different optimization strategy in parallel. All three are benchmarked against the original baseline, and the version that shows the most improvement is offered to you for merge. If no strategy beats the baseline, your original code is left completely untouched.

​
How it works

1
Baseline measurement
2
Before generating any changes, Kode runs your benchmark command against the original file and records the results — ns/op, B/op, and allocs/op for each benchmark function. This is the bar every strategy must beat.
3
Three parallel strategies
4
Kode creates three isolated git worktrees and generates a separate optimized version of your file in each, using a different strategy prompt:
5
  • Concurrency — goroutines, channels, async patterns, and parallel fan-out to reduce wall-clock time
  • Memory — pre-allocation, stack-vs-heap placement, reduced copies, and buffer reuse to shrink allocation pressure
  • Algorithmic — Big-O reduction, hash-map lookups over linear scans, loop elimination, and early-exit conditions
    • 6
    Each strategy generates a set of structured hunks, passes them through the full verification gate (syntax, imports, calls, architecture), and only applies the hunks that pass. A strategy that fails verification is marked as failed and excluded from scoring.
    7
    Benchmarking and scoring
    8
    After the optimized code is applied in each worktree, Kode runs the benchmark command in each worktree and compares results against the baseline. A strategy’s score reflects how many benchmark functions improved and by how much.
    9
    Merge the winner
    10
    Kode prints a results table showing each strategy’s per-benchmark delta and asks whether you want to merge the winning version. If you decline, or if no strategy improved the baseline, your original file is left completely untouched.

    ​
    Usage

    kode golf internal/parser/parser.go

    ​
    Flags

    FlagDescriptionDefault
    --optimizeOptimization target: speed, memory, or complexityspeed
    --modelLLM model overridefrom kode.json
    --test-commandBenchmark commandauto-detected (go test -bench=. -benchmem)
    --project-dirProject root directorycurrent working directory

    ​
    Example output

    ── Code Golf ────────────────────────────────────────
  File: internal/parser/parser.go
  Target: speed | Strategies: concurrency, memory, algorithmic
  LLM: anthropic/claude-sonnet-4-6 | Test: go test -bench=. -benchmem

── Results ──────────────────────────────────────────
  Baseline — 3 benchmark(s)
    BenchmarkParse:      1842.00 ns/op (512 B/op, 8 allocs/op)
    BenchmarkParseJSON:   934.00 ns/op (256 B/op, 4 allocs/op)
    BenchmarkParseYAML:  3210.00 ns/op (1024 B/op, 16 allocs/op)

  ✓ concurrency (ghost-alpha) 👑 WINNER
    Improvement: +3/3 benchmarks (+100%)
      BenchmarkParse:      1104.00 ns/op [⬇ 40% faster]
      BenchmarkParseJSON:   701.00 ns/op [⬇ 25% faster]
      BenchmarkParseYAML:  1987.00 ns/op [⬇ 38% faster]

  ✓ memory (ghost-beta)
    Improvement: +1/3 benchmarks (+33%)
      BenchmarkParse:      1798.00 ns/op
      BenchmarkParseJSON:   880.00 ns/op [⬇  6% faster]
      BenchmarkParseYAML:  3310.00 ns/op [⬆  3% slower]

  ✗ algorithmic (ghost-gamma)
    Failed verification

✓ Winner: concurrency (ghost-alpha)
  Benchmark improvement: +100% of benchmarks

  Merge optimized version? [Y/n]:

    ​
    Best use cases

    Code Golf is most effective when you already suspect a specific file is a bottleneck:
    • Hot paths — a function that is called millions of times per request and shows up in profiles
    • Algorithms you know are slow — O(n²) loops, repeated string concatenation, linear searches over large slices
    • Memory-intensive data structures — caches, buffers, and pools that allocate on every call
    • Parsers and serializers — files that transform large inputs and are called on every request
    Avoid running Golf on files that are primarily I/O-bound (network calls, database queries) — the LLM-generated strategies optimise CPU and memory patterns and will not improve latency caused by external systems.

    ​
    Benchmark commands for non-Go projects

    The default benchmark command is go test -bench=. -benchmem. For other languages, pass --test-command with an equivalent: 
    kode golf --test-command "npm run bench" src/parser/index.ts
    The benchmark command must write results to stdout in a format Kode can parse. For Go this is automatic. For other runtimes, Kode reads raw stdout and compares the numeric throughput figures between runs — any benchmark framework that prints numbers works, but structured output (JSON, TAP) gives cleaner comparisons.
    Run kode plan --graph "<task>" on the file before golfing to understand its blast radius — how many other files import it and could be affected by a change. A file with a blast radius of 10+ is a good candidate for caution: the benchmark might improve but callers may rely on specific allocation behaviour or ordering that changes under the algorithmic strategy.

    ​
    Next steps

    Loop Mode

    Run the full pipeline with test execution, rollback, and multi-strategy Ghost Branches.

    Daemon Mode

    Let Kode watch your git history and proactively surface performance regressions as they accumulate.