Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Explain that to the average manager or junior engineer, both who don’t care about your desire to build well but not fast.


It’s not true that I want to build “well but not fast” — I’m trying to add value, and both speed and reliability matter. My productivity is high and I don’t have trouble articulating why; my approach has generally (though not universally) been well received by management and colleagues.


> So now that we brought down prod for a day the new rule is no AI sql without three humans signing off on any queries.


If that’s the scenario, I would be asking why the testing pipeline didn’t catch this rather than why was the AI SQL wrong.


Because the testing pipeline was generated by AI, and code-reviewed by AI, reading a PR description generated by AI.


Because the testing pipeline isn't the real database.

Anyone that knows a database well can bring it down with a innocent looking statement that no one else will blink at.


Sure, but everyone knows humans end up bringing down the database too by writing an innocent looking test query nobody else blinks at, which is why you end up needing a testing strategy for ANY SQL before YOLO'ing into prod.


To offer a 3rd option - what testing pipeline? Incompetent managers aren't going to approve of developers "wasting their time" on writing high quality tests.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: