What Ivy does
Seven jobs, with the command that started each one, what the agent did, and what came out the other end. The first is a real transcript from the release check; the rest are the shape of everyday use, shortened.
Fix a failing test on a local model
A Go package with an off-by-one in Sum and a test that catches it. The model is qwen3:8b with a 32k context, on a laptop. This is the run we use to check every release.
ivy --local --model qwen3-32k --npa --print "The test in pkg/parse fails. Find the bug in Sum, fix it, and run go test ./... to confirm." → Glob **/Sum.go
→ Glob Sum
→ Read pkg/parse/parse_test.go
→ Edit pkg/parse/parse.go
✗ old_string was not found in pkg/parse/parse.go. Read the file to get its
exact current contents, then Edit with an exact snippet, or Write the file.
→ Read pkg/parse/parse.go
→ Edit pkg/parse/parse.go
→ Bash go test ./...
The test suite for pkg/parse now passes after fixing the Sum function. The loop
now correctly iterates from index 0 to include all elements in the slice.One line changed: the loop started at 1 and now starts at 0. The first Edit missed because the model reproduced the snippet from memory; the error steered it to read the file first, and the second Edit landed. Every model call went to localhost:11434.
Add a feature to a web app
A Next.js app with a login route and no protection against password guessing. Hosted mode, so the full pipeline plans with several frontier models and a judge picks the plan.
ivy "add rate limiting to the login endpoint: 5 attempts per IP per 15 minutes, 429 with Retry-After, and a test" PLAN 3 models drafting, judge picked: sliding window in the existing
in-memory limiter, keyed on IP, applied in the login route handler
ACTION Read src/lib/rate-limit.ts
ACTION Edit src/app/api/auth/login/route.ts
ACTION Write src/app/api/auth/login/route.test.ts
VERIFY Bash pnpm vitest run src/app/api/auth/login
✓ 4 passed
Done. 2 files changed, 1 created. $0.04.It found the limiter the app already had instead of adding a dependency, wired it into the route, wrote the test for the 6th attempt and the Retry-After header, and ran it. The cost is what the session cost, shown at the end.
A long migration, in the background
A Go service with 140 tests written against the standard library. The team wants testify. This takes a while, so it runs detached and the terminal can close.
ivy --endpoint http://gpu.internal:8000/v1 --model Qwen/Qwen2.5-Coder-32B-Instruct \
--detach "migrate every _test.go under ./internal to testify assert and require, keep behaviour identical, run go test ./... at the end"Task running in background (pid 48211, id 20260904-101512-a7f3c1).
Detach any time with Ctrl-C; reattach with: ivy --local --attach 20260904-101512-a7f3c1
→ Glob internal/**/*_test.go (38 files)
→ Bash go get github.com/stretchr/testify
→ Edit internal/parse/parse_test.go
→ Edit internal/auth/token_test.go
...
→ Bash go test ./...
ok internal/parse 0.31s
ok internal/auth 0.44s
...38 files edited, tests green, and the diff is in git for review. A detached task approves its own tool calls, so it is for work you would have accepted anyway; the snapshots are still there if you want any of it back.
Security review on an air-gapped box
A repository that cannot leave the building, a GPU server on the LAN serving a model through vLLM behind the company CA, and a developer workstation with no route out.
ivy --endpoint https://llm.corp.internal:8443/v1 --ca-cert /etc/ssl/corp-ca.pem \
--model llama-3.3-70b-instruct "review this service for injection, auth bypass and secrets in code. Write findings to REVIEW.md with file and line for each, most severe first. Do not change any code." → Grep (?i)(exec|query|sql)\(
→ Read internal/db/search.go
→ Grep os.Getenv|AKIA|BEGIN (RSA|EC) PRIVATE
→ Read cmd/server/main.go
→ Read internal/http/middleware/auth.go
→ Write REVIEW.md
Wrote REVIEW.md: 3 findings (1 high, 2 medium), each with file:line.Nothing left the network. The web tools were never called; if they had been, they would have failed and the review would have carried on. The findings file is the deliverable; the code is untouched because it was told not to touch it.
Fix lint in CI, unattended
A pipeline step that runs after the linter fails. Print mode, every tool approved, the model given by environment variable so the workflow file has no flags in it.
IVY_ENDPOINT=http://llm:8000/v1 IVY_MODEL=qwen2.5-coder-32b \
ivy --local --npa --print "golangci-lint reports the errors below. Fix them without changing behaviour, then run golangci-lint ./... again. $(golangci-lint run ./... 2>&1 | head -50)" → Read internal/api/handlers.go
→ Edit internal/api/handlers.go
→ Read internal/store/pg.go
→ Edit internal/store/pg.go
→ Bash golangci-lint run ./...
(no output)
Fixed 6 lint findings across 2 files; golangci-lint is clean.The step commits the result on a branch and opens a merge request. Ivy never pushes anything itself; the pipeline does, so the review stays with a person.
Two models, one plan
A tricky refactor where the plan matters more than the typing. The full pipeline's plan step runs both models and the first one judges between the two plans before any file is touched.
ivy --local --pipeline full --model qwen2.5-coder:32b,deepseek-coder-v2:16b \
"split the 900-line handlers.go into one file per resource without changing any route or behaviour" PLAN 2 candidates. Judge (qwen2.5-coder:32b) picked deepseek's plan:
move by resource, keep the router table in handlers.go, one
commit-sized step per file so tests run in between.
ACTION Write internal/api/users.go
ACTION Edit internal/api/handlers.go
ACTION Bash go test ./internal/api/...
...
VERIFY Bash go build ./... && go test ./...The plan the primary model would have written on its own moved everything at once; the one it chose from the other model ran tests between each file. You see the choice and the reason in the transcript before the first edit.
Explain a codebase you just inherited
No changes wanted. Just a map of how a thing works, written into the repo so the next person has it too.
ivy --local --model qwen2.5-coder:32b "explain how authentication works in this repo: where sessions are created, how they are checked on each request, where the vault key lives. Write it to docs/AUTH.md with file references. Do not change code." → Grep session|Session
→ Read src/lib/auth/lucia.ts
→ Read src/middleware.ts
→ Read src/lib/auth/vault.ts
→ Write docs/AUTH.md
Wrote docs/AUTH.md (1,900 words, 14 file references).A document with paths and line references you can click through, and the model never guessed: every claim in it came from a file it read in the transcript.