Architecture
The platform is organized around a simple question: what changes when the same architectural intent is carried through different systems?
Spec-Driven Development vs Adaptive System Life Cycle Development (ASLCD)
Spec-Driven Development
A development practice where structured specifications define what to build before implementation begins. Focus: clear requirements, reduced ambiguity, implementation-ready intent. Scope: Design to Implementation.
ASLCD
Adaptive System Life Cycle Development (ASLCD) is a full lifecycle framework that extends spec-driven development into an adaptive, multi-user, agent-agnostic system for building, validating, and evolving software over time. DevSpark is an implementation of ASLCD.
Spec-driven development ensures you build the right thing. ASLCD ensures the system continues to behave correctly as it grows and changes.
System Overview
The shared API layer includes WebSpark, PromptSpark, GitHub Repository Spark, and markhazleton.com content. These components provide content, prompt workflow context, repository activity, and platform presentation data to multiple frontend systems.
Controlled Comparison
TailwindSpark and BootstrapSpark are not just styling alternatives. They are controlled comparisons where similar product goals meet different component models, design constraints, and composition strategies against shared APIs.
Key Insight
Frontend architecture is not a styling decision — it is a system design decision. The lifecycle view matters because those decisions keep expressing themselves as the system grows.
DevSpark: ASLCD in Practice
DevSpark is my implementation of ASLCD — the part that actually runs in a development environment. Where ASLCD is the framework, DevSpark is the tooling: a set of prompts, conventions, and workflows that make spec-driven development practical in daily work alongside AI coding agents.
The core idea is that a project's constitution — its architecture decisions, code standards, review criteria, and governance rules — should be a first-class artifact, not tribal knowledge. DevSpark uses that constitution at every stage: when writing requirements, implementing features, reviewing pull requests, and evolving the system over time.
I started building DevSpark after noticing that spec-driven development worked well for greenfield projects but fell apart in existing codebases. There was no mechanism for keeping governance connected to code as both changed. DevSpark is my attempt to solve that — and this site is built and maintained using it.
Constitution-Driven
Every project gets a constitution that defines architecture decisions, standards, and review criteria. AI agents consult it; pull requests are reviewed against it.
Agent-Agnostic
Thin shims over canonical prompts mean DevSpark works with GitHub Copilot, Claude Code, Cursor, or whatever comes next. The governance is portable; the agent is interchangeable.
Built for Existing Code
Most governance frameworks assume a clean start. DevSpark was designed to be retrofitted into real projects — messy history, legacy decisions, and all.
The DevSpark Writing
These articles trace DevSpark from its origin through daily practice — the decisions behind it, what it's taught me, and where it's fallen short.
Why I Built DevSpark
An exploration of why I built DevSpark — driven by the personal struggle of keeping existing codebases aligned with architectural standards long after the initial specification phase.
From Oracle CASE to Spec-Driven AI Development
From Oracle CASE repositories in the 90s to AI-powered DevSpark today, this is a personal journey through four decades of model-driven development. Learn how the industry cycled from structure to speed and back to synthesis, and what Monday-morning practices you can adopt now.
DevSpark: Constitution-Driven AI for Software Development
DevSpark aligns AI coding agents with project architecture and governance through a constitution-driven toolkit for the full software development lifecycle.
Getting Started with DevSpark: Requirements Quality Matters
Bad requirements produce bad code—this was true with humans and is exponentially worse with AI. Vague prompts force AI to guess at thousands of unstated constraints, generating code that looks right but fails under real-world conditions. DevSpark addresses this through structured phases: Constitution guardrails, mandatory clarification loops, discrete pipeline gates, and human verification. Requirements quality matters more than coding speed.
Taking DevSpark to the Next Level
From EDS mainframes to AI coding agents—introducing the Adaptive System Lifecycle Development Toolkit that bridges rigorous enterprise methodology with modern AI-assisted development. Learn how to balance structure with innovation, maintain quality without rigidity, and make your project constitution valuable throughout the entire development lifecycle.
DevSpark: Constitution-Based Pull Request Reviews
Every mature codebase accumulates institutional knowledge that lives in scattered places. This article explores how to use DevSpark to perform AI-powered pull request reviews that validate changes against a project constitution—a living document capturing architectural principles, anti-patterns, and non-negotiable standards.
DevSpark: Months Later, Lessons Learned
After months of using DevSpark across real projects, the theory met reality. This article is a practitioner's check-up — what survived contact with production, what surprised me, and the lessons I didn't expect about AI confidence, adversarial review, and the economics of doing it right.
Dogfooding DevSpark: Building the Plane While Flying It
A first-person look at what it's actually like to dogfood DevSpark — using a prompt tool to refine a prompt tool — anchored in an old EDS Super Bowl commercial about building a plane mid-flight.
DevSpark Blogging Workflow: How I Built Better Articles
Writing the Cloudflare and IIS article made me realize I needed the same kind of governed workflow for content that I expect from code. This is how I layered write-article, critique, editorial, and SEO prompts on top of DevSpark so a rough idea could become a stronger, more publishable article through deliberate iteration.