Practical learning notes on context design, agent orchestration, permission boundaries, execution observability, quality evaluation, and benchmarking in AI-assisted software development.
The central question is not simply which model to use. It is how to help an agent find the right context, work within a clear scope, and connect its conclusions to evidence.
These articles turn development observations and design discussions into general patterns. They are not a framework, a formal maturity model, or documentation of any product's current implementation.
| Question | Article |
|---|---|
| How can one developer preserve decisions across sessions and agents? | Context Architecture for Solo Agent-Driven Development |
| When is delegation worth its coordination and verification cost? | Cost-Aware Agent Orchestration |
| How can an AI-assisted experiment reach a defensible stop decision? | When an Experiment Fails |
| What is an agent allowed to do, beyond what its tools can do? | Capability Is Not Authority: Defining Permission Boundaries for Coding Agents |
| How do requested settings differ from observed model execution? | Model Routing Is Not Model Observability |
| How should quality, latency, and failed requests be measured separately? | Benchmarking Quality, Performance, and Reliability |
| How should findings become bounded changes and evidence-bounded product claims? | From Benchmark Findings to Bounded Product Changes |
| What should generated content and automated playtests actually prove? | Evidence-Carrying Content and the Limits of Automated Playtesting |
| How can local fakes preserve service, ownership, and publication semantics? | From Local Fakes to Production: Service Boundaries and Data Ownership |
| How can semantic evaluation complement rules without becoming unquestioned truth? | Designing AI Judges for Quality Validation |
| How can security validation stay bounded while checking responses and side effects? | Risk-Based Security Validation Without Building an Attack Platform |
Start with context architecture for project continuity, orchestration for task execution, permission boundaries for authorized scope, model observability for execution evidence, the evaluation articles for measurement design, or bounded product changes for the decisions that follow measurement. There is no required reading sequence.
The patterns are starting points for reasoning about trade-offs, not universal prescriptions. Solo and team workflows can combine domain-based documentation with time-based task continuity. Delegating more tasks does not by itself establish lower cost or better results. A successful API response does not by itself establish useful output.
Examples are illustrative unless explicitly described otherwise. These articles do not publish experimental scores, cost savings, model rankings, or claims of production readiness. Suggestions for measurements are not completed measurements.
The articles are generalized rewrites, not complete experimental reports or copies of operational documents. Internal identifiers, raw records, deployment details, and product-specific routing policies are outside their scope.
Use this README as the single article index. Improve an existing article when a new observation fits its question; add an article only for a genuinely different question. Keep facts, interpretations, and untested ideas distinguishable, and preserve meaningful changes through Git history.
There is no required document review, approval state, or publication ladder. Editing guidance for agents is in AGENTS.md.
The aim is to share what is worth studying, trying, and questioning—not to turn every development task into a larger process.