These posts are never written by software engineers, it’s always some tech exec, retired engineer, or VC. This author is apparently a professor at the Wharton School of Management? None of these people have to ship or maintain real products, they’re just making side projects.

The only decent software engineering perspective I’ve seen has been from Mitchell Hashimoto.

▲ jimbokun 6 days ago | parent | next [-]

Well that’s kind of the point.

They can just summon bespoke software out of the ether that only handles the use cases of themselves and a few of their collaborators.

Making “side projects” was mot possible for non-developers before powerful LLMs. Now it is.

▲ an0malous 6 days ago | parent | next [-]

I don’t think that’s true, I think these authors are making a much stronger claim that AI is proficient or even an expert at software engineering. This author describes how complex and sophisticated their software is, and the only value he’ll concede to “coders” is that there might be a few bugs they’d need to fix.

Imagine not being an architect and using Claude to put together a building plan, then concluding it’s basically done but we might need a real architect to double check the measurements. It may even be true but I’d be skeptical if it’s always non-architects saying this.

▲ 21asdffdsa12 5 days ago | parent | next [-]

And - we kind of have been here before. The "proto"-type is almost complete. Its just a little slow, a little spaghettificated, just written in excel-vb, clicked together in node-graphs, or the next hot thing that makes coding unnecessary.

▲ bathtub365 5 days ago | parent | prev | next [-]

Why do they even need coders to fix these bugs? It would be an order of magnitude (at least) to ask Claude to find and fix them, and it will likely be successful.

Building in the physical world has physical and time constraints that cannot be overcome, which is one of the reasons architecture (and engineering) are so important in this domain. In software development these constraints were only inherent when people were writing the majority of the software. I feel like I’m seeing what I thought were fundamental constraints being eroded by the increasing speed and correctness of these tools and it’s making me reconsider the importance of some of the values that are held by software engineering.

It’s obviously dependent on the domain and solution, but if your software can be extremely rapidly rearranged, bugs found and fixed with little effort, and features added with only a minimum prompt, I think the entire definition of technical debt has changed. I’ve been sceptical of these tools and still approach their output with caution. I also worry that, as a software developer, if more can be accomplished in less time there will be less room on this planet for software developers.

▲ phil21 5 days ago | parent | next [-]

> I think the entire definition of technical debt has changed. I’ve been sceptical of these tools and still approach their output with caution.

This very well summarizes my current thinking on the subject as well. And most of my career has been playing the role of technical debt nazi. Much to the detriment of my earning potential.

Does AI make incredibly inefficient code most of the time? Yup. But it does it at lightspeed with minimal effort.

I think many software engineers forget they exist to get real things done (in many cases at least) and they are a cost center for most businesses. If your end product is not selling software, very few people actually Doing the Thing(tm) will give a single solitary care about code quality or maintainability when they can just spend 30 minutes and $15 worth of tokens to fix it.

It won't take over everything, but I've already seen otherwise very intelligent go-getter type folks who are not technical or know how to code made extremely useful things for themselves and their small little enterprises. And this will seemingly only get better and more efficient.

For someone who really does love the idea of well architected and future-proof code this is just icky to even say or consider. But I'm coming around to this is the future for the majority of software for most places. And it may have the ability to seriously even the playing field for small enterprises in some industries.

I'm currently using it to implement a zillion side projects at home I've been "meaning to get to" for years. It makes incredibly silly unmaintainable code most of the time - but I learned to not care, and just tell the AI bot to fix it/add to it as I go along. Worst-case I spend a single night deleting it all and starting from zero to "refactor" an entire thing.

▲ prmoustache 5 days ago | parent | next [-]

> I think many software engineers forget they exist to get real things done (in many cases at least) and they are a cost center for most businesses. If your end product is not selling software, very few people actually Doing the Thing(tm) will give a single solitary care about code quality or maintainability when they can just spend 30 minutes and $15 worth of tokens to fix it.

I am suprised to hear people so naive they expect their token usage to stay flat if code quality and maintainability starts falling exponentially?

What if to fix 2 bugs your LLM starts adding 50 new ones? Will you tell your customers in supports channel "sorry software is finished, if we try fixing anything, everything else might break, not worth it". Or "we can probably fix it, but our AI usage will raise so much we need to up the subscription 3 fold, you choose".

The speed at which LLM codes is only comparable to the speed at which they add garbage to your repo. If you stop caring about maintainability, you also stops caring about your AI/LLM related bills and the viability of your project past the PoC stage.

▲

varjag 5 days ago | parent | next [-]

