Case Studies on CodeInstances.com

How a Bug Report Can Arrive as a Runnable CodeInstances File

Sun, 18 Oct 2026 00:00:00 +0000

You maintain a command-line tool that talks to an online service. An issue comes in: “sync breaks against our account”. You don’t have their account. You can’t see their data. You ask for logs, then a bigger log, then a screen share, and after a week of back and forth you still haven’t seen the failure happen.

The reporter could send the failure itself. If they run your tool under CodeInstances, the run is kept as a file with every request your tool made and every answer their account gave back:

How CodeInstances Keeps the Failing Run of a Flaky CI Test

Sun, 18 Oct 2026 00:00:00 +0000

Here’s a situation most teams know. An integration test fails about one run in twenty. It calls an API that usually answers one way and occasionally answers another (a field missing, a list in a different order, a slow page that times out). Somebody hits rerun, it goes green, and the failure is gone. A week later it happens again, and the ticket still says “can’t reproduce”.

The trouble is that the one run worth looking at is the one nobody kept. Logs say the test failed. They don’t hold the answer that made it fail.

How to Develop Against a Metered or Rate Limited API With CodeInstances

Sun, 18 Oct 2026 00:00:00 +0000

Some APIs you can’t call as often as you’d like. A payments sandbox that throttles you after a burst. A maps or weather API billed per request. A partner’s staging server that falls over every afternoon. You’re working on the part of your program that handles the answers (the formatting, the error messages, the retry logic), and each try means another call you’d rather not make.

Record the program once against the real API, and work against the recording for the rest of the day:

How to Replay the AI Agent Run That Did Something Odd Last Night

Sun, 18 Oct 2026 00:00:00 +0000

An agent ran overnight on a batch of tasks. In the morning one result is wrong. It filed a ticket under the wrong customer, or summarised a document it never fetched, or called a tool twice. You run the agent on the same task to see what happened, and it does the job perfectly.

That’s normal for agents. The model’s answers vary from run to run, so the agent picks different tools in a different order and ends up somewhere else. Running it again doesn’t show you last night’s run. It shows you a new one. With an ordinary program, rerunning is how you debug. With an agent, the only copy of the run that went wrong is whatever you kept at the time.

How to Upgrade a Dependency With CodeInstances Replaying Real Runs

Sun, 18 Oct 2026 00:00:00 +0000

You need to bump something underneath your program. A new major version of the HTTP client library, a vendor’s SDK, or the Go toolchain itself. The changelog is long. Your unit tests pass, but they use mocks written two years ago against the old behaviour, so passing doesn’t tell you much. What you’d like to know is simple: does the program still do the same thing on real work?

Real runs answer that. Before the upgrade, record a handful of runs of the current build doing real work, against the real services: