Comment by piloto_ciego
1 month ago
This is just patently false in my experience thus far. I mean, I'm "vibe engineering" and know what I'm doing relatively well? But the way this works now is I'm more like an architect than a coder anymore. This means I can do things faster, but it also means it's less fun. But the customer doesn't really care about "fun" - so I do what I've gotta do.
But if anything, I could probably go a lot faster and be fine, it's just my life would be miserable. If you're going to "vibe code" try to remember to actually... you know... vibe.
The thing is, the development timeline is so compressed that you lose intimate knowledge of the codebase. Like, I don't think humans can form memories that detailed that quickly? Maybe it's just a me problem though. Anyway, so when you need to debug or fix stuff, AI's reasoning will be "welp makes sense, I suppose" and your mental mood of the codebase is now slippery. Eventually there comes a time where at best you can draw an incoherent high-level diagram of the architecture.
And AIs solution to problem is generally "more of the same" to fix it. It rarely looks at fixing design problems
My definition of vibe coding is coding without review (for example, a non technical person vibe coding something). In the hands of a competent engineer the AI tools do boost productivity.
But even there, there is responsibility capacity, you can't have an engineer maintaining large numbers of systems at once, so if you moved fast you can still get yourself in trouble even with technical review.
I'd argue that doing vibe coding without a competent engineer reviewing the work is likely to have worse outcomes than drafting your own legal documents without consulting an actual lawyer.
Both are likely to result in nasty surprises in the future.
> I'm more like an architect than a coder anymore
I don't understand this dichotomy. Coding is architecting, you can't divorce these things. In fact that is all it really is. It doesn't matter if you're writing assembly or python.
Of course you can.
Log File Ingest —> Parser —> Store in DB
Raw Data Ingest —> Apply Savitzky-Golay Filter —> Store in DB
Query Log File and Sensor Database from DB —> Push smoothed data to plotly dashboard
That’s architecture but it is substantially more high level than writing the code for the filter, or the connections to the db etc. It is architecture though, and honestly, I don’t need to spent 20 hours writing all the code to know what it does. I could write a parser from scratch or write that kind of filter from scratch - just need to pull out a book and re-remember the precise requirements etc. But why? This is no different in my mind than using libraries to get the computer to DWIM more conveniently.
Does it mean I understand the code worse than if I would have clacked it out directly? Yup. But it is (as always) a trade off.