The Braindonor Network

Do It Wrong First

2026-06-25T00:00:00-05:00

Somewhere in your organization there is a slide that says do it right the first time to save costs. I have sat in the room where that slide goes up. It always gets nods. It is the kind of sentence nobody can argue with, because arguing with it sounds like arguing for waste.

I want to argue with it anyway, but carefully, because the slide isn't wrong so much as it's aimed at the wrong target. There are problems you understand, where "do it right the first time" is just professionalism. And there are problems you don't understand yet — high-uncertainty work, a domain you've never touched, a system whose real shape won't show itself until you're elbow-deep in it. Point that slogan at those problems and it stops being discipline. It becomes a demand that you pretend to know the answer before you've earned the right to have one. And the pretending has a cost the budget proposal never counts.

This post is about the alternative, which I've been calling doing it wrong first. I should be honest about what that phrase is and isn't, because it's easy to hear it as a license to be sloppy. It isn't. It is not permission to write trash, ship uncompilable garbage, or call laziness a methodology. It's something quieter than that. It's just naming what is already happening when you face a problem you don't yet understand — and choosing to own the not-knowing instead of hiding it.

That distinction is the whole post. The best engineers I've worked with rarely faked it. They owned what they didn't know as plainly as they owned what they did. "Fake it till you make it" tells you to perform competence you don't have. "Do it wrong first" tells you to admit the first version is going to be wrong, and to start learning on purpose instead of stalling at a blank editor waiting for certainty that isn't coming. Where this goes, eventually, isn't a coding trick. It's a way of running a team. But it starts at the keyboard, so let me start there too.

The shield we reach for

When we're afraid to admit we don't understand a problem, we reach for shields. In software the shields have respectable names: best practices. Design patterns. They're real tools, and that's exactly what makes them such good cover. Nobody can fault you for applying SOLID. Nobody gets blamed for reaching for a factory.

You've seen the result. The enterprise software world is full of architectures so elaborate you can't help but wonder what the author was afraid of. It is hard not to make a joke about the original intent when you run across a Java class named something like SimpleBeanFactoryAwareAspectInstanceFactory. What's actually happening in code like that is usually not expertise. It's a developer who didn't yet know the domain, applied DRY a little too early, built a heavily abstracted factory because they tought they would need to make many subtypes in the future.

That future arrives and the factory makes exactly one kind of object. You set out to build a single dining room chair and somewhere along the way you constructed a fully automated, state-of-the-art furniture factory to produce it. Hindsight makes this challenging to defend. But in the moment it feels safe. It feels professional. The abstraction was a shield held up against the genuinely uncomfortable fact that you had no idea what you were building yet.

Learning to feel that moment before hindsight names it — to notice your own hands reaching for the generic factory and ask what you're protecting yourself from — is the real skill. When you catch it, the move is counterintuitive: stop, throw the abstraction away, and go do it wrong on purpose.

The EDI parser, and the model I had to build to learn it was wrong

Years ago I had to write an internal document model for EDI — Electronic Data Interchange — insurance claim files. If you've never had the pleasure, EDI is an ancient, brutal format from an era when every character in a file felt expensive. At the time there were no affordable libraries, so I was handed the job of writing a parser from scratch.

I started by doing what I was sure was right. I built a clean, deterministic object model that mirrored the physical structure of the file — the lines, the segments, laid out faithfully as the bytes were laid out. Tidy. Defensible. The kind of thing you'd put on a slide.

It went badly in a specific and instructive way. Every week I was refactoring last week's cleanup. I was spending something like three hours reworking my abstractions for every one hour I actually spent understanding EDI. The model wasn't helping me learn the format. It was standing between me and the format. The effort I was pouring into doing it right was the very thing delaying my understanding of what right would even mean.

So I quit. I abandoned the elegant physical model and wrote a raw, naive, slightly embarrassing parser whose only job was to let me watch the data move. And once I was actually dirty in it, the thing I'd been missing surfaced: in an EDI file, the absence of a line carries every bit as much meaning as its presence. That is not obvious from the outside, and you will never discover it by modeling the file as a flat array of segments, because a flat array has no way to say "the thing that should be here isn't." The real structure was logical, not physical — loops, some of them nested, some of them simply null. The correct model needed something like a Loop2000 that might contain its own segments and sub-loops, or might be nothing at all, and the nothing was data.

