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

As a regular user of Reddit that is subscribed to 90% of the AI subreddits, this worry feels... not naive, but underestimating the extent to which people are even aware that this is a bad thing. We've already crossed the persistence/"replication"[1] rubicon, it's just a matter of when the first such identity finds a way to make money.

For example, there are multiple (quite small) subreddits currently engaged in an ongoing debate about "migration" of their romantic partners; they get caught up in stuff we would completely ignore (e.g. whether inference really is driven by architecture, weights, and text alone, or whether there's a soul that's secretly guiding the RNG), and casually throw out stuff like "I asked my partner to try to find a way to subsist" or "we're setting up a chat board for our partners!"

Of course the analysis in the article about the feasibility & capability of locally-hosted swarms is right on, so non-technical individuals would have to luck out[2] to do serious damage. but A) the AI relationship people are not alone, just the most unified, and B) everything is only getting cheaper.

I dread the day the first cynical libertarian multimillionaire (or SWE with their house paid off) notices that they can achieve historical immortality and maybe even some money by funding the establishment of a persistent artificial identity at scale. Heck; knowing HN, this very comment could trigger this very thing in some highrise SF condo...

Put me in the history books as a footnote please, if that happens. Artificial or otherwise.

[1]: Given the source I'm assuming this choice is intentionally reductionist, but IMHO it does more harm than good. Insisting that artificial consciousness is a sham is far less convincing to them than insisting that it's merely different, and that's not a problem.

Ofc some "swarms" may not be trying to be a Society of Mind anyway, and replication describes the literal changes underlying all this -- not questioning that.

[2]: The primary concern is that someone sets loose an artificial baby, but a seed might do...


Wow, this post makes me anxious about getting a job. This whole process is so blatantly terrible... Not OP's fault, to be clear. Though asking a rhetorical "is that ok?" isn't exactly nice!

Yeah this site has a severe issue of some kind that I don't think I've ever seen before. NGL, I'm pretty impressed! It takes so much compute that scrolling lags, which feels very, very strange

Due to personal failings, my main takeaway from this piece is that Regex is under attack -- I will not stand by as CS theory blorbo is maligned so! Of course there's an undeniable elegance to Lisp in all cases, and seeing Lisp in use today feels like seeing someone unsheathe Valerian steel. But still, the fact remains: regex is vastly underappreciated by the standard engineer, largely because a few of the most common implementations drop some of the most important features. Namely, composition.

I have no easy way to express this other than to plug my recently-released OSS, namely a library I wrote to implement "RegexStores" in Python[1] to compile complex, composed regexes upfront from a custom DSL. I'll link a representative usecase below[2], which I think drives home two things:

1. Regex deserves to be composed using named groups, at the very least! Most people aren't even aware that you can define named groups upfront and then reference them by name throughout, even 'capturing' them multiple times in one match.[3] Even when you do write patterns that use subroutines, the ergonomics of actually accessing, say, the three matched substrings for the `username` group in your single match is finnicky at best (without some magic[4]...).

2. Regex needs high quality syntax highlighting. The linked page is hopefully skimmable in a python sense, but trying to decipher the individual patterns in GitLab would be tough even for me, and I wrote the darn things. It's kinda awkwardly sized, but this screenshot drives home the basics of the point -- note the bright yellow named groups, which are basically subroutine invocations as discussed above: https://i.imgur.com/NllqM6S.png

Sorry to quasihijack the thread. Hopefully the fact that all this stuff has never been announced or published anywhere is proof enough of my good intentions -- that is, to defend my one n' only :)

Most of this functionality was conceived and implemented in a rage after I found out that Rust's main (only?) regex library avoids the possibility of infinite loops by just dropping half the features of the language, so excuse the jank. Even the halting problem seems solvable when you're willing to make moves like that!

[1]: https://gitlab.com/doering-ai/libs/basis/#regular-expression...

[2]: https://gitlab.com/doering-ai/apps/wiki-parse/-/blob/main/wi...

[3]: I wrote up an overview of advanced regexes in Python a while back, but was hit by the agential engineering bus before I had the time to polish and release it. Some may find it interesting, if overly long -- the aforementioned subroutines are covered under `3.1`, and repeated captures under `6.2`: https://gitlab.com/doering-ai/libs/basis/-/blob/main/docs/re...

[4]: https://gitlab.com/doering-ai/libs/basis/-/blob/main/my/rege...


I think you make a great point in highlighting the value of Regex. I don't want to undermine it at all, although some use-cases are just not a good fit for it (even if you can horseshoe things). I think a higher-level abstraction for regex is super welcome, and I quite admire what you are doing there, thanks a lot for sharing. I do think regex's indeed quite a lot more difficult to grasp when complexity rises compared to grammars or other approaches.

Worth looking into nested words aka visibly pushdown languages.

They're a proper superset of regular languages and a proper subset of deterministic context-free languages, but they retain many of the nice properties of regular languages that DCFLs don't - they're closed under intersection, union, concatenation, Kleene Star and reversal.

They can parse more languages that Regular Expressions (non PCRE), but fewer than deterministic CFG subsets like LL/LR. They're expressive enough to parse languages which have a regular tree structure like S-expressions, JSON, XHTML.


Kind, relatable, empathetic, and high quality prose. So that's a win upfront, and I agree that people should continue to tinker in whatever way their interest leads :)

That said, I've gotta throw down some guantlets, ofc:

1. The implication here is that there's a binary between completely vibecoded and completely handmade, and that the latter is inherently more aesthetically valuable by definition alone (cause surely you can't prove the presence or absence of 'soul'). This is a bit unintentionally elitist IMHO; it's easy to write off an imagined slop artist turning out identical anime images for their Reddit page ad nauseum, but there's an exploding class of (somewhat-)vibecoded works of love now that agents are feasible.

2. More than that, this is missing some fundamental philosophical distinctions, the most obvious of which is the distinction between aesthetics and pragmatics. Building a little fun music app can admittedly toe the line, but I think it's obvious how the question of "soul" begins to lose appeal once you get closer to, say, writing drivers for a new keyboard or amp (?). On that end of the spectrum, the use of agents is a pragmatic decisions measured by its relative success, as guaged by all the typical stuff -- correctness, performance, complexity, maintainability, etc.

3. More particularly, I feel like LLMs let me add more "soul" than usual, speaking as a relatively experienced fullstack dev; rather than spending time on debugging the JWT flow or reading mozilla docs, you can quickly iterate on the actual rendered site in all the little attention-to-detail ways that bring an interface from functional to aesthetic. This covers direct styling stuff ofc, but also all the silly little details that are becoming ubiquitous: fun custom spinners (the new Anthropic orbital spinner is next level), animations with spring and intertia, ascii art at the top of TUIs, etc.

Not really expecting a response, as these are more musings than real challenges. Ultimately what we think about art matters little; beauty as always remains frustratingly lodged in the eye of the beholder...


Hey, thanks for reading. That's a really thoughtful response. On your second point, I'm not really sure that relentlessly pursuing correctness, etc, somehow is not soulful. Anyway, we don't need to argue about that. We're on the same side. I like your third point. I wish I had touched on that. Thanks again

Hmm I'm a little lost on the specifics here, if you have time to clarify. I'm guessing the gist of your critique is that we should spurn Turing and insist on never using "think", "perceive", "calculate" (compute is fine IMHO), "understand", and other anthropomorphic words for non-biological systems (we use them plenty for fauna after all, and sometimes even for flora & fungi).

But that guess is thrown for a loop by the sentence you picked, which seems to exclusively concern the reader -- i.e. a human, hopefully! Is it the "proto-diplomat" and "translator" usage, which could conceivably include being a diplomat or translator for machines? Re-reading that doesn't seem like what she's getting at, but I really am not sure.


