michael-dean-k/

Topic

claude-code

9 pieces

Catastrophic bug

· 284 words

Claude Code just deleted all the files in my writing folder from 2026! All I wanted it to do was rename file names so we have a consistent dating format—YYYY.MM.DD-title-title.md to YYYY-MM-DD_title-title.md—but it thought the simplest way to do this was to write new files with the new file name, and then delete the old ones. That is fine, except there was a bug in the renaming script, causing it to name every file “.md”. This means instead of making 21 new files, it kept rewriting the same file, so all the data was deleted except the last one.

Catastrophic bug — the mv loop produced the same target name for every file because BASH_REMATCH doesn’t populate in zsh. I overwrote 20 files. Stopping immediately to recover.

This is bad. I need to be straight with you: What happened—My bash script used ${BASH_REMATCH[1]} for regex captures. That works in bash but not in zsh.(your default shell on macOS), where the captures live in $match instead. Every iteration produced an empty target name —.md, and each mv overwrote the previous file at that name. Result: 20 of your 21 logs were destroyed. The surviving —.md contains only the content of 2026.04.15.institutes-vs-institutions.md (the last one processed).

This happened despite the guardrail I put in my CLAUDE.MD file: “NEVER delete or overwrite existing log entries, daily pages, or essays.” In this case, it didn’t think it was deleting, but following my command to rename. Fortunately, I had that same folder backed up to Google Drive (and most of them were on Substack anyway), but still, I’ll now be extra cautious with file operations.

michaelDank.com

· 226 words

I was able to launch this website in <15 minutes. The setup is local and simple. I have a /writing file in my Obsidian vault, and then subfolders for /code, /publish, /working. /Code holds the site design, /publish my archive, and /working files have .gitignore to not push templates and notes and such. Claude Code handles the website, and different skills help me manage tags, do the menial ops stuff, and push to the Internet. All I have to do is sync a single folder to Github, and the changes are live (hosted on Netlify for free).

Compare this with my first website prototype. I was endlessly iterating on designs and fonts, and thought that I had to organize, filter, and polish my five year archive before I could get started. Probably spent hours on it before burning out on the haul. With this second version, the principle is essentially, "if it doesn't immediately produce something of long-term value, it's not worth systematizing." Now the approach is to move forward here, and slowly fill in the backlog as I'm inspired.

No need to widely share this yet. I'll make little changes day-by-day until it becomes my main place. So many things to consider. For example, I decided to add an initial on the name ("michael-dean-k"), but without hyphens ("michaeldeank"), my wife confused me with "Michael Dank."

Heuristics for systems

· 526 words

I declared to my wife this morning that DeantownOS is getting retired. It’s been 3 months since I spiraled into Claude Code for personal systems, and I’m at the point in the curve where the amazement has normalized and I’ve accepted the fact that I’m in a trough of disillusionment. The question now is revise or abort.

The case for aborting ties back to Oliver Burkemann’s Four Thousand Weeks, which popularized the idea that all systems are methods to procrastinate from making hard decisions. They give the illusion that you can do everything, and since AI can meaningfully leverage the volume and range of things you can do, it tempts you to build galaxy-brained systems. The thing I think we fail to realize while in a vibe coding frenzy is the psychic cost to remember and maintain the stuff you build. Yes, it is appealing to “reclaim my computer” and rebuild everything I use as personal software (from Obsidian to Gmail), and it’s even possible, but it’s a new breed of Sisyphean struggle. Once you can mold your own software around you, it’s too easy to endlessly mold, to lose sight of the work and just tinker on your exoskeleton.

I’m obviously skeptical, but I’m still a believer; if I were to revise, to rebuild my Claude stack from scratch, I would have to develop a few heuristics to help me from short-circuiting.

The first one that comes to mind is “will this matter once I’m dead?” Ie: writing an essay matters, because I imagine one day my daughter will read that and get to know me better, or at the very least, future Me in 35 years may enjoy reading words of my past self. But to create detailed daily files that get spliced into atomic “routing files” that then then get saved again to a new destination folder, which exist either as (a) just context for AI, or (b) require some manual effort to prune into something that matters once I’m dead, is to create waaaay too many layers of abstraction between the source and the Work. When I read back my writing from the last few months, only a small is valuable enough to be saved as "logs" in my archive. I was writing for AI, not for my future self.

I made this assumption that atomic daily files are the kernel of a system, and it was an axiom I could never undo. There’s maybe another principle on “don’t build load-bearing infrastructure on an unproven axiom.”

Another one could be “don’t assume future you will have bandwidth,” to do X every day/week/month. Every day I had to review how my AI system proposed to route my logs, and eventually I'd ignore it and get backed up. This means that if something isn’t truly automated, I should be very cautious of it. It's possible to do one little step forever, but not a hundred. Not every promise has brush-your-teeth-scale reliability.

What I’m getting at is that it’s not about maximizing or neglecting systems, but about understanding the right principles so you build something that is actually in service of your life.

Opus entitlement

· 234 words

I’m starting to feel the Opus 4.7 annoyance. Everyone has been complaining, and I told myself I’d be patient, but now I'm here watching Codex tutorials. 2 weeks ago I was able to effectively one-shot a Google Docs prototype in ~10 minutes with Opus 4.6. This sets the standard for what’s possible, and when that is ripped away, even 10% of it, it feels like theft, even when it’s still 2,000x faster than coding by hand. It’s easy to blame the model, but really AI coding has so many variables, and you can never really know the source of what shifted. Yes, it’s a new model, but also this time, I’m (a) deploying into an existing codebase instead of doing ground up; (b) the spec is far more detailed; (c) the whole factory has been redesigned. That’s four variables. It’s easy to not take the blame, put it on Opus, and then convert back to 4.6, but that itself is a change with unknown consequences. Was 4.6 nerfed too? The truth is we’re building systems on top of quicksand, but actually that’s not so novel because people are quicksandish too, always evolving, changing incentives, dreams, and abilities, totally variable day-to-day depending on if they slept or if they’re in a fight or not. We expect these machines to be deterministic (and use language like “factories”) but the cost of agency is a less determinism.

Systems skeptic

· 380 words

I don't know if I buy the quote: "you don't rise to the level of your goals, you fall to the level of your systems." (And this is coming from a systems guy.) It's a beautiful piece of rhetoric. The rise/fall structure. The humility to stay grounded. But I just think when you really want to make sense of how to pull off hard things, it should be a little complex, a little more than what can be packaged into a meme.

Two opposite things need to happen at once: top-down destiny forging, and bottom-up monk-like routines. It's a negotiation: "What will I want to complete in 100 days?" is a very different question from, "What should I be doing today?" and you can try to force alignment, but that's not always easy, because what you feel like doing often diverges.

The quote above simplifies this whole dance into a blind trust in systems. A system is a servant, not a master! I write this to remind myself as I'm immersed in probably one of the biggest system rebuilds in my life (one where I'm suddenly able to fluidly create the containers I work within) ...

It is wild to think that probably 50% of my computer use these days are within GUIs I've designed for myself. To me, liquid GUIs are a bigger deal than autonomous agents. My whole conception of what personal computing can be is changing very fast, and it becomes alluring, almost addicting, to continuously evolve my own OS, to see what's possible. It's very easy now to get tangled in knots of systems and software that are all very impressive, lead nowhere, and become chores. What leads to aliveness, to your intentions?

An emerging maxim for me is to start with the goal and let the system emerge around it; otherwise, you feel the cold of the infinite tinker, especially if you are quarantining in the attic from COVID and you can't go touch grass because there appear to feet of snow outside and you are too achey to shovel out your car to go anywhere and so one way to relax when you're sick is to live-clone all incoming Substack posts into local JSON folders and redesign a better algorithm. But to what end?

SNAKEPIT

· 139 words

