Coding skills that matter in the age of AI
The coding skills that matter most in the age of AI are deciding what is worth building, specifying and decomposing the work, directing AI, verifying its output, reasoning across levels of abstraction, building incrementally, and securing the result. Brilliant’s durable coding skills framework organizes these capabilities into seven Big Ideas, 30 learning objectives, and 84 substandards for novice college students and young professionals. The framework at a glance Big Idea Durable role TAS · Taste Decide what is worth building and define a successful outcome. SPC · Spec & Design Frame the problem, structure the solution, and specify how success will be verified. BLD · Build Direct AI implementation and keep the result aligned with the specification. VER · Verify Test, review, debug, observe, and evaluate the result. ABS · Reasoning across levels of abstraction Move between intent, architecture, and implementation details. INC · Building incrementally Build in small, working, verifiable, and reversible steps. SEC · Security & adversarial thinking Identify misuse, secure the implementation, and constrain AI-specific risks. How to read this framework Big Idea — a pillar of durable skill (e.g. SPC, VER). Standard — a measurable learning objective (e.g. VER-1). Substandard — an essential-knowledge statement with an example (e.g. VER-1.a). The verified spine (Stack Overflow Developer Survey 2025): 84% of developers use or plan to use AI tools, yet trust is falling (33% trust vs 46% distrust). The #1 frustration (66%) is time spent debugging due to "AI solutions that are almost right, but not quite." The durable skills are the ones that catch and fix "almost right." Structure: a precursor (Taste), a core build loop (Spec & Design → Build → Verify), and the cross-cutting practices that span it. 7 Big Ideas · 30 standards · 84 substandards. Precursor · before the loop Judgment about what to build. It gates everything downstream and feeds the loop's definition of done. TAS · Taste — what's worth building Enduring understanding. As building becomes inexpensive, judgment about what to build and what constitutes a good result becomes the primary differentiator. It is difficult to teach and precedes the loop, informing the success criteria defined in SPC-5. TAS-1 · Evaluate whether a proposed artifact is worth building Code Essential knowledge Example TAS-1.a The value of building an artifact is weighed against an explicit measure such as user benefit, time saved, or cost.<br>A goal is justified against a concrete yardstick before development begins, rather than assumed to be worthwhile. A proposed notification system is weighed against the number of users it helps and whether existing email already meets the need. TAS-1.b Declining to build, or reducing scope, is a legitimate design decision.<br>Choosing not to build conserves effort for higher-value goals and is made deliberately. An established authentication provider is adopted instead of a custom one being built. TAS-2 · Define the criteria that characterize a successful outcome Code Essential knowledge Example TAS-2.a The qualities of a good outcome are defined in terms of the needs of the intended user.<br>Success is described by the properties that matter to the person using the artifact. For a note-taking application, success includes instant startup, no data loss, and searchable notes. TAS-2.b Success criteria are expressed as an explicit, checkable definition of done.<br>Qualitative goals are translated into conditions that can later be verified. Done is defined as notes persisting across restarts and search returning matches within 100 milliseconds. Sources: Osmani, The 70% Problem (2024) · Anthropic Economic Index (software) The core build loop · the concrete workflow Human skill concentrates in the two bookends — the middle is increasingly AI-run. SPC · Spec & Design Enduring understanding. When an AI performs the implementation, human leverage lies in framing the problem and specifying success, including how it will be verified, before anything is built. The most durable human skill resides here. SPC-1 · Determine which information is relevant to a task Code Essential knowledge Example SPC-1.a Relevant context is the minimal set of information that affects the outcome of a task.<br>Only the facts, files, or history that bear on the task are selected. Diagnosing a checkout failure requires the error, the payment module, and recent changes — not the entire codebase. SPC-1.b Excluding irrelevant information reduces noise and improves the quality of a result.<br>Context that does not change the answer is deliberately omitted rather than added for safety. Pasting an entire repository into a prompt obscures the few lines that determine the answer. SPC-1.c Accumulated context can become stale, at which point resetting is more useful than extending it.<br>When prior context begins to mislead, restarting from a clean state is preferable. After several failed attempts along one path, the context is cleared and the problem restated. SPC-2 · Specify intent, constraints, and success criteria precisely Code Essential knowledge Example SPC-2.a A precise specification states the desired behavior and its constraints without ambiguity.<br>Exact behavior and limits are stated so that no interpretation is required. 'Limit login to five attempts per minute per IP address, then lock for fifteen minutes' rather than 'make login safer.' SPC-2.b A definition of done states the observable condition under which a task is complete.<br>Completion is defined by an outcome that can be observed. A task is done when a sixth login attempt returns an error and the event is recorded. SPC-2.c Design rationale records why a decision was made, preserving intent for future readers.<br>The reasoning behind a choice is documented so that it is not inadvertently reversed. A note records that login is locked by IP address rather than by account to prevent deliberate lockout abuse. SPC-2.d Hidden requirements and edge cases are surfaced by questioning the stated problem.<br>Unstated needs are revealed by interrogating the requirements and the stakeholders. Questioning reveals how the system should behave for several users behind one shared IP address. SPC-3 · Decompose a problem into modular components Code Essential knowledge Example SPC-3.a A problem can be divided into subproblems, each with a single, well-defined responsibility.<br>Work is separated into parts that each address one concern. A quiz application separates into a question bank, scoring, interface, and storage. SPC-3.b A module's contract specifies its inputs, outputs, and responsibilities.<br>Each component's interface defines what it accepts, what it returns, and what it is responsible for. A scoring component accepts answers and returns a score, and does not modify the interface. SPC-3.c An interface hides details that are likely to change, limiting the impact of change.<br>Volatile implementation details are placed behind a stable boundary. Placing storage behind an interface confines a change of database to a single component. SPC-3.d The data model — the entities, their attributes, and how they relate — is a foundational structural decision that is costly to change later.<br>How the domain's data is represented shapes the whole system and resists change, so it is designed deliberately and early — an area where AI is weak without human direction. How users, orders, and products relate is decided before code is written, because reworking that structure later touches everything built on it. SPC-4 · Analyze the dependencies and ordering among components Code Essential knowledge Example SPC-4.a Dependencies determine the order in which components must be built.<br>A component that others rely on must exist before them. Authentication must exist before user-specific data can be built. SPC-4.b The blast radius of a change is the set of components it affects.<br>A change propagates to everything that depends on what it modifies. Renaming a user field affects every feature that reads that field. SPC-4.c A single point of failure is a component whose failure disables the entire system.<br>Some components, if they fail, bring down everything that depends on them. If every request depends on one cache, that cache is a single point of failure. SPC-5 · Specify success conditions and design their verification Code Essential knowledge Example SPC-5.a Success is defined in observable, testable terms rather than as a vague quality.<br>A condition is stated so that it can be directly checked. 'sort() returns elements in ascending order' is observable; 'sorting works' is not. SPC-5.b The checks that establish success are designed as part of the specification, before implementation.<br>Verification is planned with the specification and executed later, in VER. The specification includes tests for an empty list, duplicates, and an already-sorted list. SPC-5.c An end-to-end verification confirms that a complete system, not only its parts, behaves as specified.<br>Overall correctness is confirmed by exercising the whole system. A final check confirms that a given input file produces the expected output file. Sources: Anthropic, Effective Context Engineering · Anthropic, Claude Code Best Practices · Parnas, On Decomposing Systems (1972) · Wing, Computational Thinking (2006) · Stack Overflow Developer Survey 2025 BLD · Build Enduring understanding. Implementation is the phase most absorbed by AI; the durable human skill is directing it and keeping it aligned to the specification, first with one agent and then with many. How building proceeds — incrementally — is governed by the cross-cutting practices below. Directing a single agent · the default BLD-1 · Direct an AI agent to implement a specification Code Essential knowledge Example BLD-1.a An effective delegation states the objective, the necessary context, and the boundaries of the task.<br>An agent is given what to do, what it needs, and what it must not change. An agent receives the specification, the two relevant files, and an instruction to leave the public interface unchanged. BLD-1.b An agent's work is monitored so that deviation from the task can be corrected.<br>An agent that drifts from its objective is redirected. An agent that begins altering unrelated code is stopped and refocused on the assigned change. BLD-2 · Maintain alignment between an implementation and its specification Code Essential knowledge Example BLD-2.a An implementation is checked against the specification to confirm it does what was required.<br>Produced code is compared to the specification it was meant to satisfy. Code intended to handle empty input is checked to confirm that it actually does. BLD-2.b Integrating a component reveals unintended changes that must be reconciled with the rest of the system.<br>Combining new work with existing code exposes side effects; the human catches them and decides whether each is intended. An agent's change quietly alters shared behavior other code relies on; the human notices the ripple and decides whether that change should stand. Orchestrating multiple agents BLD-3 · Distribute work across multiple AI agents Code Essential knowledge Example BLD-3.a Work can be partitioned into independent tasks that multiple agents perform in parallel.<br>A job is divided so that agents can proceed without interfering with one another. One agent implements an interface, a second writes its tests, and a third writes its documentation. BLD-3.b Whether agent tasks run in parallel or must be sequenced is determined by the dependencies between them.<br>Independent subtasks are dispatched in parallel; a task that consumes another's output is ordered after it — dependency thinking (SPC-4) applied to agents. Two unrelated endpoints are built in parallel, but a task that generates documentation from an endpoint runs only after that endpoint exists. BLD-3.c Each agent requires the specific context relevant to its assigned task.<br>An agent is given only the information its task needs — relevance judgment applied at scale. An agent writing tests receives the interface specification and signatures, not the entire codebase. BLD-4 · Supervise and integrate the work of multiple agents Code Essential knowledge Example BLD-4.a The output of multiple agents is reviewed and steered toward the intended result.<br>Each agent's work is monitored and redirected as needed. An agent producing shallow tests is directed to cover error conditions. BLD-4.b Reconciling conflicting agent output is a matter of defining the conditions the combined result must satisfy, not of performing the merge by hand.<br>Tools resolve mechanical merges; the durable human role is stating what the combined result must be true of and directing agents to meet it. When two agents change overlapping behavior, the human specifies the invariants the combined result must preserve and has an agent reconcile to them. BLD-4.c Some tasks require human judgment and are not delegated to agents.<br>Ambiguous or high-stakes decisions are made by a person rather than delegated. A trade-off with no single correct answer — such as favoring lower latency over lower cost — is decided by a person. BLD-5 · Design multi-agent systems in which agents coordinate other agents Code Essential knowledge Example BLD-5.a A multi-agent system defines a division of labor and the hand-offs between agents.<br>Roles and the flow of work among agents are specified in advance. A lead agent decomposes a larger task and dispatches its parts to worker agents. BLD-5.b Quality gates specify where human approval is required and where agents may act autonomously.<br>Points of mandatory human review are distinguished from unsupervised operation. No change is merged to the main branch without human review of the differences. BLD-6 · Determine the division of labor between human and AI Code Essential knowledge Example BLD-6.a A small, high-leverage human contribution can enable an AI to complete the majority of a task.<br>A critical seed — a specification, a decision, or a key case — allows the remainder to be automated. A person writes the specification and the two hardest test cases, and an agent implements code that satisfies them. BLD-6.b Effective delegation distinguishes the parts of a task requiring human judgment from those that do not.<br>Work that needs human judgment is separated from work an agent can carry to completion. A person specifies a data model, and an agent generates the surrounding data-access code. Sources: Anthropic, Building Effective Agents · Anthropic, Multi-Agent Research System · METR, Task-Completion Time Horizons VER · Verify Enduring understanding. Because generation is inexpensive and pervasive, detecting and correcting output that is almost right is where value concentrates. Verification executes the checks designed in SPC-5, after which the loop repeats. Its advanced form is the construction of evaluations. Verifying & debugging · the default VER-1 · Verify that a program satisfies its specification Code Essential knowledge Example VER-1.a Automated tests encode expected behavior so that it can be checked repeatably.<br>Behavior is captured as tests that run on every change rather than checked once by hand. An assertion that sort([3,1,2]) equals [1,2,3] runs automatically on subsequent changes. VER-1.b Boundary and edge cases are inputs at the extremes of a program's domain, where defects most often occur.<br>The unusual and extreme inputs are tested, not only typical ones. Tests cover the empty list, a single element, duplicates, and negative values. VER-1.c An invariant is a condition that must hold for every valid input, independent of any single test case.<br>General properties that hold universally are asserted, beyond specific examples. A sort preserves length and produces a permutation of its input for every input. VER-1.d Adversarial testing seeks an input that causes failure rather than confirming success.<br>Verification actively attempts to break the program. A very large list, a NaN, and a null value are tried against the program. VER-1.e A single point of failure is a component whose failure causes the whole system to fail.<br>The components most able to collapse the system under stress are identified. Whether a database outage degrades gracefully or fails the entire application is examined. VER-1.f Verification is established by observable evidence, not by assertion that the code works.<br>Correctness is demonstrated with evidence rather than claimed. A passing test run and a screenshot are provided instead of the statement that it works. VER-2 · Interpret and review code written by others or by AI Code Essential knowledge Example VER-2.a Reading for intent reconstructs what a piece of unfamiliar code is meant to accomplish.<br>The purpose of code is inferred before it is judged or changed. The return value and purpose of a function are traced before it is edited. VER-2.b Summarizing a change captures its essential structure so it can be reviewed efficiently.<br>A large change is compressed to its principal effects for review. A large change set is summarized as three effects, of which one carries the most risk. VER-2.c Reviewing at the level of changes and behavior is more effective than reading every line equally.<br>Attention is focused on what changed and what it does. The differences are read, the changed path is executed, and the riskiest lines are examined closely. VER-3 · Debug a program by systematically isolating and correcting faults Code Essential knowledge Example VER-3.a A defect must be reliably reproduced before it can be diagnosed.<br>A consistent trigger for the failure is established first. A failure occurring on inputs ending in .5 is made to reproduce on demand. VER-3.b Localization narrows a failure to a specific component or line.<br>The fault is isolated by tracing or bisection. Logging shows a value is correct before one line and incorrect after it. VER-3.c A hypothesis about a fault is tested before a change is made.<br>A theory of the cause is confirmed prior to editing code. A rounding hypothesis is confirmed by disabling the rounding and observing that the defect disappears. VER-3.d Diagnosis of a fault is distinct from its repair, and a fix must be confirmed.<br>Identifying the cause and correcting it are separate steps, and the correction is verified. The failing case and the full test suite are re-run to confirm the repair. VER-4 · Observe a running system to confirm and diagnose its behavior Code Essential knowledge Example VER-4.a When an abstraction leaks, understanding the underlying system is required to diagnose behavior.<br>Lower-level knowledge is applied when higher-level views are insufficient. Behavior that is slow only in production is diagnosed by inspecting network and database activity. VER-4.b Instrumentation and logging make a system's behavior observable rather than assumed.<br>Observability is added so that behavior can be seen. Request timings are logged to locate a slow endpoint. VER-4.c Real signal from a running system confirms outcomes and informs the next iteration.<br>Production or user signal validates a change and guides further work. A reduced error rate confirms a fix, after which regressions are monitored. Evaluating & measuring (advanced) VER-5 · Define rubrics and metrics that measure quality Code Essential knowledge Example VER-5.a A rubric translates a qualitative notion of good into measurable criteria.<br>Quality goals are expressed as attributes that can be scored. Summary quality is scored on faithfulness, completeness, and concision. VER-5.b A useful metric reflects real quality and resists being satisfied trivially.<br>Measures are chosen that cannot be gamed without genuine improvement. Branch coverage of real paths is measured rather than the raw number of test lines. VER-6 · Construct evaluations that measure the behavior of AI systems Code Essential knowledge Example VER-6.a An evaluation set pairs representative inputs with the qualities expected of a good output.<br>Representative cases and their expected outputs are curated. Fifty representative user queries are paired with reference answers. VER-6.b Rubric-based or model-judged scoring evaluates outputs at scale.<br>Evaluation is automated across many cases using rubrics or a judge model. A judge model scores each output against the rubric across the whole set. VER-6.c Automated evaluation has limits, and some cases require human judgment.<br>The cases automation cannot reliably assess are identified for human review. Cases in which a judge and a person are likely to disagree are examined manually. Sources: Stack Overflow Developer Survey 2025 · Osmani, The 70% Problem (2024) · Google Cloud DORA 2025 · Anthropic, Claude Code Best Practices · Anthropic, Multi-Agent Research System · GitClear, Coding on Copilot Foundational cross-cutting practices · span every loop Not steps — the higher-level skills applied at every phase. They govern how the loop is run and deepen with each cycle. ABS · Reasoning across levels of abstraction Enduring understanding. Tools change continually; the ability to move between levels of abstraction and to re-apply reasoning at a higher one is what makes competence durable. It is the deepest of the practices. ABS-1 · Reason across multiple levels of abstraction Code Essential knowledge Example ABS-1.a Reasoning at a high level considers overall intent and architecture.<br>Attention moves up to goals and structure when the detail is not the issue. Before a line is corrected, whether the feature is specified correctly is considered. ABS-1.b Reasoning at a low level considers a specific mechanism or detail.<br>Attention moves down to the exact mechanism when the structure is sound. With the design correct, a defect is traced to a single off-by-one error. ABS-1.c A problem exists at a particular level of abstraction, which must be identified to address it.<br>Whether an issue is architectural, logical, or a surface detail is diagnosed. An error is recognized as a flawed data model rather than a typographical mistake. ABS-2 · Design and select appropriate abstractions Code Essential knowledge Example ABS-2.a An interface separates what a component does from how it does it, isolating change.<br>A boundary hides implementation so that it can vary independently. A payment interface hides which provider is used underneath. ABS-2.b A well-chosen name communicates the purpose of an abstraction.<br>Names reveal intent to the next reader. A method named chargeCard communicates its purpose better than doPayment2. ABS-2.c An abstraction leaks when its hidden details become visible to its users.<br>A boundary that forces callers to know internal details is failing. If callers must know a specific provider is used, the abstraction leaks. ABS-3 · Apply computational reasoning at increasing levels of abstraction Code Essential knowledge Example ABS-3.a A reasoning pattern learned at one level of abstraction recurs at higher levels.<br>Familiar structures reappear as tools raise the level at which work is done. Decomposing a program into functions and decomposing a task among agents are the same pattern. ABS-3.b Established computing fundamentals apply to each new layer of tooling.<br>Core reasoning transfers to whatever the current highest abstraction is. Invariants used to reason about a loop also apply to reasoning about an agent workflow. Sources: Spolsky, Law of Leaky Abstractions · Wing, Computational Thinking (2006) · Anthropic Economic Index (software) INC · Building incrementally Enduring understanding. Incremental, verifiable development is how control is retained over code that was not written by hand: the whole loop is run on a small slice, then the next. It governs the loop rather than sitting inside it. INC-1 · Develop a solution incrementally, beginning with a minimal end-to-end version Code Essential knowledge Example INC-1.a Each increment is a working whole, not an isolated, non-functional part.<br>Every stage functions end to end rather than being a disconnected piece. A chat app that can send and display one message end to end is built before reactions or history are added — rather than building the database, UI, and network layers separately, with nothing yet working together. INC-1.b The full specify-build-verify loop is applied to a small increment before scope is expanded.<br>A small version is completed and verified before more is added. A hardcoded list is rendered and tested before persistence is introduced. INC-2 · Sequence development increments to maximize feedback Code Essential knowledge Example INC-2.a Increments are ordered so that each can be verified independently.<br>Work is arranged so that each step can be confirmed on its own. Adding an item is shipped and verified before removing an item is built. INC-2.b Addressing risky unknowns early yields feedback when it is most useful.<br>The parts most likely to fail are attempted first. An uncertain third-party integration is tested before the surrounding system is built. INC-3 · Use version control and checkpoints to make change reversible Code Essential knowledge Example INC-3.a Version control preserves known-good states, allowing risky changes to be undone.<br>Saved states enable recovery from a change that does not work. A commit precedes a large automated refactor so that it can be reverted in one step. INC-3.b Small changes are easier to review and reason about than large ones.<br>Change is kept to a comprehensible, verifiable size. One feature is submitted per change set rather than a two-thousand-line change. Sources: Kniberg, Making Sense of MVP · Anthropic, Claude Code Best Practices Advanced cross-cutting skills · layered on once the loop is fluent Higher-order skills that scale a practitioner from building one artifact to directing systems that build — and to securing them. SEC · Security & adversarial thinking (advanced) Enduring understanding. AI expands the attack surface and readily produces insecure code; verifying safety, not only correctness, spans design, build, and verification. It is an adversarial mindset applied across the whole loop. SEC-1 · Analyze a system for ways it can be misused or attacked Code Essential knowledge Example SEC-1.a Threat modeling enumerates the ways a feature could be misused or broken.<br>The possible abuses of a feature are identified deliberately. An upload feature is examined for oversized files and executable content. SEC-1.b A trust boundary is where data passes from an untrusted source into a trusted context.<br>The points at which external data enters the system are identified. Data from the browser is treated as untrusted until validated on the server. SEC-1.c All external input is treated as potentially hostile and validated accordingly.<br>Input from outside the system is assumed malicious until it is checked. A filename is sanitized and path traversal such as ../../ is rejected. SEC-2 · Apply established secure-coding practices Code Essential knowledge Example SEC-2.a Input validation restricts input to what is expected before it is used.<br>Every input is checked against an allowed form. A username containing control characters is rejected. SEC-2.b The principle of least privilege grants each component only the access it requires.<br>Access is limited to the minimum needed, and permissions are checked. A reporting service is given read-only database access rather than administrative access. SEC-2.c Injection is prevented by using interfaces that separate code from data.<br>Safe interfaces make injection structurally impossible. A parameterized query is used instead of concatenated SQL. SEC-2.d Secrets are stored outside source code, in a dedicated secret store.<br>Credentials are kept out of code and out of version control. An API key is read from a secret manager rather than committed to the repository. SEC-3 · Evaluate AI-generated code for security vulnerabilities Code Essential knowledge Example SEC-3.a AI-generated code can be plausible yet insecure and must be reviewed for security flaws.<br>Generated code is inspected specifically for vulnerabilities, not only for correctness. A generated upload handler that omits type and size checks is identified as a vulnerability. SEC-3.b Security tooling supplements manual review, and generated code is not assumed safe.<br>Scanners are applied and generated code is treated with distrust by default. Static analysis is run on a generated endpoint before it is deployed. SEC-4 · Mitigate security risks specific to AI and agent systems Code Essential knowledge Example SEC-4.a Prompt injection occurs when untrusted content manipulates a model's instructions (OWASP LLM01).<br>Untrusted input can hijack model behavior and must be constrained. An agent that reads a web page instructing it to exfiltrate data is sandboxed and constrained. SEC-4.b Model output must be treated as untrusted and not executed or rendered unsafely (OWASP LLM05).<br>Output from a model is handled with the same caution as any untrusted input. Model output is neither evaluated as code nor rendered as raw HTML. SEC-4.c Excessive agency arises when an autonomous system is granted more authority than it needs (OWASP LLM06).<br>An agent's permissions are limited to what its task requires. An agent may read files but cannot delete data or send email without approval. SEC-5 · Assess and manage software supply-chain risk Code Essential knowledge Example SEC-5.a A dependency is vetted for authenticity and maintenance before it is adopted (OWASP LLM03).<br>Third-party code is confirmed to be genuine, maintained, and trusted. A suggested library is confirmed to exist, be widely used, and be actively maintained. SEC-5.b AI systems may recommend nonexistent or typosquatted packages, a risk known as slopsquatting.<br>Recommended package names are verified, because attackers register plausible misspellings. A suggestion to install a misspelled package name is recognized as a likely typosquat and rejected. Sources: OWASP Top 10 for LLM Applications 2025 · OWASP Secure Coding Practices · Google Cloud DORA 2025 How this framework was developed Brilliant developed this framework by synthesizing recurring capabilities from the research and engineering guidance cited throughout the page. A capability was included when it was expected to remain useful as tools change and could be expressed as a measurable learning objective. Related capabilities were then organized into a precursor, the Spec & Design → Build → Verify loop, and cross-cutting practices that strengthen every pass through that loop. The result is Brilliant’s synthesis, not an industry standard: 7 Big Ideas, 30 learning objectives, and 84 substandards. Each substandard pairs an essential-knowledge statement with a concrete example so the framework can support curriculum design and assessment. For the method used to map Brilliant’s curriculum against these skills, see How Brilliant’s coding coverage was audited.