How LLMs accelerated Cloudy development LLMs do help when writing code (we finally know how to center divs in all circumstances).<br>But when editing large, non-trivial projects, they need a lot of guidance to avoid slop; they relieve developers of typing the code, not of thinking it through.<br>So unless one is a very slow typist or using terribly verbose languages, not much gain will come from that direction.
Cloudy is typed on the best keyboards on the market and almost all its code from the agents to the web front-end is written in OCaml, a language that’s everything but verbose.
Still, LLMs are making the development much faster. How come?
Obsoleted by LLM: UI, documentation, onboarding, programmers
You would think that in developing a very technical, low level product such as Cloudy, most of the time is spent doing system programming, network analysis and infrastructure.<br>But you would be wrong: most of the development time is spent in implementing, testing and debugging the UI.<br>Yes, like any run-of-the-mill e-commerce website.
Here are some rough stats on Cloudy’s git repositories:
60% of lines of code are for the web UI (same language throughout, so the comparison holds)
50% of files touched by any commit are for the web UI
So it seems reasonable to estimate that half the work has been the UI.
Part of that is due to the accidental complexity brought by web technologies (let’s not get started on that), but also because many UI problems are genuinely hairy.<br>One of them is editing arbitrary, deeply nested data structures with many specialized data types, such as the abstract syntax tree Cloudy uses to represent its testing programs.<br>The need to edit a small DSL (Domain-Specific Language) arises frequently in UI work, and I’ve never seen a good solution for it; I came to consider this the Holy Grail of user interfaces.
Even with a good reactive layout and responsive validators, most users will find such a form intimidating:
In addition to the UI itself, one needs to write:
a contextual help,
a comprehensive manual,
a tutorial or two…
And then one needs users who are willing to make the investment of learning your software.<br>The most precious of them, those who are just giving your app a 15-minute test drive, don’t fit that description.
The fundamental issue is that a lot of concepts in tech come naturally in the form of some formal language, and humans are not good at that.<br>They need explanations and training that they have no patience for.
But guess who is good with formal languages? LLMs.<br>Give an LLM a formal syntax with its specification, a couple of examples, and half a second later it is a power user.
Compare the above screenshot with this Claude-Code session:
Claude Code
▐▛███▜▌ Claude Code v2.1.222
▝▜█████▛▘ Opus 5 · API Usage Billing
▘▘ ▝▝ ~/src/cloudy_mcp_tests
❯Start monitoring every five minutes that cloudywithachanceoflatency.net responds to HTTP v1.0 to v3 with all popular versions of SSL, and that its certificate is valid. Also, measure the routes from all probes in Europe.
●I'll set this up. Let me first look at what the cloudy MCP server actually offers.
Called cloudy 7 times, ran 1 shell command (ctrl+o to expand)
tools/programs
tools/host-info for cloudywithachanceoflatency.net
tools/inventory
tools/host-info 4 times for various probes
called shell getent to get all possible IPs for cloudywithachanceoflatency.net
●Resolved the target: cloudywithachanceoflatency.net → 104.21.25.188 / 172.67.134.122 (Cloudflare anycast). The MCP server has no DNS tool and doesn't know the host, so I used a local resolver for that one step.
European probes, confirmed via host-info rather than by name — the names lie:
┌─────────────────────────┬─────────────────────────────────┬─────────┐<br>│ Probe │ Actual location │ Europe? │<br>├─────────────────────────┼─────────────────────────────────┼─────────┤<br>│ agent-hetzner-nbg1 │ Nuremberg, DE │ yes │<br>├─────────────────────────┼─────────────────────────────────┼─────────┤<br>│ agent-hetzner-hel1 │ Germany (despite hel1) │ yes │<br>├─────────────────────────┼─────────────────────────────────┼─────────┤<br>│ agent-ovh-UK1 │ France, OVH SAS FR (despite UK) │ yes │<br>├─────────────────────────┼─────────────────────────────────┼─────────┤<br>│ … │ … │ … │<br>├─────────────────────────┼─────────────────────────────────┼─────────┤<br>│ agent-aws-us-west-1 │ US │ no │<br>└─────────────────────────┴─────────────────────────────────┴─────────┘
Called cloudy 3 times (ctrl+o to expand)
tools/program-upsert (to create the program)
tools/program-config (to start the program)
tools/programs (to check)
●The program is created, enabled, and started (started: 1786255999).
cloudy-net-monitor — every 300s.
Structure — RepeatEvery 300s wrapping a Sequence of three tasks:
1. Httping from all probes (from: "") — the 8-request batch, HTTP/1.0, 1.1, 2, 3 × TLS 1.2, 1.3, in one connection-reusing array.
2. Route to 104.21.25.188 from the four European probes, TCP/443, maxHops 30, 3...