epihelix
TFA was an unusually extreme example, to the point where I do wonder if an LLM was involved in the writing thereof.
To be fair, it's much (much!) easier to explain away an invisible god that nobody's ever seen, than a visible god that nobody's ever seen.
But whether or not this is actually needed or not now, I'm not so sure. LLMs are very good at parsing a codebase, discovering what needs to be changed to provide different functionality, suggesting any architecture changes that would be needed to do so, and ultimately implementing those changes within the bounds of an existing test suite.
I sadly suspect that if it's a choice between throwing a person or an LLM on an existing large and complex codebase cold, it's now safer and faster to use an LLM in many instances. Much better still to have someone with knowledge and understanding of the codebase work with an LLM, of course. But we're getting to the point that you can do a lot with little to no human knowledge at all.
(LLMs are also very good at bringing you up to speed with a large and complex codebase. A model can absolutely help create understanding in the person overseeing these changes, provided that person deigns to ask for it.)
(I also thought S0ix was supposed to fix all of this ...)
> > Choosing not to do something you’ve never done is one thing.
> > Choosing not to do something you’ve done is experience.
Gods, this sounds so LLM :(
Follow Apple's logic, reductio ad absurdum, and you'd have to put every single GUI element in the corners of the screen, because how else could you manage to quickly select them with a mouse? That OK button in the dialogue? Top right corner of the screen. Cancel? Top left. Quick, easy, and nobody could ever press the wrong button. It'll make it faster!
LLMs don't magic away the need for careful and extensive testing. Good code still takes a lot of time. But it's also a lot less time than before.
I suspect a lot of problems come from people trying to one-shot entire apps, or from those who do not have the relevant experience or knowledge to understand that close-with-a-nice-modern-GUI is not nearly good enough.
> Specifically, in order to successfully deliver major product realignment requires awareness of what exists currently and understanding of what needs to be.
And this is exactly what agentic coding brings to the table in spades.
I think this is what TFA was getting at -- what was once hard or impossible, and an absolutely massive headache to conceptualise, is now surprisingly simple and straightforward.
https://arxiv.org/html/2607.20526v1
From that paper, model accuracy is not perfect, but it's overall pretty favourable. There are some encouraging findings in there, too, including that accuracy of model confidence scales with reasoning effort.
I'm very glad of this now, because it means that I can still write with en- and em-dashes, while also demonstrating that my writing is not LLM-generated.
The latter look very promising for agentic coding. The former isn't quite there yet. We'll see, but I'd suggest the prior is moderately to strongly predicting that agentic coding is not a mania, but is very much here to stay.
(Obviously still the unpopular opinion here, mind you, and I may be wrong.)
The point is that it's easy to lose understanding of the finer details, even of a codebase you lovingly created, once this switch occurs and an LLM gets its hands on it.
I cannot think of any innovation that has required more defensive pleading for people to use it than passkeys. When a HN article has to be titled "passkeys are not a trap", the concept has already lost.
I don't ever recall seeing an LLM using them incorrectly, as opposed to simply at high frequency but correctly (although I'm sure some low param or early models must have done so at some point).
Whether it's actually better than OAI/Anthropic offerings, probably not, but if Google has managed to get back to parity, that's good for competition, prices, and increased model performance in the future. Three strong western competitors is better than two.
However, how the front fork rake affect stability is I believe a little complex. I doubt this old article is the last word on the subject, but it's a great read nonetheless, and note especially the ultra-stability of the reversed fork bike!
https://physicstoday.aip.org/features/from-the-archives-the-...
> That’s when you’re an established scientist. If you’re new in the field then this is the most exciting time you could wish for - an opportunity to make a name for yourself.
s/scientist/mathematician/g
There are plenty of fields of research where AI is not nearly as destructive as this, currently. Most experimental science is pretty safe for a while.
I suspect that projects that run hot and fast with LLMs will be very much like driving your car at 250 kph to the shops. You might get away with it briefly, but you'll ultimately crash and burn. As with all things -- the obsession will fade soon enough, and agentic coding will become just another tool, where those who use it well will be valued. At least, so I hope. We will see, I guess.
(The poster I was replying to was suggesting that their departmental users would go over their storage limits for metadata alone, even if they used WebDAV for attachments -- but that seems to be incorrect from my own experience, and everything I can find online.)
If you don't think it's a little ironic to be publishing your xray diffraction patterns to support a model that was only conceived by illicitly viewing those unpublished xray diffraction patterns ... well, I don't know what to say. Perhaps gut-punch would be better than ironical? But Franklin never knew that Watson and Crick had viewed her results prior to forming their model, so she never realised just how much Wilkins had punched her in the gut.
Per Watson and Crick 1953: "We have also been stimulated by a knowledge of the general nature of the unpublished experimental results and ideas of Dr. M. H. F. Wilkins, Dr. R. E. Franklin and their co-workers at King’s College, London." Kinda putting it mildly there, don't you think?
Per Franklin and Gosling's back-to-back publication, 1953, after establishing the molecular features of DNA from their diffraction patterns: "Thus our general ideas are not inconsistent with the model proposed by Watson and Crick in the preceding communication."
Ouch. Well, yes, of course they were not inconsistent -- Watson and Crick took their dimensions exactly from Franklin and Gosling's work in the first place!
Yes, Franklin had an ego, but this was ultimately hers (and Gosling's) research area to pursue. Her approach of obtaining data to then build a model (the way we still do with structural biology!) is hardly something to dismiss. And, after all, there was an agreement that DNA structure would be worked on solely by the King's College group, and not by Watson and Crick at Cambridge. Franklin had no reason to assume that that was being broken, or that she didn't have the time to pursue the structure via a rigorous scientific pathway. Most people forget that the only supporting evidence that the Watson-Crick model was correct, and not simply another spurious model, was from Franklin and Gosling's paper in the same issue of Nature.
From Zotero's site:
Data syncing is free and unlimited, and it can be used without file syncing.
Looking at my own Zotero account, I can confirm that all metadata storage is free and not counted (I am using none of my 300Mb storage in my account according to zotero.org, despite syncing metadata for several thousand bibliography items). The only storage Zotero seems to count is attachment storage, and that's all synced via my WebDAV.
What am I missing here?
What on earth makes you think that you can't adopt this exact approach with agentic coding??
This is like saying that you shouldn't drive a car around suburban streets, because the maximum speed it can do is in excess of 250 kph. You absolutely can (and arguably should) take agentic coding slow and steady, and build software the way you always did. Like using a car to get to the shops at 50 kph, you'll still get there much faster than if you walk.
There seems to be this pervasive false dichotomy about software currently: that it's either lovingly hand-tooled and crafted and perfect; or that it's a vibe-coded one-shot sloppy-slop-slop-fest of spaghetti code.
There is a middle ground, where rigorous software project management and careful architectural guidance and oversight continues, but agentic coding takes away much of the coding drudgery. It takes time, and it's not even remotely one-shot, but it's still way faster than coding everything by hand. From what I can tell, this quiet approach is where most agentic coding effort is going currently -- it's not flashy, it's not sloppy, and mostly you won't even notice.
I have many issues with Zotero (which has been dumbing down at the expense of power users for some time) – but easy private sync is definitely not one of them.