Blog | Remotely Actuarial

Predictions/Thoughts for Artificial Intelligence in April 2026

Wed, 22 Apr 2026 00:00:00 +0000

Before I begin, I will use the term AI below (and above in the title). Technically speaking this is not the best term to use, but in April 2026 AI = LLM’s for most people, so I will stick to this term (at least for this post).

These thoughts and predictions are mostly specific to technology and, to a lesser extent, Actuarial Science / Modeling and not society in general. I will “stay in my lane” so to speak…

The Crazy Pace of Change

I have written a number of drafts regarding my thoughts about AI. I’ve been asked about my opinions and what it could mean for Actuarial modeling/science, so my plan was to have a resource to point to when I get these questions. At first, I didn’t feel like I knew enough and I was not initially that interested in language models. As time has passed and their capabilities have grown, language models have become impossible to ignore so I educated myself on how they work, built some systems and played with some tools.

Unfortunately, I still don’t feel ready to put down my definitive thoughts on AI. Why? AI is moving so fast that my attempts to summarize my feelings in a nice succinct manner on the overall subject of AI has proved too difficult.
However, I do have some opinions/observations right now. Instead of collecting yet another unfinished draft, I decided to document my thoughts here so that I can look back in a year and laugh at how naive I was 😄.

Here goes….

Thoughts / Predictions in April 2026

AI will struggle to justify the investment in a lot of domains

This is one that I might be proven wrong about but this is my feeling. It’s clear that AI has caused a major step change in software development, anyone can see this. So why the prediction?

I believe software development was a unique problem:

the open source movement provided all the data needed to build very capable models tailored to the domain
the people building the AI solutions are software engineers themselves, so the builders understood the domain perfectly

I believe that other domains are not positioned to benefit as quickly as software development. The domain information is not exposed in a standardized manner in the same way that it is for software development.

Other domains will follow the same path as software development and will be disrupted but it will be slower, at the same time the success of AI in software development will be pointed to as the reason for even more investment in AI solutions. We will see success stories in other domains, including Actuarial Science, I just don’t think things will be disrupted fast enough to justify the level of investment which is already crazy high.

(Good) “Taste” will matter even more

Having “good taste” in something is a unique talent. We can all recognize that there is value to having good taste but it’s a somewhat subject quality that is hard to pin down. It’s like you know it when you see it. I do not have good taste in a great many things, my wife will attest, but I’d like to think software/technology is not one of them.

In technology circles we talk about “systems thinking” when architecting a solution or good “product instincts” when talking about the user facing solutions. Writing code has never been the blocker to making great products or solutions, it’s just been part of the cost equation. This cost has now been driven very low but the obstacles to creating great technology solutions remain the same. I believe having an eye for detail and a principled approach to creating these solutions is going to matter more than ever.

Even though everyone has to say their product is “AI enabled” at the moment, this should not be the case. “AI” is not a feature! It is an amazing tool that should super-charge your ability to create great products.

Good products will be better differentiated but also harder to discover

Following on from the above if you love building great solutions using technology, it has just become so much easier. Great right? Well it just became a lot easier to create bad technology too, and we are going to be flooded with it!

This means that the expectations for software quality, in the enterprise especially, will go down. The incentives are just not always there in enterprise settings to create great software. Companies are falling over themselves to rollout AI strategies. This is not surprising, it’s expected, AI is transformative. However, the enterprise “winners” when it comes to AI will be the second wave. The people that invested but took a more principled, measured approach to adoption.

Great products will be even less common but will stand out more.

Actuarial modeling will lag behind

The foundation your technology is built on matters. Anyone who has spent any time doing AI engineering knows that it’s all about managing context. This is very hard to do in systems that were not designed with AI in mind ( article is a good read related to this).

In my opinion, Actuarial software vendors with legacy systems will struggle to build AI into existing systems. Language models will always give some answer. This means that you can add AI to an existing product very quickly to get the “AI enabled” sticker for the marketing team but I don’t see many building truly innovative or unique experiences, at least initially.

Managing context will require a strong expressive foundation for your models, see , I’m not convinced existing vendors can execute on this. If you’re an existing vendor and disagree I’d love to see a demo.

