DanielHB

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.

> Lines of code are a liability, not an asset.

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.

The main problem of mixing sql and orm together is that most orms don't provide a way to do raw queries in a type safe manner that plays well with non-raw-sql queries.

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".

25% of humans died before reaching 5 in 1800s US, today it is <1%. Its been at least 5 generations since this value dropped dramatically.

We have not ended up with "humans which aren't as strong, aren't as smart, aren't as well adapted to a changing environment, etc."

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 is an example of the Bondaz Effect which is a subtype of the Streisand Effect:

https://en.wikipedia.org/wiki/Wolf_warrior_diplomacy#Bondaz_...

What the US is doing is not that different from wolf tiger diplomacy that China was running during the 2010s

https://en.wikipedia.org/wiki/Wolf_warrior_diplomacy

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.

Blew my mind in stockholm that they have hot water at all. In my home country we just have electric heaters at the shower tap.

(seriously though, I knew they had hot water, it just never occurred to me how awesome it is to have hot water on the tap)

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).

Sam Altman is not an AI researcher, I don't think he ever worked directly with tech as an engineer either. Pure MBA-with-engineering-degree type.

An awning protrudes out of the window so airflow can still pass and light still gets into the room (just not direct light).

Even if the shutters are wood and white when sun hits them they will radiate some heat into the indoors. But of course shutters are still better than letting the sun hit your floor directly.

> Living in a city where 80% of residential electricity comes from hydropower, the emissions argument seems a bit moot.

In an interconnected grid (most of europe) clean power capacity that is not used locally can be sold off to places that have less clean power capacity. This argument only works if all of europe was mostly renewable energy.

But I mean, heat-pump AC is quite efficient as long as you are not making your home frigid year-around I don't see that as a big argument. Govs would be better served by providing good heat-pump regulations and pre-approved installations for residential builds and banning those incredible ineficient portable ACs.

Awnings are significantly better than shutters, but they at most mitigate the heat and the temperature range they make the ambient confortable is quite limited.

It is because of insulation and lack of sun-mitigating apparatus (like awnings). Buildings with lots of insulation absorb heat all through the day and release it slowly at night.

If you are in the market for a portable AC I highly recommend you watch this video first:

https://youtu.be/_-mBeYC2KGc

People seem to be catching on this and some brands now offer portable mini-splits ACs, I just bought this one (waiting for it to arrive though):

https://youtu.be/D5ApvRis9X8?t=45

However they are still quite expensive.

I live in sweden and I am baffled by how uncommon awnings are. In my home country window shutters that also work as yawnings are quite common, especially in places without AC.

My partner was downright insulted when I suggested getting some blackout curtains to reflect sunlight back outside when the sun is hitting our living room. I eventually won that battle after the first summer.

Oh god I feel OLD reading this.

> It seems great to be able to cut hundreds of megabytes out of your app installer

Your points are valid, but the big upside is that the default system webview is very likely to already be loaded in memory before your app starts. And if multiple apps use the default system webview all of them will load that same dynamically linked binaries only once.

I don think the RAM savings are that significant on modern systems, but it greatly speeds up app first-loading times.

I did a project for a big telecom in Brazil where they kept everything in one massive Oracle database that ran out of 2 oracle refrigerators[1]. They kept freaking logs on the database, like normal application level logs.

DBA would go around screaming if you were logging too much stuff. I assumed they had some sort of periodic cleanup because I couldn't see that stuff being practical long term.

Technically it was 2 databases, one was a read replica for longer running data analysis of course.

That telecom has at least 100 million paying customers (maybe much more). I don't see they ever moving away from Oracle, they are more likely to go bankrupt than ever leaving.

[1]: Oracle RAC: https://en.wikipedia.org/wiki/Oracle_RAC

Well you have to somehow both indicate that you are not behind in the AI race but also that you are not hemorrhaging money. That means crapping all over your org in order to fund the data center spending.

All in the all-mighty fiduciary duty to your investors of course.

What I don't get is why these companies are in all the rush to replace people with AI tools. Stuff is changing so fast that capital investment right now will just need to be reworked on after a few years when things settle down a little.

And that is not even considering how much it costs to run AI right now at scale AND retraining people to use the new tools AND possible disruption in existing workflows.

If I was running a large org I would actively try to slow down AI adoption in most areas until there are clear established solutions.