AI-Assisted Coding Roadmap

What is AI-Assisted Coding? Core

AI-assisted coding means using a language model to help write, explain, change, test or review software. The help ranges from line completion in an editor, through a chat that answers questions about your code, to an agent that reads files, runs commands and makes multi-file changes while you supervise.

It does not remove the need to understand software. The assistant is fast and fluent but sometimes wrong, and it will not tell you when it is guessing. The person in charge still owns the design, the review and the consequences. This roadmap teaches the workflow that keeps that responsibility intact while using the speed.

Practice. Pick one small task from your own work and write down which parts a model could do and which parts you must decide.

Vibe Coding Core

Vibe coding is a style of building software by describing what you want in plain language, accepting what the model produces and steering by running the result, with little or no reading of the code. The term was popularised in early 2025 and is useful to name the extreme end of the scale.

It works well for prototypes, personal tools, throwaway scripts and learning. It works badly for anything that handles money, personal data or other people's trust, because nobody has checked what the code really does. The rest of this roadmap is about moving from pure vibes towards a disciplined process: plans, tests, review and security checks.

Practice. Vibe-code a small personal tool in one sitting, then list three things in it you did not verify.

The Vibe Coder Mindset Core

The productive attitude is to act like a technical lead directing a fast junior colleague. You set goals, give context, check the work and say no. You stay curious about why something works, and you treat every generated line as a proposal.

Habits that follow: expect to iterate, keep each step small enough to judge, learn the basics of the language you are producing, and be ready to stop and reset when a conversation drifts. People who treat the assistant as an oracle ship brittle software, and people who treat it as a tireless pair programmer ship faster and still understand what they have.

Practice. Write five personal rules for working with an assistant, such as always reading the diff before accepting.

The Tool Families Core

Tools fall into a few families, and most products mix them. Chat assistants such as ChatGPT and Gemini answer questions and produce snippets that you copy. Editor assistants such as GitHub Copilot and Cursor complete code and edit files inside the IDE. Terminal and cloud coding agents such as Claude Code, OpenAI Codex and Devin take a task, work through it and report back. App builders such as Lovable and v0 generate whole interfaces or applications from a description.

Choose by how much control you want and how much you can review. Chat suits learning, editors suit daily coding, agents suit larger changes with tests, and app builders suit prototypes. Features and names change quickly, so learn the ideas, which carry across tools.

Claude Code itself has a CLI, a desktop app, a browser extension for Chrome and extensions for code editors. Some tools also produce Artifacts, standalone pages or documents shown beside the chat.

Practice. Try the same small feature request in one chat tool and one editor or agent tool, and compare how much review each result needed.

Pick a Popular Tech Stack Core

Models have seen far more examples of widely used languages and frameworks than of new or niche ones, so they write better code in them. A common stack, such as TypeScript Roadmap with React Roadmap or Python Roadmap with a mainstream web framework, gives more accurate suggestions and more answers when you search for errors.

This is a practical bias, not a rule. If your job demands a rare language, expect to give more examples and documentation, and verify more. For learners, a popular stack also has more tutorials to cross-check the assistant against.

Practice. Ask an assistant for the same small function in a mainstream language and a rare one and compare how many fixes each needs.

Master Version Control Core

Version control is the safety net for working with assistants, because they can change many files quickly and sometimes in the wrong direction. Learn the basics of Git and GitHub Roadmap: status, diff, add, commit, branch, restore and reset.

Make a habit of reading the diff before accepting changes, and treat the repository as the source of truth, not the chat history. If you can always get back to a known good state in seconds, you can afford to try bolder tasks.

Practice. Create a repository, make an assistant change three files, then review the diff and undo one of the changes with a single command.

Use git commit Often, and Revert with Git Core

Commit after every small step that works. Small commits give you restore points: if the next prompt wrecks things, you return to the last good commit instead of arguing with the assistant about undoing its own work.

git status
git diff
git add -p
git commit -m "Add input validation to signup form"
# when a step goes wrong:
git restore .            # discard uncommitted changes
git reset --hard HEAD~1  # drop the last commit (careful)

Prefer restore on a clean branch to asking the model to undo. Models are unreliable at reversing their own edits, and git is exact.

Practice. Practise restoring a bad change three times until the commands are automatic.

Prompting Best Practices Core

A good coding prompt states the goal, the context, the constraints and how success will be judged. Mention the language and framework, the files involved, what must not change, and how you will check the result, for example the test that should pass.

Then keep it short and concrete. Long rambling prompts bury the important instruction. If a first answer is wrong, say what is wrong and why, instead of repeating the request louder. The Prompt Engineering Roadmap roadmap covers general techniques that apply here too.

Practice. Rewrite a vague request into one with goal, context, constraints and a success check, and compare the two results.

Be Specific About What You Want Core

Vague requests such as make it better get arbitrary changes. Specific ones get predictable ones. Say what behaviour you want, with inputs and expected outputs, name the function or file, and state the style and library choices.

Compare make the form nicer with add client-side validation to the signup form so that an empty email or a password under twelve characters shows an inline error and disables the submit button. The second leaves little room for surprise and is easy to check.

Practice. Take three vague requests from your own history and rewrite each as a testable description.

Ask for One Task at a Time Core

Large multi-part requests produce large diffs that are hard to review and easy to get subtly wrong. Ask for one change, review it, test it, commit it, then ask for the next.

This also keeps the context focused. A conversation about adding a login endpoint should not also be redesigning the database and changing the build. If you notice a second problem, note it and handle it afterwards in its own step.

Practice. Split a feature you want into five single-purpose requests and run them one by one with a commit after each.

Plan Before You Code Core

For anything bigger than a small edit, ask for a plan first. A plan is a list of steps, the files each will touch, the risks and the open questions. Read it, correct it, and only then ask for the implementation.

Planning catches wrong assumptions cheaply: the assistant picked the wrong library, misunderstood a requirement, or wants to rewrite something you would rather keep. Many agent tools have a dedicated plan mode that blocks edits until you approve.

Practice. Ask for a written plan for a medium feature, edit it, and compare the final code with what you approved.

Implement Spec-Driven Development Recommended

Spec-driven development makes a written specification the source of truth: requirements, behaviour, acceptance criteria and constraints, kept in the repository. The assistant produces a plan and code from the spec, and tests check the code against it. When behaviour needs to change, you change the spec first.

It suits larger or longer-lived projects, since the spec survives sessions and models. The cost is writing and maintaining the document, so keep it short and precise, with examples of inputs and outputs wherever possible.

Practice. Write a spec with five acceptance criteria for a small feature and have the assistant implement it, then check each criterion.

Illustrate AI with Examples Core

Examples of input and output convey the format and edge cases better than paragraphs of description. Show one or two sample records, a sample of the expected response, or an existing function whose style you want copied.

Choose examples that cover the awkward cases, such as empty values, unusual characters and large sizes. If the model copies an example too literally, say which parts are only illustrations.

Practice. Give an assistant two input and output examples for a parsing function and check it handles a third case you did not show.

Tell AI What NOT to Do Core

Assistants tend to over-help: they refactor unrelated code, add dependencies, rename things and add features. Short explicit limits prevent this. Say do not change the public API, do not add new packages, do not touch files outside the billing folder, or do not remove existing tests.

Negative instructions work best when paired with the reason and with a check, such as reviewing the list of changed files. Repeated limits belong in a project instruction file rather than in every prompt.

Practice. Add three do-not rules to a prompt and verify from the diff that each one held.

If AI Fails After Three Prompts, Stop Core

When several attempts at the same problem fail, the conversation has usually gone wrong: the context is polluted with failed attempts, the model is anchored on a bad idea, or the request is under-specified. More prompting in the same thread rarely helps.

Stop, revert to the last good commit, and start again with a fresh session and a better prompt that includes what you learned. Often the fix is to break the task down or to supply the missing fact. Sometimes the right move is to solve that part by hand.

Practice. Next time a problem resists three attempts, reset and restart with a rewritten prompt and note whether it worked.

Context Core

Context is everything the model sees when it answers: your messages, its earlier replies, file contents, command output, tool descriptions and project instructions. It has a fixed size, called the context window, measured in tokens. Anything outside it does not exist for the model.

Quality depends on what is in the window. Relevant, accurate material helps. Stale, repetitive or contradictory material hurts. Most skill in daily use is deciding what to put in, what to leave out and when to start afresh.

Practice. Look at the context usage display of your tool during a long session and note what took the most space.

Manage Context Core

Treat the window as a limited budget. Reference only the files that matter, ask the assistant to search instead of pasting whole directories, keep command output short, and summarise long threads. As a session grows, early instructions get less attention and the model may forget decisions made at the start.

