# Idiomatic Julia code in AI generated code
**URL:** https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183
**Category:** General Usage
**Tags:** ai
**Created:** [September 3, 2026, 8:12am UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183 "2026-09-03T08:12:37Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@yakir12](https://discourse.julialang.org/u/yakir12)
#### Post date: [September 3, 2026, 8:12am UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/1 "2026-09-03T08:12:37Z")
I find AI coding tools such as Claude Code incredibly useful, especially when combined with tools like Kaimon.jl. However, I also find that the code they generate is often surprisingly non-idiomatic Julia.
Beyond aesthetics, this has practical consequences. The generated code frequently misses opportunities for classic Julia strengths such as multiple dispatch, leveraging existing package functionality, and introducing concrete types or type information early in the design. Instead, it often produces code that feels more like a direct translation of patterns from Python, JavaScript, or other ecosystems.
How do you deal with this limitation?
Has anyone had success steering these models toward more idiomatic Julia? For example, can we point them at curated examples of “blessed” Julia code, style guides, or particularly well-designed packages that they can learn from and emulate?
---
### Author:  [@jakobnissen](https://discourse.julialang.org/u/jakobnissen)
#### Post date: [September 3, 2026, 9:33am UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/2 "2026-09-03T09:33:17Z")
In my experience with agentic coding, this is hard to do something about. Ingesting a comprehensive style guide big enough to rid them of Python-isms would take up a good chunk of the context window, which is probably better spent elsewhere.
I recommend two approaches to this:
- Put a brief list of instructions addressing only the most annoying tendencies in your AGENTS.md
- Have the agent work in small chunks of work and review each chunk. This way, you can steer it better.
One option which I haven’t tried yet, but maybe could work, is to have a review-julia skill, which has this more comprehensive Julia design guide. You can then point a cheaper agent (e.g. gpt-5.6 luna) to review the bigger agent’s work with that skill.
Edit: FWIW, I do a bunch of agentic coding in Python as well and I also find that agents coding Python have some bad design patterns I repeatedly need to rid my code of. An example that I constantly struggle with is that they prefer to defer checks to where data is used instead of where it’s loaded. E.g. they do
```python
def process_element(d: dict[str, int], key: str)
value = d.get(key)
process_1(value)
process_2(value)
if value is None:
raise TypeError("Should not be None")
...
def process_1(value: Union[Int, None]):
if value is None:
raise TypeError("Should not be None")
...
def process_2(value: Union[Int, None]):
if value is None:
raise TypeError("Should not be None")
...
```
---
### Author:  [@yakir12](https://discourse.julialang.org/u/yakir12)
#### Post date: [September 3, 2026, 9:44am UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/3 "2026-09-03T09:44:27Z")
I’ve read that the idea of separating these models into two, one human language trained, and one computer language trained (with a third to translate between the two), often yields worse results than the monolithic human language one. But for this specific aspect, it does sound like a version of Claude that is tuned more towards (for instance) Julia would be ideal… As unlikely as that sounds…
It would be fantastic if people could share their (currently) most successful Julia-idiomatic related agent-instructions and/or Julia review skill.
---
### Author:  [@dcelisgarza](https://discourse.julialang.org/u/dcelisgarza)
#### Post date: [September 3, 2026, 1:36pm UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/4 "2026-09-03T13:36:34Z")
Aside from asking agents to do some API documentation, help with some macros, and standardising instructions and prompts. I basically hand wrote all of PortfolioOptimisers.jl until Opus 4.8 came out.
I think i did a pretty good job creating an agentic workflow bit by bit that now works incredibly well. I’m adding a ton of features, fixing bugs, improving the user experience, documenting, etc. Here is a step by step guide of what I would do if i were starting from scratch. I had to go back and redo some stuff that in hindsight could have been avoided. However, you should periodically audit your workflow to make improvements as models change or as you get a better idea of what you want your code to do and look like.
It’s important to note that it’s best if you start with a clearly defined skeleton of your standards and code practices. You can use an AI to work with you to refine them. This should be ongoing as the codebase evolves.
1. Install [GitHub - mattpocock/skills: Skills for Real Engineers. Straight from my .agents directory. · GitHub](https://github.com/mattpocock/skills) and [plugins/cursor-team-kit/skills/thermo-nuclear-code-quality-review/SKILL.md at main · cursor/plugins · GitHub](https://github.com/cursor/plugins/blob/main/cursor-team-kit/skills/thermo-nuclear-code-quality-review/SKILL.md) `/grill-with-docs` is great for single or 2-session fixes. `/wayfinder` is extremely OP at large changes, but also works great for smaller stuff.
2. Run `/grill-with-docs` in the bare repo. This will ask you a ton of questions to establish a common lexicon and grammar. This is the [CONTEXT.md](https://github.com/dcelisgarza/PortfolioOptimisers.jl/blob/main/CONTEXT.md) file, which is going to be the first place an agent looks before asking you questions. I think i might break this up into a map where each section contains only its relevant information as it’s getting long.
3. Set up a [STANDARDS.md](https://github.com/dcelisgarza/PortfolioOptimisers.jl/blob/main/STANDARDS.md). To start with you might want to plop your standards directly, but ideally you want it to be an index of where each standard is defined. This should give the agent instructions on how you want things done. Mine has the files it must run tests on, pointers to how i want docstrings written, code subtyped, tests written, etc.
4. Set up your [CLAUDE/AGENTS.md](https://github.com/dcelisgarza/PortfolioOptimisers.jl/blob/main/CLAUDE.md). This establishes general etiquette and points the agents to the places they need to check out for contextual answers and instructions so they can make high quality additions. It also bounds the etiquette, i had claude ping people without my asking and i find that distasteful.
5. Matt’s skills (step 1) come with an `/improve-codebase-architecture` skill. Use it as the basis for creating `/improve-codebase-security` (security issues), `/improve-codebase-maintainability` (easier maintenance), `/improve-codebase-ergonomics` (for user experience improvements). You can also use it to modify `/thermo-nuclear-code-quality-review` so it generates `html` in the same style, or merge the skills into one (i haven’t tried this yet). You should probably do this after all the above files have been created so they know to use them in case they need.
6. Set up a code quality CI ratchet. I made one that uses CodeComplexity.jl, another that uses JET.jl, another one that sweeps files and additions to ensure their docs are up to date and their code is correct, another that tracks coverage, another that tracks file size. I will probably turn it into a [package](https://github.com/dcelisgarza/PortfolioOptimisers.jl/tree/main/code_health), as it’s been really useful for improving code quality in general.
7. Use the best model you have available for any grilling or research session if the task is complex. Opus 5 works great, but Fable 5.1 makes fewer bone-headed moves/asks fewer dumb questions. It can be very noticeable if the task is complex and/or touches many files.
8. When making a PR run `/improve-codebase-architecture` and `/thermo-nuclear-code-quality-review` (or the merged skill). Fix any issues you agree with, tell it not to relitigate things you need for your codebase or deliberate choices you’ve made. Repeat until it starts finding the same things over and over that maybe you think are worth doing but not just now. Move on to `/improve-codebase-security`, `/improve-codebase-maintenance`, and finally `/improve-codebase-ergonomics`. Each time, run each skill and fix issues until it keeps finding the same things. I used to run them in parallel, but i’ve found that they often find the same issues, and by fixing the one higher in the hierarchy, you end up fixing the ones below it. You should use good models for these. The best you have available if you can, but Opus 5 is really good here as well. You can use lesser models for the implementation. I typically use Opus 5 for everything unless the features or fixes are very complex, sonnet if the fix is easy and well described. You can repeat the entire loop ad infinitum, but that can get boring, burn through tokens, and give diminishing returns. If you are running up to your reset and haven’t hit your token limits, it never hurts to run these on your entire codebase. They are genuinely awesome at improving it, provided you have the set up i’ve described.
---
### Author:  [@j\_u](https://discourse.julialang.org/u/j_u)
#### Post date: [September 3, 2026, 2:51pm UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/5 "2026-09-03T14:51:25Z")
> [@yakir12](#):
>
> I’ve read that the idea of separating these models into two, one human language trained, and one computer language trained (with a third to translate between the two), often yields worse results than the monolithic human language one. But for this specific aspect, it does sound like a version of Claude that is tuned more towards (for instance) Julia would be ideal… As unlikely as that sounds…
It seems that recent discussions on this forum indicate growing interest in two directions for Julia native language models. The first is pretraining a model from scratch in Julia, as explored in the recent and fairly recent threads by @mantzaris. The second is fine-tuning / post training existing models. I believe, this approach has become even more attractive with the new generation of releases. In particular, Qwen3.8-27B and especially Qwen3.8 Flash Next appear to represent a huge step forward in both reliability and efficiency, although I’d maintain that @Palli’s estimates regarding the feasibility of running genuinely useful workloads on 2GB of VRAM or on a mobile device remain somewhat optimistic. Also Qwen models for various reasons look a bit risky, thus, I sustain again that focusing on i.e. Trinity seems to be probably much safer approach as of now and a great opportunity to practice and to set up an infrastructure. As for your proposals, if I understand them correctly: separation, orchestration, and cross-validation, they resemble a bit what I outlined a few weeks or months ago in my posts here about NeuroREPL. It has turned out that related ideas have already been validated in practice. Examples include the Sakana AI models and the self-improving coding harness behind Prime Agent.
---
### Author:  [@ParadaCarleton](https://discourse.julialang.org/u/ParadaCarleton)
#### Post date: [September 3, 2026, 9:40pm UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/6 "2026-09-03T21:40:08Z")
> [@jakobnissen](#):
>
> In my experience with agentic coding, this is hard to do something about. Ingesting a comprehensive style guide big enough to rid them of Python-isms would take up a good chunk of the context window, which is probably better spent elsewhere.
The better tool for this is hooks, which let you reject and/or rewrite edits with a regex (e.g. I have one prohibiting concrete types on function arguments to stop it from overtyping).
---
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [September 3, 2026, 9:54pm UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/7 "2026-09-03T21:54:01Z")
Note “idiomatic” below, not in the paper, but what it enabled for Fortran porting:
> **[Persistent Recursive Worlds Enable Autonomous Software Evolution](https://arxiv.org/abs/2608.10450)**
>
> Complex software systems develop over timescales that exceed the lifespan of any individual coding agent. Most agentic software systems preserve continuity through persistent sessions, memories, managers or shared context. We introduce EvoX Genesis...
> .. Genesis used DeepSeek V4 Flash to build a Rust-based C compiler with about 250k tracked lines; the run lasted over 120 hours, archived over 1,000 agent episodes and incurred only US$44 in model-token charges. The compiler passed the complete c-testsuite and most LLVM and Csmith tests. In a separate compiler world generated with GLM 5.2, development continued after repeated agent replacement while retaining full test performance. Genesis also reimplemented 13 MESA modules with over 100k Fortran lines as a Rust workspace with nearly 90k Rust lines; across six numerical workloads, it achieved median speedups of 1.55–6.87x. These results show that long-horizon software development can be organized around a persistent project rather than a persistent agent. Project Website: [this https URL](https://genesis.evox.group/)
Costing **US$10.64** :
> **[GitHub - EMI-Group/genesis-demo-mesa-rs: Mesa Rust Port 100% written by Genesis.](https://github.com/EMI-Group/genesis-demo-mesa-rs)**
>
> Mesa Rust Port 100% written by Genesis.
> rewrite of the core numerical/physics stack of [MESA](https://docs.mesastar.org/) — the original ~462K-LOC Fortran 90/2008 stellar astrophysics suite. This workspace ports the `const → utils → math → mtx → interp_1d → interp_2d → num → chem → rates → neu → net → eos → kap` module chain into 13 idiomatic Rust crates, mirroring the original module APIs to preserve backwards compatibility, and ships a benchmark harness that proves the port is **faster than the original Fortran on every workload** (medians of driver-internal timings, gfortran `-O3 -march=native` vs Rust release `lto=fat, codegen-units=1`).
>
> ## Highlights
>
> - **~67K LOC of pure Rust library code** (129 files, 13 crates), `#![forbid(unsafe_code)]` everywhere — zero `unsafe`, zero FFI.
> - **~1050 tests green** (`cargo test --workspace` → 1052 passed / 0 failed / 18 ignored), including golden tests ported from the original Fortran `test_output` files (bit-exact or ~1e-9).
> - **No LAPACK/BLAS FFI**..
Rest is older in chronological order:
So we are down 99% in cost since 6 months ago, then cost 444x making a C compiler (and now 2.8x quicker to make “120 hours”/5 days vs 2 weeks):
> **[Building a C compiler with a team of parallel Claudes](https://www.anthropic.com/engineering/building-c-compiler)**
>
> Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.
> Over nearly 2,000 Claude Code sessions and $20,000 in API costs, the agent team produced a 100,000-line compiler that can build Linux 6.9 on x86, ARM, and RISC-V.
The key seems to be 1000/16 = 62x more agents, though only part of the reason, the paper is brand new to me.
> **[Blitzy's C Compiler: 230K Lines, Zero Human Code](https://blitzy.com/blog/hello-world-the-blitzy-c-compiler-has-arrived)**
>
> Blitzy built a C11 compiler from scratch in 4.5 days: 229,983 lines of Rust, 2,271 passing tests, and the Linux kernel boots on QEMU.
> **[How it works — evocompiler](https://evocompiler.com/how-it-works)**
>
> A compiler tuned to your project, not to the average of all programs: what evolve searches, what it measures, where the measuring happens, and what a result means.
---
### Author:  [@ParadaCarleton](https://discourse.julialang.org/u/ParadaCarleton)
#### Post date: [September 3, 2026, 10:18pm UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/8 "2026-09-03T22:18:51Z")
> [@yakir12](#):
>
> Beyond aesthetics, this has practical consequences. The generated code frequently misses opportunities for classic Julia strengths such as multiple dispatch, leveraging existing package functionality, and introducing concrete types or type information early in the design. Instead, it often produces code that feels more like a direct translation of patterns from Python, JavaScript, or other ecosystems.
This has been a bit U-shaped; c. 2023-early 2025 Julia was catching up to these languages, but since then it’s fallen behind. This is mostly because Julia lacks the static checking used for informed speculative decoding and RLVF (Reinforcement Learning from Verifiable Feedback) in other programming languages. (Unfortunately, JET.jl doesn’t count: it’s slow, not sound, still doesn’t have traits or interfaces, and isn’t included by default so nobody knows about it and the LLMs often don’t think of including it in their tests.)
The other big issue is the long compile and startup times and big runtime, which make the iteration/training process painfully slow. This means you can’t make up for it in sheer quantity of data the way you can in Python (which has both a larger pretraining corpus and a faster feedback loop). Julia is kind of stuck in a “worst of both worlds” situation.
I flagged this back in 2023 when the AI companies started broadcasting their plan going forward was to use RLVF, but it lines up pretty closely with the most common complaints people have had about Julia since it came out in 2014.
---
### Author:  [@adienes](https://discourse.julialang.org/u/adienes)
#### Post date: [September 3, 2026, 10:26pm UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/9 "2026-09-03T22:26:02Z")
> [@ParadaCarleton](#):
>
> This is mostly because Julia lacks the static checking used for informed speculative decoding and RLVF (Reinforcement Learning from Verifiable Feedback) in other programming languages.
that sentence is a complete non-sequitur; neither of those techniques you’re name-dropping require nor have anything to do with static typing.
---
### Author:  [@j\_u](https://discourse.julialang.org/u/j_u)
#### Post date: [September 4, 2026, 12:11am UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/10 "2026-09-04T00:11:31Z")
> [@ParadaCarleton](#):
>
> This is mostly because Julia lacks the static checking used for informed speculative decoding and RLVF (Reinforcement Learning from Verifiable Feedback) in other programming languages.
No, with all due respect, I don’t think that’s it, its just that Julia is very if not (to say) extremely, academic.
---
### Author:  [@yakir12](https://discourse.julialang.org/u/yakir12)
#### Post date: [September 4, 2026, 12:33pm UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/11 "2026-09-04T12:33:49Z")
I appreciate @dcelisgarza’s post since it’s an actionable venue to solving some of the issues mentioned here. Thank you!
It also highlights the lack of a unified framework to achieve Julia-AI-nirvana. While every project has its own unique needs, a future where we settle on a agent-dev-env (CLAUDE.md, AGENTS.md, skills, CONTEXT.md, STANDARDS.md, etc) that results in idiomatic Julia code sounds promising. Or perhaps we’ll get there via some of the other venues mentioned in this post.
---
### Author:  [@j\_u](https://discourse.julialang.org/u/j_u)
#### Post date: [September 4, 2026, 1:43pm UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/12 "2026-09-04T13:43:49Z")
Yes, the workflow provided by @dcelisgarza looks very good. I’m planning to test something similar with Prime Agent this weekend. Also that new mention by @Palli, the one about EvoX Genesis, looks interesting. And thanks for starting this thread. The synthetic generation of idiomatic Julia code appears to be of significant importance those days.
---
### Author:  [@ParadaCarleton](https://discourse.julialang.org/u/ParadaCarleton)
#### Post date: [September 7, 2026, 3:15am UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/13 "2026-09-07T03:15:50Z")
> [@adienes](#):
>
> that sentence is a complete non-sequitur; neither of those techniques you’re name-dropping require nor have anything to do with static typing.
1. Please see [here](https://arxiv.org/abs/2504.09246) and [here](https://arxiv.org/abs/2412.10418). You can speed up performance by having a draft model propose outputs (speculative decoding); eliminating proposals that would fail to compile improves the draft model’s quality and thus overall performance.
2. Writing code that errors, fails tests, or doesn’t compile is generally scored negatively by RLVR graders, since it’s a very easy-to-measure reward signal.
…that said, I’m kinda remembering why I stopped hanging around these parts, so have a good day I suppose.
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [September 7, 2026, 10:04pm UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/14 "2026-09-07T22:04:35Z")
It’s still not apparent (to me at least) how those linked papers are relevant to static checkers, or type checkers in particular, we would be familiar with as human coders.
The first one about type-constrained code generation explicitly stated “Note that commonly used grammar and type checkers can not be used as a completion engine for constrained decoding” for the simple reason that they only work on a “complete program.” The repo for their TypeScript(-subset) completion engine [also affirms](https://github.com/eth-sri/type-constrained-code-generation#faq) that compilers only work on completed programs and adds that LSPs or similar incremental productivity tools are not designed for or reliable enough to filter arbitrary partial programs, so type constrainers have to be implemented separately. Type constrainers don’t appear to be common practice either; a paper on constrainer misalignment this year didn’t mention other prior projects and showed the TypeScript completion engine tending to underperform unconstrained decoding on a couple benchmarks ([https://doi.org/10.48550/arXiv.2606.21619](https://doi.org/10.48550/arXiv.2606.21619)).
As an aside, the paper doesn’t actually assert static _typing_, as adienes mentioned, is a requirement for type constrainers. Tracking and inferring types can work for dynamically typed languages as well, though a program with extensively checked types overlaps a lot with an atypical statically typed language like TypeScript.
The second one is about generating natural language responses and does not mention types in the sense of programming. The constraints are lexical and semantic in a broad sense, and the associated reward functions must also work on incomplete responses to judge the speculative lookaheads. This can be applied to constrained code generation, still independent of _bona fide_ type checkers.
---
### Author:  [@yakir12](https://discourse.julialang.org/u/yakir12)
#### Post date: [September 10, 2026, 12:56pm UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/15 "2026-09-10T12:56:02Z")
This has been incredibly helpful, thank you. I still have a lot to learn, but the Matt Pocock approach has already made a big difference. What you’ve built in PortfolioOptimisers.jl is seriously impressive, although it’s probably a bit more advanced than what I’m ready to tackle just yet.
That said, I still think getting coding agents to write _truly idiomatic code_ is one of the harder problems. Even so, your suggestions have definitely improved the quality of the code they generate.
---
### Author:  [@dcelisgarza](https://discourse.julialang.org/u/dcelisgarza)
#### Post date: [September 10, 2026, 2:51pm UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/16 "2026-09-10T14:51:09Z")
I’m glad it could help. And thank you for the kind words.
I’ve found that with this system it’s quite easy to at least get claude to write good Julia code that’s tested against reference implementations and/or papers. Although i’ve caught it doing heinous shit like allocating an entire array only to add one to the first item of a different one.
However, the code health module and actions should help find those in a self-healing kind of way. I’ll eventually split them up into their own package and register them as actions as they’ve really helped a ton.
---
### Author:  [@yakir12](https://discourse.julialang.org/u/yakir12)
#### Post date: [September 10, 2026, 2:58pm UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/17 "2026-09-10T14:58:40Z")
Please do…
---
### Author:  [@dcelisgarza](https://discourse.julialang.org/u/dcelisgarza)
#### Post date: [September 10, 2026, 3:13pm UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/18 "2026-09-10T15:13:40Z")
Yes, i need to use it some more to iron out some kinks but i will.
---
### Author:  [@j\_u](https://discourse.julialang.org/u/j_u)
#### Post date: [September 10, 2026, 6:27pm UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/19 "2026-09-10T18:27:37Z")
> [@yakir12](#):
>
> That said, I still think getting coding agents to write _truly idiomatic code_ is one of the harder problems.
For this to be competitive, I’m afraid we have to train and potentially even orchestrate the models. The harness can constrain and to some extent verify, but it can’t add intuition the base model doesn’t have.
> [@ParadaCarleton](#):
>
> c. 2023-early 2025 Julia was catching up to these languages, but since then it’s fallen behind
Yeah, for various reasons it looks like we missed it, but I’m still optimistic. BTW, all this lamenting on the forum and the bad press from the moderators about LLMs don’t help either.
> [@ParadaCarleton](#):
>
> The other big issue is the long compile and startup times and big runtime, which make the iteration/training process painfully slow.
Come on, it’s not that bad. I guess, some of it can be sped up with workers, and some parts could even be written in C. It can definitely be optimized to some degree. And everyone knows Julia flies in production.
---
### Author:  [@joa-quim](https://discourse.julialang.org/u/joa-quim)
#### Post date: [September 10, 2026, 6:30pm UTC](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183/20 "2026-09-10T18:30:52Z")
> [@j\_u](#):
>
> bad press from the moderators about LLMs don’t help either.
Insisting in repeating this doesn’t make it true either.
[Next page](https://discourse.julialang.org/t/idiomatic-julia-code-in-ai-generated-code/139183.md?page=2)