KallDrexx (u/KallDrexx)

KallDrexx commented on The current state of LLM-driven development blog.tolki.dev/posts/2025... · Posted by u/Signez

dogcomplex · 17 days ago

We are all too well aware of the tragedy that is modern software engineering lol. Sadly I too have never seen that situation where I was given enough time to do the requisite multiple passes for proper design...

I have been reprimanded and tediously spent collectively combing over said quick prototype code for far longer than the time originally provided to work on it though, as a proof of my incompetence! Does that count?

KallDrexx · 16 days ago

Hah my bad, I misread your original comment as you saying you usually get the chance to do multiple passes on a prototype to productionalize it :)

KallDrexx commented on The current state of LLM-driven development blog.tolki.dev/posts/2025... · Posted by u/Signez

simonw · 18 days ago

The problem with your argument here is that you're effectively saying that developers (like myself) who put effort into figuring out good workflows for coding with LLMs are deceiving themselves, and are effectively wasting their time.

Either I've wasted significant chunks of the past ~3 years of my life or you're missing something here. Up to you to decide which you believe.

I agree that it's hard to take solid measurements due to non-determinism. The same goes for managing people, and yet somehow many good engineering managers can judge if their team is performing well and figure out what levers they can pull to help them perform better.

KallDrexx · 17 days ago

I'm not the OP and I"m not saying you are wrong, but I am going to point out that the data doesn't necessarily back up significant productivity improvements with LLMs.