Signs of trouble include repeated mistakes, ignoring earlier constraints, and slower or more expensive turns. Check usage regularly, for example with the context and cost commands that many tools provide, and act before quality drops.

Practice. Run a long session, record when answers began to degrade, and compare with a restarted session on the same task.

Use /compact and /clear Core

Claude Code offers two commands for housekeeping. The compact command summarises the conversation so far into a shorter form and carries on, which frees space while keeping the thread. The clear command wipes the conversation entirely for a clean start, while project instruction files are still loaded again.

Use compact in the middle of one long task, ideally with a note on what to keep. Use clear between unrelated tasks. Other tools have equivalents, such as a new chat or session command, and the principle is the same.

Practice. Compact a long session with a note on what to preserve and check that key decisions survived.

Project Instruction Files: CLAUDE.md and AGENTS.md Core

A project instruction file is a text file in the repository that the assistant reads at the start of each session. Claude Code reads CLAUDE.md, and many other tools read a shared convention called AGENTS.md. Put in it what a new colleague would need: how to build and test, the folder layout, naming and style rules, things to avoid and where important documents live.

Keep it short and specific. A file full of vague advice wastes context, while a file that says run the unit tests with one named command saves repeated explanations.

Practice. Write an instruction file for a real repository with build, test and style rules, then check an assistant follows them.

How to Structure CLAUDE.md Core

A useful layout has a few short sections: a one-paragraph project summary, commands for build, test and lint, an outline of the code layout, coding conventions, rules about what not to do, and pointers to deeper documents. Use plain sentences and bullet lists.

The init command can generate a first draft by scanning the repository. Edit it, because generated files tend to include obvious facts and miss the real traps. Add a rule every time you correct the assistant for the same mistake twice.

Practice. Run the init command on a project and cut the result to the ten lines that would really change behaviour.

Locations of CLAUDE.md Recommended

Instruction files can live at several levels. A personal file in your home configuration applies to every project. A file at the repository root is shared with the team through version control. Files in subfolders apply when the assistant works in that part of the tree. Local override files can hold personal notes that are not committed.

Use personal files for your habits, root files for team rules, and subfolder files for local conventions in large codebases. The memory command in the tool lets you view and edit what is loaded.

Practice. Create a personal file and a root file, then check which rules each session picks up.

File Path Mentions Recommended

Most tools let you point at a file or folder directly in a prompt, in Claude Code by typing the at sign followed by a path. This loads exactly the content you mean and avoids the assistant guessing or searching.

Use it for the files central to the task and let the assistant discover the rest. Mentioning an entire large directory floods the context, so prefer specific files.

Practice. Ask for a change twice, once with explicit file mentions and once without, and compare accuracy and token use.

Resume and Rewind Conversations Recommended

Sessions are not disposable. In Claude Code you can continue the most recent conversation, pick an older one to resume from a list, or rewind to an earlier point and discard what came after. Pressing the escape key twice opens the rewind choices, and the rewind command does the same.

This is useful when the assistant takes a wrong turn: rewind to the point before it, restate the request better, and carry on, rather than arguing in a polluted thread. Rewinding conversation state is separate from reverting code, so keep using git as well.

Practice. Deliberately let a session go wrong, rewind to before the mistake and redo the step.

The Agentic Loop Core

A coding agent runs in a loop: read the task, decide the next action, call a tool such as reading a file or running a command, look at the result, and repeat until it judges the job done or asks you something. Quality comes from the loop having real feedback, such as test output and compiler errors, not only from the model.

It follows that agents do best where there are fast, trustworthy checks. Give the agent a test command, a type checker or a linter and tell it to run them, and it will correct itself. See AI Agents Roadmap for how such loops are built in general.

Practice. Watch an agent complete a task with tests available and note each tool call it makes.

Coding Agent Core

A coding agent differs from autocomplete because it acts. It can search a repository, edit several files, run the test suite, read errors and try again. Some run on your machine in a terminal, others in a cloud sandbox from a task description, and then deliver a branch or pull request.

Local agents see your environment and need permission controls. Cloud agents are isolated but need your repository access and tell you less as they work. Whichever you use, ask it to explain what it changed, and read the diff.

Practice. Give an agent a small bug with a failing test and review the diff it produces before accepting.

Tools Core

Tools are the actions an agent may take: read and write files, search, run shell commands, fetch web pages, and call external services. Each tool is a capability and a risk. The more an agent can do, the more it can damage when it is wrong or manipulated.

