AI-First Development Adoption for a Web Agency

Before introducing any AI tooling, I needed to make the codebase safe for faster iteration. This meant the foundational work that everything else depends on.

I built a CI/CD pipeline from scratch on GitHub Actions. A single workflow runs static analysis first, then the full test suite. It runs on every push to master and every pull request. If static analysis fails, the tests don't even start. The pipeline uses a prebuilt Docker image (published to GHCR) with the entire toolchain, so there's no runtime setup and execution is fast and reproducible.

I also containerized the local development environment. The same Docker image that runs in CI can run locally. This eliminated the "works on my machine" problem and gave coding agents a consistent environment to work against.

For code quality, I introduced automated style enforcement, frontend formatting, and commit message conventions with a git hook that validates the format. Consistent formatting keeps AI-generated diffs reviewable, while conventional commits make the git history easier for developers and agents to follow.

Before agents could contribute meaningfully, the repository itself needed to become agent-friendly. I consolidated scattered test files into a centralized suite, removed pervasive git submodule usage that fragmented the codebase, and gathered documentation into discoverable locations.

The existing tests had issues of their own. Some were fragile, others were skipped, a few actively prevented the suite from running. I fixed broken tests, removed unreliable ones, and organized the suite into groups (fast vs slow, with vs without external calls) so developers could run the relevant subset quickly.

I then added Playwright for end-to-end testing. The platform is a WordPress multisite, which makes E2E testing non-trivial: you need a running instance with actual data. So I built a composable seed system. Each seed module (base data, appointments, vehicles, notifications) declares its dependencies, and a registry resolves them topologically. A CLI command creates an ephemeral test instance, seeds it with exactly the data a test scenario needs, runs the test, and tears everything down. This makes E2E tests deterministic and isolated.

With the safety net in place, I introduced Claude Code into the workflow. I wrote 17 agent skills that document the codebase architecture, plugin structure, testing conventions, and CI pipeline. These skills give the agent enough context to make meaningful contributions without needing a human to explain the project from scratch each time.

I configured an automated code review workflow on GitHub: when a PR gets a specific label, Claude Code reviews the diff with full project context. I also set up CodeRabbit for surface-level review on all PRs.

Coding agents can read code efficiently, but they can't read minds. The things that cause the most problems are the unwritten rules: business logic that lives in someone's head, compliance constraints, formatting preferences, domain context that explains why the code is shaped a certain way. If you want agents to be precise and avoid hallucinations, you have to write all of that down.

I built a structured knowledge base as 17 agent skills covering the codebase architecture, plugin structure, testing conventions, CI pipeline, booking system logic and domain-specific rules. Each skill gives agents project-specific context before they touch any code.

I also created a "self-learning" skill that prompts the agent to capture new knowledge after every significant interaction. It updates the skill files so the next session starts with what the previous one learned.

Developers became more comfortable reviewing generated code once they could see which project rules the agent had read first. Knowing that the agent understood the project's conventions and constraints made its output feel less like a gamble.

The infrastructure only helped once the team was willing to use it. Code blockers were easier to identify than the doubts that kept individual developers from changing their workflow.

I ran team training sessions on how coding agents work, where they fail, and how the new infrastructure catches mistakes. The most useful work happened one-on-one, where I could understand each developer's concerns.

Some developers needed to see CI catch an agent's mistake. Others needed help setting up a useful first session or understanding where their judgment still mattered. I addressed those concerns separately instead of treating resistance as a single team-wide problem.