Your AI Agent Is Coding. What Should You Be Doing?

You describe a feature, the agent starts planning, editing files and running tests — and suddenly you have a few minutes with nothing to do.

What you do with those minutes decides whether AI makes you a better engineer or just a busier one.

The obvious move is to open a second agent on a second task. Then a third. It feels like multiplying your output. In practice, it's usually where things start to go wrong.

The trap: more tasks in flight, less finished

Remember Little's Law from system design: work in progress = throughput × time in the system. It applies to people too. If you start more tasks than you can finish, you don't get more done — tasks just spend longer half-finished.

With several agent sessions running in parallel, you'll recognise the symptoms:

• Context switching. Every switch means reloading a different codebase, ticket and set of decisions into your head. That reload is where hours quietly disappear.
• Pull requests that go stale. Branches pile up, conflict with each other and wait days for review.
• Shallow reviews. When there are ten diffs to check, each gets a skim. Bugs that an agent introduced confidently are exactly the ones a skim misses.
• Decisions nobody owns. The agent chose a library, a schema, a retry policy. If you can't explain why, nobody on the team can.
• Burnout. Constant switching between half-understood tasks is exhausting, even when each task is "easy".

The fix is the same one teams use for any overloaded system: limit work in progress. One or two agent tasks at a time that you fully understand, instead of five you're juggling.

So what do you do while it runs?

Here's a practical list, roughly in order of payoff.

1. Write down what "done" means

Before or while the agent works, write the acceptance criteria and the tests you'd want to see:

• What inputs and edge cases matter? (empty lists, nulls, duplicate requests, timeouts)
• What must not change? (public API contracts, database schema, performance)
• How will you know it works in production? (a metric, a log line, an alert)

Agents are good at making tests pass. They're much less reliable at knowing which tests should exist. That judgement is your job — and a precise definition of done also makes your next prompt better.

2. Read the docs for what it's using — properly

If the agent reaches for @Transactional, CompletableFuture, Kafka consumer settings or a new library, read the official documentation for that feature instead of skimming for a snippet.

Deep reading pays back quickly:

• You catch wrong assumptions — like @Transactional silently not applying on a self-invocation, or volatile being used as if it made count++ atomic.
• You can steer the agent with precise instructions ("use thenCompose, not thenApply — the lookup returns a future") instead of vague ones.
• You build the understanding that interviews test and that no tool can fake for you.

3. Prepare to review the diff like a senior engineer

AI-generated code tends to fail in recognisable ways. Keep a checklist and actually go through it:

A small example of the kind of bug that passes a skim:

@Service
public class OrderService {

    public void placeOrder(Order order) {
        validate(order);
        saveWithAudit(order);   // self-call: the proxy is bypassed
    }

    @Transactional
    public void saveWithAudit(Order order) {
        orderRepository.save(order);
        auditRepository.save(AuditEntry.of(order));  // not atomic with the save above
    }
}

It compiles, the happy-path test passes, and the two writes are not in one transaction. A careful review catches it; a rushed one doesn't. The fix is to put @Transactional on placeOrder (called from outside the bean) or move the method to another bean — and this self-invocation trap is a classic Spring interview question.

4. Verify behaviour, not just green tests

While the agent finishes, set up the checks it can't do for you:

• Run the feature locally against realistic data.
• Look at the SQL it actually generates (enable SQL logging) — that's where N+1 problems show up.
• For anything on a hot path, measure latency before and after.
• Try the failure cases: the downstream service is down, the request arrives twice, the input is huge.

5. Pair with someone

Use the gap to talk to a colleague: walk them through what the agent is building, or ask them to look at your approach. Explaining a design out loud is the fastest way to find the part you don't actually understand. It also spreads knowledge — the thing that makes a team resilient when you're on holiday.

If you're more experienced, this is the best time to mentor: juniors learn far more from watching how you question an agent's output than from the output itself.

6. Write things down

A few minutes of writing is some of the highest-leverage work you can do:

• A short design note or ADR: what you decided, the alternatives, and why.
• A PR description that explains the why, so reviewers don't have to reverse-engineer it.
• Notes on what you learned — a new API, a surprising bug, a production incident.

Writing forces clear thinking, gives your team context the code can't, and builds a record of your work that's invaluable at review time and in interviews.

7. Invest in fundamentals

When there's nothing else pressing, practise what agents make it tempting to skip: data structures, concurrency, JVM internals, SQL, system design. These are what let you judge whether generated code is correct — and they're exactly what interviews still test, often without any AI allowed.

What not to do

• Don't start another agent task just because you can. Finish, review and merge first.
• Don't merge code you can't explain. If a reviewer asks "why this approach?", "the agent did it" isn't an answer.
• Don't let the agent define "done". It will declare success when its own tests pass.
• Don't stop reading error messages and stack traces yourself. Debugging skill fades fast when it's always delegated.

A simple routine that works

1. Plan (5–10 min): write the acceptance criteria and constraints; give the agent a precise task.
2. While it runs: read the docs for the parts it touches, prepare your review checklist, or pair.
3. Review (properly): go through the diff with the checklist; run it; test the failure cases.
4. Write (5 min): PR description or design note.
5. Merge, then start the next task. Keep work in progress small.

It feels slower than juggling five sessions. Over a week, it ships more working software — and you'll understand all of it.

Follow-up questions this topic invites — and their answers

Q: Interview question — "How do you use AI coding tools in your work?" A: Give a concrete, balanced answer: you use them to speed up well-defined tasks, you define acceptance criteria and constraints up front, you review every diff with a checklist (APIs, error handling, transactions, security, tests), you verify behaviour yourself, and you never merge code you can't explain.

Q: Why is running many agent sessions in parallel often slower overall? A: Because work in progress grows faster than you can review and integrate it. Context switching, merge conflicts and shallow reviews add delays and bugs, so each task takes longer to actually finish — Little's Law applied to your own workload.

Q: What are the most common problems in AI-generated Java code? A: Non-existent or deprecated APIs, swallowed exceptions and missing timeouts, unsafe Optional.get() and null handling, @Transactional that doesn't apply (self-invocation, private methods), N+1 queries, thread-safety issues, and tests that can't fail.

Q: How do you review AI-generated code efficiently? A: Read the tests first to see what was actually verified, then check the risky categories with a checklist, run the code, look at generated SQL and logs, and test failure paths. Spend the most time on transactions, concurrency, security and data access.

Q: Won't deep reading and writing slow me down? A: In the short term, a little. But understanding what the agent uses lets you give precise instructions and catch bugs before they reach production, which saves far more time than it costs.

Q: How do you keep your skills sharp when AI writes much of the code? A: Keep solving problems yourself regularly (DSA, debugging, system design), read documentation instead of only snippets, explain designs to others, and review generated code critically rather than accepting it.

Q: Should juniors use AI coding agents? A: Yes, as a learning aid — but they should be able to explain every line they commit, write some solutions without assistance, and have their work reviewed. Using the agent to explain code is often more valuable than using it to write code.