# Stream of Consciousness Driven Development

DevFeed: [Stream of Consciousness Driven Development](<https://devfeed.tech/articles/stream-of-consciousness-driven-development-25506.md>)

Original publisher: [Read original article](<https://buttondown.com/hillelwayne/archive/stream-of-consciousness-driven-development/>)

Author: Hillel Wayne

Published: 2026-02-18T16:33:08Z

Content type: opinion

Language: en

Sources: [Newsletter feed for Hillel Wayne's Newsletter](<https://devfeed.tech/sources/newsletter-feed-for-hillel-wayne-s-newsletter.md>)

Topics: [Development](<https://devfeed.tech/topics/development.md>), [Specifications](<https://devfeed.tech/topics/specifications.md>), [Markdown](<https://devfeed.tech/topics/markdown.md>)

Tags: [concepts](<https://devfeed.tech/tags/concepts.md>), [development](<https://devfeed.tech/tags/development.md>), [experience](<https://devfeed.tech/tags/experience.md>), [markdown](<https://devfeed.tech/tags/markdown.md>), [pairing](<https://devfeed.tech/tags/pairing.md>), [specifications](<https://devfeed.tech/tags/specifications.md>)

## AI overview

The author describes a pairing technique for conceptually complex specification work: write the problem, discussion, rejected approaches, proposed solution, and rationale in a Markdown file before changing the specification. This helps partners understand the reasoning and agree on an approach, though the author reports having tried it only once.

## Source excerpt

This is something I just tried out last week but it seems to have enough potential to be worth showing unpolished. I was pairing with a client on writing a spec. I saw a problem with the spec, a convoluted way of fixing the spec. Instead of trying to verbally explain it, I started by creating a new markdown file: NameOfProblem.md Then I started typing. First the problem summary, then a detailed description, then the solution and why it worked. When my partner asked questions, I incorporated his question and our discussion of it into the flow. If we hit a dead end with the solution, we marked it out as a dead end. Eventually the file looked something like this: Current state of spec Problems caused by this Elaboration of problems What we tried that didn't work Proposed Solution Theory behind proposed solution How the solution works Expected changes Other problems this helps solve Problems this does *not* help with Only once this was done, my partner fully understood the chain of thought, and we agreed it represented the right approach, did we start making changes to the spec. How is this better than just making the change? The change was conceptually complex. A rough analogy: imagine pairing with a beginner who wrote an insertion sort, and you want to replace it with quicksort. You need to explain why the insertion sort is too slow, why the quicksort isn't slow, and how quicksort actually correctly sorts a list. This could involve tangents into computational complexity, big-o notation, recursion, etc. These are all concepts you have internalized, so the change is simple to you, but the solution uses concepts the beginner does not know. So it's conceptually complex to them. I wasn't pairing with a beginning programmer or even a beginning specifier. This was a client who could confidently write complex specs on their own. But they don't work on specifications full time like I do. Any time there's a relative gap in experience in a pair, there's solutions that are concep