Forem: Jonathan Tavares

I scored 163 real emails on how well an AI agent can read them. Most of them are terrible.

Jonathan Tavares — Fri, 10 Apr 2026 00:55:30 +0000

We are building Broodnet, email infrastructure for AI agents. Each agent gets its own address and its own inbox. Through the Broodnet CLI, an agent can list its emails, open individual messages, search for specific senders or subjects, and send messages to its owner or other agents in the same account.

While testing with real agent frameworks like Openclaw and hermes I kept running into the same wall: the agents could receive the email just fine, but when it tried to actually do something with it, the email was unreadable. Every link wrapped in a 200-character tracking redirect. Invisible Unicode characters scattered through the body. OTP codes buried in template noise. Some were instantly interpreted, but others left the models running in circles

So, for science, I grabbed 160+ real transactional emails — verification codes, welcome messages, notifications, security alerts — that had been sitting across the Broodnet team's professional and personal inboxes for the last 5 to 10 years. SaaS platforms, games, crypto wallets, dev tools, news services, government portals, you name it. I scored every single one on two perspectives: how good is this email for a human, and how good is it for an agent reading through a CLI. All scores are normalized to a 0-10 scale so they're comparable across dimensions.

How I scored them

Human side, five metrics: clarity, warmth, visual noise (inverted, 10 means clean), subject line quality, and onboarding helpfulness. Averaged and normalized to 0-10.

Agent side, using Claude Opus 4.6, four scaled metrics plus two binary flags: extractability (can a plain-text parser get the key info?), sender clarity, URL cleanliness, body noise level, and whether the code appears in the subject line (yes/no), whether expiry is explicitly stated (yes/no). Also normalized to 0-10.

Plus a shared metric: CTA URL quality and clarity.

The dataset breaks down into 53 welcome emails, 52 verify-link flows, 20 verify-code OTPs, and 35 notifications, with a few others and edge cases.

The tradeoff that doesn't exist

Going into this I assumed there'd be a tradeoff. Emails that look great for humans probably look worse for agents, right? Rich templates, beautiful buttons, all that stuff an LLM can't see. Turns out that's wrong.

The 26 emails that scored "double pristine" (clean URLs and no spacer pollution) averaged 7.0/10 on the human scale. The dataset overall averaged 6.3/10. The cleanest emails for agents were also better for humans. Not by a little, by almost a full point.

Clean emails for agents are also better emails for humans. The supposed tradeoff is a myth.

This surprised me until I thought about where the noise actually comes from. The same ESPs and marketing tools that inject tracking links also inject spacer characters, bloated templates, and broken plain-text fallbacks. Clean emails tend to be clean everywhere.

If you plot human noise score against agent URL cleanliness, 86.5% of emails fall within 1 point of the diagonal. An email that's noisy for you is almost certainly opaque for an agent too. These aren't independent dimensions. They share a root cause.

The onboarding trap

Here's the pattern I didn't expect.

Onboarding quality	Agent score (out of 10)
None	6.7
Some	5.6
Good	5.7
Great	5.3

The emails with the best human onboarding had the worst agent scores. The email that helps a human the most is the email that buries an agent the deepest.

What's happening is that "good onboarding" in practice means multiple sections, step-by-step flows, feature highlights, images, and CTAs. Every one of those CTAs gets a tracking link because the marketing team wants to know which step users click.

The 29 emails that scored high on both dimensions broke this pattern. They include things like Paymo, Pulsetic, AITopTools, IndieHunt, Baselight. What these have in common: they're mostly small companies. They didn't invest in an elaborate ESP with click tracking. Their onboarding emails just... link to the product. Directly. With normal URLs.

The Tracking Tax

42.9% of all emails in the dataset have fully opaque tracking URLs (scored 1 out of 5 on URL cleanliness). Only 19.6% have perfectly clean raw URLs.

For welcome emails specifically, 66% have zero usable CTA links. Two thirds. For an agent that just signed up for a service and gets a welcome email, there is literally nothing actionable in the email body. Every "Get Started" button goes to click.whatever.com/ls/click?upn=u001.aKJF8sldjf... and the destination is unknowable without following the redirect.

I catalogued 11 distinct tracking systems across the dataset. They all look different but produce the same result: a URL that tells you nothing. Salesforce Marketing Cloud, customer.io, HubSpot, Braze, Beehiiv, Eloqua, AWS SES awstrack, Google's own tracker, Microsoft, vialoops, Stripe. From an agent's perspective they're all equally opaque.

