Walter Gugenberger

How I code with AI

Tue, 18 Aug 2026 00:00:00 GMT

Anthropic published some numbers on how AI is speeding up its own development. Over 80 percent of their production code is now written by Claude, code output per engineer is up 8x since 2024, and the length of tasks an AI can finish on its own doubles every four months. It's not just them either. GitHub saw about one billion commits in all of 2025. Right now it's running at 275 million a week.

I can see it in my own work. I haven't written a function by hand in weeks. I still have my IDEs installed, but I open them so rarely at this point that IntelliJ has to rebuild its cache every single time, and anyone who has sat through that knows exactly the pain I'm talking about. Most of what I ship starts with me telling a machine what I want, from my phone or in a shell.

The plan is the work

I always planned before coding, but the plans were rough. Implementation details never had to be spelled out, because I knew the codebase and I had the experience, and between the two of them the how would work itself out while I typed. An agent doesn't bring any of that. What you hand over is a description, and a vague description gets you vague code back.

So how I start depends on the task now. Some days it's TDD, I define the tests and the agent writes code against them until they pass. Bigger or riskier work gets a thorough plan upfront, what it should do, where it fits, what it's not allowed to break, and then the agent writes its own implementation plan back to me before it touches anything and we go back and forth over it until I run out of objections. When the stakes are low I just vibe code. Let the agent go, follow its intuition, see where it lands.

The tooling supports all of it. Plan mode to write the spec, where the agent can read everything but change nothing. Goal mode to finish, where it runs until the feature is done. And loops that prompt the agents for me on a schedule, so the next task gets picked up and the queue keeps moving and the checks get rerun without me typing any of those prompts myself.

If the plan is mush, it doesn't matter how smart the model is.

The fleet

I run five to ten Claude instances at once. Even that undersells it, because one instance isn't one worker. Give it a big job and it fans out into hundreds of subagents, each working on its own piece and reporting back up, so what looks like ten agents is really ten managers with staff.

A lot of work splits up like this. Reviews that go through the whole diff from a dozen angles with a second wave checking whatever the first wave flagged, migrations where every file gets its own agent, reading a subsystem from a few directions at once, tests and specs across a big batch in one pass. I never did any of this before. Coordinating it by hand cost more than it was worth.

So what do I do all day? I keep the sessions open and round robin from one to another. I figure out what to ask for, I cut it into pieces an agent can finish, and I look at what comes back and decide whether it's any good, which is most of the job and the one part there's no handing off.

The agents run wherever it makes sense: my laptop, a Linux box in my basement, an EC2 instance, the ephemeral boxes Anthropic spins up and throws away. Even right now I have one of those ephemeral boxes open, and another agent is over on the EC2 instance working on a platform I built. I'm not typing code in either one. All of it runs in tmux over remote connections so the sessions survive me walking away. I covered that setup in I built a product from my phone.

Review and sign-off

When the work comes back, I review it. The first pass isn't me though. Automated review runs on the diff before I even look, some of it /code-review, the bigger part a set of review skills I wrote myself, standards from years of doing this, written down so a machine applies them every single time:

The spec is the contract. Code that quietly does something the spec doesn't say gets flagged, not merged.
If something can't be undone, I want a good reason it isn't a soft delete.
Keep the surface small. Don't add the endpoint or the button if you don't have to.
If it ships, it ships with the logs and metrics to debug it later.

I copied my own taste into something that checks the work for me, and what that buys me is that the boring stuff is already gone by the time I'm reading, so my attention goes to the questions that actually need a person. Is this the right approach. Does it fit the system, or just this corner of it. And is there a case nobody thought about.

The human is still in the loop, that part hasn't changed. A person merges, and if it ships broken, "the agent wrote it" is not an excuse anyone gets to use. The merge is the one button in the loop I still press myself.

What the job is now

What's left is the planning, the judgment, and the sign-off. The typing was the part that left.

The AI labs already have a name for this that fits better than "software engineer": member of technical staff. It sounds like nothing, but it covers the spread, product and engineering and the infra the agents run on, plus the open problem of orchestrating all of it. I think that's where at least some of this work is going.

