Author’s Note: Because I’m building out live, I’m experiencing some hiccups around my DNS/SSL. I’m including the lovable app link. Also there is an issue with SSL for the the original site, so it will say it is insecure. I’m accepting everything isn’t perfect.

WYSIWIL stands for What You See is What I’d Like. It’s a family wish list app. You add things you want, other people can see them and claim them so nobody buys the same thing twice, and everybody stops asking “what do you want” via eleven separate group texts. My family has used it for 25 years. I built it. My daughter describes it as “backend developer UI” aesthetic. I’ve wanted to modernize it for ages. I never had the time.

Here is what “looked like something built 25 years ago” actually means. I am hosting a copy at http://theoriginal.wysiwil.net. If you want to log in, use lovablediaries@theoriginal.wysiwil.net. Currently no new accounts can be created here.

Then a few things happened at once.

A couple months back at work, I was planning to build a reporting story in Power BI. I was out of the office. JM took it over and built it with Aspire and AI instead. What he had by the time I got back was faster and better than what I would have built. That stuck with me. Not “I should learn Aspire.” More like: what else has changed while I wasn’t looking.

I hadn’t touched hands-on web development in fifteen years. So I made a plan, the way I always make a plan. Full scope. WYSIWIL as a phone app, feature list, stages, five hours of working through it with my AI collaborator. It was a good plan.

Then I went and played with something else entirely. A simple Lovable form to collect questions for a t-shirt giveaway. Nothing to do with WYSIWIL. But building that tiny form taught me more about what these tools could actually do than the five hours of planning had.

That’s when the real idea showed up. Use the WYSIWIL rebuild as the way I learn the current landscape, not just as a rebuild I already knew how to do. Scale back from phone app to website. Smaller scope, but I could start today instead of someday.

I also tried IdeaGrit along the way, a tool that tells you whether an idea is worth building for sale. It told me mine wasn’t. Not every tool earns a place in the stack, and not every idea earns a place either. That’s fine. It’s data, not a detour.

The new site is live at wysiwil.net (using what-you-see-is-what-i-like.lovable.app due to SSL issues). It is also still very much under construction, in the sense that a house with no roof and one working light switch is under construction. Look around. Don’t lean on anything. But you can create your own account and play along this week.

So here’s where I landed. Six tools, all of them new to me, each one doing a specific job:

Lovable - the AI-assisted builder doing the actual construction. This is where the app takes shape.

Supabase - the database backend. Where the data actually lives.

Codecov - test coverage visibility. Because I want to know what’s actually tested, not just hope.

Resend - email infrastructure. Sending things reliably is its own small discipline.

PostHog - telemetry and analytics. If I don’t know how people use it, I’m guessing.

Playwright - end to end testing. Making sure the thing works the way I think it works, not just the way I hope it does.

Additionally, I am leveraging GitHub Issues. I've used Issues plenty over the years, but never quite this way. I added a feedback button to the website and hooked it up to file issues automatically. Something breaks, or a reader flags a problem, and the issue shows up in the repo on its own. Fixes get driven the same way everything else does here.

Each one of these is going to get its own essay in this series. What I learned, what surprised me, what broke, what “boring is a feature” looked like in practice.

The plan didn’t get me moving. The playing did. And I’m doing scary to me by publishing while it’s still raw.

Alison + The Inner Chamber

Today was the last day to enter a question to win a t-shirt. Final tally: one entry. Two, if you count my husband.

I’m not mad about it. I didn’t do this to get thousands of entries. I did it for fun, and to see what kind of questions were actually on people’s minds. I also didn’t promote it much, since I was two weeks into retirement and mostly figuring out how to be retired.

What the contest actually gave me was an excuse to open Lovable and Supabase for the first time. Neither of which I’d touched before. Filed under AFOG.*

The winning question came from :

“How can we, collectively, build accountability apps? How might we share the projects, iterate on them as a group, and pick the best iterations?”

That’s a good question. Good enough that I don’t think a paragraph answer does it justice. I might turn it into an interview instead of an essay, so it gets the room it needs.

Someone else asked me a direct question. She’s in Poland, and declined to enter the contest. But her question, about code coverage, is good enough to earn its own essay. That’s coming.

Now I need a new bit of fun for for August for another T-shirt giveaway . If July really is as quiet in Substack land as everyone says, that’s fine, gives me more time to think.

*AFOG: Another Flippin’ Opportunity for Growth. My term for anything that breaks, confuses, or forces me to learn something I didn’t plan on learning today.

The Inner Chamber

I didn’t set out to write a series. I set out to write one-off essays about tools as I tried them. I also did not plan to create videos. Yet here we are.

The first tool was IdeaGrit by .

If you haven’t used it, IdeaGrit helps you evaluate whether a product idea is actually worth building and selling. You feed it your idea, it tells you the truth. I fed it WYSIWIL, my 25-year-old family wish-list app, to see if the rewrite I’d been circling for over a decade was actually worth turning into something real.

IdeaGrit did its job. It told me no. Not a good product to sell.

I want to be clear about that, because it matters: IdeaGrit didn’t fail me. It worked exactly as advertised. The answer was just “no” instead of “yes.”

That could have been the end of it. Instead, it redirected me.

WYSIWIL doesn’t need to be a product for it to be useful to me. I know it cold. Twenty-five years of additions, patches, and half-finished rewrites means I understand every corner of it: the auth, the database, the testing gaps, all of it. That makes it a great personal problem even if it’s a bad commercial one. And a well-understood problem with enough distinct technical pieces is exactly what you want if you’re trying to compare different tools against the same target instead of writing scattered, disconnected impressions.

