Barclays and Anthropic announced an expansion of their cooperation on October 1st, planning to further utilize Claude for software development, old system upgrades, and customer service. This is not a trial from scratch: the knowledge assistant for Barclays's UK business has been in use since 2025, with over 16,000 employees adopting it, and it has processed more than 1 million searches in total. In the global market business, the Claude model is involved in sorting and organizing customer emails, with the relevant platform handling about 120,000 emails per day. Another goal is still ahead – banks expect to cover half of their developers with Claude Code by the end of 2026, and by 2027, this will be extended to the majority of software engineers.
Only by putting the current situation and goals together can we clearly understand the nature of this expansion. A knowledge assistant that is used on a daily basis proves that banks have at least solved some issues related to permissions, data retrieval, and employee training; the goal of developer coverage rate means that more teams are still in the process of integrating with the codebase. If the headline only reads "Half of the engineers are already using it," it would imply that future plans are already a reality. The Anthropic announcement also does not disclose complete data on time savings, failure rates, or customer satisfaction comparisons, so it is not possible to directly calculate the return on investment based on the number of users.
Let employees find the answers first, then incorporate AI into the development process.
The knowledge assistant of Barclays adopts a retrieval-enhanced generation architecture. For frontline employees, the value lies not in allowing the model to freely fabricate financial advice, but in being able to find usable information more quickly from authorized internal materials to assist in responding to questions from over 20 million retail customers in the UK. The key to retrieval-based applications is often whether the materials are up-to-date, whether different versions of policies conflict, and whether references can be traced back to the original documents. While fast response times are certainly important, retrieving outdated rates or incorrect procedures may amplify errors.
More than 1 million searches indicate that the tool has entered into actual operation, but this does not mean that every answer is adopted, nor does it mean that customer issues no longer require manual handling. Banks should continuously assess whether employees have found the correct answers, which questions are referred to experts, and whether the model clearly acknowledges its ignorance when information is missing. The more complex customer service is, the more these seemingly trivial records can determine whether a long-term investment in the system is worthwhile.
The scale of the email processing is much larger. Around 120,000 emails per day are not meant for the model to reply to independently; rather, the model is used for classification, information supplementation, and selection of the appropriate processing path. These emails may involve customer transactions, risk warnings, or internal operational requests. By placing them in the correct queues and identifying any missing information, manual sorting can be reduced. The final operations must still be carried out by a team with the necessary permissions. Especially in matters related to transactions and compliance, routing suggestions should not be confused with approval decisions.
The expansion of Claude Code targets another type of cost: large banks possess a multitude of software systems that are of different ages, have varying documentation, and are interdependent. Code assistants can help in understanding old modules, writing tests, and preparing migration plans, but they cannot guarantee that the automatically rewritten code will still comply with transaction timing, disaster recovery requirements, and regulatory documentation. Small errors in bank code can lead to payment failures or reporting inaccuracies; therefore, the modifications generated by AI still need to be tested, reviewed, and rolled out in phases. The number of engineers involved is merely one indicator, not a measure of code quality.
Who can decide and who is responsible for setting the high barriers of bank AI?
Both companies emphasize security, governance, and human supervision. For banks, these are not terms that can be omitted from press releases. Before models come into contact with customer data, it is necessary to determine the classification of the data and the identities of those authorized to access it; after models make operational recommendations, it is essential to decide whether automatic execution is allowed; in the event of errors, it is crucial to be able to trace the data used and the approval process. If the business processes themselves lack clear responsible parties, integrating more advanced models will not automatically clarify responsibilities.
Scalability also brings organizational costs. With 16,000 employees using the tools, it is necessary to train them to identify unreliable answers and to ensure that data maintainers update policies in a timely manner. If the knowledge base accumulates conflicting versions over time, the models will merely more quickly reveal these contradictions. Developer tools also require unified testing standards, code confidentiality strategies, third-party dependency reviews, and performance benchmarks. The real challenge in promotion often lies not in downloading the software, but in changing daily work practices.
Barclays case provides the AI market with a more solid example than just demonstrations: it already has real employees using it and involves high-frequency processes, along with clear expansion plans. Readers should also maintain a dual-level judgment. What has already been achieved is the integration of knowledge retrieval and email routing into daily operations; what remains to be realized is broader developer coverage and its economic impact. The most convincing evidence for the next step should be measures such as processing time, error rates, customer experience, and system stability, which can be assessed through independent or internally auditable methods, rather than just an increase in deployed seats.
This also provides other financial institutions with a practical comparison framework. Instead of purchasing based on the promotional materials provided by suppliers, it is better to first choose a process with clear boundaries and quantifiable results: for example, identifying current policies, detecting missing information in emails, or conducting additional testing for old systems. Before going live, record the time required for manual processing and common errors. After going live, retest using the same criteria, and include the costs of model usage fees, manual reviews, and maintaining the knowledge base. Such a comparison is necessary to answer the question of "whether there has been a real improvement in operations," rather than just whether "AI has been integrated."
