New: Boardroom MCP Engine!

Ready to put this into action?

Get the complete AI Integration PlaybookPractical AI implementation guide — prompt engineering, workflow automation, and ROI frameworks.

Article 103 · Part 11

Learn Enough Programming to Direct and Check AI

Read the inputs, follow the decisions, and identify what a program can change.

By Randy Salars · Published

On this page
  1. Learn the small set of ideas that programs combine
  2. Read a complete small program
  3. Trace one iteration at a time
  4. Distinguish returning, printing, and changing state
  5. Use errors as evidence
  6. Predict a change before running it
  7. Read documentation with a concrete question
  8. Create a comprehension check
  9. Build independence gradually
  10. A reusable prompt
  11. For students: show your prediction and your correction
  12. Practice: modify the title cleaner

Read the inputs, follow the decisions, and identify what a program can change.

A beginner runs a script written by AI. The terminal prints “Done.” That sounds encouraging, but the beginner cannot say which files were read, whether anything was overwritten, or whether a network request was sent.

You do not need to become a professional programmer before using AI to help with code. You do need enough understanding to explain the program’s boundaries and recognize when the evidence does not support its success message.

Begin with an in-memory task. Its inputs and outputs fit on one screen, and no file operation is needed inside the program.

Learn the small set of ideas that programs combine

A value is a piece of data, such as text, a number, or a true-or-false result. A variable gives a name to a value. A condition chooses between paths. A loop repeats an operation. A function packages a task so it can be called with specified inputs.

A list holds an ordered collection. A set is useful when the program needs to track membership, such as whether a title has already appeared. Returning a value from a function is different from printing it to the terminal.

Python’s control-flow tutorial explains conditions, loops, and functions. Use documentation alongside AI explanations, especially when a function name or behavior is unfamiliar.

The goal is not memorizing every language feature. It is recognizing the operations used by the particular program you are directing.

Read a complete small program

This function cleans a list of sample titles. It trims whitespace, skips empty titles, and removes repeated titles using lowercase comparison while preserving the first retained spelling and original order.

def tidy_titles(titles):
    cleaned = []
    seen = set()
    for title in titles:
        if not isinstance(title, str):
            raise TypeError("Every title must be text")
        value = title.strip()
        key = value.lower()
        if value and key not in seen:
            cleaned.append(value)
            seen.add(key)
    return cleaned

sample = [" Field notebook ", "", "LOCAL HISTORY", "field notebook"]
result = tidy_titles(sample)
print(result)
print(sample)

The first printed list is ['Field notebook', 'LOCAL HISTORY']. The second is the unchanged original list, including its spaces, empty string, and repeated title.

The comparison rule is intentionally simple. It uses the language’s lowercase conversion; it does not establish a universal definition of matching across every language, spelling variation, or cataloging tradition.

Save the program in a disposable learning folder as titles.py and run it with your Python 3 interpreter. Creating the script file is a workspace action. The program’s own operations use memory and terminal output; they contain no file-write or network call.

Trace one iteration at a time

For the first input, trimming produces “Field notebook.” Its lowercase key is “field notebook,” which is not in seen, so the program appends the title and records the key.

The second input becomes an empty string. The condition fails, so nothing is appended.

The third input is nonempty and new. The program retains “LOCAL HISTORY” exactly in that spelling. The final input has the same lowercase key as the first, so it is skipped.

The program builds a new list rather than editing sample. That choice is visible in cleaned = [] and in the absence of assignments to elements of the input list.

Ask AI to produce this trace, then compare it with the actual code. Generated commentary can be wrong even when it sounds plausible. The code and observed behavior remain the evidence.

Distinguish returning, printing, and changing state

return cleaned hands the result back to the caller. print(result) displays it. Neither operation saves the list as a document.

A function can also change external state: write a file, update a database, send a message, or modify an object supplied by the caller. Those effects may be useful, but they need to be identified before execution.

Search for operations related to the resources in question. File methods, network libraries, process execution, database connections, and application connectors deserve attention. A function’s harmless-sounding name does not establish what it does.

For this small program, the side-effect statement is simple: it prints two lists and raises an error if an element is not text. It does not change the source list or contact another system.

Use errors as evidence

Change one input to the number 7. The function raises TypeError with the message “Every title must be text.” That is an intentional input check.

