I've been in the data engineering space for over a decade.
As the workload for our team started to scale faster than our staff and context switching thrashed my focus, PRs took a backseat. Releases, pipelines, and reports downstream started failing or silently degrading.
Layer on AI-assistance and suddenly the PRs are 5x the size, with no additional time to review every line.
I built Lexega to block PRs for the things I was afraid I would overlook. It's a static analyzer for SQL that runs in CI and comments on the PR. It's written in Rust, ships as a single binary, runs entirely inside your network with zero telemetry, and outputs standard SARIF. You can try it in the playground without signing up: https://lexega.com/playground.
Lexega is early-stage. I'm looking for a handful of design partners to review their own PRs, stress the parser, gauge the value of the built-in rules, encode their definition of risk with custom rules, and help me shape the roadmap. If you feel the same pain I've felt: hello@lexega.com.
I actually hold both extremes inside of me simultaneously. The speed at which you can ship when you have a strong vision of the end product and the architecture is extraordinary (the part of me that loves AI-assistance).
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.
Same boat, although the soul sucking, I find, comes from the fact that AI can iterate on ideas so much faster than I could even begin to pull out a pen and paper that I find myself in an existential crisis when I use it too often.
What is the point of my work, especially when I must ship for a paycheck, if I offload all my thinking and understanding to a machine. I can certainly dig deep and understand all the code the AI wrote, but when you didn’t create it, it feels so much less fulfilling. How does one find fulfillment in the AI engineering age? Isn’t solving problems and coming up with novel solutions part of why most of us got into it in the first place? When you strip that away, what is left? It’s code casino - I pull the lever, it spits out something that either feels like a dopamine hit (it works), or it spits out garbage and I prompt and pull the lever again hoping to strike the jackpot.
I find the most insufferable engineers those who use AI and think they are geniuses because they have access to this tool. Or say “AI told me …” They mistake the tools output for their own creative output or ingenuity.
Funny story to build on this. I spent a couple of days last week building a Powershell script for database refreshes (backups + restores). The process was iterative (typical), and AI helped me solve all the problems we've ran into historically here. It helped me write tests for all the gotchas I had stored in my head from watching various approaches fail over the last couple of years. I ended up with pre and post hooks on every side, and at a high level I'd vastly improved the time to delivery because (as I initially stated) I knew EXACTLY which problems I needed to solve there, and AI helped me get there in a fraction of the time. The end result was a common .psm1 file, 2 ps1 scripts (the orchestrator and executor script), and a total of about 2k lines of Powershell, which I hadn't combed through line-by-line because the tests were solid and I tested it in non-prod prior to releasing to production.
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.
IMO we have been conditioned to believe that everything is "all or nothing" which is a mistake. AI-assistance provides undeniable leverage IF, and only if, you know what you want. I think the market, in general, is still finding where things level out here. The problem, which I have been guilty of myself at times, is offloading key decisions. Humans absolutely have to retain those. AI can be used to present options, but the accountability always rests with the human (at least for now).
both are aggravating. i think you can use AI, say you use AI, and then demonstrate your understanding of what it created through documentation or other means. Hiding it or blatantly turning off your brain and saying "AI told me" are both bad practice.
Sometimes I say an LLM told me something for a hobby project where I'm using them as a means to extend my abilities into a realm I am ignorant of. But I think if a co-worker deferred to an LLM like that I'd be super disappointed.
The code casino is real and I don't have an answer to it, only share the sentiment. It is frustrating and exhausting to go through those boom/bust cycles.
The workflow that works for me is: I do the thinking, the writing, then let the AI review it. I am still doing all of the creative work and thinking. The AI keeps me honest and its code reviews are very helpful. The loop becomes competitive and makes me pay more attention to detail; I try to nail things on the first attempt. This gives me a sense of accomplishment and improvement.
Whether this workflow has its days counted, I don't know. But I also don't care. If/when software development as we know it truly stops being a thing, then I'll sadly just have to move on and work in another field. I am not doing vibe coding or programming in natural language. Fuck that.
But I have also noticed that, as much as the AI can process things faster than I can (I also use it to help me navigate the existing code base, and that is also very helpful), it cannot answer the question of whether we should do something, or whether X is more desirable than Y, etc. Maybe for some people, thinking about those things and letting the AI do the rest is enough. For me, personally, I like to navigate all levels of the development.
"AI told me" -- yes, absolutely insufferable dudes. I just don't even bother stating a reply.
"LLMs are good at SQL" is quite the assertion. My experience with LLM generated SQL in OLTP and OLAP platforms has been a mixed bag. IMO analytics/SQL will always be a space that needs a significant weight of human input and judgement in generating. Probably always will be due to the critical business decisions that can be made from the insights.
What we learned while building this is every token matters in the context, we spend lot of time watching logs of agent sessions, changing the tool params, errors returned by tools, agent prompts, etc...
We noticed for example the importance of letting the model pull from the context, instead of pushing lots of data in the prompt. We have a "complex" error reporting because we have to differentiate between real non-retryable errors and errors that teach the model to retry differently. It changes the model behavior completely.
Also I agree with "significant weight of human input and judgement", we spent lots of time optimizing the index and thinking about how to organize data so queries perform at scale. Claude wasn't very helpful there.
Very interesting work here, no doubt. It's a measured approach to using an LLM with SQL rather than trying to make it responsible for everything end-to-end.
The key to my point is in the word "generating". Meaning human input/judgement by actually typing more SQL than the LLM produces. The model's reasoning and code generation pipelines are typically 2 separate code paths, so it may not always actually do what it intends which can lead to unexpected results.
> My experience with LLM generated SQL in OLTP and OLAP platforms has been a mixed bag
Models are evolving fast. If your experience is older than a few months, I encourage you to try again.
I mean this with the best intentions: it's seriously mind boggling. We started doing this with Sonnet 4.0 and the relevance was okay at best. Then in September we shifted to Sonnet 4.5 and it's been night and day.
Every single model released since then (Opus 4.5, 4.6) has meaningfully improved the quality of results
I totally agree. However, none of them are infallible and never will be. They're nondeterministic by nature. There is an interesting psychological nuance that I've noticed even in myself that comes with AI assistance in coding, and that's the review/approval fatigue. The model could be chugging along happily for hours and make a sudden, terrific error in the 10th hour after you've been staring at reasoning and logs endlessly. The risk of missing the terrific error in that moment is very high at the tail end of the session. The point I was making (poorly) is that in this specific domain, where businesses are making data-driven decisions on output and insights that can determine the trajectory of the entire organization, human involvement is more critical than, say, writing something like a python function with an LLM.
I agree, we automated in the Mendral agent what is time consuming for human (like debugging a flaky test), but it will need permission to confirm the remediation and open a PR.
But it's night and day to fix your CI when someone (in this case an agent) already dug into the logs, the code of the test and propose options to fix. We have several customers asking us to automate the rest (all the way to merge code), but we haven't done it for the reasons you mention. Although I am sure we'll get there sometimes this year.
Shameless plug here for Lexega—a deterministic policy enforcement layer for SQL in CI/CD :) https://lexega.com
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.
That's a pretty lofty valuation for a company that has yet to demonstrate code generation anywhere near Anthropic's models if they're leaning into the engineering angle.
"Calvinism makes pretty lofty claims for a religion who has yet to demonstrate soul salvation anywhere near Lutheranism if they're leaning into the reformation angle"
I appreciate that! It's a culmination of years of my own pain in the engineering space and a solution anticipating the flood of AI-generated SQL coming for our databases.
Yeah, it's one of those things that is hard to catch unless you've been bit by it before and know to look for it. Analytics teams at scale are at a much higher risk of this sneaking in, which is where automatic blocking with Lexega is helpful. No one wants to have to explain to their leadership why their dashboards were wrong from such a subtle SQL bug months down the road.
Looping back here - trial licenses can now be obtained instantly through the free trial form on the website with just an email. No outreach needed on your part. Here for support if you decide to try it.
That's exactly the use case I built agent runtime mode for: AI agents generating SQL need a policy layer between intention and execution. The rules engine is designed to be extensible for precisely that reason and can be enhanced with DB metadata via the catalog integration.
Would love to compare notes on how you're handling the non-SQL side. Feel free to reach out!
Great question! sqlfluff catches real things like "= NULL" bugs, implicit cross joins, unused CTEs, and SELECT *. It's a genuinely useful code quality tool. The dialect coverage of sqlfluff is also extensive. Lexega's dialect implementations focus on depth over breadth.
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.
As the workload for our team started to scale faster than our staff and context switching thrashed my focus, PRs took a backseat. Releases, pipelines, and reports downstream started failing or silently degrading.
Layer on AI-assistance and suddenly the PRs are 5x the size, with no additional time to review every line.
I built Lexega to block PRs for the things I was afraid I would overlook. It's a static analyzer for SQL that runs in CI and comments on the PR. It's written in Rust, ships as a single binary, runs entirely inside your network with zero telemetry, and outputs standard SARIF. You can try it in the playground without signing up: https://lexega.com/playground.
Lexega is early-stage. I'm looking for a handful of design partners to review their own PRs, stress the parser, gauge the value of the built-in rules, encode their definition of risk with custom rules, and help me shape the roadmap. If you feel the same pain I've felt: hello@lexega.com.