Stop Chatting, Start Working: Unlearning Your AI Bad Habits

You open Microsoft Copilot, ChatGPT or Claude. You ask it to summarise a document, rewrite an email, analyse some figures or explain something unfamiliar. It replies. You add more background. The answer improves because the model now has more information about what you are trying to do.

Then somebody gives you access to Claude Code, GitHub Copilot, OpenAI Codex or one of Google’s agentic coding tools.

The interface looks reassuringly familiar. There is a box. You type instructions into it. Results come back.

But the thing behind the box has changed.

An agentic coding tool can open files, search a repository, write code, run commands, inspect errors, execute tests and keep working through intermediate steps without asking you to perform each one yourself.

Suddenly that tedious manual process looks automatable. You can build the little internal tool nobody has had time for. You can turn a recurring spreadsheet ritual into a script. You can wire together APIs, process thousands of files or finally make the website you have been threatening to build for six years.

You also inherit a completely different class of failure.

A bad workplace AI conversation might waste ten minutes. A badly managed coding session can read dozens of files, make changes across a repository, generate mountains of command output and consume a surprising amount of model usage before confidently telling you that everything is finished.

The problem is that the interface still encourages you to behave as though you are chatting with it.

Stop.

Many of the habits that ordinary workplace AI has taught you are actively unhelpful once the AI can do work.

The first habit to unlearn is the instinct to keep every conversation forever.

First, understand what you are actually using

People casually call products such as Claude Code and Codex “coding agents”. That is convenient, but it hides a distinction that becomes important once you start wondering why context behaves the way it does.

At the bottom is the LLM, the Large Language Model: the enormous neural network running somewhere in a data centre on enough hardware to lend credibility to the theory that Nvidia CEO Jensen Huang was sent back from the future with knowledge of an impending GPU shortage.

The model takes some input and produces some output.

Around that you can build an agent: a goal-directed loop that repeatedly asks a model what to do next, gives it access to tools, observes the results and continues until some stopping condition is reached.

Around the agent sits a harness: the ordinary software responsible for making the whole thing useful.

The harness decides what information to give the model. It exposes tools. It executes commands. It reads files. It stores state. It applies permissions and guardrails. It decides what to preserve between model calls and what to discard.

If you are familiar with software test harnesses, the idea is similar. A unit test does not stand up its own fixtures, organise a test run and collate the report. Other software does that around it.

This distinction explains something that is easy to miss when the interface looks like a chat window:

the model is not wandering around your computer carrying a mental representation of your project.

The harness repeatedly assembles the information the model needs and places that information into its context.

And context is where things start getting expensive.

Context is working memory, not a filing cabinet

When you use ChatGPT, Claude or Copilot in an ordinary conversation, it feels as though the AI remembers what you told it.

What is actually happening is less magical.

For each new inference, the application gives the model the relevant conversation and any other information it needs. That may include earlier messages, system instructions, retrieved documents, tool results and summaries of material that no longer fits comfortably into the available context.

The model has not secretly trained itself on your conversation. The application is giving it the information again.

All of that information occupies the model’s context window.

For ordinary workplace chat, this can stay manageable for quite a while.

Suppose you have a reasonably substantial conversation containing about 3,000 words. That might amount to roughly 4,000 tokens.

A token is simply one of the units in which LLM input and output are measured. The conversion between words and tokens varies, but the exact number is not important here.

Now compare that with code.

Imagine a modest project containing 30 source files averaging 150 lines each. If those lines average around eight tokens, the source alone contains roughly:

30 files × 150 lines × 8 tokens = 36,000 tokens

Already about nine times our substantial workplace conversation.

And source code is only part of what an agentic coding session may need.

The harness can also feed the model your instructions, specifications, configuration, search results, documentation, test code, compiler errors, stack traces and shell output.

One failed build can generate thousands of tokens in seconds.

The agent then searches for the cause, reads another five files, calls the model again, edits the code, reruns the tests and feeds the new results back into the process.

You might have typed:

Fix the login bug.

Those four words can initiate tens of thousands of tokens of model activity.

This is why counting prompts tells you almost nothing about how much work an agentic tool is actually doing.

More importantly, it explains why preserving one enormous coding conversation is usually a bad idea.

Stop trying to preserve one immortal conversation

Ordinary AI chat rewards continuity.

You spend half an hour explaining a problem. The conversation gets better as you add information. Starting again feels wasteful because you would have to reconstruct everything the model needs to know.

That trains you to value the conversation itself.

Agentic coding sessions accumulate a different kind of material.

Imagine you are building a small arcade game. First you implement player movement. Then enemies. Then scoring.

During those jobs the agent searches the repository, reads files, encounters failed tests, follows dead ends, tries an approach you reject, fixes bugs in its first attempt and discusses features you ultimately decide not to build.

Eventually you start the next piece of work.

Your session now contains two very different things:

• information about the current state of the project;
• the entire history of how you arrived there.

