rudedogg

The abstractions are the veil that make the theft slightly less obvious

> it requires a hands-on approach and actually understanding what's being built.

I think this is true regardless of what language you’re using.

I’ve built a lot in Zig and there’s no difference between vibing stuff in it versus TypeScript/React. Claude can “one-shot” them both, and will mimic existing code or grep the standard library to figure everything out.

I’ve been vibe-ish coding a GUI Toolkit in Zig w/ SDL3 and Vulkan for a few months now.

It has lots of features, but I posted a demo of some fun with buttons here: https://x.com/rudedoggtweets/status/2043531378181161357

I think I’m building up an agentic IDE, just haven’t committed yet, but probably will this month.

One cool new thing I’m trying is running models directly w/ Vulkan. I’m about halfway there with my first model, but it’s going better/easier than I anticipated and I’m hoping I can make something very specialized and fast.

This is fun, FYI you don’t have to sign in/up with a Google account. I hesitated downloading it for that reason.

> Any serious LLM work isn't going to use that.

That’s my point.

One would expect the platform owner (especially one where they own both the hardware AND software) to provide a reasonable / easy path to using LLMs if they are going to provide a framework for doing so. But Apple can’t because of how slow they ship updates

The application development APIs, ie: https://developer.apple.com/documentation/technologyoverview...

Their rule of only releasing major software updates once a year in June is holding them back IMO. Their local LLM apis were dated before macOS/iOS 26 was even released. Just because something worked 20 years ago doesn’t mean it works today, but I’m sure it’s hard to argue against a historically successful strategy internally.

> You don't have to use all of them!

You sure pay for the language complexity in high compile times though. Swift is slow, like really slow. I’ve been with it since like v1.2, and its been getting progressively worse for a while IMO. Complex language features (Lets do a borrow checker! Lets do embedded!) and half of the shit isn’t being used internally as far as I can tell

And if Google Maps charged per tile viewed, so the user pays the same amount regardless of which maps client they used, would your opinion hold?

I get that it’s a ToS violation, but I’m saying it shouldn’t be. They’re trying to make the harness the moat because they all have no moat.

My point is that model providers are just a compute service, and should have no say in what sends the data, or displays the data. Especially when they only bill based on the quantity of data.

They are basically a utility.

This is more like if Google took action against Thunderbird and open-source email clients

> And on top of it, if you develop for native macOS, There’s no official tooling for visual verification. It’s like 95% of development is web and LLM providers care only about that.

I think this is built in to the latest Xcode IIRC

I think the real divide is over quality and standards.

We all have different thresholds for what is acceptable, and our roles as engineers typically reflect that preference. I can grind on a single piece of code for hours, iterating over and over until I like the way it works, the parameter names, etc.

Other people do not see the value in that whatsoever, and something that works is good enough. We both are valuable in different ways.

Also, theres the pace of advancement of the models. Many people formed their opinions last year, and the landscape has changed a lot. There’s also some effort requires in honing your skill using them. The “default” output is average quality, but with some coaxing higher quality output is easily attained.

I’m happy people are skeptical though, there are a lot of things that do require deep thought, connecting ideas in new ways, etc., and LLMs aren’t good at that in my experience.

Thanks for mentioning, but I did update it to High Effort when I got the notification

I've been thinking this too. I frequently do deep research on some systems programming technique, ask it to generate a .md for it, and then I use that in later sessions with Claude Code "look at the research I collected in {*-research}.md and help me explore ways to apply it to {thing}".

At the research step it frequently (always?) uses memory to direct/scope the research to what I typically work on, but I think that kind of pigeon holes the model and what it explores. And the memory doesn't quite capture all the areas I'm interested in, or want to directly apply the research to.

And regarding the crap in memories, I found the same. Mine at work mentioned I'm an expert at a business domain I have almost zero experience with.

I feel like the companies building this stuff accept a lot of "slop" in their approach, and just can't see past building things by slopping stuff into prompts. I wish they'd explore more rigid approaches. Yes, I understand "the bitter lesson" but it seems obvious to me some traditional approaches would yield better results for the foreseeable future. Less magic (which is just running things through the cheapest model they have and dumping it in every chat). It seems like poison.

Related: https://vercel.com/blog/agents-md-outperforms-skills-in-our-...

Also, agent skills are usually pure slop. If you look through https://skills.sh on a framework/topic you're knowledgeable in you'll be a bit disheartened. This stuff was pioneered by people who move fast, but I think it's now time to try and push for quality and care in the approach since these have gotten good enough to contribute to more than prototype work.

It's not much but I was planning to cancel my Anthropic subscription to try Codex over the weekend, but I'll skip that. I don't want to support a company with someone like this at the top. Massive donations to the administration, sneaky backdoor deals. No thanks, fuck you.

> And if China gets AI, they're more than likely to use it to further raise people out of poverty and automate away more menial jobs without making those displaced workers homeless.

Your comment is very optimistic. But the quoted part reminded me of something I heard (again) about China using slave labor in their lithium mines:

https://www.state.gov/forced-labor-in-chinas-xinjiang-region...

Thanks! I think I spent as much time writing the post as I did making the skill, so I’m happy someone got some value out of it.

