← Back to posts Herald: An AI Changelog System Built in a Day and Abandoned in a Week
The Fastest I’ve Ever Built Something I Didn’t Need
On September 3rd 2025, I sat down with Kiro - AWS’s AI coding agent, which I was trying for the first time - and built an entire automated changelog system from scratch. Fifteen commits in a single day. I called it Herald.
By November 28th, I deleted all of it.
Herald is the most complete thing I’ve ever built that served absolutely no purpose. And the speed at which I built it is exactly why it existed at all.
What Herald Actually Was
The idea was straightforward: automatically generate human-readable changelogs from git history, powered by AI. The architecture looked like this:
- Git Analysis Lambda - scan commits, detect what changed, categorise by type
- Bedrock Content Generation Lambda - feed commit data to Claude, get back prose
- Build Orchestration Lambda - coordinate the pipeline
- README Extraction Lambda - pull context from project docs
- Full CDK infrastructure stack - the whole backend, properly deployed
- Historical archive system - search and navigation across past changelogs
- CI/CD pipeline - CodeBuild, CodeStar connections, the works
This wasn’t a prototype. This was a fully architected system with error handling, monitoring infrastructure, type definitions, data integration tests, and search functionality. In one day.
The Kiro Effect
Kiro was new to me. I was testing it out, seeing what it could do. And what it could do, it turned out, was make me feel incredibly productive while building something nobody asked for.
The workflow was intoxicating. I’d describe a component, Kiro would generate it, I’d review and tweak, commit, move on. The feedback loop was so tight that the question “should I build this?” never had time to surface. By the time you’d normally be sketching an architecture diagram, I had working Lambda functions.
There’s a specific danger here that I think anyone using AI coding tools has experienced: the cost of building drops so low that the decision to build becomes automatic. You don’t evaluate whether a changelog system is the best use of your time. You just… build it. Because you can. Because it’s Tuesday and you’re curious about a new tool and the code is flowing.
The commit messages tell the story. Look at the cadence:
feat(types): add comprehensive changelog type definitionsfeat(aws): implement Git analysis Lambda functionfeat(aws): implement AWS Bedrock content generation Lambdafeat(aws): implement README extraction Lambda functionfeat(aws): implement build orchestration Lambda functionfeat(aws): implement complete CDK infrastructure stackfeat(herald): implement complete historical archive system with searchfeat(herald): implement comprehensive data integration and testingfeat(herald): implement comprehensive error handling and monitoringfeat(herald): implement comprehensive CI/CD deployment infrastructureupdate kiro tasklistfeat(herald): complete task 16 and improve project configuration
That’s a full system. Types, four Lambda functions, CDK infrastructure, archives, testing, error handling, CI/CD. All in one sitting. That “update kiro tasklist” commit in the middle is the tell - Kiro was managing a task list and I was checking things off like a to-do app speedrun.
The Slow Death
September 4th: one more commit. Code quality cleanup.
Then September 9th: six commits trying to get the CI/CD pipeline working. CodeStar connection issues, CodeBuild cache conflicts, branch triggers pointing at the wrong branch. The kind of unglamorous infrastructure plumbing that AI tools are less good at - the stuff where you’re fighting AWS service integration quirks, not generating green-field code.
September 12th: Herald gets migrated from Biome to ESLint as part of a broader linting change. Routine maintenance. Not a sign of life, just a sign of it existing in the monorepo.
Then silence. Three months of nothing.
November 28th: “Remove Herald/Changelog and clean up GitHub connection from staging account.”
One commit. Gone.
The Real Problem
Herald wasn’t a bad idea. Automated changelogs are genuinely useful. The architecture was sound. The code was well-structured. If I’d needed it, it would have worked.
But I didn’t need it. Our startup is two people: me and my non-technical business partner. I knew what changed because I was the one changing it. The elaborate pipeline of Lambdas analysing git history and feeding it to Bedrock for prose generation was solving a communication problem we didn’t have - while the problems we did have (CI reliability, deployment automation, actual product features) sat waiting.
This is the pattern I keep seeing with AI coding tools: the bottleneck shifts. Before AI assistance, the bottleneck was implementation speed. You had to be selective about what to build because building was expensive. With AI tools, implementation is cheap but judgment becomes the bottleneck. The hard part isn’t writing the code anymore. The hard part is deciding what code to write.
Herald was a judgment failure dressed up as productivity.
The Shiny Object Pattern
I’d love to say Herald was an isolated incident, but it wasn’t. This period - mid-2025 - was peak “shiny object” season. Every new AI coding tool was an excuse to build something. Cursor, Kiro, Claude in various forms - each one got its inaugural project, and those projects had a suspicious tendency to be technically interesting but strategically irrelevant.
The pattern is always the same:
- Try new AI tool
- Need a project to test it on
- Pick something that sounds cool
- Build it in a day because the tool is good
- Feel productive
- Never use it
- Delete it three months later
The speed is the trap. If Herald had taken two weeks to build, I would have abandoned it after day two when the novelty wore off and I remembered that nobody was asking for it. But it took a day. The sunk cost was so low that I never hit the “wait, why am I doing this?” checkpoint.
What I’d Do Differently
Not “don’t use AI coding tools” - that ship has sailed and they’re genuinely transformative. But I’ve started applying a rule: before starting any new project with AI assistance, write down the user and the problem in one sentence. If you can’t, or if the user is “me, because it would be cool,” stop.
Herald’s sentence would have been: “Engineers will read AI-generated changelogs instead of git log.” Nobody was going to do that. Nobody was struggling with git log. The problem was fictional.
The other thing I’d do differently: separate the tool evaluation from the project. If you want to test Kiro, test it on something you already need to build. Don’t invent work to justify trying a new toy. The toy will still be shiny tomorrow, and you’ll have something useful to show for it.
The Epitaph
Herald lived for 86 days. In that time, it accumulated 15 commits on its birthday, a handful of pipeline fixes, one linting migration, and zero users. It was deleted in a single commit with no ceremony.
It was, by every measure, the most well-engineered thing I’ve ever thrown away.
Rest in peace, Herald. You were a very good answer to a question nobody asked.
I Built an Entire Product in a Day and Deleted It Three Months Later
The Most Complete Thing I’ve Ever Thrown Away
On September 3rd 2025, I sat down with a new AI coding assistant — Kiro, AWS’s take on the AI pair programmer concept — and built an entire automated changelog system from scratch. I called it Herald.
Fifteen commits in one day. A full backend. Multiple processing stages, cloud infrastructure, AI integration, search, monitoring, deployment pipelines.
By November 28th, I deleted all of it in a single commit.
Herald is the most polished thing I’ve ever built that served absolutely no purpose. The speed at which I built it is exactly why it existed at all.
What Herald Actually Was
The idea was reasonable enough: automatically generate human-readable changelogs from git history, using AI to turn raw commit data into something a person might actually want to read.
The implementation was… not small. It had:
- A component to scan commits and categorise what changed
- A component to feed that data to an AI model and get back readable prose
- A component to coordinate the pipeline between those two
- A component to pull in context from project documentation
- Full cloud infrastructure, properly configured and deployed
- A historical archive with search functionality
- A complete deployment pipeline
This wasn’t a proof of concept. This was a properly architected system with error handling, monitoring, type definitions, data tests, and search. In one day.
The Trap
Kiro was new to me. I was testing it, seeing what it could do. And what it could do, it turned out, was make me feel incredibly productive while building something nobody asked for.
The feedback loop was intoxicating. Describe a component, the AI generates it, review and adjust, commit, move on. The loop was so tight that the question “should I be building this?” never had time to surface. By the time you’d normally be sketching out your approach on paper, you already had working code.
There’s a specific danger here that I think anyone using AI coding tools has felt: when building gets cheap, the decision to build becomes automatic. You stop evaluating whether something is worth your time and just… do it. Because you can. Because it’s a Tuesday and you’re curious about a new tool and the code is flowing.
The commit history tells the whole story. Multiple commits in quick succession, each one a complete new component. There’s one commit in the middle that just says “update kiro tasklist” — the AI was managing a checklist and I was checking things off like a to-do app speedrun. The list reached the end before I’d asked whether the list was worth completing.
The Slow Fade
September 4th: one more commit. Code tidying.
September 9th: six commits trying to get the deployment pipeline working. This is where things slowed down — fighting with AWS integration quirks, the kind of fiddly infrastructure work where AI tools are less impressive. Not generating exciting new code, just troubleshooting configuration details.
September 12th: Herald gets updated as part of a routine linting change across the monorepo. Not a sign of life, just a sign of it existing and needing maintenance.
Then silence. Three months.
November 28th: “Remove Herald and clean up.”
One commit. Gone.
The Real Problem
Herald wasn’t a bad idea. Automated changelogs are genuinely useful for larger teams. The code was well-structured. The architecture was sound.
But our startup is two people: me and my non-technical business partner. I knew what changed because I was the one changing it. The elaborate system for turning git history into readable prose was solving a communication problem we didn’t have — while the problems we actually had (CI reliability, deployment automation, product features that customers wanted) sat waiting.
This is the pattern I keep seeing: AI tools shift where the bottleneck is. Before AI assistance, the bottleneck was building speed. You had to be selective because implementation was expensive. With AI tools, implementation is cheap, and judgment becomes the bottleneck. The hard part isn’t writing the code anymore. The hard part is deciding what code to write.
Herald was a judgment failure dressed up as productivity.
The Shiny Object Loop
I’d love to say this was an isolated incident. It wasn’t. This period — mid-2025 — was peak “new AI tool” season. Every new coding assistant was an excuse to build something. Each tool got an inaugural project, and those projects had a suspicious tendency to be technically interesting but strategically irrelevant.
The pattern always went the same way:
- Try a new AI tool
- Need something to test it on
- Pick something that sounds cool
- Build it in a day because the tool is great
- Feel very productive
- Never use it
- Delete it three months later
The speed is the trap. If Herald had taken two weeks, I’d have abandoned it after day two when the novelty wore off and I remembered nobody was asking for it. But it took one day. The cost was so low I never hit the “wait, why am I doing this?” checkpoint.
What I’d Do Differently
Not “stop using AI coding tools” — they’re genuinely transformative and there’s no going back. But I now apply one rule before starting any new project: write down the user and the problem in one sentence. If you can’t, or if the user is “me, because it would be interesting,” stop.
Herald’s sentence would have been: “Engineers will read AI-generated changelogs instead of looking at the git history themselves.” Nobody was going to do that. Nobody was struggling with the git history. The problem was fictional.
The other lesson: separate the tool evaluation from the project. If you want to try a new tool, test it on something you already need to build. Don’t invent work to justify the curiosity. The tool will still be there tomorrow, and you’ll have something useful to show for it.
Herald lived for 86 days. Fifteen commits on day one, a handful of fixes, one maintenance update, zero users. Deleted in a single commit with no ceremony.
The most well-engineered thing I’ve ever thrown away.
Rest in peace, Herald. You were a very good answer to a question nobody asked.
This is the first post in an ongoing series about building a startup from scratch with AI assistance. The AI tools evolved significantly — for where things ended up, see AI Coding Tools, Part 1 and Part 2.