Hey! I would encourage you to try our Claude code instead, which is also part of your subscription. It's a CLI that takes care of many of the issues you encountered, as it works directly on the code files in a directory. No more copy pasting or unscrambling results. Likewise, it can run commands itself to e.g. compile or even test code.

I'm working on old hardware and not-recent Linux and compiler versions, and I have no confidence yet in allowing AI direct (write) access to my repositories.

Instead I provided Claude with the source code of a transpiler to C (one file) which is known to work, uses the same IR as the new code generators were supposed to use.

This is a controlled experiment with a clear and complete input and clear expectations and specifications of the output. I don't think I would be able to clearly isolate the contributions and assess the performance of Claude when it has access to arbitrary parts of the source code.

I use Claude Code with the Max plan, and the experience isn't far off from what you describe. You still need to understand the system and review the implementation, because it makes many mistakes.

That's not the part it saves me time in, it saves me time in looking up the documentation. Other than that, it might be slower, because the larger the code change is, the more time I need to spend reviewing, and past a point I just can't be bothered.

The best way I've found is to have it write small functions, and then I tell it to compose them together. That way, I know exactly what's happening in the code, and I can trust that it works correctly. Cursor is probably a better way to do that than Claude Code, though.

> The best way I've found is to have it write small functions, and then I tell it to compose them together.

Pretty much how I code without AI, except making my brain break the problem down into small functions and expressing them in code rather than as a chat.

> it saves me time in looking up the documentation

I have a Perplexity subscription which I heavily use for such purpose, just asking how something works or should be used, with a response just on the point and with examples. Very useful indeed. Perplexity gives me access to Claude Sonnet 4 w/o Thinking which I consider great models, and it can also generate decent code. My intention was to find out how good the recent Claude Opus is in comparison and how much of my work I'm able to delegate. Personally I much prefer the user interface features, performance and availability of Perplexity to Claude.ai.

I end up using Perplexity a lot too, especially when I'm doing something unfamiliar. It's also a good way to quickly find out what are best practices for a given framework/language I'm not that familiar with (I usually ask it to link to examples in the wild and it find opensource projects illustrating those points)

