EN ↔ ҚАЗ · 180 terms
Technical Kazakh is still being decided in public. This is the set of choices this site makes, why it makes them, and what to avoid. If you teach or write in Kazakh, take it and argue with it.
01 How we write Kazakh here
Words the learner will type or see on screen stay as they are: git, prompt, agent, API, deploy, token, repo, frontend, backend, MCP, Claude Code. Words that have already settled into Kazakh are written in Cyrillic: агент, токен, модель, сервер, код, файл, промпт, репозиторий, коммит. Everything else gets a real Kazakh word: қолданба (app), тармақ (branch), біріктіру (merge), дерекқор (database), сілтеме (link), құпиясөз (password).
Attach the ending with a hyphen, never an apostrophe and never a space: GitHub-қа, git-те, Claude Code-ты, API-ге, LLM-ді, Vercel-ге. Choose the ending by how the word sounds, not how it is spelled: Claude is read [клод], so it behaves like a back-vowel word ending in a hard consonant, giving Claude-қа and Claude-та. When the reading is unclear (Gemini, production, CLI, IDE, README), drop the suffix and put a Kazakh descriptor noun after the name instead: CLI құралында, production ортасына, README файлын.
A word already written in Cyrillic needs no hyphen: промптты, токендер, серверге, репозиторийде, агентпен, модельдің. The hyphen belongs to Latin script and to acronyms only. Kazakh also never uses an apostrophe for this, so API-ге is right and API`ге is not.
A command has to be typed character for character, so it never carries a Kazakh ending. Wrap it in a descriptor noun instead: write «npm install пәрменін орында», not «npm install-ды орында»; write «CLAUDE.md файлын аш», not «CLAUDE.md-ны аш». The same holds for file names, flags and anything shown as inline code.
Learner-facing prose, tips and quiz feedback use сен: «Промптты нақтырақ жаз», «Жарайсың!». Buttons and menu items use the neutral infinitive, so the interface itself never has to choose a register: «Бастау», «Сақтау», «Кодты көшіру». Error messages use no second person at all and no exclamation mark: «Жүктеу мүмкін болмады», not «Сен жүктей алмадың». Prompts written to an AI are сен-form imperatives too, which is exactly the register the learner will be typing all day.
Dates start with the year: «2026 ж. 22 қыркүйек»; the short form is 22.09.2026. Months and weekdays are lowercase. Time is 24-hour (19:00) and a range uses an en dash with no spaces (19:00–21:00). Decimals take a comma (3,5), thousands a non-breaking space (1 500), money the same (5 000 ₸). Percent has no space, 80%, and its ending takes a hyphen, «80%-ы». A noun after a numeral stays singular: «5 сабақ», «3 коммит», never «5 сабақтар». Ordinals written in digits take a hyphen: «1-қадам», «3-модуль». A version is written «2.3 нұсқасы».
Use қолданба not қосымша, жүктеп алу not скачать ету, параметрлер not настройкалар, құпиясөз not пароль, сілтеме not ссылка, түйме not кнопка, қалта not папка, пайдаланушы not юзер, әзірлеуші not разработчик, нұсқа not версия, әдепкі not по умолчанию, дерекқор not мәліметтер базасы. Never hang Russian verb endings on an English root: instead of закоммитить, запушить, пофиксить, задеплоить write «commit жасау», «push жасау», «түзету», «deploy жасау». And never use the Russian-flavoured spellings бэкенд, фронтэнд, деплой, вайб-кодинг: backend, frontend, deploy and vibe coding stay in Latin.
The first time a term appears on a page, give the Kazakh rendering with the English in parentheses: «Тармақ (branch) — кодтың жеке көшірмесі…». After that use whichever form is shorter and clearer, тармақ or branch. This rule applies per page, not per site, because most people arrive straight into one lesson from search.
02 Terms
No term matches. Try part of the word.
Writing software by telling an AI in plain language what you want, then looking at what it built.
Build your first app with vibe coding, but read the code yourself afterwards.
Technology that lets a computer do work that used to need human thinking.
Working with AI is a skill every builder needs today, not a separate profession.
A program trained on huge amounts of text to predict what comes next, which is how it writes answers and code.
Do not think of an LLM as a database: it does not look the answer up, it writes it.
One trained AI program you can send a request to; each one differs in strength, speed and price.
Pick a cheap model for simple tasks and a strong one for hard ones.
The smallest piece a model actually reads and writes: a word, a part of a word, or a punctuation mark.
Everything is counted in tokens: the price, the limits and the context window.
The part that cuts text into tokens; every model family has its own.
The extra cost of writing in a language the tokenizer handles badly: Kazakh text needs roughly two to four times more tokens than the same meaning in English.
Write prompts and CLAUDE.md in English, keep Kazakh for what the user reads.
Everything the model can see at once: your instructions, the conversation, the files it read and its own reply.
Anything outside the context window simply does not exist for the model.
All the information the model has in front of it at the moment it writes an answer.
The fact that answers get less reliable as the input grows, even on easy questions.
A long window does not fix context rot: start a fresh session for a new task.
A setting for how much randomness goes into choosing the next token: low means repeatable, high means varied.
Keep it low for code, raise it for brainstorming.
Output that sounds right but is invented: a function that does not exist, a fake link, a wrong price.
Do not trust a link the model gives you until you open it.
The process of showing a model enormous amounts of text and adjusting the billions of numbers inside it.
Training a ready model further on your own examples so it fits one narrow job.
To add facts use RAG, not fine-tuning.
A collection of examples gathered to train or to test a model.
The numbers inside a model that get adjusted during training; the count is how model sizes are compared.
The trained values a model stores; everything it seems to know lives in them.
A structure of simple calculations stacked in layers that learns from examples instead of fixed rules.
Getting a computer to find the rule from examples instead of you writing the rule by hand.
Machine learning that uses neural networks with many layers; it is what made modern AI possible.
Turning a piece of text into a list of numbers so that texts with similar meaning end up close together.
Embeddings let search find the meaning, not just the exact word.
First finding the relevant passages in your own documents, then pasting them into the prompt so the model answers from them.
With RAG the model answers from your documents and can point at the source.
The moment a trained model actually answers your request; this is what you pay for.
A model that spends extra tokens thinking a problem through before answering: stronger, but slower and dearer.
Give a tricky bug to a reasoning model and a rename to a fast one.
A mode that lets the model use more tokens on thinking before it writes the answer.
Able to understand more than text: images, audio or video as well.
Show a multimodal model a screenshot of a design and ask for the page.
A fixed set of tasks used to compare models with each other.
A benchmark score is a hint, not a promise about your own task.
AI that produces new text, code, images or sound instead of picking from ready answers.
A model whose weights anyone can download and run on their own machine.
A model that runs on your own laptop with no internet: free and private, but weaker than a hosted frontier model.
With Ollama your prompts never leave the computer.
Shrinking a model by storing its numbers with less precision, so it fits on ordinary hardware.
A 4-bit model needs roughly 0.6-0.7 GB of memory per billion parameters.
The field that teaches computers to read and write human language.
A program you talk to in question-and-answer form.
The maximum number of requests you may send in a given period.
A model running in a loop: it takes a goal, calls tools itself, looks at the result and tries again.
The agent reads the file, edits it, runs the tests, sees the error and fixes it.
Look at the goal, choose an action, observe the result, repeat until it is done or it needs you.
The power of the loop is feedback: the agent sees real results instead of guessing.
Writing software by directing an agent instead of typing most of the code yourself.
The professional version of vibe coding: the agent writes, but tests, review and git stay in place.
The step from vibe coding to agentic engineering starts with one test.
Giving a model the ability to act: read a file, run a command, call an API.
Without tools a model can only produce text.
The structured request a model makes, such as read this file, which your program then executes.
An open standard for plugging external tools and data into AI apps, so one server works in many of them.
MCP is USB-C for AI: one connector instead of a separate cable for every pair.
A small program that exposes the tools and data of one system, such as GitHub, Figma or your database.
Install only servers you trust: a tool description is untrusted input too.
A helper agent the main one starts: it works in its own context window and returns a short summary.
Give a long investigation to a subagent so your main window stays clean.
A folder that describes how to do one job properly, which the agent opens only when that job comes up.
A skill beats stuffing everything into CLAUDE.md: it enters the context only when needed.
Your own script that runs automatically at a fixed point in the agent run, for example a linter after every edit.
A rule that must never be broken belongs in a hook, not in CLAUDE.md.
The project memory loaded at the start of every session: commands, rules and quirks the agent cannot guess.
Keep it under 200 lines: every line costs context in every session.
The same idea as CLAUDE.md but in a shared format that many different tools read.
One AGENTS.md is read by Claude Code, Codex and Cursor alike.
A mode where the agent reads and explores but does not touch the code, and writes out what it intends to do.
Review the 200-line plan, not the 2000-line diff.
The setting that decides which actions the agent may take without asking you first.
A mode where a separate checking model reviews the actions instead of asking you about each one.
Auto mode is a seatbelt, not an isolated sandbox.
One continuous conversation with the agent; when it ends, its context is gone.
After two failed corrections, clear the session and write a better first prompt.
Notes and files the agent keeps between sessions, because the conversation itself does not survive.
Turning a long conversation into a short summary so work can continue in a fresh window.
For an unrelated task clearing is better than compacting, and it is free.
The craft of giving the model exactly the tokens it needs at each step, and nothing more.
Context engineering is what prompt engineering became once agents started running in loops.
A snapshot the tool takes before an edit, so you can step back to it.
A checkpoint is local undo, git is permanent undo.
A separate folder with its own branch that shares one repository history, so parallel sessions never collide.
Give parallel agents a worktree each, so they do not fight over the same file.
Several agents splitting one task between them.
It typically costs three to ten times the tokens, so try one agent first.
The agent that splits the work, hands parts to worker agents and collects the results.
An agent whose only job is to check the finished work against the agreed criteria.
Separate the maker from the checker: an agent grades its own work far too generously.
A test suite for the agent and your own instructions: a set of real tasks you rerun after every change.
The minimal version: keep 10-20 tasks that once went wrong and rerun them.
Anything that gives the agent a pass or fail signal it can read itself: a test, a build, a screenshot.
If you cannot verify it, do not ship it.
The limits that keep an agent from going too far: permissions, tests, folders it may not touch.
Keeping a person in the chain so that important actions are seen and approved before they happen.
The scaffolding around a long-running agent: a progress file, a feature list and a fixed ritual for each session.
A simple shell loop that feeds the same prompt to the agent again and again, each time in a fresh context.
If you start a loop, always cap the number of iterations.
A ready-made action inside the agent, typed with a slash at the start.
An agent running on a machine in the cloud rather than on your laptop, which you watch from a browser or phone.
A lead agent and several teammates sharing one task list and messaging each other.
If you run a team, give every file exactly one owner.
Writing what and why first, then how, then the task list, and only then letting the agent code against those files.
Running the agent from a single command with no interactive screen, which is what scripts and automation need.
How many tokens you are willing to spend on one task; set it before you start anything that runs on its own.
Sending each kind of work to the model that suits it: a cheap one for simple steps, a strong one for architecture.
The instruction you give the model; the more precise it is, the better the result.
Write the prompt precisely: which file, what result, how to check it.
The standing instruction that sits in front of every request and sets the agent rules and manner.
Building instructions that get a correct, repeatable result out of a model.
One clear sentence telling the model what to do, in the imperative.
Write a test for this function. Explain why the error happened.
A ready prompt with blanks you fill in and reuse again and again.
One to three correctly done examples put inside the prompt, whose shape the model then copies.
A short document saying what will be built, what is out of scope, and what counts as done.
Once the spec is written, open a fresh session and build from it.
A document collecting who the product is for, why it exists and what it must do.
The list of steps the agent writes before it touches the code; read it before you approve it.
One bad line of plan turns into a hundred bad lines of code.
The concrete, checkable points that prove a task is finished.
What belongs to the task and what does not; if you leave it unsaid, the agent will add things nobody asked for.
Write the out-of-scope list too, not just the task.
Proof rather than a claim: the test output, the command and its result, a screenshot.
Ask the agent for evidence: let it show the test output.
Looking at the result, fixing the prompt and running again; not getting it right first time is normal.
What the model gives back: text, code or a tool call.
A text window where you type commands to the computer instead of clicking.
Coding agents work through the terminal, so this window matters more than it used to.
The line in the terminal where you type and the computer waits for your command.
One line of text the computer runs when you press Enter.
Run npm install. (A command never takes a Kazakh ending.)
A program with no window of its own, driven entirely from the terminal.
Claude Code is a CLI tool: you start it from the terminal.
The program that reads what you typed and runs it; bash and zsh are two of them.
To start a program so that it begins doing its work.
To put a program or a library on your computer so it is ready to use.
A named piece of saved information: a text, a picture, a piece of code.
A container that holds files and other folders.
The exact address of a file on the computer: which folder it sits in and under what name.
The bit after the dot in a file name that says what kind of file it is.
A program for writing code, which colours the syntax and spots obvious mistakes.
An editor, a terminal and a debugger gathered into one window.
VS Code is an IDE, and coding agents run inside it as well.
The human-readable text a program is actually written in.
Describing to a computer, step by step and without ambiguity, what it should do.
A person who builds software; with agents the job shifts from typing to directing and checking.
The language a program is written in, such as Python or JavaScript.
Write this script in Python.
The writing rules of a language: where the commas, brackets and spaces go.
The program will not even start because a rule of writing was broken, often one missing bracket.
A named place you put a value into and call back by that name later.
A named value that never changes while the program runs.
A named piece of code that takes input, does one job and gives a result back.
A template for making objects of the same kind.
One concrete thing in code, with its own data and its own actions.
What kind of value this is: text, number, yes or no, list.
A text value inside code, written between quotation marks.
A value that can only be true or false.
An ordered set of values kept under one name and reached by position.
Several values in a row that you can add to and walk through one by one.
Code that repeats the same action until a condition stops it.
A check that decides which branch of the code runs next.
An unexpected situation the program reports instead of carrying on quietly.
The program runs, but does something other than what you intended.
Finding out why the program misbehaves and fixing the cause.
Copy the whole error text and give it to the agent: that is the fastest route to a fix.
A marked line where the program pauses so you can look at the values.
The list printed when an error happens, showing which function was called from where.
The place where a program prints its messages and where you can type into it.
The timestamped messages a program writes while it runs.
When something breaks in production, read the logs first.
A small program that runs your code and checks that the expected result comes out.
For an agent a test is the objective signal that the work is done.
A test that checks one small piece of code on its own.
Write a failing test first, watch it fail, then write just enough code to make it pass.
A test never seen failing proves nothing: it may be passing for the wrong reason.
A test that catches the moment a new change silently breaks something that used to work.
Tidying the code without changing what the program does.
A tool that checks style and suspicious places in the code without running it.
Ready-made code written by someone else that you use instead of writing it yourself.
A ready structure that decides the shape of your project and leaves you to fill in the parts.
A library packed up so it can be installed with one command.
A tool that downloads the libraries your project needs, and the ones those need, at matching versions.
After cloning the repository, run npm install.
Someone else code your project cannot run without.
One file or folder of code that does a clearly separate part of the job.
To bring code from another file or library into this one.
A note inside the code for people to read; the computer skips it.
The written explanation of how a tool or library is used.
A short program that does one job from start to finish, usually run from the terminal.
To turn source code into the form a machine can run.
A precise sequence of steps that leads to a result.
One numbered state of a program, for example 2.3.
A version handed over to users, with a note of what changed.
The values you can change to make a program behave the way you want.
The value a program uses when you have not chosen one yourself.
A combination of keys that does an action faster than the menu.
The invisible place that holds what you copied until you paste it.
A picture of what is on your screen, useful as evidence for an agent.
How fast a program works and how much memory it eats.
A system that records snapshots of your project so you can see what changed and go back to any earlier state.
Think of git as save points in a game: before the boss fight you save.
Keeping the whole history of a project so nothing is ever lost for good.
The project folder together with its entire git history.
Your repositories on GitHub are the portfolio people actually look at.
To copy a repository, with its history, onto your own computer.
One saved snapshot in git: the exact state of the files plus a short message saying what changed.
Commit before every big request, so you can always roll back.
The one line explaining why this change was made, written for whoever reads it in six months.
A parallel line of work inside one repository, so you can try an idea without touching the stable code.
Open a new branch and the main code stays intact.
The branch holding the version considered stable, usually called main.
Bringing the work of one branch back into another.
Two branches changed the same line differently, so git asks you which version to keep.
A proposal to merge one branch into another: it shows exactly which lines changed and lets people comment.
Never open a pull request with code you have not read yourself.
Sending your local commits up to the repository on the server.
After saving the changes, commit and push to GitHub.
Bringing other people commits from the server down into your copy.
Downloading the news from the server without changing your own files yet.
Your own copy of someone else repository, which you may change freely.
The difference between two states: which lines were added and which removed.
The chain of all commits: who changed what, when and why.
Undoing one earlier change without erasing the history around it.
Putting unfinished changes aside for a moment so you can work on something else.
A name pinned to one commit, usually to mark a released version.
The copy of the repository living on a server, which everyone syncs with.
The list telling git which files must never be saved into the history.
Do not forget to put the .env file in .gitignore.
The first page of a repository: what this is, how to run it, how to help.
A platform that stores repositories on the internet and makes working together possible.
You can show a friend your repository on GitHub with one link.
A written-down task or bug in a repository, which anyone can discuss.
Code anyone may read, use and improve, within the terms of its licence.
The file saying what others are allowed to do with your code.
Someone reading the written code and saying what is wrong with it before it is merged.
Review in a fresh session: a fresh context is not attached to code it just wrote.
Anyone whose work has gone into a project, whether code, docs or translation.
Several people building one project without stepping on each other work.