You now know how models are built and trained. The final frontier is agents — AI systems that do not just answer questions but take actions: run code, edit files, browse the web, and coordinate with other agents. This chapter introduces the Claude ecosystem and Claude Code as a working example, then maps the skills you have learned onto two realistic career paths, and closes with a roadmap.
Claude is a family of large language models trained to be helpful, honest, and safe. Around the models sits an ecosystem of tools: the Claude web and mobile apps for conversational use; Claude API for developers to embed Claude in their products; Claude Code, a command-line tool that works directly inside a repository and acts like an engineering teammate; and Claude Skills, Hooks, and Subagents that customize and extend what Claude Code can do. Everything you learn here transfers to other agentic frameworks.
Think of the ecosystem as layers of increasing control. The web app answers questions. The API lets your own code call the model. Claude Code lets the model operate on your filesystem with your approval. Skills and hooks let you shape how it operates. Each layer gives you more leverage — and demands more discipline from you as the human who supervises it.
Claude Code runs in your terminal, inside your project. Install it, log in, and start a session:
npm install -g @anthropic-ai/claude-code
claudeInside the session you type requests in plain English — "add a /health endpoint to this Flask app" — and Claude Code reads your files, plans, edits code, runs commands, and shows you a diff of every change. You approve edits before they land, and you can ask for explanations at any step.
A typical working rhythm: state the goal, let Claude Code inspect the repository and propose a plan, approve the plan, review each diff as it is applied, run your test suite, and iterate. You stay in the driver's seat — the tool accelerates the work you already know how to supervise. For beginners, treat the transcript as a tutor: every time Claude Code does something surprising, ask it to explain the reasoning step by step.
An agent is defined by a name, a role, a system prompt, and a set of tools. Start small: a single agent that owns a well-scoped job, such as "refactor the data-loading module". Give it precise instructions, tell it which files it may touch, and run it. As your workflows grow, combine multiple agents so each one stays focused on its specialty.
claude "Refactor the loader module into loader.py and
validate.py. Keep the public API unchanged, update the
tests, and run pytest until everything passes."The shape of a good agent prompt is the shape of a good task brief: a clear objective, the files and tools allowed, the acceptance criteria, and the failure rules ("if the tests cannot be fixed, stop and report"). The narrower the agent's charter, the more reliable its work — broad charters are how agents drift off course.
Agent views are different lenses for supervising and steering your agents. A plan view shows the steps an agent intends to take before it acts; a diff view shows exactly what code changed; and an output view streams what the agent is doing in real time. Checking the plan first, then the diff, keeps you in control of anything the agent modifies.
Use the views deliberately rather than reactively. Before you approve an agent's first action, read the plan and look for scope creep — an agent asked to "clean the loader" sometimes decides to rename the whole package. After each tool call, scan the diff view for changes outside the allowed files. Reviewing output streams also teaches you how agents behave: you will quickly learn which prompt styles produce disciplined plans and which produce shotgun edits.
For larger tasks, define an agent team: a coordinator agent plus specialist agents, each with its own prompt and allowed tools. The coordinator breaks the task into pieces, delegates to the specialists, and merges their results. For example, one agent analyzes the dataset, one trains models, and one writes the deployment config, all coordinated by a lead that keeps the project on track.
Hooks are small scripts that Claude Code runs automatically at defined points in its lifecycle — before or after a tool call, when a message starts, when a command completes. They enforce rules you cannot trust an agent to remember: running a linter after every edit, blocking pushes to the main branch, or sending a notification when a long task finishes.
# after every file edit, run the formatter
on: PostToolUse
command: python -m black --check "$FILE"A good hook suite encodes your team's non-negotiables. Start with three: format the edited file, run the unit tests before Claude declares a task done, and refuse to let any command touch the prod environment. Each one is a few lines, and together they convert "please be careful" from a hope into a guarantee.
Skills package reusable instructions and helper scripts into a folder that Claude loads when the task matches, like a reference manual the model can follow. Plugins bundle skills, hooks, and configuration into a versioned unit you can share across projects. Together they let teams capture hard-won knowledge — "how we do code review here" — and reuse it on every project.
When you add a skill, write it as instructions you would give a competent junior teammate: the goal, the exact commands, the quality bar, and the mistakes to avoid. Claude follows them mechanically, so the precision is what pays off. Your own experience from earlier chapters — the encoding steps, the validation splits, the deployment checklist — is exactly the kind of knowledge worth packaging as a skill.
What the role involves: pulling articles from hundreds of feeds, deduplicating stories about the same event, classifying articles into topics, extracting key entities and dates, building a summarization pipeline, and serving a searchable API. Day to day you will balance model work with data plumbing and careful evaluation of pipeline quality.
Skills that matter: the full NLP stack from this book — tokenization, embeddings, classification with BOW/TF-IDF and with neural models, summarization concepts, and the transformers intuition from Chapter 38 — plus Python, Docker, Git, and API design. You need to measure quality: precision and recall of topic tags, and human-verified samples of summaries.
A typical day: you might add a new news source to the ingestion pipeline, inspect a spike in duplicate articles and tighten the deduplication threshold, retrain the topic classifier after the vocabulary drifted, and ship a summary-length change based on reader feedback. Most of the time is data and evaluation, not model math — which is why the engineering chapters of this book matter as much as the algorithm chapters.
Sample project approach: (1) ingest a small RSS corpus into a pipeline with metadata; (2) cluster near-duplicate headlines with embeddings and compare against an exact-match baseline; (3) fine-tune a small transformer classifier for topics; (4) expose the pipeline through a FastAPI service, containerize it, and deploy it; (5) build an evaluation report and iterate. Start on your own machine, then move the pieces to the cloud exactly as in Chapters 29–30.
To stand out, add the evaluation step that most portfolios skip: build a labeled sample of fifty stories, report precision, recall, and latency, and show how you would know when to retrain. Interviewers in this role ask for exactly that — evidence of judgment, not just working code.
What the role involves: turning user reviews into signal. You build sentiment models, detect fake or duplicated reviews, identify the reasons behind ratings (plot, acting, pacing), and produce dashboards and recommendations the product team can act on. You are judged on both model quality and how clearly you communicate findings.
What the role involves day to day: most weeks blend exploration, modeling, and communication in roughly equal parts. You query review tables, inspect drift when a new film genre surges, retrain classifiers, and translate a drop in the F1 score into a story a product manager can act on. Honest metrics and reproducible experiments are the currency of this job.
Skills that matter: the classification and regression toolbox — logistic regression through the neural networks in Chapters 33–37 — plus feature engineering, careful train/test discipline, cross-validation, and strong storytelling with charts. The IMDB projects in Chapters 36–37 are essentially a miniature version of this job.
A typical day: you might investigate why predicted sentiment dropped over the weekend, discover that a blockbuster release skewed review vocabulary, retrain with a date-aware split, and present the corrected results to product managers who care about which features drive ratings — not about the architecture of your model.
Sample project approach: (1) build the sentiment pipeline from Chapter 36 on a large review dump; (2) add aspect analysis by training a model per aspect category; (3) compare the RNN against an LSTM and a transformer, documenting metrics and runtime; (4) package the winner behind a Streamlit app for stakeholders; (5) write a short report connecting model outputs to business decisions, such as which features drive low ratings. This portfolio directly mirrors what hiring managers in this role look for.
The single most important habit you can adopt now is shipping small things repeatedly. A tiny model deployed and shared beats a perfect model that never leaves your laptop. Every chapter in this book was a step toward that habit; the next step is yours to take.
Wherever the field moves next — bigger context windows, better agents, new model families — the principles hold steady: understand your data, measure your results, keep your pipeline honest, and communicate what the model can and cannot do. You have built that foundation from the ground up. Now go use it.