Coding with AI assistants

How does your assistant see your code? Let's try to understand. In a simple way. Here is the surprise.

To the AI, your code is not code. It arrives as plain text, chopped into tokens, the same little pieces any sentence becomes. And the model never compiles that text. It never runs it.

There is no debugger inside. It simply reads, the same way it reads a news article. So what does it actually receive? Every time you ask something, your editor quietly builds one big prompt behind the scenes, and ships it to the model.

Into that prompt goes the file you have open. The lines you selected. Your question. And often, a few snippets pulled from related files.

That bundle is a snapshot, frozen at the moment you asked. The model reads that frozen copy. Not your living, changing project. And it is only a slice.

Files that never made it into the prompt simply do not exist for the model. It cannot peek at them on its own. One more thing. Your comments and your variable names are not decoration here.

To the model, they are text like everything else. Real signals it actually reads. This explains a lot. Ask about a function it was never shown, and it can only guess.

Open the right file first, and the same assistant suddenly looks brilliant. So, your assistant sees one thing. A prompt. Your code as plain text, packed by your editor, one frozen slice at a time.

Quick check now. One question is coming up. Let's see if it clicked.

How does AI code generation work? Let's try to understand. In a simple way. You type a request in plain English.

Sort this list by date. And seconds later, working code appears. It feels like magic. It is not.

Here is the secret. To the model, code is just text. A Python function and an English sentence are the same thing. Sequences of tokens.

During training, the model read billions of lines of public code. Tutorials, libraries, whole projects. Code that real programmers wrote and shared. From all that reading, it learned the patterns.

What a loop looks like. How a sort is written. Which code usually follows which comment. So when you type your request, the model does one thing.

It predicts the most likely next token. Then the next. Your English sets it on a path, and code flows out. Programmers use this daily.

Write a comment saying what a function should do, and the model completes it. In training data, comments sat right above the code that did the job. That is why wording matters. Say sort a list, and you get something generic.

Name the language, the inputs, and the edge cases, and the prediction locks onto exactly what you need. One catch. The model never runs the code it writes. It only predicts text that looks right.

So the final step is yours. Run it. So, plain English in, working code out. No magic.

A model that read mountains of code, predicting one token at a time, steered by your words. Quick check now. One question is coming up. Let's see if it clicked.

How does AI refactoring work? Let's try to understand. In a simple way. Refactoring means changing the shape of your code, without changing what it does.

Same behavior outside. Cleaner structure inside. That is the whole promise. So you select a messy function and ask the assistant.

Split this up. Rename these variables. Pull this block out into its own helper. Here is the surprise.

The assistant does not patch your code with rules. It writes a fresh version, predicting it one token at a time. What guides the rewrite? Training.

It has read millions of examples of tidy code. Your tangled loop matches patterns it has seen cleaned up before. And your old code never leaves the room. It sits in the context window, and every new line is generated while looking straight at it.

Now the catch. Nothing in the model proves the behavior stayed the same. The new version is a very strong guess. Not a guarantee.

Compare your editor's rename tool. It parses the code, so it is provably safe, but tiny. The AI can reshape whole files. Power without proof.

That is why tests are the safety net. Run them before the rewrite, and after. Green both times means the shape changed and the behavior did not. So, the assistant refactors by rewriting.

Old code as the anchor, clean patterns as the guide, and your tests as the judge. Quick check now. One question is coming up. Let's see if it clicked.

How does debugging with AI work? Let's try to understand. In a simple way. Here is the first thing to know.

Your assistant cannot run your code. It never sees the crash happen. It only sees what you paste into the chat. So debugging with AI is about handing over evidence.

Three things. The code. The error message. And what you expected to happen instead.

That error message is gold. A stack trace names the exact file and line where things blew up, and the path the program took to get there. From that evidence, the model forms a hypothesis. It has read millions of bug reports and their fixes.

Your crash matches patterns it has seen before. But a hypothesis needs testing, and the model has no hands. So you become the hands. You run the suggested fix, and report back what happened.

That is the loop. Evidence goes in. A hypothesis comes out. You run it, and the result becomes new evidence.

Every round narrows the search. No error message at all? Ask the model for print statements. The output you paste back becomes its eyes inside the running program.