How far this goes isn't up to me. METR tracks how long a task an agent can finish on its own, and the line keeps doubling. That's the curve to watch.

Marquis: an AI-native media intelligence platform

Sat, 11 Jul 2026 00:00:00 GMT

Marquis is a media-intelligence platform I built for my wife's PR firm. It watches news coverage for the firm's clients around the clock, uses AI to decide what is about them and how it reads, and delivers browsable coverage, daily briefs in Slack, and weekly reports. It has been in production since May 2026, replacing links pasted into Slack and a spreadsheet.

I built it in about two months of evenings and weekends, largely from my phone. One engineer. This post is about how that is possible.

The frontend is a protocol

Marquis has no forms. Operators run it by talking to Claude: "onboard a new client", "why is this feed noisy?", "compare this month's coverage to last month's". The assistant picks the right actions and does them.

That works because the product is built as tools and skills behind MCP, an open protocol. Any chat interface that speaks MCP and supports skills can drive Marquis. Claude is just the current front door. When the models get better or a new client app ships, the product's interface improves without Marquis shipping a line of code. I never build another frontend for another channel.

There is a web app, and it deliberately does less. It exists for the one thing conversation is bad at, scanning a whole portfolio at a glance. You cannot build clients or queries there. That still happens in conversation.

Asynchronous by design

Triggering a collection run takes about a second. The coverage lands minutes later. That gap is deliberate. The backend is asynchronous end to end, the way Werner Vogels has argued the world already is. It scales to many clients without redesign. When a new source or destination is needed, it fans out and nothing else has to change.

AI on both sides

The intelligence layer runs on the latest models from Anthropic and Google. Every article gets a relevance decision and a sentiment read. When the AI is not sure, it holds the article and asks a human in Slack instead of guessing.

That layer got a real test recently. The firm needed coverage on a high-value news target whose press ran almost entirely through South American outlets, some of it in Spanish, some in English. Onboarding took one Claude conversation. And because the intelligence is an LLM, the language barrier never showed up. Marquis read the coverage in whatever language it arrived and delivered the sentiment in plain English.

AI agents also wrote the code, under the same discipline I would hold a human team to. Specs drive every repository and changes land through pull requests. The operator documentation carries a freshness contract that ties it to the code it describes. That discipline is why I trust what the agents build.

Stack

Kotlin · Python · TypeScript · React · AWS.

I wrote about the build in Building Marquis and about the workflow in I built a product from my phone. More posts in the series are on the way. If you want to talk, LinkedIn is the best way to reach me.

Marquis is proprietary software, owned and operated by The Lafayette Company.

Thank You, America

Sat, 04 Jul 2026 00:00:00 GMT

Thank you, America, for every opportunity you have given me, from my family to my career. For someone who came from Europe, this would never have been imaginable where I grew up.

This freedom was paid for. By the 56 men who signed the Declaration of Independence, and with it their own death sentence. By the members of our armed services, who stand watch, right now, somewhere I will never have to. Thank you.

We all come from different backgrounds, and they all led us here. That, ultimately, is what unites us as Americans.

The Case for Soft Deletes

Fri, 19 Jun 2026 00:00:00 GMT

I always liked soft deletes as a feature because it allowed customers to undo their potential mistakes. It also allowed the engineers to better debug, so it was just an overall nice feature, right? It was also a comforting sort of safety net, because the alternative is that if someone deletes something, you might have to roll back the database, you might have to go digging in the logs, et cetera. It also doubles as a rough audit log, since the deleted rows are still in the table, just tombstoned.

But now that increasingly agents are used to access our systems, I do think soft deletes have a much bigger use case. If your agent goes rogue and starts deleting a bunch of stuff, the agent is much faster than a human could delete it. Even a human could use a script, but the agent can do it without a human really knowing. A human has to actively run the script. The agent could just do it in the background.

If you build an application with soft deletes in mind and gate it by an API, that gives your AI an additional guardrail. To me, that's a basic rule of letting agents touch production. The API protects itself from bad inputs, sort of the same way validation does. The agent can ask for whatever it wants, but a delete is still just a reversible delete.

