Levels of LLM Adoption

How to code a statement/function

How a technology works

How technologies compare and contrast

Find better ways to implement small sections of code

Compare libraries and approaches

Summarize docs and concepts

Parse and analyze CSV/JSON/etc for quick answers

Interpret logs/traces/stack traces

Propose 2–3 hypotheses

Understand security/privacy pitfalls, licensing concerns, “what could go wrong”

Autocomplete single-lines / small-blocks

Autocomplete multi-file edits that follow existing patterns and conventions

Generate scaffolds, fixtures, mocks, and edge cases

Perform small code and document refactors

Repo-aware Q&A (Cursor/Cody-style): “Where is X?” “What calls this?” “How does Y work here?”

Fill coverage gaps; add regression tests for bugs

Triage, isolate repro, propose fixes + verification steps

Draft implementation + iterate based on review feedback

Summarize diffs, spot risks, suggest improvements, call out missing tests

Generate outlines, user stories, non-goals, open questions

Turn fuzzy asks into constraints, acceptance criteria, and phased rollout plans

Generate Classic Requirements documents

Generate feature-based Product Requirements Documents (PRDs)

Generate significant number of unit tests

Generate effective end-to-end (e2e) tests (such as Playwright tests)

LLM drafts implementation + tests + docs; human validates/accepts

State goal, non-goals, constraints, and definition of done

Provide “what good looks like” examples (inputs/outputs, acceptance checks)

Name what must not change (APIs, behavior, performance budgets, accessibility expectations)

Break work into small, verifiable steps

Ask for a plan first (milestones, risks, unknowns, test plan)

Choose a safe order: scaffolding → tests → implementation → cleanup

Give repo-specific context: conventions, file locations, patterns to follow

Teach it your working agreements (style, naming, commit hygiene, review expectations)

Require tests for behavior changes and a clear verification checklist

Ask for edge cases, failure modes, and rollback considerations

Building and tweaking AGENTS.md files

LLM runs linters/automated tests, interpret failures, propose focused patches

LLM stops on uncertainty; ask for clarification instead of guessing

Explicit scope (“only touch X files”), deterministic formatting, non-interactive commands

Require evidence for risky changes (tests, benchmarks, logs, diffs)

Define agents such as Planner, Implementer, Reviewer, Verifier

Agents work on independent slices (tests, refactors, docs) in parallel

Strict ownership of files/modules to avoid conflicts

Shared definition of done, shared guardrails, shared tool permissions

Central change log: what changed, why, evidence, and remaining risks

Human approval gates at milestones (design, pre-merge, release)