Writing

How a 1,900-line specification document, a 245-line rules file, and Claude Code turned a solo developer into a full-stack team.

What happens when spec-driven, AI-assisted development moves from a solo workflow to a team? The benefits, the tensions, and what it would actually look like in practice.

You don't need expertise in every language, framework, or protocol anymore. AI fills the syntax gap. Your job is knowing how to build software well.

Why spec-driven, AI-assisted development matters to leadership — reduced rework, faster onboarding, knowledge durability, and predictable delivery.

A high-level map of the modern AI stack. LLMs, tokens, embeddings, RAG, fine-tuning, agents, and how they all fit together. The first post in a series covering AI fundamentals from the ground up.

What happens inside a large language model. Neural networks, transformers, attention, training, parameters, and inference. How the machine turns text into text.

How models break text into tokens, why context windows have limits, and what this means for cost, capability, and application design.

How text becomes numbers that capture meaning. Embeddings, vector similarity, vector databases, and the practical applications that depend on them.

Retrieval-Augmented Generation explained. How to give LLMs access to your own data through chunking, embedding, retrieval, and generation.

How to communicate effectively with LLMs. System prompts, few-shot examples, chain-of-thought, structured output, temperature, and sampling strategies.

When and how to fine-tune an LLM. Full fine-tuning, LoRA, RLHF, and the decision framework for choosing between fine-tuning, RAG, and prompting.

LLMs vs SLMs, open vs closed, cloud vs on-device. A practical framework for selecting the right AI model for your use case, budget, and constraints.

How models move beyond text generation to take actions. Function calling, tool use, agent architectures, and building autonomous workflows.

Why organizations should invest in AI. ROI frameworks, competitive dynamics, practical adoption paths, and the risk of waiting.

A high-level overview of Domain-Driven Design: what it is, why it exists, and when it is an effective approach for building software systems. The first installment in a broader series.

A deep dive into running effective event storming sessions, from facilitating workshops to translating discoveries into domain models.

How to establish a shared language between business and code, and the naming strategies that keep domain models honest as systems grow.

How to identify bounded context boundaries, choose integration patterns, and keep contexts autonomous without creating silos.

How to design aggregates that protect business rules, enforce invariants at their boundaries, and keep your domain model honest.

How domain events capture what happened in your system, decouple aggregates, and drive workflows without creating tight coupling between bounded contexts.

How the repository pattern keeps persistence concerns out of your domain model, why domain and data models should be separate, and what a clean persistence boundary looks like.

How separating commands from queries gives you different optimization strategies for writing and reading, and when CQRS is worth the added complexity.

How strongly-typed IDs, smart enums, value objects, and guard clauses make invalid states unrepresentable in your domain model.

Why Domain-Driven Design matters to leadership: reduced maintenance costs, faster feature delivery, scalable team autonomy, and systems that age well.

Extreme Programming defined a system of reinforcing practices in the late 1990s. Most teams cherry-picked the easy parts and skipped the rest. Here's what got lost and why it matters.

TDD, refactoring, and simple design form a triangle. Remove any side and the structure collapses. Most teams attempt one or two. Here's why you need all three.

Code review isn't pair programming. 'That's Steve's service' isn't collective ownership. These two practices eliminate knowledge silos and make every other XP practice work at team scale.

Your CI pipeline running against a two-week-old branch isn't continuous integration. These two practices reduce the distance between writing code and learning from it in production.

The planning game isn't estimation theater. Customer collaboration isn't a stakeholder demo every two weeks. XP's feedback practices predate modern product discovery, and they got it right.

Why Extreme Programming matters to leadership: reduced rework, predictable delivery, lower key-person risk, and teams that get faster over time instead of slower.

Most developers type prompts and accept suggestions. That's 20% of what Claude Code can do. Here's the other 80%: rules, plugins, skills, hooks, subagents, MCP servers, and the prompt patterns that make all of it work.

How I extracted, improved, and published the DDD base classes I've been copying between projects for years into a proper, tested NuGet package.