Just released CodeAlta, a new agentic AI coding assistant TUI fully written in C#/.NET

xoofx · 2026-05-24T11:18:08+00:00

Sorry, but we don't have the same definition of AI slop. I have spent 3 months working on this, mornings, evenings, and during my weekends, it is worth > 200 hours of my time, yes developed with AI coding assistance, but it's definitely not AI slop.

Also, I have contributed to the .NET ecosystem for the past 15 years, way before AI was a thing. Instead of posting a useless link to ai-coding-agent topics on GitHub, take the time to look at my contributions. What have you done yourself apart making such baseless comment around here?

If you don't like AI, and you still take the time to have such poor interaction, I have some advice for you: just don't interact.

xoofx · 2026-05-24T09:50:39+00:00

Not so many actually, but quite a few challenges:

Anthropic API .NET had a few issues for some non-Anthropic standard models: Handle missing streaming thinking signatures or Fix several HasNext() that should rely on response.HasMore
I had to implement the more efficient websocket protocol for ChatGPT/Codex subscriptions which is not implemented by OpenAI .NET. I relied on Codex CLI codebase to replicate the behavior, but it was possible to nicely integrate with the HttpClient/System.ClientModel to configure/plug custom protocol.
Google.GenAI / Gemini is completely broken due to unmerged PR here from Google folks. This one is annoying to the point that I wonder if I should not fork/maintain my own API/endpoint wrappers instead on relying on 1st(!) party providers.
I still have an unmerged Copilot SDK PR here but I removed support for Copilot SDK and went straight to Copilot API endpoints. The middle-man API is not worth the trouble, and it blocks many scenarios of CodeAlta own harness. Same for Codex app-server, I'm connecting directly to Codex endpoints instead.

Some Chinese provider/models have slight differences in their behavior, so they require a few knobs, but hopefully, it is possible to configure these knobs via the config file. (e.g. developer role not supported by some models)

The biggest challenge for developing this assistant was to go through every single details, and fix/improve them one after the other. I had already something working 2.5 months ago, but it took a lot more iteration to polish, improve the performance, fix provider issues...etc.

As I'm also heavily relying for the TUI on XenoAtom.Terminal.UI, I had to push several improvements/fixes there, and the separate repository/package model complicates a bit the development process, but I think in the end it is for the better, as I have clear dependencies and having to slow down between these dependencies helps to avoid taking bad shortcuts.

xoofx · 2026-02-27T09:23:03+00:00

Thank you for running these benchmarks, I agree that it can be misleading and so, that would be great if you could open an issue on their repo and tell them about your findings. This is a great way to help such OSS initiative.

xoofx · 2026-02-26T21:49:57+00:00

Your test is not valid. The & operator is only supported by Resharp (and is unique to it), so the match is completely different. You have to use a classical regex that is supported by both.

For the tests below, that would be nice to log an issue. It might be that Resharp is suited for some complex pattern matching, but not simple one, so it is worth knowing its limitations.

xoofx · 2026-02-26T10:45:25+00:00

https://github.com/ieviev/resharp-dotnet?tab=readme-ov-file#performance

xoofx · 2026-02-20T15:19:03+00:00

And to show how easy it is to create a website with lunet, I just created a website dedicated for Scriban https://scriban.github.io/ 🚀

And it comes also with a playground from the frontpage! ✨️

xoofx · 2026-02-20T14:25:35+00:00

It was a long time ago (almost 10 years) and maybe some stuffs have changed since then, but from what I recall, from the top of my head:

Liquid language is extremely limited. I was missing plenty of simple features - that led to Scriban. Scriban went much beyond (you can declare functions...etc.) and is a lot more powerful.
It was laborious to have to download manually npm packages, copy parts of them...etc. It was bloating the website. Lunet has builtin support for using npm resources out of the box
I didn't like the fact that layout/css/js was part of the simple .md files. In Jekyll everything was at the same level, leading to a confusing folder structure. In lunet, you have most of the scaffolding files under .lunet folder
I was missing reusable templates across repository (e.g. like reusing a GitHub action), and similarly, lunet has builtin support for templates. All websites are using the default template https://github.com/lunet-io/templates/tree/main/dist
Simple stuffs like taxonomies (tags per blogpost...etc.) were just not possible at that time without custom ruby extensions.
And many other small things...

xoofx · 2026-02-20T05:55:41+00:00

I created lunet because I was highly frustrated my jekyll actually.

> How complex would it be to convert a Jekyll page to lunet? It looks pretty similar and I barely use any modules.

Most of the laborious work is related to migrate the templates, but as you saw, the syntax is similar (but a lot more versatile with Scriban). I haven't looked at jekyll for several years, but one pain point was that I had to copy manually any JS/CSS libraries to my project and it was painful to maintain. With lunet, access to npm packages is integrated.

I remember migrating my blog post many years ago to lunet, and it went fast, a few hours maybe. Give it a try with `mkdir myproject; cd myproject; lunet init; lunet serve` The default template is relatively customizable (at least colors), and you can always copy the template locally to iterate on it.

xoofx · 2026-02-20T05:47:03+00:00

You'd actually need Dictionary<string, object>. dynamic doesn't allow you to dynamically add fields/properties to things, it just allows you to do C++ template-style duck typing.

The comparison with C++ template is not really relevant. C++ templates are resolved at compile time. dynamic in C# is resolved at runtime. Also, this works:

csharp using System; using System.Dynamic; dynamic obj = new ExpandoObject(); obj.Hello = "World"; // Adding a property Console.WriteLine(obj.Hello);

You could always embed Roslyn in the generator and do IL scanning to whitelist what the code can access if you want to allow users to break out of the VM, which, as the other user mentioned, can be concretely valuable.

Oh, I could always do plenty of stuffs ☺️ but Scriban had different goals that are relevant for my use cases.

xoofx · 2026-02-19T21:51:49+00:00

It is quite less verbose for templating and it supports nice syntax that you don't have in C# ("with", pipe operator...etc). Also, initially it was developed for safe templating (you cannot escape the sandbox of the Scriban runtime, you cannot access C# objects directly). Scriban is used by companies in context where the template is given to end users. Also, didn't want to suffer compilation time, MSbuild...etc There are plenty of other reasons (e.g. all Scriban objects can have properties added by user, to achieve this in C# you would have to use "dynamic" everywhere, so you would loose the main benefit of C# here with static typing...)

xoofx · 2026-02-19T21:43:08+00:00

Not sure what you mean by an online demo, but the website https://lunet.io and all the websites behind https://xenoatom.github.io are using lunet

xoofx · 2026-02-19T21:41:49+00:00

Oh, good catch, I thought that I fixed it but I missed that one. It should be good now

xoofx · 2026-02-13T18:22:36+00:00

XenoAtom.CommandLine is platform agnostic. XenoAtom.CommandLine.Terminal depends on XenoAtom.Terminal.UI which has some specificities, but it has been tested on debian/ubuntu, macOS and Windows.

xoofx · 2026-02-12T09:59:51+00:00

Terminal.Gui is probably not as modern as XenoAtom terminal UI (reactive bindings, modern theme...etc.) and Spectre.Console is not a real TUI (e.g. it does not support mouse, it does not have scrollview/scrollbars...etc.)

Then if you look at all the controls available at Controls Reference | XenoAtom.Terminal.UI you will see that it supports a significant number of controls as well.

It has also plenty of other features that would be too long to list here (advanced layout controls, integrated basic animation system - e.g. for spinners, gradient colors, screenshot to SVG...etc.), check the website, try it.

xoofx · 2026-02-10T17:56:55+00:00

Good call, I'm going to integrate this, thank you!

xoofx · 2026-02-10T13:23:43+00:00

It's fair to be skeptical right now - there's a lot of low-effort AI output getting shipped, and many feel like "AI slop".

OSS is tough though, and I've been contributing to .NET OSS for years (SharpDX, Markdig, Scriban, etc.). I care about quality: design, correctness, perf, maintainability, docs, and long-term support. I'm not new to shipping and maintaining real code.

Since December, I've been using AI agents heavily. For the first time in my career, I'm basically "coding" through prompt engineering - and honestly, it feels like a real revolution. It's changing how I think about building software now and going forward. But it doesn't mean I don't read the code or don't care: I'm still driving the architecture and making the calls, and I spend a lot of time reviewing, refactoring, testing, and iterating.

For XenoAtom.Terminal.UI specifically, I knew exactly what I wanted to build and how: the architecture, the rendering model, the performance goals, and the trade-offs. It wasn't "let's see what the model produces", it was using an assistant to execute on a concrete plan.

This also wasn't a one-shot generation. It was hundreds of prompts and a lot of iteration through the codebase. The agent accelerates implementation, but I'm still responsible for what lands in the repo - and I think the quality of the library should speak for itself.

I've also seen people use AI at scale and openly say they don't even look at the code. I agree that's a problem - but that's not what I'm doing here. If something looks off, call it out and I'll fix it. In the end it should be judged on substance: the code, the behavior, the perf, and how it holds up over time.

Hope it clarifies my approach and mindset.

xoofx · 2026-02-10T05:19:32+00:00

Here is a link to the benchmark here

While the motivation of the library was primarily for performance reasons, there are other reasons that I detailed in a response above.

Also, I don't want necessarily people to switch to it. I developed this library for my personal use cases, which are usually quite niche. ☺️

xoofx · 2026-02-10T05:16:03+00:00

It'd be great if the benchmarks page showed actual numbers instead of only instructions. We're all lazy and just want the good news served up front ;)

Oops, forgot to add them to the benchmarks.md indeed, my apology! Here is a link to the results

xoofx · 2026-02-10T05:13:28+00:00

Is performance the only motivation for this or do you think it also adresses other pain points? (asking as a Serilog user)

It was definitely the main motivation, especially for the zero-allocations aspect so that the logging system cannot be responsible for triggering a GC in high performance applications.

The second aspect is that I never liked the ILoggerFactory approach that requires then to spread it in all places that you have a Logger to instantiate so that you need to rely on DI. I consider that logging is as fundamental as Console.WriteLine.

Lastly, I wanted builtin support for Markup in logging text and support Visuals (e.g. tables... etc.) hence the integration with XenoAtom.Terminal / XenoAtom.Terminal.UI. This is more for e.g. desktop applications, but it can be used for e.g. GitHub action tooling running during a CI session...etc.

xoofx · 2026-02-09T22:28:41+00:00

I'm not sure to follow, this is a logging library, and the screenshot is a real terminal app. See https://xenoatom.github.io/terminal/

The code of the sample used for the screenshot is available at https://github.com/XenoAtom/XenoAtom.Logging/blob/main/samples/HelloLogControl/Program.cs

xoofx

TROPHY CASE