GPT can't even tell what its done or give what it knows it should. It's endless, "Apologies, here is what you actually asked for ..." and again it isn't.

This was my primary reason for using Claude. Absolutely useless experience with chatgpt oftentimes. I’ve mainly been using LLMs to help maintain a ridiculously poorly made technical debt dumpster fire, and Claude has been really helpful here mainly with repetitive code.

Yeah ChatGPT is truly the worst. Claude has been consistently much better. Grok 3 is surprising me every day.

I would love an AI coding assistant that doesn't respond until it's gone out and tested its answer in a sandbox to confirm it actually compiles.

I personally haven't figured out why there isn't a tool that just loops the AI severals times on a task by compiling, feeding in the errors adjusting and repeating and then letting the user review the result be in a success or failure by exceed the loop limits.

Claude has a tendency to overcomplicate bug fixes. If you put it on loop it would probably build a custom ERP.

They exist in various forms...

The LLMs want to please, they can infinitely keep making 'important' changes; changing variable names without changing anything else, adding/removing comments, adding removing print statements, moving a function somewhere in the code (usually by first duplicating it) and fixing perfectly fine code with 'let me see if everything is really working' (it was and now it's broken again).

"Wanting to please" is just fine-tuned implicit prompt stuff, though. You can tell the LLM that it's roleplaying as a senior engineer, and should consider you, the human to be a junior engineer it works with, who is asking it for advice. You can just leave it at that (often works, if the AI knows enough about how software is produced); or you can describe particular traits of senior engineers — e.g. "wants code that works" and "knows when to say the code is good enough and that the junior is now wasting time by fiddling with it."

https://syntix.pro automatically executes and verifies the code it generates. Disclaimer: I made it.

Devin does that

Wasn't Devin a scam? Honest question; Google is not very clear about it but some people said it was a scam/money grab. You are saying it works?

I've used it for some smaller greenfield code with success. Like, write an Arduino program that performs a number of super-sampled analog readings, and performs a linear regression fit, printing the result to the serial port.

That sort of stuff can be very helpful to newbies in the DIY electronics world for example.

But for anything involving my $dayjob it's been fairly useless beyond writing unit test outlines.

> Like, write an Arduino program that performs

stuff like that works amazing

> But for anything involving my $dayjob it's been fairly useless beyond writing unit test outlines

This was my opinion 3-6 months ago. But I think a lot of tools matured enough to already provide a lot of value for complex tasks. The difficult part is to learn when and how to use AI.

I use it everyday, it has to have good search and good static analysis built in.

You also have to be very explanatory with a direct communication style.

Our system imports the codebase so it can search and navigate plus we feed lsp errors directly to the LLM as development is happening.

> we feed lsp errors directly to the LLM as development is happening

Yeah I guess that would help a lot. Stuck with a bit more primitive tools here, so that doesn't help.

> That sort of stuff can be very helpful to newbies

Yep, if it's newbie stuff there are enough tutorials out there for the LLM to have data.

It's when you get off the tutorials and do the actual functionality of your project that they fail.

I use LLMs for writing generic, repetitive code, like scaffolding. It's OK with boring, generic stuff. Sure it makes mistakes occasionally but usually it's a no-brainer to fix them.

> I use LLMs for writing generic, repetitive code, like scaffolding. It's OK with boring, generic stuff.

In other words, they're OK in use-cases that programmers need to eliminate, because it means there's high demand for a reusable library, some new syntax sugar, or an improved API.

Boilerplate and plumbing code isn't inherently bad, nor do you improve the codebase by factoring it down to zero with libraries and abstractions.

As I've matured as a developer, I've appreciated certain types of boilerplate more and more because it's code that shows up in your git diffs. You don't need to chase down the code in some version of some library to see how something works.

Of course, not all boilerplate is created equally.

Boilerplate is better than bad abstractions. But good abstractions are far superior.

The best abstraction is no abstraction.

No.

Edit: I'm not going to code asm just to be cool.

asm? Why would anyone use that useless abstraction over byte code?

bytes are abstractions. Only use them if you know upfront how many bits you need.

I agree with you but as I've matured as a programmer, I feel like it's very hard to get abstractions for boilerplate right. Every library I've seen attempt to do it has struggled.

Even Rails went with codegen despite being backed by the language most amenable to abstractions.

I would consider deterministic codegen to be a valid abstraction (or rather a valid implementation of some abstraction). It's not really any different from a regular library wrt ability to test & validate. The problem with any human- and LLM- handwritten code is that even the best coders make mistakes.

Abstractions are like mutations - most of them kill the host =P

"A program is like a poem. You cannot write a poem without writing it." — Dijkstra

You can use niche libraries and still benefit from AI, basically anything I want to code is something that I don't think exists, and to bend API in a way that makes a generic library do just what I want means basically writing the same code, just instead of contributing to library its immediate, because the "piping" around it magically appears. I bet if it keeps improving at a current late for a decade, the occupation "programmer" will morph into "architect".

I'll take boring scaffolding code over libraries that perform undebuggable magic with monkey patches, reflection or dynamic code.

With LLMs, I hope we move towards libraries that make code easier to read, not easier to write.

We won't be eliminating anything until we give up on only ever working directly on plaintext single source of truth code. AI is automating tedium that's otherwise impossible to automate because we're stuck in a 1970s Unix paradigm and can't let go.

But people, especially here on HN, are saying it's the only way to go.

> because it means there's high demand for a reusable library

Every 'modern' project takes bucket loads of (annoying) setup and plumbing. Even in rather trivial 'start' cases, the LLM has to spend quite a bit of time to get a hello world thingy working (almost all of that is because 'modern programmers' have some kind of brain damage concerning backward compatibility; move fast and break things between MINOR versions that have no use or reason for those changes whatsoever but 'they liked it better', so stuff never works as it says on the product page; heaven help you if you need something exotic to be added). It's a terrible timeline for programming, but LLMs do fix at least that annoyance by just changing configs/slabs of code it until it works.

I try to keep "boring" code to a minimum, by finding meaningful and simple abstractions. LLMs are especially bad handling those, because they were not trained on non-standard abstractions.

Edit: most LLMs are great for spitting out some code that fulfills 90% of what you asked for. That's sometimes all you need. But we all know that the last 10% usually take the same amount of effort as the first 90%.

This is what got me in most sleepless nights, crunch and ass clenching production issues over my career.

Simple repetitive shit is easy to reason about, debug and onboard people on.

Naturally it's balancing act, and modern/popular frameworks are where most people landed, there's been a lot of iteration in this space for decades now.

I've made the opposite observation. Without proper abstractions code bases grow like crazy. At some point they are just a huge amount of copy, paste, and slight modification. The amount of code often grows exponentially. With more lines of code comes more effort to maintain it.

After a few years those copy and pasted code pieces completely drift apart and create a lot of similar but different issues, that need to be addressed one by one.

My approach for designing abstractions is always to make them composable (not this enterprise java inheritance chaos). To allow escaping them when needed.

> At some point they are just a huge amount of copy, paste, and slight modification.

I mean is that bad? Unless you keep having to have huge MRs that modify every copy/paste could you just let the code sit there and run forever?

I only say this because I've been a maintenance programmer and I could only dream of a codebase like this. The idea that I get a Rollbar with a stack trace and the entirety of what the code actually does is laid bare right at the site of the error in a single file is amazing. And I can change it without affecting anything else?! I end up having to "unwind" all of the abstractions anyway because the nature of the job means I'm not intimately familiar with the codebase and don't just know where the real work happens.

There is a balance. Too much abstractions isn’t necessarily better than not enough abstractions. The optimal amount is usually non-zero, though.

But the point is that modern/popular frameworks picked the low hanging fruit of abstraction, we had several iteration cycles over two+ decades of mainstream web tech.

The landscape (browser capabilities, backend stacks) has settled over last ten years.

We even had time to standardize on things somewhat.

Building new abstractions at this point is almost always the wrong move. This is one of the points that LLMs will improve in software dev - they will kill the framework churn because they will work best on stuff already in training data.

>most LLMs are great for spitting out some code that fulfills 90% of what you asked for. That's sometimes all you need. But we all know that the last 10% usually take the same amount of effort as the first 90%.

The issue is if you have an LLm write for you 10k lines of code, where 100 lines are bugged. Now you need to debug the code you did not write and find the bugged code, you will waste similar amount of time. The issue is if you do not catch the bugs in time, you think you gain some hours but you will get upset customers because things went wrong because the code is weird.

From my experience you need to work withan LLM and have the code done function by function, with your input and you checking it and calling bullshit when it does stupid things.

In my experience using LLMs, the 90% is less about buggy code and more about just ignoring 10% of the features that you require. So it will write code that's mostly correct in 100-1000 lines of code (not buggy) but then no matter how hard you try, it won't get the remaining 10% right and in the process, it will mess up parts of the 90% that was already working or end up writing another 1000 lines of undecipherable code to get 97% there but still never 100% unless you're building something that's not that unique.

Exactly my experience. It's always missing something. And the generated code often can't be extended to fulfil those missing aspects.

I use a custom code generator for that. It works much better than trying to explain to an AI exactly what I want. Yes it’s a it more work up front but worth it IMHO.

> I really don't get how so many people can get LLMs to code most of their tasks without those issues permanently popping up

They can't, they usually just don't understand the code enough to notice the issues immediately.

The perceived quality of LLM answers is inversely proportional to the user's understanding of the topic they're asking about.

That's more or less my suspicion.

A few months ago I tried to do a small project with Langchain. I'm a professional software developer, but it was my first Python project. So I tried to use a lot of AI generated code.

I was really surprised that AI couldn't do much more than in the examples. Whenever I had some things to solve that were not supported with the Langchain abstractions it just started to hallucinate Langchain methods that didn't exist, instead of suggesting some code to actually solve it. I had to figure it out by myself, the glue code I had to hack together wasn't pretty, but it worked. And I learned not to use Langchain ever again :)

Alternatively, we understand it well, and discard bad completions immediately.

When I'm using llama.vim, like 40% of what it writes in a 4-5 line completion is exactly what I'd write. 20-30% is stuff that I wouldn't judge coming from someone else, so I usually accept it. And 30-40% is garbage... but I just write a comment or a couple of lines, instead, and then reroll the dice.

It's like working through a junior engineer, except the junior engineer types a new solution instantly. I can get down to alternating between mashing tab and writing tricky lines.

I don't see the point in AI code completions, they are just distracting noise. I'm only doing bigger changes with AI.

Prompt based stuff, like "extract the filtering part from all API endpoints in folder abc/xyz. Find a suitable abstraction and put this function into filter-utils.codefile"

What tools do you use to perform such tasks?

Aider. I tried Cursor too, but I don't like VS Code and not being able to chose the LLM provider. I think there are already a lot of tools that perform kind of equally.

What do you mean? You can chose the LLM in Cursor. (I don't like VSCode either, but unfortunately Cursor is best for the rest of the UX; I find myself using Cursor for the prompt-based part of the work, and then move to IntelliJ to do "my" part of the coding)

I've tried using basic AI completions before and found that the signal-to-noise ratio wasn't quite good enough for my taste in my use cases, but I can totally understand it being good enough for others.

My comment was more about just asking questions on how to do things you're totally clueless about, in the form of "how do I implement X using Y?" for example. I've found that, as a general rule, if I can't find the answer to that question myself in a minute or two of googling, LLMs can't answer it either the majority of the time. This would be fine if they said "I don't know how to do that" or "I don't believe that's possible" but no, they will confidently make up code that doesn't work using interfaces that don't exist, which usually ends up wasting my time.

I've got basically the opposite experience. I receive very little useful toplevel help or directing me to appropriate resources.

But if I'm writing out a bunch of linear algebra, I get a lot of useful completions and avoid tediousness.

I've settled on Qwen2.5.1-Coder-7B-Instruct-Q6_K_L.gguf-- so not even a very big model.

Exactly.

A language like Golang tries really hard to only have _one_ way to do something, one right way, one way. Just one way. See how it was before generics. You just have a for loop. Can't really mess up a for loop.

I predict that the variance in success in using LLM for coding (even agentic coding with multi-step rather than a simple line autosuggest or block autosuggest that many are familar with via CoPilot) has much more to do with:

1) is the language a super simple, hard to foot-gun yourself language, with one way to do things that is consistent

AND

2) do juniors and students tend to use the lang, and how much of the online content vis a vis StackOverflow as an example, is written by students or juniors or bootcamp folks writing incorrect code and posting it online.

What % of the online Golang is GH repo like Docker or K8s vs a student posting their buggy Gomoku implementation in StackOverflow?

The future of programming language design has AI-comprehensibility/AI-hallucination-avoidance as one of the key pillars. #1 above is a key aspect.

> A language like Golang tries really hard to only have _one_ way to do something

Really?

Logging in Go: A Comparison of the Top 9 Libraries

https://betterstack.com/community/guides/logging/best-golang...

Since Go added slog many of these have been removed in favor of that. Obviously not universal, but compared to npm there really are massive numbers of devs just using the standard library.

I would argue logging options to be more of an exception than the rule. Compare the actual language features of Go to something like Rust or Javascript and you'll see what I mean. As a new developer to the language (especially for juniors), you can learn all the features of Go much faster. It's made to be picked up quickly and for everyone's code to look the same, rather than expressing a personal style.

I find it hard to imagine how a language could enforce that no two (third-party) libraries can implement the same functionality.

Note that "super-simple", "hard to footgun yourself" and "one way to do things that is consistent" are three very different things.

I don't think that we yet have one language that is good at all that. And yes, I (sometimes) program in Go for a living.

> LLMs. I really don't get how so many people can get LLMs to code most of their tasks without those issues permanently popping up.

You write tests in the same way as you would delegate to anyone else?

