Editorial note
How to Build an Audio Website in the Age of AI
A behind-the-scenes account of building Informed Listening in a single afternoon using AI coding tools.
This is a behind-the-scenes note on how Informed Listening came together, rather than a technical or measurement article.
Six hours, roughly
The honest answer to “how long did this take” is about six hours, spread across a single session, using AI coding tools throughout. Six hours isn’t a speed record. It’s a useful data point about what these tools are good for right now, and where they still need a careful editor sitting over their shoulder.
The build broke down roughly like this:
- Domain and architecture — 30 minutes
- Infrastructure setup — 10 minutes
- Website build — 30 minutes
- News monitoring tool — 2 hours
- Article generation — 2 hours
- Final tweaking — 1 hour
Domain and architecture
The site needed a name before it needed anything else. “informedlistening.com” was available for about $15 a year, which settled that question quickly. The bigger decision was architecture, and here prior experience mattered more than the AI tooling did: an existing Hugo static site (for a sister site, PragmaticAudio) meant the shape of the solution was already known — static generation, GitLab Pages hosting, a simple content model of reviews, articles, and news. AI is very good at extending a pattern you already trust; it is a slower way to discover that pattern for the first time.
Infrastructure in ten minutes
With the architecture decided, getting GitLab Pages wired up and DNS pointed at it through AWS Route 53 took about ten minutes, mostly because the instructions could be generated directly rather than re-derived from documentation. This is the least interesting part of the build and also the part where AI assistance saves the most proportional time — nobody enjoys re-reading Route 53 record-type documentation.
The Hugo build
The core Hugo site — page structure, layouts, and the three main content sections (Reviews, Informed Articles, and News) — came together in about half an hour. Because the content model was already decided, this step was mostly scaffolding: taxonomies, list templates, and a homepage that could pull from all three sections.
A local LLM for news monitoring
The most substantial piece of engineering was a Python tool that monitors RSS feeds from a set of audio news sources, and uses a locally-run Gemma (4B/12B) model to summarize candidate stories before they go anywhere near the website. Running the summarization model locally, rather than through a hosted API, keeps the monitoring loop cheap enough to run continuously and keeps a human editorial step between “the feed mentioned this” and “this is published.”
This piece took about two hours, most of it spent on the feed-parsing and deduplication logic rather than on the LLM integration itself, which was comparatively simple.
Turning forum threads into articles
The “Informed Articles” section draws on long-form discussion threads from forums like ASR and headphones.com — the kind of thread that contains a genuinely useful argument buried in fifteen pages of back-and-forth. Generating a first-draft article from one of these threads, including requesting diagrams and images to illustrate the argument, took roughly two hours across the first batch of articles.
This is also the step that most needs editorial oversight. A generated article can read fluently and still misrepresent the balance of a forum discussion, flatten a caveat the original poster cared about, or invent a diagram that looks authoritative but isn’t. That’s why every article adapted from someone else’s discussion links back to its source. It’s the one thing that catches a generated draft misrepresenting a discussion.
Making it look consistent
The last hour went into layout tweaks and making the review template consistent with the existing PragmaticAudio site, so that a reader moving between the two properties would not notice a jarring change in tone or structure.
So what does this actually prove?
This doesn’t prove AI tooling replaces editorial judgment. It is evidence that these tools get you from an idea to a working site fast, with real content to react to and correct, provided the person driving it already knows the architecture they want and is prepared to review what comes out the other end. The honest caveat stands: more time should have gone into reviewing the first batch of generated content before it went live than actually went into reviewing it.