Your first request

A small, self-contained request is the best way to get an honest first impression, something like fix the null pointer in checkout.py, then add a test for it. It is specific enough that you can judge the result, but small enough that a single turn covers it start to finish.

Watching this first turn happen is worth doing deliberately rather than skimming past: tCode reads the file before touching it, makes the edit, writes a test alongside it, and asks you to approve both before anything is saved. Once approved, it runs your test suite itself to confirm the fix actually holds rather than assuming it does.

The output ends with a short summary of exactly what happened, files read, files edited, whether the tests passed, described in full in Outputs. This same shape, read, propose, ask, verify, is what every subsequent turn looks like too, regardless of size.

It is worth actually reading both approval prompts in this first turn rather than reflexively approving them, specifically to see what the real detail looks like, the exact file path, the exact size of what is being written. That is the same level of detail every future prompt will show, so seeing it once deliberately builds a sense of what to expect.

If the fix or the test tCode proposes is not quite right, that is a completely normal outcome for a first try at a real request, not a sign anything is broken; see Correcting course mid-turn for the fastest way to steer it from there.