See if we fitBook a training

Research2026-08-15

How to become an AI coding expert in six months

Expertise here is not prompt knowledge. It is knowing what to hand an agent and what to keep.

Most of what you learn this year expires

Anyone trying to become an AI coding expert runs into the same trap early. They memorise the surface. Specific prompt phrasings, specific menu paths, the exact wording that made one model behave last spring. All of it decays with the next release. We have watched engineers rebuild their whole workflow twice in a year because they anchored on the tool instead of the technique.

The durable half is judgement. Which tasks are safe to delegate. How much context to give before the agent starts inventing. When to throw the diff away rather than fix it. Nobody has automated that yet.

The skills that compound

From training over a hundred engineering teams, the people who get genuinely good share four habits:

  • They write specifications, not requests. "Add caching" produces garbage. "Add an in-memory cache to getUserSettings, keyed by user id, invalidated on write, with a test for the invalidation path" produces something reviewable.
  • They keep the feedback loop tight. The agent runs the tests itself. If your agent cannot execute your test command, you are reviewing fiction.
  • They read every diff. Not skim. Read. The engineers who stopped reading are the ones who later cannot explain their own service during an incident.
  • They know their own codebase better than the agent does, and they treat that as the moat it is.

A six-month path that is not a certificate collection

Months one and two: bounded tasks in a repo you own, with tests. Grade the output yourself every time.

Months three and four: larger refactors and a real project instructions file. Learn where context runs out. Learn what happens when the agent hits a file it has never seen and confidently edits it anyway.

Months five and six: work with other people's agent output. Review it. Set the standard for your team. This is the part everyone skips and it is the part that turns a fast individual into someone worth listening to.

Where courses help and where they do not

A course can compress the first month into a day. That is real value. What a course cannot do is give you the repo scars, and it cannot answer the question that actually blocks teams: how do we let five engineers run agents against one service without drowning code review. We teach that because it is the thing nobody solves from a video.

Be sceptical of any programme promising expert status from a curriculum alone. Expertise here comes from volume of reviewed output, and no instructor can do that reviewing for you.

Do this next

Pick one repository. Commit to running every non-trivial change through an agent for thirty days, and to reading every line before it merges. Keep a text file of every wrong guess it made. Read that file at the end of the month. The pattern in it is your curriculum.