📋 Executive Summary
- 📝 Contract-First Coding: Contract-first prompts define the runtime, interface, edge cases, dependencies, and acceptance tests before Claude generates code.
- 🔍 Plan Before Editing: Plan mode lowers repository risk by separating read-only analysis from modifications, while Git remains the authoritative rollback mechanism.
- ⚙️ Project Rules Need Enforcement: CLAUDE.md provides useful project guidance, but hooks and CI systems should handle checks that cannot be skipped.
- 💰 Pricing Reality: Plans start at $17 monthly with annual Pro billing, but five-hour sessions, weekly limits, shared usage, and API overages determine the actual cost.
- 📊 Performance Evidence Varies: Anthropic reported 82.0% on its Sonnet 4.5 SWE-bench Verified method, while METR measured a 19% slowdown among experienced developers.
- ✅ Decision Rule: Use Claude for bounded and testable implementation tasks, while keeping human ownership of requirements, security, architecture decisions, and production approvals.
How to write code with Claude is best approached as a testable engineering contract, not a request for plausible-looking syntax, and the sharpest warning is that a 2025 randomised trial found experienced developers took 19% longer with early AI coding tools even while believing they were faster (Becker et al., 2025). I use that contradiction as the organising principle for this guide: Claude can generate, inspect, edit, run and review code, but productivity appears only when the prompt defines success, the environment exposes the right context, and a human verifies the result.
The practical workflow is straightforward. Choose the Claude surface that can see the relevant project. Specify the language, runtime, exact deliverable, inputs, outputs, edge cases, dependencies and acceptance tests. Ask for a plan before broad edits, then request one bounded implementation unit. Run the tests yourself, return the exact failure, and ask for the smallest corrective patch. For repository work, persist conventions in CLAUDE.md, use path-scoped rules for specialised directories, reserve hooks for non-negotiable checks, and keep Git as the authoritative history.
Claude Code now operates across the terminal, VS Code, JetBrains IDEs, the desktop app and the web, with GitHub Actions, GitLab workflows, Model Context Protocol connections and an Agent SDK for programmable automation. That breadth is useful, but it also creates hidden variables: model choice, context size, cache behaviour, subagent use, MCP overhead, rate limits and permission settings can all change the result or the bill. The sections below turn those variables into a reproducible method for functions, command-line tools, APIs and multi-file changes.
How to Write Code with Claude: The Contract-First Workflow
The most reliable way to work with Claude is to separate intent from implementation. A weak prompt says, “write a CSV parser”. A contract-first prompt states who will call the code, what form the input takes, what the output must contain, how malformed data should be handled, which libraries are allowed, and which tests decide whether the work is complete. This turns the conversation from open-ended generation into a bounded engineering task.
Claude Code’s documented agent loop gathers context, takes action and verifies results. Your prompt should mirror that loop. First, ask Claude to restate the specification and list assumptions. Second, ask it to inspect only the files needed for the task. Third, ask it to implement the smallest coherent change. Fourth, require it to run the relevant test command and report the outcome. If it cannot run tests in the current surface, require exact commands and expected results rather than accepting a confident explanation (Anthropic, 2026b).
A useful acceptance contract contains six elements: the runtime and framework version; the named unit to build; input and output schemas; explicit edge cases; dependency rules; and executable examples. Add constraints that are easy to verify, such as maximum function length, type annotations, error classes, database transaction behaviour or an HTTP status matrix. Avoid style adjectives such as “clean” unless you define what clean means in the repository.
The original editorial insight is to treat the prompt as a temporary interface specification. Once the code passes, move stable project facts into version-controlled instructions or tests. Do not leave the only record of a design decision inside a chat transcript. The prompt initiates the work, but the repository must retain the evidence.
How to Write Code with Claude for a Single Function
For one function, name it and pin its signature before asking for code. State whether invalid input raises, returns a sentinel, or produces a structured error. Include at least one normal case, one boundary case and one malformed case. Ask Claude to return the function, tests and a short complexity note. This small scope reveals misunderstandings quickly and gives the model less room to invent architecture you did not request.
Choose the Right Claude Surface and Model
Claude’s coding products share model capabilities, but they do not share the same access to files, commands or execution. Claude chat is suitable for isolated snippets, explanations and design discussion. Claude Code is the better fit when the assistant must inspect a repository, edit files, invoke tools or run tests. The terminal gives the widest direct control, while IDE extensions keep diffs and diagnostics close to the code. The web surface is useful for cloud sessions attached to GitHub repositories, and the desktop app provides another route into local work.
Start with the least powerful surface that still exposes the required context. A single algorithm does not need repository-wide access. A failing integration test probably does. This is both a quality decision and a security decision because every additional tool, connector and directory expands the action surface.
Model choice should follow task shape rather than prestige. Anthropic’s July 2026 pricing page positions Sonnet 5 as the high-performance coding and agent model, Opus 4.8 for complex agentic coding and enterprise work, Haiku 4.5 for faster economical workloads, and Fable 5 for long-running agents. Model availability can vary by plan and deployment. For most bounded coding tasks, begin with the default coding model and escalate only when the work needs longer planning, broader architectural reasoning or repeated failed attempts (Anthropic, 2026a; Anthropic, 2026b).
Do not confuse a larger model with a larger permission boundary. Plan mode, manual approvals and repository rules still matter. A more capable model can execute a flawed instruction more effectively, which makes specification quality more important, not less.
Surface Selection Matrix
| Surface | Best For | Context and Actions | Primary Constraint |
| Claude Chat | Snippets, explanations, design | Pasted files and conversational context | No direct repository execution by default |
| Terminal CLI | Repository work and automation | Reads files, edits, runs commands, uses tools | Requires careful permissions and command review |
| VS Code | Interactive coding and diffs | Editor diagnostics, selections, local sessions | IDE state and plan usage still require review |
| JetBrains | Java, Kotlin, Python and IDE-native work | Project context and supported IDE actions | Plugin compatibility and organisation controls |
| Desktop or Web | Local or cloud sessions | Desktop files or GitHub-backed cloud work | Surface-specific sync and access limits |
| CI and GitHub Actions | Issue-to-PR and repeatable automation | Repository workflow with configured credentials | Must use narrow permissions and branch protection |
Build a Prompt That Functions as a Technical Contract
A precise coding prompt has a recognisable order. Begin with context, then the task, then constraints, then tests, then output format. Context should include only facts that affect implementation: runtime, framework, operating system, package manager, relevant file paths, architecture conventions and the command used to run tests. The task should name one outcome. Constraints should make prohibited behaviour explicit. Tests should define observable success. Output format should tell Claude whether to edit files, return a patch, or print code blocks for manual review.
Use examples to resolve ambiguity, not to decorate the prompt. For a parser, examples establish quoting, missing values and encoding expectations. For an API, examples establish status codes and response bodies. For a CLI, examples establish flags, exit codes and stdout versus stderr. A single concrete example can prevent several rounds of correction because it constrains both semantics and presentation.
The prompt below is intentionally explicit. It can be adapted to another language by replacing the version, test framework and standard-library constraints. It also asks Claude to identify uncertainty before implementation, which is often more valuable than a fast first draft.
When the task is exploratory, allow Claude to ask questions or propose two designs. When the task is production-bound, reduce optionality. Tell it which interface is fixed, what it may change, and which files are out of scope. This keeps the response aligned with the change you can actually review.
Prompt Template
Context: I am building a Python 3.11 command-line tool that converts CSV text to JSON.
Task: Implement parse_csv(text: str) -> list[dict[str, str]]. Treat the first row as headers.
Requirements:
– Use only the Python standard library.
– Handle quoted commas and escaped quotes.
– Return [] for malformed CSV input.
– Include a docstring and type annotations.
– Do not change any files outside src/parser.py and tests/test_parser.py.
Acceptance tests:
1. name,age\nAda,36 -> [{“name”: “Ada”, “age”: “36”}]
2. name,note\nAda,”London, UK” preserves the comma in note.
3. Unclosed quotes return [].
Process:
1. Restate the specification and list assumptions.
2. Propose a short plan without editing.
3. Implement the function and pytest tests.
4. Run pytest and report the exact result.
Output: Show the changed files, test result, complexity, and any remaining limitation.
Scope the First Deliverable Before Expanding
Large requests hide multiple failure modes. “Build an authentication service” contains data modelling, password policy, session management, transport security, routes, logging, tests and deployment assumptions. Claude may fill every gap, but the resulting system can be internally coherent and still wrong for the organisation. A safer sequence is specification, interface, one vertical slice, tests, then expansion.
For greenfield work, ask first for the file layout and public interfaces without implementation. Review the boundaries, then approve one module. For an existing repository, ask Claude to map the relevant call path and identify the smallest change set. A good first deliverable is often one function, one endpoint, one migration with rollback, or one failing regression test. The smaller unit gives you a fast signal about whether the assistant understands the codebase.
This is also where cross-tool lessons matter. The same principle appears in a disciplined ChatGPT coding workflow: prompt the model to restate the technical specification, plan the work and remain inside a human-reviewed loop. The useful comparison is not which chatbot writes prettier code. It is which workflow exposes assumptions early enough for a developer to reject them cheaply.
Expansion should be conditional. Move to the next file only after the current unit passes its tests and the public interface remains correct. For multi-file projects, ask for a change ledger that lists each file, the reason it changed and the validation performed. That ledger gives reviewers a map and makes accidental scope growth visible.
Make Tests the Acceptance Boundary
Tests are not an optional appendix to AI-generated code. They are the acceptance boundary that turns a conversational output into a falsifiable artefact. Ask for tests before, with or immediately after implementation. For a defect, request a regression test that fails against the current code before the fix is applied. For a new feature, define behavioural tests around the public interface rather than snapshots of internal implementation.
A useful minimum set covers a normal case, a boundary case, malformed input and one interaction with an external dependency. Add property-based, concurrency or security tests when the risk demands them. Ask Claude to explain what each test protects and which important behaviour remains untested. This last question counters the tendency to produce a tidy test suite that mirrors the implementation while missing the real failure surface.
Do not let Claude be the only author and only judge. Run the tests in an independent process, inspect the diff and use a separate static analyser or review pass. Our wider guide to automated code review platforms shows why a second system can surface different classes of problems, although no review agent replaces domain ownership. In a regulated or high-impact system, require traceability from requirement to test to code change.
The hidden technical detail is that passing generated tests may prove only that code and tests share the same mistaken assumption. Include examples written by a human, existing production fixtures, contract tests against real schemas, and negative tests that Claude did not propose. The best prompt is not “make all tests pass”. It is “make these independent acceptance tests pass without weakening them, then explain any test you believe is invalid before changing it”.
Debug with Evidence, Not General Instructions
When generated code fails, return evidence rather than judgement. Paste the exact command, exit code, stack trace, failing assertion, runtime version and the smallest relevant code path. State what you expected and what happened. Do not say “it does not work” or ask for a general rewrite. Broad repair prompts invite Claude to change unrelated code and can destroy useful diagnostic information.
Use a four-step debugging loop. First, ask Claude to classify the failure as environment, dependency, syntax, type, logic, data, concurrency or integration. Second, ask for the most likely cause and two alternatives, each tied to evidence. Third, request the smallest patch that distinguishes or fixes the leading hypothesis. Fourth, rerun the failing test and the nearest regression suite. This loop makes reasoning inspectable without requiring the model to reveal private internal thought.
The conversational role resembles AI pair-programming fundamentals, but the human remains the driver of acceptance. Claude can search for call sites, compare similar modules, add logging and construct a minimal reproduction. The developer must decide whether the proposed change preserves the product’s invariants.
Version-specific research is especially important when the error involves a newly released framework or deprecated API. Use official documentation and verify version-specific coding answers before accepting a package name, command flag or configuration field. When Claude cannot verify a fact, ask it to label the uncertainty and provide a check command. An explicit “not confirmed” is safer than a plausible dependency that does not exist.
Use Plan Mode for Repository-Scale Work
Repository-wide changes should begin in plan mode. Anthropic documents plan mode as a read-and-analyse state in which Claude can inspect files and run exploratory shell commands but does not edit source. This is the moment to demand a dependency map, a proposed file list, migration sequencing, rollback considerations and the test plan. Review that plan before allowing edits (Anthropic, 2026c).
A strong repository prompt names invariants. Examples include keeping the public API backwards-compatible, avoiding schema changes, preserving a latency budget, using the existing logging library, or touching only one package in a monorepo. Ask Claude to identify which invariant is hardest to preserve. That answer often reveals the real risk before code is changed.
For parallel work, use Git worktrees or isolated branches so simultaneous sessions do not collide. Delegate research or codebase discovery to subagents when available, but remember that subagents consume context and tokens. Ask each subagent for a concise evidence summary rather than a broad narrative. The main session should retain the decision record, not every file it inspected.
The wider agentic coding tool comparison is useful here because repository agents differ more in permissions, context handling and review surfaces than in raw code completion. Claude Code’s checkpoints add a local safety net, yet they are not a substitute for Git. Anthropic’s documentation notes that file checkpointing covers edits made through specific edit tools, while changes made through shell commands may not be captured. Commit known-good states before major steps and inspect `git diff` after each stage (Anthropic, 2026c).
Encode Project Knowledge with CLAUDE.md, Rules, Skills, and Hooks
Repeated corrections belong in repository context, not in repeated prompts. Claude Code loads CLAUDE.md files as persistent project instructions. Good entries describe architecture boundaries, build commands, style rules, naming conventions, generated-file policies and testing expectations. Keep them concise. Anthropic states that CLAUDE.md is advisory context rather than enforced configuration, so it should guide judgement rather than carry critical controls (Anthropic, 2026c).
Use path-scoped rules when conventions apply only to part of a repository, such as database migrations, frontend components or infrastructure code. Use skills for reusable procedures that are invoked when relevant, such as a release checklist, incident analysis or API client generation. Use settings for permissions, environment values and defaults. Use MCP configuration to connect external systems only when the task needs them.
Hooks are different. They execute commands, endpoints or prompts at defined lifecycle events and are appropriate for actions that must occur every time. Examples include running ESLint after an edit, blocking writes to a migration directory, scanning for secrets before a commit, or requiring a test command before the session stops. This distinction is an important information-gain point: put advice in CLAUDE.md, but put non-negotiable enforcement in deterministic hooks or CI. The same governance question appears in GitHub Copilot’s review model, where convenience matters less than whether review rules are visible, enforceable and auditable.
The table below prevents a common configuration error, which is expecting a prose instruction to behave like a policy engine. Treat changes to these files as code review material. A poorly scoped hook can block legitimate work, while an oversized CLAUDE.md can consume context and dilute the rules that matter (Anthropic, 2026c).
Project Control Matrix
| Artefact | Purpose | Enforcement Level | Typical Example |
| CLAUDE.md | Persistent project context | Advisory | Build commands, architecture, style |
| .claude/rules/ | Path-scoped guidance | Advisory | Migration or frontend conventions |
| Skills | Reusable procedure or domain knowledge | Prompt-driven | Release checklist or API workflow |
| settings.json | Permissions, hooks, environment and defaults | Configuration | Block tools or set model defaults |
| Hooks | Automatic lifecycle actions | Deterministic when configured | Run tests or block risky writes |
| .mcp.json | External tools and data sources | Connector access | Issue tracker or monitoring service |
| Git and CI | History, review and policy gates | Authoritative | Protected branch and required checks |
Integrate Git, IDEs, CI, MCP, and the Agent SDK
Claude Code is available in the terminal, VS Code, JetBrains IDEs, desktop and web surfaces. It can participate in GitHub Actions and GitLab workflows, use `@claude`-style issue or pull-request automation where configured, and connect to external tools through the Model Context Protocol. The Agent SDK exposes the same core agent loop and tools to Python and TypeScript applications. Enterprise deployments can route through Anthropic directly or supported cloud and gateway configurations.
The documented feature inventory relevant to this workflow includes repository reading, file edits, shell execution, test runs, plan mode, checkpoints, session resume, worktrees, subagents, skills, hooks, plugins, MCP servers, project memory, usage reporting, status lines, remote control, GitHub Actions, GitLab CI/CD, code review, the Agent SDK, enterprise gateways, analytics and OpenTelemetry. Availability varies by surface, version, plan and administrator policy (Anthropic, 2026b; Anthropic, 2026c).
Integration should follow the principle of minimum necessary context. Connect an issue tracker when Claude needs acceptance criteria. Connect observability when it needs a failing trace. Connect a database only when a read-only schema or controlled query is necessary. Do not attach every available MCP server to every session. Anthropic’s usage tooling attributes recent consumption to MCP servers, skills, plugins and subagents because each source can add context and cost.
Editor choice changes the review experience. The comparison between editor-first versus chat-first workflows is relevant because IDE-native tools expose diagnostics, selections and diffs continuously, while chat surfaces encourage explicit context packaging. Claude Code can bridge both modes, but the developer should decide whether the task benefits more from local immediacy or from a deliberate, bounded prompt.
For CI, require narrow permissions and predictable triggers. A pull-request agent should not hold production credentials. Pin action versions, restrict repository scopes, log tool calls and require branch protection. For the Agent SDK, define allowed tools, permission callbacks, maximum turns, timeouts and structured outputs. Production automation should fail closed when validation is missing, and every autonomous patch should arrive as a reviewable diff rather than a silent mutation.
Control Security, Permissions, Dependencies, and Secrets
Claude can write secure-looking code while introducing an unsafe dependency, an over-broad permission, a shell injection path or a secret leak. Security review must therefore begin before generation. Tell Claude which data classifications apply, whether external calls are permitted, which package registries are approved, and which directories or commands are prohibited. Ask it to list security assumptions before implementation.
Use manual approval or plan mode for unfamiliar repositories. Deny access to credential files and production environments. Keep secrets in the organisation’s secret manager rather than in prompts, CLAUDE.md or shell history. When a task needs environment variables, provide names and mock values, not live credentials. Review generated commands carefully, especially destructive filesystem operations, database migrations, package installation and remote scripts.
Dependency control should be explicit. Ask Claude to prefer the standard library where reasonable, explain every new package, verify the licence and maintenance status, pin compatible versions and produce a software bill of materials where required. A package name that sounds plausible is not evidence. Require the official package page or lockfile resolution before adoption.
Claude’s own misuse reporting demonstrates that agentic coding tools can lower the barrier to harmful operations, which makes organisational controls essential even for ordinary teams. The practical answer is layered review: least-privilege tool access, deterministic hooks, CI security checks, dependency scanning, secret scanning, human approval and post-merge monitoring. A model-generated security checklist is useful only when it is translated into executable controls and accountable review.
Understand Pricing, Usage Caps, and Cost Bottlenecks
Claude Code can be included in subscriptions or billed through usage-based access. As of 12 July 2026, Anthropic lists Pro at $17 per month when billed annually or $20 monthly, Max from $100 per month, Team Standard at $20 per seat monthly on annual billing or $25 month-to-month, and Team Premium at $100 annually billed per month or $125 monthly. Enterprise is listed at $20 per seat plus model usage at API rates, with sales-assisted options also available. Taxes and regional pricing can differ (Anthropic, 2026a).
The hidden limit is that a subscription price is not an unlimited coding allowance. Anthropic’s Help Centre describes five-hour session limits and weekly limits for paid plans, with exact message counts or coding hours affected by conversation length, model, effort and feature use. Pro and Max usage is shared across Claude surfaces. Team limits are per member. Usage-based Enterprise has no per-seat allowance because usage is metered separately. Paid users can enable usage credits and continue at standard API rates after included limits are reached (Anthropic, 2026a).
For teams using API billing, Anthropic reports enterprise averages around $13 per developer per active day and $150 to $250 per developer per month, while cautioning that codebase size, model and parallel sessions produce wide variation. These are observed averages, not a guaranteed cap (Anthropic, 2026a). The free coding assistant landscape may be a better starting point for light learning, but free quotas often create interruption risk that is unacceptable for scheduled delivery.
The practical bottlenecks are long context, cache misses, subagent-heavy sessions, broad MCP connections, repeated repository scans and parallel instances. Use `/usage`, session budgets and workspace spend limits. Compact or restart when context becomes noisy. Split large work into verified stages. A cost-efficient session is not the one with the fewest tokens; it is the one that reaches a correct, reviewed outcome with the least rework.
Subscription Pricing Matrix
| Plan | Public Price in USD | Claude Code | Usage and Caps |
| Free | $0 | Not listed as included | Free Claude usage limits apply |
| Pro | $17/month annual or $20 monthly | Included | Five-hour session and weekly limits; shared across Claude surfaces |
| Max | From $100/month | Included | 5x or 20x more usage than Pro; higher output limits |
| Team Standard | $20/seat annual or $25 monthly | Included | Per-member limits; 1.25x more per session than Pro |
| Team Premium | $100/seat annual or $125 monthly | Included | Per-member limits; 6.25x more per session than Pro |
| Enterprise | $20/seat plus API-rate usage | Included | Usage-based plans have no per-seat allowance; admin spend controls |
API Model Pricing
| Model | Input per MTok | Output per MTok | Prompt Cache Write | Prompt Cache Read |
| Fable 5 | $10 | $50 | $12.50 | $1.00 |
| Opus 4.8 | $5 | $25 | $6.25 | $0.50 |
| Sonnet 5 | $2 introductory | $10 introductory | $2.50 | $0.20 |
| Haiku 4.5 | $1 | $5 | $1.25 | $0.10 |
Where Claude Helps and Where It Slows You Down
The evidence is deliberately mixed. Anthropic reported that Claude Sonnet 4.5 reached 82.0% on its SWE-bench Verified methodology and maintained focus for more than 30 hours on complex tasks. Anthropic’s institute later reported that more than 80% of code merged into its own codebase was authored by Claude as of May 2026, while acknowledging that lines of code exaggerate productivity because quantity is not quality. These figures show capability and internal adoption, not universal return on investment (Anthropic, 2025; Anthropic Institute, 2026).
The strongest counterweight is the METR randomised controlled trial. Sixteen experienced open-source developers completed 246 tasks in mature repositories. With early-2025 AI tools available, they took 19% longer, although they expected a 24% speed-up and afterwards still believed they had been 20% faster. The result does not prove Claude Code slows every developer. It shows that familiarity with a complex codebase, high quality standards and review overhead can reverse the apparent gain (Becker et al., 2025).
Industry commentary captures the same tension. Boris Cherny, creator and head of Claude Code, said in a 2026 interview that “coding is practically solved for me” (Business Insider, 2026). Will England, CEO and CIO of Walleye, said “100% of employees at Walleye Capital use Claude Code”. Kate Stepp, FactSet’s Chief AI Officer, said adoption was “accelerating how quickly we can ship”. Gary Koveats of Dun & Bradstreet stressed “deterministic, auditable outcomes”, while Adam Wheat of Morningstar said “trust starts with the data behind it” (Anthropic, 2026d).
A 2026 empirical study of more than 3,800 reported bugs across Claude Code, Codex and Gemini CLI found over 67% related to functionality, with 36.9% rooted in API, integration or configuration errors. That is why the best use cases are bounded implementation, test generation, codebase exploration, migrations with clear contracts, repetitive refactors and documented debugging. The weaker use cases are ambiguous product decisions, security-critical changes without independent review, mature codebases where context is expensive to reconstruct, and tasks whose correctness cannot be tested (Zhang et al., 2026).
A Reproducible End-to-End Example
The following example turns the brief’s CSV idea into a complete interaction sequence. The goal is not to obtain one magical response. It is to create a chain of artefacts that a developer can inspect: specification, implementation, tests, failure evidence and a final patch.
Step one is the initial request. It fixes Python 3.11, the function signature, standard-library-only constraint, invalid-input behaviour and three tests. Step two asks Claude to state assumptions before writing. Step three requests the function and pytest tests. Step four runs the tests outside the conversation. Step five returns any failure exactly. Step six requests the smallest patch and a complexity note. Step seven records stable conventions in the repository if this pattern will recur.
During our hands-on validation, we checked the sample implementation against Python 3.11 grammar and executed the three pytest cases in a local Python environment. The tests cover ordinary rows, a quoted comma and malformed quoting. That validation proves the example artefact behaves as stated; it does not prove that every Claude response to the same prompt will be identical.
For a React component, replace the contract with the React and TypeScript versions, API schema, loading state, error state, cancellation behaviour, accessibility requirements and component tests. For SQL, provide the dialect, schemas, join keys, date semantics, null policy and expected row examples. For Go CLI work, specify the Go version, filename collision rules, dry-run output, rollback behaviour and table-driven tests. The method remains constant because the acceptance boundary remains executable.
End-to-End Prompt
/plan
Inspect the repository and identify the smallest change required to add parse_csv(text: str) -> list[dict[str, str]] for Python 3.11.
Constraints:
– Standard library only.
– First row is the header.
– Quoted commas must work.
– Malformed CSV returns [].
– Add three pytest cases.
– Do not edit configuration or dependency files.
Return the proposed files, assumptions, risks, and test command. Do not edit yet.
Reference Implementation
from __future__ import annotations
import csv
import io
def parse_csv(text: str) -> list[dict[str, str]]:
“””Parse CSV text into dictionaries, returning an empty list when invalid.”””
if not text.strip():
return []
try:
stream = io.StringIO(text, newline=””)
reader = csv.DictReader(stream, strict=True)
if not reader.fieldnames or any(name is None or name == “” for name in reader.fieldnames):
return []
rows: list[dict[str, str]] = []
for row in reader:
if None in row or any(value is None for value in row.values()):
return []
rows.append({key: value for key, value in row.items()})
return rows
except (csv.Error, TypeError):
return []
Pytest File
from src.parser import parse_csv
def test_normal_row() -> None:
assert parse_csv(“name,age\nAda,36”) == [{“name”: “Ada”, “age”: “36”}]
def test_quoted_comma() -> None:
assert parse_csv(‘name,note\nAda,”London, UK”‘) == [
{“name”: “Ada”, “note”: “London, UK”}
]
def test_unclosed_quote_is_invalid() -> None:
assert parse_csv(‘name,note\nAda,”London’) == []
Our Content Testing Methodology
This guide was produced as a feature and troubleshooting workflow, so our content testing methodology focused on reproducibility, current product documentation and explicit limitations. We checked Claude Code’s documented surfaces, plan mode, project memory, hooks, checkpoints, MCP, GitHub automation, Agent SDK, cost reporting and usage guidance against Anthropic’s official documentation and Help Centre pages available on 12 July 2026. Pricing tables were limited to figures visible on Anthropic’s official pricing page. Where exact message counts or coding-hour allowances were not public, the article reports the limit structure without inventing a number.
For performance claims, we separated vendor benchmarks, vendor operational data and independent research. Anthropic’s Sonnet 4.5 announcement supplied the 82.0% SWE-bench Verified figure and methodology caveat. Anthropic’s institute supplied the internal 80% code-authorship and 8x lines-of-code observations, along with its own warning that lines of code overstate productivity. The METR randomised trial supplied the 19% slowdown result for experienced open-source developers. The 2026 bug study supplied failure categories across command-line coding agents.
We attempted to retrieve the Perplexity AI Magazine XML sitemap endpoints specified in the editorial brief, but the browsing layer did not return parseable XML. Internal links were therefore selected from live indexed pages on the same publication and restricted to coding assistants, coding agents, code review, developer search and adjacent workflows. Each internal URL appears once in a body section.
The worked CSV artefact was syntax-checked against Python 3.11 grammar and its pytest cases were executed locally. We did not publish the WordPress article, so the post-publication back-button test, WPCode snippet audit and hidden-content inspection remain a site-side publishing step rather than a completed document check.
This article was researched and drafted with AI assistance and reviewed by the Sami Ullah Khan editorial desk at Perplexity AI Magazine. All data, citations, pricing figures, and named quotes have been independently verified against primary sources before publication.
Conclusion
Claude is most useful when it is treated as an engineering participant with bounded authority. A precise prompt can turn a vague coding request into a contract. Plan mode can expose repository risk before edits. Tests, hooks, CI and human review can convert fluent output into evidence. The strongest workflow does not ask Claude to be correct by confidence; it asks Claude to produce artefacts that can be independently checked.
The open question is not whether Claude can write code. Official benchmarks, enterprise adoption and everyday developer experience show that it can. The unresolved question is when that capability reduces total delivery time after prompting, context collection, review, correction, maintenance and security work are counted. The METR slowdown result and Anthropic’s internal acceleration can both be true because they describe different environments, tasks and organisational systems.
In 2026, the durable skill is therefore not prompt cleverness. It is specification, decomposition, verification and judgement. Teams that already have clear interfaces, reliable tests, disciplined Git practices and visible ownership are positioned to gain the most. Teams with ambiguous requirements and weak review may simply generate defects faster. Claude changes the economics of implementation, but it does not remove the need to decide what should be built, why it is safe, or how anyone will know it works.
Frequently Asked Questions
Can Claude Write a Complete Program?
Yes. Claude can generate a complete program or project scaffold, especially when the prompt defines the runtime, files, interfaces, dependencies, inputs, outputs and tests. For production work, request the architecture and one vertical slice first, then expand after tests pass. Large one-shot requests make hidden assumptions harder to review.
Is Claude Code Different from Claude Chat?
Yes. Claude chat is useful for isolated code, explanations and design discussion. Claude Code is an agentic coding tool that can inspect repositories, edit files, run commands and integrate with development tools. It is available through terminal, IDE, desktop and web surfaces, subject to plan and deployment access.
What Should I Include in a Claude Coding Prompt?
Include the language and version, framework, exact deliverable, function or endpoint signature, input and output formats, edge cases, permitted libraries, files in scope, tests, security constraints and desired output format. Add sample inputs and outputs when behaviour could be interpreted more than one way.
Should I Ask Claude to Write Tests?
Yes. Ask for unit or integration tests that exercise normal, boundary, malformed and failure cases. Run them independently and add human-written acceptance tests. Generated tests can repeat the same mistaken assumption as generated code, so passing them is necessary but not sufficient.
How Do I Debug Claude-Generated Code?
Return the exact command, runtime version, stack trace, failing assertion and minimal relevant code. Ask Claude to classify the failure, rank likely causes and propose the smallest patch. Rerun the failing test and nearby regression suite before accepting broader changes.
What Is CLAUDE.md Used For?
CLAUDE.md stores persistent project instructions such as architecture, coding standards, build commands and repository conventions. It is advisory context, not a security control. Use hooks, permissions and CI for rules that must be enforced without exception.
How Much Does Claude Code Cost?
Claude Code is included with several paid Claude plans and can also use metered API or enterprise access. Subscription limits are shared across Claude surfaces and are affected by model, context and workload. Extra usage may be billed at standard API rates. Check Anthropic’s live pricing before purchase.
Can I Trust Claude-Generated Code in Production?
Not without review. Require tests, inspect diffs, verify dependencies, scan for secrets and vulnerabilities, and preserve least-privilege permissions. Security-critical or regulated code needs accountable human approval and independent validation. Claude can accelerate implementation, but production responsibility remains with the team.
References
Anthropic. (2026a). Plans and pricing.
Anthropic. (2026b). Claude Code overview.
Anthropic. (2026c). Best practices for Claude Code.
Anthropic. (2026d). Agents for financial services.
Anthropic Institute. (2026). When AI builds itself.
Anthropic. (2025). Introducing Claude Sonnet 4.5.
