▲ 270 points
back
237 comments
A lot of people down on AI in this thread, but I'm watching the industry slip over the line of trust with these latest frontier models. GPT 5.5 is the first model good enough for me to just let rip.
Every jira ticket I see now has acceptance criteria, reproduction steps, and detailed information about why the ticket exists.
Every commit message now matches the repo style, and has detailed information about what's contained in the commit.
Every MR now has detailed information about what's being merged.
Every code base in the teams around me now has 70 to 90%+ code coverage.
Every line of code now comes with best practices baked in, helpful comments, and optimized hot paths.
I regularly ship four features at a time now across multiple projects.
The MCP has now automated away all of the drudgery of programming, from summarizing emails, to generating confluence documentation, to generating slide decks.
People keep screaming that tech debt is going to pile up, but I think it's going to be exactly the opposite. Software is going to pile up because developing it is now cheap.
Most code before llms sucked. Most projects I on-boarded to were a massive ball of undocumented spaghetti, written by humans. The floor has been raised significantly as to what bad code can even look like, and fixing issues is now basically free if your company is willing to shell out for tokens.
> Software is going to pile up because developing it is now cheap.
Software to do what, though ?!
Coding, maybe 10% of a developers job (Brooks "Silver Bullet" estimates 1/6), was never the bottleneck, and even if you automated that away entirely then you've only reduced development time by 10% (assuming you are not doing human code review etc).
I would also argue that software development as a whole (not just the coding part) was also typically never the bottleneck to companies shipping product faster, maybe also not for automating their business faster (internal IT systems), since the rest of the company is not moving that fast, business needs are not changing that fast, and external factors that might drive change are not moving that fast either.
I think that when the dust settles we'll find that LLM-assisted coding has had far less impact than those trying to sell it to us are forecasting. There will be exceptions of course, especially in terms of what a lone developer can do, or how fast a software startup can get going, but in terms of impact to larger established companies I expect not so much.
The ticket has subtle errors in its description that are only caught by someone experienced with the codebase.
The code hides an exception behind an if-then-else that defaults to the most common state, which isn't caught until it breaks things for the 1% of users who don't have that state.
The new feature quietly breaks a feature not covered by the acceptance tests.
The documentation is four times as long and nobody who relies on it can read it.
And I'm stuck spending my time going over tickets with a fine-toothed comb, reviewing PRs, and mentoring contributors to prevent all of this garbage from ending up in the live code.
What you are describing is a the role of a manager, not a software engineer. Software engineering has very little to do with writing code, but more on architecting at the higher level on what needs to be done. The code is just the executional part. LLMs can code? Ok good. Without a clear architectural pathway / direction, that code is just useless. It's not tech debt. It's just a bunch of random strings. You can argue that Claude code and others do create a plan of attack - but still, it's not at the architectural level, but rather executional level.
To me, architecture starts all the way from the top - even before you write a single line of code, you do the DDD (Domain-Driven Design) and then create a set of rulesets (eg. use the domain name as table prefix) and contexts and then define the functionality w.r.t to that architecture. LLMs can do all this - only if you ask them to explicitly. So, they are pretty useful to brainstorm with, but not autonomously design reliably and push it to production with your eyes closed and support a 100,000 user base. It's a far cry from that.
But sure, you can upsell to management about the vanity metrics like lines of code and get that promotion with LLM. But, it's still not software engineering.
For people who like to tick boxes, which is essentially most of the above, AI is welcome. That includes managers.
It still has nothing to do with software engineering. All good code was written by humans. AI took it, plagiarizes it, launders it and repackages it in a bloated form.
Whenever I look deeply at an AI plagiarized mess, it looks like it is 90% there but in reality it is only 50%. Fixing the mess takes longer than writing it oneself.
>I regularly ship four features at a time now across multiple projects.
Well, this explains why so much software nowadays is so slow, buggy, and chaotic.
> I regularly ship four features at a time now across multiple projects.
Can that happen without you? I would assume this is the next step. I don't find it either good or bad, but I'm genuinely curious where this all goes.
> I regularly ship four features at a time now across multiple projects.
Many people are missing the fact that LLMs allow ICs to start operating like managers.
You can manage 4 streams now. Within a couple years, you may be able to manage 10 streams like a typical manager does today.
IME, LLMs don't speed you up that much if 1) you're already an expert at what you're doing (inherently not scalable), 2) you're only working on one thing (doesn't make sense when you can manage multiple streams), or 3) doing something LLMs are particularly bad it (not many remaining coding tasks, but definitely still some).
Software is going to pile up because developing it is now cheap.
It won't, because right now we're busy exhausting the vein of good-ideas-we-wanted-to-build, and that's the source of all the good stuff you listed. When that runs out you'll see teams building any old crap because building is cheap, and learning that experimenting by putting any old crap in front of users is a fast way to burn goodwill and brand loyalty.
You still need good ideas and the taste to choose which to put out there over the bad ideas that people actively dislike.
If writing code was the only part of the job, and it was easy, these jobs wouldn't pay so well.
Engineering is hard. It's always going to be hard. I'm glad that AI makes some parts of it easier, and we (software engineers) can focus on engineering, that's nice.
Code is NEVER cheap. Just because, at current completely unrealistic AI pricing, using agents is cheaper than hiring juniors, does not make code cheap. It makes producing code cheap, which has always been low-cost. Every line of code is a cost, is a maintenance burden, is complexity. An AI, even with somehow infinite context window, will cost more money the more code you have.
Could you replace a whole team of engineers with AI? Probably, yeah. Could you simply fire everyone at your company and close it down, without much of a problem? Also probably yes, for most companies.
AIs can help with debugging, can help with writing code, with drafting designs, they can help with almost every step. The second you let OpenAI, or Anthropic, take full code ownership over your products, and you fire the last engineer, is the time when the AI pricing can go up to match what engineers make today. You've just reinvented the highly paid consultant.
Or you could take the middle-ground and hire good engineers, make sure they maintain an understanding of the codebase, and let them use whatever tools they use to get the job done, and done well. This is the way that I've seen competent companies handle it.
Certain types of code are cheap. Proof of concept is cheap. Adding small features that fit within the existing architecture is cheap. Otherwise, I'm not so sure. Coding agents are fantastic at minutiae, but have no taste. They'll turn a code base into a ball of mud very quickly, given the opportunity.
I came here exactly to point out what I'm glad to see is 10. "Free as in puppies" is a wonderful way to put it.
Every time I open linkedin I'm scared of how many big heads have taken the wrong lesson that coding almost free == free engineering. So many bait posts asking engineers why they would need to pay them any longer, or being glad they're generating millions of lines a month....this is going to end badly.
I am in India, junior developer hiring is all down. Ai has reduced offshoring to India and eliminated the need for janitor work (often offloaded to juniors).
Many people are finding it difficult to even land internships.
The most affected areas are sysadmin, devops, and frontend. Where you'll have very hard time getting any offer.
Companies like BrowserStack are withdrawing campus placement offers.
Meanwhile, I am writing apps for my own use and have reached 10,000+ monthly active users already, even though I am making zero money from doing all this, but it's fun.
Guy works for the Overture Map Foundation, with Amazon, Microsoft etc. being sponsors. He has been boosting AI all over the Internet. I'm sure Microslop and Amazon are very happy with these efforts.
I'm glad that "10 ways to do X" submissions are allowed as long as they boost AI.
Realize it's going to be 10-100x more expensive once you have no way back?
This is such a weird argument, beside obvious #10 which will bite back with a vengeance, because... code can't be cheaper than free!
Since at least the early 80s a LOT of very important code wasn't cheap, it was free. Both free of cost (you could "just" download it and run it) but also free as freedom-respecting software.
I just don't get the argument that cheap is new. Cheap is MORE expensive than free!
We change how we value code: https://jerf.org/iri/post/2026/what_value_code_in_ai_era/
Short-short version, code will still be accruing value in proportion to how much of the real world it has encountered. The bottleneck on building valuable code will be how much real world there is to go around. As is so often the case, what may initially seem to kill SaaS will actually make them stronger as they end up with more exposure to the real world than some random guy's random AI code.
I used to work as a VP and a part of my responsibilities was to chop up tasks to self-contained work units that can be easily assigned to random devs. This was both morally problematic for humans (i.e. EVPs forced treating human = CPU) and very optimistic when it came to individual dev capabilities and domain knowledge. However, this style is precisely what works well with agentic AI coding and I have no qualms to use it.
"We" should not do anything. The LLM industry should go and find solutions for the problems they created, themselves. Not offload it to others through sneaky influencer posts. And we should hold them responsible, should they not be able to address the problems they are creating.
It's not a question of cheap or expensive; it's when to pay what costs.
With LLM's, it's arguably easier to avoid exporting costs to the future, or to export them.
Whether because of LLM's or frameworks, process consistency typically creates a forcing function to continuously improve quality (i.e., avoid exporting costs); for each problem, create step in the process to surface and address it - hopefully in an automated way.
Having spent lifetimes trying to get teams to up their game, I'm hopeful this may help, if it gets baked in not just to code generation, but to process.
The list in the article looks like verification practices. Document intent, develop taste, find the hard stuff, etc. It assumes that when code is cheap the bottleneck shifts to knowing whether what you generated is actually right.
e2e tests can do a lot, but in my experience it's not enough. By the time the test fails you've already burned a generation cycle on an artifact that came from a flawed spec or design. I've gotten more mileage from having checks at stage boundaries (standard SDLC: plan, design, code, test). We all know the earlier you catch the mistake, the cheaper the fix.
The "implement to learn" is the same idea: you need to know enough about both where you want to go AND the path to get there to guide the agents to a proper implementation. You have contact with the world, both the users and the operational considerations that come from running software. Agents do not. We do the same thing with spikes, but now our spikes become far more sophisticated.
Code being cheap doesn't remove verification, it moves it earlier.
> What should we do when code is cheap?
Make usable software. Cheap code means that you can create a lot more prototypes to then perform usability tests by finding a user and sitting next to them. I mostly worked on internal apps lately, so perhaps it's much easier for me to do than it is for some others.
#10 needs more emphasis than it receives. Cheaper code doesn't automatically lead to good product decisions.
Instead of focusing on whether you can build it, the scarcer resource becomes whether you should build it. And most teams lack a clear process for addressing this latter question. Requirements are collected in all sorts of places without ever being prioritized in an organized fashion. This is exacerbated by cheaper code. With cheaper code, you can release five times what you used to be able to release in a given period of time, but only if you knew which five products you needed.
Good list, I have intuitively realized all of these except for (3). I agree with the author: cheap experiments to figure out a grand architectural plan, then executing fast without needing to wait for input is the right way to go. "Automate everything that's easy" is also important, but I'd extend it and say you probably should try to automate things that are hard too: it's worth spending a great deal of time on it simply due to how crazy valuable the returns are. But I guess I should look more into end-to-end testing.
Code is a liability - the more there is, the higher potential for bugs and poor performance. I'd recommend treating cheap code like cheap toxic waste, and try to minimize how much is generated.
Apart from (2), the first seven lessons are exactly identical to good project management practices with humans. Which are also the difficult bits.
Once upon a time, highly bureaucratic organizations tried to make a distinction between "analyst", "programmer" and "coder": https://cacm.acm.org/opinion/the-myth-of-the-coder/
The pure "coder" role, per that paper, died out almost immediately. Nowadays it's done by compilers (a deterministic automation). The distinction between analyst and programmer held out a bit longer - ten years ago I was working somewhere that had "business analysts", essentially requirements-wranglers. It's possible that the "programmer" job of converting a well-defined specification into a program is also going to start disappearing.
.. but that still leaves the specification as the difficult bit! It remains like the old stories with genies: the genie can give you what you ask for. But you need to be very sure what you want, very clear about it, and aware that it may come with unasked-for downsides if you're not.
Not all code is cheap. Some code remains very expensive.
But the idea that some code is cheap and some code is expensive is not new.
The only new thing is there are some adjustments on how to asses the value of the code you’re presently, or about to, work on.
AI has absolutely expanded the set of code that is cheap and if you can make a thing easily with AI then so can someone else. That project is unlikely to result in valuable code. Which is not to say it doesn’t have utility. Just its monetary value is low.
Would add my biggest tip to that: TDD. Most people omit it.
There is a difference between:
- write code, write tests
And
- write tests, write code
Had another agentic (vibe) coding experience, which confirmed that for me. Creating an SDK for a $500 light so I can control it from my Steam Deck instead of my phone (no SDK existed before yesterday). For anyone interested, I'm teaching my vibe coding (I meant agentic) tutorial at pycon next week. The 3-hour-long version should be posted to YouTube soon thereafter.
I think you can boil down most of the list to: Understand what you want to do.
I’m not convinced about rebuilding repeatedly as a learning tool though. As relatively quick as it is, it over emphasizes the front line problems you face early. Those tend to be simpler, more straightforward issues that can be more quickly solved by a few minutes of thought (and more cheaply too).
Stop spending time on design. Try all of the permutations and stress test them.
Stop caring about extendable modular code. Just rewrite from scratch when you have new requirements.
Build a demo for every idea you have.
Build 100 visualizations and metrics for any algorithm you develop.
We are finally free of friction. Bad news is we have no brakes. Brace for impact.
I find the intent/why very important. I have a rule in vault related that basically anytime CC writes a WHAT (requirement, concept, RFC) it must colocated a WHY and the WHY should be MY words. It helps resolve a lot of confusion.
I think there is a massive divide in the market between large enterprises and smaller org.
The large enterprises are their typically laggard self. Prioritizing governance over innovation.
Everyone else, at least in tech or tech adjacent, is building. Build vs buy is the conversation.
People should do what has always been needed, rather than focus on how hard it is to build something, or easy, find what is needed, what right is, what good is, what quality is that actually solves problems and do those things.
> Automate everything thats easy.
Hold on, I better write this down, this is good stuff..
Wrong answers: $1
Plausible answers: $10
Good, useful answers: $100
Validation and Verification is what separate "should work" from "is shown to work".
Anyone can write non-functional code.
It's functional useful code that takes more work.
Code might be cheaper but it's still a liability. In that regard anything that's not been properly designed and documented is going to be an even bigger issue.
Is it cheap though? Do we actually know how much it costs? Isn't it possible that TODO app you vibe coded in 15 minutes actually costs investors $50k?
Every thread on this topic has so much authoritative pontification. In the end, it doesn't really matter what some $random internet person thinks.
It's cheap to change code, it doesn't mean you have to add more of it...
Stick to patterns which were painful before. For example, I recently refactored a project written in TS to use better-result instead of throwing errors. Without Claude writing out all of that boilerplate I could not have imagined transitioning to this. Right now the cost of "doing it right" is decreased so much there is no reason to ship slop / poorly thought out code.
the best code is the code you never have to write.
this means code also written by 'A.i'.
seems as an industry we're hellbent on optimizing for the wrong-thing.
Test it for god's sake. Test it.
Finish unmaintained Open Source OSes?
Learn to throw code away
I've found the get-shit-done tool[1] to be quite useful for forcing me to properly plan the implementation and ensuring the context remains small and relevant at all times.
It is slower than when I was just using Claude directly though.
Lessons for agentic swimming: What should we do when lead weights are cheap?
Also:
> It’s invigorating, rewarding, and deeply weird.
It's mind-numbing, infanialising, and deeply dehumanizing. Which, I suppose, is a valid description of the future silicon valley is building.
The remainder of the post is as vapid as the AI generating it.
Disappointing - not a very insightful list