Layer 3: Software Foundations

Foundations

The engineering principles that make AI systems reliable, maintainable, and production-ready. Timeless patterns that existed before the current AI wave and will endure after the tools change.


Related paths: This page covers timeless software engineering principles (SOLID, Clean Architecture, DDD, testing, deployment) that apply to AI systems. If you want a conceptual overview of how the wiki organizes AI system components into layers (Applications, Orchestration, Models, Data, Infrastructure), see The Five Layers of AI Systems instead. Choose Foundations if you want to learn engineering principles; choose Layers if you want a map of the AI stack.


Every era of software produces new tools, new frameworks, and new paradigms. The tools change on a cycle of years. The underlying principles change on a cycle of decades, if they change at all.

The principles collected here - SOLID, Clean Architecture, Domain-Driven Design, the testing pyramid, continuous delivery, and the rest - were formalized in the late 1990s and early 2000s. They emerged from practitioners who had spent careers building systems that failed in predictable ways: components too tightly coupled to change, business rules buried in frameworks, test suites that gave false confidence, deployments that required coordination across teams. These principles are the distillation of those failures.

The current AI development environment creates the same pressures in new forms. A system built on a single LLM provider with prompt logic scattered throughout application code, no evaluation harness, and no deployment strategy is not an AI-first system - it is a prototype with the same structural problems that have caused software failures since the 1970s.

Understanding these foundations is what separates a working prototype from a system that can be maintained, extended, and trusted in production. None of the principles here are specific to AI. All of them apply directly to it.

Engineering Foundations

These are not our opinion of what matters. Each is a widely-adopted software engineering standard formalized by a named author or organization. The source and year are on every card; open one for the full reference, examples, and how it applies to AI systems.

SOLID Principles

Robert C. Martin, 2000

Five object-oriented design rules that keep code easy to change as requirements grow, instead of rotting into something rigid and fragile.

Clean Architecture

Robert C. Martin, 2017

Keeps business logic independent of frameworks, databases, and UI, so the parts that change most never destabilize the core of the system.

Design Patterns

Gang of Four, 1994

A shared vocabulary of 23 proven solutions to recurring design problems, so teams can name and reuse structure instead of reinventing it.

Domain-Driven Design

Eric Evans, 2003

Aligns code structure and language with the business domain through bounded contexts, so complex systems stay coherent as they grow.

Testing Strategy

Beck 2002, Cohn 2009

The testing pyramid and test-driven development: automated proof that code does what it should, with fast feedback the moment it does not.

Continuous Integration and Delivery

Humble & Farley, 2010

Automated build, test, and deploy that keeps software releasable at all times, turning risky big releases into small routine ones.

API Design

Fielding (REST), 2000

REST, GraphQL, and gRPC, plus versioning and error handling, so an API stays a reliable contract for its callers as it evolves.

Security Fundamentals

OWASP, since 2003

Authentication, authorization, encryption, and the OWASP Top 10: security treated as a design property, not a late add-on.

Well-Architected Framework

AWS, 2015

A structured review against reliability, security, cost, performance, and operational excellence: closing the gap between "it works" and "it is production-ready".