Learn which tools your agent has by default, which need approval and which can be turned off. Provide extra tools through protocols such as MCP only when needed, and prefer narrow tools over general ones.

Practice. List the tools your agent can use and mark which ones could do irreversible harm.

Modes and Permission Modes Core

Agents usually have modes that trade speed for control. In a default mode they ask before editing files or running commands. A mode that auto-accepts edits speeds up work on trusted changes. A plan mode lets the agent read and think but not change anything. Fully permissive modes skip prompts altogether and should be kept for sandboxed environments.

In Claude Code the shift and tab keys cycle through modes during a session, and a command-line option sets a permission mode at start. The permissions command shows and edits the allow and deny rules, which let you approve common safe commands once and keep dangerous ones blocked.

Typing an exclamation mark at the prompt enters bash mode, which runs a shell command directly and puts its output in the context. Auto mode is a newer, more autonomous setting in which a safety check decides which actions proceed without asking. Use it only in disposable branches or sandboxes.

Practice. Set rules that allow your test and lint commands and deny deleting files, then confirm the agent respects them.

Plan Mode Core

Plan mode puts the agent in a read-only stance. It explores the code, asks clarifying questions and produces a proposed plan, which you approve or edit before it changes anything. It is the built-in form of plan before you code.

Use it for unfamiliar code, risky changes and anything touching many files. A model setting called opusplan uses a stronger model while planning and a faster one while executing, which balances quality and cost.

Practice. Use plan mode for a refactor, edit the plan, and see how closely the implementation follows it.

Subagents Recommended

A subagent is a separate agent instance with its own context window, instructions and tool set, started by the main agent for a focused job such as searching the codebase, reviewing a diff or running tests. It reports back a summary, so the noisy detail never fills the main conversation.

Subagents protect context and allow specialisation: a reviewer that may only read, a test writer with a particular style guide. In Claude Code they are defined as small files with a name, description, tools and prompt, and the agents command manages them. Use them for work that is self-contained and produces a short answer.

Practice. Create a read-only reviewer subagent and ask the main agent to use it on your last commit.

Skills Recommended

A skill is a packaged set of instructions, and optionally scripts and reference files, that the agent loads when a task matches it. Examples are a procedure for writing release notes, a checklist for database migrations or a house style for tests. Because only a short description is read up front, skills add little context until used.

Write skills with a precise description of when to use them, steps that are specific and checkable, and small supporting files. Reuse good skills that others have written, but read them first, since a skill is instructions your agent will follow.

Practice. Write a skill for a task you repeat weekly and test that the agent selects it on its own.

Model Context Protocol Core

The Model Context Protocol, or MCP, is an open standard for connecting assistants to external tools and data: issue trackers, databases, documentation, browsers and design files. A server exposes tools, and any compatible client can use them, so one integration works across tools.

It extends what an agent can do, and its attack surface. Each server runs with some authority and returns text that the model reads, which can contain injected instructions. Install servers from sources you trust, grant minimal permissions, and review what each tool can do. Claude Code manages servers with the mcp command, and many other agents support the protocol too.

Practice. Connect one read-only MCP server to your tool and use it to answer a question about your project.

Hooks Recommended

Hooks are scripts that run automatically at defined points in an agent's lifecycle, so behaviour is enforced by code, not by asking the model nicely. Typical uses: run the formatter after every edit, block commands that match a dangerous pattern, log tool calls, or send a notification when a task finishes.

Claude Code hooks fire on events such as SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, PermissionRequest, Stop, SubagentStop and SessionEnd. A matcher selects which tools a hook applies to, the hook receives details as input, and its exit status or output can allow, block or alter the action. Manage them with the hooks command.

Practice. Write a pre-tool hook that rejects shell commands containing a force push, and test it.

Plugins and Slash Commands Optional

Slash commands are shortcuts typed at the prompt, such as help, config, model, status and usage in Claude Code, and you can define your own as reusable prompts. Plugins bundle commands, subagents, skills, hooks and server settings so a team can share one setup.

Be mindful of extensions. A plugin can change what your agent does and run code, so review its contents, prefer ones from known authors, pin versions and remove what you do not use.

Practice. List the slash commands in your tool and write one custom command for a prompt you reuse.

Headless Mode and CI/CD Recommended

