Use cases

tCode is general-purpose: there is no fixed list of tasks it is limited to. The scenarios below are the ones that come up most naturally, grouped by the kind of work rather than by industry or language, since the underlying pattern, read first, propose a change, verify it, is the same regardless of what you are actually building.

Getting oriented in a codebase you did not write

Opening an unfamiliar repository and asking a direct question, "how does the retry logic in the API client work", "where does this app read its configuration from", gets an answer grounded in the actual code rather than in what a function's name suggests it probably does. tCode traces real call sites with grep before explaining anything, which matters most in codebases with history, where a name from an earlier design has outlived the behavior it originally described.

Turning an error into a fix

Pasting a stack trace or an error message directly into a prompt and asking tCode to resolve it works because it reads the actual file and the surrounding code the error points to, rather than pattern-matching on the error text alone. It can also run the code afterward, through bash, to confirm the fix holds instead of leaving that check to you.

Refactoring and renaming across files

A rename or a structural change that spans multiple files is exactly where doing it by hand risks quietly missing a caller three files away that never came up in the files you happened to have open. tCode searches the whole project for every reference before it starts editing, and shows you each edit for approval, so a change that touches a dozen call sites is still reviewable one file at a time rather than landing as one large, unexplained diff.

Writing tests for code that has none

Given a file with real logic but no coverage, tCode reads the implementation, writes tests against its actual behavior rather than an idealized version of what it should do, and then runs the suite itself through bash to confirm the new tests actually pass before handing them back to you.

Bringing outside context into the work

A bug report sitting in a Linear issue, a design decision buried in a Notion page, the original pull request that introduced the code you are now debugging on GitHub, all of this is normally a separate browser tab you have to keep switching to. The connector commands (see Connectors) pull a specific item directly into your next message, so tCode is working from the same information you are instead of you summarizing it by hand first.

Reviewing a change before it goes further

Before opening a pull request, asking tCode to look over the diff for the kind of thing a reviewer would flag, an inconsistent naming choice, a missing test for a new code path, an edge case the change quietly does not handle, catches issues while you still have full context on why you made each choice, rather than after a reviewer has to reconstruct that context from the diff alone.

Investigating a performance regression

"This endpoint got slower after last week's deploy" is exactly the kind of task where reading code and running it go hand in hand: tCode can compare the current implementation against what changed, form a hypothesis about where the added cost is coming from, and confirm it by actually running a timing check through bash rather than guessing from the code alone.

Working through a genuinely unfamiliar language or framework

Picking up a task in a language or framework you do not use often is where reading real, working examples from the same codebase, rather than generic documentation, matters most. tCode reads the actual conventions already established in your project and follows them, rather than defaulting to whatever is most common in the language generally, which keeps a change written by someone still learning the stack looking consistent with everything around it.

Exploring an idea before committing to it

Not every use of tCode has to result in a change landing in your project. Asking it to sketch out how a feature might be structured, or what a migration to a different library would actually involve touching, is a legitimate way to use it purely for exploration, especially combined with plan mode (see Plan mode), which produces a concrete plan you can evaluate without anything being written yet.