The Industrialization of IT
benn.substack.com
benn.substack.com
I have an app where people scan their retail/restaurant/cafe receipts and store them. I use Gemini 2.0 for OCR.
It is right more than 99% of the time. I would be making many more errors transcribing the receipts manually.
AIs are a different kind of tools, for a different kind of problems, with a different kind of failure cases.
In the app, I am, in fact, using AI/ML tech and I'm saying it's very accurate for my use case, as a counterpoint to the parent comment which says AI works in 1% cases, maybe.
But since you brought it up, this workflow works better than the supposedly "99.999999% right all the time" traditional code (traditional OCR tools).
Hope this clears it up.
just write another prompt
edit to say:
One of the best skills for developers is to lookup information using search engines. All the information is out there already you just need an understanding what you are looking for. This is similar to painting the colors are there already but not everyone is a good painter. LLMs empower skilled developers and do the boilerplate work usually done by mediocre developers. Later on it will depend on who can write the best prompt but that requires understanding.
I don't think we need to wait for 2030. Today, using aider/cursor and Gemini-pro-2.5, I'm pretty sure a team of two or three senior developers with great domain knowledge would be competitive with a team of 10 average devs. Being a small, close-knit team has a lot of advantages. And LLMs can help close the productivity gap.
This has always been true. LLMs didn't change that.
Spend any amount of time, reading the implementation of powerfull algorithms (A* search, Bubble sort), and you will realize that the power is in the idea, not the feeble attempt at coding it in PHP, Go, JS or what ever.
But what if the three senior devs could produce thousands of lines of great code that implement thousands of features perfectly. I don't think this is the case but I believe this is what the OP means.
the interest is of course because what "the business" wants is thousands of features, perfectly or imperfectly is a secondary consideration.
on edit: changed senior devs hundreds of thousands to thousands because one benefit is that much of the code the average make is not really needed.
You are comparing senior vs average devs here. What will happen if a team of 'two or three senior devs' with AI/ML tools compete with equally skilled 10 senior devs with AI/ML tools?
The resulting code had a memory leak (from good old Promise.race) that would have caused the app to continuously grow the RAM usage.
I decided to let the AI code, and then asked it to fix the problems, describing the issue (steadily growing RAM usage). It was not able to find the issue.
That's what I'm afraid of. We'll get megabytes of code that just fails sometimes, for unfathomable reasons.
But…that’s the current situation.
A single human can't write megabytes of code within a few hours, unless it's something that was repeatedly cut&pasted.
AI can create megabytes of complicated code that will be impossible to debug. It can do what you want it to do, but not quite.
Kinda like a genie from a lamp.
> But…that’s the current situation.
Where? Bugs are fixed by humans. I want to see a ticket closed due to "can't find bug".
The reality is that we don't know.
We don't know what the ceiling is for LLM programming ability. We don't know how much better they can get without scaling up the hardware. We don't know how well we'll be able to scale up the hardware. We don't know how many more billions we'll allow companies to spend building better and better models until the market loses confidence in them.
We can make educated guesses, but that's all they are. We just don't know.
The fact that no one really knows how LLMS will pan-out means every projection in future is a prediction.
But...
We _do know_ that companies are typically driven by greed and profit, so if it is possible for them to replace their human workers with something that does a similar level of work but also does not require a paycheck, we would be absolute fools to assume that they won't do everything in their power to make that a reality, regardless of the understood reliability of LLMs.
The first steam engines were too expensive and underpowered, the first cars were deatch traps when they actually ran. Dont lul yourself into the dream of a static world.
We see the wave coming, I will look for a way to surf it. Don't be the stunned sceptic waiting to feel the crush.
What would you do to surf it? What would you suggest to who's an engineer right now?
I think the original author is on to something, about how the structure of our codebases will change, and therefore our preferred frameworks will change as well.
The frameworks we use today, assume that the codebase is DRY[1], and that a human will verify the workings of the codebase. A human will write a single test, for a single component and verify that the test functions correctly - then leave it in there, for successive runs to prove there has been no regression to the code quality.
But as the author points out - that doesn't lend itself to truly parallel programming. Because as one programmer/agent changes a central component that another programmer/agent also changed in the same release cycle, merge conflicts arise and grown into architectural conflicts and grow into team conflicts.
I see how accepting more duplication, can lead to more parallelization. I mostly cared about keeping code DRY because its hell to refactor a codebase with 5 implementations of the same thing. But if I am just instructing an LLM to make the change, I dont care how many files it has to visit - its still the same single instruction from me.
So I will think long and hard about how tooling needs to improve, and how frameworks need to change, to be part of this new paradigm. Similar to how Object Oriented Programming optimised for human logic rather than cpu cycles, the time of LLMs will optimise for testability and parallelisation rather than gpu cycles, or DRY paradigmes.
In a well off European country, you'd pay around 45k USD for a strong entry level developer. I can imagine 2x salaries, considering costs of living, fire at will and all that, but >4x? Not sure how to back that up.
Eastern Europe was a place to find hidden gems (very cheap - but not so now), and some brilliant people (but not all of them). Western Europe was consistent, solid moderate quality at moderate costs vs US. So in line with your views
Because a well paid SW dev wages goes soooo much further in developing countries, you're basically a king as every other profession earns very poor in comparison, so home ownership is no issue.
I absolutely know people individually who made 150k+ out of college. Sorry europeans, but Bay Area salaries are definitely a large multiple of European salaries, even entry level.
A lot of this is possible because these companies make a lot of money, and a lot of money per employee, and that trickles down to new-hire salaries. It doesn't seem like there are many wildly profitable European companies in tech, at least not ones that can really drive up salaries like this. It's too bad, because Europe broadly has really strong talent, but I imagine there is a constant pressure pulling people away for more money.
You back that up with the fact that Google makes 500k USD profit per employee, AFTER they pay each of them 200k+ in salaries plus added taxes and other expenses. Valve makes 19 Million USD profit per employee. There are no European tech companies that make even remotely as much profit per employee, so obviously they'll never be able to pay such salaries no matter how much EU workers as for.
It's not like the US tech workers work 4x harder, or 4x faster, or are 4x smarter than the European ones, it's that their companies are 4x more profitable and that reflects in workers' compensation.
What's more interesting to me though is the complete lack of mention of labor unions as a potential defense mechanism for engineers (either in the OP or in the conversation here, at least so far).
For a while now I've felt it's quite arrogant and completely naive of us to not accept that we're just keyboard workers, and not rare special flowers that will forever be economically privileged.
Color photographic film ended that job, but not photography nor painting.
What ended was just the small intersection between the two that was, for a moment, very popular and valuable but suddenly became not a job.
So diversification within the same or adjacent skillset is probably a good idea. Better than panic or putting all chips on one thing.
We don't know the future after all. So much can change so fast.
The US tech industry is reaping the benefits of being the WW2 and cold war victor, the first to the punch in SW development and online capitalization, a homogenous single language market with the top economy in the world and owning the world reserve currency, meaning they can print and throw ungodly sums of money at any app that helps with mass data collection, data which is more valuable to advertisers because the US consumer has the highest purchasing power in the world by a long margin, and subject to less linguistical, financial and legal fragmentation and gov oversight than the EU.
It's a positive reinforcing feedback loop where more money helps creates even more money, like a snowball rolling downhill. It's not something Italy or any EU as a whole can replicate. We can replicate the same SW tech/concepts here, but not the scale and monetary effects that the same tech has in the hands of the US. US is basically playing the game with the infinite money glitch, and the crazy US salaries are a second order effect of that.