Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The unbearable slowness of AI coding

joshuavaldez.com

Post reply on HN
Print view View original

51–60 of 107 posts

Re: The unbearable slowness of AI coding

#51

Post by CuriouslyC »

jmvldz wrote: post #40
falcor84 wrote: post #2

> ... I’ll keep pulling PRs locally, adding more git hooks to enforce code quality, and zooming through coding tasks—only to realize ChatGPT and Claude hallucinated library features and I now have to rip out Clerk and implement GitHub OAuth from scratch. I don't get this, how many git hooks do you need to identify that Claude had hallucinated a library feature? Wouldn't a single hook running your tests identify that?

I don't have a ton of tests. From what I've seen, Claude will often just update the tests to no-op so tests passing isn't trustworthy. My workflow is often to plan with ChatGPT and what I was getting at here is ChatGPT can often hallucinate features of 3rd party libraries. I usually dump the plan from ChatGPT straight into Claude Code and only look at the details when I'm testing. That said, I've become more careful…

Tell Claude to use a code review sub agent after every significant change set, tell them to run the tests and evaluate the change set, don't tell Claude it wrote the code, and give them strict review instructions. Works like a charm.

Re: The unbearable slowness of AI coding

#52

Post by kiitos »

block_dagger wrote: post #17

My employer hosts one of the largest Ruby on Rails apps in the world. I've noticed that Claude Code takes a long time to grep for what it needs. Cursor is much better at this (probably because of local project indexing). Due to this, I favor Cursor over CC in my day to day workflows. In smaller code bases, both are pretty fast.

for projects of any non-trivial size, you should have a (local) MCP server that wraps/bridges some LSP over the local repo, so that when the LLM needs to find some identifier X, or callers, or implementations, or etc., it can ask the LSP directly rather than needing to do a grep or whatever

Re: The unbearable slowness of AI coding

#53

Post by CuriouslyC »

Workaccount2 wrote: post #33

Gemini CLI is pretty weak, but the Gemini 2.5 pro is still the best for long contexts. Claude is great but it crumbles as you start to get in the 50-100k range. I find Gemini doesn't start to crack until the 150-200k range. It's too bad the tooling around it is mediocre at best.

One of my favorite patterns is to use repomix to take a project repo and turn it into a single file, drop it in gemini and chat with it for a while about how to improve the codebase, then ask it to create a hyper-detailed set of instructions for claude to implement the changes we discussed. The planning tends to be much better than Opus because you've got your whole codebase in context and you've been chatting and steering the model for a bit, plus it can save you ~200-300k tokens.

Re: The unbearable slowness of AI coding

#55

Post by CuriouslyC »

sarchertech wrote: post #19
skeedle wrote: post #13

Even it's slow, you can run multiple agents. You can have one doing changes, while another writes documentation, while another does security checks, while another looks for optimizations. Persist finding to markdown files to track progress and for cross-agent knowledge sharing if need. And do whatever else while it's all running. This has been my experience.

But then you have to keep all those tasks in your head and be ready to jump into any of them. The check-ins are much more frequent and the instructions much lower level than what you’d give to a team if you were running it. Do you have an example of a large application you’ve released with this methodology that has real paying users that isn’t in the AI space?

If you set up your agents correctly, they can run for hours. My record is around 4 hours for a "prod/launch readiness" on a 90k LoC codebase, and that same codebase had a marathon lint and mypy plan that fixed ~700 issues over 6 hours (split around 3/3 due to API limits)

Re: The unbearable slowness of AI coding

#56

Post by simonw »

I wonder if the author is using automated tests.

My hunch is that good automated testing is an enormous factor with respect to how productive you can get with coding agent tools.

Thorough tests? Just like working without LLMs you can confidently make changes without fear of breaking other parts of the application.

No tests at all? Any change you make is a roll of the dice with respect to how it affects the rest of your existing code.

Re: The unbearable slowness of AI coding

#58

Post by littlestymaar »

Mistral may not be the smartest chat assistant out there, but I've stopped using others entirely given how slow they are compared to Mistral (which runs inference with Cerebras).

Waiting for an AI to complete its task isn't a fun thing at all, and I'd chose the fast 70% correct response any day over the slow 90% correct one. Because by the time the slow one gives you its first attempt, you'd have clarified you need and fixed the output from the fast one.

Sure if we get to the point where the slow system is 100% right, then it's no big deal if it's slow, but we're still far from that point.

Re: The unbearable slowness of AI coding

#59

Post by jmvldz »

CuriouslyC wrote: post #51
jmvldz wrote: post #40

Earlier quoted context omitted.

I don't have a ton of tests. From what I've seen, Claude will often just update the tests to no-op so tests passing isn't trustworthy. My workflow is often to plan with ChatGPT and what I was getting at here is ChatGPT can often hallucinate features of 3rd party libraries. I usually dump the plan from ChatGPT straight into Claude Code and only look at the details when I'm testing. That said, I've become more careful…

Tell Claude to use a code review sub agent after every significant change set, tell them to run the tests and evaluate the change set, don't tell Claude it wrote the code, and give them strict review instructions. Works like a charm.

Interesting. I had not thought about a code review sub agent. I will give that a shot.

Re: The unbearable slowness of AI coding

#60

Post by lkramer »

manmal wrote: post #30
sc68cal wrote: post #3

Earlier quoted context omitted.

They probably don't have any tests, or the tests that the LLM creates are flawed and not detecting these problems

Yesterday Claude Code assured me the following: • Good news! The code is compiling successfully (the errors shown are related to an existing macro issue, not our new code). When infact, it managed to insert 10 compilation errors that were not at all related with any macros.

The other day I had Claude proudly proclaim it fixed the bug, by deleting log line that exposed the bug...
Post reply on HN