From Prototype to Production Code at BAFTA View

In August I wrote about building a working prototype for BAFTA View’s support agent with agentic engineering, so the team could evaluate the idea before committing developer time. This is what happened next, as that prototype became production code owned by a BAFTA developer and I kept contributing to it myself.

From prototype to a developer’s hands

After validating the concept with stakeholders across the organisation, I spoke with the development team to work out how to move forward. The Make.com workflow used webhooks, so there was no need to build a new one, and Claude had already produced production-grade code, a self-contained JavaScript widget, so I shared the GitHub repository with one of BAFTA’s senior developers to implement in BAFTA View.

Hardening it for production

The developer forked the prototype and added significant development. It now authenticates against BAFTA’s real member login rather than a shared demo password, encrypts each member’s conversation history so it cannot be read by whoever uses a shared device next and integrates with the Voting API that already manages BAFTA’s award data. These were additional security layers the prototype had not needed.

He also ran a security review that found sixteen issues, from a conversation ID that could cross between members on a shared device to a markdown renderer that could misrender a link’s destination. All were fixed and documented, including why an obvious-looking fix would have been wrong. About ten of the sixteen were generic client-side bugs with nothing to do with BAFTA’s login system: a prompt injection route through a URL parameter, a drag and drop handler that would have interfered with the rest of the page it sat on, no cap on how large an uploaded image could be before the browser tried to read it into memory and a markdown rendering bug that could corrupt a link if the AI’s reply contained the wrong text.

Checking what survived the rebuild

When the Jira ticket came back to me to review on staging, I checked whether the tone of voice decisions and original design from my prototype had survived. They had. The production version had diverged everywhere it needed to, around authentication and storage, and stayed identical everywhere it did not need to change.

The developer showed me how to fork a branch from his new repository. I asked Claude to investigate what had survived and what needed further attention and to update our original repository where necessary. I also asked it to explain what had changed and why, so I understood it. I wanted to keep the original prototype for rapid testing and iteration so I could fold in further feedback quickly, with Claude keeping it in line with the production version.

Fixing the production code myself

After the staging deployment a stakeholder reported a genuine bug. A conversation that had sat idle for a while would fail with a timeout, and clicking “Try again” resent the same message down the same broken thread rather than starting fresh. Claude implemented a fix that refreshed the page and stopped the recurring error, and I added a “Start new chat” option directly on the error message, alongside “Try again”, built on the same reset logic the header button already used.

I also asked Claude to compile a document of every piece of member-facing text in the widget, the welcome messages, error states and button labels, so the membership team could review it against BAFTA’s own tone of voice guides. They found a handful of real inconsistencies and returned the document, and Claude updated the copy.

The last step was porting these changes into the developer’s actual production repository. I could not simply copy my files over his, since his version had evolved its own more thorough reset logic that also had to account for the encrypted storage. Claude read his real code first and extended what was already there rather than replacing it, then opened a pull request describing exactly what had changed and why. The developer reviewed the pull request and merged it, unchanged, into the production code that same day. My first code, well, Claude’s code, was live on a BAFTA product.

Closing the gap between finding and fixing

Receiving that email reminded me of something Elena Verna wrote recently. She described taking a screenshot of a broken button, telling Cursor what was wrong with it and having it fix the colour and open a pull request, despite having no engineering background. Her point was that the gap between noticing something is wrong and actually fixing it has closed for people who would never previously have been the ones making the fix.

That was the pattern here. None of what I fixed needed the developer’s specific knowledge of BAFTA’s authentication or encryption, and asking him to stop and do it would have taken time away from work that depended on that expertise, particularly when he had effectively solved the underlying problem once already in a different repository. What he still owns, rightly, is reviewing what comes in and deciding whether it is good enough to merge. That is a better use of a developer’s time than being the only person allowed to fix a small, well understood bug.