A good prompt. You don’t just ask it. You tell it how to behave and give it a shot load of context

With Claude the context window is quite small. But with adding too much context it often seems to get worse. If the context is not carefully narrowly picked and too unrelated, the LLMs often start to do unrelated things to what you've asked.

At some point it's not really worth anymore creating the perfect prompt, just code it yourself. Also saves the time to carefully review the AI generated code.

Claude's context window is not small, is it not larger than ChatGPT's?

I just looked it up, it seems to be the rate limit that's actually kicking in for me.

Yes, that's it! It is frustrating to me, too. You have to start a new chat with all relevant data, and a detailed summary of the progress/status.

(Because you reach the limit faster otherwise).

Doesn't prevent it from hallucinating, only reduces hallucinations by a single digit percentage

Personally I’ve been finding that the more context I provide the more it hallucinates.

There's probably a sweet spot. Same with people. Too much context (especially unnecessary context) can be confusing/distracting, as well as being too vague (as it leaves room for multiple interpretations). But generally, I find the more refined and explicit you are, the better.

They are good at (combining well-known, codeforces-style) algorithms; often times I don’t care about the syntax, but I need the algorithm. LLMs can write pseudocode for all I care but they tend to get syntax correct quite often

I have made large projects using Claude, with success. I know what I want to do and how to do it, maybe my prompts were right.