Deterministic building blocks will be essential

In AI engineering this is called “tool calling”. The space is evolving quickly, MCP’s were all the rage initially but now it seems people are moving away from this (recently, I was looking into papers which are very interesting because they work really well with “small” models, see below).

I have always been a proponent of the unix philosophy of simple tools with narrow scope that can be combined. I believe this is still the correct approach to take with AI systems, maybe more so. Anthropic are basing a lot of Claude Code on their interaction with bash, this makes complete sense. You want to decide where the model can use it’s “creativity” and where it should be deterministic.

I believe the future of domain specific AI solutions will involve building the correct deterministic foundation that the language models can sit on top of and balancing this creative/deterministic trade-off. AI engineering will become more specialized to the domain and restricting what models can do will become more important in a world where we connect several models with narrow scopes to build solutions.

This might lead to a comeback for mirco-services. My issue with this architecture has always been managing all the interaction boundaries and administration. AI is pretty great at these particular tasks as the patterns are very well established.

Connecting smaller systems is already happening to an extent with people focusing on “agentic” workflows. However, they are still mostly using larger frontier models. Which brings us to…

Smaller models will be more important, especially in the enterprise

Yes, there’s lot of FOMO at the moment and everyone is throwing money at AI and that’s understandable given it’s potential.

However, when the dust settles and the VC money tap is off I believe enterprises will focus more on cost and less on capabilities. When this happens solutions based on smaller models will be favored over the massive foundation models everyone is using. On there are so many capable models that run surprisingly well even on your laptop, check . Right now, enterprises are not concerned with the correct model for the job but eventually they will be and this will mean smaller more cost-efficient models. . I believe this will lead to better AI engineered technology solutions, developers will need to be more thoughtful when building solutions with smaller models due to the smaller context windows.

This might be when we swing back the other way and realize developers are not really going to be replaced, just that software development has changed.

I’m particularly interested in small, local models for reasons other than cost, but that’s for another post…

AI will lead to lower Python adoption

I love Python but I don’t always enjoy the tradeoffs it makes, see .
For many people, writing code by hand with Python is perfect. However, writing code fully by hand is on the way out.

AI coding assistants don’t care that Rust syntax is harder to read and write than Python, in fact, they love it. In this new world Rust is a language with a lot of context built-in. The things that made Rust hard for developers, which were seen as negatives such as lifetimes, etc., are positives for AI. There are many more guardrails built-in so the degrees of freedom that the AI has to navigate are more constrained (i.e. better management of the creative/deterministic trade-off and the context window in general).

This may take some time to play out but I see less Python adoption and more adoption of Rust, Go, etc. Go has a particular advantage as it’s compile times are very fast, perfect for an agent loop.

The whole point to use Python is that it’s easy to read and write. So if I’m not reading or writing the code, what’s the point? - Wes McKinney

People will come to value “human experiences”, online communities will suffer in the short term

I already feel a little AI fatigued and . I find that with things I read I can usually tell that some/all has been AI generated. The issue is that I can’t tell immediately… I have to invest my time in really reading and absorbing the material before I start to realize this.
I also think it works the other way. People don’t trust anymore and, at times, feel something is AI generated when it’s not due to previous experiences.

I believe people will swing back to really valuing human experiences and content (like this blog 😄). I could see blockchain finally having a killer use-case. If you had a central body that could verify that content is human created I think people will seek this out to avoid AI in certain areas of their life. I think if a social network could ensure that all participants are actual humans it would be very popular.

However, in the short term online communities will suffer. We join communities to benefit from the connection with others. If we have to work so much harder to screen new connections we won’t connect as much. AI generated content is already flooding online communities and it’s a major distraction and obstacle to making real connections with others.

There is alot of talk about the algorithm’s that are designed to maximize engagement, but without real connections with others I think these platforms will lose their appeal.

AI will be a bad thing for Open Source

This one hurts me to write but I can’t see AI being good for open source. Open source is built around the sharing of ideas and, well, openness. It’s ironic that this openness is what has provided the model makers with the data they needed to build transformational products aimed at software development, which in-turn will be bad for those very communities.

Open source has always had an issue where a lot of the burden falls to relatively few people. I have wanted to get back into open source more but life happens! There are only so many hours in the day. There are some people who give up an awful lot to support these communities and they have always been close to burnout.

AI is going to place even more of a burden on these people. This has started already, the overall signal to noise ratio in terms of quality pull requests is heading in the wrong direction. At the extreme, there are new and terrible issues maintainers are having to deal with, see .

Conclusion

The only thing I’m sure about is that it’s a crazy (and exciting) time to be building technology!

AI assisted Actuarial Modeling, who owns the key ingredient?

Wed, 19 Mar 2025 00:00:00 +0000

The sad news about Montoux

The recent news that was sad to see. There are not many companies trying to innovate in the Actuarial modeling space and now there is one less. Innovation and disruption almost always lead to good things for customers and so the customers (Actuaries building models) are really one of the biggest losers with this news. Some people are reporting that this was “lawfare”, see .

From the link above it seems that Fidelity National Information Services, Inc. (FIS), the owners of the Prophet modeling system, who are a massive company brought a lawsuite against Montoux that they knew would bury them in legal costs. Maybe Montoux pushed the envelope too much (as startups sometimes do) and opened themselves up to this risk (i.e. they were in the wrong), you can decide this for yourself.

Regardless, Montoux going under is unfortunate and will set innovation in Actuarial modeling back significantly. Every small startup in this space is trying to find the one large customer that will take a chance on them. From what I heard Montoux did make some progress at cracking into larger insurers. However, now those insurers are left high and dry which will make them more risk adverse. This will lead to carriers playing it safe and larger monopolies when it comes to vendor supplied Actuarial modeling software. In turn this, unfortunately, will lead to less innovation and worse tools for Actuaries.

So, there is one less innovator and one more cautionary tale for insurers when they think about taking a chance on a small innovative solution. The real loser? Actuarial modeling.

The story within the story

This post is not about Montoux, FIS or who is right or wrong. For me, the Montoux story has another layer to it. According to the lawsuit Montoux got into trouble for a “Model Replication Module” that would aid potential customers in migrating off Prophet to Montoux. Switching costs in Actuarial modeling are very high so this technology would help existing insurers reduce these costs.

In Prophet there is a standard library of sorts. You use “indicators” to bring in product features when you begin building an insurance product. Based on these indicators you get a “template” for the product and then you customize from there. The thing that is interesting about Prophet is that you can edit all the code once a product is built.

In my experience, it’s normal to heavily customize the code after first creating a product template. Then the question is “who owns the code you write?” Is this code written by FIS that you tweaked or did you start from some very basic template and build your product (I know some people that don’t use the template at all)? Where you are on this spectrum depends on how you use the product. However, from the lawsuit that was filed it seems that FIS might believe that they own the code written in Prophet or at the very least that you can’t separate the part they own (the DSL and the “template” code) from the part that users likely believe they own.

Why is “ownership” important?

I think this is a question that will become more and more important in the near future. I was very skeptical of the whole “AI will replace everyone” narrative, and to some degree I still am. However, something that is very clear is that software development is going to transform. Building software is fundamentally about solving problems, AI will not replace (good) developers but it will change the tools they use to solve problems and as a result the cost of software development will reduce (potentially dramatically).

I believe this could completely change the “Build vs Buy” trade-off when it comes to Actuarial modeling. The biggest downside to the “Build” option to this point has been the cost of engineers to build and maintain the software but with this cost reducing this will become less of a downside. This process could also be accelerated if some strong open source modeling libraries take off or if we, as a community, can agree on some .

Add to this that the negatives of the “Buy” side will become more pronounced also. There are many tried and tested solutions to problems encountered in building software, things like version control, CI/CD, cloud management, etc. However, due to the incentives at play, vendors are more likely to try and build their own custom solution (and charge you for it) than to integrate with industry standard solutions. However, the new wave of AI enabled tools will likely be designed to integrate with these industry standard solutions as many of them are open source. This means there is a lot of data on how to use these tools freely available, i.e. training data.

Vendors will try to add the same AI enabled productivity gains to their software and hope the switching costs are too high. They do have some advantages. One is that they could specialize their AI solution to the insurance domain via fine tuning their AI models. It’s easy to see that an AI that understands insurance product design could be better for Actuaries than one that knows how to “just code”.

Now we can get to the important point. If vendors believe they own your code or it’s not clear you own it, can they use it to fine tune their AI solutions? I’m not saying they will, I’m just saying that it’s not something people were thinking about when they signed contracts, potentially years ago. Also, there would be no “smoking gun” as there was in the Montoux case. Software communicates back to the vendor for all kinds of reasons, license servers, telemetry, etc. In this case, there will be no evidence that your code was used, no marketing material to point to like the Montoux case. Just millions of trained parameters.

Conclusion

Things are changing very quickly on the AI front and companies need to foresee the challenges that are coming because when change comes it will be rapid.

In the new world of AI solutions the foundation models will become commodities, available from the big tech companies, and fine-tuning for specific domains will become the differentiator (some recognise this and are targeting the fine tuning step of the process). When this becomes the case, having access to the domain specific data to fine tune on will be the competitive advantage.

Actuarial modeling software is generally slow to adopt new technology and the agreements you originally signed might not be considering where the industry is going…

Disclaimer

To be clear, I am not anti vendor supplied Actuarial software. I am pro user centric software. I have used many vendor supplied solutions and can see the value they bring, including Prophet. However, I also think that larger vendors need to be pushed by smaller innovators to ensure the best outcomes for end-users.

Could the Actuarial community benefit from an open Actuarial Intermediate Representation?

Sat, 18 May 2024 00:00:00 +0000

Note, when I talk about Actuarial modeling below I’m referring to long term insurance, not P&C.

What is an “Intermediate Representation”?

Programming languages make different trade-offs, some are high level, some are low level. I might consider Python to be high level and Rust to be low level. However, this classification depends on your perspective.

Modern compilers are made up of many layers of “programming languages”, it’s just the ones under the hood are not designed for humans. In fact, several compilers for modern languages use the same backend to , i.e. they use the same internal “programing language” or intermediate representation.

An intermediate representation (IR) is a standard representation that is designed with the next phase of compilation in mind. When you run cargo build (for Rust) you don’t see any of this, you just get a nice new optimized binary but your code can pass through many layers of IR before the final binary is created.

Why are open standards important?

Open standards help spur innovation. The Rust compiler is a very sophisticated piece of software but if it could not rely on the it would have taken much more effort to realize. At some point it became obvious that it did not make sense for every programming language to rebuild how to optimize code for specific hardware targets while also supporting a wide range of targets. Programming languages “compete” on other things, like the experience for developers. Investment in LLVM, for example, benefits all the languages that use LLVM as a backend and the entire developer community is better off as a result.

set out to do something very simple. It set out to align the community on how to lay out tables of data in memory (down to the bits and memory alignment). This is a very simple concept but has had major impacts, for example see . As a result, Arrow is seeing major adoption in data systems. With Arrow establishing itself as the foundation it has allowed other projects to be realized such as which builds on Arrow to define a kind of IR for relational algebra (i.e. database systems).

The competition in the database space is intense, new databases are popping up all the time to the point that it’s hard to keep up. However, there is more and more of a trend toward less vertically integrated systems. and this is only possible due to open standards like Apache Arrow and Apache Substrait.

What would an Actuarial IR look like?

I’m not sure, but I’ve thought about this alot. Actuarial modeling is interesting as it’s quite varied. Regular valuation type runs are alot like batch processing, on the other hand other types of jobs involve path dependent benefits, etc. and can’t be parallelized in the same way. However, this would be the whole point of a single IR representation. You represent the logic via one IR and you could deploy and optimize the logic for the specific use case and computation patterns.

There is alot of prior art to pull inspiration from. From Substrait mentioned above to which allows , this would be a very useful feature in Actuarial models.

“Community over Code” is the mantra of the Apache Software Foundation, and it’s especially true for projects around open standards. The concept of Arrow is quite simple, the technical details are quite complicated, but its success as an open standard is dependent on the community that supports it.

