Gains:
- Ability to explain how a coding assistant works as a language model and the concepts of token, context window, hallucination
- Ability to distinguish software tasks where AI is strong and weak with a mental map
- Ability to apply the basic work cycle of propose-produce-verify to their own tasks
A software developer's day is rarely spent "writing code from scratch." Real time; Reading the code written by someone else, trying to reproduce a bug, scanning the log (log lines produced by the application while running), writing tests, writing a PR (pull request - a merge request where a code change is submitted for team review) explanation and updating the documentation. Artificial intelligence (AI) is a speed multiplier that can touch almost all of these unseen jobs. But the first condition for using it safely is to correctly understand what it is and what it is not.
In this unit, we first explain the underlying technology of a coding assistant in plain language; then we create a mental map of the model's strengths and weaknesses; Finally, we establish the basic working discipline that we will use throughout the entire module: propose, produce, verify. These three steps are the backbone of the next eleven units.
Note: This module is a general training. In security-critical software (payment processing, healthcare, authentication, critical infrastructure) AI output is not a substitute for review and approval by a qualified engineer. AI is an assistant; The signer is the engineer.
What Does a Coding Assistant Actually Do?
Most coding assistants are built on a large language model (LLM—an AI trained on huge amounts of text and code that predicts the next most likely “chunk”). The model does not "understand" the code like a human; It generates the most likely continuation of the context you give it, based on the patterns it learns from a huge pool of examples. This seemingly simple mechanism yields surprisingly proficient results in practice — because most software consists of repeating patterns: an HTTP request, a loop, a null check, a test pattern.
Three terms are critical here. Token is the smallest unit that the model processes by dividing the text; It is roughly a few letters or part of a word. The context window is the amount of tokens the model can "see" at once; Your code, error message, and instruction must fit in this window. A prompt is all the instructions and context you give to the model. The quality of the output you get depends directly on these two: the better context and clearer instructions you give the model, the better result you will get. Bad input produces bad output, even if it is a smart model — the classic “garbage in, garbage out” rule of software also applies to AI.
Strengths and Weaknesses Map
To direct AI to the right jobs, it is necessary to know where it shines and where it stumbles. Memorizing this map will make you wonder with each next mission, "Should I outsource this job to the AI or do it myself?" It allows you to answer the question in seconds.
Its strengths are: Generating boilerplate code, translating from one language to another, writing a regular expression (regex), describing a function, creating a test skeleton, interpreting an error message, drafting documentation, suggesting variable/function names, and minor refactorings (improving the structure of the code without changing its behavior).
Weaknesses: Knowing your company-specific business rules, remembering your entire code base, actually running and verifying the code, knowing the latest library versions for sure, detecting security vulnerabilities with a hundred percent guarantee. The most dangerous thing is hallucination: the model invents a non-existent function, library or API (interface that enables data exchange between applications) in a very convincing language. This risk can actually be turned to your advantage, since the code, unlike plain text, can be tested to see if it “works” — just don't skip the verification step.
Mission type
The role of AI
man's role
Produce boilerplate/skeleton
produces draft
Adapts, reviews
Code description
Gives a quick summary
Verifies the critical part in the code
writing tests
Case suggests
Confirms coverage and accuracy
Security-critical logic
helpful idea
Decision and responsibility rest entirely with humans.
API/library usage
Generates sample
Verifies existence and version
architectural decision
Sorts of options
Selects and defends knowing the context
Step by Step: Basic Working Cycle
- Clarify the task. If you can't write what you want in one sentence, neither can the model. The earlier uncertainty seeps into the input, the greater it grows in the output.
- Give context. Add the relevant code, full error message, language/framework version and constraints to the prompt. Don't say "fix this", say "Python 3.11, FastAPI 0.110; this function gives a 500 error, it explodes when the request body is empty".
- Imposition role and format. A framework like "You're a senior Go developer; just give the code and a two-sentence rationale" focuses the output.
- Ask for small. Break it down into steps rather than one giant request; Verify each step separately. Major changes are risky because they are difficult to verify and prone to hiding errors.
- Verify. Run it, test it, read it visually. Unverified AI code is a "sketch", not a "solution". This is the most non-negotiable step of the cycle.
Three Mini Cases
Case 1 — The time savings are real but modest. When a team skeletonized new CRUD (Create-Read-Update-Delete) endpoints with AI, first draft time dropped from approximately 40 minutes to 8 minutes. However, with review and testing, the total time was 25 minutes; so the real gain is from 40 to 25, about 38%. This rate, measured instead of the expectation of "we have accelerated 10 times", is a sustainable gain.
Case 2 — Hallucination is costly. A developer used the AI-suggested requests.get_json() call without validation; There was no such method (precisely response.json()). 20 minutes were lost when the code did not compile. A simple "does this method really exist?" verification would reset the loss.
Case 3 — Good context doubles output. For the same bug, one developer simply wrote "I'm getting an error" and the other added the full stack trace, version, and input sample. The latter got the correct solution on the first try; The first one spent three turns. The difference was not in the model, but in the input.
Four Copiable Templates
A general-purpose, powerful startup prompt:
Role: You are an experienced {{language}} developer.Task: {{what_want}}Context:- Framework/version: {{framework_and_version}}- Constraints: {{performance, style, dependency rules}}Rules:- Do not use non-existent library/function; If you are not sure, mark it as "verify". - First, give a short plan, then the code, then 2 sentences of justification. - Produce testable, working code.
To filter uncertainty back into the model:
Before solving the task below, list AT LEAST 3 points that you find missing or unclear as questions. DO NOT write code before I reply.Task: {{task}}
To have the output self-checked:
You have produced the following code. Now change your role and critique this code:- List 3 cases (edge cases) that might not work.- Are there any APIs/functions you could have made up? Mark.- Give corrected version.Code:{{code}}
To break down a decision into options:
Suggest 2-3 solution approaches for {{problem}}. For each: short description, plus/minus, when to choose. Give in tabular form. DO NOT choose for me; just clarify the option.
Weak prompt / Strong prompt
Weak: "Fix the bug in this code." (Which error? Which language? What is the expected behavior?)
Strong: "Python 3.11 / FastAPI 0.110. The following endpoint returns 500 with KeyError when the request body comes empty; I want it to return 400 and meaningful message on empty body. First explain the reason, then give the corrected function, then write a test for this scenario. [code]"
Powerful version; It gives the language, version, actual error, expected behavior and output format. The model no longer has to predict.
Common mistakes
- Trusting without verification. The most common and most expensive mistake. Don't say "solved" until the code is compiled and tested.
- Asking questions without context. The answer without version, error text and restrictions is generic and often wrong.
- One huge request. Not being able to request and review a 300-line production at once makes mistakes invisible.
- Mistaking the model's self-confidence as proof. AI can confidently say something wrong; Tone is not an indicator of accuracy.
- Randomly pasting the company secret. Private keys, customer data or private source code should not be entered into unapproved tools (we will delve into this topic in unit 10).
Tip: Treat every AI output as “this is a draft.” This single mental habit extinguishes most of the risks you will see throughout the module.
In summary
A coding assistant is a language model that predicts the next most likely fragment; It doesn't understand the code, it produces patterns. That's why he's strong in repetitive, formulaic jobs; It should be used cautiously for work that requires verification that is specific to your context. The biggest risk is hallucination, and the only antidote is verification. The discipline we will follow throughout the entire module is clear: clarify the task, give context, ask for small, validate each deliverable.
Application task
Write down three software tasks you did in the last week (e.g. a bug fix, a test, a README update). Look at the “strengths and weaknesses map” for each and describe in one sentence what your and the AI’s role would be if you had the AI do this. Then give one of these tasks to the AI with the “start prompt” template above and run and verify the output; Note how many minutes you saved and how many mistakes you had to fix.
checklist
- [ ] I realized that LLM produces patterns, not "understands" code.
- [ ] I can explain the concepts of token, context window and prompt in one sentence.
- [ ] I can distinguish between types of tasks where AI is strong and weak.
- [ ] I know what a hallucination is and the only antidote is verification.
- [ ] I adapted the "propose, produce, verify" cycle to my own task.
- [ ] I can show the difference between a strong prompt and a weak prompt in a concrete example.