In this video (https://www.youtube.com/watch?v=EO3_qN_Ynsk) they present a slide by the company DX that surveyed 38,880 developers across 184 organizations, and found the surveyed developers claiming a 4 hour average time savings per developer per week. So all of these LLM workflows are only making the average developer 10% more productive in a given work week, with a bunch of developers getting less. Few developers are attaining productivity higher than that.

In this video by stanford researchers actively researching productivity using github commit data for private and public repositories (https://www.youtube.com/watch?v=tbDDYKRFjhk) they have a few very important data points in there:

1. There's zero correlation they've found between how productive respondants claim their productivity is and how it's actually measured, meaning people are poor judges of their own productivity numbers. This does refute the claims on the previous point I made but only if you assume people are wildly more productive then they claim on average.

2. They have been able to measure actual increase in rework and refactoring commits in the repositories measured as AI tools become more in use in those organizations. So even with being able to ship things faster, they are observing increase number of pull requests that need to fix those previous pushes.

3. They have measured that greenfield low complexity systems have pretty good measurements for productivity gains, but once you get more towards higher complexity systems or brownfield systems they start to measure much lower productivity gains, and even negative productivity with AI tools.

This goes hand in hand with this research paper: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o... which had experienced devs in significant long term projects lose productivity when using AI tools, but also completely thought the AI tools were making them even more productivity.

Yes, all of these studies have their flaws and nitpicks we can go over that I'm not interested in rehashing. However, there's a lot more data and studies that show AI having very marginal productivity boost compared to what people claim than vice versa. I'm legitimately interested in other studies that can show significant productivity gains in brownfield projects.

KallDrexx commented on The current state of LLM-driven development blog.tolki.dev/posts/2025... · Posted by u/Signez

dogcomplex · 17 days ago

> Ahh, sweet summer child, if I had a nickel for every time I've heard "just hack something together quickly, that's throwaway code", that ended up being a critical lynchpin of a production system - well, I'd probably have at least like a buck or so.

Because this is the first pass on any project, any component, ever. Design is done with iterations. One can and should throw out the original rough lynchpin and replace it with a more robust solution once it becomes evident that it is essential.

If you know that ahead of time and want to make it robust early, the answer is still rarely a single diligent one-shot to perfection - you absolutely should take multiple quick rough iterations to think through the possibility space before settling on your choice. Even that is quite conducive to LLM coding - and the resulting synthesis after attacking it from multiple angles is usually the strongest of all. Should still go over it all with a fine toothed comb at the end, and understand exactly why each choice was made, but the AI helps immensely in narrowing down the possibility space.

Not to rag on you though - you were being tongue in cheek - but we're kidding ourselves if we don't accept that like 90% of the code we write is rough throwaway code at first and only a small portion gets polished into critical form. That's just how all design works though.

KallDrexx · 17 days ago

I would love to work at the places you have been where you are given enough time to throw out the prototype and do it properly. In my almost 20 years of professional experience this has never been the case and prototype and exploratory code has only been given minimal polishing time before reaching production and in use state.

KallDrexx commented on “ZLinq”, a Zero-Allocation LINQ Library for .NET neuecc.medium.com/zlinq-a... · Posted by u/cempaka

KallDrexx · 3 months ago

This is neat, but how does this get away with being zero allocation? It appears to use `Func<T,U>` for its predicates, and since `Func<T>` is a reference type this will allocate. The IL definitely generates definitely seems like it's forming a reference type from what I can tell.

KallDrexx commented on DotnetSnes: Library allowing to use C# to create SNES ROMs github.com/KallDrexx/Dotn... · Posted by u/ingve

SideburnsOfDoom · 4 months ago

> No dynamic allocations are supported (thus no reference type support)

No class instances. This is a severe limitation, to the point where it will change the character of the language entirely.

KallDrexx · 4 months ago

Also, I would point out that there are cases where it doesn't change significant amount of the language or hamper things.

The transpiler also works for Linux eBPF kernel side applications without unsafe pointers and other odd things I need to do for SNES.

Since you can have methods on c# struct instances, things can still work pretty idiomatically.

You also do have statically sized arrays, or heap allocated arrays (the latter is only supported if host C application passes it in before hand, and is responsible for free ing it).

KallDrexx commented on DotnetSnes: Library allowing to use C# to create SNES ROMs github.com/KallDrexx/Dotn... · Posted by u/ingve

reverseblade2 · 4 months ago

Just use F# to Rust via fable. https://github.com/ncave/fable-raytracer

KallDrexx · 4 months ago

It's not clear that Fable would fit the constraints, especially since F# heavily relies on reference types for discriminated unions and lots of other features. It's possible that Fable wouldn't be able to compile down to lower end embedded platforms, or even things like Linux eBPF applications (like my transpiler can do).

KallDrexx commented on DotnetSnes: Library allowing to use C# to create SNES ROMs github.com/KallDrexx/Dotn... · Posted by u/ingve

SideburnsOfDoom · 4 months ago

Does "no reference type support" also imply "no strings" ? i.e. no instances of the common reference type System.String ?

KallDrexx · 4 months ago

Strings become `char*` so they are supported as long as they are not dynamically generated (no concatenation for example, but some things like `printf()` templates do work.

e.g. https://github.com/KallDrexx/DotnetSnes/blob/master/src/Dotn...

KallDrexx commented on DotnetSnes: Library allowing to use C# to create SNES ROMs github.com/KallDrexx/Dotn... · Posted by u/ingve

SideburnsOfDoom · 4 months ago

> No dynamic allocations are supported (thus no reference type support)

No class instances. This is a severe limitation, to the point where it will change the character of the language entirely.

KallDrexx · 4 months ago

In theory, allocation could be hacked in with an arena allocator. I just need to add in reference type support and custom allocation strategies into the transpiler.

Then again, that's only viable if you don't use enough memory to require rom bank switching, or have better control over which class gets placed in which rom bank.

KallDrexx commented on Making SNES ROMs using C# reddit.com/r/dotnet/s/fhm... · Posted by u/nor0x

tombert · 4 months ago

Very cool.

I might need to play with this; I have been looking for an excuse to play with the retro console homebrew scene, this seems like as good an excuse as any.

KallDrexx · 4 months ago

Feel free to write up any issues in the repo if you encounter them. It's likely to encounter MSIL opcodes that my transpiler is missing support for.

Also the pvsneslib docs will probably be crucial for working with the SNES in general.

The Maven 2 SNES emulator was pretty useful for debugging. If you are on windows there's also a no$sns emulator that pvsnseslib has console message support for debugging.

I'm not going to promise it's a super polished effort in its current state :)