FPC releases and A.I

[440bx]

Hello,

A.I was recently able to write a full fledged C compiler - no small feat.

Here is a summarized description of what A.I did:

In early 2026, AI was successfully used to code a functional C compiler. Anthropic’s Opus 4.6 model, utilizing 16 autonomous AI agents working on a shared repository, developed a 100,000-line Rust-based compiler in two weeks. This compiler was demonstrated compiling the Linux 6.9 kernel.

Key Details of the AI Compiler Project

The Approach: Researchers tasked 16 Claude Opus 4.6 agents with creating a C compiler from scratch without human intervention, resulting in over 2,000 code sessions.

Capabilities: The resulting compiler was able to compile a bootable Linux kernel on x86, ARM, and RISC-V architectures and run the game Doom.

Limitations: While impressive, critics pointed out that the AI relied on techniques that could not handle the 16-bit bootloader, requiring a fallback to existing tools like GCC for certain aspects, notes Medium.

Cost: The effort cost roughly $20,000 in API fees.

This demonstration highlights a significant leap in autonomous AI software development, moving from generating small snippets of code to creating complex, multi-component systems.

Writing a complete C compiler in 2 weeks is definitely better than the great majority of human compiler writers can do.

The point of this thread is: if A.I can be used to develop a C compiler, it sounds like with a little guidance it should be able to prepare an FPC release, like, for instance, FPC v3.2.4 

The reason for the delay is reportedly the lack of manpower.  It looks like A.I could manage doing the work involved in releasing the next version of FPC.  If producing a C compiler comes at a cost of $20,000, the cost of an FPC release should be a very small fraction of that which I believe the community as a whole would likely be willing to occasionally shoulder.    Built into the above is the presumption that the amount of work involved in an FPC release is significantly less than what's required to produce a C compiler and also that it is a lot simpler.

Comments welcome.

[C0m3b4ck]

Yeah, it developed a full fledged kernel. Congrats for it I guess. However, the context growing with every release will massively increase - the AI will either lose context or become more and more expensive.

[valdir.marcos]

Hello,

A.I was recently able to write a full fledged C compiler - no small feat.

Here is a summarized description of what A.I did:

In early 2026, AI was successfully used to code a functional C compiler. Anthropic’s Opus 4.6 model, utilizing 16 autonomous AI agents working on a shared repository, developed a 100,000-line Rust-based compiler in two weeks. This compiler was demonstrated compiling the Linux 6.9 kernel.

Key Details of the AI Compiler Project

The Approach: Researchers tasked 16 Claude Opus 4.6 agents with creating a C compiler from scratch without human intervention, resulting in over 2,000 code sessions.

Capabilities: The resulting compiler was able to compile a bootable Linux kernel on x86, ARM, and RISC-V architectures and run the game Doom.

Limitations: While impressive, critics pointed out that the AI relied on techniques that could not handle the 16-bit bootloader, requiring a fallback to existing tools like GCC for certain aspects, notes Medium.

Cost: The effort cost roughly $20,000 in API fees.

This demonstration highlights a significant leap in autonomous AI software development, moving from generating small snippets of code to creating complex, multi-component systems.

Writing a complete C compiler in 2 weeks is definitely better than the great majority of human compiler writers can do.

The point of this thread is: if A.I can be used to develop a C compiler, it sounds like with a little guidance it should be able to prepare an FPC release, like, for instance, FPC v3.2.4 

The reason for the delay is reportedly the lack of manpower.  It looks like A.I could manage doing the work involved in releasing the next version of FPC.  If producing a C compiler comes at a cost of $20,000, the cost of an FPC release should be a very small fraction of that which I believe the community as a whole would likely be willing to occasionally shoulder.    Built into the above is the presumption that the amount of work involved in an FPC release is significantly less than what's required to produce a C compiler and also that it is a lot simpler.

Comments welcome.

"We tasked Opus 4.6 using agent teams to build a C Compiler, and then (mostly) walked away. Here's what it taught us about the future of autonomous software development."
https://www.anthropic.com/engineering/building-c-compiler

- Enabling long-running Claudes
- Running Claude in parallel
- Lessons from programming with Claude agent teams
- Stress testing the limits of agent teams
- Looking forward



