It’s pretty much a vibe coding issue. What you describe I can recall being advocated forevet, the project manager’s dtram that you model and spec things out enough and perfectly model the world in your test cases, then you are golden. Except the world has never been so convenient and you bank on the programming being reasonably workable by people to compensate.
Problem is people who think they can replace understanding with vibe coding. If you can only vibe code, you will end up with problems you cannot fix and the LLM can’t either. If you can fix the problems, then you are not inclined to toss overly long chunks of LLM stuff because they generate ugly hard to maintain code that tends to violate all sorts of best practices for programming.
For sure, I am talking about smaller projects where programming elements are relatively low key and critical parts are the business logic and how it impacts UX/UI and use case flows.
I was between projects and I needed money so I accepted a project from a repeat client where I knew 80% of it very well (and how to implement it), but there were parts that I vibe coded (albeit they were simple enough that I could understand the logic of what I was deploying even though I don’t know how to code).
The contract size was simply too small for me to get a subcontractor, I would be giving them most of payment (while doing 80% of the work).
I think it’s fair to use vibe coding in such situations.
I would not risk vibe coding in a situation where I felt I would be undermining the clients’ project (I want repeat clients and I don’t want to have to spend time fixing things for free).
It’s pretty much a vibe coding issue. What you describe I can recall being advocated forevet, the project manager’s dtram that you model and spec things out enough and perfectly model the world in your test cases, then you are golden. Except the world has never been so convenient and you bank on the programming being reasonably workable by people to compensate.
Problem is people who think they can replace understanding with vibe coding. If you can only vibe code, you will end up with problems you cannot fix and the LLM can’t either. If you can fix the problems, then you are not inclined to toss overly long chunks of LLM stuff because they generate ugly hard to maintain code that tends to violate all sorts of best practices for programming.
For sure, I am talking about smaller projects where programming elements are relatively low key and critical parts are the business logic and how it impacts UX/UI and use case flows.
I was between projects and I needed money so I accepted a project from a repeat client where I knew 80% of it very well (and how to implement it), but there were parts that I vibe coded (albeit they were simple enough that I could understand the logic of what I was deploying even though I don’t know how to code).
The contract size was simply too small for me to get a subcontractor, I would be giving them most of payment (while doing 80% of the work).
I think it’s fair to use vibe coding in such situations.
I would not risk vibe coding in a situation where I felt I would be undermining the clients’ project (I want repeat clients and I don’t want to have to spend time fixing things for free).