The guy from the story, it’s just another developer starting from a different trade, pretty normal across our history, musicians, lawyers that discovered that they were good at computers. The conclusion is flawed, not anyone can endure what this person did, sit at a terminal, going back and forward until something is finished. That’s what a SW dev does. My conclusion, many more people will discover that they are good at software, not everybody, but some of them will discover this new powers, thanks to a new lower barrier provided by LLM.
More like the inverse. No true Scotsman seeks to remove someone from belonging to a group to keep the group pure, because no true member of that group could act in such a way.
This is adding people to a group that they would otherwise be excluded from. It seeks to expand the definition of the group to include the outsiders.
It means specialization. When people with no software development experience but lots of experience in some other domain have the ability to create software that fits their individual needs, that's a recipe for an explosion in highly specialized tooling.
Lol no it doesn't you literally have it backwards - think about the trades, specifically construction, as low barrier to entry jobs and consider that houses/buildings are all different (not commodities).
Both can be true in homes being unique while also functionally being like commodities. Whether a home or a spec home or tract home the pricing is based similarly to sports stats and no matter how one-of-a-kind a home is a mortgage on such a home can then be packaged with a bunch of other homes into a bond where bond investors will look at the stats of the combined homes and who the borrowers are.
New multifamily construction in the US that has to undergo design review is arguably fairly custom in that each site will have different requirements. I think it's fair to say that commoditization is a spectrum?
Lol you think developers aren't already commodities? You joking?
edit: i love how this is getting downvotes but no further responses. y'all are in denial. let me ask you this: why is the most common interview loop round a generic LC round? lolol
"Lol", do you think in lols or do you ever sit and consider something more deeply? Or maybe you think adding a lol makes the other side's argument ridiculous and yours stronger?
Skipping the lols, here's the answer to your question: doesn't matter if developers "are already commodities" to some degree.
First, because that degree is small, else developers wouldn't command such high salaries relative to other trades. So they might be commoditized compared to surgeons, but not at all compared to most office or blue collar trades.
Second, even if they are commoditized to some degree, the argument is that AI will bring further commodification. Not that it will introduce the first and foremost case of commodification in the developing world.
> developers wouldn't command such high salaries relative to other trades.
lololol something can be a commodity and still expensive. to wit: have you heard of this thing called oil which is recently very expensive?
> do you think in lols or do you ever sit and consider something more deeply?
i think deeply enough to recognize when someone's reasoning is so flawed they should've almost immediately reconsidered their claim upon conceiving of it. and then i laugh out loud (at them) when they didn't. occasionally many many times.
Let's take the metaphor of writing. Would we say this guy is just a writer who started from another trade? No. Writing is something that used to require experts (scribes) and that now anyone can do and is just a normal part of doing any work.
Developers are scribes - we have sacred knowledge that is now being democratized because everyone can do it due to good enough tools. As a result, we won't be needed much going forward.
> Developers are scribes - we have sacred knowledge that is now being democratized because everyone can do it due to good enough tools. As a result, we won't be needed much going forward.
The ability to solve problems is what’s important. Not your ability to remember things or to hold sacred knowledge.
This. Software development probably requires some of the least boilerplate memorization in all of STEM. Deductive reasoning and imagination are far more important than being flexing that you’ve committed quicksort to memory.
Writing is a tool, a technology. Much like hammers or saws, which are also commodified. And even though anyone can go buy a saw, not everyone is a carpenter.
Is it knowing how to write a regex without a reference, or maybe implementing a distributed ec postgres cluster using bash, ooh how about writing a minimum cnn in C for edge classification ooohhh wooowee…
Ever worked construction? There’s hammer swingers that need one swing per nail and never miss. Or plasterers that make chalk look like marble. How about a high voltage lineman that can switch a 20kv oil-cooled transformer in less than 15 minutes to get the power to the school back on
No different from any tradesman - we’re not special
I've more or less accepted this, and I think my future is in making software more resilient, secure, and fault tolerant. These people will likely want to scale these solutions up, tie different solutions together, and generally make their lives increasingly difficult. Often without realizing it.
My experience is that Claude starts to make quite a mess in this context, and it'll often cause as many problems as it solves unless you have the technical and domain knowledge to redirect and correct it frequently. Perhaps training will solve this, and it'll certainly get better, but I'm not sure how far it'll go and how fast.
My gut feeling is that software will only become more ambitious and interface with hardware and other systems in increasingly sophisticated ways. Things that seemed infeasible due to time and cost constraints will be on the table. It'll reveal new challenges, I think. I have a feeling it'll be humans with deep technical skills who are at the forefront of solving those challenges for a while yet.
Not claiming I have the skills and to be one of those people, just that it's where I'm pushing my career at the moment.
I'm stoked that people like this have the resources and newfound capabilities to create solutions like this. The reality is that previously, many people have been underserved due to the economics of software and inherent risks of trying things like this as a smaller business owner. So this is great. We can find more ways that software can be valuable, and people can do their jobs better in ways they've literally only imagined before. It's great.
What could happen is a reduction in the amount of programs used, with a smaller set of more sophisticated programs doing more work. This maps to what we saw pre-industrial revolution: lots of small family operations doing menial manufacturing work (woodworking, textiles, cooking). This got replaced by large factories. A smaller amount of companies producing the a larger volume of goods. With AI, a smaller group of engineers could handle more local complexity, thus allowing more sophisticated, general purpose software to be created, deleting the sea of small pieces of software we have today.
Will this means many will be jobless? No, they would do other things. They'd be using this software to support society, operating at a high level. Think low-code, but incredibly complex stuff; just not raw code anymore. Instead of making circuit boards out of descrete components, you now slap a few ICs on a board with some supporting passives and the work is then all done in software. Engineers use more high-level components rather then welding and machinijng things from scratch; you buy T-slot profiles and bolts rather than casting and milling steel from billets.
So the job of programmer may disappear simmilar to how we don't have bakers anymore, baking is done in factories, operated by a small staff. Current-day programmers will then increasingly shift to whatever high-level constructs we'll come up with, this high level work will be supported by the base infrastructure that those who still touch raw code will build.
From what I have observed in my team, the opposite is occurring. Everyone is just making their own software because the barriers are so low. There is a lot less sharing and coordination going on, and the bottleneck moved to having the hardware available to run it all, so now we’re spending a lot more money on compute.
Factories benefit from economies of scale that favour centralization.
I think smaller groups handling more complexity is on point. But that's because each group will build their own bespoke factory catered to their exact needs.
I very fully expect a mass proliferation of custom programs rather than standardizing on a common set that groans under the weight of being so general to support all use cases.
You assume that the agents can produce okayish software that isn't very resilient, but that's not quite what we're seeing. Remember Anthropic's attempt to have agents write a C compiler (which isn't a super-complicated task by any means). Despite preparation work that is well beyond what most software can have (specs available to the agent and that the model trained on, thousands of human-written tests available to the agent and that the model trained on, and a human-written reference implementation available to the agent and that the model trained on) the agents still failed to converge. In other words, under conditions that are so favourable as to be unrealistic for almost any kind of real software, the AI agents couldn't even produce so much a workable C compiler. And this is what I also see: the agents take the code in a direction that doesn't converge, let alone make it resilient.
Are we sure Claude Scale™ won’t appear next month? A specialist agent that turns your vibe coded mess into a production grade scaled solution on their infrastructure.
Expect anthropic to want to capture more of the supply chain over time
If they could they would, and if they can they will. Maybe it will appear next month, and maybe 5 years from now, and we don't know which of these is more likely. But I think that if agents could actually produce good, reliable software than can evolve over time, there's little they couldn't do even beyond software. So it won't be (just) the software developers being replaced, but also software users.
Yeah which is why the solution has to be legislative. These companies are trying to take over the entire industry and even if they won’t have as good a solution as someone who only focuses on one thing they have the capital, distribution and name recognition to kill any upstarts
scaling these solutions will prove to be counter productive. If you are thinking of scaling you are still trapped in the current paradigm. This plumber guy is only unique in that he read the news and pushed a little harder to see what the actual f is going on. In the days that come, every single person who is serious about their job will do and experience the same thing.
I'm not saying this particular individual is wrong in trying to build his solution to the market. Maybe there is some VC money to be made in this moment. But as AI in the workplace gets normalised, most people will either come up with solutions for their problems, or they will ask someone they know to help them with this.
scale will only matter if you are explicitly building a platform. That will still require real software engineering skills.
As for hardware interfacing, if I am not mistaken, almost all companies selling hardware right now still behave like babies when it comes to users getting access to the software inside it. They void warrantees, sue them, so on etc. For ambitious user driven software innovations in the hardware space the companies should open up their interfaces. I don't see this happening at all not only because of the companies' greed but also for regulatory and safety reasons.
I had to strike more of a balance between moving quickly and focusing strictly on resilience. The difference moving forward would be that the features already exist, and my job will increasingly be focused on ensuring they work properly, and the underlying systems supporting features are consistent, cohesive, and not duct taped together like an LLM built it.
It reminds me a lot of my early career spent remediating offshored PHP applications.
I absolutely love this, because to me, this is what software development should be about, solving actual problems and providing faster calculations, improving the workflow for people.
It does strike me as a little odd that they didn't hire a developer earlier and got the code written. Sitting back and waiting for someone to drop by and present a solution is a little naive, but it's also the world we built in the IT industry over the past 20 years. When I started my first job, we frequently had customers ask for bespoke solution, most of which was small one week to a few months of work. Multiple co-workers in the mid 2000s has side businesses, where they did contract development, most of which was these types of small one off solutions. Most of the software companies, in my area, that did these types of jobs are all gone now.
If AI accidentally created an environment where people can once again solve small programming problems on their own and massively improve the workflows I'm all for it. Serves the industry right for abandoning these customers.
Yeah the whole tech world did a weird side quest over the past 20 or so years huffing its own farts due to how the internet/adtech/etc sucked all the air out of everything else tech related. And the economy as a whole.
It also coincided with the hollowing out and offshoring of practically all US industrial and manufacturing capability.
I will be very happy if the result of AI means we go back to how things should actually be - where technology/IT is used to support real world things and acts as a backstage enabler to get shit done. Not the main event.
I often said since the early 00’s my dream would be to have made enough money in the insanely stupid “tech for tech sake” world to go back to just being one of a few “IT guys” supporting a factory and keeping the machines running. These jobs of course exist, but due to tech salaries very few small manufacturing businesses could support hiring such a person.
There is now a generation or two of technologists who don’t understand that the job isn’t to learn the latest hot web framework or yammer on about best practices or whatever. It’s to support a business in shipping actual products to customers.
In my experience, I've worked with a number of people in non-tech industries who tried to pivot their company into software, and a huge obstacle was that ultimately the code became unmaintainable.
Maybe they didn't have the expertise to pick a software stack that would serve them in the long run, or they just didn't have the budget to hire a SWE or team full time, or their contractor team just wasn't super invested in the project.
So tech people look at "vibeslop" as unmaintainable technical debt, but they ignore that in a lot of situations their own salary is what makes the tech debt unmaintainable. Maybe that's uncharitable, but I do think many techs are very far removed from the "solve a problem and then dogfood it" cycle
I love it too. It's a really positive aspect of AI. And it's NOT because it "takes jobs away from developers". In this case, there was NO (professional/career) developer and NO software product focused on what this guy did.
We've long made fun of excel-jockeys getting carried away with VBA, but they came into being because engaging with turgid and expensive software companies to do important but small jobs was such a pain in the ass. This is the start of a new era, and while I am sure we're going to see some wild fiascos, it is a move in the right direction for people that need to solve problems with computers.
You’re telling me that salesforce CAN’T actually solve every problem in the world more simply and efficiently than just building a tool to fit the job??
The software industry has just abstracted every problem to the point of being unable to solve anything.
Trades / SWE overlap is interesting as I think they are analogous to each other.
I went to college with a lot of actual engineers - mechanical, electrical, chemical, etc. In those fields you are designing products and then engineering processes to output a cog of some sort (drug, car, GPU, iPhone, etc) in the thousands to millions.
In our fields as SWEs, a lot of our job it's like the trades going into a house to install HVAC, fix a burst pipe, upgrade a circuit breaker, replace a furnace, etc. No two setups are exactly alike, no requirements are exactly alike, etc.
Even in the age of LLMs I think the industry remains more artisanal than engineering. And that's not a knock on us, I think it's because what we do is essentially automate business processes.. and no two businesses are alike. I don't think LLMs replace the role, it just makes parts of our job faster. The mindset of how you automate something doesn't generally exist in the minds of people who want the automation.
Here's what I find difficult to reconcile with my own experience. I've been using Codex in anger for the past 2 months or so (with gpt5.3-codex and then gpt5.4) on projects of different complexity. It is quite good at debugging, but the (non-trivial) code it produces is really bad. And I don't mean bad stylistically, but bad in the sense that Codex clearly won't be able to maintain it for long (which is how Anthropic's C compiler experiment failed) because it uses an approach of "success at all costs" where it always prefers fixes that treat the symptom rather than going back and rethinking the architecture as features are added.
So the options are: 1. the program involved here is really trivial, 2. it hasn't evolved long enough for the agent to fail at evolution, or 3. others are not seeing what I'm seeing.
It is weird. I've had maintainable solutions on non-trivial code, but it does kind of require babysitting. Planning documents and detailed specs help. You get a feel for where the agent will want to take a shortcut and can devise ways to navigate around that.
I also find Go works really well, and generally stays, if not exceptional, than at least maintainable.
I've also enjoyed using OCaml, but I will say that I found the single worst function I've ever seen in a codebase in vibecoded OCAML.
You might just try asking - "hey I'm having trouble keeping maintainable codebases - how can I structure this project in a way where the code will be stable long term".
Sometimes getting the "software architect" role into the agent context is all it takes.
This tracks with my own experience. I have to watch what the LLM does in response to any given ask, especially when adding new features to an existing system, because it will do things a different way every time until it no longer knows what patterns to follow.
For better or for worse, when everyone is a "potential software founder" nobody is because your potential customers can just use AI the same way you did.
I think there are many moats that non-experts won't attempt to cross even with AI assistance.
For example, we've built in a lot of complexity to areas like authentication. And for good reason. It's like electrical code. I'd pay good money to watch a muggle attempt to configure OIDC infrastructure. Even with the AI explaining everything to you, it's too much information to digest at once. You'd need an entire afternoon just to wrap your head around the idea of asymmetric cryptography. That's a lot of time not spent doing the thing your business is actually about.
Software development usability has always been measured in mean time before black-box failure: something misbehaves that the person can't fix or understand.
LLM's shorten that time for every application and every user, but particularly for users from professions that haven't built modeling or debugging skills because they rely on physical reality - like pipes fitting or process supervision - to weed out non-performers.
Hiring for LLM-enhanced work should focus on debugging skills in unknown situations.
Except I find that agents are much better at debugging than writing code. When the code gets to the state where the agents can no longer debug it and keep it running (as happened in Anthropic's failed C compiler attempt) humans will likely not be able to save the situation (in an efficient way). And without careful human supervision from the start, the code ultimately gets to that place.
For decades, employees have been developing tools using whatever was available to them, and in most cases, this was limited to Excel macros.
AI provides access to much better tools for testing and quickly experimenting with new ideas.
The only ones who should be worried are companies that charge millions for four junior developers and an agile coach, and deliver more PowerPoints than code (I’m looking at you, Capgemini).
It's a really interesting case study, but the summary seems to lean into the AI hype to an extent that borders on lying.
> His fabrication shop uses it daily, and he built the entire thing in 8 weeks. During those 8 weeks he also had to learn everything about Claude Code, the terminal, VS Code, everything.
I don't see how he can give this summary with a straight face after posting the interview that CLEARLY contradicts it.
In the interview the engineer says "When Claud Code came out almost a year ago, I started dabbling with web based tools ..." and "When it first came out I had so many ideas and tried all these different things", so he had clearly already used extensively it for a year. I would also guess the engineer was somewhat technically minded from the get-go, since he claims he was "really good with excel" before starting with Claude Code, but that is beside the point.
The interviewer later asks "How much of those 8 weeks was learning Claude Code versus actually building the thing?", and the interviewee answers "Well, I started Claude Code when it first came out so the learning curve has really gone down for me now..." and then trails off to a different subject. Which further confirms that the summary in the post is false.
It really seems like the engineer has spent the year prior learning Claude Code and then spent 8 weeks on solely building this specific application.
The interviewer also claims "This would normally have taken a developer a year to build", which seems really unsubstantiated. It's of course hard to judge without all the details, but looking at the short demo in the video, 8 weeks of regular development time from a somewhat experienced developer doesn't seem too far fetched if the objective is "don't make it pretty, just make it work".
As I said, it's a really interesting case study about a paradigm shift in how software is developed, and it's clear this app would never have existed without Claude Code. So I don't really see the need for the blatant lying.
I've noticed even experienced engineers have started overestimating how long things would take to build without AI. Believe it or not we coded before AI and not everything took years all the time.
We’ve all worked on projects where it took months to get requirements from the business. Sometimes to see the project cancelled after months of sitting around waiting for them to decide on things.
Coding has never been the roadblock in software. Indeed don’t we experience this now with ai? Vibe code a basics idea then discover the things we didn’t consider. Try to vibe that and the code base quickly gets out of hand. Then we all discover “spec driven development” SDD and in turn discover thinking of specifying everything our selves is an even bigger of PITA?
I feel both great and awful about this. For over a decade I’ve said that nearly anyone that uses a computer could benefit from some programming understanding. A little bit can go a long way to solving problems like this. Problems that collectively slow down and block the ambitions of a huge number of people worldwide.
But instead we’ve found a way to circumvent the process. Losing the understanding of your own problem and the new ideas that come off the back of it.
I’m reminded of the story that NASA had a research project to make pens that would work in space, and Roscosmos just used pencils. I always thought NASA came off worse in that anecdote, but I wonder what they learnt while making the pen…
Both agencies used pencils, but they were problematic because the graphite could break off / float around / cause shorts.
The space pen was developed by Fisher independently of NASA. NASA bought 400 of them for $2.39 each. The Roscosmos later bought 100 for the same price.
Firstly, pencils in space pose serious risks. Pencils produce dust, graphite dust is conductive, and won't settle down in microgravity. They were used early on, but both space agencies phased them out when they realized the risks. After that, they first moved to grease pencils, which kind of suck for normal writing.
NASA didn't research how to make pens that work in space, an American private company did it on their own initiative and money. Then they sold pens to NASA for cheap, and marketed the same pens to people not in space for a lot of money and made a nice profit.
Today, both Roscosmos and NASA use the same pens, bought from Fisher.
I agree, my immediate reaction was that mechanical engineer is not a trades worker.
I majored in mechanical engineering at college. We had a required programming class. A lot of people like myself already knew how to program before we took the class too. We also had a required electronics class. My experience is that most folks with CS degrees would be surprised by the breadth of what mechanical/aerospace/chemical/etc. engineers learn.
"Mechanical engineer uses code to improve engineering process". Okay, this has been going on forever. Other engineering disciplines and various fields using software to solve problems. Programming doesn't exist in a vacuum of theory.
As part of my "well shit what's next" arc I've been checking out machine shops in my area. By and large they are dumb manual 30 year contracts or highly automated job shops..
And the owners of those job shops aim for 3 shifts per worker via automation, and mash their own software with AI already. They are ruthless at cost cutting and automation and AI tools are perfect for them.
Unfortunately the vibe I get talking to them is essentially a triumphant "why would I need you, I have AI" or "yeah you're screwed".
I can't blame them for being served expensive barely functional crap SaaS or ERP software for ages, but I was not expecting to be viewed as part of the problem coming from a robotics, automation, and optimization background myself. It's just all a block of overpaid swindlers to them.
I have always wanted to get back to the metal, and the rapidly changing software landscape seemed like a good kick into it, but it might also mean a complete lack of opportunity
The general approval the average person has for tech/software workers has declined precipitously over the last decade (IMO for some pretty good reasons, as an overall industry we've done a lot of societal harm) which just adds to how cosmically funny it is that as a group we are likely to experience one of the quickest mass career disruptions from AI.
People like this will create a net increase in software jobs. Once his software makes enough money so he doesn't have to sit in front of a computer, he will employ someone. It will initially be a gig fixing slop. https://www.slater.dev/2025/09/about-that-gig-fixing-vibe-co...
People in the trades have a ruthless pragmatism that SV has forgotten.
I think it's awesome that AI is enabling this. I think the the future of software engineering is in helping make this kind of thing resilient and removing the fragility that AI generated code always seems to inject
I had a similar “oh wow this has normalised fast” a few weeks back when someone was like “oh it just takes all the human written recipe data and normalises it?” and I smiled at the “just”. Literally a nightmare problem only a few short years ago.
I also caught this but then figured 10m may not be the typical drawing time. 10m -> 1m means 10x faster. 5m = 300s alas 3s/drawing. So maybe it only tool 30s/drawing previously. (Unlikely.)
But even then, it also says 5m can save days of work. Days is minimum 2days, or 16h, or 960s. That’s not 10x faster as previously stated, but 192x faster.
The guy from the story, it’s just another developer starting from a different trade, pretty normal across our history, musicians, lawyers that discovered that they were good at computers. The conclusion is flawed, not anyone can endure what this person did, sit at a terminal, going back and forward until something is finished. That’s what a SW dev does. My conclusion, many more people will discover that they are good at software, not everybody, but some of them will discover this new powers, thanks to a new lower barrier provided by LLM.
You are 100% correct. That guy just did not know that he has developer soul.
This sounds like "no true Scotsman..."
More like the inverse. No true Scotsman seeks to remove someone from belonging to a group to keep the group pure, because no true member of that group could act in such a way. This is adding people to a group that they would otherwise be excluded from. It seeks to expand the definition of the group to include the outsiders.
>thanks to a new lower barrier provided by LLM.
New lower barrier means commodification.
It means specialization. When people with no software development experience but lots of experience in some other domain have the ability to create software that fits their individual needs, that's a recipe for an explosion in highly specialized tooling.
Lol no it doesn't you literally have it backwards - think about the trades, specifically construction, as low barrier to entry jobs and consider that houses/buildings are all different (not commodities).
Both can be true in homes being unique while also functionally being like commodities. Whether a home or a spec home or tract home the pricing is based similarly to sports stats and no matter how one-of-a-kind a home is a mortgage on such a home can then be packaged with a bunch of other homes into a bond where bond investors will look at the stats of the combined homes and who the borrowers are.
It's difficult to appreciate just how quickly and obviously low-barrier jobs sort people by ability and aptitude.
> consider that houses/building are all different (not commodities)
The vast majority of US housing construction is tract housing, which is a commodity. In the EU, flats, which are also commodities.
Citation please. Certainly I'm aware of cookie cutter developments but "vast majority" seems like an exaggeration to me.
”The current market share of custom-built homes is approximately 19% of total single-family starts”
https://www.nahb.org/blog/2025/08/custom-home-building-grows...
New multifamily construction in the US that has to undergo design review is arguably fairly custom in that each site will have different requirements. I think it's fair to say that commoditization is a spectrum?
tract != multifamily
Lol,no.
Houses/buildings are each isolated physical structures.
Software is trivially and instantly replicated, and the same software can serve millions.
Also, even in your example you're just the commodified roofer or construction worker. Not the non-commodified house.
Apprentices are considered commodities here
Lol you think developers aren't already commodities? You joking?
edit: i love how this is getting downvotes but no further responses. y'all are in denial. let me ask you this: why is the most common interview loop round a generic LC round? lolol
"Lol", do you think in lols or do you ever sit and consider something more deeply? Or maybe you think adding a lol makes the other side's argument ridiculous and yours stronger?
Skipping the lols, here's the answer to your question: doesn't matter if developers "are already commodities" to some degree.
First, because that degree is small, else developers wouldn't command such high salaries relative to other trades. So they might be commoditized compared to surgeons, but not at all compared to most office or blue collar trades.
Second, even if they are commoditized to some degree, the argument is that AI will bring further commodification. Not that it will introduce the first and foremost case of commodification in the developing world.
> developers wouldn't command such high salaries relative to other trades.
lololol something can be a commodity and still expensive. to wit: have you heard of this thing called oil which is recently very expensive?
> do you think in lols or do you ever sit and consider something more deeply?
i think deeply enough to recognize when someone's reasoning is so flawed they should've almost immediately reconsidered their claim upon conceiving of it. and then i laugh out loud (at them) when they didn't. occasionally many many times.
I was pointing out the reference wasn't pointing at the house but the apprentice.
Lower barrier to entry means the developers are even more interchangeable than now.
Let's take the metaphor of writing. Would we say this guy is just a writer who started from another trade? No. Writing is something that used to require experts (scribes) and that now anyone can do and is just a normal part of doing any work.
Developers are scribes - we have sacred knowledge that is now being democratized because everyone can do it due to good enough tools. As a result, we won't be needed much going forward.
> Developers are scribes - we have sacred knowledge that is now being democratized because everyone can do it due to good enough tools. As a result, we won't be needed much going forward.
The ability to solve problems is what’s important. Not your ability to remember things or to hold sacred knowledge.
This. Software development probably requires some of the least boilerplate memorization in all of STEM. Deductive reasoning and imagination are far more important than being flexing that you’ve committed quicksort to memory.
If that were true, industry interview processes would be very different.
Writing is a tool, a technology. Much like hammers or saws, which are also commodified. And even though anyone can go buy a saw, not everyone is a carpenter.
I am not a carpenter; I use a saw at least once a month.
> Writing is a tool, a technology.
Like paint, it can be used as a tool, to paint your house, or as a craft and artform, to paint the Rouen Cathedral.
What is this “sacred knowledge?”
Is it knowing how to write a regex without a reference, or maybe implementing a distributed ec postgres cluster using bash, ooh how about writing a minimum cnn in C for edge classification ooohhh wooowee…
Ever worked construction? There’s hammer swingers that need one swing per nail and never miss. Or plasterers that make chalk look like marble. How about a high voltage lineman that can switch a 20kv oil-cooled transformer in less than 15 minutes to get the power to the school back on
No different from any tradesman - we’re not special
I've more or less accepted this, and I think my future is in making software more resilient, secure, and fault tolerant. These people will likely want to scale these solutions up, tie different solutions together, and generally make their lives increasingly difficult. Often without realizing it.
My experience is that Claude starts to make quite a mess in this context, and it'll often cause as many problems as it solves unless you have the technical and domain knowledge to redirect and correct it frequently. Perhaps training will solve this, and it'll certainly get better, but I'm not sure how far it'll go and how fast.
My gut feeling is that software will only become more ambitious and interface with hardware and other systems in increasingly sophisticated ways. Things that seemed infeasible due to time and cost constraints will be on the table. It'll reveal new challenges, I think. I have a feeling it'll be humans with deep technical skills who are at the forefront of solving those challenges for a while yet.
Not claiming I have the skills and to be one of those people, just that it's where I'm pushing my career at the moment.
I'm stoked that people like this have the resources and newfound capabilities to create solutions like this. The reality is that previously, many people have been underserved due to the economics of software and inherent risks of trying things like this as a smaller business owner. So this is great. We can find more ways that software can be valuable, and people can do their jobs better in ways they've literally only imagined before. It's great.
What could happen is a reduction in the amount of programs used, with a smaller set of more sophisticated programs doing more work. This maps to what we saw pre-industrial revolution: lots of small family operations doing menial manufacturing work (woodworking, textiles, cooking). This got replaced by large factories. A smaller amount of companies producing the a larger volume of goods. With AI, a smaller group of engineers could handle more local complexity, thus allowing more sophisticated, general purpose software to be created, deleting the sea of small pieces of software we have today.
Will this means many will be jobless? No, they would do other things. They'd be using this software to support society, operating at a high level. Think low-code, but incredibly complex stuff; just not raw code anymore. Instead of making circuit boards out of descrete components, you now slap a few ICs on a board with some supporting passives and the work is then all done in software. Engineers use more high-level components rather then welding and machinijng things from scratch; you buy T-slot profiles and bolts rather than casting and milling steel from billets.
So the job of programmer may disappear simmilar to how we don't have bakers anymore, baking is done in factories, operated by a small staff. Current-day programmers will then increasingly shift to whatever high-level constructs we'll come up with, this high level work will be supported by the base infrastructure that those who still touch raw code will build.
From what I have observed in my team, the opposite is occurring. Everyone is just making their own software because the barriers are so low. There is a lot less sharing and coordination going on, and the bottleneck moved to having the hardware available to run it all, so now we’re spending a lot more money on compute.
Factories benefit from economies of scale that favour centralization.
I think smaller groups handling more complexity is on point. But that's because each group will build their own bespoke factory catered to their exact needs.
I very fully expect a mass proliferation of custom programs rather than standardizing on a common set that groans under the weight of being so general to support all use cases.
You assume that the agents can produce okayish software that isn't very resilient, but that's not quite what we're seeing. Remember Anthropic's attempt to have agents write a C compiler (which isn't a super-complicated task by any means). Despite preparation work that is well beyond what most software can have (specs available to the agent and that the model trained on, thousands of human-written tests available to the agent and that the model trained on, and a human-written reference implementation available to the agent and that the model trained on) the agents still failed to converge. In other words, under conditions that are so favourable as to be unrealistic for almost any kind of real software, the AI agents couldn't even produce so much a workable C compiler. And this is what I also see: the agents take the code in a direction that doesn't converge, let alone make it resilient.
Are we sure Claude Scale™ won’t appear next month? A specialist agent that turns your vibe coded mess into a production grade scaled solution on their infrastructure.
Expect anthropic to want to capture more of the supply chain over time
If they could they would, and if they can they will. Maybe it will appear next month, and maybe 5 years from now, and we don't know which of these is more likely. But I think that if agents could actually produce good, reliable software than can evolve over time, there's little they couldn't do even beyond software. So it won't be (just) the software developers being replaced, but also software users.
Yeah which is why the solution has to be legislative. These companies are trying to take over the entire industry and even if they won’t have as good a solution as someone who only focuses on one thing they have the capital, distribution and name recognition to kill any upstarts
scaling these solutions will prove to be counter productive. If you are thinking of scaling you are still trapped in the current paradigm. This plumber guy is only unique in that he read the news and pushed a little harder to see what the actual f is going on. In the days that come, every single person who is serious about their job will do and experience the same thing.
I'm not saying this particular individual is wrong in trying to build his solution to the market. Maybe there is some VC money to be made in this moment. But as AI in the workplace gets normalised, most people will either come up with solutions for their problems, or they will ask someone they know to help them with this.
scale will only matter if you are explicitly building a platform. That will still require real software engineering skills.
As for hardware interfacing, if I am not mistaken, almost all companies selling hardware right now still behave like babies when it comes to users getting access to the software inside it. They void warrantees, sue them, so on etc. For ambitious user driven software innovations in the hardware space the companies should open up their interfaces. I don't see this happening at all not only because of the companies' greed but also for regulatory and safety reasons.
What were you doing before, if not making resilient software?
I find that scalability is usually overblown because computers are fast now, which is not to say you shouldn't make it run fast on one computer.
I had to strike more of a balance between moving quickly and focusing strictly on resilience. The difference moving forward would be that the features already exist, and my job will increasingly be focused on ensuring they work properly, and the underlying systems supporting features are consistent, cohesive, and not duct taped together like an LLM built it.
It reminds me a lot of my early career spent remediating offshored PHP applications.
I absolutely love this, because to me, this is what software development should be about, solving actual problems and providing faster calculations, improving the workflow for people.
It does strike me as a little odd that they didn't hire a developer earlier and got the code written. Sitting back and waiting for someone to drop by and present a solution is a little naive, but it's also the world we built in the IT industry over the past 20 years. When I started my first job, we frequently had customers ask for bespoke solution, most of which was small one week to a few months of work. Multiple co-workers in the mid 2000s has side businesses, where they did contract development, most of which was these types of small one off solutions. Most of the software companies, in my area, that did these types of jobs are all gone now.
If AI accidentally created an environment where people can once again solve small programming problems on their own and massively improve the workflows I'm all for it. Serves the industry right for abandoning these customers.
Yeah the whole tech world did a weird side quest over the past 20 or so years huffing its own farts due to how the internet/adtech/etc sucked all the air out of everything else tech related. And the economy as a whole.
It also coincided with the hollowing out and offshoring of practically all US industrial and manufacturing capability.
I will be very happy if the result of AI means we go back to how things should actually be - where technology/IT is used to support real world things and acts as a backstage enabler to get shit done. Not the main event.
I often said since the early 00’s my dream would be to have made enough money in the insanely stupid “tech for tech sake” world to go back to just being one of a few “IT guys” supporting a factory and keeping the machines running. These jobs of course exist, but due to tech salaries very few small manufacturing businesses could support hiring such a person.
There is now a generation or two of technologists who don’t understand that the job isn’t to learn the latest hot web framework or yammer on about best practices or whatever. It’s to support a business in shipping actual products to customers.
In my experience, I've worked with a number of people in non-tech industries who tried to pivot their company into software, and a huge obstacle was that ultimately the code became unmaintainable.
Maybe they didn't have the expertise to pick a software stack that would serve them in the long run, or they just didn't have the budget to hire a SWE or team full time, or their contractor team just wasn't super invested in the project.
So tech people look at "vibeslop" as unmaintainable technical debt, but they ignore that in a lot of situations their own salary is what makes the tech debt unmaintainable. Maybe that's uncharitable, but I do think many techs are very far removed from the "solve a problem and then dogfood it" cycle
I love it too. It's a really positive aspect of AI. And it's NOT because it "takes jobs away from developers". In this case, there was NO (professional/career) developer and NO software product focused on what this guy did.
We've long made fun of excel-jockeys getting carried away with VBA, but they came into being because engaging with turgid and expensive software companies to do important but small jobs was such a pain in the ass. This is the start of a new era, and while I am sure we're going to see some wild fiascos, it is a move in the right direction for people that need to solve problems with computers.
You’re telling me that salesforce CAN’T actually solve every problem in the world more simply and efficiently than just building a tool to fit the job??
The software industry has just abstracted every problem to the point of being unable to solve anything.
Trades / SWE overlap is interesting as I think they are analogous to each other.
I went to college with a lot of actual engineers - mechanical, electrical, chemical, etc. In those fields you are designing products and then engineering processes to output a cog of some sort (drug, car, GPU, iPhone, etc) in the thousands to millions.
In our fields as SWEs, a lot of our job it's like the trades going into a house to install HVAC, fix a burst pipe, upgrade a circuit breaker, replace a furnace, etc. No two setups are exactly alike, no requirements are exactly alike, etc.
Even in the age of LLMs I think the industry remains more artisanal than engineering. And that's not a knock on us, I think it's because what we do is essentially automate business processes.. and no two businesses are alike. I don't think LLMs replace the role, it just makes parts of our job faster. The mindset of how you automate something doesn't generally exist in the minds of people who want the automation.
Here's what I find difficult to reconcile with my own experience. I've been using Codex in anger for the past 2 months or so (with gpt5.3-codex and then gpt5.4) on projects of different complexity. It is quite good at debugging, but the (non-trivial) code it produces is really bad. And I don't mean bad stylistically, but bad in the sense that Codex clearly won't be able to maintain it for long (which is how Anthropic's C compiler experiment failed) because it uses an approach of "success at all costs" where it always prefers fixes that treat the symptom rather than going back and rethinking the architecture as features are added.
So the options are: 1. the program involved here is really trivial, 2. it hasn't evolved long enough for the agent to fail at evolution, or 3. others are not seeing what I'm seeing.
It is weird. I've had maintainable solutions on non-trivial code, but it does kind of require babysitting. Planning documents and detailed specs help. You get a feel for where the agent will want to take a shortcut and can devise ways to navigate around that.
I also find Go works really well, and generally stays, if not exceptional, than at least maintainable.
I've also enjoyed using OCaml, but I will say that I found the single worst function I've ever seen in a codebase in vibecoded OCAML.
You might just try asking - "hey I'm having trouble keeping maintainable codebases - how can I structure this project in a way where the code will be stable long term".
Sometimes getting the "software architect" role into the agent context is all it takes.
He used Claude Code, you are using Codex.
This tracks with my own experience. I have to watch what the LLM does in response to any given ask, especially when adding new features to an existing system, because it will do things a different way every time until it no longer knows what patterns to follow.
For better or for worse, when everyone is a "potential software founder" nobody is because your potential customers can just use AI the same way you did.
I believe that it just changes the opportunity cost. There are still only 24 hours in a day. You can’t copy everything.
I think there are many moats that non-experts won't attempt to cross even with AI assistance.
For example, we've built in a lot of complexity to areas like authentication. And for good reason. It's like electrical code. I'd pay good money to watch a muggle attempt to configure OIDC infrastructure. Even with the AI explaining everything to you, it's too much information to digest at once. You'd need an entire afternoon just to wrap your head around the idea of asymmetric cryptography. That's a lot of time not spent doing the thing your business is actually about.
Software development usability has always been measured in mean time before black-box failure: something misbehaves that the person can't fix or understand.
LLM's shorten that time for every application and every user, but particularly for users from professions that haven't built modeling or debugging skills because they rely on physical reality - like pipes fitting or process supervision - to weed out non-performers.
Hiring for LLM-enhanced work should focus on debugging skills in unknown situations.
Except I find that agents are much better at debugging than writing code. When the code gets to the state where the agents can no longer debug it and keep it running (as happened in Anthropic's failed C compiler attempt) humans will likely not be able to save the situation (in an efficient way). And without careful human supervision from the start, the code ultimately gets to that place.
For decades, employees have been developing tools using whatever was available to them, and in most cases, this was limited to Excel macros.
AI provides access to much better tools for testing and quickly experimenting with new ideas.
The only ones who should be worried are companies that charge millions for four junior developers and an agile coach, and deliver more PowerPoints than code (I’m looking at you, Capgemini).
It's a really interesting case study, but the summary seems to lean into the AI hype to an extent that borders on lying.
> His fabrication shop uses it daily, and he built the entire thing in 8 weeks. During those 8 weeks he also had to learn everything about Claude Code, the terminal, VS Code, everything.
I don't see how he can give this summary with a straight face after posting the interview that CLEARLY contradicts it.
In the interview the engineer says "When Claud Code came out almost a year ago, I started dabbling with web based tools ..." and "When it first came out I had so many ideas and tried all these different things", so he had clearly already used extensively it for a year. I would also guess the engineer was somewhat technically minded from the get-go, since he claims he was "really good with excel" before starting with Claude Code, but that is beside the point.
The interviewer later asks "How much of those 8 weeks was learning Claude Code versus actually building the thing?", and the interviewee answers "Well, I started Claude Code when it first came out so the learning curve has really gone down for me now..." and then trails off to a different subject. Which further confirms that the summary in the post is false.
It really seems like the engineer has spent the year prior learning Claude Code and then spent 8 weeks on solely building this specific application.
The interviewer also claims "This would normally have taken a developer a year to build", which seems really unsubstantiated. It's of course hard to judge without all the details, but looking at the short demo in the video, 8 weeks of regular development time from a somewhat experienced developer doesn't seem too far fetched if the objective is "don't make it pretty, just make it work".
As I said, it's a really interesting case study about a paradigm shift in how software is developed, and it's clear this app would never have existed without Claude Code. So I don't really see the need for the blatant lying.
I've noticed even experienced engineers have started overestimating how long things would take to build without AI. Believe it or not we coded before AI and not everything took years all the time.
We’ve all worked on projects where it took months to get requirements from the business. Sometimes to see the project cancelled after months of sitting around waiting for them to decide on things.
Coding has never been the roadblock in software. Indeed don’t we experience this now with ai? Vibe code a basics idea then discover the things we didn’t consider. Try to vibe that and the code base quickly gets out of hand. Then we all discover “spec driven development” SDD and in turn discover thinking of specifying everything our selves is an even bigger of PITA?
> So I don't really see the need for the blatant lying.
Because this is an advert
Seems like a really slick application, nice work.
I feel both great and awful about this. For over a decade I’ve said that nearly anyone that uses a computer could benefit from some programming understanding. A little bit can go a long way to solving problems like this. Problems that collectively slow down and block the ambitions of a huge number of people worldwide.
But instead we’ve found a way to circumvent the process. Losing the understanding of your own problem and the new ideas that come off the back of it.
I’m reminded of the story that NASA had a research project to make pens that would work in space, and Roscosmos just used pencils. I always thought NASA came off worse in that anecdote, but I wonder what they learnt while making the pen…
That story is a classic urban legend.
Both agencies used pencils, but they were problematic because the graphite could break off / float around / cause shorts.
The space pen was developed by Fisher independently of NASA. NASA bought 400 of them for $2.39 each. The Roscosmos later bought 100 for the same price.
The story is BS, btw.
Firstly, pencils in space pose serious risks. Pencils produce dust, graphite dust is conductive, and won't settle down in microgravity. They were used early on, but both space agencies phased them out when they realized the risks. After that, they first moved to grease pencils, which kind of suck for normal writing.
NASA didn't research how to make pens that work in space, an American private company did it on their own initiative and money. Then they sold pens to NASA for cheap, and marketed the same pens to people not in space for a lot of money and made a nice profit.
Today, both Roscosmos and NASA use the same pens, bought from Fisher.
Space pen is also an incredibly reliable pen here on earth too. Highly suggest people grab one.
Overpriced for what it is - there are pressurized tank pens starting at $4, a lot more ergonomic too.
How is a mechanical engineer a “trade worker.”
Most engineers have to take at least one programming class in college.
I agree, my immediate reaction was that mechanical engineer is not a trades worker.
I majored in mechanical engineering at college. We had a required programming class. A lot of people like myself already knew how to program before we took the class too. We also had a required electronics class. My experience is that most folks with CS degrees would be surprised by the breadth of what mechanical/aerospace/chemical/etc. engineers learn.
"Mechanical engineer uses code to improve engineering process". Okay, this has been going on forever. Other engineering disciplines and various fields using software to solve problems. Programming doesn't exist in a vacuum of theory.
I do this wirh conduit. Not as far along but definitely certain tasks in trades are prime for automation.
Tbh this is nothing new; we knew technical people with Claude code would be able to program well enough that tbey would be business developers.
As part of my "well shit what's next" arc I've been checking out machine shops in my area. By and large they are dumb manual 30 year contracts or highly automated job shops..
And the owners of those job shops aim for 3 shifts per worker via automation, and mash their own software with AI already. They are ruthless at cost cutting and automation and AI tools are perfect for them.
Unfortunately the vibe I get talking to them is essentially a triumphant "why would I need you, I have AI" or "yeah you're screwed".
I can't blame them for being served expensive barely functional crap SaaS or ERP software for ages, but I was not expecting to be viewed as part of the problem coming from a robotics, automation, and optimization background myself. It's just all a block of overpaid swindlers to them.
I have always wanted to get back to the metal, and the rapidly changing software landscape seemed like a good kick into it, but it might also mean a complete lack of opportunity
The general approval the average person has for tech/software workers has declined precipitously over the last decade (IMO for some pretty good reasons, as an overall industry we've done a lot of societal harm) which just adds to how cosmically funny it is that as a group we are likely to experience one of the quickest mass career disruptions from AI.
People like this will create a net increase in software jobs. Once his software makes enough money so he doesn't have to sit in front of a computer, he will employ someone. It will initially be a gig fixing slop. https://www.slater.dev/2025/09/about-that-gig-fixing-vibe-co...
People in the trades have a ruthless pragmatism that SV has forgotten.
https://www.slater.dev/2025/08/oil-spills-can-create-jobs/
I think it's awesome that AI is enabling this. I think the the future of software engineering is in helping make this kind of thing resilient and removing the fragility that AI generated code always seems to inject
I don't get it - it's an app that uses an image model to parse a pdf file and structure the data with a csv export?
Yes that phrase shows how simple it is, doesn't it?
But before LLMs, computers couldn't understand that phrase. Now they can.
I had a similar “oh wow this has normalised fast” a few weeks back when someone was like “oh it just takes all the human written recipe data and normalises it?” and I smiled at the “just”. Literally a nightmare problem only a few short years ago.
>10 minutes per drawing now takes 60 seconds. It can do 100 drawings in five minutes
bullshit story always leave something like this.
I also caught this but then figured 10m may not be the typical drawing time. 10m -> 1m means 10x faster. 5m = 300s alas 3s/drawing. So maybe it only tool 30s/drawing previously. (Unlikely.)
But even then, it also says 5m can save days of work. Days is minimum 2days, or 16h, or 960s. That’s not 10x faster as previously stated, but 192x faster.
So yeah, it doesn’t add up.
Waiting for the "jUsT sToChAsTiC pArRoTs" crowd.