Nothing can be best choice for everything for everybody all the time. For me that doesn’t take anything away from appreciating what it actually is very good for. And some specialization makes it easier to focus and shine in chosen fields. Python has it strengths and so do Elixir. As for AI stacks I regard both as orchestrators of Cuda/ Rust/ C++ stack of libraries.
I can assure you I do serious work with Claude, there is zero copy-paste, and I have yet to find any limits for my work.
So in response to your initial question, my personal experience is that Claude Opus 4.6 hardly makes any mistakes in Elixir now. I check most of the code and I very rarely need to intervene, even stylistically. I suspect the fact it is a small-ish language, immutable and functional plays a bit part. But I am even more sure that José’s idea of “local reasoning” (where you can easily reason about code because most of the stuff you need to care about is in the same file) is even more important (and side note: I think monkey patching, concerns, operator overloading and inheritance are the opposite of this).
We are one-shotting applications that would have taken us months before in Ruby/Python + React. My belief is that Elixir is hard to beat for the time-to-first-value case.
Where we need custom AI, we do fall back on Python. But 95% of our tech stack is Web+FrontEnd+Redis+Backend+API+DB.
At the possible risk of derailing the discussion, I’d like to talk about the use of other (supporting) languages in LLM-assisted development projects. FWIW, I’ve been using a form of spec-driven development, with:
So, for example, each script has its own companion spec file (e.g., foo.py has _spex/foo.fe.md) and most directories have _{index,readme}.md files.
In most Elixir projects, much of the documentation for files tends to be kept in the file itself (props to José et al for this!). I’m not sure how this would fit in with spec files and such, but I imagine I’ll find out (:-).
I’m quite willing to share. In fact, I’ve been working toward getting things in shape to push to GitHub. But finding an interesting but relatively small example could be a challenge. Hmmmm; here’s something from a small subproject.
To be clear, CC wrote most of the following Markdown, Python, and YAML text. I simply:
TBH, I didn’t even inspect the Python code. However, the plan is to have it (mechanically) inspected, reformatted, etc.
That said, here is the YAML header from the subproject spec file:
---
title: CC One-Off Execution Staging
path: WB/core/convs/meta/cc_one_offs.fe.md
role: convention
scope: conventions
status: active
---
Here is the start (~25%) of the spec’s Markdown content.
CC One-Off Execution Staging
Purpose
Define how CC should stage one-off generated execution artifacts so that runs are inspectable, auditable, and (perhaps) reusable.
Scope
This convention applies whenever CC generates and executes a non-trivial command, program, or patch artifact.
Examples include:
- interpreted scripts (Awk, Perl, Python, sed, shell, etc.)
- patch artifacts (
.diff) applied withpatch- compiled workflows (source + build/run commands)
- multi-step one-off command sequences
Required Behavior
CC should not execute non-trivial generated logic only as inline terminal payload (e.g., heredoc-only execution).
CC should also not create or edit non-trivial one-off artifacts via heredoc payloads (e.g.,
cat <<EOF ...for script content). Compose/edit the artifact using staged files and normal file-edit workflows, then execute from the staged artifact.Instead, CC should stage reusable artifacts under
Big/one_offs/YYYY-MM-DD/.
…
Here are the header and spec for one of the working scripts.
---
title: stage_one_off Spec
path: WB/tools/CC/one_offs/_spex/stage_one_off.spec.fe.md
role: specification
scope: maintenance
status: active
---
stage_one_off Spec
Purpose
Create a one-off script and paired spec under
Big/one_offs/YYYY-MM-DD/usingHHMMaanaming.Why
Avoids heredoc-only execution artifacts in terminal logs and preserves reusable code plus spec context.
Usage
script=WB/tools/CC/one_offs/stage_one_off.py python3 $script \ --title "scan for X" \ --motivation "Need one-time analysis for Y" \ --usage-notes "Adjust target path if needed" \ --expected-results "Generates report file" \ --evaluation "TBD after run"Inputs
--title(required): short readable purpose.--ext: extension for code artifact (pydefault).- Optional prose fields for motivation, usage notes, expected results,
and evaluation.Outputs
Big/one_offs/YYYY-MM-DD/HHMMaa.<ext>Big/one_offs/YYYY-MM-DD/HHMMaa.spec.fe.mdSide Effects
- Creates date bucket directory if missing.
- Marks
.pyand.shoutputs executable.Notes
HHMMaaslot selection avoids collisions in a single minute.- Intended replacement for ad hoc heredoc-only scripts.
I think we are going towards, or at least opening up for, specification driven development.
My current approach is caveman like in comparison. I use skills for sharpening know-how for matters at hand, and I use plan mode. I always add to the plan to save it to file and use needed skills. Apart from that I usually only use two files. A key_findings.md that captures project specific issues, what has been tried, breakthroughs and so on. And a file_locations.md to keep Claude updated with locations of various data, files, code, results etc. Claude sometimes loose track of that after compaction and various mayhem follows, so that is to avoid that. After it is done I get Claude to make a technical report, but that is for documentation and easier picking up again in the future.
I’d also mention that Claude has limited understanding of project scope. So say for instance you ssh into a more powerful computer to do some heavy processing there. When done you tell Claude to tidy up and remove any files no longer needed in the project… Just don’t do that.
I have the advantage (?) of being a retired geezer with a huge backlog of projects I could never do on my own. Also, none of what I’m doing has any privacy or proprietary concerns. So, this is sort of my model train set…
I haven’t gotten into playing with modes or models, but the CC and CG defaults work pretty well for my purposes. I use CG for idea exploration, high-level discussions, and research. I then use CC for spec hardening, implementation and testing, etc.
One experiment I’ve tried, with great success, is to have CC and CG sessions look over each other’s work. For example, have CG generate a spec, have CC critique it, then pass the analysis back to CG. Alternatively, have two CC sessions critique each other’s work. Not surprisingly, the sessions agree on most things, but the interchange can uncover corner cases, missed possibilities, etc.
However, this has required a lot of copying and pasting on my part, so I’m working on setting up better communication paths. The constraints (roughly) are that:
However, the local file system and public repositories (eg, GitHub) seem to allow some interesting workarounds:
Skills look very tasty, but I haven’t tried using (let alone creating) any yet. One thing I really like about the emerging ecosystem is the possibility of exchanging skills, techniques, tooling, etc. If these can be captured in an LLM-agnostic manner, developers might be able to leverage each other’s work in very powerful ways. For example, there could be:
Last year I thought I’d set up some sophisticated setup, and I gave it decent shot for about two months, but apart from the formal specifications I’m not sure that is for me. These days I focus on an exact prompt for planning in the beginning, and after that it is chat for the most part. That works surprisingly well.
I’ve also tried having two Claudes argue with each other with me as some hapless middleman. It was actually fairly effective as for some reason they came up with different angles and possible solutions.
I’ve found that skills really help with difficult topics, avoiding small errors, sticking to idiomatic ways and being aware of and able to implement non-obvious or rare solutions that exists out there.
Yes, the long term memory remains an issue. I use a key_findings file, and that works until it gets too big. Claude will typically butcher important bits if asked to shorten it so there I still do some manual editing. I hope this is more of a temporary issue though. I expect larger context available in the future.
Last Friday I needed to make two small custom neural models for different tasks. I told Claude I wanted it done in Rust, what data was available for training and to optimize the model capacity accordingly, the input data types and structure, what I wanted as output, and the success criteria. Then I asked to get three different architectures able to solve the issue, presented with training done, and setup ready to test on the held off data. A few hours later they were done and ready, and after testing I had several options that surpassed the requirements. Some years ago I would have been locked to some Python libraries for days to just make one.
I think this is utterly amazing, and I find myself doing things and testing options which l would never even have considered before. And we are likely still just in the very feebly beginnings.
The ability to be able to share and build up major skill sets is really interesting. Another side of this is that language itself matters less. If I want something with a web UI and some heavy processing the Claude plan will typically suggest Phoenix Liveview for UI, Rust for the heavy processing, and Rustler. (And it usually works as planned). If I had made skills and shown preferences for Go and Python earlier it would probably made that work instead.
Once in a while Claude makes some outbursts. I’ve been informed that ‘I’m very frustrating’. (Probably true if you try to be lazy I wont let you). And my favorite when I had the bright idea to put Claude in charge of setting up an old Jetson Orin. After about two hours there was this unprompted: “Dependency hell!” (So true! That is why Claude got the job!)
This turned into a bit of rambling brain droppings, but well, I’ve typed it so I’m pressing the button anyway!
It’s available since yesterday and I started using it. Sadly it indeed deteriorates as you get closer to compaction – but it holds surprisingly well actually, which I like. Limitations are visible but are less than I thought.
Any recommendations? I am trying to curate a collection.
100% the same for me. Not everything needs to be super spelled out; there are layers. I believe I am doing fairly well there and getting full Pareto usefulness out of my prompting. I periodically stop and devise a closed feedback loop process for Claude and order it to remember it, put it inside CLAUDE.md and have it re-read it before each task. Just a two days old practice and it works much better than I expected.
They have made more context available? I will have to check on that. Sounds good!
I’ve made many skills, and a skill to make skill just to be a bit meta about it. (Then I discovered Anthrohic actually made an official skill making skill).
If I’m about to do something within a new topic/ language/ area I make a new skill first. Then find a few hassles here and there, collect them in the key_findings, and afterwards ask Claude to update the skill. Iterate until nice.
I try to make skills with sub skills. That was only the routing core with the most crucial info is loaded into context, but Claude knows where to look for more specialized sub skills when needed. As some skill are in tens of thousands of lines by now that is the only way it could work.
For a new topic I would start making clear what this skill will be used for and it’s coverage. Then make local texts or references available, and specify some key topics and to look for things like patterns, anti-patterns and common failures and issues. I then ask Claude to go off internetting to learn more about these topics and to research each one systematically and properly so they reach production level. And I most expressively ban short cuts, skipping ahead or doing things later. And I check on on that. Claude is lazy, and lies through his teeth to avoid work, so without the skills will end up with random gaps.
Once that research is done there is the question if Claude discovered more topics that should naturally be included in a skill for the given use and coverage. And most often there will be some. So those get researched similarly. Then in the end Claude will take all this research and combine into a skill structure according to the size needed. Small skills one file, big skills a central skill with many sub skills. Claude likes actionable rules so to the extent sensible I get those added.
For code Github is great. I point Claude at some major libraries and repositories and says that is the way to do it basically.
Skills will have to interface and combine so I make sure there is a bit of overlap. One can then cover the bare basics of the other without having to load an entire adjacent skill for that.
I also do more like reference skills for SVGs, Mermaid, specific libraries, and research topics for more specific tasks.