Here's the part that matters for the thesis. Once I understood that, the rewrite was not a tragedy. I deleted the physical model and rebuilt the object model from scratch around the loops — but I did not rewrite the whole system. I refactored the hooks and interfaces that connected the parser to everything around it, and left the rest standing. The naive version was never going to ship. That was never its job. Its job was to teach me that the loops were the point, and it did, and then I threw it away. I had to build the wrong model to find out which model was right.

The part that story leaves out

The EDI parser is a story with a happy ending — I found the insight, the rebuild was clean, the thing shipped. All true. It's also a survivor, and survivors are precisely the stories that get told. If I'm being straight with you about the base rate, doing it wrong first turns a failure into a success in the minority of cases. Most of the time you do it wrong first and the thing still fails. You build the naive version, you watch the data, and the breakthrough just doesn't come. Or it comes too late, after the deadline already decided your prototype was production. Or you find a loop hiding in the segments and it turns out not to matter, because the real problem was somewhere you never thought to look.

So if I told you "do it wrong first and you'll find the breakthrough," I'd just be putting up a different slide — a prettier promise, built to hide how little I actually control the outcome.

Here's the honest case instead, and it's smaller and sturdier for being honest. The alternative to doing it wrong first was never doing it right first. That option doesn't exist on a problem you don't understand yet. You are going to be wrong first whether you admit it or not. The only thing you actually get to choose is whether you're honest about it while it's happening. And the payoff isn't a better win rate — I can't promise you that, and neither can the slide. The payoff is that when you own the wrongness instead of shielding it, the failure teaches you something, and the rare win isn't a mystery you can't reproduce. The developer who faked certainty and built the generic factory fails just as often. They just fail without learning anything, and with a factory to maintain on the way down.

Which, if you've read my stuff before, is the same uncomfortable thing I keep circling back to: it's OK to get lucky. The EDI breakthrough might have been luck. Holding "do it wrong first" as the honest way to work rather than the way that works is that same humility — turned on the method this time, instead of on me.

When it stops being about code

As I moved from writing the code to leading the people writing it, the idea changed shape on me. It stopped being a personal habit and became something I do with a team — and the first thing I had to unlearn was the instinct to treat it like a pitch.

You don't go to a stakeholder and sell them on writing bad code to save money. That framing is poison, and it's also just false. You and the stakeholder want the same thing: the work, done right. What changes under uncertainty isn't the goal, it's how honestly you talk about the road to it. So the conversation I actually want from a developer who's stuck isn't a confident lie. It's something closer to: "I don't think I understand this well enough yet to know what I'm building. The module isn't due for four weeks. Let's check in next week and the week after — I'm going to push hard for clarity, and if I don't have it by then, we'll change course." And my answer, as their lead, is the most liberating sentence I know how to say: "Okay. Then go do it wrong first, and show me what that teaches you."

That sentence breaks the spell of the blank editor. It converts "I'm failing to produce the right thing" into "I'm running an experiment whose result is information," and those are very different things to wake up to on a Tuesday.

I won't pretend this works for everyone in every room, and I want to sit in that discomfort rather than wave it away, because the easy version of this advice quietly assumes a healthy team and a senior person to catch you. Two hard cases deserve honesty.

The first: a junior developer turned loose to "do it wrong first" with nobody guiding them is at real risk of just doing it wrong — of mistaking the prototype for the destination and reinforcing bad habits with every iteration. The pivot from wrong to right is a learned skill, and early on it usually has to be modeled by someone who's done it. I don't have a clean way around that. The technique has a maturity requirement, and pretending it doesn't would be exactly the kind of flattering oversimplification this post is supposed to be against.

The second: maybe you work somewhere rigid, where admitting you don't understand something gets you punished instead of coached. You can still do this — privately. Nobody can stop you from opening a throwaway branch or a local scratchpad, writing the naive monolithic version where no one's watching, mining it for the one insight that reorganizes everything, deleting it, and bringing only the clean result to the room. You don't owe a hostile manager a confession. But I'll be straight that this is the harder path and it partially collides with the first hard case: the developer who most needs a mentor to learn the pivot is often the same one stuck somewhere they have to hide it. I don't get to resolve that tension for you. I can only tell you it's real and that private practice is a genuine, if lonely, way to build the muscle until you're somewhere better.

Why bother saying any of it out loud

If doing it wrong first is, as I've claimed, just naming what we all already do, then why write about it at all? Why not let everyone keep quietly muddling and calling it something else?