We tasked Opus 4.6 using agent teams to build a C Compiler, and then (mostly) walked away. Here's what it taught us about the future of autonomous software development.

Written by Nicholas Carlini, a researcher on our Safeguards team.


I've been experimenting with a new approach to supervising language models that we’re calling "agent teams."

With agent teams, multiple Claude instances work in parallel on a shared codebase without active human intervention. This approach dramatically expands the scope of what's achievable with LLM agents.

To stress test it, I tasked 16 agents with writing a Rust-based C compiler, from scratch, capable of compiling the Linux kernel. 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 compiler is an interesting artifact on its own, but I focus here on what I learned about designing harnesses for long-running autonomous agent teams: how to write tests that keep agents on track without human oversight, how to structure work so multiple agents can make progress in parallel, and where this approach hits its ceiling.

Enabling long-running Claudes
Existing agent scaffolds like Claude Code require an operator to be online and available to work jointly. If you ask for a solution to a long and complex problem, the model may solve part of it, but eventually it will stop and wait for continued input—a question, a status update, or a request for clarification.

To elicit sustained, autonomous progress, I built a harness that sticks Claude in a simple loop (if you’ve seen Ralph-loop, this should look familiar). When it finishes one task, it immediately picks up the next. (Run this in a container, not your actual machine).

#!/bin/bash

while true; do
    COMMIT=$(git rev-parse --short=6 HEAD)
    LOGFILE="agent_logs/agent_${COMMIT}.log"

    claude --dangerously-skip-permissions \
           -p "$(cat AGENT_PROMPT.md)" \
           --model claude-opus-X-Y &> "$LOGFILE"
done          [Copy]

In the agent prompt, I tell Claude what problem to solve and ask it to approach the problem by breaking it into small pieces, tracking what it’s working on, figuring out what to work on next, and to effectively keep going until it’s perfect. (On this last point, Claude has no choice. The loop runs forever—although in one instance, I did see Claude pkill -9 bash on accident, thus killing itself and ending the loop. Whoops!).


Running Claude in parallel
Running multiple instances in parallel can address two weaknesses of a single-agent harness:

One Claude Code session can only do one thing at a time. Especially as the scope of a project expands, debugging multiple issues in parallel is far more efficient.
Running multiple Claude agents allows for specialization. While a few agents are tasked to solve the actual problem at hand, other specialized agents can be invoked to (for example) maintain documentation, keep an eye on code quality, or solve specialized sub-tasks.
My implementation of parallel Claude is bare-bones. A new bare git repo is created, and for each agent, a Docker container is spun up with the repo mounted to /upstream. Each agent clones a local copy to /workspace, and when it's done, pushes from its own local container to upstream.

To prevent two agents from trying to solve the same problem at the same time, the harness uses a simple synchronization algorithm:

Claude takes a "lock" on a task by writing a text file to current_tasks/ (e.g., one agent might lock current_tasks/parse_if_statement.txt, while another locks current_tasks/codegen_function_definition.txt). If two agents try to claim the same task, git's synchronization forces the second agent to pick a different one.
Claude works on the task, then pulls from upstream, merges changes from other agents, pushes its changes, and removes the lock. Merge conflicts are frequent, but Claude is smart enough to figure that out.
The infinite agent-generation-loop spawns a new Claude Code session in a fresh container, and the cycle repeats.
This is a very early research prototype. I haven’t yet implemented any other method for communication between agents, nor do I enforce any process for managing high-level goals. I don’t use an orchestration agent.

Instead, I leave it up to each Claude agent to decide how to act. In most cases, Claude picks up the “next most obvious” problem. When stuck on a bug, Claude will often maintain a running doc of failed approaches and remaining tasks. In the git repository of the project, you can read through the history and watch it take out locks on various tasks.

Lessons from programming with Claude agent teams
The scaffolding runs Claude in a loop, but that loop is only useful if Claude can tell how to make progress. Most of my effort went into designing the environment around Claude—the tests, the environment, the feedback—so that it could orient itself without me. These are the approaches I’ve found most helpful when orchestrating multiple Claude instances.

