More tokens -> more compute involved. Attention-based models work by attending every token with each other, so more tokens means not only having more time to "think" but also being able to think "better". That is also at least part of the reason why o1/o3/R1 can sometimes solve what other LLMs could not.

Anyway, I don't think any of the current LLMs are really good for coding. What it's good at is copy-pasting (with some minor changes) from the massive code corpus it has been pre-trained. For example, give it some Zig code and it's straight unable to solve even basic tasks. Same if you give it really unique task, or if you simply ask for potential improvements of your existing code. Very, very bad results, no signs of out-of-box thinking whatsoever.

BTW: I think what people are missing is that LLMs are really great at language modeling. I had great results, and boosts in productivity, just by being able to prepare the task specification, and do quick changes in that really easily. Once I have a good understanding of the problem, I can usually implement everything quickly, and do it in much much better way than any LLM can currently do.

It doesn't hurt that the model vendors get paid by the token, so there's zero incentive to correct this pattern at the model layer.

What’s worse, I get a lot of comments left saying what the AI did, not what the code does or why. Eg “moved this from file xy”, “code deleted because we have abc”, etc. Completely useless stuff that should be communicated in the chat window, not in the code.

LLMs are also good at commenting on existing code.

It’s trivial to ask Claude via Cursor to add comments to illustrate how some code works. I’ve found this helpful with uncommented code I’m trying to follow.

I haven’t seen it hallucinate an incorrect comment yet, but sometimes it will comment a TODO that a section should be made more more clear. (Rude… haha)

> If the code works, passes all relevant tests, is reasonably maintainable, and can be fitted into the system correctly with a well defined interface, does it really matter?

You're not wrong here, but there's a big difference in programming one-off tooling or prototype MVPs and programming things that need to be maintained for years and years.

We did this song and dance pretty recently with dynamic typing. Developers thought it was so much more productive to use dynamically typed languages, because it is in the initial phases. Then years went by, those small, quick-to-make dynamic codebases ended up becoming unmaintainable monstrosities, and those developers who hyped up dynamic typing invented Python/PHP type hinting and Flow for JavaScript, later moving to TypeScript entirely. Nowadays nobody seriously recommends building long-lived systems in untyped languages, but they are still very useful for one-off scripting and more interactive/exploratory work where correctness is less important, i.e. Jupyter notebooks.

I wouldn't be surprised to see the same pattern happen with low-supervision AI code; it's great for popping out the first MVP, but because it generates poor code, the gung-ho junior devs who think they're getting 10x productivity gains will wisen up and realize the value of spending an hour thinking about proper levels of abstraction instead of YOLO'ing the first thing the AI spits out when they want to build a system that's going to be worked on by multiple developers for multiple years.

what are you going to do when something suddenly doesn't work and cursor endlessly spins without progress no matter how many "please don't make mistakes" you add? delete the whole thing and try to one-shot it again?

Good insight, and indeed quite exactly my state of mind while creating this particular solution.

Iin this case, I did put in the guard rails to ensure that I reach my goal in hopefully a straight line and a quickly as possible, but to be honest, I did not give much thought to long-term maintainability or ease of extending it with more and more features, because I needed a very specific solution for a use case that doesn't change much.

I'm definitely working differently in my brown-field projects where I'm intimately familiar with the tech stack and architecture — I do very thorough code reviews afterwards.

I think this code is at least twice the size than it needs to be compared to nicer, manually produced Python code: a lot of it is really superfluous.

People have different definitions of "reasonably maintainable", but if code has extra stuff that provides no value, it always perplexes the reader (what is the point of this? what am I missing?), and increases cognitive load significantly.

But if AI coding tools were advertised as "get 10x the output of your least capable teammate", would they really go anywhere?

I love doing code reviews as an opportunity to teach people. Doing this one would suck.

Right, and the reason why professional developers are writing worse code out there is most likely because they simply don't have the time/aren't paid to care more about it. The LLM is then mildly improving the output in this brand of common real world scenario

I don't see the difference there. Whether I've written all the code myself or an AI wrote all of it, my name will be on the commit. I'll be the person people turn to when they question why code is the way it is. In a pull request for my commit, I'll be the one discussing it with my colleagues. I can't say "oh, the AI wrote it". I'm responsible for the code. Full stop.

If you're in a team where somebody can continuously commit trash without any repercussions, this isn't a problem caused by AI.

I think there’s a difference in that this is about as good as LLM code is going to get in terms of code quality (as opposed to capability a la agentic functionality). LLM output can only be as good as its training data, and the proliferation of public LLM-generated code will only serve as a further anchor in future training. Humans on the other hand ideally will learn and improve with each code review and if they don’t want to you can replace them (to put it harshly).

I do believe it's amazing what we can build with AI tools today.

But whenever someone advertises how an expert will benefit from it yet they end up with crap, it's a different discussion.

As an expert, I want AI to help me produce code of similar quality faster. Anyone can find a cheaper engineer (maybe five of them?) that can produce 5-10x the code I need at much worse quality.

I will sometimes produce crappy code when I lack the time to produce higher quality code: can AI step in and make me always produce high quality code?

That's a marked improvement I would sign up for, and some seem to tout, yet I have never seen it play out.

In a sense, the world is already full of crappy code used to build crappy products: I never felt we were lacking in that department.

And I can't really rejoice if we end up with even more of it :)

This really gets to an acceleration of enshittification. If you can't tell its an LLM, and there's nobody to verify the information, humanity is architecting errors and mindfucks into everything. All of the markers of what is trustworthy has been coopted by untrustworthy machines, so all of the way's we'd previously differentiated actors have stopped working. It feels like we're just losing truth as rapidly as LLMs can generate mistakes. We've built a scoundrels paradise.

How useful is a library of knowledge when n% of the information is suspect? We're all about to find out.

The pool is named backups according to zpool status and the paragraph right after.

But then again the old id doesn't match between the two commands.

>Its date is November 2021

The date can be spoofed. It first showed up on archive.org in December 2022, and there's no captures for the site before then, so I'm liable to believe the dates are spoofed.

There was alot going on in the years before ChatGPT. Text generation was going strong with interactive fiction before anyone were talking about OpenAI.

I used LLM:s for content generation in july 2021. Of course that was when LLM:s were pretty bad.

GPT-2 was released in 2019. ChatGPT wasn't the first publicly available LLM.

This typically happens when you run the chat too long. When it gives you a new codebase, fire up a new chat so the old stuff doesn't poison the context window.

Are you reading a whole encyclopedia each time you assigned to a task? The one thing about learning is that it compounds. You get faster the longer you use a specific technology. So unless you use a different platform for each task, I don't think you have to read that much documentation (understanding them is another matter).

I expect some of the big companies that went all in on relying on AI to fall in the coming years.

It will take some time tho, as decision makers will struggle to make up reasons why why noone on the payroll is able to fix production.

It’s probably the same way monks copying books felt when the printing press came along. “Look at this mechanical, low-quality copy. It lacks all finesse and flourish of the pen!”

I agree with you that it is sad. And what is especially sad is that the result will probably be lower quality overall, but much cheaper. It’s the inevitable result of automation.

I feel exactly the same way, it’s profoundly depressing.

You "AI" enthusiasts always try to find a positive spin :)

What if I had trusted the code? It was working after all.

I'm guessing that if i asked for string manipulation code it would have done something worth posting on accidentally quadratic.

Regarding your first paragraph, we still don't understand what the issue actually is.

Won't it throw the same "FileNotFound" exception in that case? The issue being bothering to check if it exists in the first place I suppose.

OK, that does make sense. Thanks!

I did another session with the sole focus being on code quality improvements.

The commit with all changes that Cursor/claude-3.7-sonnet(thinking) has done is at https://github.com/dx-tooling/platform-problem-monitoring-co....

As you can see, I've fed your feeback verbatim:

  I have received the following feedback regarding this codebase:

  "The premise might possibly be true, but as an actually seasoned Python developer, I've taken a look at one file: @utils.py. All of it smells of a (lousy) junior software engineer: from configuring root logger at the top, module level (which relies on module import caching not to be reapplied), over not using a stdlib config file parser and building one themselves, to a raciness in load_json where it's checked for file existence with an if and then carrying on as if the file is certainly there..."

  I therefore ask you to thoroughly improve the code quality of the implementation in @src   while staying in line with the requirements from @REQUIREMENTS.md, and while ensuring that the Quality Tools (see @makefile) won't fail. Also, make sure that the tests in folder @tests  don't break.

  See file @pyproject.toml for the general project setup. There is already a virtualenv at @venv.

Computer, enhance 15 to 23.

Or even fewer by doing it in a global exception handler instead of every time you try to open a file, since all your doing is piping the error though logger.