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

Some things just take time

lucumr.pocoo.org

Post reply on HN
Print view View original

221–230 of 295 posts

Re: Some things just take time

#221

Post by imtringued »

timacles wrote: post #168
smj-edison wrote: post #149

Earlier quoted context omitted.

tbh that's not a helpful thing to say. I think a more productive thing would be to ask "What model are you using?" "Are you using it in chat mode or as a dedicated agent?" "Do you have an AGENTS.md or CLAUDE.md?" I've also been underwhelmed with its ability to iterate, as it tends to pile on hacks. So another useful question is "did you try having it write again with what you/it learned?"

Agreed was a bit rough. Yes they are not great at iterating and keeping long contexts, but you look at what he’s describing and you have to agree that’s exactly the type of problem llm excel at Shouldn’t have to baby step through the basics when the author is clearly not interested in learning himself

There is a big performance difference between models.

Trying to trace back the quality of the model to the "skills" of the person sounds extremely manipulative.

Re: Some things just take time

#222

Post by imtringued »

ErroneousBosh wrote: post #215
timacles wrote: post #166

Earlier quoted context omitted.

GD92 packets? No idea what you’re talking about but if it has a spec then it doesn’t matter if it’s trained on it. Break the problem down into small enough chunks. Give it examples of expected input and output then any llm can reason about it. Use a planning mode and keep the context small and focused on each segment of the process. You’re describing a basic tcp exchange, learn more about the domain and how packets a…

> GD92 packets? No idea what you’re talking about but if it has a spec then it doesn’t matter if it’s trained on it. Okay, so you're running into the same problem that LLMs are. > Break the problem down into small enough chunks. Give it examples of expected input and output then any llm can reason about it. So I have to do lots of grunt work? > You’re describing a basic tcp exchange, learn more about the domain and h…

>Okay, so you're running into the same problem that LLMs are.

I can't tell if you are a troll or not, but you can't complain that nobody understands your intentionally vague and obtuse way to describe the problem at hand to pretend you're superior.

https://www.publiccontractsscotland.gov.uk/NoticeDownload/Do...

You have to rename the file ending to PDF. It's probably the wrong spec, because I'm basing this research on literally four letters that could mean anything since there is zero context given here. I've also found some German documents about chemistry.

If your argument is that LLMs and humans are stupid because they don't know what a "GD92" is, then yeah maybe it's a you problem.

Go and throw the spec into openai codex inside limactl (get it from GitHub) and use zed (the editor) and a SSH remote project to get inside the VM, don't forget to enable KVM for performance. The free tier for openai is fine, but make sure to use codex 5.2.

First ask questions on what the binary encoding is based on. It's probably X.400, then once you've asked enough questions, tell it to implement it. You probably won't have to read the spec at all yourself.

Re: Some things just take time

#223

Post by johnnyanmac »

ozim wrote: post #164
gopalv wrote: post #100

Earlier quoted context omitted.

> Increased speed only gets us where we want to be sooner if we are also heading in the right direction. This is a real problem when the "direction" == "good feedback" from a customer standpoint. Before we had a product person for every ~20 people generating code and now we're all product people, the machines are writing the code (not all of it, but enough of it that I will -1 a ~4000 line PR and ask someone to start…

Have been there, we got pushback from users and we had to back off with releases. Users hunted product owner with pitchforks and torches. As dev team we were able to crank the speed even more and silly product people thought they are doing something good by demanding even more from us. But that was one of the instances where users were helpful :). People use dozens of apps every day to do their work. Just think about…

> Just think about how are you going to make time to give feedback to each of each.

That's pretty much solved by the size of the audiences. You won't give feedback on 12 apps, but 11 other people will probably do so on 11 different apps.

Of course, the issue with my domain is that there's plenty of feedback, and product owners just dismiss it. Burn down your entire portfolio to get that boosted shareholder value for the next earnings report.

Re: Some things just take time

#224

Post by johnnyanmac »

overfeed wrote: post #112
nabbed wrote: post #102

Earlier quoted context omitted.

>Increased speed only gets us where we want to be sooner if we are also heading in the right direction. I suppose there is an argument that if you are building the wrong thing, build it fast so that you can find out more quickly that you built the wrong thing, allowing you to iterate more quickly.

> I suppose there is an argument that if you are building the wrong thing, build it fast so that you can find out more quickly that you built the wrong thing, A lot of people are so enamored by speed, they are not even taking the time to carefully consider the full picture of what they are building. Take the HN frontpage story on OpenCode: IIRC, a maintainer admitted they keep adding many shallow features that are br…

Tech very quickly shifted to a industry of marketers instead of hackers. And with salesmen, you want to advertise as many features as possible, not talk about how quality one good crucial feature is.

This won't really stop until investors start judging on quality and not quantity. But a lot of those are thinking in finances, and the thought of removing their biggest cost center is too tempting to not go all in on. So they want to hear "we made this super fast with 2-3 people!" instead of "we optimized and scaled this up to handle 400% more workload with double the performance".

Re: Some things just take time

#225

Post by johnnyanmac »

throwaway27448 wrote: post #183
Chris_Newton wrote: post #60

With all the emphasis on the speed of modern AI tools, we often seem to forget that velocity is a vector quantity. Increased speed only gets us where we want to be sooner if we are also heading in the right direction. If we’re far enough off course, increasing speed becomes counterproductive and it ends up taking longer to get where we want to be. I’ve been noticing that this simple reality explains almost all of bot…

> Increased speed only gets us where we want to be sooner if we are also heading in the right direction. A proper capitalist system will tend toward the right direction as directed by the market yea? All of this neuroticism about AI doesn't matter.

Yes, the true market; shareholders.

Re: Some things just take time

#226

Post by johnnyanmac »

jstummbillig wrote: post #201
Chris_Newton wrote: post #154

Earlier quoted context omitted.

Speed actually just wins, because we are usually constrained by time. Sorry, but I don’t understand what you mean here. What do we win by being faster at producing the wrong things?

You learn more quickly that you are producing the wrong thing.

This implies that

1) a lot of shallow, orthogonal directions is better than 1 deep, careful approach

2) There's no social aspect to churning out a bunch of slop that will affect the perception of potential "right things" later. My domain can be particularly grudgeful in this regard.

Re: Some things just take time

#227

Post by johnnyanmac »

ChrisMarshallNY wrote: post #136

I find myself sympathetic to the author's PoV, but I am incorporating LLMs into my workflow, with a resultant jaw-dropping (to me) increase in velocity. But I am not just dispatching to agents. I work interactively with a chat interface, and sometimes, I will just bin a whole hour's worth of back-and-forth, because we're not getting anywhere (in fact, I did exactly that, about 30 minutes ago). But that hour is peanut…

> the Quality is really high, and I'm happy with the results.

>toss all 5 of my SDK files into the LLM, paste in the JSON server interaction, describe the bug, and ask it to help me figure it out.

I wonder if this "quality" code wouldn't have that many bugs to dive into if it was more carefully considered and produced up front?

This harkens back to a study in 2024 were senior devs were actually less productive with LLMS but they felt more productive, even after being told they were less productive.

Re: Some things just take time

#229

Post by johnnyanmac »

ramshanker wrote: post #199
ChrisMarshallNY wrote: post #136

I find myself sympathetic to the author's PoV, but I am incorporating LLMs into my workflow, with a resultant jaw-dropping (to me) increase in velocity. But I am not just dispatching to agents. I work interactively with a chat interface, and sometimes, I will just bin a whole hour's worth of back-and-forth, because we're not getting anywhere (in fact, I did exactly that, about 30 minutes ago). But that hour is peanut…

Same approach as mine. :) One more thing I try is give same prompt once in a while to ChatGPT/Gemini/Grok. Than take the 2 out of 3 ideas forward. All leading AI seems to have some blind spot. Like some kind of intricsic character. 1 will completely overlook some particular bug while finding other excellent bugs and edge cases. Getting the code through all 3 before commiting has shown excellent results to me.

Hope you'll be able to afford that workflow once the money dries up and costs skyrocket.
Post reply on HN