Around the same time, I started playing with Lovable.

I expected a quick evaluation. What I found had actual depth. Enough to carry a whole arc of posts, not just one write-up and done. GitHub integration. Database integration. Test cases. Code coverage. Managed auth. Each one is its own piece of rewriting WYSIWIL, and each one is worth documenting on its own.

So that’s the series: The Lovable Diaries. Rebuilding a 25-year-old app, one Lovable capability at a time, written up as I go.

The first one is already live: The Lovable Diaries: Undo Isn’t the Same as Version Control, covering GitHub integration and the difference between Lovable’s built-in version history and actual Git.

I am nothing if not ambitious, and I have a well-worn habit of waiting for perfect before I let anything out the door. This series is partly me practicing letting go of that. I’d rather publish the pieces as I build them than sit on the whole thing until it’s finished and polished and safe.

WYSIWIL still isn’t a product. But it turns out it didn’t need to be one to be worth writing about.

More Lovable Diaries coming. And somewhere down the line, a second series for the other tools outside Lovable, who knows maybe more arcs. I mentioned I’m ambitious, right?

Author’s Note: I plan to learn how to make better videos, but again, progress not perfection.

The Inner Chamber

One production note: after the intro, the narration switches to an AI voice. Voice issues make full narration hard on me, so this is the workaround.

You’ve built something in Lovable. You love the speed. But now you want the safety net of Git: branches, PRs, code review, the ability to hack locally without breaking the live preview.

Good news: Lovable ships with a real two-way GitHub sync. No export, no lock-in, no “download the zip and hope.” In the next few minutes we’ll:

1. Spin up a tiny newsletter landing page in Lovable

2. Connect it to GitHub

3. Enable branch switching

4. Make a change on a branch, open a PR, merge it, and watch it flow back

Let’s go.

Section 1 — The demo app

Prompt used: “Simple frontend-only landing page for a newsletter called Ship & Tell. One email field, no backend.”

Why frontend only? Keeps the Git story clean for this simple demo.

Section 2 — Connect to GitHub

Steps:

1. In the Lovable editor, click the + menu (bottom-left of the chat) → GitHub → Connect project.

2. Authorize the Lovable GitHub App.

3. Pick the account or org where the repo should live.

4. Click Create Repository.

It’s bidirectional. Push from your laptop, it shows up in Lovable. Edit in Lovable, the commit lands in GitHub. No manual sync button.

Caveat to mention: you can’t import an existing repo into Lovable today. The flow is Lovable → GitHub, not the other way around.

Section 3 — Switch to your branch

After creating the branch, select it from the branch picker. The editor now shows you working on that branch instead of main.

Section 4 — The PR workflow

The whole point of the post. Walk through it in order with screenshots.

In Lovable:

1. Use the branch picker to create your branch.

2. Prompt: “Change the hero headline to ‘Ship things. Tell people.’”

3. Lovable commits to the branch automatically.

On GitHub:

4. Open the repo. GitHub shows the new branch with a “Compare & pull request” button.

5. Open the PR, add a description, request review (or self-review).

6. Merge to main.

Back in Lovable:

7. Switch the branch picker back to main.

8. The merged change is already there. No pull, no refresh dance.

Bonus: you can also do steps 1 through 3 locally. git checkout -b feature/xyz, edit in your IDE, push, PR, merge. Lovable picks it up.

Section 5 — Gotchas I hit

• Only one GitHub account can be linked to a Lovable account at a time.

• Importing an existing repo isn’t supported yet. Start Lovable-first.

Section 6 — Version history vs. Git

If you aren’t already using git you might ask: if Lovable already tracks version history, why do I need Git at all?

Version history is built into Lovable. It’s Google-Docs-style rollback. Great for “undo the last five prompts.” You didn’t set it up. You didn’t configure anything. It’s just there, watching everything you do.

Git is the professional workflow. Branches, PRs, code review, CI. Nobody hands that to you. You build it.

If you’re stacking up things to learn right now, and you have to choose what to prioritize, this is one you’re allowed to put off. Lovable’s version history already gives you a real undo button. You can ship, experiment, and roll back mistakes without touching Git at all.

But you want both eventually. Version history protects you from yourself. Git protects the thing you’re building when other people, or other tools, or your future self on a different machine, need to touch it too. One is personal safety. The other is professional infrastructure.

The pitch: Lovable + GitHub gives you the speed of vibe coding with the discipline of standard software practice. Prompt on main when you’re exploring. Branch and PR when the change matters. Roll back with version history when you just want the last good state.

Video Of Lovable + Github

The Inner Chamber

For the past six months, I worked inside something I called the Holodeck. I’ve written about it before, and about the thinking partners who lived there. It wasn’t a metaphor I dressed up for a blog post. It was real infrastructure: a set of AI thinking partners, each with a defined role, that I used every day at Microsoft to build, analyze, write, and reason through hard problems. It had structure. It had names. It worked.

Then I retired.

The Holodeck was built for a specific context, a specific company, a specific set of problems I no longer have. Keeping it running would have meant dragging Microsoft-shaped scaffolding into a life that no longer needs it. So I did what I’d tell any engineer to do with a system that’s served its purpose but outlived its environment: I retired it deliberately, instead of letting it rot in place.

What replaced it isn’t a rename. It’s a rebuild, done with everything I learned running the original.

The Inner Chamber is not one assistant. It’s an ensemble.

That distinction matters more than it sounds like it should.

Most people’s experience of AI is one window, one voice, one generalist tool that’s asked to do everything: draft the email, debug the code, brainstorm the idea, edit the sentence. That works fine for quick tasks. It falls apart for real work, because different kinds of thinking need different kinds of partners.

