Applying Cynefin to Software Development and AI-Assisted Systems
This article applies Dave Snowden's Cynefin framework to distinguish between 'Complicated' and 'Complex' problems in software development, particularly in the context of AI coding tools. It argues that while AI tools excel at Complicated tasks like writing functions, they fall short in addressing the emergent 'Complex' challenges of system coherence and interaction. Understanding this distinction is crucial for architects and developers to leverage AI effectively and navigate system evolution.
Read original on Dev.to #architectureThe Cynefin Framework: Complicated vs. Complex Domains
The Cynefin framework helps classify problems based on the nature of cause and effect. In system design, it's vital to differentiate between Complicated and Complex problems, as they require fundamentally different approaches.
- Complicated Problems: These have knowable right answers, discoverable through skill or analysis. They are deducible, repeatable, and can be solved by following a process. Examples include writing a function to a schema, refactoring with a known pattern, or adhering to a detailed specification. AI coding agents excel in this domain.
- Complex Problems: These lack deducible answers in advance. Outcomes emerge from a web of interacting parts and are only coherent in retrospect. Examples include ensuring consistency across many merged changes, maintaining architectural coherence over time, or predicting race conditions under production load. These require a 'probe, sense, respond' approach rather than pure analysis.
AI Tools and System Coherence
The article highlights that current AI-dev tooling, such as Agent Skills, Superpowers, and spec-driven development kits, are highly effective in the Complicated domain. They make individual tasks (units of work) more reliable, repeatable, and verifiable by packaging procedural knowledge, enforcing rigorous processes, and ensuring adherence to specifications.
The Overclaim Trap
It is a significant mistake to assume that making individual units of work perfectly reliable (Complicated domain) will automatically lead to a coherent and correct overall system (Complex domain). System coherence is an emergent property of interactions, not merely the sum of perfectly executed isolated tasks. A system can be incoherent even if every individual component adheres perfectly to its specifications.
Issues like mismatched field names (e.g., `userId` vs. `user_id`), conflicting retry/timeout policies, or interdependent refactors often arise from the Complex domain. These are not caught by per-task discipline because each task was 'done right' in isolation. Integration failures are often emergent, not deducible from individual components or even large context windows.
Navigating Complexity in System Design
For Complex problems, the methodology shifts from 'analyze, then execute' to 'probe, sense, respond'. This involves active integration, deployment, and monitoring under real load to observe emergent behaviors. Integration and property-based tests become crucial instrumentation to sharpen sensing, rather than exhaustive upfront checks that presume foreknowledge of all failure modes.
- New Category Products: Products in new categories start in the Complex domain, where the solution's shape is unknown. Here, the focus should be on learning through prototypes and experiments (probe-sense-respond) rather than rigid, upfront specifications. Code is often a liability if it hardens assumptions prematurely.
- Experienced Engineers: Expertise can be a liability in the Complex domain if it leads to reflexively applying known patterns when the situation demands exploration and learning. The discipline required for new categories is almost the inverse of building known categories.