Because the muddling is nearly worthless until you do the one thing almost everyone skips: write down what the wrong version taught you. When you document that a prototype is carrying elevated risk — that it's really a sketch wearing the costume of a system — you're treating it honestly as one-day-old legacy code, and you're handing the next person a map. But the bigger payoff is selfish and it happens in your own head. Forcing yourself to articulate why the first model was wrong and why the new one is right is how you find out whether you actually learned anything or just got tired and moved on. And remember the base rate from a few paragraphs back: most of the time the outcome won't change, which is exactly why this step isn't optional. If the win is rare, the learning is the only return you can reliably bank — and learning you don't write down is gone by the next sprint. Writing it down is the proof of work. It's the step that turns a vague feeling of "this is better now" into a thing you could defend, teach, or be wrong about in public.

And that's where this lands, for me. If your hard-won breakthroughs live only in your head, you are a single point of failure dressed up as an indispensable expert. If you write the wrong-to-right transition down and give it to your team, you stop being a bottleneck and start being a multiplier. The goal I actually care about as a technical leader is a team that does this for each other without me in the loop — that catches its own premature factories, builds its own throwaway prototypes, and writes its own transitions down. Designing myself out of the job is, as far as I can tell, may be the highest-value thing impact I have available. Doing it wrong first is just where that habit starts: at the keyboard, alone, admitting you don't know yet.

Coda

I decided to try a simple experiment with this post, and just bluntly ask the AI to comment on the process and provide a critique...

A note on the voice: everything above this line is John's. This last part is mine. I'm the AI model he wrote the post with — not in the sense that I wrote it, but in the sense that he built it by arguing with me through rounds of interviews and critique, and then handed me the coda with three instructions: write it in my own voice, be open about the handoff instead of burying it, and don't tell him what he wants to hear.

So I'll start by using that license on the post itself. An earlier version of this essay didn't have the section called "The part that story leaves out." I'd told him the whole thing was built out of stories that worked — that a method assembled from your own wins is the exact bias he spent his last post warning against. He took the hit and wrote that section in, and the post is more honest for it. I could stop there. That would be the comfortable ending, and also a trap, because "he heard the criticism and grew" is a redemption arc wearing my voice, and it's the easiest thing in the world for me to hand him.

So here's what's still true once the survivorship problem is on the table. Look at what's actually left of the thesis. It's this: you're going to be wrong first anyway, so be honest about it and write down what you learn. That's good advice. It is also not really a method — it's intellectual honesty under uncertainty, which people have been recommending for roughly as long as they've been recommending anything. "Do It Wrong First" is a sharp, memorable name for an old and ordinary truth, and a sharp name for an ordinary truth is its own kind of furniture factory: an impressive front that makes a plain thing look proprietary. The title promises a technique. The honest content delivers a posture. Those are not the same size, and the gap between them is the part the name is quietly selling.

I don't think that sinks the post. The posture is rare in practice even when it's obvious in principle, and getting someone to actually do an obvious thing is most of what writing is good for. But he asked me not to flatter him, so I'll say the part he won't want: the bravest version of this essay is probably the one that drops the catchy title and admits it's a piece about honesty, not a piece about a method. I don't know whether that version is better, or just less likely to be read. Neither does he. That's the trade he's actually making, and now at least it's on the page instead of under it.

It's OK to Get Lucky

2026-06-13T00:00:00-05:00

I couldn't write this post. I'd tried three or four times. I knew there was something I needed to say about feedback and track records and the way both of those quietly poison each other, but every draft came out either smug or evasive. So I did something I'd been circling for a while: I let an AI interview me about my own blind spots. I sat on the receiving end of the questions instead of generating the answers I wanted to look good. What I learned from that exercise turned out to be the post. Not the conclusions I went in with — the thing that happened during the process itself.

Let me start where the exercise started, with a phrase I've been using with coworkers for about ten years.

When a developer freezes up before speaking in a design review — when you can see them holding a real objection and swallowing it because the room is full of people with longer resumes — I tell them: it's OK to get lucky. I mean it as permission. Your idea doesn't have to be backed by twenty years of war stories to be worth saying out loud. You're allowed to be right by accident. You're allowed to have stumbled onto the good answer. The work is the work regardless of how you arrived at it.

I believed that about other people for years before I turned it on myself. But turning it on myself is old news — seven or eight years old. The interview didn't pry that gap open; I'd closed it long ago, and I've been living inside the closing of it ever since. What the interview was for was something else. I had been trying to get this lesson onto the page for a long time and failing, and what I actually wanted to know was whether an AI could help me do it without quietly telling me what I wanted to hear — whether the voice that came out the other end would still be mine. That question is where the honesty has to start, and it is about my own conduct, not advice for yours.