One warning. A wrong hypothesis sounds exactly as confident as a right one. So the proof is never the explanation. The proof is the passing run.

So, finding bugs with AI is a partnership. You supply the evidence and run the code. It supplies the pattern memory. The loop does the rest.

Quick check now. One question is coming up. Let's see if it clicked.

Why does your coding assistant get confused? Let's try to understand. In a simple way. You ask for a small change.

The assistant renames the wrong function, or calls a helper that does not exist. It feels random. It is not. The assistant never sees your whole project.

It reads a limited window of text. Your open file, a few snippets, the recent chat. That is all. So when your real helper lives in a file outside that window, the assistant cannot know it exists.

It fills the gap with something that looks right. Second trap. You edit your code, but the old version still sits in the chat. Now the window holds two versions, and the assistant may blend them.

Long chats add a third trap. An instruction from twenty messages ago still sits in the window, quietly fighting the one you just gave. And vague requests confuse it too. Fix the date bug, you say.

Your project has three date functions. It picks the one that looks most likely. Here is the key mechanism. The model predicts the most likely next token, always.

A gap in its knowledge does not stop it. It just guesses, confidently. So the cure is simple. Open the right files, paste the current code, restate the rule that matters.

You are not talking to it. You are filling its window. Confusion is not stupidity. It is a gap between what you can see and what the model was shown.

Quick check now. One question is coming up. Let's see if it clicked.

How does AI test generation work? Let's try to understand. In a simple way. A unit test is tiny.

Call one function with a known input. Then assert the answer matches what you expected. That is the whole thing. Writing them is repetitive work.

The same shape, again and again. That is perfect food for a pattern machine. The model has read millions of test files. So how does it pick the cases?

It reads your function. The name, the arguments, the branches. Every if statement it finds becomes a path worth testing. Its favorite move is edge cases.

The empty list. Zero. A negative number. The boring cases you would skip, it lists without getting tired.

Now the trap. Where does the expected answer come from? Often, from your own code. The model runs the function in its head, and asserts whatever that gives.

See the danger? If your function has a bug, the test can lock it in. The buggy output becomes the official right answer. Green checkmarks, guarding a mistake.

The fix is simple. Check every expected value by hand. Even better, tell the model what the function should do. Intent goes in, honest asserts come out.

So split the work. You write the one tricky test that captures the real requirement. The model fills in the routine cases around it. Fast, and safe.

So, the model is a tireless test writer. It reads your function and lists the cases. But you own the expected answers. Check them before trusting the green.

Quick check now. One question is coming up. Let's see if it clicked.

How does AI bug spotting work? Let's try to understand. In a simple way. Here is the puzzle.

The model never runs your code. No debugger, no output. Yet you paste a function, and it points at a broken line. How?

The answer is in the training data. Millions of real bug fixes. Each one shows code before, and code after. The model learned what buggy code looks like.

Because most bugs are not unique. An off by one in a loop. A missing null check. A single equals where two belong.

Familiar shapes, seen thousands of times. There is a second trick. Your names and comments state an intent. Sort descending, says the name.

The body sorts ascending. The model flags the mismatch. It can also trace. Step through a small function line by line, in text, tracking each value like a careful reader with a pencil.

Underneath, it is all probability. Correct code is what the model expects to see. A bug is a line that surprises it. Low probability, loud alarm.

The blind spots follow from that. A bug that only appears with rare inputs, or bad timing, leaves no strange shape on the page. Reading alone cannot catch it. And the detector misfires the other way.

Correct but unusual code can look wrong. So treat every flag as a lead, not a verdict. So, the model spots bugs the way a well read reviewer does. Pattern memory, a promise check, and a careful trace.

No running required. Quick check now. One question is coming up. Let's see if it clicked.

What exactly is plausible but wrong code? Let's try to understand. In a simple way. Your assistant writes a function.

Clean names, tidy comments, perfect style. You nod and accept it. Then it fails. The code looked right.

It was wrong. Here is why. The model picks each next token by probability. So it writes the most likely looking code, not checked code.

Likely and correct usually agree. Not always. And nothing inside verifies it. The model does not run the code, or compile it, or test it.

It cannot tell working from almost working. One classic failure. It calls a library function that does not exist. Why?

Because a function like that should exist. The name fits the pattern. The library never had it. Another one.

