Your SDLC Is Your Context Engineering  🔗 **Source:** [Your SDLC Is Your Context Engineering](https://leaddev.com/software-quality/your-sdlc-is-your-context-engineering) > [!note]+ Document Notes > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > --- > tags: [context-engineering, ai-coding-agents, sdlc, code-review, developer-tools, engineering-culture] > author: [MISSING] > source: LeadDev > reference: https://leaddev.com/software-quality/your-sdlc-is-your-context-engineering > date created: 2026-08-10 > > --- > > # 🏷️ Title: Your SDLC is your context engineering > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [What is context engineering?](https://leaddev.com/ai/what-is-context-engineering) - [Engineering owns velocity](https://leaddev.com/velocity/engineering-owns-velocity) - [DORA 2025 AI-assisted software development report](https://cloud.google.com/resources/content/2025-dora-ai-assisted-software-development-report) - [Do we need AI agents to fix our AI agents?](https://leaddev.com/technical-direction/do-we-need-ai-agents-to-fix-our-ai-agents) - [How to avoid knowledge decay in software engineering](https://leaddev.com/ai/how-to-avoid-knowledge-decay-in-software-engineering) - [Your AI coding tools buying checklist for 2026](https://leaddev.com/ai/your-ai-coding-tools-buying-checklist-for-2026) - [Build a productive code review culture](https://leaddev.com/culture/build-a-productive-code-review-culture) - [AI governance is now an engineering problem](https://leaddev.com/ai/ai-governance-is-now-an-engineering-problem) - [How to prepare for AI agents](https://leaddev.com/technical-direction/how-to-prepare-for-ai-agents) ## 📝 Summary - A founding engineer at Vendict (a lean third-party risk management/TPRM startup) rebuilds the company's entire SDLC around one thesis: in the agentic era, the software development lifecycle itself is the context an AI coding agent operates on — not just an AGENTS.md file. - The rebuild took roughly a month and reorganizes the repo into a monorepo with a three-lifecycle doc structure (docs/ = current truth, plans/ = future work, docs/adr/ = durable decisions), four execution "lanes" by risk level, a path-referenced standards layer, and a devcontainer that scopes credentials but leaves egress open. - Key stakeholders: engineering leadership designing agent-ready process, individual contributors (human and AI) who consume the same standards, human reviewers whose bottleneck is now review throughput rather than implementation speed, and tooling vendors (Cursor, Claude Code, Codex, CodeRabbit) that read the same files. - Risks and tradeoffs named explicitly: PR-size caps can push agents to skip tests unless tests are exempted; single-agent-session builder/reviewer conflation causes agents to rationalize away their own failures; open egress trades a security surface for agent research capability; deferring observability and production-agent safety leaves real gaps the author admits are out of scope. - Bottom line: most critical defects the team now sees trace back to underspecified plans and specs, not code — so the leverage point for agentic reliability is upstream process design, not tighter prompts or bigger context windows. ## 📖 Main Content - Core argument: file-level context engineering (AGENTS.md) is necessary but insufficient. It tells an agent facts about the codebase but not operational judgment — what "done" means, what is off-limits, when to split a change, when to escalate to a human, which test type fits which behavior. That judgment lives in the SDLC: the specify → review → test → ship pipeline. - Structural changes made at Vendict: - **Monorepo** as shared context boundary (mirrors Google's model, "at a tiny fraction of that" scale) — shared visibility, but build/deploy/ownership stay scoped separately from the repo boundary. - **Three-lifecycle docs**: `docs/` = current merged truth only; `plans/` = future/active execution artifacts; `docs/adr/` = durable architecture decision records, never deleted, only superseded. Rigidity here exists specifically so an agent knows which document to trust — mixed current/future docs is called out as a direct path to agent hallucination on an abandoned plan. - **Four execution lanes**: Lane A (standard work), Lane B (spec+plan required for meaningful design surface), Lane C (two approvals + CODEOWNERS for control-plane/auth/data-access paths), Lane D (isolated experiments). - Three "easy to miss" design choices the author walks through in detail: 1. **Tests excluded from PR size caps.** Soft cap 500 lines, hard cap 1,000 — but tests don't count, because counting them would train the agent to under-test or split implementation from tests. A separate, isolated test-designer subagent (reading only the spec's acceptance criteria and the plan, not the implementer's reasoning trace) prevents the implementing agent from writing a test that conveniently validates whatever it actually shipped. 2. **Builder/reviewer separation at task granularity, not PR granularity.** A single agent session can span implementation, tests, verification, and lint — meaning the same context that decided "this is correct" would grade its own test. The `plan-implementer` skill spawns four separate subagents (test designer, failure analyzer, verifier, linter), each in an isolated context. A failure-classifier subagent (not the implementer) labels failures TEST_ISSUE / IMPL_ISSUE / DOC_ISSUE / UNCLEAR; UNCLEAR always escalates to a human. Circuit breakers cap the loop: three test-fix cycles, two verification cycles, then mandatory escalation. 3. **spec.md and plan.md as separate but co-located artifacts.** Reviewed from different angles (product/system vs. R&D) to stop intent, strategy, and approval authority from blurring into one ambiguous thread — but shipped in the same PR so both artifacts stay durable, visible context for agents that can't "remember a Slack thread" the way humans do. - **Standards layer**: `docs/standards/` holds one profile per concern (per-language quality, cross-cutting rules, document shape, templates). Profiles cite each other by path and never restate — one edit propagates everywhere. ~19 AGENTS.md files across root/app/submodule levels reference these profiles and list deny-list paths. A single Makefile interface (`make ci/test/lint/fmt/build/run`) is the verification contract for agents, CI, and new human engineers alike. CodeRabbit config is "thin" — mostly path-routing to the same markdown profiles, plus lane-aware escalation (a Lane A PR touching Lane B/C surface gets escalated automatically). - **Four rubric principles calibrated for AI-heavy review**: (1) verify a claim against HEAD before filing it, or file it as a question — false-positive rate dropped from ~30% to ~10% this way; (2) documentation inconsistencies are never "Minor," always at least "Medium," because stale docs mislead every future agent session; (3) reviewers must cross-read design-decisions.md/ADRs before flagging something as redundant or fragile; (4) tests are graded against the spec's acceptance criteria, not line coverage. - **Devcontainer as execution boundary**: scopes credentials (no SSH keys, time-scoped AWS access, no DB delete) but deliberately leaves outbound network access open — the tradeoff being that agents do a lot of legitimate research (API contracts, README lookups, Terraform examples) that egress-locking would kill. - **Explicitly out of scope** (named, not hidden): observability/tracing/SLOs/on-call beyond CloudWatch; product-facing AI safety (prompt injection, customer-behavior evals); production agent safety (sandboxing, credential scoping, runtime governance for customer-facing agents). - **First-month lessons**: weekly "what I shipped, what I learned, no takes" demo syncs helped adoption; the merge queue is the next bottleneck; and — the headline empirical finding — almost every critical issue reviewers catch traces back to the specification and planning stage, not the code itself. - **Two meta-lessons**: the SDLC didn't need to be perfect before rollout (tune in flight beats predicting everything up front); and some engineers adopt faster from one worked example (a template, a first Lane B feature) than from a process document. - **Where the bottleneck moved**: implementation speed used to gate velocity; now it's human review throughput, because focused agent-generated PRs arrive faster than humans can review them. The author predicts (not yet practiced at Vendict) that humans will increasingly review intent — spec, plan, acceptance criteria — while AI/automation increasingly covers the code diff itself. ### 🗒️ Notes - Uncertainty flagged by the author: the PR-lane rule "sometimes makes agents stricter with themselves than necessary" — approved-plan changes to protected paths still get flagged by the agent or a reviewer as "this file wasn't supposed to change," a self-acknowledged false-positive cost of an otherwise-sound safety rule. - Contested framing to note: the article treats "90–95% of Claude Code's own codebase is written by Claude Code" (cited to Anthropic's Mike Krieger) as representative of where the industry is heading; that figure describes one frontier lab's internal tool-building loop, not typical enterprise or startup conditions, and the author acknowledges the "magnitude is different" at a small startup even while claiming "the direction is the same." - The article is written from inside a single, very small (unspecified size, "lean… startup," "my team is small") organization roughly one month into the new process — findings are self-reported, not externally audited, and there is no control condition (no comparison to the pre-rebuild SDLC's defect or velocity numbers beyond the general PR-size defect-detection stat, which is drawn from an external cross-industry study, not Vendict's own data). - Terms defined in-article: SDLC (software development lifecycle), TPRM (third-party risk management), ADR (architecture decision record), CODEOWNERS (GitHub path-based required-reviewer mechanism, assumed known), DORA (DevOps Research and Assessment). ## 📚 References - [What is context engineering?](https://leaddev.com/ai/what-is-context-engineering) - [Anthropic 2026 Agentic Coding Trends Report](https://resources.anthropic.com/hubfs/2026%20Agentic%20Coding%20Trends%20Report.pdf) (Mike Krieger's Claude Code self-authorship stat) - [Engineering owns velocity](https://leaddev.com/velocity/engineering-owns-velocity) - [DORA 2025 AI-assisted software development report](https://cloud.google.com/resources/content/2025-dora-ai-assisted-software-development-report) - [Do we need AI agents to fix our AI agents?](https://leaddev.com/technical-direction/do-we-need-ai-agents-to-fix-our-ai-agents) - [How to avoid knowledge decay in software engineering](https://leaddev.com/ai/how-to-avoid-knowledge-decay-in-software-engineering) - [AI coding tools buying checklist for 2026](https://leaddev.com/ai/your-ai-coding-tools-buying-checklist-for-2026) - [Build a productive code review culture](https://leaddev.com/culture/build-a-productive-code-review-culture) - [AI governance is now an engineering problem](https://leaddev.com/ai/ai-governance-is-now-an-engineering-problem) - [How to prepare for AI agents](https://leaddev.com/technical-direction/how-to-prepare-for-ai-agents) - PR size vs. defect-detection data — cited inline as "the data says otherwise," referencing an external study on AI-review accuracy degrading past ~1,000-line diffs (source not individually linked in captured content) ## 🗣️ Paraphrase - The piece argues that AGENTS.md-style file instructions were the first wave of "context engineering" for coding agents and they worked, but they cap out: they tell an agent facts, not judgment. An agent reading a perfect AGENTS.md still doesn't know when a change is safe to ship whole versus needs slicing, when an edge case needs a human, or what "done" means for this specific feature — because that judgment isn't a fact you can write once, it's a process you have to build into how work gets specified, reviewed, tested, and released. The author's fix was to rebuild the company's entire SDLC — documentation lifecycle, PR-risk lanes, review rubric, subagent separation, container security boundary — as one coherent system where every rule exists because of a specific agent failure mode it prevents, not as generic best practice. - The second half is a report from one month of running that system: the biggest surprise wasn't a broken rule, it was where the failures cluster — almost entirely in planning and specification, not in the code an agent produces. That reframes the entire problem: better agents or better prompts don't fix bad specs; only better upstream process does. The corollary bottleneck shift — from "how fast can we implement" to "how fast can humans review" — is presented as the next problem the author expects the industry to face broadly as agent-authored PR volume rises. ## 📰 Newsletter Most WordPress teams still treat AGENTS.md (or CLAUDE.md, or a plugin's own contributing guide) as the whole story for getting an AI coding agent to behave. This piece argues that's the easy 20% — the file tells the agent facts, but not judgment: what counts as "done" for a Core ticket, which files are genuinely off-limits (looking at you, `wp-includes/`), when a patch should be split into a smaller diff for review, and when an edge case needs a human's eyes instead of a confident guess. The author's answer was to rebuild their whole SDLC — a three-lifecycle doc structure (current truth vs. active plans vs. permanent decision records), risk-based PR lanes, and — most relevant to WP Core/CLI/Playground contributors — separating "the agent that wrote the patch" from "the agent that reviews the patch" at the task level, not just the PR level, because a single agent session grading its own tests will rationalize away its own gaps almost every time. Their biggest one-month finding: nearly every critical defect traced back to an underspecified ticket or plan, not to bad code. If you're piloting AI-assisted patches for Trac tickets or plugin PRs, that's the lesson worth stealing before you touch a single prompt: tighten the spec, not the model. ## ✅ Action Items #### DevRel - Developer advocacy: build a short talk/demo comparing "AGENTS.md-only" agent workflows vs. an SDLC-scoped one (lanes, doc lifecycles, subagent separation) for WordPress plugin/theme teams piloting AI-assisted contributions. - Education: draft a workshop module on writing spec/plan artifacts that agents can act on without a human filling gaps verbally — directly reusable for WP Core onboarding of AI-assisted contributors. - Developer experience: prototype a WordPress-flavored `docs/standards/` layer (coding-standards.md, testing-profile.md, review-rubric.md) that Core, CLI, and Playground could each reference by path instead of duplicating in each plugin's CONTRIBUTING.md. - Developer marketing: no strong fit identified from this source. - Community management: survey active AI-assisted contributors on where their PRs get rejected — spec ambiguity vs. code quality — to test whether the article's "planning, not code" finding replicates in a WP context. - Internal/external/cross-project: share this piece with Core Performance and Core AI subteams as a case study on separating builder/reviewer agent roles before mandating AI-assisted patches. #### OSPO - Policy & Governance: consider a lane-style PR risk classification (standard / spec-required / two-approval-required) for AI-assisted contributions touching security-sensitive paths. - License Compliance: not directly addressed by this source; no action identified. - Security Management: evaluate the devcontainer credential-scoping pattern (no SSH keys, time-scoped cloud credentials, open egress) as a reference model for sandboxing AI agents contributing to owned repos. - Software Inventory: not directly addressed; no action identified. - Developer Support: document a "which file is current truth" convention (mirroring docs/ vs plans/ vs adr/) for contributor-facing docs to reduce agent hallucination on stale plans. - Community Engagement: no strong fit identified. - Strategic Alignment: use the article's five stated goals (velocity, mainline safety, agent usability, operational clarity, incremental adoption) as a template for framing an internal AI-tooling adoption OKR. #### Community - Maintainers: pilot a test-generation subagent pattern (isolated from the implementer's context) for maintainers reviewing AI-assisted first-time-contributor PRs. - Contributors: add a "spec.md vs plan.md" style split to first-issue templates so new contributors (human or agent-assisted) separate what to build from how to build it. - Sponsors: no strong fit identified. - Ecosystem: flag the "review throughput becomes the bottleneck, not implementation speed" finding for cross-project incident/retro discussions as AI-assisted PR volume grows. #### WordPress - Core: evaluate whether Trac ticket descriptions could be split into spec-like (intended behavior) and plan-like (execution approach) sections to give AI-assisted patch contributors clearer acceptance criteria. - Core Performance: no strong fit identified from this source. - Core AI: pilot the "verify before flagging" and "docs inconsistencies are never Minor" rubric rules for any AI-assisted Core review tooling. - Core Program Team: consider a lightweight risk-lane classification for Core Program Team dependency tracking on AI-assisted contributions. - Mobile: no strong fit identified. - Playground: prototype the devcontainer credential-scoping pattern (scoped credentials, open egress) for AI agents testing changes inside Playground sandboxes. - Community: no strong fit identified. - Training: build a lesson plan module on "writing specs an agent can act on" using the article's Lane B spec+plan structure as a worked example. - Marketing: no strong fit identified. - Support: no strong fit identified. - Design: no strong fit identified. - Documentation: pilot a path-referenced standards layer (single source per concern, cited not duplicated) for DevHub/HelpHub style guides consumed by both humans and AI tools. - Photos: no strong fit identified. - TV: no strong fit identified. - Polyglots: no strong fit identified. - Accessibility: no strong fit identified from this source specifically. - Meta: no strong fit identified. - CLI: evaluate a Makefile-style single verification interface (`make ci/test/lint/fmt`) for WP-CLI command scaffolds so agents, CI, and contributors self-verify identically. - Hosting: no strong fit identified. - Tide: consider the "verify before flagging" false-positive-reduction principle for Tide's automated scoring transparency work. - Openverse: no strong fit identified. - Themes: no strong fit identified. - Plugins: pilot the builder/reviewer subagent separation pattern for plugin security review triage, where a single reviewing agent currently both flags and self-validates issues. #### The WPOCC - Programs: no strong fit identified from this source. - Projects: consider documenting a "current truth vs. active plan vs. permanent decision" convention for WPOCC governance docs to reduce ambiguity for contributors. - Funding experiments: no strong fit identified. ### FAIR - Technical independence: the devcontainer's scoped-credential/open-egress model is a relevant reference pattern for FAIR's provenance and signature-check tooling if AI agents are ever used to author FAIR infrastructure code — worth a bookmark, not urgent. - Policies and covenants: no strong fit identified. - Productized governance artifacts: the article's docs/adr/ (never-deleted, only-superseded decision records) pattern is directly reusable for FAIR's charter/operator-agreement version history. ## 🧪 Hypotheses - H1: Teams that separate builder and reviewer agent roles at the task level (not just the PR level) will show a measurably lower rate of "agent rationalizes its own test failure" incidents than teams that rely on a single agent session covering implementation, testing, and self-verification. - H2: PR size caps that exclude test code from the line-count limit will correlate with higher test-suite density (tests per feature) from AI-authored PRs than caps that count all changed lines equally. - H3: Organizations that maintain a strict "current truth vs. future plan" document separation (this article's docs/ vs plans/ vs adr/ split) will see a lower rate of agent actions grounded in stale or abandoned plans than organizations with a single merged documentation tree. - H4: As AI-assisted PR volume rises, human code review throughput — not implementation speed — becomes the binding constraint on delivery velocity, independent of team size. - H5: The share of critical post-merge defects attributable to underspecified requirements/plans (versus implementation bugs) rises as agent-authored code share rises, because agents execute a bad spec faithfully rather than catching its ambiguity the way an experienced human engineer might. - H6: A "verify against HEAD before flagging" rule for AI code reviewers reduces false-positive review comments more than tuning the reviewer's prompt or model choice does. ### 📊 Methodology - H1/H2: A/B or before/after comparison across matched repositories (or matched time windows in the same repo) — one cohort with task-level builder/reviewer subagent separation and test-exempt PR caps, one without. Measure: rate of post-merge test-related bugs, rate of reviewer-flagged "test conveniently matches shipped behavior" cases, and tests-per-feature ratio. Requires manual labeling of a sample of PRs to classify failure causes (as Vendict's own TEST_ISSUE/IMPL_ISSUE/DOC_ISSUE/UNCLEAR taxonomy does). - H3: Compare agent hallucination/error rates (actions grounded in stale plans) between repos using a strict docs/plans/adr split versus repos with merged documentation, controlling for repo size and agent tooling. Could be tested retrospectively via git-blame analysis of agent-authored commits that reference or act on outdated planning docs. - H4: Time-series analysis within a single organization tracking PR throughput vs. review-completion latency over the adoption period, correlated against the share of PRs that are agent-authored. Vendict's own one-month dataset is a natural (if small, n=1 org) starting point; a multi-org study would need review-latency telemetry from several teams at different agent-adoption stages. - H5: Root-cause tagging of a statistically meaningful sample of post-merge defects (e.g., 100+) as "spec/plan issue" vs. "implementation issue" vs. "test issue," repeated at intervals as agent-authored code share increases, to see if the spec/plan share trends upward. This is essentially what Vendict's rubric already does at the individual-PR level — the missing piece is aggregating it into a longitudinal metric. - H6: Controlled comparison of AI-reviewer false-positive rates with and without a "verify against HEAD" enforcement step, holding the underlying review model constant. Vendict's self-reported drop (~30% to ~10%) is suggestive but uncontrolled — a proper test would need a holdout set of reviews without the rule, scored by the same rubric. ### ❓ Questions - Does the "planning, not code" finding replicate outside a single ~month-old, single-startup dataset, or is it partly an artifact of Vendict's rubric explicitly steering reviewers to check design-decision alignment before flagging code — which would mechanically push blame upstream regardless of where the actual defect originated? - How does the four-lane risk classification (A/B/C/D) hold up as team size scales past "lean startup" — does CODEOWNERS enforcement on Lane C become a bottleneck once dozens of engineers and agents are shipping concurrently? - What happens to the "open egress, closed credentials" devcontainer tradeoff if an agent's research browsing is itself compromised (e.g., prompt injection from a malicious README) — does the threat model need revisiting given the article explicitly defers "production agent safety" to a future piece? - Is the builder/reviewer subagent separation pattern (test designer, failure analyzer, verifier, linter as four isolated contexts) cost-effective at scale, or does it work specifically because Vendict is small enough that the added inference cost per feature is negligible? - As "humans review intent, AI reviews code" becomes more common (the article's stated direction), who is accountable when an AI reviewer approves code that technically satisfies a flawed spec that a human already signed off on? ### 🔮 Future Research - A longitudinal, multi-organization study tracking defect root-cause distribution (spec/plan vs. implementation vs. test) as AI-authored code share rises from near-zero to majority, to test whether "critical issues trace back to planning" is a general pattern or specific to teams that have already tuned their review rubric to look for it. - Empirical comparison of PR-size defect-detection curves (the "87% at small diffs, 28% above 1,000 lines" statistic the article cites) specifically for AI reviewers versus human reviewers, and whether excluding tests from the cap actually changes AI-reviewer accuracy or just changes the diff a human sees. - Research into merge-queue and review-throughput bottlenecks under high agent-authored PR volume — the article names this as "the next problem to solve" but doesn't yet have data on it. - A study of whether the escalate-on-UNCLEAR circuit-breaker pattern (three test-fix cycles, two verification cycles, then mandatory human escalation) generalizes across agent tooling vendors, or is tuned to the specific failure modes of the tools named (Cursor, Claude Code, Codex, CodeRabbit). ### 💡 Implications - **Practice**: Teams adopting AI coding agents should treat SDLC redesign — not prompt engineering or bigger AGENTS.md files — as the highest-leverage investment for agent reliability. The specific, reusable patterns are: separate builder and reviewer contexts at the task level; exempt tests from PR size limits while still capping implementation diffs; maintain a hard current/future/permanent documentation split; and give agents (and humans) a single, path-referenced standards source instead of duplicated instructions per tool. - **Education**: Training programs for engineers adopting AI-assisted development should teach spec/plan writing as a first-class skill, on the article's evidence that most critical defects trace to underspecified requirements rather than code. This reframes "AI coding literacy" curricula away from prompt syntax and toward requirements clarity — a skill overlap with product management, not just engineering. - **Security**: The devcontainer pattern (scope credentials tightly, leave egress open, review the boundary itself in a high-scrutiny PR lane) is a concrete, adoptable middle ground for orgs weighing "lock everything down" against "give agents full access" — worth piloting before assuming either extreme is necessary. - **Funding/resourcing models**: The article's warning that review throughput — not implementation speed — becomes the bottleneck has budget implications: organizations investing heavily in agent tooling without also investing in reviewer capacity (human or automated) will hit a wall regardless of how fast agents ship code. - **Tooling vendor relationships**: Keeping standards in version-controlled markdown rather than vendor-specific config (the article's explicit "tool portability" argument) is a hedge against vendor lock-in that OSPO and platform teams should weigh when standardizing on any single AI coding tool. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid approx. grade 12–13 (long compound sentences, technical vocabulary like "CODEOWNERS," "egress," "circuit breakers," assumed familiarity with SDLC/CI/PR terminology) — aimed at practicing engineering leaders, not a general audience. #### 👀 Visual learners - Present: five embedded diagrams (all credited "Source: Daniel Kravets") covering severity calibration, Python conventions, the docs/standards tree, the CodeRabbit YAML config, and the "verify before flagging" rubric flow. - Improve: the diagrams are referenced ("Here is what that looks like in the actual file") but the article text doesn't describe their content in enough detail to be useful without viewing the image — add captions or alt-text summaries so the visual argument survives in text-only contexts (e.g., screen readers, RSS readers). #### 🔊 Aural learners - Present: no audio/podcast version identified in the fetched content. - Improve: a 3–5 minute narrated summary of the five lanes and three design choices would let this content work as a commute-length listen. #### 🗣️ Verbal learners - Present: the article defines acronyms on first use (SDLC, TPRM, ADR, DORA) and uses concrete analogies ("the 11th contributor," "reviewing documentation instead of code"). - Improve: a short glossary sidebar (Lane A–D, docs/plans/adr, TEST_ISSUE/IMPL_ISSUE/DOC_ISSUE/UNCLEAR) would help readers unfamiliar with Vendict's specific vocabulary track the piece without re-reading definitions embedded mid-paragraph. #### 🧩 Kinesthetic learners - Present: the article names concrete artifacts (Makefile targets, AGENTS.md file count, PR line caps) a reader could replicate. - Improve: no downloadable template, sample AGENTS.md, or sample rubric file is linked — a companion repo or gist with a starter docs/standards/ layout would make this actionable rather than descriptive. #### 🧠 Logical learners - Present: the four execution lanes and the TEST_ISSUE/IMPL_ISSUE/DOC_ISSUE/UNCLEAR classification are effectively decision trees; the five stated goals function as evaluation criteria applied consistently through the piece. - Improve: an explicit table mapping each of the five goals to the specific structural choice that serves it would make the causal chain (goal → design decision) easier to audit at a glance. #### 🧑‍🤝‍🧑 Social learners - Present: the weekly demo-sync practice ("describe only what you shipped and learned, avoid industry takes") is itself a social learning mechanism the article describes. - Improve: no discussion prompt or comment thread is surfaced in the fetched content; LeadDev's site likely has comments, but they weren't part of html_content. #### 🧘‍♀️ Solitary learners - Present: the piece is structured as a single narrative reflection an individual reader can work through linearly, with explicit self-critique ("Ironically, the system sometimes makes agents stricter with themselves than necessary"). - Improve: a self-assessment checklist ("does your org have X, Y, Z?") at the end would let a solitary reader audit their own SDLC against the article's five goals without needing a team discussion. #### 🌿 Naturalistic learners - Present: no explicit sustainability or ecosystem-impact framing in the article. - Improve: not applicable to this source — the topic (internal engineering process design) doesn't naturally map to environmental or lifecycle themes; forcing a tie-in would be a stretch. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: the fetched HTML uses semantic `<p>`, `<li>`, and `<figure>/<figcaption>` elements consistently; bulleted "Key takeaways" use a proper `<li>` list rather than visual-only formatting. - Improve: the five embedded images use `<figure>` with `<figcaption>` for attribution ("Source: Daniel Kravets") but the fetched markup shows no descriptive `alt` text distinguishing what each diagram actually depicts — a screen reader user gets "image" plus a credit line, not the diagram's content. #### Keyboard navigation - Present: standard inline `<a href>` links throughout for citations, which are natively keyboard-focusable. - Improve: not assessable from static HTML content alone (no CSS/JS captured); a live-site audit would be needed to confirm focus order and visible focus states. #### Contrast and readability - Present: not assessable from html_content alone (no color/CSS captured in this fetch). - Improve: recommend a live-page contrast check against WCAG 2.2 AA's 4.5:1 minimum for body text, especially given LeadDev's registration-wall banner text at the top of the article. #### Text resizing and reflow - Present: not assessable from the fetched content (structural HTML only, no responsive layout data). - Improve: not applicable from this fetch; would require live-page testing at 200% zoom. #### Media and captions - Present: no audio or video content in this article — five static diagram images only, each with a text figcaption crediting the source. - Improve: as above, add descriptive alt text per diagram (what the diagram shows, not just who made it) so the visual argument is available without sight. #### Forms and interactions - Present: no interactive form elements in the article body itself (the "register a free account" prompt is a link, not a form). - Improve: not applicable — no forms present in the fetched content to assess. #### Standards reference - Gaps mapped to WCAG 2.2 AA: 1.1.1 Non-text Content (diagram alt text insufficient/absent), 1.4.3 Contrast (unverifiable from this fetch, flag for live-page check). No other criteria assessable from static content alone. ## 🌍 DEIB Assessment #### Cultural breadth - Present: single-organization, single-region (implicitly US-based, AWS/Terraform/US tooling references) case study; no multi-region or multilingual examples. - Improve: acknowledge that lane-based governance and CODEOWNERS enforcement assume a GitHub-centric, English-language tooling stack — teams outside that ecosystem would need translation of the pattern, not just the text. #### Inclusive language - Present: gender-neutral throughout ("engineers," "the agent," "a human"); technical jargon is mostly defined on first use. - Improve: a few terms (CODEOWNERS, egress, circuit breakers) are used without definition, assuming prior DevOps fluency — a glossary would widen accessibility to readers newer to the field, not just non-native English speakers. #### Neurodiversity support - Present: consistent heading structure, numbered/lettered lane and rule systems (Lane A–D, four subagents, four rubric principles) that chunk information predictably. - Improve: dense paragraphs (some 100+ words) mixing narrative and technical detail could be broken into shorter chunks with more subheadings for readers who benefit from more frequent visual anchoring. #### Representation - Present: the article centers a single first-person voice (a founding engineer); no other named contributors or perspectives are quoted. - Improve: the piece would benefit from at least one contrasting voice (e.g., a team that tried task-level builder/reviewer separation and found it too costly) to avoid presenting one startup's month-old experience as a settled industry direction. #### Psychological safety - Present: the author's transparent self-critique of the system's own flaws ("stricter with themselves than necessary," "we are not yet at the point where we are comfortable removing human eyes") models a psychologically safe way to discuss imperfect process design. - Improve: not applicable beyond what's present — the tone already invites disagreement rather than asserting the system as finished or beyond question. ## ✅ Logical Validity #### Strong reasoning - Causal reasoning, located in the PR-size/test-exemption section: the author traces a clear mechanism — if tests count toward the cap, agents will either under-test or split PRs, both worse outcomes than the cap's original goal — and proposes a structural fix (isolated test-designer subagent) rather than a rule change alone. This is strong because it identifies the actual incentive an agent responds to, not just the symptom. - Analogical reasoning, located in the monorepo section: comparing Vendict's approach to "Google runs this model at two billion lines of code... we run it at a tiny fraction of that, but the principle holds at any scale" is an appropriately scoped analogy — it borrows the structural principle (shared context ≠ shared responsibility) without overclaiming that Vendict's scale validates it the way Google's does. - Empirical grounding, located in the rubric section: the "verify before flagging" rule cites a concrete before/after metric (false-positive rate ~30% → ~10%), which is falsifiable and specific rather than a vague claim of improvement. #### Fallacies - Hasty generalization, located in the opening motivation section ("Frontier labs state openly that the majority of their code is AI-authored... That pace is no longer reserved for the largest companies... the magnitude is different, but the direction is the same"): a single cited statistic about Claude Code's self-authorship rate is used to imply a general industry direction applicable to a small TPRM startup, without establishing that the underlying conditions (an AI company building AI tools for itself) transfer to unrelated domains. Fix: qualify the claim explicitly as "suggestive of a trend among AI-native companies" rather than implying it as evidence for startups generally. - Appeal to authority (mild), located in "The data says otherwise," where a single external study is used to settle "whether to limit PR size" without naming the study's methodology, sample, or whether it examined AI-authored PRs specifically or PRs in general. Fix: name the study and its scope explicitly so readers can judge whether "defect detection drops from 87% to 28%" applies to the same context Vendict is generalizing it to. - Unfalsifiable-at-present claim, located in the conclusion's forecast ("The direction the industry is moving toward seems clear: humans review intent... while automation and AI reviewers increasingly cover the code itself"): presented as an observed trend but is explicitly the author's own prediction, not yet practiced even at Vendict ("For now, human review still includes code"). Fix: label it clearly as a forecast rather than a described-as-underway shift. #### Tone of voice - Reflective, practitioner-to-practitioner, and self-critical — e.g., "Ironically, the system sometimes makes agents stricter with themselves than necessary" and "we are not yet at the point where we are comfortable removing human eyes from the diff entirely." The tone consistently favors qualified, evidence-anchored claims over hype, and explicitly names what was left out of scope rather than implying the system is complete. ## 🛡️ DARVO Analysis - Not applicable to this source. This is a first-person technical practice essay about internal process redesign, with no accusation, conflict, or reputational defense at stake — there is no denial, attack, or victim-reversal pattern to analyze. The author's self-critical asides (e.g., acknowledging the PR-lane rule is "stricter than intended") are the opposite of DARVO: direct acknowledgment of a system's own shortcomings without deflection. ## 🎯 Conclusion - The article's bottom line: AGENTS.md-style file instructions were the first wave of context engineering and they worked, but they're a ceiling, not a foundation — the operational judgment an agent needs (what's done, what's off-limits, when to escalate) lives in the SDLC itself, not in a markdown file. Vendict's month-old rebuild — monorepo, three-lifecycle docs, four risk lanes, task-level builder/reviewer separation, a path-referenced standards layer, and a credential-scoped devcontainer — is offered as one concrete, adoptable instance of that principle, not a finished blueprint. - Practical next steps for readers: start with the cheapest, highest-leverage pieces named in the article — a strict current/future/permanent documentation split, and separating the reviewing agent's context from the implementing agent's context at the task level (not just requiring a different agent for PR review). Track defect root causes for a month before assuming code quality is the bottleneck; the article's central empirical claim is that most critical issues traced back to planning, not implementation, and that reprioritizes where engineering leaders should spend their standardization effort first. ## 🔄 Refactor Appendix — Your SDLC is your context engineering > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] SDLC is the agent's real context, not AGENTS.md > [!quote] ID:rw_sdlc-thesis > At Vendict, a lean third-party risk management (TPRM) startup, we rebuilt our engineering process around one thesis: in the agentic era, the SDLC is the context. **Context & use**: - Opening thesis statement of the article, following the critique of file-level context engineering. - Central claim the whole piece argues from — every subsequent structural choice (lanes, doc lifecycles, subagent separation) is presented as a consequence of this thesis. **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://01kzp1fhtrv7h8mnrdsnd6xbsy) <!-- atomicity: 1 idea ✓ --> #### [H2] Exempt tests from PR size caps to keep agent test coverage high > [!quote] ID:rw_test-exemption > Agents generate tests aggressively, which is exactly what we want. If tests count toward size pressure, the agent learns to either write fewer tests or split implementation from tests into separate PRs. Both outcomes are strictly worse than what the rule was trying to buy: fast review of a focused implementation diff. **Context & use**: - From the "three design choices that need explaining" section, choice #1. - Directly actionable rule for any team setting AI-agent PR size limits — a concrete counter-incentive to guard against when designing constraints for agents. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://01kzp1fhtrv7h8mnrdsnd6xbsy) <!-- atomicity: 1 idea ✓ --> #### [H3] Builder-reviewer separation must live at task level, not PR level > [!quote] ID:rw_builder-reviewer > Builder-reviewer separation has to live at the task level because a single agent session today can be the size of what used to be a full PR a couple of years ago. The human reviewer and CodeRabbit both read from the same canonical rubric in docs/standards/code-review-rubric.md. **Context & use**: - From design choice #2, following the description of the four-subagent plan-implementer skill (test designer, failure analyzer, verifier, linter). - The mechanism behind why "don't let the agent review its own code" advice needs to apply within a single session's sub-steps, not just across separate PRs. **Tags**: #xref **Highlight**: [view highlight](readwise://01kzp1fhtrv7h8mnrdsnd6xbsy) <!-- atomicity: 1 idea ✓ --> #### [H4] Stale docs are Medium severity, never Minor, in agent-heavy review > [!quote] ID:rw_docs-severity > Agentic development depends on docs being trustworthy. A stale doc is not a minor annoyance – it can mislead every future agent session that reads it. **Context & use**: - From the four rubric principles calibrated for agent-heavy review, principle #2. - Reusable review-policy rule: reframes documentation debt as a correctness risk multiplier once agents consume docs as ground truth. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://01kzp1fhtrv7h8mnrdsnd6xbsy) <!-- atomicity: 1 idea ✓ --> #### [H5] Critical issues trace back to planning, not code > [!quote] ID:rw_planning-root-cause > The key point, though, is that the critical issues we see come from insufficiently thoughtful planning and underspecified requirements. The real problem is not only how agents write code, but how clearly humans define the work before the code is written. **Context & use**: - Final substantive claim of the article, closing the "lessons of the first month" section. - The article's single strongest empirical takeaway — reframes where engineering-leadership attention should go when adopting AI agents. **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://01kzp1fhtrv7h8mnrdsnd6xbsy) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Agent judgment lives in process, not in instruction files **Claim** (one sentence, Courtney's voice): An AI coding agent's operational judgment — what counts as done, what's off-limits, when to escalate — comes from the SDLC it operates inside, not from any single instruction file, however well-written. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds when the agent has genuine autonomy over multi-step work (planning, testing, shipping) rather than single-shot code generation; breaks down for narrow, single-turn coding tasks where a good prompt or file genuinely is sufficient context. **Links** (≥1 with annotation): - [[Context engineering]] — because extends the file-level context-engineering concept into process-level design - [[Builder-reviewer separation]] — because applies-in the specific mechanism of task-level subagent isolation <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Check whether Post Formats for Block Themes or Post Kinds for IndieWeb's contributing docs could adopt a docs/ vs plans/ vs adr/ split to reduce stale-plan confusion for AI-assisted PRs — https://leaddev.com/software-quality/your-sdlc-is-your-context-engineering #xref - [F2] Cross-reference this article's "review throughput becomes the bottleneck" claim against any WordPress Core AI subteam notes on agent-assisted patch review capacity — #xref ### → Things 3 (max 2 actions) - [ ] Skim the article's linked DORA 2025 AI-assisted software development report for corroborating data on the "planning, not code" defect-source claim — research #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Your SDLC Is Your Context Engineering.md|Your SDLC Is Your Context Engineering by leaddev.com]] ## Highlights - At Vendict, a lean third-party risk management (TPRM) startup, we rebuilt our engineering process around one thesis: in the agentic era, the SDLC is the context. The same structure that lets 10 human engineers coordinate is what lets the 11th contributor – an [AI agent](https://leaddev.com/technical-direction/how-to-prepare-for-ai-agents) – operate reliably. ([View Highlight](https://read.readwise.io/read/01kzp24kg5jb4rfmjknynrvhtz)) - Note: Central thesis: the SDLC itself, not AGENTS.md, is the operational context an AI agent needs. - Tags: atom/literature/h1 - Agents generate tests aggressively, which is exactly what we want. If tests count toward size pressure, the agent learns to either write fewer tests or split implementation from tests into separate PRs. Both outcomes are strictly worse than what the rule was trying to buy: fast review of a focused implementation diff. So tests are excluded from the cap, and test design is handled by a separate subagent that has no line limit at all. ([View Highlight](https://read.readwise.io/read/01kzp24p6byhbmg1d7c0pdg84a)) - Note: Design choice #1: exempt tests from PR size caps to avoid perverse incentive against test coverage. - Tags: atom/literature/h2 - Builder-reviewer separation has to live at the task level because a single agent session today can be the size of what used to be a full PR a couple of years ago. The human reviewer and CodeRabbit both read from the same canonical rubric in docs/standards/code-review-rubric.md. The separation is grounded in the workflow, not in a rule that asks anyone to behave. ([View Highlight](https://read.readwise.io/read/01kzp24shw8rc9cyd0heyk3xqd)) - Note: Builder/reviewer separation must be enforced at task granularity, not just PR granularity. - Tags: atom/literature/h3 - Agentic development depends on docs being trustworthy. A stale doc is not a minor annoyance – it can mislead every future agent session that reads it. ([View Highlight](https://read.readwise.io/read/01kzp24wpy2xrgv1sch87pqw47)) - Note: Rubric principle: documentation inconsistencies are never "Minor" severity in agent-heavy review. - Tags: atom/literature/h4 - The key point, though, is that the critical issues we see come from insufficiently thoughtful planning and underspecified requirements. The real problem is not only how agents write code, but how clearly humans define the work before the code is written. ([View Highlight](https://read.readwise.io/read/01kzp24zg6k1jze64b03gmw6gq)) - Note: Headline empirical finding: critical issues trace to planning/specification, not code quality. - Tags: atom/literature/h5 ## Links - [[Spec-Driven Development Turns Throwaway Prompts Into Durable System Memory]] — existing Permanent captures the source's claim that reviewed specs preserve intent for future agent sessions. - [[Encoding What Good Looks Like Is What Makes Agent Verification Trustworthy]] — applies-in: the SDLC makes definitions of done executable across builders and checkers.