Our engineering team spent two days in Bournemouth learning, building and sharing. Last time the question was ‘what AI can do for us?‘ This time the focus was on an engineering AI hackathon. How we choose the right tool for each job, and how we use AI to improve the way we build software for social care.
From generating code to imroving how we work
Earlier this month we shared the story of our first company wide Nourish AI Lab, where cross functional teams tackled real business problems in under two days. On 29 and 30 September, our engineers came together for the latest in our series of Engineering AI Hackathons.
Each hackathon builds on the one before. We look at what worked, what didn’t, and where our use of AI has matured. Our Director of Engineering, Nick Liebmann, organised the event and summed up the shift he saw this time.
That shift shaped everything about the two days.
Two days, two different kinds of learning
We kept what worked last time and built on it.
Day one was AWS Day. It was a hands on day focused on the AWS platforms we already run on. Sessions covered the AWS DevOps Agent, Amazon Bedrock and Amazon’s agentic tools. Including Kiro, alongside dedicated tracks for quality assurance and engineering tooling.
Day two belonged to our engineers. The morning opened with a session on choosing the right AI model, followed by two rounds of lightning talks from across the team. Topics ranged from patterns and anti patterns in AI assisted development, to AI powered testing, to how platform engineering can offer guardrails rather than gates. One talk took on a harder question. How it feels when a job you trained for changes shape underneath you.
The afternoon was free build time. Teams took what they had learned over the two days and applied it to their own work, then showed their progress at the end of the day.
The biggest model isn’t always the best choice when engineering AI
At our earlier hackathons, the focus was on getting comfortable with AI tools and seeing what they could do. With our engineers now using Claude, Codex and GitHub Copilot every day, the next step was learning to use them well.
Nick opened day two with a session on choosing the right AI model. The starting point was a common habit. Reaching for the most powerful model, at maximum effort, for everything. It feels like the safe choice. In practice it is slower, costs more and can make simple work more complicated than it needs to be.
Instead, the session set out one principle.
Match the reasoning effort to the ambiguity and consequence of the decision, not the size of the task.
A two thousand line rename is trivial. A three line change to medication timing is not. At Nourish, consequence has a very specific meaning. Anything a carer acts on, such as medication records, care plans, observations and alerts, sits at the top of the scale. So do the care records behind inspections, permissions and access, and the integrations our customers and partners rely on. Work in those areas gets the strongest models, careful thought and an independent review. Routine, well defined work gets a lighter, faster model.
Seeing it in action
To make the point, Nick ran the same small task side by side. One engineering AI session at maximum effort, one at medium. The medium effort session had finished before the maximum effort session had written much code at all. It was still thinking. On a small task, more effort bought more time and more cost, not a better result.
Three things to remember
The session closed with three rules the team took away.
- If a script, linter or query can answer it, you don’t need an AI model.
- Size the effort to ambiguity and consequence, not lines of code.
- The reviewer is never the author. Use a fresh session, ideally with a different model.
One rule underpinned all of it. Resident and staff data never goes into a prompt. Our engineers use synthetic or anonymised data for testing and debugging, and only Nourish approved accounts.
The team then worked through six real examples, from adding a filter to a screen through to changing a medication alert rule, and debated which tool, model and level of effort each one deserved. The result is a shared routing guide that will become the team’s default. Which will be reviewed as new Engineering AI models are released.
What the teams built
The afternoon demos showed how far the conversation has moved. We have gone beyond using AI to write code. Most teams used it to make our engineering process faster, safer and more reliable. Highlights included:
- Model selection built into planning. One team put the morning’s session straight into practice. They extended an existing planning tool so that every step of a development plan now recommends a model, an effort level and a reason. In testing it correctly suggested moving a routine task from a top tier model to a lighter one.
- Faster admin screens. Using AI to analyse and optimise performance, one team benchmarked improvements of up to 75% on some administration screens. On our staging environment, one care home page went from around 15 seconds to around 5.
- Performance feedback loop. A way to see which parts of the platform changed in a release, whether performance improved or degraded, and which change caused it.
- Self healing tests. A tool that spots automated tests failing because part of a screen has changed, fixes the test, reruns it and raises the change for review.
- Automated release regression. Tagging a release candidate now spins up an environment and runs the regression pack automatically. Freeing our QA team from a manual step. The longer term ambition is for AI to identify the areas most likely to be affected and test those first.
- Intelligent deployments. An early exploration of an AI agent that reads logs and metrics during a staged rollout and recommends whether to continue or roll back. Our existing safety checks stay firmly in place alongside it.
Not everything was finished, and that was never the point. Several teams have clear next steps, from moving tools into our automated pipelines to completing testing before anything goes near production.
Why this matters for social care
For the people who use Nourish every day, this work shows up in quieter ways. Faster screens. Fewer issues reaching a release. Problems spotted and fixed sooner. And the most careful thinking reserved for the parts of our platform that affect resident safety and care records.
As Nick put it at the close of the day.
What comes next
Every Engineering AI hackathon feeds the next one. Coming out of this event, we will:
- Publish the model routing guide to every engineer and agree shared defaults across our teams
- Review that guide regularly, as new models arrive every few weeks
- Take the strongest prototypes forward into our day to day pipelines
Our next Engineering AI Hackathon is planned for around the New Year. We’ll be looking back at what landed, what didn’t, and how much further we can push.
Thank you to everyone who presented, built, demoed and asked difficult questions, both in the room and online.
