Thinking in an agentic way
The method comes before the commands. In this module you learn to guide an agent like an operational collaborator: you give it an observable result, allow only the necessary actions and you check the evidence before accepting the job.
What you will tackle, step by step
From response to workflow
In Module 0 you saw who proposes and who acts. Now let's take it a step further: what happens when the first attempt doesn't work? We don't start again blindly. You use what just happened to choose the next step.
A chatbot primarily produces a response. A coding agent, on the other hand, can read files, formulate a plan, apply changes and perform checks. The important difference is not how much text it generates, but the observable cycle it goes through.
The useful cycle is: observe the actual state, plan a limited change, take action, verify the result and report evidence and limitations. If the initial observation is missing, the agent guesses. If the final verification is missing, a convincing answer can hide an error.
- Observe the files, constraints, and actual symptoms.
- Plan the smallest change that will fix the problem.
- Act within authorized files and permissions.
- Verify with a reproducible test, output, or comparison.
- Report what has changed and what remains uncertain.
Import a file with three titles and a blank line. Task Notes creates four tasks, one of which is untitled.
- Observe: reproduce the problem with the same file and locate the parser, the part of the program that reads each line and turns it into a task.
- Plan: propose ignoring only lines that are empty after whitespace is removed; do not change the saved format.
- Act and verify: first add a test for a blank line, apply the minimal patch, and rerun the import tests.
- Report: show the diff and the before-and-after outcome, and state that no import format other than the tested one was checked.
Result: The bug isn't just "fixed": it's reproducible, linked to a cause, protected by a test, and accompanied by a stated limit.
The operational assignment
An operational assignment is not a long prompt: it is an agreement that allows you and the agent to recognize the same result. Useful information is that which, if missing, could change the solution.
An effective request contains four elements: the desired outcome, the necessary context, action boundaries, and evidence of completion. You don't need to write a novel; it is necessary to eliminate ambiguities that would change the solution.
With Task Notes, “fix the import” is too open-ended. “Blank lines must not create tasks; modify only the parser, preserve the data format, and run the import tests” establishes a testable contract.
Task Notes imports dates in the `YYYY-MM-DD` format, but a value like `2026-19-40` generates a difficult error.
- Define the result: the invalid line is rejected and the message indicates line number and expected format.
- Provide context: the parser is in `importer.py`, and valid records that have already been saved must not change format.
- Establish the boundary: modify parser and import tests, without migrating the database or rewriting the interface.
- Define the evidence: add one invalid and one valid case; show that the former produces the expected message and the latter continues to be imported.
Result: The agent can choose the validation technique, but cannot declare success without protecting both the new and existing behavior.
Autonomy proportionate to risk
Before granting autonomy, ask yourself three very concrete questions: if it goes badly, who is affected? Can I undo it? Does the action leave my computer? The answers tell you where the agent can proceed and where your explicit approval is needed.
Reading a local folder and publishing an app do not have the same impact. Autonomy must be granted based on the reversibility, scope and destination of the action. A local change under Git is easier to control than a push to clients or a remote delete.
The principle of least privilege reduces the scope of error: read-only access during analysis, writing only to agreed-upon files, and human approval before external or irreversible actions.
You want to test the new template on three test addresses. The connected service also contains the real list of customers.
- The agent reads the local template and generates a preview with fictitious data, without accessing the customer list.
- You authorize a send only to the test environment and three explicitly listed addresses.
- Check the subject, link, and delivery of the received email; the agent records the results without expanding the recipients.
- Sending to the real list remains blocked behind a new human checkpoint, with a summary of the number of recipients and final content.
Result: The agent can complete preparation and testing autonomously, while the broader external consequence remains under explicit control.
Evidence beats certainty of tone
The phrase “fact” is a summary, not evidence. To accept a job you have to connect every promise to evidence that observes that very behavior, otherwise you are measuring one thing and concluding on another.
An agent can say "done" even when it has only changed the code. The conclusion is only reliable if it is accompanied by adequate evidence: a previously failed test that now passes, a limited diff, a reproducible output, or a relevant visual check.
The check must match the promise. A syntax check does not prove that the app works in the browser; a parser test does not prove that the data is displayed correctly. Always ask what evidence supports which conclusion.
The agent changes the text of a button and reports that the build — the check that confirms whether the project compiles — succeeded. In the browser, however, an invisible panel still covers the button.
- The diff proves that the label was changed to the correct component and that no other files were touched.
- The green build tests that the project compiles, but does not simulate clicking or observe overlapping elements.
- A browser test opens the page, locates the button and tries to click it; the test fails because another element intercepts the action.
- After a separate patch, the same test passes and a visual check confirms the expected text, position and on-screen interaction.
Result: All evidence supports a precise conclusion: scope of the diff, compilation, interaction and visual rendering are no longer mixed.
From vague request to verifiable mission
Task Notes generates a blank task when the file contains a blank line.
Goal: ignore blank lines during import.
Scope: modify only parser.py and its related tests.
Constraints: do not change the saved JSON format.
Verification: reproduce the bug, add a test, and show the final diff.