The Bigger Picture: Strategy, Design, Systems and DevOps

Building with AI is easy to get started with. A conversation, a prompt, a result. It feels almost frictionless in those early stages — and that frictionlessness is genuinely valuable. It lowers the barrier to experimentation and lets you move fast.

But moving fast and building something that lasts are different things. The gap between them is where strategy, design, systems thinking, and engineering discipline come in. And it turns out that AI doesn't just help you write code — it transforms how you approach all of these disciplines, from the first idea through to a live, maintained product.

The Problem with Freeform AI Development

When you build software by chatting with an AI, something subtle happens over time. The context window fills with accumulated history — completed tasks, discarded directions, repeated instructions, old versions of the same thing. The AI starts losing track of decisions made earlier. It produces code that contradicts what it built ten messages ago. Quality drifts.

This is context rot in its most damaging form — not just degraded responses, but an entire codebase gradually losing coherence because there's no persistent memory of why things were built the way they were.

The solution isn't to use AI less. It's to engineer the context deliberately.

Context Engineering: The Foundation

Context engineering is the practice of structuring what goes into an AI's context window at each step — so every agent starts with exactly what it needs and nothing it doesn't.

Instead of one long conversation that fills up with noise, the approach is to:

• Keep persistent structured files that capture decisions, plans, and state
• Give each task its own fresh context window with only the relevant information loaded
• Use specialised agents for specialised jobs — one researches, one plans, one implements, one verifies
• Commit every task atomically so the history is always clean and reversible

The result is consistent, high-quality output regardless of how large the project grows — because each agent is always working with a clean, focused context rather than a degraded one.

The Component Architecture

A well-structured AI-assisted development setup brings together four distinct layers of tooling, each serving a specific purpose.

The strategy layer lives in a dedicated workspace — a Claude.ai Project used for research, triage, and planning conversations. No code is written here. It's where ideas are shaped, issues are reviewed, and milestone briefs are produced that inform the build cycle.

The GitHub layer is the source of truth for everything that gets built. The repository holds the codebase and all planning files. Issues track discrete ideas, bugs, and feedback — one idea per issue. GitHub Actions automates testing and deployment. The master roadmap lives here, version-controlled alongside the code.

The build layer is where Claude Code operates locally — reading the repo, writing code, running builds, and committing. A context engineering framework sits alongside it, managing planning files, orchestrating agents, and maintaining state across sessions. This is what prevents context rot at the build level.

The environment layer runs three stages: local test, staging, and production. Each build is promoted through this pipeline rather than deployed directly.

The CI/CD Pipeline

Every commit triggers a pipeline that takes code from a developer's machine to production in a controlled, repeatable way.

The pipeline starts with a push to the main branch. GitHub Actions runs the full test suite — unit tests, component tests, and end-to-end tests. If anything fails, the pipeline stops and deployment is blocked. No broken code reaches staging.

When tests pass, the build deploys automatically to staging. Before that happens, the current build is archived with a timestamp — the last ten builds are retained, older ones purged. This gives a clean rollback path without manual intervention.

Promotion to production is a manual step. This is deliberate: it creates a human checkpoint between staging validation and a live release. The production deploy runs its own build, its own backup, and then updates documentation automatically — screenshots are regenerated and committed back to the repository, so the README always reflects the current state of the app.

Notifications fire on completion, whether the deploy succeeded or a test failure blocked it.

The Development Workflow

The workflow that connects strategy to shipped code has four distinct layers, each feeding the next.

Strategy and triage

Every build cycle starts not with code but with a review of what needs to be built. Three inputs feed the triage process: research documents in the repository, GitHub Issues representing discrete buildable items, and the retrospective from the previous milestone.

The triage process validates the backlog — checking for stale issues, shipped work that hasn't been closed, and items that need context before they can be planned. It reviews the strategic research documents and surfaces anything that hasn't been captured as an issue. It groups open work into themed milestones and aligns the planning roadmap with GitHub milestones so that both stay in sync.

The output is a fully aligned state: every open issue assigned to a milestone, every milestone reflecting the strategic direction.

Planning

With a clear milestone scope, the planning cycle begins in Claude Code using the context engineering framework. A new milestone session asks questions about scope, constraints, and goals — then creates a phased roadmap. Each phase goes through a discuss stage (capturing implementation intentions and edge cases), a research and plan stage (investigating approaches and producing atomic task plans), and a final check before any code is written.

This separation of planning from execution is important. Planning with a clean context produces better plans. Executing against explicit plans produces better code. The quality of each stage compounds.

Build

Phases execute in Claude Code with fresh subagent contexts — each task gets its own clean window. Independent tasks run in parallel; tasks with dependencies run in sequence. Every task produces its own atomic git commit with a descriptive message, so the history tells a clear story of what was built and why.

After execution, each phase goes through manual user acceptance testing. Specific, testable criteria are checked against what was actually built. If anything fails, fix plans are created and execution runs again. Nothing advances to the next phase without passing verification.

Deploy

Once a milestone is complete and audited, the deploy pipeline runs. Builds promote through test to staging to production. Retrospective notes are written, capturing what went well, what didn't, and what carries forward. Those notes become one of the three inputs to the next triage cycle — closing the loop.

Why This Architecture Matters

It might seem like a lot of structure for what is ultimately one person and an AI. And it's true that for a small prototype or a throwaway tool, this level of rigour isn't necessary. But for anything that needs to keep working — anything with users, anything that needs to be maintained, anything where the codebase needs to be understandable in six months — the architecture pays for itself quickly.

The key insight is that AI doesn't remove the need for engineering discipline. It amplifies whatever discipline you bring. A well-structured approach to context, planning, and state management produces dramatically better outcomes than freeform chat. The models haven't changed — what's changed is the architecture around them.

Strategy tells you what to build and in what order. Design (of both the product and the system) determines how it holds together. Context engineering keeps the AI effective as complexity grows. DevOps — the pipeline, the environments, the backups, the tests — ensures that what gets built can actually be deployed reliably and maintained over time.

These aren't separate concerns. In an AI-first development practice, they're all part of the same discipline: building things that work, that last, and that can be improved.

Posted by Envision8 · envision8.com