The only "third-party" packages that we want to ideally allow/support would be provided from LTS versions of our runtime (in this case, packages provided by the dotnet team and audited by microsoft). So we will always try to build around what the framework provides. Second choice is our own code, third choice is open-source packages, fouth choice is a separate application/appliance (lets say ZenDesk for ticketing). Over time, we will reduce this footprint to only have dotnet team code and our own.
Remember most CVE's can be hidden on servers that are not publicly routable and don't have a real exploitation paths. The bits that are public (lets say a linux edge server with a web server on it, some firewalls, a couple of open ports) - these should be hardened to the max and not allow full access to all the services running behind it. We don't even give our internal services public IP addresses to make near impossible to route traffic to them.
Our git repo's are also not on public infrastructure (serious, think carefully about hosting on public services and if you really need it), never mind making the repo public.
We also have a dedicated secrets/certs manager, so no credentials are in codebases or pipelines. Very strict in this regard.
also some 3rd party libraries are overdesigned/overcomplicated because everybody wants the library to do everything for everybody.
This overcomplication can easily introduce security problems that is not present in the 1K solution.
Also a source of significant dependency churn even excluding security bugs.
Whereas with my own code I don't have to worry about scheduling work that's only arisen because somebody outside my organisation has decided to make a breaking change in a dependency. Paying that tax got old over a decade ago, and my patience with it now is close to zero.
What a bullshit.
It's different scenario, different trade offs.
You mitigate risk of library being sold to malicious 3rd party, you avoid risk of your supply chain being hacked, you avoid API/behaviour breaks, etc.
The trade off is that you have to maintain it.
That's why dotnet's ecosystem is so loved due to MS providing 90% of needed libraries, so you avoid some 3rd parties maintained by single person.
Often it can be a very good choice to write the functionality yourself and not rely on external libraries.
And since we now have coding assistants, maintaining in-house costs near nothing now. Nobody else can break us, only ourselves.
>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.
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?
How's that going? Any lessons learnt you'd be willing to share?
Mmm what else. I prefer postgres so I'm very excited about this. So many foot-guns will no longer haunt us like on MSSQL and less db/table locks to try solve (pessimistic vs optimistic locks). Oh and we are going to save a gross amount of money per year, as we will also be able to switch off a couple of Windows Server VM's in the process. These puppies are costing us a ton (I think about half of our infra bill are licenses...).
Just create a branch, spin up a test db and try to port a small feature. Its very easy in most cases. Debian + dotnet + postgres = dream team.
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...
Worse case, we enter the Dark Forest era for technology. Read up on this concept and apply it to the tech industry. I suspect open-source might die and everything becomes private, no more public networks, no more open access, as to assure survival. In a sense we are halfway there already as it seems the internet is starting to close down, people not posting their art and music as much anymore, not posting their knowledge for free anymore, as it might be used against them by AI (the other party in the dark forest..). Thus private authentic experiences will become more valuable.
1. The cost of running AI is dropping down to "free" - there's open weight models, open source tools, and guides on running your own if the long list of suppliers isn't good enough for your use cases.
2. Vulnerabilities have always been a risk; AI is not a panacea. The pre-AI best practices still apply. Furthermore, a huge percentage of vulnerabilities are in 3rd party tools and systems, which are systematically being scanned and fixed and/or exploited, then fixed.
You mention "the free software community" in your last sentence though - this implies the code in question is open source, so it's able to receive plenty of improvements from anyone with access to these tools.
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.
Before we started this journey (about a year ago), we spent a ton of time cleaning up our codebase, splitting large files (10K+ lines) into files that are no more than 2K lines, things like that. Then we let claude scan our important files and summarize them, add comments for future claude sessions. So we've let it built up tribal knowledge per file and the reasons for things to exist. We tell it all about our operating environment, the country and legal framework etc, so every little piece helps it stay honest and on track.
So to start, do something simple like: Scan the files in this folder for database code and check for queries that loads the entire result set into memory and/or queries that loads all columns. Suggest which queries we can filter better or reduce columns being transferred. Once done, also check real db row counts, compare them with the queries in these files and check if they might benefit from an index or partitioning/sharding. Also check for queries that loads data but their results are not used. Don't make changes yet, just do a deep investigation and report back. Feel free to spin up muliple agents to batch the scans.
edit: it goes without saying you need a language with strict typing and a good compiler (we use dotnet). Doing this on python/javascript would be a nightmare.
Would you mind elaborating?
Oh it also helps to split refactoring work into three buckets: business logic changes, performance changes (same output as before but faster) and cosmetic changes (rename files/folders/classes, breaking large files up, add logging/comments, domain layering etc). We tend to focus on performance and cosmetic changes for bulk refactors and leave logic changes to more dedicated sessions as to avoid changing what the system do (our domain is fairly complex and we cannot afford breakages). We also managed to port ALL of our code to dotnet 10 lts and have clean boundaries between projects (we have a mono-repo with about 50 projects in it), so we can wholesale upgrade dependencies without a sweat.
Of course, crashes and bugs can happen when applying quickfixes, which isn't nice. Ideally, they should be reported and fixed. You can also ask an agent to fix the occurences instead of using the IDE quickfixes if that's blocking you.
I guess what I'm trying to say is that IDEs shouldn't make that process harder, they can actually improve agents' results. For example, you don't need to write custom skills to prevent agents from writing some class of bugs if the IDE can detect it and agents have access to the results.
> Changing 200K+ lines of code yourself is a nightmare (and to prove it still does the same thing afterwards).
If an agent does it, you still have no proof, but okay.
Full disclosure, I work at JetBrains, but not in the IDE department.
Where now, the compiler flags & strict analyzer settings forces claude to do the right things (we explicitly tell claude not try and bypass or lower the barrier). I think it only works because we don't spend 95% of our time in the IDE anymore like a couple of years back, so we as developers no longer feel that friction, as claude tries to satisfy the compiler instead. Its a massive mental load that is just gone, we haven't had any conversations in meeting about this kinda stuff anymore (remember in the past we would have flameouts in meetings or code reviews about linter settings...).
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.