I've been in love with F# for many years. But as AI changes how I write code, the IDE I depend on may not survive – and F# might not either (at least not in my toolstack).
Published on Wed, February 25, 2026
Nearly six years ago, when I was pondering the technology stack for the project that would later become Taxaro, I was considering TypeScript and F# for the web application, alongside more exotic options like Reason and Elm. The latter two weren't really viable even then due to their limited adoption, and ultimately, I decided against F# more than for TypeScript because I didn't believe in the F# ecosystem for frontend development. I was right.
Nevertheless, I used F# and still do today – in the backend. And I have to be honest: I'm as in love with the language and the way of programming as I was on day one. Whenever I've even thought about working on the codebase in recent years, I've been overcome with a warm, fuzzy feeling. That sounds sentimental, irrational, and probably is – but it has simply always brought me nothing but joy. Whereas I've always approached working on the React frontend with TypeScript with a completely unemotional attitude. TypeScript has some functional concepts, but in my opinion, it's far too verbose, and something's missing. Just like with Dart, which I have to use for the Taxaro mobile app.
But things have changed, especially in the last year. Since May 2025, I've been using Claude Code, and my token consumption in the last 30 days alone was 775 million.
I'm writing less and less code myself. While I still review almost everything that's generated and keep track of Git commits, I see that potentially disappearing in the medium term. That's also why I haven't published anything about my workflow with Claude Code and Codex recently, because it feels like it changes and evolves every two to four weeks. The increase in the tools' capabilities is also breathtaking.
A brief digression: Yesterday, I wanted to address some crashes of the Taxaro mobile app that had accumulated in Sentry. Previously, I would have gone through the logs, created tickets, and copied stack traces into them. Then I would have spent a few days watching the team process the tickets and see them circulate through the board. Then it occurred to me that Claude should be able to do that too. Turns out: it can. Using a plugin and an MCP server, I was finally able to say: review all the crashes, suggest solutions, and implement them. A quick review, commit, build, deploy, done. Everything was finished in half an hour. The bottleneck is no longer our internal process, but Apple's review.
So what does this have to do with F#? Well, with the change in my workflow, the frequency with which I have my IDE open also decreases. This aligns with reports from others – David Fowler from Microsoft, for example, recently wrote that he hardly used the "big" Visual Studio anymore because he mostly lets AI generate his code.
In my case, the IDE is Rider from JetBrains, without which I can't imagine working with F# at all. Visual Studio for Windows is out of the question (because of Windows), Visual Studio for Mac is no longer available, and Ionide, the plugin for Visual Studio Code, was historically buggy. So my "developer experience" depends on the F# plugin in Rider. A plugin presumably maintained by one or two part-time people, for an IDE whose economic future is, at the very least, uncertain. If these "full-blown" development environments are hardly needed anymore because an editor and perhaps a Git frontend suffice, what will that mean for their development budgets? I fear the worst.
Therefore, I won't be porting Taxaro's existing F# backend. But I will incorporate this consideration into the upcoming technology decision for a new product. And then I'll probably opt for something with a broader user base, or for which a simple editor is sufficient. TypeScript, for example.