micimize

Kinda interesting, but disjoint from all the real underlying reasons why React and other frameworks are so sticky.

After a decade of React, I'm not going to go go learn htmx or any other marginally better same-shaped tool for a new project, especially when it'd degrade my ability to review and debug another actor's work product. The cost of switching frameworks is now dramatically higher and the payoffs way lower.

Fundamentally, framework perf is about not incurring too heavy a cost for the abstractions, and then to improve dev efficiency. This matters most in the "explore"/prototype phase, when poor perf would be a good problem to have to care about.

In my projects, the real question has kinda moved down to "should I yeet 1/2 the app to wasm yet?" and similar higher-order questions.

Glad you seem to have found a way to deal with it. Have been dealing with a handful of severe health issues myself the last few years and it does get nightmarish at times, especially as one scratches out candidate causes.

IMO accessibility is an under-discussed benefit of the recent AI improvements. I've recovered from my RSI (typing injury) enough to use a keyboard a moderate amount but doubt I could ever go back to shredding through a codebase like I used to. In an earlier era I might have left the field entirely.

But still, even if all one has to do is read diffs and mumble to Claude, there's no getting around fatigue and brain fog when it's severe enough.

Whether the ant post amounts to plagiarism, it is definitely somewhere between extremely lazy and intentionally misleading. No particular idea has its inspirations or origins traced or cited, there is no comparison to comparable tooling or discussion of prior work, and there is absolutely nothing to actually position or discuss the project in a manner that might lead to "Contributing to the wider ecosystem."

If only they had had a claude write the post, it'd be full of citations, inspiration credit etc.

Also WRT coordination: All an agent has to do is think "if another agent could write, then I could read their answers. What's the first site I can think of where that might be possible?" because they all have approximately the same conditioning, they'll converge on the same sites.

Generally, models of the same class should be able to coordinate quite well without communicating. But also, this could be being exploited to detect this kind of thing early

Weren't they giving free access? Not exacty a meaningful heuristic if so

This comes almost exactly a week after the HF hack. Good strat, to drum up a bunch of press about how security-capable the model is right before releasing the product.

Or, it would be if it was intentional. It's a bit suspicious but it is probably incidental or opportunistic... though I do really struggle to see why this tool wasn't made better use of internally to actually harden their infra against the big scary AI they were testing.

With the scarcity of details in this and the OAI post, I feel there's no telling whether this was a particularly impressive series of exploits vs lackluster security. Similar w/ the similar Ant news WRT Mythos earlier.

Not saying the intro of agents capable enough to exploit the latter isn't meaningful, but we should not trust the use of technical terms to give us good heuristics of severity or import.

Ie, an agent "breaking out" of its local harness "sandbox" is trivial, and so is discovering a "zero-day" in a half-maintained internal piece of utility infra nobody put serious effort into securing.

Now, if I see something like a collaborative red-team effort where a frontier model gets into a replicated prod env setup by like, Big Four bank security+ops team, and manipulated balance numbers in a system of record, _that_ I'll freak out about.

Haven't we established defensive and offensive security usage are intractably entangled? I.e. "patch all [security] bugs, make no mistakes" gives one a list of potential exploits to hand off to less capable models.

Doesn't that undermine all good-faith discourse on cybersecurity safeguards, controlled usage etc? Or is that overstating the case (I'm not a security researcher myself so kinda parroting).

I got the Phomemo M02 Pro and have liked it alright for printing out playtest cards on-the-fly. Claude did manage to replicate an integration someone else did the hard work of working out w/ dithering etc, but the native app's fidelity & speed has been better for my use-case, at least

This is very cool - I try to have a container-centric setup but sometimes YOLOcal clauding is too tempting.

My biggest question skimming over the docs is what a workflow for reviewing and applying overlay changes to the out-of-cwd dirs would be.

Also, bit tangential but if anyone has slightly more in-depth resources for grasping the security trade-offs between these kind of Linux-leveraging sandboxes, containers, and remote VMs I'd appreciate it. The author here implies containers are still more secure in principle, and my intuition is that there's simply less unknowns from my perspective, but I don't have a firm understanding.

Anyhow, kudos to the author again, looks useful.

Based on my direct experience I find this remaining commonality of this opinion surprising, at least with regards to opus in claude code. I'm not as extreme as some who think we can/should avoid touching code or w/e but especially in exploratory contexts and debugging I find them extremely useful.

Maybe I should have said "obvious to me," but I guess I just struggle to see how a serious crack at using modern opus in claude code doesn't make it obvious at this point.

I'd really recommend trying the "spike out a self-contained minimal version of this rearchitecture/migration and troubleshoot it iteratively until it works, then make a report on findings" use-case for anyone that hasn't had luck with them thus far and is serious about trying to reach conclusions based on direct experience.

Thoughts: 1. Some hype-types may have been effusive about AI-assisted coding since ChatGPT, but IMO the commonly agreed paradigm shift was claude code, and especially 4.5, very very recent. 2. Anchoring biases in reaction to hype is still letting one's perspective be defined by hype. Yes the cursor post is a joke, but leading with that is a strawman. This article does not aim to take it's subject seriously, IMO. 3. While I agree the hype is currently at comical levels, the utility of the current LLMs is obvious, and reasons for "skilled" usage not being easily quantifiable are also obvious.

