|
|
|
|
|
|
by metalspot
1 hour ago
|
|
|
I have used AI almost exclusively for a year, but I was programming by hand for almost 30 years before that. I don't think there is any difference between going from assembly -> C -> Java, TypeScript, C#, Go, etc, and taking the next step to AI. It is just another intermediate abstraction layer that allows you to work at larger scale. Programming with AI enforces some good disciplines, which were always true, but could be avoided doing it by hand. Most importantly: you are shipping your tests. If you don't have reproducible automated tests then it probably doesn't work. |
|
|
The reason is that the compiler's mechanical contract is 'deterministic.' AI, on the other hand, is 'probabilistic.' No matter how much you specify the same situation and details, it doesn't produce 100% identical results.
Abstraction should fundamentally share the same axis of change, but AI doesn't do that. And human code typically starts small, adjusts bit by bit, and refactors as requirements change or scale grows to realign the axis of change. AI's abstraction is fundamentally different from what humans create.
Of course, it can depend on the 'workflow.' If you work in small function units, it can act similarly to a deterministic system. But fundamentally, the market's expectation for natural language AI coding is based on 'large codebases.' Since it's not a codebase understood by a human, it effectively creates an abstraction that's different from my cognitive abilities.
The problem is that AI's abstraction varies from project to project. This is undeniably black-box coding. Sure, you can review it if you know how to read code, but my view differs from yours.
I don't think this is a new abstraction layer. I see it as a technique for controlling blast radius. Of course, you could review the entire codebase while working, but considering the recent vibe coding trend, where people only check core P0 and P1 parts and let AI generate the rest freely, it's even more clear that the focus is on scaling to sizes that humans couldn't handle before.
Of course, my perspective differs from yours, and I think you're a far better programmer than I am.
That's why I think hand-coding and vibe-coding share only the surface-level axis of producing an output, but the cognitive instincts they demand are completely different.
The core of vibe-coding is essentially predicting which part of the black box, if it breaks, would be most critical to the system, and isolating the blast radius. Hand-coding, on the other hand, is fundamentally about surveying the entire system, and definitively controlling and designing every control flow and state change.
In other words, one is an area of 'auditing,' giving up direct control in favor of managing risk, while the other is an area of 'creation,' shaping logical consistency from 0 to 1.
I imagine you also have experience as a PM.
A project manegaris a different profession from a programmer. It requires programming experience, but it's fundamentally a different role. In my view, vibe-coding is essentially a career transition toward being a PM. But separate from that, I don't think this is simply a new abstraction layer. I've seen enough cases where the same prompt and same environment produce different results