AI in Production Conference Summary (2026)
“AI In Production 2026”, a new conference hosted by Jumping Rivers, was held on 4-5 June, 2026. The conference touched on many of the intricacies of using AI in software products, as part of the developer toolkit, and at the wider usage of AI throughout organisations. Themes that stood out in the talks this year included regulatory and security matters, the deployment and scalability of AI products, how to incorporate custom data/knowledge, and how to make use of AI tooling to simplify data-intensive tasks.
In addition to the talks (held on 5th June), there was a day of workshops on the 4th June.
AI within the software-development lifecycle
AI-based tooling has revolutionised software development during the 2020s. Colin Eberhardt (Scott Logic) highlighted steps in the evolution of the AI developer since 2022 (“Agentic AI and the Future of Software Development”). In 2022, AI could be used as an auto-completion tool with assistive code suggestions. With CoPilot (GitHub) and the launch of Claude (Anthropic), by 2023 AI tools could function as a virtual pair-programmer (proposing code, finding and fixing bugs in new code), though any contributions needed thorough code review. Since 2024, AI tools have increasingly been used as autonomous contributors or as a component of continuous code-review operations.
This transition is having an impact throughout software organisations:
- How should a junior, or newly-onboarded, developer get up-to-speed with a project?
- Where should developers focus their time and effort?
- How should projects, teams and organisations be structured to take best advantage of AI tooling?
On the first point, Rebecca Guiney (Certara) gave an interesting lightning talk (“Learning in Production: Becoming a software engineer during the AI wave”). In a recent project, she used AI to build a tool for schema discovery (over clinical trial databases). The tool can work reproducibly on new data.
Rebecca highlighted how “contract-first development” is important when building tools using AI assistance. That is, when agents can write code and/or tests, an important role of the developer is to control what the different components of a system are reponsible for, and how they interact. Similarly, when reviewing code a greater emphasis is placed on the purpose of what was implemented than on how it works. This emphasis on higher-level thinking is also impacting how new developers learn - learning from AI-generated example code, rather than from step-by-step tutorials.
Rebecca won the (CRC-Press sponsored) prize for the best lightning talk.
Since the AI toolkit is relatively new, many projects exist upon which AI has never been used. When looking at these projects, Claude (or similar) could find countless issues. So how do you prioritise what to fix first (when you may also have a list of bugs and features waiting to be addressed)? Badr Adnani (Roundel Kitchens) gave a lightning talk explaining how his use of AI helped identify and fix a critical bug in a SQL command (“Breaking Barriers with AI Automation”). The bug itself, could have posed a real financial risk to the company.
As part of his talk, Badr split up the audience by their level of AI usage. Most of our attendees were daily users of AI for well-defined tasks. Had Badr not increased his usage of AI at work, he may not have fixed the above bug (and got promoted), and he urged us all to experiment more with AI in our daily work.
So how do we broaden the use of AI within programming teams? Firstly we make the tools easy to use, and work out how to use them cheaply and effectively.
The Positron IDE is becoming a very popular system for development in data science and allied fields. George Stagg (Posit) gave the closing talk of the meeting describing how the Posit Assistant came into existence (“A Builder’s Guide to Working with AI”). Posit Assistant is an AI agent available in RStudio and Positron, with which a user can explore their data and generate analytical dashboards via a conversational interface.
Building the Posit Assistant helped George understand AI systems like Claude. These systems can lie to you (or your users), for example, if you ask an AI tool to summarise the trend in a dataset, it may give you a good enough answer. But it could be guessing - it might not even have seen the data - but may still give you an answer. So it’s sometimes important to check the raw messages that are sent to an AI tool and have an independent way to verify agent outputs.
There are existing standards that make using AI coding tools more effective. Project-level definitions of how certain tasks should be performed, or how the project is structured, can be put into an AGENTS.md file or a ‘skills’ directory. George explained that it is important to make use of these common standards when building a developer-facing agent.
If you want to limit the cost of AI-usage in a project, limit the amount of data that is sent to- and from- your agent. This could be by cacheing previous messages - because otherwise you may be sending all of your previous conversation each time you interact with an agent.
AI usage in specific projects
There are many ways in which AI can be used across organisations. In addition to its use as an aid in software development (above) and within search-engine summaries, it is extremely common to find people using AI to write emails, to summarise meetings, to annotate videos and speak and to perform a range of other workplace tasks.
Nayara Macedo de Medeiros Albrech (Newcastle University) gave an interesting summary of her research on the use of AI in local government and education (“AI Beyond Industry: Insights from Higher Education and Government”). Government decision making has a focus on ’evidence-based policy’, so AI could contribute in this area, but there is a need to prevent AI from introducing bias into decision making. The talk emphasised ethics in the public sector use of AI and the variability in take-up of AI tooling across different local government sectors.
Continuing on the theme of AI use in government, Katy Morgan introduced some self-serve tools that the Government Internal Audit Agency have generated to aid the production of internal audits (“From risks to insights: Driving innovation with AI-powered tools in internal audit”). The use of AI in these products ranged from highly-guided settings (where user-selection from a fixed collection of application-encoded choices creates LLM prompt input automatically), to more flexible use (where an auditor could freely interact with a chat engine). With these tools, users are encouraged to use their own judgement to interpret any AI-generated output.
So AI-embedded tools can fix your code and reduce administrative work. Can AI help resurrect old projects?
Shona Ferguson outlined an interesting use-case for LLMs in data-rescue efforts at the UK Centre for Ecology and Hydrology (“Comparing and Evaluating Large Language Models for Efficient and Responsible Data Rescue”). Preservation of historical data resources is a time-consuming, and largely manual, task. The typical steps involve defining some quality checks, writing a data-cleaning script, finding supporting publications and creating documentation.
Shona demonstrated how effective three different LLM tools (free versions of CoPilot, ChatGPT and Claude Sonnet) could be in a project to rescue a dataset related to cloud and rain chemistry. The tools were particularly effective at code generation and making draft documentation. When approaching this type of project, recommendations are to give the LLM prompt as much context about the project as possible, to tell the LLM ’not to guess’ results and to be very explicit about the form of output you expect the LLM to return.
Sometimes your data is so large that it wouldn’t be possible to analyse it manually. The team from Wordnerds (Izzie Johnson and Damani Richards) gave a talk that touched on some novel themes for our conference (“A Nerd’s eye view: wrangling the GenAI hype cycle and refusing to become irrelevant”).
One of the powers of LLMs is their ability to accept natural language as input. But natural language is complex and there’s an awful lot of natural language in the world. For text-analytics specialists, processing customer reviews or other large-scale collections of text using LLMs could be pretty expensive: both economically and ecologically. If you want to process natural language efficiently at-scale, maybe an LLM isn’t the right tool to use. Izzie and Damani explained a hybrid approach, using both the Gemini LLM to identify and tag training data, and smaller custom-trained neural networks to analyse millions of records efficiently.
Just as human language is a complicated world, so is human behaviour. Grant Beasley from tombola, alongside our own Myles Mitchell (Jumping Rivers), presented a project where they used deep-learning to assess player behaviour in their online betting platform (“Using Deep Learning to monitor player safety on online betting platforms”). tombola monitors players over time, to help identify people at risk of gambling addiction, and to intervene where appropriate.
The models used here are not large language models, they are deep neural networks trained on time-series data. Training this model over large numbers of players was a substantial undertaking. But the tombola project highlighted how, if you are planning to build a model on this scale, it is important that you start with simpler benchmark models to compare your larger model against.
William Kirby (Wessex Water) presented a lightning talk covering another project where real-time interventions can impact on human behaviour. This time the subject was wild-swimming and water quality in inland bathing waters in the UK (“Near Real Time Notifications for Bathing Waters using Machine Learning”). The project integrates data on water quality and climate with sensor and sampling data, and is capable of classifying risk at their pilot site (Warleigh Weir, near Bath) on a 15 minute turnaround. They have developed a web application to present their results and are scaling out to additional sites over the next two years.
Incorporating custom information into AI-tools
Agentic systems are clearly very powerful, but they can become far more useful in a project or product when the data they have access to is tailored to that project. Three talks highlighted different ways to connect an LLM to a custom data source or an external service so that the agent can be better informed.
The standard way to enhance an LLM with a custom data source, is by using “Retrieval-Augmented Generation” (RAG). Obinna Iheanachor (Rotork; and host of the Wisabi Analytics YouTube channel) gave a lightning talk explaining a two-step AI-driven process where he used RAGs to identify documents related to corporate insolvency cases, and then to identify evidence within those documents (“RAG in the Real World: Designing Trustworthy LLM Systems for Corporate Insolvency Data”). The aim here was to identify citable evidence, rather than plausible-sounding and eloquently written LLM outputs, so the use of RAGs was essential.
RAG is a way of embedding document-derived text in a way that can be searched by an LLM. An extension of this concept is the GraphRAG, where relationships between entities in a series of documents can also be represented. Jonny Law (Neo4J) presented a talk that explained many of the concepts underpinning GraphRAG (“Engineering a Scalable Knowledge Graph Builder on Neo4J Cloud”). Neo4J have developed a “Knowledge Graph Builder” that allows data and relationships to be extracted from documents and represented in a graph structure. This graph structure can be queried using an LLM by converting an LLM query into a GraphRAG query.
Another way to connect an agent to an external data source or service is the “Model Context Protocol” (MCP). MCP is an open standard and was the subject of Neal Richardson’s (Posit) talk (“MCP, or not MCP”). As a motivation, Neal explained that for security reasons, there are external resources that an AI agent shouldn’t be given access to. For example, you might not want an LLM to be able to read and write to the support message-board for your software, or to read any file on your computer.
MCPs use a standard API and JSON-based interchange format, but they make it easier to restrict the reach of an AI system. OAuth 2.1 can be used to register an LLM with an MCP, meaning that API secrets needn’t be available to the LLM - so it can’t leak these. Recommendations for building MCPs, are to only define the tools you actually need, to make API responses concise and to sanitise any sensitive data that the MCP might return.
Development, deployment and auditing of AI-embedded products
We have seen software-development tools that make use of AI; specific projects that use AI and/or ML; analysis of, and recommendations for, the use of AI; and ways to link additional data to AI tools. But before you incorporate AI into all your workflows, you need to take a step back and consider how to implement everything in a way that’s cost-effective, safe and legal.
First we need to consider what we’re allowed to do with AI and the liabilities we create when we use it on the public.
Nathan Bilton (Weightmans) provided a thought-provoking insight into how legislation is evolving to match the growth of AI (“Regulating Artificial Intelligence”). Given that AI can take in vast quantities of personal data and intellectual property during training, does existing legislation provide enough protection? And even if we agree on a better set of rules, how do we enforce them? And who will be the enforcers?
Some of these questions may feel out of your remit, and something for your elected lawmakers to debate over. But keeping abreast of these developing laws remains relevant to your deployment of AI, both now and in the uncertain future.
The EU AI Act 2024 already applies a number of restrictions on how AI can be used, with extraterrestrial effects. If you feed personal data of UK or EU citizens into AI, then GDPR rules still apply. And if you do allow AI to interface with the public on your behalf, are you responsible if things go wrong? Here Nathan cites the case of Moffatt v. Air Canada, 2024 where a Civil Resolution Tribunal found Air Canada to be liable for damages due to “negligent misrepresentation” after incorrect advice was given by a chatbot on their website.
Next, how do you ensure your product’s use of AI is secure? Mac Misiura (Red Hat) presented the first technical talk of the day (“Open Source Guardrails for AI: Securing LLM Applications at Scale”). If you are planning to deploy an AI-backed application to production, I strongly urge you to watch this talk (soon to be on the Jumping Rivers YouTube channel).
Mac highlighted some of the top risks that an LLM-based app exposes you to. There is a top-10 list hosted by OWASP, that covers things like disclosure of sensitive information, and spreading of misinformation. Not addressing these risks can expose you to reputational damage and adversarial attacks.
To help secure your app, you can use “Guardrails”, which filter out inappropriate queries. These can range in complexity from rules and regular expressions up to LLM-based assessment of the intent of the query (use the simplest guardrails first). There are open-source guardrail collections that you can use with your application, for example, the NVIDIA NeMo Guardrails. Mac also argued that you should run attacks against your own system to identify security weak spots.
You may have multiple products in the pipeline. Diego Jimenez and Oliver Thomas from Sage covered their approach to product delivery using what they described as a “repeatable path for controlled AI at enterprise scale” (“Beyond the POC: Architecting Enterprise-Grade Agentic Systems at Sage”). This approach allows them to rapidly iterate from prototype to scalable product, by using common designs across those products. They emphasised the importance of monitoring agent behaviour, and similarly to Mac Misiura (above) the use of safety guardrails across their products.
Finally, once your app is in production, you’ll need to start paying for tokens.
Seb Ringrose (Doubleword) described “Doubleword Code”, a system developed by Doubleword that performs pull-request reviews on repositories. During the talk, Seb identified a few challenges with the current use of AI agents: how to select which model to use (from a continually changing collection of models), how much context to provide to an agent, what ancillary tooling to use, and—importantly—the cost of using these agents.
Given these desirable qualities of agents - low latency, low cost and high quality - Seb argued that you can only have two in any AI system. So if you need a real-time system, then you have to choose between high cost or low quality. But not all systems need to run in real-time. For the pull-request review system, it can run asynchronously or as a batch process, and by doing so can lead to cost savings. Given that for many settings, the number of tokens used per task is increasing, finding ways to reduce cost is becoming extremely important.
Summary
This years talks at “AI In Production” covered a wide spectrum of the uses of AI (and advanced machine learning) in software products and data projects across several domains. We discussed best practices for securely releasing AI-embedded software into the world, regulatory matters, and how we can evolve as software professionals as AI tooling becomes commonplace.
Jumping Rivers would like to thank everyone who presented talks or workshops at the conference (or submitted abstracts), all of the sponsors and the attendees for making this an interesting conference. We hope to see you again next year at AI In Production 2027.
The talks from the conference will be added to the Jumping Rivers YouTube channel soon.
Sponsors
- Jumping Rivers
- Databricks
- The Royal Statistical Society
- Posit
- CRC Press
- The National Innovation Centre for Data (NICD)
Community Partners
