انتقل إلى المحتوى
أمين أبوزيد
منشورBEG-056-L01

ما هو مساعد البرمجة بالذكاء الاصطناعي فعلاً

  • الدرس 1 من 5
  • 11 دقيقة قراءة
  • مبتدئ
في هذا الدرس 11 موضوعات

هذا الدرس متاح حاليًا باللغة الإنجليزية فقط، ولم تُنشر نسخته العربية بعد.

Lesson Overview

You have learned to write, run, and debug Java programs. Many learners now also have an AI coding assistant: a chat window or editor plug-in that answers questions about code in seconds. Used well, it is a patient tutor. Used badly, it is a way to skip the learning you need for a job.

This lesson opens the box just enough to remove the mystery. We will use one picture throughout the module: a very well-read autocomplete friend. The friend has read a huge amount of text and code, answers fast, and always sounds sure. But the friend never checks facts and cannot see your computer.

Why this matters: a backend developer is responsible for the code that ships, whoever or whatever typed it. You can only judge an assistant's answer if you know roughly how it was produced.

This lesson builds on your Java basics (BEG-016 and BEG-018: problem-solving and debugging). No machine-learning background is needed.

Learning Objectives

By the end of this lesson you will be able to:

  • Explain in plain words that an assistant is built on a large language model (LLM) trained on large amounts of text and code.
  • Define a token and split a short piece of text or code into plausible tokens.
  • Describe next-token prediction: the model picks one token at a time and repeats.
  • Explain what training data is and why the model's knowledge comes from patterns in it.
  • State two things the model does not do by itself: run your code and look facts up.
  • Explain why fluent text is not the same as correct text.

Written Explanation

The assistant is a model plus an interface

When you type into an assistant, you talk to a program that sends your text to a large language model, or LLM. The LLM is the part that produces the answer. Everything else (the chat window, the editor plug-in) is packaging.

An LLM is a mathematical model with a very large number of adjustable numbers inside it. It is trained on huge collections of text and code. During training it practises one task over and over: given some text, guess what comes next. Its internal numbers are adjusted until its guesses become good. After training, you use the model to continue your text.

Tokens

The model does not read letters or whole sentences. It reads tokens: small pieces of text. A token can be a whole word, part of a word, a single character, or a piece of punctuation. Google's machine-learning course describes tokens as the smallest unit a language model works with, and gives a rough rule for English of about four characters per token. Exactly how text is split depends on the model, so the splits below are only an illustration.

text
Text:    The list is empty.
Tokens:  The | list | is | empty | .

Code:    names.add("Ana");
Tokens:  names | . | add | (" | Ana | "); 

