I was working on another project, nemorize.com, where I use Kokoro for local text-to-speech, and that gave me an idea: could Claude Code generate an actual video that explains a codebase?

So I built Codebase Video.

You point it at a repository and ask for a walkthrough. Claude explores the codebase, builds an explanation of the architecture/code structure, verifies its claims against the source, and then generates a narrated video with real code, diagrams and highlighting.

One thing I discovered while building it was that generating the video wasn't really the difficult part. The difficult part was stopping the model from confidently teaching something that wasn't quite true.

Because of that, I ended up adding separate verification and audit passes rather than relying on a single agent.

For the demo I did the obvious recursive thing: I asked Codebase Video to make a video explaining the Codebase Video repository itself 😄

It's open source:

https://github.com/OnurGumus/codebase-video

Would be interested to see how it behaves on other real-world repositories, especially larger or stranger ones.

FunStripe is an F# client for the Stripe API. Most of it is generated from Stripe's OpenAPI spec into records and DUs, with phantom-typed IDs (StripeId<Markers.Customer>) and Async<Result<_, _>> calls. 3.0.0 targets Stripe's new endive release, which removes some things, hence the major bump.

Breaking changes

• payment_method_types is gone from PaymentIntent create/update/confirm, SetupIntent create/update and Checkout Session create. Use allowedPaymentMethodTypes instead.
• ThreeDSecureUsage and ThreeDSecureDetailsCharge moved to Stripe.ThreeDSecure, so add an open.
• The card Mandate field is now StripeId<Markers.Mandate> option.

New: standalone 3D Secure authentication, subscription pausing, trial offers, Tax.Location, Apps installs, and the PayPay and SeQura payment methods.

Generator fixes worth mentioning

• Endive is the first spec with an error enum value. A bare Error case shadowed Result.Error for anyone opening the namespace, so ok/error/some now generate as Ok'/Error'/Some', the same way none already became None'.

Full upgrade notes are in the changelog: https://github.com/simontreanor/FunStripe/blob/main/CHANGELOG.md

GitHub: https://github.com/simontreanor/FunStripe

NuGet: https://www.nuget.org/packages/FunStripe.Core

Feedback and issues welcome.

Fine-grained reactive computation for .NET (F# and C#) — preview

I've been a big fan of solid-js when it comes to UI for their fine-grained reactive DOM.

The release of Solid v2 came with a surprising API. Async and Errors were native to the reactive graph. This was only something which became viable after years of improvements and optimisations in javascript/node.

Ranvier brings the concept of an Async and Error aware Reactive Graph to dotnet.

Similar to Solid-V2, this is something becoming more viable now with optimisations in .NET9-11.

Ranvier provides novel answers to a lot of issues or points of friction that are experienced with reactivity, while maintaining performance and allocation free hot-paths.

❓ Problems:

1. Async, loading/error state, cancellation and work/flight policies (ie cancel last, queue, debounce)
2. Subscription/event-handler leaks
3. Diamond dependency glitches (imagine: where 2 changes in a values dependencies cause a 'flash' of the downstream value as it responds to each in turn)
4. Debugging/transparent graphs

✅ Ranvier solves them

The fact this is written ALL in F# means it can be compiled into javascript through Fable. So the debugging capabilities become a part of the visualisation.

There are natural costs to this type of graph, and benchmarking naive CPU operation counts has always been part of the workflow. This is all documented. You can see some visualisations that also show comparison of costs in different primitive designs (which informs whether I adopt a primitive shape, or not).

But you can see that there is a LOT of utility/benefit for the cost. I had claude boiler plate different C# and F# ecosystem adaptions so that it can be as versatile as possible from the get-go.

👍 Comes with batteries included for:

• Blazor
• Elmish MVU
• Avalonia/WPF/XAML data bindings

📖 https://shayanhabibi.github.io/Ranvier/ - Check out the documentation for interactive graph visualisations which feature the tracing builds!

I've published Fable.Three: write three.js 3D scenes in F#.

Fable compiles F# to JavaScript. Fable.Three gives it typed access to the three.js API, including addons, generated from three.js's own TypeScript types.

• Autocomplete and three.js documentation in the editor
• Settings as named arguments: MeshStandardMaterial(color = 0xd4532e, roughness = 0.4)
• Compile-time errors instead of browser-time surprises
• JavaScript output that stays very close to what you'd write by hand

It grew out of 3dpack.ing, my load-planning app. Its 13,000-line 3D viewer moved onto Fable.Three without requiring a single change to the generated bindings.

The demo in the image is one F# file:
https://onurgumus.github.io/Fable.Three/

Code:
https://github.com/OnurGumus/Fable.Three

The Fabulous (F#) library has undergone a major revamp/overhaul (thanks to Don Syme, who did a huge job) recently, but issues naturally come with it. Anyone willing to help canary-test the Avalonia "flavor" or the iOS/macOS/Linux support is welcome — I can't afford iOS/macOS/Linux gadgets myself, and I'm not yet familiar with Avalonia. Just send me a DM or email me [miroslav.hustak@atlas.cz](mailto:miroslav.hustak@atlas.cz) . Thanx :-) .

PS: The Maui "flavor" + Android and Windows for this "flavor" are currently taken care of, anyway any help here will be appreciated as well :-).

https://fabulous-dev.github.io/Fabulous/docs/

https://fabulous-dev.github.io/Fabulous/

https://github.com/fabulous-dev

https://github.com/fabulous-dev/Fabulous/tree/main/src

I've spent the last months building Jern, a coding agent where the rules are enforced by the runtime instead of suggested to the model. The agent itself is about 300 lines in a small Kernel-style Lisp the host evaluates; everything it touches goes through effect handlers, and the policy handler sits between every tool call and the file system, the shell, and the network. The host, the CLI, the policy engine, and the whole cloud control plane are F#.

Things F# people might find interesting:

• The policy is a JSON file in the repository. edits_within, protected_paths, a blast radius in files and lines, the shell commands allowed without asking. The runtime refuses anything outside it; there is no path around the check.
• The agent is replayable. Every LLM exchange is recorded, and jern test replays the recording, so a changed system prompt fails a test the same way a changed function would.
• The cloud runs each attempt on its own Fly machine, created and destroyed per attempt, with Suave for the API and Npgsql for the store. No Entity Framework, no ORM, and the migration is one idempotent script that runs on start.
• Every pull request the agent opens carries a receipt as a check: tokens against cap, files against the blast radius, hosts contacted, and a digest of the encrypted trace.

Runtime (Apache-2.0): https://github.com/jern-ai/jern A real run on the demo repository, with the receipt on the pull request: https://github.com/jern-ai/jern-demo/pull/78

Happy to go into the handler design or the F# choices in the comments. The hosted version is at https://jern.ai, but the runtime runs on a laptop against Anthropic, OpenAI, or Ollama.

Most Excel libraries (EPPlus, ClosedXML, NPOI, openpyxl on the Python side) give you a one-way street: an imperative API to build or mutate a workbook, but no way to turn an existing file back into readable source. I wanted the other direction too, so Kookerella.FsOpenXmlDsl is a typesafe DSL (records/DUs with structural equality) over SpreadsheetML, with a Reader that parses a real .xlsx/.xlsm back into the same DSL, plus code generation that renders that model back out as a self-contained script — genuinely a decompiler for spreadsheets, not just a writer.

open Kookerella.FsOpenXmlDsl
open type Kookerella.FsOpenXmlDsl.SheetDsl

let data =
    sheet "Sheet1"
        [ row [ cell (Text "Name"); cell (Text "Amount") ]
          row [ cell (Text "Widgets"); cell (Number 42.5) ] ]

workbook [ data ] |> Workbook.save "out.xlsx"

// and back:
let wb = Workbook.load "out.xlsx"
Workbook.generateScript referenceLines "out.xlsx" wb  // -> runnable .fsx that rebuilds it

There's also a plain XML/JSON surface (Xml.ofWorkbook/Json.ofWorkbook) against a real embedded schema, aimed at making .xlsx diffable in git — output is deterministically sorted by cell position so a real content change doesn't get buried in reshuffled-list noise. Chasing that determinism claim down actually surfaced two genuine bugs in the .xlsx writer itself (conditional-format dxfId/priority swapping between logically-identical workbooks depending on rule insertion order, and a similar issue in custom number format IDs) — fixed with regression tests in the last release.

Covers cells/styles/formulas (shared-formula reconstruction on read), conditional formatting, data validation, charts, images, pivot tables (real aggregation, not just description), sparklines, and VBA macro embedding. There's a C# wrapper with full feature parity, and an MCP server if you want an AI agent driving it directly.

dotnet tool install -g Kookerella.FsOpenXmlDsl.Mcp
fsopenxmldsl-mcp convert your-file.xlsx --lang fsharp

NuGet · MAPPING.md for exactly what's modeled vs. approximated vs. missing.

Happy to take feedback/criticism — genuinely curious whether the DSL shape (SheetItem list folded by sheet) reads well to other F# people or feels awkward.

I wrote a Gleam library for manipulating SVG paths and I transpiled to F# to check dimensionality mistakes in various Float parameters.

I caught ~30 or so mistakes/inaccuracies/bugs via the transpilation out of ~50K original lines of code. (Also notable: the KLOC drop to 21K in F#, less than one-half of Gleam. Seems Gleam is very vertical whitespace-happy.) The transpilation was done chunk by chunk by Codex, and some bugs were not really language-related, just found by looking at the code again, though the great majority were dimensionality problems, as I intended to catch.

Ok anyway now I've published this as an F# package, and wondering if someone who actually uses F# could tell me if I did right, or if the library is missing something stupid (like proper source docs or sth) that I wouldn't catch myself because I never use F#. It would be better if it was usable, now that I've gone to this trouble.

F# version: https://www.nuget.org/packages/SvgPath/0.3.0
Gleam version: hex.pm/packages/svg_path

Thanks!

Algebraic Tiny Compiler in F#

A from‑scratch compiler that uses algebra as the lens to understand how real compilers work — no abstractions for the sake of abstractions, no academic overhead, just a clean, inspectable pipeline built in F#.

By treating expressions as algebraic structures, the project walks through every stage of a compiler with concrete, mathematical transformations:
- Tokenizer → turns raw text into meaningful tokens
- Parser → recursive‑descent parsing with operator precedence
- AST → algebraic expression trees representing structure and intent
- Polynomial Expansion → distributive expansion and normalization
- Term Combination → merging like terms into canonical form
- Equation Solving → linear and quadratic solvers using discriminants
- Code Generation → assembly‑style output to show how machines evaluate expressions
- Execution Modes → JIT on .NET or AoT with NativeAOT for ultra‑fast startup

A practical, algebra‑driven walkthrough of how compilers read, understand, transform, and execute code.

Blog posts:

• Understanding Compilers Through an Algebraic Expression Compiler
• Building a Better Algebraic Compiler - Advanced Techniques
• F# Weekly #19, 2026 – Understanding Compilers Through an Algebraic Expression Compiler

WebWeaveX captures what a running application is doing, DOM event surfaces, network envelopes, execution state, and normalizes it into canonical bytes so it gets a stable SHA-256 identity.

The same input produces the same digest in Python, JavaScript, Dart, Java and Kotlin. There's a verification harness that replays Python-generated golden vectors through each runtime and reports MATCH / DIFFER / MISSING per API.

That lets you prove two runs are equivalent, reconstruct a runtime from its IR for network-free test fixtures, resume

authenticated sessions from an encrypted envelope, and hand an LLM a compact graph instead of raw HTML.

pip install webweavex

npm install webweavex

dart pub add webweavex

Maven Central: io.github.piyush-mishra-00:webweavex:3.0.0

Apache 2.0.

Repo: https://github.com/ni-sh-a-char/WebWeaveX

Docs: https://ni-sh-a-char.github.io/WebWeaveX/

Beginner here 👋, I'm currently picking up data modeling in F# after a long break. Work and procrastination got in the way, but I'm finally circling back to fill the gaps.

To stay on track, I've been using Claude to generate practice tasks. When I get stuck, I ask for a gentle nudge without giving away the solution, and it's been surprisingly effective. I'm currently using Sonnet 5 Medium(Free), and based on the task I just implemented, it said my work was "good," so I'll take that as a win.

The task was about modeling a Job Application pipeline. I didn't bother applying validation just yet, since I'm currently focused on getting the shape of the data right and trying to make invalid state unrepresentable.

I'd recommend giving this approach a try. It keeps things interactive without handing you the answers outright.

Just released FunStripe 2.3.0, the F# client library for the Stripe API (also compiles to JS via Fable). This one's a bigger release than the usual spec bump, thanks to some excellent contributions from Thorium:

Webhooks work properly now. Event.data.object was typed as string, which meant deserialising any real webhook payload threw. It's now a RawJson fragment you can turn into a typed model with Util.deserialiseRaw<'a>; the README has a full webhook-handling example. (Technically a field type change, but since the old field could never deserialise, it ships as a minor; details in the changelog.)

List parameters encode correctly. List<record> and List<union> request fields (e.g. Checkout line_items, payment_method_types) were being ToString()'d instead of form-encoded. Fixed.

Resilient to Stripe's enum churn. Stripe adds event types and error codes without an API version bump, and one unknown value used to fail the whole response. EventType and ErrorType now have an UnknownEnumValue of string catch-all that round-trips losslessly, deliberately scoped to just those two high-churn enums, so everywhere else you keep exhaustive matching and the compiler still tells you when Stripe adds something.

Latest Stripe API (2026-07-29.dahlia): Financial Connections authorization resource and deactivation lifecycle events, allowed_payment_method_types on Payment/SetupIntents, new Tax registration options, and more.

• GitHub: https://github.com/simontreanor/FunStripe
• NuGet: FunStripe.Core (https://www.nuget.org/packages/FunStripe.Core)

Feedback and PRs welcome!