alt Hacker News> You no longer need to review the code. Or instruct the model at the level of files or functions. You can test behaviors instead.
Maybe for a personal project but this doesn't work in a multi-dev environment with paying customers. In my experience, paying attention to architecture and the code itself results in a much more pliable application that can be evolved.
Replies
Counter argument...
High velocity teams also observe production system telemetry and use error rates, tracing and more to maintain high SLAs for customers.
They set a "budget" and use feature flagging to release risky code and roll back or roll forward based on metrics.
So agentic coding can feed back on observed behaviors in production too.
It's doesn't work...yet. I agree my stomach churns a little at this sentence. However, paying customers care about reliability and performance. Code review helps that today, but it's only a matter of time before it is more performative than useful in serving those goals at the cost of velocity.
Everyone who is responsible for SOC 2 at their company just felt a disturbance.
Honestly, I can't wait for AI: development practices to mature, because I'm really tired of the fake hype and missteps getting in the way of things.
Agree. And with the comments in the thread.
I'll caveat my statement, with AI ready repos. Meaning those with good documentation, good comments (ex. avoiding Chestertons fence), comprehensive interface tests, Sentry, CI/CD, etc.
Established repos are harder because a) the marginal cost of something going wrong is much higher b) there's more dependencies c) this makes it harder to 'comprehensively' ensure the AI didn't mess anything up
I say this in the article
> There's no "right answer." The only way to create your best system is to create it yourself by being in the loop. Best is biased by taste and experience. Experiment, iterate, and discover what works for you.
Try pushing the boundary. It's like figuring out the minimum amount of sleep you need. You undersleep and oversleep a couple times, but you end up with a good idea.
To be clear, I'm not advocating for canonical 'vibe coding'. Just that what it means to be a good engineer has changed again. 1) Being able to quickly create a mental map of code at the speed of changes, 2) debugging and refactoring 3) prompting, 4) and ensuring everything works (verifiability) are now the most valuable skills.
We should also focus more on the derivative than our point in time.