In my (really large) typescript project we have like 6 static analysis tools running[1]. Steps to get the project running: install nodejs, install package manager, install dependencies, run project.
The main difference is that in the JS ecosystem it is all installed at the project level, you don't need anything globablly installed besides the runtime and package manager (and even the package manager can be auto-installed as well if you set it up that way).
[1]: eslint, biome, prettier, scass linter, graphql-codegen, tsc, tanstack-router codegen. That I remember, might be more (although codegen might not be considered static analysis, it is needed for static analysis).
I don't think so, my experience is that most often falls into two scenarios:
1) The devs pushing for more complex solutions, covering obscure edge case scenarios, feature-creep, "future-architecturing" because they are more interesting to implement. Classic over-engineering problems.
2) The features the managers actually want are usually boring or annoying to implement and the devs just work around any big architectural problems caused by the feature delivery.
1 is 100% on the devs, 2 it varies wildly, the willingness to address architectural problems are often under pressure by time-delivery estimates from managers. But many devs (especially in companies with low morale) will often just work around issues because addressing the underlying problems can be very difficult and/or time consuming.
Meaning either the dev wants to do the right thing but doesn't have the time, or the dev doesn't care enough and just pushes the tech debt down to the future (when hopefully they will be at another job).
LLMs makes both problems significantly worse, although they are also often very helpful with the big restructurings mentioned in 2. The dev can still be lazy and the deadline can still be too tight even with that extra LLM help.
I have been saying this for years, I once had a heated argument about a small system of maybe 1000 lines of code that was technically superior and more scalable but was freaking 1000 lines of code to maintain compared to the quick and dirty 10 lines of code it was suppose to abstract and make generic (for future use of course).
That with also countless debates over insignificant features in frontend apps at the cost of extra code. Frontend code is very susceptible to this maintenance cost dilema.
Many developers are too focused on delivery value compared to maintenance cost. It is unfortunate that non-technical management can see value delivered, but not maintenance cost incurred. With LLM-assisted code this has become many times worse.
Executives are salivating at the prospect of AI being able to execute their plans instead of real humans. It is not even about human payroll cost, you can just tell that many higher up executives just complain about how hard it is to steer the ship and get people to work on the right things.
Unfortunately they also don't realize just how much decision-making real people do lower down the org-chart. Critical decisions are often done by the leaf nodes, often without even discussing it internally with the leaf-node team. AI will likely not be very good at this kind of decision making or realize any decision needs to be made at all.
My company recently got a ton of AI credits on Linear and they are testing out this feature where whenever an issue is created in linear, it triggers an AI agent to automatically fix the issue. The idea is that when the dev gets to it, he will just check the preview-URL or run unit tests and rubber-stamp the PR.
It is unlikely this kind of agentic workflow will ever get cheaper. Agents get stuck in doom-loops quite often, just burning tokens without any value. Especially by prompts created by people unfamiliar with the codebase.
And it is becoming increasingly obvious that better models just use more tokens (and take longer to execute on prompts). So this kind of human-out-of-the-loop workflows will be forced to use cheaper models and be time-gated in order to not waste tokens. And then they will also produce worse results than a manual change or a more powerful model...
If tokens get cheaper you just put a better model for this kind of problem and let it run for longer.
But what is more insane is that we are using a ton of cloud VM time on top of a ton of tokens just to save a few minutes from a developer doing the same on his machine...
I don't think my company will keep this system once the free credits run out once they realize how much it actually costs.
I got really annoyed at how slow the LLMs are so I found myself doing more and more prompts like "in file X do Y", if you can piecemeal your task into very limited prompts and periodically reset the context on each go the LLMs do the work MUCH faster. Since I reset the context all the time I often do manual changes in-between prompts.
But at the same time if you do like this you can't do that insane multitasking I see a lot of devs doing where they juggle multiple agents doing separate tasks (maybe even completely separate tasks on different git branches). I _really_ hate working like this and only do it if I know on of my prompts will take 10+ min. Usually an initial prompt for a large task where I will move to my usual 1-file-per-prompt style later.
Of note that I am working on a ~10 year old codebase with a lot of custom instructions for agents and a lot of code to dig through to get things done. I feel a lot of people are conflating using LLMs to start hobby projects and extrapolating the workflow to real world large codebases.
> there is incredibly little interest in most orgs code
I think from a commercial perspective yes, but access to source code is very good for finding exploits which could be very valuable for governments. I could also see a future where companies are directly cyber-attacking competitors in hostile markets too...
Since compilers became a thing Assembly language knowledge atrophied[1] across the workforce.
Since automatic memory management became a thing memory management and pointers knowledge atrophied[1] across the workforce (although not nearly to the same degree).
I think the pattern here is that compilers almost always output better machine code than humans, automatic memory management doesn't output better machine code than skilled humans can very (especially with modern languages that give you a lot build-time safety checks).
And even then, there is still demand for assembly knowledge in the workforce, it is just very niche.
I don't think LLMs will ever be good enough to "almost always" output better code than humans. But, like automatic memory management, it will likely make some types of programming more niche.
The key thing here is that compilers are deterministic, deterministic tools have way less variance in output quality. Automatic memory management is not as deterministic as a compiler because it happens at runtime. LLMs output build-time code, but the can be drastically different if I sneeze too hard.
[1]: as in % of the workforce, not absolute numbers. Hard to get exact figures on this, but I think we have more experienced people actively using Assembly today than we had before compilers became the default (late 80s). We probably have more active C/C++ programmers today than before Java became popular (early 2000s).
I am consistently underwhelmed by the output, I can't really explain it besides LLMs have no taste about what is easier to read for humans.
I usually start a task with an LLM and then do small refactors using the LLM and then do some manual refactors before I am done. But often for more complex tasks the manual refactors are quite large.
Maybe it is because they can read walls of text so easily, so they output walls of text that are hard to read for humans.
I feel quite sad because a lot of my fellow colleagues are not putting this extra effort in to make things easier to understand by humans. PR review is basically me just doing this extra effort for them and their LLM implementing my comments.
And that is when I can even pinpoint the bad taste in the code structure, sometimes it is not something you can easily describe in a PR comment besides "no human would structure the code like this".
My point is that the expertise drain is going to hit those other countries too, within our work-lives given the demographics of China, Korea and Japan. The same thing is happening over there to even worse degrees, youth unemployment is already massive problem in east asia and when all those trained workspeople and engineers leave the work force in ~30 years.
Sure then that expertise could migrate to other countries, possibly some in Africa. But the demographics slow down is probably already going to afflict those countries before the expertise leaves east asia in the first place.
I truly believe that within 40 years we are going to have a massive infrastructure maintenance problem, where the world will run dry of trained professionals to maintain everything that is already built. And, like I mentioned above, the wealth inequality will reduce because the owners of capital will need to pay premium rates for qualified workforce (think how cobol is today).
This kind of antagonism comes from the top. China mostly toned it down recently because it is ideology-driven counter-productive, we will see how long it takes the US to do the same.
It is not a problem of Sweden specifically, I imagine this kind of problem will hit China hard in 20-40 years too. Companies in China behave just the same way as in Sweden, they have huge youth unemployment problems there too.
I worked with CNC machining shops in Sweden and the people working there made the exact same points. CNC is not exactly an art form, but programming the machines definitely has some craftsmanship aspects to it. Even considering that after a part is programmed it can then be mass produced.
- Very hard to get young people in because entry level pays very poorly AND requires non-trivial amounts of training.
- Razor-thin margins so shops can't afford to pay well
- Overall not great work conditions compared to an office job
- Retiring experienced older workforce with no one to replace them
- Having a shop in China machine the parts for you can be quite acceptable, especially in higher volumes
However I disagree with your argument of "obsession with [...] only ever hiring the 10xer". It is not so much that, but rather that if you hire average people with average skills or people that require training *you go out of business* because the shop next door won't.
Basically it drains the expertise completely dry until is just completely moves to another country having a demographic boom. And this is happening to software engineering right now. People who complain about immigration don't seem to realize that non-developed countries are seeing massive population growth reductions too.
Eventually the world is going to run out of countries having demographic booms, then society will have a massive lack of people to maintain existing infrastructure and corporations. The only upside is that wealth inequality should drastically reduce in this scenario (unless some governments manage to push caste systems back into fashion).
Actually yeah, data centers using evaporative cooling shouldn't be causing more waste heat problems than most types of heavy industry. Heck, I would guess that even if datacenters dumping hot water on rivers it shouldn't have much of an impact unless the river is very small.
Shouldn't spread misinformation when there are plenty of other valid points about datacenters.
Datacenter waste heat even a problem? I only ever heard of nuclear power plants waste heat being a problem when the cooling water is dumped directly into rivers (instead of the ocean).
https://www.linkedin.com/in/danielhoffmannbernardes/