From Idea to Internal Tool in 31 Minutes: What AI-Accelerated Prototyping Taught Me
Every engineering team has the same quiet problem: pull requests that sit unreviewed. Nobody is ignoring them on purpose. They just get lost across a dozen repos, behind Slack threads and stand-ups. The fix was obvious: a daily digest of every open PR the team owns. The tool had never been built because it was never anyone's priority. So I gave it 31 minutes, with an AI assistant doing most of the typing. The result was a small Slack bot that posts a morning summary to the team's channel, listing every pull request that's waiting for review, how long each one has waited, and where it's stuck. This talk isn't a demo of how fast AI can write code. It's an honest look at where those 31 minutes went. Some of it was the AI doing the work. Some of it was me describing what I wanted, checking the output and fixing it. And there were the parts that went wrong: the edge cases the AI got confidently wrong or the bug reports that only came in once real teams depended on it. If a prototype takes half an hour instead of half a sprint, the question stops being "can we build it?" and becomes "want to see what I built?" Key takeaways: - Where the time really goes in an AI-assisted build, and what the AI sped up or slowed down - A repeatable path from team annoyance to a tool teams can use - How to catch AI output that's confidently wrong before your users do - Why a working prototype is more convincing than a pitch
Adam McGrogan
Adam McGrogan is a final-year Computing and IT student at Queen's University Belfast, and a Placement Software Engineer at DailyPay, where he works on backend microservices and internal developer tooling. He's especially interested in how AI is changing the way engineers build software, and he enjoys turning the small frustrations that slow teams down into tools that make them go away.