4 ms·
The Industrialization of IT
- Animats 2y agoHow much are people paying per month per user for coding AI services?
- dharmab 2y ago20-40 USD per seat is typical (Cursor and GitHub Copilot are both around there)
- lordkrandel 2y agoYou get something right, something awfully wrong. It's true that machines dont sleep, but less true that every software engineer costs 230000$ an year. Maybe (!) that's true in Silicon Valley. In Italy, it costs 35000E. And we don't see many software companies in Italy. Why? Because I'm sad to have that explained, code is 10% of development. Whatsapp was sold for 17 billion dollars and it was 55 employees, and it's an IRC chat made mobile. At the time, it didn't have video. I can keep going on, but this discussion sounds so out-in-space that only USA people could not see. Sorry if you're from somewhere else.
- FirmwareBurner 2y agoUSA is the worldwide exception when it comes to SW industry, not the rule. 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.
- ghaff 2y agoCertainly the sorts of salary numbers thrown around with the likes of Google are not generally true of smaller companies, east coast companies except perhaps for some finance roles, and certainly not for IT/developer roles at non-tech companies. Nor is it true for pretty much any other STEM jobs. Doesn’t seem sustainable. I’m tempted to think that a lot of people learning CS today because it’s so lucrative are going to be disappointed.
- fhd2 2y agoTangential, but an entry level developer at 190k USD per year seems nuts, is that really a reasonable number? From a quick search, I find numbers below 100k USD for the bay area, which seems more reasonable. 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.
- lordkrandel 2y agoTotally agree, and USA hasnt delocalized that, so if cost was the problem, or code production... why?
- hyfgfh 2y agoAgree US market seems bloated, not only salaries but also positions, you can find "seniors" with 2 years of experience, maybe a side effect from the pandemic boom
- c0redump 2y agoYou’re right, but you’ve only got half the truth. Bay Area devs are overpaid and European devs are underpaid.
- freetanga 2y agoAlso, a few years ago I had teams in multiple countries (South East Asia, India, Easter Europe, Western Europe, East and West Coast), all well paid (but not at FAANG levels). While their capacity was roughly similar, the West Coast ones were by far the more expensive ones, but also quite stressed out to make ends meet (buying a house, having a kid, putting them through school) compared to the other teams. 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
- FirmwareBurner 2y ago>but also quite stressed out to make ends meet (buying a house, having a kid, putting them through school) compared to the other teams. 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.
- lordkrandel 2y agoAlso, calculators did millions of operations, but the were 99.999999% right all the time. That's what set the apart from human people: eternal reliability 24/7. AI is about right 1% of the time, a human is needed to recognise when the machine is wrong, and it keeps repeating the same mistakes when identified and corrected. People WISH it was like a calculator, but you know, magic thinking doesn't make things happen.
- senko 2y ago> AI is about right 1% of the time 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.
- jsk2600 2y agoOCRs are quite different from AI/ML, which the parent comment is referring to. In fact, OCR existed way before the current AI wave.
- immibis 2y agoOCRs are AI/ML in the sense it meant to everyone before 2020.
- senko 2y agoIn case it wasn't clear, I'm using "OCR" in my comment above for "reading and interpreting textual documents provided as images", not as a reference to a specific tech such as Tesseract. 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.
- deleted 2y ago[deleted]
- lordkrandel 2y agoI guess that your takes on parallel, compartimentalized, self healing, game-theory based micro AI agents could be spawned and organized code their own way. But... wake me up when it happens, ok? ;)
- ExxKA 2y agoClear and concise thinking, its the first time I have read someone cut through the hype and argue logically for what the next incremental steps are in making progress down this path of LLMs creating technology. 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.
- gabrieledarrigo 2y ago> 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?
- ExxKA 2y agoFor one, I have started using the tools that are available right now, to increase my productivity and intuition with what the new capabilities are. 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. 1. https://en.wikipedia.org/wiki/Don%27t_repeat_yourself https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
- joelthelion 2y ago> In 2025, the engineer probably beats Gemini. Sure, great. But in 2030, who wins this hypothetical? 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.
- Sateeshm 2y ago> 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. This has always been true. LLMs didn't change that.
- ExxKA 2y agoYes! 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.
- bryanrasmussen 2y agoThe 10 average devs can produce hundreds of thousands of lines of buggy, poor performance code that implement thousands of features poorly in the same amount of time the senior developers could implement tens of thousands of lines of great code that implement hundreds of features perfectly. 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.
- swexbe 2y agoTyping shouldn't be what's taking up most of your time if you are a great dev writing great code.
- cyberax 2y agoI tried vibe-coding some non-trivial code. It failed successfully. 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.
- ConspiracyFact 2y ago> We'll get megabytes of code that just fails sometimes, for unfathomable reasons. But…that’s the current situation.
- cyberax 2y agoSorry, not even close. 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.
- lelanthran 2y ago>> We'll get megabytes of code that just fails sometimes, for unfathomable reasons. > 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".
- InsideOutSanta 2y agoI wish people would stop making predictions about LLMs so confidently. Some people confidently predict that LLMs will never be able to replace capable engineers, and other people equally confidently predict that we'll all be out of a job in five years. 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.
- devnull3 2y agoTo be fair, if we know something will happen with high certainty then its not much of a prediction. The fact that no one really knows how LLMS will pan-out means every projection in future is a prediction.
- mihaic 2y agoI echo the parent comment. It's not the fact that predictions are made, it's the fact that no certainty interval is ever given, and everything is pronounced with complete confidence.
- walterbell 2y agos/making predictions/talking their book/ https://news.ycombinator.com/item?id=18146703 https://news.ycombinator.com/item?id=18146703
- 0xEF 2y agoCorrect. 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.
- alganet 2y agoThere was a job once consisting of painting with color black and white photography. 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.
- delbronski 2y agoThe difficult question to answer is not if we will lose our jobs to AI, but when. Are we talking 100 years from now? Are we talking 5 years, 1 year? But yeah, given enough time it is clear to see computers will one day program themselves.
- leto_ii 2y agoI find the outlined scenario well argued and plausible. 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.
- deleted 2y ago[deleted]