Michael Dominick, who runs a software consultancy, describes what he is seeing from clients. For most of the year they said they could just vibe code internally; now some are coming back for rebuilds.
But notably in their S1 to IPO paperwork. So there's no potential other motor for that, right?
…anybody can do that. My students will face an interview where they're asked things like, Oh, whiteboard interviews. Right. Here's a whiteboard and a box of markers. Can you show me how you would solve this problem? If my students can do that, I'll be able to retire and feel pretty good about that.
I think you're definitely on the right track. I mean, from the vendor side here at the Mad Botter, it's funny. Most of the year was kind of a lot of people like, well, we can just vibe code this up internally, right? And now, little by little, I'm getting calls where it's like, hey, we kind of vibe coded this, but maybe we should treat it more like a prototype. And can you build us an actual system or take what we vibe coded and fix it to be simple, but kind of refactor it into something more enterprise quality and maintainable. The other thing I've been noticing is I think you're right on the core fundamentals education-wise. Because, you know, of course, I work a lot with Claw Claude. I think if you're not using these tools, you're kind of falling behind, at least from a commercial standpoint. But you really need to know your architecture. I'm talking about your, you know, your, your big old book, your canoe. You need to know your canoe. Or else, I mean, Claude, and I'm not just picking on Claude, right? So Codex, whatever, will just slap together crazy stuff sometimes that's totally inefficient, totally insecure. Not to…
Oh, 100%. Think about, you know, it's this 80, the 80-20 rule that applies in so many places. You know, in an organization, 80% of the work's done by 20% of the people, that kind of thinking. The 80% of your product development being planning and 20% being execution holds true. If you can't design…
Yeah.
And you'll end up with, you'll end up missing the whole point of software engineering and system engineering. Why do we have engineering processes? Because then we have validated outcomes. We have assured outcomes. We know things will perform according to their requirements. We know that they are…