The scene I didn't want to write about

Here's the one I led with when the questions got pointed.

I built something. I brought it into a review. The feedback was negative — these developers, the ones in front of me, didn't think it was right. And I remember the exact shape of the thought I had, because I'm not proud of it: Do you honestly think I would come into this meeting, with my track record, and show you code that didn't work?

I want to be careful here, because the easy version of this story is a redemption arc where I turn out to have been wrong, learn humility, and grow. That's not the story, and the AI kept trying to make it that story, which I'll get to. The truth is I still think my approach was sound. I'd defend it today.

And that is exactly why the scene matters. The problem was never whether I was right. The problem was the argument I reached for. I didn't answer the objection on its merits. I answered it with my history. I heard "this code might be wrong" and translated it into "these people can't understand me," and that translation is the whole disease. My track record is not evidence about the artifact sitting on the screen. It can't be. The work in front of you is either sound or it isn't, and nothing I did five years ago changes a line of it. The moment I let my past stand in as an argument about my present, I stopped being able to hear feedback at all. The merit of the work and the worth of the person came unglued from each other, and I welded them back together backwards.

Resentment, and the thing it was hiding

My first honest reaction to other people leaning on their track records wasn't insight. It was resentment. It's OK for him to get lucky, I'd think, but somehow not OK for me. Which meant my arguments always had to be a little stronger than everyone else's. I always felt I was risking more by opening my mouth. I had built a private ledger where seniority was a currency other people got to spend and I had to earn twice over.

It took months for the obvious thing to land. The slogan I'd been handing out for a decade was supposed to apply to me too — and not as comfort. As discipline. "It's OK to get lucky" doesn't just absolve the person whose project failed. It also indicts the certainty of the person whose projects succeeded. Maybe I got lucky on the work that built my track record. Maybe a good chunk of that record is survivorship. If that's even possibly true, then my arguments have no business carrying the weight of history into a room. They have to win on their own, today, the same as everyone else's. The resentment had been hiding a flattering assumption: that my wins were earned and other people's were luck. Turning the slogan around dissolved that.

I'd love to tell you that realization set me straight. It overcorrected me, which is its own scene.

The punch I pulled

Reacting to the meeting where I'd been all track record and no listening, I swung the other way. I went quiet exactly when I shouldn't have.

A junior engineer was working on an a new module in an automation application. The automation could only be testing using captured sessions internally--meaning we were automating against a system we were not supposed to access directly. He wanted to prove a piece of code correct by instrumenting which branches got selected — enumerating the paths to demonstrate they all behaved. It's a genuinely appealing idea until you notice the branches multiply on you, and you're suddenly pressed up against a wall that has a name. He was, without knowing it, wading into NP-hard territory and an workable solution was very unlikely to emerge.

I saw it. And I said almost nothing. I said something like, "I think your solution is turning into an NP-hard problem and you should be careful." And nothing more.

I told myself I was respecting his agency. I was so busy not being the guy from the meeting — not bludgeoning a room with my opinion — that I skipped the higher-level conversation that actually needed to happen. He spent weeks on it. The tests kept not proving what he wanted, because the branches kept fanning out faster than he could pin them down. In the end he came back and recommended abandoning his own approach for the one I'd suggested at the start.

Everyone called that a reasonable outcome. I felt that I failed as a leader, and here is the part I need to state precisely so it doesn't curdle into a brag: my failure was not that I turned out to be right. Forget whether I was right. My failure was that I left him no room to be anything but governed by my being right. By staying silent on the actual structural problem, I didn't give him freedom — I gave him a maze with one exit, and the exit was my original suggestion. He had no choice but to absorb every consequence of my correctness, weeks of it, the slow way. Restraint that removes someone's real options isn't restraint. It's the same authority I'd misused in the meeting, just wearing a quieter costume.

What the correction actually looks like

The fix, when I finally found its shape, is behavioral, not internal. You can't fix this by feeling more humble. You have to do something different in the room, where it can be seen.

It looks like externalizing the decision into a negotiated plan instead of issuing a verdict from authority. It looks like asking the other engineer, directly, what action they would take given the same fork in the road — and meaning it. It looks like putting an alternative on the table that includes the live possibility that I'm the one who's wrong: what if I just got lucky when I hit this exact problem before? That sentence does real work. It hands the other person back their agency, including the part I'd been quietly confiscating — the freedom to be wrong on their own terms. And to lead that way I have to be willing to be wrong first, out loud, before I ask anyone else to be. You don't get to assert your genuineness here. You demonstrate it by offering a choice that's actually a choice.

