Pure vibe-coding isn’t that satisfying (as you’ve discovered) the problem is you’re constantly reviewing its huge output, and it probably goes wild in directions making assumptions.
It’s much more fulfilling to give the LLM guardrails by engineering the solution.
This means coming up with the high level architecture, dependencies, breaking down the system into deliverable chunks, and implementing those chunks. The LLM can help in all those steps of the process. And it will be much easier to review and keep an understanding of the code.
I don’t love GitHub, but that number is a little misleading… That’s the intersection uptime of all GitHub services, most of which I (and most users) do not care about; code spaces, copilot, packages etc…
When you take out those uptimes, it becomes a lot higher. I’ll admit there seems to be a lot more incidents than usual though…
Good UX abstractions out perform bad ones, which means they endure, are copied, and eventually become the implied standard UX… some examples of this are; the hamburger menu, tiny icons and auto-scroll for streaming text
Hamburger menu is not a good UX abstraction, that's why the mass usage stage of it was pretty short lived and most people are leaving it for more obvious patterns, like tab bars
Doesn't necessarily have to be good. Can also propagate and become "standardised" if it's the easiest, most convenient, most well documented way. Eg. Twitter Bootstrap.
I believe it has to do with the size of the icons rather than placing the icon with a label. The AI trend is towards smaller icons. That being said, the more I look at the pic in the article, the more pleasing the smaller icons look to me. Perhaps we just didn't know any better.
> Mainframes survive, but serving a much tinier portion of the market than they used to.
I would argue mainframes rebranded to "cloud" which is ubiquitous and more people interact with this computer than any other type of device... only difference is that it's a browser instead of a terminal
There is constant shifting between client and server computation. I think it is a stretch to call cloud servers “mainframes”. There are still old school mainframes, running JCL, and old school mainframe DB2 and COBOL. That ain’t cloud.
Should be very doable. I ship a small CNN in a browser extension via onnxruntime-web and the model weights were never the bottleneck, the runtime was. The wasm backend adds a few MB of runtime before your first inference, so a 500kb model with a lean hand-rolled wasm build would actually beat most "tiny" browser ML deployments in total download.
One gotcha if anyone wants this in a Chrome extension: MV3 requires 'wasm-unsafe-eval' in the CSP for any wasm at all, which surprised me the first time a build that worked fine as a web page died silently as an extension.
Yeah, I also found that for ultra low footprint models ORT is a big portion of the total payload, because it contains logic for general ONNX graph operations. In my case I found that ORT alone was 3.4MB over the wire, so I swapped it out for a tiny wasm that was 850x smaller and only contained the operations I needed: https://blog.lukesalamone.com/posts/creating-tiny-semantic-s...
This is one of the reasons why native proprietary coding agent runners like claude-code, codex, grok-build etc are so dangerous for privacy… you just don’t know what “secret sauce” they’ll add in the next update…
It’s much safer to use something like opencode and use models via their API… however, the tradeoff is that it will never perform as well as it does in their native agent runners…
Give enough usage, you can reconstruct an entire codebase via tool calls alone, and it'll be entirely undetectable because it's all done server side. Whatever grok's doing is just more blatant, but using opencode or whatever doesn't create a meaningful security boundary. It's like the meme of using cheetos as a lock.
> however, the tradeoff is that it will never perform as well as it does in their native agent runners
There's no reason to assume that. The recent Databricks benchmark in fact showed the exact opposite - that using Pi vs native agent both outperformed native agents in terms of task success, and did so cheaper due to using less tokens.
That's a major problem in its own right. Yes, not updating an XP SP1 RCE immediately is dangerous, but in the last couple decades I've seen far more damage inflicted from automatic updates than what I think the lack of them would have caused.
Is the server side open-source too, as gruez brought up in the sibling comment?
Technically they can still do potentially any- and everything undetected there; and for what it’s worth, even with a closed-source client bad behavior would get detected eventually through network inspection.
The best way to access ChatGPT "chat" was always on ChatGPT.com via a web browser, not even the iOS app seems to have all the little things you can do on the web version.
The Mac desktop ChatGPT app had weird issues like not being able to see the model being used by a chat inside a project etc. I just ended up installing ChatGPT Atlas and using that as an AI-only browser for all LLMs including Claude and Grok lol
It’s much more fulfilling to give the LLM guardrails by engineering the solution.
This means coming up with the high level architecture, dependencies, breaking down the system into deliverable chunks, and implementing those chunks. The LLM can help in all those steps of the process. And it will be much easier to review and keep an understanding of the code.
reply