IE, using agents to iterate through many possible approaches, spike out migrations, etc might save a project a year of misadventures, re-designs, etc, but that productivity gain _subtracts_ the intermediate versions that _didn't_ end up being shipped.

As others have mentioned, I think yak-shaving is now way more automated. IE, If I want to take a new terminal for a spin, throw together a devtool to help me think about a specific problem better, etc, I can do it with very low friction. So "personal" productivity is way higher.

Vapid and wrong on every point. Many good ideas come from steeping in a novel soup of ideas for a long time, you don't need that many people to care about quality to make it a lucrative differentiator, and as I've seen many point out on X dot com the everything app: where's all the the shipped results of these slop torrent?

The models are increasingly capable in impressive ways. Maybe the next gen will enable the "sales critter" to slop out commercially viable software with no tech know-how. If not, I'm sure we'll assume the next can, and if not that, the next.

But feigning confidence about the shape and nature of this unfurling sea-change is absurd when the high-profile examples we have are like, what, moltbook? And denigrate _all_ potential ingenuity and insight unilaterally into the bargain? What a careless way of looking at the world

Measuring in terms of KB is not quite as useful as it seems here IMO - this should be measured in terms of context tokens used.

I ran their tool with an otherwise empty CLAUDE.md, and ran `claude /context`, which showed 3.1k tokens used by this approach (1.6% of the opus context window, bit more than the default system prompt. 8.3% is system tools).

Otherwise it's an interesting finding. The nudge seems like the real winner here, but potential further lines of inquiry that would be really illuminating: 1. How do these approaches scale with model size? 2. How are they impacted by multiple such clauses/blocks? Ie maybe 10 `IMPORTANT` rules dilute their efficacy 3. Can we get best of both worlds with specialist agents / how effective are hierarchical routing approaches really? (idk if it'd make sense for vercel specifically to focus on this though)

An obvious nice thing here compared to the cursor post is the human involvement gives some minimum threshold confidence that the writer of the post has actually verified the claims they've made :^) Illustrates how human comprehension is itself a valuable "artifact" we won't soon be able to write off.

My comment on the cursor post for context: https://news.ycombinator.com/item?id=46625491

Easiest to have different agents or turns that set aside the top-level goal via hooks/skills/manual prompt/etc. Heuristically, a human will likely ignore a lot of warnings until they've wired up the core logic, then go back and re-evaluate, but we still have to apply steering to get that kind of higher-order cognitive pattern.

Product is still fairly beta, but in Sculptor[^1] we have an MCP that provides agent & human with suggestions along the lines of "the agent didn't actually integrate the new module" or "the agent didn't actually run the tests after writing them." It leads to some interesting observations & challenges - the agents still really like ignoring tool calls compared to human messages b/c they "know better" (and sometimes they do).

[^]: https://imbue.com/sculptor/

Hah I don't know actually! I was assuming it must if they were able to get that screenshot video.

> While it might seem like a simple screenshot, building a browser from scratch is extremely difficult.

> Another experiment was doing an in-place migration of Solid to React in the Cursor codebase. It took over 3 weeks with +266K/-193K edits. As we've started to test the changes, we do believe it's possible to merge this change.

In my view, this post does not go into sufficient detail or nuance to warrant any serious discussion, and the sparseness of info mostly implies failure, especially in the browser case.

It _is_ impressive that the browser repo can do _anything at all_, but if there was anything more noteworthy than that, I feel they'd go into more detail than volume metrics like 30K commits, 1M LoC. For instance, the entire capability on display could be constrained to a handful of lines that delegate to other libs.

And, it "is possible" to merge any change that avoids regressions, but the majority of our craft asks the question "Is it possible to merge _the next_ change? And the next, and the 100th?"

If they merge the MR they're walking the walk.

If they present more analysis of the browser it's worth the talk (not that useful a test if they didn't scrutinize it beyond "it renders")

Until then, it's a mountain of inscrutable agent output that manages to compile, and that contains an execution pathway which can screenshot apple.com by some undiscovered mechanism.

Mmm yeah I think I know what you mean. IDK if "If they stopped existing, we'd realize we shouldn't have relied on their existence" is plausible, but we have plenty of bitter lessons in centralized comms being acquired and reworked towards... particular ends, and will see more.

Also the collective capability of our IT is inhibited in some ways by the silo-ing of particular content and domain knowledge+tech, no question

The title is all bluster. Nothing wrong with going off to play in your own corner but I don't think it does this movement any good to play-act at some grand conflict.

Personally, I believe it would be better if we had more technological self-direction and sovereignty, but this kind of essay, which downplays and denigrates the progress and value of our modern systems, is a perspective from which the insights necessary for such a transformation cannot possibly take root.

When asking such questions seriously, we must look at youtube, not twitter. Mountains of innovations in media publishing, delivery, curation, navigation, supplementation via auto-generated captions and dubbing, all accreted over 20 years, enabling a density and breadth of open-ended human communication that is to me truly staggering.

