> If the point of an engineer is to know how things work behind a piece of software

That might be the point of an engineer in some orgs, but mostly the point of an engineer is to ship a product or release that matches someone's vision of what should come next, and doesn't cause additional noticeable problems in the next quarter or three.

> You wouldn't trust an engineer a bridge that an engineer vibe-engineered would you?

If it was as easy to stress test/battery test/materials test/etc a bridge as it is to test code - then yes. I'd trust an engineer who vibe-engineered a bridge.

---

The problem with mapping digital problems into meat-space is that there is inherently a few orders of magnitude of cost automatically added to anything that happens in meat-space.

I can spin up an arbitrary number (10, 10k, 500k) docker instances, X with fuzzed inputs, Y with explicit edge cases, Z with tolerance testing, etc etc. And if that doesn't work - I can fix and push a button and it just happens again.

If a bridge engineer could do that with bridges - yes I'd expect them to be vibing just as hard as we are now.

Don't mechanical engineers do that with FEM simulations? Example: https://www.youtube.com/watch?v=tZspM_TvPKQ

Absolutely. These days engineers use AI and simulation to design new types of engines, jet nozzles, etc. Treating it not like a tool is the mistake, and the assumption many make is that “other people must be making that mistake too”.

That's verification. An engineer still understands the bridge and the engineering decisions that they built.

No, but I’d certainly trust an engineer to use software with in-built algorithms to design a bridge instead of using a typewriter, calculator, and a pencil. What you argue is your perception that this means everything is vibe coded and an engineer doesn’t understand any of it. My thought would be that this sentiment seems more telling of your views or how you use it than someone else. I’m not saying it isn’t possible for you to be right in circumstances, but rather you seem to assume your view fits all circumstances.

That the point of the engineer is to know how all of it works? So one must know the specific details of how every hard disk driver is implemented, with the algorithms being used, and have checked all the math and inspected all that code, just to be able to “read file”? Do you also argue that million+ line codebases should be inspected through every dependency and every file, line by line, and run through a debugger, before making a single line change anywhere?

Seems more like an extensive exercise in self-flagellation on the company’s dime than would be appropriate, but that’s just my opinion.

We all have our domains. A person can absolutely use AI within their domain and understand its output perfectly as much as having written it themselves.

The need for knowledge in those domains also changes over time. The need to understand a domain at a depth is directly proportional to the depth of the changes you are making to a stack. I don’t need to know how the hard drive spins to write a program. I don’t even need to understand that hard drives exist to write most programs these days, because it is not an area of concern. All of the implementation and efficiencies happen at a level below, or another below that, or within a trusted dependency. The people working on all those things understand those domains better than I ever could have the time to.

Maybe you could better explain where vibe-coding significantly differs from the above as another “layer” of separation?

Look, I’m not arguing vibe coding is “good” in and of itself by any means, but just basically that it’s not all vibe coding, and those of us that understand that don’t really have as much need to argue about the inevitable or that things change.