If an Actuarial IR could be developed it would have to be a community effort.

Why is now the time?

The Actuarial profession and community is being forced to evolve. Actuaries were the original data scientists. However, the rise of the data scientist / Machine Learning / AI, etc. is challenging the Actuarial profession. On this front, the SOA is recognizing the challenge and .

However, on the technology side I don’t think we are evolving the way we need to. Machine learning / AI evolved from computer science and require a strong technology foundation (both the skills of the practitioners and the tools available). We also need to free up Actuaries to allow them to work in the areas that have the most impact for the businesses they serve. We need to reduce the cost of Actuarial modeling and provide access to new technologies.

I believe that the status quo of vendor supplied vertically integrated systems is holding us back on this front (this is my experience, if you feel your system is different please reach out! I would love to be proved wrong 😄).

What could the future look like?

Let’s assume we have defined our new IR called Actuarial IR (AIR), it was a community effort and is seeing broad adoption, what would be different today?

Each modeling system could focus on what they believe is their competitive advantage, they could focus more on the experience for Actuaries who build models and less on how to optimize their custom domain specific language to the new accelerator of the day. Or they could target a different part of the stack like program analysis to identify inconsistencies in models across an organization, etc.

We could develop a common infrastructure for deploying and optimizing AIR for different hardware targets. This would turn into a common challenge and insurers don’t compete in this domain, so they could collaborate to reduce the cost of insurance for the industry.

We could define how to serialize AIR so compute plans could be sent to different machines efficiently allowing all systems that adopt the standard to run in a distributed fashion.

It would allow us to define new reporting standards in a single place as a reference implementation for all the community to use. i.e. the specification for common reserving approaches could be written in AIR.

It would support the modularization of Actuarial models. In YouTube video on Actuarial transformation the speaker dreams of a more modular Actuarial modeling infrastructure (starting at 22:20). This would be possible with AIR.

We could build a variety of “front-ends”. For a small insurer they could use Excel with a plugin that exports their Excel model to AIR. From there the ecosystem of tooling around AIR could be used.

Actuarial software vendors would be pushed to innovate! Vendor lock-in would no longer be the reason to stay as there would be pressure to support an export (and import) to AIR. Some Actuaries may not like this (if they work for Actuarial software vendors) but I believe the benefits to the community as a whole could be immense. Also, there could be a huge new opportunity for software vendors, they could focus less on major parts of the Actuarial modeling stack and instead could focus on innovation and incorporating new technologies like advances in AI, etc.

Summing up…

Actuarial models are becoming more and more complex
different models require different compute patterns
new regulations are pushing us and our models to deliver more in less time
all these pressures leave no room for pushing forward the state of the art in Actuarial modeling/science
we need to reduce the burden
I believe that defining and adopting community driven open standards could do this

A similar path has been followed in the database community, and it has led to new innovation in database development. YouTube video (though technical in parts) is only 15 minutes long and provides a good summary of the changes in that domain. I can see so many parallels in Actuarial modeling…

Rust for Domain Experts

Wed, 09 Sep 2020 00:00:00 +0000

Introduction

Over the past few years I have been writing more and more Rust code. I have been using Python for many years, it’s a great language, and I am very productive in it. However, I have come to the conclusion that Rust is a really strong candidate for domain experts to learn. By domain expert I mean someone who does not have a formal computer science background. I’m in this category, my domain being Actuarial Modeling. I will refer to Actuaries below, but you can insert your domain if you are in the same boat as I believe the arguments apply across domains.

But isn’t Python good enough?

Python is a fantastic tool and language. I feel I owe a lot to Python and the community that supports it. In my initial years working as an Actuary I was always drawn to the more technical roles, especially with regard to technology. For any new Actuary without any knowledge of programming or computer science this meant bending Microsoft Excel to do things it was never designed to do.

I then started to work on a product then embedded Python, I had the Python interpreter and standard library at my finger-tips. This was an amazing period of exploration. It was like a whole new world opened up for me. I started to realize the power of a “proper” programming language. Over the next few years I became quite proficient in Python and I loved the power that came with it. I felt I was able to hack on anything I wanted, and it was quite addicting. Sometimes I would solve certain problems in a certain way just to use feature X or challenge myself. I have come a long way in my Python journey and over time I invested in learning to fill in the holes in my skills with regard to software development.

Python can be used to build larger software systems that need to be performant, i.e. Actuarial Modeling, but as with most things in life you are making a trade off. Python is too easy in some sense. People copy and paste code that uses (insert-new-machine-learning-framework) and just go from there. In reality, it takes an investment in the basics of software development to really learn it correctly, or more accurately learn how to manage it correctly. When I write large systems in Python now it feels a little like taking out a loan. I can have that instant satisfaction of building something fast, but I know that I’m going to have to pay for it down the line in the form of maintenance.

Another drawback is when you hit the performance barrier in Python. All the high performance libraries in Python are written in C/C++ but every so often your problem does not fit into the paradigm that these libraries use (typically array processing). At this point you’re out of luck, you can invest in numba, Cython, etc. but they bring their own complexity and trade-offs.

Rust is too hard for Actuaries to learn

There is no denying that Rust is more difficult to learn than Python, but let’s not sell the Actuarial profession short here. Actuaries spend years studying complex topics, it’s well within their reach to learn Rust. In general, I don’t feel that Actuaries embrace programming as much as they should. Quants embrace programming and go head first into C++ of all things, I would love to have Actuaries take this approach also, i.e. the mind-set not C++…

I prefer to look at Rust as enforcing standards, i.e. quality at the source. Yes, you will get frustrated but once it complies generally it works. Also, once it complies there are whole classes of bugs that are ruled out, the kinds of bugs that you always remember to write tests for in Python, right? Rust is blazing fast and complies to a single binary meaning that deployment is simple. Hand over the .exe and it runs, no more serving as the Python install help desk within your team.

The biggest win for Rust though is that in return for the upfront investment you create systems that are far more robust and easier to maintain. When you build a large system in Python it’s easy to build because you have the whole system in your mind while you are working on it. However, coming back to said system years later and making changes can be difficult especially if others have been developing it since then. The Rust compiler is the ultimate code reviewer ensuring that everyone is keeping up their standards.

A short note on C++

Yes - this actually is too hard to learn for Actuaries (in general). In order to learn C++ you really need to immerse yourself in it. There is no other way, the language is too big (something I hope does not happen Rust). You have to learn the concepts encoded in the Rust borrow checker as good coding practice.

After all this would I recommend using Rust today, yes I would. However, it will still feel like you are an “early adopter” the point of this post is that I see it being a far more attractive option in Actuarial Modeling in the future. Like all software, great abstractions can reduce the barrier to entry and increase productivity. At the moment, you kind of need to “roll your own” for a lot of things. I think that once some foundational Actuarial Modeling libraries are in place Rust will be a great option for Actuaries and Actuarial Modeling in particular. My involvement in the Apache Arrow project has been motivated with this goal in mind. More to come on that…. I hope :)

Blog | Remotely Actuarial

Predictions/Thoughts for Artificial Intelligence in April 2026

The Crazy Pace of Change

Thoughts / Predictions in April 2026

AI will struggle to justify the investment in a lot of domains

(Good) “Taste” will matter even more

Good products will be better differentiated but also harder to discover

Actuarial modeling will lag behind

Deterministic building blocks will be essential

Smaller models will be more important, especially in the enterprise

AI will lead to lower Python adoption

People will come to value “human experiences”, online communities will suffer in the short term

AI will be a bad thing for Open Source

Conclusion

AI assisted Actuarial Modeling, who owns the key ingredient?

The sad news about Montoux

The story within the story

Why is “ownership” important?

Conclusion

Disclaimer

Could the Actuarial community benefit from an open Actuarial Intermediate Representation?

What is an “Intermediate Representation”?

Why are open standards important?

What would an Actuarial IR look like?

Why is now the time?

What could the future look like?

Summing up…

Rust for Domain Experts

Introduction

But isn’t Python good enough?

Rust is too hard for Actuaries to learn

A short note on C++

Where do I sign-up?