The first is useful.

Much of the second is not.

Yesterday’s stack trace does not become more valuable because you keep sending it back to the model. Neither does the abandoned implementation, the solved bug or the discussion about a feature you decided against.

Treat the conversation as working memory, not project storage.

When a coherent piece of work finishes, extract the knowledge that needs to survive.

Then clear the working context.

If clearing the conversation would destroy an important project decision, that decision is stored in the wrong place.

Put project knowledge in the project

You do not need an elaborate knowledge-management system.

Markdown files in the repository are enough.

For a small project:

docs/
decisions.md
specs/
scoring.md
multiplayer.md

Suppose you decide to use SQLite instead of storing application state in JSON files.

Put that decision somewhere durable:

# Save-game storage
Decision: Use SQLite.
Reason: We need structured queries and reliable updates across related records.
Rejected: JSON files, because concurrent updates would require additional locking logic.

Notice what you are preserving.

Not the twenty-minute argument with the model.

The outcome.

The reasoning somebody will need later.

And, where useful, the rejected alternative that somebody will inevitably suggest again six months from now.

The same principle applies to different kinds of project knowledge.

A project-wide architectural decision belongs in a decision record.

The behaviour of a feature belongs in its specification.

A requirement the software can verify belongs in a test.

A standing instruction that changes how an agent should work across the repository belongs in something like CLAUDE.md, AGENTS.md or .github/copilot-instructions.md.

Put information in the narrowest durable place that naturally owns it.

Do not turn your project instruction file into the repository’s attic.

If the database choice is in CLAUDE.md, every agent task may have to carry that information whether it needs it or not. If the scoring rules are buried there too, and then the API design, deployment history and meeting notes, you have simply recreated the immortal chat session as a Markdown file.

Project instruction files are context too.

Keep them focused on instructions the agent repeatedly needs.

Do not let ambiguity quietly become architecture

Workplace chat is unusually tolerant of vague instructions.

You can write:

Make this email more professional.

The model makes some stylistic choices. You read the result and decide whether you like them.

Software is less forgiving because ambiguity becomes behaviour.

Suppose you tell an agent:

Add a dash ability to the game.

That sounds perfectly reasonable until you ask what “dash” actually means.

Does the player become invulnerable?

Can they dash through enemies?

How long is the cooldown?

What happens when they hit a wall?

Can they dash in mid-air?

Can they change direction during the dash?

If those decisions are absent, the model still has to produce something.

So it makes assumptions.

The danger is not merely that one assumption might be wrong.

The assumption becomes code.

Then tests may be written around it. Other features may depend on it. APIs may expose it. Save data may encode it.

A vague requirement has now become project state.

The chain looks like this:

ambiguity → assumption → implementation → dependency → expensive reversal

So resolve important ambiguity before implementation.

You do not have to become clairvoyant and write a perfect specification upfront. You do need to make unanswered decisions visible.

This is where requirements-elicitation workflows become genuinely useful.

Some agentic setups provide Skills or commands designed specifically to interrogate a vague idea before implementation. They ask the annoying questions a competent business analyst, developer or solutions architect would ask.

Good.

Let them be annoying now.

It is cheaper than discovering the missing requirement after the database schema, API and UI all depend on the wrong answer.

Once those questions are resolved, move the result out of the conversation and into the specification.

Then implementation can begin.

Turn specifications into bounded jobs

A specification can still be too large to hand to an agent as one enormous instruction.

Break it into coherent tasks.

Think Jira tickets, except they can just as easily be Markdown files in a tasks/, tickets/ or issues/ directory.

Each task should let the agent answer three questions:

1. What should change?
2. What constraints must remain true?
3. What evidence proves the task is complete?

That third question is the one people most often forget.

“Implement authentication” is a task description.

“Implement authentication, preserve the existing session API, reject expired credentials, pass the authentication test suite and introduce no new linter errors” is a job the agent can actually reason about completing.

Clear boundaries reduce the amount of repository the agent needs to consider and reduce the number of decisions it has to invent.

You are not trying to describe the entire project every time you ask for work.

You are creating the smallest useful envelope around the job.

Keep noisy exploration away from implementation

Agentic coding tools spend a remarkable amount of time finding things.

Ask for one small change and the agent may search the repository, open twelve files, chase a reference into a dead end, read old tests and inspect configuration before discovering the two facts it actually needed.

Imagine that investigation consumes 20,000 tokens but the useful result is:

Authentication is handled in auth/session.py.
The current user is available through request.user.

The implementation task needs those facts.

It does not need the other 19,900 tokens of exploration.

This is one reason subagents can be useful.

Give a separate agent a noisy investigative task and let it return a compact result:

Investigate how authentication works. Return only the components that need modification, the relevant tests and any constraints the implementation must preserve.

The exploration happens in one context.

The findings move into another.

That suggests a broader rule:

match the lifetime of the context to the lifetime of the information.