What do you define as a large project? Like TLOC?

In my case the maximum was ~3k LOC.

That's not a "large" project, it's either a toy or a single-purpose tool.

A single-purpose tool, and libraries, yes.

What is the LOC of cgit? Because I made a lot of changes to it, too, albeit privately. I uploaded most files as project files.

That's not just small, it's utterly miniscule. It's most certainly not large.

Depends. 3k is pretty much enough for a fully-featured XY.

So no context, and differences of the definition of "large".

Perhaps if you come from Java, then yeah.

shrugs

I'd still call 3kLOC quite small in all mainstream languages.

I worked on a Python project which I'd consider as medium sized, ie not small but not large, and it was around 25kLOC.

My $dayjob is a Delphi codebase with roughly 500kLOC, which I'd say is large but not huge.

Though if you wrote it in something like K[1], then yeah ok, I'd agree 3kLOC probably counts as large.

[1]: https://en.wikipedia.org/wiki/K_(programming_language)

I have spent my career working on software that measures its size in MLOC (millions of lines of code). Not because it's Java, but because it's big.

Nah this is miniscule: https://github.com/coreutils/coreutils/blob/master/src/yes.c

You can fit a hell of a lot of functionality in 3k statements. Really whether it's considered large or small necessarily must rely on the functionality it's intended to provide.

