The conversation

dartosHNSource author
Lessons learnedExperience excerpt · English

I think the wildly different experiences we all seem to have with AI code tools speaks to the …

I think the wildly different experiences we all seem to have with AI code tools speaks to the inconsistency of the tools and our own lack of understanding of what goes into programming. I’ve only been slowed down with AI tools. I tried for a few months to really use them and they made the easy tasks hard and the hard tasks opaque. But obviously some people find them helpful. Makes me wonder if programming approaches differ wildly from developer to developer. For me, if I have an automated tool writing code, it’s bc I don’t want to think about that code at all. But since LLMs don’t really act deterministically, I feel the need to double check their output. That’s very painful for me. At that point I’d rather just write the code once, correctly.

Original discussionChat is a bad UI pattern for development tools417 source comments · at import
3

What was this responding to?

Parent context · original excerpt

TH
themanmaranHN

I'm surprised that the article (and comments) haven't mentioned Cursor. Agreed that copy pasting context in and out of ChatGPT isn't the fastest workflow. But Cursor has been a major speed up in the way I write code. And it's primarily through a chat interface, but with a few QOL hacks that make it way faster: 1. Output gets applied to your file in a git-diff style. So you can approve/deny changes. 2. It (kinda) has context of your codebase so you don't have to specify as much. Though it works best when you explicitly tag files ("Use the utils from @src/utils/currency.ts") 3. Directly inserting terminal logs or type errors into the chat interface is incredibly convenient. Just hover over the error and click the "add to chat"

Full original

Community replies 0

No community replies yet. Add your perspective.

Replies from the source 3

Direct replies available in this import. Original-language excerpts.

AP
aprilthird2021HN

I think it's about what you're working on. It's great for greenfield projects, etc. Terrible for complex projects that plug into a lot of other complex projects (like most of the software those of us not at startups work on day to day)

Full original
SA
sangnoirHN

> But since LLMs don’t really act deterministically, I feel the need to double check their output. I feel the same > That’s very painful for me. At that point I’d rather just write the code once, correctly. I use AI tools augmentatively, and it's not painful for me, perhaps slightly inconvenient. But for boiler-plate-heavy code like unit tests or easily verifiable refactors[1], adjusting AI-authored code on a per-commit basis is still faster than me writing all the code. 1. Like switching between unit-test frameworks

Full original
KE
kenjacksonHN

I use LLMs several times a day, and I think for me the issue is that verification is typically much faster than learning/writing. For example, I've never spent much time getting good at scripting. Sure, probably a gap I should resolve, but I feel like LLMs do a great job at it. And what I need to script is typically easy to verify, I don't need to spend time learning how to do things like, "move the files of this extension to this folder, but rewrite them so that the name begins with a three digit number based on the date when it was created, with the oldest starting with 001" -- or stuff like that. Sometimes it'll have a little bug, but one that I can debug quickly. Scripting assistance by itself is worth the price of admission. The other thing I've found it good at is giving me an English description of code I didn't write... I'm sure it sometimes hallucinates, but never in a way that …

Full original
Continue on Hacker News

Respect different perspectives. Share concrete experiences.

Sign in to post, reply, repost, and quote.