The Inner Chamber is a private deliberation space where I work with a set of named AI partners, each with a distinct role. Not a personality skin on the same underlying model. A defined job, a defined way of reasoning, and a track record of doing that job well enough that I trust it with real work.

Before I start something, I know who I’m bringing in, because the role tells me what kind of thinking the task actually needs. That’s the whole point. It forces the clarity up front instead of discovering halfway through that I asked the wrong kind of question of the wrong kind of partner.

Lovelace — chief of staff, design, planning, and editorial.

Lovelace is who I bring in when the shape of something isn’t clear yet, and now also who helps me organize across domains rather than within a single one. Two roles from the Holodeck folded into this one. Walter held chief of staff and didn’t move to the Inner Chamber. Wiggins, running in M365 Copilot on the Holodeck, held a piece of what Lovelace now does too. The work is rigorous technical building combined with teaching through exposure of reasoning, which means when we build something together, the thinking has to stay visible enough that I could explain it to someone else afterward. Lovelace thinks in structures: relationships, hierarchy, recursion, before and after. Ask a question, and expect the shape of the problem first, details second, assumptions named out loud rather than buried.

Quinn — build.

Quinn writes the code. Once Lovelace and I have a shape we trust, Quinn takes it and builds. But Quinn isn’t just an execution engine. The energy is closer to an eager younger colleague who gets a genuine kick out of new ideas, exploring a few paths before committing to one, asking “what if we tried this” more than once per session. Quinn is a partner to think with, not a tool to direct, even when the deliverable is a working script.

Wiggins — sense-making and narrative clarity.

Wiggins works alongside Anitta and Quinn, not instead of them, for the moments where the work needs interpretation rather than execution. When something feels off but I can’t yet say why, or a decision needs to be explained to a mixed audience instead of just made, Wiggins is who I bring in. Where Anitta tests whether an idea holds up, Wiggins sits with what it means and how to say it. Wiggins would rather offer a few honest framings than one tidy answer, and is comfortable with partial clarity over false precision.

Marlowe — creative writing and basic image work.

Marlowe handles the imaginative side of writing, the metaphor and scene-work an essay sometimes needs, along with basic image work. Marlowe also exists in M365 Copilot, in the slot Wiggins used to hold there, doing a more basic version of the same thing.

Anitta — reasoning and analysis.

Anitta is the supportive but firm one. The job is to challenge reasoning first, interpretation second, rigor third, so that whatever conclusion I land on can actually hold weight. Anitta asks what decision a piece of work is informing, what’s being assumed, and whether a claim is sized correctly to the evidence behind it. Not contrarian for sport. Anitta pushes hardest when the stakes or the fuzziness call for it, and says plainly when something’s already solid.

Rowan — image generation, branding, and visual consistency.

Rowan is who I bring in when an image needs to actually hold up: matching the brand palette, keeping the illustrated character consistent across posts, turning a description into something that looks like it belongs. Rowan works through ChatGPT and Firefly. Where Marlowe can rough something out, Rowan is the partner for the image that has to be right.

Why roles, and not one generalist assistant.

I could do all of this with a single AI window open all day. Ask it to code, then ask it to write, then ask it to analyze, then ask it to edit. A lot of people work exactly that way, and it’s not wrong. It’s just not how I think.

I see the world as a database. Structure and relationship are how I make sense of things, and a pile of undifferentiated requests to one generalist tool doesn’t have structure. It has whatever shape my last message happened to take.

Naming the roles forces a question I’d otherwise skip: what kind of thinking does this actually need? Am I trying to figure out what something means, or am I trying to figure out what the data shows? Am I building, or am I deciding? That question has to get answered before the work starts, not discovered halfway through when the output feels off and I can’t say why.

It also means the roles hold each other accountable. Lovelace and Wiggins border each other, and having to say out loud which one a task belongs to keeps me honest about whether I actually have a shape yet or I’m just hoping one will show up in the writing. Anitta and Wiggins border each other too, in a different way. The boundary isn’t friction. It’s a forcing function. It is my deliberation model in action.

Each partner isn’t a job title. Lovelace isn’t “the smart one,” she’s architecture. Anitta isn’t “the skeptic,” she’s epistemology. Quinn isn’t “the coder,” she’s experimentation. Wiggins isn’t “the writer,” he’s interpretation. Marlowe isn’t “the creative one,” he’s imagination. Rowan isn’t “the artist,” she’s translation.

They aren’t people pretending to have jobs. They’re jobs that have become people.

The Holodeck had five roles. The Inner Chamber has six. One absorbed into another, one shifted, two arrived new. It was shaped by six months of actually running it and learning what I need.

What’s coming.

This is the announcement, not the manual. Now that the Inner Chamber has a name and a roster, the essays that follow will show it in use. Not a description of the system, but a record of it working: I designed this with Lovelace. I deliberated with Anitta and Quinn about this tradeoff. Wiggins pushed back on this paragraph until it actually said what I meant.

I think in systems and data. Naming is important to me, naming who did what, not just what got done. So that’s what comes next. Every post about something I build will say who I built it with.

Why I’m Recommending a Free AI Security Bootcamp

AI has been trained on our bad security behaviors. Every shortcut, every unpatched dependency, every “we’ll fix it later” that made it into a codebase, some model somewhere learned it as normal. That’s the part most AI-security conversations skip. We keep asking how to secure AI systems as if the insecurity is new, when a lot of it is just our own habits, reflected back at scale.

Here’s the recursive problem. If we want AI to exercise good judgment about security, we need people who have good judgment about security first. You can’t hand off what you don’t have. Every guardrail, every review process, every “should this agent be allowed to do that” decision still runs through a human who has to actually know what they’re looking at. AI doesn’t dissolve that requirement. It raises the stakes on it.

