The JournalBuild Your Proof

Your first two hours with an AI coding agent

A practical walkthrough for moving from chat-style AI to an agentic coding tool: what to pick, what to ask for, and what to check before you trust it.

The ProoV Team··5 min read

If the only AI you have used so far is a chat window, an AI coding agent feels like a different animal the first time you try it. You are not copying answers out of a conversation anymore. You point it at a real codebase, give it a task, and it reads files, plans a change, writes code, and can run tests, across an entire repository, not just the file you happened to paste in. Here is how to spend your first two hours with one so that it actually teaches you something, rather than just producing code you do not understand.

Pick a small real repository, not a blank file

The instinct with a new tool is to start from nothing, a blank folder, "build me an app." Resist it. An empty project has no constraints, so the agent has nothing to be wrong about and you have nothing to check it against. A small, real, already-working repository is a far better starting point, because now there is existing behaviour you can compare against: does the code still do what it did before, plus the one thing you asked for?

If you do not have a repository of your own lying around, a prepared one with a graded outcome is a better first choice than a random project you find online, because you get a clear pass or fail signal at the end instead of just a feeling that it probably worked.

Give the agent one bounded task

Do not ask for "clean up this codebase" or "make this better." Both are true statements the agent can technically satisfy while doing almost anything, which makes them impossible to check. Ask for one specific, bounded thing instead: "this function returns the wrong total when the input list is empty, find out why and fix it," or "add a test that reproduces this bug before you fix it." A bounded task gives you a bounded diff to review, and a diff you can actually read is the entire point of this exercise.

Read every diff

This is the step people skip, and it is the one that matters most. When the agent finishes, it will show you a diff, the exact lines it changed. Read every one of them before you accept anything, the same way you would review a colleague's pull request. Ask yourself, for each change: do I understand why this line moved, and would I have made this exact change myself?

You will find lines you cannot justify. That is normal, and it is not a sign you picked the wrong tool. It is the agent optimising for "looks plausible" rather than "is definitely correct," which is exactly the gap a human is still needed to close.

The diff is not a formality to click past. Reading it is the entire skill.

Make it write tests, then break the tests on purpose

Once you have a change you are reasonably happy with, ask the agent to write a test that would catch the bug if it came back. Then do something slightly mischievous: reintroduce the original bug on purpose, by hand, and run the test suite again. If the test fails, it is actually doing its job. If it still passes, the test was decorative, and you have just learned something the agent's confident explanation did not tell you.

This one habit, breaking your own tests to see if they catch anything, will teach you more about what "AI-written tests" are actually worth than any amount of reading about it.

Keep a log of what you had to correct

Open a plain text file and, every time you catch the agent doing something wrong, write one line: what it got wrong, and what you changed. After two hours you will have a short list. Keep that list. It is not a record of the agent's failures, it is a record of what you noticed that it did not, and that noticing is the actual skill an employer is paying for when they hire someone to work alongside AI tools rather than instead of them.

Staying agnostic about the tool

Which agent you use matters less than doing this exercise properly with whichever one you pick. Most current agentic coding tools follow the same basic loop: read, plan, write, test. One option worth knowing about if you want to try a purpose-built one is IBM Bob, which offers a 30 day free trial and is built specifically for reading and modernising existing codebases rather than writing from scratch, which suits this exercise well.

Where to actually do this

If you want a repository that already has a graded outcome attached, rather than picking one at random and guessing whether you did well, the IBM Bobathon page walks you through exactly this exercise: a legacy repository, an AI agent, and a fix you verify against the repo's own acceptance script.

Your first two hours will not make you fast with an agent. It will make you able to tell when it is wrong, which is the part that actually holds up in an interview.

From ProoV

Prove this on a real project

You just read about the skill. These live briefs use real industry data and end in a certificate a recruiter can verify.

See all projects