The GP explicitly mentioned "end product is not selling software". But even then, bugfixes introducing new bugs are not unheard of before. Most code used to be mediocre quality so there's not a sea of change with AI. Perhaps it even becomes better on average.

Another thing though is selling software in the first place will soon become tough proposition outside of a few niches.

▲

senordevnyc 5 days ago | parent | prev [-]

I am suprised to hear people so naive they expect their token usage to stay flat if code quality and maintainability starts falling exponentially?

There's no reason to think that quality and maintainability will start falling exponentially. On the contrary, these models get better every couple months, and 99% of software isn't actually that complicated. There's just no reason for the fear-mongering that fixing 2 bugs will cause the LLM to add 50 new ones.

	▲	queenkjuul 5 days ago \| parent [-]
		Except that i witness it create new bugs while fixing existing ones? Not 50:1 but it does happen

▲ senordevnyc 5 days ago | parent | prev | next [-]

I think many software engineers forget they exist to get real things done

One billion percent. I think the vast majority of the anti-AI sentiments I hear from software engineers comes down to them caring more about playing with their tools than actually solving the problem.

	▲	Anamon 13 hours ago \| parent [-]
		Many software engineers have to get things done not just once, but ensure they keep getting done, reliably. That's what 100% of vibe coders don't understand when they brag about their one-shot toy projects. The tools we "play" with, we developed and refined over decades, and we did so for good reason. They all emerged out of real problems that needed solving in the real world. Many are born out of experiences where things went terribly wrong. AI bros and execs drinking the kool aid are gleefully dismissing the warning signs of millions of experienced developers, and don't think that maybe, just maybe, their billions of hours of experience may mean they know some things they don't. The landing will be brutal, and I have my popcorn ready.

▲ locknitpicker 5 days ago | parent | prev [-]

> Does AI make incredibly inefficient code most of the time? Yup. But it does it at lightspeed with minimal effort.

This hits the nail in the head.

Detractors often hang on to examples of coding assistants making mistakes or output subpar code, but they somehow miss the fact that coding assistants can also be prompted again and refactor whole swaths of code just as fast as they introduce oopsies. This means that the worst case scenario implies fast convergence to an acceptable outcome, and from there also fast iteration to improve upon that.

▲ rglullis 5 days ago | parent | next [-]

The problem is that this approach is not sustainable. Errors compound. The cost to fix one issue might seem small at first, but over a stretch of time all these "oopsies" become architectural spaghetti that can only be fixed with a complete rewrite, which will certainly become more expensive than getting the code "organically" developed.

The only way I see AI coding working in the long run is if we go back to a Waterfall/BDUF process and having actual engineering. Let engineers really own the architecture. Enforce that any new feature - no matter how small - to be specced out with complete sequence diagrams. Ensure that every new software package needs to be put on an UML component diagram for the team to review and see each addition interacts with the whole system, etc.

If we do that, then we can just give all the documents to a coding agent and say "go ahead and implement this" with a minimal amount of confidence. But in doing this, I bet we will realize the following:

    - the "effort" has never been about writing code itself. The code is just the material manifest of all the thought that went to think over a solution into the problems that the product is attempting to solve.

   - we will likely be better off by using code generation tools (i.e, UML-to-code) and a "weak" LLM (than can run locally) than by playing the token lottery at the Anthropic Casino.

▲

eithed 5 days ago | parent | next [-]

I mirror your thoughts. I think we'll end up with "perfect map" paradox = you cannot be vague or indecisive on what you want (and if you are then these decisions don't matter) and you're creating a 1:1 representation of what the code needs to be.

I'd substitute "owner" for the team and in that sense the owner will not need to be human.

We're at this state where Claude is great at doing the "middle" part of work, but it's crap at gathering requirements and verification of what it has done. I also don't see people caring about these aspects of software development as shown in the article

▲

locknitpicker 5 days ago | parent | prev [-]

> The problem is that this approach is not sustainable. Errors compound. The cost to fix one issue might seem small at first, but over a stretch of time all these "oopsies" become architectural spaghetti that can only be fixed with a complete rewrite, which will certainly become more expensive than getting the code "organically" developed.

That's so far been called software development.

All software developed by people suffers from this issue.

Where exactly is the novelty?

> The only way I see AI coding working in the long run is if we go back to a Waterfall/BDUF process and having actual engineering.

Nonsense. The problem is exactly the same.

With agents iterations are much faster, and this can mean things can get messier faster but can get in shape just as fast.

Ironically, agents improve the quality of the deliverable as well. Approaches such as spec-driven development do a far better job delivering features up to spec than manual coding by flesh and blood developers.

