Live data from Hacker News

How I write software with LLMs

stavros.io

431–440 of 544 posts

Re: How I write software with LLMs

#431

Genuine question: what's the evidence that the architect → developer → reviewer pipeline actually produces better results than just... talking to one strong model in one session? The author uses different models for each role, which I get. But I run production agents on Opus daily and in my experience, if you give it good context and clear direction in a single conversation, the output is already solid. The ceremony…

This is anecdotal but just a couple days ago, with some colleagues, we conducted a little experiment to gather that evidence. We used a hierarchy of agents to analyze a requirement, letting agents with different personas (architect, business analyst, security expert, developer, infra etc) discuss a request and distill a solution. They all had access to the source code of the project to work on. Then we provided the v…

Probably the same reason it takes a team of developers and managers 6 months to write what one or two developers can do on their own in one week. The overhead caused by constant meetings and negotiations is massive.

Re: How I write software with LLMs

#433

It's interesting to see some patterns starting to emerge. Over time, I ended up with a similar workflow. Instead of using plan files within the repository, I'm using notion as the memory and source of truth. My "thinker" agent will ask questions, explore, and refine. It will write a feature page in notion, and split the implementation into tasks in a kanban board, for an "executor" to pick up, implement, and pass to…

No criticism or anything, but it really does feel / sound like you (and others who embraced LLMs and agentic coding) aspire to be more of a product manager than a coder. Thing is, a "real" PM comes with a lot more requirements and there's less demand for them - more requirements in that you need to be a people person and willing to spend at least half your time in meetings, and less demand because one PM will organiz…

This seems more about how you view PMs than anything else.

Re: How I write software with LLMs

#434

Genuine question: what's the evidence that the architect → developer → reviewer pipeline actually produces better results than just... talking to one strong model in one session? The author uses different models for each role, which I get. But I run production agents on Opus daily and in my experience, if you give it good context and clear direction in a single conversation, the output is already solid. The ceremony…

To me, such techniques feel like temporary cudgels that may or may not even help that will be obsolete in 1-6 months. This is similar to telling Claude Code to write its steps into a separate markdown file, or use separate agents to independently perform many tasks, or some of the other things that were commonly posted about 3-6+ months ago. Now Claude Code does that on its own if necessary, so it's probably a net ne…

Totally agree - the fundamental concept here of automatically improving context control when writing code is absolutely something that will be baked into agents in 6 months. The reason it hasn't yet is mainly because the improvements it makes seem to be very marginal.

You can contrast this to something like reasoning, which offered very large, very clear improvements in fundamental performance, and as a result was tackled very aggressively by all the labs. Or (like you mentioned) todo lists, which gave relatively small gains but were implemented relatively quickly. Automatic context control is just going to take more time to get it right, and the gains will be quite small.

Re: How I write software with LLMs

#435
> Pine Town is a whimsical infinite multiplayer canvas of a meadow, where you get your own little plot of land to draw on. Most people draw… questionable content

Doesn't help that _pine_ is one way of saying penis in french

Re: How I write software with LLMs

#436

Earlier quoted context omitted.

Don't think it's fair to think any negative comment is from some anti-LLM-axe. I seriously gave you the benefit of the doubt, that was the whole reason I even looked further into your work. It's no shame to be critical in todays world. Delivering proof is something that holds extra value and if I would create an article about the wonderful things I've created, I'd be extra sure to show it. I looked at your clock proj…

Saying things like "there's no proof of your work" is the anti-LLM axe. Yes, it's all written by LLMs, and yes, it's all my work. Judge it on what it does and how well it works, not on whether the code looks like the code you would have written.

Is it your work? What did you bring to the table? Because if we're going to analyze design, then code is one function of that design.

For example, you talk about how the code is secure. How do you prove that it is secure?

Re: How I write software with LLMs

#438

Earlier quoted context omitted.

Saying things like "there's no proof of your work" is the anti-LLM axe. Yes, it's all written by LLMs, and yes, it's all my work. Judge it on what it does and how well it works, not on whether the code looks like the code you would have written.

Is it your work? What did you bring to the table? Because if we're going to analyze design, then code is one function of that design. For example, you talk about how the code is secure. How do you prove that it is secure?

The same way you prove your OSS code is secure.

People here see an LLM-assisted project and suddenly they've never written a bug in their life.

Re: How I write software with LLMs

#439
post #58

Earlier quoted context omitted.

Where's this delusion come from recently that great engineers didnt write code? What a load of crap. All you're doing is describing a different job role. What you're talking about is BA work, and a subset of engineers are great at it, but most are just ok. You're claiming a part of the job that was secondary, and not required, is now the whole job.

I never said great engineers didn’t write code. But writing the code was never the point. The point has always been delivering the product to the customer, in any industry. Code is rarely the deliverable. That’s my point.

And a horse breeder was important to transportation until the 1920s, but it doesn't mean their job was transportation.

They didn't magically become great truck drivers.

Programmers do not deliver products, they deliver code to make products.

If the code is no longer needed, nor is the job. A different job will replace it with different skills required.

Re: How I write software with LLMs

#440

Earlier quoted context omitted.

>> They have been natively incentivized to generate more where possible Do you have any evidence of this?

The cloud providers charge per output token, so aren't they then incentivized to generate as many tokens as possible? The business model is the incentive.

This is only true in some cases though and not others. With a Claude Pro plan, I'm being billed monthly regardless of token usage so maximizing token count just causes frustration when I hit the rather low usage limits. I've also observed quite the opposite problem when using Github's Copilot, which charges per-prompt. In that world, I have to carefully structure prompts to be bounded in scope, or the agent will start taking shortcuts and half-assing work when it decides the prompt has gone on too long. It's not good at stopping and just saying "I need you to prompt me again so I can charge you for the next chunk of work".

So the summary of the annecdata to me is that the model itself certainly isn't incentivized to do anything in particular here, it's the tooling that's putting its finger on the scale (and different tooling nudges things in different directions).

Post reply on HN