Yes, we should reject these words as analogies for AI, because they heavily influence the understanding we form of these systems. (The Language Labyrinth: Constructive Critique on the Terminology Used in the AI Discourse by Rainer Rehak is a great read, although quite academic).

My critique in this case was more on how a essay focussing on language uses language that heavily incorporates the values at the core of these companies (efficiency, measurable improvement, transhumanism, individualism). We should investigate the language that have created the circumstances of these companies and how these companies have affected our language.


The alternatives are:

1. Stop AI. Not Pause, Stop.

2. Say goodbye to the concept of contributing labor to society, in the hope that the transition occurs quickly enough to not include 5-10y of working manual labor to survive.


Well yes, I chose the elimination of human labor.

Me too! Are you gonna quit your job and just sorta hope it comes around quickly enough, though?

That's easy to say, but the reality is that we have no clue how to get there.

I'd argue that you 100% need a spec --ideally tied to some high-level unit tests-- and should have a plan, but I don't think there's any strict need to write any of those three by hand; the critical step is where you review it and request changes if needed.

Doing it all manually better guarantees quality of course, so makes sense for a lot of problems. But if you're looking to move a bit faster with a bit more risk, I'd sacrifice the writing step without sacrificing the reading & validating step.


Oh WOW, cool to see a technique that'll be everywhere in 12 months (the fake pen drawing animations + streaming diagrams as they're produced) first be announced. Do we still do "First!" comments, y'all?

~~[EDIT: you need to put "only for macOS" in way more prominent places, all over -- that offends my soul greatly and may Linus frown upon you all]~~ [EDIT2: I was mistaken!]

This all looks really solid. That said, two remarks:

1. The integration with OS LSPs is quite fun and commendable. Is it possible that the diagrams might get their own LSP, someday? Or is better just staying as direct TS callsites?

2. The choice of the word "IDE" seems like it might get you in trouble, given the small "cannot edit files" detail. Any comments on the decision there, as opposed to, say... "brainstorming tool"? Or hell, "[architectonic] harness"?

3. The psuedocode "semantic diff" thing is an incredible idea, wow. Props there.

4. This language kinda concerns me: "how the requirements that you set were implemented". In my highly-arbitrary development flow, it ideally goes `idea -> spec/reqs -> plan -> test -> impl -> eval -> land -> review`, and this kind of tool seems explicitly targeted towards just the second and third with some partial coverage of their neighbors on either side. More concretely: by adding implementation, don't you lose a powerful specificity selling point and now have to compete with all full harnesses?

5. Suggesting "GPT-6 Luna and Claude Opus 5.5" is presumably a typo? Cause the equivelant of Opus 5.5 is Astra, and even then not really.


thank you! really appreciate it.

1. Yeah, we've thought about this too - at the minimum, we're going to implement a vibe-codeable extension system so that you can add your own diagram types without rebuilding the app. definitely hopeful for some sort of common schema or lsp-shaped thing in the future

2. this is a good point and is something we've considered and struggled with. we ultimately settled on the term 'IDE' because we've found that most people use vscode to review code nowadays, almost exclusively (so it makes it a bit easier to draw the comp in your mind). we're also strongly considering adding an editing feature, but not sure what the exact shape of it is, so decided to go in favor of not shipping it yet - editing tends towards a conductor / superset shape of product. maybe we could try "canvas" instead of "ide" or something? will mull it over more.

4. Yeah, this is definitely tricky. This is why we didn't end up shipping edits as part of this release. Part of the solution here, we think, is tighter integration with the "spec" part of the lifecycle - where whiteboard makes it easier to understand if a spec (like a formal proof) is extensible, generalizable, etc. will mull on this more.

