I use AI as a rubber duck to research my options, sanity-check my code before a PR, and give me a heads up on potential pain points going forward.
But I still write my own code. If I'm going to be responsible for it, I'm going to be the one who writes it.
It's my belief that velocity up front always comes at a cost down the line. That's been true for abstractions, for frameworks, for all kinds of time-saving tools. Sometimes that cost is felt quickly, as we've seen with vibe coding.
So I'm more interested in using AI in the research phase and to increase the breadth of what I can work on than to save time.
Over the course of a project, all approaches, even total hand-coding with no LLMs whatever, likely regress to the mean when it comes to hours worked. So I'd rather go with an approach that keeps me fully in control.
Yeah my guess is that it takes roughly the same amount of time regardless if it's AI agents or hand coding, the time just gets spent in different ways (writing vs reading for example).
My question is why use AI to output javascript or python?
Why not output everything in C and ASM for 500x performance? Why use high level languages meant to be easier for humans? Why not go right to the metal?
If anyone's ever tried this, it's clear why: AI is terrible at C and ASM. But that cuts into what AI is at its core: It's not actual programming, it's mechanical reproduction.
Which means its incapabilities in C and ASM don't disappear when using it for higher-level languages. They're still there, just temporarily smoothed over due to larger datasets.
My small-program success story with genAI coding is pretty much the opposite of your claim. I used to use a bash script with a few sox instances piped into each other to beat-match and mix a few tracks. Couldn't use a GUI... Then came gpt-5, and I wanted to test it anyway. So I had it write a single-file C++ program that does the track database, offline mixing, limiter and a small REPL-based "UI" to control the thing. I basically had results before my partner was finished preparing breakfast. Then I had a lot of fun bikeshedding the resulting code until it felt like something I'd like to read. Some back and forth, pretending to have an intern and just reviewing/fixing their code. During the whole experience, it basically never generated code which wouldn't compile. Had a single segfault which was due to unclear interface to a C library. Got that fixed quickly.
And now, I have a tool to do a (shuffled if I want) beat-matched mix of all the tracks in my db which match a certain tag expression. "(dnb | jungle) & vocals", wait a few minutes, and play a 2 hour beat-matched mix, finally replacing mpd's "crossfade" feature. I have a lot of joy using that tool, and it was definitely fun having it made. clmix[1] is now something I almost use daily to generate club-style mixes to listen to at home.
One thing I have been doing is breaking out of my long-held default mode of spinning up a react/nextjs project whenever I need frontend, and generating barebones HTML/CSS/JS for basic web apps. A lot of the reason we went with the former was the easy access to packages and easy-to-understand state management, but now that a lot of the functionality packages used to provide can be just as easily generated, I can get a lot more functionality while keeping dependencies minimal.
I haven't tried C or ASM yet, but it has been working very well with a C++ project I've been working on, and I'm sure it would do reasonably well with bare-bones C as well.
I'd be willing to bet it would struggle more with a lower-level language initially, but give it a solid set of guardrails with a testing/eval infrastructure and it'll get its way to what you want.
Pretty interesting take this. I wonder if there is a minimal state management we could evolve which would be sufficient for LLMs to use while still making it possible for a human to reason about the abstraction. It won't be as bloated as the existing ones we came up with organically however.
I mean, you're basically LLM-washing other people's code, then. All those UI components that other people wrote and at least expected attribution may not be libraries anymore, sure. But you've basically just copied and maybe lightly modified that code into your project and then slapped a sticker on it saying "mine." If you did that manually with open source code, you'd be in violation of the attribution terms almost all the licenses have in common. But somehow it's okay if the computer does it for you?
It is a gray area. What if you took Qt, removed macros, replaced anchoring with css for alignment, took all widget properties out into an entity component system and called it ET, could Trolltech complain? It is an entirely new design and nothing like they built. A ship of Theseus if you will.
The Ship of Theseus has nothing to do with the identity of the parts. That is not in question at all; they are explicitly different parts. The thought experiment is the question of the identity of the whole.
Qt in your example is a part. You're application is the whole. If you replaced Qt with WxWidgets, is your application still the same application?
But to answer your question, to replace Qt with you're own piecemeal code doesn't do anything more to Qt than replacing it with WxWidgets would: nothing. The Qt code is gone. The only way it would ship-of-theseus itself into "still being Qt, despite not being the original Qt" would be if Qt required all modifications to be copyright-assigned and upstreamed. That is absurd. I don't think I've ever seen a license that did anything like that.
Even though licenses like the GPL require reciprocal FOSS release in-kind, you still retain the rights to your code. If you were ever to remove the GPL'd library dependency, then you would no longer be required to reciprocate. Of course, that would be a new version of your software and the previous versions would still be available and still be FOSS. But neither are you required to continue to offer the original version to anyone new. You are only required to provide the source to people who have received your software. And technically, you only have to do it when they ask, but that's a different story.
We used higher level programming languages because "Developer time is more expensive than compute time", but if the AI techbros are right, we are approaching the point where that is not going to be true.
It's going to take the same amount of time creating a program in C as it does in Python.
The premise of your question is wrong. I would still write Python for most of my tasks even if I were just as fast at writing C or ASM.
Because the conciseness and readability of the code that I use is way more important than execution speed 99% of the time.
I assume that people who use AI tools still want to be able to make manual changes. There are hardly any all or nothing paradigms in the tech world, why do you assume that AI is different?
I don't get this. AI coders keep saying they review all the code they push, and your suggestion is to use even harder languages the average vibe coder is unable to understand, all in name of "performance"? Faster code maybe, and exponentially increasing the tech debt and amount of bugs that slips through.
It wasn't even long ago that we thought developer experience and capacity for abstraction (which is easier to achieve in higher level languages) was paramount.
> AI coders keep saying they review all the code they push
Those tides have shifted over the past 6 weeks. I'm increasingly seeing serious, experienced engineers who are using AI to write code and are not reviewing every line of code that they push, because they've developed a level of trust in the output of Opus 4.5 that line-by-line reviews no longer feel necessary.
(I'm hesitant to admit it but I'm starting to join their ranks.)
In the past week, I saw Opus 4.5 (being used by someone else) implement "JWT based authentication" by appending the key, to a (fake) header and body. When asked to fix this, it switched to hashing the key (and nothing else), and appending the hash instead. The "signature" still did not depend on the body, meaning any attacker could trivially forge an arbitrary body, allowing them to e.g. impersonate any user they wanted to.
Do I think Opus 4.5 would always make that mistake? No. But it does indicate that the output of even SotA models needs careful review if the code actually matters.
Until your client tells you that it doesn't work in Edge and you find out it's because every browser has its own styling and they are impossible to change enough to get the really long options to show up correctly.
Then you're stuck with a bugfix's allotment of time to implement an accessible, correctly themed combo box that you should have reached for in the first place, just like what you had to do last week with the native date pickers.
I'd argue that adding complexity from the get-go to ensure that all users have a pleasant experience from the get-go is better than simplicity at the expense of some percentage of users.
I think it's important for web devs to spend more than two seconds to think if the complexity is necessary from the get-go though.
I got the right answer but it was so easy I went in with doubt I had done it right.
Which I understand is my issue to work on, but if I were interviewing, I'd ask candidates to verbalize or write out their thought process to get a sense of who is overthinking or doubting themselves.
That doubt is valid. Anyone reading this blog post (or in an interview, given the prevalence of trick interview questions) would know there must be some kind of trick. So, after getting the answer without finding a trick, it would be totally reasonable to conclude you must have missed something. In this case, it turns out the trick was something that was INTENDED for you to miss if you solved the problem in your head. At the end of the day, the knowledge that "I may have missed something" is just part of day to day life as an engineer. You have to make your best effort and not get paralyzed by the possibility of failure. If you did it right, had a gut feeling that something was amiss, but submitted the right answer without too much hemming and hawing, I expect that's typical for a qualified engineer.
I'm a fan of anything that allows me to build with javascript that doesn't require a build step.
Modern HTML/CSS with Web Components and JSDoc is underrated. Not for everyone but should be more in the running for a modern frontend stack than it is.
On the one hand I can see the appeal of not having a build step. On the other, given how many different parts of the web dev pipeline require one, it seems very tricky to get all of your dependencies to be build-step-free. And with things like HMR the cost of a build step is much ameliorated.
Any kind of downleveling, though that's less important these days most users only need polyfills, new syntax features like `using` are not widely used.
Minification, and bundling for web is still somewhat necessary. ESM is still tricky to use without assistance.
None of these are necessary. But if you use any of them you've already committed to having a build step, so adding in a typescript-erasure step isn't much extra work.
No Lit Element or Lit or whatever it's branded now, no framework just vanilla web components, lit-html in a render() method, class properties for reactivity, JSDoc for opt-in typing, using it where it makes sense but not junking up the code base where it's not needed...
No build step, no bundles, most things stay in light dom, so just normal CSS, no source maps, transpiling or wasted hours with framework version churn...
Such a wonderful and relaxing way to do modern web development.
I love it. I've had a hard time convincing clients it's the best way to go but any side projects recently and going forward will always start with this frontend stack and no more until fully necessary.
This discussion made me happy to see more people enjoying the stack available in the browser. I think over time, what devs enjoy using is what becomes mainstream, React was the same fresh breeze in the past.
I have not written a line of JavaScript that got shipped as-is in probably a decade. It always goes through Vite or Webpack. So the benefit of JS without a build step is of no benefit to me.
I've built Solarite, a library that's made vanilla web components a lot more productive IMHO. It allows minimal DOM updates when the data changes. And other nice features like nested styles and passing constructor arguments to sub-components via attributes.
It's ok now, at least for me. There are still challenges around theming and styling because of styling boundaries (which makes Web Components powerful, but still). A part of it is about tooling, which can be easier to improve.
I find Web Components aren't as much of a pain to write if you ignore the Shadow DOM. You don't need the Shadow DOM, it is optional. I don't think we are doing ourselves too many favors in how many Web Component tutorials start with or barrel straight into the Shadow DOM as if it was required.
It's a shame Surplus (Adam Haile's, not my succession of it) isn't cited nor is he mentioned, given that at least two of the listed frameworks were heavily and directly inspired by his work. S.js is probably one of the most incredible JavaScript libraries I've used that should be the reference for a signal API, in my opinion.
Agreed on native HTML+CSS+JSDoc. An advantage in my use-cases is that built-in browser dev tools become fluid to use. View a network request, click to the initiator directly in your source code, add breakpoints and step without getting thrown into library internals, edit code and data in memory to verify assumptions & fixes, etc.
Especially helpful as applications become larger and a debugger becomes necessary to efficiently track down and fix problems.
No, because layers of abstraction come at a cost and we have created a temple to the clouds piled with abstractions. Any option to simplify processes and remove abstractions should be taken or at least strongly considered.
Code written for a web browser 30 years ago will still run in a web browser today. But what guarantee does a build step have that the toolchain will still even exist 30 years from now?
And because modern HTML/CSS is powerful and improving at a rapid clip. I don't want to be stuck on non-standard frameworks when the rest of the world moves on to better and better standards.
> Code written for a web browser 30 years ago will still run in a web browser today.
Will it? - My browser doesn't have document.layers (Netscape) It seems to still have document.all (MSIE), but not sure it's 100% compatible to all the shenanigans from the pre-DOM times as it's now mapped to DOM elements.
Having all your code go through a multi-step process that spits out 30 different files makes it impossible to know what’s really happening, which I’m uncomfortable with.
reply