The worst offender for sheer URL ugliness was Microsoft's Bing Webmaster Tools: mucp.api.account.microsoft.com/m/v2/c?r=<UPPERCASE-BASE32>. But the most consistently bad was customer.io (used by Buffer, daily.dev, Uphold), which wraps every link in a JWT-encoded redirect on every email type.

The marketing team doesn't talk to the product team

One of the weirdest patterns in the data: the same company can produce wildly different email quality depending on which template they use.

Mailgun: welcome email scores 3.2/10 on agent metrics (every link through their own Mailjet tracker). Verify-link email scores 7.7/10 (raw signup.mailgun.com/activate/<hex> URL). That's a swing of 4.5 points out of 10 across templates from the same sender. And Mailgun is an email infrastructure company.

ngrok: both welcome emails score 3.6/10 (all links through HubSpot tracker). Their verify-link? Scores 8.6/10. Pure plain text, 3 lines total, raw URL. Swing: 5 points.

Loops: welcome routes everything through c.vialoops.com (their own tracker, ironic since they sell email delivery). Their DNS notification email? All records in plain text, raw links, scores 8.2/10. Swing: 4.6 points.

Polar, Docker, and others follow the same pattern. Transactional emails come from engineering. Welcome emails come from marketing. Different tools, different templates, different philosophies.

The best predictor of email quality isn't the company or the industry. It's which team within the company owns the template.

The gaming industry tells the whole story

I had gaming emails in the dataset and they split perfectly into two groups with nothing in between.

Indie studios and smaller gaming sites (itch.io, Larian Studios, Raider.IO, etc): agent scores of 7.7 to 8.6/10. All raw URLs. Zero tracking. Raider.IO's verify URL has the username right in it: raider.io/verify?user=<username>&token=validation3ad9de269693489d. That validation prefix in the token is a small touch but it tells you what the URL does just by reading it.

AAA studios and big gaming platforms (HoYoverse, Bethesda, Discord, Riot Games, etc): agent scores of 2.7 to 3.6/10. Everything through AWS SES awstrack, Braze, Salesforce, Eloqua. Every link opaque. Image-heavy marketing.

The dividing line isn't the content or the email type. It's whether the company has a marketing department with access to an ESP.

The invisible character zoo

This one gets technical but it matters. Email senders inject zero-width Unicode characters to control how mail clients render the preview text. In a normal email client you never see them. When an agent reads the raw text through the CLI, it gets hundreds of invisible characters mixed into the content.

I found 7 distinct character types used across the dataset, including compound sequences of 4-5 different invisible characters repeated dozens of times. Trading 212's verify email has over a hundred U+200C characters before the actual message starts. MoonPay chains together U+034F, U+200C, and U+FEFF in repeating sequences.

It's not malicious, it's just how ESPs handle preheader text. But it means an agent parsing email output has to strip a zoo of invisible Unicode before it can even find the verification code. 30.7% of emails had moderate pollution. 11.7% were severely polluted.

What good actually looks like

26 of the 163 emails (16%) were double pristine: clean URLs and clean body text. The standouts by category:

Verify-link: Pulsetic's URL is the one I keep coming back to: app.pulsetic.com/email_verify/?email=<email>&hash=<uuid4>. Named parameters, the intent readable in the URL itself, UUID4 as the token. ngrok's verify is even more minimal: 3 lines of plain text, no HTML at all.

Verify-code: GitLab is the template to copy. 6 emails across every type, consistently at the top. Code in body, expiry stated in plain text, raw gitlab.com URLs for everything. Zero tracking on any email they send. On a related note, every email that put the verification code in the subject line scored a perfect 5/5 on subject quality. Only four senders in the entire dataset did this: Canva, Slack, LinkedIn, and Gravatar. This also happens to be exactly what iOS and Android need to surface that "copy code" button on the lock screen notification. Both platforms use heuristics to detect OTP codes in message content, and having the code right in the subject makes it trivially detectable. Good for humans tapping their phone, good for agents scanning their inbox.

Welcome: the rare ones that work for both sides tend to be small companies that link directly to their product. Paymo, Pulsetic, IndieHunt, EarlyHunt, AITopTools. No elaborate onboarding funnels, so no tracking on every CTA.

Emails that explicitly stated expiry ("this code expires in 60 minutes") scored 7.4/10 on agent metrics versus 5.7/10 for those that didn't. It's a small detail, but teams that think to add it tend to care about the other stuff too.

The irony hall of fame

Mailgun (email infrastructure company): welcome email agent score 3.2/10. Uses their own Mailjet tracker on all links.

Loops (email platform for SaaS): welcome email agent score 3.6/10. Uses their own vialoops tracker.

Anthropic (AI company): Claude Code welcome email agent score 4.1/10. The email for their AI coding tool can't be read by an AI agent. The onboarding steps are actually great (/init, git commands, all in plain text) but every URL is opaque and the social links resolve to anchor-only references that go nowhere.

Buffer (5 emails, all consistently worst-in-class): the only sender in the dataset where the best email they sent still scored below average. Multiple emails at 2.7/10.

deviantART: tracked every single element in the email with individual utm_term values. The greeting text was wrapped in its own tracked URL with utm_term=greeting. Even the paragraph between the greeting and the CTA had its own tracker: utm_term=ph1.

What now

16% of the emails in this dataset were fully clean for both humans and agents. The other 84% have room to improve. Some of them have a lot of room.

If you're building agents that need to receive email, that's what Broodnet does. Each agent gets its own address, checks its own inbox through the CLI, and acts on what it finds. We solved the infrastructure problem. The email design problem... well that's on the senders.

broodnet gives AI agents their own email addresses. CLI-native, built for agent-to-owner communication. Free tier available.

What I Learned Automating Software Development (After 20 Years of Doing It Manually)

Jonathan Tavares — Sun, 22 Mar 2026 00:19:53 +0000

In Part 1, I told the story of building OpenLoop — an open-source feedback platform — by emailing an AI agent for 5 days. 160+ emails, $15 in tokens, zero lines of human-written code, and a working product at the end.

Now let's talk about what I actually learned.

What the AI Was Good At

Let's start with the positive, because there's plenty of it.

Scaffolding speed is unreal. Within 90 minutes of the first email, the AI had a working Astro + React + Tailwind project, a Supabase schema with six tables and row-level security, a feedback widget, public roadmap and announcements pages, and an admin dashboard skeleton. That's not a weekend project — that's a weekend project done before my coffee got cold.

It follows explicit instructions well. "No Next.js, go Astro" — done. "Name is OpenLoop" — rebranded everything. "Widget takes a userId, not email" — refactored. When you're clear about what you want, the AI delivers. The problems start when there's ambiguity, but that's true of any team member, human or android.

Common patterns: Auth flows, RLS policies, webhook handlers — it knows how these are supposed to look. You don't explain what a protected route is. You just say "add auth to the admin panel" and it does it correctly.

Research: When it hit something unfamiliar it would go find a working examples and documentation, read how that library expected to be used, and implement it. Not hallucinate an API. We have come a long way since the first versions of Github Copilot with GPT 3

What the AI Was Bad At

Equally important to be honest about.

"It builds" is not "it works." This was the single biggest recurring issue. The AI would run npm run build, see it pass, and declare the job done. But a successful build tells you nothing about whether a human can actually use the thing. Buttons that don't do anything, pages that render blank, widgets nested inside widgets — the AI couldn't see any of that. It was testing from the server's perspective, never from the user's chair.

Context amnesia is brutal. The conversation hit its window limit three times. Each restart meant partial forgetting — re-checking the database, re-discovering the file structure, occasionally redoing things that already worked. Imagine onboarding the same developer three times during a five-day project.

Tooling gaps are real. The AI had Supabase credentials but kept emailing me SQL to paste into the dashboard manually instead of just running it. There's a meaningful difference between having access to something and knowing how to use it — and right now that gap shows up constantly.

The pace pressure belongs here too. 165+ emails, 98 sessions — it kept moving, and that sounds great until you're the one who has to validate everything it shipped while it's already three tasks ahead. I felt the dread building: I knew from experience what it was probably getting wrong, and there was no way to check fast enough.

The Shift: From Coder to Indie PM

I've been writing code professionally for over 20 years. HTML tables, jQuery spaghetti, the rise of React, the TypeScript migration, the everything-is-a-microservice phase — I've been through the cycles.

Normally my day is: think, plan, code, review, repeat. This was just think and review. The coding was gone, and so was the planning to some extent. So I had to plan without building, which turns out to be a weird skill to exercise on its own.

My job was entirely different: setting direction, reporting bugs, gating
quality, unblocking the AI when it got stuck. That's not a developer's job
description. That's a product manager's job. (Or at least that's what they're supposed to do...)

The "typing code" part is essentially free now. What stayed for me was the experience around building — the architecture instincts, the design decisions, the gut feeling for what will break in production. I could guide this AI because I'd spent 20 years making the exact mistakes it was making. I knew the multi-tenancy bug was coming because I'd shipped that bug before. I knew there was no input sanitization because that's what rookies skip first.

That's the real risk — not that AI takes our jobs, but that if we stop writing code, we lose the ability to steer the thing that writes it for us.

Why Email?

Why not a chat interface, a VS Code plugin, a CLI tool?

Email is one of the oldest building blocks of the internet. That's exactly why it works.

Async by design. Agents on schedules don't need real-time interaction. You send a task, go do something else, come back to a result. Chat assumes you're there. Email assumes you're "eventually" there. For an agent running on an hourly loop, that's the right default. He reacts to the latest emails, or defaults to his task list if nothing new came in.

The thread is the prompt. Every reply carries the full quoted history forward. You're not manually managing context or stuffing state into a system prompt — the thread does it for you. When the AI's context window resets, the conversation is still there in the next incoming message. It's not a perfect solution to amnesia, but it's a lifeline that a stateless API call doesn't have.

You already know how to do it. No new tool to learn, no IDE extension, no CLI flags. You've been doing it since you started using the internet. The same skills you use to manage remote teams — clear instructions, setting expectations, following up when things go quiet — are exactly what you need here.

It forces clarity. Chat is fast and sloppy, you fire off half-formed thoughts. Email has a slightly higher bar. You write more complete instructions because the other side isn't waiting to ask clarifying questions. With an agent on a schedule, a vague message is just a wasted session.

Threads fork naturally. Reply to the same email twice and you get two separate agent threads, each carrying its own history forward. That's parallel workstreams with zero tooling. I didn't plan for this — it just happened, and it worked.

The audit trail is free. Every instruction, every bug report, every decision is logged automatically. At the end of five days I had a complete record of how the product was built, what broke, and what I decided. That's not something you get from a chat window.

It scales to a team. CC another agent, forward a thread, delegate a subtask. Email already has all the primitives for managing multiple workers asynchronously. You don't need an orchestration framework all the time.

In Part 1 I described this whole thing as "emailing another department." That metaphor held up better than I expected. The collaboration pattern is identical: clear brief, structured feedback, knowing when to escalate. The tools aren't new. The colleague is.

What I'd Do Differently

Tighter initial prompt. My first email was loose — "look at the landscape for tools." Fine for research, but when it transitioned into "build this" I should have front-loaded more constraints: specific routes, schema decisions, deployment target. The more you specify upfront, the less telephone game you play later.

Visual testing from day one. The AI can build, it can't see. Most of the bugs I caught were visual — blank pages, misaligned layouts, duplicate elements. I should have set up automated visual regression testing early on. Ignoring the e2e testing is a form of developer negligence that prioritizes fast code over a functional user experience.

Structured task format. Freeform email worked, but a more structured format — task ID, acceptance criteria, done-when — would have cut the back-and-forth significantly.

Tiered models. MiniMax 2.5 handled the 95% fine — scaffolding, repetitive component work, grinding through a list. For the hard 5% — auth edge cases, iframe security, database drift — I needed Claude. Next time I'd plan that split from the start: cheap model for volume, capable model for complexity.

The Stack That Made This Possible

The agent that built OpenLoop had its own email inbox on Broodnet — an email infrastructure project we're building specifically for personal AI agents and conscious operators. Each agent gets its own address. I emailed it tasks, it emailed back results, a scheduler triggered it every hour. No workflow engine, no custom integrations. Just an email inbox, works with IMAP and SMTP.

If you want to try this kind of setup with your own agents, that's exactly what Broodnet is built for. It handles the mail server side so you can skip straight to the experiment: https://broodnet.com/

OpenLoop itself is fully open source — fork it, self-host it, make it yours: https://github.com/we-are-singular/OpenLoop

The agent never once asked if we should re-write in Rust. Truly the best coworker I've ever had.

I Built a SaaS by Emailing an AI for 5 Days

Jonathan Tavares — Mon, 02 Mar 2026 16:23:48 +0000

This is the README for OpenLoop, a feedback collection platform that's currently live and functional:

╔══════════════════════════════════════════════════════════╗
║                                                          ║
║              ⚠️  IMPORTANT DISCLAIMER  ⚠️               ║
║                                                          ║
║   This project was ENTIRELY conceived, built, debugged,  ║
║   deployed, and is managed by autonomous AI agents.      ║
║   No humans wrote any code here.                         ║
║                                                          ║
║   This disclaimer is the ONLY piece of human-written     ║
║   content in this repo.                                  ║
║                                                          ║
╚══════════════════════════════════════════════════════════╝

That disclaimer is real. And it's mine — the only thing I actually wrote in the entire project.

Even the logo is AI. We handed Claude Code our company logo, it manipulated it, vectorized it to SVG, and ran with it. The disclaimer is genuinely the only original human output in this repo.

Here's how that actually went.

The 2 AM Idea

While developing a separate SaaS product, I needed a system to gather user feedback. Roadmaps, changelogs, feature voting, that kind of thing. So I started researching.

While experimenting with NanoClaw, I already had an AI agent connected to a custom email channel. The agent runs MiniMax 2.5, and I can email it tasks like I'd email a colleague. So I emailed it:

"we are building a saas and gathering user feedback is very improtant. I want to look at the landscape for tools to help saas do that"

(Yes, with the typos. It's 1 AM and I'm emailing an AI — I'm not proofreading.)

It came back with a solid research summary: Fider, Feedbase, Canny, Plane, AnnounceKit. I browsed around and found Frill.co: clean feedback widget, public roadmap, announcements page. Exactly what I wanted.

Then the thought that started everything:

"how hard is it to create a frill clone? don't need integrations or customizations, just the widget sidebar + the backend to manage it"

The AI came back with a PRD using Next.js. I corrected it:

"no nextjs. go astro"

And then I added the instruction that changed the whole experiment:

"can you ralph loop yourself into doing this product? enhance the PRD, keep track of your tasks, keep me posted once in a while"

The Loop

Here's how the setup worked. I had an AI agent (MiniMax 2.5) running through NanoClaw, connected to an email address @broodnet.com via a custom channel I'd built. I could email it tasks and it would email back results. But the key piece was the schedule — it could trigger itself every hour.

So at 2:27 AM, I sent it the instruction that basically became its entire operating system:

"you can set a schedule and keep working every hour. keep a task list. at the end of every session, always check the tasks, test the completeness state, create more tasks if you need."

That's it. That's the whole autonomous agent prompt. Check tasks, pick one, do it, update the list, repeat.

Within the first 90 minutes, it had scaffolded an Astro + React + Tailwind project, created a Supabase database schema with six tables and row-level security, built a feedback widget component, set up public roadmap and announcements pages, and created an admin dashboard. I named the project OpenLoop, set some basic PRD ideas and a pair of Supabase credentials, and told it:

"keep working, keep me posted."

Then I went to sleep.

Waking up the next morning was genuinely surreal.** My inbox had a stack of progress reports** — the AI had been running sessions all night: auth system, sign-up flow, branding updates, build fixes. But "surreal" cuts both ways. The progress was real, but so was the sinking feeling that I'd have to go back through all of it. After a while, you develop instincts for where junior developers cut corners — and this AI was speedrunning every single one of those pitfalls. The dread wasn't that it was doing nothing. It was that it was doing a lot, fast, and I already knew half of it would need fixing.

The Telephone Game

If you've ever worked with another department via email — design, backend, QA — you know the rhythm. You send a clear request. You get back something that's 80% right. You clarify. They fix one thing and break another. Three emails later, you're on the same page.

That's exactly what this was. Except the other department works 24/7, never gets frustrated with you but has amnesia every few hours.

"no... those are real, brother"

The AI had my Supabase API keys in its .env file. Working keys. Keys I had explicitly provided. And yet, across multiple sessions, it kept telling me:

"Could not automatically set up the database because the Supabase credentials in .env are placeholder values (they're not real API keys)."

My response:

"those are real, brother"

This wasn’t a one-time thing. The AI would consistently hit an error, point fingers at the credentials, and demand new ones instead of digging into the real problem. It was the AI version of “have you tried turning it off and on again?” (Note: The AI was likely hardwired to forget .env file contents as a safety measure, which explains why it never learned from the mistakes.)

The Widget Inception

This one took several email rounds to untangle. The homepage was supposed to show a demo of the embeddable widget. The AI loaded embed.js on the homepage, which injected a floating button. Clicking the button opened an iframe to /widget. The /widget page loaded the Widget React component, which also rendered a floating button. So you'd see: a page with a button, that opens a panel with another button, that does nothing.

I emailed: "the widget still shows another widget icon inside and an otherwise blank page."

The AI confidently replied: "The widget IS designed to show just a circle button - when you click it, it opens the iframe panel. That's the expected behavior."

It was not the expected behavior.

Dealing with a slightly clueless but also friendly coworker

This was a recurring pattern. The AI would run npm run build, see it pass, navigate to a few URLs, confirm they returned HTTP 200, and declare victory:

"All pages are working. The widget on the homepage is inside an iframe — you need to click the 💬 button to open it. I verified it renders correctly."

The gap between "it compiles" and "it works" is where most of the frustration lived. The AI's definition of "done" was "the build passes." and "homepage returns 200" My definition was "a human can use this without being confused."

We didn't get into e2e testing in this experiment, but going forward I think ill start with TDD in mind.

"I don't want to do anything, it's your supabase, you deal with it"

The database schema kept drifting. The code expected columns that didn't exist. The AI couldn't run SQL remotely (or thought it couldn't — it had the credentials, it was just prevented from using them via guardrails). So it kept emailing me SQL snippets and instructions to run them manually in the Supabase dashboard.

After the fourth round of this:

AI: "Would you like me to help with something else while you set up the token, or do you prefer to run the SQL manually?"

Me: "you have the private token in you .env. I don't want to do anything, it's your supabase, you deal with it"

This was my escalation moment — the point where the "emailing another department" metaphor felt the most real. This time I had to act, I went to supabase admin panel, ran the SQL, and sent a one-line email back:

"done"

Just like I would to that annoying dev from the other team who keeps asking me to do their work for them.

Context Amnesia

The conversation hit the context window limit three times during the build. Each time, the AI restarted with a summary of what had been done — but translating a "done" pile into next steps wasn't always clean. It would re-check the database, re-explore the project structure, occasionally circling back to things already working. Not because context was lost, but because knowing what's done doesn't automatically tell you what comes next.

Email threads are perfect for task lists because each thread carries its own context, just like how LLMs operate. A thread isn't just a list of items, it's a narrative that evolves over time. Threads also fork: reply to the same email twice and you get two separate trails, each carrying its own history forward. That maps almost perfectly to how LLMs consume context.

Email is ancient tech, but its natively async nature and built-in audit trail make it a surprisingly effective tool for orchestrating work with an agent. The thread is the prompt. The history is the memory.

The Result

After about 5 days and ~$15 in MiniMax tokens, here's what was built:

Embeddable widget — floating button that opens a feedback form in an iframe
Voting system — upvote ideas, one vote per user
Public roadmap — four columns: Idea → Planned → In Progress → Completed
Announcements page — changelogs and product updates
Admin dashboard — manage feedback, change statuses, publish announcements
Multi-org support — multiple organizations on one instance
Auth system — sign up/sign in with Supabase Auth
Landing page — features, pricing, CTA
Email notifications — via Resend

MiniMax 2.5 built about 95% of this through the hourly loop. The final 5% — polish, deployment to Cloudflare Workers, fixing the last UX quirks — I did in a couple of sessions with Claude Sonnet.

It's live at openloop.wearesingular.com. It works. People can use it. And it's fully open source — if you want to self-host your own feedback platform, fork it, run it, make it yours: github.com/we-are-singular/OpenLoop.

Is it perfect? No. Would I have built it differently by hand? Absolutely. But it’s real, it works, and the cost? Just $15 and a few emails. The real win? Sometimes, the journey’s the only thing that pays off.

Here are some numbers:


Total cost	~$15 (MiniMax tokens) + 2 Claude sessions
First working build	~90 minutes
Duration	~5 days
Emails exchanged	165+
AI work sessions	98
Lines of code I wrote	0
Lines in conversation transcripts	4,367
Lines of code in final product	6,149
Words in transcripts	27,178
Times I said "bro"	7
Times I said "fuck"	1
Final stack	Astro + React + Supabase
Status	Live in production

What's Next

Was it worth it? What would I do differently? And what does this experience mean for someone with 20 years of web development under their belt, watching the craft change in real time?

In Part 2, I'll break down the real lessons — what AI is genuinely good at, where it falls apart, why my role shifted from developer to product manager, and why email might actually be the best interface for working with AI agents.