And honestly, that's the part I like most about it. If the agent does go off the rails and deletes everything it can reach, you haven't really lost anything. It's all still there with a flag on it, so recovering is just a matter of flipping those flags back. Worst case, the app is down for a little while, but the data is never actually gone.

Soft deletes aren't free, though. You have to remember to filter out the deleted rows on basically every query, and the day you forget is the day you show someone data they thought was gone. Unique constraints get awkward too, since a deleted row still occupies that email or that slug. And the whole thing only holds if everything goes through the API. The moment someone runs a script straight against the database, the safety net isn't there.

As always, there is, of course, a use case for hard deletes. If you provision infrastructure, it's probably a good idea to deprovision that part so you don't incur cost when something's deleted. Even that you could delay by a certain time window, but it's really up to the app. Generally, when I can, I will do soft deletes, just for the convenience, the laziness, but now more and more also as the additional safeguard.

Building Marquis

Fri, 22 May 2026 00:00:00 GMT

Every time The Lafayette Company earned a piece of media coverage, someone pasted the link into Slack, then into a spreadsheet. That was the whole system.

The spreadsheet was a log. No way to tell if sentiment was shifting, no view across sources they hadn't found yet, just whatever ended up in a cell.

My wife founded The Lafayette Company in 2015. Eleven years in, she's built it into a seven-person PR firm in Alexandria. I handle their IT, which means I'm in their Slack and I see how the work flows. One evening I asked her whether automated news collection would be useful.

She said sentiment was the main thing. Whether a client got covered, they already knew. What she couldn't see was whether the tone was positive or negative, and whether it was moving in a direction they should care about. Beyond that, why were they building reports by hand when a machine could do it? And they were missing coverage from sources that weren't already landing in Slack.

They already had media monitoring software. It found clips and filed them, and that was where it stopped. It couldn't tell you whether sentiment was shifting, and nobody was getting a report out of it. The missing piece was analysis.

So I started building.

Marquis collects from news APIs and RSS feeds across more than 150,000 sources via EventRegistry, Google RSS, and GDELT. It runs on a schedule, scores sentiment from the news APIs, calculates earned media value, and stores everything. When a report is due, it builds one and drops it into Slack and cloud storage, so nobody has to go looking for it.

The main interface is Claude. Analysts tell Claude which clients to monitor, what topics to track, how often to run. A Claude plugin handles the setup. When they want to understand what's happening with a client's coverage, they ask. Claude fetches the data and talks about it. You can ask why sentiment dropped in a particular week, or how the last month compares to the quarter before, and you get an answer instead of a chart.

There's a web interface too, and it does quite little on purpose. It's an observability tool for the visualizations and portfolio views a text conversation is bad at. The input layer stays in the chat.

I built the whole thing in about two months of evenings and weekends, most of it written on my phone. If that sounds implausible, I wrote about how the setup works.

The pilot ran last week. The first automated report came back in a few minutes. The same report would have taken several hours to assemble by hand. The main open issue is cold start latency on low-traffic endpoints. As of this week, the firm is running on it.

I built a product from my phone

Fri, 24 Apr 2026 00:00:00 GMT

I built a media intelligence platform for The Lafayette Company, my wife's PR firm in Alexandria, over two months of evenings and weekends. Roughly three-quarters of it got written on my phone.

The reason I wanted this was boring. I have a family and real obligations. Finding a clean hour at a laptop is a narrow window on a day like mine, and it almost never lines up with when I actually have ideas. Mostly I had ideas when I wasn't near a laptop. In the pickup line at school, or while my kid was getting ready for soccer practice.

It's the same principle that used to keep work calls tied to a desk phone. You take the Zoom from the car now because the meeting and the afternoon pickup are both non-negotiable, and only one of them can move. Coding just hadn't caught up yet.

So I put the agent somewhere the phone could reach it.

The setup

A small EC2 instance runs a tmux session with Claude Code inside. The Claude iOS app connects over a remote channel. I dictate or type what I want, the agent starts, I close the app.