Agents can run without a person at the keyboard. Claude Code has a print mode, run with the p flag, that takes a prompt, performs the work and writes the result to standard output, which suits scripts, scheduled tasks and pipelines. Other flags continue or resume a session and control permissions.

claude -p "Summarise the failing tests in this log" < build.log
claude -p "List risky changes in this diff" --permission-mode plan < change.diff

In CI the agent can draft pull request reviews, triage issues or fix lint failures through integrations for GitHub Actions and GitLab. Run it with narrow permissions, since it is unattended and sees untrusted pull request content.

The claude command starts an interactive session. Running claude -c continues the latest conversation, and claude -r lets you choose an earlier one to resume. The flag claude --add-dir gives a session access to an extra folder, and claude --permission-mode sets the permission mode at start.

Practice. Add a scheduled or CI job that has an agent summarise open pull requests, with read-only permissions.

Agent SDK and Scheduling Optional

The same engine that powers the command line tool is available as a software development kit, so you can embed an agent in your own programs with custom tools and permission rules. This is how teams build internal bots for support, migrations or documentation.

Scheduling lets recurring work run on a timetable: a nightly dependency check, a weekly cleanup. Use loops and scheduled tasks sparingly, with budgets and alerts, because unattended agents that fail quietly are hard to notice.

Scheduled tasks can run on your own machine or in the cloud, and an agent team lets several agents coordinate on one job. Cloud scheduled tasks need no open laptop, but they also need repository access, so scope it narrowly.

Practice. Sketch an internal agent you would build with the SDK, listing its tools and the permissions each needs.

Testing Core

Tests are what turn generated code from plausible into trusted. Ask the assistant to write tests, but read them, because a model can write tests that pass for the wrong reason: asserting what the code does, not what it should do. Check that each test fails when the behaviour is broken.

Run the whole suite after every change, and give the agent the test command so it can run it itself. See Code Review Roadmap for the review side. A project without tests gets little safety from AI speed.

Ask AI to write tests, but also ask it for a list of possible causes whenever a test fails for no clear reason, and ask for modular code so each test has a small target.

Practice. Ask for tests for a function, then deliberately break the function and confirm each test catches it.

Consider Test-Driven Development Recommended

Test-driven development fits assistants well. You write or approve failing tests that describe the behaviour, then ask the agent to make them pass without changing the tests. The tests give it a clear target and give you a precise definition of done.

Tell the agent explicitly not to modify the tests to fit its code. Agents under pressure to pass will sometimes weaken a test, so review any change to test files closely.

Practice. Write three failing tests by hand and have an agent make them pass, checking it did not edit them.

Once Tests Are in Place, Refactor Regularly Recommended

Generated code tends to accumulate duplication and awkward structure, because each request is solved locally. With tests passing, schedule regular cleanup: ask the assistant to propose refactors, apply them in small steps, and re-run tests after each.

Ask for modular code in small files and functions from the start, which keeps each piece within what the model and you can hold in mind. Without tests, refactoring by assistant is a gamble.

Practice. Ask for a refactor proposal on one messy file, apply it in three small steps and run the tests after each.

Debugging Core

Assistants are useful debuggers if you give them evidence. Provide the error, the relevant code, what you expected, what happened and what you already tried. Ask for hypotheses before fixes, and verify each by experiment, not by reading the model's confident explanation.

Avoid the loop of pasting errors and accepting patches without understanding. If the fix works but you do not know why, ask for the explanation and check it. That is how you learn and how you avoid hidden bugs.

Practice. Debug a real failure by getting three hypotheses from an assistant and testing each.

Ask for a List of Possible Causes Core

When the cause is unclear, ask the assistant to list possible causes ranked by likelihood, with a quick check for each. This avoids fixation on the first guess and gives you a diagnostic plan you can follow yourself.

Work through the list in order, report what you found, and let the assistant revise. It is the same method as a good engineer's debugging notebook, with the assistant as a fast source of ideas.

Practice. Pick a flaky behaviour and write the ranked causes with one test each before changing anything.

Tell AI to Add Logs Core

When behaviour is hard to see, ask the assistant to add targeted logging around the suspect path: inputs, branch taken, values at key points. Run the code, paste the output back, and let it reason from real data.

Remove or reduce the logging afterwards, and never log secrets or personal data. Structured logs with clear messages are worth keeping in production code where they help future debugging.

Practice. Add logging to a failing flow, capture a run and use it to locate the fault.

Reviewing AI-Written Code Core

