> Currently the reason that it's bad to not reviewing/testing the code LLMs generated is that the LLMs can sometime generate bad codes.
Sometimes?
I am heavily into vibe coding and I think they almost always generate bad code. At least as soon as you're distant enough from the code to call it vibe coding.
When you're still in touch with the code, have at least been recently talking to it about code rather than 100% about features, and its context is filled with good code, it can generate good code.
This looks like one of the better pieces of LLM-output documentation I've seen. It's bad technical writing, but better than most of what I've seen come out of an LLM.
---------------
Pre-empting the "how can you tell", here's some of the tells.
> The API is shaped after Sharp:
Constantly using "shaped" and "shape" is becoming an LLM-ism, much more common than in human writing.
> The constructor accepts a path, bytes, or a Blob — including Bun.file() and Bun.s3().
> The format is sniffed from the bytes — extensions and Content-Type are ignored.
Repeatedly formatting statements as X: Y, X — Y, or [b]X[b] Y is also an LLM-ism.
> Don’t pass user-controlled strings directly to the constructor — that’s an arbitrary-file-read primitive.
> When passing a TypedArray/ArrayBuffer, don’t mutate it while a terminal is pending — decode runs off-thread and borrows the bytes.
Doing so by leading with what-it's-not / what-not-to-do is even more of an LLM-ism.
The other big problem with LLM documentation is that it tends to drift from the code, because agents forget to update it. Then later agents sometimes reference the documentation, sometimes reference the code, and get confused.
For agent written code I now default to no documentation and explanatory function signatures, it works better for me at least.
I agree, I think for agents though, documentation does more harm than good. When I'm writing code with an agent I tell it to skip documentation entirely (reading or writing it) and it leads to more accurate outcomes.
When agents write most of our code, I question if we will still even need documentation.
I think that's a fair take. I think we definitely still need specs that describe the desired behavior as an artifact. But documentation describing the implementation definitely feels less important.
I just have a rule in AGENTS.md that any additions, removals or modifications to the public facing APIs should update the corresponding API documentation, works fine for me (assuming both sit in the single workspace).
> So, on the one hand, I’m seeing the most talented developers I know amplify what they can do with AI, and on the other, I’m seeing people with less domain knowledge struggle to get past the “MVP” stage.
Those are people who weren't making it to the MVP stage before LLMs.
There is no doubt that highly technical people are getting A LOT more out of LLMs than people without dev experience, in an absolute sense. I think it's less clear in a relative sense.
A question I also ask myself a lot: What are the skills I'm leveraging, exactly, as a highly experienced developer that's now doing a lot of vibe coding?
1) I'm choosing good technology for the task, and thinking about what LLM-agents are good at and choosing technology that they can work well with.
2) I'm choosing good workflows for the LLM-agent, starting a new context at the right time, having it test things, making sure it has logging that it can inspect, making sure it can operate the application in a way that it can debug and inspect it.
3) I'm thinking about the code even though I'm not looking at it, I'm telling it how I want things implemented, I'm telling it how to debug things.
I think these are all hard things for non-developers to do, but I also think non-developers will be able to replicate a large chunk of #1 and #2 relatively quickly. I only have to figure out that it's valuable to tell the LLM-agent to use playwright when working on web page visuals once, and then I can tell you to do that too. Or the coding agents will come with that knowledge built-in (to the model or as a builtin skill or whatever). Knowledge around this will accumulate and become easier for non-developers to access, and in many cases be builtin to the models or harnesses.
You will be right, but we already see this blame-shifting with "AI deleted my production"/"AI told me to do it" and washing it away with "AI can make mistakes, so double-check responses". They will try to make you responsible for trusting something you see on screen marked with an asterisk as not trustworthy and not reading the box with another asterisk.
We live in a world where ads are the primary way information about products enters the information sphere. That seems like something we should fix to me, but it's where we are, and it means if ads are well enough targeted it can be rational for an individual to want to consume them.
Also I think people pay much of the price of ads even if they don't view them, via increased prices. The trillion dollar advertising industry money ultimately is paid by consumers. It is a necessary cost to try to launch a new product because we are reliant on it for information and because all your competitors are advertising.
I sort of wish there was a google "ad" search, where its like google search but only for ads, for the rare cases you want to buy something, and are looking through for a compatible product. Make advertisers differentiate by providing more information about their product to help me make a choice rather than shoving the product everywhere else hoping that I'll buy the thing out of fatigue
Their desktop software. If you’re going to switch off the desktop software to something, it may as well be something that isn’t turbotax.
My dad had to upgrade his PC recently to do his taxes as it was stuck on Windows 10 due to CPU support. I suggested a Mac Mini, but neglected to confirm that turbotax Canada supports macOS with their desktop software. My dad had no interest the website version, so he bought another Windows laptop and now has both the Mac Mini and his “tax laptop” that he plans to only use once a year.
Some people are just ingrained in their habits and not interested in change. (Though my retired father was perfectly willing to try a Mac for the first time - apparently new tax software was a bridge too far.)
Folks of retirement age or nearing it are largely free to either play with it or not depending on their interest. This segment may present as largely positive if those without interest get to just opt out.
For folks in the middle of their career or earlier, or just starting out, it's more of a labor vs capital thing where capital doesn't care if skills that have been invested in are devalued, and raises expectations where skills are amplified. This segment will likely present as largely negative.
Younger still, high school and earlier, probably fairly free again to play with it or not depending on interest, but subject to temptation to use it to cheat, and subject to teacher influence not to.
reply