This is a good thing. Repaying technical debt is always a great thing.
On our own 1.5M loc system, we've found and fixed thousands of bugs, security holes and circular dependencies in the last year. Code quality has increased, test coverage increased. We've also recently set our compiler to treat warnings as errors, and to be as strict as possible. It is absolutely amazing to see the gaps being filled, it would've been an impossible task for human devs and IDE's would've made it very uncomfortable. We've also ironed out all the bugs and failure modes in our infrastructure automation / monitoring. Our next project is to eliminate all 3rd party dependencies, and after that to rebuild our frontends completely using zero frameworks, not touching npm ever again after that.
So when I read this about postgres, I was very happy that they found and pursued this side quest. They can make the codebase bullet proof.
>fixed thousands of bugs
>set our compiler to treat warnings as errors, and to be as strict as possible
>ironed out all the bugs and failure modes in our infrastructure automation / monitoring.
>eliminate all 3rd party dependencies
>rebuild our frontends completely using zero frameworks
Oh yeah, that's what i call "software engineering" and excellent use of LLM's! Great to see Company's with a Mindset like that.
Now this is how companies should be using AI. Not as an excuse to fire half the devs. Less bugs, less failures, better experience for everyone.
> Our next project is to eliminate all 3rd party dependencies, and after that to rebuild our frontends completely using zero frameworks, not touching npm ever again after that.
What's the proportion of bugs you've encountered that was due to a library versus due to your own code? I suspect it's probably more than 1:1000.
This is a stupid decision.
> rebuild our frontends completely using zero frameworks, not touching npm ever again after that
Genuine question, because I don’t know: Wouldn’t it suffice to vendor your current packages and “only” stick to maintenance from there on out, instead of rewriting it all?
This should still achieve the goal of not needing to touch npm, but presumably with less effort/tokens, right? Or is it just that you would expect the result of that process to be less clear and maintainable than a full rewrite?
Good thing if you can afford the vulnerability detection run.
I could imagine scenarios where only well off developers and companies could afford that.
Then if you don't have the money, you are out of luck and risk having vulnerabilities in your code.
And it takes just one adversary to pay the bot & the bot will happily find an exploit for them in your code.
This worry this could lead to a serious power imbalance & furthe damage the free software community...
Didn’t you guys have to ship new products? How a business can afford so many backlog tickets being implemented? I understand fixing bugs can also mean improving the product but still - (almost) the whole world has this balance between new features and acceptable-ish number of bugs
Can you tell us how did you achieve that kind of work, briefly? I struggle to figure out how such massive bug fixing campaigns or even large scale software engineering are done with ai not taking weird decisions...
If you're going to roll your libs, be sure to set up agents to scan for CVE analogues of equivalent known vulnerabilities in your own code. It takes quite a bit of work to set this pipeline up, as well as manually selecting high-impact CVEs (relying on the public scores is worthless, because there are some vulns that are catastrophic with a score of 6 vs something meaningless thats a 10).
It's also crucial to scan for "analogues" because otherwise many LLMs autoreport as "not vulnerable" since "this applies to Postgres/whatever and this repo isn't using it"
If you get hit by cyber guardrails you should use a local model to prune any CVE specific language from the reports.
To give examples, every single LLM (and people too tbh) will write netcode that's vulnerable to these CVEs: CVE-2026-27135, CVE-2024-45311, CVE-2021-32567, CVE-2019-9511; without explicitly mentioning the CVE text no LLM finds these either.
> IDE's would've made it very uncomfortable
Would you mind elaborating?
The JS frameworks exist for a reason, recreating them seems a little excessive. Why not skip JS and go to a Rust wasm framework or Phoenix LiveView if the goal is to get away from JS/node/npm?
Avoiding 3rd party libraries seems like a false sense of security. You’ll stop seeing CVEs on the scanner reports, but the bugs are still there, just in your own code that is less well audited than public libraries.