# AI-generated enhancements and examples for StaticCompiler.jl
**URL:** https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054
**Category:** Tooling
**Tags:** staticcompiler
**Created:** [November 23, 2025, 9:02am UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054 "2025-11-23T09:02:33Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@joelreymont](https://discourse.julialang.org/u/joelreymont)
#### Post date: [November 23, 2025, 9:02am UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/1 "2025-11-23T09:02:33Z")
I [updated StaticCompiler.jl](https://github.com/tshort/StaticCompiler.jl/pull/180) to provide extensive analysis and generate standalone binaries using Julia 1.12.
Some [mods to GPUCompiler.jl](https://github.com/JuliaGPU/GPUCompiler.jl/pull/743) were required.
[This blog post](https://joel.id/julia-my-love/) provides a detailed guide to using the above.
Please let me know what you think!
P.S. I didn’t write a single line of code but carefully shepherded the project to completion.
---
### Author:  [@gdalle](https://discourse.julialang.org/u/gdalle)
#### Post date: [November 23, 2025, 9:17am UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/2 "2025-11-23T09:17:53Z")
While experiments of this kind are definitely interesting, I can’t help but wonder: who will bother to review a PR with 22000 lines of code that you didn’t bother to write?
---
### Author:  [@joelreymont](https://discourse.julialang.org/u/joelreymont)
#### Post date: [November 23, 2025, 9:27am UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/3 "2025-11-23T09:27:51Z")
I have no idea, to be honest. The PR has been reviewed by AI, over and over again.
All tests pass, the code works and what’s important to me is that it provides a new capability that wasn’t there before I tackled the project.
Updating StaticCompiler.jl to Julia 1.12 doesn’t hurt either.
---
### Author:  [@joelreymont](https://discourse.julialang.org/u/joelreymont)
#### Post date: [November 23, 2025, 9:33am UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/4 "2025-11-23T09:33:11Z")
Having said that, I released this into the world and it’s my baby now!
I’m responsible for maintaining it and fixing anything that’s broken.
---
### Author:  [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)
#### Post date: [November 23, 2025, 9:35am UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/5 "2025-11-23T09:35:19Z")
> [@gdalle](#):
>
> who will bother to review a PR with 22000 lines of code
It’s not just about bothering. Very few have the capacity to review that much, regardless whether it’s written by humans or AI.
---
### Author:  [@joelreymont](https://discourse.julialang.org/u/joelreymont)
#### Post date: [November 23, 2025, 9:43am UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/6 "2025-11-23T09:43:54Z")
This is exactly the kind of discussion I wanted to foster!
What do you do in cases like this?
This PR would not make sense piecemeal, it either works as a whole or it doesn’t. I do have a bunch of design and rationale docs for it, maybe I should commit those or add them to the PR discussion.
---
### Author:  [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)
#### Post date: [November 23, 2025, 11:38am UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/7 "2025-11-23T11:38:53Z")
I can’t talk for anybody else but if I received a 22000 lines PR to one of my packages, I would right out refuse it because
1. I don’t have the time and mental capacity to review it. Or at least it would take too much time away from other things I’d rather do with my hobby hacking time.
2. I wouldn’t be able to maintain the package any more.
3. I wouldn’t lend my credibility to something I don’t know what it does or contains.
---
### Author:  [@joelreymont](https://discourse.julialang.org/u/joelreymont)
#### Post date: [November 23, 2025, 11:40am UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/8 "2025-11-23T11:40:47Z")
What do you suggest?
---
### Author:  [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)
#### Post date: [November 23, 2025, 11:43am UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/9 "2025-11-23T11:43:59Z")
Again, if it was one of my packages I’d suggest that they’d either extract manageable pieces for PRs or fork it and make a new package.
---
### Author:  [@gdalle](https://discourse.julialang.org/u/gdalle)
#### Post date: [November 23, 2025, 11:44am UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/10 "2025-11-23T11:44:08Z")
Is it just me or did you do the same thing in the OCaml ecosystem this week?
>
>
> I have several high-level criticisms of this PR and the overall contribution dyn…amics:
>
> \- There is an obvious problem with copyright if you reuse large amounts of people's code. The fact that the tool that produced the code attributes its copyright to a real human is a clear sign that something is an issue. (You might also wonder if that human agrees with being described as the author of code that you yourself introduce in the compiler.) At this point, merging the code in the compiler would be a legal liability.
>
> \- There hasn't been a design discussion for which approach should be chosen to integrate this feature. We would appreciate people discussing design before they dump 13K-lines PRs on us. In fact, it's a bit worse in this case: people that are expert on this topic and actively working on this feature ( @tmcgilchrist above ) have given you design advice and made recommendations for how to contribute in a way that they felt would be productive. As far as I can tell you did not take this feedback into account.
>
> \- This humongous amount of code is hard to review, and very lightly tested. (You are only testing that basic functionality works.) Inevitably the code will be full of problems, and \*we\* (the maintainers of the compiler) will have to pay the cost of fixing them. But maintaining large pieces of plausible-in-general-but-weird-in-the-details code is a large burden.
>
> \- As you might know, the OCaml compiler codebase suffers from a lack of people available to do code reviews and maintenance. See this topic for background: \[Maintenance bottlenecks in the compiler distribution\](https://discuss.ocaml.org/t/maintenance-bottlenecks-in-the-compiler-distribution/11045). Your approach of submitting very large relatively-low-effort PRs creates a very real risk of bringing the Pull-Request system to a halt, especially given that, in my personal experience, reviewing AI-written code is more taxing that reviewing human-written code.
> You may think that the answer to that is to also automate the review process, or (more plausibly) to lower our quality standards: we can accept PRs based on simple/lightweight tests (themselves AI-generated), and if users find issues we can quickly use automated tools to fix them, basically having our users perform the testing work that is missing. But so far we have not decided to work in this way (and this has very real costs for users of the compiler), so these potential solutions are not available.
>
> \- Finally, you seem to not give a thought about the fact that your contributions demand work of other people. The fact that you were able to generate large amount of code that passes test is interesting, but that's only 20% of the work, the other 80% are to get the feature discussed, reviewed and integrated, and this work will be paid by you \*and others\*. But you only focus on the initial writing phase and you personal success, over-communicate on this, and do not appear to realize that this has very real costs on others. For example, a few days ago you sent a PR that was a complete waste of our collective maintenance time (#14350 ; you had us review and discuss the implementation of a feature that was in fact already available in the tool), we wasted this time, and you never apologized.
>
> If your intent is to demonstrate that you personally know how to generate large amount of code that provide useful functionality and pass basic test, in a complex software project, then I think you have succeeded; congratulations. But if you are also hoping to demonstrate that they can be successfully integrated by upstream software projects, following the existing collaboration practices of the project, this is a complete failure. Maybe being a bit less tone-deaf and discussing things with people before you throw hundreds or thousands of lines at them would be a first step. But personally at this point I wish that you would do your "scientific experiments" (\[your words\](https://discuss.ocaml.org/t/artisanal-coding-is-dead-long-live-artisanal-coding/17487/5)) on another software project, and I have personally decided that I will not invest any more time looking at your PRs for the next six months.
---
### Author:  [@joelreymont](https://discourse.julialang.org/u/joelreymont)
#### Post date: [November 23, 2025, 11:46am UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/11 "2025-11-23T11:46:09Z")
I have. Same issue: DWARF debugging info cannot be added piecemeal. It either works or it doesn’t.
---
### Author:  [@joelreymont](https://discourse.julialang.org/u/joelreymont)
#### Post date: [November 23, 2025, 11:55am UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/12 "2025-11-23T11:55:24Z")
It works like this…
I have no idea if something can be done but I want to try it. So I try it and keep pushing it forward until it either succeeds and I have something working, or it doesn’t.
I managed to succeed in the case of OCaml DWARF debugging info and StaticCompiler.jl. Perhaps, the right question now is whether the latter work can be split into a more manageable set of PRs, now that it’s fully working and tested.
If this was my project I would have expected someone to
- Open an issue describing the problem
- Get buy-in from the maintainer
- Start submitting small PRs that move the project towards the goal
Here I just wanted to prove that something substantial, something that moves the goal posts, can be done with little manual coding. I believe I solved this problem. The next problem to tackle is how to properly integrate work like this into existing projects.
I have one more large experiment to run but that’s it. I’m now convinced that AI can write our next compiler!
---
### Author:  [@greatpet](https://discourse.julialang.org/u/greatpet)
#### Post date: [November 23, 2025, 12:11pm UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/13 "2025-11-23T12:11:19Z")
I’d love to use StaticCompiler with Julia 1.12.
Could you ask the LLMs to identify the minimal set of changes to make StaticCompiler work and skip any enhanced functionality and performance / style improvements? This would allow you to make a minimal PR for the sole purpose of making the package work again. Then ask the LLMs to write up an account about what API changes in Julia 1.12 broke StaticCompiler and why the changes fixed it. A summary could be inserted into your README.
I have no idea if these steps would convince the original maintainers to accept your PR, but it’ll certainly add credibility to your forked repository and I might want to try it out.
---
### Author:  [@joelreymont](https://discourse.julialang.org/u/joelreymont)
#### Post date: [November 23, 2025, 12:13pm UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/14 "2025-11-23T12:13:47Z")
I’ll see what I can do.
In the meantime, nothing prevents you from trying my forked repository with Julia 1.12 and running through the [examples in the blog post](https://joel.id/julia-my-love/).
All the examples in the blog post have been fully tested and their output should match the blog post.
---
### Author:  [@joelreymont](https://discourse.julialang.org/u/joelreymont)
#### Post date: [November 23, 2025, 12:17pm UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/15 "2025-11-23T12:17:30Z")
Indeed, it’s possible.
• Here’s the minimal-change set (functional-only) to get StaticCompiler working on
Julia 1.12, without the extra enhancements, plus the API-breakage notes you asked
for.
Minimal fixes only
- Core.Compiler API drift: in src/interpreter.jl, gate the rename to
InternalCodeCache and add versioned shims for get\_inference\_world, cache\_owner,
- GPUCompiler/LLVM API drift: in src/StaticCompiler.jl, adjust
GPUCompiler.emit\_asm call signature for 1.12 and guard LLVM.merge\_functions!
(removed in 1.12). Avoid any unrelated restructuring.
- Runtime symbol rename: Julia 1.12 exports ijl\_error instead of jl\_error; add a
tiny runtime\_stubs.c and link it so both symbols exist, or otherwise alias in
the Julia-side stubs. Keep this self-contained; no broader changes to codegen.
- Compat bounds: relax Project.toml to include Julia 1.12 and the GPUCompiler/
LLVM versions that work there. Don’t pull in new feature deps; just widen bounds
as needed.
- Optional but pragmatic: keep the “exit(0)” in the stub to tolerate the known
What broke in Julia 1.12 (for README summary)
- Core.Compiler internal API reshuffle: CodeCache → InternalCodeCache, new helpers
(get\_inference\_world, cache\_owner), and some debug hooks became conditional.
StaticCompiler’s interpreter hooks needed version-gated shims to keep inference
plumbing intact.
- GPUCompiler/LLVM surface changes: emit\_asm signature shifted (keywords →
positional), and LLVM.merge\_functions! was removed in the LLVM bundled with
Julia 1.12. Calls had to be updated/guarded to keep codegen and linking working.
- Runtime symbol rename: the exported error symbol moved from jl\_error to
ijl\_error, so binaries failed to link unless a compatibility symbol was
provided. Adding a small C stub (or equivalent alias) restores the missing
symbol.
- Opaque-pointer fallout: GPUCompiler 1.7.4 can emit IR that trips validation
under LLVM 15+ (used by Julia 1.12). The workaround is to surface the warning
but avoid failing the build/tests (e.g., via the stub’s exit behavior) until
GPUCompiler addresses it.
---
### Author:  [@abraemer](https://discourse.julialang.org/u/abraemer)
#### Post date: [November 23, 2025, 3:08pm UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/16 "2025-11-23T15:08:11Z")
> [@joelreymont](#):
>
> Here’s the minimal-change set (functional-only) to get StaticCompiler working on
> Julia 1.12, without the extra enhancements, plus the API-breakage notes you asked
> for.
Disclaimer: I am not a maintainer of any of the packages here.
I think if you open a PR for these changes only with a clear description of the changes and their reason, that would be quite welcome. In fact, it would be even easier if you made a PR for each of these points separately. The shorter and self-contained a PR is, the easier the review. In my experience, mixing together many changes does never make review.
After these fixes, a discussion can be held about the enhancements you propose, which look interesting to me.
In your PR, I also notice some things that are not about fixes or features but definitively need discussion with the maintainers and should not be jumbled up with the rest:
- Changes to CI
- Introduction of pre-commit hooks
- Formatting changes (e.g. [src/dllexport.jl](https://github.com/tshort/StaticCompiler.jl/pull/180/files#diff-9bbecdb53b6624174ed6318b6916222e8c186482e1eacbe71eb5f2870ef10646) received formatting changes only)
I recommend to separate these out as well as these things are very opinionated which further lowers the chances of your PR.
Edit: Also I am curious: How long did that PR take you roughly?
---
### Author:  [@joelreymont](https://discourse.julialang.org/u/joelreymont)
#### Post date: [November 23, 2025, 3:19pm UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/17 "2025-11-23T15:19:14Z")
The points here are just to upgrade to Julia 1.12.
The overall _set of points_ is larger but I get the idea.
The PR took me about a work week of monitoring AI and steering it in the right direction. It wasn’t a full work week as AI would go off and work on its own for anywhere from a few minutes to an hour or two. I was switching between different terminal windows with different projects during that time.
---
### Author:  [@joelreymont](https://discourse.julialang.org/u/joelreymont)
#### Post date: [November 23, 2025, 3:26pm UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/18 "2025-11-23T15:26:14Z")
> [@abraemer](#):
>
> Edit: Also I am curious: How long did that PR take you roughly?
I like to call it [cooking](https://x.com/joelreymont/status/1991114713434935552?s=20) as opposed to vibe-coding. It’s a slow process and I need to sample the dishes periodically. AI can indeed work for hours at a time as it’s doing with my non-LLVM Zig backend for macOS (there’s one for Intel).
---
### Author:  [@Mason](https://discourse.julialang.org/u/Mason)
#### Post date: [November 23, 2025, 3:27pm UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/19 "2025-11-23T15:27:44Z")
> [@abraemer](#):
>
> Disclaimer: I am not a maintainer of any of the packages here.
As a (lapsed) maintainer of StaticCompiler, I agree. There’s no way I’m spending the required time to review a monster PR like this which is mostly slop unless it’s broken down, structured more, and better motivated.
---
### Author:  [@joelreymont](https://discourse.julialang.org/u/joelreymont)
#### Post date: [November 23, 2025, 3:30pm UTC](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054/20 "2025-11-23T15:30:49Z")
What is slop to you?
Does the code look bad?
Are design decisions wrong?
Are you just anti-AI and strictly pro- [artisanal coding](https://joel.id/artisanal-coding-is-dead-long-live-artisanal-coding/)?
[Next page](https://discourse.julialang.org/t/ai-generated-enhancements-and-examples-for-staticcompiler-jl/134054.md?page=2)