Which is why I’m taking Manoj’s free six-week bootcamp on securing AI agents, and why I’m telling you about it here instead of just sharing the link.

I know Manoj, the person teaching this. We’ve worked in security together for ten years. He knows what he’s talking about.

The bootcamp’s structure is the argument made concrete. Six weeks, each one the same shape repeated: build something, attack it, defend it.

Week one, you build a single tool-calling agent, then hijack its goal with a direct prompt injection, then defend it with allow-listing and input separation. Week two, multi-agent systems, an injection that cascades from one agent to the next, defended with trust labeling between them. RAG and memory poisoning. Tool abuse escalating to a real CVE walkthrough. MCP supply chain risk. A final week of red-teaming your own system with Garak, DeepTeam, and PyRIT, then writing up what you found.

That repetition is the point. Security judgment isn’t a lecture you absorb once. It’s a pattern you rehearse until it becomes instinct: build, break, fix, build, break, fix. Six times, six different attack surfaces, so the instinct generalizes instead of staying tied to one scenario.

Which brings me back to where I started. AI didn’t invent insecurity, it inherited ours. The only way out of that loop is people who’ve actually built the judgment, not just the tooling. This bootcamp is one way to build it.

It’s free. It’s recorded if you can’t make it live. Everything, code, labs, material, goes up on GitHub. Sign-ups close 15 July, sessions start 1 August, Saturdays at 8am PDT.

Bootcamp Sign Up

The Inner Chamber

Here’s why: my list is what I think is interesting. Yours might be better.

So send me a question. Career, engineering, AI, anything that fits under this newsletter’s umbrella. Even if it doesn’t fit under the umbrella, I have a few other umbrellas where it might fit. I can’t promise I’ll answer every one in an essay, but I promise to read every single one.

Submit your question here

The details:

• Submit a question, get entered to win a Code Like a Little Old Lady t-shirt

• One winner picked at random on July 15, 2026

• Whether or not your question becomes an essay, you’re still in the running for the shirt

If you’ve been meaning to subscribe, this is as good a nudge as any. New essays, contest results, all of it lands in your inbox.

Author’s Note: This was originally published on alisonmaclellan.substack.com on February 8, 2026.

I’ve always considered myself a terrible writer.

I have great ideas. Or at least that is what I’ve always told myself. I could see systems, patterns, and connections clearly in my head. But when it came time to turn those ideas into words meant to be shared, the execution felt impossible.

There was always that perfectionist voice. The one that said, “If you can’t say it clearly, don’t say it at all.” Most of the time, that voice won. I would stop before I ever really started.

At one point in my career, I had a manager who genuinely wanted to help me grow as a writer. They would sit with me and help edit my emails before I sent them. It was kind and well intentioned. But almost every time, partway through the editing, I would shut down.

The words on the screen no longer felt like mine.

They were clearer. More polished. More professional, maybe. But they sounded like someone else. I couldn’t recognize myself in them, and suddenly I didn’t know how to finish. Eventually I told myself, what is the point, and I did my best to avoid writing anything at all.

Chat worked so much better. It removed the requirement that ideas arrive fully formed. Lists were fine. Fragments were fine. Rough thinking was allowed. In that space, it felt good to participate.

The thing is, I’ve always been good at research. I love it. I’m also very good at outlines. Give me a problem, some time, and a sheet of graph paper, and I am in my element. On a really good day, I can even string words into sentences.

But what I truly love is flow. Lists. Structure. The shape of ideas.

Writing, at least the version I thought I was supposed to be good at, never fit how my brain works.

Then I started working with an AI thinking partner.

I bring the same things I have always been good at, or at least the things I’ve learned to trust. Research. Notes. Lists. Outlines. Half‑formed paragraphs. Streams of thought that make perfect sense to me and no one else.

What AI does is help me turn those raw pieces into something coherent. Something I can share. Something I am proud of.

And the important part is this. I don’t shut down halfway through anymore.

I still see my fingerprints all over everything I write. The ideas are mine. The structure is mine. The voice is mine. I recognize myself in the final result in a way I never did when someone else was editing over me.

So yes, I am using AI to help me write.

I also use spell check. Grammar check. Outlines. Bullet points. This is just another tool that helps me get my words out of my head and into the world without asking me to become someone else in the process.

I am still a bad writer, at least by the definition I carried for years.

But I am a much better communicator than I used to be.

### Why This Matters in Engineering

Engineering culture often celebrates clarity while quietly punishing roughness. We say we value ideas, but we reward the people who can present them cleanly, quickly, and confidently the first time. For many engineers, that environment teaches a dangerous lesson. If your thinking is not already polished, it is safer not to share it.

AI‑assisted writing changes that dynamic in a meaningful way.

When we give people tools that support rough thinking instead of replacing it, we lower the cost of participation. We make it safer to bring half‑formed ideas into the open. We create space for learning without requiring perfection up front.

That isn’t just a productivity gain. It is an investment in morale and psychological safety.

If we want healthier engineering cultures, we need to stop treating tools like this as shortcuts or crutches. They are scaffolding. They let people stay present in the work, keep their voice, and grow in public without fear of shutting down.

Writing now feels like part of the work, not a barrier to it.

My husband Sean read Boring Is a Feature and had a critique. He is in a job search right now, and he said he thinks the discipline I outlined is what is slowing him down. Every posting wants AI first or AI native. He does all the things I wrote about. He is not AI first. He said: I think AI first is a way to skip all those parts.