Write extremely high-quality tests
Claude will work autonomously to solve whatever problem I give it. So it’s important that the task verifier is nearly perfect, otherwise Claude will solve the wrong problem. Improving the testing harness required finding high-quality compiler test suites, writing verifiers and build scripts for open-source software packages, and watching for mistakes Claude was making, then designing new tests as I identified those failure modes.

For example, near the end of the project, Claude started to frequently break existing functionality each time it implemented a new feature. To address this, I built a continuous integration pipeline and implemented stricter enforcement that allowed Claude to better test its work so that new commits can’t break existing code.

Put yourself in Claude’s shoes
I had to constantly remind myself that I was writing this test harness for Claude and not for myself, which meant rethinking many of my assumptions about how tests should communicate results.

For example, each agent is dropped into a fresh container with no context and will spend significant time orienting itself, especially on large projects. Before we even reach the tests, to help Claude help itself, I included instructions to maintain extensive READMEs and progress files that should be updated frequently with the current status.

I also kept in mind the fact that language models have inherent limitations, which, in this case, needed to be designed around. These include:

Context window pollution: The test harness should not print thousands of useless bytes. At most, it should print a few lines of output and log all important information to a file so Claude can find it when needed. Logfiles should be easy to process automatically: if there are errors, Claude should write ERROR and put the reason on the same line so grep will find it. It helps to pre-compute aggregate summary statistics so Claude doesn't have to recompute them.
Time blindness: Claude can't tell time and, left alone, will happily spend hours running tests instead of making progress. The harness prints incremental progress infrequently (to avoid polluting context) and includes a default --fast option that runs a 1% or 10% random sample. This subsample is deterministic per-agent but random across VMs, so Claude still covers all files but each agent can perfectly identify regressions.
Make parallelism easy
When there are many distinct failing tests, parallelization is trivial: each agent picks a different failing test to work on. After the test suite reached a 99% pass rate, each agent worked on getting a different small open-source project (e.g., SQlite, Redis, libjpeg, MQuickJS, Lua) to compile.

But when agents started to compile the Linux kernel, they got stuck. Unlike a test suite with hundreds of independent tests, compiling the Linux kernel is one giant task. Every agent would hit the same bug, fix that bug, and then overwrite each other's changes. Having 16 agents running didn't help because each was stuck solving the same task.

The fix was to use GCC as an online known-good compiler oracle to compare against. I wrote a new test harness that randomly compiled most of the kernel using GCC, and only the remaining files with Claude's C Compiler. If the kernel worked, then the problem wasn’t in Claude’s subset of the files. If it broke, then it could further refine by re-compiling some of these files with GCC. This let each agent work in parallel, fixing different bugs in different files, until Claude's compiler could eventually compile all files. (After this worked, it was still necessary to apply delta debugging techniques to find pairs of files that failed together but worked independently.)

Multiple agent roles
Parallelism also enables specialization. LLM-written code frequently re-implements existing functionality, so I tasked one agent with coalescing any duplicate code it found. I put another in charge of improving the performance of the compiler itself, and a third I made responsible for outputting efficient compiled code. I asked another agent to critique the design of the project from the perspective of a Rust developer, and make structural changes to the project to improve the overall code quality, and another to work on documentation.

Stress testing the limits of agent teams
This project was designed as a capability benchmark. I am interested in stress-testing the limits of what LLMs can just barely achieve today in order to help us prepare for what models will reliably achieve in the future.

I’ve been using the C Compiler project as a benchmark across the entire Claude 4 model series. As I did with prior projects, I started by drafting what I wanted: a from-scratch optimizing compiler with no dependencies, GCC-compatible, able to compile the Linux kernel, and designed to support multiple backends. While I specified some aspects of the design (e.g., that it should have an SSA IR to enable multiple optimization passes) I did not go into any detail on how to do so.

Previous Opus 4 models were barely capable of producing a functional compiler. Opus 4.5 was the first to cross a threshold that allowed it to produce a functional compiler which could pass large test suites, but it was still incapable of compiling any real large projects. My goal with Opus 4.6 was to again test the limits.

Evaluation
Over nearly 2,000 Claude Code sessions across two weeks, Opus 4.6 consumed 2 billion input tokens and generated 140 million output tokens, a total cost just under $20,000. Compared to even the most expensive Claude Max plans, this was an extremely expensive project. But that total is a fraction of what it would cost me to produce this myself—let alone an entire team.

This was a clean-room implementation (Claude did not have internet access at any point during its development); it depends only on the Rust standard library. The 100,000-line compiler can build a bootable Linux 6.9 on x86, ARM, and RISC-V. It can also compile QEMU, FFmpeg, SQlite, postgres, redis, and has a 99% pass rate on most compiler test suites including the GCC torture test suite. It also passes the developer's ultimate litmus test: it can compile and run Doom.

The compiler, however, is not without limitations. These include:

It lacks the 16-bit x86 compiler that is necessary to boot Linux out of real mode. For this, it calls out to GCC (the x86_32 and x86_64 compilers are its own).
It does not have its own assembler and linker; these are the very last bits that Claude started automating and are still somewhat buggy. The demo video was produced with a GCC assembler and linker.
The compiler successfully builds many projects, but not all. It's not yet a drop-in replacement for a real compiler.
The generated code is not very efficient. Even with all optimizations enabled, it outputs less efficient code than GCC with all optimizations disabled.
The Rust code quality is reasonable, but is nowhere near the quality of what an expert Rust programmer might produce.
The resulting compiler has nearly reached the limits of Opus’s abilities. I tried (hard!) to fix several of the above limitations but wasn’t fully successful. New features and bugfixes frequently broke existing functionality.

As one particularly challenging example, Opus was unable to implement a 16-bit x86 code generator needed to boot into 16-bit real mode. While the compiler can output correct 16-bit x86 via the 66/67 opcode prefixes, the resulting compiled output is over 60kb, far exceeding the 32k code limit enforced by Linux. Instead, Claude simply cheats here and calls out to GCC for this phase (This is only the case for x86. For ARM or RISC-V, Claude’s compiler can compile completely by itself.)

The source code for the compiler is available. Download it, read through the code, and try it on your favorite C projects. I’ve consistently found the best way to understand what language models can do is to push them to their limits, and then study where they start to break down. Over the coming days, I’ll continue having Claude push new changes if you want to follow along with Claude’s continued attempts at addressing these limitations.

Looking forward
Each generation of language models opens up new ways of working with them. Early models were useful for tab-completion in IDEs. Before long, models could complete a function body from its docstring. The launch of Claude Code brought agents into the mainstream and enabled developers to pair-program with Claude. But each of these products operates under the assumption that a user defines a task, an LLM runs for a few seconds or minutes and returns an answer, and then the user provides a follow-up.

Agent teams show the possibility of implementing entire, complex projects autonomously. This allows us, as users of these tools, to become more ambitious with our goals.

We are still early, and fully autonomous development comes with real risks. When a human sits with Claude during development, they can ensure consistent quality and catch errors in real time. For autonomous systems, it is easy to see tests pass and assume the job is done, when this is rarely the case. I used to work in penetration testing, exploiting vulnerabilities in products produced by large companies, and the thought of programmers deploying software they’ve never personally verified is a real concern.

So, while this experiment excites me, it also leaves me feeling uneasy. Building this compiler has been some of the most fun I’ve had recently, but I did not expect this to be anywhere near possible so early in 2026. The rapid progress in both language models and the scaffolds we use to interact with them opens the door to writing an enormous amount of new code. I expect the positive applications to outweigh the negative, but we’re entering a new world which will require new strategies to navigate safely.

Acknowledgements
Special thanks to Josef Bacik, Edwin Chen, Bernardo Meurer Costa, Jake Eaton, Dan Kelley, Felix Klock, Jannet Park, Steve Weis, and many other people across Anthropic for their assistance and contributions.

Without a doubt, $20,000 in 2 weeks to build a Rust-based C compiler capable of compiling the Linux Kernel 6.9 is fast and cheap compared to human work.

The great danger here is the risk of lawsuits for copyright infringement.

Building C compilers is a well-worn topic, extensively documented in books and university courses for decades.

Building Object Pascal compilers has an infinitely smaller scope. And here begins the danger.

AI needs training to function. And much of this training is based on private knowledge [often obtained in dubious ways, if not blatantly illegally] subject to legal action for copyright infringement. Even if this knowledge comes from open source, there are licenses that need to be respected before this knowledge can be used in other software.

