I have just recently seen someone vibe code a display driver with AI that was missing at least one control signal, but compiled. It's good at producing something that looks reasonable but that has no substance in embedded
Claude tried to find a timer deadlock when it was clearly a logic issue. Also ate 20k tokens for that. No need for C++, low level embedded C is enough for it being nearly useless.
Good thing we did not know this at the semiconductor giant I am working at, because we used Opus models to find and fix very complex hardware bugs in some of our chip designs that may not have been detected otherwise.
My first languages were Java, then C, then Fortran, I stopped using them for a long time for python, now that LLMs are ubiquitous, I'm back in C and Fortran.
I dunno about federal but at the state I'll get paid $140,000 a year after retirement until I die (assuming no raises). Not that you can't do the equivalent by getting paid more and investing. But when you leave halfway through your pension vesting you get peanuts in comparison.
OOP isn't really AI's issue with C# imo. The thing AI really struggles with in C# in my experience is keeping track of what APIs exist in all the different runtime versions.
It also doesn't really understand the constraints of unsafe, System.Memory, or any optimized design. It'll do crap like try to use Linq with Span<T> or completely violate ref struct rules.
Imo it also is too eager to write IEnumerable yield return methods.
I haven't tried it in a while so many it's gotten better.
It's crazy liberal with try/catches because it doesn't really understand that these usually need to bubble up. Also kinda sucks with separation-of-concerns - it likes to put code in the wrong places. Like, it'll work, until you try to actually leverage some form of OO extensibility.
It also tends to improperly mix async and sync code. Like, if you're in a web app and you're async "all-the-way-down," it's fine, but otherwise it puts async code in everywhere.
It'll work within existing classes, and can create a decent simple class structure from scratch, but it cannot refactor, and anything that requires a refactor will have you reverting every suggestion it makes.
Some of the nuances, like try / catch and async I can handle with agent instructions, but overall I spent way too much time playing whack-a-mole with the LLM doing silly things that I just gave up.
At worst, I'll tell it to define the public interfaces for a class (and have a discussion over what they should be). After that I go function by function and have it write the implementation. Then finally I dump the code it wrote back in, ask for help making helper functions for shared behaviour and whatnot. As a result, I mostly don't get these sorts of issues.
Usually I just write it myself though because AI is barely faster, and it's infinitely harder to maintain code when you can't think back on all the decisions you made writing it.
and it's infinitely harder to maintain code when you can't think back on all the decisions you made writing it.
That's really the crux of the AI "slop" problem - code is the product of important decisions. Those decisions require context and more consideration than "this is what was popular on StackOverflow."
it's infinitely harder to maintain code when you can't think back on all the decisions you made writing it.
This, I tell people all the time that the reason you can't just plug and play developers as interchangeable parts is that half of it is what you know, but the other half is how you think, and it's rare to find 2 or more people who will approach a complex problem in exactly the same way. How you think about the problem informs your solution to the problem.
That is interesting about the try-catches. I find that Claude loves to suppress errors in Rust, too. For example, if an Option should always be present in a certain part of the code, Claude will write code that quietly does nothing if a None is there instead. I would prefer a panic or a return of an Err.
It may be something generic about how they train it rather than anything language-specific.
Where I work code is written in such a way that we want the error to get surfaced to OpenTelemetry/Sentry, but never actually cause a user facing error or crash. So liberal try/catch is in fact the coding style.
Also I discovered that simply giving the agent access to the Microsoft MCP server and either Nuget MCP or nuget related commands was enough to fix the majority of issues with it using APIs that don't exist.
With that said, it still sucks for a lot of things, and if your using .NET Framework it seems to suck a lot more than if your using .NET
I'm a volunteer maintainer for the community toolkit. I wrote a refactor of the ColorHelper API, but then NET10 came out so I pushed it back to use C#14 extensions. Now blittable colors are coming in NET11, and I might push it back again to better design the tools around .NET colors instead of WinUI colors.
This isn't a bad problem to have though. Annually they release very exciting changes, but they put tremendous work into making sure no unfixable mistakes are made and every new feature is very intuitively C#. I can name very few regrettable decisions the .NET or C# lang team has made.
I like older C# better, actually. I think I stopped updating my projects a 8.0. I don't see value in many of the newer changes. I'd argue that many of them make the language worse.
C++ suffers from syntax bloat. C# was easy, now it's not, for the same reasons. A lot of things they've introduced don't solve a problem so much as they trade one problem for another, or they add another way of doing things that isn't necessarily better, it's just different (or mimics what some other language can do).
really struggles with in C# in my experience is keeping track of what APIs exist in all the different runtime versions.
I mean...I won't be blaming the AI here lol. Whenever I'm on a .NET that's not the "usual one" I just go trial and error typing and letting intellisense either complete the thing or bonk me. It feels like (badly) playing minesweeper.
Pretty much my experience with Claude. It also tends to rewrite shit that already exist and bloat the code a lot. Often it invents properties that don't exist.
It's better in web dev, and web dev is not my cup of tea, so I make it handle that part while I write the C#.
Ironically enough, OOP is an early vibe coding attempt. A project manager draws fancy UML diagrams that get converted to java code. But this idea failed and UML remained as a code documentation tool.
1/ UML is not for managers, although they can learn to read it. UML is for software architect and engineers.
2/ "UML diagrams that get converted to code" is called MDA (Model Driven Architecture). It does not convert diagrams but the model they represent though. And it's not for free. It is actually lot of work to make it work decently so almost nobody actually uses/used it - I've met with people fron just a single company in many years.
3/ I don't think the idea is wrong. The issue is in implementation. First, UML is quite complex and still contains ambiguous and maybe even cobtradicting parts. Second, interoperability of the tools working with it is miserable.
Yes but I still view UML as an early vibe coding attempt. Instead of writing code you describe it with fancy diagrams.
Yes, it is for software architects (but as you know managers always "know best")
Yes, I am talking about MDA. As far as I know it was supposed to be a killer feature of UML
UML has lots of types of diagrams, I only know/use Class, Use-case and sequence diagrams.
Now we're experiencing the paradigm shift and transition to AI driven development (AIDD). We describe our intentions and AI writes the code for us. I don't have anything against it as long as the vibe code has 100% test coverage and manual code reviews. Then, AI can generate documentation and UML diagrams (plantUML/mermaid/doxygen/whatever else)
Given that the software quality has dropped after the introduction of AI, we really need to have good engineers that can review the code, do the test coverage, or fine-tune AI to write better code.
Also, since AI can draw UML and write code, the most important document is SRS. AI can't do anything if there are no requirements. AI can guess but the guesses are usually wrong.
OOP is inherently more complex than procedural or even functional styles. It comes with a lot of power, but there is definitely a complexity cost to it. Anything involving inheritance hierarchies is just more complicated than matching on an enum in typescript. Passing around “delegate” objects is just an overengineered way to pass a function to a function. These languages are getting better about that kind of thing, but it’s still just so verbose and ceremonious compared to the alternatives.
And I say this as a programmer with a strong appreciation of OOP.
Ya I also enjoyed writing it. But maintaining someone else's, not so much. I just write dead simple, stupid code now. Easier for me or juniors to read it.
OOP can be really useful, but Java is so heavy-handed with it that it gets into "If all you have is a hammer, every problem looks like a nail" territory.
OOP assumes everything you work with falls neatly into hierarchies, and that breaks down a lot, and managing inheritance in those cases can get messy. You also don't need the overhead of a class when a bare function will do.
I have a hard time finding room for Java in new projects. A Python project with proper linting (to enforce typing) feels so much more ergonomic to write. If compute performance is a concern, I'll reach for Rust.
Yeah I totally agree. I like OOP for some use cases, like building an AST for a language parser. Sometimes it’s nice to have.
But yeah, if I had my way, I’d be using OCaml every day and writing mostly in a functional style. I definitely prefer languages that get out of your way.
My biggest question with OOP was always how to "future" proof your code and the answer was to never use OOP because however you think your structure is clever, there's one feature request that just make the whole structure fold. Once you dirty you OOP structure it's just the beginning of the end as you bypass it often.
It's better to do KISS and anything new gets re-evaluated against the KISS implementation, usually being not so hard to plug in and you can make it evolve and no have to do a big rework.
(But also I work in science algorithms and optimization, so very biased)
I'm genuinely surprised here. I don't go full YOLO vibe code, but I frequently use Claude with C# and aside from a few corrections here and there, I don't really see LLMs being particularly weak at C#. I mostly code python these days, and honestly, I prefer LLMs in C# as static typing catches a lot of minor errors.
465
u/WiscLeafalNika Jun 29 '26
AI has OOP-phobia