Sometimes I come back fifteen minutes later, sometimes two days later. I open the app and the session is where I left it. Same shell and files, same thought I was mid-sentence on. Whatever the agent got done while I was gone is waiting.

I'd been watching self-hostable autonomous agents like OpenClaw for a while. The shape was right, but I didn't want to install one. I already work in Claude Code every day. Then Claude Code, randomly, shipped a remote-control function right around when I was thinking about this.

The kit

The parts are ordinary: EC2, tmux, Claude Code, the Claude iOS app, and a small CDK stack to hold it together. The version I run is in blog-code, kept bare so you can fork it and have it running in an afternoon.

The setup has limits worth naming. Debugging something complex still needs a laptop. So does reading a long diff carefully, or any architectural decision that wants multiple files open at once. The phone handles direction-setting work well. I write a spec, kick off a task, look at what comes back. That's where most of the hours actually went.

The total hours didn't go up. In a typical week I spent about as much time on this as I would have anyway. But the time I already had started to count. Fifteen minutes in a parking lot, stretches that used to be dead time. Over two months of those, I had a product.

Living Specs for AI Agents

Wed, 15 Apr 2026 00:00:00 GMT

Every morning when I logged back in, I had to re-educate the AI agent. What are we building, where are we in it, what did we decide yesterday, what's the convention for this thing and the constraint on that thing and the reason we went with option B instead of A. Ten minutes sometimes, twenty other times. Every single day.

Multiply that across a week and across a team and it adds up fast. AI agents don't remember. Every session is day one and that's not changing any time soon, so the question is what you do about it.

The answer I landed on is simple. Write it down once, in a place the agent reads on startup, and stop re-typing it. For Claude Code that file is CLAUDE.md. For Kiro it's AGENTS.md or something similar. The name doesn't matter as long as the agent reads it before it does anything else.

This isn't a new idea. .cursorrules, .aider.conf, and similar files have been doing something like this for years. What changed is that modern agents are better at actually acting on them, and the cost of keeping them updated is low enough to be worth it.

So that's where I put the things I was repeating every morning. The stack, the branches, the conventions, rules like "never push from an agent" and "only commit when I ask." The stuff a new teammate would want on day one, because that's exactly what the agent is, a new teammate every single morning.

A trimmed version of mine:

# project-name

Web app built with Astro, deployed on Vercel. This file is the
single source of truth for any agent working in this repo. Read
it completely before doing anything else.

## Rules

- DO NOT push code. Ever. Only the human pushes.
- DO NOT commit unless explicitly told to.
- DO NOT merge to `main` without explicit approval. `main` is
  production. Merging is deploying.
- DO NOT start work without a spec. No spec, no code.
- DO NOT invent outside scope. If it's not in a spec and wasn't
  explicitly requested, don't do it.
- DO NOT deviate from specs. If code contradicts a spec, stop
  and flag it.
- DO NOT generate filler. No AI slop, no hedging, no padding.
  If it reads like AI wrote it, rewrite it or flag it.
- DO NOT guess when you can ask.
- Update this file when you learn something durable about the
  project. The next session depends on it.

## Spec-driven workflow

All work is driven by specifications. No exceptions.

- `docs/system-specs/` describes the current state of the project.
  These are living documents. If the system changes, the spec
  changes. If they disagree, one of them is wrong and you fix it.
- `docs/task-specs/` holds one file per piece of work, prefixed
  with the date: `2026-04-15_some-task.md`. Once the task ships
  the spec is frozen. It becomes a historical record of what was
  built and why. Never rewrite a shipped task spec.
- Before starting any work, check for a task spec. If none exists,
  create one first.

## Content workflow

1. Human shares an idea. Agent categorizes it and routes it to
   the content bank or a task spec.
2. When ready, agent creates a dated task spec. Ask probing
   questions to get the real story before writing begins. Don't
   fill gaps, surface them.
3. Draft on a branch. Never pad. If a section is thin, ask for
   more rather than generating generic content.
4. Review via PR. Every sentence earns its place.
5. Merge only with explicit approval.

## Branches

- `main` is production. What's in main is live.
- `develop` is the integration branch for ongoing work.

I put one rule at the top of the file. It's a living document. When the agent learns something durable about the project, it updates the file itself. The next morning that context is already there and I don't re-type it.

It only works if you keep the file honest. Skip an update after something changes and the next session works from a stale picture, which is worse than starting from nothing.

Two kinds of specs

Once the entry point was sorted I had to deal with the rest of the docs. I used to have a flat docs/ folder with a pile of specs. Some described the current state of the system and others described a specific piece of work I'd done six months ago. They lived next to each other and drifted apart. That confused me and it definitely confused the agent.

So I split them. docs/system-specs/ is living documentation that describes what the system is right now. If the system changes, the spec changes. If the spec and the code disagree, one of them is wrong and you fix it. docs/task-specs/ is frozen, one file per piece of work, prefixed with the date: 2026-04-15_some-task.md. Once the task ships the spec becomes a historical record. You don't rewrite it, it's the timeline of what got built and why.

The agent knows which is which because they live in different folders. When I start a new task the agent creates a task spec with today's date, we iterate on it, and once I approve it implements against the spec. When it's done the spec stays and a month from now if I want to know why I did something the dated file is right there.

Beyond code

None of this is specific to code, which I didn't expect when I started. This blog you're reading right now is set up the same way. There's a CLAUDE.md that tells the agent how I write and what my content pillars are, a system-specs folder with the content strategy and post conventions, and a task-specs folder with a dated spec for every post including this one. When I sit down to write, the agent already knows my voice and structure, and it asks me for the story before filling in blanks. I don't have to explain any of that.

Any domain where you work with an AI agent over time can use this. Research, consulting, writing a book, running a small business. Anywhere you'd otherwise be explaining the same context over and over.

I set this up for myself to stop repeating context every morning. But the real payoff showed up when someone else joined the work. They didn't have to ask me how anything was organized. They opened the repo, their agent read the file, and they were in the work. That's what happens when you write things down once. The file doesn't care who opens it, whether that's a human, an agent, or future-you who forgot.

This is persistent memory, file-based. The CLAUDE.md and the system specs change with the project. The task specs just pile up. Some of it stays current and some of it becomes historical context. It's memory that lives in the repo instead of inside the model.

Some tools are starting to build this in natively. Claude has a memory feature in the app and in Claude Code. It remembers things about you across conversations. But from my experience it's still thin. It captures high-level facts about you and misses the depth of how you work on a specific project day to day.

The spec structure fills that gap for project-level memory. But there's still a missing layer above it. The stuff about you that should follow you everywhere regardless of which repo you're in. How you like to work, how you communicate, your preferences and patterns that aren't tied to one codebase. That's personal memory and it's the piece that's still not solved well. I'll write about that next.

For now, if you're still re-educating your agent every morning, write it down once and let the repo brief the next session for you.

One Hour to Save the Data

Tue, 31 Mar 2026 00:00:00 GMT

I needed to build a disaster recovery solution. The goal was to get DynamoDB data backed up to a different region on a continuous basis. A one-off export wouldn't cut it. It had to be reliable and run on its own.

The approach

DDB has an export API that allows customers to move data to an S3 bucket which can be in a different region. While we could have run this manually we needed something that was reliable and continuous. At least as much as possible.

I decided to deploy a lambda that ran at scheduled times. Exports the tables into an S3 bucket. The lambda had to accept a list of tables and a destination. Ideally this solution was repeatable for future applications (which we needed the next day). A config driven approach deployed via a pipeline seemed ideal.

Building it

I created a CDK project and told Kiro to start a spec. I needed a lambda, S3 bucket, IAM roles and a schedule. Some alarming and monitoring would be nice too, but nothing crazy. Oh yeah, and I needed the inputs (table names, buckets) to be created based on a config. That way the CDK stack can be deployed over and over with different parameters.

Writing a spec with Kiro is an iterative approach. It starts out, gets things right and some wrong. You read the spec and make corrections. And when you're happy you tell it to go implement. Then you check the implementation and most of the time it's good. Sometimes you tweak in a few spots. The spec took a few minutes to write and so did the implementation. A deployment to preprod to make sure the whole thing worked, a review, and out to production. Total time about 1h, maybe 90 min.

