Skinney

I would say that a calculator and a database like postgres differ quite significantly, though. How many PRs are merged per month on your average calculator? How many lines of code is in that firmware?

Trusting that a calculator works is like trusting that there will be another day tomorrow, while trusting the code of an LLM is like trusting that the current weather will hold for the next hour.

Also, LLM finding bugs in human written code doesn't mean it wouldn't find much more in LLM generated code, and spend much more money doing so. That is, of course, after ruling out the false positives (of which there are a few, judging by the PRs I've received on my open source projects)

This JEP is essentially about caching the JIT's generated code for later runs. The JIT is still free to discard the cache if it deems it worthwhile.

> Doltlite, like most software nowadays, has been touched by LLMs, but dismissing this project as "vibe coded" seems harsh

From the article, at the end of the second paragraph:

> Could a team of agents pull it off? It only took about 2,000 pull requests but DoltLite going Beta proves a team of agents certainly could.

The first PR was merged March 17th.

"vibe coded" seems pretty fitting

It only has to ask if the cookies are used for behaviour not relevant for the site (like specialized ads), so it probably doesn’t have to ask.

> That's why most client-side routing libraries support lazy loading.

Trading off total size with more network requests.

> does HTMX make fetches magically faster or what?

With backend rendering (htmx) you'd do all of that on the initial render, which would be faster than first fetching the app, then fetching the data, as you'd typically do in a single page app.

React itself, or Preact for that matter, is just the baseline. You still need the application itself, which in every application I’ve worked on is quite a bit bigger than the framework itself.

So you need to download the app, maybe have that app perform some fetch requests, then have the app generate html to show to the user. This is going to be slower than just retriving the resulting html directly.

If you’re in a place with unreliable or plain out bad signal, the difference will be quite noticeable.

* spaghetti or not depends on how you structure things, not on the framework/library used. * HTMX doesn’t introduce a new language. It extends HTML with props, which is less than what React is doing. * unpredictable state? You rely on the browser and (partial) page-refreshes.

How?

Everything served under one domain doesn’t have to use one technology.

Use backend rendering when you can, use HTMX where you need a little bit more, use React on the actual bits where it matters.

As a side-benefit, the React bits might end up less complicated as React doesn’t need to handle every single use case.

Thank you :)

I think I'm handling this as well, though. I have my own personal retrospective every once in a while where I evaluate the different things I work on and if they're worth continuing, or if there are other things (or just rest) I need to replace one of them with.

> So logically, if AI can help us complete tasks 2-100x faster than before, we should be UNDERWORKED and experiencing ZERO burnout, right?

Got to admit, I stopped reading here.

In my experience, burnout isn't related to the amount of work, but to your confidence in being able to do your job and if you find your job meaningful (like, does it even matter?).

I'm probably doing twice as much work now compared to the period just before I burned out, but I'm also nowhere near a burnout. Part of that is general experience, but it's also because I feel like I know what I'm doing (so, no imposter syndrome) and because I've chosen my job based on what I find meaningful to do (is it ethical? does it make a difference in society? is it interesting?).

I understand why LLM assisted development can lead to burnout. You now have a machine that "does most of the work for you". It's a gateway to questions like "how good are you really at your job?" and "anyone could push these buttons, couldn't they?" and "is this what the rest of my life should be?". It probably also reduces how interesting or fulfilling the job is for many people. You've been reduced to a cog in the machine, and you might be questioning your ability to be anything but.

This is required in order to implement value classes in Java (project valhala).

MNT just started offering the QCS6490 for their laptops.

https://mnt.re/media/reform_md/2026-06-30-june-update.html

vibe has improved _a lot_ during the past few months, fyi.

The new Mistral Medium 3.5 is also a big improvement over devstral-2

"Unified" means that it's shared between CPU and GPU, I believe.

But yes, it tends to be soldered on.

Cheaper tokens means the company's margins increase, which would be valuable for investors to hear

I'm not doing anything huge, but my local radicle node is connected to ten other nodes at present, one of which is my own hetzner-hosted seed. Even if half of these go down, I still have full access to all the repos I follow.

Wouldn't people discover HardenedBSD via google and then find the link to the code via the website?

I've personally never discovered projects through Github.

Radicle is local-first, so you can create issues and patches (pull requests) even when offline. It will sync when you're back online.

Also, my understanding is that ATProto is relatively centralized in practice, wheras in radicle every node is sort of equal.

The load will be spread across the network, but I guess the main benefit is that everything continues working even though HardenedBSDs official seed is down.

Every user has their own node, and everyone's node talks to several seed nodes. Even if the official HardenedBSD seed is down, there's still going to be another node to sync with.

> You work for money.

I work for money because I need food on the table and a place to sleep. It doesn't motivate me much more than that. In fact, I wouldn't even call it motivation. It's a requirement to live.

There have also been studies that have found that money stops making people happier or more motivated once their yearly salary exceeds a certain amount (the equivalent of 700.000NOK here in Norway).

Some people are primarily motivated by making as much money as possible, sure, but most people I've worked with have found someplace else to work once their current job stops being interesting.

> Having a register machine doesn't seem very useful...

Requires fewer instructions, so potentially faster evaluation, which is good for short-lived programs that ends before the JIT kicks in.

Stack machines requires less space per instruction, however, which reduces the size of the program (faster to load).

If it works anything like what we've got in Norway, they take a rough percentage, and once every year when the taxes are filed, the IRS equivalent charges or repays the missing amount.