Funny how Marx never actually worked, like, ever, so his first time is never.

architecture involves pseudo-code to some degree

Clue: you can vibe-code pseudo-code. Hell, I vibe-coded a season of screen-plays for a TV series. Once you're comfortable with the architecture and requirements, then have your agent do a "readiness review" to ensure it thinks you've specified everything well enough to code it, then have it plan implementation and execute the plan, and review the output to ensure it's all consistent with all that documentation, and iterate on the reviews until you're happy that the only "problems" it's finding are inconsequential.

Then hand it over to an independent human test team. Like you always should have been doing without LLMs anyway.

I've done it because work is ✨desparate✨ and required I try it to learn it for some reason. I'm at a senior level. Generally I instructed it on the exact architecture and patterns I wanted, along with the broad classes and algorithms required. That meant it was left to do the individual procedure implementation that I might have instructed a junior developer to do while I managed more macro level concerns. It did surprisingly well, but this was on a greenfield project, so It would probably become excessively slow and error prone on a sufficiently large project.

So, now, when I see senior developers (which I am not) vibe code green field projects, I am just astounded as to how they manage the architecture + understanding + optimization + maintenance context.

My experience is, they're not. Like the article says they are just focused on MOAR and not on the quality of the output. It may take years for the unmaintainable code to cause problems, and they may have already been laid off by the time that happens, anyway .

I don't write much code anymore, but when I did, there was a fair amount of embedded code, where fixing a bug is more costly than just pushing out a build to a production server. I actively sought out automation back then, but the purpose of the automation was to help cover edge cases and better test the embedded code for flaws that traced through multiple layers of code.

Whenever I start a new software project, it usually starts with a short period of experimentation when I try out several things. Then, I coalesce on an architecture in my head (and eventually document it), and once I do that I can add more structure to the code.

Given the state of the AI tools today, I can see myself using them to accelerate all the little fiddly parts of this (especially if I can give it a coding standard and have it stick to it). But I wouldn't trust it more than that. I would always keep the archictecture separate, because I don't trust the AI tools to change it on me for no good reason.