I felt literal pain. Not kidding.

There's something to investigate here.

Made me notice I'm actually exposed to very similar crap on other places. Scary.

yes, the good news is that once recognized the pattern we can work in the opposite direction

Agreed, conceptually.

BUT. For 99% of tasks I'm totally certain there's people out there that are orders of magnitude better at them than me.

If the AI can regurgitate their thinking, my output is better.

Humans may need to think to advance the state of the art.

Humans may not need to think to just... do stuff.

> For 99% of tasks I'm totally certain there's people out there that are orders of magnitude better at them than me.

And LLMs slurped some of those together with the output of thousands of people who’d do the task worse, and you have no way of forcing it to be the good one every time.

> If the AI can regurgitate their thinking, my output is better.

But it can’t. Not definitively and consistently, so that hypothetical is about as meaningful as “if I had a magic wand to end world hunger, I’d use it”.

> Humans may not need to think to just... do stuff.

If you don’t think to do regular things, you won’t be able to think to do advanced things. It’s akin to any muscle; you don’t use it, it atrophies.

> And LLMs slurped some of those together with the output of thousands of people who’d do the task worse, and you have no way of forcing it to be the good one every time.

That's solvable though, whether through changing training data or RL.

> And LLMs slurped some of those together with the output of thousands of people who’d do the task worse

Theoretically fixable, then.

> But it can’t. Not definitively and consistently

Again, it can't, yet, but with better training data I don't see a fundamental impossibility here. The comparison with any magic wand is, in my opinion, disingenuous.

> If you don’t think to do regular things, you won’t be able to think to do advanced things

Humans already don't think for a myriad of critical jobs. Once expertise is achieved on a particular task, it becomes mostly mechanical.

-

Again, I agree with the original comment I was answering to in essence. I do think AI will make us dumber overall, and I sort of wish it was never invented.

But it was. And, being realistic, I will try to extract as much positive value from it as possible instead of discounting it wholly.

Only if you're less intelligent than the average. The problem with LLMs is that they will always fall to the average/mean/median of information.

And if the average person is orders of magnitude better than you at thinking, you're right... you should let the AI do it lol

Your comment is nonsensical. Have you ever used any LLM?

Ask the LLM to... I don't know, to explain to you the chemistry of aluminium oxides.

Do you really think the average human will even get remotely close to the knowledge an LLM will return to such a simple question?

Ask an LLM to amend a commit. Ask it to initialize a rails project. Have it look at a piece of C code and figure out if there are any off-by-one errors.

Then try the same to a few random people on the street.

If you think the knowledge stored in the LLM weights for any of these questions is that of the average person I don't even know what to say. You must live in some secluded community of savant polymaths.

"they will always fall to the average/mean/median of *information."*

Do you think that the average person can get a gold on the IMO?

> Humans may not need to think to just... do stuff.

God forbid we should ever have to think lol

It is concerning how some people really don't want to think about some things, and just "do".

Very Zen of you to say

Imagine if everyone got the opportunity to work on SOTA. What a world we would be.

Unfortunately that’s not where we’re headed.

We've never been there.

With AI and robotics there may be the slim chance we get closer to that.

But we won't. Not because AI, but because humans, of course.

Cool project! Will surely copy ideas from it :)

A general question for the room: where's the tipping point where you need a "proper" backend, in a different language, with all the inconveniences of possible type safety issues and impedance mismatches?

Because I feel like for 90% of small-medium projects it's just good enough with all the backend stuff within the same Next.js process as the front-end. I just do "separation of concerns"-ish with the code organization and funnel all communication with something structured and type safe like tRPC.

Feels separate enough but very pleasant to work anyway.

Am I doing it wrong?

You're not doing it wrong.

For most CRUD apps, Next.js + tRPC is the right call.

My tipping point was long-running tasks (OCR, AI processing that takes 30+ seconds) and wanting to scale backend compute separately from frontend serving.

If you don't have those needs, stick with what you have.

Thanks for the answer! I've hit those tipping points myself in exactly the same scenarios (OCR and AI). For me, ends up being hacky or just decoupled (independent job runners). Makes sense to have a proper monolith backend for these.

Congrats on the launch again!

I really appreciate your comment, never hesitate to reach out to me if you have any concerns, you can find my info in the repo.

dbos.dev should take care of long-running tasks, but I haven't tried running too many tasks yet as my other bigger projects all use Temporal

A question for the heavy Emacs users:

What's your take on opinionated distros like Doom Emacs or Spacemacs?

I've been doing my daily journaling and task management on Emacs for while now, using Doom Emacs. Rationale was that it'd be mostly pre-configured to a sane standard and that, for actual text editing, I'm a long time vim enjoyer, so evil mode is great there.

However I always feel that when I go beyond the safe borders of the preconfigured, leader-key-accessible realm, I'm quite lost. I don't have good intuitions on how to interact with more raw parts of the system.

And I do want to venture further, so I'm feeling I need to get re-started with one of the recommended tutorials/books.

Should I start fresh Emacs install instead?

PS: I've coded in a bunch of lisps in the past and I have already done a bit of customization on top of Doom, so I sort of know my way around, but I'm just not comfortable I guess.

