Vibe Coding for Actuaries

This article is jointly co-authored by Anton Kobelev , Enoch Ou and Ning(Alina) Y.

Perspective from Anton Kobelev :

Vibe coding is the term coined by AI expert Andrej Karpathy, founder of OpenAI, in February 2025. Vibe coding is essentially the process of using Large Language Models (LLMs), such as ChatGPT or Perplexity, to describe the end-result in English and have the GPT generate working code for you.

Andrej essentially defined what I have been doing for years - asking Google to find me a solution for a tiny spec of a larger problem, find some code on Stack Overflow, adapt it as much as I can, integrate it into larger code base and hope it compiles.

LLMs have come a long way in being able to generate workable code, despite struggling with basic math. This limitation notwithstanding, one can describe the issue in English and have workable code in no time. Pete Sena describes one such use case in his article:

I recently tested this myself. I prompted CursorAI, an AI-enabled IDE (integrated development environment), and built an app called DaddyTime that helps discover new cool things I can do with my son (he’s three). Within 30 minutes, I had a fully functional progressive web app.

When presented with a request to hire an actuarial modeler or developer, and having read articles like the one above, senior management may be inclined to reject the hiring request and direct their underlings to engines like Cursor AI for some DIY vibe coding.

There are ways that AI can benefit actuaries in the realm of coding, especially on open-code systems like Python. The benefits are, but are not limited to:

Increased Speed of Model and Tool Development: Vibe coding aims to significantly increase the speed of software development and the volume of customer-facing features developed. Actuaries could potentially leverage this by describing complex actuarial models, valuation systems, or data analysis tools to an AI using conceptual directions. The AI could then generate the underlying code, potentially much faster than traditional manual coding, accelerating the development cycle for new models or updates.

Focus on Actuarial Logic and Design: Vibe coding shifts the focus to the overall product's behavior and the "what" rather than the "how" of the code. This could allow actuaries to concentrate more on the critical actuarial logic, assumptions, and design of models and analyses, rather than getting bogged down in the specifics of programming syntax or debugging code line by line. They could describe the desired calculations, data transformations, or model structures, and the AI would handle the code generation.

Faster Prototyping and Scenario Testing: Vibe coding could enable super-speed prototyping and iterative refinement. Actuaries frequently need to prototype new models, test different assumptions, or run various scenarios (like sensitivity analysis). By describing these variations conceptually to an AI, actuaries could rapidly generate and test the code for these different scenarios, iterating quickly based on the results.

Better Documentation: Documentation and comments are always an after-thought and AI can generate proper documentation as the code is being created, as well as after it has been finalized. This will reduce the strain on new developers as they get rolled onto the project and have to decipher someone else's code.

The above points make a clear case that AI is a useful tool in any actuary's arsenal, however actuarial and programming expertise is still needed. To help me make the case, I invited my colleague Enoch Ou, who is our actuarial modeling and programming superstar (and resident AI skeptic). I will let him make the points on how vibe-coding could be used versus how it should be used.

Perspective from Enoch Ou : 

I’ve spent the majority of my actuarial career building tools to accelerate actuarial modeling processes for myself and for others, using languages like Python, VB.NET, and MS SQL. These tools have complemented my modeling in software like AXIS, Excel, and Slope.

Before the age of Gen AI, most of us tool-builders had to use Stack Overflow. We would have to sift through previously-asked questions on the forum and determine which human-generated answer (if any) was the most appropriate for our own use case. The hope is that Stack Overflow’s democratic system of upvoting good answers and downvoting bad answers would steer us into the most optimal solution. And if there were nuances specific to our own use-case, we would further hope that amongst the answers and snarky comments from programmers, there was some additional useful information.

But with the advent of Gen AI, all that changed; no more sass from humans and no more spending hours hunting for answers that could help debug a single line of code. At first, we were using Gen AI to generate small snippets of code. But very quickly, the capability of these AI models grew to the point where it could generate entire scripts or even whole applications with a few prompts and without the need to manually write a single of code. AI solutions like GitHub Copilot, Cursor, and Genspark allow us to vibe-code these full-stack solutions relatively quickly and without much programming experience.

This is not necessarily a bad thing. In fact, I love that creative minds can now prototype without bothering the average programmer who dreads hearing the words “I have an idea for an app” from non-programmers. But I do have some cautions for people who endeavor to vibe-code their way to a solution, based on my own experiences.