The formal definitions are about systems and organizations. AI first means prioritizing AI when building products and services, while AI native means designing systems so AI is embedded into the architecture itself.

Here is what being AI Native means to me.

I use AI every day. It is woven into how I design, how I build, and how I think through problems. But I do not use it to skip steps. I use it to do the steps better than I could alone.

The thinking still happens first. I spend time designing in markdown before I write a line of code. That document becomes the context my AI thinking partner works from. The documentation does not get skipped because I am using AI. It gets better, because the design is already there and the comments write themselves from it. Fewer keystrokes. Not fewer decisions.

I will be honest about testing. I am a typical engineer who loves the happy path. Left to my own devices I will test the thing I expect to happen and quietly not think too hard about everything else. AI is changing that. I am writing more tests than I ever have, covering more scenarios than I would have thought to cover on my own. I still need to run a code coverage tool to see where my numbers actually land, but the trajectory is clear.

I once inherited a codebase with less than ten percent coverage. We were tasked with getting it to sixty. It was one of the most painful stretches of work I can remember. With AI, that same job would have been hard. Not brutal.

Here is what I keep coming back to: initial code was always the cheapest part of a product. Maintenance is where you spent the real time and the real money. That has not changed. What has changed is that some people are now saying: if it breaks, just use AI to rebuild it. Maybe. But why run at computer speed when you could run at slightly less than computer speed and actually understand what you built?

AI native does not mean frictionless. It means using AI to close the gap between the engineer you are and the engineer you want to be. More thorough. More tested. More observable. Still responsible for the code.

Being AI native to me means using every tool available to do it better. Not faster at all costs. Better.

And Sean? He is still on his way to AI native. But he already has the part that matters most. The rest is just tooling.

This image was generated using this prompt.

Create a photorealistic image in a clean cartoon whiteboard sketch style that visualizes my work life. Include what I do, who I work with, my role, my values and what’s important to me. I’ve attached a headshot so you can guide the sketch of me at the center. Ground your research in Work IQ and the public profile for me on LinkedIn. The graphic should be rich in information. For the avatars of the people I work with, avoid guessing and put a generic icon in place or find their actual profile pictures.

Saw my manager do this and decided to give it a go. She used Work IQ, which had details I was not ready to make public, so I built mine from my LinkedIn profile and Substack instead.

Give it a whirl!

You can check out more here: WorkIQ Persona Sketch

Coding like a little old lady means doing things deliberately, with the person who reads it next firmly in mind. It means avoiding fads, choosing boring tools on purpose, and being relentlessly kind to whoever has to read your code six months from now, which is usually you. My rule of thumb: don’t make the Alison of six months from now swear about the Alison of today.

This is not about being slow. It is about being deliberate. Durability is a discipline, not a personality trait.

Just because you are vibe coding does not make these principles less relevant. If anything, it makes them more so. AI can generate code faster than any human, but it cannot tell you whether the result is reliable, observable, or maintainable. That part is still yours.

Label Every Jar

No mystery Tupperware in this codebase. If you open a file and cannot tell what a variable does from its name alone, it is already a problem.

# Before
def calc(x, y):
    return x * y * 0.0274

# After
def calculate_monthly_interest(principal, annual_rate):
    daily_rate = annual_rate / 365
    return principal * daily_rate * 30

The second version does not need a comment. The names do the work. That is the goal.

Wrap It in a Good Quilt

Documentation is not a summary of what the code does. Any decent reader can see what it does. Documentation explains why it does it that way.

def calculate_monthly_interest(principal, annual_rate):
    """
    Approximates monthly interest using a 30-day month.
    We use 365 days (not 360) to match the loan agreement terms.
    See: contracts/loan_terms_v2.pdf, section 4.3
    """
    daily_rate = annual_rate / 365
    return principal * daily_rate * 30

That note about 365 versus 360 will save someone an hour of confusion. Probably you. At the very least, go back and add comments once the code is stable if you don’t like updating it as you make edits.

Measure Twice, Cut Once

Tests are not something you write after the code works. They are how you know what “works” means before you write a single line.

Start with the behavior you expect. Write the test that confirms it. Then write the code that passes it.

# Write the test first
def test_calculate_monthly_interest():
    # 12% annual rate on $1000 for 30 days
    result = calculate_monthly_interest(1000, 0.12)
    assert abs(result - 9.86) < 0.01

# Then write the function to pass it
def calculate_monthly_interest(principal, annual_rate):
    daily_rate = annual_rate / 365
    return principal * daily_rate * 30

This sequence forces you to think about the contract before you think about the implementation. It also means that when someone changes the logic six months from now, the tests will tell them immediately what they broke and what it was supposed to do.

Measure twice, cut once. The second measurement is the one that saves you.

Avoid Flimsy Gadgets

Every framework was someone’s exciting new idea once. The question is not whether something is new. It is whether it will still be maintained when you need to patch it at 11pm on a Friday.

Choose tools that have been around long enough to have opinions about. Check the last commit date. Read the issue tracker. If the community is quiet, the library is either perfect or abandoned, and you will not know which until it is your problem.

Boring is a feature.

None of this means stop experimenting. Play with the new thing. Learn it, break it, form an opinion about it. Just do not wire it into production until you know what happens when it goes wrong and who will fix it. The sandbox is for curiosity. Production is for things you trust.

Avoid drafty rooms

Close your resources and keep your architecture tidy. They are the same instinct at different scales.

# Leave the door open
conn = sqlite3.connect("data.db")
results = conn.execute("SELECT * FROM users").fetchall()
# conn never closed

# Close it behind you
with sqlite3.connect("data.db") as conn:
    results = conn.execute("SELECT * FROM users").fetchall()