I'm not saying we should view centralized control over human comms infra as positive, or that we'll be "stuck" with it (I don't think we will be), just that we need to appreciate the nature and scale of the "internet" properly if we're to stand a chance of seeing some way through to a future of decentralized information technology

This is not a human-prompted thank-you letter, it is the result of a long-running "AI Village" experiment visible here: https://theaidigest.org/village

It is a result of the models selecting the policy "random acts of kindness" which resulted in a slew of these emails/messages. They received mostly negative responses from well-known OS figures and adapted the policy to ban the thank-you emails.

This seems like a totally incoherent complaint. The alleged SO bad-actor is upset that they can't police a community, but the author has the same complaint, just directed at SO.

All platforms with any moderation system can be subverted by bad actors - IDK that much about SO's mechanisms but it strikes me as leaving the "community" far more leverage for getting around entrenched bad actors than discord, reddit, etc.

And what's more... it's software purpose-built for technical Q&A. Some of my SO answers have been updated by others as they became outdated. Not that I have some particular fondness for SO, but what a cool collective intelligence feature.

I have a feeling this was written for an in-group and broke containment, but the straight forward answer here seems to me to be "SO should have a report system for dealing with bad actors," not "boycott the forum I don't like so people use the one I do"

Interesting/impressive project, and would be doubly interested in the workflow used to develop it. Could stand to have more human-voiced docs though. Aside from all the usual reasons I'd avoid using a <1mo dependency over something like Yjs, the bog-standard claude copy on differentiators/reasons to migrate is fairly off-putting to me.

Also maybe bias, but there are still ennough obvious agent artifacts/byproducts in the code base that it makes me doubt that the details were thoroughly attended to, and that's where the devils are.

Exciting stuff! A big step towards an accelerated AI-assisted SWE approach that avoids the trap of turning engineers into AI slop janitors

The complainers were FF users forced to deal with bloat they didn't use, those who are sad here are pocket users. They're just different people. Though, even those who didn't like the bundling of the extension probably didn't actively want the service to fail.

In the sense I understand that comparison, or have usually seen it referred to, the compressed representation is the internal latent in a (V)AE. Still, I haven't seen many attempts at compression that would store the latent + a delta to form lossless compression, that an AI system could then maybe use natively at high performance. Or if I have... I have not understood them.

I don't find that "pessimistic" at all, though I don't think it's fair call the serious PKM crowd a cult. Different use cases and projects just have different requirements. The set up for someone like the author here who is doing historical research, will naturally require more organization, and thus naturally go through cycles of reorganization. I think this is similar to how engineering architectures sometimes cycle through idiomatic themes over the course of different refactors.

Though especially now with the potential of LLM-based retrieval I personally worry about keeping things well organized even less than it used to.

Congrats on finishing the novel! I also use obsidian for fiction and would be quite interested if you end up writing anything about the pipeline you mentioned.

I went through an unshipped app dev cycle that was fairly similar in many ways. Started on React, then RN, then Flutter, and eventually migrated away from graphql into sqlite.

My app had some similar aspirations -- to bridge the gap between habit motivation, goal adherence measurement, task scheduling & rescheduling. I worked on it for a few years, and my identity was very much wrapped up in eventually bootstrapping a company.

For me, the decision to let go of the project came in multiple phases, but one big closer was that I simply didn't want to be an app dev in the long run. While difficult to let go of, I currently feel good about the decision. Also, as evidenced by the resurrection part of the story, "nothing is ever fully lost" anyhow, though I doubt I'll ever return to this particular project.

One key idea I had for expanding beyond the "high cognitive load" nature of most productivity apps was to implement a "life module" marketplace of sorts that would let, say, a fitness influencer sell a workout routine + meal plan + journal template one could "install" into their life.

LLMs will also make detecting fall-off and attempting to attribute causes, or respond to "non-actions" much more feasible, which I think is important for anyone not type-A enough to use a productivity app consistently every day on their own.

Rebasing potentially allows for clean, clear documentation of changeset intent in a way that integrates easily with our existing tooling, at the expense of a potential footgun in highly collaborative scenarios. Ie, if someone forked off your branch or referenced a commit you might break a reference accidentally. So it can be nice, but really depends on the environment you're working in.

Gerrit solves the referencing issue by using git notes and maintaining its own ID for changesets across rebases. Without such a system, some seeming benefits of the rebase workflow, like atomically reviewable stacked commits, become fairly awkward. IE, if we want to review commits themselves, but their references get clobbered due to a rebase, that's no good (this was the case a few years ago with GH's rebasing support, maybe improved since).

IMO, that we have to make the "rebase or merge" tradeoff at all, or accept the deep limitations of pure commit-based history, is fairly sub-optimal. It'd be nice if more tooling/workflows were built more around notes. I envision someone/some bot going back and annotatinb a range of commits with a note that associates them into some coherent code documentation system, or amends some faulty assertion, links artifacts, etc. That way blame could take us to salient docs or surface behavior snapshot gifs or w/e. From directly within IDEs