| ▲ | fg137 3 hours ago | |
I was just looking at some user-facing error messages Claude generated for me which contained unnecessary/irrelevant technical details while failed to provide clear instructions or fix. Earlier, I reviewed code that does way more than specified scope, changes public API and introduces new behavior. I had to almost redo the whole thing. I thought to myself, no way I am going to ship the code as written without actually reading through it (or as some people put it, only looking at the "intent"). I'll get more complaints from users while having absolutely no idea what's going on with the code or actual behavior. It's a puzzle to me how these orgs can pull it off. | ||
| ▲ | gwbas1c 2 hours ago | parent | next [-] | |
It really depends on the kind of product you're working on. A lot of developers (and managers and business leaders) assume that their workflows will apply to other kinds of products; and are often very wrong. For example: A few days ago I saw a quote that over 90% of current Y-Combinator startups vibecode their products. The problem is the author misunderstands context: Startups sacrifice quality for time to market. In other cases, if you're building something that isn't technically challenging, (because it's 80% similar to many other products out there,) you can probably vibecode it. In contrast, if you're doing something technically challenging, it's to your benefit to be a lot more hands-on. I recently started getting excellent reviews from copilot of my hand-written code. (Or, I should say, the hand-written parts of an AI-assisted pull request.) | ||
| ▲ | zeeveener 3 hours ago | parent | prev | next [-] | |
The people / orgs that can actually codify their strong software engineering principles and practices into "a harness"[1] are the people / orgs that find success with these tools. The rest are just marketers. [1] Whatever that means to them | ||
| ▲ | worik 3 hours ago | parent | prev [-] | |
Yes > no way I am going to ship the code as written without actually reading through it Interestingly agents can help, not replace, this process These tools will make us more productive, they will disrupt (have disrupted) our industry, but they will not replace us because they cannot | ||