Agentic Coding Track

What agentic coding actually is

The real distinction

Three different things get called "AI coding" and they are not the same tool wearing different skins.

The defining feature isn't "the AI writes code." Chat-assisted does that too. It's that the loop closes without a human in the middle of every iteration.

The loop, precisely

1. Perceive. Read the relevant files, run the build and tests, see the actual current state, not a description of it.
2. Plan. Decide the next concrete action given the goal and the current state.
3. Act. Call a tool: edit a file, run a command, search, run tests.
4. Observe. Read the real output of that action.
5. Repeat until the goal is met, a boundary is hit (max iterations, needs permission), or it's stuck and has to ask you.

This is not magic, and it is not reasoning the way a person reasons. It is a control loop.

The analogy: this is a game AI whose "game" is your codebase

You've built something structurally identical to this before, just in a different domain. An NPC or a bot that runs a sense to think to act cycle every tick: query the world state, run it through a behavior tree or state machine, execute an action, re-sense next tick. Agentic coding tools run that same loop, just slower, against a different world.

Which means the failure modes are ones you already know how to think about from AI programming. A bad world-state read produces a confidently wrong plan — exactly like a bot acting on stale perception data. A poorly-scoped action space produces thrashing. A missing feedback signal (no tests, no build step) means the loop can't tell success from failure, and it will confidently report both as success.

You are the level designer and the QA here. You decide what it can perceive, what it can touch, and what "success" is measured against.

That's the whole professional skill, and it's what Weeks 1 through 3 train.

Why this matters for how you'll learn it

Because the loop is mechanical, the way to get good at it is not "chat with it more." It's: control what it can see, control what it can do, and control how success is measured — then read its mistakes the way you'd read a bot's replay log. That's Week 1.

The landscape, honestly assessed

The 30-day track

Every week ends with something real: a document, a merged change, a small tested library, or a working piece of software — not a completed checklist. The exercises assume you have (or can get to) your Full Sail capstone repo (the Vulkan/C++ engine and gameplay/AI systems from Quantex Games) or an equivalent C++ project of a few hundred lines or more that you wrote and can verify against your own memory. If your original repo isn't handy, any real C++ project you've personally written works — the point is code where you, not the agent, are the ground truth.

# LIES_FILE.md

## Entry
- Date / session:
- Code under discussion:
- What it claimed:
- What is actually true:
- How confident it sounded (any hedge, or flat?):
- Category: confidently correct | confidently wrong | correctly hedged

make the renderer more configurable

FILE / FUNCTION:  the exact file and function to change

BEHAVIOR:         exactly what it should do afterward

CONSTRAINTS:      no new dependencies
                  must not change the public API

DEFINITION OF DONE:
                  what has to be true for this to be finished

add a new leaf node type

list_files(dir)
read_file(path)
apply_edit(path, new_content)
run_build()          # returns stdout / stderr

messages = [{"role": "user", "content": build_task_prompt(error_log)}]
for iteration in range(MAX_ITERATIONS):
    response = call_model(messages, tools=TOOL_SCHEMAS)
    if response.stop_reason == "tool_use":
        result = execute_tool(response.tool_call)   # your real function, not the model's
        log_iteration(iteration, response.tool_call, result)
        messages.append(tool_result_message(response.tool_call, result))
    else:
        log_final(response.text)
        break
else:
    log_final("Hit MAX_ITERATIONS without a clean build.")

The interview payload

Everything below is earned by finishing the track, not claimed on top of it. Fill in the specific library and tool names you actually used and built once you've named them.

Resume bullets

The gold fields are editable. Type your real numbers and names in, then copy the finished line straight into your resume.

• Built and shipped a C++ behavior-tree/state-machine library extending a Vulkan-based capstone engine, using agentic AI tooling under a self-imposed test-first and independent-verification process — completed in roughly a week what solo estimation put at .
  Copy bullet
• Designed and built a small autonomous coding agent — a tool-calling loop with a hard-scoped, explicitly guardrailed action set — that diagnoses and repairs real C++ build failures without human intervention.
  Copy bullet
• Systematically evaluated agentic coding tools against a real C++/Vulkan codebase, cataloguing failure modes (stale context, confidently wrong technical claims) to build a disciplined verification workflow — not just "used AI," built a process for trusting it correctly.
  Copy bullet

LinkedIn framing

• Headline addition. C++ / Systems Programmer — Vulkan, Game & Simulation AI, Agentic Tooling
  Copy