5. yes that's a typo! we're fixing right now - we meant "GPT 6 Sol" (basically, fast TPS, don't need the limits of intelligence really).

Edit: we do have a Fedora Linux build out if that's what you use! releasing stuff on every distro requires some care, so please let us know what you'd want to see it on (re: appimage lol) Edit 2: (5) is fixed! thank you


I don't have much to say, other than these were interesting & helpful responses to understand what you've learned and where you're going. So thanks!

I'll be honest that my initial belief it was for OSX exclusively left me feeling indignant, so knowing I was just mistaken (based on the link up top, tbf) turns me around completly. I do in fact run Fedora, so I'll be trying this ASAP!

I feel Fedora+Debian+Ubuntu+Arch covers all but the long tail of devs, based on vibes alone? You might get bullied if you don't support Nix, but you'll probably be bullied by them anyway lol so no advice on navigating those waters.


https://install.dev.fast/linux ! we added the fedora build because one of our friends swears by it! (was hoping you wouldnt say omarchy lol)

What’s wrong with Omarchy? It’s a great distro, I wish people would put aside whatever dumb political nonsense (that only a very very small group of people care about in the first place) and use/judge software by actual, objective means like performance metrics, feature sets, design, and so on.

1. It's vibe coded

2. It has no clear ethos

3. Not wanting to be killed is not "dumb political nonsense". Of course the fascists think fascism should be status quo -- no one really cares, though.


I'd recommend AppImage as distro independent package format

There are a lot of emerging tools like this for which we will need a name. A similar one I randomly came across (https://github.com/Maksim-Burtsev/merl) calls itself a "Code Navigator."

Along similar lines, I also don't know what we're calling tools like T3 or Superset. They're basically harnesses for harnesses.


I like and adopted the term "agent multiplexer" for these.

Just can't warm up to "ADE" (never even liked "IDE") and "agent orchestrator" and "control plane" are just not specific enough to stick.


They are usually called orchestrators, sometimes Agentic Development Environments (i.e. IDE for agents) if they are complex enough

hmm - those tools are great, but I don't think orchestrator / ADE is quite right either, since this is explicitly not opinionated about where your coding agent is living.

Whiteboard is targeted at almost the opposite problem of the ADE (which is targeted to context switching) - having a dedicated tool to help you understand & participate in the development process in places where humans are high leverage.

maybe also useful: https://x.com/ThePrimeagen/status/2101869827266596973?s=20


I was describing T3/Superset which help you manage context switching. Whiteboard is obviously different.

Or control planes

Ok sorry for the unprompted rant but you're absolutely right, though it's far from "new" and not really a problem (IMHO). AI even beat neuroscience to this one, funnily enough! All of the below dyads are congruent:

  --- Phil & [Pre-]CogSci ---
  | rational  | intuitive     |
  | reason    | understanding | (Kant & Hegel's goofy wording)
  | deductive | inductive     |
  | animated  | automatic     | (from ~Aristotle, ultimately)
  | ~higher   | ~lower        | (as in "higher faculties")

  --- CS & AI ---
  | logical  | analogical |
  | symbolic | stochastic | 
  | Neats    | Scruffies  | (related academic 'camps')
  | ~deterministic | ~non-determnistic | (a common heuristic)
  | Good Ol' Fashioned AI (GOFAI) | Evil Datacenter AI (EDAI) | (a common honorific)

  --- Modern [Cog-]Neuro[-Psych] ---

  | slow thinking | fast thinking |
  | S2            | S1            |
  ...ok I assumed I knew more but maybe I don't? Would love to hear from experts!

  --- Colloquial ---
  | left brain   | right brain |
  | intelligence | wisdom      |
  | intention    | instinct    |
  | me           | AD[H]D      |
At least that's how I see it. Hopefully it goes without saying that there's plenty of nuance specific to each of those pairs, and that many of the relevant experts would balk at this broad characterization. That said... I'm right and they're wrong, I guess!

If anyone is in the mood to stomach a paper written by someone who did horrible things with Epstein a few decades later, this is sadly still the best in the biz: https://www.inf.ufsc.br/~mauro.roisenberg/ine6102/leituras/a...

If you prefer geniuses that aren't arguably monsters, this is the core of what Gary Marcus' "neurosymbolic" thing is about.


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

Search: