michael-dean-k/

welcome_ Welcome to the Essay Architecture development blog! You're getting this email because you've either expressed interest in, signed into, or used my editing software sometime in the last year (this list started from my How I Write episode with David Perell). Since then, I've been posting on my Substack, very preoccupied with an essay prize and anthology launch (and becoming a father), but I finally set up the infrastructure for a separate list dedicated to the app.

what-is-this_ While Substack is the home for my essays, this is the place where I'll share (1) new features and prototypes for you to try, and (2) the musings, mishaps, and epiphanies of a writer-builder. I plan to send this every Friday. If that's too much, you can adjust the lists you are subscribed to: my DevBlog list comes weekly, and my __Major Feature__s list will come every 1-3 months—you can opt-out here:

in-case-you-have-no-idea-what-I-am-talking-about.JPEG_

retro_ My editing tool, in its current form, gives you feedback reports: you upload your draft, it gives you a comprehensive breakdown of your craft, along with many suggestions. So far, many writers have said nice things about it (ie: "an AI coach that is not a sycophant," and "expert editorial LLM" and even "the best feedback on my writing I've ever received"). Also, though, it has some existential problems: (1) it takes 30 minutes to run 10,000 atomic evals, and then it gives you 100+ comments to sift through and manage; (2) it places too high an emphasis on scoring, especially when it's not perfectly calibrated (it's off by +/- 0.43 on average—accuracy is a hard technical problem, but one I'm still committed to solving). The fact that I find myself using Claude Code for feedback more than my own app is a sign that the form factor is off and the UX needs a rethink.

version-2_ In the last month or so I've been building prototypes, many of which helped validate the decision to rebuild instead of improve what exists. I've been able to make the feedback better, cheaper, and faster (from 30 minutes down to 30 seconds). These technical upgrades enable a totally different product, one that's less like a report tool, and more like an editor that you write/edit within. For example, now you can click a single pattern on the left (ie: Experience), and then quickly get comment cards in the right margin, so the feedback is immediately in context. What I release in the coming weeks will look something like this:

an-IDE-for-writing_ This UI excites me because it's not limited to the Essay Architecture framework, it can become a scaffolding for many types of editing tools. It aspires to be a lightweight "IDE for writers"; this stands for "integrated development environment," the software that coders use to code (ie: VS Code, Cursor, etc.). An IDE is a customizable space (a desk) that developers use to manage files, install plugins, annotate their text, view split screen, work in layers, etc. It's interesting to me that developers have very flexible environments, while most writers work within Google Docs, a rigid tool that has to be generic enough to not confuse the mass-market user. My vision here is to make a simple, delightful place to write—worth using even if you don't want to use any AI—that can evolve into an editing exoskeleton for a power user. To start, I'll be shipping Essay Architecture tools, but eventually I'd like writers to be able to configure their own.

the-vertigo-of-AI-coding_ It would not have been possible to build this all 6 months ago, but the pace of AI coding is continually shocking. When people say LLMs are dumb and stagnant, I imagine they aren't using desktop-based coding harnesses on top of their own files using a max plan. It took me about 15 months to build v1 of Essay Architecture, and now I'm confident I can ship a better v2 in 1-2 weeks. The nature of coding has completely changed too. In 2024 I was using AI to assist me in writing individual functions; now, I've (1) written a 7,000-word spec on the platform I want to build, and (2) built a "coding factory," an architecture of self-evolving agents that will build the whole thing for me. The plan: every Monday I'll draft my devBlog email along with a spec on what I want to ship that Friday; each morning I'll say "go," and each afternoon I'll test the updates and give detailed written feedback; then on Friday it gets shipped in this email.

build-for-yourself_ The north star of this new phase is to build the place where I personally think and write essays. So much software is built for the mean of a TAM, and so it's safe and visionless and never quite addresses what any given user needs. Google Docs is suited for meeting minutes, not longform creative writing with multiple restructures. I now feel electrified to answer this question: "What innovations in our text editor UI/UX can help unlock the creative process?" I figure that is a rich enough space to explore that it deserves its own newsletter, so here it is.

say-hey_ I'd love to hear from you, so please reply directly to this email. How does this land? What prevents you from shifting into a new writing tool? What is a feature you've dreamed of, that if it existed, might get you to try it? There's a fair chance your reply might be baked into what I share next week.