My petty opinion is that distributions which disable the menu bar are bad, distributions which use an edgelord dark theme are bad, and distributions which do both are terrible. Where Doom in particular is concerned I dislike the fact that it starts with Vi keybindings by default (I quite disfavour modal editing, there's a reason I switched away from Vim after 5 years) and that it changes the 's' binding so I can't even rely on my muscle memory.

I've tried both Spacemacs and Doom (and others like Witchmacs and Bedrock) and now I'm just using my own 800 line init.el (which does include comments and whitespace so the actual LOC will be lower) and 110 line custom.el (if you set the custom file to a different file than your init then using customize to change settings won't mess things up if you manually edit your init).

If you really like Doom you can try reading its code base, if it's just too much then maybe it would be better to try setting up your own configuration from scratch.

I think some of these are unfair criticisms, because they are things that can be trivially changed. E.g. disabling evil mode or changing the theme are one-line modifications in the Doom config. After all, any opinionated Emacs distro has to make some choices otherwise there would be little point in anyone using one.

For me the issues with Doom are (a) the complexity as a whole that it introduces, and (b) so many things are already installed/configured that you end up using them without any real "under the hood" understanding which is so essential for customisation.

One tip I read somewhere (possibly from Steve Yegge?) was that it's a good idea to disable the Emacs menu bar - and I agree. The Emacs menu bar is this kind of weird uncanny valley thing. It looks like a normal menu bar, but any time you click one of the items on it, you'll find that you're doing something that actually only makes sense if you're into Emacs already. It won't help you when you're starting out, and once you're up and running you won't need it (but you can ctrl+right click on the buffer to get if you ever feel like you do...) - and, meanwhile, it's taking up space on the screen that you could use for more lines of text.

(macOS users are stuck with the menu bar generally, and that means they're stuck with the Emacs menu bar too. Just ignore it.)

While you're there, get rid of the scroll bars too. They never work properly, and this way you get an extra column or two of text per window.

The Edit menu has undo, cut, copy, and paste. Is that stuff that only makes sense if you're into Emacs already? The Help menu has the tutorial and the manual. Same question. The File menu has open file, save, save as, close, and quit. If you open a file which uses a mode which has options you get a menu showing those options.

I don't think the discoverability of all those things is worth giving up in exchange for 1 more line of text, but of course everyone is different and that makes the world such an interesting place.

Hmm, good question. I had another go, for the first time in years, albeit with experienced Emacs eyes now, so I know roughly what's going on. Still felt like every click just gave me More Emacs Shit, which I remember being the main confusing thing.

Almost none of the options bring up a friendly GUI dialog of the sort you might be accustomed to; you're most likely just plonked back in the Emacs frame, possibly in some new window that opened in some random place, that doesn't seem to work quite like anything you've ever seen before, or possibly in the minibuffer, ditto, plus its own set of additional confusing aspects.

So perhaps the suggestion to just dispense with it entirely (along with the toolbar, which I forgot to mention...) was just the thing that got me over this initial notch in the difficulty curve, the bit where I just needed to give up and accept that Emacs was going to be one of those things that was absolutely not like anything else.

(You're not wrong about the discoverability though. I've been using Emacs for 20 years now and I did find a couple of interesting-looking things.)

> What's your take on opinionated distros like Doom Emacs or Spacemacs?

If you use vanilla emacs without customization, you are going to have a very basic text editor experience. That is fine if you understand that, and understand that you'll need to start adding your own customizations (like enabling eglot for LSP, and company-mode for code completions, etc) in order to get to an experience closer to what you'd get out of the box in an IDE like vscode.

Some people might see vanilla emacs, assume emacs is just a plain text editor, and go back to their fancy IDEs. For them, distros like doom/space would be good for avoiding that initial shock/disappointment.

Another great use for doom/space is to see what is possible. Figure out what bits you like, and then figure out how to enable them in your own vanilla-based config. Essentially window-shopping for your own emacs config.

But in the end, I'd recommend you eventually get to the state I am in: I started with a completely vanilla emacs and then slowly added the bits that I wanted. That way I have only what I want, and nothing that I don't want. I don't get surprised by unexpected features. My breakages are fewer because I use so few packages. My load times are great because I am not loading a bunch of stuff I don't use. I understand everything that is enabled in my config.

You also might want to check out emacs-solo. It's a config that is built based entirely on built-in packages rather than 3rd party packages. I still use some 3rd-party packages like company-mode but it is good to see just how far you can go with the built-in stuff (for example, you probably don't need projectile, you can use the built-in project.el, and you probably don't need lsp-mode, you can use the built-in eglot): https://github.com/LionyxML/emacs-solo

Whatever works for you works. If you want to use your editor for a goal, using the guardrails of Doom is fine. I use a vanilla setup as my base but I've been using emacs since before distributions. If you want to tinker or otherwise learn emacs more deeply, feel free to start from a vanilla config.

Don't use them. A personal config is highly personal, and a distro force someone else's preferences onto you. Even things like how exactly your config is organized.

But ultimately it's all about tradeoffs and what works for you. You don't necessarily need to go beyond your distro, but if you want to or need to, then that's a good sign to try it

I went from Emacs to Vim to Vscode and back to Emacs with Doom, but I still use pretty much all of them. Vscode has copilot, Emacs has org mode, vim is great for light editing.

Vim is the magic that lets me use all of those for what I want without having to change muscle memory, and Doom just happens to aligns with my needs perfectly on that regard.

I think anyone trying to master Emacs within the lines of this article will be trying to bend it to their particular needs and likely will be annoyed at any opinionated configuration.

The answer to your question will depend if you want to add community extensions beyond what Doom integrates or if you want to personalize Emacs by yourself. The latter will work just fine with leader keys as long as you map them, all Elisp should be still available in pretty much the same way. The former will probably be much harder.

I personally use Doom because there are a lot of out of the box optimizations, some don't like how hlissner has brought nix ideas of declarative package management into the mix, but I am a nix user so it makes sense. I also am an evil (heretic) user - Doom is configured from the get go as a gateway from vim/neovim into emacs, and it does that job very well.

I would say use both. You can run multiple emacs configurations, and you could have your vanilla config which you slowly build as well as Doom/spacemacs where you can see what is possible.

They have their place. I started out with Doom and it definitely helped to streamline the beginner phase where vanilla would have felt overwhelming. But, as with you, I soon became frustrated when I wanted to move beyond its default configuration.

I've since switched to Vanilla and I've been using ChatGPT to gradually explain and help me integrate the Doom features that I like, so that I end up with a similar base that I actually understand and which I can deviate from where I want to.

I have tried Doom Emacs in a Debian VM on Windows host, because that was the opportunity to install a new Emacs thing for me (to code while playing a game). There Doom Emacs was not stable. Sometimes it just crashed and one time I even lost a whole function I wrote, because somehow it doesn't do the same backup file thing Emacs usually does. The keybindings were nice, but the stability requirement I have overrules it. So I am back to standard Emacs and currently using evil mode.

I'm in the same boat and curious if other more experienced users have any resources to point to. My anedoctal data point is that after starting with doom emacs and having problems to set it up on another machine i fund out all i needed was a very small configuration file to accomplish my orgmode/agenda usage needs. So all it took was an issue and a clear vision of the goal to find a way through. Maybe it is a healthy approach to keep the complexity manageable to your usage

IMO, they're a great way to get started without having to invest too much time up-front. On the other hand, that was 10 years ago and it's a LOT easier to throw together a usable config nowadays; with LSP + built-in tree-sitter modes, you no longer need 3 packages per language plus a bunch of configuration glue.

>>I've been doing my daily journaling and task management on Emacs for while now

Trust me, move to Google Docs.

This is simply a whole larger and easier universe compared to anything Org-mode will ever evolve to be. Its also backed up online, pictures are embedded in the document itself. And several other features come out of the box. You also don't have spend years learning to use it, and can get productive from minute 1.

Where's the fun in that? :D

We choose to automate these things, not because they are easy, but because they are an interesting problem to solve

Well this goes to show that, as some other commenter said, the gamer community (whatever that is) is indeed very fragmented.

I routinely re-play games like Diablo 2 or BG1/2 and I couldn't care less about graphics, voice acting or motion capture.

AFAIK, the electrolyte.

I think it's become a running theme: senior devs who have been coding for a while now are able to extract value from these tools because, even if you don't know Rust, you know how to code.

BS code smells the same in any language.

Beginner devs don't even know what smelling means.

Seniors being able to extract more from any new tool is a time proven constant. That hasn't changed.

What happened is that companies tried to push an idea that this new AI thing would be inhospitable to whoever is already an experienced programmer. The idea of "new land", fair and equal to all. Smelling woudn't matter, because all smells would be new and unfamiliar.

After insisting on this silly mistake for a while, they realized that experienced programmers were actually their only viable target audience, and attempted to change their approach accordingly. It's embarassing.

Maybe this is the answer to the ageism problem people have complained about in tech.

In the land of vibe-coders, the old man is king.

I thought this was going to be yet another post about how AI is ruining Junior devs so we'll have a Senior replacement crysis in a few years.

It sort of is, indirectly, and I agree with pretty much everything.

But the bit about sycophancy was particularly enlightening. I actually thought "plain" ChatGPT-like interfaces could be good for learning. But the Youtube ROAS example is really powerful. If the student can skew the teacher's conclusions so much just by the way they phrase their questions/answers, we're going to mislead new programmers en masse.

I'm not even sure that the extensive prompting they say they use for their "Boots" is good enough.

I guess in the age of AI you still need someone to repeatedly reject your pull requests until you learn. And AI won't be that someone, at least for now.

I think I agree. From personal experience, even when I ask for scathing critique, the need to placate and make me feel better seems to bleed through ( both on 4o and 5 as far as I could tell ). I am not sure what to make of it.

We go back to this original prediction that the tool will help those, who both want help and are painfully aware of LLMs peculiar issues.

The incentives align: when the success metric is engagement, it will be optimized for engagement. It makes perfect sense that it is going to agree with you.

> But the bit about sycophancy was particularly enlightening.

I always try to stay above this by prompting the question twice, with the opposite biases. But I of course don't know, which hidden biases I have that the LLM still reinforces.