When I personally want tight code, I have to spend a considerable amount of time adjusting it manually:
- It needs to be trimmed down. In my experience, at least one agent I use struggles to produce minimalist designs, and it's very frustrating
- I need to consider whether there are solutions based on higher-level assumptions, that AIs typically miss
- I need to check whether there are off-the-shelf solutions - AIs like to reinvent the wheel
IMO, software production has become a mass-produced commodity in every sense - it's much more expensive to produce software manually, but the quality is not the same.
> software production has become a mass-produced commodity in every sense - it's much more expensive to produce software manually, but the quality is not the same.
Agreed.
Homer reunites with his long lost brother, who runs car company Powell Motors. Homer is ultimately tasked by his brother with helping to design a car for the “average man” that ultimately bankrupts the company for being wildly overengineered and costing too much ($82,000 in 1991-money).
Here’s the car: https://simpsons.fandom.com/wiki/The_Homer
You will really have to weigh the cost of making the software against the expected revenue.
In such markets, what you produce is either worth nothing or worth millions of dollars. For as long as it's the case that well-constructed code (with or without LLM help) is more likely to be in the latter category, the economics of software don't really change.
Even before LLMs, you could've commissioned a half-assed clone of any app you wanted from a 3rd world consultancy for a few thousand dollars. LLMs are basically Bangalore-as-API.
I remember hearing a story that in the past movies were so technically difficult to make that any movie that got made had a good chance to be a profitable hit. But as movies got cheaper to make, more movies got made. Nowadays movie studio execs have to really calculate out the audience and expected revenue for any new movie and balance that against the budget and the cost of the studio's failed movies.
I think a similar dynamic may happen in software
That might be part of it, but I think it also has to do with the reality of replicating and scaling. Hardware or physical goods simply don’t scale like digital goods. There can be hundreds of knock-off physical products that have lower quality and lower cost but serve 90% of the same purpose, because physical capacity for raw materials, construction, labor, shipping, etc. have scaling limits in each market and economy. Digital goods are just so much easier to replicate and scale, so it often doesn’t make sense to buy software at lower quality and lower price if it doesn’t do most of the job. There are still limits of course, and different from physical goods, but I think this is a key reason why software is seen as winner-take-all.
I.e. because software was hard to make and complex to copy you would tend to have "natural monopolies" that were hard to compete with. Who wants to try to build a new desktop OS to compete with Windows? Or a web browser from scratch? Or a new search engine? Etc.
Those and other pieces of software were complex and hard to make. The cost to copy and compete was very high. So one winner took most because that winner was the company who could figure that software out.
But as we can see with Kimi Work and other such things, software is now much easier to copy. Let's say it took $1 billion to make a copycat piece of software with people but now takes $100 million or $10 million with AI. Suddenly a copy and compete tactic makes much more sense than before
For example, with AI it might make financial sense to build a Chinese Native OS instead of Windows. Similarly for Russia, Iran, the EU, and a whole bunch of other places. All of a sudden, Windows might not be the winner take most OS, we might have lots of Operating Systems, with smaller markets and lower profits, which require much more careful financial analysis to stay profitable.
This would be just like Movies, TV Shows, Books or Music. When something works, people relentlessly copy it and different regions put their own spin on the idea. After Iron Man succeeded we had so many super hero movies. Etc. So there is not really a winner take most dynamic in these other digital products. Software may be moving that way
Fairly sure software dev was always an iceberg. Most software and most software devs aren't working on horizontal software, but on vertical software, in cost centers. Sales for that kind of software don't scale as much.
[1]: https://pluralistic.net/2024/04/24/naming-names/#prabhakar-r...
Same with a junior dev. They don't write long form spaghetti because they're trying to write more LOC. They do it because not doing it is hard, literally above their pay grade.
I use LLM every day, but they're still completely awful at architecture. I don't think this clear lack of ability is some conspiracy.
I was only able to do that after I had solved multiple related problems in different places and started introducing subtle bugs by accident / had difficulty detecting all edge cases
I've noticed whenever I use LLMs they introduce the same kind of thing but at much smaller scales than I would. They often suggest solving the wrong problem when I prompt them to diagnose specific bugs too. Usually opting for a shortcut that introduces its own issues and ironically calling the proper direction "too complex" when it's really not.
For who?
The public? The public has never liked buying software at any price.
Businesses? Businesses need higher quality software when it's relevant to their core competencies, so they hire people instead. Buying competing SaaS or depending too much on AI is throwing the baby out with the bathwater.
Also just remember - minimalist code looks and feels great but customers do not read your code. I have caught myself many times providing "corrections" to abstractions that were already ~fine, just not perfect. The average SWE costs $200/hr. Careful you don't burn $50 worrying about code that will likely be rewritten or can be better abstracted when that's actually needed.
This is a pointless quibble but the hourly rate claim is not true--it's like ~$60 in the USA [0]. Maybe you meant at a specific Org but this is important context when comparing "pricing" between human and AI.
[0] https://www.salaryexpert.com/salary/job/software-developer/u...
Even for a junior making $100K, I have a hard time believe their time is worth less than $75/hr or so.
Edit: Fine, "Senior" is not "Average". But naive salary is not the true numerator.
I have a hard time believe their time is worth less than $75/hr or so.
Pay hits a ceiling, and that ceiling is moving lower regardless of experience. That has nothing to do with AI, but what the market will bear. Hiring counts of humans must increase no matter what. Moving some of the spend to AI reduces the risk of hiring less qualified employees they might have rejected a decade ago.
Wages at the top end are stagnating to subsidize this. That's undeniable.
"Will I benefit from this code being minimalist before [date]", where [date] is whenever you think the agent will be good enough to come back and make the corrections you would make today.
Even as a self-contained unit, you can't step in the same river twice, and on [date] some important details may have seriously faded, both in terms of text that can be mined and also in terms of human "why did we do that" and "what was the reason we did it this way and not that way" etc.
And this is how I find out I'm woefully underpaid.
How does a “small startup” end up with a multi million line “legacy” codebase? Something not mathing
Easy! The output of 6 months ago Opus! Which seemed so wonderful at the time.
My observation has been:
- Initial greenfield work by an LLM is fast and very effective with minimal or no human oversight.
- Subsequent work ends up being over engineered and very verbose. Assumptions are made that aren't suited to the problem at hand (for example I find Fable is extremely regex happy where structured data would work much better from a readability perspective.)
- Once code bloats beyond a certain point due to unguided LLM usage, complexity is high enough that only LLMs can operate on the codebase with any economical amount of time.
- Rinse repeat and your code ends up unclear about any state that's not explicitly being tested and verified in QA loops
For some of our products this has been fine, for others it's been problematic. An understanding of your size and reliability requirements will help make the conversation more productive.
Why aren't you guiding your LLM usage? Is that what I said - to spam it and not guide anything? Or to have a careful workflow where you agree on design and maximize your human judgement/leverage?
> any state that's not explicitly being tested and verified in QA loops
As opposed to before, when engineers perfectly reasoned about code behavior from first principals and QA was unnecessary?
You didn't say anything positively or negatively regarding this so I made an assumption that you were using the LLM relatively unguided (e.g. a bit of oversight, not the kind of thing that heavy code reviews used to involve pre-agents.) Feel free to add clarity on your actual usage loop.
> As opposed to before, when engineers perfectly reasoned about code behavior from first principals and QA was unnecessary?
In my experience, most engineers are quite good at reasoning about code behavior for non-QAed code paths. Obviously things fall through the cracks. But I've been in the ground floor of plenty of Big Techs in their early stages before agents and, yes, a lot of initial development had spotty test coverage and yet most of the engineers had good mental models of what was happening. It used to be a very valuable skill to wrap your head around a torrid piece of code with few or no tests but was nonetheless a core piece of your application. Conversely, agentic development can bring cognitive debt [1].
===
This isn't a fight. We aren't sparring over what's right and wrong. I'm just curious how other people use agents in their work as someone who is also now in a startup that uses LLM agents heavily and has no limitations on spend.
I feel like this statement betrays your lack of advanced experience coding with LLMs.
OP's elaboration of the steps they are going through (planning, agreeing on plan, getting one LLM to draft execution plan, approving it, then executing with a separate LLM, then reviewing/testing) made it super obvious to me that they are guiding their LLMs quite considerably as part of their work.
Anyone making blanket statements about LLMs producing garbage is just telling on themselves about not having proper SDLC practices in place.
I find for my own work that I need to read the diff the LLM produces then offer feedback on the diff in its own loop before I am satisfied, and this is after all the unattended QA steps through Codex Computer or Claude MCPs happen. Then auto reviewers come in and then reviewers come in. Of course, at our stage, we rarely have this luxury and it's only reserved for the very core of our codebase.
This is still much less guidance than we used to do for code before agents became popular. Even at Series A companies, before agents, we used to socialize tech specs, get buy-in from multiple engineers, create test plans, etc etc.
> Anyone making blanket statements about LLMs producing garbage is just telling on themselves about not having proper SDLC practices in place.
> I feel like this statement betrays your lack of advanced experience coding with LLMs.
Are we in school debate club? I don't know what's going on lol, I'm just curious how people are using LLMs! Is it just that irresistable to take a cheap shot at each other?
Not that I know of but that's the conclusion I drew from your statement.
It's not a cheap shot unless you took it personally?
I suppose I could have said "the fact that OP's explanation of how they work did not lead you to conclude they were in fact guiding their LLM usage quite a bit tells me that perhaps you have not been working with LLMs in any advanced capacity".
For the SDLC comment I admit it was a broader statement (based on observing people generalizing that "LLMs produce bad outputs") and not specifically aimed at you, and I didn't make that clear, so my bad.
Yes, this is literally what that means.
What exactly does "unguided" mean to you, then?
Design is too expensive, we do agile. QA too expensive, we fire all of them, and claim devops is the now, which allows us to fire the Ops team too, 100% ownership from deisng to ops on devs.
One person with an agent can replace all these teams. Yeah mo profits.
What is the point of working at a startup if you’re dealing with millions of lines of legacy code ? Isn’t the whole point of startups to create & innovate with a clean slate and modern tools?
I’ve never seen a startup with a multi million line legacy codebase.
>”Have you worked at many startups?”
In response to a question about a legacy codebase at a startup. That implies that they think whatever they are doing is common. And forking a multi million line codebase and heavily developing it isn’t common for startups.
OP might just be working at a small software company or for one that broke from a bigger one and is now "startup" like?
And if you're saying (based on your other comments) that a 6 month window is enough to create a legacy codebase...that indicates a serious lack of experience or understanding as to what a legacy codebase is, or why they exist.
Accept that other people may ascribe different meanings/interpretations to words than you, and that if your reading of their statement doesn't make sense to you, perhaps you are simply reading it wrong.
Trying to hold someone else to your definition of words suits what purpose exactly? Are you just trying to "win" ?
But who cares? The point is any codebase over a few years old with lots of customers and a big surface area has lots of code, much of it "legacy" from the standpoint of a guy in 2026.
15 people is a pretty small startup, what if this is a 50-person startup?
Doesn't seem like that much to me, depending on what you're building and the size of your team.
This whole thread around loc is depressing. It speaks volumes of some peoples inexperience working on actual legacy code. Legacy code is not just age or size but that the technical foundation is dated in a fundamental way. A giant monolith running on a now defunk framework using a database only one guy in canada knows about.
Case and point in my day job. The org that owns XMM development does not know how to recover a physical bench that is bricked because everyone who knew how has left. So now they just use simulators…
Interestingly, AI figured out some of this pretty easily for me. But the org has the exact same AI as i do. At the same time another org is close to a year into a greenfield rewrite that has been developed via agentic swarms. Absolute trainwreck.
AI doesnt make bad engineers good. Anyone who says they are doing 4 eng work likely would be without ai too. Those that claim otherwise, are the bad engineers.
- Suggest a better approach that makes the AI say, “That’s much simpler. And you’re right. My original plan was over-engineered.”
A lot of my high costs is because I just throw Sol at everything. If I were more selective and brought in Luna or v4 Flash every once in a while, I think I'd be more like ~$400/month. That's why I'm not aligned with the notion that "tokens are subsidized so that's why people are using so much": its not that I'll have to adjust to using less, its just that I'd need to think before I prompt a bit and be more judicious. I could easily see my raw token counts doubling or tripling in the coming months. I don't think that will change as subsidization subsides; though maybe lab revenue will; intelligence per dollar is getting cheaper every week. Its solely a function of adaptation to process, which takes time.
The productivity gains per token are the single most asymmetrical thing I've ever seen in engineering. The engineers on our team are pretty effective with tokens; easily that 2x-4x output as you're seeing, spending $20-$200/day. Some of our security folks have also started contributing more-and-more code, and they're on the other side: they'll spend hundreds a day running in circles, eventually producing these +/-30k loc pull requests that take ages to get merged and are littered with issues. They weren't writing much code before, so arguably they're more productive by some multiplier greater than 1, but I think the drag on the rest of the team, and potential issues with what they produce, has overall created a net-negative situation. Inversely, some other company functions have produced a few one-off websites for things like sales processes, and those have been a huge win. The asymmetry is wild. There's almost a valley of incoming skill where if you know nothing about code, you'll leverage it well; if you know just a little bit, it makes you super dangerous; if you know a lot, you're the biggest winner. Really difficult situation to navigate.
I have had some $3,000 token days - even without Fable. I don't see how this is sustainable.
My personal 20x plans get so much usage for so cheap. The consumer subsidies are crazy, but alas I can't use them for work.
It actually gives me quite an uncanny feeling, bulldozing over years of human optimization work with a newer, "perfect" design. Like bringing an AK-47 back to the middle ages.
it's so hard to square such totalizing statements with my day to day experience with fable and sol, (every possible, improvement, really?? they are NOT omniscient) arguing with them/my colleagues' agents that no they have slowed down the system 200x with their terrible change, doing string operations on millions of db rows, trying to get it to understand that I don't care that it's calling it a "cache" if a cache hit is slower than what we had before.
These agents do let you learn codebases quickly, and produce code way faster. I don't look at IDEs all that often. But literally multiple times every single day I catch them doing something stupid.
I don't think its impossible that we could get better performance from the agents. I know ive tried all sorts of workflows and skills, few of which seem to have much effect on the things the models struggle with. I think a big part of it is encoding enough context for large codebases, and providing it with all the tools it needs to make it successful, things to automatically check its work, etc. But that's not automatic, in fact its generally a terrible judge of what it needs or what its bad at
but the revolution is it doesn't take that long. in like 15 minutes you can chat with fable and get to the meat of whatever the issue is with repeated questioning. and then it does the solution for you. so it's not magic but it's still like a 100x speedup.
Opus and I wrote a parallelized test harness and labeled groundtruth in around 2 hours.
In 2022 that would've likely been all I did for a couple sprints
That sense that you did something better in a few days than you would have in a month 5 years ago. It's like buying a table saw for wood working.
One crazy thing I think about often is how there are so many correctness and testing harnesses that would have taken weeks to build in the past so we simply never would have. We'd just do our best then wait and see what comes to the surface. This is a huge part of what makes it possible to actually make better software with LLMs in my opinion. It isn't just 'LLM codes better than I ever could' (that's often untrue still) but 'LLM enables me to make assertions about the program to degrees that would have been absurdly impractical in the past'. It's huge
In this case the design was also AI generated, and there were limited wins to be found because the design was already superb.
I'm in an infra team and for the last 2 weeks or so I've been trying to understand whether a particular workload will catch fire if a switch is flicked. I'm also new to the team so partly it is me wearing training wheels, familiarizing myself with the telemetry etc, but I will state that I'm not completely lousy at this stuff.
No model in my experience can do anything remotely comparable to the work "what happens to the workload if this switch is flicked" needs. They can't even design a reliable quick experiment to answer what cast should be applied to the binary trace_id in table A for the join to table B to work. They will happily do something idiotic and then conclude that the join does not work.
you should probably be doing this discussion work along with Fable 5. It will give good feedback if you're working on the correct things.
> Come up with QA plan and have Codex Computer Use execute on it
QA plan should be part of the above "design + plan", not after it. The implementer needs to be able to fully test before publishing a PR. This is true whether humans or agents are writing the code.
> Manually spot check the final result (usually a sizable diff, thousands of lines, complete feature E2E, etc)
unfortunately this is not really scalable with amount of code agents can produce, so you need independent (fresh context) agent reviewers to help. Ideally they only escalate to a human when really stuck.
> I probably spend like $80 a day at least
at a small startup you should be on the $200/month plan(s).
But that's also why it's now easy to justify the cost of an Nvidia or Intel inference server with Kimi K3 locked and loaded :)
Wait what? I don't understand these numbers. I spend $1k/day
Your story about being told to use AI for everything I was expecting you to be well over that
Gotta love this loop, I have it running while I'm asleep all the time.
Are you at least conversational in the subject matter? You're gonna have a good time just by paying attention and adjusting your workflow. If you're getting a lot of back and forth with it, its asking a lot of planning type questions, stop, step back, rethink the whole feature, and start again from the beginning with everything more fleshed out.
If you are in a brand new field, there's no way to bridge that divide. The issue is you don't know what is good or bad, or whether what you have learned is good or bad. You're in a sports car and you don't know how to drive much less what's track and what's field.
You can spend a lot of effort getting good at prompting towards writing tests and E2E tests to at least verify your app does what you expect it to, regardless of experience.
I actually have no doubt that I could replace my Opus 5 Low/Medium subagent profiles with Grok 4.5/GLM 5.2/Deepseek v4 Flash and perf would probably be pretty similar.
On top of that - highly recommend adding accurate cost counters to your statusline. You can't improve what you don't measure! (Or even have any intuition about).
> I probably spend like $80 a day
This doesn’t sound like “unlimited”, I spend more than this out of pocket per day and I have a strict budget.
Possibly, but the output of a 2022 engineer is about 1/10th of the output of a 2010 engineer, so it's an extremely low bar.
I would love to see what these tools create but outside slop there's never: This works, is in production, here's the code.
Any day now.
It was all generated in the last 4 months, so don’t come at me with the “but did they use a model from the last 6 months” nonsense.
no one’s AI spent will be in question working a single terminal with carefully planned out and executed process you do