How 3 ADRs Changed Everything: The Spring PetClinic Proof

The Setup

I took Spring PetClinic — the canonical Spring Boot example app. 2,800+ stars. 43 contributors. 13 years of history. A codebase I've never touched.

Generated the same feature twice with OutcomeOps:

First time: No ADRs documenting their patterns
Second time: Added 3 ADRs, re-ingested the knowledge base

Zero changes to OutcomeOps. Zero prompt engineering. Zero customization.

The Results

Branch 12 — No ADRs

src/main/java/.../petclinic/
├── dto/
│   └── PetStatisticsDTO.java
├── service/
│   └── PetStatisticsService.java
├── controller/
│   └── PetStatisticsController.java
└── exception/
    └── StatisticsException.java

Generic Spring Boot. Layers everywhere. DTOs. Service classes. What every AI tool generates.

View Branch 12 →

Branch 13 — With 3 ADRs

src/main/java/.../petclinic/
└── stats/
    ├── PetStatistics.java
    ├── PetStatisticsController.java
    └── PetStatisticsControllerTests.java

Pure Spring PetClinic style. Domain packages. No service layer. Direct repository injection. What a maintainer would actually merge.

View Branch 13 →

See the Full Diff on GitHub

Every commit is atomic, reviewed, and merge-ready. Just like your best senior.

The 3 ADRs That Did It

Between Branch 12 and Branch 13, I added exactly three files:

docs/adr/ADR-003-controller-patterns.md

Controllers follow domain packaging (owner/, vet/, visit/)
Use @Controller not @RestController
Inject repositories directly - no service layer

docs/adr/ADR-005-domain-models.md

POJOs in domain packages, not DTOs
Return domain objects directly
JPA annotations on entities

docs/adr/ADR-006-testing-standards.md

Test classes named *Tests.java (plural!)
Integration tests in same package
@SpringBootTest for controller tests

Three markdown files. 200 words total. Complete transformation.

Look At The Execution Plans

Check the issues/ directory in each branch. OutcomeOps generates a plan before writing code.

Branch 12 Plan:

Step 1: Create DTO layer
Step 2: Create service layer
Step 3: Create controller with @RestController
Step 4: Create custom exception

Branch 13 Plan:

Step 1: Create domain POJO in stats package
Step 2: Create controller with @Controller
Step 3: Create integration tests (plural)

The AI literally changed its entire architecture based on 3 markdown files.

Why This Changes Everything

Every Other AI Tool:

• Generates the same generic patterns
• Requires custom prompts per project
• Needs fine-tuning for your conventions
• Still gets it wrong

OutcomeOps With Your ADRs:

• Reads your actual standards
• Adapts to each repository automatically
• No model training needed
• Gets it right the first time

This Is Context Engineering

I didn't make the AI smarter.

I made Spring PetClinic's patterns readable.

I didn't customize my platform.

I documented their conventions.

I didn't change my code.

I changed what the AI could see.

The Enterprise Implications

Your enterprise has hundreds of these patterns:

• "We always use Factory pattern for X"
• "Never put business logic in controllers"
• "All money calculations use BigDecimal"
• "Integration tests go in /integration not /test"

Right now they live in:

• Slack threads
• Wiki pages nobody reads
• Senior engineers' heads
• "You'll learn our way eventually"

With OutcomeOps, they become executable context. Every AI-generated PR follows YOUR standards from day one.

Try It Yourself

Compare the branches:

Branch 12 — Generic Spring Boot Branch 13 — Spring PetClinic style

Look at:

• Directory structure
• Class naming
• Test conventions
• The execution plans in issues/

Same user story. Same platform. Three ADRs made the difference.

The Bottom Line

Copilot will never learn your patterns.

Cursor can't read your ADRs.

ChatGPT doesn't know your architecture.

OutcomeOps does. Because you document it, and documentation becomes intelligence.

This isn't the future. This is running in production at Fortune 500 scale today.

See It Work With YOUR Patterns

The Spring PetClinic experiment proves the concept. Now imagine it with:

• Your naming conventions
• Your architectural patterns
• Your compliance requirements
• Your 20 years of accumulated wisdom

All becoming executable context. All making AI write code the way YOU write code.

Book an Enterprise Briefing

Because with the right context, your best engineers already wrote it.

Note: The branches shown are public for examination. OutcomeOps itself is enterprise software deployed in your AWS environment. Learn more about enterprise engagements.