I engage with “recreational programming” (and natural language writing as well!) every weekend. I wouldn’t say I avoid it entirely, but experiencing flow state here and there helps to at least slow the decline.
martosaur
Alex66
Hope I’m not off topic,
a lot of people in this thread say LLMs are fine for trivial stuff but not for serious work. I disagree, with one condition: they’re useless for serious work if you drive them like autocomplete.
After more or less a year of daily LLM use on non-trivial Elixir libraries and projects, work related and side ones, I didn’t end up with a swarm of agents. I ended up with exactly two instances, a hard gate, and a deliberately annoying process.
The coder is Claude Code. It sees the repo, writes the code, and runs the gate.
The architect is a separate Claude chat that never sees the implementation. It only gets what the coder produces about the code: review reports, gate output, and an api.md describing the public contract (types, functions, invariants, error cases). From that alone, it writes the tests and reviews the reports.
The gate runs in this order, cheapest first:
mix compile --warnings-as-errors
mix format --check-formatted
mix test
mix credo --strict # plus extra checks enabled in .credo.exs
mix dialyzer # last, it's the slow one
CI runs Credo diff-gated against the merge base (credo diff --from-git-merge-base origin/main --strict), so a branch fails on what it adds, while a full-tree run ratchets the legacy baseline down over time. Dialyzer runs with :unmatched_returns on. Nothing counts as done until all of it is green, and “done” is the coder’s claim, not a fact, until the architect has seen the output.
Why bother?
- Tests written from the spec, not the code. When the same model writes both the implementation and the tests, the tests quietly encode whatever it did, bugs included. The architect can’t overfit to code it has never seen.
- The coder can’t grade its own homework. The gate is the objective part, and the architect is the skeptical part. A frontier model with no feedback loop gives you confident code. The same model inside a strict loop gives you good code.
- The gate catches what review misses. Credo strict flagged a function the model had grown to cyclomatic complexity 35 in one session. The model then admitted, unprompted, that its own week of work wouldn’t pass its own gate. That’s the loop working.
- The architect’s context stays clean. It isn’t drowning in diffs, so it holds the big picture and catches scope creep and “helpful” features nobody asked for.
api.mdis a forcing function. If the contract can’t be written clearly enough for a blind reviewer to test against, the design isn’t finished.
The last layer: oracles nobody in the loop wrote. The gate and the architect still share one weakness: both are the same model family, and they can share the same misreading of a spec. So where it matters, the final judge is external to the project entirely (for example):
- Tincture (PDF generation): conformance isn’t claimed, it’s verified by veraPDF: PDF/A-2a at 153/153 rules, PDF/UA-1 at 106/106. The reports and the source documents are committed, so anyone can reproduce them.
- An OPC UA stack I’m working on: the existing Erlang implementation served as a characterization oracle for the codec port, where “wrong” meant “diverges from upstream,” though never treated as gospel. For the parts upstream never implemented, like Write, there’s no reference at all, so the answer is interop testing against independent implementations (asyncua, open62541, UAExpert).
That’s the real hierarchy: the compiler checks syntax, Credo and Dialyzer check shape, the tests check intent, and an external validator checks the truth. LLMs are good at satisfying whatever judge you give them. Give them one they can’t sweet-talk.
It’s slow as hell. Every retry is a cold mix run, I’m the courier and the watcher between the two instances, and every contract change means updating api.md first. But the failure mode shifts from “confidently wrong code” to “a gate fails, or we argue about the spec.” That’s the argument you actually want to have.
Why Elixir, specifically. This setup works in any language, but it works better here, and not only because we’re on the Elixir forum:
- Immutability and explicit data flow. A function’s behaviour is on the page: no hidden mutation, no action at a distance. The model can reason locally, which is exactly what a context window rewards.
- Contracts in the syntax. Pattern matching,
{:ok, _} | {:error, _}tuples,@spec, and guards mean the intent is written down, not implied. That’s also what makes a blindapi.mdpossible in the first place. - The feedback is fast, precise, and machine-readable. Compiler warnings, the new type checks, Credo, Dialyzer, and doctests all tell the model what is wrong and where, which is what an agent loop runs on.
- Stable language, one place for docs. No framework churn every six months, and HexDocs for everything. The model’s knowledge doesn’t rot as fast as it does in JS land.
- OTP limits the blast radius. When generated code is wrong at runtime, supervision contains it instead of taking the system down.
It isn’t just my impression. On Tencent’s AutoCodeBench (20 languages, execution-graded), Elixir got the highest completion rate across models, despite having a fraction of Python’s training data. The caveat is that those are self-contained functions, not systems with architecture. That gap is exactly what the gate and the architect are for.
It’s also not free. Less training data shows up as idiom leakage: the model writes acc ++ [x] in reduces and leaves semicolons around like it’s still in Python. Credo catches most of it, and that’s the point.
So no, LLMs aren’t only good for trivial stuff. Left unsupervised, they produce trivial-quality work at any scale. Put them inside a structure where every claim is checked by a compiler, a linter, a type checker, and a second instance that has never seen the code, and they do serious work.
The structure is the engineering. That’s where the skill went. It didn’t evaporate, it moved up a level: deciding the contract, the invariants, and the gate, and knowing when the model is bluffing. It’s the same hard part it always was.
One honest caveat. I’m not a 40-year-old developer, I’m an architect with a lot of years of hand-written code behind me from before any of this existed. That matters, because the architect role only works if you can smell a bluff, and I learned to smell it by writing the code myself for decades. How the next generation builds that instinct is, to me, the real open question in this thread.
If you like LEGO, you’ll get this: none of these bricks is clever on its own. The strength is in how they lock together.
Best,
Alex
volcov
Agentic coding also changes the way we see other people. Teams used to be sort of like parties of adventurers: a Git wizard, a Rust witch, a bard who is really into mechanical keyboards. There was plenty of room for skill expression, and the diversity of expertise was celebrated.
Now, an average team consists of a Claude operator, a Codex whisperer, and a guy with AI psychosis who insists on committing .md files. “This is John—you’ll want to see how he prompts,” said nobody ever.
You described exactly what I feel and what I mentioned in the previous message, hahaha!
derek-zhou
I have not seen many non-coders taking up coding via AI though. If AI made everyday Joe a coder, producing applications for himself, friends and family, like social media made everyone a reporter that friends and family follows, then I would have much higher respect on AI.
Zurga
In the Netherlands, this is a prediction a lot of people are betting on. Get as many people to produce code, use their non-coding background as a plus so they will want to solve problems in their domain.
Even in government, people are told to just try to vibecode their daily problems away, but don’t integrate with the existing software solutions. Totally unproductive; shadow IT has been a problem for a long time.
krasenyp
cmo
You could shell out the thousands of dollars to get the specs, though I’ve found several of them online, and another $1500 or so for the conformance test software and let it go wild on that.
jam
This sounds potentially interesting. So what’s the input you provide to the agents? Just the `api.md`? What about for the user-facing frontend?
Also wish you would have written it yourself. My eyes kind of glaze over with the claudese. 
Alex66
Yes, CTT is on the list.
Interop first because it’s free, and CTT when the stack is worth paying to fail.
Alex66
Fair point on the claudese I’m the gate: grumpy old IT guy, bad temper, I say no a lot.
Inputs: the coder sees the repo, the architect only sees api.md, gate output and reports. I write/approve api.md.
Frontend: honestly, I’ve used it on libraries, not UIs.