# No Faster Than Understanding ## Context Software generation is becoming inexpensive. Code, tests, documentation, migrations, refactors, and exploratory implementations can be produced in quantities that were previously impractical. This does not remove scarcity. It moves scarcity. The constrained resources increasingly become: - attention; - understanding; - product judgment; - review capacity; - production feedback; - coordination; - trust; - the ability to distinguish evidence from plausible output. We therefore do not organize engineering around maximizing code production. We organize engineering around maximizing useful learning and safe change. --- ## Our position ### 1. Value over output Working software is useful only when it changes an outcome we care about. Generated code is inventory until it produces evidence of value. We prefer: > a smaller validated change over: > a larger impressive implementation. --- ### 2. Flow over utilization Keeping every engineer and every agent busy is not the goal. A system with ten concurrent AI-generated changes and a review bottleneck is not productive. It is congested. We prefer low work in progress, short queues, and fast feedback over local utilization. AI should increase throughput **inside the WIP limit**, not justify increasing WIP. --- ### 3. Small changes over cheap generation AI reduces the cost of producing large changes. That makes small changes more valuable, not less. We prefer changes that can be: - understood; - tested; - reviewed; - deployed; - reverted or forward-fixed; - observed independently. Cheap generation is not permission for large batches. --- ### 4. Evidence over confidence Plausibility is one of AI's strengths and one of its risks. A coherent implementation can still be based on a false assumption. We therefore prefer executable or observable evidence: - tests; - contracts; - invariants; - production telemetry; - reconciliation; - benchmarks; - experiments; - user behavior over confident explanations. --- ### 5. Fast feedback over long autonomous runs An agent working for thirty minutes without feedback can move quickly in the wrong direction. We prefer agents operating inside short feedback loops: ```text intent -> assumption -> small change -> test -> feedback -> refactor -> integration ``` Autonomy is useful when feedback remains frequent. --- ### 6. Understanding over generated volume The cost of understanding a change must not be transferred downstream. The author of a change remains responsible for making it reviewable, regardless of who or what generated it. We reject the pattern: ```text cheap generation -> expensive human review -> hidden organizational cost ``` A useful constraint is: > No faster than understanding. This does not require memorizing every line. It requires sufficient understanding to explain the problem, important decisions, trade-offs, failure modes, and evidence. --- ### 7. Collective ownership over agent-local knowledge We do not want regions of the system that only one engineer and their agent can safely modify. Knowledge should remain transferable through: - small changes; - tests; - executable contracts; - simple design; - shared operation; - pairing or swarming when useful; - production feedback. AI must reduce the cost of knowledge sharing, not create private synthetic expertise. --- ### 8. Simple design over speculative abstraction AI is very good at producing complete-looking abstractions. Completeness is not the same as necessity. We prefer the simplest design that satisfies current evidence and preserves cheap future change. We refactor when pressure appears. We do not pre-pay complexity because generation is cheap. --- ### 9. Continuous integration over branch completion Integration is a feedback mechanism, not an administrative stage. We prefer: - trunk-based development; - short-lived changes; - feature flags where needed; - build once/promote many; - reproducible validation; - frequent integration. A branch that contains days of agent work is delayed feedback. --- ### 10. Assumptions made explicit over assumptions hidden in implementation Important assumptions should be visible before they become architecture. Examples: - an external API is idempotent; - a table can tolerate a locking migration; - eventual consistency is acceptable; - an event is delivered at least once; - a customer workflow tolerates a specific delay. Whenever practical, an important assumption should eventually become one or more of: - a test; - a contract; - an invariant; - a monitor; - a decision record; - an experiment result. --- ### 11. Human accountability over delegated blame AI can generate, inspect, explain, and propose. It cannot own organizational accountability. The engineer accepting a change remains responsible for: - understanding its intent; - evaluating important trade-offs; - validating relevant evidence; - escalating uncertainty; - operating the result. "AI generated it" is neither a quality exception nor an incident explanation. --- ### 12. Learning over process compliance Lean and XP are not ceremonies. A practice exists because it improves a feedback loop or reduces a known form of waste. When a practice no longer improves the system, we change or remove it. We prefer evidence that the system is improving over evidence that the team followed the process. --- ## The operating model we want to explore ```text problem -> hypothesis -> smallest useful change -> evidence -> production -> learning ``` rather than: ```text ticket -> implementation -> pull request -> approval -> done ``` "Done" should mean that the relevant uncertainty was reduced, not merely that code was merged. --- ## What this manifesto is not It is not: - an AI usage policy; - a mandatory tool list; - a ban on large changes when they are genuinely necessary; - a demand for 100% TDD; - a fixed Scrum replacement; - a developer productivity scorecard; - a justification for measuring engineers by output. It is a set of beliefs to be tested against real engineering work. --- ## A compact statement > When code generation becomes cheap, engineering should optimize for flow, feedback, understanding, and evidence. Lean helps us control the system of work. XP helps us keep change safe and inexpensive. AI increases execution capacity, but accountability remains human.