Hacker Newsnew | past | comments | ask | show | jobs | submit | appplication's commentslogin

I think it’s worth recognizing that people’s issues with LLMs isn’t that they make mistakes. And I think hammering the argument that humans also make mistakes indicates a bit of a disconnect with the more common reasons there is frustration with LLM use.

Ultimately I think people find it frustrating because many of us have spent years refining our communication so that it is deliberate and precise. LLMs essentially represent a layer of indirection to both of those goals. If I prepare some communication (email, code, a blog post, etc) and try to use an LLM more actively, I find at best I end up with something that more or less captures what I probably was going to communicate but doesn’t quite feel like an extension of my own thoughts as much as an slightly blurred approximation.

I think this also explains to some degree why it seems folks who were never particularly critical of their own communication have a hard time comprehending why anyone could be upset about this.

There is of course the flip side where now when receiving communication that I have to attempt to deduce if I’m reading a 5 paragraph, meticulously formatted email (or 200 line, meticulously tested function) because whoever sent it was too lazy to more concisely write 2-3 well thought out sentences (or make a 15-line diff to an existing function). And of course the answer here for the AI pragmatist is that I should consider having an AI summarize these extensive communications back down to an easily digestible 2-3 sentence summary (or employ an AI to do code review for me).

For those that value precise communications, this experience is pretty exhausting.


I think there’s some kernel of validity in this comment, but the unnecessarily aggressive tone loses it. This just comes off as bitter.

The is cool, thank you for sharing. I was just thinking about onboarding to ansible since I’ve just been following a manual checklist of commands for my remote server but based on positive feedback here I’ll probs oh give this a shot. Only downside is I imagine LLMs are probably a little more proficient at ansible just due to volume of training data.

I never depend on a models built-in training when using third-party libraries. Providing tons of additional context to the model like a skill, example repos, or context7 snippets that I manually curate is more effort up-front and takes longer, but the results are worth it.

Stuff I threw into the inputs before working with pyinfra

https://github.com/pyinfra-dev/pyinfra-examples

https://context7.com/websites/pyinfra


Agree on the 2M lines of code point. Looking at GitHub stats, I’ve personally written about 500k loc over the last 6 years, and that’s not including my teammates contributions etc. There are a lot o f things on our roadmap and I would consider the codebase to still be immature a feature incomplete. And this is all for a particular niche in a gigacorp.

If anything, having your entire company’s codebase be 2M loc and it be a functional product seems reasonably efficient to me.


You can remove shorts under YouTube’s time management settings > daily limits > shorts feed limit, you can set the max allowed time to 0 min and the effect is they all disappear.

Pity this setting is only for the mobile app.

Easier the first week? Have you forgotten the meconium days? I mean it’s nothing crazy but that stuff was so sticky. We thankfully didn’t have any total blowouts but talking to parents who do it sounded pretty rough to clean up comparatively.

Maybe ours was weird then? We just didn't have much volume of that.

No amount of it is pleasant but it still felt, even at the time, like training wheels on a diaper.


Our first kid’s poops came out with velocity. For the first month or two, every poop change was also a full outfit change. We are very glad that our second kid’s poops come out at a normal speed, so that it is just the normal amount of drool which necessitates the new outfits instead.

That’s a really cool idea I had not heard before, thank you for sharing this. It also feels like the type of thing a db ought to be able to do under the hood. I wonder why this is not a config (though there’s a pg extension for everything so maybe it does exist)

As far as I can tell, Postgres is not designed with this inclination towards doing lighter work when clients are waiting and piling up maintenance work to do in background. I think the background work it does is mostly running vacuum on tables now and then.

Contrast that with ClickHouse, for example. It operates in a different niche than Postgres (OLAP instead of OLTP) – with their merge tree engine family [1] that does data deduplication in background.

There is one project of modernizing Postgres' storage engine called OrioleDB [2], but I think the company got acquihired by Supabase [3] and maybe the project has not been progressing very quickly since then.

[1] https://clickhouse.com/docs/engines/table-engines/mergetree-... [2] https://www.orioledb.com/ [3] https://supabase.com/blog/supabase-acquires-oriole


Oriole is under very heavy development since we acquired them. We cut a release just 2 weeks ago:

https://github.com/orioledb/orioledb/releases/tag/beta15

We expect it to be production ready this year


It wouldn't be atomic, and so would break transaction semantics.

If you committed a row update but didn't update the index, a subsequent query using the not yet updated index would not find the updated row correctly.

It would also only work for certain types of indexes, you couldn't do it for uniqueness constraint for example.

I do agree that in theory you could have some extension to the index declaration that covers all that, but my worry there would be that it would be non obvious and a foot gun. Doing it the way described above makes that break in semantics clear.


> If you committed a row update but didn't update the index, a subsequent query using the not yet updated index would not find the updated row correctly.

I wonder if you could make it so that queries read from both the index and the unindexed changes. It would be slightly slower but as long as the unindexed changes are kept small it might be fine.


My impression is that InnoDB (MySQL's primary storage engine) is doing something like this. We have never seen any slow-downs on adding to the data set I've discussed in this thread, even at hundreds of millions of rows, and per the nature of the system creating this data the majority of these rows are targeted for additional single-row DML within a few seconds of being inserted, with instantaneous effect.

I’ve had not great experiences with Opus 4.7. It seems the model is overall less effective at reliably delivering via my standard way of interacting, and it also forgets things it was asked several times, even just minutes after being reminded again (e.g. “don’t in-line imports”).

I’m probably holding it wrong, but I think a given a sufficiently advanced AI it would essentially be impossible to use it incorrectly. Feels like a step backwards in this regard.


That was like living out and episode of Arrested Development in real time. I have a hard time recalling it without mentally casting Jeffrey Tambor as Rudy Giuliani.

Wow! Yes it does sound exactly like that. Reality really can be stranger than fiction

Perhaps it’s worth considering you both have valid experiences that are context dependent and not mutually exclusive.

In either case I think you might be coming in a bit hot. OP is just sharing their perspective. No one wants to get into internet fights.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: