Live data from Hacker News

My LLM codegen workflow

harper.blog

91–100 of 168 posts

Re: My LLM codegen workflow

#91
post #85

That lonely/downtime section at the end is a giant red flag for me. It looks like the sort of nonproductive yak-shaving you do when you're stuck or avoiding an unpleasant task--coasting, fooling around incrementally with your LLM because your project's fucked and you psychologically need some sense of progress. The opposite of this is burnout--one of the things they don't tell you about successful projects with good…

It sounds like LLMs are the new futzing with emacs configuration.

Old and busted: Futzing around with my Emacs configuration. New hotness: Having an LLM do it for me.

Re: My LLM codegen workflow

#94
Am I the only one that doesn’t see the hype with Claude? I recently tried it, hit the usage limit, read around found tons of blogs and posts from devs saying Claude is the best code assistant LLM… so I purchased Claude pro… and I hate it. I have been asking it surface level questions about Apache spark (configuring the number of tasks retries, errors, error handling, etc.) and it hallucinated so much, so frequently. It reminds me of like ChatGPT 3…

What am I doing wrong or what am I missing? My experience has been so underwhelming I just don’t understand the hype for why people use Claude over something else.

Sorry I know there are many models out there, and Claude is probably better than 99% of them. Can someone help me understand the value of it over o1/o3? I honestly feel like I like 4o better.

/frustration-rant

Re: My LLM codegen workflow

#95
post #73

Absolutely LLMs are great for greenfield projects. They can get you to a prototype for a new idea faster than any tool yet invented. Where they start to break down, I find, is when you ask it to make changes/refactors to existing code and mature projects. They usually lack context, so they doesn't hesitate to introduce lots of extra complexity, add frameworks you don't need, and in general just make the situation wor…

100% agree. My experience to date across the major LLMs is that they are quick to leap to complex solutions, and I find that the code often is much harder to maintain than if I were to do it myself. But complex code is only part of the problem. Another huge problem I see is the rapid accumulation of technical debt. LLMs will confidently generate massive amounts of code with abstractions and design patterns that may b…

But why follow the wrong abstraction and why try to build something that you don't fundamentally understand?

I've built some rather complex systems:

Guish, a bi-directional CLI/GUI for constructing and executing Unix pipelines: https://github.com/williamcotton/guish

WebDSL, fast C-based pipeline-driven DSL for building web apps with SQL, Lua and jq: https://github.com/williamcotton/webdsl

Search Input Query, a search input query parser and React component: https://github.com/williamcotton/search-input-query

Re: My LLM codegen workflow

#96
post #32

Earlier quoted context omitted.

The end of artisan frameworks - probably for the better.

It's likely the end of a lot of abstractions that made programming easier. At some point, specialized code-gen transformer models should get really good at just spitting out the lowest level code required to perform the job.

Disagree. Some abstractions are still vital, and it's for the same reasons as always: communicate purpose and complexity concisely rather than hiding it.

The best code is that which explains itself most efficiently and readably to Whoever Reads It Next. That's even more important with LLMs than with humans, because the LLMs probably have far less context than the humans do.

Developers often fall back on standard abstraction patterns that don't have good semantic fit with the real intent. Right now, LLMs are mostly copying those bad habits. But there's so much potential here for future AI to be great at creating and using the right abstractions as part of software that explains itself.

Re: My LLM codegen workflow

#97
post #94

Am I the only one that doesn’t see the hype with Claude? I recently tried it, hit the usage limit, read around found tons of blogs and posts from devs saying Claude is the best code assistant LLM… so I purchased Claude pro… and I hate it. I have been asking it surface level questions about Apache spark (configuring the number of tasks retries, errors, error handling, etc.) and it hallucinated so much, so frequently.…

It seems like you might be trying to use it like a search engine, which is a common mistake people make when first trying LLMs. LLMs are not like Google.

The key is to give it context so it can help you. For example, if you want it to help you with Spark configuration, give it the Spark docs. If you want it to help you write code, give it your codebase.

Tools like cursor and the like make this process very easy. You can also set up a local MCP server so the LLM can get the context and tools it needs on its own.

Re: My LLM codegen workflow

#98
post #20

This is all fine for a solo dev, but how does this work with a team / squad, working on the same code base? Having 7 different instances of an LLM analyzing the same code base and making suggestions would not just be economically wasteful, it would also be unpractical or even dangerous? Outside of RAG, which is a different thing, are there products that somehow "centralize" the context for a team, where all questions…

I've started substituting "human" for "LLM" when I read posts like these. Is having 7 different humans analyzing the same code base any less wasteful?

Re: My LLM codegen workflow

#99

Earlier quoted context omitted.

If you steer it and build a stdlib, you get better outcomes. See https://ghuntley.com/stdlib

> I'm hesitant to give this advice away for free With all the layoffs in our sector, I wouldn't blame you if you didn't share it, so thank you for sharing.

Yeah, don't they know how to hustle? I bet they're still asleep at 5am.

Seriously, though, it's really sad that not trying to profit off a discussion of industry tooling is something someone has to "push through".

Re: My LLM codegen workflow

#100
post #15

Has anyone who evolved from a baseline of just using Cursor chat and freestyling to a proper workflow like this got any anecdata to share on noticeable improvements? Does the time invested into the planning benefit you? Have you noticed less hallucinations? Have you saved time overall? I’d be curious to hear because my current workflow is basically 1. Have idea 2. create-next-app + ShadCN + TailwindUI boilerplate 3.…

Yes, and then I keep going back to the basics:

- small .cursorrules file explaining what I am trying to build and why at a very high level and my tech stack

- a DEVELOPMENT.md file which is just a to-do/issue list for me that I tell cursor to update before every commit

- a temp/ directory where I dump contextual md and txt files (chat logs discussing feature, more detailed issue specs, etc.)

- a separate snippet management app that has my commonly used request snippets (write commit message, ask me clarify questions, update README, summarize chat for new session, etc.)

Otherwise it's pretty much what your workflow is.

Post reply on HN