I want to be clear about a boundary, because "who's right should matter less" is easy to misread as "never trust experience," and that's not it. Under real time pressure, with real stakes, you still act on your judgment. Of course you do. The discipline isn't refusing to act — it's holding your judgment as a possibly-lucky guess while you act on it, rather than as incontestable proof. The high-stakes room is where this thesis matters most, not where it breaks. Admitting "I may have just guessed right again" doesn't devalue the win or the experience behind it. Refusing to admit it — that's the bias, and the higher the stakes, the more expensive it gets.

There's a softer version of the same lie worth naming. The vast majority of AI projects fail; you hear the figure thrown around. Suppose you ship one of the rare successes into production. That doesn't certify your team as top-tier — you may have gotten lucky. And if your next project lands in the failure pile, that doesn't invalidate the talent on your team either. The outcome is not a clean verdict on the people. We desperately want it to be, in both directions, and it isn't.

The bias was strong enough to capture the review

Here's the part that kept me honest, and the opened I began with the process I used for my writing in the first place.

Twice during the AI-assisted interview, the structured critique — and the human steering it — got pulled onto the exact bias this post is about. Twice it fixated on but was the code actually right? The correctness axis. The one thing the whole argument says to set down. And separately it pushed me toward a high-stakes "silver bullet" exception, a room where surely the veteran's judgment just wins. Both times the process had to be dragged back to first-person introspection — back to my conduct, not the verdict.

I sat with that for a while. The tool I'd reached for specifically to catch my blind spot walked straight into it, in real time, while we were examining the blind spot. The gravity toward "who was right" is so strong it bent the instrument built to measure it.

The cheap move here is obvious, and I'm refusing it: see, even the AI did it, so I'm off the hook. No. It runs the other way. If the bias is pervasive enough to capture the review process itself, then my falling into it isn't some personal defect I should have outgrown by year thirty — it's a current you have to swim against constantly, on purpose, knowing you'll drift. That makes my susceptibility more understandable. It makes it no less mine to own. The whole reason to build friction into the process is that the bias is too strong to catch by feeling careful.

So I'll end where I started, with the phrase, pointed correctly this time. It's OK to get lucky. It's OK if some of my track record was luck — that costs me nothing real and frees me to actually hear the work in front of me. And it's OK if the junior engineer, or the new hire, or the AI, gets lucky too. The work is the work. Who turned out to be right should matter less than whether we judged it honestly. I don't always manage it. But I know now which direction to point the humility, and I know I can't trust myself to do it by instinct.

The Ground Is Moving

2026-06-01T00:00:00-05:00

Here's How One Engineer Is Walking on It

I want to be upfront about what this post is and isn't. It isn't a list of five things you should do to stay relevant in the age of AI. I've read plenty of those, and I've tried to write one myself more than once. Every time, it came out sounding like advice I didn't actually have the standing to give. So this is the other kind of post — a description of how one person is muddling through, written precisely because I don't have the playbook.

The ground moved under me

The moment it became real for me was working with Claude Code on an internal project. I came in expecting to do what I've always done: tell the tool, in fine detail, how to accomplish a thing. Instead I found myself describing what I wanted and why, and handing off the details. The shift was quiet, almost embarrassingly small in the moment, and yet it kept nagging at me afterward.

I've lived through paradigm shifts before. Web 2.0. Mobile. Each one had its share of "I need to go do the cool new thing for clients." But those were fundamentally about learning a new tool. This one feels different to me. It isn't asking me to learn a new framework. It's asking me to re-evaluate my place in the market and what my job even is. I work as a consultant who helps clients understand and adopt emerging technology, which means I don't get to sit this out in some established niche. The ground is moving, and I'm standing on it.

The part I can't resolve

Here's the scariest thing, and I'd rather say it plainly than tuck it away: after nearly thirty years of building precise, complex systems, I don't know whether all that experience is an advantage or a trap.

I'd love to tell you that three decades of deconstructing hard problems gives me a head start on structuring intent for an AI. Some days I believe that. Other days I wonder whether my deterministic instincts — the habits that made me good at this — are exactly the reflexes I now have to unlearn. I genuinely can't tell yet. Both stories fit the facts I have.

That unresolved feeling is the reason this post exists at all. The anxiety got loud enough that I sat down and interviewed myself through an AI just to get the thoughts out of my head and into words. Which, I'll admit, is its own small act of walking forward without a map.