Be aware of the risk: there is a lot of material about Delphi and other lesser-known flavors of Pascal, both closed-source and open-source, scattered around.

[440bx]

I don't know exactly what an appropriate comment is to your observations because, I don't believe that a release of FPC involves writing the compiler, that's already done.

I'm not sure what is specifically missing that is preventing FPC v3.2.4 from being released but, it has to be very little compared to writing the full FPC compiler and, in addition to that, the A.I thing would do whatever has to be done as directed by the developer(s) involved in the release.  IOW, since the knowledge would be obtained from the FPC team, it is unlikely that "tainted" knowledge would make it into the release (the human supervision alone should prevent that.)

I know the above is rather imprecise but, it is a result of the lack of details about what is preventing v3.2.4 from being released.  The "lack of manpower" reason offered so far, lacks detail.

At any rate, it seems A.I, with the proper direction should be capable of "lending a hand" for likely not much money.

[rasberryrabbit]

Recently, I used Claude to create patches for several bug reports.

With Claude, I couldn't always get a clear answer right away, so I had to create prompts several more times for the content to be written.
Claude is definitely a good solution that can provide an answer within a week to a problem that had no solution for more than a month.

I also tried Gemini, but Gemini doesn't seem to be good for code writing, it mainly answers questions based on principles.
Gemini is also a very good AI for checking the contents of the code.

[440bx]

I recently tried Claude to port some simple C programs to Pascal. Initially it was a bit of a slow going but, the thing learns which makes subsequent ports easier and less time consuming.

I don't really know everything that is involved in making an FPC release but, it am under the impression that A.I, after some training, could likely do at least some of the work. 