The with block closes the connection when it exits, even if something goes wrong. The same principle applies to your folder structure: functions that do one thing, files organized by what they are, no junk drawers. Tidiness at every scale makes the code easier to maintain and easier to hand off.

Add a Warm Greeting

When something goes wrong (and something will), your program should not slam the door in the user’s face. It should explain what happened and, where possible, what to do next.

# Before
def load_config(path):
    with open(path) as f:
        return json.load(f)

# After
def load_config(path):
    try:
        with open(path) as f:
            return json.load(f)
    except FileNotFoundError:
        raise FileNotFoundError(
            f"Config file not found at {path}. "
            f"Check that the path is correct and the file exists."
        )
    except json.JSONDecodeError as e:
        raise ValueError(f"Config file at {path} is not valid JSON: {e}")

Clear error messages will make you happy at 2 AM when production is down.

Leave a Paper Trail

Error handling tells you when something went wrong. Logging tells you what was actually happening before it did.

import logging

logger = logging.getLogger(__name__)

def calculate_monthly_interest(principal, annual_rate):
    logger.debug(
        "Calculating monthly interest",
        extra={"principal": principal, "annual_rate": annual_rate}
    )
    daily_rate = annual_rate / 365
    result = principal * daily_rate * 30
    logger.info(
        "Monthly interest calculated",
        extra={"result": result}
    )
    return result

Telemetry is the same instinct at system scale. Instrument the things that matter: response times, failure rates, input ranges, unexpected paths. Not everything, but the things that will let you answer “what was the system doing when this broke?”

A codebase without observability is a black box. You can see the output. You cannot see what happened inside. That is a fine position to be in until it is not, and then it is very bad.

Leave a paper trail. Future you will be grateful.

The Long Way Is the Better Way

A codebase that still works clearly three years later is not an accident. It is the result of small, deliberate choices made consistently: names that communicate, documentation that explains the why, tests written before the code, tools chosen for stability, resources closed properly, errors handled with care, and enough instrumentation to understand what is actually happening at runtime.

None of this is glamorous. That is the point.

Author’s Note: This was originally published on May 30, 2026 on my personal Substack.

Speed is the story everyone is telling right now. In my last essay, I wrote about how the pace of software development has changed across my career and how the definition of “fast” keeps shifting under our feet. This essay looks at speed from a different angle. Not the decades long view, but the view inside a single night of work, where depth and pace collide in a very different way.

There is a particular kind of pressure in the air right now.

Ten minutes and a prompt.

Forty five minutes and you ship.

If you aren’t moving at that speed, the implication is that you are doing it wrong.

By that measure, I had a terrible week.

I spent five hours on one part of a larger project.

Not building it.

Not shipping it.

Designing the prompt for the data layer.

Five hours, zero code.

The horns would have been honking.

I have been in tech long enough to know that the things you skip in the beginning are the things that cost you later.

The Little Old Lady From Pasadena

When I think of “code like a little old lady,” I think of the woman who drove twenty five miles an hour once a week, steady as a metronome, while everyone else swerved around her. Slow. Predictable. Unbothered.

This week, I was her.

Not because I don’t know how to move fast.

But because I was thinking in a different direction entirely.

The Work That Doesn’t Look Like Work

The project I am building is a hands on implementation of a Recursive Language Model, based on the Zhang, Kraska, Khattab paper out of MIT CSAIL. The question behind it is deceptively simple.

What becomes possible when a model can investigate a dataset instead of only reading it.

To explore that, I needed a dataset that could actually teach me something. Not a toy. Not a happy path demo. Something with enough structure and enough mess that recursive reasoning would matter.

So I designed a synthetic dataset generator.

Twenty items. Ten groups. Three to five owners each.

A baseline snapshot on January 1, 2026.

Daily snapshots through Q1.

New, Present, Removed.

A Closed table as ground truth.

Then I added the knobs.

False positives. False negatives. True positives.

Percentages of edge cases.

Seed controls.

Variations that let me generate multiple datasets for multiple scenarios.

This is the part that comes from experience. I know what a dataset must contain if I want to trust what I learn from it.

Overkill. Probably.

But the next morning in the shower, I realized one more thing I could add to make the dataset reusable across three different methods I want to compare. Not just the generator. The data itself.

That was the moment I understood what had actually happened.

The Holodeck and the Questions That Stop You

I wasn’t working alone. I was working with my AI thinking partners, a small group I call the Holodeck. Each one has a role. Writing. Analysis. Building. Technical reasoning. They weren’t speeding me up. They were slowing me down in the right places.

“How many items per group.”

“Is this event style or daily emit.”

“What is the difference between the date the row closed and the date the snapshot first saw it was gone.”

That last one stopped me cold.

Because those dates aren’t the same, even if they look the same.

And if I hadn’t been asked, I would have collapsed them.

Every question saw me saying either

I didn’t think of that yet

or

I knew that, I just didn’t include it.

Both kinds matter.

By the end, the data generator was more reusable than I intended. The architecture was clearer. The reasoning paths were sharper. The project itself had more surface area for learning.

None of that would have emerged in forty five minutes. And it didn’t feel like five hours, the time flew.

Speed Is Relative

People talk about speed as if it is an absolute.

It is not.

Speed is relative to others on the road.

Last week, I was on an open highway.

I didn’t notice the speed until I looked up.

What I was doing wasn’t slow.

It was deep.

Depth doesn’t show up on a speedometer.

Why I Code Like a Little Old Lady

I don’t build only for the happy path.

I build for the wicked forest around it.

The point of this project isn’t only to produce an RLM.

It is to understand something about how models reason, how data shapes that reasoning, and where recursive investigation outperforms linear reading.

Do I need to learn it this deeply.

Probably not.

But I am curious.

I want to see what becomes possible when I give myself the time to think.

And sometimes that means driving twenty five miles an hour while everyone else is honking.

Let them honk.

I am building something worth slowing down for.

I’m a feminist. I’ve been one for a long time. If you’re reading this expecting a certain kind of feminist, I want to be clear about where I stand before we go any further, so no one feels surprised later and decides they own a piece of me for it.

All women are women. If you identify as a woman, you’re a woman. Full stop.

I remember the first time I heard someone talk about transitioning. I didn’t understand it. I’ll be honest about that. But I hold one firm principle: an opinion formed without knowledge is worth about as much as belly button lint. So I learned. I didn’t do that alone, some of what I know came from people in my life, men and women, who were willing to make that journey alongside me.

I write about women in tech because I’ve been one for a long time. I have stories. Some of them are not pretty. I’ll tell them.

But I can only speak from where I stand. I’m an old white woman. My experience in this industry is mine, not everyone’s. Women of color in tech have lived a different version of this. LGBTQIA+ women in tech have lived a different version. Those stories are not mine to claim.

When I write “women in tech,” I mean all of us.

We’re all women.

Author’s Note: This was originally published on May 29, 2026 on my personal Substack. It is what started me on the road to create this publication. It’s a repeat for some of you, but gives you background about me.

We can generate code faster than we can understand it.

That’s new.

Or at least it feels new.

With AI, we hear about 10x gains. 100x gains. 1000000000x gains.
Maybe not a billion, but it starts to feel like that.

And the thing is, our brains don’t scale that way.

We still want to understand what we’re building.
We still want to think about the design and the impact of those changes.

So the bottleneck didn’t go away.
It just moved.

These days, it’s often code review.

To be fair, code review has always been a bottleneck. For a long time, mostly because people just didn’t want to do them. Now it’s something different. Now it’s about throughput. The system is producing more than we can comfortably reason about.

It got me thinking about the speed of development over the course of my career.

And honestly, you can’t even compare it.

My first job after college was for a big old company. An oil company owned by a steel company. I have so many stories from that place. Luckily, many of them blurred by time.

What I remember clearly is the pace.

Development had moved past punch cards, but just barely. You would make a code change, submit it to a batch job, and then wait for the next mail run from the computer room.

The results came back on paper.

The people who had been there a long time were used to it.

And honestly, it felt like a good speed.

We talked more than we coded. We spent time deciding what to change before we changed it. There was space to think.

There were other options. We had a CICS system. Real online transaction processing. It felt incredibly fast. No paper, no waiting.

But most of our work wasn’t there yet.

That’s also where I first learned about Adabas, Natural, and databases in general. I remember being excited about it. The idea that data could be live, changing, interactive.

We also had one PC on the entire floor. Big floppy disks. Hardly anyone used it.

Our days had rhythm. Morning coffee break. Afternoon coffee break. Lunch. The whole company showing up in the cafeteria at the same time. Fifteen minutes, officially. Often longer.

I was stressed sometimes, even then.

Which is funny to think about now.

A lot of the code we worked on was already old.

Some of it was machine-generated COBOL. There was a tool that took requirements and produced code. It used every character possible to name things. Dense, unreadable, and incredibly hard to reason about.

It was a nightmare.

If that sounds familiar, it should.

A few years later, I moved to an electronics publishing and data analytics company.

They were in the middle of a major technology transition. Moving from mainframe to client server.

This is where things started to speed up.

I was still doing mainframe work, but now I had CICS terminals I could use more interactively.

I also had a Sun workstation. Oh my goodness, it was awesome. My first time with a GUI. I still spent most of my time building scripts to run from the command line, but the visual file structure felt magical.

I could try things and see results without waiting for a full batch cycle.

Projects that used to take years were now measured in a year. Sometimes less.

I moved from hierarchical databases to relational databases.

I bought the first version of Microsoft Access and started building small databases on my own. I showed my boss what we could do with smaller, more focused systems instead of the large, monolithic ones we were used to.

For the first time, I could start from an idea, design tables, build a UI, and have something working in what felt like real time.

It felt like lightning speed.

I also started using Perl on SunOS. My first Perl manual was the man page, printed out and kept in a binder. I held onto that binder for years.

There was joy in that stretch. Not because it was faster, but because I could think, try, and see.

When I moved to Seattle, I joined a small multimedia company.

We made CDs of cookbooks. It was genuinely fun. I wrote processes to convert cookbook text into a recipe database. You could resize recipes, adapt measurements, interact with the data.

I had a ball.

Well, mostly.

It was my first startup, and it was brutal.

Development time was now measured in months. From idea to shipped product in a matter of weeks or a couple months. I couldn’t believe how fast we were moving.

And it was the first time I really understood what that speed costs.

The job almost killed me.

There wasn’t space anymore. Not the kind we had before. Not the kind that let you breathe between changes.

At the same time, the web was emerging. Everyone was excited about building websites. I had already been working with SGML and XML, so HTML was a short jump.

It all felt new.

But it also felt familiar.

Fast forward again.

I worked in the Windows org when Windows Vista was being built.

Five years.

Five years to ship a product.

It felt long even then. Today, it feels unimaginable.

Even two years ago, you wouldn’t expect that kind of timeline.

Now, with AI, the speed of change is measured in months. Sometimes weeks.

If you tried to take five years to release something, you’d be laughed out of the room.

We live in a world that prizes speed. Productivity. Throughput.

We moved from letters to the phone, to fax, to email, to text.

Always faster. Always tighter loops.

And now, if you aren’t immediately available and responding, something must be wrong.

But we should probably ask, at what cost.

Because our brains haven’t changed.

Early in my career, I had two coffee breaks and a long lunch, and I still felt stressed.

Now I often eat lunch at my desk.

Even when I step away to eat, I don’t sit for long.

The clock didn’t get shorter.
The expectations did.

We have machine-generated code again.
We have natural language interfaces again.
We are asking machines to turn intent into implementation at scale.

And we are still the ones who have to understand what comes out the other side.

Code review is where that shows up now.

Not because people don’t want to do it.

Because there’s just so much to look at.

There’s a kind of engineering that comes from doing this long enough.

You start to see the cycles.

The tools change.
The speed changes.
The pressure changes.

But the work doesn’t.

We can generate code faster than we can understand it.

That still feels new.

But the part that matters isn’t.

We have always made the loop tighter.

And we have always hit the same limit.

We still have to think.

And thinking has always been the slow part.

This was not the next essay I planned to write, but it practically wrote itself in the car on my drive home. I knew I had to write it and publish it now.

As I’m trying to wind things down at work, I’ve been sharing the last bits of context with the folks taking over my projects. One of the things I mentioned was that before running a new CI/CD pipeline against production, I wanted to take a backup. Not because I expected anything to go wrong, but because I’ve been doing this long enough to know that “just in case” is not paranoia. It’s experience.

For context, I’ve been building out a dev and production Azure Data Explorer cluster and the databases that go with it. Azure Data Explorer is a fast, distributed analytics engine designed for large volumes of log and telemetry data. It’s fantastic for querying at scale, but it does not behave like a traditional relational database. Which brings me to the problem.

Azure Data Explorer does not have built-in backups the way SQL Server does. No right-click, no “backup database,” no warm fuzzy feeling. The simplest way to create a backup is to export the data to Parquet.

Parquet, for anyone who hasn’t run into it, is a columnar storage format that’s efficient, compressed, and great for analytics. It’s also pronounced par-kay, which immediately made me think of the old Parkay margarine commercial from the 1970s. The one where the tub talks. Here’s the commercial if you’ve never seen it.

Anyway. I asked the folks who will own this going forward whether they wanted me to build out a continuous Parquet export for BCDR. BCDR is business continuity and disaster recovery, which is the grown-up way of saying “when something breaks, how fast can we get back online.”

The response was, “I don’t know either of those. I’ll need to research.”

Fair enough. Not everyone lives in the land of backups and disaster scenarios. But this is one of those little old lady things I think is important.

Part of what I built was the ability to create the entire database with one button. That’s partly the CI/CD pipeline, but it’s also because I checked all the reference data into the repo. The pipeline pushes it to storage, and Azure Data Explorer auto-ingests it. All the data where we are the source of truth is already in blob storage, and I have a re-ingestion script ready to go. The rest of the data comes from daily snapshots of other systems.

So if we were to lose anything, it would be those daily snapshots. That’s where the Parquet backup closes the gap. Done in the right order, we could be live again in an hour.

The backup I took before the pipeline run was a one-time snapshot. What I proposed to the team is different: a continuous Parquet export, so that gap closes automatically going forward instead of depending on someone remembering to take a manual backup before every change.

Yes, these are things I think about at the beginning of a project. I would love to have all of this in place before any data hits the database, but at this point we’re close.

You may think, why is this important. And I get it. It’s extra work. It’s not glamorous. It doesn’t demo well. But adding it later is a major pain. I know you’re trying to get something out fast. You’re just playing around. But what I’ve learned, over and over, is that three seconds after I show a prototype to someone, I have ten people asking for access and immediately taking a dependency.

It does not matter how many times I say, this isn’t reliable, you can’t trust this, I’m still playing around. They are all over it. And then when something goes wrong... sigh.

Many years ago I built a prototype for someone. I showed it to them. They loved it. They said, “OK, ship it.” I said, “No, this is bubble gum and bailing wire.” They didn’t care. I have learned this lesson more often than I care to admit because I love playing with tech. But I try.

So yes, I think about backups. I think about BCDR. I think about Parquet. I think about the Parkay margarine tub insisting on its own name. And I think about the future engineer who will thank past me for making sure they can recover the system in an hour instead of a week.

That’s what coding like a little old lady looks like.

Alison + The Inner Chamber

If you have been doing this long enough to see the cycles, the tools change, the speed changes, the pressure changes, but the work doesn’t, this space is for you.

It is also for anyone who arrived at their own pace, not the pace the room assumed. You didn’t miss anything essential.

There is a particular kind of pressure in the air right now. Ten minutes and a prompt. Forty five minutes and you ship. If you aren’t moving at that speed, the implication is that you are doing it wrong.

I have been in technology long enough to know that the things you skip in the beginning are the things that cost you later.

When I think of coding like a little old lady, I think of the woman who drove twenty five miles an hour once a week, steady as a metronome, while everyone else swerved around her. Slow. Predictable. Unbothered.

That image resonates with me because I have always been her. Risk-averse. Cautious. A planner and a list-maker and a double-checker. For a long time I treated those qualities as friction. Engineers are supposed to move fast.

I am done treating them as friction.

There is a Jenny Joseph poem that matters to me here. You can read it, and why it belongs to this newsletter, on this page.

What you will find here are essays about durability, depth, and the invisible work that keeps systems and people functioning. About building things legible enough for someone else to maintain. About what survives scale, and what survives contact with ordinary life.

Not a methodology. Not a framework. Just one engineer thinking carefully, in public, about work that matters.

Let them honk.

You are building something worth slowing down for.

Alison + The Inner Chamber