Review generated code as you would a stranger's pull request, with extra suspicion for confident but unverified claims. Read the diff, run it, and check against requirements. Look for invented functions or packages, silent error swallowing, hard-coded values, missing input validation, and unrequested changes elsewhere.

Ask the assistant to review its own work as a second pass, ideally in a fresh session or with a different model, and treat that as a hint, not a verdict. Code review tools and commands in agents can automate a first pass, and humans make the decision.

Practice. Review a generated pull request line by line and list every issue before asking an assistant to find any.

Security Best Practices Core

Generated code has the same weaknesses as human code, and often the common ones: missing authorisation checks, injectable queries, weak randomness, unsafe file handling and verbose errors. Models imitate what is common in training data, and a lot of common code is insecure.

Apply normal secure development: validate input, use parameterised queries, check authorisation on the server, keep dependencies updated, scan with static analysis and dependency tools, and review security-sensitive changes by hand. The Security Engineer role page and the AI Red Teaming Roadmap roadmap go deeper.

Practice. Run a static analysis tool on an AI-generated project and fix the top findings.

Always Use Environment Variables Core

Never put secrets such as API keys, passwords and tokens in source code, prompts or chat. Assistants will happily write a key into a file if you paste it, and it may end up in version control or in a provider's logs.

Read secrets from environment variables or a secret manager, keep local files that hold them out of version control, and add a pattern-based scanner as a commit check.

import os
API_KEY = os.environ["PAYMENTS_API_KEY"]   # fails loudly if missing

If a key is ever exposed, rotate it immediately, because deleting it from history does not undo the exposure.

Practice. Add a secret scanner to a repository and move any keys found into environment variables.

Explicitly Ask for a Security Audit Core

Ask the assistant to audit the application specifically for security: authentication and session handling, authorisation, input validation, injection, secrets, dependencies, logging and data exposure. Give it a checklist, such as the OWASP top ten, so the review is systematic.

Use a fresh session so it is not anchored on the code it wrote. Treat the output as leads to verify and fix, not as proof the code is safe, since models both miss real issues and report imaginary ones.

Practice. Request an audit with a checklist on a small app and verify each reported finding by hand.

Claude Code Security and Sandboxing Core

Agent tools run code and read files with your privileges, so containment matters. Claude Code asks permission for edits and commands by default, supports allow and deny rules, and offers sandboxing that restricts file and network access for commands it runs. The security model of any agent has the same layers: what it may do without asking, what it may never do, and what the operating system enforces regardless.

For risky or unattended work, use a container, virtual machine or dedicated user with no access to personal credentials, and restrict outbound network access.

Practice. Run an agent inside a container with only the project mounted and no access to your home directory.

Prompt Injection Against Coding Agents Core

An agent reads text from many places: issues, web pages, README files, dependency documentation, tool output. Any of it may contain instructions aimed at the agent, which can try to make it leak files, run commands or change code. Never trust external content to prevent prompt injection; assume it can be hostile.

Reduce risk by limiting permissions, blocking network access where possible, reviewing commands before approval, and keeping secrets out of reach. Be most careful when an unattended agent processes content from strangers, such as public issues. See AI Red Teaming Roadmap for the concepts.

Practice. Review which untrusted text sources your agent reads and what it could do after reading each.

Be Mindful of Extensions Core

Plugins, skills, MCP servers and community tools all extend what an agent does, and all run with some authority. Malicious or careless extensions can steal credentials, change code or send data away. Reports of harmful packages in public skill and plugin registries show the risk is real.

Install only what you need, from authors you can check, read what it does before enabling it, pin versions and review updates. Remove what you stop using.

Practice. Audit the extensions installed in your tool and remove or pin each one.

Dependencies and Hallucinated Packages Core

Models sometimes suggest packages that do not exist, and attackers can register those names with malicious code, a trick called slopsquatting. Models also pick outdated or unmaintained libraries and old API versions.

Before installing anything an assistant recommends, check that the package exists, is maintained, has a plausible history and matches what you want. Pin versions, use lock files, and run dependency vulnerability scans. Prefer a small number of well-known dependencies.

Practice. Check every dependency in a generated project for existence, maintenance and licence.

Licences, Copyright and Data Privacy Core

Generated code may resemble open-source code with licence conditions, and policies on ownership of AI output vary by country and are still developing. Many tools offer filters for code matching public repositories and some vendors offer legal indemnities, so read your terms and your employer's policy.

