Posted by delaugust 11/19/2025
What that means is that if you work in a certain context, for a while you keep seeing AI get a 0 because it is worse than the current process. Behind the scenes the underlying technology is improving rapidly, but because it hasn’t cusped the viability threshold you don’t feel it at all. From this vantage point, it is easy to dismiss the whole thing and forget about the slope, because the whole line is under the surface of usefulness in your context. The author has identified two cases where current AI is below the cusp of viability: design and large scale changes to a codebase (though Codex is cracking the second one quickly).
The hard and useful thing is not to find contexts where the general purpose technology gets a 0, but to surf the cusp of viability by finding incrementally harder problems that are newly solvable as the underlying technology improves. A very clear example of this is early Tesla surfing the reduction in Li-ion battery prices by starting with expensive sports cars, then luxury sedans, then normal cars. You can be sure that throughout the first two phases, everyone at GM and Toyota was saying: Li-ion batteries are totally infeasible for the consumers we prioritize who want affordable cars. By the time the technology is ready for sedans, Tesla has a 5 year lead.
I think you should say succesful "general purpose technologies". What you describe is what happens when things work out. Sometimes things stall at step 1, and the technology gets relegated to a foot note in the history books.
And we argue that microwaves will indeed never replace your grill as the makers, again, would love you to believe.
What we actually have is a physical system (the brain) that somehow implements what we know as the only approximation of general intelligence and artificial systems of various architectures (mostly transformers) that are intended to capture the essence of general intelligence.
We are not at the microwave and the grill stage. We are at the birds and the heavier-than-air contraptions stage, when it's not yet clear whether those particular models will fly, or whether they need more power, more control surfaces, or something else.
Heck, the frontier models have around 100 times lower number of parameters than the most conservative estimate of the equivalent number of parameters of the brain: the number of synapses. And we are like "it won't fly".
Attempting to roast a full chicken or turkey is not the correct way to use microwaves. You must first remove the bones from the bird, then cut the meat into bite-sized chunks. After using a boning knife for the former operation, I prefer to do the latter operation with some good Japanese kitchen scissors, as it is simpler and faster than with a knife.
If you buy turkey/chicken breasts or thighs without bones, then you have to do only the latter operation and cut them into bite-sized pieces.
Then you can roast the meat pieces in a closed glass vessel, without adding anything to the meat, except salt and spices (i.e. no added water or oil). The microwave oven must be set to a relatively low power and long time, e.g. for turkey meat to 30 minutes @ 440 W and for chicken to less time than that, e.g. 20 to 25 minutes. The exact values depend on the oven and on the amount of cooked meat, but once determined by experiment, they remain valid forever.
The meat cooked like this is practically identical to meat cooked on a covered grill (the kind with indirect heating, through hot air), but it is done faster and without needing any supervision. In my opinion this results in the tastiest meat in comparison with any other cooking method. However, I do not care about a roasted crust on the meat, which is also unhealthy, so I do not use the infrared lamp that the microwave oven has for making such a crust.
Vegetable garnishes, e.g. potatoes, must be cooked at microwaves separate from the meat, as they typically need much less time than meat, usually less than 10 minutes (but higher power). Everything must be mixed into the final dish after cooking, including things like added oil, which should better not be heated at great temperatures.
Even without the constraints of a microwave oven, preparing meat like this makes much more sense than cooking whole birds or fish or whatever. Removing all the bones and any other inedible parts and also cutting the meat into bite-sized pieces before cooking wastes much less time than when everybody must repeat all these operations every time during eating, so I consider that serving whole animals at a meal is just stupid, even if they may look appetizing for some people.
It sounds like this is steamed meat, as opposed to roasted. Your cooking time seems to match a quick search for steamed chicken recipes: https://tiffycooks.com/20-minutes-chinese-steamed-chicken/
While there is steam in the vessel, it comes only from the water lost from the meat, not from any additional water, and the meat is heated by the microwaves, not by the steam.
Without keeping a lid on the cooking vessel, the loss of water is too rapid and the cooked meat becomes too dry. Even so, the weight of meat is reduced to about two thirds, due to the loss of water.
In the past, I was roasting meat on a covered grill, where the air enclosed in it was heated by a gas burner through an opening located on one side, on its bottom. With such a covered grill, the air in which the meat was cooked would also contain steam from the water lost by the meat, so the end result was very similar to the microwave cooking that I do now, also preventing the meat from becoming too dry, unlike with roasting on an open grill, while also concentrating the flavor and avoiding its dilution by added water or oil.
However, I am frequently lazy, when I buy breasts/thighs without bones.
Some of us also like the food tasting nice besides the reproducibility of the results.
Even for the burned-crust lovers, many microwave ovens have lamps for this purpose, but I cannot say whether the lamps are good at making tasty burned crusts, because I have never used them, since I like more to eat meat than to eat burned crusts.
The good taste of meat prepared in this way is not surprising, because the meat is heated very uniformly and the flavor of the meat is not leached away by added water or oil, but it is concentrated due to the loss of water from the meat, so the taste is very similar to that of meat well cooked on a grill, neither burned nor under-cooked, and also without adding anything but salt and spices.
Let me strongly doubt that.
> the meat is heated very uniformly
Are you sure you are using a microwave oven at all?
The second part is boring. Advertisers are always pushy. It's their work. The interesting part is how much truth in their statements and it depends on the first part.
So maybe it's not high on the list based on the value you are measuring but it definitely has a convenience value that isn't replaced by anything else.
The same thing happened with web search and social media. Now, those selfsame companies are trying to get us to adopt AI. Even if it somehow manages to fulfill its promise, it will only be for a time. Cost-cutting will degrade the service.
Like the remainder of the soup i made yesterday that I've put in a china bowl in the fridge. I was able to eat warm soup out of that bowl without requiring to make any other dishes dirty. Pretty convenient if you ask me.
Bonus: you can take a cherry tomato or a single grape and make a small plasma arc in the microwave. Pretty cool trick to impress and scare people at house parties.
What usually happens is they either empower unskilled (in a particular context) personnel to perform some amount of tasks at "good enough" level or replace highly specialized machinery for some amount of tasks at again "good enough" level.
At some point (typically, when a general purpose technology is able to do "good enough" in multiple contexts) operating at "good enough" enough level in multiple verticals becomes profitable over operating ant specialized level and this is when the general purpose technology starts replacing specialized technology/personnel. Very much not all general-purpose technologies reach this stage at all, this is only applicable to highly successful general purpose technologies.
Then market share of general technology starts increasing rapidly while at the same time market share of specialized technologies drops, RnD in general tech explodes while specialized technologies start stagnating. Over time this may lead to cutting edge general purpose technologies surpassing the now-old specialized technologies, taking over in most areas.
> A very clear example of this is early Tesla surfing the reduction in Li-ion battery prices. <...> By the time the technology is ready for sedans, Tesla has a 5 year lead. > everyone at GM and Toyota was saying: Li-ion batteries are totally infeasible for the consumers we prioritize who want affordable cars.
We are nearly two decades since the Tesla "expensive sports car" and pure BEVs are still the significantly more expensive option, despite massive subsidies. If anything, everyone at Toyota were right. Furthermore, they have been developing their electric drive-trains in parallel via the hybrid tech: surfing the same wave while raking in profits.
In fact, BEV sales outpace other drive-train sales only in regions where either registrations of those are artificially limited, or the government heavily subsidizes both purchase and maintenance costs. If you don't have government subsidized rooftop solar the cost per mile of BEV is more or less on par with a HEV and in most cases worse than diesel for long range trips.
New technology often has ‘new’ tradeoffs, are GPU’s are sill only situationally better than CPU’s.
DC fast charging is several times more expensive than home charging which heavily influences the economics of buying an EV without subsidies. Same deal with plug in Hybrids or long range batteries on PEV, if you don’t need the range you’re just wasting money. So there’s cases when an unsubsidized PEV is the cheapest option and that line will change over time even if it’s not going away anytime soon.
AI on the other hand is such a wide umbrella it doesn’t really make sense to talk about specific tradeoffs beyond the short term. Nobody can say what the downsides will be in 10-20 years because they aren’t extrapolating a specific technology with clear tradeoffs. Self driving cars could be taking over industries in 15 years, or still quite limited we can’t say.
Once in the mid 2000s we figured out that single-thread perf won't scale, GPUs became the next scaling frontier and it was thought that they'd complement and supplant CPUs - with the Xbox and smartphones having integrated GPUs, and games starting to rely on general purpose compute shaders, a lot of folks (including me) thought that the software in the future will constantly pingpong between CPU and GPU execution? Got an array to sort? Let the GPU handle that. Got a JPEG to decode? GPU. Etc.
I took an in depth CUDA course back in the early 2010s, thinking that come 5 years or so, all professional signal processing will move to GPUs, and GPU algorithm knowledge will be just as widespread and expected as how to program a CPU, and I would need to Leetcode a bitonic sort to get a regular-ass job.
What happened? GPUs weren't really used, data sharing between CPU and GPU is still cumbersome and slow, dedicated accelerators like video decoders weren't replaced by general purpose GPU compute, we still have special function units for these.
There are technical challenges sure to doing these things, but very solvable ones.
GPUs are still stuck in 2 niches - video games, and AI (which incidentally got huge). Everybody still writes single-threaded Python and Js.
There was every reason to be optimistic about GPGPU back then, and there's every reason to be optimistic about AI now.
Not sure where this will go, but probably not where we expect it to.
I find it a powerful mental model precisely because it is not a statement of success rate or survival rate: Yes, a lot of ideas never break any kind of viability threshold, sure, but every idea that did also started out as laughable, toy-like, and generally shit (not just li-ion batteries, also the wheel, guns, the internet and mobile computers).
It is essentially saying 'current lack of viability is a bad indicator of future death' (at least not any more than the high mortality of new tech in general), I guess.
Can you share some experience regarding Codex and large scale changes to codebase? I haven't noticed any improvements.
What do you have to say about the circular trillions of dollars going around 7 companies and building huge data centers and expecting all smaller players to just subsidize them?
Sure, you can elide the argument by saying, "actually that doesn't matter because I am really smart and understood what the author really was talking about, let me reframe it properly".
I don't really have a response to that. You're free to do what you please. To me, something feels very wrong with that and this behavior in general plagues the modern Internet.
IMHO the bleeding edge of what’s working well with LLMs is within software engineering because we’re building for ourselves, first.
Claude code is incredible. Where I work, there are an incredible number of custom agents that integrate with our internal tooling. Many make me very productive and are worthwhile.
I find it hard to buy in to opinions of non-SWE on the uselessness of AI solely because I think the innovation is lagging in other areas. I don’t doubt they don’t yet have compelling AI tooling.
No, it's not going to write all your code for you. Yes your skills are still needed to design, debug, perform teamwork(selling your designs, building consensus, etc), etc.. But it's time to get on the train.
IMO LLMs are still at the point where they require significant handholding, showing what exactly to do, exactly where. Otherwise, it's constant review of random application of different random patterns, which may or may not satisfy requirements, goals and invariants.
Also - for most seasoned developers, actual dev activity is miniscule part of overall efforts. If you are churning code like some sweatshop every single day at say 45 its by your own choice, you don't want to progress in career or career didn't push you up on its own.
What I want to say - that miniscule part of the day when I actually get my hands on the code are the best. Pure creativity, puzzle solving, learning new stuff (or relearning when looking at old code). Why the heck would I want to lose or dilute this and even run towards it? It makes sense if my performance is rated only based on code output, but its not... that would be a pretty toxic place to be polite.
Seniority doesn't come from churning out code quicker. Its more long the lines of communication, leading others, empathy, toughness when needed, not avoiding uncomfortable situations or discussions and so on. No room for llms there.
So now with AI, that's even quicker. And I can do it more easily during the half relevant part of meetings, which I have a lot more of nowadays. When I have real time to sit and code, I focus on the hardest and most interesting parts, which the AI can't do.
It is always the talking that transitions "here's quick proof of concept" to "someone else will implement this fully and then maintain". One cannot be catapulted if they cannot offload the implementation and maintenance. Two quick proof of concept ideas you are stuck with and it's already your full capacity. one either talks their way out to having a team supporting them or they find themselves on a PIP with a regular backlog piling up.
Most of my day isn't coding. But sometimes it is. On those days, AI helps me get back to doing the important stuff. Sure, I like solving problems and writing code, but where I add value to my company is in bringing solutions to users and getting them into production.
I'm a systems/embedded engineer. In my 30 years of being employed I've written very little code, relatively speaking. I am not a code monkey cranking out thousands of lines per day or even week. AI is like having an on-demand intern who can do that if I need to, however. I basically gained an employee for free. AI can also saving me time debugging because look, I'm old and I really don't write all that much code. I mess up syntax sometimes. I can't remember some stupid C++ rule or best-practice sometimes. Now I don't have to read a book or google it.
AI is letting me put my experience and intuition to work much more efficiently than ever before and it's pretty cool.
I don't think that's a relevant metric. "learning" rate of humans versus LLMs. If you expect typical LLMs to grow from juniors to competent mids and maybe even seniors faster than typical human, then there is little point to learn to write code, but rather learn "software engineering with artificial code monkey". However, if that turns out to not be true, we have just broken the pipeline producing actual mids and seniors, who can actually oversee the LLMs.
they might be poor at it, but if you do everything you specified online and through a computer, then its in an LLMs domain. If we hadnt pushed so hard for work from home it might be a different story. LLMs are poor on soft skills but is that inherent or just a problem that can be refined away? i dont know
And if you are not "churning code like some sweatshop every single day" those hours are not "hey, let's bang out something cool!", it's more like "here are 5 reasons we can't do the cool thing, young padawan".
I'm happy, it's happy, I've never been more productive.
The longer I do this, the more likely it is to one-shot things across 5-10 files with testing passing on the first try.
Using AI, I constantly realize that a-typical patterns are much rarer than I thought.
Humbling.
It will give the developer a leg up in the future when the mature tools are ready. Just like the people who surfed the 90s internet seem to do better with advanced technology than the youngsters who've only seen the latest sleek modern GUI tools and apps of today.
I think there's an obsession, especially in more veteran SWEs to think they are creating something one of a kind and special, when in reality, we're just iterating over the same patterns.
Claude 3.5 was actually where it could generate simple stuff. Progress kind of tapered off since tho, Claude is still best but Sonnet 4.5 is disappointing in that it does't fundamentally bring me more than 3.5 did it's just a bit better at execution - but I still can't delegate higher level problems to it.
Top tier models are sometimes surprisingly good but they take forever.
And from reading through the forums and talking to co-workers this was a common experience.
Especially Claude, where if you check the forums everyone is complaining that it's gone stupid the last few months.
Claude's code is all over the place, and if you can't see that and are putting it's code into production I pity your colleagues.
Try stopping. Honestly, just try. Just use claude as a super search engine. Though right now ChatGPT is better.
You won't see any drop in productivity.
Its like terminal autocomplete on steroids. Everything around the code is blazing fast.
Secondly it depends what you're using it for within web dev. One shot an entire app? I did that recently for a Chrome extension and while it got many things wrong that I had to learn and fix, it was still waaaaaay faster than doing it myself. Especially for solving stupid JS ecosystem bugs.
Nobody sane is suggesting you just generate code and put it straight into production. It isn't ready for that. It is ready for saving you a ton of time if you use it wisely.
And I do web dev, the code is rubbish. It's actually got subtle problems, even though it fails less. It often munges together loads of old APIs or deprecated ways of doing things. God forbid you need to deal with something like react router or MUI as it will combine code from several different versions.
And yes, people are using these tools to directly put code in. I see devs DOING it. The code sucks.
Vibe coded PRs are a huge timesink that OTHER people end up fixing.
One guy let it run and it changed code in an entirely unrelated part of the system and he didn't even notice. Worse, when scanning the PR it looked reasonable, until I went to fix a 350 line service Claude or codex had puked out that could be rewritten in 20 lines, and realized the code files were in an entirely different search system.
They're also generally both terrible at abstracting code. So you end up with tons of code that does sweet FA over and over. And the constant over engineering and exception handling theatre it does makes it look like it's written a lot of code when it's basically turned what should be a 5 liner into an essay.
Ugh. This is like coding in the FactoryFactoryFactory days all over again.
The teams that have embraced AI in their worlflow have not increased their output compared with they ones that don't use it.
AI Companies have invested a crazy amount of money into a small productivity gain for their customers.
If AI was replacing developers it wouldn’t cost me $20-100/month to get a subscription.
I will get all the goverment IT contracts and make billions in a few months.
Nobody does it because LLMS are a fucking scam, like crypto, and I am tired of pretending is not.
Good for you, though.
I haven't found that to be true
I'm of the opinion that anyone who is impressed by the code these things produce is a hack
Whoever says is time to move to LLMS is clueless.
I have not even seen a CRUD app with real users wrote using AI tools.
Cloudfare gets blocked in some parts of Europe on the weekend... Only the DNS, not really blocked.
Football is more important.
They block random Cloudfare IPs related with sport streaming sites.
Know this: someone is coming after this already.
One day someone from management will hear about a cost-saving story at a dinner table, the words GPT, Cursor, Antigravity, reasoning, AGI will cause a buzzing in her ear. Waking up with tinnitus the next morning, they'll instantly schedule a 1:1 to discuss "the degree of AI use and automation"
Yesterday, GitHub Copilot declared that my less-AI-weary friend’s new Laravel project was following all industry best-practices for database design as it storing entities as denormalized JSON blobs in a MySQL 8.x database with no FKs, indexes, constraints, all NULL columns (and using root@mysql as the login, of course); while all Laravel controller actions’ DB queries were RBAR loops that did loaded all rows into memory before doing JSON deserialisation in order to filter rows.
I can’t reconcile your attitude with my own personal lived experience of LLMs being utterly wrong 40% of the time; while 50% of the time being no better or faster than if I did things myself; another 5% of the time it gets stuck in a loop debating the existence of the seahorse emoji; and the last 5% of the time genuinely utterly scaring me with a profoundly accurate answer or solution that it produced instantly.
Also, LLMs have yet to demonstrate an ability to tackle other real-world DBA problems… like physically installing a new SSD into the SAN unit in the rack.
You can trow all AI you want, but at the end of the day you get what you pay for.
Feed an LLM stack traces or ask it to ask you questions about a topic you're unfamiliar about. Give it a rough hypothesis and demand it poke holes in it. These things it does well. I use Kagi's auto summariser to distil search results in to a hand full of paragraphs and then read through the citations it gives me.
Know that LLMs will suck up to you and confirm your ideas and make up bonkers things a third of the time.
You are doing yourself a huge disservice.
I'm a long time SWE and in the last week, I've made and shipped production changes across around 6 different repos/monorepos, ranging from Python to Golang, to Kotlin to TS to Java. I'd consider myself "expert" in maybe one or two of those codebases and only having a passing knowledge of the others.
I'm using AI, not to fire-and-forget changes, but to explain and document where I can find certain functionality, generate snippets and boilerplate, and produce test cases for the changes I need. I read, review and consider that every line of code I commit has my name against it, and treat it as such.
Without these tools I'd estimate being around 25% as effective when it comes to getting up to speed on unfamiliar code and service. For that alone, AI tooling is utterly invaluable.
AI and LLMs are tools. The best tools tend to be highly focused in their application. I expect AI to eventually find its way to various specific tool uses, but I have no crystal ball to predict what those tools might be or where they will surface. Although I have to say that I have seen, earlier this week, the first genuinely interesting use-case for AI-powered code generation.
A very senior engineer (think: ~40 years of hands-on experience) had joined a company and was frustrated by lack of integration tests. Unit tests, yes. E2E test suite, yes. Nothing in between. So he wrote a piece of machinery to automatically test integration between a selected number of interacting components, and eventually was happy with the result. But since that was only a small portion of the stack, he would have had to then replicate that body of work for a whole lot of other pieces - and thought "I could make AI repeat this chore".
The end result is a set of very specific prompts, constraints, requirements, instructions, and sequences of logical steps that tell one advanced model what to do. One of the instructions is along the lines of "use this body of work I wrote $OVER_THERE as a reference". That the model is building iteratively a set of tests that self-validate the progress certainly helps. The curious insight in the workflow is that once the model has finished, he then points the generated body of work to another advanced model from a different vendor, and has that do an automated code review, again using his original work as a reference material. And then feeds that back to the first model to fix things.
That means that he still has to do the final review of the results, and tweak/polish parts where the two-headed AI went off the rails. But overall the approach saves quite a lot of time and actually scales pretty much linearly to the size of the codebase and stack depth. To quote his presentation note, "this way AI works as a highly productive junior that can follow good instructions, not as a misguided oracle that comes up with inventive reinterpretations."
He made modern AI repeat his effort, but crucially he had had to do the work at least once to know precisely what constraints would apply. I suspect that eventually we'll be seeing more of these increasingly sophisticated but very narrowly tailored tooling use cases to pop up. The best tools are after all focused, even surgical.
ß: Who could have predicted in 1900 that radioactive compounds would change fields ranging from medicine to food storage?
Or, more correctly, they don't work well for my problems or usage. They can at best answer basic questions, stuff you could lookup using a search engine, if you knew what to look for. They can also generate code for inspiration, but you'll end up rewriting all of it before you're done. What they can't do it solve your problem start to end. They really do need a RTFM mode, where they will just insult you if you're approach or design is plain wrong or at least just let you know that it will now stop helping as you're clearly of the rails.
We need to bubble to pop, it'll be a year or two, the finance bros aren't done extracting value from the stonks. Once it does, we can focus on what's working and what isn't and refine the good stuff.
Right now the LLMs are the product, and they can't be, it makes no sense. They need to be embedded within product, either as a built in feature, e.g. CoPilot in Visual Studio, or as plugins, like LSPs.
Clearly others are having more luck with LLMs than I do, and do amazing projects, but that sort of illustrates the point, their aren't ready and we don't have a solution for them to be universally useful (and here I'm even restricting myself to thinking about coding).
Can you give some examples, please?
You’re deliberately disadvantaging yourself by a mile. Give it a go
… the first one’s free ;)
In a 1-year company, the only tech person that's been there for more than 3-4 months (the CTO), only really understands a tiny fraction of the codebase and infrastructure, and can't review code anymore. Application size has blown up tremendously despite being quite simple. Turnover is crazy and people rarely stay for more than a couple months. The team works nights and weekends, and sales is CONSTANTLY complaining about small bugs that take weeks to solve.
The funny thing is that this is an AI company, but I see the CTO constantly asking developers "how much of that code is AI?". Paranoia has set in for him.
Oh, look, you've normalized deviance. All of these things are screaming red flags, the house is burning down around you.
People who don’t yet have the maturity for the responsibility of their roles, thinking that merely adopting a new technology will make up for not taking care of the processes and the people.
The value of a boss/manager when there's no employees to do the work is negative. AI won't change this.
I don't know where you work, but in my experience, headcount reductions are strictly a top-down exercise. At best, the bosses may ask line managers who the essential people on their teams are. At worst, they get handed a list of people to fire, and they themselves may get the boot right after.
Even the execution of "reducing head count" is done by everyone else.
> edit for spelling
They have not necessarily changed the rate at which I produce valuable outputs (yet).
The fact is, value is produced when something can be produced at a fraction of the resources required previously, as long as the cost is borne by the person receiving the end result.
This also makes it harder to prioritize work in an organization. If work is perceived as "cheap" then it's easy to demand teams prioritize features that will simply never be used. Or to polish single user experiences far beyond what is necessary.
We prioritize now based on time complexity and omg, it changes everything: if we have 10 easy bugfixes and one giant feature to do (random bad faith example), we do 5 bugfixes and half the feature within a month and have an enormous satisfaction output from the users who would never have accepted to do it that way in the first place . If we had listened, we would have done 75% of the features and zero bug fixes and have angry users/clients whining that we did nothing all month...
The time spent on dev stuff absolutely matters, and churning quick stuff quickly provides more joy to the people who pay us. It's a delicate balance.
As for AI, for now, it just wastes our time. Always craps out half correct stuff so we optimized our time by refusing to use it, and beat teams who do that way.
It's a code laundering machine. Software engineering has a higher number of people who have never created anything by themselves and have no issues with copyright infringement. Other professions still tend to take a broader view. Even unproductive people in other professions may have compunctions about stealing other people's work.
Kind of how for the longest time, Google used to be best at finding solutions to programming problems and programming documentation: say, a Google built by librarians would have a totally different slant.
Perhaps that's why designers don't see it yet, no designers have built Claude's 'world-view'.
With subagents and A2A generally, you should be able to hook any of them into your preferred agentic interface
(Agent SDK, not android)
AGI is a lot of things, a lot of ever moving targets, but it's never (under any sane definition) "infinite growth". That's already ASI territory / singularity and all that stuff. I see more and more people mixing the two, and arguing against ASI being a thing, when talking about AGI. "Human level competences" is AGI. Super-human, ever improving, infinite growth - that's ASI.
If and when we reach AGI is left for everyone to decide. I sometimes like to think about it this way: how many decades would you have to go back, and ask people from that time if what we have today is "AGI".
[1] - https://ia.samaltman.com/#:~:text=we%20will%20have-,superint...
Meta just laid 600 of them off.
All this talk of AGI, ASI, super-intelligence, and recursive self-improvement etc is just undefined masturbatory pipe dreams.
For now it's all about LLMs and agents, and you will not see anything fundamentally new until this approach has been accepted as having reached the point of diminishing returns.
The snake oil salesmen will soon tell you that they've cracked continual learning, but it'll just be memory, and still won't be the AI intern that learns on the job.
Maybe in 5 years we'll see "AlphaThought" that does a better job of reasoning.
Like we can theoretically build a spaceship that can accelerate to 99.9999% C - just a constant 1G accel engine with "enough fuel".
Of course the problem is that "enough fuel" = more mass than is available in our solar system.
ASI might have a similar problem.
I don’t disagree that these are useful tools, by the way. I just haven’t seen any discernible uptick in general software quality and utility either, nor any economic uptick that should presumably follow from being able to develop software more efficiently.
There are many really lucrative markets that need a fresh approach, and AI doesn't seem to have caused a huge explosion of new software created by upstarts.
Or am I missing something? Where are the consumer facing software apps developed primarily with AI by smaller companies? I'm excluding big companies because in their case it's impossible to prove the productivity, the could be throwing more bodies at the problem and we'd never know.
The challenge in competing with these products is not code. The challenge competing in lucrative markets that need a fresh approach is also generally not code. So I’m not sure that is a good metric to evaluate LLMs for code generation.
I could see it being doable by forking LibreOffice or Calligra Suite as a starting point, although even with AI assistance I'd imagine that it might take anyone not intimately familiar with both LibreOffice (or Calligra) and MS Office longer than a weekend to determine the full scope of the delta between them, much less implement that delta.
But you'd still need someone with sufficient skill (not a novice), maybe several hundred or thousand dollars to burn, and nothing better to do for some amount of time that's probably longer than a weekend. And then that person would need some sort of motivation or incentive to go through with the project. It's plausible, but not a given that this will happen just because useful agentic coding tools exist.
So where are they?
We're not asking to evaluate LLM's for code. We're asking to evaluate them as product generators or improvers.
I can go to Wendys or I can make my own version of Wendys at home pretty easily with just a bit more time expended.
The cliff is still too high for software. I could go and write office from scratch or customize the shivers FOSS software out there but its not worth the time effort.
So, where is that in the 2020s?
Yes, code is a detail (ideas too). It's a platform. It positions itself as the new thing. Does that platform allow upstarts? Or does it consolidate power?
We have superhuman coding (https://news.ycombinator.com/item?id=45977992), where are the superhuman coded major apps from small companies that would benefit most from these superhumans?
Heck, we have superhuman requirements gathering, superhuman marketing, superhuman almost all white collar work, so it should be even faster!
the jury is still out on that...
Of course it's a collaborative process — you can't just tell it to document the code with no other information and expect it to one-shot exactly what you wanted — but I find that documentation is actually a major strength of LLMs.
This ignorance or failure to address these aspects of the issue and solely focus on its utility in a vacuum is precisely the blinkered perspective that will enable the consolidations of power the essay is worried about...the people pushing this stuff are overjoyed that so few people seem to be paying any attention to the more significant shifts they are enacting (as the article states, land purchase, political/capital power accumulation, reduction of workforces and operating costs and labor power... the list goes on)
The mistake is to project the same level of productivity provided by LLMs in coding to all other areas of work.
The point of TFA is that LLMs are an excellent tool for particular aspects of work (coding being one of them), not a general intelligence tool that improves all aspects (as we're being sold).
If LLMs only disrupt software engineering and content slop, the economy is going to undergo rapid changes. Every car wash will have a forward deployed engineer maintaining their mobile app, website, backend, and LLM-augmented customer service. That happens even if LLMs plateau in six months.
However, while I like using AI for software development, as also a middle-manager, it increased my output A TON because AI works better for virtually anything that's not software development.
Examples: Update Jira issues in bulk, write difficult responses and incident reports, understand a tool or system I'm not familiar with, analyse 30 projects to understand which of them have this particular problem, review tickets in bulk to see if they have anything missing that was mentioned in the solution design, and so on ... All sorts tasks that used to take hours, now take minutes.
This is in line with what I'm hearing from other people: My CFO is complaining daily about running out of tokens. My technical sales relative says it is now taking him minutes to create tech specs from requirements of his customers, while it used to take hours.
While devs are rightfully "meh" because they truly need to review every single line generated by AI and type-writing the code is not their bottleneck anyway. It is harder to realise the gains for them.
The only reply I have got to this question was: it created a sap script.
How are we building _for_ ourselves when we literally automate away our jobs? This is probably one of the _worst_ things someone could do to me.
Maybe that will continue with AI, or maybe our long-standing habit will finally turn against us.
The declared goal of AI is to automated software engineering entirely. This is in no way comparable to building an assembler. So the question is mostly about whether or not this goal will be achieved.
Still, nobody is building these systems _for_ me. They're building them to replace me, because my living is too much for them to pay.
But here's the thing: the hard part of programming was never really syntax, it was about having the clarity of thought and conceptual precision to build a system that normal humans find useful despite the fact they will never have the patience to understand let alone debug failures. Modern AI tools are just the next step to abstracting away syntax as a gatekeeper function, but the need for precise systemic thinking is as glaringly necessary as ever.
I won't say AI will never get there—it already surpasses human programmers in many of the mechanical and rote knowledge of programing language arcana—but it it still is orders of magnitude away from being able to produce a useful system when specified by someone who does not think like a programmer. Perhaps it will get there. But I think the barrier at that point will be the age old human need to have a throat to choke when things go sideways. Those in power know how to control and manipulate humans through well-understood incentives, and this applies all the way to the highest levels of leadership. No matter how smart or competent AI is, you can't just drop it into those scenarios. Business leaders can't replace human accountability with an SLA from OpenAI, it just doesn't work. Never say never I suppose, but I'd be willing to bet the wheels come off modern civilization long before the skillset of senior software engineers becomes obsolete.
Syntax is not a gatekeeper function. It’s exactly the means to describe the precise systemic thinking. When you’re creating a program, you’re creating a DSL for multiple subsystem, which you then integrate.
The subsystem can be abstract, but we usually define good software by how closely fitted the subsystem are to the problem at hand, meaning adjustments only need slight code alterations.
So viewing syntax as a gatekeeper is like viewing sheet music as a gatekeeper for playing music, or numbers and arithmetic as a gatekeeper for accounting.
I can't directly compile that into instructions which will make a CPU do the thing, but for the purposes of describing that component of a system, it's at about the right level of abstraction to reasonably encode the expected behavior. Aside from choosing specific libraries/APIs, there's not much remaining depth to get into without bikeshedding; the solution space is sufficiently narrow that any conforming implementation will be functionally interchangeable.
AI is just laying bare that the hard part of building a system has always been the logic, not the code per se. Hypothetically, one can imagine that the average developer in the future might one day think of programming language syntax in the same way that an average web developer today thinks of assembly. As silly as this may sound today, maybe certain types of introductory courses or bootcamps would even stop teaching code, and focus more on concepts, prompt engineering, and developing/deploying with agentic tooling.
I don't know how much learning syntax really gatekeeps the field in practice, but it is something extra that needs to be learned, where in theory that same time could be spent learning some other aspect of programming. More significant is the hurdle of actually implementing syntax; turning requirements into code might be cognitively simple given sufficiently baked requirements, but it is at minimum time-consuming manual labor which not everyone is in a position to easily afford.
I won't unless both you and I have a shared context which will tie each of these concept to a specific thing. You said "async function", and there's a lot of languages that don't have that concept. And what about the permissions of the s3 bucket, what's the initial time of the wait time? And what algorithm for the resizing? What if someone sent us a very big image (let say the maximum that the standard allows).
These are still logic questions that have not been addressed.
The thing is that general programming languages are general. We do have constructs like procedure/functions and class, that allows us for a more specialized notation, but that's a skill to acquire (like writing clear and informative text).
So in pseudo lisp, the code would be like
(defun fn (bytes)
(when-let\* ((png (byte2png bytes))
(valid (and (valid-png-p png)
(square-res-p png)))
(small-png (resize-image png))
(bucket (get-env "IMAGE_BUCKET"))
(filename (uuid)))
(do-retry :backoff 'exp
(s3-upload bucket small-png))))
And in pseudo prolog square(P) :- width(P, W), height(P, H), W is H.
validpng(P, X) :- a whole list of clauses that parses X and build up P, square(P).
resizepng(P) :- bigger(100,100, P), scale(100, 100, P).
smallpng(P, X) :- validpng(P, X), resizepng(P).
s3upload(P): env("IMAGE_BUCKET", B), s3_put(P, B, (exp_backoff(100))))
fn(X) :- smallpng(P, X), s3upload(P)
So what you've left is all the details. It's great if someone already have an library that already does the thing, and the functions has the same signature, but more often than not, there isn't something like that.Code can be as highlevel as you want and very close to natural language. Where people spend time is the implementation of the lower level and dealing with all the failure modes.
The fact that you're able to confidently take what I wrote and stretch it into pseudocode with zero deviation from my intended meaning proves my point.
I can create a pseudocode because I know the relevant paradigm as well as how to design software. There’s no way you can have a novice draft pseudo-code like this because they can’t abstract well and discern intent behind abstractions.
Collaborating with AI also speeds this up a lot. For example, it's much faster to have the AI write a code snippet involving a dependency/API and manually verify the code's correctness for inclusion in the spec than it is to read though documentation and write the same code by hand.
The feat of implementing that function based on my description is well within the capabilities of AI. Grok did it in under 30 seconds, and I don't see any obvious mistakes at first glance: https://grok.com/share/c2hhcmQtMw_fa68bae1-3436-404b-bf9e-09....
Reading the documentation is mostly for gotchas and understanding the subsystem you're going to incorporate in your software. You can not design something that will use GTK or sndio without understanding the core concepts of those technologies. And if you know the concepts, then I will say it's easier and faster to write the code than to write such specs.
As for finding samples, it's easy on the web. Especially with GitHub search. But these days, I often take a look at the source code of the library itself, because I often got questions that the documentation don't have the answer for. It's not about what the code I wrote may do (which is trivial to know) but what it cannot do at all.
import { env } from './env';
import { v4 as uuidv4 } from 'uuid';
import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
import sharp from 'sharp';
async function retry<T>(fn: () => Promise<T>, maxAttempts: number): Promise<T> {
let attempt = 1;
while (true) {
try {
return await fn();
} catch (error) {
if (attempt >= maxAttempts) {
throw error;
}
const delayMs = Math.pow(2, attempt - 1) * 100;
await new Promise((resolve) => setTimeout(resolve, delayMs));
attempt++;
}
}
}
export async function processAndUploadImage(s3: S3Client, imageData: Uint8Array): Promise<string> {
let metadata;
try {
metadata = await sharp(imageData).metadata();
} catch {
throw new Error('Invalid image');
}
if (metadata.format !== 'png') {
throw new Error('Not a PNG image');
}
if (!metadata.width || !metadata.height || metadata.width !== metadata.height || metadata.width < 100) {
throw new Error('Image must have a 1:1 aspect ratio and resolution >= 100x100');
}
const resizedBuffer = await sharp(imageData).resize(100, 100).toBuffer();
const key = `${uuidv4()}.png`;
const command = new PutObjectCommand({
Bucket: env.IMAGE_BUCKET,
Key: key,
Body: resizedBuffer,
ContentType: 'image/png',
});
await retry(async () => {
await s3.send(command);
}, 100);
return key;
}
The prompting was the same as above, with the stipulations that it use TypeScript, import `env` from `./env`, and take the S3 client as the first function argument.You still need reference information of some sort in order to use any API for the first time. Knowing common Node.js AWS SDK functions offhand might not be unusual, but that's just one example. I often review source code of libraries before using them as well, which isn't in any way contradictory with involving AI in the development process.
From my perspective, using AI is just like having a bunch of interns on speed at my beck and call 24/7 who don't mind being micromanaged. Maybe I'd prefer the end result of building the thing 100% solo if I had an infinite amount of time to do so, but given that time is scarce, vastly expanding the resources available to me in exchange for relinquishing some control over low-priority details is a fair trade. I'd rather deliver a better product with some quirks under the hood than let my (fast, but still human) coding speed be the bottleneck on what gets built. The AI may not write every last detail exactly the way I would, but neither do other humans.
I’m not saying that I write flawless code, but I’m more for less feature and better code. I’ve battled code where people would add big libraries just to not write ten lines of code. And then can’t reason when a snippet fails because it’s unreliable code into unreliable code. And then after a few months, you got zombie code in the project. And the same thing implemented multiple times in a slightly different way each time. These are pitfalls that occur when you don’t have an holistic view of the project.
I’ve never found coding speed to be an issue. The only time when my coding is slow is when I’m rewriting some legacy code and pausing every two lines to decipher the intent with no documentation.
But I do use advanced editing tools. Coding speed is very much not a bottleneck in Emacs. And I had a somewhat similar config for Vim. Things like quick access to docs, quick navigation (thing like running a lint program and then navigating directly to each error), quick commit, quick blaming and time traveling through the code history,…
This is a bit of a reach. There's no reason to assume that the entire project would only be using one endpoint, or that AI would have any trouble coding against the REST API instead if instructed to. Using the official SDK is a safe default in the absence of a specific reason or instruction not to.
Either way, we're already past the point of demonstrating that AI is perfectly capable of writing correct pseudocode based on my description.
> Coding speed is very much not a bottleneck in Emacs.
Of course it is. No editor is going to make your mind and fingers fast enough to emit an arbitrarily large amount of useful code in 0 seconds, and any time you spend writing code is time you're not spending on other things. Working with AI can be a lot harder because the AI is doing the easy parts while you're multitasking on all the things it can't do, but in exchange you can be a lot more productive.
Of course you still need to have enough participation in the process to be able to maintain ownership of the task and be confident in what you're committing. If you don't have a holistic view of the project and just YOLO AI-generated code that you've never looked at into production, you're probably going to have a bad time, but I would say the same thing about intern-generated code.
> I’m more for less feature and better code.
Well that's part of the issue I'm raising. If you're at the point of pushing back on business requirements in the interest of code quality, that's just another way of saying that coding speed is a bottleneck. Using AI doesn't only help with rapidly pumping out more features; it's an extremely useful tool for fixing bugs at a faster pace.
IMO, useful code is code in production (or if it’s for myself, something I can run reliably). Anything else is experimentation. If you’re working in a team, code shared with others are proposal/demo level.
Experimentation is nice for learning purpose. Kinda like scratch notes and manuscripts in the writing process. But then, it’s the editing phase when you’re stamping out bugs, with tools like static analysis, automated testing, and manual qa. The whole goal is to have the feature in the hand of the users. Then there’s the errata phase for errors that have slipped trough.
But the thing is code is just a static representation of a very dynamic medium, the process. And a process have a lot of layers. The code is usually a small part of the whole. For the whole thing to be consistent, parts need to be consistent with each other, and that’s when contract cames into place.The thing with generated AI code is that they don’t respect contracts. Because of their nature (non deterministic) and the fact that the code (which is the most faithful representation of the contracts can be contradictory (which leads to bugs).
It’s very easy to write optimistic code. But as the contracts (or constraints) in the system grew in number, they can be tricky to balance. The rescourse is always to go up a level in abstraction. Make the subsystems blackboxes and consider only their interactions. This assumes that the subsystems are consistent in themselves.
Code is not the lowest level of abstraction, but it’s often correct to assume that the language itself is consistent. Then it’s the libraries and the quality varies. Then it’s the framework and often it’s all good until it’s not. Then it’s your code and that’s very much a mistery.
All of this to say that writing code is the same as writing words on a manuscript to produce a book. It’s useful but only if it’s part of the final product or help in creating it. Especially if it’s not increasing the technical debt exponentially.
I don’t work with AI tools because by the time I’m ok with the result, more time have been spent than if I’ve done the thing without. And the process is not even enjoyable.
If what you're saying is that your current experience involves a lot of process and friction to get small changes approved, that seems like a reasonable use case for hand-coding. I still prefer to make changes by hand myself when they're small and specific enough that explaining the change in English would be more work than directly making the change.
Even then, if there's any incentive to help the organization move more quickly, and there's no policy against AI usage, I'd give it a shot during the pre-coding stages. It costs almost nothing to open up Cursor's "Ask" mode and bounce your ideas off of Gemini or have it investigate the root cause of a bug.
What I typically do is have Gemini perform a broad initial investigation and describe its findings and suggestions with a list of relevant files, then throw all that into a Grok chat for a deeper investigation. (Grok is really strong at analysis in general, but its superpower seems to be a willingness to churn on sufficiently complex problems for as long as 5+ minutes in order to find the right answer.) I'll often have a bunch of Cursor agents and Grok chats going in parallel — bouncing between different bug investigations, enhancement plans, and one or two code reviews and QA tests of actual changes. Most of the time that AI saves isn't the act of emitting characters in and of itself.
Its hardly the first thing that has that as its “declared goal” (i.e., the fantasy sold by to investors to get capital and the media to get attention.)
If you're just in it to collect a salary, then yeah, maybe you do benefit from delivering the minimum possible productivity that won't get you fired.
But if you like making computers do things, and you get joy from making computers do more and new things, then LLMs that can write programs are a fantastic gift.
Maybe currently if you enjoy social engineering an LLM more than writing stuff yourself. Feels a bit like saying "if you like running, you'll love cars!"
In the future when the whole process is automated you won't be needed to make the computer do stuff, so it won't matter whether you would like it. You'll have another job. Likely one that pays less and is harter on your body.
Maybe some future version of agentic tooling will decimate software engineering as a career path, but that's just another way of saying that everyone and their grandmother would suddenly have the ability to launch a tech startup. Having gone through fundraising in the past, I'd personally prefer to live in a world where anyone with a good idea could get access to the equivalent of a full dev team without raising a dime.
This is the crux of the OP's argument, adding in that (in the meantime) the incumbents and/or bad actors will use it as a path to intensify their political and economic power.
But to me the article fails to:
(1) actually make the case that AI's not going to be 'valuable enough' which is a sweeping and bold claim (especially in light of its speed), and;
(2) quantify AI's true value versus the crazy overhyped valuation, which is admittedly hard to do - but matters if we're talking 10% of 100x overvalued.
If all of my direct evidence (from my own work and life) is that AI is absolutely transformative and multiplies my output substantially, AND I see that that trend seems to be continuing - then it's going to be a hard argument for me to agree with #1 just because image generation isn't great (and OP really cares about that).
Higher Ed is in crisis; VC has bet their entire asset class on AI; non-trivial amounts of code are being written by AI at every startup; tech co's are paying crazy amounts for top AI talents... in other words, just because it can't one-shot some complex visual design workflow does not mean (a) it's limited in its potential, or (b) that we fully understand how valuable it will become given the rate of change.
As for #2 - well, that's the whole rub isn't it? Knowing how much something is overvalued or undervalued is the whole game. If you believe it's waaaay overvalued with only a limited time before the music stop, then go make your fortune! "The Big Short 2: The AI Boogaloo".
The market can remain irrational longer than you can remain solvent.
edit: by well designed I mean that they put the lies in a chart or something. The lies themselves may be quite obvious to spot, like saying that 86% of marriages in Spain end in divorces (when the reality is hard to measure but more likely about 50%). Still, Facebook users don't seem to spot them (or maybe the ones spotting them don't comment?).
They think that if an engineer makes $100k, then making a machine that produce the work of 100 million of them, that machine would be worth $10/T per year. This certainly wouldn't be the case as the supply and demand would dictate that as cost goes down, there's going to be more demand, but not to an infinite degree, and the overall contribution to the economic output would probably be within 2x of what we have today, it's just that something that used to cost a lot, is suddenly very cheap and widely available.
There'd be an economic bottleneck somewhere else. I think most people nowadays understand that A: technology in general has hit diminishing returns and B: it has gotten increasingly sinister overtones.
I held and continue to hold that software engineer shouldn't be constrained to any specific language. And extrapolate to the entire engineering field, the engineering profession will continue to exist because to first translate a business or real life scenario into logic, you would need to describe it accurately - the rest of the translation is rote work. That describing things accurately is a skill I see most common (but still not common enough) among engineers, even if that is done in English.
I'm hoping that AI programming pushes more people toward the engineering side and as it takes over the rote work side. There will be people far to the programmer side that might be put out of a job, but the creative, innovative, inventive engineering positions will persist.
But it does open up engineering to do much more on otherwise under engineered areas and open up entire new fields.
My experience with AI in the design context tends to reflect what I think is generally true about AI in the workplace: the smaller the use case, the larger the gain.
This might be the money quote, encapsulating the difference between people who say their work benefits from LLMs and those who don't. Expecting it to one-shot your entire module will leave you disappointed, using it for code completion, generating documentation, and small-scale agentic tasks frees you up from a lot of little trivial distractions.I think one huge issue in my life has been: getting started
If AI helps with this, I think it is worth it.
Even if getting started is incorrect, it sparks outrage and an "I'll fix this" momentum.
Worth what? I probably agree, the greenfield rote mechanical tasks of putting together something like a basic interface, somewhat thorough unit tests, or a basic state container that maps to a complicated typed endpoint are things I'd procrastinate on or would otherwise drain my energy before I get started.
But that real tangible value does need to have an agreeable *price* and *cost* depending on the context. For me, that price ceiling depends on how often and to what extent it's able to contribute to generating maximum overall value, but in terms of personal economic value (the proportion of my fixed time I'm spending on which work), if it's on an upward trend of practical utility, that means I'm actually increasing the proportion of dull tasks I'm spending my time on... potentially.
Kind of like how having a car makes it so comfortable and easy and ostensibly fast to get somewhere for an individual—theoretically freeing up time to do all kinds of other activities—that some people justify endless amounts of debt to acquire them, allowing the parameters of where they're willing to live to shift further and further to the point where nearly all of their free time, energy, and money is spent on driving, all of their kids depend on driving, and society accepts it as an unavoidable necessity; all the deaths, environmental damage, side-effects of decreased physical activity and increased stress along for the ride. Likewise how various chat platforms tried to make communication so friction-less that I actually now want to exchange messages with people far less than ever before, effectively a foot gun
Maybe America is once again demolishing its cities so they can plow through a freeway, and before we know it, every city will be Dallas, and every road will be like commuting between San Jose to anywhere else—metaphorically of course, but also literally in the case of infrastructure build— when will it be too late to realize that we should have just accepted the tiny bit of hardship of walking to the grocery store.
------
All of that might be a bit excessive lol, but I guess we'll find out
Perhaps a human coworker or colleague would help?
"This lump of code is producing this behaviour when I don't want to"
Is a quick way to find/fix bugs (IME)
BUT it requires me to understand the response (sometimes the AI hits the nail on the head, sometimes it says something that makes my brain - that's not it, but now I know exactly what it is
If it's a less trodden path expect it to hallucinate some settings.
Also a regular thing I see is that it adds some random other settings without comment and then when you ask it about them it goes, whoops, yeah, those aren't necessary.
For instance, we still use steel - and for 99% of humanity's existence nobody knew how to make it. It turns out it's really easy, and it's just one amongst countless other techs along a similar lines. A human who spent a year dedicating himself to consuming freely accessible information, who was then warped back into the past, could send humanity forward by tens of thousands of years - all by himself.
We're all free to use these technologies in any way we see fit, but somehow we've created this weird society where we have all the potential in the world, but instead we spend inordinate amounts of time doing pointless things like shit posting on the internet and mostly being upset about what we can't do and/or have, even though even if we had access to such in all probability we'd again take it for granted and find something else to complain about.
This isn't really a condemnation of humanity. Probably this sort of eternal discontent we have is precisely what drove us to discover all of these great things. Like I mean who in their right mind would have left the basic oasis of Africa to go freeze their ass off and struggle just to live in the inhospitable areas up north? There's something wrong with that guy, and that guy is all of us, for the most part.
Wow! That's a great many indeed. Can you just name 1 though? Just 1?
Let's start with fire, certainly making and controlling fire is a skill that uses knowledge, a "technology". Go from there, try to find one technology that did not find itself in the service of power, for consolidating resources, etc..
Don't get me wrong, I think might, both intellectual and physical, should serve the purposes of benevolence and valour. I'm not complaining, I'm taking note of reality.
...PBS? Sesame Street has only ever been a boon to the common kid.
Only recently in my life have I developed an appreciation for fiction, because it contains deep insights into human behavior. I often fantasize about traveling back to the past, and explaining to folks that we've been to the moon, explored the planets, etc. It's a fun thought exercize, but I think the "reality" of such an experience would be more like this:
https://www.gutenberg.org/files/11870/11870-h/11870-h.htm#li...
I don't know that this is the correct characterization of how out-of-Africa migrations progressed. Youth (and people with the influence to shield themselves from danger) are expeditious, families and societies head where living looks to be easier and away from where living looks to be hard, whatever the pressure may be.
>this weird society where ... we spend inordinate amounts of time ... shit posting
human life is a strange business that has come about as a fleeting side effect of eons of DNA reproduction. I think things could maybe be improved there.
And printing presses themselves ended up being licensed by the state, e.g. this in England: https://en.wikipedia.org/wiki/Licensing_of_the_Press_Act_166...
Summary of above: cool and useful!
Example based on the above: cool and insightful!
Slamming someone for using a european example because that's what they know: not cool, not insightful, not useful.
Please don't take out your embarrassment on me.
But I suppose this analogy reveals that your tack is fundamentally European. So, at least you're consistent. What would be better is if you'd have some humility. Say it with me now: "We forgot to consider prior art because it originated from a part of the world that we tend to fail to acknowledge. This failure adulterated our analysis with an inferior premise. Thank you for pointing this out. We will now make a more appropriate analysis using research on the subject that was previously in our blindspot."
You know exactly why this in particular hits a nerve.
That was only true for a subset of polities. Not all had kings, and some had elected kings etc.
the wheel
bicycles
sewing machines
hand tools
musical instruments
open radio bands like CB and FRS
ham radio (licensing exists but not corporate control)
meshtastic
blacksmithing
glass blowing
garden tools
propane camp stoves
mechanical clocks and watches
open source software (the ecosystem overall, not specific projects)
email as a protocol
RSS
SMS as a protocol
USB storage devices
SIP based VOIP
mesh networking gear
3d printers in the hobby market
drones under 250g
amateur astronomy gear
microcontrollers like Arduino
LED strips and controllers
bicycles
composting tech
sourdough starter culture tech (yes really)bicycles --> police forces, see the Japanese in Malaya 1941
sewing machines --> factory labor, mass production of clothes
hand tools --> Guild systems
musical instruments --> organized religion, national anthems, cultural soft power
open radio bands --> policing, surveillance
blacksmithing --> weapons
etc. etc. we can do this all day :)
> The list of technologies that have not become a front for consolidation of resources and power _and which consumed capital investments equal to a significant portion of the entire market_ appears below
I love torrent, but it's legal used are cripple by corporate infra, so it's mostly florishing thanks to illegal stuff paid by shady ads.
What's the business model though? Most Russian torrents are about giving away copyrighted stuff for free.
UPD: I've checked what ads it shows me on Rutracker - it's VPN services and online gambling. Youtube and Facebook have shown me worse
If anything I have more sympathy for that mafia.
It's also of note that on Facebook I don't get many online casino ads, I get mostly reMarkable ads, there was one from Roli when they launched their new instrument, and others were mostly advertising stuff to me that I already bought elsewhere. I think it might be because I had banned the first dozen of such ads, and they stopped coming.
BTC itself can't do that: the transaction rate would be borderline even just for a low-ball estimate of all the once-a-month payments happening in just the city of Berlin.
The various proposals for layer-2 stuff makes it look like a bunch of banks using a funky currency without any of the controls that exist because weird currencies are bad for business, but AFAICT because of that, the BTC part itself works like interbank balancing transactions, and the BTC transaction rate isn't sufficient to cover once-a-day interbank balancing transactions.
- These solutions are easier for people, and therefore will win in the long run
- these solutions benefit companies because of the surveillance data they have access to now. They always had some data, but now they collect and process even more
- those who control AI will be the kings of the future, so naturally everyone will be running toward this goal
The average user I've seen takes LLM output as objective fact. One only needs to look at muskgrok to see where that's headed.
But AI is certainly going to be the death knell
It seems glib, rather than insightful.
And it's not "we" who'll push, unless you're an AI investor, of course.
That can’t be good