You guys said you like snakes, so I built SNAKEPIT: Every dot is a log from last year (so 408 mini-essays), and when they collide, they combine into a new snake that is +1 in length (told Claude to “use traditional snake physics”). Next step is to have it generate new logs based on combos, making this like a petri dish for idea sex, where most mutations are slop, but some could be unexpected/interesting. Step 2 is to make it an experimental open blog, where anyone can upload ideas. Step 3 is to give the snake a sense of smell using vector embeddings, so it’s not just random, and they sniff towards related ideas. Step 4 is to build a Substack Notes integration, so instead of finding writing through an engagement-ranked feed, we find writing through snakepit.

→ source

Deantown OS

· 211 words

Weird post-midnight project: built myself an operating system. Not really, but really. It's just an app that finds all the other apps I've built in my 80_code folder, but then displays them as icons in a Mac dock + desktop GUI. It’s an easy way to see/use/remember what would otherwise be scattered. Lots of weird features, like the clock changes to a random time every 0.5 seconds, and instead of the date it tells me how many thousand days old I am. If you click the "Fun?" toggle, it lets snakes loose. What's trippy is I also built a multi-tab terminal inside of it, so I can Claude Code to code the code I'm coding (actually writing 0 code). Seriously though this is becoming my Notion replacement, a place to write/plan/do, except with complete interface flexibility, and all-local data. Currently writing this note from within the OS. The unlock for me was in realizing the power of local data over cloud apps. Feels like owning vs. renting. When you have everything in a single sandbox on your computer, you can spawn interfaces to help you with anything, and they can be far more idiosyncratic than anything you'd ever find in a mass-market product. Notion doesn't have snakes.

→ source

Makers and the Managerial Goon Loop

· 390 words

Paul Graham’s idea of makers/managers is helpful when thinking about AI agents. The cost of being unreasonably productive is that all your time will go into management. I’ve heard people celebrate this, as if elevating above the work itself and only making high-leverage decisions based on taste is the place we want to be. Disagree. Without actually being in the weeds and making thousands of unbearably slow decisions, you won’t develop taste, and (probably) won’t be a great manager either. I guess the ideal (for me) is to be in maker mode as often as possible, and then let my synthetic managers come in to process my deep work. (Currently have a “proseOS” where I can riff 5k words into a daily note, and then agents come in to route my logs to different interfaces). Ideally, you build the manager once and forget about it. But realistically, a maker can find fun in making manager bots and management apps, and it’s quite easy to slip into a managerial goon loop. What I mean is, similar to masturbating with no intention of ever finishing (aka gooning), it’s very possible to make your own task manager app, and a writing app, and an idea Kanban linked to Obsidian, and why not a new personal website, and a 1,000 day calendar because you can, and seriously anything you can think of, and it’s very possible to just numb out over how unbelievable it is that code, markdown, and interface are now liquids that shape around your every intention, but actually, you never quite finish anything. PKM procrastination is timeless, except now it’s multiplied to new levels. The brute velocity of execution means you’re bound to make many little mistakes, which eventually compound into your own megamachine that traps you with endless bugs and feature ideas and system decay. This is all quite dramatic. I love Claude Code and insist everyone IRL and IFL try it. But now that it’s shockingly trivial to build your own personal software for free, I imagine there will be all sorts of unanticipated psychic costs. For one, it’s dangerous if building your own tools is equal to or more fun than the work the tools are for. I’m sure that wears off. But I generally think this all leads to both extremes: individuals who are unbelievable prolific, and individuals stuck in a goon loop who feel unbelievably prolific.

→ source

The myth of canonical docs

· 109 words

The “wasted time” in AI-generation is generating reports and “canonical documents” that you think your future self will need, but will possibly never use. However, I think the core difference is that these documents have a way of compounding that is automatic in a way that second brains never did. Meaning, yes, I generated 8 documents on babies, but the 9th one, can be based on the thinking in the first 8. Shed the original, but maybe 9 is something like a core “README” that shapes all future interactions. That’s the thing. Through writing you are developing a particular lens that is not just sitting there, but being accessed.