DEV Community: Edmunds Puce

Building With an AI Isn't About Speed. It's About Clarity.

Edmunds Puce — Mon, 07 Sep 2026 06:00:00 +0000

This site was mine alone for eight years. These days I'm not the only one who works on it, and the thing that changed most wasn't the code.

A while ago I started building here alongside an AI assistant. I expected it to make me faster. What I didn't expect was that it would force me to write down how I think, and that the writing would end up mattering more than any single afternoon of code.

You can actually see the moment it began. For years the changes to this site were named the way you name things when no one is watching: Save my work, add lang switcher, fix stuff. Then, almost overnight, every change started arriving in the same careful shape, each one a small labelled promise about exactly what it did and why.

That wasn't a new tool doing it for me. It was me starting to work in a way a collaborator could follow, because for the first time the collaborator wasn't only future me.

I had to write down how I think

Working with an assistant broke a habit I didn't know I had. For years the reasons things were built the way they were lived nowhere but my head. Why this pattern and not that one, which shortcuts were fine and which would come back to bite me, where the sharp edges were. None of it was written down, because I never needed to tell anyone. I just knew.

An assistant knows none of that. It reads the code, not the years of decisions behind it. So the only way to get help that fit the project instead of fighting it was to make the unwritten rules written. I started keeping a manual: not documentation for users, but an operating manual for whoever, or whatever, works on the site next.

It started as a single short page of ground rules. It did not stay that way.

The core page is now surrounded by a dozen companion files, one for each part of the site that got complicated enough to deserve its own chapter. Together they run well past five hundred lines, and every one of them is written for a reader who is precise, tireless, and completely without context unless I give it.

Here is the part I didn't see coming: writing all of that down made me a better engineer on this project, before the assistant read a word of it. You cannot write a clear rule for a decision you only half understand. Explaining myself to a machine kept forcing me to actually decide what I believed.

It grew with the work, not ahead of it

The manual didn't arrive fully formed. It grew the way scar tissue does, one lesson at a time. Every time I got something wrong, or the assistant confidently did the wrong thing because I'd never told it the right one, that became a new line in the manual. Traps I fell into once are now written down so neither of us falls into them again.

When a section got too heavy, I split it out into its own file, so the everyday rules stay short and the deep detail is one click away when it's actually needed. I gave myself one hard rule above all the others: if a change makes anything in the manual wrong, the manual gets fixed in the same breath as the code. Documentation that lies is worse than none, and the fastest way to get there is to let it drift.

That single rule is what turned the manual from a nice idea into something I can trust. It stays true because keeping it true is part of the work, not a chore saved for later that never comes.

Then the site started using AI too

For a long time AI was only in how I built the site. At some point it crossed over into what the site does. A couple of small features now lean on a language model themselves: one makes up a fresh little daily puzzle, another writes up the case for and against an idea as a research aid, each with a plain, boring fallback for when the clever part isn't available.

I even added a page that lets a machine read the site the way a person reads the front door, and a quiet meter that counts how much thinking the AI parts actually cost me. None of it is the point of the site. It's there because building it taught me how these things behave when they meet real users, real edge cases, and a real bill, which is exactly the kind of thing I no longer get to learn by accident in my day job.

The point

I thought bringing an AI into a personal project would be a story about speed. It turned out to be a story about clarity.

The assistant is useful, but it isn't the thing I'll keep. The thing I'll keep is the manual: the written-down version of how I think about this codebase, dragged out of my head by the simple need to explain myself to something that couldn't guess. It outlives every session, every tool, and every version of the assistant.

That's the part worth passing on. The real work of building with AI wasn't learning to prompt it. It was learning to say plainly what I'd always just known.

I Manage Software Engineers. I Still Need a Codebase of My Own.

Edmunds Puce — Wed, 19 Aug 2026 04:00:00 +0000

I lead a team of software engineers, but I still want to keep my hands on the code and work in a codebase of my own.

Nearly 300 changes over eight years. Two of those years are completely empty, and more than half of everything landed in the last stretch.

For me, as an engineering manager, a codebase of my own isn't only about writing code. It keeps me connected to the technical reality, helps me see what my team's days actually look like, lets me make better-grounded technical calls, and keeps my own skills from going rusty.

That's what I actually needed, a chance to build things again myself, to experiment, to get things wrong, to work problems out, and to learn.

Because leading a team of engineers doesn't mean you stop being one. Sometimes going back to the code yourself is what makes you a better manager.

These days other people write the code in my job. That's not a bad thing. It's a step up, and most of the time it's the best use of my time.

But there's another side to it. Over time I started to forget what it's like to go through the whole thing myself, to understand how a system fits together, to make the technical decisions, and then to live with what they cost.

This is where I keep that kind of thinking alive.

This codebase isn't perfect. Neither is its history. And that's exactly why I want to show it.

An engineering manager doesn't have to be the person writing the most code. But it's worth going back to it every so often, just so you don't forget what it feels like.

Hundreds of changes. Then two years of silence.

I've been working on this site for eight years, and its history tells my story from those years pretty well. Here's what it looks like:

For two years I didn't make a single change to it. One year, just one. The longest gap ran 732 days and ended in December 2022.

So for two years this site was just there in my life. It was mine, but I wasn't working on it.

Then look at 2026. This year I've made more changes than in any other. Not at a steady pace, more in short, intense bursts, with the quiet settling back in between them.

This isn't a story about disciplined work on a side project. It's a story about someone who finally had a bit of time and a lot of ideas.

What's more interesting is when it happened. The year I became an engineering manager turned out to be the year I did more on my own project than in some of my most active years writing code full time.

I didn't plan that, but I think it's a good thing. When your job stops depending on you writing code, you have to go out of your way to make the time to write it for yourself. Stepping back from coding isn't the same as walking away from it. This chart just reminds me that I still believe that.

And I'm showing it exactly as it is, even though it would have been easy to dress the story up.

Because the honest version is worth more:

A personal project doesn't have to be something you're always working on. It just has to be there when you feel like coming back to it.

The machinery is what matters, not the site

Here's what the site looks like under the hood right now.

After every change I make, it checks itself in a real browser, and if something breaks, it rolls back to the last good version on its own.

Every night it backs itself up, emails me the copy, and can restore the whole site if something goes sideways.

Every day it checks that the site is up and accessible. It counts errors even when visitors are running ad blockers.

There's a mechanism for database changes too, so I can apply them and undo them if I need to.

And before any code reaches the site, it gets checked against the standards I've set for myself.

The interesting part here honestly isn't the site. It's the machinery that lets me work on it safely, try things, and not worry about breaking something.

For a personal website, this is overkill. That's the whole point.

I wanted to actually understand all of it, not just sort of. A personal project is one of the few places I can pick up the parts that aren't much fun but do matter, without it landing on anyone else. If I break something, I'm the one who cleans it up.

The other way to learn this is for the first time on a project that matters, with people watching, deadlines, responsibility, and pressure. I've done it that way. This way is better.

A personal project lets you get things wrong safely, figure out what went wrong, fix it, and try again. That's exactly why it can afford to be more complicated than it has any need to be.

Because the goal here isn't a perfect site. The goal is learning to build things properly.

What my job stopped teaching me, and my own project still does

There are three things this project gives me that my day job mostly doesn't anymore.

1. I have to do all of it myself. On a team, the work gets split across people. As a manager you coordinate more, decide more, and unblock other people more, and you finish the whole thing start to end less and less. On my own project there's no one to hand it to. I come up with the idea, write the code, make the change, test it, document it, and clean up after myself. That's where I feel what being an engineer actually means again.

2. I live with the results of my decisions. When I review someone else's code and wave through a shortcut, the fallout usually doesn't reach me. On my own project it does. Make a bad technical call, or take the quick route instead of the right one, and I'm the one living with it later. That teaches you fast to tell what sounds good in theory from what actually holds up.

3. It keeps my opinions honest. It's easy to have opinions about code when you're judging someone else's. It's a lot harder to hold yourself to the same bar when it's all on you. This project keeps me honest about what I actually know, what's worth doing, and where I quietly take the easy way out myself.

And that's probably why a few of my opinions about coding have shifted while working on it.

A personal project reminds me that engineering isn't only making calls about other people's work. It's being willing to live with the results of those calls yourself.

The stretches where I wasn't working on it mattered too

The years with no changes at all aren't a failure. They're just part of the story.

Nothing depended on this site, so nothing fell over while I ignored it. It just kept running. And when I came back, it was still there.

Coming back taught me something else - the code I wrote years ago is a good test of how well I did it at the time. My past self had left me a site that still worked.

What I hadn't left were any notes on why things were built the way they were. That's exactly why the site now has a manual, and a system that reads the code and checks it against my own rules.

The core of it is simple. If your day job isn't about writing code anymore, you should still keep somewhere you can write it.

It doesn't have to be popular. It doesn't have to be steady. It doesn't have to be impressive.

It just has to be your place to try things, get them wrong, fix them, and learn.

Eight Years of Getting It Wrong (and Why I'd Do It Again)

Edmunds Puce — Mon, 10 Aug 2026 00:00:00 +0000

This site's Git history dates back to April 2018. Three stacks, a few long silences, and some commit messages I'd rather you didn't see. I'm going to show them anyway because the mistakes turned out to matter most.

It started as a Jekyll static site on GitHub Pages. In 2019 I rewrote it in PHP and moved it to my own server. This year it became what it is today: a Vue 3 + TypeScript SPA with a PHP API behind it. Same domain, same person, completely different codebase. The difference is obvious at a glance:

Exhibit A: "please work v5"

On December 2, 2022, I tried to fix image lazy loading for cached images. The commit log for that single day reads: fix lazy loading … please work … please work v2 … v3 … v4 … please work v5. Seven commits, one bug, zero dignity.

The bug wasn't the problem. The problem was that my only way to test the fix was to deploy it. Two days later, the log shows the actual lesson: "improve deploy: have a rollback option if build fails." Not a smarter fix, but a better feedback loop. That's the pattern I keep relearning: when you catch yourself praying in a commit message, the thing to fix is rarely the code. It's the loop around the code.

Exhibit B: the mistake I made five times

The production runtime is pinned to a specific language version. My local toolchain isn't, so it happily accepts syntax that the pin doesn't allow. I have known about that gap since 2019. And yet, this spring the history shows me walking straight into it five separate times, each one breaking production, each one followed by a commit whose entire message is a variation on the same apology: revert that, use the supported form instead, fix the entity to match the server.

After the fifth time, I finally stopped trusting my memory: I wrote the constraint into the project docs and pointed static analysis at it, so the build fails before the server can. I haven't made that mistake since, not because I got smarter, but because I made it impossible.

The same shift shows up throughout the recent history. In 2019, I committed "hope that chrome audit is all green :D". This year, the site runs automated accessibility tests on every change and even has a live audit built into the examples page:

The point

Nothing in this repo is impressive on its own. What I like about it is that every ugly commit is still there, and each one bought something: a rollback button, a static analysis rule, a test suite, a habit. If your Git history looks embarrassing, good: it means the lessons were real. Just make sure each mistake leaves a guardrail behind so you get to make new ones next time.