dogweather

Here's how I'm coding Elixir with AI. Results are mixed, mostly positive. How about you?

First, the downsides. I periodically fire the AI.

^^ This was earlier today in Cursor AI, working with “Claude 4 Sonnet / Thinking”.

I bounce back and forth between Claude Code (w/ Claude 4 Opus) and Cursor AI (w/ Claude 4 Sonnet Thinking and ChatGPT o3). I find that each tool has its own ‘secret sauce’ of patterns for AI assistance that come through, even when using the same model with each. (I.e., w/ Claude 4 Opus in Cursor, it acts differently than Claude Code.)

My Claude.md File

This is what Claude Code writes and then reads. Here’s how I edited the start:

CLAUDE.md

This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

Engineering Principles we Follow

Security first. If we detect a security issue like mismatching user_id and customer_id, fail loudly.
Never, ever write demo code. Instead, we write a test that fails for a new feature or function. Then we implement the feature or function to production quality.
Fail fast
Use compile-time checking as much as possible.
No silent failures (So, e.g., don’t do this plan = Map.get(plan_map, frequency, "starter") —
instead fail loudly with an ‘unknown frequency’ error.
Make illegal states unrepresentable.
Lazyness is a virtue.
Every feature idea must overcome the YAGNI argument.
TDD

Definition of Done

A set of todos is only complete when ALL of the following conditions are met:

All tests pass (mix test)
Dialyzer passes (mix dialyzer)
Credo passes (mix credo)

^^ That all works…most of the time. In Cursor, I have similar configuration in “User Rules”.

Now, my favorite hack that helps pair programming with AI: in every project, I create a /docs directory in the root. I have the AI assistants create documentation there, plans, and to do lists. Then I set it up as an Obsidian Vault. That’s pretty lightweight - Obsidian is basically a fancy markdown reader and editor. So in a nutshell, I “collaborate” with the AI this way.

I asked it to document what it learned — both for future AI sessions to refer back to, and for me. And then, of course, it’s very easy for me to edit and search:

I still have frequent very frustrating episodes: Claude Code deciding that a certain number of Credo warnings is acceptable. Or, the test failures are ok because it’s “demo code”. (What?? Who told you to write “demo code”?)

And I frequently need to steer the assistants in the right direction. The feeling I get is like working with a junior/mid-level programmer—but who never gets defensive and is happy to rewrite their code when asked. I do often have to do massive refactors and cleanups. But the AI did get me started, and got some kind of working code shipped.

So even though Elixir is more niche than Javascript or Python, I’m getting value from AI. When we’re really “clicking” well, I come back to my desk and see Claude Code’s latest message to me:

30 comments

#chatgpt #claude

68 2683 30

2025-07-28 07:55:24 UTC

Most Liked

ErikNaslund

I’m just a lightweight Cursor user building webapps. I rarely ask the AI to code Elixir for me. I often find myself unhappy with the result, or it simply takes more time to steer the AI into the right direction than it takes to write the code myself. Adding the Tidewave MCP server helped improve the workflow with the AI agent quite a bit, but I still find it lacking.

The hallucinations and stubbornness of the AI is a real problem for me. I have had repeated “arguments” trying to convince it that a function it hallucinated doesn’t exist…just to have it go “Oh you’re right, I’m so sorry…here’s a version that is guaranteed to work: produces similar output with hallucinated functions still there”

However, I do get real value out of Cursor when it comes to doing the stuff I don’t know that well - especially CSS. An oversimplified example might be me selecting a block of HTML, ctrl+k → “center this horizontally”, and Cursor spits out the correct Tailwind CSS to center the content (which varies based on context).

Post #9

gtcode

Claude doesn’t really know how to write OTP code by default. And I’m not a senior OTP dev by any means, not even a junior one yet. But, I have studied OTP, and with my limited background, it’s obvious that Claude really prefers (as of Sonnet and Opus 4) to write crappy OTP, when unrestricted.

Without explicit direction, Claude will sneak in brittle tests with concurrency issues, unsupervised processes, overuse of potentially runaway atoms, and all sorts of other beginner-level gotchas.

I’m working on enhancing credo checks to help enforce OTP compliance. You want to spawn? Is it supervised? Robust specification for OTP compliance are a must, for every context. The issues I’ve faced are also related to not having explicit definitions of the OTP design in-context. Going back to having the design worked out in advance, with the supervision tree worked out, clearly specified in the prompts, has been working better for me in testing. Going to try this approach again on the next go-around for my OTP app. Vibe coding for these scenarios isn’t really feasible at this time, except to prototype, sketch, or learn (how not to do things).

As for prompting, the best success I’ve had is to have Claude break down a complicated set of technical documents into self-contained prompts that, for each, assume no previous context, and include all required reading. Even then, I have to review the prompt file to ensure that all of the refs are self contained. Then it’s just a matter of ensuring all dialyzer/warnings/failures/credo issues are resolved before moving onto the next prompt. But, still, Claude will take shortcuts from time to time, so a skilled human reviewer ensuring Claude stays on track is still worth a lot.

Once the prompt is finished, I either /clear or just restart Claude Code from scratch for the next prompt.

Short prompts are better (in the sense of fewer TODO’s per prompt, all else equal). It might seem to take longer because now you’re recontextualizing on relatively smaller changes, but the shorter the context, the better. Less drift.

Another thought I had is that long sets of rules to follow don’t work consistently. Simply saying, “here are my OTP rules, build robust OTP” has mixed results. “Don’t use sleep to solve concurrency issues” works, until it drifts (happens faster than you’d expect, due to fighting the grain on Claude’s preferences). On my next go, the design will be worked out in advance with tight audit/checks for every prompt to ensure compliance. Just because all of your tests pass doesn’t mean the code is good. Just reiterating this main point: generalized guidelines at length will fall apart.

Post #4