Do not automatically “fix” the error by converting every value to text. Doing so changes the requirement. The number might be an accidental field mismatch that should remain visible.

Read the error type, message, and location. Then ask what input and code path produced it. The line where an exception appears may be the place the problem was detected rather than the place it originated.

A syntax error prevents the program from being interpreted correctly. A runtime exception occurs while the program executes. A logic error can produce the wrong result with no exception at all. The duplicated-join lesson in Article 097 illustrated that last category.

Predict a change before running it

Suppose you replace key = value.lower() with key = value. The matching rule becomes case-sensitive. The final “field notebook” no longer matches “Field notebook,” so both remain.

Suppose you instead apply .title() to the retained value. That changes displayed capitalization, which may be undesirable for acronyms, names, or deliberate styling. The new output should be judged against the requirement, not merely described as cleaner.

Write the expected result before execution. If your prediction differs from the actual result, investigate the difference. This develops understanding faster than repeatedly accepting whatever the latest AI patch prints.

Make one meaningful change at a time while learning. If you change matching, ordering, capitalization, and validation together, an unexpected result is harder to explain.

Read documentation with a concrete question

“Teach me Python” invites a broad lesson. “Does str.strip() change the original string or return another string?” identifies a question tied to the code.

Use the official reference for the relevant method and language version. Ask AI to connect the documentation to the current example, then verify the behavior with a small input.

Do not install a new package simply because the model suggests one. This task needs only the standard language. A dependency can be justified when it solves a real requirement, but it also adds setup and maintenance work.

Likewise, a successful import does not prove that you are using the expected package version or environment. Article 105 will make that boundary more explicit.

Create a comprehension check

A learner should be able to answer: What are the inputs? What is returned? What is printed? Which items are skipped? What makes two titles duplicates? What happens with a non-text item? Does the source list change?

These questions assess the behavior that matters. They are more useful than asking whether the learner can recite every line of an AI-generated explanation.

A small test packet might include ordinary text, spaces-only text, duplicate capitalization, repeated identical titles, an empty list, and a non-text value. State the expected behavior for each before running it.

For an empty list, the result is an empty list. For a list containing a non-text element, the function raises an error; it does not return a partial cleaned result. That distinction belongs in the function’s contract.

Build independence gradually

Once you understand the function, write a short version yourself without viewing the original. Compare behavior rather than demanding identical code.

Two programs can produce the same result for the sample while differing on an edge case. Expand the comparison only where it resolves a meaningful uncertainty about the requirement.

AI can act as a tutor, reviewer, or debugging partner. Ask it to pose prediction questions, identify unexplained side effects, and help interpret errors. Avoid making it the only judge of code it just wrote.

The practical milestone is being able to direct a small change and verify what happened. That skill transfers to larger projects one understandable piece at a time.

A reusable prompt

Explain this program’s inputs, values, variables, control flow, returned output, printed output, and side effects. Identify any file, network, database, or process operations. Trace one small example. Ask me to predict a specific change before revealing the result. Check unfamiliar behavior against official documentation, and do not silently change the requirements to make an error disappear.

For students: show your prediction and your correction

Submit the original code, your predicted output, the actual output, and a short explanation of any difference. Then make one change with a stated purpose.

Beginning students can trace the list on paper. More advanced students can write their own function and compare behavior. Students in other subjects can substitute authorized sample titles from their field while keeping the same data rules.

Follow your course’s requirements for AI assistance. A useful disclosure describes which parts were suggested and how you checked them. Understanding the program is the learning goal, even when AI helps produce it.

Practice: modify the title cleaner

Predict and run the function on ['Map', ' map ', 'Guide', ' ']. Then make comparison case-sensitive and explain the difference. Finally, test an empty list and a list containing an integer.

Write a side-effect statement that distinguishes saving the source-code file from the operations performed when the program runs.

Completion check: The original comparison returns ['Map', 'Guide']; the case-sensitive version retains “map” as a separate title; the empty input returns an empty list; non-text input raises the stated error; and the input list remains unchanged.

Stretch: Rewrite the function independently. Compare its behavior on the defined cases and explain one implementation difference without changing the agreed matching and ordering rules.

Get the AI Dispatch

Weekly insights on ai & technology — delivered to your inbox. No spam, unsubscribe any time.

Want to choose specific topics? Customize your interests