Repository exploration may only be useful for five minutes.

Implementation context may need to survive for the duration of one ticket.

Architectural decisions may need to survive for years.

Tests may remain useful for the lifetime of the software.

Do not keep all of those things in one bucket simply because a chat interface makes that convenient.

Make the machine prove it worked

With ordinary workplace AI, you are usually the verifier.

Copilot drafts an email. You read it.

Claude summarises a document. You compare the result with the source.

Agentic coding gives you an opportunity to automate part of that verification.

This is where Test-Driven Development suddenly starts looking rather fashionable again.

Suppose our dash feature has four requirements:

1. The dash has a one-second cooldown.
2. The player cannot dash through walls.
3. Existing movement still works.
4. Automated tests cover the new behaviour.

Now the agent has something better than a vague notion of completion.

It can change the code, run the tests, inspect failures, modify the implementation and run them again.

The important principle is broader than TDD.

Before handing over substantial work, ask:

What observable result would demonstrate that this works?

Then give the agent access to that check wherever possible.

That might mean:

• unit tests;
• integration tests;
• a successful build;
• type checking;
• linting;
• an API request with an expected response;
• comparison against a known fixture;
• a performance threshold;
• generated output that can be inspected automatically.

The mechanism depends on the task. The principle does not.

If the only evidence that the work is complete is the model saying “done”, you have not verified the work.

You have received a status update from the thing whose work you are supposed to be checking.

Separate implementation from review

Suppose an agent spends a substantial session implementing a feature.

During that session it sees every assumption, failed attempt, workaround and correction involved in producing the final code.

Then, at the end, you ask:

Review your work.

That is better than nothing, but it is not much separation between implementation and evaluation.

For complex or important changes, start a clean session.

Give the reviewer:

• the specification;
• the resulting code changes;
• the test results;
• any constraints that should have been preserved.

Then ask it to find requirement violations, missing cases, unnecessary changes and questionable assumptions.

The clean reviewer has not followed the implementation process step by step. It sees the result against the requirements rather than inheriting every justification made along the way.

This does not magically make the reviewer unbiased.

It simply removes one source of correlated reasoning between the person — or model — that created something and the process used to evaluate it.

Software engineering discovered a long time ago that separating generation from evaluation tends to be useful.

Agentic coding has not repealed that idea.

Use project instruction files for instructions

Sooner or later you will encounter files such as:

CLAUDE.md
AGENTS.md
.github/copilot-instructions.md

These are project instruction files.

Compatible tools load them to understand how they should work inside the repository.

Useful contents might include:

• how to run the tests;
• which package manager the project uses;
• directories that contain generated files and must not be edited manually;
• formatting or naming conventions that apply across the codebase;
• important commands an agent needs repeatedly.

Ordinary project knowledge does not belong there merely because the agent reads the file automatically.

A decision to use OAuth rather than local passwords is a project decision.

The instruction “never manually edit files under generated/” changes how the agent should behave on many tasks, so that belongs in the project instruction file.

Again, context has a cost.

A bloated instruction file gets dragged into work that may have nothing to do with most of its contents.

Do not solve context management by creating a giant file that automatically pollutes every new context.

What I would do on day one

Pick a real project you care enough about to finish but can afford to break.

Build a tiny game.

Create a personal website.

Automate some tedious admin.

Write a little utility that saves you ten minutes every week.

Then use the agentic coding tool for one clearly bounded task and actually watch what it does.

Notice which files it reads.

Watch the commands it executes.

Look at how much output a failed build produces.

Notice how much activity can follow from one short instruction.

Create a docs/ directory early.

Give project decisions somewhere durable to live.

Give substantial features specifications.

When a conversation produces information the project needs to remember, move that information into the repository.

Before implementation, resolve the decisions that would otherwise be guessed.

Break larger specifications into bounded jobs.

Give each job observable completion criteria.

Use separate contexts for noisy investigation where it helps.

Run automated checks.

Review important changes from a clean session.

Then clear the old working context and move on.

Only add elaborate Skills, subagents, orchestration frameworks and multi-agent workflows once you have experienced the failures they actually prevent.

Do not begin by constructing an artificial intelligence bureaucracy around a three-file Python project.

Learn the failure modes first.

The habit that actually needs to change

Workplace AI taught us to treat the conversation as the product.

We keep adding context, refining instructions and preserving the thread because the thread is where the useful information lives.

Agentic coding changes that relationship.

The project now exists outside the conversation.

The code exists outside it.

The specifications exist outside it.

The decisions exist outside it.

The tests exist outside it.

The conversation is temporary working space around those things.

Once you understand that, most of the other advice stops looking like a collection of arbitrary best practices.

Of course you clear old sessions.

Of course decisions need a durable home.

Of course tasks need boundaries.

Of course noisy investigations can be isolated.

Of course the agent needs a way to prove its work.

You are no longer trying to maintain the perfect conversation.

You are trying to get work done reliably.