however, it’s not all smooth sailing. mixed bag.

“Ok but what does the AI have against capital letters?” — Jeff Casimir

“all lowercase threw me off at first” — an engineer on my team

“I like the no caps. let’s everyone know its not slop” — Jesse

fix: there’s now a toggle. lowerchaos is still the default. if capitalization is what you prefer, it’s there.

there’s tension here creatively. i like lowerchaos. it’s a purposeful framing shift, a “wtf?” feeling.

lowerchaos:cosmic_farmland::capitalization:standard_realm. choose your own adventure!

as a long time em dash user, i dislike that it’s now a marker of ai slop. lowerchaos says “it may be slop, but it’s MY slop.” :P

writing again publicly feels the same and vastly different. 15 years is a long time.

the pipeline

notebook <-> kernel <-> idea <-> refine <-> draft <-> revision cycles <-> publish

this flow often takes days or weeks. ideas emerge, sit, breathe, shift shapes. though it’s represented here as linear, it’s decidedly nonlinear. porous, amoebic, adhd chaos with multiple parallel sessions all in various stages at the same time.

notebook. pen to paper. noodling and doodling without any structure. fragments, quick thoughts, lists and bullets that then expand wide. furious scribbles. the feeling of pen on paper unlocks flow. this is not editing time. i really like my moleskine cahier xl notebook with unlined pages; unlined is magical because there are no lines to confine. infrequently, i’ll grab a legal pad lying around or one of those black and white composition notebooks (downside here is that i lose the plot and try to write as small as possible within a single line… partner says it looks serial-killerish, so yeah lol). love rotating the notebook randomly to write at 90 / 135 / 180 degrees. off kilter. write tiny, write huge.

kernel. first shift out of the notebook and into digital realm. claude code session in local repo using wispr flow to talk directly about the kernel. goes into the _kernels directory and ends up in kernels. extract it down to one sentence, the thread to pull and pull. lightweight. often add many kernels at once and then keep moving onto other things, and let these ferment. i don’t want to lose the context around the kernel, so that automatically gets thrown into the ideas section.

idea. all the random connections and thoughts related to a kernel from the initial planting. when inspiration strikes, i’ll add more thoughts about the kernel. claude code & wispr flow again. broad framing: why do i find this interesting? what’s the framing? what’s the arc? what’s the energy? what’s the crux? this is where the shape starts to take form. more details and looser than the tightly scoped one-sentence kernel but not a full draft. append only. not editing. i don’t look at what’s collected in the ideas file. that would trigger the urge to edit, and we do not edit ideas :P then, i step away. the fermentation magic happens. let it simmer. blue smoke’s rolling and temp has settled, nom bbq.

refine. refine is a more structured. usually q&a: why this post, why now? what am i trying to accomplish? what emotional resonance am i going for? main purpose is to further clarify thinking and intent. claude code & wispr flow again. can oscillate back to more free-flowing ideas stage. sometimes let ferment further but others straight into next step if i’m feeling the creative urge.

draft. we’re finally ready to throw it into a draft state. claude code without wispr flow. take what we’ve got from ideas and see what happens. i will hate this first draft. it is guaranteed. it’s terrible. inaccurate. definitely not what i want, not what i said, not the voice or point… THE KERNEL IS CLEAR. visceral reaction expected… “no no no, this is trash. how in the hell is that what was produced”. but it’s a launching point, and i feel the immediate shift. “ok cool, let’s curate. i’m going to tear this shit to pieces and make it mine!”. i’ve now got something to see and feel and interact with, and this shift matters.

revision cycles. the english major comes out. the tinkerer, the tweaker. there will be many, many revision cycles. claude code paired back up with wispr flow. /feedback skill creates a local html file with the draft on the left side and open feedback sections on the right. the first few cycles are focused on high level thinking, structure, feelings as i read it. we are not focused at the granular word and sentence level. once this is dialed, i get more detailed and make changes with specific words and sentences. all feedback is fed back directly into claude code with “copy all feedback as markdown” button. could this be automatic? yeah. but system’s good enough for now. can always build it in the future. tbd on how many times this /feedback skill gets run. precision, intent. an extra grain of finishing salt. another squeeze of lemon or splash of vinegar.

published post. holy shit, we’re finally here! it’s ready. claude code moves it from _drafts/ to _posts/. commit and push, and the simple github site automatically updates. “ready” is a feeling; it is not a checklist. ship it earlier than i want to get it out there. by this time, dinner companions are starving, but that’s what apps are for ;)