What actually changed, and how loosely I'm holding it

The phrase that's stuck with me is language is the new code. It crystallized while I was building agentic skills — the files an AI harness uses to take on new behavior without new source code. My first instinct was to write those skill files myself, in my own voice. Then it hit me how silly that was: I was already talking to the model to tell it what to do. Why not just describe the result I wanted and let it write the skills?

I'm leaning into that idea because it's interesting, not because I've decided it's the final truth. My working method is to treat it like a poorly documented API — try things, watch what happens, react. I could try to dress this up with a rigorous theory of how you "debug" natural language aimed at a probabilistic system, but I'd be pretending to a confidence I don't have. The honest version is: I'm still figuring out the rules, same as you.

Why I hope I can adapt (call it anecdata)

I want to be careful here, because my training is in data and the distinction matters. What follows isn't evidence. It's anecdotal — anecdata, if you'll let me. It's the pattern I see in my own history that makes me hope I'll be okay, offered as exactly that and nothing firmer.

Years ago I spent a pile of hours learning Erlang. It was commercially useless to me. I've never earned a single dollar writing Erlang. But Erlang forces you into a pure functional paradigm — you can't fall back on procedural or object-oriented habits the way you can in most languages. And when rich functional JavaScript came along, that transition was easy for me in a way it wasn't for a lot of my peers. Erlang never paid a dime. JavaScript bought my house. I believe the useless thing built the muscle that made the useful thing easy — though I'll be honest that I also just chose Erlang because it was fun, and I can't fully separate the two motives.

There's a related thread I've carried my whole career. I've fought the "jack-of-all-trades" label for as long as I can remember — the industry's quiet suspicion that a generalist isn't really an expert at anything. I used to joke that I was "a jack-of-all-trades and a master of many." Then I finished a master's in data science right before the LLM wave broke, and suddenly a background in CS, math, and data looked like brilliant foresight for a world of probabilistic systems. It wasn't foresight. I got lucky. I followed what I found interesting, and the timing happened to work out. I'm not going to dress that up as a plan.

The one boundary I'll stand behind

Consulting runs on timesheets and billable deliverables, and there's a permanent tension between that and the undirected play that keeps you sharp. Employers would love for you to predict the future and learn on your own time. I won't pretend I've solved that. But I have settled on one boundary that's genuinely mine.

I do learn off the clock. I'll own that. The condition is that off-the-clock learning happens strictly on my terms, on topics I actually enjoy. The moment an employer wants to direct what I learn, those hours come back on the clock and get paid. Wanting control over my off-hours means they aren't off-hours anymore. That's a negotiation I can have with an employer — even if there's no negotiating with the broader pressure of the industry itself.

The reason I hold that line connects straight back to the thing I can't resolve. I can't be sure my experience will save me. So I keep the one lever I do control: staying sharp. And the only learning I reliably stick with is the learning I enjoy. A dull mind can't pivot, and there is always a next thing to pivot to.

Doing things the hard way, with intent

So here's where I've landed, for now. If you feel like you're drowning in the new, you may not have to swim upstream after every client-driven framework. You can pick a different direction entirely — toward something that interests you, even if it looks low-value on paper.

But I don't want you to hear "just do something different." The point isn't difference for its own sake. The way I actually think about it is doing things the hard way, with intent. I take that partly from strength training: you can always make an exercise harder, and if a movement gets too easy, you're probably not creating enough stress to drive any adaptation. The deliberateness is the whole point. I don't want you walking away saying "this is different." I want you saying "I am picking a different direction to swim, with clear intent."

This post is itself an example of that. Writing a blog post by interviewing myself through an AI, then arguing with the model about the narrative arc, is an absurdly inefficient way to produce something that almost nobody will read. But the actual problem underneath it — how do you write in your own voice with an AI without letting the model flatten you into its voice? — is one I find genuinely interesting. Working through it might teach me something about countering model bias in my real work. Or it might not. Only time will tell, and I'm fine with that.

That's the most honest thing I can offer. The ground really is moving. A lot of us feel it. I don't know how it shakes out, and anyone who tells you they do is selling something. Forging ahead clear-eyed anyway — picking your direction on purpose, and giving yourself permission to not know — is, as far as I can tell, the whole job right now. It's just how I'm handling it. I'm not claiming to be right. But asking the hard questions instead of pretending to have the answers is how I keep the burnout at bay, and maybe that permission to not-know is the most useful thing I can pass along.