Website of Peter Westerman

At some point in any substantial AI-assisted practice, you face a choice between two ways to spend your time: keep building output, or step back and build infrastructure. Infrastructure does not produce immediate deliverables. It does not show up in a product inventory or generate client value directly. But infrastructure multiplies everything that comes after it — and in an AI-assisted practice, the multiplier effect of good infrastructure is unusually large because AI systems are exceptionally good at leveraging well-built context, templates, and reusable components.

In the portfolio documented in this series, three pieces of infrastructure were built: the Shared Library of reusable code components, the Agent System of specialist AI advisors, and the Personalized Coding Playbook capturing accumulated learning. Each took real time and effort. Each produced a return that substantially exceeded the investment. And each was built later than it should have been — which is the most important thing to understand about infrastructure investment timing.

The Shared Library

The Shared Library is the centralized collection of components that are used across multiple products. It includes the Claude API client, Tavily web search client, and Pinecone vector database client as tested, documented, and generalized PHP classes. It includes a WordPress database base class providing standard CRUD operations, table management, and query utilities. It includes a patterns library documenting the architectural patterns that appear repeatedly across the portfolio. It includes project templates for starting new products with the right foundation already in place.

The catalog of the library documents the impact precisely: Claude API went from six-plus independent implementations to one, with a seventy percent code reduction. Tavily from seven-plus to one, sixty percent reduction. Pinecone from five-plus to one, sixty percent. Database base class from four-plus to one, fifty percent. Overall code reduction across these component categories: fifty to seventy percent.

The time impact on new products was immediately visible and dramatic: a standard WordPress plugin with Claude API integration, database operations, and admin UI went from approximately two weeks of directed work to three days. A seventy percent reduction in standard build time came entirely from having reusable components to assemble rather than building from first principles. This improvement did not require any increase in AI capability — it required having built the shared infrastructure that made assembly possible.

The maintenance impact compounds over time: every bug fix to a shared component propagates automatically to all products using it. Every API update — which previously required separate fixes in six or seven places — now requires one fix that applies everywhere. The ongoing maintenance cost of a twenty-product portfolio was dramatically reduced by the library, not through any single large change but through the accumulation of hundreds of avoided separate maintenance events.

The Agent System

The Agent System is a tiered structure of specialist AI agents, each with a defined role, pre-loaded specialist context, and handoff protocols for routing complex tasks to the right specialist.

The Orchestrator routes incoming tasks. The Architecture Agent handles system design with context loaded from all previous architectural decisions in the portfolio. The API Integration Agent handles external service connections with knowledge of every existing integration and the shared library clients. The Database Agent handles data modeling and query optimization with knowledge of existing schemas. The QA Agent handles debugging and testing with awareness of common failure modes across the portfolio. The Documentation Agent handles context file updates and Playbook maintenance.

The value of the Agent System differs from the Shared Library. The library provides reusable code. The Agent System provides reusable expertise — deep, stable, pre-loaded specialist context that makes specialist tasks start from an expert baseline rather than from a general starting point. A debugging session with the QA Agent immediately engages with the specific problem at an expert level, without any re-establishment of what the common failure modes are or what the debugging approach should be. That context was loaded when the agent was built and remains current because the agent profile is maintained when patterns change.

The time saving per specialist session is ten to fifteen minutes of avoided re-establishment overhead. More important is the quality improvement: specialist agents with stable deep context produce more consistent, better-calibrated outputs on complex specialist tasks than general sessions working from session-specific re-establishment. The architectural coherence of the codebase improved measurably after the Architecture Agent was in place, because design decisions were evaluated against a consistent framework rather than rebuilt from first principles each time.

The Coding Playbook

The Personalized Coding Playbook is a living cross-project reference that captures the accumulated learning of the entire practice: the standard technology stack, architectural patterns and their rationale, coding conventions that apply across all products, common solutions to recurring problems, integration patterns for each external service, testing and debugging approaches, and deployment patterns.

Version one was organized as a learning document — thorough and useful but optimized for human comprehension rather than AI reference. Version two was reorganized specifically for how AI systems use reference material during sessions: conventions stated before explanations, code examples before prose, explicit cross-references to products implementing each pattern, decision records capturing the reasoning behind non-obvious choices. The reorganization for AI reference rather than human reading changed the practical value of the document substantially — not because the content changed but because the organization made it faster and more reliable to use.

The measurable impact of V2: sessions using V2 as context produced first-pass output with fewer deviations from established conventions. The AI could look up conventions more efficiently, which meant it applied them more consistently. The documentation investment became directly visible in output quality improvement.

When to Build Infrastructure

The consistent lesson across all three infrastructure types: build earlier than feels necessary, and build incrementally from the beginning.

The project context file should be created on day one of any new project — even if it has only three sentences. The shared component should exist after the second implementation, not the seventh. The specialist agent profile should be created when a task type appears for the third time, not the thirtieth. The Playbook entry for a pattern should be written the first time the pattern is established, not when there are enough patterns to justify starting the Playbook.