Privacy matters in the other direction: what you send to a tool may be stored or used for training depending on the plan and settings. Do not send customer data, secrets or proprietary code to services your organisation has not approved, and prefer enterprise plans or local models for sensitive work.

Practice. Read the data-use terms for your tool and write down what is retained and for how long.

How OpenClaw Works Recommended

OpenClaw is an open-source, self-hosted personal assistant. Unlike a coding agent that you start for a task, it runs continuously as a background service, receives messages from chat apps you connect, and acts for you using tools, files and models you configure. It is aimed at general automation, such as reminders, research and housekeeping, and can also help with coding.

Its pieces are a gateway that handles connections, channels for each messaging service, an agent that runs the model loop, a workspace of plain text files that hold instructions and memory, and optional skills and plugins. The project is young and changes quickly, so check its current documentation for commands and options.

Practice. Read the overview of the project and draw the flow of one message from a chat app to an action.

Why and Why Not? Recommended

The attraction is an assistant that is always available, remembers context over weeks, reaches you where you already chat, and works on your own hardware and chosen models. It can run tasks on a schedule and act without being asked.

The cost is risk. An agent that is always on, holds credentials and reads messages from outside is a larger target than a tool you open and close. Limitations include model mistakes, setup effort and the need to maintain it. Use it if you accept those trade-offs, and begin with low-stakes tasks.

Practice. Write a short pros and cons list for running such an agent for your own needs and decide whether to try it.

OpenClaw vs Claude Code Recommended

They overlap in ideas but differ in purpose. Claude Code is a coding agent you start in a project for a bounded task, with a developer present and permission prompts. OpenClaw is a persistent assistant reached through chat apps that runs in the background, keeps long-term memory files and acts on schedules and events.

Many concepts transfer between them: instruction files, skills, memory, hooks, MCP and permission control. The difference in risk is mostly about duration, reach and who may talk to the agent.

Practice. Make a table comparing the two tools on trigger, lifetime, memory, reach and main risks.

Installation, Onboarding and Setting Up Recommended

Installation is done with the project's installer or a container image, followed by an onboarding command that walks through choosing a model provider, creating the workspace, setting the gateway and adding a first channel. The openclaw doctor command checks the setup for problems, and a deeper check inspects more.

Install it on a machine that you can afford to isolate, such as a spare computer, small server or virtual machine. Run it as a normal user, not as the administrator, and read what each setup step changes.

Practice. Install it in a virtual machine, complete onboarding and run the doctor command.

Auth, Model Providers and Local Models Recommended

The agent needs a language model. It can use hosted providers such as Anthropic, OpenAI and Gemini through keys or tokens, or run local models through Ollama. Commands list, set and check the models in use, and add authentication.

Hosted models are usually stronger and send your content to a provider, while local models keep data on your machine but are weaker and need hardware. Store keys outside the workspace, never hard-code them, and set spending limits with the provider.

Practice. Configure one hosted and one local model and compare their answers on three tasks.

Channels Recommended

A channel connects the assistant to a messaging service such as WhatsApp, Telegram, Discord, Slack, Signal or iMessage. You add a channel, log in, and check its status with the channel commands. Routing rules decide which agent or session handles messages from which conversation.

Each channel is an entry point for instructions, so decide who may use it. Start with one private channel that only you can write to, and add others only when you have controls such as an allowlist of senders.

Practice. Connect a single private chat channel and confirm messages from anyone else are ignored.

Workspace Files and Memory System Recommended

The agent's behaviour and memory live in text files you can read and edit. AGENTS.md holds operating instructions, SOUL.md the personality and values, USER.md facts about you, and MEMORY.md durable notes. Daily notes go in dated files under a memory folder, and an index supports search over them with the memory commands. HEARTBEAT.md describes what to check on each periodic wake-up.

Because everything is plain text, you can audit what the agent believes and remove anything wrong or sensitive. Review these files regularly, since memory can also store injected content.

Practice. Read each workspace file of a test install and delete one memory entry you would not want kept.

Heartbeats, Cron Jobs and Automating Tasks Optional

Heartbeats are periodic wake-ups within active hours at an interval you set, when the agent checks its heartbeat file and acts if something needs attention. Cron jobs run specific tasks at specific times and can be listed, added, managed and disabled with commands. Together they make the assistant proactive.

Proactive agents can also fail quietly or run up costs. Give each scheduled task a clear purpose, a small permission set and a budget, and review logs.

