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

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


If going through a strongly designed process with quality gates is vibe coding, I guess so. I thought the term was reserved fir “claude, make this happen” style development and the term for the more professional approach was “agentic development”, though this seems to be another layer higher.

Grouping it all under “vibe coded” loses precision. Sure, it uses AI, but differently from other projects and with different implications.


Agentic development still requires human review and human ownership of PRs. This is vibe coded. Seems precise to me.


You can call it what you want I guess, but "vibe coded" around these parts is a simple pejorative, it means the authors don't know what the code does and the product is poor quality.

Most successful agent-coded projects have a few essential features that it's worth calling out: 1) The human driving it has real domain expertise; 2) There's an oracle for correctness; 3) The agent has a real-world example to copy, adapt, or translate.

This project had all these elements. The human driving the agent understood the technical and product decisions that make a version-controlled database work, because he's been doing that for 8 years. The project uses the existing 5.7M query test suite for SQLite3 as its oracle, as well as adapted versions of Dolt's extensive test suite to verify the version-control features that SQLite has no tests for. And the agent had a human-written implementation of the core product (Dolt) to crib from.

All of this is to say: yes, agents wrote this code, but if you or another randomly chosen software engineer sat down and tried to duplicate this result you wouldn't succeed. You wouldn't know what the agent had gotten wrong at every step of development, or even what questions to ask to find out where the errors might be. Despite the existence of a correctness oracle, the agent on its own cannot iterate to 100% correctness without a domain expert steering it. And that expert also has to have an extensive understanding of the existing code base that's being copied. You can't just say "Claude, implement version control in SQLite3, make no mistakes", it's not going to work.


"going beta" is a human decision. It proves nothing. All it proves is that at some point someone looked at it and said "good enough, ship it". It says nothing about the quality of the unreviewed code.


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.


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.


> every application I’ve worked on is quite a bit bigger than the framework itself

That's why most client-side routing libraries support lazy loading. You don't have to load the entire application at once, only the parts you need.

> So you need to download the app, maybe have that app perform some fetch requests

That's... completely unrelated to React, though? Parent comment claimed that React is slow and HTMX fast - does HTMX make fetches magically faster or what?


> 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.


* 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.


HTMX does introduce a new language, in fact it introduces 2 different ones, one is an extension of HTML and second is for the codelets it uses inside the array of attributes it uses as a pragma.


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.


Indeed. In a publishing (Wordpress) like solution maybe you would use HTMX for the user facing parts and React or something similar for the more interactive admin parts. Then you don't need to bother with server side rendering for the admin bits, which at least I think simplifies React a great deal. It's not that the JS fullstack frameworks doesn't handle server side rendering and routing for you, but they feel very much like black box magic to me. Especially the new fangled React Server Components with the whole serialization and streaming model.

Good old server side rendering is simple in Rich Hickey's "Simple Made Easy" way. You can build more complex logic on top of a standard server rendered model, but the base model is mostly dead simple to reason about. I like that. I've built web "apps" in AngularJS, React, Reagent (ClojureScript) and Next. So I'm not coming at this from a grumpy "backender" position. I'm coming at this from having done lots of frontend stuff and finding the frameworks becoming increasingly complex beneath the surface. It feels like they are targeting the "easy" in Rich Hickeys parlance in the sense that you don't have to write a lot of code to make something fancy. But reasoning about the behavior and what actually happens in the framework when something doesn't work is increasingly difficult.

Edit: And maybe this is a "skill issue". If you just learn the framework and library well enough you'll get by much better. But I tend to not want to bind myself to any single framework too much. So simple frameworks that don't churn too much is better for me.


> 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.


I mostly agree with your observations, but in my experience, if you're spread very thin, you may be nearing the sudden burnout onset.

You feel motivated, full of energy, your juggle millions things at once, and then stumble once, then another time. Then your mistakes become more frequent. And you don't even realize you make them, others do... Until eventually you no longer operate efficiently.

Can take a few years to develop.

Take some rest. Especially if you feel productive like never before. It's gonna be hard to shut down for the first few days, so it should be at least a week of rest. Better two.

Chances are: after coming back you'll immediately notice a dozen of stupid decisions you've made.


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.


I agree with your points here - I don't know if I feel more burnt out, but I definitely feel like my work has become less meaningful and fulfilling despite doing more work and iterating faster on a daily basis. I miss the satisfaction that comes with solving a problem on my own after wrestling with it for a bit.

It raises the uncomfortable question of, if so much of my work could be automated, was it ever really that important to begin with? It definitely has me asking a lot of questions about what I'm doing and where my life is headed.

One optimistic view is that AI could free up time for people who see their job as just a job, allowing them to invest more in other parts of their lives... but who knows how far down the line that is, and whether it'll even reach that point.


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


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

Search: