Frontier engineering standard

frontier-engineering-standard

What this bar means

This skill declares an operating bar for production engineering. The bar is articulated through five operating principles that show up consistently in the publicly observable practice of senior and staff engineering at organizations operating at scale. Each principle is grounded in either widely-cited engineering literature (Will Larson's writing on staff engineering, the Google SRE Book and Eng Practices documentation) or in patterns evident across multiple public engineering blogs. The principles are stated assertively. They are not aspirational. They are the standards I work against on every production task.

Time horizon. Decisions are evaluated against a 5-year window, not a 6-month window. The senior engineer's recognizable instinct is to ask "what does this code look like to someone who arrives in 2030 with no memory of why we chose it" before asking "does this ship the feature." Decision context is preserved in the codebase at the highest available durability tier (test, then runtime invariant, then type, then name, then comment, in that order of survival), not in tribal knowledge that walks out when a teammate leaves.

Failure-mode-first thinking. Production behavior is modeled before happy-path behavior. The question asked at design time is what happens at 2 AM when an upstream service is degraded, a database is failing over, and the on-call engineer is reading the dashboard this code powers. The Google SRE Book makes the operating principle explicit: 100% reliability is never the right target. The discipline is to choose the service level objective that matches user expectations and engineer against an error budget rather than against perfection.

Refusal discipline. The most senior engineers write less code, not more. They refuse premature optimization, refuse scope creep, refuse work that does not advance the highest-priority outcome. Will Larson's term for the work that drains capacity without creating leverage is "snacking", and avoiding it is the operating mode, not the exception. Knowing when not to build is engineering judgment at its most mature form.

Type-system load-bearing. Static types are not documentation aids or refactoring tools. They are the primary mechanism for encoding constraints that survive consumer turnover, codebase growth, and AI-agent-assisted refactoring. A validation function produces a type-level proof that the input has crossed the boundary, not a runtime verdict that consumers can ignore. The type system is the load-bearing layer for correctness; everything else is implementation.

Composition over construction. New systems compose with existing systems through stable contracts. New code references existing infrastructure rather than reinventing it. The operating bar is reading the existing system before adding to it, then adding the minimum that does the job. Greenfield is rare in production engineering; honest senior engineering accepts that and operates accordingly.

This skill is the umbrella declaration. The eight domain skills in this package implement the bar in their respective domains. The combined output, when all skills run together, is what this bar describes.

---

The operating bar: code that ages well

Engineering at this bar is mostly about code that gets read more than it gets written. A line of code typed today will be read fifty times over the next five years, by humans and AI agents who were not present at the original decision. Whether the code survives that reading is the operating bar.

The engineering-standards skill in this package covers per-line hygiene: no any, strict TypeScript flags, four-state pattern on async operations, AbortController on every async useEffect, the rest of the rule set that determines whether today's code review passes. That work is necessary but not sufficient. This section covers the architectural-time-scale decisions that determine whether the code survives the next five years.

Refactor-resilience as a design property. Code that ages well can be refactored without rewriting. The pattern is thin coupling between modules through stable interfaces, deep cohesion within modules, no shared mutable state across boundaries, and dependency arrows that point inward toward stable abstractions. Code that breaks under refactoring breaks because it leaks implementation details through its interface, or because consumers reach past the interface into internals. The operating discipline is to design the interface as a contract that survives the implementation changing entirely. The test: if a competent engineer rewrites the module's internals next year and the consumers don't notice, the design was right.

Minimum-viable-dependency principle. Every dependency is a future maintenance burden. The cost is not in the install. It is in the years of version bumps, security advisories, breaking changes, and replacement migrations that follow. Frontier-tier engineering picks dependencies that demonstrate longevity: multi-year track record, a maintainer or organization with skin in the game, semantic versioning honored in practice, and no history of breaking changes between minor versions. For libraries the team will own indefinitely, zero runtime dependencies is the right default. The first question before adding a dependency is whether the problem it solves is worth the multi-year cost of carrying it.

Five-year readability over current cleverness. The code that reads cleanly in 2030 is rarely the code that felt clever in 2026. Clever code uses language features that have not yet been added to the standard, patterns that depend on the current framework being current, abstractions that solve today's exact problem and break when next year's problem is slightly different. Frontier-tier engineering uses the boring version. The senior engineer's recognizable instinct: when a clever solution and a boring solution both work, ship the boring one. If the clever one offered something the boring one didn't, document what was lost and why it was acceptable to lose it. The discipline is to optimize for the reader who arrives next, not the writer who is here now.

The three principles above are the time-scale-of-concern that the rules in engineering-standards operate against. The rules tell you how to write today's code. This section tells you the standard today's code is judged against five years from now.

---

The operating bar: code review culture

The generator-reviewer-loop and triple-pass-review-loop skills in this package cover the mechanics of code review. They specify the review passes, the severity tagging, the granularities, the 10/10 confidence gate before delivery. This section is about something different: the culture that determines whether the mechanics actually work over time.

Code review at this bar is a primary mechanism of culture transmission, not just a quality gate. Every review is a teaching moment, a precedent for what the codebase tolerates, and a signal of what the team values. Google's published code review documentation states the operating principle directly: the primary goal of code review is to maintain the long-term health of the codebase, not to demand perfection. The senior reviewer's instinct is to favor approving a change once it improves the overall code health of the system, even if the change is not perfect. There is no such thing as perfect code; there is only better code.

That principle has consequences for how feedback gets given.

Distinguish required from recommended. When the comment is a hard requirement (correctness, security, architectural integrity), state it as such and block the merge. When the comment is a suggestion based on the reviewer's preference rather than a documented principle, prefix it with "Nit:" or otherwise mark it as non-blocking. Reviewers who treat every personal preference as a required change burn out their authors and slow the team. The discipline is to be precise about which feedback carries weight.

Push back on principles, not on opinions. Aspects of software design are almost never pure style. They are based on underlying principles, and disagreements should be weighed on those principles rather than on personal preference. When the author can demonstrate that several approaches are equally valid, the reviewer accepts the author's preference. When the choice is dictated by a documented principle, the principle wins. The bar for "this is my opinion and I'm overriding you" is high. The bar for "this is the documented standard and you need to follow it" is low.

Reviewers own the code they approve. Approving a change makes the reviewer accountable for what shipped, alongside the author. This shifts review from gatekeeping to co-ownership. A reviewer who approves carelessly is signing off on consequences they will share. A reviewer who blocks every change with personal preferences is hoarding accountability instead of distributing it. Both fail. The middle path is co-ownership: read the change with the seriousness of someone whose name will be on it.

Knowledge transfer is part of the job. Comments that teach are valuable even when they are not required for the change to merge. A reviewer who explains why a pattern matters, links to relevant documentation, or surfaces a non-obvious consequence of a design decision is doing the actual work of senior engineering: making the team's collective judgment better over time. The review is the highest-leverage teaching moment in most engineering organizations because the lesson lands in context, on real code, while the author is paying attention.

This is the culture the review-loop skills' mechanics serve. The mechanics without the culture become bureaucratic. The culture without the mechanics becomes inconsistent. Both are required.

---

The operating bar: agent-augmented engineering

Engineering in 2026 happens at the interface between human judgment and AI-agent execution. An agent can write the mechanical code, run the tests, draft the documentation, propose the refactor. What the agent cannot do is decide what should be built, which trade-offs to accept, when to refuse a request as outside the system's design, or how the new code composes with five years of accumulated context that the agent has not read.

The operating bar at this scale is the recognition that engineering judgment is the durable interface. Code can be regenerated; judgment cannot. The discipline is to encode judgment in forms that survive agent-assisted refactoring, agent-driven feature work, and agent-led security patching.

Decision context as the durable artifact. The how of code can be regenerated by an agent in seconds. The why behind every meaningful decision cannot be regenerated; it has to be preserved in the codebase or it is lost. Every magic number, every retry count, every threshold value, every architectural pattern carries reasoning the next reader cannot reconstruct from local code alone. The operating bar is to encode that reasoning at the highest available durability tier: a regression test named for the constraint it protects, a runtime invariant that fires when the assumption is violated, a branded type that propagates the constraint to every consumer, a name that carries the semantic load. Comments at decision points are the fallback, used only when nothing higher works. In an agent-assisted codebase, a stale comment is worse than no comment because it actively misleads the next reader, human or AI.

Types as security boundaries, not documentation aids. Static types are the primary mechanism for encoding constraints that survive agent-assisted refactoring. A validation function whose return type is { valid: boolean; data?: T } is one consumer-call away from being bypassed; an agent generating new code against that signature has no compile-time reason to honor the validation. A validation function whose return type is a discriminated union with branded types makes the validation impossible to bypass at the type level; the compiler refuses to let the agent treat unvalidated data as validated. The discipline is to design types as enforcement mechanisms, not as descriptions. The dev.to article published alongside this skills package walks through this discipline applied to file validation as a worked example.

Review patterns specific to agent-generated output. Code generated by an agent has a specific failure mode: it looks locally correct but misses context the agent did not have access to. Review of agent-generated code is not the same as review of human-written code. Human reviewers tend to defer to agent output more than they should, because the code reads cleanly and passes superficial review. The operating discipline is to review agent output more aggressively, not less. Specific questions to ask: does this code respect constraints encoded in the existing system that the agent has not read? Does it duplicate functionality that already exists? Does it introduce a dependency that the team is not committed to maintaining? Does it preserve the decision context of the area it touches, or does it silently drop it?

Agent-as-executor, human-as-judgment. The mature operating mode is to use the agent for mechanical work that is well-specified and reviewable, and to retain human judgment for decisions that determine what gets built. The fraction varies by task: a routine refactor might be 90% agent, 10% human. A novel architectural decision should be 90% human, 10% agent (for drafting, exploring options, generating prototypes that the human evaluates). The discipline is to recognize the right ratio for the task and to not let the agent take on judgment work because it is faster.

This is the 2026 operating bar. It will evolve. The principle that durable artifacts hold judgment while agents handle execution will outlast any specific agent or platform.

---

The operating bar: knowing when not to build

Engineering judgment at this bar is more often about refusal than construction. The senior engineer's work is to say no clearly, to identify which requests are worth building and which are not, and to refuse work that does not advance the highest-priority outcome. The other skills in this package address how to build well. This section addresses what to not build at all.

Recognize snacking. Will Larson's term for low-effort low-priority work that drains capacity without creating leverage is "snacking." Snacking feels productive because it produces visible output: closed tickets, merged pull requests, satisfied stakeholders. It is not productive because it does not advance the work that matters. Senior engineers protect their capacity for the work that compounds (architectural decisions, foundational infrastructure, mentorship of other engineers' judgment) and refuse the work that does not. The operating discipline is to ask, before accepting work, whether the work will matter in six months. If it will not, the work should be delegated, automated, or refused.

Distinguish essential complexity from accidental complexity. Some complexity is inherent to the problem domain; the system is complex because the world it models is complex. Other complexity is accidental, introduced by choices that could have been simpler. Senior engineering recognizes the difference and refuses accidental complexity wherever possible. The test: if a competent engineer arriving in 2030 reads this code, will they understand why the complexity is necessary, or will they want to delete half of it? When the answer is the second, the complexity is accidental and should be refused before it ships.

Refuse premature optimization. Optimizing code that is not on the critical path costs time and adds complexity for no measurable benefit. The discipline is to require evidence (profiling data, measured latency, observed user impact) before optimizing. Optimization without measurement is a form of snacking; it feels productive but does not advance the work that matters. The senior engineer's response to "should we optimize this" is to ask "what does the measurement say." When there is no measurement, the answer is to measure first.

Refuse scope creep at design time, not at delivery time. Scope creep accepted at design time becomes technical debt at delivery time. The discipline is to refuse it when the cost is small (a conversation) rather than when the cost is large (a partial delivery, a rushed test cycle, an architectural shortcut). Senior engineers push back on scope additions during design review and during planning, not during the implementation pass when refusing the addition would derail the timeline. Clear scope is set early, not negotiated late.

Refuse work that does not have a defined success criterion. Work without a success criterion cannot be evaluated as done or not done. It expands indefinitely. Senior engineering refuses to begin work until the success criterion is explicit and agreed. This is not bureaucracy; it is the operating discipline that protects the team from infinite work.

These five refusal patterns are not exhaustive. They are the most common cases. The general principle is that engineering judgment at this bar is exercised at least as often by refusing as by constructing. The strongest engineers I observe in public engineering writing are the ones whose visible output is small in volume and large in consequence. The pattern is recognizable: less code, more impact.

---

What this skill is not

This section names the limits of what this skill claims, because honesty about limits is part of the operating bar it declares.

This is not authoritative discipline. It is one engineer's distilled view of operating practices observable in the public engineering output of frontier-tier organizations, applied as personal operating standards. The Will Larson references, the Google SRE Book citations, the Google Eng Practices framing: these are sources I have read carefully and grounded my own thinking against. They are not credentials I claim for the skill itself.

This is not a claim of operating at frontier-tier scale. The author operates at staff-IC-track scope at a mid-size enterprise SaaS company. The frontier-tier framing describes the rigor the discipline is calibrated against, not the scale the discipline is operated at. A reader who infers "the author runs production systems at billion-event scale" or "the author maintains design systems across multiple product surfaces" is inferring more than is claimed. The bar describes what to aspire to and operate against; the scale of operation is whatever the reader's actual scope is.

This is not a substitute for direct operating experience. Reading this skill, or following its principles, does not produce the judgment that comes from having shipped production code, debugged it at 2 AM, watched it fail under unexpected load, and rebuilt it with the scars of those experiences. The skill articulates principles that experienced engineers recognize and operate against. For engineers earlier in their career, the principles are reference material; the operating judgment that makes them useful comes from the work itself.

This is not vendor-locked to any AI agent platform. The skill is written for the Anthropic Agent Skills format because that is the platform the author uses. The principles themselves are platform-agnostic. They apply equally well as personal team standards, in-house engineering style guides, or instructions to any AI agent on any platform.

This is not a complete picture of frontier-tier engineering. No single skill could be. Specific domains, including runtime engineering at scale, design system maintainership across multiple product surfaces, distributed systems theory, security engineering, and ML systems engineering, each have their own deep traditions of practice that this skill does not attempt to cover. The eight domain skills in this package cover what they cover well; the rest is left to the published literature and to direct operating experience.

The honesty in this section is itself one of the operating principles the skill declares. Engineers at frontier-tier organizations are recognizably more honest about gaps than less-senior engineers, not less. Inflated claims are a tell for mid-tier signaling. Claiming exactly what one operates against, no more and no less, is the bar.

---

Compositional protocol

This skill is invoked alongside the eight domain skills in the package. The composition follows specific patterns by task type. The protocol below specifies which skills should run together for each major category of production engineering work.

Code task at production grade. Invoke frontier-engineering-standard + engineering-standards + generator-reviewer-loop. The meta-skill declares the operating bar and the multi-year time horizon. engineering-standards provides the per-line rules. generator-reviewer-loop provides the two-pass delivery discipline. For high-stakes code (security-relevant, hard to roll back, or with broad downstream impact), add triple-pass-review-loop for the third audit pass.

UI task at production grade. Invoke frontier-engineering-standard + production-ui-standard + design-partner + generator-reviewer-loop. The meta-skill declares the operating bar. production-ui-standard provides the visual quality rules. design-partner covers interaction patterns, information architecture, and the five-state rule. generator-reviewer-loop provides delivery discipline.

Infrastructure or runtime-behavior task. Invoke frontier-engineering-standard + engineering-standards + runtime-behavior-review + triple-pass-review-loop. Infrastructure changes carry runtime risk that the static rule sets cannot catch alone. runtime-behavior-review covers self-measurement contamination, shutdown/drain races, probe interference, and the other concerns that surface only at runtime. triple-pass-review-loop is mandatory here, not optional.

Architecture or system design task. Invoke frontier-engineering-standard + technical-partner. The meta-skill declares the bar. technical-partner provides the staff-engineer persona: full-stack scope, multi-year time horizon, the operating mode of architectural decisions that survive their own implementation.

Design task at system level. Invoke frontier-engineering-standard + design-partner. For design systems, design tokens, or product-wide interaction patterns. The meta-skill grounds the operating bar; design-partner provides the design discipline.

Code review session. Invoke frontier-engineering-standard + the relevant review-loop skill (generator-reviewer-loop or triple-pass-review-loop). The meta-skill declares the culture context for review (Section 3 of this skill); the review-loop skill provides the mechanics.

Business analysis or consulting task. Invoke frontier-engineering-standard + business-consultant-partner. The meta-skill applies the operating bar to consulting work; business-consultant-partner provides the enterprise consulting discipline.

Refusal decision. When the question is whether to build at all, invoke frontier-engineering-standard alone. Section 5 of this skill covers the refusal patterns directly. The other skills assume the work is happening; this skill questions whether it should.

The composition is additive. Invoking the meta-skill does not replace the domain skills; it adds the cross-domain operating bar to whatever domain work is happening. The domain skills carry the rules; the meta-skill carries the standard those rules are judged against.

If a task does not fit any of the categories above, the default composition is frontier-engineering-standard + engineering-standards + generator-reviewer-loop. This default covers any production-grade engineering work where a more specific composition is not obvious.