I have both, and Perplexity is much more like a search engine than a chat companion (or at least that's how I use it). I like both, though.

You can select the model. I very much appreciate the Claude Sonnet models which are very good and rational discussion partners, responding to arguments in detail and critically, allowing for the dialectical exploration of complex topics. I have also experimented with other models including ChatGPT, Gemini or Grok, but the resulting discussions were only a fraction as useful (i.e. more optimized towards affirmative feel-good small talk, from my humble point of view).

Hmm, I've never tried that, even though I prefer Claude in general too. I'll try that, thanks!

So, I am paying $20, for a glorified code generator, that may or may not be correct, to write a small function that I can do for free, and be confident about the correctness, if I have not been lazy to implement a test for it.

If you point out, with test it's also the same with any AI tool available, but to come to that result, I have to continuously prompt it till it gives me the desired output, while I may be able to do it in 2/3 iterations.

Reading documentation always made me little bit knowledgeable than before, while prompting the LLM, gives me nothing of knowledge.

And, I also have to decide which LLM would be good for the task at hand, and most of them will not be free (unless I use a local, but that will also use GPU, and add an energy cost)

I may be nitpicking, but I see too many holes with this approach

The biggest hole you don't see is that it's worth the $20 to make me overcome my laziness, because I don't like writing code, but I like making stuff, and this way I can make stuff while fooling my brain into thinking I'm not writing code.

Sure, that can be a point, which is helping you overcome your personal barrier, But that can be anything,

That is not you were vouching for on the original comment. It was about saving time.

Not only that, but the process described is how you train a junior dev.

There, at least, the wasted time results in the training of a human being who can become sophisticated enough to become a trusted independent implementer in a relatively short duration

Your time isn't free, and I'd certainly with more than $20/month.

I find it extremely useful as a smarter autocomplete, especially for the tedious work - changing function definitions, updating queries when DB schema changes, and writing http requests/api calls from vendor/library documentation.

Certainly, So I use an IDE, IntelliJ Ultimate to be precise.

None of the use-cases you mention requires LLM. Just available as IDE functionalities.

IntelliJ has LLM based auto complete, with which I am okay, But it still wrong too many times. Works extremely well with Rust. Their non-llm autocomplete is also superb, which uses ML for suggesting closest, relevant match, IIRC.

It also makes refactoring a breeze, I know what it's going to do exactly.

Also, it can handle database refactoring to a certain capacity! And for that it does not require LLM, so no nondeterministic behavior.

Also, the IDE have its own way of doing http requests, and it's really nice! But, I can use their live template to do autocomplete any boilerplate code. It only requires setting once. No need to fiddle with prompts.

On Claude you specifically accept any attempt to use a terminal command (optionally whitelisting) so there’s no risk that it will push force something or whatever. You can also whitelist with granularity, for example to enable it to use git to view git logs but not commit.

You can just let it work, see what’s uncommitted after it’s over, and get rid of the result if you don’t like it.

> I have no confidence yet in allowing AI direct (write) access to my repositories.

You don't need to give it write access to your repositories, just to a source tree.

claude-code asks you to allow it to do anything before it does them. Once you start trusting it and get comfortable with its behavior it gets annoying being prompted all the time, so you can whitelist specific commands it wants to run. You can also interactively toggle into (and out of) "accept changes without asking" mode.

(It wasn't clear to me that I would be able to toggle out of accept changes mode, so I resisted for a loooooong time. But turns out it's just a toggle on/off and can be changed in real-time as it's chugging along. There's also a planning state but haven't looked into that yet)

It always asks before running commands unless you whitelist them. I have whitelisted running testsuites and linters, for example so it can iterate on those corners with minimal interaction. I have had to learn to let it go ahead and make small obvious mistakes rather than intervene immediately because the linters and tests will catch them and Claude will diagnose the failure and fix them at that point.

Anyway I took a small toy project and used that to get a feel for claude-code. In my experience using the /init command to create CLAUDE.md (or asking Claude to interview you to create it) is vital for consistent behavior.

I haven't had good "vibe" experiences yet. Mostly I know what I want to do and just basically delegate implementation. Some things that have worked well for me is to ask Claude to propose a few ways to improve or implement a feature. It's come up with a few things I hadn't thought of that way.

Anyway, claude-code was very good at slowly and incrementally earning my trust. I resisted trying it because I expected it would just run hogwild doing bewildering things, but that's not what it does. It tends to be a bit of an asskisser in it's communication style in a way that would annoy me if it were a real person. But I've managed to look past that.

I've been trying it for a couple of months, I can't recommend it either tbh. It's frustrating as hell to work with: super inconsistent, very bad at following its own instructions, wasteful and generally unreliable.

The problem is, it's like a very, very junior programmer that knows the framework well, but won't use it consistently and doesn't learn from mistakes AT ALL. And has amnesia. Fine for some trivial things, but anything more complicated the hand-holding becomes so involved you are better off doing it yourself. That way you internalise some of the solutions as well, which is nice because then you can debug it later! Now I have a huge PR that even I myself don't really grasp as much as I would want.

But for me the nail in the coffin was the terrible customer service. ymmv.

Do you mean Claude code should fail? Why?

developers who use LLM code generation are a burden to their coworkers.

everybody can tell that chat gpt wrote your code. your breath stinks.

In what specific programming language/toolchain/technology is your experience? Why do you think that "everybody can tell that chat gpt wrote your code"? Meanwhile I looked at a lot of LLM generated code in different languages, and I wouldn't generally subscribe to your statement. And you still didn't explain why Claude should fail. I think it is rather an advantage (when I reliably works in future).

I can tell when my coworkers Go code is generated by an llm. I hate it very much.

Wow, shots fired! Would you add something to that?

i spend a lot of time fixing unacceptably poor code that LLM platforms have tricked human coworkers into finding adequate.

my coworkers are increasingly ignorant about the software products they work on.

LLM-informed software development is organizationally poisonous.

Businesses selling LLM coding tools occupy the same place in my mind as drug dealers.

Feels like that's more of a problem with the competence of your coworkers than with the LLM. The LLM is just exposing how bad they are.

I hate to play the "you're holding it wrong" card, but when I started, I had more or less the same experience. Eventually you start to learn how to better talk to it in order to get better results.

Something I've found useful with Claude Code is that it works a lot better if I give it many small tasks to perform to eventually get the big thing done, rather than just dumping the big thing in its lap. You can do this interactively (prompt, output, prompt, output, prompt, output...) or by writing a big markdown file with the steps to build it laid out.

This. For me (senior as in I am in the field since last century), that's how I use it. "I want to do that, with this data, to obtain that"

I still do the part of my job that I got experience on, analyze the need, and use the AI like an assistant to do small libraries or part of code. Like these, errors have less chance to appear. Then I glue that together.

For me the time ratio is best use like that. If I have to describe the whole thing, I'm not far from doing it myself, so there's no need for me.

Important: I work alone, not in a team, so maybe it has an impact on my thought

I just tried to use it for something I consider it to provide the most benefit (for my case). Being able to fully delegate a complicated (and boring) part to a machine would give me more time for the things I'm really interested in. I think we are on the right track in this regard, but we still have a long way to go.

It’d be nice if we could “pipe” prompts directly similar to how we pipe multiple Unix commands to eventually get what we really want.

Then we can give someone that entire string of prompts as a repeatable recipe.

You can send prompts on the command line to Claude, I typically save prompts in the repo. But note it won’t produce deterministic output.

Similar here. AI works much better as a consultant than as a developer. I ask it all kinds of things I have suspicions and intuitions about and it provides clarity and examples. It's great for subroutines. Trying to make full programs is just too large of a space. It's difficult to communicate all the implicit requirements.

People who consistently consult LLMs for product direction or software feature design overwhelmingly appear to me as willfully ignorant dullards.

I mean it's even further than willful ignorance. It's delight in one's own ignorance.

While this matches my experience, it's worth mentioning thar the act of breaking a task up into the correct chunk size and describing it in English is itself a non trivial task which can be more time consuming than simply writing the actual code.

The fact that it works is amazing, but I'm less convinced that it's enhancing my productivity.

(I think they real productivity boost for me is if I still write the code and have the assistant write test coverage based on diffs, which is trivial to prompt for good results)

And one that a lot of people skip, so that forcing function might make for better code, even if it isn’t faster.

Imho your post summarizes 90% of the posts I see about AI coding on HN: not understanding the tools, not understanding their strenghts and weaknesses, not being good at prompting or context management yet forming strong(ish) opinions.

If you don't know what they are good at and how to use them of course you may end up with mixed results and yes, you may waste time.

That's a criticism I have also towards AI super enthusiasts (especially vibe coders, albeit you won't find much here), they often confuse the fact that LLMs often one shot 80% of the solutions with the idea that LLMs are 80% there, whereas the Pareto principle well applies to software development where it's the hardest 20% that's gonna prove difficult.

I'm pretty good at prompting and I successfully use Perplexity (mostly with Claude Sonnet 4) to develop concepts, sometimes with the same session expanded over several days. I think the user interface is much superior over Claude.ai. My hope was that the newer Claude Opus 4.1 would be much better in solving complicated coding tasks, which doesn't seem to be the case. For this I had to subscribe to claude.ai. Actually I didn't see much difference in performance, but a much worse UI and availability experience. When it comes to developing a complex topic in a factual dialogue, Claude Sonnet Thinking seems to me to be even more suitable than Claude Opus.

I'll be more detailed in my second reply.

1) Your original post asks a lot if not too much out the LLM, the expectation you have is too big, to the point that to get anywhere near decent results you need a super detailed prompt (if not several spec documents) and your conclusion stands true: it might be faster to just do it manually. That's the state of LLMs as of today. Your post neither hints at such detailed and laborious prompting nor seem to recognize you've asked it too much, displaying that you are not very comfortable with the limitations of the tool. You're still exploring what it can and what it can't do. But that also implies you're yet not an expert.