Notice that code is tokenized too. To the model, Java is just another kind of text with strong patterns: after names. a method name usually follows, after ( an argument usually follows.

Next-token prediction

Here is the whole generation loop:

  1. Your question is split into tokens.
  2. The model computes, for every token it knows, how likely it is to come next.
  3. One token is chosen (often a likely one, sometimes with a little randomness).
  4. That token is added to the text, and the loop repeats from step 2.

The answer therefore grows left to right, one token at a time. There is no separate step where the model plans the full answer, looks in a reference book, or tests it. Google's course calls such models, in effect, autocomplete mechanisms that can complete very long stretches of text.

Training data and patterns

What the model "knows" is whatever patterns were useful for guessing the next token in its training data. A model that saw millions of Java examples learns that public static void main(String[] args) is a very likely continuation of public class Main {. It also learns style, common mistakes, and typical explanations.

Two consequences follow:

  • Quality depends on the data. Patterns that were common in training are reproduced well. Rare things are reproduced badly.
  • The data stops at some date. Anything newer than the training cutoff was never seen. The next lesson returns to this.

A toy version of the idea fits in a few lines. In the examples you will build a tiny model that counts which word follows which, then generates text from the counts. A real LLM is vastly more sophisticated, but the job is the same: continue the text with a likely next piece.

What the model does not do by itself

  • It does not run your code. It never compiled your program. When it says "this prints 6", that is a prediction of what such an answer looks like.
  • It does not look things up in the documentation while answering, unless the product has a search or documentation tool attached. When such a tool exists, its results are still text that you should check.
  • It does not remember your project beyond what is in the conversation or what the tool sends it.
  • It does not know when it is guessing. Producing a likely token feels the same, to the model, whether the result happens to be true or not.

Fluent is not the same as correct

Because the model is trained to produce likely text, its output reads smoothly. Smooth reading is a different property from being true. A correct answer and an invented one can have the same tone, the same formatting, and the same confidence. The compiler, a test, the debugger, and the official documentation are the judges, not the assistant's tone.

Examples

Example 1: splitting a sentence into tokens (simple)

Take the question: Why does my loop never stop?

A plausible split is:

text
Why | does | my | loop | never | stop | ?

That is seven tokens. A longer or unusual word, such as NullPointerException, would probably be split into several pieces. You cannot see the real split without the model's tokenizer, which is why we say "plausible".

The model now has seven pieces of context and will add one token at a time: perhaps This, then usually, then happens, and so on.

Example 2: a toy next-token model in Java (practical)

This program does what an LLM does in miniature. It counts which word follows each word in a tiny training text, then generates by repeatedly choosing the most frequent next word (ties go to the alphabetically first word).

java
import java.util.*;

public class Bigram {
    public static void main(String[] args) {
        String training = "the cat sat on the mat the cat ate the fish the dog sat on the rug";
        String[] words = training.split(" ");

        // Count which word follows which word.
        Map<String, Map<String, Integer>> follows = new HashMap<>();
        for (int i = 0; i < words.length - 1; i++) {
            follows.computeIfAbsent(words[i], k -> new HashMap<>())
                   .merge(words[i + 1], 1, Integer::sum);
        }
        System.out.println("after 'the': " + new TreeMap<>(follows.get("the")));
        System.out.println("after 'sat': " + follows.get("sat"));

        // Generate: always pick the most frequent next word (ties: alphabetical).
        String current = "the";
        StringBuilder out = new StringBuilder(current);
        for (int step = 0; step < 6; step++) {
            Map<String, Integer> options = follows.get(current);
            if (options == null) break;
            String best = null;
            for (Map.Entry<String, Integer> e : new TreeMap<>(options).entrySet()) {
                if (best == null || e.getValue() > options.get(best)) best = e.getKey();
            }
            out.append(' ').append(best);
            current = best;
        }
        System.out.println(out);
    }
}

Output (compiled and run with JDK 21):

text
after 'the': {cat=2, dog=1, fish=1, mat=1, rug=1}
after 'sat': {on=2}
the cat ate the cat ate the

Read the result carefully. The output is grammatical-looking and follows the training patterns, yet it is meaningless and loops. The program has no idea what a cat is. It only follows counts. A real LLM looks at far more context and produces far better text, but it is the same kind of machine: patterns in, likely continuation out.

Example 3: the assistant says "this prints 6" (realistic)

You ask an assistant what this prints:

java
int total = 0;
for (int i = 1; i <= 3; i++) {
    total += i;
}
System.out.println(total);

The assistant answers "6". That is correct, and you can confirm it by hand-tracing (BEG-016): 1 + 2 + 3. Now imagine you change the loop to i < 3 and ask again. The answer might still say "6" because the code looks so much like the common example. The model did not run anything.

The lesson: when the answer matters, run the code. You have an IDE and a JDK; the model has neither. A thirty-second experiment beats a confident paragraph.

Backend Insight

In a backend team, code review, tests, and monitoring exist because every source of code makes mistakes: you, your teammates, copied snippets, and assistants. Review does not care who wrote a line; it asks whether the line is correct and safe.

Expect to work with assistants that are connected to tools: some can search documentation, read your repository, or run tests. That makes them more useful, and the habit is the same: treat the output as a proposal. Your job is to understand it, test it, and decide.

Common Mistakes

Mistake 1: Thinking the assistant looked the answer up

  • Incorrect: "It must be right, it found it in the documentation."
  • Correct: "It produced text that resembles documentation. I will check the real documentation."

Mistake 2: Thinking the assistant ran your code

If the answer states a result, such as an output value or a line number, it is a prediction unless a tool really executed the program. Run it yourself.

Mistake 3: Treating a confident tone as evidence

Tone is produced by the same next-token process as everything else. It carries no information about truth.

Mistake 4: Assuming it knows your project

It sees only what you paste or what the tool sends. If it did not see a file, it is guessing about that file.

Exercises

Try each exercise yourself before opening the solutions.

Level A: Foundation

A1. In one sentence, what is a token?

أظهر الحل A1

A1. A token is a small piece of text (a word, part of a word, a character, or punctuation) that the model reads and produces.

A2. Fill in: the model produces an answer by predicting the ______ token, again and again.

أظهر الحل A2

A2. Next.

A3. Name two things an LLM does not do by itself while answering.

أظهر الحل A3

A3. Any two of: run your code, look facts up in documentation (unless a tool is attached), remember your whole project, know when it is guessing.

Level B: Application

B1. Split int count = 0; into plausible tokens. Explain in one sentence why your split may differ from a real model's.

أظهر الحل B1

B1. For example int | count | = | 0 | ;. A real model's tokenizer may merge or split differently (for instance joining count with its leading space), because splits are learned and differ between models.

B2. In the toy program, what does the model predict after sat, and why? Use the output above.

أظهر الحل B2

B2. It predicts on. In the training text, sat is followed by on both times (after 'sat': {on=2}), so on has the highest count and is the only option.

B3. A friend says: "The assistant compiled my code and it works." What question do you ask first?

أظهر الحل B3

B3. Ask whether a tool actually ran it, or whether the assistant is predicting that it works. Then run it yourself.

Level C: Challenge

C1. In the toy program the generated text was the cat ate the cat ate the. Explain why it loops, and name one change to the generation rule that would make it vary.

أظهر الحل C1

C1. The rule always picks the most frequent next word. After the the top choice is cat (count 2), after cat the tie goes to ate, and after ate the only option is the, so the walk returns to where it started: a cycle. Choosing among the likely words with some randomness (weighted by counts) instead of always picking the top one would make the output vary. Real models are often run with a little randomness for that reason.

C2. Write four sentences explaining to a friend what an assistant is, using the words tokens, next token, and training data, and ending with a sentence on why it can be fluent and wrong.

أظهر الحل C2

C2. For example: "An assistant is a chat program on top of a large language model. The model splits text into tokens and, using patterns learned from its training data, predicts the next token over and over to build an answer. It does not run code or check facts unless a tool is attached. So its text reads smoothly whether or not it is true."

Mini Challenge

Run the Bigram program yourself, then change the training sentence to six or more words of your own (for example about your favourite food). Before running, write down what you expect follows.get(...) to show for one word. Then run and compare.

Check your work: you predicted first, you ran the program, and you can explain any difference between your prediction and the output by pointing at the training text. Add one sentence: what would a bigger training text change?

Summary & Next Lesson

Key takeaways

  • An assistant is an interface on top of a large language model trained on large amounts of text and code.
  • Text is split into tokens; the model predicts the next token repeatedly to build an answer.
  • Its knowledge is patterns from training data, not checked facts.
  • By itself it does not run your code or look things up.
  • Fluent is not the same as correct: use the compiler, tests, the debugger, and the documentation to judge.

Next lesson

The next lesson, "Why assistants sound right and are sometimes wrong", shows what that gap looks like in practice: hallucinated methods, wrong API calls, and outdated code, and how to catch each one.

Self-check

  1. What does the model do at each step of generating an answer?
  2. What is a token?
  3. Where do the model's "facts" come from?
  4. If an assistant says "this prints 6", has it run your program?
  5. Why can a wrong answer sound as confident as a right one?
أظهر الإجابات
  1. It predicts the next token and adds it to the text.
  2. A small piece of text or code: a word, part of a word, a character, or punctuation.
  3. From patterns in its training data, not from checking sources while answering.
  4. Not unless a tool really executed it; otherwise it predicted what such an answer looks like.
  5. Tone comes from the same prediction process; the model does not know whether a token sequence is true.

References

  • Google for Developers, Intro to large language models. Supports the description of tokens as the smallest unit of language modelling, the rough "about four characters per English token" rule, probability-based next-token prediction, and the dependence of predictions on training data.
  • Google for Developers, Machine Learning Crash Course: Transformers. Supports the description of LLMs as predicting a token or sequence of tokens, as autocomplete-like, and as generating token by token.
  • The "well-read autocomplete friend" picture, the toy Bigram model, and the token splits shown are this course's own illustrations; real tokenizers differ. The Java output was produced by compiling and running the program with JDK 21.

التطبيق

طبّق هذا الدرس بمختبر الوحدة وتمارينها واختبارها.

المختبر والتمارين الاختبار

تعليم الدرس كمكتمل اختياري ويمكنك التراجع عنه في أي وقت. يبقى تقدمك محفوظًا في هذا المتصفح.

اكتب للبحث في المستويات والمراحل والوحدات والدروس.