Each of these feels premature when the moment arrives. The context file feels unnecessary when the project is new. The shared component feels like over-engineering when you have only built it twice. The specialist agent feels like overhead when you could just handle the task in the current session. The Playbook entry feels like busywork when there is building to do. These feelings are systematically wrong. The infrastructure consistently pays back faster than it feels like it will, and the cost of building it early is always lower than the cost of building it late — because late means building on top of accumulated debt rather than on a clean foundation.

Thinking in Systems About Your Own Workflow

The meta-lesson from this infrastructure-building experience is about developing a systems perspective on your own practice. Most professionals optimize locally most of the time: they make the best decision for the current task, the current session, the current project. Local optimization is natural and often correct. But it systematically underinvests in global infrastructure — the stuff that makes all future work better but doesn’t produce anything directly in the current moment.

Global optimization requires periodically asking: what am I repeatedly rebuilding that I have already built? What infrastructure would make the next ten projects faster than the last ten? What knowledge, currently living only in my head or in chat transcripts, should be captured in a form that compounds its value rather than decaying?

In an AI-augmented practice, the return on global infrastructure investment is unusually high because AI systems are designed to leverage structured, accessible reference material. A well-maintained context file improves every session. A shared component library improves every product. A Playbook with well-organized reference content improves every new project start. The leverage available from these investments is not available from the same time investment in direct production work — direct production work produces one thing; infrastructure investment multiplies everything that comes after it.

The Infrastructure Investment That Was Missing: Automated Testing

One piece of infrastructure that was notably absent from the portfolio documented in this series: automated testing. All twenty products rely on manual testing — the practitioner walks through user scenarios after each session and verifies the behavior. This is effective for catching obvious failures but misses regression testing: verifying that a change in one area of the codebase did not inadvertently break something in another area.

In a portfolio of twenty products with a shared library, a change to the shared library could theoretically affect any of the twenty products that use it. Manual testing catches regressions in the product being actively worked on; it does not systematically test the other nineteen products every time the shared library changes. Automated tests would catch regressions wherever they occur, regardless of which product is currently active.

This is a gap in the infrastructure documented in this series — acknowledged explicitly because the series commits to honesty about both what worked and what was missing. Automated test coverage for the shared library, at minimum, is the infrastructure investment that was most conspicuously absent. It remains on the “should be built” list rather than the “has been built” list. The lesson: infrastructure is not just the things you built — it is also the things you should have built and did not. The debt register concept applies to infrastructure gaps as much as to code quality gaps.

How to Start When You Have Nothing

The infrastructure described in this post — Shared Library, Agent System, Coding Playbook — may feel overwhelming as a starting point. It wasn’t built all at once. It was built incrementally over twelve months, each piece at the point when the evidence for its value was sufficient to justify the investment.

The starting point for any new practice is not the full infrastructure. It is the context file. Create a context file for the first project. Update it after every session. That one discipline, consistently applied, produces compounding returns from the very first session and builds the habit of context maintenance that supports all the other infrastructure investments as they become appropriate.

The next investment is the component registry — the simple document listing components that have been built. When a component appears twice, the registry triggers the generalization decision. The registry costs nothing to maintain and prevents the most expensive form of technical debt in any fast-moving practice.

After the context file and component registry are established habits, the fuller infrastructure — specialist agent profiles, comprehensive playbook, project templates — can be built as the evidence for their value accumulates. Each piece earns its place in the infrastructure through demonstrated need, not through theoretical completeness. That evidence-driven infrastructure building is itself a practice worth establishing: build what the work requires, when it requires it, rather than building comprehensive infrastructure before you have proven the need.

How Recent AI Innovations Change This Picture

The shared library infrastructure described in this post was built through significant manual effort — retrospective consolidation of patterns that had been duplicated across products. AI platform innovations now provide formal infrastructure support for exactly this kind of shared knowledge architecture, which would have substantially reduced the time required to build it.

Agent Skills are the platform-native version of the shared library concept. Where this case study built custom CLAUDE.md files, documentation folders, and context loading procedures, Agent Skills provide a standardized structure for the same content: reusable instructions, scripts, templates, and resources organized into portable, composable units. An organization building a shared library today would build it as a set of Agent Skills rather than as custom markdown documentation.

The composability of Agent Skills is particularly relevant for the shared library architecture described here. The original shared library had distinct domains — authentication patterns, database patterns, API integration patterns, UI component patterns — that sometimes needed to be combined and sometimes loaded independently. Agent Skills can be composed together, loading only what is needed for a specific task without loading the entire library for every session. The infrastructure becomes more targeted and more efficient.

MCP as infrastructure changes the scope of what the shared library can reference. The original shared library was code and documentation — static artifacts. MCP-connected infrastructure can include live connections to databases, APIs, and external services that the shared library describes. An authentication pattern in the shared library can reference the live identity provider’s current API specification. A database pattern can reference the live schema. The shared library becomes a living reference, not a static document.