2) The second takeaway that you're not yet as comfortable with the tools as you think you are is clearly context management. 2/3k locs of code are way too much. It's a massive amount of output to hope for good results (this also ties with the quality of the prompt, with the guidelines and code practices provided, etc, etc).

3) Neither 1 or 2 are criticisms of your conclusions or opinions, if anything, they are confirmations of your point that LLMs are not there. But what I disagree with is the rush into concluding that AI coding provides net 0 benefits out of your experience. That I don't share. Instead of settling on what it could do (help with planning, writing a spec file, writing unit tests, providing the more boilerplate-y part of the code) and use the LLM to reduce the friction (and thus provide a net benefit), you essentially asked it to replace you and found out the obvious: that LLMs cannot take care of non-trivial business logic yet, and even when they can the results are nowhere near being satisfactory. But that doesn't mean that AI-assisted coding is useless and the net benefit is 0, or negative, it only becomes so as the expectations on the tool are too big and the amount of information provided is either too small to return consistent results or too large for the context to be an issue.

This is a kind of nuts take; - Senior engineer - Uses tools for non trivial undertaking - Didn't find value in it

Your conclusion from that is "but they are doing it wrong", while also claiming they are saying things they didn't say (0 net benefits, useless, etc).

Do you see how that might undermine your point? That you feel they haven't take the time to understand the tools, but you didn't actually read what what wrote?