Off by a detail. The loop stops one step early. The date math forgets leap years. Most of the pattern is right, and the last piece is the bug.

And here is the trap. Wrong code arrives in the same confident, polished style as right code. There is no shaky handwriting to warn you. Clean code lowers your guard.

You skim what looks professional. That is exactly how plausible but wrong code slips into real projects. So treat every suggestion as a draft. Run it.

Test it with edge cases. Check that the function even exists. Your tools do the checking the model never did. So, assistants write likely code, not verified code.

It always looks finished. Your job is the verifying. Quick check now. One question is coming up.

Let's see if it clicked.

How does AI write insecure code? Let's try to understand. In a simple way. Ask an AI assistant for a login page, and the code will usually run.

The page loads, the password checks. But code that runs is not code that is safe. Remember where the code comes from. The model learned from mountains of public code, tutorials, and forum answers.

When you ask, it predicts the most common way people wrote it. And the most common way is often the insecure way. Tutorials skip safety checks to keep the demo short. The model absorbed those shortcuts as normal.

One famous example. Building a database query by gluing user text straight into the command. If someone types commands instead of a name, the database obeys. That is injection.

Another one. Passwords and secret keys written directly in the code, because thousands of examples did exactly that. Here is the dangerous part. Insecure code passes every normal test.

It only fails when someone attacks it. So nothing ever looks broken. And your prompt matters. If you only ask for working code, the model aims at working.

Safe was never part of the request. The fix has two parts. Name the threat in your prompt. Then review the code like a stranger wrote it.

Because, in a way, thousands of strangers did. So, the assistant imitates the crowd, the crowd takes shortcuts, and attacks stay invisible in tests. Let it write code. Check it before you trust it.

Quick check now. One question is coming up. Let's see if it clicked.

How does teaching your assistant your coding style work? Let's try to understand. In a simple way. You ask for a small function.

The code works, but it does not look like yours. Different names, different spacing, patterns your team would never allow. Every team has a house style. How you name things, how you handle errors, which patterns are welcome and which are banned.

Here is the key. An assistant writes by imitating whatever sits in its context window. So to teach it your style, you put your style in front of its eyes. The first tool is a rules file.

A short document of standing instructions. Use these names. Avoid that pattern. It is quietly pasted in front of every single request.

The second tool is examples. Show it two or three files of real code from your project. Prediction is pattern matching, so new code comes out shaped like the old. And examples usually beat descriptions.

Saying, write clean code, is vague. A real file pins down a hundred tiny choices at once. One catch. When you correct the assistant in chat, nothing is saved.

The model's weights never change. Close the chat and the lesson is gone. So the fix is simple. Every time you repeat a correction, move it into the rules file.

That is the only memory that survives. So, style is taught through context, not training. A rules file for the rules, real code for the feel, and it writes like your team. Quick check now.

One question is coming up. Let's see if it clicked.

What exactly is a coding agent? Let's try to understand. In a simple way. A normal assistant works in one shot.

You ask, it predicts one answer, and it stops. If the code is broken, that is your problem now. An agent is different. It is the same model, but wrapped in a loop.

Write some code. Run it. Read what happened. Then decide the next step.

Here is the mechanism. Whatever the code prints, errors included, is pasted back into the model's context. So the next prediction is based on real results, not guesses. That changes everything.

The model sees the exact error message, writes a fix, and runs it again. Round after round, without you in the middle. So when does it stop? It follows a stop rule.

Usually, the tests pass, or the goal is met. Until then, the loop keeps turning. One request from you can become dozens of steps. Open a file, edit it, run the tests, fail, edit again.

You only see the finish line. Your own job changes too. You are not typing the code anymore. You describe the outcome, then you review what comes back.

From author to editor. One warning. Each step builds on the last one. So a small early mistake can steer the whole run off course.

A longer leash means more drift. So, an agent is a model in a loop. Write, run, read, fix, repeat, until a stop rule says done. It codes, and it checks, by itself.

Quick check now. One question is coming up. Let's see if it clicked.

What exactly is a tool call? Let's try to understand. In a simple way. Here is the surprise.

A language model, on its own, can only do one thing. Produce text. It cannot open a file, run a test, or touch the internet. A tool fixes that.

A tool is a named action your software offers to the model. Read this file. Run the tests. Search the web.

