2,780 karma · joined September 17, 2016
The difference is that in gambling 'the house always wins', but in our case we do make progress towards our goal of conquering the world with our newly minted apps.
The situation where this comparison holds is when vibe coding leads nowhere and you don't accomplish anything but just burn through tokens.
Software engineers work on Jira tickets, created by product managers and several layers of middle managers.
But the power of recent models is not in working on cogs, their true power is in working on the entire mechanism.
When talking about a piece of software that a company produces, I'll use the analogy of a puzzle.
A human hierarchy (read: company) works on designing the big puzzle at the top and delegating the individual pieces to human engineers. This process goes back and forth between levels in the hierarchy until the whole puzzle slowly emerges. Until recently, AI could only help on improving the pieces of the puzzle.
Latest models got really good at working on the entire puzzle - big picture and pieces.
This makes human hierarchy obsolete and a bottleneck.
The future seems to be one operator working on the entire puzzle, minus the hierarchy of people.
Of course, it's not just about the software, but streams of information - customer support, bug tickets, testing, changing customer requirements.. but all of these can be handled by AI even today. And it will only get better.
This means different things depending on which angle you look at it - yes, it will mean companies will become obsolete, but also that each employee can become a company.
It is highly unlikely that the hardware which makes LLMs possible would have been developed otherwise.
Isn't that amazing ?
Just like internet grew because of p*rn, AI grew because of video games. Of course, that's just a funny angle.
The way I see it, AI isn't accidental. Its inception has been in the first chips, the Internet, Open Source, Github, ... AI is not just the neural networks - it's also the data used to train it, the OSes, APIs, the Cloud computing, the data centers, the scalable architectures.. everything we've been working on over the last decades was inevitably leading us to this. And even before the chips, it was the maths, the physics ..
Singularity it seems, is inevitable and it was inevitable for longer than we can remember.
There's this interesting arc of growth for apps which are successful. At first users love it, company grows, founders get rich, they hire expensive people to develop the product and increase revenue until eventually the initial culture and mission is replaced by internal politics and processes.
Software starts getting features which users don't want or need, side effects of the company size and their Q4 roadmap to 'optimize' revenue|engagement|profits|growth|...
Users become tools in the hands of the app they initially used as a tool. This model worked well so far and built some of the biggest companies in history.
AI could make this business model less effective. Once a piece of software becomes successful and veers off into crap territory, people will start cloning it, keeping only the features that made that software successful initially. Companies who try to strong arm their users will see users jump ship, or rather, de-board on islands.
At least I hope this will be the case.
From the tools which were used to design and develop the models (programming languages, libraries) to the operating systems running them to the databases used for storing training data .. plus of course they were trained mostly on open source code.
If OSS didn't exist, it's highly unlikely that LLMs would have been built.
Where `:people` is a key in a huge (larger than memory) map. This database will only touch the referenced nodes when traversing, without loading the whole thing into memory.
So the 'query language' is actually your programming language. To the programmer this database looks like an in-memory data structure, when in fact it's efficiently reading data from the disk. Plus immutability of course (meaning you can go back in history).
People use software for specific features, but most software have lots of features people never use or need. A lot of modern software is designed to handle lots of users, so they need to be scalable, deployable, etc.
I don't need any of that. I just need the tool to do the thing I want it to do. I'm not thinking about end users, I just need to solve my specific problem. Sure there might be better pieces of software out there, which do more things. But the vibe coded thing works quite well for me and I can always fix it by prompting the model.
For example, I've vibe coded a tool where I upload an audio file, the tool transcribes it and splits it into 'scenes' which I can sync to audio via a simple UI and then I can generate images for each scene. Then it exports the video. It's simple, a bit buggy, lacks some features, but it does the job.
It would have taken me weeks to get to where I am now without having written one manual line of code.
I need the generated videos, not the software. I might eventually turn it into a product which others can use, but I don't focus on that yet, I'm solving my problem. Which simplifies the software a lot.
After I'm finished with this one, I might generate another one, now that I know exactly what I want it to do and what pitfalls to avoid. But yeah, the age of industrial software is upon us. We'll have to adapt.
The situation is far from similar now. Now there's an app for everything and you must use all of them to function, which is both great and horrible.
From my experience, current generation of AI is unreliable and so cannot be trusted. It makes non-obvious mistakes and often sends you off on tangents, which consumes energy and leads to confusion.
It's an opinion I've built up over time from using AI extensively. I would have expected my opinion to improve after 3 years, but it hasn't.
At the same time, a million people talk to chatgpt about suicide each week, there's an epidemic of loneliness, mental health issues, wars, famines, pollution, climate change and the list goes on.
Work is not just about earning wages. A lot of people find a sense of purpose, a sense of belonging, community, pride and joy in the work they do. For many it's also about the hierarchy, the title, the career ladder, etc.
I for one don't see how more automation / tech is going to fix the fundamental problems that the previous waves of automation have left behind.
Or lose control of the codebase, which you no longer understand after weeks of vibing (since we can only think and accumulate knowledge at 1x).
Sometimes the easy way out is throwing a week of generated code away and starting over.
So that 3x doesn't come for free at all, besides API costs, there's the cost of quickly accumulating tech debt which you have to pay if this is a long term project.
For prototypes, it's still amazing.
The population (especially the youth) is anesthetized by social media, shorts, fear-inducing news, economic hopelessness, climate extremes..
In the meantime, everything is getting integrated - banks, tax systems, tech platforms. Now this age verification.. And of course, AI is being implemented everywhere so that no one can evade the big brother.
As it stands now, this Internet is no longer salvageable imo.
Eg.
> transducer-first design, laziness either eliminated or opt-in
You can write your code using transducers or opt-in for laziness in Clojure now. So it's a matter of choice of tools, rather than a feature of the language.
> protocols everywhere as much as practically possible (performance)
Again, it's a choice made by the programmer, the language already allows you to have protocols everywhere. It's also how Clojure is implemented under the hood.
-> first-class data structures/types are also CRDT data types, where practical (correctness and performance)
Most of the programs I worked on, did not require CRDT. I'm inclined to choose a library for this.
> first-class maps, vectors, arrays, sets, counters, and more
Isn't this the case already ? If Clojure's native data structures are not enough, there's the ocean of Java options..
Which leads to a very interesting question:
How should the 'real' AGI respond to your request ?
Ok. I know this is all hypothetical. But I don't buy this premise.
Why is the server faulty ? In what way does it fail ? How do you know it's because it's processing more than one request at a time ? What if there are multiple clients each doing one request only ? Do you have control over the server code ? If so, fix it there!
---
The point is, this solution is fixing the wrong problem and introducing a new one down the line.
If the bug on the server gets fixed, you've now implemented an artificial performance bottleneck on the client.
Devs who know about it are going to leave the org, others are going to try to 'optimize' the code around it with other hacks, since by allowing these kinds of fixes you're building to the wrong kind of culture. Always fix the root issue.
Or change the premise of the problem.
Here's a simple theoretical situation. A brilliant mathematician with very high IQ crashes in the jungle, but is unhurt.
Not far from the crash site, there's a tribesman who lived in the jungle all his life. He doesn't know how to read or write.
The jungle is filled with predators, spiders and snakes. The sun is setting, the night starts soon.
Who has bigger chances of surviving ? I guess most people would bet on the tribesman. Why does nature select the person who would most likely score lower on the IQ score ?
The point is - intelligence is contextual and circumstantial. It's not one number, like width or length. Not sure why people still try to squeeze some sort of conclusion from it..
AI makes it very easy to avoid typing and hence make learning this skill less attractive.
But I don't necessarily see it as doom and gloom, what I think will happen - juniors will develop advanced intuition about using AI and getting the functionality they need, not the quality of the code, while at the same time the AI models will get increasingly better and write higher quality code.
You chat with an AI and have a working app in minutes.
I've been building about 1 app per week lately and they're not trivial apps. They have UI, backend, database, audio, etc.
One fact checks audio in real time, another does semantic search for song lyrics.
A real-time translator, which translates the text to Spanish as I'm typing. I needed it to better communicate with a Tinder date. It has a nice javafx UI. It didn't occur to me to look for a translator app, since those come with restrictions/registration/ads/etc.
This is possible today. Give it a bit more time and it will be able to clone any existing app.
The question 'what are we going to do then?' visits me more often lately.
Without a shred or actual evidence, I'd be ready to bet that many terrorist groups are buying their equipment/weapons in crypto. Arms, drugs, laundering, etc, it's just so convenient.. And in time it will become worse.
That being said, I also understand that crypto is unavoidable - eg the concept of the blockchain would have been discovered sooner or later and now it can't be stopped.
I see articles (like the one above) where people are sharing their excellent experience using the language as has been my experience over the years of using it.
A justification would be 'we hate this ugly thing, but we use it because it's cool', but that's not what I've been reading..
Alternatively, open the project in IntelliJ with Cursive installed or VSCode with Clava or other supported editors and start evaluating code at the repl.
Go through a few tutorials, then go through one of the free books available online. Don't give up when you're stuck.
The language has a steep learning curve because it requires thinking about the program in a different way than many mainstream languages. But it compensates by giving you many 'aha!' moments which make the day :).
Might be because our brains try to 'feel' the speaker, the emotion, the pauses, the invisible smile, etc.
No doubt models will improve and will be harder to identify as AI generated, but for now, as with diffusion images, I still notice it and react by just moving on..
Future versions will get more capable and smaller, portable.
Can be used to train new types models (not just LLMs).
I assume the GPU can do 3D graphics.
Several of these in a cluster could run multiple powerful models in real time (vision, llm, OCR, 3D navigation, etc).
If successful, millions of such units will be distributed around the world within 1-2 years.
A p2p network of millions of such devices would be a very powerful thing indeed.
The Core architecture [1] documentation is given in terms of TypeScript or Python abstractions, adding a lot of unnecessary syntactic noise for someone who doesn't use these languages. Very thin on actual conceptual explanation and full of irrelevant implementation details.
The 'Your first server'[2] tutorial is given in terms of big chunks of python code, with no explanation whatsoever, eg:
Add these tool-related handlers:
...100 lines of undocumented code...
[1] https://modelcontextprotocol.io/docs/concepts/architecture [2] https://modelcontextprotocol.io/docs/first-server/python
But isn't the same true with go channels ? If you want to asynchronously interact with a channel (that is, without blocking the main thread), you have to do it in a go block and the caller has to do the same and so on ?
Promises behave similarly - must wrap your code in promises all the way.
These constructs are alternatives to the good old callbacks, which force you to write your code inside callbacks, thus 'infecting' everything and leading to callback hell.
This 'cascade infection' effect is due to the inherent nature of things happening asynchronously, which contradicts the synchronous program flow inside a thread, so when the async event terminates, the program has to jump to a handler in order to process the results.
In the end it's a matter of taste imo..