I don't know where your confidence or assumptions come from. Do you work for Anthropic? My prompts for the code generators included an 1.2kLOC code file plus detailed instructions (as described elsewhere), with more details during the session. So I don't think your points apply.

How do you know that your humble opinion is right about who knows what tool and how deep?

Even if you know better than themselves how musch they know, isn't the tool inadequate just yet for power use then when it is sooo easy to misuse?

Too much tweeking and adapting users to the needs of the tool (vs. the other way around) and there is little point using those (which is a bit of the sickness of modern day computing: 'with computers you can solve problems lightning fast that you wouldn't have without them')

Would you agree with the claim that emacs/vim is an inadequate tool, since it has such a high learning curve?

Prior to LLMs, my impression was "high learning curve, high results" was a pretty popular sweet-spot with a large portion of the tech crowd. It seems weird how much LLMs seem to be an exception to this.

Emacs and vim have complex interfaces that have been stable for decades. Seems like every new flavor of LLM requires learning its warts and blind spots from scratch.

The situation has improved a little bit over the last few months but LLMs are still only barely usable in languages like C/C++/Zig - and it's not about prompting. I would say that LLMs are usable for JS/Python and while the code is not always what I'd write myself, it can be used and improved later (unless you are working on perf-sensitive JS app, then it's useless again).

And it might be also something with GC, because I suppose the big boys are doing some GRPO over synthetically generated/altered source code (I would!) but obviously doing that in C++ is much more challenging - and I'd expect Rust to be straight impossible.

Vibe coder that reads hacker news chiming in here. I think that the true usefullness of LLMs for coding is often lost on the usual audience of this website, because most people here have extremely high standards of what they expect LLMs to accomplish.

But take people like me, I am an MD who was always into computers, but that just ended up going down a separate series of life decision, and could never find the time or energy to actually learn to code. When GPT-4 arrived, I started trying out using it for a medically-related coding hobby project, which eventually escalated into an ongoing PhD. Now, the fact is that this whole thing would just never have happened without LLMs. I would have never even thought of starting such a project, and if I did I wouldn't have had the time, and would have never made any progress even if I did. Vibe coding enabled me to do something entirely outside the scope of my previous capabilities. And the reality is that if I hadn't been able to do everything myself (down to the point of installing hardware managing the servers I am using), the project as a whole just wouldn't have happened.

The code I produce isn't going into production anywhere, it is only used for my particular purposes, it is not exposed to the web in any way, and so typical LLM issues like security etc. are a non-issue. And while my understanding of what my code is actually doing is pretty rudimentary (for instance, basic syntax conventions is something I just never bothered to learn), this doesn't really matter in practice. If it works it works.

I'm just shy of 30 years experience. I think I've spent more time learning how to use these tools than any other technology I've learned, and I still don't know the best way to use them.

They certainly weren't a time-saver right away but they became one after some time giving them a real shot. I tested their + my limits on small projects, working out how to get them to do the whole project, figuring out when they stop working and why, figuring out which technology they work best with, figuring out the right size problems to give them, figuring out how to recognize if I'm asking them something they can't do well a ask something different instead, guide them into creating code that they can't actually continue to be successful with.

I started last December in Cursor's agentic mode and have been in Claude Code ever since probably March or April. It's definitely been a huge boost all year for side projects - but only in the last couple months have I been having success in a large codebase.

Even with all this experience I don't know that I would really be able to get much value out of the chat interface for them. They need to be proposing changes I can just hit accept or reject on (this is how both Claude Code and Cursor work btw - you don't have to allow it to write to any file you don't want or execute any command you don't want).

The fact that you use Claude, not gpt5 which is light-years ahead for coding, tells me all I need to know.

I don't think it is true that GPT-5 is much better than Claude 4.1. And more important is that light year is distance measure and I am sure openAI data centers is still on earth.