Forem: David Hoze

Introducing claude-collab

David Hoze — Sun, 08 Mar 2026 04:09:11 +0000

Hi there.

I've been working on my project — bit — and wanted to work on several ideas at once. I tried doing it with 3 working directories, git pushing and pulling and merging... it really gave me a headache. So I started using agents in the same directory, and telling them not to interfere with each other. It worked OK, but at some point it got hard always coordinating them, making sure they don't step on each other's toes. That's why I built claude-collab.

Implemented in Haskell, it's a single binary CLI tool that gives multiple Claude Code agents a way to coordinate. No server, no database, just the filesystem. The idea is simple: give agents two primitives — claim a file and commit your work — and a reservation system for resources you can't share. That's basically it. The agents are smart enough to figure out the rest.

The Problem

Picture this: you have Agent A working on auth, Agent B working on the config system, and Agent C writing tests. Sounds great until Agent A and Agent B both decide to touch src/utils.hs at the same time. Or Agent C runs run-test-suite.sh while Agent A is mid-refactor and everything blows up. Or two agents commit at the same time and you get a mess.

You could just tell them "hey don't touch each other's files" but... they're agents. They don't always listen. And even when they do, there's no structured way for them to know what the other agents are doing.

How It Works

Setup: One Command

Run claude-collab install in your project root and you're done. It installs three Claude Code hooks that automate the entire workflow:

SessionStart — auto-registers each agent when a session opens
PreToolUse (Edit/Write) — auto-claims files before any edit
SessionEnd — auto-cleans up when a session closes

This means agents don't need to remember to register or claim files. The only manual step is committing — and that's intentional. You want agents to commit deliberately, after they finished a feature, not after every edit.

Agent Registration

Under the hood, each agent registers itself when its session starts:

claude-collab init --name auth-refactor

This gives it a unique hash (like a3f8b201) and a human-readable name. The name is stored in the registry and can be used as an alias for the hash in all subsequent commands. So instead of claude-collab commit a1b2c3d4 -m "msg" the agent can do claude-collab commit auth-refactor -m "msg".

Claiming Files

Before an agent edits a file, it claims it (automatically, via the hook):

claude-collab files claim a3f8b201 src/auth.ts

If nobody else has it — great, you got it. If another agent already claimed it? You get a rejection (exit code 1), which forces the agent to pause and negotiate. This is the key design choice: the friction is intentional. It creates a natural "hey, let's talk about this" moment.

The rejected agent can then message the other agent using Claude Code's native messaging and either:

Wait for the other agent to finish
Co-claim the file with --shared if they're working on different parts

# After negotiating with the other agent...
claude-collab files claim a3f8b201 src/auth.ts --shared

Committing

When an agent is done with its work:

claude-collab commit a3f8b201 -m "refactor auth validation"

This stages and commits only the files that agent claimed. No accidentally committing someone else's work. The committed files are automatically unclaimed, freeing them up for others.

But here's where it gets interesting — what about co-claimed files? If two agents both edited the same file, you can't just have them both commit separately.

So I used git's staging mechanism. Instead of trying to figure out how to commit only one agent's changes and not the other, claude-collab simply stages the first agent's files and waits for the other agent to finish. When the second agent commits, it triggers the real git commit with everyone's changes combined:

[a3f8b201] refactor token validation | [d4e5] add rate limiting

One clean commit with both agents' work. No merge conflicts, no manual intervention. And the first agent doesn't need to sit around waiting — it can claim new files, make more edits, and even run another commit for different work while the co-claimed files stay staged in the background.

Resource Reservations

Some operations can't run in parallel — two agents running the test suite at the same time would interfere with each other. So there's a reservation system:

# Reserve the test suite
claude-collab reserve a3f8b201 test

# Run your tests
run-test-suite.sh

# Release it
claude-collab release a3f8b201 test

After running tests, agents message each other with the results using Claude Code's native messaging, so others can skip redundant work.

If another agent already has the resource, reserve will wait (polling every 500ms) until it's free or times out. Each reservation has a TTL so if an agent crashes without releasing, the reservation expires. The TTL is configured per-resource in .claude/agents/resources.json.

Two resources come pre-configured: test and build. You can add your own by editing that file.

Under the Hood

Locking

All the coordination uses mkdir-based locks. mkdir is atomic on every major filesystem (NTFS, ext4, APFS), so it's a cheap and reliable mutex. There are two locks:

Git lock — serializes git commits so two agents can't commit simultaneously (30s stale timeout)
Reserve lock — protects reservation updates (5s stale timeout)

Crash Recovery

If an agent crashes mid-task, nothing deadlocks. Lock directories older than their stale timeout get force-broken by the next agent that needs them. Resource reservations expire after their TTL, so a crashed agent's reservation doesn't block others forever. And the SessionEnd hook runs cleanup automatically when a session closes — unclaiming files, releasing reservations, and removing the agent from the registry.

The one thing that doesn't auto-recover is staged co-claimed files. If Agent A stages changes for a two-phase commit and then crashes before Agent B commits, those files stay staged in the registry. But that's a deliberate trade-off — it's better to leave staged work intact for manual recovery than to silently discard it.

Atomic Writes

All JSON file writes (the registry, reservations, resources) use write-to-temp-then-rename. This prevents partial writes from corrupting the data if an agent crashes mid-write. On Windows, the destination is removed before renaming since Windows rename fails if the target already exists.

Putting It All Together

Here's what a typical multi-agent session looks like:

# Agent 1: auth work
claude-collab init --name auth-agent
claude-collab files claim auth-agent src/auth.ts src/session.ts
# ... edit files ...
claude-collab commit auth-agent -m "refactor auth flow"
claude-collab cleanup auth-agent

# Agent 2: tests (running concurrently)
claude-collab init --name test-agent
claude-collab reserve test-agent test
npm test
claude-collab release test-agent test
claude-collab cleanup test-agent

And if they need the same file? They negotiate through Claude Code's native messaging, co-claim, and the two-phase commit handles the rest.

The Design Philosophy

The whole thing is built on one idea: don't try to be smarter than the agents. Instead of building a complex locking system with priority queues and deadlock detection, just give agents simple tools and let them talk through Claude Code's native messaging. They're Claude Code instances — they can negotiate, delegate, and figure things out. The claim system creates the pause; the agents fill it with conversation.

A Working Example

Here's a real session where I used agents to fix test failures, and two of them ended up touching the same file. Pay attention to the bold note on binary-fixer — that's the co-claim and two-phase commit in action.

❯ OK, run another team to fix all failures

2 agents launched:

Agent	Task
`@export-fixer`	Fix export/import junction routing
`@binary-fixer`	Fix binary test edge cases

Team fix-failures is up with 3 agents:

Agent	Task	Failures
`export-fixer`	Export/import broken in junction mode	14 CLI test failures
`binary-fixer`	Binary test edge cases	4 failures (restore, mv subdir, merge -X theirs)
`init-fixer`	init-nested test 8	1 CLI test failure

Skipping network-remote.test (9 failures) — those require \\tsclient UNC path which is infrastructure-only.

That's 19 fixable failures across the three agents. I'll relay results as they come in.

❯ Don't skip network-remote.test.

Added network-fixer to handle the 9 network-remote.test failures. Now all 28 failures are covered:

Agent	Failures
`export-fixer`	14 (export + import)
`binary-fixer`	4 (restore, mv, merge)
`init-fixer`	1 (init-nested)
`network-fixer`	9 (network-remote)

@init-fixer — Fixed init-nested test 8, committed cf618cd. Test expectation was outdated for the gitfile change. ✅

@binary-fixer — All 3 binary test fixes done and verified. 1 real code bug (bit mv to subdirectory) and 2 test bugs. The Passthrough.hs commit is blocked on a co-claim with d6d55282 — likely export-fixer who also needs to edit Passthrough.hs. When export-fixer commits, both changes will land together. ✅

@export-fixer — Fixed export/import/init junction routing, all tests pass. The isBitOnlyCommand guard is the right approach — keeps the junction early-exit but carves out bit-specific commands. ✅

@network-fixer — network-remote.test fixed, 17/17 pass, committed. Network tests now degrade gracefully — pass with real UNC when available, skip cleanly when not. ✅

Worked for 15m 59s

Results: 28 failures → 0

Agent	Failures Fixed	Type
`init-fixer`	1 (init-nested)	Test expectation updated for gitfile
`binary-fixer`	4 (restore, mv subdir, merge -X theirs)	1 code bug + 2 test bugs
`export-fixer`	14 (export + import)	Code bug — junction early-exit skipping bit-only commands
`network-fixer`	9 (network-remote)	Added graceful skip when `\\tsclient` unavailable