It would be really nice to hear from those who are responsible for creating the FPC release, whether or not A.I could be used to make the process less humanly time consuming.  Who knows maybe we could get FPC v3.2.4 before 2027 (I hope that's not too optimistic.)

[marcov]

I don't really know everything that is involved in making an FPC release but, it am under the impression that A.I, after some training, could likely do at least some of the work. 

It would be really nice to hear from those who are responsible for creating the FPC release, whether or not A.I could be used to make the process less humanly time consuming.  Who knows maybe we could get FPC v3.2.4 before 2027 (I hope that's not too optimistic.)

The current release manager is not often on the forum nowadays, but I don't expect AI to be a good fit. Simply because the task is not easy to describe, contrary to a C compiler when you can just point to specs and other compilers as example.   

Anyway, maybe focus on automating/assisting separate steps rather than the umbrella term? The first step is making sure all necessary bugs are fixed, and revisions are merged. The bugtracker contents are downloadable, and so is the list of revisions to merge. https://www.stack.nl/~marcov/mergelogs32/

.

[440bx]

but I don't expect AI to be a good fit. Simply because the task is not easy to describe, contrary to a C compiler when you can just point to specs and other compilers as example.   

I don't really know if it would be a good fit or not but, it seems like the thing could be trained to help.  That said, I could easily be wrong since I have never gone through the process of getting an FPC release out the door.  I appreciate your viewpoint.

[JuhaManninen]

Simply because the task is not easy to describe, ...

I have understood that some MacOS related commits should be merged and then FPC 3.2.4 is ready for release.
If the commits are known, it should be easy to explain. "Merge commits xxx, yyy, zzz and solve merge conflicts."
Are the commits known? I assume somebody knows.

[runewalsh]

An AI trained on tons of C compilers managed to create a C compiler? Wow, that boggles the mind.

[440bx]

An AI trained on tons of C compilers managed to create a C compiler? Wow, that boggles the mind.

Can you do what that A.I thing did ?... it does not boggle my mind but, it is a very respectable accomplishment that only a very small percentage of humans manage to do.

[PascalDragon]

Simply because the task is not easy to describe, ...

I have understood that some MacOS related commits should be merged and then FPC 3.2.4 is ready for release.
If the commits are known, it should be easy to explain. "Merge commits xxx, yyy, zzz and solve merge conflicts."
Are the commits known? I assume somebody knows.

The thing is that fpk, who is the release manager for 3.2.4 had said that the fixes branch is frozen (around 1 1/2 years ago) and hadn't yet said that it is free for merges again. Which is why marcov and I have refrained from doing further merges including the fixes for macOS, which yes, are known.

The reason for the delay is reportedly the lack of manpower.  It looks like A.I could manage doing the work involved in releasing the next version of FPC.  If producing a C compiler comes at a cost of $20,000, the cost of an FPC release should be a very small fraction of that which I believe the community as a whole would likely be willing to occasionally shoulder.    Built into the above is the presumption that the amount of work involved in an FPC release is significantly less than what's required to produce a C compiler and also that it is a lot simpler.

The issues we are talking about are issues one doesn't need to use AI for. That's just unnecessary overkill.
For deciding which commits are necessary to be merged a human is required and will always be required, because as soon as we bow to that AI non-sense part of the core devs (including me) will leave the project. I have absolutely no love for AI assisted coding and I don't want to be bother by it in a project I do for enjoyment.
What we instead need is better automation for building, like Jenkins which we indirectly have through alb42 (who mainly tests the Amiga-like platforms, but also some other platforms). If we can get that to automatically generate full releases instead of simply snapshots then that already makes things easier for us.
The issues we have can be solved using normal, deterministic ways, one doesn't need to resort to stochastic parrots.

[440bx]

I have absolutely no love for AI assisted coding and I don't want to be bother by it in a project I do for enjoyment.

I have no love for A.I either and if I didn't enjoy programming I wouldn't do it.  It just seems that A.I might be a helpful tool and, it looks like we can use all the help we can get.  Maybe it could be used to do some of the grunt work which very few programmers, if any, enjoy doing.

What we instead need is better automation for building, like Jenkins which we indirectly have through alb42 (who mainly tests the Amiga-like platforms, but also some other platforms). If we can get that to automatically generate full releases instead of simply snapshots then that already makes things easier for us.

That makes sense.  Any automation is very likely to be a plus.

The issues we have can be solved using normal, deterministic ways, one doesn't need to resort to stochastic parrots.

I've had an equally low opinion of A.I but, when I see that it can be used to produced a full fledged C compiler, I have to acknowledge that it is more capable than I thought and might, under the right circumstances, be a useful tool.

Bottom line: I don't know if A.I can be useful in producing an FPC release simply because of the fact that I've never been involved in the production of an FPC release therefore I do not have the knowledge to fully evaluate the task.  When it comes to A.I, my experience with it is very limited but, it does seem like it could be a useful tool in some cases.

[silvestre]

Dear friends,

I believe it's positive to have an open mind. The use of AI in programming is the greatest advancement of this technology, and undoubtedly, in the hands of a programmer who understands the architecture well—acting like a conductor—it can make all the difference in project delivery.

It's interesting to read how OpenAI has decided to redirect its Sora department, which dedicated significant processing power to video creation, to channel its efforts toward models similar to Claude Code, geared toward the enterprise sector and, specifically, programming.

In particular, the Claude Opus 4.6 models have marked a complete turning point in the use of AI. They can manage projects with multiple units, create forms, compile autonomously, analyze and correct errors, understand complex contexts, and deliver what's requested with sometimes astonishing accuracy.

When a project lacks human developers and there are pending tasks such as automation, bug fixing, or testing, this technology undoubtedly saves hundreds of hours of work. The world is changing rapidly, and we must take advantage of its positive aspects.

In short, in my opinion, integrating AI with complex models, using context files and appropriate rules under the supervision of a good software architect, can generate advantages.

[JuhaManninen]

The thing is that fpk, who is the release manager for 3.2.4 had said that the fixes branch is frozen (around 1 1/2 years ago) and hadn't yet said that it is free for merges again.

Which clearly shows he is not a suitable person for a release manager role at this moment.
For whatever reason that is. Busy, tired, fed up, pissed off... Makes no difference.

The issues we have can be solved using normal, deterministic ways, one doesn't need to resort to stochastic parrots.

Then please use normal, deterministic ways to release FPC 3.2.4.
The suggestion to use AI was just a desperate attempt to get it out somehow because allegedly you guys don't have time and manpower for it. Somehow FPC developers have time and energy to write mails in lists and write posts here and to commit code in FPC trunk.
The manpower thing seems to be an excuse.
You emphasize that developers do what they want and nobody can force you to release FPC 3.2.4. Yes OK, I truly hope somebody will fork FPC project and starts to maintain it with a better attitude.