You're thinking on "lean" vs "bloated". "Large" and "small" have meanings of their own, and a 3k LOC project wouldn't be accepted as "large" by anyone. "Small", maybe.

I certainly never described 3k as large, so I'll assume you replied to the wrong comment. If not, let's just agree to use the terms differently.

This is 11,682 lines of C (and not including some Lua and Python scripts) according to cloc:

https://github.com/williamcotton/webdsl

It's a pipeline-based DSL for building web apps with SQL, Lua, jq and mustache templates.

I'd say it's like 90% Cursor Composer in Agent mode.

This is probably more like a mid-sized project, right?

Quite nice that.

I've done >100k LoC with Claude; by far most of that is frontend in react/ts which is incredibly verbose and wasteful, so very easy to pack up many many lines quickly without a lot (mostly none) of ROI per line. Which is probably why claude is great at it.

How do you deal with large files? After about a thousand lines in a file, it starts to cough for me. Forgets that some functions exist and makes up inferior duplicate ones.

If possible you need to refactor before getting to that point.

Claude has done a good job refactoring, though I’ve had to tell it to give me a refactor plan upfront in case the conversation limit gets hit. Then in a new chat I tell it which parts of the plan it has already done.

But a larger context/conversation limit is definitely needed because it’s super easy to fill up.

I did not experience hallucinations (very rarely if at al) when I use it for programming. It happened more with niche languages (so I provide examples and documentation), and with GPT.

Let us say there is 3k lines of RFCs, API, documentation of niche languages, examples), 2k lines of code generated by Claude (iteratively, starting small), then I do exceed the limit after a while. In that case I ask it to summarize everything in detail, start a new chat, use those 3k lines and the recent code, and continue ad infinitum.

I ask it to cut files up when they get too large, that seems t work pretty well. It is also good at that, but you have to sternly tell it NOT to make any functional changes, otherwise it will and breakage will happen.

What TFA was talking about didn't really seem like an hallucination - just a case of garbage in-garbage out. Normally there are more examples of good/correct data in the training set than bad, so statistically the good wins, but if it's prompted for something obscure maybe bad is all that it has got.

Common coding tasks are going to be better represented in the training set and give better results.

It means that "reasoning" isn't.

Probably by coding things that are bery mainstream and have already been fed to the LLM a thousand times from ripped off projects.

Here's the secret to coding with an LLM: don't expect it to get things 100% correct. You will need to fix something almost every time you use it to generate code. Maybe a name here, maybe a calculation, maybe a function signature. And maybe you won't spot the issue until later.

You still "used" an LLM to write the code. And it still saved you time (though depending on the circumstances this can be debatable).

That's why all these people say they use LLMs to write lots of code. They aren't saying it did it 100% without any checking and fixing. They're just saying they used it.

The trick to coding with LLMs is not caring if the code is correct.

Call me cynical but coding at some companies has such perverse incentives that I kind of get it:

- "Solve" the issue assigned to me with a bunch of code that looks about right. Passes review and probably not covered by tests anyway.

- Once QA or customers notice it's not working, I can get credit for "solving" the bug as well.

- Repeat for 0 value delivered but infinite productivity points in my next performance review.

I suppose that you are using a dynamic language? Static typed languages have less of this problem.

This is a hypothetical "I". Personally I am deeply passionate about delivering shareholder value, producing high-quality code, enthusing stakeholders, tabs vs spaces, and so forth...

Sometimes I don't know anything (relatively) about the topic and I want to get a foundation so I don't care whether the syntax or the code is valid as long as it points me in the right direction. Other times I know exactly what I want and I just find that instructing LLM specifically what output I expect from it just helps me get there faster.