Built for reuse

The config-driven setup meant that pointing it at a different set of tables and buckets took a config edit. That's why a second region came together the next day in minutes. Same stack, different parameters.

What I did vs. what the AI did

Kiro acted like a personal assistant. It took my thoughts and wrote them into a spec. Organized them (I can be all over the place sometimes), and when I was ready it implemented everything. It confirmed with a successful build.

Kiro didn't know we needed cross region replication or which tables we needed to save, and it wouldn't have thought to make the whole thing reusable and configuration driven. All that came from the experience of the human operator. But a human could not have built something this complete this quickly, or at least this one couldn't have.

One hour

With the help of AI I was able to build something quickly and with minimal issues. Generally those two things are in tension. It was successful because of the help of the friendly ghost (Kiro) and the combined experience building applications and knowing the underlying system.

AI is good at exactly that part, taking a clear brief from an experienced operator and turning it into working infrastructure. Knowing how to use it is the difference.

Why This Blog

Sat, 28 Mar 2026 00:00:00 GMT

I've been a software engineer for 12 years. I just had my work anniversary in early March. I started at a startup, ran my own consulting company, then bootstrapped another one. I've worked in large enterprises too. I've built a lot of things and I have little to show for it, in terms of artifacts. I can give you a resume but I've forgotten more than what's on that resume.

I want to start writing this blog to keep a record of what I've done and what I am thinking about at the time of writing. It's not going to be your millionth tutorial on how to set up Claude Code (ok, maybe a little for one specific thing I did). But I want to show what worked for me and what didn't. If it helps someone, great. If it doesn't, also great.

Whether AI is going to change the world or take your job, I don't know. I've been using it to ship real software, and some of it impressed me and some of it was garbage. Like any tool.

For me it's practical. My wife founded The Lafayette Company in Alexandria in 2015 and has built it into a seven-person PR firm over the past eleven years. I built Marquis for them, a full production system with DynamoDB, Lambda, EventBridge, Slack integration, the whole stack. I built Gilbert, a Rust CLI that talks to that platform. I coded half of both of them from my phone.

The phone thing

I have a family. Young kids. Anyone with small children knows the math. If something requires pulling out a laptop, finding a quiet spot, and getting into a flow state for two hours, it's not getting done. Not on a weeknight. Probably not on a weekend either.

But I can write a spec on my phone during a lunch break. I can refine it at night after the kids are down. And with spec-driven development, where the spec is the source of truth and the AI implements against it, that's enough. I write the what and the why. The AI handles the typing.

I set up Claude Code running remotely on an AWS instance and controlled it from my phone. I'd write a spec, send it over, review what came back, refine, iterate. Marquis and Gilbert got built in the cracks of my day. Ten minutes here, twenty minutes there.

What I think about AI, honestly

If AI takes my job someday, so be it. Me refusing to learn it won't slow it down. I'd rather be at the front of this wave than scrambling to catch up when it's too late.

That doesn't make me a true believer either. I've seen AI write clean, correct infrastructure code in minutes, and I've seen it confidently generate something that would have taken down a production service. Using the AI is the easy part. The work is knowing what to ask for and validating what comes back. The design decisions stay yours, because the AI can't make them for you.

The developer is still the one in charge. You're the one who says "make this config-driven so other teams can use it." The AI just writes the code.

What's coming

I'm going to write about the things I've actually built and operated. For now, I am committing to write about these three things (I claim to have expertise in):

AI-assisted development in practice
Distributed systems and cloud architecture
Career engineering

I recently built a disaster recovery framework during an operational crisis. A full IaC solution for exporting DynamoDB data to safe regions, spec-driven, built in about an hour. By noon the same day the entire org had adopted it. That's a story I want to tell. There are more like it.

There's one more reason I'm writing this, and it has nothing to do with tech. I know very little about some of the people in my family who came before me. They're not here to tell their story anymore. I don't want that to happen to mine. Someday my kids/grand kids might want to know what their papa was building and thinking about during these years. This is that record too.