evolution

the first post i wrote with this flow was build friction fix. the setup was very simple. claude code on the left, locally served blog post on the right, wispr flow for voice input.

the loop: read the rendered post in the browser, talk through what wasn’t working via wispr flow to bring that feedback into claude code, get a new draft, look again. over and over again.

the feedback was mostly structural at the outset. “is the arc right? does this section flow into the next one? am i losing energy here?” big-picture stuff.

since i wasn’t distinguishing between “rewrite this whole section, the framing is off” and “change this specific phrase exactly,” i got frustrated with the changes in the next draft when i told claude to incorporate the feedback. it felt like three steps back. structural feedback and line-level feedback were tangled together, and claude code happily gave me entire rewrites… oof.

however, the system was good enough. i finally wrote a thing! the cosmic farmland was BACK UP! yayayayayay

the second post, mental experimentation budgets, took shape over a few weeks.

i addressed the friction from writing bff where high-level general feedback tangled with specific wording feedback. the fix was review.html, an early version of the /feedback skill.

now, the feedback loop became read a section, add feedback, hit “copy all feedback as markdown,” paste into claude code. structured, repeatable, and no more confusion level of granularity.

wispr flow as granularity guardrail

wispr flow has been awesome to harness co-intelligence. i braindump and riff with the quickness. ~170 wpm of pure chaos.

when i’m typing feedback, i go too quickly to wordsmithing. i edit and re-edit sentences, fiddle with phrasing, chase rabbits. typing pulls me down to the word level whether i want to be there or not.

talking lets me stay at the right level of granularity. when feedbacking on overall structure, i stay in the structural realm. i’m not tempted to rewrite a sentence. yes, i can go to the granular level if i absolutely must, but it is easier to stay in the feedback lane i want.

wispr flow helps me stay at the right level of granularity, & it keeps the main thing the main thing.

the current system

the system i’ve got in place for this post adds another layer. the structured feedback sections from meb were good for big-picture notes. for specific wording, i was using instead: "copied text" do: "revision" over and over again. type instead:, highlight text to copy & then paste it in feedback box, type do:, copy & paste, edit specific wording.

that was annoying. i fixed. now, i highlight any text in the draft and the feedback text area auto-populates with:

instead: "<selected_text>"
do: "<selected_text>"

cursor lands right on the empty do: line, ready for the replacement. quick & easy.

bffing the system. at the core, this entire flow is a bff fractal.

the thread

i like that the patterns emerged naturally through action. write, name the friction, and fix it. again and again.

this ai-augmented writing flow co-intelligence is bonkers for me. moving from notebook through ideas happens much quicker and in parallel; friction to start costs less neuron-watts. the revision loop is fast enough that i actually iterate on voice and structure.

tangent i throw away a ton of shit. the experimental weird wtf is this, oh yes catharsis probabilistically perfect piggies emerged after jamming on a lengthy diatribe about authenticity, hunter s thompson, creatives responses to authoritarianism and fascism, and homemade mullet energy + jbs&tdc’s mutiny after midnight. late, late stages on it. about to ship. but i didn’t love it. felt off, forced a bit. so i went old-school, straight writing, no co-intelligence. oink oink motherfuckers. end tangent

the bottleneck has never been “can i write?” i’ve done that before (tracked down a blog from 15 years ago when i was moving out to colorado. hilarious trip into nostalgia land).

the last 15 years it’s been everything else.

not just me

widening out, i love seeing versions of this pattern out in the wild from all sorts of folks. people finding their own way to use ai as co-intelligence for exactly what they want and need and then sharing it.

one example i love is from jeff casimir who shared his experience using ai to prepare for a technical assessment in python:

We researched likely interview problems, wrote test suites, I built implementation, Claude gave feedback, and we distilled it into a PDF “Python for Rubyists” that I could print and have on my desk for the assessment.

I think the real value is in using AI as a coach and collaborator. It can be the hub of a conversation that mixes the learner, the work, research, outside expertise (like a teacher), experience/context (like your past work/success/struggle), requirements/constraints, etc. The answer is the least interesting part of the process.

not “ai do this for me” vibe thinking but “ai as co-intelligence to own my own learning.” the specific tools and workflows are different, but the relationship is the same. own your learning. own it!

come along

this process will keep evolving. i’ll bff and bff again. maybe there’s a bff’d writing gastown out there.

weird times we live in y’all. keep learning and building :)

vibe thinking. look how easy it is! turn off our brains. submit.

the duality of it all is so striking. we have such incredible power at our fingertips, and yet slop slop slop fills up the trough. this slop never ends, yipppppeeeeeee!

the meeting summaries with a bajillion emojis. :rocket-ship: :sparkles: :megaphone: :racecar: :checkmark: :glitter-pig: the formulaic linkedin posts “what making zoodles for a dinner party taught me about <insert_job_title>…” and “you’ll never guess what happens next”.

convergence to sameness, don’t rock the boat, stay in your lane, optimize for engagement above all to the most average of averages. see you at the slop trough my fellow piggies.

the walls are closing in, the slaughterhouse awaits. get in line, fatten up for the holiday ham. we’ll double-glaze ya with walls and walls of text and em dashes and sycophancy.

i feel it in my bones. deep in my soul.

where is the authenticity? the raw, unbridled awesomeness of humanity. of what your mushy mash of cells of our brains can create. not probabilistically, authentically. YOU.

i’m leaning into my authenticity.

i have to create. i have to write. i have to connect. i have to reject.

harness the power of the human possible.

oink, oink piggies. let’s get weird.

claude code + skills + observability clis make debugging even more enjoyable. i can move through data -> information -> knowledge -> wisdom levels quickly and switch between breadth and depth on a whim.

as i’ve built some small tools to explore what’s possible in this area, i’ve also been directly pairing with a wide-range of people on issues (the weirder & more perplexing, the better). we record the live debugging session and automatically generate artifacts afterwards (highlight reels, docs with takeaways and patterns and strategies, etc).

people start applying this general idea in ways i’d never consider (love planting seeds and seeing what grows / thrives).

during a 1:1 with someone on my team who was using this flow, i asked how it was going as an early adopter. “super helpful, much easier to make sense of systems, drive outcomes, really enjoying it, etc”. however, there was one instance where this combo didn’t find something they knew existed in the observability data. their conclusion: “i don’t trust it anymore at all.”

wait, what? why throw away and ignore all the positive feedback. that surprised me.

since that convo, i’ve been noodling on the concept of mental experimentation budgets and how we might use this idea in the rapidly changing ‘wtf is happening’ period we’re in.

mental experimentation budgets

mental experimentation budgets are the capacity to keep trying new things (workflows, patterns, tools, etc) in the moment and over longer periods of time.

what’s your capacity right now? how fast is it draining? what’s the cost of each new attempt?

the variables

capacity. your total budget at any given point. this shifts with sleep, energy, emotional state, time of day, what happened in your last meeting. changes often.

marginal cost. what it costs to run one more experiment. when everything is brand new, the cost is high. every interaction takes effort, attention, active decision-making. but as you build fluency & patterns become automatic, the cost per experiment drops. you stop thinking about how to do the thing and you just do it.

fixed cost. the startup cost of beginning at all. the decision to try or to switch into this context. getting oriented in a new tool or a new way of thinking. this cost is real and it hits before the experiment even starts.

outcome shock. the cost that comes from the result. when an experiment goes the way you expected, the cost is manageable. expected outcomes are cheap to process mentally. but when something unexpected happens, when you know something is there and the tool isn’t finding it, that’s a spike. the cost shoots up. and if your budget is already low when the shock hits, it can be a total drain.

return. not every experiment is a cost. some deposit back into the budget. a win gives you confidence, knowledge, momentum. success compounds when you’ve got the budget to keep going. returns are what make experimentation sustainable, not just tolerable. (suppose this could be folded into outcome shock in a capacity increasing way but shrug)

recharge. the budget replenishes. sleep, movement, flow states, small wins, time away. these are inputs back into the system. the budget isn’t a battery that only drains. it’s a living resource that fluctuates.

the model

in cosmic farmland math:

remaining budget = capacity - fixed cost - (marginal cost × experiments) - outcome shocks + returns + recharge

as i was thinking about the 1:1 afterward, i could see the model at work. the outcome shock hit at exactly the wrong moment. when the shock cost more than what was left in the budget, boom, we get “don’t trust it anymore at all”

feedback loops are built into the system both positively and negatively.

success lowers future marginal costs (you’ve built fluency). returns increase capacity (confidence expands what you’re willing to try).

however, shocks can create negative loops that seem to have more gravitational pull or acceleration than positive ones.

one bad outcome raises the perceived cost of the next experiment, which means you need more budget to try again, which means you’re less likely to get the return that would restore it.

boom, a single failure becomes a full stop. and now it’s harder to get started again. probably slower recharge rate as well.

connections

a brief detour into some connections drawn from my past and from current golf obsession that, if i squint, the model is derived (at least partially) from. ymmv

i taught middle school math and coached sports before getting into software. i spent years digging into how people learn, how understanding builds and then sometimes just collapses. humans are sense-making machines, and i got obsessed with the mechanics of it. what conditions let someone integrate new knowledge, and what conditions cause them to reject it?

that obsession led me into cognitive science and psychology, and what i found there maps onto this model.

kahneman’s thinking, fast and slow describes system 1 and system 2, the fast automatic brain and the slow deliberate one. when you’re experimenting and it’s going well, system 2 is engaged, learning, processing, building. when an outcome shock hits, system 1 takes over. something faster than rational assessment, operating on pattern and instinct.

raymond prior’s golf beneath the surface calls it the old brain and the young brain. the young brain is where deliberate thinking happens. the old brain is where perceived threat lives. under stress, the old brain wins. every time. we aren’t choosing to ignore our wins. the old brain is making that choice for us.

donella meadows, in thinking in systems, frames the budget as a stock. experiments are outflows. recharge is inflow. the feedback loops (reinforcing and balancing) are where the behavior of the system gets determined. you don’t change the system by pushing harder. you find the leverage points.

putting it into practice

as i’ve been thinking about this model and sharing with others, it seems like there’s something here.

some questions i keep coming back to:

• what’s my budget right now?
• how do i reduce the fixed cost of starting?
• how do i build automaticity and reduce the marginal cost per experiment?
• am i aware of my recharge patterns? am i honest with myself about them?
• how do i increase my overall capacity?
• how do i build resiliency to outcome shocks?
• how do i make recharging more intentional?
• am i pairing the type of experimentation with where i’m at?

this model gives me language for reasoning and sense-making.

does this resonate? what’s missing? what would you add?

here’s to understanding our mental experimentation budgets.

the rapid pace of change right now in tech world feels overwhelming. timelines are compressed. new tools & new ways of working popping up left and right. all the things so fast.

for months, i said i wanted to get started, to get building. but i wasn’t taking the first step to actually build. instead, it was reading articles, chasing best practices, tweaking configs, getting my setup dialed.

at some point in late 2025 or early 2026 (maybe the hope of a new year?), i realized there’s no singular perfect prompt. i had to start somewhere. building, writing, engaging, finding the connections. just taking a first step. this realization freed me up.

bff (build, friction, fix) is a pattern that emerged after a few months of building.

i use it to give myself the permission, the freedom, to get started and take the first step. it applies on varying levels of granularity: a single session, larger features, entire projects or far-flung dreams. a self-reinforcing fractal pattern. small to wide to wider.

let emergent patterns emerge.

build

in this phase, the most important thing is to build. that’s it. take one step. try something, try anything.

release the idea of perfect. release premature optimization.

does not matter where you start. maybe it’s code, research, analyzing data, jotting down ideas, brainstorming, synthesizing an article, compiling pieces to search for connections.

yes, it takes from your experimentation budget. trying things has a cost.

take one step now to build. build something. literally anything. start now.

friction

friction will happen. not if, but when.

as you build, notice. be aware of what wasn’t quite as simple as you wanted or what didn’t go like you expected. but don’t stop to fix it yet; that’s the land of rabbit holes. keep building.

(admittedly, yes, i’m spending more and more time in these rabbit holes. always have. i’m making rabbit friends, we’re chatting, hanging out. i’m a big waver in my neighborhood and elsewhere. lots of waves, lots of head nods. i’m head nodding and waving to rabbits as they welcome me to their communities. thankfully, though, i keep finding my way back to the main path.)

so as i build, what am i noticing that’s not quite as smooth as i’d like? what was harder than i anticipated? i jot these down simply, a quick word or three. we’ll come back to these.

once you’ve built the thing and you’ve got your noticings on friction, now’s the time to get explicit. name them. compile a quick list. brain dump it out.

as i’m writing this post, here are three frictions i’ve named and will apply fixes to moving forward. raw words, here they are:

