The first run in production ended up causing an unhealthy db in RECOVERING state because there was a tiny logic bug where the restored db wasn't verified as ONLINE before it set it MULTI-USER (which our db state monitors caught within the couple seconds of that being true).

I think AI has enabled us to solve problems much quicker without being intimate with every tiny detail of the code itself. The funny thing about the story is that this isn't a novel problem. Coming in behind a peer who wrote the thing, or even coming in to debug a script I'd written myself a year ago is the same. AI has just pushed up the time to lacking knowledge of precise details of logic, so you can ship something and be unaware of EXACTLY what it does the same day, instead of 6+ months later.

I'm not sure if this is right or wrong, but debugging it was 3 minutes of presenting the issue back to AI instead of 2 days of combing through 2k lines of Powershell that I may or may not have written.

The journey itself, at least for me, has been absolutely grueling though; I'd say ~30% of the time it's just straight up soul-sucking. Some of that could be because of my own incessant need for discipline and clean code. I don't know how people let agents run wild in hours-long workflows, I can't even get Opus to stop running my test suite repeatedly to look for failures even though cargo test fails fast (the model already knows this), CLAUDE.md has the exact steps and commands for running the test suite, every invoked skill explains the same, and the hook rejects repeated attempts with the same explanation. It STILL, 90% of the time, uses whatever command it wants, bypasses the hook's cooldown to try a different grep because its own invented command didn't return any failures, and if it doesn't bypass the command it tries to wait it out so it can try again. Such a simple thing that it can't get right no matter what I've tried.

Anyways.. Love the leverage, hate fighting with the model on the way from A to B. Everything it does should be challenged.

People that "hate" AI are either expecting it to do too much and are disappointed or aren't watching it closely enough and have to suffer through refactors after they thought they'd been making progress. People that are only over the moon may be working in less complex systems and haven't felt the pain of all the failure modes yet, or just aren't yet aware of the bugs hiding in what AI produced.

Anyone who has built something significantly complex enough probably shares the same love/hate relationship.

There are bridges here that the industry has yet to figure out. There is absolutely a place for LLMs in these workflows, and what you've done here with the Mendral agent is very disciplined, which is, I'd venture to say, uncommon. Leadership wants results, which presses teams to ship things that maybe shouldn't be shipped quite yet. IMO the industry is moving faster than they can keep up with the implications.

Would love to compare notes on how you're handling the non-SQL side. Feel free to reach out!

hello@lexega.com.

Lexega is asking a different question though. sqlfluff asks "is this SQL well-written?", while Lexega asks "is this SQL dangerous?". It parses into a full AST and emits signals (categorized AST components) that can be matched against YAML rules to block PRs or execution in agent runtime mode. DELETE without WHERE, GRANT to PUBLIC, PII exposure without masking, DDL that drops tables in production pipelines. The output isn't "fix your style", it's "this query violates an organizational risk policy and shouldn't be allowed to hit production".

Think code quality vs. risk analysis. Both useful, different jobs.

Good call on the GitHub link - I need to fix that.

Comments URL: https://news.ycombinator.com/item?id=47095592

Points: 21

# Comments: 14