Situation
I wanted to test a question that’s increasingly relevant across product, design and technology teams: what does high-quality product development actually look like when AI becomes part of the delivery process, not as a demo, but on a real product with real constraints?
The test case was a browser-based Australian radio streaming platform. Australia has hundreds of stations across commercial, community, regional and digital broadcasters, but no unified discovery or listening experience, streaming infrastructure varies wildly between providers, browser audio behaviour is inconsistent across devices, and many streams aren’t configured in ways modern web apps handle reliably. I aggregated over 1,500 of them into a single progressive web app, under deliberate constraints:
- Zero operating cost at launch
- No backend database initially
- Single codebase, dual deployment targets
- Reliable browser-based streaming across devices and browsers
- Production-grade experience on lightweight infrastructure
Task
The goal wasn’t “build an app”, it was to understand where AI genuinely augments product and engineering work, and where it doesn’t. Specifically: where does it accelerate delivery, where does it introduce risk or technical debt, how good is it at debugging real infrastructure problems, can it bridge capability gaps into unfamiliar technology, and what still needs human judgement? The challenge was to use AI as an actual development partner, not a code-generation novelty.
Action
Wave 1, Architecture and product planning.
The biggest early lesson: AI works best when paired with strong upfront thinking. Before writing significant code, I mapped platform objectives, UX priorities, hosting architecture, stream ingestion strategy, scalability paths, PWA/offline behaviour and deployment constraints. The clearer the intent going in, the better the AI output coming out, poorly considered architecture produced poor implementation, fast.
↑ Simple responsive UI design in early-stage testing
Wave 2, Data ingestion and scale.
Using the Radio Browser API, AI significantly sped up ingestion scripts, transformation logic and filtering, turning what’s normally documentation-heavy trial-and-error into a conversational, iterative process. The platform scaled from an ~18-station proof of concept to 1,500+ aggregated stations. This phase doubled as a fast-track learning environment for unfamiliar territory: API integration patterns, MCP concepts, static hosting optimisation, Vercel deployment, CI/CD, and stream-handling edge cases, AI acted less like a code generator here and more like an accelerated technical mentor.
Wave 3, Player experience and PWA features.
Focus shifted to frontend and interaction: persistent playback, Web Audio API waveform visualisation, lock-screen/MediaSession integration, full PWA support, mobile-first responsive design, and background playback. This is where AI-assisted development showed its strongest use case, rapid iteration across unfamiliar APIs that would normally carry heavy research overhead (MediaSession integration, browser audio behaviour). But it also reinforced that AI output still needs human evaluation: plausible-looking solutions weren’t always correct or production-safe, and architectural judgement and UX refinement stayed firmly human-led.
Wave 4, Streaming reliability and production hardening.
The hardest phase, and the one that exposed AI’s limits fastest. Real-world streaming threw up mixed-content blocking, CORS restrictions, HTTPS incompatibilities, TCP instability, browser autoplay policies, and inconsistent provider configurations. AI was genuinely useful for generating hypotheses and troubleshooting paths quickly, but solving the actual problems took systems thinking, testing discipline and persistence, including an unconventional fix using GitHub Pages and CI workflows to work around streaming reliability limits under static hosting. The distinction that came out of this phase: AI accelerates implementation and exploration, but is far less reliable at resolving complex systems problems on its own.
Result
The platform shipped as a production-ready browser radio app: 1,500+ stations, full PWA deployment, browser-based streaming across mobile and desktop, MediaSession/lock-screen integration, static deployment architecture, dual deployment from a single codebase, zero operating cost at launch.
More significant than the product itself was what the process showed about AI-assisted delivery:
- It compressed implementation time and research friction substantially, especially for unfamiliar tech (API integration, PWA behaviour, deployment pipelines)
- It reduced the friction of moving between product, design and engineering work, one person operating across a wider delivery surface than would normally be practical
- It made architectural ideas cheaper to test quickly
But it also had real limits: AI regularly produced technically plausible but incorrect solutions, generated code often needed real refinement, and architectural mistakes could compound fast once implementation was accelerated. Complex infrastructure problems (Wave 4) still required deep human reasoning, the harder the problem, the less AI could carry on its own.
Summary
The core insight: AI doesn’t remove the need for expertise or judgement, it relocates where the leverage is. It compresses implementation effort and research friction, and lets a single person operate across a much broader delivery surface than was previously realistic. But output quality still depends on clarity of thinking, architectural discipline, product judgement and critical evaluation of what the AI produces.
In practice, it felt less like “AI replacing development” and more like working with an extremely fast, highly capable junior engineer, able to prototype, explore, and debug quickly, but needing direction, validation and oversight throughout. For product designers and strategic technologists, that’s the real shift: the gap between idea, architecture and implementation is collapsing, which makes the ability to think across product, experience and technical systems more valuable, not less.