• About paragraph, direction. I build real-time systems in C++ — most recently a Vulkan renderer and the AI/state-machine systems for a shipped capstone game. I've also gone deep on agentic AI coding tools: not just using them, but building the verification discipline to trust them on production-grade code, and building a small autonomous agent of my own to understand the mechanism from the inside.
  Copy

Featured section: pin the Build Doctor demo video and a link to the behavior-tree library repo. A working demo beats a bullet point every time.

Interview questions you'll have earned

The honest limits

This section is what makes you credible in a room full of skeptical senior engineers, including the Ohio manufacturing and automation engineers you're likely to interview with, many of whom have good reason to be skeptical of anything that sounds like a pitch. Lead with this section in that room, not with Part 1's optimism. Naming the failure modes precisely earns more trust than enthusiasm does.

Where to go next

Ten questions. Answer from memory first.

Say your answer out loud or write it down before you open the real one. Then grade yourself honestly. The score is only useful if the grading is. Your read is at the bottom of this section and unlocks once all ten are graded. Nothing here is sent anywhere; it's saved in this browser so you can come back and beat it.

1. 01

   What's the actual technical difference between chat-assisted coding and agentic coding?

   Show the answer

   In chat-assisted coding, the model only produces text or code in a conversation; a human copies it in, runs it, and reports back what happened — the human closes every loop iteration. In agentic coding, the model is given tools (read/edit files, run commands, run tests) and closes the loop itself: it acts, observes the real result, and decides the next action, iterating without a human relaying each step.

2. 02

   In the sense-think-act framing, what plays the role of "world state," and what plays the role of the "reward signal"?

   Show the answer

   World state = the repo's actual current contents plus real command output (compiler messages, test results). Reward signal = the test suite, build, or linter — whatever tells the agent (and you) whether an action actually worked, versus merely looking plausible.

3. 03

   Why does a vague prompt reliably produce worse results than a scoped spec?

   Show the answer

   A vague prompt leaves the agent to guess your goal, constraints, and definition of success — and it guesses confidently rather than asking, so it optimizes for a plausible interpretation, not necessarily yours. A scoped spec removes the guessing, which is the single highest-leverage thing you control.

4. 04

   What makes a confidently-wrong agent answer more dangerous than an ordinary compiler error?

   Show the answer

   A compiler error tells you something is wrong. A confidently-wrong agent answer is fluent and structurally indistinguishable from a correct one — it carries no signal of its own uncertainty, so catching it depends entirely on your independent verification.

5. 05

   What is "test-first agentic," and why does it change what the agent can get away with?

   Show the answer

   Writing (or fully specifying) the test before the agent writes the implementation. It matters because the agent now has to satisfy a check you defined and can't quietly redefine, instead of you having to eyeball whether the output "looks right" after the fact.

6. 06

   In the "break your own context" exercise, why did the agent generate code against a stale assumption even though you had already changed the relevant file?

   Show the answer

   Because the agent's working knowledge is limited to what's actually in its current context or session. A change you made in reality isn't automatically visible to it. You have to put it in front of the model again, explicitly.

7. 07

   What's the difference between "using an agent" and "building an agent"?

   Show the answer

   Using one means working inside a loop someone else designed. Building one means defining the tool contract (exactly what it can perceive and touch), writing the loop that calls the model and executes its tool calls, and setting the guardrails yourself — you own the action space and the stop conditions, not just the prompt.

8. 08

   Name two reasons agentic coding tools are measurably weaker on a Vulkan, embedded, or real-time codebase than on a typical web app.

   Show the answer

   Any two of: training data is dominated by web and app code, so low-level and unusual-shape code is underrepresented; correctness often depends on constraints invisible from source text alone (GPU synchronization timing, memory layout, hardware behavior); feedback signals are weaker or slower — a race condition or a GPU validation issue may not surface in a quick test run the way a unit test failure does.

9. 09

   Give the weak version and the strong version of an answer to "how do you use AI in your work?"

   Show the answer

   Weak: "I use it to write code." Strong: names the actual process — where you use it (mechanical, decomposable work), what you verify and how (test-first, independent checks, a documented history of catching it wrong on your own code), and a concrete artifact that proves judgment rather than just usage.

10. 10

    Why is senior judgment still the binding constraint even once the tooling is excellent?

    Show the answer

    The loop can execute and iterate, but it can't yet reliably decide what's worth building, which tradeoff is right for a specific system, or whether a passing test suite actually proves correctness in a domain where some failures don't reliably show up in tests. That decision-making is the actual senior skill, and it's what 30 days of verification practice is training in you.