Each one has a short description. Now the key mechanism. The model never runs anything itself. Instead, it writes a structured request.

The tool's name, plus the arguments. Like, run tests, in the source folder. Your software catches that request, and it does the actual work. Real command, real machine, real result.

The model just waits. Then the result is pasted back into the conversation, as plain text. The model reads it, and carries on. That round trip is one tool call.

So when your assistant seems to read your code, that is what happened. A request went out, and text came back. How does it choose a tool? The whole menu sits in its context, descriptions included.

It predicts which action fits your request. So a vague description leads to wrong picks. And here is the quiet benefit. The menu is also a fence.

No delete tool means no deleting. The model can only ask for what you chose to offer. So, tools turn a talker into a doer. The model asks, your software acts, and the result flows back as text.

That is the whole trick. Quick check now. One question is coming up. Let's see if it clicked.

What exactly is an agent's mission? Let's try to understand. In a simple way. An AI agent runs on its own.

You do not hand it a list of steps. You hand it an outcome. The mission is a goal, stated as the result you want. A vague mission gives it nowhere to aim.

Make the app better, you say. It wanders, or it stops early and calls a half done job finished. So a good mission names a concrete outcome. Not improve the page.

Instead, the login page loads in under one second. Here is the most important part. A way to check when it is done. A test the agent can run by itself.

If it passes, the mission is finished. Now the agent can steer. It plans, it acts, it checks the result against that finish line, and it repeats until the check finally passes. A mission also carries guardrails.

The things it must not touch. Do not change the database. Keep the existing tests green. One catch.

The finish line has to be checkable by a machine. Tests pass. A file exists. Output matches.

Looks good is not a finish line. A giant fuzzy mission has no clear end. So break it into smaller missions. Each one gets its own check, and they get done one at a time.

So a mission is an outcome plus a test for done. Give the agent a finish line it can see, and it will find its own way there. Quick check now. One question is coming up.

Let's see if it clicked.

What exactly is the right move when your agent fails? Let's try to understand. In a simple way. First, what does an agent even do?

It runs a loop. Plan, act, read the result, plan again. Failure means that loop went wrong. Failure has a few shapes.

It gets stuck repeating one broken action. It drifts from your goal. Or it hits a wall. Your first instinct is to hit run again.

But a fresh run fails the same way, because the cause has not changed. So here is the real move. The agent leaves a trace. Every thought, action, and result, written in order.

That log is your evidence. Read it, and find the first wrong step, not the last. The last error is just where it crashed. Errors compound, so one early slip spawns many.

That first slip almost always has one of three causes. A goal too vague. A tool it was missing. Or a result it misread.

Now fix that cause, do not just scold the agent. Shrink the mission into one small piece it can finish and you can check. And if it is truly stuck, start fresh. A confused agent cannot reason its way out.

Clear the context and begin again. One last habit. Give it a stopping rule. A step limit, a budget, a checkpoint.

So a silent failure cannot burn forever. So, do not just rerun. Read the trace, find the first wrong step, fix its cause, and cap the loop. Quick check now.

One question is coming up. Let's see if it clicked.

What exactly is a senior developer's edge? Let's try to understand. In a simple way. First, be fair to the AI.

It writes code fast. Ask for a function, a working draft appears in seconds. No human is that quick. But here is the engine.

It predicts the next likely token, learned from piles of code. Likely is not correct. It can look perfect but be wrong. And it only sees what fits in its context window.

Not the whole system, not the real users, not last year's painful bug. A senior holds all of that. So the hard part is not writing the code. It is deciding what to build at all.

That comes from the goal, not from patterns. Real work is full of tradeoffs. Fast now, or easy to change later. The AI has no stake in the call.

A senior weighs it, and lives with it. The model cannot truly know if its answer is right. It never runs a test in its head. Someone must read it, question it, catch the plausible mistakes.

And when the code ships and breaks, the model is not paged at midnight. A person owns the outcome. Ownership cannot be outsourced. So the job does not vanish.

It moves up. Less typing, more deciding. You set the direction, review the drafts, own the calls. From typist to decision maker.

So, the AI is a fast drafting engine. It cannot pick the goal, weigh the tradeoffs, or own the result. Judgment is the senior's edge. Quick check now.

One question is coming up. Let's see if it clicked.