notes to words: notes to verbal brain dump clarified my thinking. but taking the verbal brain dump and crafting it into “what is the kernel? what is not being lost in transition?” how do i get these ideas actually into this writing system without losing the fidelity that matters? i’ll figure out how to make this better. we’ll figure out how to fix that in the future.

finding my voice: this co-intelligence combination, collaborative style. i’m having to think, when do i say something exactly as i want it? do i want it to go through a summarization process, because i don’t feel like it’s capturing my voice? we’re capturing my voice along the way. we need to figure out what’s my writing style and how to be clearer with what’s a quote, what’s an idea that we summarize versus directness.

ship it: the drafting process is key. go from skeleton notes all the way through to “hey, when is this done?” set some timers. am i losing the essence, or am i making the essence clear? this is going to be hard to navigate. when is it ready? just send it out and see how people engage. when do i feel good enough? i just have to keep going, knowing that my pattern can be side quests, more of this, more of that. this will be a friction that we’ll have to figure out as we move forward.

friction is expected. by naming it, we now have a chance to fix it.

fix

now we get the chance to improve our system and carry it forward.

talk with your tool, claude, opencode, codex, whatever you’re using. “here’s the friction i had. how can i fix this moving forward?”

and in conjunction, ask yourself the same question. how might i fix this? what do i think the recommendation will be? i’m literally asking myself in the same way i’d ask the tool.

this is a great way to understand the shape of the system. sometimes what you think and what the tool recommends don’t line up. that’s where the learning happens.

the fix might take different forms.

human clarity

we’ve learned some things. knowing what we know now, how can i say this differently?

you know now what you didn’t know then. maybe it’s a framing fix. am i providing enough context? have i done the thinking? is my lack of clarity causing the challenge?

lazar jovanovic talks about this with his debugging workflow. when something breaks, he steps through layers: let the tool try, then bring your own awareness, then bring in an external tool, then check if it’s your fault. and when the fix lands, he asks the tool:

“i needed to do four different things to fix this. how can you help me learn to prompt you better so that next time, we do it in one go?”

then he goes further:

“put what we just learned into rules. i’m not going to prompt you better. you’re just going to learn and prompt yourself better.”

the human clarity is the bottleneck, not the tool. as lazar puts it, we’re going to be rewarded for clarity, judgment, thinking. building it is going to be instant. it’s the thinking that matters.

structural fix

maybe the fix isn’t how you said it. maybe it’s the system around you.

a change to your CLAUDE.md. adding something to memory. a skill, a hook, a command. these are the primitives, the composable building blocks.

maybe it’s a tool fix entirely. the one you’re using isn’t getting anywhere. you’re spinning. switch tools. “here’s the input, here’s the desired outcome, how do i get there?”

when you’ve got a hammer, everything’s a nail. cool, treat it like a nail. apply your own bff loop here and you’ll get more tools. all the tools. and the judgment on when to use them.

“but you said there’s no perfect prompt.” it’s not about finding that perfect prompt. it’s about thinking, how can i say something different? how can i do something different? how can i build the system so that the system is more important than any one single prompt?

and here’s the thing that stacks on it: you can always change it later. that freedom is magical. i’m fixing this one piece of friction right here. then i’ll do another bff cycle. and another. and another. just bff looping for days.

bff: the widening gyre

build. friction. fix. repeat.

the power is in the loop. the interactions over time stack together. that’s compounding.

i’m taking the smallest first step. noticing where things weren’t smooth. naming it. fixing it.

because we’re taking action and reflecting, patterns emerge. the shape of the challenges. the shape of how you work. the shape of the work itself. you’re building your system.

what didn’t go well? what do we want to experiment with? these aren’t new questions. but they’re hyper-personalized. my experience. my actions. my reflections. my fixes. yours will be yours.

as you work, you will evolve. maybe you start from scratch entirely when a system no longer fits what you need or want. awesome.

the same pattern repeats at varying degrees of granularity. fractals.

yeats wrote about the widening gyre as dark, destructive, things falling apart. the system you built no longer fits? that’s not failure, that’s growth. that’s freeing. you’ve got the tools to come back to center and rebuild. wider this time.

here’s what i found. i want to see what you find. let’s chat :)

a friend guessed that bff meant “build fucking fast” based on what i’ve been encouraging over the last few months. yes, that applies here too. compress the learning. establish your system. let’s go.

happy bffing.

i’ve written at times throughout my life. not consistently.

this is an attempt to change that.