A little bit! I wrote a long blog post about how I made it, I think the strategy of having an LLM look at individual std modules one by one make it actually pretty accurate. Not perfect, but better than I expected

I made a Zig agent skill yesterday if interested: https://github.com/rudedogg/zig-skills/

Claude getting the ArrayList API wrong every time was a major reason why

It’s AI generated but should help. I need to test and review it more (noticed it mentions async which isn’t in 0.15.x :| )

From what I’ve read there’s a pretty sizable performance gap between SQLite and pglite (with SQLite being much faster).

I’m excited to see things improve though. Having a more traditional database, with more features and less historical weirdness on the client would be really cool.

Edit: https://pglite.dev/benchmarks actually not looking too bad.. I might have something new to try!

This is kind of where I'm at.

I don't think everything is for certain though. I think it's 50/50 on whether Anthropic/whoever figures out how to turn them into more than a boilerplate generator.

The imprecision of LLMs is real, and a serious problem. And I think a lot of the engineering improvements (little s-curve gains or whatever) have caused more and more of these. Every step or improvement has some randomness/lossiness attached to it.

Context too small?:

- No worries, we'll compact (information loss)

- No problem, we'll fire off a bunch of agents each with their own little context window and small task to combat this. (You're trusting the coordinator to do this perfectly, and cutting the sub-agent off from the whole picture)

All of this is causing bugs/issues?:

- No worries, we'll have a review agent scan over the changes (They have the same issues though, not the full context, etc.)

Right now I think it's a fair opinion to say LLMs are poison and I don't want them to touch my codebase because they produce more output I can handle, and the mistakes they make are too subtle that I can't reliably catch them.

It's also fair to say that you don't care, and your work allows enough bugs/imprecision that you accept the risks. I do think there's a bit of an experience divide here, where people more experienced have been down the path of a codebase degrading until it's just too much to salvage – so I think that's part of why you see so much pushback. Others have worked in different environments, or projects of smaller scales where they haven't been bit by that before. But it's very easy to get to that place with SOTA LLMs today.

There's also the whole cost component to this. I think I disagree with the author about the value provided today. If costs were 5x what they are now, I think it would be a hard decision for me to decide if they are worth it. For prototypes, yes. But for serious work, where I need things to work right and be reasonably bug free, I don't know if the value works out.

I think everyone is right that we don't have the right architecture, and we're trying to fix layers of slop/imprecision by slapping on more layers of slop. Some of these issues/limitations seem fundamental and I don't know if little gains are going to change things much, but I'm really not sure and don't think I trust anyone working on the problem enough to tell me what the answer is. I guess we'll see in the next 6-12 months.

My experience with them is limited, but I’m having issues with the LLMs ignoring the skills content. I guess it makes sense, it’s like any other piece of context.

But it’s put a damper in my dream of constraining them with well crafted skills, and producing high quality output.

Yes, this is part of what is supposed to justify the premium prices, is that they can have a different business model.

But it seems Tim Cook can’t leave anything on the table. I’m really going to be irritated if we end up with a premium Siri. It’s going to undermine the privacy aspect, the hardware innovation, and everything else they have going for themselves despite missing the boat on AI

If these things can ever actually think and understand a codebase this mindset makes sense, but as of now it's a short-sighted way to work. The quality of the output is usually not great, and in some cases terrible. If you're just blindly accepting code with no review, eventually things are going to implode, and the AI is more limited than you are in understanding why. It's not going to save you in it's current form.

> increasing the level of abstraction developers can work at

Something is lost each step of the abstraction ladder we climb. And the latest rung uses natural language which introduces a lot of imprecision/slop, in a way that prior abstractions did not. And, this new technology providing the new abstraction is non-deterministic on top of that.

There's also the quality issue of the output you do get.

I don't think the analogy of the assembly -> C transition people like to use holds water – there are some similarities but LLMs have a lot of downsides.

LSP also kind of sucks. But the problem is all the big companies want big valuations, so they only chase generic solutions. That's why everything is a VS Code clone, etc..

https://paulgraham.com/ds.html

Hearing people on tech twitter say that LLMs always produce better code than they do by hand was pretty enlightening for me.

LLMs can produce better code for languages and domains I’m not proficient in, at a much faster rate, but damn it’s rare I look at LLM output and don’t spot something I’d do measurably better.

These things are average text generation machines. Yes you can improve the output quality by writing a good prompt that activates the right weights, getting you higher quality output. But if you’re seeing output that is consistently better than what you produce by hand, you’re probably just below average at programming. And yes, it matters sometimes. Look at the number of software bugs we’re all subjected to.

And let’s not forget that code is a liability. Utilizing code that was “cheap” to generate has a cost, which I’m sure will be the subject of much conversation in the near future.

Also iCloud Private Relay.

CloudFlare is making it impossible to browse privately

> JIT compilation has the potential to exceed native compiled speeds

The battlecry of Java developers riding their tortoises.

Don’t we have decades of real-world experience showing native code almost always performs better?

For most things it doesn’t matter, but it always rubs me the wrong way when people mention this about JIT since it almost never works that way in the real world (you can look at web framework benchmarks as an easy example)