There's an awful lot of baseless scaremongering in your post. You make it sound like with AI assisted coding developers stopped paying any attention to quality.

▲

skydhash 5 days ago | parent | next [-]

> All software developed by people suffers from this issue.

And that’s pretty much where you are wrong. Take any long running open source project and you can see the craftsmanship that goes into it. It may not be perfect, but hacks are clearly marked as such.

	▲	locknitpicker 4 days ago \| parent [-]
		> And that’s pretty much where you are wrong. Take any long running open source project and (...) I think you are demonstrating a clear lack of insight and experience in software development settings, including FLOSS projects. I can name you a dozen of fairly known FLOSS projects which are a big ball of mud. Just go to the likes of GitHub, check out the list of popular projects, and peek at their code. You will get a very mixed set of results.

▲

shakna 5 days ago | parent | prev | next [-]

> Where exactly is the novelty?

The compounding speed. Your devs might reach a point where they have to rewrite and refactor, in a decade.

Your LLM, with its higher throughput, may put you in that game breaking situation next week.

▲

locknitpicker 4 days ago | parent [-]

> The compounding speed. Your devs might reach a point where they have to rewrite and refactor, in a decade.

I think that this is exactly why this scaremongering breaks down. If you believe the compounding speed is that greater, wouldn't you be compelled to accept that refactoring and cleaning things up is just as fast and effortless?

I mean, you have a tool that writes software for you following your commands. If you are that concerned with maintainability then what can possibly compell you to not invest any effort in it?

	▲	rglullis 4 days ago \| parent [-]
		> wouldn't you be compelled to accept that refactoring and cleaning things up is just as fast and effortless? No. not at all. Imagine that each unit of work (a new PR for a feature, a bugfix) builds something that is 99% close to optimal and you can only get to bring it to 100% if you spend time to really review and rewrite the "not good" part. Also, for the sake of argument, let's just say that the overall quality of the system is geometric mean of the quality score of each unit of work. The only way to get an "ideal" system is by ensuring that work done on it follows the "ideal" architecture - for whatever "ideal" means for the developers/maintainers. You are arguing that you are saving time because you only have to write the 1% that the AI got wrong, so you'd be getting a 100x speed up. My argument is that there is not so much time because if you want 100% quality, you will have to review 100% of the code. Understanding the produced code is the time-consuming part, not typing it out. So, the only way to have these time savings by working with coding agents is if you accept that the code generated is good enough to not have careful review. But if you do that, then each unit of work that you tell yourself "not ideal but good enough. Ship it and we refactor later" ends up bringing the overall system quality. If you have 10 of these "99% good enough" PRs, and your overall system score is already at 90%. With 50 of these, the score dives down to 60%. This is what OP and I are talking about "compounding" issues: unless we get to a point where generated code does not need review at all, your development speed will always be bottle-necked by the human in the loop. The only way to get speed benefits from the code generation is if we remove the human in the loop, but in doing so quality will drop faster than you can fix it.

▲

rglullis 5 days ago | parent | prev [-]

[dead]

▲ dkersten 5 days ago | parent | prev | next [-]

I haven’t used Fable/Mythos yet, but my experience with recent version of Opus, GPT 5.5 and recent Chinese models is that promoting again isn’t guaranteed to fix the underlying issues, nor is it guaranteed to not introduce more issues. I’ve seen SOTA models make ridiculously stupid architectural decisions that they were then unable to back out of without being prompted very specifically, instead adding a patchwork of “fixes” on top.

I’m not saying that you can’t use AI to do it because I believe that with carefully controlled workflows and context management you can, but it’s not a simple prompt away, it’s requires guidance and understanding, and isn’t the speed demon that raw prompting is.

▲

locknitpicker 5 days ago | parent [-]

> I haven’t used Fable/Mythos yet, but my experience with recent version of Opus, GPT 5.5 and recent Chinese models is that promoting again isn’t guaranteed to fix the underlying issues, nor is it guaranteed to not introduce more issues.

That's not really the point though. That presumes models are only useful if they are one-shot models. That is false.

I mean, what if your prompt successfully changes 20 source files and makes a mess in one? How much work did it saved?

And the elephant in the room is when models actually outperform whatever the prompter is able to deliver, and faster. That is somehow left out.

▲

dkersten 5 days ago | parent [-]

> That presumes models are only useful if they are one-shot models

That’s not at all what I’m saying.

I’m saying that in my experience across multiple models, the follow up prompts don’t fix prior underlying issues. They usually patch on top instead, unless you give them significant and time consuming guidance.

I want them to be more useful outside of one-shot uses, but I find that they currently miss the mark.

	▲	locknitpicker 5 days ago \| parent [-]
		> I’m saying that in my experience across multiple models, the follow up prompts don’t fix prior underlying issues. They usually patch on top instead, unless you give them significant and time consuming guidance. That's not my experience at all, and I have been using models that are far from being cutting edge. Even in the cases where a model generates utter nonsense, a couple of clarifying questions is all it takes to get it back on track. But that might be a factor of the project being worked on, and the extension of the changes being asked.

▲ vrganj 5 days ago | parent | prev | next [-]

In my experience, the refactors are just as bad, just in different ways. All you end up doing is treading water with different iterations of shitty code. By the time you get somewhere acceptable, you could've just fixed it up yourself.

My preferred workflow these days is to pair program with an LLM until it gets close-ish and then manually touch it up. Without that, it just produces junk in different forms.

▲ asoderlind 5 days ago | parent | prev | next [-]

I think this is overlooking the fact that assigning a coding assistant to fix the bugs it re-introduces for all eternity just leads to spiraling token costs, which might cost more than just hiring a competent engineer in the first place.

	▲	sfn42 5 days ago \| parent \| next [-]
		This has been a debate for ever, long before LLMs. On the one hand you have people who don't care, on the other you have people who produce good code. Doesn't matter how fast you can make the wrong thing.
	▲	phil21 4 days ago \| parent \| prev [-]
		Maybe. We will see. I think computers are incredibly cheap compared to humans. These models and infrastructure to run them are going to only get more efficient in time. Right now we are still using (for the most part) entire hardware architectures mostly shoehorned from one purpose (graphics) into another. As purpose-built hardware becomes more prevalent and the SOTA starts to slow down I can't imagine a $100k hardware box not being able to handle a small team of developer's needs for many things. I do think there will be a place for the top 20% of software engineers forever. But most people are not in that top 20%, and the quality when you get below average is not a linear progression. It will not be that difficult for AI generated code to beat the "bottom end" of the industry since tbh it's hard for me to tell the difference between LLM generated code and some of the shit I've seen over the years. I've ran across code written by folks who don't know what an array is more than once. Most software is not built by MIT and Stanford grads making $500k/yr in the Valley. It's built by work-a-day programmers in the middle of nowhere making $80k/yr to keep some niche small business going with hyper-specific software that was first designed for Windows 95. Or stuff like making horribly designed Wordpress plugins. Or Shopify integrations. etc. etc. I've also seen these small businesses totally held back by incompetent programmers, and despite their best efforts and huge amounts (for them!) of investment they can never seem to fix it. These types of enterprises are having AI run circles around their current engineering practices, even if it would make most FAANG engineers gasp in horror. Either way it will certainly be interesting to watch! I just wish I was closer to retirement.

▲ eithed 5 days ago | parent | prev [-]

Don't forget that you can adjust your requirements (either via plan or skill) to ensure the mistakes do not happen. The problem is that neither LLMs, nor humans (that don't work with the domain) will know they made these mistakes. Even coders don't think about everything all the time

▲

brazzy 5 days ago | parent [-]

> Don't forget that you can adjust your requirements (either via plan or skill) to ensure the mistakes do not happen.

No, you can't. Adjusting prompts ensures absolutely nothing.

▲

eithed 5 days ago | parent [-]

I disagree. What I should have added is that with agents (as well as humans) you do need to have tests that verify what was done.

▲

brazzy 5 days ago | parent [-]

That assumes you can write automated tests that reliably identify the mistakes over an entire codebase. Nice idea in theory. If it were actually possible, we would long since have generalized libraries of tests to catch every significant security and performance gotcha. What we have are static code analysis tools, fuzzers, etc. None of which have come close to eliminating security and performance problems. I don't see how AI somehome changes that.

	▲	eithed 5 days ago \| parent [-]
		Ah, I see what you mean now. Yes, my mind went straight to static analysis and testing (unit, feature, uat, mutation). Thanks for expanding on your point!

▲ dv_dt 5 days ago | parent | prev | next [-]

It's quick to build a hut in a green field, but slow to remodel the expanded building after. I think that will remain true regardless of if a team of sw developers are doing it, or an AI with a product manager or somewhere in between.

▲ mitxela 5 days ago | parent | prev [-]

Technical debt remains the same. LLMs are found not to work as well when editing messy codebases - exactly the kind you get after using an LLM for a while. After a few weeks or months you have to either throw it away and start over, or involve a human at exorbitant prices.

▲ squidbeak 5 days ago | parent | prev [-]

> I think these authors are making a much stronger claim that AI is proficient or even an expert at software engineering.

The author specifically says:

> I am sure it is not perfect (I only spent an hour working with the results), but a software engineer would iron out the remaining potential bugs that I could not find quickly (which is one reason we may need more, not less, coders in the future, to help with the explosion of new uses for software)

which acknowledges pretty clearly that engineers bring a level of insight and experience still missing from Mythos. Saying that, I totally disagree with his contention that this will always be true. It's pretty weird that the author of an article stressing the steep improvements in a model's capability can't seem to imagine further improvements in that capability. As if Mythos is where development ends or whatever gap remains between models and experts won't steadily narrow or eventually widen in reverse.

▲ SpicyLemonZest 5 days ago | parent | prev | next [-]

It is, and it's cool that it is, but the calibration is important. Statements like this:

> With Fable the spell has gotten powerful enough that I am no longer sure I am the wizard. I am closer to a patron. I describe what I want, I pay for it, and I judge the result. The conjuring happens somewhere I cannot watch, in hundreds of small choices I never get a vote on. The work has shifted from process to outcome. I no longer steer; I commission.

have a very different meaning coming from a non-technical researcher than they would from someone who builds software for a living.

▲ shimman 6 days ago | parent | prev | next [-]

Making side projects isn't a trillion dollar industry tho, adding to the fact that we are facing another global supply chain crisis due to the Iran War; the US is about to commit the biggest self-own ever in the history of empire.

▲

Schmerika 5 days ago | parent | next [-]

There are actually quite a few trillion dollar industries that exist thanks to "side projects".

Apple was Woz's side project, once upon a time. Adsense came from Google's 20% time. Social media started as a side project.

Forests grow from trees. Trees grow from seeds. More potential seeds = more potential forests.

	▲	queenkjuul 5 days ago \| parent [-]
		All the undiscovered Woz's of the world add up to a trillion dollars? There's $1T of money out there waiting to be spent on side projects? The question was "are side projects a trillion dollar industry" not "has a side project ever started an industry" How much of a new $1T software product will anthropic capture in token costs, anyway?

▲

zelphirkalt 5 days ago | parent | prev [-]

The US has been on a course of self-owns ever since Trump got into office. That they still are a dominant power on the globe shows how much they were one before Trump, but it seems to be changing. At every self-own they commit, China laughs and inches up a little closer. I think we will see the day, when they are evenly matched in our lifetimes.

But which self-own exactly do you mean, of the many there are?

▲ bandrami 5 days ago | parent | prev [-]

Well, right, but if the real use case for LLMs is "making software that wasn't economical to make before" that's bearish for the labs because it means they're only going to be chasing the low end of the market.

▲ neilv 5 days ago | parent | prev [-]

Relevant quote:

> I am sure it is not perfect (I only spent an hour working with the results), but a software engineer would iron out the remaining potential bugs that I could not find quickly [...]

People have said things like this many times in the past, and, in the past (perhaps not now), it's always been a misunderstanding of what is good and bad, what's difficult and easy.

For example, someone would draw a UI in a GUI painter that generates code (or a resource file), and a manager would see it and think the majority of the work towards the product is done. (Incidentally, then there seemed to be a reaction, towards making your UI mockups look abstract or otherwise different from runnable code, helping the nontechical to understand that this isn't 90% of the finished product.)

Or a student intern hacks out a homework-grade demo, and a manager who understands neither software engineering nor product domain says "we just need some engineers to polish it up for production", and thinks the student is a star and why can't their engineers be as brilliant and productive. (I might have once been that energetic intern, who was happy for the encouragement, but then learned more, and saw it was a thing.)

This common misunderstanding was sometimes self-correcting -- when trying to ship became a disaster of misery and regretted-attrition, or the product was poorly received by the market because it wasn't thought through nor implemented well, or building subsequent functionality atop it was a nightmare. (But adverse effects of bad approaches is one of the reasons for management and ICs to job-hop, before the unwanted effects affect them personally.)

What might be different now is that some of these AI tools are outputting better-engineered work than some software engineers, and much faster.

At the back of my mind, I'm wondering how the really great software engineers will continue to stand out, as the discipline is being devalued in the minds of most leadership, and anyone can prompt an AI to generate something that superficially appears to them like what they assume a great software engineer would produce. (Even if the great engineer would do much better quality of implementation, have innovative ideas that ML from open source code would not, and maybe arrive at better product concepts as they worked through the problems.)