For example, once a use-case gets sufficiently nuanced, my AI responses occasionally exhibit “hallucinations”. These are sections of code that are conjured from thin-air and that I know are wrong but might seem OK to the untrained eye. More advanced AI offerings will self-test its own generated code first and adjust accordingly (e.g. Perplexity does a decent job of this) but the AI will not always self-correct these hallucinations, especially if the human prompter doesn’t suggest edge cases in the prompt. Granted, as the training data for these AI models grows, I expect hallucinations to become rarer. Unfortunately, the actuarial industry currently doesn’t provide much training data to these AI models because a lot of actuarial knowledge and data (especially the mathematics) is still passed around via offline documentation or textbooks. So, the more math-oriented (as opposed to process-oriented) your tool is, the more hallucinations you can expect. This will eventually improve as more actuarial knowledge gets uploaded to the public internet. But in the meantime, “trust, but verify”.

Similar to how the dependency of GPS and Google Maps in our daily lives has deteriorated our ability to self-navigate, I suspect our increasing dependence on AI to write code will eventually have the same effect. Proper programming is not simply about generating code that produces your desired output. There are important considerations such as scalability, maintainability, security, and verifiability that need to influence the tool’s design before the tool can be considered production-ready.

Scalability

AI tends to prioritize correctness over efficiency, leading to slow or bloated applications. For example, database queries and resource usage might not be optimized for scale. And the lack of connection to real-world actuarial data (e.g. your model’s policy information table) means the AI may struggle with designing a solution that it avoids these performance bottlenecks. Vibe-coded apps might also work fine for a few users, but struggle under real-world load.

Maintainability

Code can become a black box, with unclear logic and inconsistent naming conventions. AI can also often generate elegant solutions that are difficult to comprehend and thus difficult to enhance in the future. These AI solutions may also lack the modularity required for a production solution so that a certain component can be safely or easily updated without affecting other components.

Adjusting the vibe-code with prompt-after-prompt, may also affect the code’s architecture in a way that creates technical debt; quick fixes and patchwork solutions accumulate without considering the big-picture design, making future development harder.

Security

AI-generated code sometimes skips input validation, making it prone to SQL injection, XSS, and other attacks. Vibe-coders might also accidentally hardcode credentials (e.g. admin passwords or API keys) or insecure access patterns.

Verifiability

AI-generated code can work, but the underlying logic might be opaque, making it hard to verify why it works or whether your application’s outputs are correct. It may become difficult to trace decisions or assumptions baked into the code. Vibe coding also often skips unit tests, integration tests, and edge case coverage.

In summary, vibe-coding is great for demoing new ideas and generating a proof-of-concept, but as of this writing, I would not let vibe-coded solutions anywhere near a production environment. For production applications, I currently manually design the architecture and then, if needed, prompt AI to generate small blocks of code at a time, and I spend time to understand each solution and adjust when necessary. But if AI continues to grow at the current rate, the line between programmer and vibe coder will become very blurry very soon.

Perspective from Ning(Alina) Y. :

From Prototype to Client-Ready

In our day-to-day as actuarial consultants, AI has truly shifted how we approach building tools - transforming what used to take days into an afternoon’s project. There is definitely a thrill to “vibe coding” your way through a client request, especially with Gen AI now sketching out scripts or dashboards in a single prompt. But some hands-on lessons keep coming up in real-life work and passing them on feels more empowering than cautionary.

Building Trust, Not Just Code

A rapid prototype is a fantastic springboard for discussions—a way to road-test ideas, frame assumptions, and get buy-in before diving deep. We’ve both seen how a quick AI-driven demo can demystify a complex reserving problem or help a client visualize results. But after that initial wow-factor, teams always circle back to the same practical needs:

• Clients want tools they can understand and own, not just a working script, but something with clear inputs, labeled outputs, and comments explaining the why, not just the what.
• Handovers happen: Today’s deliverable is tomorrow’s legacy. A little time spent adding docstrings, a change log, or even a “how-to-run” note can mean the difference between smooth adoption and endless clarification calls.

Thus, we believe some practical steps an make a difference:

Always validate AI output: We always run our AI-generated outputs with a couple of “edge case” scenarios the client actually cares about. This catches odd behaviors and also gives everyone comfort that the tool’s not just right, but right for their business context.

Stay iterative: The best solution is rarely born perfect - so we share our drafts early, encourage feedback, and treat each prototype as a living document. This helps us surface context-specific wrinkles and keeps the client involved in shaping the product.

By blending the speed and excitement of AI-driven development with habits like validation, iterative feedback, and thoughtful documentation, we ensure that every tool is practical, understandable, and truly client-ready.

To wrap up, vibe coding is great, but don't discount the necessity of an SME in the room!