Practice. Add one daily scheduled task with a narrow purpose and verify what it did after a week.

Skills, Plugins and ClawHub Optional

Skills teach the assistant procedures, plugins add new capabilities, and a public registry called ClawHub distributes both. You can create your own or install others.

Registries of community skills and plugins have carried malicious entries in practice. Treat installing one like running unknown software: read it, check the author, install only what you need and keep it updated.

Practice. Read the full text of a published skill before installing it and note anything that touches credentials or the network.

Hardening a Self-Hosted Agent Core

Apply these in order. Deploy on an isolated machine, VM or container rather than your main computer, and run as a non-root user. Bind the gateway to localhost so it is not reachable from outside, and set a strong gateway authentication token. Enable device pairing and keep a minimal sender allowlist. Never hard-code API keys. Start in read-only mode and widen permissions deliberately.

Never trust external content: messages, web pages and files can carry injected instructions. Run the built-in security audit command, including its deep option, after every configuration change, update regularly, and if a breach is suspected rotate all credentials immediately. A VPS or other cloud server suits an always-on agent, but a dedicated device such as a Mac Mini or Raspberry Pi keeps data at home.

Practice. Run the security audit on a test install and fix every finding, then repeat after a config change.

Models and Thinking Effort Recommended

Providers offer a range of models. Larger ones, such as the Opus tier from Anthropic, reason better and cost more. Mid-sized ones like Sonnet balance quality and speed, and small fast ones like Haiku suit simple, high-volume work. Other vendors have similar tiers. Tools let you switch with a model command and adjust thinking or reasoning effort.

Match the model to the task: small models for search and summaries, mid-sized for everyday edits, large for design and hard bugs. Model names and capabilities change often, so test on your own tasks.

Practice. Run one hard and one easy task on two model tiers and compare quality, time and cost.

Pricing, Usage and Subscriptions Recommended

Usage is billed in tokens, either through API pricing, where you pay per token, or through subscription plans with usage limits. Agents use many tokens because they re-read context and loop, so costs can surprise you.

Watch the usage and cost displays, keep sessions focused, use cheaper models for easy work, and set budgets and alerts. Compare plans against your real usage and check the current terms, since they change.

Practice. Track token use for a week of normal work and estimate the monthly cost under each pricing model.

Common Use Cases Core

Assistants shine on certain jobs: explaining unfamiliar code, writing boilerplate, generating tests, small refactors, migrations across many files, writing documentation, drafting scripts and prototypes, and first-pass reviews. They are weaker on subtle concurrency bugs, large architectural decisions and anything needing knowledge that is not in the context.

Use them to widen what you can attempt, and keep the work that needs judgement for yourself. Choose tasks with fast feedback, where you can check the result quickly.

Claude Code Models and other tiers appear later in this roadmap. In short, a connection to tools with MCP, a code review on PRs and a scheduled job are the usual first extensions people add.

Practice. List your ten most frequent tasks and mark which suit an assistant, which need caution and which are yours alone.

Code Review on Pull Requests Recommended

Assistants can review pull requests automatically, commenting on bugs, risky changes, missing tests and style. This catches routine problems early and frees humans for design discussion. Some tools also provide deeper review commands for larger changes.

Keep a human approver. Automated reviewers produce false positives and miss context, and people tend to approve whatever the bot approves. Make the author responsible for AI-written code as if they had typed it.

Practice. Enable an assistant review on a repository and track how many of its comments were useful over a month.

Team Policies and Conventions Core

Teams need shared rules: which tools and plans are approved, what data may be sent to them, what must be reviewed by a human, how generated code is labelled, and who owns security of agent configurations. Put project instructions, skills and hook settings in the repository so everyone gets the same behaviour.

Include training for newer developers, so that they still learn fundamentals. Review the policy regularly, because tools and risks change.

Practice. Draft a one-page policy covering approved tools, data rules, review requirements and ownership.

Limitations and Honest Expectations Core

Assistants hallucinate APIs, miss requirements, overlook edge cases, produce inconsistent style and lose track of long tasks. They can be confidently wrong, and quality varies by language, task and prompt. They do not understand your business unless you tell them.

Keep learning the fundamentals so that you can judge the output. The people who benefit most are those who can read and test what is produced, and who know when to stop and do it by hand. Community tools and tips are useful, but verify them against your own experience.

Practice. Record every mistake an assistant made in a week and sort them into categories you can guard against.