I am in the middle of reading a fascinating book about the early days of computing: Turing’s Cathedral by George Dyson. It really opened my eyes to American engineering craft post WWW II.
We seem to take everything for granted now and forget what real engineering is like.
How much effort would it take GenAI to write a browser/engine from scratch for GenAI to consume (and generate) all the web artifacts generated by human and GenAI? (This only needs to work in headless CI.)
How much effort would it take for a group of humans to do it?
I'm not sure about what you mean with your first sentence in terms of product.
But in general, my guess at an answer(supported by the results of the experiment discussed on this thread), is that:
- GenAi left unsupervised cannot write a browser/engine, or any other complex software. What you end-up with is just chaos.
- A group of humans using GenAi and supervising it's output could write such an engine(or any other complex software), and in theory be more productive than a group of humans not using GenAi: the humans could focus on the conceptual bottlenecks, and the Ai could bang-out the features that require only the translation of already established architectural patterns.
When I write conceptual bottlenecks I don't mean standing in front of a whiteboard full of diagrams. What I mean is any work the gives proper meaning and functionality to the code: it can be at the level of an individual function, or the project as a whole. It can also be outside of the code itself, such as when you describe the desired behavior of (some part of) a program in TLA+.
“This is a clear indication that while the AI can write the code, it cannot design software”
To clarify what I mean by a product. If we want to design a browser system (engine + chrome) from scratch to optimize the human computer symbiosis (Licklider), what would be the best approach? Who should take the roles of making design decisions, implementation decisions, engineering decisions and supervision?
We can imagine a whole system with human out of the loop, that would be a huge unit test and integration test with no real application.
Then human can study it and learn from it.
Or the other way around, we had already made a huge mess of engineering beasts and machine will learn to fix our mess or make it worse by order of magnitude.
I don’t have an answer.
I used to be a big fan of TDD and now I am not, the testing system is a big mess by itself.
Engineering is more or less about getting familiar with the proper tools and use them to solve specific problems: add new features, debugging, refactoring and optimizing.
And the tools themselves are built by other engineers and they need new features, debugging, optimization etc. It is turtles all the way down.
But each layer has its own jargons, conventions and unwritten hacks. That is where experience comes in. Once you get out off a rabbit hole or pothole, you are one step closer to becoming the “domain expert”. There is no short cut.
Ironically, when machine learning is getting “deeper & deeper”, human learning is getting more and more impatient and shallow.
I have been searching “Vibe coding” videos on YouTube that are not promoting something. And I found this one and sat down and watched the whole three hours. It does take a lot of real effort.
I'm a machine learning researcher myself and one of the things that frustrates me is that many of my peers really embrace the "black box" notion of ML models. There are plenty of deep thinkers too, but like with any topic the masters are a much smaller proportion. Just a bit of a shame given that I'm talking about a bunch of people with PhDs...
As for my experience vibe coding is that it is not so much vibing but needing to do a lot of actual work too. I haven't watched that video you linked but that sounds to reflect my actual experience and that of people I know offline.
Since the JavaScript and Python worlds are heavily polluted by LLMs, I start to look into Rust and Cargo ecosystem. Surprisingly it picked up the pace as quickly as possible.
Once Rust can be agentic coded, there will be millions of mines hidden in our critical infrastructure. Then we are doomed.
Someone needs to see the problem coming and start to work on the paths to solution.
The mines are already being placed. There are plenty of people vibe coding C programs. Despite C documentation and examples being more prolific than rust, well... C vulnerabilities are quite easy to create and are even in those examples. You can probably even get the LLMs to find these mines, but it'll require you to know about them.
That's the real scary part to me. It really ramps up the botnets. Those that know what to look for have better automation tools to attack and at the same time we're producing more vulnerable places. It's like we're creating as much kindling as possible and producing more easy strike matches. It's a fire waiting to happen.
I did a toy experiment on a pretty low level crate (serde) in Rust ecosystem, to run a simple demonstration from their website pulling in 42M of dependencies.
It amazes me how much we've embraced dependency hell. Surely we need some dependencies but certainly we're going overboard.
On a side note, I wonder how much of this is due to the avoidance of abstraction. I hear so many say that the biggest use they get from LLMs is avoiding repetition. But I don't quite understand this, as repetition implies poor coding. I also don't understand why there's such a strong reaction against abstraction. Of course, there is such a thing as too much abstraction and this should be avoided, but code, by its very nature, is abstraction. It feels much like how people turned Knuth's "premature optimization is the root of all evil" from "grab a profiler before you optimize you idiot" to "optimization is to be avoided at all costs".
Part of my questioning here is that as the barriers to entry are lowered do these kinds of gross mischaracterizations become more prevalent? Seems like there is a real dark side to lowering the barrier to entry. Just as we see in any social setting (like any subreddit or even HN) that as the population grows the culture changes significantly, and almost always to be towards the novice. For example, it seems that on HN we can't even make the assumption that a given user is a programmer. I'm glad we're opening up (as I'm glad we make barriers to entry lower), but "why are you here if you don't want to learn the details?" How do we lower barriers and increase openness without killing the wizards and letting the novices rule?
Think of it as the early years of UNIX & PC. Running inferences and tools locally and offline opens doors to new industries. We might not even need client/server paradigm locally. LLM is just a probabilistic library we can call.
We seem to take everything for granted now and forget what real engineering is like.
This review is 13 years old by itself:
https://www.theguardian.com/books/2012/mar/25/turings-cathed...
reply