How I use AI agents to write code 🔗 **Source:** [How I use AI agents to write code](https://nolanlawson.com/2025/12/22/how-i-use-ai-agents-to-write-code/) > [!note]+ Document Notes > tags: [AI, coding, developer-tools] > author: Read the Tea Leaves > source: nolanlawson.com > reference: [https://nolanlawson.com/2025/12/22/how-i-use-ai-agents-to-write-code/] > date created: 2025-12-26 12:00 > > # 🏷️ Title: How I use AI agents to write code > <!-- 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 - Include links cited in or relevant to the article. ## 📝 Summary - The author, a former AI skeptic, now relies heavily on coding agents (especially Claude Code) to write large amounts of production code. - It matters because it illustrates a pragmatic, test-centric workflow for pairing human judgment with AI automation. - Stakeholders: professional developers, teams adopting AI tools, OSS maintainers, and tool vendors. - Risks: brittle automation, subtle bugs, code duplication, reduced fun/ownership, privacy/security of codebases, work-life boundary erosion. - Bottom line: AI coding agents “work” enough that they’re becoming the default, but must be constrained with tests, specs, and human review. ## 📖 Main Content - The author admits he “used to be a fairly hard-line anti-AI zealot” but AI coding tools now routinely outperform him on many tasks despite 20 years’ experience. - He primarily uses Claude Code with a strong **CLAUDE.md** / **AGENTS.md**: one file for project architecture and landmines, another for his personal coding preferences. This gives the agent context similar to onboarding a new teammate. - His **overall strategy** centers on: - Automated tests as a feedback loop so the agent can iterate toward passing behavior. - “Plan mode” for complex changes, forcing the agent to outline steps before editing. - Avoiding UI work for now, given token costs and clumsy DOM interaction. - He calls out recurring AI mistakes: deleting meaningful comments, duplicating code, and introducing subtle behavioral changes during refactors. To counter this, he often spins up a **second, fresh AI session** to diff against the main branch and review for unintended changes. - He exploits the agent’s tirelessness to let it iterate on problems while he’s off the clock, but notes “automation blindness” when approving many small actions and concerns about running agents in “yolo mode” with broad permissions. - He distinguishes between **proprietary work**, where he uses AI extensively, and **open-source work**, where he avoids AI because it feels inauthentic to publish code he didn’t really write. - Ultimately, he sees himself moving toward a **software architect**-like role—writing specs and reviewing AI-generated code more than typing every line himself—while remaining emotionally ambivalent about this shift. ### 🗒️ Notes - “Some people really find LLMs distasteful… I used to be a fairly hard-line anti-AI zealot” → strong acknowledgment of critics, but framed against direct experience of productivity gains. - AI as “a finely-honed kitchen knife attached to a chainsaw” captures both its power and potential for harm if misused. - **CLAUDE.md / AGENTS.md**: - Project file: describes architecture, stable/unstable areas, dragons, and design intent, so the agent isn’t “coming in fresh to the project every time.” - Personal file: encodes his quirks (e.g., preferring `_` as a `map`/`filter` variable) so the agent matches his style. - **Feedback loops & planning**: - Automated tests convert vague “it should work” into pass/fail signals the agent can optimize against. - Example: a “performance improvement” to a SQL query that initially *slowed* things down; only benchmarking + `EXPLAIN` exposed the regression, prompting multiple iterations. - **Why agents struggle with UI**: - DOM inspection consumes many tokens or requires slow Playwright scripts/screenshots. - He’s seen agents fumble basic UI tasks like closing a modal, making them poor fits for fast interactive UI changes. - **AI mistakes & meta-AI review**: - Tendency to delete or sanitize “hack” comments loses important tribal knowledge. - Code duplication suggests a lack of DRY awareness. - Seemingly harmless null checks or refactor tweaks can alter logic. - Mitigation: new session, diff vs `origin/main`, and an explicit request to check whether a supposed “pure refactor” changed behavior. - He notes this works better if the reviewer-agent doesn’t “know” the code is his, to avoid flattery bias. - **Background automation & work-life friction**: - He uses Claude Code as a night-shift clone that attempts many variants while he sleeps. - Sometimes he wakes up to useless tangents and hard-resets the repo. - Permission prompts on every action lead to rubber-stamp approvals, pushing him to experiment with a more permissive containerized “yolo mode” for low-stakes side projects. - **Ethics, ownership, and fun**: - He refuses to use AI for OSS because he doesn’t feel genuine ownership and is uncomfortable putting his name on AI-written code. - He compares LLMs to a “boring but optimal” exploit in a game—players (and coders) use it even if it reduces enjoyment. - **Conclusion stance**: - He remains ambivalent, saying he might still choose a world without LLMs, but concedes that “I write an insane amount of code these days… and this would have been impossible before LLMs.” - Views AI as pushing him into an architect/spec-writer/reviewer role while delegating more implementation details to agents. ## 📚 References - Original article: **How I use AI agents to write code** — Nolan Lawson / Read the Tea Leaves (nolanlawson.com) - Anthropic Claude Code (coding agent IDE integration) - Concepts referenced: automated testing, SQL `EXPLAIN`, Playwright, Podman, DRY principle ## 🗣️ Paraphrase - A: The author used to strongly oppose AI coding tools, but after watching them outperform him and colleagues in many routine coding tasks, he now relies on them—especially Claude Code—while insisting on strong project documentation and automated tests so they don’t destroy the codebase. - B: He uses AI to iterate on problems, review its own mistakes, and free himself for higher-level design and specs, yet he refuses to apply it to open-source work and still feels uneasy that the most efficient strategy (LLMs) is also less personally satisfying. ## 📰 Newsletter In this week’s WordPress-adjacent reading, Nolan Lawson walks through how AI coding agents have reshaped his day-to-day development. While his stack isn’t WP-specific, the patterns map cleanly to modern plugin and theme work: define a clear AGENTS.md for your project, lean on test suites as your guardrails, and treat AI as a relentless junior dev that never tires of refactoring and benchmarking. For WordPress builders flirting with AI-assisted coding, this article is a pragmatic companion to tools like: - GitHub Copilot, Codeium, and Claude Code-style agents for PHP/JS. - WP-CLI-based test and migration scripts you can let agents iterate on. - Playwright or Cypress end-to-end tests wrapping Gutenberg and front-end flows. It’s a useful reality check: AI can massively boost throughput, but only if you invest in specs, tests, and review habits that keep your repos from turning into an inscrutable, duplicated mess. ## ✅ Action Items #### DevRel - Plan live demos showing AI agents refactoring WordPress plugins with test suites guarding behavior. - Create workshops on writing CLAUDE.md/AGENTS.md-style context docs for WP projects. - Publish quickstarts and templates for integrating AI agents into common WP dev flows (plugins, themes, block editor). - Track developer sentiment and usage via surveys, office hours, and funnel analytics. - Moderate community spaces to share AI “gotchas” and safe patterns. #### OSPO - Draft or update policies around AI-generated code in company and open-source projects. - Clarify license and provenance requirements when AI contributes to GPLv2+ WordPress-related code. - Integrate AI usage into security and vulnerability management playbooks. - Capture AI-assisted contributions in SBOMs and internal inventories. - Support devs with guardrails and legal guidance on AI usage and disclosure norms. #### Community - Host clinics for maintainers on reviewing AI-generated PRs and spotting subtle refactor bugs. - Run contributor onboarding that explicitly covers when AI assistance is encouraged vs discouraged. - Encourage sponsors to fund testing infrastructure and CI/CD improvements that make safe AI use possible. - Coordinate cross-project incident drills for AI-caused regressions and rollbacks. #### WordPress - **Core:** Evaluate where AI agents can safely propose patches guarded by existing test suites. - **Core Performance:** Use agents to generate performance experiment variants, but require benchmarks and metrics dashboards. - **Core AI:** Define responsible AI guidelines, evaluation sets, and pilot integrations for core and Gutenberg. - **Core Program Team:** Align release processes with AI-assisted workflows and review patterns. - **Mobile:** Explore AI help for UI tests and boilerplate code while keeping manual UX judgment central. - **Playground:** Offer AI-powered lab recipes to reproduce bugs and experiment with patches in-browser. - **Community:** Provide meetups and WordCamps with AI coding sessions and hands-on labs. - **Training:** Ship lesson plans on AI-assisted plugin/theme development and safe practices. - **Marketing:** Tell honest stories about productivity plus pitfalls, not hype alone. - **Support:** Update docs and SLAs to address AI-caused issues and debugging guidance. - **Design:** Keep humans in charge of UX, with AI limited to code-level changes vetted by designers. - **Documentation:** Maintain clear style guides so AI-generated docs remain consistent and comprehensible. - **Photos / TV / Polyglots:** Clarify AI content policies; encourage disclosure and human review. - **Accessibility:** Ensure AI tooling and outcomes respect WCAG; don’t let agents silently introduce a11y regressions. - **Meta / CLI / Hosting / Tide / Openverse / Themes / Plugins:** Integrate AI where tests and review can control risk, and document expectations around provenance and security. #### The WPOCC - Pilot fellowships for maintainers experimenting with AI-assisted workflows in the open. - Fund documentation sprints on AI usage patterns, review practices, and ethics. - Explore grant programs tied to testing, CI, and infrastructure that make responsible AI use feasible. ### FAIR - Encourage technically independent verification of AI-generated code (local tools, signatures, provenance). - Codify transparent funding and governance around AI infrastructure in the WP ecosystem. - Turn policies into reusable governance artifacts projects can adopt or adapt. ## 🧪 Hypotheses - H1: Providing AI agents with project- and developer-specific configuration files (CLAUDE.md) significantly improves code quality and reduces regressions. - H2: AI coding agents are more effective on well-specified, test-covered backend tasks than on interactive UI tasks. - H3: Using a second AI agent as a reviewer for AI-generated diffs reduces subtle behavioral bugs compared to human review alone under time pressure. - H4: Heavy reliance on AI agents increases throughput but reduces developers’ subjective enjoyment and sense of ownership over code. - H5: Developers are less willing to use AI for open-source contributions than for proprietary, employer-owned code. ### 📊 Methodology - For H1: Run controlled experiments across teams with and without structured AGENTS.md files; compare defect rates and review feedback. - For H2: Log success rates, time-to-completion, and bug counts for AI-assisted backend vs UI tasks under similar constraints. - For H3: A/B test review pipelines (human-only vs human+AI-reviewer) and measure post-merge incidents and rollbacks. - For H4: Survey developers in AI-heavy vs AI-light teams; correlate usage patterns with self-reported enjoyment and burnout metrics. - For H5: Analyze commit histories and survey OSS vs proprietary devs about AI usage, disclosure, and comfort levels. ### ❓ Questions - Where is the threshold where AI agents cause more harm than good without extensive test coverage? - How should contributors disclose AI assistance in open-source projects, especially under copyleft licenses? - What governance do teams need before granting AI agents broad filesystem and network access? - How will long-term use of AI agents affect developers’ skills and career trajectories? ### 🔮 Future Research - Better human-agent interaction models that reduce prompt fatigue and automation blindness. - Lightweight UI inspection tools optimized for agents to work on front-ends without huge token costs. - Economic and psychological impacts of shifting developers toward architect/spec roles. - Community norms for AI-generated contributions in large ecosystems (e.g., WordPress, Linux). ### 💡 Implications - **Practice:** Teams should invest in tests, architecture docs, and review workflows before scaling AI use. - **Policy:** Organizations and OSS communities must clarify rules about AI-generated code, attribution, and licensing. - **Security:** AI agents with broad local access create new exfiltration and supply-chain risks. - **Education:** Curricula should teach devs to orchestrate and critique AI work, not just write code themselves. - **Funding:** Supporting infrastructure (CI, tests, tools) becomes a key leverage point for safe AI adoption. ### 🧠 Learning Styles Assessment - **Reading level estimate:** Roughly upper high-school to early college (Flesch-Kincaid style; mixed short/long sentences, technical vocabulary but conversational tone). #### 👀 Visual learners - Present: Mental images (chainsaw/knife, sorcerer’s apprentices) but few actual visuals. - Improve: Add diagrams of AI workflows, before/after diffs, and data flow charts for agent interactions. #### 🔊 Aural learners - Present: None intrinsic. - Improve: Offer an audio narration or short podcast-style summary. #### 🗣️ Verbal learners - Present: Strong analogies, clear definitions, opinionated examples. - Improve: Add a concise glossary for AI-agent jargon and patterns. #### 🧩 Kinesthetic learners - Present: Implicit: suggestions to try CLAUDE.md, tests, etc. - Improve: Provide step-by-step exercises to set up an agent workflow in a sample repo. #### 🧠 Logical learners - Present: Causal reasoning around tests, benchmarks, and agent limitations. - Improve: Include simple tables comparing tasks (backend vs UI) and outcomes. #### 🧑‍🤝‍🧑 Social learners - Present: Framed as peer experience a developer might discuss with colleagues. - Improve: Add discussion prompts for teams considering AI adoption. #### 🧘‍♀️ Solitary learners - Present: Reflective sections on ambivalence and ethics. - Improve: Include explicit reflection questions and journaling prompts. #### 🌿 Naturalistic learners - Present: None. - Improve: Use ecosystem or environmental analogies for tooling and governance. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Standard blog headings and paragraphs (typical for personal blogs). - Improve: Ensure heading hierarchy is strict and all meaningful images (if any) have descriptive alt text. #### Keyboard navigation - Present: Likely fine (simple article layout). - Improve: Confirm focus indicators and skip links for site navigation. #### Contrast and readability - Present: Dependent on site theme; likely adequate but unverified. - Improve: Ensure at least 4.5:1 contrast, generous line spacing, and readable font sizes. #### Text resizing and reflow - Present: Likely responsive layout. - Improve: Test at 200% zoom and with prefers-reduced-motion settings. #### Media and captions - Present: Primarily text; no captioned media needed. - Improve: Provide downloadable or printer-friendly versions. #### Forms and interactions - Present: Minimal interaction (typical blog). - Improve: If comments exist, ensure accessible labels, error messages, and tap targets. #### Standards reference - Map improvements against WCAG 2.2 AA (1.4.x for contrast, 2.4.x for navigation, 1.3.x for structure). ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focused on Western tech culture and AI discourse. - Improve: Include experiences from more regions and backgrounds of developers. #### Inclusive language - Present: Mostly gender-neutral, conversational English. - Improve: Avoid niche idioms; add short summaries in plainer language. #### Neurodiversity support - Present: Logical structure, but long paragraphs in places. - Improve: More subheadings, bullet lists, and consistent patterning of examples. #### Representation - Present: Single-author anecdote from one vantage point. - Improve: Cite or link to opinions from a wider range of developers. #### Psychological safety - Present: Acknowledges critics respectfully; no shaming of alternative choices. - Improve: Offer explicit permission for readers to opt out of AI and still be “real” developers. ### ✅ Logical Validity #### Strong reasoning - Uses causal reasoning: no tests → AI can confidently produce broken or slower code; tests/benchmarks → clear feedback loop. - Uses analogy effectively: AI agents likened to a powerful but dangerous tool, and optimal-but-boring game exploits, explaining why he uses them despite reduced fun. #### Fallacies - Some generalizations about “the vast majority of developers” making peace with AI are asserted without evidence; could be tempered with “many” or backed by surveys. - Personal experience is heavily used; it’s strong as anecdote but should not be treated as broad empirical proof. #### Tone of voice - Wry, self-deprecating, and conversational (“write everything myself like a Neanderthal”). - Pragmatic rather than evangelical; acknowledges tensions and discomforts openly. ### 🛡️ DARVO Analysis - **Deny:** The author does not deny AI risks; he explicitly calls agents “dumb” in many ways and documents their mistakes. - **Attack:** He does not attack AI critics; he notes their arguments resonate with him. - **Reverse victim/offender:** No attempt to present himself as a victim of critics; instead he frames himself as reluctantly adapting to a shifting landscape. - Overall, the piece is not engaged in DARVO; it’s an introspective narrative about changing one’s own mind. ## 🎯 Conclusion The article argues that, despite real flaws and personal misgivings, AI coding agents already provide enough practical value that many experienced developers will keep using them. The safest and most productive path is to pair agents with strong tests, clear specs, and human review, while drawing ethical boundaries (such as in open-source work) and accepting a gradual shift from pure coding toward architecture and oversight. ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] AI coding agents reshape developer workflows > [!quote] [How I use AI agents to write code](https://nolanlawson.com/2025/12/22/how-i-use-ai-agents-to-write-code/) by [[Read the Tea Leaves]] via [[nolanlawson.com]]. Published 2025-12-23. Accessed 2025-12-26. > “I write an insane amount of code these days in a very short number of hours, and this would have been impossible before LLMs.” Two lines: context and use. Cite data if relevant. [view highlight](https://nolanlawson.com/2025/12/22/how-i-use-ai-agents-to-write-code/#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] Structured context files improve AI code output > [!quote] [How I use AI agents to write code](https://nolanlawson.com/2025/12/22/how-i-use-ai-agents-to-write-code/) > “First off, you need a good CLAUDE.md (or AGENTS.md).” Two lines: context and use. [view highlight](https://nolanlawson.com/2025/12/22/how-i-use-ai-agents-to-write-code/#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] Coding agents need tests to be reliable - Agents perform best when guarded by automated tests and benchmarks that give immediate feedback on regressions. - Links: [[AI-Agents]] [[Software-Testing]] #### [Z2] Developers feel uneasy using AI for open-source - Some devs avoid AI in OSS because they don’t feel true ownership over AI-generated code. - Links: [[Open-Source-Ethics]] [[AI-Generated-Code]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Draft a CLAUDE.md template for WordPress plugin projects — context/https://nolanlawson.com/2025/12/22/how-i-use-ai-agents-to-write-code/ #fleeting #inbox - [F2] Experiment with AI-as-reviewer for AI-generated PRs in a test repo — context/https://nolanlawson.com/2025/12/22/how-i-use-ai-agents-to-write-code/ #fleeting #inbox - [F3] Write guidelines on AI usage in open-source WordPress plugins — context/https://nolanlawson.com/2025/12/22/how-i-use-ai-agents-to-write-code/ #fleeting #inbox --- <!-- deep-read:sections end -->