Has the cost of building software dropped 90%?
martinalderson.com
martinalderson.com
I tried leaning in. I really tried. I'm not a web developer or game developer (more robotics, embedded systems). I tried vibe coding web apps and games. They were pretty boring. I got frustrated that I couldn't change little things. I remember getting frustrated that my game character kept getting stuck on imaginary walls and kept asking Cursor to fix it and it just made more and more of a mess. I remember making a simple front-end + backend with a database app to analyze thousands of pull request comments and it got massively slow and I didn't know why. Cursor wasn't very helpful in fixing it. I felt dumber after the whole process.
The next time I made a web app I just taught myself Flask and some basic JS and I found myself moving way more quickly. Not in the initial development, but later on when I had to tweak things.
The AI helped me a ton with looking things up: documentation, error messages, etc. It's essentially a supercharged Google search and Stack Overflow replacement, but I did not find it useful letting it take the wheel.
Like, is there truly an agentic way to go 10x or is there some catch? At this point while I'm not thrilled about the idea of just "vibe coding" all the time, I'm fine with facing reality.
But I keep having the same experience as you, or rather leaning more on that supercharged Google/SO replacement
or just a "can you quickly make this boring func here that does xyz" "also add this" or for bash scripts etc.
And that's only when I've done most of the plumbing myself.
I switched jobs somewhat recently. At my previous job, where I was on the codebase for years, I knew where the changes should be and what they should look like. So I tried to jump directly to implementation with the AI because I didn't need much help planning and the AI got confused and did an awful job.
In a new codebase, where I had no idea how things are structured, I started the process by using AI to understand where the relevant code is, the call hierarchies and side effects, etc.
I have found by using the AI to conduct the initial investigation, it was then very easy to get the AI to generate an effective spec, and then it was relatively easy to get the AI to generate the code to that spec. That flow works much better than trying to one shot implementation
When given focused questions for parts of the code it it will give me 2-4 different approaches extending/implementing different bean overrides. I go through a cycle of back and forth having it give me sample implementations. I often ask what is considered the more modern or desirable approach. Things like give me a pros and cons list of the different approaches. The one I like the best I then go look up the specific docs to fact check a bit.
For this type of work it easily is a 2-3x. Spring specifically is really tough to search for due to its long history and large changes between major versions. More times than not it lands me on the most modern approach for my Spring Boot version and while the code it produces is not bad it isn’t great either. So, I rewrite it.
Also it does a pretty good job of writing integration tests. I have it give me the boilerplate for the test and then I can modify it for all my different scenarios. Then I run those against the unmodified and refactored code as validation suite that the refactor didn’t introduce issues.
When I am working in GoLang I don’t get this level of speed up but I also don’t need to look up as much. The number of ways to do things is far lower and there is no real magic behind the scenes. This might be one reason experiences may differ so radically.
Someone who hasn’t got any experience coding, or leading in any capacity, anywhere in life (or mentoring) will have a hard time with agentic development.
I’ll elaborate a bit more - the ideal mindset requires fighting that itch to “do it yourself” and sticking to the prompts for any changes. This habit will force you to get better at communicating effectively to others (including agents).
Just last weekend I wanted a script to process a csv file and produce some reports and graphs out of that. I think it would've taken me the 2-4 hours to write it myself. Instead, I had cursor write it while waiting for boarding at the airport, probably no more than 10 minutes.
For codebases anything more complex than that, it starts to fall apart pretty quickly.
In that scenario it works ok only if I do all the work of designing the system and the functions and only let it type in the code for individual strictly-defined functions. So it does save some work which is nice, but it's not a huge win.
I'm 45 years old, have been programming since I was 9, and this is the most amazing time to be building stuff.
If you can reduce a problem to a point where it can be solved by simple code you can get the rest of the solution very quickly.
Reducing a problem to a point where it can be solved with simple code takes a lot of skill and experience and is generally still quite a time-consuming process.
Granted that's because the program is incredibly poorly written, but still, context window will stay a huge barrier for quite some time.
Here's an example I saw on twitter. Asking an LLM to document a protocol from the codebase:
https://ampcode.com/threads/T-f02e59f8-e474-493d-9558-11fddf...
Do you think you will be able to capture any of this extra value? I think I'm faster at coding, but the overall corporate project timeline feels about the same. I feel more relaxed and confident that the work can be done. Not sure how to get a raise out of this.
That's not the definition of legacy. Being there for a long time and getting lots of use is not what makes a legacy project "legacy".
Legacy projects are characterized by not being maintained and having little to no test coverage. The term "legacy" means "I'm afraid to touch it because it might break and I doubt I can put it back together". Legacy means resistance to change.
You can and do have legacy projects created a year or two ago. Most vibecoded apps fit the definition of legacy code.
That is why legacy projects are a challenge to agentic coding. Agents already output huge volumes of code changes that developers struggle to review, let alone assert it's correctness. On legacy projects that are in production, this is disastrous.
This is the key take right here. LLMs excel at parsing existing content, summarizing it, and use it to explore scenarios and hypotheticals.
Even the best coding agents out there such as Claude Code or Gemini often fail to generate at the first try code that actually compiles, let alone does what it is expected to do.
Apologists come up with excuses such as the legacy software is not architected well enough to be easily parseable by LLMs but that is a cheap excuse. The same reference LLMs often output utter crap in greenfield projects they themselves generated, and do so after a hand full of prompts. The state of a project is not the issue.
The world is coming to the realization that the AI hype is not delivering. The talk of AI bubble is already mainstream. But like IDEs with auto complete, agents might not solve every problem but they are nevertheless useful and are here to stay. They are more a kin to a search engine where a user doesn't need to copy/paste code snippets to apply a code change.
The sooner we realize this, the better.
E.g. I have to deal with lot of reports and those are usually "never fully developed" because "we can add this one row/feature later" because "management want us to ship early". Now I can enhance our reports by whatever metric just by handing over a current XLSX-exportcode and tell the LLM: "now i want additionally XY here...."
The open question is why people needed fancy AI tools like Claude to write CRUDs in the first place. These kind of tasks ought to be have been automated a long time ago.
They have been, repeatedly, since the 70s. See dBase, Clipper, Microsoft Access, Hypercard, Ruby on Rails, stretching Wordpress to within an inch of its life, all manner of "no-code" things...
And, honestly, Excel. People do all manner of terrifying things with Excel, and it is unquestionably the most successful, and arguably the _only_ successful, "we can do this thing instead of employing a programmer" tool.
Generally, one of two things has happened. Either (a) the products of such automation become unmaintainable nightmares (common for the more automated approaches like MS Access) or (b) they become complex enough that they tend towards 'normal' programming (common with, say, Rails, where you could get a simple CRUD with basically just DSL, but realistically eventually you're gonna be writing lots of Ruby).
I feel like LLM-produced stuff is probably going to fall into column A.
It’s much easier to write business logic in code. The entire value of CRUD apps is in their business logic. Therefore, it makes sense to write CRUD apps in code and not some app builder.
And coding assistants can finally help with writing that business logic, in a way that frameworks cannot.
You don't need Claude to write it. But you cannot generate solid web forms with the same speed. What usually would have taken you a few hours is now solved in much less time.
I doubt software will get cheaper though, requirements will adapt.
People have been trying for literally decades. The problem is that there is just enough uniqueness to every CRUD app that you can't really have "the CRUD app".
I guess it's the sweet spot for AI at the moment because they're 95% all the same but with some fairly simple unique aspects.
The number of lines of code to be written is much, much lower than in the early 2000's.
Your project is still going to fail, but it will fail faster with the 10 excavators.
Plus there's a lot of simple code you shouldn't be writing either way, because it's in a library by now.
By their nature, LLMs will do their best with things that could be plagiarized.
Local models are becoming more and more capable but the tooling still needs to get better for those.
Need to add, “…and what ‘simple’ means is getting broader by the day.”
The cost of writing code has dropped 90%. The cost of maintaining code, which has always been the hardest part, has grown 90% ; )
Even 12 months ago simplifying tasks alone was insufficient, you still needed a large group engineers to actually write, review and maintain a typical product for solid startup offering. This came with the associated overhead of hiring and running mid sized teams.
A lot of skilled people (y)our age/experience are forced into doing people management roles because there was no other way to deliver a product that scales(in team and complexity not DAU).
A CTO of mid-stage startup had to be good architect, a decent engineering manager, be deeply involved in product and also effectively communicate with internal and external customers.
Now for startups setting up new you can either defer the engineering manager and people complexity lot latter than you did before. You could have a very senior but small team who can be truly 10x level and be more productive without the overhead of communication, alignment and management that comes with large teams.
----
tldr; Skilled engineers can generate outsized returns to orgs that set them up to be successful(far more than before), I can't say if compensation is reflecting this yet, if not it soon will.
I fed Claude Pro a REST API spec and told it to spit out a Powershell module and well... So far that 27k lines of code largely checks out (minus the undocumented stuff I knew about).
Getting it to write the pester scripts was a very different matter...
From where I sit, right now, this does not seem to be the case.
This is as if writing down the code is not the biggest problem, or the biggest time sink, of building software.
- Maintenance, Security
- Upgrades and patches
- Hosting and ability to maintain uptime with traffic
- Support and dealing with customer complexities
- New requirements/features
- Most importantly, ability to blame someone else (at least for management). Politics plays a part. If you build a tool in-house and it fails, you are on the chopping block. If you buy, you at least can say "Hey everyone else bought it too and I shouldn't be fired for that".
Customers pay for all of the above when they buy a SAAS subscription. AI may come for most of the above at some point but not yet. I say give it 3-5 years to see how it all pans out.
My bet is if there were a lot of great apps being built, even excellent quality, nobody would even hear about them. The big players would copy them before anyone even found out about them.
IMO, the market is not even a playing field anymore, this is why everyone is getting into politics now, though politics is also somewhat monopolized, there is still more potential for success because there is such an abundance of dissatisfied people willing to look outside of mainstream channels. It's much easier to sell political ideologies than to sell products.
And why would the benefits of being able to code faster accrue to a small independent developer over a large company that already has an established reputation and a customer base?
“No one ever got fired for buying Salesforce”.
I once had influence over the buying decision to support an implementation I was leading. I found this perfect SaaS product by a one man shop who was local.
Working with my CTO and lawyers, we made a proposal to the founder. We would sign with him and be 70% of his post signing revenue if he agreed to give us our own self hosted instance and put his latest code in escrow with a third party (Green Mountain) and we would have non exclusive rights to use the code (but not distribute it) under certain circumstances.
Often these SaaS tools are expensive, aren't actually that complicated (or if they are complicated, the bit they need isn't) and have limitations.
For example, a company I know recently got told their v1 API they relied on on some back office SaaS tool was being deprecated. V2 of the API didn't have the same features.
Result = dev spends a week or two rebuilding that tool. It's shipped and in production now. It would have taken similar amount of time to work around the API deprecation.
You had all these small-by-modern-standards teams (though sometimes in large companies) putting out desktop applications, sometimes on multiple platforms, with shitloads of features. On fairly tight schedules. To address markets that are itty-bitty by modern standards.
Now people are like “We’ll need (3x the personnel) and (2x the time) and you can forget about native, it’s webshit or else you can double those figures… for one platform. What’s that? Your TAM is only (the size of the entire home PC market circa 1995)? Oh forget about it then, you’ll never get funded”
It seems like we’ve gotten far less efficient.
I’m skeptical this problem has to do with code-writing, and so am skeptical that LLMs are going to even get us back to our former baseline.
Edit: I also feel stumped why so many people give in to this hype that LLMs are good at coding when they can't even do seemingly simple tasks of plain English language summarization accurately as evidenced in https://www.youtube.com/watch?v=MrwJgDHJJoE. If the AI summarizes the code in its own context incorrectly then it will not be able to write it correctly either.
It definitely has for me. I'm creating toolS and utilities every week easily that I never would've attempted in the past.
> This is as if writing down the code is not the biggest problem, or the biggest time sink, of building software.
Lots of people can think logically and organize a process flow, but don't know all the ridiculous code incantations (and worse development and hosting environment details) to turn their plans into tools.
It's trivial to one-shot all kinds of impressive toys in Gemini now, but it's going to be an even bigger deal when Google adds some type of persistent data storage. It will be like the rebirth of a fully modern Microsoft Access.
Most SaaS used to be killed by bespoke software engineers that would build some custom thing, and it was integrated perfectly into the legacy system.
Then all those people decided to be managers and go on "i dont care" autopilot mode and hired a bunch of teens that still do care, to some extent. But those teens suck at it, and the old guys just don't really care anymore.
Now with agentic code, instead of "buy splunk" or "buy jira" or whatever thing they are trying to do, they have one of those "teens now in their mid twenties" that are SUPER excited about Agentic flows, either write an agentic tool or simply use an agentic tool to code up the 300 lines of code that would replace their need for a Jira or a Splunk or whatever. Since most people only use 5% of the total features of any product, there's no reason to buy tools anymore, just build it for a fraction of the cost.
I don't know if the above is where we're at right now, but it's coming.
Don't forget the second-order effect of clients deciding they could do it in-house.
Aha. Are developers finally realizing that just writing code doesn't make a business? We actually have a ton of SaaS companies being born right now but they're not making headway, because functionality and good code don't necessarily mean good businesses. Building a business is hard.
You are saying there aren't more low cost alternatives coming out
You also say writing code isn't the big problem (which I agree with)
But both can be true and in fact the reason is because the second is true! You aren't seeing the alternate because marketing is hard. People generally don't care about new products and aren't willing to save a little bit of money risking their time on something new
There have been a lot of little blogs about "home cooking" style apps that you make for yourself. Maybe AI is the microwave meal version.
make something decent in the same space as an existing mega-corporation's tool? prepare to get sued and they also steal your good ideas and implement them themselves because you don't have the money to fight them in court
"Today we’re introducing Fizzy. Kanban as it should be, not as it has been. [...] we’ll host your account for just $20/month for unlimited cards and unlimited users. [...] And here’s a surprise... Fizzy is open source! If you’d prefer not to pay us, or you want to customize Fizzy for your own use, you can run it yourself for free forever." https://x.com/jasonfried/status/1995886683028685291
(Or at least AI-assisted to the point where the author feels like they should mention it.)
The marketplace for software for single-owner shops or 1-5 employee size places does seem to be quite strong, and then there's enterprise software, but small business seems to have a software marketplace that is atrociously bad. Here is the typical thing a prospective customer asks me to fix for them:
- They are using some piece of software that is essential to their business. - There really isn't much good competition for that software, and it would be a large cost to convert to another platform that also has all the same downsides below. - The software vendor used to be great, but seems to have been sold several times. - The vendor has recently switched to a subscription-only model and keeps on raising subscription prices in the 12% or so range every year, and the cost of this has started to become noticeable in their budget. - They were accustomed to software being a capital investment with a modest ongoing cost for support, but now it's becoming just an expense. - Quality has taken a nosedive and in particular new features are buggy. Promised integrations seem quite lacking and new features/integrations feel bolted on. - Support is difficult to get ahold of, and the formerly good telephone support then got replaced by being asked to open tickets/emails and now has been replaced by an AI chatbot frontend before they can even open a ticket. Most issues go unresolved.
There are literally millions of software packages in existence, and the bulk of them by numbers are niche products used by small businesses. (Think of a software package which solely exists to help you write custom enhancements for another software package which is used by a specific sector of the furniture-manufacturing business, to get an example.) The quality of this sector is not improving.
This is a field that is absolutely ripe for improvement. If the cost of building software really were dropping 90%, this would be a very easy field to move into and simply start offering for $6,000 a year the product that your competition is charging $12,000 a year for, for an inferior product. Before you bring up things like vendor lock-in or the pain of migration... why can't you write software to solve those problems, too? After all, the cost of writing a migration tool should be 90% cheaper now, too, right?
The crap I build _replaces_ someone else's SaaS (or free open source) product.
They solve my exact problem and nothing else and they follow the ways I like to use my software, with no fancy Dockerised WebUIs etc.
I have exactly zero intention of putting any of that shit out there as any kind of service with user accounts and billing and all of the associated stress. A few of them might be something I could sell as a SaaS offering, but I'm not interested in it at all.
Most of them are on my Github though for anyone to get and use as they see fit, but then it's up to them if the vibe coded program does something it shouldn't :)
NODS HEAD VIGOROUSLY
Last 12 months: Docusign down 37%, Adobe down 38%, Atlassian down 41%, Asana down 41%, Monday.com down 44%, Hubspot down 49%. Eventbrite being bought for pennies.
They are being replaced by newer, smaller, cheaper, sometimes internal solutions.
> I've had Claude Code write an entire unit/integration test suite in a few hours (300+ tests) for a fairly complex internal tool. This would take me, or many developers I know and respect, days to write by hand.
I have no problem believing that Claude generated 300 passing tests. I have a very hard time believing those tests were all well thought out, consise, actually testing the desired behavior while communicating to the next person or agent how the system under test is supposed to work. I'd give very good odds at least some of those tests are subtly testing themselves (ex mocking a function, calling said function, then asserting the mock was called). Many of them are probably also testing implementation details that were never intended to be part of the contract.
I'm not anti-AI, I use it regularly, but all of these articles about how crazy productive it is skip over the crazy amount of supervision it needs. Yes, it can spit out code fast, but unless your prepared to spend a significant chunk of that 'saved" time CAREFULLY (more carefully than with a human) reviewing code, you've accepted a big drop in quality.
However, in saying that, I am by no means an AI hater, but rather I just want models to be better than they currently are. I am tired of the tech demos and benchmark stats that don't really mean much aside from impressing someone who's not in a critical thinking mindset.
Yes sometimes those tests are necessary, but it seemed to just do it everywhere because it made the code coverage percentage go up. Even though it was useless.
I have also had great experiences with AI cranking out straightforward boilerplate or asking C++ template metaprogramming questions. It's not all negative. But net-net it feels like it takes more work in total to use AI as you have to learn to recognize when it just won't handle the task, which can happen a lot. And you need to keep up with what it did enough to be able to take over. And reading code is harder than writing it.
Right, but you do it in a 10th of the time.
I had CC write a bunch of tests to make sure some refactoring didn't break anything, and then I ran the app and it crashed out of the gate. Why? Because despite the verbosity of the tests it turns out that it had mocked the most import parts to test, so the _actual_ connections weren't being tested, and while CC was happy to claim victory with all tests green, the app was broken.
Hundreds of tests that were written basically for free in a few minutes even though a lot of them are kind of dumb?
Or hundreds of tests that were written for a five figure sum that took weeks or months, and only some of them are kind of dumb?
If you’re just thinking of code as the end in and of itself, then of course, the handcrafted artisanal product is better. If you think of code like an owner, an incidental expense towards solving a problem that has value, then cheap and disposable wins every time. We can throw our hands up about “quality“ and all that, but that baby was thrown out with the bathwater a very, very long time ago. The modern Web is slower than the older web. Desktop applications are just web browsers. Enterprise software barely works. Windows 11 happened. I don’t think anybody even bothers to scrutinize their dependency chains except for, I don’t know, like maybe missile guidance or something. And I just want to say Claude is not responsible for any of this. You humans are.
Far better off for who? People constantly dismiss spreadsheets, but in many cases, they are more powerful, more easily used by the people who have the domain knowledge required to properly implement calculations or workflow, and are more or less universally accessible.
But it's very hard to have a large conventional cell-formula spreadsheet that is correct. The programming model / UI are closely coupled, so it's hard to see what's going on once your sheet is above some fairly low complexity. And many workplaces have monstrous sheets that run important things, curated lovingly (?) for many years. I bet many or most of them have significant errors.
Especially for collaboration, access controls, etc. Not to mention they could do with unit testing.
Most medium to large complex spreadsheets are better implemented in a high level programming language.
Spreadsheets seem useful for people that are scared of programming syntax but quickly become so much less maintainable and janky that I believe its almost always easier to just start with learning to program already.
Especially excel is 100% jank.
It’s a rare spreadsheet that survives its original creator.
There is of course SAP for common problems.
Assuming the SaaS is implemented competently, of course. Otherwise there's not much advantage.
I think the 90/90 rule comes into play. We all know Tom Cargill quote (even if we’ve never seen it attributed):
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
It feels like a gigantic win when it carves through that first 90%… like, “wow, I’m almost done and I just started!” And it ‘is’ a genuine win! But for me it’s dramatically less useful after that. The things that trip up experienced developers really trip up LLMs and sometimes trying to break the task down into teeny weeny pieces and cajole it into doing the thing is worse than not having it.
So great with the backhoe tasks but mediocre-to-counterproductive with the shovel tasks. I have a feeling a lot of the impressiveness depends on which kind of tasks take up most of your dev time.
If your job is pumping out low-effort websites that are essentially marketing tools for small businesses, it must feel like magic. I think the more magical it feels for your use case, the less likely your use case will be earning you a living 2 years from now.
I (probably) still would have used CC heavily with benefit of hindsight but with a view that every seemingly “trivial” feature CC adds in the greenfield stage to be radioactive tech debt as the pile grows over time. Until reaching the point where CC starts being unable to comprehend its own work and I have to plan out tedious large scale refactors to get the codebase into a state approaching long term maintainability.
The company had already tried to push 2 poor data analysts who kind of new Python into the role of vibe coding a Python desktop application that they would then distribute to users. In the best case scenario, these people would have vibe coded an application where the state was held in the UI, with no concept of architectural seperation and no prospects of understanding what the code was doing a couple months from inception (except through the lens of AI sycophancy), all packaged as a desktop application which would generate excel spreadsheets that they would then send to each other via Email (for some reason, this is what they wanted - probably because it is what they know).
You can't blame the business for this, because there are no technical people in these orgs. They were very smart people in this case, doing high-end consultancy work themselves, but they are not technical. If I tried to do vibe chemistry, I'm sure it would be equally disastrous.
The only thing vibe coding unlocks for these orgs by themselves is to run headfirst into an application which does horrendous things with customer data. It doesn't free up time for me as the experienced dev to bring the cost down, because again, there is so much work needed to bring these orgs to the point where they can actually run and own an internal piece of software that I'm not doing much coding anyway.
Well there is a terrifying thought
Maybe we should collect all of these predictions, then go back in 5-10 years and see if anyone was actually right.
Overall, it echos my experience with Claude Opus 4.5 in particular. We’ve passed a threshold (one of several, no doubt).
It’s often hard to ground how “good” blog writers are, but tidbits like this make it easy to disregard the author’s opinions. I’ve worked in many codebases where the test writers share the authors sentiment. They are awful and the tests are at best useless and often harmful.
Getting to this point in your career without understanding how to write effective tests is a major red flag.
Stuff like reimplementing large amounts of the code inside the tests because testing the actual code is "too hard", spending inordinate amounts of time covering every single edge case on some tiny bit of input processing unrelated to the main business logic, mocking out the code under test, changing failing tests to match obviously incorrect behavior... basically all the mistakes you expect to see totally green devs who don't understand the purpose of tests making.
It saves a shitload of time setting up all the scaffolding and whatnot, but unless they very carefully reviewed and either manually edited or iterated a lot with the LLM I would be almost certain the tests were garbage given my experiences.
(This is with fairly current models too btw - mostly sonnet 4 and 4.5, also in fairness to the LLM a shocking proportion of tests written by real people that I've read are also unhelpful garbage, I can't imagine the training data is of great quality)
I hear vague suggestions like "get better at the business domain" and other things like that. I'm not discounting any of that, but what does this actually mean or look like in your day-to-day life? I'm working at a mid-sized company right now. I use Cursor and some other tools, but I can't help but wonder if I'm still falling behind or doing something wrong.
Does anybody have any thoughts or suggestions on this? The landscape and horizon just seems so foggy to me right now.
I think it's about looking at what you're building and proactively suggesting/prototyping what else could be useful for the business. This does get tricky in large corps where things are often quite siloed, but can you think "one step ahead" of the product requirements and build that as well?
I think regardless if you build it, it's a good exercise to run on any project - what would you think to build next, and what does the business actually want. If you are getting closer on those requests in your head then I think it's a positive sign you are understanding the domain.
1. Use the tools to their fullest extend, push boundaries and figure out what works and what doesn't
2. Be more than your tools
As long as you + LLM is significantly more valuable than just an LLM, you'll be employed. I don't know how "practical" this advice is, because it's basically what you're already doing, but it's how I'm thinking about it.
Ultimately, software is for doing something, and that something can be a whole range of things. If you become really good at just a slice of that, things get a lot easier regardless of the general state of the industry.
1) Specialize in product engineering, which means taking on more business responsibility. Maybe it means building your own products, or maybe it means trying to get yourself in a more customer-facing or managerial role? Im not very sure. Probably do this if you think AI will be replacing most programmers.
2) Specialize in hard programming problems that AI can't do. Frontend is probably most at risk, low level systems programming least at risk. Learn Rust or C/C++, or maybe backend (C#\Java\Go) if you don't want to transition all the way to low level systems stuff.
That being said I don't think AI is really going to replace us anytime soon.
This is normal with all that is going on in the industry and the AI/ML hype. But, one should not allow that to lead to "analysis paralysis".
> specifically with how I should be positioning myself. ... Does anybody have any thoughts or suggestions on this?
You have a stable job; hence your entire focus (for now) should be to "grow" in your job/organization. This means taking more responsibilities both technical/non-technical and demonstrating your long-term commitment to management. On the technical side, start with "full stack development" both frontend and backend so you can contribute end-to-end to the entire product line. Learn/Use all available tools (AI and otherwise) to demonstrate independent initiative. Step up for any tasks which might not have a owner (eg. CI/CD etc.). Keep your boss/higher-ups informed so as to maintain visibility throughout the organization. Learn more about the problem domain, interact more with Marketing/Sales so as to become the liaison between Engineering and rest of the organization/clients.
Generally, all higher management look for initiative and independent drive so that they can delegate work with the assurance that it will be taken care of and that is what you need to provide.
AI will probably replace the bottom ~30-70%(depends who you ask) of dev jobs. Dont get caught in the dead zone when the bottom falls out.
Exactly how we'll train good devs in the future, if we don't give them a financially stable environment environment to learn in while they're bad, is an open question.
Maybe becoming full stack? Maybe understanding the industry a little deeper? Maybe analyzing your company's competitors better? That would increase your value for the business (a bit of overlap with product management though). Assuming you can now deliver the expected tech part more easily, that's what I'd do.
As for me, I've moved to a permanent product management position.
Build your own tools, need a small utility? Use an LLM to create it with you.
Create LLM-focused tools and adjust your workflows to be LLM-friendly.
I personally have a Taskfile setup that follows the same formula regardless of language. "task build" runs lint+test+build. Test and lint are kinda self-evident. All output is set to minimum, only errors are verbose (don't waste context on fancy output).
I also have tools for LLMs to use to find large code files, large and overly complex functions etc.
All project documentation lives in docs/ as markdown files with Mermaid charts.
This way I can just have the general "how to use a taskfile" instructions in my global WHATEVER.md and it'll work in every project.
Learn project management. Working with LLMs is exactly like project managing a bunch of smart and over eager junior coders who want to use every trick and pattern they learned at school for every tiny shell script.
Do a few test projects where you just pretend you're a non-techinical project lead and know WHAT you want but not HOW you want it done. Plan the project, split it into tasks (github tasks or beads[0] both work pretty well). Then have the LLM(s) tackle the tasks one by one and test the end result like a non-techical PM would do in a demo. Comment, critique and ask them to change stuff that doesn't work.
If you can afford it, bring in an outside consultant (Codex or Gemini), both of which are _really_ good at evaluating large codebases for duplication, test coverage, repetition, bad patterns etc. Give their responses verbatim to Claude and ask what it thinks about them.
Working with LLMs is a skill you just need to use to get a feel for it, it's not a science and more like an art. For example I can "feel" when Claude is doing its thing and being either overeager or trying to complete a task while ignoring the burning pile of unit tests it leaves behind and interrupt. it before it gets too far.
Answers I see are typically "be a product manager" or "start your own business" which obviously 95% of developers can't/don't want to do.
My .02$. Show you can tackle harder problems. That includes knowing which problems matter. That happens with learning a "domain", versus just learning a tool (e.g. web development) in a domain.
Change is scary, but thats because most aren't willing to change. Part of the "scare" is the fear of lost investment (e.g. pick wrong major or career). I can appreciate that, but with a little flexibility, that investment can be repurposed quicker today that in pre-2022 thanks to AI.
AI is just another tool, treat it like a partner not a replacement. That can also include learning a domain. Ask AI how a given process works, its history, regulations, etc. Go confirm what it says. Have it break it down. We now can learn faster than ever before. Trust but verify.
You are using Cursor, that shows a willingness to try new things. Now try to move faster than before, go deeper into the challenges. That is always going to be valued.
The people up in the clouds think they have a full understanding of what the software is supposed to be, that they "own" the entire intent and specification in a few ambiguously worded requirements and some loose constraints and, being generous, a very incomplete understanding of the system dependencies. They see software teams as an expensive cost center, not as true the source of all their wealth and power.
The art of turning that into an actual software product is what good software teams do; I haven't yet seen anything that can automate that process away or even help all that much.
Who is going to patch all bugs, edge cases and security vulnerabilities?
In fact looking at the vibecoders enthusiasm for serverless I’m expecting a sharp spike in surprise cloud bills never mind thinking about edge case
It was built by real people. Not a single line of AI slop in it. It was the most fragile crap I had ever the misfortune to witness. Even in my wildest vibe coding a prototype moments I was not able to get the AI to produce that amount of anti patterns, bad shit and code that would have had Hitchcock running.
I think we would be shocked to see what kind of human slop out there is running in production. The scale might change, but at least in this example, if I had rebuilt the app purely by vibe coding the code quality and the security of the code would actually have improved. Even with the lowest vibe coding effort thinkable.
I am not in any way condoning (is this the right word) bad practices, or shipping vibe code into prod without very, very thorough review. Far from it. I am just trying to provide a counter point to the narrative, that at least in the medium sized business I got to know in my time consulting/working in agencies, I have seen quite a metric ton of slop, that would make coding agents shiver.
edit: typos
I'm not sure about this. The tests I've gotten out in a few hours are the kind I'd approve if another dev sent then but haven't really ended up finding meaningful issues.
I had the agent scan the UX of the app being built, find all the common flows and save them to a markdown file.
I then asked the agent to find edge cases for them and come up with tests for those scenarios. I then set off parallel subagents to develop the the test suite.
It found some really interesting edge cases running them - so even if they never failed again there is value there.
I do realise in hindsight it makes it sound like the tests were just a load of nonsense. I was blown away with how well Claude Code + Opus 4.5 + 6 parallel subagents handled this.
People say their prompts are good, awesome code is being generated, it solved a month's worth of work in a minute. Nobody comes with receipts.
I closed a comment from ~2.5y ago (https://news.ycombinator.com/item?id=36594800) with this sentence: "I'm not sure that incorporating LLMs into programming is (yet) not just an infinite generator of messes for humans to clean up." My experience with it is convincing me that that's just what it is. When the bills come due, the VC money dries up, and the AI providers start jacking up their prices... there's probably going to be a boom market for humans to clean up AI messes.
> AI Agents however in my mind massively reduce...
Nevermind. It's a vibe 90%.
Instead it's some guy that claims it takes a team to make CI/CD for something he can vibe-code in a day, and that agentic code totally solves the complexity problems caused by too much React.
There is no value-add to hiring software engineers to build basic apps. That's what AI will be good for: repeating what has already been written and published to the web somewhere. The commoditized software that we shouldn't have been paying to write to begin with.
But AI won't help you with all the rest of the cost. The maintenance, which is 80% of your cost anyway. The infrastructure, monitoring, logging, metrics, VCS hosting, security scanning, QA, product manager, designer, data scientist, sales/marketing, customer support. All of that is part of the cost of building and running the software. The software engineers that churn out the initial app is a smaller cost than it seems. And we're still gonna need skilled engineers to use the AI, because AI is an idiot savant.
Personally I think 50% cost reduction in human engineers is the best you can expect. That's not nothing, but that's probably like a 10% savings on total revenue expenditure.
Well, arent these the topics for what we have AI-managed infrastructure now? :-D LOL
My wife works at Shutterstock, first as a SWE, now as a product manager. Most of their tasks involve small changes in 5 different systems. Sometimes in places like Salesforce. A simple ask can be profoundly complicated.
AI has certainly made grokking, and code changes easier. But the real cost of building has not been reduced 90%. Not even close.
Developing production grade software which you want to people to rely on and pay for it is not gone down so much. The "weak" link is still human.
Debugging complex production issues needs intimate knowledge of the code. Not gonna happen in next 3-4 years atleast.
1. Rob one’s understanding of the design and implementation
2. Give the unqualified enough confidence to contribute
I'm finding this stuff, when given proper guidance, can reproduce experiments I've run incredibly fast. Weeks of typing done in minutes of talking to Claude Code.
In the working world, a lot of the time what matters is getting results, not writing 'perfect' code the way software engineers would like to.
concerns: - security bugs - business logic errors that seem correct but are wrong
as long as you have domain experts, I suspect these will gradually go away. hopefully LLMs can be trained not to do insecure things in code.
But you do recognize that one's ability to speedily implement features is dependent on the present quality of a codebase, right? Being a serious practitioner here means balancing active feature development with active tending to the codebase to keep it in a reasonable state, since its quality will tend ever downward otherwise.
In your experiments, do you find agents readily find this balance? I ask genuinely, I have only minimal experience with Cursor.
The more niche the thing you’re working on the worse results I’ve found these tools to give
Was there an explosion of useful features in any software product you use? A jump in quality? Anything tangible an end user can see?..
I used to look at release notes excited about what new features I might get. Now I read them with some level of anxiety. I hope none of the inevitably removed features are ones I used.
The AI evangelist talks to me about 10×. Meanwhile, all the software I use is becoming less functional, less configurable, less powerful, less secure, less stable, and in general crappier by the day.
you need to give it a bigish thing so it can work 15 min on it. and in those 15 min you prepare the next one(s)
If you're replacing spreadsheets with a single-purpose web UI with proper access control and concurrent editing that doesn't need Sharepoint or Google Workspaces, fine, but if you're telling me that's going to revolutionize the entire industry and economy and justify trillions of dollars in new data centers, I don't think so. I think you need to actually compete with Sharepoint and Google Workspaces. Supposedly, Google and Microsoft claim to be using LLMs internally more than ever, but they're publicly traded companies. If it's having some huge impact, surely we'll see their margins skyrocket when they have no more labor costs, right?
TDD as defined by Kent Beck (https://tidyfirst.substack.com/p/canon-tdd ) doesn't belong in that list. Beck's TDD is a way to order work you'd do anyway: slice the requirement, automate checks to confirm behavior and catch regressions, and refactor to keep the code healthy. It's not a bloated workflow, and it generalizes well to practices like property-based testing and design-by-contract.
Like I prefer Opus 4.5 and Gemini 3 to the open weights models, but if Anthropic or Google upped the pricing 10x then everyone would switch to the open weights models.
Arguably you could say that the Chinese labs may stop releasing them, true, but even if all model development stopped today then they'd still be extremely useful and a decent competitor.
This is simply unimaginable level of productivity— in one day on my phone, I can essentially build and replace expensive software. Unreal days we are living in.
Product doesn't understand the product because if it was easy to understand then someone else would have solved the problem already and we wouldn't have jobs. This means you need to iterate and discuss and figure out just like always. The iterations can be bolder, bigger, etc and maybe a bit faster but ultimately software scales np so a 10x improvement in -individual- capability doesn't scale to 10x improvement in -organizational- capability.
Let me put it another way. If your problem was so simple you could write a 200 word prompt to fully articulate it then you probably don't have much of a moat and aren't providing enough value to be competitive.
I'm sure that AI tools will be here to stay and will become more integrated and better. I wonder what the final result will be, -20% productivity as in the METR study? +20%? Anything like 90% is the kind of sensationalism reserved for r/WallStreetBets
If you are a chairmaker and everyone gains access to a machine that can spit out all the chair components but sometimes only spits out 3 legs or makes a mistake on the backs, you might find it pointless. Maybe it can't do all the nice artisan styles you can do. But you can be confident others will take advantage of this chair machine, work around the issues and drive the price down from $20 per chair to $2 per chair. In 24 months, you won't be able to sell enough of your chairs any more.
The advent of the PC, and the appearance of Turbo Pascal, Visual Basic, and spreadsheets that could be automated made it possible for almost anyone to write useful applications.
If it gets cheaper to write code, we'll just find more uses for it.
We are hurdling towards a brave new world where only 10% of humans have to work, and the other 90% form the bureaucracy on top.
If it’s so good why hasn’t it made you rich?
And this company, with all the formidable powers of AI behind them, can find no way to optimize that other than pre loading the app in memory. And that's for a app that's basically a GUI for `ls`
With the steam engine, though, consumers made a trade-off: You pay less, and get (in most cases, I presume) a worse product. With LLMs and other machine learning technologies, maybe if you're paying for the software there's a trade-off (if the software is actually cheaper anyway), but otherwise it doesn't exist. It costs the same amount of money for you to read an LLM-generated article as to read a real one; your internet bill doesn't go down. Likewise for gratis software. It's just worse, with no benefit.
Hacker News is full of producers, in this sense, who often benefit from cutting corners, and LLMs allow them to cut corners, so obviously there are plenty of evangelists here. I saw someone else in this comment section mention that gamers who are not in the tech industry don't like "AI". That's to be expected; they're not the producers, so they're not the ones who benefit.
And what do you have then? 300 tests that test the behavior that's exposed by the implementations of the api. Are they useful? Probably some are, probably some are not. The ones that are not will just be clutter and maintenance overhead. Plus, there will be lots of use-cases for which you need to look a little deeper than just the api implementation, which are now not covered. And those kind of tests, tests that test real business use cases, are by far the most useful ones if you want to catch regressions.
So if your goal is to display some nice test coverage metrics on SonarQube or whatever, making your CTO happy, yes AI will help you enormously. But if your goal is to speed up development of useful test cases, less so. You will still gain from AI, but nowhere near 90%.
My observation is that there is perhaps 15% of my job that has been boosted by AI by quite a lot, and the rest it hasn't touched much at all. Most of the job just isn't coding badically. The code generation aspect is a bit flawed too because to get good results I often spend more time collating requirements and engineering the prompt that I again could have just done it quicker myself.
There is a sweet spot in there where the requirements were easy to write out, and the code was simple enough but there is a lot to write, that it's nice to not have to write it myself. But even then I am finding that AI is often not successful, and if it takes three tries to get it to do the work properly then there is no productivity gain. Often enough time is lost to the failed attempts.
Usually there isn't that much code to write, but it's fairly complex and needs to be correct, which is where I find LLMs have too many failed attempts and waste time.
(I am an 18+ year "everything" developer, my experiences are from using Claude Code)
"Good AI developers" are a mystery being (not really, but for corporate they are). Right now, companies are trying to measure them to understand what makes them tick.
Once that is measured, I can assure you that the next step is trying to control their output, which will inevitably kill their productivity.
> This then allows developers who really master this technology to be hugely effective at solving business problems.
See what I mean?
"If only we could make them work to solve our problems..."
You can! But that implies additional coordination overhead, which means they'll not be as productive as they were.
> Your job is going to change
My job changes all the time. Developers are ready for this. They were born of change, molded by it. You know what hasn't caught up with the changes?
But the hard work always was the conceptual thinking? At least at and beyond the Senior level, for me it was always the thinking that's the hard work, not converting the thoughts into code.
Oh, false dilemma :/
I refer here to my experience as a solo developer.
With AI assistance I don't spend less hours coding, but more.
There is the thrill of shipping relevant features that were sleeping in my drawers for ages, quicker. Each hour of coding delivers just 8 x more features and bug solving.
Also, whereas I spent a few dozen dollars per month on server costs, I now also spend an equivalent amount on subscriptions and API calls to LLM services for this AI assisted coding. Worth every penny.
So while productivity increased manifold, absolute cost actually increased as well for me.
"I've had Claude Code write an entire unit/integration test suite in a few hours (300+ tests) for a fairly complex internal tool"
Did you catch what the author didn't mention? Are the tests any good? Are they even tests? I'm playing with Opus now (best entertainment for a coder), it is excellent at writing fake code and fabricating results. It wrote me a test that validates an extremely complex utility, and the test passed!
What was the test? Call utility with invalid parameters and check that there is an error.
I'm skeptical the extent to which people publishing articles like this use AI to build non-trivial software, and by non-trivial I mean _imperfect_ codebases that have existed for a few years, battle tested, with scars from hotfixes to deal with fires and compromises to handle weird edge cases/workarounds and especially a codebase where many developers have contributed to it over time.
Just this morning I was using Gemini 3 Pro working on some trivial feature, I asked it about how to go about solving an issue and it completely hallucinated a solution suggesting to use a non-existing function that was supposedly exposed by a library. This situation has been the norm in my experience for years now and, while this has improved over time, it's still very, very common occurrence. If it can't get these use cases down to an acceptable successful degree, I just don't see how much I can trust it to take the reins and do it all with an agentic approach.
And this is just a pure usability perspective. If we consider the economics aspect, none of the AI services are profitable, they are all heavily subsidized by investor cash. Is it sustainable long term? Today it seems as if there is an infinite amount of cash but my bet is that this will give in before the cost of building software drops by 90%.
Yeah, that's a huge pain point in LLMs. Personally, I'm way less impacted by them because my codebase is only minimally dependent on library stuff (by surface area) so if something doesn't exist or whatever, I can just tell the LLM to also implement the thing it hallucinated :P
These hallucinations are usually a good sign of "this logically should exist but it doesn't exist yet" as opposed to pure bs.
As an example I wanted a plugin for visual studio. In the past I would have spent hours on it or just not bothered but I used Claude code to write it, it isn’t beautiful or interesting code, it lacks tests but it works and saves me time. It isn’t worth anything, won’t ever be deployed into production, I’ll likely share it but won’t try to monetise it, it is boring ugly code but more than good enough for its purpose.
Writing little utility apps has never been simpler and these are probably 90% cheaper
I've had a couple of contracts now, where I get to fix everything for teams who vibe-coded their infrastructure. I'm not saying it isn't a speed-up for teams who already have a wealth of infra experience - but it's not a substitute for the years of infra experience such a team already has.
so what does this mean in practice? for people working on proprietary systems (cost will never go down) - the code is not on github, maybe hosted on an internal VCS - bitbucket etc. the agents were never trained on that code - yeah they might help with docs (but are they using the latest docs?)
for others - the agents spit bad code, make assumptions that don't exist, call api's that don't exist or have been deprecated ?
each of those you need an experienced builder who has 1. technical know-how 2. domain expertise ? so has the cost of experienced builder(s) gone down ? I don't think so - I think it has gone up
what people are vibecoding out there - is mostly tools / apps that deal in closed systems (never really interact with the outside world), scripts were ai can infer based on what was done before etc but are these people building anything new ?
I have also noticed there's a huge conflation with regards to - cost & complexity. zirp drove people to build software on very complex abstractions eg kubernetes, nextjs, microservices etc - hence people thought they needed huge armies of people etc. however we also know the inverse is true that most software can be built by teams of 1-3 people. we have countless proof of this.
so people think to reduce cost is to use a.i agents instead of addressing the problem head-on - built software in a simpler manner. will ai help - yeah but not to the extent of what is being sold or written daily.
This is doubtful and not what I've seen in over 30 years in the industry. People who are ashamed of their source code don't make it Open Source. In general, Open Source will be higher quality than closed source.
Sure, these days you will need to avoid github repositories made by students for their homework assignments. I don't think that's a problem.
All of the major model vendors are competing on how well their models can code. The key to getting better code out of the model is improving the quality of the code that it is trained on.
Filtering training data for high quality code is easier than filtering for high quality data if other types.
My strong hunch is that the quality of code being used to train current frontier models is way higher than it was a year ago.
just thinking from the finance world, in 2010 no knew how to program on the desk and no one knew sql, and even if they did the institutional knowledge to use the dev systems was not worth their time. So you had multiple layers of meetings and managers to communicate programs. As a result, anything small just didn't get done, and everything took time.
by 2020 most junior guys knew enough python to pick up some of the small stuff
in 2025 ai tools are good enough that they're picking up things that legit would have taken weeks to do in 2010 because of the processes around them not the difficulty and doing it in hours. A task that would take an hour to do used to take multiple meetings to properly outline to someone without finance knowledge and now they can do themselves in less time than it took to describe to a fresh cs grad.
Those tasks that junior traders/strats are able to do now that would have taken weeks or months to get into prod going through an it department i'm seeing cost drop 90% everyday right now. Which is good, it lets tech focus on tech and not learning the minutia of options trading in some random country
I haven’t experienced this at all. They can do okay with greenfield services (as the author mentioned). However it’s often not “extremely good”. It’s usually “passable” at best. It doesn’t save me any time either. I have to read and audit every line and change it anyway.
The tale goes like this: one day visual arts got commoditised to the point any given visual artwork could be obtained for virtually free digitally. This has been the case for centuries. The aural arts (see records of spoken poetry, podcasts, music) have been commoditised for a long time. Full commodisation might never been happen (ie you can still work in the field) but it is undeniable that it has had a massive impact in their respective fields. Getting a Picasso-like painting might not be quite possible but we are getting quite there, same with music.
The same is coming for devs.
Devving is still far away but it doesn't really take that much to produce a significant impact in the field. The percentage of devs who can be able to get late 10s salaries will be gradually diminishing over time. This is what early stage commodisation looks like.
No, no, and no.
I believe Betteridge's law of headlines [1] applies here:
No.
1. https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
I haven't written production code for the last 8 years, but has prior development experience for about 17 years (ranging from C++, full stack, .NET, PHP and bunch of other stuff).
I used AI at personal level, and know the basics. Used Claude/Github to me help fix and write some pieces of the code in languages I wasn't familiar with. But it seems like people talking and deploying large real world projects in short-"er" amount of time. An old colleague of mine whom I trust mentioned his startup is developing code 3x faster than we used to develop software.
Is there resource that explains the current best practices (presumably it's all new)? Where do I even start?
For the past few days I asked it to built a mu-recursive Ackermann function in Emacs Lisp (built on the primitive-recursive functions/operators, plus an extra operator - minimization). I said that the prime detector function it already built should be able to use the same functions/operators, and to rewrite code if necessary.
So far it has been unable to do this. If I thought it could but was stumbling over Emacs Lisp I might ask it to try in Scheme or Common Lisp or some other language. It's possible I'll get it to work in the time I have allotted from my daily free tier, but I have had no success so far. I am also starting with inputs to the Ackermann function of 0,0 - 0,1 - 1,0 - 1,1 to not overburden the system but it can't even handle 0, 0. Also it tries to redefine the Emacs Lisp keyword "and", which Emacs hiccups on.
A year ago LLMs were stumbling over Leetcode and Project Euler functions I was asking it to make. They seem to have gotten a little better, and I'm impressed Gemini 3 can handle, with help, primitive recursive functions in Emacs Lisp. Doesn't seem to be able to handle mu-recursive functions with minimization yet though. The trivial, toy implementations of these things. Also as I said, it tried to redefine "and" as well, which Emacs Lisp fell over on.
So it's a helpful helper and tool, but definitely not ready to hand things over to. As the saying goes, the first 90% of the code takes 90% of the time, and the last 10% of the code takes the other 90% of the time. Or the other saying - it's harder to find bugs than write code, so if you're coding at peak mental capacity, finding bugs becomes impossible. It does have its uses though, and has been getting better.
Lots of applications have a simple structure of collecting and operating data with fairly well documented business logic tying everything together. Coding outside of that is going to be more tricky.
And if agentic coding is so great then why are there so still so many awful spreadsheets that can't compete with Excel? Something isn't adding up quite as well as some seem to expect.
So yes, the cost of certain tasks may drop by 90% (though I think that's a high number still), certainly the cost of developing software overall has not dropped by 90%.
I might be able to whip up a script in 30 seconds instead of 30 minutes, but I still have to think of whether I need the script, what exactly it should do, what am I trying to build and how and why, how does it fit with all the requirements, etc. That part isn't being reduced by 90%.
However, the cost of software maintenance went up by 1000% . Lets hope you don't need to ever add a new business rule or user interface to your vibe coded software.
More sophisticated tools mean more refined products.
If an easier and cheaper method for working carbon fiber becomes broadly available, it won't mean you get less money; it means you'll now be cramming carbon fiber in the silverware, in the shoes, in baby strollers, EVERYWHERE. The cost of a carbon fiber bike will drop 90%, but teams will be doing a LOT more.
You could say the cost per line of code has dropped 90%, but the number of lines of code written will 100x.
But currently reproduceability, reliability, correctness, and consistency are lacking.
There's also meaningful domain variance.
And yet, the conclusion seems to be as if the answer is yes?
Until AI can work organizationally as opposed to individually it'll necessarily be restricted in its abilities to produce gains beyond relatively marginal improvements (Saved 20 hours of developer time on unit tests) for a project that took X weeks/months/years to work it's way through Y number of people.
So sure, simple projects, simple asks, unit tests, projects handled by small teams of close knit coworkers who know the system in and out and already have the experience to differentiate between good code and bad? I could see that being reduced by 90%.
But, it doesn't seem to have done much for organizational efficiency here at BigCo and unit tests are pretty much the very tip of a project's iceberg here. I know a lot of people are using the AI agents, and I know a lot of people who aren't, and I worry for the younger engineers who I'm not sure have the chops to distinguish between good, bad, and irrelevant and thus leave in clearly extraneous code, and paragraphs in their documents. And as for the senior engineers with the chops, they seem to do okay with it although I can certainly tell you they're not doing ten times more than they were four years ago.
I kinda rambled at the end there, all that to say... organizational efficiency is the bug to solve.
(It's very difficult, I believe the 2D interfaces we've had for the last 40 years or whatever are not truly meeting the needs of the vast cathedrals of code we're working in, same thing for our organizations, our code reviews, everything man)
Cars wont be cheap because bumper prices fell 90%
But....
Obviously AI is coming for the whole car so I will operate on tbe assumption 90% is coming. We will eventually be agentic orhcestra conductors.
But you need: a staff level engineer to guide it, great standardization and testing best practices. And yes in that situation you can go 10-50x faster. Many teams/products are not in that environment though.
What I see are salaries stagnating and opportunity for new niche roles or roles being redefined to have more technical responsibility. Is this not the future we all expected before AI hype anyway? People need to relax and refocus on what matters.
The gap between a demo and a product is still enormous.
An exception might be building something that is well specified in advance, maybe because it's a direct copy of existing software.
And obviously the cost of not upskilling in intricate technical details as much as before (aka staying at the high level perspective) will have to be paid at some point
Cost is a funny misnomer. The best code that's written is the code that doesn't need to be written, and doesn't have to be supported.
Being able to build different approaches to solving a problem quickly may turn out to be a lot more helpful than saving 90%.
Let's say it is complicated. But what is the better alternative when dealing with large software? To what point we can simplify it and not lose anything important?
What was the value add of those tests, when I tried this, AI would often re-write the code to make match its poorly written test.
- More engineers moving from employment to indie development.
- Less abandoned open source software.
- Indie developers, small teams, and open source software developers will be more able to catch up and better compete with tech giants.
I believe the AI agentic coders will threat tech giants more than it - collectively - threats software engineers.
Currently, I don't think so. Coding agents' performance generally depends on the quality of the model behind them. Running a powerful model is assets-dependent. Not everyone has the hardware and power to support Sonnet 4.5 or Gemini 3 even if they are open-source. So, before the top notch models can be deployed on personal computing devices, I would not say coding agents will threat any organization.
Opus 4.5 in particular has been a profound shift. I’m not sure how software dev as a career survives this. I have nearly 0 reason to hire a developer for my company because I just write a spec and Claude does it in one shot.
It’s honestly scary, and I hope my company doesn’t fail because as a developer I’m fucked. But… statistically my business will fail.
I think in a few years there will only be a handful of software companies—the ones who already have control of distribution. Products can be cloned in a few weeks now; not long until it’s a few minutes. I used to see a new competitor once every six months. Now I see a new competitor every few hours.
Are you shipping things you haven't reviewed at all, and pronouncing them high quality?
I find these threads baffling. I haven't seen a glut of new software anywhere. I certainly haven't seen a bunch of companies fixing the same bugs that have been sitting in their trackers for years. People keep telling me there's this deluge of LLM code happening, but it (the actual code) is all a secret and behind closed doors. Why in the world would you keep it a secret? Why would any multibillion dollar company that ships AI features have any known bugs left in their flagship products?
I haven't seen a difference anywhere when looking outwards. I personally find it useful, but I have to constantly force refactors and rearchitecting to make the code intelligible. When I add features, bugs get reinserted, refactors get reverted, and instrumentation silently disappears. If I don't do the constant refactors, I wouldn't even notice this was happening half the time.
They wont automate everything, but the bar for being able to produce working software will plummet.
The 90% cost reduction isn’t just about efficiency — it’s about access. If the barrier to shipping software drops this dramatically, we’re likely standing at the edge of a new wave of innovation driven not just by engineers, but by domain specialists who previously couldn’t justify the investment.
The most interesting takeaway here is that technical mastery may become less of the moat, while contextual and domain intelligence becomes the real differentiator. That flips the traditional power structure in tech.
2026 might really be the year where “build fast, throw away, rebuild smarter” becomes normal instead of reckless.
Curious to see how fast organizations adapt — and who gets left behind simply because they assumed disruption would arrive slower.
> isn’t just
How do you do fellow human
Can’t wait to debug all that stuff.
I ask it to do something, if it works, I keep it without looking at it. If it doesn't I look, recoil in horror, delete and rewrite myself.
It takes more time but seems to work for me.
I've no idea what's going on in the enterprise space, but in the small 1-10 employee space, absolutely
Only a miniscule part of the work is green-field development. Everything else is managing a mess.
If you can build it in a weekend so can I. So you're going to have to figure out bigger things to build.
The biggest bottleneck I have seen is converting the requirements into code fast enough to prove to the customer that they didn't give us the right/sufficient requirements. Up until recently, you had to avoid spending time on code if you thought the requirements were bad. Throwing away 2+ weeks of work on ambiguity is a terrible time.
Today, you could hypothetically get lucky on a single prompt and be ~99% of the way there in one shot. Even if that other 1% sucks to clean up, imagine if it was enough to get the final polished requirements out of the customer. You could crap out an 80% prototype in the time it takes you to complete one daily standup call. Is the fact that it's only 80% there bad? I don't think so in this context. Handing a customer something that almost works is much more productive than fucking around with design documents and ensuring requirements are perfectly polished to developer preferences. A slightly wrong thing gets you the exact answer a lot faster than nothing at all.
How good are tests written by AI, really? The junk "coverage" unit tests sure, but well thought out integration tests? No way. Testing code is difficult, some AI slop isn't going to make that easier because someone has to know the code and the infrastructure it is going in to and reason about all of it.
The thing is, writing code is just the first step on building software. You are reviewing what your AI generates, right? You will still be held responsible when it doesn't work. And you will have to maintain and support that code. That is, in my mind, also "building software".
This reminds me of the (amazing) Vim experts that zip around a codebase with their arcane keystrokes. I'm a main Vim user and I can't mimic a fraction of their power. It's mesmerizing to watch them edit files, it's as if their thoughs get translated into words on the screen.
I also know that editing is just the first step. If you skip the rest, you are being misled by an industry with vested interests.
as better engineers and better designers get more leverage with lower nuisance in the form of meetings and other people, they will be able to build better software with a level of taste and sophistication that wouldn't make sense if you had to hand type everything
I'd love to see someone do this, or a similar task, live on stream. I always feel like an idiot when I read things like this because despite using Claude Code a lot I've never been able to get anything of that magnitude out of it that wasn't slop/completely unusable, to the point where I started to question if I hadn't been faster writing everything by hand.
Claiming that software is now 90% cheaper feels absurd to me and I'd love to understand better where this completely different worldview comes from. Am I using the tools incorrectly? Different domains/languages/ecosystems?
Where I am, 3 year old is greenfield, and old and large is 20 years old and has 8million lines of nasty c++. I’ll have to wait a bit more I think …
I can’t see LLMs contributing to anything this size when they can’t remember what I said 4 messages ago
So the claim of massive cost reduction is just something the author made up (or hallucinated to use the lingo of the field)?
Seems like Betteridges law applies here.
0.1x engineering cost
It is throwaway software at best.
What AI did was to move the goalpost even further. Now you need to write exceptional software.
AI has also probably saved me 100 hours of repetitive work at this point and completely elimitated the need to rely on other people working on time consuming configuration tasks and back-and-forward which used to stall work for me since I am the kind of person who will work for 20 hours until something is finished without losing that much in productivity.
I should have stopped reading here. People who think that the time it takes to write some code is the only metric that matters are only marginally better than people who rank employees by lines of code.
I've only been working with AI for a couple of months, but IMHO it's over. The Internet Age which ran 30 years from roughly 1995-2025 has ended and we've entered the AI Age (maybe the last age).
I know people with little programming experience who have already passed me in productivity, and I've been doing this since the 80s. And that trend is only going to accelerate and intensify.
The main point that people are having a hard time seeing, probably due to denial, is that once problem solving is solved at any level with AI, then it's solved at all levels. We're lost in the details of LLMs, NNs, etc, but not seeing the big picture. That if AI can work through a todo list, then it can write a todo list. It can check if a todo list is done. It can work recursively at any level of the problem solving hierarchy and in parallel. It can come up with new ideas creatively with stable diffusion. It can learn and it can teach. And most importantly, it can evolve.
Based on the context I have before me, I predict that at the end of 2026 (coinciding with the election) America and probably the world will enter a massive recession, likely bigger than the Housing Bubble popping. Definitely bigger than the Dot Bomb. Where too many bad decisions compounded for too many decades converge to throw away most of the quality of life gains that humanity has made since WWII, forcing us to start over. I'll just call it the Great Dumbpression.
If something like UBI is the eventual goal for humankind, or soft versions of that such as democratic socialism, it's on the other side of a bottleneck. One where 1000 billionaires and a few trillionaires effectively own the world, while everyone else scratches out a subsistence income under neofeudalism. One where as much food gets thrown away as what the world consumes, and a billion people go hungry. One where some people have more than they could use in countless lifetimes, including the option to cheat death, while everyone else faces their own mortality.
"AI was the answer to Earth's problems" could be the opening line of a novel. But I've heard this story too many times. In those stories, the next 10 years don't go as planned. Once we enter the Singularity and the rate of technological progress goes exponential, it becomes impossible to predict the future. Meaning that a lot of fringe and unthinkable timelines become highly likely. It's basically the Great Filter in the Drake equation and Fermi paradox.
This is a little hard for me to come to terms with after a lifetime of little or no progress in the areas of tech that I care about. I remember in the late 90s when people were talking about AI and couldn't find a use for it, so it had no funding. The best they could come up with was predicting the stock market, auditing, genetics, stuff like that. Who knew that AI would take off because of self-help, adult material and parody? But I guess we should have known. Every other form of information technology followed those trends.
Because of that lack of real tech as labor-saving devices to help us get real work done, there's been an explosion of phantom tech that increases our burden through distraction and makes our work/life balance even less healthy as underemployment. This is why AI will inevitably be recruited to demand an increase in productivity from us for the same income, not decrease our share of the workload.
What keeps me going is that I've always been wrong about the future. Maybe one of those timelines sees a great democratization of tech, where even the poorest people have access to free problem solving tech that allows them to build assistants that increase their leverage enough to escape poverty without money. In effect making (late-stage) capitalism irrelevent.
If the rate of increasing equity is faster than the rate of increasing excess, then we have a small window of time to catch up before we enter a Long Now of suffering, where wealth inequality approaches an asymptote making life performative, pageantry for the masses who must please an emperor with no clothes.
In a recent interview with Mel Robbins in episode 715 of Real Time, Bill Maher said "my book would be called: It's Not Gonna Be That" about the future not being what we think it is. I can't find a video, but he describes it starting around the 19:00 mark:
https://podcasts.musixmatch.com/podcast/real-time-with-bill-...
Our best hope for the future is that we're wrong about it.