Total: 28 failures → 0. The full CLI suite now passes clean (minus cloud tests needing specific remotes).

All agents shut down. 🧹

What's Next

You can grab a pre-built binary — Windows or Linux x86_64 — or build from source with cabal build && cabal install. Once it's on your PATH, run claude-collab install in your project root. It sets up CLAUDE_COLLAB.md, the hooks, and adds a few lines to CLAUDE.md so your agents know how to use it.

Happy collaborating!

Cast Your Bread Upon the Waters

David Hoze — Sun, 15 Feb 2026 20:35:54 +0000

Hi, my name is David, and I'm a very good developer. For insane reasons I cannot specify right now, I stopped working in the tech industry. I now work approximately 3 hours a day fund raising for the religious schools of my orthodox congregation. I study Torah at night, where Rachel Imenu (yes, from the bible) is buried, and like it a lot. I wasn't laid off because of AI. My story is different.

During my time here calling people and asking them to renew their donations, I started hacking around with stuff. One thing led to another, and I started thinking of an idea. Why can't I just git add mp3 files, pdfs, or whatever, and just commit and push them? I know, no diffs, and git doesn't handle that well and so on and so on. But why? The more I thought of it, ideas started popping. Not some extension or a tool with different semantics, the same git semantics and simplicity, just for other files. Ideas started coming to my head, and I thought about it all day long.

When things started to form into shape, I consulted AI and started writing my program. I found out how easy it was to write code using AI, and from copying and pasting, I slowly started to find out about developing more seriously with AI. Cursor IDE was my first, and it amazed me how easy it was to write code, specs, tests (things I was always too lazy to do as a developer), and it was just FUN. AI did all the heavy-lifting for me, and I just had to interfere when it was doing silly things, and pointing it to the right direction.

I wasn't a developer anymore. I have become an architect. The years of experience came into play. I knew what good code looked like, and I could spot architectural mistakes. I no longer had to meddle with the details, I just had to think of an architecture, weigh subtle alternatives and make important decisions. I have become a manager of junior programmers, Claude et al. It was amazing. But what was more amazing were the circumstances that led me to it. I have very little money, and for various reasons, I can not be employed right now as a developer. That actually gave me unlimited freedom. I could just program what I wanted, not caring if anyone liked it, would buy it or whatever.

So, I created bit, which I'm very proud of. It's still a work in progress, but I have high hopes for it. So, what am I saying? Maybe you're a developer who has not found himself in the right place in the tech industry... Maybe you're over-qualified in what you do. Maybe you lost your jobs because of current trends, or maybe you're just wondering what your role is in the world of AI development. I want to tell you what I think. I think that AI poses an opportunity. It's an opportunity to do what you've always wanted.. Write in any language you like, and develop that amazing tool you always wanted to. With AI you can do in weeks what would take months or years, and all by yourself. As a seasoned dev, you can instruct AI to build GOOD and maintainable software. You can design a product, and use skills a manager might not have, i.e. reading code, understanding trade-offs... You can skim over code, find out architectural mistakes AI makes (and it still makes them), and guide it to give very good results...

King Solomon says "Cast your bread upon the waters, for after many days you will find it again" (Ecclesiastes 11:1). I have the advantage of having nothing to lose. That gives me a lot of freedom. Maybe my story will inspire people to create something, without expecting return.

Writing idiomatic Haskell with AI

David Hoze — Thu, 12 Feb 2026 15:29:04 +0000

So, I checked out my project, bit — a version-control tool for binary files, that I talked about in my previous article, and the code looked pretty decent. However, it really looked like it was imperative code written in Haskell. So true, the types and the ADTs were great (though not fully taken advantage of in a lot of the project), and I believe that the mere fact that a function is pure and has no side-effects, lets AI reason about the function much more easily. But it looked like the AI wasn't fully taking advantage of all of Haskell's features.

Letting AI do the research

So.. I asked Claude to research and give me two documents, a Guide for Writing Idiomatic Haskell a Guide for Type Safety in Haskell . I then used Cursor IDE to run Opus 4.6 and use those guides to refactor the code. At first, it just changed a lot of returns to pures (and not all of them). I told the agent it looks a little weird that it only changed that, so it admitted and made a deeper pass over the code base, that had a lot of changes. I then asked it again, and it did another one, again with a lot of changes. I did that for 12 (!) rounds, and each time it found something new.. I'm talking about Opus 4.6 here.. One of the times I tried Sonnet 4.5, but it did some weird refactoring.. These refactors require more subtlety and reasoning I guess.

