Q&A with Stephen Green

Jonathan: We saw the substantial work your team produced. How was the hackathon approached? How were the teams structured? What made the process efficient?

Stephen: It was an interesting case study. We started with a basic requirements discussion for the charity—a web app. I quickly generated some static web pages using Kiro while the AWS team lead worked with the client to narrow down and prioritise the requirements. The first thing on day two was turning the requirements document into an MD doc for Kiro, which it used to create an initial task list and a reasonable, bare-bones application.

Jonathan: So, you fast-tracked getting the core web app to enable parallel work?

Stephen: Yes, that was key. Structuring the work and assigning tasks efficiently across the team was honestly the hardest part, but getting that basic web application up allowed others to pick up different pages and carve out blocks of work. We had a team of seven or eight people, including myself, two AWS staff, a client, two consultants from Reply, a BBC employee who works with Java and data pipelines (which was a big shift for him!), and a student. So no specialist front-end devs!

Jonathan: What technical challenges did the team face with the AWS and AI components?

Stephen: The main project idea was a VR AI therapist. One team member quickly got the voice-to-voice AI component working locally, but it never deployed successfully to the cloud. The feature got trapped in a loop with load balancer and SSL issues with Kiro going in circles trying to configure the deployment, which failed repeatedly, Kiro tried to fix, and so on. I also tried integrating Bedrock Agent Core for a chatbot, which also worked locally, but we had persistent authentication and logging issues in deployment.

Jonathan: From a long-term perspective, what is the key benefit for the charities that participate?

Stephen: That’s a good question. For bigger, established charities like Cancer Research UK, a hackathon project is something they can realistically take, test alongside their existing operations, and move forward with their internal team or contractors. However, our charity was very small, with limited permanent staff, and they wanted a core platform to be built in two or three days. I think the real takeaway for the charities—especially the smaller ones—is a Proof of Concept (POC) and Public Relations (PR).

Jonathan: Based on your experience, it seems that quickly defining requirements and enabling parallel work are the two most important factors for a successful hackathon. Is that fair?

Stephen: Absolutely, for a hackathon with a decent-sized team. Everyone wants to contribute, but AI tends to design solutions in a very linear fashion. In some ways, it is just the ‘mythical man-month’ problem common in all project work, just with very little time to solve it!

Jonathan: On the note of development, you mentioned using Kiro for the front end. Could a hackathon approach be adopted for client POCs, especially for web front ends?

Stephen: I think so, with the right client. We could certainly produce a full-featured POC in a couple of days or even hours, and be clear that it's a throwaway—it doesn't follow best practices. I was particularly impressed with how well AI tools like Kiro handled the UI/UX aspects, moving boxes and changing colour schemes quickly. This approach could potentially replace traditional flow diagrams by offering a placeholder front-end instantly.

Jonathan: What future improvements do you think AI code generation tools like Kiro need?

Stephen: The current codebases are much larger and more complex, with extensive use of AWS services. What's missing is for AI tools to prioritise separating concerns—for example, defining a clear API between the front and back end. That's the most critical step to solve first, so that multiple people can work on different parts of the application independently.