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

My LLM codegen workflow

harper.blog

Post reply on HN
Print view View original

121–130 of 168 posts

Re: My LLM codegen workflow

#121

Post by ukuina »

jrvarela56 wrote: post #117
briga wrote: 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…

I would recommend everyone reading this to think of it as a skill issue. You can learn to use the LLM/agent to document your code base, test isolated components and refactor your spaghetti into modular chunks easily understandable by the agent. The greenfield projects turn into a mess very quick because if you let it code without any guidance (wrt documentation, interactivity, testability, modularity) it generates cr…

> turns into legacy as fast as the agent can spit out new code.

This is an important point. Unconstrained code generation lets you witness accelerated codebase aging in real-time.

Re: My LLM codegen workflow

#122

Post by ghuntley »

MarkMarine wrote: post #69
ghuntley wrote: post #50

Earlier quoted context omitted.

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

I’ve been following this, my workflow doesn’t us cursor (VS Code descendants just aren’t my preference) but I’ve built your advice into my home made system using emacs and gptel. I keep a style guide that is super detailed for each language and project, and now I’ve been building the stdlib you recommended. It’s great, thanks for writing this!

no problem <3

Re: My LLM codegen workflow

#123

Post by hnuser123456 »

harper wrote: post #5
ggulati wrote: post #3

Nice, I coincidentally wrote a blog post today exploring workflows as well: https://ggulati.wordpress.com/2025/02/17/cursorai-for-fronte... Your workflow is much more polished, will definitely try it out for my next project

let me know how it works!

Thank you for fixing it

Re: My LLM codegen workflow

#124

Post by triyambakam »

bcoates wrote: 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's more like waiting for the code to compile (or node_modules to install before npm improved)

Re: My LLM codegen workflow

#125

Post by triyambakam »

krupan wrote: post #120

If I have to go to this much effort, what is AI buying us here? Why don't we just put the effort in to learn to write code ourselves? Instead of troubleshooting AI problems and coming up with clever workarounds for those problems, troubleshoot your code, solve those problems directly!

Speed. The abstraction layer has moved up. You probably aren't writing machine code anymore.

Re: My LLM codegen workflow

#126

Post by triyambakam »

krupan wrote: post #119
junto wrote: post #114

Something I’ve started to do recently is mob programming with LLM’s. I act as the director, creativity and ideas person. I have one LLM that implements, and a second LLM that critiques and suggests improvements and alternatives.

I hope this is a joke, but I'm guessing it isn't, lol!

It's a good idea. Get diverse model output.

Re: My LLM codegen workflow

#127

Post by risyachka »

fragmede wrote: post #72
risyachka wrote: post #71

Earlier quoted context omitted.

How does it help and not make it worse when it comes to layoffs?

Because ghuntly doesn't have to outrun the bear, just outrun the rest of us. Meaning, if ghuntly can provide more value to an employer than a different employee, who doesn't know this trick, it's the other employee that's getting laid off, not ghuntly. In sharing this trick, it means that ghuntly now also has to outperform the other employee who also has this trick.

This is a race to the bottom and doesn’t help anyone

Re: My LLM codegen workflow

#128

Post by mike_hearn »

manmal wrote: post #58
mike_hearn wrote: post #44

Earlier quoted context omitted.

Aider + AI generated maps and user guides for internal modules has worked well for me. Just today I did my own version of a script that uses Gemini 2 Flash (1M context window) to generate maps of each module in my codebase, i.e. a short one or two sentence description of what's in every file. Aider's repo maps don't work well for me, so I disable them, and I think this will work better. I also have a scratchpad file…

LLMs forcing us to improve our documentation habits. Seriously though, many languages allow API doc generation out of comments. Maybe these docs can just be flattened into a file.

Yes sort of. This particular codebase is a mix of Java and Kotlin, and all my internal code is documented with proper Javadocs/KDocs already since years, just for myself and other people I work with. That's partly why Gemini can make such accurate maps.

The problem isn't a lack of docs but rather birds-eye context: even with models that allow huge context windows and are fast, you can drown a model in irrelevant stuff and it's expensive. I'm still with Claude 3.5 for coding and its window is large but not unlimited. You really don't want to add a bunch of source files _and_ the complete API docs for tens of thousands of classes into every prompt, not unless you like waiting whilst money burns and getting problems due to the model getting distracted.

It's also just wasteful, docs contain a lot of redundancy and stuff the model can guess. If you ask models to make notes about only the surprising stuff, it's a form of compression that lets you make smaller prompts.

Aider provides a quick fix because it's easy to control what files are in the context. But to 'level up' I need to let the AI find and add files itself. Aider can do this: it gives the model tools for requesting files to be added to the chat. And in theory, Aider computes a PageRank over symbols and symbolic references to find the most important stuff in the repository and computes a map that's prepended to the prompt so the model knows what to ask for. In practice for reasons I don't understand, Aider's repo maps in this project are full of random useless stuff. Maybe it works better for Python.

Finding the right way to digest codebases is still an open problem. I haven't tried RAG, for instance. If things are well abstracted it in theory shouldn't be needed.

Re: My LLM codegen workflow

#130

Post by flir »

bcoates wrote: 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…

> constantly clean-rebuilding your whole (doomed) project, gives you both some downtime and a sense of forward momentum

ouch. You've thought about this, haven't you? Your ideas are intriguing to me, and I wish to subscribe to your newsletter.

Post reply on HN