> When you vide-code you don't care about code quality, right?
I don't mind compromising on code quality. The part I don't want to compromise on is product quality. So far the two seem pretty closely tied together - like the more unmaintainable code there is, the more you lose track of the big picture and the worse your product gets, with slightly misaligned definitions of the same concept scattered throughout the code/product resulting in an inconsistent UX.
I'm down to have a state where i never have to look at code and worry about it at all. At this point, I think my issue is the fact that we don't have a super clear spec when we begin, since we're "exploring", and by the time the spec becomes more clear, there's too much bad code/product decisions that the agent is taking into context that ruin the results going forward.
I'm going to try out having product specs committed in the repo itself - hopefully this gives every agent I spin up context into how the product is supposed to behave as opposed to having to "guess" it from reading the code adjacent to whatever prompt I gave it
Yeah I feel like what you say makes sense. Part of my issue comes from the fact that we're a pre-PMF startup, so rapid experimentation and prototyping really matters at the moment with very little room left for deep thought around testing and benchmarking.
The trouble comes later when the "experimental features" actually start getting traction and we discover all the holes in our implementation.
By the time we need to "productionize" our experiment, it has already been patched all over the place to account for bugs.
I get a feeling that this is made worse by the fact that since a lot of what we're doing is rapid prototyping, our repo is cluttered with examples of bad code that the agent picks up on and then goes ahead to copy in its own implementation.
I get that we need to clean this up, but it's crazy trying to figure out where to start and what to tackle
One of my mantras is 'fast is the best UX'. Users will put up with minor annoyances as long as they're over with quickly. Once you fix the annoyances, you're still fast, which leads to User Delight.
> I get that we need to clean this up, but it's crazy trying to figure out where to start and what to tackle
Enumerate, then fix-or-nix all known examples of bad code first. If you clear the path first, you will advance more quickly. It can feel frustrating having to do that, but my experience is that paying off tech debt earlier will prevent hitting the wall at an inopportune time.
I don't mind compromising on code quality. The part I don't want to compromise on is product quality. So far the two seem pretty closely tied together - like the more unmaintainable code there is, the more you lose track of the big picture and the worse your product gets, with slightly misaligned definitions of the same concept scattered throughout the code/product resulting in an inconsistent UX.
I'm down to have a state where i never have to look at code and worry about it at all. At this point, I think my issue is the fact that we don't have a super clear spec when we begin, since we're "exploring", and by the time the spec becomes more clear, there's too much bad code/product decisions that the agent is taking into context that ruin the results going forward.
reply