My personal experience: writing code has always been the easy part. AI does most of that now.
Understanding the problem and the existing system well enough to design the right solution, even with AI assistance, is a higher cognitive load. I’m doing a lot more of that lately.
I’m more productive, but also more tired. This may be due in part to the breadth of what my team owns, which makes my day a bit more context-switchy than other teams.
As others in this thread have noted, the situation is still evolving. However, I worry less each day about being replaced by AI. There has always been more work than available bandwidth in my experience.
What seems clear to me is that expectations around velocity and throughput will increase (are increasing). AI use will be required to meet those expectations. Learning to use this new tool effectively will be essential for career progression (and preservation).
> My personal experience: writing code has always been the easy part. AI does most of that now.
The only reason dev jobs paid more (by a factor of two or more) than pure solution modeling was because "writing code" was the hard part.
If you wanted to get paid just modeling the solution and handing it off to a coding team, those jobs were available for decades, typically called Business Analysts but few devs moved from dev to BA.
> Understanding the problem and the existing system well enough to design the right solution, even with AI assistance, is a higher cognitive load.
I've found that the act of physically writing refines my understanding a lot more than simply reading.
We don't typically expect a person to read a trigonometry textbook and then perform well on an exam. They have to drill problems to surface their misunderstandings to themselves.
My fear is that, with developers adopting your approach, they're "designing" systems in much the same way that a read-the-book-only trigonometry student solves trigonometry problems.
GP's "design the right solution" is a role between "programmer" and "business analyst" that got merged with "programmer" to become "developer" decades ago. That's where the high salary came from. It's been reemerging as "architect" now that "developer" has been watered down to include "programmer".
Perhaps solution was the wrong word for me to use here. It was intended to encompass the implementation details (abstractions, architecture, observability, etc)… All the decisions the engineers would normally make during planning and execution. Once I have that nailed down, the act of writing the code is largely mechanical.
That’s the source of my “easy” framing. It has always had the lower cognitive load in my experience. Now that I can offload the mechanical part to AI, I spend more time on the hard parts.
I still read plenty of code along the way, maybe less of it now because it’s easier to surface which parts of the code I need to read.
thank you for putting into words that which has been hard for me to describe — I’ve noticed the worse a dev was at their job the more high their opinions of AI seem to be. The subject textbook analogy (trig book in your ex.) is a perfect frame of reference for why that might be the case…
to further that example, many people with the help of AI are ostensibly copy pasting trig problems from the book without understanding the mechanics running through them and labouring under the impressions they’ve become closer to skilled mathematicians
There was a time back in the 1980s (and probably before) when "analyst" paid better than "programmer". The programmer wrote the code; the analyst figured out what the code was supposed to do to meet the business need.
In my view, "programmer" merged with "analyst" to become "software engineer".
> Who hires “pure solution modelers”? I don’t think I’ve ever encountered someone like that.
They're called Business Analysts, sometimes simply Analysts, and that's effectively their job - come up with a spec and give it to the software engineers.
Agreed; typically (especially if a client is involved) I’ve seen creative and dev define and articulate spec and expected behavior, and BA documents it. Then, when it inevitably evolves, BA’s job is to capture the changed spec. The artifact is simply documentation as a client deliverable that’s then often never referenced or used for anything outside of maybe complaining that a feature doesn’t do what the spec claimed, or maybe as context when the client takes their whole project to another vendor to be rebuilt from scratch lol
> What seems clear to me is that expectations around velocity and throughput will increase (are increasing).
This is why I don’t understand why folks around here (that are employed) feel so enthusiastic about AI. We are going to be working more in a rush to produce stuff that we won’t be feeling as proud of as we did before AI. Unless you were in the profession for the money, the delights of crafting software simply go away and AI is pushing us closer to be just… well, I don’t know, but I don’t like it. Sure thing, if you are a CEO, this new state of things must be wonderful
I didn’t know modern (2015-2026) software engineers were making such a strong distinction between “writing code” and “designing solutions”. It’s not the majority of engineers “design” and then hand over the implementation to others (at least Ive never seen that before).
From my experience, a typical software engineer needs to understand the business (e.g., knowing who your users are), design a solution (e.g., we probably need an event-driven arch right here) and write the code (e.g., we should use select for update skip locked to avoid over claiming). They all are equally challenging imho
> My personal experience: writing code has always been the easy part. AI does most of that now.
That's exactly why I don't have AI writing my code. It is doing the easiest part of the job (making symbols appear in the text), which isn't actually valuable to me. A good tool should help me to do hard things, not easy things.
Agree. Also, there is a lot fog at the moment. AI generates more code, we need a lot of markdowns now to teach it how to write "good code"... and <insert here a lot of AI processes>. But at the end... a programmer has to take ownership of that code and responsibility, meaning: reading A LOT of code and/or coding more code.
Responding to my own comment to add that I think this moment favors the curious and passionate. None of what I wrote above is a complaint. I’m having more fun now than I have in a long time.
I'm a Senior Freelance Programmer, I can see many of my past and present clients moving towards the exact path you described. I keep warning them during meetings that Claude model isn't sustainable for long, eventually the VCs will come for their revenues and Claude will be forced to close their access to all but the most enterprisey ones with deep pockets. The mere electricity cost for that kind of high level reasoning and abstraction can't be subsidized forever. However, there are other forces which pull them towards Claude and AI workflows. Most of the clients are in a "wait and watch" mode right now, using LLM assistance for code generation but not fully depending on them.
Before LLMs came, there used to be the technical debt to deal with in a project, now there is also the added cognitive debt which is way more subtle and impactful long-term. If your source of truth isn't source code but a prompt (or even a series of prompts with branches) and the executor of prompts is a non-deterministic agent, I think you've already lost the battle there.
You're standing on the shore, and your clients are having fun in the water. The tide is going up, and you're screaming at your clients "come back! it's not safe". And so, they show you the face. You appear to them like the boring guy who's not fun to hang out with.
Eventually the tide is high, there is strong current, and they are being swept away further and further from the shore and they are panicking : "pyeri! help us! please!"
People (the non tech people, the MBA people) don't want to hear what you, the tech guy has to say. You're the not fun guy. Stay in touch until they do need you and say : you were right. That's the day you charge them a dear price for the service.
AI is still at the bait stage of rollout. They subsidize it, they want you to get hooked onto it to the point where you cannot do without it. Then only, they start to charge.
I used google code assist for around 9 months. It was free. I would ask it questions from time to time, to help to fix bugs, and to avoid to spend an hour browsing SO. Now, it's around $30 per month.
They are losing too much too fast atm, they have reached the stage where they have to start to charge. Another one of their strategies is : IPO. Once they (openai/anthropic) are listed on the nasdaq, you will pay whether you want it or not (via your exposure to the nasdaq/S&p500 with your etfs).
> Stay in touch until they do need you and say : you were right. That's the day you charge them a dear price for the service.
That assumes OP will still be in business if that day even happens. Odds are that cheap AI access will be around for longer than freelancers can remain solvent.
Using today's model prices as a rebuttal is a very weak argument.
Two years ago, SOTA was gpt-o1, and it was much more expensive than Fable. Now, for $4,699, you can easily run a much smarter Qwen3.6-35B locally with DGX Spark.
Think about where we are. This is an era where a new SOTA arrives every two months. It took LLMs only about 18 months to go from chain-of-thought reasoning to disproving the unit-distance conjecture. chatGPT itself is only three and a half years old.
DeepSeek V4, released two months ago, is almost as cheap as the electricity costed, has the ability to being absolutely a top-tier model in 2025 standards.
You ignore that Claude are not alone, tech progresses and reduce costs, and there are always the Chinese alternatives which are becoming sufficiently better over time.
The electricity cost per unit of machine “reasoning” is vastly less than the cost of salary for human reasoning. That’s a weak argument. You should focus on the second part… LLMs (at least today’s) don’t build simple solutions, and the complexity they introduce has a cost.
Definitely. One of my fav techniques is to ask an LLM to simplify something by 90% or 99% if it looks overly complicated. Or asking the output to be critically reviewed by another agent too.
As a Freelance Programmer, are you even getting consistent clients at decent rates? If so, how are you getting clients consistently and how do you convince businesses that you are better than AI?
I think a lot of developers probably FEEL like they are in super mode, but in reality they're just letting Claude drive the boat and they get to wear the captain's hat.
Maybe I'm wrong. Maybe AI Natives will be faster in the end and can build / do more, or building software really is a dead field - but I noticed that I was losing my brain and had to get back into the seat.
There are definitely great use cases for agents - but I think a lot of us aren't flexing our brains anymore and, even worse, some devs believe they are. I urge every developer to put Claude down for a day/week... see how well you can do in the "old" ways. It'll still be here when you get back, but my guess is it'll be a rude awakening.
i understand your concern about relaying too much on ai tools like claude. while they can enhance productivity, they shouldnt replace critical thinking and problem solving skills that define good software developer so yea taking break from ai and working on "old" way can help sharpen those skills. i think its important to strike balance between working on new/old way but i also have feeling that everyone is addicted and trying to develop 24/7 cos someone might "steal" their idea. like theres some kind of imaginary race and if u dont code for 1 day with claude (even if it is nonsense) u wont end up first...
These are people who don't understand the job of SWE.
Look, the job of a medicine doctor, or a plane pilot, have largely been automated. The doctor could rely on google searches, or even AI, to answer your questions. The pilot can trust the auto pilot.
Yet, the doctor who does advanced stuff (surgery) has no shortcut to mastering his skill : he still has to go through 10 years of studies + years of experience under the supervision of a senior with 20y of XP.
Similar path for the plane pilot.
And the same reasoning applies to the SWE. AI allows to : delegate the repetitive tasks, generate the boilerplate code, fix time consuming bugs, to focus on more meaningful stuff.
AI is a tool. It's an additional layer of abstraction. The winners will be the guys who are passionate, who still put efforts to master SW, who still put efforts to remain up to date with the regular updates (new releases, new libraries, new approaches...), and who understand how to use AI the right way.
All those guys who 100% rely on AI do is help big tech cover their massive costs for the deployment of AI infrastructures. Big tech does need those guys.
Imagine the auto pilot fails for some reason, during a flight. There are 400 passengers behind. This is a minor issue for the trained and experienced pilot.
What do you do, as a SWE, when tomorrow, anthropic/google/whoever, tells you : "we can't keep running at a loss, our prices for AI have to reflect our costs. Your monthly subscription for Claude is now $500/month". Or there is a power shortage and for a couple of days you cannot rely on AI, you can only rely on your brain to deliver this feature you committed to deliver tomorrow ?
>Look, the job of a medicine doctor, or a plane pilot, have largely been automated. The doctor could rely on google searches, or even AI, to answer your questions.
And clearly you are not someone who understands the job of a physician.
I have had some truly spectacular results that still kind of stagger me in the last few months using Claude in my hobby projects -- but even though Claude insists on trying to slip its name into the git history as credit it's not Claude -- it's me. Someone who has studied CS and software engineering for decades will craft different prompts from someone without that background. A suggested axiom: there is nothing I can build with Claude that I could not build myself with my current level of CS knowledge, assuming I had infinite focus and time. In my hands it can go as far I could anyway, and no further. (But it is faster!) My experience bears that out so far.
Fair enough but speed, especially the kind that comes with LLMs, is fast enough to open new ways of working and doing things. We don't have infinite time and if there's something that can give me multiple, for example, UI suggestions in a minute which I can pick from, it's a different way of working than sitting with a UI designer for several hours have discussions. So, while I agree with you in theory, I don't fully agree with you in, what I think you're implying, when it comes to practice.
Claude writes probably 95% of our code now, fintech, amongst top 5 in the world in what we do. I am 100% certain we're not even at the forefront of using agents for coding compared to some others.
We still review everything. And we guide by planning, prompting, speccing.
So we're not actually much faster at the core code, because reviews still take time. Ultimately, we're on the finance markets and we have regulatory pressures and I, as the human, am responsible for putting the code out there.
But we're freeing up a lot of time to get other things correct. We have n x more metrics now because plumbing in basic stuff is now trivial. We now have dozens more tools and skills to help analyse issues (e.g. why this price and not x), answer questions, etc.
I now have skills to scrape logs, download unpack and scape our bus persistence, link to kdb, and so on, all in my claude prompt, joining it all together and the AI is figuring things out. I can diagnose things, I don't know, maybe 100 times faster?
It is revolutionary, and I am highly sceptical of the motivations of people who keep saying otherwise.
When you review everything, do you understand every line of code before approving? Do you make it rewrite code that is too abstract or unclear for future humans to understand? Does AI write the tests and do you review those with the same diligence?
I don't disagree that it's revolutionary in many ways, but I am seeing lots of companies make very costly mistakes by relying too heavily on AI without fully understanding the code it writes and without fact checking its outputs by a human.
Yes we understand all code merged. Yes, I have coding rules and standards that the agent follows to ensure it writes code in virtually the same style as the whole team does. Someone isn't going to let my change be merged if they don't understand it.
My hunch however is that in a few years we're not going to be reviewing as heavily as we improve guardrails and can trust the AI code and review cycle more. I'm not sure what to expect for my career at that point.
> Someone who has studied CS and software engineering for decades will craft different prompts from someone without that background.
This, to me, is the biggest differentiator. In terms of results, there's a huge yawning chasm between the person who says "Claude make me a $thing" versus the person who puts in the effort to lay down the overall architecture, gives some thoughts to libraries and dependencies, performance trade-offs etc, and only then begins prompting.
Knowing how to implement Djikstra or a linked list by heart is no longer important. Actual software engineering skills are more important than ever.
Even more narrow - you only need to know when to consider them.
I only ever bothered remembering enough of any algorithm to know my options and a few rules of thumb. If I ever actually need to consider the details of the algorithm, I certainly need to spend a lot more time thinking through the problem and its solution. Knowing a specific algorithm well enough to pump out in 15 minutes is a party trick that is as useful as being able to change a tire in 3 minutes flat. A great time saver that will be functionally useful maybe 3 times in your life...
The gap is closing; a shitty wannabe programmer will eventually learn the structures one way or another. Agentic coding just got many new people involved, and these new people create noise.
Low-skill work that used to be outsourced will go to cheaper LLMs, unless wages are depressed enough / running costs are high enough to keep using humans as cogs in the machine. This will also consume a ton of small-scale things, like personal-sized automation and small-business customization of better-crafted things (stuff that normally wouldn't be paid for in the first place, or only extremely rarely). Some will obviously exist, because paying someone else to farm out a ton of mediocre output with LLMs is still worthwhile sometimes, but it's going to be gutted as a general statement.
Especially with prototyping-style work, LLMs are clearly good enough for a ton of business-oriented proof-of-concepts, and that line of work is essentially dead. Unfortunately a lot of mid-tier art falls into this category as well, particularly because execs very clearly can't tell good art from bad (on a "customers like this" scale, with functionality being the judge, which is fairly objective. not a subjective "this is good art").
High-skill work is still necessary, but it's hard to tell if it's actually going to be more important (because skill is obviously still needed for actually-good results, and I honestly see no evidence that this will change with current tech) or less (primarily due to less demand, and it being significantly harder for non-skilled to judge skill when everyone can prototype something seemingly-impressive in a weekend). Some will very obviously continue to exist though.
Whether this means "high-skill people are going to be fine, stay the course" or "<10% of high-skill people will be fine, you had better be scrambling right now or looking for a new line of work" is... much less clear.
"Computer" use to be a job title. So no, I am not optimistic about the future of most programmers, maybe even all programmers.
One possibility is that software starts to look more like traditional manufacturing.
The machine is the company’s core asset.
The engineer only needs to know how to operate the machine well. Once that happens, the barrier gets much lower, need much less people, and the job naturally become much less valuable.
Some parts will still need to be done by hand, of course. But only a very small part.
It is like old factories. They used to need lots of fitters, at all levels of skill. Now you only need a few of the elite ones.
AI is the CNC machine of the software industry.
The more pessimistic future is that, maybe five years from now, the best programmers will look at AI the same way the best Go or chess players look at AI today:
Like KeJie said, "I don't even know what I am trying so hard against."
We now have a new SOTA every two months. It just took 18 months for LLMs from reasoning models to disproving the unit distance conjecture. ChatGPT itself has not even existed for as long as a college student spends in university.
In any case, we have already passed the point where this can be rolled back.
Maybe ten years from now I will be leaving a comment saying that "programmer" used to be a job too :-/
Programming is the low-hanging fruit for AI.
Open source and knowledge sharing have given it huge amount of public, high-quality training data at a level other industries can hardly imagine.
And almost everything in programming can be tested and verified inside the computer quickly in a closed loop. No robot arm is needed.
The main weakness of current LLMs is still that they are static:
They do not really change themselves through use. Harness tools are just elaborate ornamentation on top of prompts. LLMs are frozen at the moment training stops.
Once we get models that can change their own weights through self-feedback, then maybe AGI really is on the horizon.
Thinking optimistically: I may be lucky enough to see it in my lifetime. Maybe by then, people will be able to live more like human beings, instead of organizing their whole lives around work :-)
A well-equipped local-AI-capable machine is already much cheaper than a CNC machine -- and will presumably get cheaper over time, RAM prices notwithstanding.
I'm not sure the comparison works if individuals can afford these machines themselves and don't have to commute to a factory to use them; I doubt employers will serve as either gatekeepers or sole providers of access to AI.
Your comment makes sense. Today's DGX Spark can easily run qwen-3.6-35B, which is indeed much stronger than the gpt-o1 two years ago. The future is hard to predict, perhaps the bigger issue is that while production capacity exists, where the demand will come from.
Thank you for your comment. I enjoyed it a lot. Good food for thought.
Your analogon is a bit leaky abstraction in the sense that it misses out on the broad stastical nature of LLMs. However, I find it is a good way to illustrate the potential industrial transformation.
It is hard to say what the future will bring. The original AsK HN post is definitly an omen for things to come.
What are you writing that Claude is actually writing all of it? Every time I get past the green field stage, I just end up throwing out what it writes half the time since its trash. Claude seems really great at fix this unit test, generate this boiler plate, take this uml and build this framework out. But when I am doing refactorings, or implementing things that are beyond monotonous, I end up writing it all by hand. My best luck is still do the design, query AI for possible choices, sketch out the framework of what I am writing, have AI critique my plan, and then have AI design individual methods, then fix what it writes.
> What are you writing that Claude is actually writing all of it? Every time I get past the green field stage, I just end up throwing out what it writes half the time since its trash.
For the current state of frontier models, you need to break the steps down so that the LLM understands a process like what you might go through as you expect it (which is often different for everyone).
i.e., get it to agree to a spec, then get it to agree to a build plan, agree on unit test signatures, UI etc as needed, then let it build, ...
I can take all of those steps, turn them into separate skills, then give them to a product manager or business analyst who makes half your salary, but has far more knowledge about the customers needs than you do.
A business analyst or product managers spends most of their time in meetings understanding customer requirements. Now they have to find time to build the project and fix bugs?
The business analyst use to hand off details to another person who would define detail technical specs like database fields names, type and size. Then the programmer would implement it.
What you say could be theoretically possible, but it's probably an issue with your usage of if. For eg: if any of this hard non-promptable project is available on github, or you've seen this problem in any large scale github project, you can share that. I've rarely seen a repo and a problem that claude can't chew through with the right prompt.
> I've rarely seen a repo and a problem that claude can't chew through with the right prompt
> a skill/PEBKAC issue
But then I remember how Anthropic couldn't fix the flickering issue for many months. It just does not compute.
Is it that people working at Anthropic can't prompt and it's a "skill issue" too? I mean, the terminal does not flicker in a lot of other complex TUI apps that I use every day - Midnight Commander, Emacs, tmux, etc. These are open source, Claude could be prompted to "just do what Midnight Commander does". So what is it?
Opencode had the same flickering issue not too long ago and they fixed it by switching from ink to opentui if I am not mistaken. So a solution is possible and known. Antropic just doesn't seem to care.
Because it proves that even the greatest prompt-engineers in the world are unable to vibe code their way out of a simple bug. The fact that this example is a small, annoying, random bug that is relatively harmless does not mean that the next bug won't be as harmless or even as apparent.
> Every time I get past the green field stage, I just end up throwing out what it writes half the time since its trash.
Is a skill/PEBKAC issue. You still need to exercise engineering best-practices like decomposing work to the smallest unit before taking a task on, brainstorming design first and implementation last, clearly defining your success criteria and requirements before beginning any work, etc.
I'm on a >10yr old codebase and have been able to get my org to orchestrate entire features, fully unit tested, e2e tested, storybooked, from scratch without touching an IDE. Refactorings and the endless mountain of 80% completed migrations from one pattern to another are now trivially able to offload.
Point your SOTA de jeur at the original docs, a few of the original examples/PRs and have it draft a skill describing the work, the scope, and the success metrics. Iterate on the skill with the main agent by subagenting to test the skill until you are happy with the result and it mostly gets it right with the guardrails you've defined. Again - keep the scope extremely small. It gives much less rope for the agents to hang themselves with and it is less cognitive load when you have to review/test the PR.
Then set up a reasonable cadence for it to execute an autonomous thread on and review when you get comfortable.
----
The issue I've been running into lately is simply that we've got so many PRs coming in that actually doing thorough human reviews on them is not sustainable relative to the rate the team is creating agents to open them and people (especially juniors and mid level) are getting burned out by essentially having entire days where they are just doing code reviews.
I think it’s becoming more and more performative. We’ve never been less focused on the actual product — the software — than we are now. The focus is increasingly on how someone generates code, despite that not having much to do with the product.
The software is not getting better. Generating code faster does not result in better software. Software continues to be slow, unreliable, complex, and counter-intuitive. AI has not improved on the metrics that matter.
AI, as amazing as it is, has not actually changed the process of software development and as a consequence, the resulting software has not changed. The job hasn’t either, except insofar as you’re judged for tokenmaxxing.
compare this to Electronic engineering, we are not making chips by hand, It is impossible to squeeze too many transistors in such a small space, we just create the circuit designs. I believe writing the code is heading in the same direction as well, you don't write too much code now, but you have to design the architecture and connect things. But it does not mean that you don't need to understand the code, now of all the times people who understand code are more important. Many below par devs will loose jobs for sure.
The profession has already changed. For the past eight months, AI has been competent enough to code like the best human programmer, but strangely, the software isn't any better yet. Everyone has lost sight of what the profession truly is. It's not just about coding; it's about software engineering. Our role is no longer that of programmers, AI has taken over that role. Our role is that of engineers who manage programming agents. Every attempt to have AI develop a medium-to-large project fails because the goal is to solve everything with a magic four-line prompt. We're forgetting the structural aspect, the engineering side. We must treat the tool as just that: a tool. The direction and responsibility remain in our hands. It's not about reviewing the code line by line; it's about ensuring that the product faithfully represents a well-planned engineering intent. That's why the concept of AI-augmented Software Engineering is so important.
> AI has been competent enough to code like the best human programmer
It’s really not. Opus 4.8 can’t produce good software design and it still makes straightforward implementation mistakes. Two errors it made in one day for me recently: it built the Cookie class I asked for without a name field—cookies have a name and a value—and it neglected to handle a case where a database could have multiple rows with the same id, just returning whatever came back first.
The “best human programmers” absolutely would not have made those mistakes. At worst, they would have asked if I really meant what they thought I meant.
I understand your point, but what you're describing is exactly the kind of mistake even the best human programmer could make in a poorly managed environment. I'm concerned that since AI emerged, we've overestimated our programming abilities. The comparisons we make between our own work and AI are based on an assumption of absolute perfection that doesn't exist in reality. Bugs aren't an invention of AI; they're ours. All modern software engineering, testing systems, version control systems, and so on, were developed through years of dealing with our own mistakes. We don't make systems fault-tolerant by understanding that failures are external to our work. These failures are our doing, and now they're AI's doing too. We have to deal with applying to those agents the management that we previously applied among ourselves. The example you provide is very good, because you yourself, with your human mind that solves problems, suspect that the origin of the problem was poor communication, and you are very likely right, but just as if it were a human error, the programmer is responsible for their faulty code, but you are responsible for poor process management, and yes, the same applies to working with AI agents.
Sorry, I have to disagree. People often react to criticisms of AI with “but people also make mistakes,” but that’s a whataboutism fallacy.
The statement was that AI is as good as the “best human programmer” and it’s quite obvious that it’s not. It makes inhuman mistakes on a regular basis because it’s not using human thinking. Blaming those mistakes on poor management is just sweeping the problems under the rug.
I don’t know the best way to work with AI, but I do know that we’ll only discover the best way if we’re honest about its capabilities. That includes not pretending it’s as good as the best human programmers.
I suppose our opinions stem from different experiences. I don't expect AI to do all the work with just a paragraph of instructions. Some people do, and they get very poor results. I design large, complex systems based on microservices, and so far I haven't encountered any of the obvious and glaring errors that other users report. For each project, I've spent two or three weeks working on thousands of lines of specification documents, user stories, plans, and task lists, using DDD. My prompts consist of dozens of files with 10,000-20,000 lines in total. Because the implementation tasks are extensive and atomic, AI has worked very well for me in solving them.
My experience shows that AI can program like the best programmers; its code is very good when given precise instructions, just like a human. I've encountered problems elsewhere, such as anti-patterns in unwired modules, which are "large-scale" implementation errors. I'm resolving these thanks to an open source tool I'm building for AI cognitive governance, and it's yielded excellent results for me. The code produced at both small and large scales is high quality.
In my experience, people experiencing gross AI errors are doing so because they aren't giving it precise instructions. And by precise instructions, I don't mean a highly refined prompt or "vibe-coding"; I'm talking about instructions thousands of lines long, just like the ones we create when developing with human teams.
If two people are using the same model, and one reports that the AI "neglected to handle a case where a database could have multiple rows with the same ID", while the other says they can develop a huge microservices system with multiple databases without any major issues, perhaps one of them isn't using the tool optimally, based on my experience.
Yeah, your experience is definitely different than mine. When I’m working with human teams, I don’t spend weeks giving them thousands of lines of precise instructions. We work incrementally, having fairly brief conversations to make sure we’re on the same page about the tasks we’re tackling, and then letting individual pairs work out the details of each task… which they do, because they’re experienced professionals.
For example, the project we were working on was to add support for reading a session cookie to a codebase that, up until now, had used a different kind of auth. Fairly straightforward, everybody knows what a session cookie is and how it works. In about 10 minutes, we decided on the big picture design elements (how it was going to fit into our existing system, what we needed to add/modify, etc.) and the corresponding tasks.
One of the things we wanted was an “UntrustedCookie” class to represent the cookie. It was meant to follow a pattern we had already established for other user-controlled input. Our HttpServerRequest object was going have a new getCookie() method that returned it.
This would have been about 30 min of work for a pair to implement, including tests. It’s pretty trivial. No further documentation is needed.
Anyway, I’m glad AI is working for you. My experience is that it often fails, and does so in ways that experienced humans don’t.
Exactly, that's precisely the point. They're different experiences. What I achieve now with three weeks of theoretical work, other teams achieve incrementally over several months in iterable work blocks.
The interesting thing is what you mentioned, that "no further documentation is needed." In the industries I work in, it's mandatory (with or without AI, and it's been that way for many years) to have everything fully documented from the design process onward. For me, it hasn't been difficult to work this way with AI because I know and have practiced the discipline of documenting decisions for a long time. For my clients, it's an essential accountability requirement.
These documents now have a dual purpose because they now serve to manage cognitive discipline too, so that agents do a better job than they would with vibe coding. Because without that discipline, what you say is absolutely true: AI agents do a terrible job and only hinder the good workflows already adopted by professional teams.
This is what I'm seeing at my company as well, "software development principles" are out the window. People have forgotten all about "Second System Syndrome" too, docs, tests, code, design - all LLM generated.
I don't like, I prefer to use Claude/Codex as an aide, not to let it take the wheel entirely but I don't really feel like I have much choice in the matter.
Basically, in a decade or so, we'll be completely out of the loop in software development; even this title won't exist anymore (like the 2000's webmaster). We'll still be around, but with different roles.
For what it’s worth, I find comments and articles with assertive predictions like this difficult to take at face value.
I don’t even disagree with the premise, but it shifts the burden of assessing likelihood back onto the reader, so it doesn’t really add much value to me.
I think the genie gets put back in the bottle, at least partly.
I don't think the future is massive data centers running at a staggering loss to generate questionable code.
The future is rethinking IDEs to have local models work in partnership with the developer to ease tedium and catch mistakes.
A model that maintains a visual, zoomable mind-map of the entire project, with two way binding. Code can be created visually or textually, same with data flows.
Project structure and architecture are presented in high-level ways, that can be easily altered and refactored with almost zero tedium.
I think we start using AI for what it's good for: pattern matching and transformation, and stop trying to make it reason and pretend like it's a human.
Once we, as an industry, figure this out we'll unlock a massive boost in quality and productivity, but it looks like there will be some painful times ahead before everyone realizes that the token extrusion machines are only increasing the total cost of ownership, and they are being used incorrectly when we try to outsource our thinking to them.
I think there's an enormous opportunity to build these tools right now, and that whoever nails it will win.
It's disappearing. Even if models stop evolving tomorrow, there's still enough potential in the harness improvement to reach the point where anything 99% of us know about software engineering is useless. How many humans will be involved in creating software after the dust settles is anybody's guess, but I wouldn't bet on it being anywhere near the current level.
> I had an interview where I was asked the obligatory “what’s your Al workflow” and I said I use it for searching documentation and writing small functions or boilerplate that are tedious. Then I was asked whether I use Cursor. I said no, and immediately was told that “I’d be a better programmer if I used Cursor”. I have 13 years of software engineering experience, and was talked down by an Al startup with no minimal viable prototype. Then I was told I did not have the experience for the role. I love this timeline so much
I will just say, if you are any good at programming and have experience using agents, you're in the top 0.1% of the world in adoption of a critical new technology.
It may seem hopeless as a programmer, but imo you'd be much better off reframing your situation re: the above sentence.
Iunno, I feel like being born in a first world country did most of that "top 0.1% of the world" work. That sentence works the same with and without AI/LLMs.
Among peers, I feel like I am top 20%? 30%? maybe, by being a good programmer who is adept at agents. A year ago was the 0.1% point, this stuff is spreading like wildfire. A year from now I think it's going to just be de rigeur that these are our tools now.
Worse, any edge I have from working with this stuff for years is quickly dulled. The tools are evolving fast. My tricks from 3 months ago have been eclipsed.
"Well, in our country," said Alice, still panting a little, "you'd generally get to somewhere else—if you ran very fast for a long time, as we've been doing."
"A slow sort of country!" said the Queen. "Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!"
Maybe if only you ran a little faster, you'd outpace the rapid advancement of automation! There's fewer jobs now? Malnourish yourself until you're a running skeleton to get that speed advantage. More people competing for the same opportunities? You can't afford breaks anymore, just run, day and night, doesn't matter where, move. Thousands of people still outpacing than you despite all this? A true self-starter strives to dedicate their whole life, their existence to competition, you must give everything short of death to reach the coveted peaks of temporary employment.
It doesn't matter what you're doing, there's always a trade off to taking a shortcut and rarely does the price not need paying.
We're seeing lots of code being ~written~ generated, deployed, checked (tested manually), then shipping it as done. Fine for the simplist of things, but in a complex system unintended side effects are far more common.
I feel like the system analyst role is going to make a resurgence in the coming years. Once the domain knowledge is lost, there's going to be a need to re-discover it and understand what should be happening and what is happening.
Going against the grain - i don't think all but the most expensive (and non critical) SaaS products are going to be replaced by an in-house system. If you're company of 100 people is spending $12k a year on HR software. Building and running it yourself isn't going to save you 12k and in reality it's going to cost you headcount for someone to manage and maintain it. Mattermost exists and people still pay Slack $200 per year per user when they could just roll out Mattermost "for free".
My impression is that smaller companies, that depend on rapid prototyping to gain clients, exert a lot of pressure onto their devs to use LLMs. At least that's the situation in the companies some friends of mine are working at.
I'm in a slow-moving, much bigger company. Lot's of talk about "AI" here and we can use copilot if we want to, but there is 0 pressure. I'm in a small team and one colleague uses copilot often. In the beginning there was a minor conflict between him and me, because I found the quality of the LLM code unacceptable and had to ask him to review it more carefully. I think that's settled now, but it makes me sad how a once motivated colleague now seems to try to cheat his way out of work.
I personally find it incredibly boring to write copilot prompts or read its answers full of boiler plate and sycophancy. I don't understand how anyone would want to replace the cognitive work of programming, that I find enjoyable for the most part, with the cognitive work of "talking" to an LLM.
Anyway, I think it will be like this at least for a little while longer: only vibe coding allowed in small companies and less vibe coding the bigger the company is.
But before vibe coding can take over the slow-moving big companies, all the accumulated technical debt will come back to haunt us and vibe-free software will be the new fad. That's what I hope at least.
At the high end, there will always (or at least for a fairly long time) be a subset of work where AI can't do everything itself. Perhaps the framework or language is too new, or its built for hardware that's only just become possible. Perhaps the company is worried about security issues resulting from letting LLMs access its systems, or needs a human in the loop to take any liability. Perhaps the tech needs a level of performance that an AI might struggle with, and which a longtime engineer with a computer science background may be better at dealing with (like stock trading systems or something).
This will pay very well, but probably only provide enough jobs for 5-10% of the current software engineering workforce.
Then there will probably be a large number of companies where AI does most of the work, but where one or two people will probably be kept on board to guide it in the right direction/take care of issues. I suspect a lot of less technical/cutting edge companies in more 'traditional' industries will be in this camp.
Finally, a lot of work will just be outright replaced by having an LLM take care of everything. This isn't viable for FAANG companies or fortune 500 level ones, but the average mum and pop business could probably just replace its entire development team with a Claude subscription. I suspect a lot of web development agencies and lower level jobs are just going to vanish.
So, yeah. High level bespoke work where every microsecond is king? Stays mostly the same, albeit with some AI usage to handle the boring stuff.
Basic brochure/shop/CMS site development? Claude and co take over almost entirely.
Not the same thing. Developers' clients are being approached by thousands of people instead of a handful. It creates the illusion that everyone can do the same thing for cheaper.
I've tried AI tooling in the past and it felt wrong to me. The software was alright (it worked).
I don't know if anyone can relate, but it didn't feel like it was "mine". I didn't even keep the project/code. It was a working software emulator for a video game console but I felt zero connection with it and couldn't even get myself to keep the code.
Maybe I'm old fashioned and/or stubborn, but I like to write code. I like to know the minute details with regards to how things work. I like to know every function an API provides. I like to understand the differences between platforms, devices, hardware, etc. I've always loved it and always will.
I don't really get stuck, but when I do the answer is usually in documentation or a man page. I probably read documentation and man pages more than the average developer.
You could argue that is slower than asking an LLM, but I am willing to do things a little slower if it means building up my knowledge and getting stuck less in the future.
- LLM adoption varies across the org. Some are heavy users and some less. Some suspicious some less.
Where are we heading? Depends on model/harness capabilities. Likely some sort of mix where some projects will still require expert humans and others will just be vibe coded. How much we lean in that direction - we'll see.
Every software developer will be a manager of one or more AI agents. Managing AI agents will turn out to be surprisingly similar to managing people, except for the drama, illness, and tragedy.
I was trying to make a different statement. Everyone will need to become a manager, even ICs. But in the past, many engineers shied away from management, for various reasons. Now, it will need to change.
Managing people is hard because of all the things that make us human. Managing AI will be simpler as we won't need to deal with some of those things.
Separately,
> "By using AI we get all the benefits of workers but with none of the drawbacks of humans."
To be fair, I did not write that. You are projecting your thoughts on my post.
Its similar for us to a certain extent. I honestly don‘t know yet where this will lead to.
Personally I also don‘t really follow the arguments that the agent does the coding and the human does the understanding.
In my opinion one is thinking differently about the code when not coding it by himself, on a higher level or lets even say a more superficial one.
To keep the understanding on the same level you would have to limit the agent to just „typing“ but this is definitely not whats happening.
Yes, may be a skill issue[tm], may be an inherent one or it may not even be relevant anymore, we will see.
For me it currently still works well because I am working on legacy systems I more or less have a good understanding about - so I can judge the agent code.
Not sure how this will be with new, green field code.
Not even starting with the discussion how it should be possible to review the sheer amounts of generated code.
I must be honest, but I have started doing the same thing to some degree. Now this is for me in particular, I do know coding, but if the task at hand will take like 3 days and Claude can write and debug it in an hour, then I usually just run it by Claude. This is not to say I don't still code, because I still do, depending on the project, but I find myself relying on Claude a lot. I know this is counterintuitive to what you want to hear, but this is my reality. However, I still know a lot of people who still code with out the use of AI. So in my opinion the profession of programming will go down as AI progresses but will never die no matter how AI advances.
The adoption curve across companies and industries is highly variable right now. Tech moves fast but plenty of boring industries need software but don't move on the bleeding edge of tech / LLMs / etc.
Even in the discourse here, you can see people getting variable quality of results and variable skepticism, some of which is valid, but a lot of it reads more like not having spent time really understanding prompt engineering.
From my experience, Ai right now is not perfect and people still treat it as if it was, leaked secrets, create 10 bugs to solve one minor issue, whole backend a mess that won’t resist at scale. Even though it is improving and all this issues will disappear, Ai will take over most of the technical hurdle, what will be left?
Materializing and scoping down broad idea ( or just abstract vision ) into what needs to be built, it’s not the same to say.
“Hey Claude build me a fitness app”
Thank actually understanding your customer behind it, the behaviour and psychology, the journey and what is the actual problem you’re solving.
Tech in general and programming emerged as a need to create new things in a digital world to solve our problems, building them just got easier but understanding the problems and the people behind them, that’s gonna be an increasingly necessary task
151 "profession" wn "WordNet (r) 3.0 (2006)"
profession
n 1: the body of people in a learned occupation; "the news spread rapidly through the medical profession"; "they formed a community of scientists"
2: an occupation requiring special education (especially in the liberal arts or sciences)
3: an open avowal (true or false) of some belief or opinion; "a profession of disagreement" [syn: {profession}, {professing}]
4: affirmation of acceptance of some religion or faith; "a profession of Christianity"
Eventually the costs of running inference will catch up to us, then we will see. But LLMs are really expensive and it is possible that with the incredible amounts of code they generatr it might become too expensive for them to keep up with it. There should be some kind of equilibrium which might take a while to reach but I think knowledge work won't disappear.
However many people have rightfully been saying it for years before LLMs that many so-called software engineers had no business in this field because for a lot of them it was just a way to earn more money than peers. It's not an issue by itself, just a rational human choice but the fact that it was possible was just because of unhealthy economic conditions.
This works, until it doesn’t. I’m continuously shocked by these stories, where so many people put the future of their job/company in the hands of these agents after only a few months of existing.
I still constantly run into bad output from LLMs, from code to basic questions. I don’t understand how anyone can hand things over to something that is laughably wrong on a pretty regular basis, often in subtle ways that won’t be noticed by someone who isn’t reading closely and thinking critically.
They’ve gotten better, but I still regularly give them the old Nick Burns treatment, push it out of the way, and do it myself.
There's nothing shocking about this. The vast majority of software/source code is pretty terrible anyways, code that is full of bugs, slow to use, has little to no automated tests and very hard to maintain.
To the extent that it gets fixed or works at all, it's not because of competent developers doing rigorous analysis of the software, it's because either someone testing it or using it gets annoyed, reports an issue, and then that specific issue gets patched out.
If using LLMs to perform a similar function shocks you, then you should have been shocked already by the proliferation of pretty bad software for the better part of the last couple of decades.
So many criticisms of LLMs assume that people have been writing software very diligently, applying a high standard of engineering, subjecting the code to a battery of rigorous tests, passing it through a strict review process... and that does happen for some software, especially software that is commonly used, but it's not true for the vast majority of software developed.
AI is no good, but neither are people, isn’t a great sales pitch.
I think for small tools that people want to make for themselves, that’s great. Where I see a problems are when other people and money get involved. If something goes wrong, who is accountable? Claude wrote it, Claude reviewed it, Claude submitted the PR… yet Claude can’t have any real accountability.
I think small tools people make for themselves is realistically less than 1% of software produced. Most of the code, and - to the GP’s point - bad code, is produced in corporations with plenty of money and budget.
There is just such a tremendous amount of waste at every company, in that the headcount and software expands to fill the budget. I’m not defending Elon, but look at how much he slashed from X (80% or so?) and the company still has its core product functioning and an active user base.
There is a ton of software (especially internal) at essentially every company that also is low accountability before Claude. “Oh Ted built that but he’s working on a new important project. I understand it’s broken and that’s impacting you but we won’t be able to prioritize this until next quarter at least. Can you set up a meeting next month to discuss?”
Honestly the outcome for all of these LLMs is indeed is likely a higher amount of software with no accountability, but it’s also an improved ability to juggle more of that software to the same (realistically low) standard.
It's an absolutely phenomenal sales pitch to executives. A ton of automation is sold on the basis that it's probably not going to be as good as having a dedicated person do it, but that automation leads to much lower maintenance scales better, is more deterministic and reproducible.
I’m not sure how you can say something general about the quality of tests unless you mean by simply prompting “make tests” or similar.
Yes, I’ve experienced that those tests succeed, and the app still breaks trivially on first run.
What I mean is: you design the tests. You analyse patterns. You insist on making testable code (average code by humans isn’t, so neither is average code by LLMs unless you specify testability as a design constraint.
One way to get testable code is to mock all interfaces. This is usually expensive, but not difficult for an AI, because you can set the success criterion to be interface exactness of your mock for a series of plausible and somewhat extensive interactions.
The tests you can make with AI are as good as you can make them otherwise, you just save time doing them, which should justify making more extensive testing.
It's a really fun philosophical exercise to ask what it means for them to be "wrong." My perspective is that they are fantastic at association and generalization (of language and symbols in particular), but whether they're identifying the associations you care about or generalizing to the level of abstraction you're aiming for is a complete crapshoot. If you aren't checking and correcting them, and discarding the misfires, you will end up with a very pretty Tower of Babel.
One area where I feel safe saying they are “wrong”, rather than just going with a different assumption that was left unsaid, would be when it makes up API endpoints. It sees the general pattern in an API, then makes up an endpoint that sounds good, follows the pattern, but isn’t actually implemented.
I’ve also seen a lot of issues with co-workers using an LLM to write their readme files. I look at the readme for what return values I should get, go to use them, and get an error. I check the code, and sure enough, none of the variables in the readme exist. The LLM just through they sounded good. Things like this I would say are pretty objectively wrong.
> One area where I feel safe saying they are “wrong”, rather than just going with a different assumption that was left unsaid, would be when it makes up API endpoints. It sees the general pattern in an API, then makes up an endpoint that sounds good, follows the pattern, but isn’t actually implemented.
I remember seeing this maybe 6+ months ago, but using paid plans, RAG, and a high thinking mode has eliminated a ton (almost all) of those kinds of hallucinations. Open models and free tiers are not there yet though.
> I’ve also seen a lot of issues with co-workers using an LLM to write their readme files. I look at the readme for what return values I should get, go to use them, and get an error. I check the code, and sure enough, none of the variables in the readme exist. The LLM just through they sounded good. Things like this I would say are pretty objectively wrong.
LLMs don't co-sign the quality of PRs though — your coworkers do. It's not unusual for docs to get oudated and not be maintained enough in small codebases, but that's not an LLM specific problem.
I saw this, all of this happening years before ChatGPT existed, but with outsourcing to Indian dev shops.
You'd be shocked how often I see the meat-space equivalent of vibe coding!
"I trust the developers."
"You really shouldn't!"
The thing to realise is that there is no fundamental difference between outsourcing a development task to other human developers versus outsourcing[1] it to LLMs.
Either way, total and complete understanding is being sacrificed in the name of productivity and scalability.
It's just there's one extra layer of work assignment now, with ICs handing off tasks to agents.
What this has revealed to ICs is the BIG issue that has plagued all software development for decades, especially since outsourcing became so popular: Oversight is critical, and more importantly: authority can be delegated, but responsibility cannot.
LLM output is fine, as long as you review everything it does.
This is the same as any competent dev team manager reviewing PRs for quality, paying attention to critical matters such as security, adherence to high level design and low-level style standards, etc.
Some do.
Many never did.
[1] This doesn't have to be a contract with an overseas provider, by "outsourcing" I mean any variant of not-your-own-hands-on-keyboard. Any scenario where a customer or manager assigns tasks to developers other than themselves.
Even if / when it does work, the value being produced is reduced to the dollars paid to Anthropic or OpenAI or whoever. What are you even contributing? What’s stopping the ai provider from coming in and eating your lunch?
it was hype all day long and managers forgot that ai is tool and not some magic stick. tool like dewalt or makita. after ai went out i got expected from some collegues at company to generate 600 700 lines of code or more, i tried to explain i cannot read or understand whats actually happening that fast, but they were like just push, go, copy paste it. complete autodrive mode, insane. then i spend weekend fixing it, making me double mad. whats actually happening is retarded, cos of all stories out there managers thinking that claude generate perfect code, and u could make twitter clone in half a day...
Every AI coding project feels like working with legacy code. All the skills I actually use look more like managing a big messy, brittle black box codebase. It’s exactly how we would have inherited a big ugly codebase pre AI.
I think if you’re used to traditional green field development, and have never owned legacy code AI software engineering can be bewildering. If, however, you’ve been stuck maintaining legacy code, the skills serve you well
In AI development.
You’re constantly looking how to tame this ball of mud. Test it end to end. Break apart bits to test. You’re chasing where the brittleness in the system exists, and you try to create a testing and feedback strategy to gain leverage on that class of problem. That in turn turns to modularization and gradually more careful organization.
I find starting out you may look at code less. As time goes on, you descend deeper and use AI to do targeted refactors to account for more constraints. You leave alone what's OK to be slop, and hone in on what needs deep care. All along adding guardrails to constrain the big ugly beast and help LLMs stay on track with their work.
Same here. At our company, we've pretty much stopped writing code by hand. We hand the implementation to Claude and Codex now. Feels like the real skill is moving up a level: architecture, design choices, and knowing what should be built in the first place.
Software was never a precise occupation. It was a tool shed that obeyed the Pareto Principle: 20% of the people deliver 80% of the value.
This was the expectation because hiring was the primary goal, not product delivery. The industry could have fixed this by upgrading itself from an occupation to a profession built upon standards and credentials. That never happened because the 80% would become unemployable, which adds friction to hiring (the real business goal before COVID).
Now, that ship has sailed and there is no going back. The Pareto Principle is now a 5%/95% funnel because there is less incentive to learn to do the work. Good luck!
For the last 6 decades or so, a computer was a machine assumed to operate with high levels of precision and deterministic outputs. Such precision enabled spacecraft like Voyager 1 & 2 to travel billions of miles from Earth, staying on course, semi-operational and sending telemetry- 50 years after launch.
Now we have machines that, when asked to produce a paperclip, may instead produce a butter knife, or a banana, or maybe just a "try again later".
These modern "tools" are quite a different animal. They're more akin to roulette wheels that generate massive amounts of heat and CO2.
This is cope. sota agents produces what's asked exactly, usually it's the asking that's the problem not the result, improve the prompt and the output drastically improves.
I mean, literally the answer is that nobody knows. Maybe the robots replace us all. Maybe they shift those who remain into being some combination of Product Manager and QA. Maybe there's still a role for a technical overseer even in the medium-long run.
But it sounds like you're really asking about the state of the world today. If so, I don't think that ideal state is like your friend's company (or at least, as it appeared to be to you). It might be possible that you can make that "dark factory" pattern work (StrongDM seems to be doing it), but it would require infrastructure and discipline that I doubt they're mustering. Think about how CD didn't involve taking a sloppy build process with no testing or observability and just going straight to prod -- it required building up a lot of infra and discipline first.
But on the other hand, I don't think the ideal present involves artisan hand-crafting code either. I haven't written a line of code by hand in enough months that it would genuinely feel weird if I were to try to program that way despite decades of having done just that. That era's done with, and moderate normie practices right now today are more about supervising and guiding agents than about chiseling code into clay tablets.
What you're describing sounds like what many people in the industry are doing, and likely what most AI-adopters are doing. It scales until it falls apart.
The responsible and professional way to actually make AI work at scale is to build a dark factory. (You can search HN for a lot of good resources, start with Simon Willison and StrongDM)
Imo this will be the future model: a company puts a gun to your head, gives you agents, and tells you to figure out how to maximize the utility output you provide as an employee. They might put a token limit which incentivizes efficient token usage.
There's a lot of "room" here for creativity, i.e. the agents don't know how to milk the agents efficiently, which is essentially your new job. The agents might not know how to structure tasks so that the agents run overnight and run the proper experiment.
The difference between mediocre and 10x will increase. The more aggressive SV performance culture is probably going to become more mainstream.
Frankly, I think this whole model is way more burnout inducing. You're not really doing software engineering anymore. You're running this mental loop in the background of trying to multiplex between agents and mapping unstructured business problems to agentic work.
It's probably going to infect other industries over time. Software is the first big wave. I don't think people with computer skills who are good at computers will be screwed out of work long term. The tech industry has a lot of concentrated technical capital in the form of tooling and automation that other parts of the economy could significantly benefit from. Short term it looks bad, but long term, computers will become more and more dominant over the economy.
I don't think companies have yet figured out how to adapt their hiring, managerial practices, or internal incentive structures to reflect this. Most of what they're doing now is extremely crude and terrible for morale.
My profession is not, and never was, _programmer_. Lines of code—the actual text, is a means to an end, not an end in and of itself. I'll take heat for that here for sure. But do you think a carpenter considers himself "one who screws nails" or "glues joints"? No, the small minutiae of the job was never the job itself.
That's maybe wishful thinking from my part, but more towards like other engineering fields: Project engineers design it from scratch, everyone must speak architecture, customer and compliance at once, and we will have standards and "codes" drawn up by the end of this decade.
in the olden days (pre-LLMs) we would write high-level code.
the entire layer was high-level code and rarely would we ever need to peak into the assembly:
writing, debugging, architecting, reviewing, testing - all were done in the high-level language layer.
---
welcome to present day:
since we don't write code - we write intents, we also shouldn't review code either - we should review intents.
I don't review my code anymore. I ask the agent to generate markdown docs, graphviz diagrams, changelogs, audit reports, etc. I only review that.
I also ask it to write test and evaluate by whether the tests passed or not. I don't need to peak into the tests code - I can also ask plain english, pseudocode, control flow graph, whatever it is I want.
I can ask it to find errors or missing tests and improve that too!
code is like assembly now.
rare are the cases you would need to peak into that level.
I sometimes end up at or near this conclusion when considering the future.
Consider some software that was written by AI purely using markdown files. The spec was sufficient enough to classify all of the business logic, conditionals, etc... You might even end up creating "loops" that tell AI to do something over and over again. Some markdown files become standard, repeatable "functions" that are to be followed EXACTLY (determinism). Some markdown files become assertion tests. Heck, the markdown file might eventually invent some kind of "typing system" so that you know when you're working with the person "class", it's always going to have the same facets.
I love the concept of it going in this direction - we already had plenty of languages to tell a computer what to do, we've just generated MORE text at a higher level and made it less deterministic.
Just to clarify, I don't think it's likely that this is the end result, but it sure is funny to think about.
Yes, this is the direction I am observing. Ironically, I don't think anybody is happy about it and we keep saying that it is a tool and you need to verify everything, etc, but this is not what is happening.
There are tons of people who produce questionable code at a rate which is not really compatible with a thoughtful review, we have people with little engineering background pushing their changes (although there is a large pushback against that as the results are really bad even short term), as you said, there is an explosion of LLM-generated tests.
As soon as someone writes a next-level harness which tightly iterates based on the spec/plan and/pr pioneers some sort of acceptance criteria format that works, I think at that point SWE job will completely change. We are not there yet but probably not that far off.
I’m not a super experienced engineer career-wise ~5 years, so take my view with a grain of salt - but I’ve done work in full-stack, systems, gaming, extensions (web and ide), low level languages including assembly, and a small amount of embedded.
I spend almost all my spare time coding. And have done so for the last 5 years. So I consider myself capable of bringing most projects to fruition.
I roll my eyes when people say “AI sucks” “AI isn’t better than me” “AI doesn’t speed me up” - it’s either a load of shit, delusion, cope, high-horsing, or they are a Luddite.
I’m sorry but the rate at which I can work pre-AI and post-AI is insane (when not limited by bureaucracy). Yes the outputs and code can be terrible, but I can prototype 10 ideas in the time it would take me in the past to prototype 1.
However most of the LLMs approaches are fucking terrible, it gets it working but it’s pure spaghetti and I do all the architecture and usually most of the code. But I prototype ideas with AI. Like if you actually use performance monitoring and memory monitoring tools, LLMs have no fucking clue what they are doing and make slow bloated buggy shit.
But it’s great for blueprinting.
Who’s to say it won’t also be great at implementing too? I think it will be.
But for now it requires guidance and orchestration and I mostly use it to test concepts.
I did my first purely vibe coded completely hands off project the other week and loved the results! It was just for fun.
I see nothing wrong with something probabilistic. I think it is all about offsetting the risk and reducing the odds of bad outcomes. There is this concept of Defence in Depth, thus I assume some sort of binomial formula also applies here.
That’s realistic. If AI generates 100% of the expected result, the vast majority of people might think that understanding the code is useless or unnecessary.
With advent of AI, the software engineering landscape has been changed a lot. Writing code which was once a noble ("giving god like feeling") profession is not just a prompt away for vast majority of the tasks.
> "it feels like software development is going from a precise occupation that requires high degree of understanding to something probabilistic and offloaded understanding"
Well how much ever I agree with this, I believe in near future it will open more "expert" like positions who will suffice as orchestrators to not let the AI slop take over and make your systems either dumb or vulnerable or both!
From what you said: Not looking at code is bad, not because Claude can slip a few bugs (it can), but because LLMs tend to default to writing more code and features than needed, which isn't a good thing. I see a lot of people making 10+ PRs per day, but most of them are just going back to fix earlier PRs.
Claude always likes to "go big," for example, by choosing tools that can support millions of concurrent users or by adding unnecessary layers of abstraction that create more maintenance pain. I guess that's good for LLM companies, since more tokens are spent fixing the mess it caused.
Every time I enter plan mode for a huge feature, I end up cutting about 30-60% of the task scope before the LLM can actually start the work. I review the final code, and I still find things to cut. As said before "The best code is no code, or code you don’t have to maintain" [0]
- spending exorbitant amounts of time up front planning, surfacing every milestone, subtask, and individual change, burning tons of tokens in addition to man hours fixing minute but important mistakes or derivations despite explicit instructions, CLAUDE.md, memory subsystems, agent and skill instructions, etc.
- executing and reviewing results compared to the plan and finding even more mistakes and derivations from the plan often takes a lot of time
- the relative rapidity produces a lot of output for the team which stresses our lifecycle and introduces feelings the whole process is on the verge of flying off the rails
- individual developers have different expectations, definitions of acceptable, skills/experience to detect and deal with problems, and patience. I might spend hours to days meticulously planning and executing a ticket and another guy might yolo it in 30 minutes. Other than bug escape rate and tracking review failures I’m struggling with how to track people who are “doing it wrong” let alone telling them the “right” way to do it.
- growing exhaustion, lack of ownership and confidence, frustration, and a generalized feeling of endlessly fighting your tools but in a weird way they never seem to really improve despite all your efforts to do so
- taking humans out of the loop and letting the agents be more autonomous in hopes that we’ll reduce the bottleneck and produce better results has not helped.
- I find even myself fighting (and sometimes failing) the urge to give in even though the proposed or implemented solution doesn’t feel right. Scale that across your team
- experience has not really changed despite changes in models and harnesses
- there’s a deep feeling that I’m doing something wrong and fomo since so many people in the industry boast of incredible results. I probably am, but everything I’ve read about and tried has not really moved the needle much and it’s introducing another dimension of exhaustion and frustration
overall, I don’t feel like we’re being much more productive when you factor in quality and accountability (which should be a given, but this industry increasingly overtaken by a reckless philosophy of speed over everything else). I do think it has helped parallelize tasks, produce higher quality PoCs to explore more options and do it faster, offload joyless but necessary tasks that are narrow in scope and measurable, do exploratory work and act as a generalized interactive knowledge base, and make shallow techniques, technologies, etc. that you don’t yet have experience with. Maybe I’m just missing a critical component or two in the process (formal specification, etc). Maybe it’s growing pains, or maybe there’s a looming rot. Either way job satisfaction and confidence in my work is much lower than I would have expected.
Seems clear that the age of everyone and their dog getting a programming gig for easy money is coming to a close. What will be left (for the foreseeable future) is positions for very highly skilled software engineers who actually know the craft well enough to make good use of AI.
The industry is going to shift from hiring as many programmers as you can afford to hiring a small number of the best engineers you can find. AI can't replace an engineer's skill and insight, and I have yet to see signs that LLMs are fundamentally capable of such a thing. What is screamingly obvious however is that when a highly skilled engineer learns how to drive AI agents, that's when you get true effort multiplication. A real engineer can leverage AI in ways that an unskilled vibe coder simply cannot, because it turns out that building a house still requires engineering even when you have a nail gun. LLMs can write code all day but if you don't understand programming and engineering on your own, you lack fundamental tools to build software.
Sorry kids, buffet is closed. No more FAANG salaries for anyone with a pulse and a copy of VSCode. The future of the industry looks to lie with a vastly smaller number of much more highly skilled engineers.
What happens when those engineers age out and we realize we stopped training new ones? I genuinely fear for the coming generations of engineers. It's not going to be good.
This has always been a very different profession depending on where you work and what you're working on.
I haven't worked at a startup in over a decade, but the stories I hear now sound the same as back then. There's lots of wasted effort for mediocre to poor code destined to be rewritten or thrown away until there's enough investment to justify more work. At which point, "more work" just means more sprawling slop instead of fixing the technical debt rotting at the foundation.
AI just put a spotlight on the futility of trying to run before you can walk. Whether so many founders are going to stay in denial about it is yet to be seen. Statistics about any line of business says yes. This is how most businesses fail and most of them have to fail.
> it feels like software development is going from a precise occupation that requires high degree of understanding to something probabilistic and offloaded understanding
To me it felt like there were always engineers and vibers.
Vibers don't work systematically, never test, accept unknown regression, don't use git, and if they do, treat it like Dropbox, use terrible languages, have terrible habits. Vibers got a new tool, too, and it vastly increases the amount of slop. But the slop was always there.
The slop actually got better after vibers stopped writing their own slop, I have to say.
And vibers are less defensive about the particular slop they didn't write themselves.
"This is exactly why we built AINAScan — we found that AI-generated code passes all tests and 'works', but consistently produces the same 15 structural bugs: save functions that never write to DB, async functions with no await, parameters that have zero effect on return values. Linters miss all of these. The code looks fine until production."
I've found they optimize largely for the happy path and don't consider any (or enough) edge cases (e.g. what happens to everything downstream of this, if say, there's a timeout in this specific HTTP request.)
I find Claude fighting me when I point out things like that as well claiming its not worth it to worry about and when I point out the train wreck that would ensue by leaving some things in a weird state it flips its script: "I was incorrect about that..."
Folks will claim that's a skill issue but, its an issue letting the LLM run off without any oversight and it creates so much code you can't possibly review it all yourself, so like you've found, you hit a lot of problems in production.
AGENTS.md and friends help but I've found it ignoring rules in their as well, often and very frequently.
Personally what I've found to be the biggest win is:
1. Use AI to go harder not faster - use it for code reviews, second opinions, researching all the angles to a deep topic, but don't use it to pump out a whole app. Don't outsource your entire understanding to it (which is precisely what we do at my job today...)
2. Use it for the boring tasks that are hard to get wrong and can be easily validated.
Oh and tests... I've seen so many completely useless tests being generated. Any valuable test that I've ever seen claude create came from me finding a bug or missed edgecase.
imho programmers should jump into completely unrelated jobs (even unskilled labor) and discover how gawd awful all of the software is. Nothing gives you the user perspective like being the user. Then dogfood your way into a highly specialized product.
There is an amazing amount of complexity in even the dumbest looking job. It takes decades to see all the strange edge cases.
The people planning the work never have the full picture, if they did the job themselves the layer of management above fails to imagine it. The people doing the manual work match the offer by inability to explain how to ride a bicycle and not understanding how to plan or budget.
My personal experience: writing code has always been the easy part. AI does most of that now.
Understanding the problem and the existing system well enough to design the right solution, even with AI assistance, is a higher cognitive load. I’m doing a lot more of that lately.
I’m more productive, but also more tired. This may be due in part to the breadth of what my team owns, which makes my day a bit more context-switchy than other teams.
As others in this thread have noted, the situation is still evolving. However, I worry less each day about being replaced by AI. There has always been more work than available bandwidth in my experience.
What seems clear to me is that expectations around velocity and throughput will increase (are increasing). AI use will be required to meet those expectations. Learning to use this new tool effectively will be essential for career progression (and preservation).
> My personal experience: writing code has always been the easy part. AI does most of that now.
The only reason dev jobs paid more (by a factor of two or more) than pure solution modeling was because "writing code" was the hard part.
If you wanted to get paid just modeling the solution and handing it off to a coding team, those jobs were available for decades, typically called Business Analysts but few devs moved from dev to BA.
> Understanding the problem and the existing system well enough to design the right solution, even with AI assistance, is a higher cognitive load.
I've found that the act of physically writing refines my understanding a lot more than simply reading.
We don't typically expect a person to read a trigonometry textbook and then perform well on an exam. They have to drill problems to surface their misunderstandings to themselves.
My fear is that, with developers adopting your approach, they're "designing" systems in much the same way that a read-the-book-only trigonometry student solves trigonometry problems.
GP's "design the right solution" is a role between "programmer" and "business analyst" that got merged with "programmer" to become "developer" decades ago. That's where the high salary came from. It's been reemerging as "architect" now that "developer" has been watered down to include "programmer".
Perhaps solution was the wrong word for me to use here. It was intended to encompass the implementation details (abstractions, architecture, observability, etc)… All the decisions the engineers would normally make during planning and execution. Once I have that nailed down, the act of writing the code is largely mechanical.
That’s the source of my “easy” framing. It has always had the lower cognitive load in my experience. Now that I can offload the mechanical part to AI, I spend more time on the hard parts.
I still read plenty of code along the way, maybe less of it now because it’s easier to surface which parts of the code I need to read.
thank you for putting into words that which has been hard for me to describe — I’ve noticed the worse a dev was at their job the more high their opinions of AI seem to be. The subject textbook analogy (trig book in your ex.) is a perfect frame of reference for why that might be the case…
to further that example, many people with the help of AI are ostensibly copy pasting trig problems from the book without understanding the mechanics running through them and labouring under the impressions they’ve become closer to skilled mathematicians
There was a time back in the 1980s (and probably before) when "analyst" paid better than "programmer". The programmer wrote the code; the analyst figured out what the code was supposed to do to meet the business need.
In my view, "programmer" merged with "analyst" to become "software engineer".
Who hires “pure solution modelers”? I don’t think I’ve ever encountered someone like that.
> Who hires “pure solution modelers”? I don’t think I’ve ever encountered someone like that.
They're called Business Analysts, sometimes simply Analysts, and that's effectively their job - come up with a spec and give it to the software engineers.
I've never seen BAs execute that way. I don't think that is an accurate description of their role and its link to SWEs.
Agreed; typically (especially if a client is involved) I’ve seen creative and dev define and articulate spec and expected behavior, and BA documents it. Then, when it inevitably evolves, BA’s job is to capture the changed spec. The artifact is simply documentation as a client deliverable that’s then often never referenced or used for anything outside of maybe complaining that a feature doesn’t do what the spec claimed, or maybe as context when the client takes their whole project to another vendor to be rebuilt from scratch lol
Aren't they simply called "consultants"?
It’s still lower level than a business analysis though so it’s not the same
> What seems clear to me is that expectations around velocity and throughput will increase (are increasing).
This is why I don’t understand why folks around here (that are employed) feel so enthusiastic about AI. We are going to be working more in a rush to produce stuff that we won’t be feeling as proud of as we did before AI. Unless you were in the profession for the money, the delights of crafting software simply go away and AI is pushing us closer to be just… well, I don’t know, but I don’t like it. Sure thing, if you are a CEO, this new state of things must be wonderful
I didn’t know modern (2015-2026) software engineers were making such a strong distinction between “writing code” and “designing solutions”. It’s not the majority of engineers “design” and then hand over the implementation to others (at least Ive never seen that before).
From my experience, a typical software engineer needs to understand the business (e.g., knowing who your users are), design a solution (e.g., we probably need an event-driven arch right here) and write the code (e.g., we should use select for update skip locked to avoid over claiming). They all are equally challenging imho
> My personal experience: writing code has always been the easy part. AI does most of that now.
That's exactly why I don't have AI writing my code. It is doing the easiest part of the job (making symbols appear in the text), which isn't actually valuable to me. A good tool should help me to do hard things, not easy things.
I seem to only have discussions about architecture with it.
Agree. Also, there is a lot fog at the moment. AI generates more code, we need a lot of markdowns now to teach it how to write "good code"... and <insert here a lot of AI processes>. But at the end... a programmer has to take ownership of that code and responsibility, meaning: reading A LOT of code and/or coding more code.
Spot on, in my experience.
exactly like this https://x.com/TBreakyour85306/status/2070811834131546196?s=2... An experienced coder can do faster, a business dev can launch faster, but a rookie coder without business cannot
Responding to my own comment to add that I think this moment favors the curious and passionate. None of what I wrote above is a complaint. I’m having more fun now than I have in a long time.
Coding is the easy part, huh? Sure, buddy.
I'm a Senior Freelance Programmer, I can see many of my past and present clients moving towards the exact path you described. I keep warning them during meetings that Claude model isn't sustainable for long, eventually the VCs will come for their revenues and Claude will be forced to close their access to all but the most enterprisey ones with deep pockets. The mere electricity cost for that kind of high level reasoning and abstraction can't be subsidized forever. However, there are other forces which pull them towards Claude and AI workflows. Most of the clients are in a "wait and watch" mode right now, using LLM assistance for code generation but not fully depending on them.
Before LLMs came, there used to be the technical debt to deal with in a project, now there is also the added cognitive debt which is way more subtle and impactful long-term. If your source of truth isn't source code but a prompt (or even a series of prompts with branches) and the executor of prompts is a non-deterministic agent, I think you've already lost the battle there.
I fully agree with that. Well said.
You're standing on the shore, and your clients are having fun in the water. The tide is going up, and you're screaming at your clients "come back! it's not safe". And so, they show you the face. You appear to them like the boring guy who's not fun to hang out with. Eventually the tide is high, there is strong current, and they are being swept away further and further from the shore and they are panicking : "pyeri! help us! please!"
People (the non tech people, the MBA people) don't want to hear what you, the tech guy has to say. You're the not fun guy. Stay in touch until they do need you and say : you were right. That's the day you charge them a dear price for the service.
AI is still at the bait stage of rollout. They subsidize it, they want you to get hooked onto it to the point where you cannot do without it. Then only, they start to charge. I used google code assist for around 9 months. It was free. I would ask it questions from time to time, to help to fix bugs, and to avoid to spend an hour browsing SO. Now, it's around $30 per month. They are losing too much too fast atm, they have reached the stage where they have to start to charge. Another one of their strategies is : IPO. Once they (openai/anthropic) are listed on the nasdaq, you will pay whether you want it or not (via your exposure to the nasdaq/S&p500 with your etfs).
> Stay in touch until they do need you and say : you were right. That's the day you charge them a dear price for the service.
That assumes OP will still be in business if that day even happens. Odds are that cheap AI access will be around for longer than freelancers can remain solvent.
Using today's model prices as a rebuttal is a very weak argument.
Two years ago, SOTA was gpt-o1, and it was much more expensive than Fable. Now, for $4,699, you can easily run a much smarter Qwen3.6-35B locally with DGX Spark.
Think about where we are. This is an era where a new SOTA arrives every two months. It took LLMs only about 18 months to go from chain-of-thought reasoning to disproving the unit-distance conjecture. chatGPT itself is only three and a half years old.
DeepSeek V4, released two months ago, is almost as cheap as the electricity costed, has the ability to being absolutely a top-tier model in 2025 standards.
You ignore that Claude are not alone, tech progresses and reduce costs, and there are always the Chinese alternatives which are becoming sufficiently better over time.
The electricity cost per unit of machine “reasoning” is vastly less than the cost of salary for human reasoning. That’s a weak argument. You should focus on the second part… LLMs (at least today’s) don’t build simple solutions, and the complexity they introduce has a cost.
> LLMs (at least today’s) don’t build simple solutions ...
... by default.
Not sure why this is downvoted but you truly can get a lot of mileage out of asking Claude to simplify things.
Definitely. One of my fav techniques is to ask an LLM to simplify something by 90% or 99% if it looks overly complicated. Or asking the output to be critically reviewed by another agent too.
> Claude model isn't sustainable for long, eventually the VCs will come for their revenues
This is cope. There are multiple open models that are already good enough and cheap enough at API rates to sustain this.
As a Freelance Programmer, are you even getting consistent clients at decent rates? If so, how are you getting clients consistently and how do you convince businesses that you are better than AI?
I think a lot of developers probably FEEL like they are in super mode, but in reality they're just letting Claude drive the boat and they get to wear the captain's hat.
Maybe I'm wrong. Maybe AI Natives will be faster in the end and can build / do more, or building software really is a dead field - but I noticed that I was losing my brain and had to get back into the seat.
There are definitely great use cases for agents - but I think a lot of us aren't flexing our brains anymore and, even worse, some devs believe they are. I urge every developer to put Claude down for a day/week... see how well you can do in the "old" ways. It'll still be here when you get back, but my guess is it'll be a rude awakening.
i understand your concern about relaying too much on ai tools like claude. while they can enhance productivity, they shouldnt replace critical thinking and problem solving skills that define good software developer so yea taking break from ai and working on "old" way can help sharpen those skills. i think its important to strike balance between working on new/old way but i also have feeling that everyone is addicted and trying to develop 24/7 cos someone might "steal" their idea. like theres some kind of imaginary race and if u dont code for 1 day with claude (even if it is nonsense) u wont end up first...
These are people who don't understand the job of SWE.
Look, the job of a medicine doctor, or a plane pilot, have largely been automated. The doctor could rely on google searches, or even AI, to answer your questions. The pilot can trust the auto pilot. Yet, the doctor who does advanced stuff (surgery) has no shortcut to mastering his skill : he still has to go through 10 years of studies + years of experience under the supervision of a senior with 20y of XP. Similar path for the plane pilot.
And the same reasoning applies to the SWE. AI allows to : delegate the repetitive tasks, generate the boilerplate code, fix time consuming bugs, to focus on more meaningful stuff.
AI is a tool. It's an additional layer of abstraction. The winners will be the guys who are passionate, who still put efforts to master SW, who still put efforts to remain up to date with the regular updates (new releases, new libraries, new approaches...), and who understand how to use AI the right way.
All those guys who 100% rely on AI do is help big tech cover their massive costs for the deployment of AI infrastructures. Big tech does need those guys.
Imagine the auto pilot fails for some reason, during a flight. There are 400 passengers behind. This is a minor issue for the trained and experienced pilot.
What do you do, as a SWE, when tomorrow, anthropic/google/whoever, tells you : "we can't keep running at a loss, our prices for AI have to reflect our costs. Your monthly subscription for Claude is now $500/month". Or there is a power shortage and for a couple of days you cannot rely on AI, you can only rely on your brain to deliver this feature you committed to deliver tomorrow ?
>Look, the job of a medicine doctor, or a plane pilot, have largely been automated. The doctor could rely on google searches, or even AI, to answer your questions.
And clearly you are not someone who understands the job of a physician.
I have had some truly spectacular results that still kind of stagger me in the last few months using Claude in my hobby projects -- but even though Claude insists on trying to slip its name into the git history as credit it's not Claude -- it's me. Someone who has studied CS and software engineering for decades will craft different prompts from someone without that background. A suggested axiom: there is nothing I can build with Claude that I could not build myself with my current level of CS knowledge, assuming I had infinite focus and time. In my hands it can go as far I could anyway, and no further. (But it is faster!) My experience bears that out so far.
Fair enough but speed, especially the kind that comes with LLMs, is fast enough to open new ways of working and doing things. We don't have infinite time and if there's something that can give me multiple, for example, UI suggestions in a minute which I can pick from, it's a different way of working than sitting with a UI designer for several hours have discussions. So, while I agree with you in theory, I don't fully agree with you in, what I think you're implying, when it comes to practice.
> hobby projects
Unfortunately despite being impressive for solo stuff, such results don’t scale to software you’d give to others.
Claude writes probably 95% of our code now, fintech, amongst top 5 in the world in what we do. I am 100% certain we're not even at the forefront of using agents for coding compared to some others.
It definitely can scale.
Are there any code reviews? Or is AI reviewing code also?
We still review everything. And we guide by planning, prompting, speccing.
So we're not actually much faster at the core code, because reviews still take time. Ultimately, we're on the finance markets and we have regulatory pressures and I, as the human, am responsible for putting the code out there.
But we're freeing up a lot of time to get other things correct. We have n x more metrics now because plumbing in basic stuff is now trivial. We now have dozens more tools and skills to help analyse issues (e.g. why this price and not x), answer questions, etc.
I now have skills to scrape logs, download unpack and scape our bus persistence, link to kdb, and so on, all in my claude prompt, joining it all together and the AI is figuring things out. I can diagnose things, I don't know, maybe 100 times faster?
It is revolutionary, and I am highly sceptical of the motivations of people who keep saying otherwise.
When you review everything, do you understand every line of code before approving? Do you make it rewrite code that is too abstract or unclear for future humans to understand? Does AI write the tests and do you review those with the same diligence?
I don't disagree that it's revolutionary in many ways, but I am seeing lots of companies make very costly mistakes by relying too heavily on AI without fully understanding the code it writes and without fact checking its outputs by a human.
Yes we understand all code merged. Yes, I have coding rules and standards that the agent follows to ensure it writes code in virtually the same style as the whole team does. Someone isn't going to let my change be merged if they don't understand it.
My hunch however is that in a few years we're not going to be reviewing as heavily as we improve guardrails and can trust the AI code and review cycle more. I'm not sure what to expect for my career at that point.
> Someone who has studied CS and software engineering for decades will craft different prompts from someone without that background.
This, to me, is the biggest differentiator. In terms of results, there's a huge yawning chasm between the person who says "Claude make me a $thing" versus the person who puts in the effort to lay down the overall architecture, gives some thoughts to libraries and dependencies, performance trade-offs etc, and only then begins prompting.
Knowing how to implement Djikstra or a linked list by heart is no longer important. Actual software engineering skills are more important than ever.
> Knowing how to implement Djikstra or a linked list by heart is no longer important.
This was never important. The important part was always knowing when to use them.
Even more narrow - you only need to know when to consider them.
I only ever bothered remembering enough of any algorithm to know my options and a few rules of thumb. If I ever actually need to consider the details of the algorithm, I certainly need to spend a lot more time thinking through the problem and its solution. Knowing a specific algorithm well enough to pump out in 15 minutes is a party trick that is as useful as being able to change a tire in 3 minutes flat. A great time saver that will be functionally useful maybe 3 times in your life...
>The important part was always knowing when to use them.
Two things can be true simultaneously. I think there was a time when deep familiarity with implementing algorithms was important.
always was. Still is.
It is for coding interviews
The gap is closing; a shitty wannabe programmer will eventually learn the structures one way or another. Agentic coding just got many new people involved, and these new people create noise.
Low-skill work that used to be outsourced will go to cheaper LLMs, unless wages are depressed enough / running costs are high enough to keep using humans as cogs in the machine. This will also consume a ton of small-scale things, like personal-sized automation and small-business customization of better-crafted things (stuff that normally wouldn't be paid for in the first place, or only extremely rarely). Some will obviously exist, because paying someone else to farm out a ton of mediocre output with LLMs is still worthwhile sometimes, but it's going to be gutted as a general statement.
Especially with prototyping-style work, LLMs are clearly good enough for a ton of business-oriented proof-of-concepts, and that line of work is essentially dead. Unfortunately a lot of mid-tier art falls into this category as well, particularly because execs very clearly can't tell good art from bad (on a "customers like this" scale, with functionality being the judge, which is fairly objective. not a subjective "this is good art").
High-skill work is still necessary, but it's hard to tell if it's actually going to be more important (because skill is obviously still needed for actually-good results, and I honestly see no evidence that this will change with current tech) or less (primarily due to less demand, and it being significantly harder for non-skilled to judge skill when everyone can prototype something seemingly-impressive in a weekend). Some will very obviously continue to exist though.
Whether this means "high-skill people are going to be fine, stay the course" or "<10% of high-skill people will be fine, you had better be scrambling right now or looking for a new line of work" is... much less clear.
It’s like how google translate replaced the low end but we still have human translators for high end stuff
"Computer" use to be a job title. So no, I am not optimistic about the future of most programmers, maybe even all programmers.
One possibility is that software starts to look more like traditional manufacturing.
The machine is the company’s core asset. The engineer only needs to know how to operate the machine well. Once that happens, the barrier gets much lower, need much less people, and the job naturally become much less valuable. Some parts will still need to be done by hand, of course. But only a very small part. It is like old factories. They used to need lots of fitters, at all levels of skill. Now you only need a few of the elite ones.
AI is the CNC machine of the software industry.
The more pessimistic future is that, maybe five years from now, the best programmers will look at AI the same way the best Go or chess players look at AI today: Like KeJie said, "I don't even know what I am trying so hard against." We now have a new SOTA every two months. It just took 18 months for LLMs from reasoning models to disproving the unit distance conjecture. ChatGPT itself has not even existed for as long as a college student spends in university.
In any case, we have already passed the point where this can be rolled back.
Maybe ten years from now I will be leaving a comment saying that "programmer" used to be a job too :-/
Programming is the low-hanging fruit for AI. Open source and knowledge sharing have given it huge amount of public, high-quality training data at a level other industries can hardly imagine. And almost everything in programming can be tested and verified inside the computer quickly in a closed loop. No robot arm is needed.
The main weakness of current LLMs is still that they are static: They do not really change themselves through use. Harness tools are just elaborate ornamentation on top of prompts. LLMs are frozen at the moment training stops. Once we get models that can change their own weights through self-feedback, then maybe AGI really is on the horizon.
Thinking optimistically: I may be lucky enough to see it in my lifetime. Maybe by then, people will be able to live more like human beings, instead of organizing their whole lives around work :-)
A well-equipped local-AI-capable machine is already much cheaper than a CNC machine -- and will presumably get cheaper over time, RAM prices notwithstanding.
I'm not sure the comparison works if individuals can afford these machines themselves and don't have to commute to a factory to use them; I doubt employers will serve as either gatekeepers or sole providers of access to AI.
Your comment makes sense. Today's DGX Spark can easily run qwen-3.6-35B, which is indeed much stronger than the gpt-o1 two years ago. The future is hard to predict, perhaps the bigger issue is that while production capacity exists, where the demand will come from.
Thank you for your comment. I enjoyed it a lot. Good food for thought.
Your analogon is a bit leaky abstraction in the sense that it misses out on the broad stastical nature of LLMs. However, I find it is a good way to illustrate the potential industrial transformation.
It is hard to say what the future will bring. The original AsK HN post is definitly an omen for things to come.
> AI is the CNC machine of the software industry.
CNC and other factory automation have eliminated innumerable jobs.
What are you writing that Claude is actually writing all of it? Every time I get past the green field stage, I just end up throwing out what it writes half the time since its trash. Claude seems really great at fix this unit test, generate this boiler plate, take this uml and build this framework out. But when I am doing refactorings, or implementing things that are beyond monotonous, I end up writing it all by hand. My best luck is still do the design, query AI for possible choices, sketch out the framework of what I am writing, have AI critique my plan, and then have AI design individual methods, then fix what it writes.
> What are you writing that Claude is actually writing all of it? Every time I get past the green field stage, I just end up throwing out what it writes half the time since its trash.
For the current state of frontier models, you need to break the steps down so that the LLM understands a process like what you might go through as you expect it (which is often different for everyone).
i.e., get it to agree to a spec, then get it to agree to a build plan, agree on unit test signatures, UI etc as needed, then let it build, ...
"Prompt engineering"
What role do you serve in this process?
I can take all of those steps, turn them into separate skills, then give them to a product manager or business analyst who makes half your salary, but has far more knowledge about the customers needs than you do.
A business analyst or product managers spends most of their time in meetings understanding customer requirements. Now they have to find time to build the project and fix bugs?
The business analyst use to hand off details to another person who would define detail technical specs like database fields names, type and size. Then the programmer would implement it.
the creative inputs to the whole process and judgment aspects of telling it how to refine and edit
>the creative inputs to the whole process and judgment aspects of telling it how to refine and edit
Why does that require an engineer? I think a business analyst or product manager could do that just fine.
What you say could be theoretically possible, but it's probably an issue with your usage of if. For eg: if any of this hard non-promptable project is available on github, or you've seen this problem in any large scale github project, you can share that. I've rarely seen a repo and a problem that claude can't chew through with the right prompt.
People keep saying things like
> it's probably an issue with your usage of if
> I've rarely seen a repo and a problem that claude can't chew through with the right prompt
> a skill/PEBKAC issue
But then I remember how Anthropic couldn't fix the flickering issue for many months. It just does not compute.
Is it that people working at Anthropic can't prompt and it's a "skill issue" too? I mean, the terminal does not flicker in a lot of other complex TUI apps that I use every day - Midnight Commander, Emacs, tmux, etc. These are open source, Claude could be prompted to "just do what Midnight Commander does". So what is it?
Opencode had the same flickering issue not too long ago and they fixed it by switching from ink to opentui if I am not mistaken. So a solution is possible and known. Antropic just doesn't seem to care.
What does a random bug in one LLM's frontend app have to do with learning how to do prompt engineering well?
Because it proves that even the greatest prompt-engineers in the world are unable to vibe code their way out of a simple bug. The fact that this example is a small, annoying, random bug that is relatively harmless does not mean that the next bug won't be as harmless or even as apparent.
pretty big leap of faith there
I mean this with no disrespect, but
> Every time I get past the green field stage, I just end up throwing out what it writes half the time since its trash.
Is a skill/PEBKAC issue. You still need to exercise engineering best-practices like decomposing work to the smallest unit before taking a task on, brainstorming design first and implementation last, clearly defining your success criteria and requirements before beginning any work, etc.
I'm on a >10yr old codebase and have been able to get my org to orchestrate entire features, fully unit tested, e2e tested, storybooked, from scratch without touching an IDE. Refactorings and the endless mountain of 80% completed migrations from one pattern to another are now trivially able to offload.
Point your SOTA de jeur at the original docs, a few of the original examples/PRs and have it draft a skill describing the work, the scope, and the success metrics. Iterate on the skill with the main agent by subagenting to test the skill until you are happy with the result and it mostly gets it right with the guardrails you've defined. Again - keep the scope extremely small. It gives much less rope for the agents to hang themselves with and it is less cognitive load when you have to review/test the PR.
Then set up a reasonable cadence for it to execute an autonomous thread on and review when you get comfortable.
----
The issue I've been running into lately is simply that we've got so many PRs coming in that actually doing thorough human reviews on them is not sustainable relative to the rate the team is creating agents to open them and people (especially juniors and mid level) are getting burned out by essentially having entire days where they are just doing code reviews.
I think it’s becoming more and more performative. We’ve never been less focused on the actual product — the software — than we are now. The focus is increasingly on how someone generates code, despite that not having much to do with the product.
The software is not getting better. Generating code faster does not result in better software. Software continues to be slow, unreliable, complex, and counter-intuitive. AI has not improved on the metrics that matter.
AI, as amazing as it is, has not actually changed the process of software development and as a consequence, the resulting software has not changed. The job hasn’t either, except insofar as you’re judged for tokenmaxxing.
compare this to Electronic engineering, we are not making chips by hand, It is impossible to squeeze too many transistors in such a small space, we just create the circuit designs. I believe writing the code is heading in the same direction as well, you don't write too much code now, but you have to design the architecture and connect things. But it does not mean that you don't need to understand the code, now of all the times people who understand code are more important. Many below par devs will loose jobs for sure.
The profession has already changed. For the past eight months, AI has been competent enough to code like the best human programmer, but strangely, the software isn't any better yet. Everyone has lost sight of what the profession truly is. It's not just about coding; it's about software engineering. Our role is no longer that of programmers, AI has taken over that role. Our role is that of engineers who manage programming agents. Every attempt to have AI develop a medium-to-large project fails because the goal is to solve everything with a magic four-line prompt. We're forgetting the structural aspect, the engineering side. We must treat the tool as just that: a tool. The direction and responsibility remain in our hands. It's not about reviewing the code line by line; it's about ensuring that the product faithfully represents a well-planned engineering intent. That's why the concept of AI-augmented Software Engineering is so important.
> AI has been competent enough to code like the best human programmer
It’s really not. Opus 4.8 can’t produce good software design and it still makes straightforward implementation mistakes. Two errors it made in one day for me recently: it built the Cookie class I asked for without a name field—cookies have a name and a value—and it neglected to handle a case where a database could have multiple rows with the same id, just returning whatever came back first.
The “best human programmers” absolutely would not have made those mistakes. At worst, they would have asked if I really meant what they thought I meant.
I understand your point, but what you're describing is exactly the kind of mistake even the best human programmer could make in a poorly managed environment. I'm concerned that since AI emerged, we've overestimated our programming abilities. The comparisons we make between our own work and AI are based on an assumption of absolute perfection that doesn't exist in reality. Bugs aren't an invention of AI; they're ours. All modern software engineering, testing systems, version control systems, and so on, were developed through years of dealing with our own mistakes. We don't make systems fault-tolerant by understanding that failures are external to our work. These failures are our doing, and now they're AI's doing too. We have to deal with applying to those agents the management that we previously applied among ourselves. The example you provide is very good, because you yourself, with your human mind that solves problems, suspect that the origin of the problem was poor communication, and you are very likely right, but just as if it were a human error, the programmer is responsible for their faulty code, but you are responsible for poor process management, and yes, the same applies to working with AI agents.
Sorry, I have to disagree. People often react to criticisms of AI with “but people also make mistakes,” but that’s a whataboutism fallacy.
The statement was that AI is as good as the “best human programmer” and it’s quite obvious that it’s not. It makes inhuman mistakes on a regular basis because it’s not using human thinking. Blaming those mistakes on poor management is just sweeping the problems under the rug.
I don’t know the best way to work with AI, but I do know that we’ll only discover the best way if we’re honest about its capabilities. That includes not pretending it’s as good as the best human programmers.
I suppose our opinions stem from different experiences. I don't expect AI to do all the work with just a paragraph of instructions. Some people do, and they get very poor results. I design large, complex systems based on microservices, and so far I haven't encountered any of the obvious and glaring errors that other users report. For each project, I've spent two or three weeks working on thousands of lines of specification documents, user stories, plans, and task lists, using DDD. My prompts consist of dozens of files with 10,000-20,000 lines in total. Because the implementation tasks are extensive and atomic, AI has worked very well for me in solving them.
My experience shows that AI can program like the best programmers; its code is very good when given precise instructions, just like a human. I've encountered problems elsewhere, such as anti-patterns in unwired modules, which are "large-scale" implementation errors. I'm resolving these thanks to an open source tool I'm building for AI cognitive governance, and it's yielded excellent results for me. The code produced at both small and large scales is high quality.
In my experience, people experiencing gross AI errors are doing so because they aren't giving it precise instructions. And by precise instructions, I don't mean a highly refined prompt or "vibe-coding"; I'm talking about instructions thousands of lines long, just like the ones we create when developing with human teams.
If two people are using the same model, and one reports that the AI "neglected to handle a case where a database could have multiple rows with the same ID", while the other says they can develop a huge microservices system with multiple databases without any major issues, perhaps one of them isn't using the tool optimally, based on my experience.
Yeah, your experience is definitely different than mine. When I’m working with human teams, I don’t spend weeks giving them thousands of lines of precise instructions. We work incrementally, having fairly brief conversations to make sure we’re on the same page about the tasks we’re tackling, and then letting individual pairs work out the details of each task… which they do, because they’re experienced professionals.
For example, the project we were working on was to add support for reading a session cookie to a codebase that, up until now, had used a different kind of auth. Fairly straightforward, everybody knows what a session cookie is and how it works. In about 10 minutes, we decided on the big picture design elements (how it was going to fit into our existing system, what we needed to add/modify, etc.) and the corresponding tasks.
One of the things we wanted was an “UntrustedCookie” class to represent the cookie. It was meant to follow a pattern we had already established for other user-controlled input. Our HttpServerRequest object was going have a new getCookie() method that returned it.
This would have been about 30 min of work for a pair to implement, including tests. It’s pretty trivial. No further documentation is needed.
Anyway, I’m glad AI is working for you. My experience is that it often fails, and does so in ways that experienced humans don’t.
Exactly, that's precisely the point. They're different experiences. What I achieve now with three weeks of theoretical work, other teams achieve incrementally over several months in iterable work blocks.
The interesting thing is what you mentioned, that "no further documentation is needed." In the industries I work in, it's mandatory (with or without AI, and it's been that way for many years) to have everything fully documented from the design process onward. For me, it hasn't been difficult to work this way with AI because I know and have practiced the discipline of documenting decisions for a long time. For my clients, it's an essential accountability requirement.
These documents now have a dual purpose because they now serve to manage cognitive discipline too, so that agents do a better job than they would with vibe coding. Because without that discipline, what you say is absolutely true: AI agents do a terrible job and only hinder the good workflows already adopted by professional teams.
This is what I'm seeing at my company as well, "software development principles" are out the window. People have forgotten all about "Second System Syndrome" too, docs, tests, code, design - all LLM generated.
I don't like, I prefer to use Claude/Codex as an aide, not to let it take the wheel entirely but I don't really feel like I have much choice in the matter.
I've posted a recent article about the future of software development https://saturnino.substack.com/p/out-of-the-loop?r=7eqhw&utm...
Basically, in a decade or so, we'll be completely out of the loop in software development; even this title won't exist anymore (like the 2000's webmaster). We'll still be around, but with different roles.
For what it’s worth, I find comments and articles with assertive predictions like this difficult to take at face value.
I don’t even disagree with the premise, but it shifts the burden of assessing likelihood back onto the reader, so it doesn’t really add much value to me.
I think the genie gets put back in the bottle, at least partly.
I don't think the future is massive data centers running at a staggering loss to generate questionable code.
The future is rethinking IDEs to have local models work in partnership with the developer to ease tedium and catch mistakes.
A model that maintains a visual, zoomable mind-map of the entire project, with two way binding. Code can be created visually or textually, same with data flows.
Project structure and architecture are presented in high-level ways, that can be easily altered and refactored with almost zero tedium.
I think we start using AI for what it's good for: pattern matching and transformation, and stop trying to make it reason and pretend like it's a human.
Once we, as an industry, figure this out we'll unlock a massive boost in quality and productivity, but it looks like there will be some painful times ahead before everyone realizes that the token extrusion machines are only increasing the total cost of ownership, and they are being used incorrectly when we try to outsource our thinking to them.
I think there's an enormous opportunity to build these tools right now, and that whoever nails it will win.
It's disappearing. Even if models stop evolving tomorrow, there's still enough potential in the harness improvement to reach the point where anything 99% of us know about software engineering is useless. How many humans will be involved in creating software after the dust settles is anybody's guess, but I wouldn't bet on it being anywhere near the current level.
There was a reddit thread earlier very similar some interesting comments there too:
https://www.reddit.com/r/technology/comments/1ueidyv/softwar...
> I had an interview where I was asked the obligatory “what’s your Al workflow” and I said I use it for searching documentation and writing small functions or boilerplate that are tedious. Then I was asked whether I use Cursor. I said no, and immediately was told that “I’d be a better programmer if I used Cursor”. I have 13 years of software engineering experience, and was talked down by an Al startup with no minimal viable prototype. Then I was told I did not have the experience for the role. I love this timeline so much
I will just say, if you are any good at programming and have experience using agents, you're in the top 0.1% of the world in adoption of a critical new technology.
It may seem hopeless as a programmer, but imo you'd be much better off reframing your situation re: the above sentence.
Iunno, I feel like being born in a first world country did most of that "top 0.1% of the world" work. That sentence works the same with and without AI/LLMs.
Among peers, I feel like I am top 20%? 30%? maybe, by being a good programmer who is adept at agents. A year ago was the 0.1% point, this stuff is spreading like wildfire. A year from now I think it's going to just be de rigeur that these are our tools now.
Worse, any edge I have from working with this stuff for years is quickly dulled. The tools are evolving fast. My tricks from 3 months ago have been eclipsed.
"Well, in our country," said Alice, still panting a little, "you'd generally get to somewhere else—if you ran very fast for a long time, as we've been doing."
"A slow sort of country!" said the Queen. "Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!"
Maybe if only you ran a little faster, you'd outpace the rapid advancement of automation! There's fewer jobs now? Malnourish yourself until you're a running skeleton to get that speed advantage. More people competing for the same opportunities? You can't afford breaks anymore, just run, day and night, doesn't matter where, move. Thousands of people still outpacing than you despite all this? A true self-starter strives to dedicate their whole life, their existence to competition, you must give everything short of death to reach the coveted peaks of temporary employment.
Is this the world you're excited to be living in?
It doesn't matter what you're doing, there's always a trade off to taking a shortcut and rarely does the price not need paying.
We're seeing lots of code being ~written~ generated, deployed, checked (tested manually), then shipping it as done. Fine for the simplist of things, but in a complex system unintended side effects are far more common.
I feel like the system analyst role is going to make a resurgence in the coming years. Once the domain knowledge is lost, there's going to be a need to re-discover it and understand what should be happening and what is happening.
Going against the grain - i don't think all but the most expensive (and non critical) SaaS products are going to be replaced by an in-house system. If you're company of 100 people is spending $12k a year on HR software. Building and running it yourself isn't going to save you 12k and in reality it's going to cost you headcount for someone to manage and maintain it. Mattermost exists and people still pay Slack $200 per year per user when they could just roll out Mattermost "for free".
My impression is that smaller companies, that depend on rapid prototyping to gain clients, exert a lot of pressure onto their devs to use LLMs. At least that's the situation in the companies some friends of mine are working at.
I'm in a slow-moving, much bigger company. Lot's of talk about "AI" here and we can use copilot if we want to, but there is 0 pressure. I'm in a small team and one colleague uses copilot often. In the beginning there was a minor conflict between him and me, because I found the quality of the LLM code unacceptable and had to ask him to review it more carefully. I think that's settled now, but it makes me sad how a once motivated colleague now seems to try to cheat his way out of work.
I personally find it incredibly boring to write copilot prompts or read its answers full of boiler plate and sycophancy. I don't understand how anyone would want to replace the cognitive work of programming, that I find enjoyable for the most part, with the cognitive work of "talking" to an LLM.
Anyway, I think it will be like this at least for a little while longer: only vibe coding allowed in small companies and less vibe coding the bigger the company is.
But before vibe coding can take over the slow-moving big companies, all the accumulated technical debt will come back to haunt us and vibe-free software will be the new fad. That's what I hope at least.
Sadly, the folks vibe coding the massive projects also think that any technical debt created can also just be vibe coded away too...
I think it'll probably split.
At the high end, there will always (or at least for a fairly long time) be a subset of work where AI can't do everything itself. Perhaps the framework or language is too new, or its built for hardware that's only just become possible. Perhaps the company is worried about security issues resulting from letting LLMs access its systems, or needs a human in the loop to take any liability. Perhaps the tech needs a level of performance that an AI might struggle with, and which a longtime engineer with a computer science background may be better at dealing with (like stock trading systems or something).
This will pay very well, but probably only provide enough jobs for 5-10% of the current software engineering workforce.
Then there will probably be a large number of companies where AI does most of the work, but where one or two people will probably be kept on board to guide it in the right direction/take care of issues. I suspect a lot of less technical/cutting edge companies in more 'traditional' industries will be in this camp.
Finally, a lot of work will just be outright replaced by having an LLM take care of everything. This isn't viable for FAANG companies or fortune 500 level ones, but the average mum and pop business could probably just replace its entire development team with a Claude subscription. I suspect a lot of web development agencies and lower level jobs are just going to vanish.
So, yeah. High level bespoke work where every microsecond is king? Stays mostly the same, albeit with some AI usage to handle the boring stuff.
Basic brochure/shop/CMS site development? Claude and co take over almost entirely.
Relevant:
Writing code versus shipping code: Productivity effects across generations of AI coding tools - https://cepr.org/voxeu/columns/writing-code-versus-shipping-...
I think frontend will be dead in next years. Now, my company doesn't hire frontend developer. Our programmers write frontend with claude.
Even contracts are being drafted by AI, and managers are signing them. I've seen contracts signed using emojis, and the project has already begun.
We live in an interesting era...
Remember you had to quit social media to keep your sanity in check? Ok, now AI. Same thing.
Not the same thing. Developers' clients are being approached by thousands of people instead of a handful. It creates the illusion that everyone can do the same thing for cheaper.
For whatever it's worth -- I run my own product/company (software). I do all code by hand and don't use any AI.
Are.. you okay? Jokes aside, how has the experience been? I’ve really curious to hear about your motivation for doing software without AI
I enjoy writing code.
I've tried AI tooling in the past and it felt wrong to me. The software was alright (it worked).
I don't know if anyone can relate, but it didn't feel like it was "mine". I didn't even keep the project/code. It was a working software emulator for a video game console but I felt zero connection with it and couldn't even get myself to keep the code.
Maybe I'm old fashioned and/or stubborn, but I like to write code. I like to know the minute details with regards to how things work. I like to know every function an API provides. I like to understand the differences between platforms, devices, hardware, etc. I've always loved it and always will.
When you get stuck, you google search/stackoverflow rather than asking an llm?
I don't really get stuck, but when I do the answer is usually in documentation or a man page. I probably read documentation and man pages more than the average developer.
You could argue that is slower than asking an LLM, but I am willing to do things a little slower if it means building up my knowledge and getting stuck less in the future.
I admire your persistence and hope your efforts pay off!
For me in large tech:
- Humans still own the code
- All code reviewed by humans
- LLM adoption varies across the org. Some are heavy users and some less. Some suspicious some less.
Where are we heading? Depends on model/harness capabilities. Likely some sort of mix where some projects will still require expert humans and others will just be vibe coded. How much we lean in that direction - we'll see.
Every software developer will be a manager of one or more AI agents. Managing AI agents will turn out to be surprisingly similar to managing people, except for the drama, illness, and tragedy.
I'm downvoting you because:
1) You're anthropomorphizing AI.
2) You're devaluing your fellow human/professional.
>except for the drama, illness, and tragedy.
"By using AI we get all the benefits of workers but with none of the drawbacks of humans."
I hear this spiel most often about junior engineers on HN, and it really pisses me off. It just comes off as incredibly anti-social.
I was trying to make a different statement. Everyone will need to become a manager, even ICs. But in the past, many engineers shied away from management, for various reasons. Now, it will need to change.
Managing people is hard because of all the things that make us human. Managing AI will be simpler as we won't need to deal with some of those things.
Separately,
> "By using AI we get all the benefits of workers but with none of the drawbacks of humans."
To be fair, I did not write that. You are projecting your thoughts on my post.
Its similar for us to a certain extent. I honestly don‘t know yet where this will lead to. Personally I also don‘t really follow the arguments that the agent does the coding and the human does the understanding. In my opinion one is thinking differently about the code when not coding it by himself, on a higher level or lets even say a more superficial one. To keep the understanding on the same level you would have to limit the agent to just „typing“ but this is definitely not whats happening.
Yes, may be a skill issue[tm], may be an inherent one or it may not even be relevant anymore, we will see.
For me it currently still works well because I am working on legacy systems I more or less have a good understanding about - so I can judge the agent code. Not sure how this will be with new, green field code.
Not even starting with the discussion how it should be possible to review the sheer amounts of generated code.
I must be honest, but I have started doing the same thing to some degree. Now this is for me in particular, I do know coding, but if the task at hand will take like 3 days and Claude can write and debug it in an hour, then I usually just run it by Claude. This is not to say I don't still code, because I still do, depending on the project, but I find myself relying on Claude a lot. I know this is counterintuitive to what you want to hear, but this is my reality. However, I still know a lot of people who still code with out the use of AI. So in my opinion the profession of programming will go down as AI progresses but will never die no matter how AI advances.
The adoption curve across companies and industries is highly variable right now. Tech moves fast but plenty of boring industries need software but don't move on the bleeding edge of tech / LLMs / etc.
Even in the discourse here, you can see people getting variable quality of results and variable skepticism, some of which is valid, but a lot of it reads more like not having spent time really understanding prompt engineering.
From my experience, Ai right now is not perfect and people still treat it as if it was, leaked secrets, create 10 bugs to solve one minor issue, whole backend a mess that won’t resist at scale. Even though it is improving and all this issues will disappear, Ai will take over most of the technical hurdle, what will be left?
Materializing and scoping down broad idea ( or just abstract vision ) into what needs to be built, it’s not the same to say.
“Hey Claude build me a fitness app”
Thank actually understanding your customer behind it, the behaviour and psychology, the journey and what is the actual problem you’re solving.
Tech in general and programming emerged as a need to create new things in a digital world to solve our problems, building them just got easier but understanding the problems and the people behind them, that’s gonna be an increasingly necessary task
.
Does programming require special educationEventually the costs of running inference will catch up to us, then we will see. But LLMs are really expensive and it is possible that with the incredible amounts of code they generatr it might become too expensive for them to keep up with it. There should be some kind of equilibrium which might take a while to reach but I think knowledge work won't disappear.
However many people have rightfully been saying it for years before LLMs that many so-called software engineers had no business in this field because for a lot of them it was just a way to earn more money than peers. It's not an issue by itself, just a rational human choice but the fact that it was possible was just because of unhealthy economic conditions.
> ask claude to write, and ask claude to explain
This works, until it doesn’t. I’m continuously shocked by these stories, where so many people put the future of their job/company in the hands of these agents after only a few months of existing.
I still constantly run into bad output from LLMs, from code to basic questions. I don’t understand how anyone can hand things over to something that is laughably wrong on a pretty regular basis, often in subtle ways that won’t be noticed by someone who isn’t reading closely and thinking critically.
They’ve gotten better, but I still regularly give them the old Nick Burns treatment, push it out of the way, and do it myself.
There's nothing shocking about this. The vast majority of software/source code is pretty terrible anyways, code that is full of bugs, slow to use, has little to no automated tests and very hard to maintain.
To the extent that it gets fixed or works at all, it's not because of competent developers doing rigorous analysis of the software, it's because either someone testing it or using it gets annoyed, reports an issue, and then that specific issue gets patched out.
If using LLMs to perform a similar function shocks you, then you should have been shocked already by the proliferation of pretty bad software for the better part of the last couple of decades.
So many criticisms of LLMs assume that people have been writing software very diligently, applying a high standard of engineering, subjecting the code to a battery of rigorous tests, passing it through a strict review process... and that does happen for some software, especially software that is commonly used, but it's not true for the vast majority of software developed.
AI is no good, but neither are people, isn’t a great sales pitch.
I think for small tools that people want to make for themselves, that’s great. Where I see a problems are when other people and money get involved. If something goes wrong, who is accountable? Claude wrote it, Claude reviewed it, Claude submitted the PR… yet Claude can’t have any real accountability.
"A computer can never be held accountable
Therefore a computer must never make a management decision"
-- Internal IBM training manual, 1979
I think small tools people make for themselves is realistically less than 1% of software produced. Most of the code, and - to the GP’s point - bad code, is produced in corporations with plenty of money and budget.
There is just such a tremendous amount of waste at every company, in that the headcount and software expands to fill the budget. I’m not defending Elon, but look at how much he slashed from X (80% or so?) and the company still has its core product functioning and an active user base.
There is a ton of software (especially internal) at essentially every company that also is low accountability before Claude. “Oh Ted built that but he’s working on a new important project. I understand it’s broken and that’s impacting you but we won’t be able to prioritize this until next quarter at least. Can you set up a meeting next month to discuss?”
Honestly the outcome for all of these LLMs is indeed is likely a higher amount of software with no accountability, but it’s also an improved ability to juggle more of that software to the same (realistically low) standard.
It's an absolutely phenomenal sales pitch to executives. A ton of automation is sold on the basis that it's probably not going to be as good as having a dedicated person do it, but that automation leads to much lower maintenance scales better, is more deterministic and reproducible.
> little to no automated tests
I'm still amazed people don't achieve extremely high test quality, since you get tests "for free" now.
One of the limitations of testing were always that people "design" things so they're hard to test.
And then they argue "This can't be tested", or "Refactoring this for testing is not worth it."
It is now. Yet, I work on codebases with no tests and lots of yolo co-authoring.
You get quantity of tests, but the tests are not good quality by default, at all.
I’m not sure how you can say something general about the quality of tests unless you mean by simply prompting “make tests” or similar.
Yes, I’ve experienced that those tests succeed, and the app still breaks trivially on first run.
What I mean is: you design the tests. You analyse patterns. You insist on making testable code (average code by humans isn’t, so neither is average code by LLMs unless you specify testability as a design constraint.
One way to get testable code is to mock all interfaces. This is usually expensive, but not difficult for an AI, because you can set the success criterion to be interface exactness of your mock for a series of plausible and somewhat extensive interactions.
The tests you can make with AI are as good as you can make them otherwise, you just save time doing them, which should justify making more extensive testing.
It's a really fun philosophical exercise to ask what it means for them to be "wrong." My perspective is that they are fantastic at association and generalization (of language and symbols in particular), but whether they're identifying the associations you care about or generalizing to the level of abstraction you're aiming for is a complete crapshoot. If you aren't checking and correcting them, and discarding the misfires, you will end up with a very pretty Tower of Babel.
One area where I feel safe saying they are “wrong”, rather than just going with a different assumption that was left unsaid, would be when it makes up API endpoints. It sees the general pattern in an API, then makes up an endpoint that sounds good, follows the pattern, but isn’t actually implemented.
I’ve also seen a lot of issues with co-workers using an LLM to write their readme files. I look at the readme for what return values I should get, go to use them, and get an error. I check the code, and sure enough, none of the variables in the readme exist. The LLM just through they sounded good. Things like this I would say are pretty objectively wrong.
> One area where I feel safe saying they are “wrong”, rather than just going with a different assumption that was left unsaid, would be when it makes up API endpoints. It sees the general pattern in an API, then makes up an endpoint that sounds good, follows the pattern, but isn’t actually implemented.
I remember seeing this maybe 6+ months ago, but using paid plans, RAG, and a high thinking mode has eliminated a ton (almost all) of those kinds of hallucinations. Open models and free tiers are not there yet though.
> I’ve also seen a lot of issues with co-workers using an LLM to write their readme files. I look at the readme for what return values I should get, go to use them, and get an error. I check the code, and sure enough, none of the variables in the readme exist. The LLM just through they sounded good. Things like this I would say are pretty objectively wrong.
LLMs don't co-sign the quality of PRs though — your coworkers do. It's not unusual for docs to get oudated and not be maintained enough in small codebases, but that's not an LLM specific problem.
I saw this, all of this happening years before ChatGPT existed, but with outsourcing to Indian dev shops.
You'd be shocked how often I see the meat-space equivalent of vibe coding!
"I trust the developers."
"You really shouldn't!"
The thing to realise is that there is no fundamental difference between outsourcing a development task to other human developers versus outsourcing[1] it to LLMs.
Either way, total and complete understanding is being sacrificed in the name of productivity and scalability.
It's just there's one extra layer of work assignment now, with ICs handing off tasks to agents.
What this has revealed to ICs is the BIG issue that has plagued all software development for decades, especially since outsourcing became so popular: Oversight is critical, and more importantly: authority can be delegated, but responsibility cannot.
LLM output is fine, as long as you review everything it does.
This is the same as any competent dev team manager reviewing PRs for quality, paying attention to critical matters such as security, adherence to high level design and low-level style standards, etc.
Some do.
Many never did.
[1] This doesn't have to be a contract with an overseas provider, by "outsourcing" I mean any variant of not-your-own-hands-on-keyboard. Any scenario where a customer or manager assigns tasks to developers other than themselves.
AI is just a tool, and, as always, people will use it incorrectly and lazily. Are we forgetting the good old days of Copy/Paste from Stack Overflow?
LLMs just made it more convenient for the same people to take the lazy route.
Even if / when it does work, the value being produced is reduced to the dollars paid to Anthropic or OpenAI or whoever. What are you even contributing? What’s stopping the ai provider from coming in and eating your lunch?
it was hype all day long and managers forgot that ai is tool and not some magic stick. tool like dewalt or makita. after ai went out i got expected from some collegues at company to generate 600 700 lines of code or more, i tried to explain i cannot read or understand whats actually happening that fast, but they were like just push, go, copy paste it. complete autodrive mode, insane. then i spend weekend fixing it, making me double mad. whats actually happening is retarded, cos of all stories out there managers thinking that claude generate perfect code, and u could make twitter clone in half a day...
Every AI coding project feels like working with legacy code. All the skills I actually use look more like managing a big messy, brittle black box codebase. It’s exactly how we would have inherited a big ugly codebase pre AI.
I think if you’re used to traditional green field development, and have never owned legacy code AI software engineering can be bewildering. If, however, you’ve been stuck maintaining legacy code, the skills serve you well In AI development.
You’re constantly looking how to tame this ball of mud. Test it end to end. Break apart bits to test. You’re chasing where the brittleness in the system exists, and you try to create a testing and feedback strategy to gain leverage on that class of problem. That in turn turns to modularization and gradually more careful organization.
I find starting out you may look at code less. As time goes on, you descend deeper and use AI to do targeted refactors to account for more constraints. You leave alone what's OK to be slop, and hone in on what needs deep care. All along adding guardrails to constrain the big ugly beast and help LLMs stay on track with their work.
The classic Michael Feathers book might be sneakily relevant: https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe...
This sounds kinda of horrible ?
I'd rather build things slower (perhaps with an LLMs help at times) that understandable and high quality.
I find with AI coding its like tick-tock
You "tick" - expanding functionality and get over your skis in code quality (this is the 'legacy code' part)
Then you "tock" - you break apart the slop into better and more reliable code.
The problem is whether you're allowed to "tock" as the pressure is often on the "tick" (more functionality) part.
Same here. At our company, we've pretty much stopped writing code by hand. We hand the implementation to Claude and Codex now. Feels like the real skill is moving up a level: architecture, design choices, and knowing what should be built in the first place.
Software was never a precise occupation. It was a tool shed that obeyed the Pareto Principle: 20% of the people deliver 80% of the value.
This was the expectation because hiring was the primary goal, not product delivery. The industry could have fixed this by upgrading itself from an occupation to a profession built upon standards and credentials. That never happened because the 80% would become unemployable, which adds friction to hiring (the real business goal before COVID).
Now, that ship has sailed and there is no going back. The Pareto Principle is now a 5%/95% funnel because there is less incentive to learn to do the work. Good luck!
For the last 6 decades or so, a computer was a machine assumed to operate with high levels of precision and deterministic outputs. Such precision enabled spacecraft like Voyager 1 & 2 to travel billions of miles from Earth, staying on course, semi-operational and sending telemetry- 50 years after launch.
Now we have machines that, when asked to produce a paperclip, may instead produce a butter knife, or a banana, or maybe just a "try again later".
These modern "tools" are quite a different animal. They're more akin to roulette wheels that generate massive amounts of heat and CO2.
This is cope. sota agents produces what's asked exactly, usually it's the asking that's the problem not the result, improve the prompt and the output drastically improves.
I mean, literally the answer is that nobody knows. Maybe the robots replace us all. Maybe they shift those who remain into being some combination of Product Manager and QA. Maybe there's still a role for a technical overseer even in the medium-long run.
But it sounds like you're really asking about the state of the world today. If so, I don't think that ideal state is like your friend's company (or at least, as it appeared to be to you). It might be possible that you can make that "dark factory" pattern work (StrongDM seems to be doing it), but it would require infrastructure and discipline that I doubt they're mustering. Think about how CD didn't involve taking a sloppy build process with no testing or observability and just going straight to prod -- it required building up a lot of infra and discipline first.
But on the other hand, I don't think the ideal present involves artisan hand-crafting code either. I haven't written a line of code by hand in enough months that it would genuinely feel weird if I were to try to program that way despite decades of having done just that. That era's done with, and moderate normie practices right now today are more about supervising and guiding agents than about chiseling code into clay tablets.
What you're describing sounds like what many people in the industry are doing, and likely what most AI-adopters are doing. It scales until it falls apart.
The responsible and professional way to actually make AI work at scale is to build a dark factory. (You can search HN for a lot of good resources, start with Simon Willison and StrongDM)
I really didn't get it, how is dark factory better than vibe coding whole day and not looking at code?
If dark factory indeed worked, shouldn't StrongDM print a new unicorn startup every month?
Imo this will be the future model: a company puts a gun to your head, gives you agents, and tells you to figure out how to maximize the utility output you provide as an employee. They might put a token limit which incentivizes efficient token usage.
There's a lot of "room" here for creativity, i.e. the agents don't know how to milk the agents efficiently, which is essentially your new job. The agents might not know how to structure tasks so that the agents run overnight and run the proper experiment.
The difference between mediocre and 10x will increase. The more aggressive SV performance culture is probably going to become more mainstream.
Frankly, I think this whole model is way more burnout inducing. You're not really doing software engineering anymore. You're running this mental loop in the background of trying to multiplex between agents and mapping unstructured business problems to agentic work.
It's probably going to infect other industries over time. Software is the first big wave. I don't think people with computer skills who are good at computers will be screwed out of work long term. The tech industry has a lot of concentrated technical capital in the form of tooling and automation that other parts of the economy could significantly benefit from. Short term it looks bad, but long term, computers will become more and more dominant over the economy.
I don't think companies have yet figured out how to adapt their hiring, managerial practices, or internal incentive structures to reflect this. Most of what they're doing now is extremely crude and terrible for morale.
My profession is not, and never was, _programmer_. Lines of code—the actual text, is a means to an end, not an end in and of itself. I'll take heat for that here for sure. But do you think a carpenter considers himself "one who screws nails" or "glues joints"? No, the small minutiae of the job was never the job itself.
> But do you think a carpenter considers himself "one who screws nails" or "glues joints"?
Sure, but a carpenter who is unable to use a screwdriver without hurting themselves is unlikely to produce robust furniture with a a powered driver.
That's maybe wishful thinking from my part, but more towards like other engineering fields: Project engineers design it from scratch, everyone must speak architecture, customer and compliance at once, and we will have standards and "codes" drawn up by the end of this decade.
code is like assembly now.
in the olden days (pre-LLMs) we would write high-level code.
the entire layer was high-level code and rarely would we ever need to peak into the assembly:
writing, debugging, architecting, reviewing, testing - all were done in the high-level language layer.
---
welcome to present day:
since we don't write code - we write intents, we also shouldn't review code either - we should review intents.
I don't review my code anymore. I ask the agent to generate markdown docs, graphviz diagrams, changelogs, audit reports, etc. I only review that.
I also ask it to write test and evaluate by whether the tests passed or not. I don't need to peak into the tests code - I can also ask plain english, pseudocode, control flow graph, whatever it is I want.
I can ask it to find errors or missing tests and improve that too!
code is like assembly now.
rare are the cases you would need to peak into that level.
> I ask the agent to generate markdown docs, graphviz diagrams, changelogs, audit reports, etc. I only review that.
From an alternative perspective, that is the code.
I sometimes end up at or near this conclusion when considering the future.
Consider some software that was written by AI purely using markdown files. The spec was sufficient enough to classify all of the business logic, conditionals, etc... You might even end up creating "loops" that tell AI to do something over and over again. Some markdown files become standard, repeatable "functions" that are to be followed EXACTLY (determinism). Some markdown files become assertion tests. Heck, the markdown file might eventually invent some kind of "typing system" so that you know when you're working with the person "class", it's always going to have the same facets.
I love the concept of it going in this direction - we already had plenty of languages to tell a computer what to do, we've just generated MORE text at a higher level and made it less deterministic.
Just to clarify, I don't think it's likely that this is the end result, but it sure is funny to think about.
Yes, this is the direction I am observing. Ironically, I don't think anybody is happy about it and we keep saying that it is a tool and you need to verify everything, etc, but this is not what is happening.
There are tons of people who produce questionable code at a rate which is not really compatible with a thoughtful review, we have people with little engineering background pushing their changes (although there is a large pushback against that as the results are really bad even short term), as you said, there is an explosion of LLM-generated tests.
As soon as someone writes a next-level harness which tightly iterates based on the spec/plan and/pr pioneers some sort of acceptance criteria format that works, I think at that point SWE job will completely change. We are not there yet but probably not that far off.
No one knows so just embrace it :)
LLM capabilities are mind-blowing.
I’m not a super experienced engineer career-wise ~5 years, so take my view with a grain of salt - but I’ve done work in full-stack, systems, gaming, extensions (web and ide), low level languages including assembly, and a small amount of embedded.
I spend almost all my spare time coding. And have done so for the last 5 years. So I consider myself capable of bringing most projects to fruition.
I roll my eyes when people say “AI sucks” “AI isn’t better than me” “AI doesn’t speed me up” - it’s either a load of shit, delusion, cope, high-horsing, or they are a Luddite.
I’m sorry but the rate at which I can work pre-AI and post-AI is insane (when not limited by bureaucracy). Yes the outputs and code can be terrible, but I can prototype 10 ideas in the time it would take me in the past to prototype 1.
However most of the LLMs approaches are fucking terrible, it gets it working but it’s pure spaghetti and I do all the architecture and usually most of the code. But I prototype ideas with AI. Like if you actually use performance monitoring and memory monitoring tools, LLMs have no fucking clue what they are doing and make slow bloated buggy shit.
But it’s great for blueprinting.
Who’s to say it won’t also be great at implementing too? I think it will be.
But for now it requires guidance and orchestration and I mostly use it to test concepts.
I did my first purely vibe coded completely hands off project the other week and loved the results! It was just for fun.
I see nothing wrong with something probabilistic. I think it is all about offsetting the risk and reducing the odds of bad outcomes. There is this concept of Defence in Depth, thus I assume some sort of binomial formula also applies here.
That’s realistic. If AI generates 100% of the expected result, the vast majority of people might think that understanding the code is useless or unnecessary.
With advent of AI, the software engineering landscape has been changed a lot. Writing code which was once a noble ("giving god like feeling") profession is not just a prompt away for vast majority of the tasks.
> "it feels like software development is going from a precise occupation that requires high degree of understanding to something probabilistic and offloaded understanding"
Well how much ever I agree with this, I believe in near future it will open more "expert" like positions who will suffice as orchestrators to not let the AI slop take over and make your systems either dumb or vulnerable or both!
From what you said: Not looking at code is bad, not because Claude can slip a few bugs (it can), but because LLMs tend to default to writing more code and features than needed, which isn't a good thing. I see a lot of people making 10+ PRs per day, but most of them are just going back to fix earlier PRs.
Claude always likes to "go big," for example, by choosing tools that can support millions of concurrent users or by adding unnecessary layers of abstraction that create more maintenance pain. I guess that's good for LLM companies, since more tokens are spent fixing the mess it caused.
Every time I enter plan mode for a huge feature, I end up cutting about 30-60% of the task scope before the LLM can actually start the work. I review the final code, and I still find things to cut. As said before "The best code is no code, or code you don’t have to maintain" [0]
0: https://www.simplethread.com/20-things-ive-learned-in-my-20-...
Anecdotal experience amongst my small team:
- spending exorbitant amounts of time up front planning, surfacing every milestone, subtask, and individual change, burning tons of tokens in addition to man hours fixing minute but important mistakes or derivations despite explicit instructions, CLAUDE.md, memory subsystems, agent and skill instructions, etc.
- executing and reviewing results compared to the plan and finding even more mistakes and derivations from the plan often takes a lot of time - the relative rapidity produces a lot of output for the team which stresses our lifecycle and introduces feelings the whole process is on the verge of flying off the rails
- individual developers have different expectations, definitions of acceptable, skills/experience to detect and deal with problems, and patience. I might spend hours to days meticulously planning and executing a ticket and another guy might yolo it in 30 minutes. Other than bug escape rate and tracking review failures I’m struggling with how to track people who are “doing it wrong” let alone telling them the “right” way to do it.
- growing exhaustion, lack of ownership and confidence, frustration, and a generalized feeling of endlessly fighting your tools but in a weird way they never seem to really improve despite all your efforts to do so
- taking humans out of the loop and letting the agents be more autonomous in hopes that we’ll reduce the bottleneck and produce better results has not helped.
- I find even myself fighting (and sometimes failing) the urge to give in even though the proposed or implemented solution doesn’t feel right. Scale that across your team
- experience has not really changed despite changes in models and harnesses
- there’s a deep feeling that I’m doing something wrong and fomo since so many people in the industry boast of incredible results. I probably am, but everything I’ve read about and tried has not really moved the needle much and it’s introducing another dimension of exhaustion and frustration
overall, I don’t feel like we’re being much more productive when you factor in quality and accountability (which should be a given, but this industry increasingly overtaken by a reckless philosophy of speed over everything else). I do think it has helped parallelize tasks, produce higher quality PoCs to explore more options and do it faster, offload joyless but necessary tasks that are narrow in scope and measurable, do exploratory work and act as a generalized interactive knowledge base, and make shallow techniques, technologies, etc. that you don’t yet have experience with. Maybe I’m just missing a critical component or two in the process (formal specification, etc). Maybe it’s growing pains, or maybe there’s a looming rot. Either way job satisfaction and confidence in my work is much lower than I would have expected.
Seems clear that the age of everyone and their dog getting a programming gig for easy money is coming to a close. What will be left (for the foreseeable future) is positions for very highly skilled software engineers who actually know the craft well enough to make good use of AI.
The industry is going to shift from hiring as many programmers as you can afford to hiring a small number of the best engineers you can find. AI can't replace an engineer's skill and insight, and I have yet to see signs that LLMs are fundamentally capable of such a thing. What is screamingly obvious however is that when a highly skilled engineer learns how to drive AI agents, that's when you get true effort multiplication. A real engineer can leverage AI in ways that an unskilled vibe coder simply cannot, because it turns out that building a house still requires engineering even when you have a nail gun. LLMs can write code all day but if you don't understand programming and engineering on your own, you lack fundamental tools to build software.
Sorry kids, buffet is closed. No more FAANG salaries for anyone with a pulse and a copy of VSCode. The future of the industry looks to lie with a vastly smaller number of much more highly skilled engineers.
What happens when those engineers age out and we realize we stopped training new ones? I genuinely fear for the coming generations of engineers. It's not going to be good.
I recommend you learn to weld instead.
I wouldn't be as sure that engineers won't be needed, whereas welders will.
This is the 2020s re-enactement of the early 2000 WYSIWYG editors.
What sorts of things does your software company make or do?
No mention of whether the product is actually good.
This has always been a very different profession depending on where you work and what you're working on.
I haven't worked at a startup in over a decade, but the stories I hear now sound the same as back then. There's lots of wasted effort for mediocre to poor code destined to be rewritten or thrown away until there's enough investment to justify more work. At which point, "more work" just means more sprawling slop instead of fixing the technical debt rotting at the foundation.
AI just put a spotlight on the futility of trying to run before you can walk. Whether so many founders are going to stay in denial about it is yet to be seen. Statistics about any line of business says yes. This is how most businesses fail and most of them have to fail.
We're still running the race, but it's just not on foot anymore. You can still run it into the wall if you're not careful where you're going.
> it feels like software development is going from a precise occupation that requires high degree of understanding to something probabilistic and offloaded understanding
To me it felt like there were always engineers and vibers.
Vibers don't work systematically, never test, accept unknown regression, don't use git, and if they do, treat it like Dropbox, use terrible languages, have terrible habits. Vibers got a new tool, too, and it vastly increases the amount of slop. But the slop was always there.
The slop actually got better after vibers stopped writing their own slop, I have to say.
And vibers are less defensive about the particular slop they didn't write themselves.
how is that company doing?
i think that is a more important question that you shouldn't ignore.
do they have growing revenue?
And more important, how will they be doing in a year or two?
"This is exactly why we built AINAScan — we found that AI-generated code passes all tests and 'works', but consistently produces the same 15 structural bugs: save functions that never write to DB, async functions with no await, parameters that have zero effect on return values. Linters miss all of these. The code looks fine until production."
I've found they optimize largely for the happy path and don't consider any (or enough) edge cases (e.g. what happens to everything downstream of this, if say, there's a timeout in this specific HTTP request.)
I find Claude fighting me when I point out things like that as well claiming its not worth it to worry about and when I point out the train wreck that would ensue by leaving some things in a weird state it flips its script: "I was incorrect about that..."
Folks will claim that's a skill issue but, its an issue letting the LLM run off without any oversight and it creates so much code you can't possibly review it all yourself, so like you've found, you hit a lot of problems in production.
AGENTS.md and friends help but I've found it ignoring rules in their as well, often and very frequently.
Personally what I've found to be the biggest win is:
1. Use AI to go harder not faster - use it for code reviews, second opinions, researching all the angles to a deep topic, but don't use it to pump out a whole app. Don't outsource your entire understanding to it (which is precisely what we do at my job today...)
2. Use it for the boring tasks that are hard to get wrong and can be easily validated.
Oh and tests... I've seen so many completely useless tests being generated. Any valuable test that I've ever seen claude create came from me finding a bug or missed edgecase.
towards system design and solution architecture.
imho programmers should jump into completely unrelated jobs (even unskilled labor) and discover how gawd awful all of the software is. Nothing gives you the user perspective like being the user. Then dogfood your way into a highly specialized product.
There is an amazing amount of complexity in even the dumbest looking job. It takes decades to see all the strange edge cases.
The people planning the work never have the full picture, if they did the job themselves the layer of management above fails to imagine it. The people doing the manual work match the offer by inability to explain how to ride a bicycle and not understanding how to plan or budget.