Learn the Git safety net.
A branch isolates work. A commit records a checkpoint. A diff shows exactly what changed. A pull request gives another person and your automated checks a review surface.
Beginner-safe AI development · checked 31 July 2026
How Do You Build Software Safely with AI?
Codex, Claude Code, OpenCode and spec tools differ at the edges. The durable method is the same: make the problem clear, keep changes small, verify the result and let security checks stop unsafe code before production.
This guide starts with your first branch and ends with an evidence-based decision about subscriptions, emergency APIs, open-weight models, DGX hardware and private cloud.
Before the first prompt
Prepare a reversible place to learn.
You do not need to be a senior developer. You do need a repository, a small task and a way back when an experiment fails.
Know where commands run.
The terminal runs with your user permissions. Before approving a command, read its target path and effect. If you cannot explain it, ask the agent to explain it without running it.
Beginner notice
Never paste a command containing a password, API key or private token into chat, code or a commit.
Write down how the repo works.
Keep build, test and lint commands; important directories; conventions; forbidden paths; and “done” checks in a short repository instruction file. Prefer rules a person or CI job can verify.
See the file each tool reads →New to a codebase?Ask for a map before asking for a change.
Start read-only: “Explain the folder structure, how to run the tests, where authentication lives and which files you would inspect for this task. Do not edit anything.” Check the answer against the repository.
A reusable first prompt
Give four things—not a novel.
Good context reduces guesswork. Durable project facts belong in repository instructions; the specific goal belongs in this task.
Goal · context · constraints · done when
Goal: add an empty-state message to the saved-items page. Context: inspect the page, its existing tests and the shared message component. Constraints: do not add dependencies or change the API. Plan first and ask if the expected wording is missing. Done when: the empty and non-empty cases both pass, the diff is reviewed and no security check regresses.
Choose the smallest surface
Give AI only as much room as the task needs.
A line completion and an autonomous terminal agent are not the same risk. Start narrow, widen authority only when the work genuinely needs it, and keep the same definition of done.
Finish a local thought
Use an inline suggestion for a line, expression or repetitive pattern you already understand. Read it before accepting it.
Authority: suggestion onlyBuild understanding
Ask for an explanation, repository map or likely files. Require references and keep the pass read-only.
Authority: read and explainTransform a selection
Use a targeted edit when the boundary is visible: add validation, rename a symbol or write a focused test.
Authority: named files or selectionExecute a bounded task
Use plan/agent mode for multi-file work that can be split into tasks, tested and reviewed as a diff.
Authority: workspace + approved toolsRepeat a proven workflow
Use a CLI, SDK or CI agent only after the interactive version is reliable, permissioned and observable.
Authority: policy-defined and loggedPocket control is still system accessA phone changes the surface—not the authority.
Label a mobile session as chat, assistant or operator. Show whether the model and tools run on the phone, a home computer or a cloud service; preserve the same file limits, command review and approval gates you would require at the keyboard. See the private remote pattern →
Beginner shortcutConfused? Ask. Certain? Edit. Multi-file? Plan.
If you cannot predict which files or commands are needed, begin with a read-only question. Do not jump to an autonomous agent because the prompt is hard to write—the uncertainty is a reason to explore first.
Spec-driven development
Turn intent into a six-stage reviewable loop.
A specification does not need to be long. It needs to say what will change, what will not change and how someone can prove the result.
01ExploreRead code, examples and constraints. Make no edits.
02SpecifyProblem, users, scope, requirements and acceptance cases.
03PlanFiles, interfaces, dependencies, tests, risks and rollback.
04TasksSmall ordered changes, each with an acceptance check.
05ImplementOne task and its tests; stop before the next task.
06ReviewDiff, tests, security findings and the original acceptance cases.
The promise
Who needs what behavior? What is in and out? Which examples must work? Which questions are still unresolved?
The route
Which modules change? What data crosses a trust boundary? Which tests, migration and rollback are required?
The sequence
Can each task be reviewed, tested and committed independently? If not, split it again.
Example acceptance caseWrite behavior a beginner can check.
Given a signed-in user has no saved items, when they open Saved Items, then the page shows the agreed empty-state message and does not make a delete request. This is more testable than “make the page nice.”
Stop and return to the spec when
a requirement is ambiguous
the agent proposes a new dependency
a migration or permission appears unexpectedly
tests disagree with the intended behavior
the same fix fails twice
the diff is too large to explain
Three routes, one method
Use the tool’s native controls without changing the discipline.
The material difference is usually authentication, instruction files, permission controls and model routing—not the shape of good engineering work.
| Workflow moment | Codex | Claude Code | OpenCode + OpenSpec |
|---|---|---|---|
| Start safely | Use default sandbox and approvals; ask or enter Plan mode before a broad change. | Use plan mode, permission rules and sandboxing; keep consequential commands behind approval. | Use the restricted Plan agent; set unknown actions to ask and deny pushes, destructive commands and out-of-repo access. |
| Durable repo rules | AGENTS.md, with nearer nested files overriding broader guidance. | CLAUDE.md. Import @AGENTS.md to share cross-tool rules, then add only Claude-specific notes. | AGENTS.md by default; OpenCode can fall back to CLAUDE.md. Keep OpenSpec artifacts under openspec/. |
| Think before code | Ask for a plan or use Plan mode; agree on files, checks and stop conditions before edits. | Use plan mode or a read-only research pass; approve the plan before implementation. | Use OpenCode Plan or /opsx:explore, then /opsx:propose to create proposal, requirements, design and tasks. |
| Implement | Name one task, require relevant tests, then inspect the diff or run a review. | Implement one bounded task, run tests and inspect the diff before accepting more authority. | Run /opsx:apply for approved tasks. Verify the artifacts and implementation before /opsx:archive. |
| Switch models | Choose models available to the plan or API key. API authentication is separate from plan authentication. | Choose the available Claude model; a plan allowance and Console/API billing are distinct capacity paths. | OpenCode connects to multiple providers, OpenRouter and local endpoints; OpenSpec supplies the workflow, not the model. |
| What stays human | Requirement approval, secret/data policy, production access, security exceptions, migration approval, final review and release. | ||
Context engineering
Context is a budget—not a repository landfill.
The agent can act only on what its harness sends to the model: instructions, conversation, files, tool descriptions and tool results. Missing facts invite guesses; irrelevant facts bury the useful signal.
Build/test commands, architecture invariants, forbidden paths and verifiable conventions.
The requested outcome, relevant files, non-goals, acceptance checks and stop conditions.
Nearby instructions, a matching skill, selected documentation and the smallest useful files.
Search output, tests, scans and diffs—trimmed to what the next decision needs.
Save decisions in artifacts, then compact or open a fresh session for the next coherent task.
Context-engineering hintThe harness matters. So does the evidence it can reach.
For open-source dependencies, manuals no longer have to be the agent’s ceiling: the exact source is the strongest evidence of how an implementation behaves. opensrc lets a coding agent fetch and search version-matched package or repository source with ordinary tools. Give it the implementation, tests and examples; keep official documentation for the supported contract, migrations and security guidance. Compare opensrc in the tool catalogue.
Model-specific context limit
First loop
System
+ tools Prompt File Response Available context
+ tools Prompt File Response Available context
Second loop
Repeated prefix + prior responsepotentially cached input
Prompt
File
Response
Less room remains
System + tools
Prompt
Selected file
Model response
Repeated / cached
Why agent sessions growEvery loop adds material the next decision must compete with.
The harness assembles instructions, tool definitions, conversation, selected files and results for each model call. Repeated prefixes may be cached for efficiency, but caching does not make stale or irrelevant context useful.
| Control | Use it when | Avoid | Portable form |
|---|---|---|---|
| Repository instructions | A rule matters in almost every task in this repository. | Vague advice, temporary task detail and a giant generated handbook. | AGENTS.md; tool-specific files may import or complement it. |
| Scoped instructions | A rule applies only to one directory, language or file type. | Loading frontend, database and test conventions into every turn. | Nested AGENTS.md files or a tool’s path-scoped rules. |
| Reusable prompt | A person starts the same procedure with a different input. | Pretending a one-shot prompt is a permanent project rule. | A versioned Markdown template; native prompt commands where supported. |
| Skill | A repeatable multi-step capability should load only when relevant. | One enormous skill that handles unrelated jobs or hides unsafe commands. | SKILL.md plus reviewed scripts and references. |
| Specialist agent | A recurring role needs a bounded mission and restricted tools. | A “do everything” persona with write, deploy and admin access. | Named agent instructions; read-only archaeologist or test-only reviewer. |
| MCP or custom tool | The workflow needs live data or a real action from another system. | Connecting every server, exposing raw admin APIs or trusting model arguments. | A small typed tool contract with least privilege and approval. |
| Subagent | A broad, independent investigation would flood the main task context. | Delegating an ambiguous whole project or losing integration ownership. | A bounded read-only brief returning evidence and unresolved questions. |
First valuable skill
Package judgment you do not want the agent to reinvent.
A skill is a small, version-controlled folder that teaches an agent one repeatable job. Only SKILL.md is required; add references, scripts or assets when they improve repeated work. A strong first skill starts with a real standard you can judge—not a vague “be helpful” persona.
SKILL.mdTrigger + core workflow
references/Knowledge loaded on demand
scripts/Tested repeatable checks
assets/Optional templates + resources
Read the Agent Skills specification↗Download color accessibility skillDownload code structure skillDownload evidence-driven testing skillBrowse NVIDIA agent skills↗
Just landed: Agent Plugins 1.0.0 wraps Agent Skills and MCP servers in one portable, vendor-neutral package that compatible clients can discover. The client still controls installation, permissions and execution.
Try it: give the downloaded folder to your coding agent and ask: Install this skill where you can discover it for this project, and update AGENTS.md or the repository’s equivalent instructions only if a durable note is needed. Start a fresh task, describe the job normally and let the agent select a matching skill.
- 01Pick one repeated judgment.
Collect real prompts, inputs, expected outputs and the mistakes that matter. Keep one skill focused on one coherent job.
- 02Write the trigger and workflow.
Give
SKILL.mda precise name and description, then write the shortest sequence that reliably produces a reviewable result. - 03Bundle only reusable material.
Move detailed knowledge into references and deterministic repeated work into tested scripts. Leave ordinary reasoning to the agent.
- 04Run it, compare it, improve it.
Test prompts that should and should not trigger it. Replay real tasks, inspect failures and keep a new rule only when it improves the result.
Illustrative · below half fullThe middle can fade before capacity is close.
Beginning
tokens Middle tokens
weaker recall End
tokens
tokens Middle tokens
weaker recall End
tokens
Illustrative · beyond half fullOlder material competes with every new turn.
Newest tokens
Oldest tokens
Illustrative halfway mark
01Miss
→
Record the concrete wrong result, not “the model is bad.”
02Diagnose
→
Was context missing, contradictory, overloaded—or was the task beyond the model?
03Fix
→
Add one scoped rule, example, test, tool constraint or smaller task boundary.
04Verify
Undo the result, replay the same case and keep the change only if it helps.
How tool calling works
The model proposes. Your software executes.
A model can emit a structured request such as create_issue({title, body}). The agent harness or your application must validate the arguments, enforce identity and policy, ask for approval when needed, run the function, and return the result. A fluent request is not authorization.
User request→Model proposes call→Host validates + approves→Tool runs→Result returns
Context-rot noticeA fresh session is a tool, not a failure.
Long sessions accumulate stale plans, failed approaches and noisy tool output. Preserve approved decisions in spec.md, plan.md, issues or commits; then summarize or restart before the next distinct task.
Existing and legacy systems
Rediscover the behavior before rewriting the code.
Old code contains business rules, edge cases and operational bargains that may exist nowhere else. Treat modernization as agent-assisted archaeology followed by normal spec-driven delivery.
What does it actually do?
Produce business rules with code evidence, a data model, integration inventory and an open-questions list. Read one module at a time.
Output: reviewable current-state specWhat should stay, retire or change?
Compare home-grown utilities, integrations, stores, runtimes and operational assumptions with current supported options. “Keep” is valid.
Output: substitution map + trade-offsWhat should the target shape be?
Decide boundaries, data migration, contracts, authentication, secrets, observability, rollback and a cutover strategy before implementation.
Output: approved target planHow do we preserve behavior?
Derive tests from rediscovered rules, keep the old interface where practical and switch traffic gradually. Stop when behavior is ambiguous.
Output: tested, committable modulesHow does the same artifact reach users?
Build, test and scan in CI; promote through dev and staging; observe both paths and keep a rehearsed rollback during cutover.
Output: repeatable release + recoveryA safe rediscovery prompt
Ask for evidence, not confidence.
Run this against one module—not an entire twenty-year-old system. A domain expert still has to validate what is active in production.
Read-only archaeology
Do not edit code. For this module, produce: (1) business rules in plain language with concrete file references, (2) entities, relationships and invariants, including database-enforced rules, (3) every external integration and operational dependency, and (4) unresolved behavior questions. Separate evidence from inference. Do not propose a new architecture yet, and never guess a missing business rule.Why “strangler”?Replace a large system one safe path at a time.
A strangler-style migration routes selected behavior to the new implementation while the rest stays on the old one. You compare results, increase traffic gradually and retain a rollback instead of betting the business on one big switch.
Security before production
Make the unsafe path fail early.
An AI review is useful additional evidence. It is not a replacement for deterministic tests, scanners, least privilege or a human who can own the risk.
Non-negotiable default
Security checks run on every pull request, before merge. A production deployment consumes the already-scanned commit; it does not become the first place you discover a secret, vulnerable package or obvious code flaw.
Security words in plain languageFour checks catch different mistakes.
SAST inspects source code. SCA checks third-party packages and licences. Secret scanning catches credentials. DAST probes a running application. None proves the application is secure; together they find problems earlier.
A sensible setup order for your first repository
Names differ across GitHub, GitLab, Azure DevOps and other platforms, but the control sequence stays useful. Some private-repository features require a paid security plan; use a supported scanner you can require in CI rather than leaving the gate empty.
Prevent and protect
Enable secret scanning or push protection, dependency alerts, branch/ruleset protection and default code scanning where available. Do not let contributors push directly to the production branch.
Test the changed commit
Install from the lockfile; run lint, types and tests; then SAST, dependency review and relevant infrastructure/container scans. Give every required check a clear name.
Promote the same artifact
Give deploy credentials only to the release job, require an environment approval, run preview smoke/DAST checks and keep a tested rollback. A later rebuild breaks the evidence chain.
| Gate | Minimum check | Block the change when | Safe response |
|---|---|---|---|
| Before commit | Secret scan, formatter and focused unit tests | A real credential, private key or generated secret appears. | Remove it, rotate it if exposure is possible, and replace it with a documented secret reference. |
| Pull request | Full tests, lint/type checks, SAST, dependency review and licence policy | A new high/critical flaw, vulnerable runtime dependency, forbidden licence or failing test is introduced. | Fix or remove the change. A time-limited exception needs an owner, reason, compensating control and expiry. |
| Infrastructure | IaC and container scan, least-privilege review and ephemeral credentials | Public exposure, privileged containers, broad IAM or unpinned images appear unexpectedly. | Reduce access, pin the artifact, prove a denied path and document rollback. |
| Preview | DAST, end-to-end smoke tests and authorization abuse cases | One user can read or change another user’s data, input reaches an unsafe sink, or a critical flow breaks. | Return to the spec and threat model; add a regression test before the fix is merged. |
| Deploy | Protected environment, approved artifact, health check and rollback | The commit differs from the scanned artifact, secrets are unavailable or rollback is untested. | Stop promotion. Repair the release path without rebuilding unreviewed code in production. |
If a secret reaches Git
Deleting the visible line is not enough because history and logs may still contain it. Revoke or rotate the credential first, investigate its use, then clean history only with repository-owner coordination.
Developer subscription playbook
Pay for a fair test. Upgrade the lane that wins your work.
Free plans are product demos, not serious reliability tests. Start with affordable paid access, then put the larger allowance behind the workflow that proves most useful.
01 · Minimum useful starting point
Pay for a real trial.
The free tier is fine for simple prompts, but its limits can make capable models feel unreliable. For frequent development, begin with the lowest paid plan on both platforms.
Rule: use the checkout price in your region, including tax, and only an organization-approved plan. Do not take annual plans as they don't give flexibility to switch between tiers.
OpenAIChatGPT Plus~20€per month
AnthropicClaude Pro~20€per month
02 · The upgrade trigger
Promote the winner.
When a limit repeatedly interrupts useful work, decide which tool fits your workflow better. Upgrade that subscription to its 5× tier and keep the other on the cheaper plan.
Do not upgrade on one bad day. Look for a repeated limit pattern across real tasks. While Annual plans might be enticing there might be more value in switching 5x plans between providers as new models are released.
5×roughly €90–€100 per month before tax
03 · Before the 20× plan
Fix the workflow first.
Improve prompts, context files, tool choice, reusable skills, model routing and the agent harness before buying another block of capacity.
Practical rule of thumb: if one developer cannot make 5× last, optimize before assuming the only answer is 20×.
- Interactive work: target 5× for a full workweek.
- 20× signal: measured autonomous or parallel-agent demand.
- Watch the meter: model, effort and fast mode change usage.
High-output developer split
Two subscriptions. One premium lane.
This field-tested setup is used by experienced, high-output developers: keep both tools available, but put the higher tier behind the lane doing the heavier work.
This is a working pattern, not one person’s current split—and not a benchmark verdict. Run the same representative tasks through both tools, count accepted results and review effort, then let your own work choose the premium plan.
Scope of this recommendationChoose the whole system, not only the model.
This guide concentrates on OpenAI and Anthropic because they are the frontier options used in the subscription pattern above—not because they are the only credible choices. Google, other major labs and Chinese providers may offer a better price, model or regional route for a particular project. No useful guide can list every combination, so explore the wider tool market and test contenders on your own accepted-task set.
The harness is part of the result. Context selection, tools, permissions, retries and verification can materially improve—or degrade—the same model’s performance. Cursor can produce a dramatic lift when its editor context, change review and agent loop fit the way a project is built; another workflow may perform better in Codex, Claude Code or a different harness. Test the exact developer workflow, not Cursor or any other harness in the abstract.
Use bring-your-own-key deliberately in case of Cursor. Cursor’s Pro tier or higher can run supported OpenAI and Anthropic models through Cursor’s own agent harness using your API key. The provider then meters the model tokens separately—a ChatGPT or Claude subscription does not fund those API calls. Free access is not enough for this route, and specialized features such as Tab completion still use Cursor’s services and models. Evaluate Cursor’s own models separately and keep them only if they earn a place on your work; team plans should also check Cursor’s current platform-token charges.
Resilience after subscriptions
Keep fallback routes. Provision what must be predictable.
An API account provides access, not assured capacity. Put approved provider routes behind one governed gateway, and treat owned compute as a measured capacity decision.
Treat capacity as a portfolio.
Do not assume any one on-demand provider will always have headroom. Keep approved routes behind one policy-enforcing LLM proxy, and add or retire providers only when measured capacity, quality, cost or incident performance justify it.
Build the five-minute switch →Own compute only after comparison.
Record real tasks and accepted outcomes, then test a suitable open-weight model through a hosted route. Consider owned compute only after quality and usage are known.
Run the replacement lab →
Production is down, quota is full or capacity is constrained
Make the emergency switch boring.
The worst time to discover authentication, model behavior or spending controls is during an outage. Test this route before you need it.
- 01
Own the account. Use a team or service account, MFA and a named incident approver—not one developer’s personal billing.
- 02
Constrain the key. Separate it from production application keys; set the smallest model/provider allowlist, budget and expiry that works.
- 03
Protect the data. Apply the same source-code, customer-data, retention and region rules as the normal route.
- 04
Run a smoke and failover pack. Re-run five representative tasks against every emergency route because a fallback model or provider can produce a materially different patch, tool call or latency profile.
- 05
Close the incident. Export usage, record the model and provider, disable the route, rotate if needed and write the lesson into the runbook.
Plan + API are separate lanes.
Codex plans provide included usage and optional credits. API-key use is metered by tokens and fits CLI, SDK, IDE or CI; it does not carry every plan/cloud integration.
Plan + usage credits can bridge a cap.
Claude’s paid plans can enable additional metered usage at standard API rates. A Console/API route remains a distinct billing and governance path.
The harness follows the provider.
OpenCode connects to many providers and local models. With OpenRouter, use a dedicated prepaid key, budget guardrail and an explicit model/provider policy. Provider credentials stay local, so protect the workstation profile and never commit keys.
The spec does not buy inference.
OpenSpec stores planning artifacts and commands for supported coding tools. Authentication, quotas, model quality and data policy still belong to the agent/provider route.
Incident boundary
Do not send production secrets, customer records or unredacted incident logs to a personal account just because it has remaining quota. An emergency shortens time; it does not suspend data policy.
Hosted success → open alternative
Judge a replacement by its results, not its reputation.
Once an online model works, preserve its successful tasks as a baseline. An open-weight candidate earns a place by matching those outcomes at acceptable speed, cost and risk.
Licence noticeOpen-weight is not automatically open source.
A downloadable checkpoint may still restrict use, modification or redistribution. Read the exact model card and licence, record the version, and check whether your planned commercial or internal use is permitted. The Open Source AI Definition is a useful benchmark for the stronger term.
| Measure | Hosted baseline | OpenRouter candidate | Local candidate | Reject when |
|---|---|---|---|---|
| Accepted-task rate | Human-approved result on the same fixed cases | Same rubric and retry limit | Same checkpoint family, prompt and tool contract | The quality gap creates more review or rework than the saving covers. |
| Reviewer effort | Minutes and material edits per accepted task | Measure changed lines and review minutes | Measure again; quantization may change behavior | Humans become the hidden inference engine. |
| Reliability | Tool failures, retries and timeouts | Pin provider and disable fallback for the experiment | Record crashes, OOMs, queue time and recovery | The route cannot finish the real workflow predictably. |
| Performance | Wall time, time to first token and output speed | Record provider and endpoint metadata | Test concurrency, context and sustained load | Interactive latency or team throughput misses its service target. |
| Economics | Plan cost plus measured overflow/API cost | Input, cache and output cost per accepted task | Capex, power, cooling, operations and variable cost | Savings disappear after failed tasks and staff time. |
A fair OpenRouter trial
Pin what can silently change.
Select the exact model. For a controlled comparison, set a provider order and disable automatic fallbacks; otherwise a successful response may come from a different endpoint. Enforce the data policy your inputs require, including zero-data-retention routing where appropriate.
Cloud-to-local calculator
Buy hardware only when measured work pays for it.
Use accepted tasks, not raw tokens. A cheap model that fails twice and needs a rewrite is not cheap.
Use at least one month of measured hosted/OpenRouter results. Put staff time, support, storage, networking and realistic electricity into the local side.
Measured exampleLocal is cheaper at this volume
Quality and capacity still have to pass.
The model
local monthly = hardware ÷ useful life + energy + operations + accepted tasks × local variable costbreak-even tasks = local fixed monthly ÷ (hosted cost/task − local variable cost/task)This result is financial only. Keep hosted access until the exact local model, quantization and runtime pass quality, latency, concurrency, context and recovery tests.
Existing computer or hosted model
Best for the first baseline and low or irregular volume. Use idle hardware only if its model passes; “already owned” does not make staff time free.
DGX Spark class
DGX Spark has 128 GB unified memory and NVIDIA documents model support up to 200B parameters. Fit is not speed: benchmark the exact checkpoint, quantization, runtime and context.
Use the Spark runbook →DGX Station class
The current Grace Blackwell DGX Station architecture offers up to 748 GB coherent memory, including up to 252 GB HBM3e. It needs a utilization case, support owner and acceptance test—not just a model that loads.
Use the Station buyer’s guide →Private cloud
Consider a shared cluster when multiple teams have steady, governed demand and can operate identity, scheduling, observability, backups, patching and incident response. Rent a comparable service before building one.
Compare infrastructure tiers →Not only a cost decisionPrivacy or latency may justify local before financial break-even.
Say that explicitly. The benefit is then risk reduction, data control or service behavior—not cheaper tokens. Local also creates new obligations: endpoint security, physical access, patching, backups, model licences and an operator who answers when it fails.
Your first month
Build capability in four small weeks.
Do not install every plugin, agent and server on day one. Add a capability only when a real workflow proves it is useful.
Learn and map
- Finish the main Learn Git Branching levels.
- Create a practice repository and a branch.
- Ask an agent to explain one small codebase without editing.
- Review every proposed command.
Specify and build
- Choose one tiny user-visible change.
- Write scope, acceptance examples and stop rules.
- Approve a plan, implement one task and add tests.
- Record which instruction would prevent a repeated mistake.
Secure the path
- Enable secret prevention.
- Run tests, SAST and dependency review on pull requests.
- Test one denied authorization case.
- Require checks before merge and protect deploy credentials.
Measure and prepare
- Track accepted tasks, edits, time and plan/API use.
- Configure a capped emergency API route and run its smoke pack.
- Replay a small test set on one open-weight candidate.
- Keep renting unless quality, volume and economics justify local.
What progress looks like
You can explain the requirement, the change, the tests, the scan results, the cost and the rollback without asking the model to remember for you.
The durable skill
Use AI to widen your reach—not to outsource your judgment.