I believe there are entire companies right now under AI psychosis

It's really not that big of a word. The CAP theorem shows that as few as three reasonable-sounding requirements with no obvious conflicts can be impossible to satisfy simultaneously. (User needs will start more flexible than strict mathematical requirements, of course, but once people start to build production workloads on top of your systems that flexibility is radically reduced.)

> find ways to let the agent make the boring decisions, like how to loop over some array, or how to adapt the output of one call into the input of another.

Those kind of advice ultimately don't matter. If you're familiar with a programming project, you'll also be familiar with the constructs and API so looping over an array or mapping some data is obvious. Just like you needn't read to a dictionary to write "Thank you", you just write it.

And if you're not, ultimately you need to verify the doc for the contract of some function or the lifecycle of some object to have any guaranty that the software will do what you want to do. And after a few day of doing that, you'll then be familiar with the constructs.

> make the real decisions ahead of time. encode them into specs. define boundaries, apis, key data structures. identify systems and responsibilities. explicitly enumerate error handling. set hard constraints around security and PII.

The only way to do that is if you have implemented the algorithm before and now are redoing for some reason (instead of using the previous project). If you compare nice specs like the ietf RFCs and the USB standards and their implementation in OS like FreeBSD, you will see that implementation has often no resemblance to how it's described. The spec is important, but getting a consistent implementation based on it is hard work too.

That consistency is hard to get right without getting involved in the details. Because it's ultimately about fine grained control.

If there's one thing I know about users is that they're never certain about whatever they've produced.

That's a study. I can link you studies that say violent video games cause aggression, that porn causes rape, etc. Studies are products of the biases of the researchers.

> Maybe this is what will turn software engineering into an Engineering field.

Oh man, I think you may have touched the third rail here.

My first job out of high school was as an AutoCAD/network admin at a large Civil & Structural firm. I later got further into tech, but after my initial experience with real Engineering, "software engineering" always made my eyes roll. Without real enforced standards, without consequences, it's been vibe engineering the whole time.

In Civil, Structural, and many other fields, Engineers have a path to Professional Engineer. That PE stamp means that you suffer actual legal consequences if you are found guilty of gross negligence in your field. This is why Engineering firms are a collective of actual Professional Engineer partners, and not your average corporate structure.

The issue is that in software dev, we move fast, SOC2 is screenshot theater, and actual Engineering would slow things way down. But, now that coding is fast, maybe you are correct! Maybe vibe coding is the forcing function for actual Software Engineering!

___

edit: I just searched to see if my comment was correct, and it turns out that Software PE was attempted! It was discontinued due to low participation.

> NCEES will discontinue the Principles and Practice of Engineering (PE) Software Engineering exam after the April 2019 exam administration. Since the original offering in 2013, the exam has been administered five times, with a total population of 81 candidates.

https://ncees.org/ncees-discontinuing-pe-software-engineerin...

[dead]