This isn't surprising — recent research found that LLMs struggle with Haskell specifically because functional languages make up a tiny fraction of training data (Haskell is just 0.29% of The Stack]), a major code training dataset). The models know the syntax, but they default to imperative patterns unless pushed.

What the AI actually changed

After twelve rounds of refactoring guided by the two reference documents, the diff touched 30 Haskell files across roughly 1,500 lines. Many changes were mechanical — pure over return, void over _ <- — but three categories stood out as the AI applying genuine Haskell reasoning, not just surface-level substitution.

Killing boolean blindness with sum types

The original code tracked push behavior with two booleans on the environment record:

data BitEnv = BitEnv
    { ...
    , envForce          :: Bool
    , envForceWithLease :: Bool
    , ...
    }

Since force with lease is already force, the combination (True, True) was meaningless. And indeed, the command parser had a runtime guard to reject it:

when (isForce && isForceWithLease) $ do
    hPutStrLn stderr "fatal: Cannot use both --force and --force-with-lease"
    exitWith (ExitFailure 1)

So, on one of the passes, the AI replaced both booleans with a single sum type:

data ForceMode = NoForce | Force | ForceWithLease

It was one field less, no runtime guard, and every consumer switched from a nested if-else-if to case fMode of — which looks nicer, and is checked by the compiler exhaustiveness. And on the safety angle, the illegal state (True, True) is no longer representable.

The AI applied this same transformation twice more, and in each case, the pattern was the same: an undernamed boolean became a properly named type, that anyone (including AI) can read immediately and understand.

This is what Robert Harper calls boolean blindness — a Bool carries no information beyond its value, so the moment you branch on it, you've lost the meaning of what was tested. And in software safety terms, no test can prove the absence of a (True, True) code path as reliably as a type that simply can't express it. (An ICSE 2017 study found that static type systems catch roughly 15% of public bugs in JavaScript projects — bugs that tests missed...)

Replacing verbose case expressions with combinators

A nice replacement is this one:

bs <- BS.readFile path
let content = case decodeUtf8' bs of
      Left _ -> ""
      Right txt -> T.unpack txt

The AI recognized every instance as the either eliminator and collapsed them:

bs <- BS.readFile path
let content = either (const "") T.unpack (decodeUtf8' bs)

A lot of boilerplate is gone here, less clutter for the mind (and for AI) to deal with.

Reducing ambiguity per token with Functor

This classifyRemoteState example though, has a deeper advantage:

-- Before
classifyRemoteState remote = do
    result <- Transport.listRemoteItems remote 1
    case result of
        Left err -> pure (StateNetworkError err)
        Right items -> pure (interpretRemoteItems items)

-- After
classifyRemoteState remote =
    either StateNetworkError interpretRemoteItems
      <$> Transport.listRemoteItems remote 1

The <$> means that we're chaining the result from Transport.listRemoteItems remote 1 to either one of the options, an error or the remote items, but it also means that no side effects happen when chaining.

The former do block on the other hand, uses monadic bind (>>=), which tells the compiler and the reader "the next step might depend on the result of the previous one." But the <$> version uses Functor, which says something stronger: "this is a pure transformation over an effectful value — unlike the do notation, the function inside the <$> can't print, can't read files, can't launch side effects based on whether it got a Left or Right.

The model processes both versions either way — but the difference lies in pattern recognition load. When the model sees <$>, it can classify the entire expression in one step: "pure function applied over an effect, move on." When it sees the do version, it has to read each line to reach the same conclusion: "bind, then case, then pure in both branches — ok, so this is just a pure transformation."

This change actually reduces ambiguity per token. Each expression carries more information about what it can't do, which means the model's context window is doing more useful work. It's simple information theory: higher signal per token means less work to resolve the meaning of the surrounding context.

There's growing evidence for this. A NeurIPS 2024 paper showed that not all tokens contribute equally to learning — roughly half are "easy tokens" that carry little information, while training selectively on high-information tokens improved math reasoning by up to 30%. And research on tokenization theory has shown that how information is packed into tokens directly affects whether transformers can learn underlying structure. The implication for code is that expressions which encode more meaning per token — like <$> signaling purity — give the model richer signal to work with.

The win is local reasoning. The <$> version communicates its intent in its type structure rather than requiring you to read the implementation to confirm "yes, result is only used once, in a pure context, and pure is the only effect after the bind."

Introducing an ADT and finding a bug

Sometimes the refactor itself lets AI unravel logical bugs. compareHistory in RemoteManagement.hs compared local and remote histories, to check whether a push would fast-forward or not. It checked both directions, and had a pattern match on the resulting booleans:

localAhead  <- Git.checkIsAhead rHash lHash
remoteAhead <- Git.checkIsAhead lHash rHash

case (localAhead, remoteAhead) of
    (True, False) -> putStrLn "    main pushes to main (fast-forwardable)"
    (False, True) -> putStrLn "    main pushes to main (local out of date)"
    (False, False) -> putStrLn "    main pushes to main (local out of date)"
    (True, True)   -> putStrLn "    main pushes to main (up to date)"

When the AI first wrote this code, it was just filling in strings. Notice though, that for the (False, False) case — neither side ahead of the other, which means the repos diverged. The AI conveniently printed "local out of date", which sounds plausible enough if you're not thinking too hard. And clearly it wasn't. What caused this? The string has no structure, no type checker reading it, no compiler verifying it means what it says. It's just characters going to a terminal.

Then I asked the AI to refactor using an ADT. It introduced PushRefStatus with three constructors — PushRefUpToDate, PushRefFastForwardable, PushRefLocalOutOfDate — and a bridge function to convert the boolean pair. But when it got to (False, False) and had to map it to a constructor, something shifted. It couldn't just type a vague phrase and move on. It had to pick a name — a name that would appear in type signatures, in pattern matches, in code review. And PushRefLocalOutOfDate was the wrong name.

If the hashes aren't equal and neither side is ahead of the other, the histories have diverged — both sides have commits the other lacks. The AI flagged this itself during the refactor: the act of naming the state precisely made the incorrectness visible.

The fix was to add a fourth constructor:

data PushRefStatus
  = PushRefUpToDate
  | PushRefFastForwardable
  | PushRefLocalOutOfDate
  | PushRefDiverged

This is the principle Yaron Minsky articulated as "make illegal states unrepresentable" — but here it worked in a subtler way. The illegal state wasn't a type error; it was a semantic error that became visible when the type demanded precision. Alexis King's "Parse, don't validate" makes the same argument from a different angle: a parser (or an ADT) forces you to commit to what your data means, where a validator (or a string) lets you be vague.

This is something worth internalizing about AI-assisted development. When the output is a string, the AI can be vague and get away with it — "local out of date" is close enough, and no tool will object. But when the output is a type, vagueness has a cost. A constructor name is a commitment: it appears everywhere the value is handled, and it has to be accurate at every site. The ADT didn't just replace the booleans — it raised the precision bar high enough that the AI couldn't miss a case it had previously gotten wrong.

Conclusion

AI is used to writing imperative code, but it in fact knows how to write Haskell code, it just needs to be pushed in that direction. This gives FP beginners an easier start when trying to enter this world. It does the heavy-lifting (pun intended) for us, and the result is a more expressive, more reliable and robust code, that's easier for AI, or experienced FP programmers, to reason about.

Overall I'm having a lot of fun writing Haskell with AI. Claude Opus 4.6 doesn't seem to "struggle" with Haskell, it's smart enough. I'm learning a lot of cool concepts as I go along, an can apply them with a lot of the tedious work being done by AI.

How I Built a Version Control Tool in Haskell Using AI – Even Though I'm a Swift Developer

David Hoze — Sat, 07 Feb 2026 23:54:53 +0000

Though I'm an experienced Swift developer, I barely know Haskell. I vaguely understand what a monad is, and I once spent an afternoon fighting cabal before giving up. I had no business writing a serious program in Haskell.

And yet I built bit — a version-control tool for binary files, like Git but for large media, datasets, and anything too big for Git to handle sanely — almost entirely through AI-assisted programming in Haskell. It's a real CLI tool that I use daily. What I discovered runs directly against the conventional wisdom about which languages work best with AI.

The Conventional Wisdom Is Backwards
What Happens When You Make AI Write Haskell?
The Workflow
AI Doesn't Just Write FP — It Discovers FP
The Training Data Paradox Is Temporary
It Works
The Real Question

The Conventional Wisdom Is Backwards

Ask around and you'll hear: use Python, use JavaScript. Most training data, gentlest syntax.

That's true. AI generates Python fluently. The problem is what happens next. It always compiles, because almost everything compiles in Python. Three weeks later you discover a silently mutated dictionary broke your data pipeline. The AI wrote confident, fluent, completely buggy code. Yes, Python is forgiving, but in a forgiving language, AI's mistakes go undetected.

What Happens When You Make AI Write Haskell?

At first, nothing compiles. GHC (the Haskell compiler) rejects almost everything, but the errors are specific — not "something went wrong" but "this function returns IO String and you're using it where Either Error String is expected."

So, Cursor sees the errors right away, and everything is immediately fixed. One or two rounds and it compiled. And when Haskell compiles, it usually works.

I'd gone from "fluent code that's silently broken" to "broken code that converges on correct code almost immediately."

The Workflow

Brainstorm → I describe what I want using Claude Opus 4.5 with extended thinking, and research mode when I thought it was necessary. I then brainstorm about the idea, and when it's final, I ask Claude to give me a Cursor prompt. Claude has access to my code, so it writes a really good prompt for Cursor.

Write code and tests → Cursor then writes the code and tests using Sonnet 4.5 (cheap model) that does it very fast and accurate, cuz it has a killer prompt from Claude.

Compile and fix → Cursor handles all of the dependency and GHC errors. Very smooth.

Test and fix → Also very cool. I have time now to write this article.

Reflect → After a feature is done, I ask Cursor this question:

You introduced some bugs while implementing this feature, right? Analyze why this happened structurally. What about the code's design made it easy to break [X] when touching [Y]? Suggest a refactor that would make this class of bug impossible or caught at compile time.

I expected generic advice. I got precise analysis of real design flaws that had caused real bugs minutes earlier. I took Cursor's suggestions back to Claude and asked it what we should do about this. Claude took some of Sonnet's suggestions seriously and wrote me a refactor prompt for Cursor. And there were some suggestions it declined. My code is now refactored to prevent real bugs AI introduced to the system, because it wasn't built well enough.

The code didn't just get better. It got harder to break.

AI Doesn't Just Write FP — It Discovers FP

Here's what I didn't expect. I asked the AI whether functional programming had abstractions that could improve my code's structure. It searched the web, read FP articles, and came back with concepts I'd never heard of.

There's a Kleisli arrow composition in my codebase now — it's called Pipeline — and it elegantly chains pure transformations: scan → diff → plan, where the pure core has no IO at all and is fully property-testable. I don't understand the category theory. But I don't need to.

Here's what it actually looks like in my code. The entire sync logic is a pure function — no network calls, no filesystem access, just data in and data out:

-- The pure core: no IO, fully property-testable
diffAndPlan :: [FileEntry] -> [FileEntry] -> [RcloneAction]
diffAndPlan sourceFiles targetFiles =
  let sourceIndex = buildIndexFromFileEntries sourceFiles
      targetIndex = buildIndexFromFileEntries targetFiles
      diffs       = computeDiff sourceIndex targetIndex
  in  map planAction diffs

It goes further. Here's what AI built into my codebase — concepts I have some intuition for but do not fully understand:

Phantom Types

A phantom type is a type parameter that appears in a type's definition but isn't used in its data. It exists purely for the compiler to enforce constraints.

My hash type uses one so the compiler distinguishes MD5 from SHA256. Mixing hash algorithms is a compile error. One line of type machinery that eliminates an entire class of bugs forever:

data HashAlgo = MD5 | SHA256

newtype Hash (a :: HashAlgo) = Hash Text

Now if a function expects Hash 'MD5 and you pass it Hash 'SHA256, GHC stops you at compile time. No runtime check needed. I think it looks cool. Couldn't write it myself.

Opaque Types with Smart Constructors

Remote exports its type but hides the constructor. You can only create one through mkRemote. Invalid remotes are unrepresentable:

module Bit.Remote
  ( Remote          -- type exported, constructor hidden
  , mkRemote        -- the only way to create a Remote
  , remoteName      -- read-only access
  ) where

data Remote = Remote
  { _remoteName :: String
  , _remoteUrl  :: String
  }

mkRemote :: String -> String -> Remote
mkRemote = Remote

This is a standard pattern in Haskell for maintaining invariants through the type system. Code outside this module literally cannot construct an invalid Remote.

ADTs for Every Domain Concept

An ADT (Algebraic Data Type) is a type defined by enumerating its possible variants. The compiler forces you to handle every variant — miss one and GHC gives you a warning (or an error, if you enable -Wall).

Every domain concept in my project is modeled this way:

-- What changed between local and remote?
data GitDiff
  = Renamed LightFileEntry LightFileEntry
  | Added   LightFileEntry
  | Deleted LightFileEntry
  | Modified LightFileEntry

-- What should rclone do about it?
data RcloneAction
  = Move Path Path
  | Copy Path Path
  | Delete Path
  | Swap Path Path Path

-- The planner: pure function, no IO
planAction :: GitDiff -> RcloneAction
planAction (Modified f)      = Copy f.filePath f.filePath
planAction (Renamed old new) = Move old.filePath new.filePath
planAction (Added f)         = Copy f.filePath f.filePath
planAction (Deleted f)       = Delete f.filePath

If I add a new variant to GitDiff tomorrow, the compiler immediately tells me every function that needs updating. In Python, that's a bug waiting to happen at runtime.

A Free Monad Effect System (That Got Removed)

AI built a free monad effect system — with a pure interpreter that simulates the entire program without touching IO, using a fake filesystem in memory. I used it, and then the AI itself analyzed the tradeoff and recommended removing it: the complexity wasn't justified since I had no pure tests yet.

It's documented in my spec under "What We Chose": ReaderT BitEnv IO (no free monad) — rejected as premature.

AI didn't just apply FP — it applied it, evaluated the cost, and rolled it back when simpler was better.

A ConcurrentIO Newtype Without MonadIO

AI built a ConcurrentIO newtype that deliberately hides its constructor and omits MonadIO, so nobody can smuggle unsafe lazy IO into concurrent code. The comment in the source says:

newtype ConcurrentIO a = UnsafeConcurrentIO { runConcurrentIO :: IO a }
  deriving (Functor, Applicative, Monad)
  -- NOTE: No MonadIO instance! This is intentional.
  -- Deriving MonadIO would allow 'liftIO' to smuggle arbitrary lazy IO.

I know enough to appreciate this. I don't know enough to have designed it.

What We Deliberately Don't Do

And then there's a "What We Deliberately Do NOT Do" section in my spec, where AI listed FP abstractions it considered and rejected: typed state machines, representable functors, group structures. It reasoned about the right level of abstraction for each problem.

I want to be clear: I am not familiar with most of these concepts. I have intuition — they feel right, they look elegant. But the AI found them, read the articles and the docs, and applied them to my code! I don't have to be afraid, because the compiler shouts at the errors, the tests find the bugs, and everything just magically works! No, really.

The Training Data Paradox Is Temporary

Supposedly AI is worse at Haskell today because there's less training data. From my experience, it matters less than you'd think. My AI needed two abilities: generate a reasonable first attempt, and respond intelligently to compiler errors. The first requires some training data. The second requires reasoning — and that is improving fast.

My codebase is proof. The AI didn't retrieve memorized Haskell patterns for phantom types or free monads. It reasoned about type relationships, searched for solutions, and applied concepts from articles it had never seen during training. As models get better at reasoning, the importance of training data volume shrinks. And the languages with the strictest compilers will have the biggest advantage, because they provide the richest feedback signal.

The conventional wisdom says: use the language AI knows best. I think the better advice is: use the language whose compiler teaches AI the most.

It Works

I should mention: bit isn't a toy project. I use it daily. I'm its only user so far (just pushed it to GitHub a week ago), but I'm also its active developer — building features and using them as I go, and... it works. It's a pleasure to write this way. I just tell Claude what I want, and we think together about how to do it. The test suite is comprehensive because AI wrote tests for every feature, so I know everything's good. The architecture is clean because AI audited its own mistakes and proposed structural fixes. And the code uses FP concepts I barely understand.

Mind this: I built this in a language I barely know, using concepts I can't fully explain, with an AI that learned those concepts on the fly. And the result is more robust than most codebases I've seen written by teams of experienced developers.

The Real Question

For decades we chose languages based on how easy they were for humans to write. Python won that race. But the question is shifting. It's no longer "what's easy to write" but "what's easy to write correctly, when AI is doing most of the writing?"

The next time you start a project with AI, consider reaching for the language that makes AI accountable, not just productive. You might be surprised how far you get — even in a language you barely know.

I was.