I don't know about online dating, but I think the vibe coders I've interacted with the past few years break down into two distinct groups:
1. People who let agents drive designs/plans and just let them rip (what I would /actually/ call vibe coding) -- who place value in the final product, and aren't shameful about the tools used to get there as long as the product is "good" (and generally reroll entire apps from a single prompt until they get something that's actually good)
2. People who provide (or collaborate with AI on) designs/plans and use AI to write the code (which I wouldn't call vibe coding, but often gets conflated) -- who place value in the planning, and aren't shameful about the tools used to implement them as long as the architecture is "good"
Either way: I'd say most people who "vibe code" (in either category) are a little annoyed at the term inherently belittling what they make, but generally dismiss the term rather than feel any shame about it.
I'd be surprised to learn anyone in my programming network doesn't use any AI anywhere. It's a very powerful tool that's integrated pretty much everywhere into the 2026 Developer's toolkit, and the question is generally /where/ you use it (or not), not whether you use it at all.
Implementation became cheaper but it’s still not cheap. I’m working on an implementation for a runtime that’s been going on for 4 months of 24/7 constant Sol and now Astra work. When things go wrong it costs my time, which is my most valuable commodity. A week spent going in the wrong direction is still a week. If I can avoid that by planning better I will.
I would argue that if you belong to group one you have not actually "made" anything.
I would also argue that group two aren't "software engineers" anymore; what they do is less engineering and more architecture. Perhaps "agentic developer" is more appropriate.
> I would argue that if you belong to group one you have not actually "made" anything.
That's exactly the sentiment I'm referring to.
I'm excited that group one is full of people who couldn't previously "make" anything with code, but now can (in the same way I'm excited that more people can now "make" music, art, stories, movies, etc). And they're definitely making stuff (friends with kids are making games that their friends play, sharing homemade videos with each other, making bedtime stories, making websites and apps that others use, etc).
I'd also argue that theory and architecture have always been closer to "software engineering" than coding ever was, but I also acknowledge I've got a bit of a bias belonging to group 2 (otherwise: been coding for ~25 years).
>I'm excited that group one is full of people who couldn't previously "make" anything with code, but now can (in the same way I'm excited that more people can now "make" music, art, stories, movies, etc). And they're definitely making stuff (friends with kids are making games that their friends play, sharing homemade videos with each other, making bedtime stories, making websites and apps that others use, etc).
This is a dangerous game people are playing. One where people trick themselves into believing that ideation == creation. Not only are they not the same, framing it as such gives people licensure to crowd out the actual creatives who spent countless hours creating the inputs to these models.
Furthermore, I disagree with the following:
>I'm excited that group one is full of people who couldn't previously "make" anything with code, but now can (in the same way I'm excited that more people can now "make" music, art, stories, movies, etc).
What are these barriers people keep referring to that prevented people from creating music, art, stories pre-2022? If someone owned a phone, laptop, etc. in 2022 they already had access any number of free digital tools to assist in making music, art, stories, home made films. Hell, you can buy a pen and notebook from a store for a handful of dollars.
What you really mean is that pre-2022 nobody could produce a decent looking photo, song, or program without having to spend a lot of time learning about that craft. But that isn't a barrier--someone making a shitty song is still making music.
People just want the ability to generate content which resembles quality without having worked for it. In practice, this kind of behavior is far closer to consumption than craft/art/making/whatever.
I don't know if I would call myself a vibe coder, but I definitely feel shame about putting any llm-generated code online unless I've reviewed it to the point of it being what I would've have written on my own anyway.
So lots of personal one-off tools/dashbooards that I never would have made before will probably live forever on my personal git server instead of github or somewhere.
there was a mild stigma around "i met her on facebook". a negative spin would be like: it's like you're stalking random women, and you must not have much luck or courage to approach women. but facebook wasn't exactly a dating app, so.
Sharing anything that has even a whiff of being machine generated opens you up to huge amounts of scorn and derision. It happens in the comment section of nearly every post on this site. If that's not the community here using shame as a mechanism of control, I don't know what is.
I hate reading slop as much as the next person, so I get it, but I don't try to deny it exists.
I was yesterday years old when I learned that those open weight models need custom code to run.
Somehow I expected inference engines are generic LLM runtimes that can execute any weight.
So, to get this right.
Someone trains a model.
They release the weights and a reference implementation of the model architecture.
Then a provider has to host this model either by running inference via the reference implementation, an open source implementation, or build their own.
Does this mean, providers don't just differ in quantisation and configuration, but also in inference engine implementation?
The implementation of a language model is usually good enough for running _a single forward pass_ through the model, but to host it via an inference engine you typically need to convert a few operations. For instance the MLP can be easily split across GPUs (tensor parallelism) and MoEs also have a way of parallelizing.
Most of it is pretty standard, since not that many different layers and primitives are used in LLM architectures, but once in a while something new comes along that needs more effort. MoEs are one example, they are sparse and allow for completely different inference patterns, which takes a while to figure out.
Last year I started a blogpost series about this topic (that I hope to update some time). I start from a minimal gpt implementation by Karpathy and build the engine around it, you might like it: https://pieter.ai/blog/2025/nanogpt-inference/
yes. this is just raw implementation of the model arch as described in papers. for complete model training with back propogation we need training pipeline with optmizer and loss calculation.
> Somehow I expected inference engines are generic LLM runtimes that can execute any weight.
In fact, this was close to be true until last year: almost every open model except DeepSeek had a very similar architecture that was pretty close to the GPT-2 one with very few variations on top (and sometimes an MoE architecture, which itself was a few year old at that point).
But a year ago there's been a cambrian explosion, first in attention mechanism but also in a bunch of other directions, mostly coming from China, and now there's a very massive diversity today's space.
Makes me feel better as a guy who tries to get O(1000) times smaller models working for scientific applications. Writing a backend that works for all the models people train is quite a chore, so the common refrain is "why don't we just do what industry does?" (he answer is that "industry" has billions of dollars). You also get "no one uses X backend any more" to which the reply is also "yes, but they have billions of dollars and a team of software engineers".
Yes. https://inferencex.semianalysis.com provides some comparisons wrt. certain cost metrics. Some commonly used ones are vLLM, TensorRT-LLM, and SGLang. These three at least are open source, and all come with an Apache 2.0 license.
Some providers also have to implement their own engines, e.g., Cerebras has their own inference serving stack for their wafer-scale chips, as does Google for their TPUs (XLA compiler).
yes, most of them are similar. but implementation of GQA, MLA, mHC, Sliding Window changes the implementation drastically because of which the overall model effeciency changes.
Yes. You can see this affecting perf benchmarks as well. Usually the cheapest inference providers either use approximations like tanh instead of sigmoid, nvfp4 quantizarion, etc.
There was a post here the other day highlighting this by showing the benchmark perf of different I defence providers, it's a fantastic area to cheap out in, because you can never really tell if a model is 75% good or 83% good on some specific benchmark when you use it to build your own stuff
Absolutely. The worst part is that ML being probabilistic means the models still output something comprehensible meaning you can't determine if it's correct or not without a lot of scrutiny and engineering.
Go look at the github commits for llama.cpp and read the actual code they're adding to support new model/quant types... to me at least it's some serious black magic, and the sheer number of genius developers and activity level in this repo is absolutely wild.
Imagine what could happen if other open source projects had this level of engagement and expertise at hand and eager to contribute... instead of arguing over politics and making yet another fork of something.
I don't know about animation, but it seems the UI system and their widget library was overhauled.
"The Feathers widgets have migrated to BSN, Bevy's next-generation scene system. BSN is a better foundation for widgets than the old spawn-function approach: it reduces boilerplate, lets you compose widgets together, parameterize widgets with SceneComponent props, reference font/image assets, and register observers in the same declaration."
Yet, I wouldn't go so far as to say every novel is one. If you aren't an established author, publishers won't take on your manuscript if it doesn't hook them with the first chapter, better even with the first page.
That doesn't mean that a well written first chapter will hook everyone, though.
reply