# Is Julia still as relevant in the age of AI agents?

**URL:** <https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889>\
**Category:** General Usage\
**Created:** [October 7, 2026, 3:51pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889 "2026-10-07T15:51:04Z")\
**Posts on this page:** 2\
**Page:** 2

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 7, 2026, 10:07pm UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/21 "2026-10-07T22:07:41Z")

</div>

> [@austin-putz](#):
>
> today I can easily implement C++ with Rcpp in my R package (only 200 lines so far but more coming). I cannot exactly pinpoint why I should come back to Julia for anything.

I would think you could implement those 200 lines also in Julia with (or without!) AI. And you can already call Julia from R; and with this package it will likely get easier as it already has for Python to call Julia:

> [@\[ANN\] JuliaLibWrapping.jl: bringing Julia libraries to C and Python users](https://discourse.julialang.org/t/ann-julialibwrapping-jl-bringing-julia-libraries-to-c-and-python-users/139150/1):
>
> R and Matlab are likely to follow soon.

> <https://github.com/JuliaInterop/JuliaLibWrapping.jl/issues/19>
>
> Tracking issue for the two unimplemented language backends.
> 
> Matlab is the close…r of the two: \`loadlibrary\` consumes the \`.h\` header that \`CTarget\` already generates, so a Matlab backend is largely a thin \`.m\` façade generator — and would itself exercise the façade machinery (#13).
> 
> R (via \`.Call\` / Rcpp) is more involved.

R is likely next, and AI has been helping greatly recently in the Julia ecosystem as with the MATLAB support (and at JuliaLang and elsewhere), here with 45 commits across 30 files:

> <https://github.com/JuliaInterop/JuliaLibWrapping.jl/pull/90>
>
> A MATLAB backend, from the same \`@api\` declarations as the Python one. Second
> o…f three; the last runs real MATLAB in CI.
> 
> One \`.m\` façade per declaration in a \`+package\` directory, plus a C gateway
> that turns \`mxArray\`s into the carriers and releases what Julia allocated.
> Emitting needs no MATLAB. Every fixture's gateway is compiled in the suite with
> \`-Wall -Wextra -Werror\`, and the emitted \`.m\` and \`.c\` are pinned by goldens.
> 
> \`\`\`julia
> standard\_build(@\_\_DIR\_\_; libname = "boundary", matlab\_package = "boundary")
> \`\`\`
> 
> \## An open question
> 
> Array arguments are borrowed, so a function that writes to one changes every
> variable sharing that buffer. \`duplicate\_arguments = true\` copies instead, but
> it is per build: one mutating function taxes every other.
> 
> | approach | granularity | cost |
> |---|---|---|
> | target flag (this PR) | whole library | one mutating function taxes the rest |
> | \`@api … mutates=(a,)\` | per argument | changes the annotation layer |
> | \`MatlabTarget(…; duplicate=\["f"\])\` | per function | names repeated in the build script |
> | always duplicate | none | gives up the no-copy property |
> 
> Putting it in \`@api\` seem the right place as mutability is a fact about the function, not MATLAB — but I left it out for the same reason we dropped the target field: no consumer, no case in hand. What do you think?
> 
> @timholy Maybe I need to clarify. MATLAB makes copies of everything and has value semantics almost everywhere. To avoid copying too much by default this wrapper borrows, but could have unintended side-effects. So, there is an option to make copies instead, that makes it more MATLAB-ish. But it is an all or nothing approach. The question is, should we make it more granular? if so, how granular?
> 
> \*\*Not in this PR:\*\* running MATLAB. The compile check verifies types, not
> semantics, so \`mustBeVector(\[\])\`, the integer coercion order and finding the
> library at run time want a real gate. That is the next PR.
> 
> Apologies for the scope creep :sweat\_smile: 
> 
> 🤖 Generated with \[Claude Code\](https://claude.com/claude-code)

I still think Julia is the better language for, and if you’re language agnostic, you might be able to move everything to Julia. AI can probably already do it as has been shown in other cases (in one recent case of large codebase translation by AI for C++ to Julia resulted in 6x speedup):

> [@Julia faster than C++ on a converted large simulation model](https://discourse.julialang.org/t/julia-faster-than-c-on-a-converted-large-simulation-model/139787/13):
>
> It’s about 12k LOC (comments, libraries code and doc removed)  
> I am using Claude Opus 5.5 .. I wasn’t able to squeeze C++ performance the way it could have been possible. I am sure the LLM could do it, but I am not sure I could then read the code. My claim is that doing that in Julia (by myself or by the LLM) is much easier while keeping the code high-level, compact, and readable by a non-expert. At least, this has been my experience.

Now it’s a question of which is the best language.

Depending on exactly what you’re doing this might apply:

> **[The Best AI Models Fail at Physics: Coding Harnesses are to Blame - Blog |...](https://juliahub.com/blog/why-the-best-ai-models-fail-at-physics)**
>
> How the Dyad Harness Turns Silent AI Model Failure into Scientific Rigor

> **Same AI model, different results:** Dyad Agent scored 0.899 versus Claude Code’s 0.533 across four physics problems, at similar cost and runtime.

---

<div class="post-metadata">

**Author:** ![tim.holy](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tim.holy/32/52_2.png) [@tim.holy](https://discourse.julialang.org/u/tim.holy)\
**Post date:** [October 8, 2026, 12:29am UTC](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889/22 "2026-10-08T00:29:12Z")

</div>

My suspicion is that in the fullness of time, it will go the other way: AI agents will make (and perhaps already are making) Julia more relevant, not less. There are three reasons:

- they remove one of the main barriers to _not_ trying Julia
- they allow Julia developers to fill gaps in the ecosystem quickly
- I _think_ Julia offers agents a more efficient development process (if you use MCP)

The last point is the most subtle, and here I’m not talking about token-efficiency (though I won’t deny that either). Suppose you’re working on a mixed R/Rcpp code base, and the agent notices that something isn’t quite right: an algorithm isn’t converging like it should, there are weird values being spit back, whatever. Suppose that the problem arises in the C++ code. The number of layers that the agent has to work through is substantially bigger than if the same code is written in Julia: in Julia, the agent can essentially copy the inputs to the call that gives the problem, and then is immediately debugging at the site of trouble. In the mixed workflow, the data will come from the wrapper language and has to be passed through to the low-level language. That erects more barriers and makes it harder to introspect the code. I’m not saying the agent can’t do that—clearly it can—but by the time you have it isolated, my agent writing in Julia is already submitting a PR with the fix.

[Previous page](https://discourse.julialang.org/t/is-julia-still-as-relevant-in-the-age-of-ai-agents/139889.md?page=1)