A significant (majority?) portion of developers have been shipping JavaScript/node applications for the last decade that contain hundreds of MB to GB of code from god knows where doing god knows what with dependency trees the size of redwoods. It’s not like your average mediocre dev really knew what was going on behind their gluing of frameworks together - at least from what I’ve seen.
If you have remotely competent tech leadership that enforces relatively intelligent patterns (a good one I’ve found is “write everything backend in rust”) you can make AI churn out monstrous amounts of code that… isn’t all that bad? And if you enforce it writing and updating a docs/API.md on every commit/PR you’re probably doing better than 80+% of devs I’ve ever met. Up until a few years ago it wasn’t uncommon to roll up to a new job that was a “legacy” pile of garbage concocted over 20+ years with no comments or API docs and a readme that tells you to ask for help from someone who has been dead for 5 years. At least AI code is full of comments (some of which might even be accurate) and there’s a finite (relatively low!) cost to figuring out “wtf is this doing and how is it doing it”
What happens when the maintainers lose access to frontier models because of cost, politics or other external factors? What happens if they don't have enough hardware to spin up an open-weights model?
I've seen variants of this play out before AI, so I can tell you: they will inherit a codebase they've never seen before, take forever to ship fixes (forget new features), and they'll either scrap it, completely rewrite it, or, if they're "enterprise" enough, will pay consulting companies literal mountains of cash to make it their problem.
The whole point of writing simple code was to write code that other humans can maintain. If AI is here to stay and becomes economical enough for everyone to use it, then you're right; writing code for other humans is no longer useful. If that doesn't happen though...developers who can/want to still code by hand will be loving life
and there is a community of developers who care about the quality of those libraries and take the weight of their responsibility seriously
You can give the AI the spec, and own the spec instead of the code.
Eventually, the spec too will be something the model owns, and you'll work at a higher level of abstraction.
Beyond a certain size, the documentation becomes too large to ingest. Below a certain size, it can only contain a fraction of what is needed. If you take any sufficiently engineering project, and give every engineer amnesia; the project will go to shit for a undetermined amount of time, as it takes months or years go build-back the understanding that was lost.
This is clear enough then large companies fire and replace workers randomly to cut costs; a worker that has built up useful knowledge in the origination over a few years is more valuable than three cheap consultants from "low-cost countries" that are fired when the work package is over.
---
AI, looses its memory every time we press "new thread". No spec can bring that back until AIs become able to write and ingest whole books of context without getting confused.
The revenue for a new feature today is something sure. While the cost associated with supporting such feature will be up to debate in the coming quarters.
As often it is the case, we are moving on a long vs short term trade-off space. And I don't think any experience will generalize
When I worked at a big tech company on a large codebase (tens of millions of LOC across dozens of repos), it was extremely common to work on something in an area of the codebase I had zero familiarity with, and due to turnover, no one else at the company did either. As you say, docs were frequently missing or out of date.
However, with some effort over a couple hours, I could make a LOT of progress in understanding the history of the code. Every commit and PR were linked to JIRA tickets, most had eng design docs with comments, slack discussions, etc. I could step through the git history and watch the code change, alongside the artifacts of the human discussion and decisions that led to the changes. It wasn’t perfect, but I could make tremendous progress. Now, this was a remote company with pretty strong culture around using JIRA, design docs with review, etc. Probably the biggest gap was meeting transcripts.
Today, an agent can chew through years of history and artifacts on a large codebase in a half hour, documenting as it goes, and have way better understanding of it than I ever will.
It’s true that an agent can’t hold all of that in its head at once without context rot (though this is improving every year), but neither can any human!
If your goal is understanding how to do something, why something was done, why something wasn’t done, etc, and the codebase is large, mature, and extremely well-“artifacted”, I’m not at all convinced that you’re better off asking Bob who has worked on this section of the codebase for a decade than just asking a really good frontier-level agent. Maybe, but it feels like that won’t be true much longer.
At my last job we worked in a large, but publicly available code base. My experience was that just giving an agent the prompt to look at area X to figure out how it works would use up half or more of the context window. And that was thrown away every time we started again. We had docs, agent generated overviews but the agents still filled their context windows way too quickly to actually really be any use.
Like "if you're using this database, and the engine has these configurations, then do _x_, unless _x'_ and _y'_ are enabled, in which case, do _y_..."
Which, if you're already being THAT specific in your spec, you might as well, idk, write the code yourself?
Because at that point your human language is basically the code and AI is the compiler. A non-deterministic one.
Regardless, your business stakeholders won't understand what's going on anyway (nor should they), so we're back at square zero.
(I wrote Technical and Functional Requirements Documents as a business analyst in college. What's happening now _for most situations_ is more or less the same thing.)
AI abstracts effort and cognitive load away from code at a heafty rate, but it doesn’t abstract liability away from code at all.
My business is paid to produce artefacts for which it has liability in the case of error, so we need to do additional work to mitigate and eliminate the liability risk introduced with language models. So far I’ve not found a better way to do that than a plan/act/assert type approach on every feature.
If you use established libraries then actually the code IS well known to someone (and likely many), even if that's not you. Likely it was built with an actual purpose and with the foresight to not add red herrings to the design.
You can't say any of that for the equivalent amount generated lines. Literally no one knows what it does.
Arguments against it are sort of like why have devs on staff at all when you build the thing the first time, or why not outsource everything, or why should I care what my code looks like when the code seems to work?
The cost of tokens is not zero, and the bigger the thing you’re doing the more low quality will cost. When your company is the software, you take on an existential risk based on the software working or not.
Pure AI generated code without human curation is full of bad wordy comments but those comments can mislead, be stale, contain duplicates, and drastically reduce the ability to understand things. I watch teams that still care about code understanding ship good products while those vibe coding in the same org just flounder after the initial burst of features. Some problems only come up after the first 90%, and AI can help you solve them but a big ball of spaghetti is still a big ball of spaghetti.
I.e. how hard is it to point an AI at a piece of software and say "AI, copy this"?
Seems like sooner or later copying just becomes a matter of spending enough on tokens.
Seems in that world, all significant software projects get copied. That turns software into a commodity loss leader for other business models or an open source project. Similar to the way Chrome works for Google and the way Firefox works.
Won't you be worried if your mechanic didn't understand your car but offloaded it to a robot that made mistakes all the time?
This is what happens when executives suffer from AI psychosis. They were already impatient, now with AI all they care about is feature velocity.
The faster they can hit that refresh button to see the features, the quicker sales can close the deals for them.
AI has basically sold them to wet dream.
I guess we just wait for the boom.
I see it kind of like baking/cooking. Do you bake your bread from scratch? Do you grow your own wheat and grist your own flour?
I think over reliance on it or not even trying to understand what is happening is a big problem to be sure, but it's certainly not a new problem.
Actually baking is a good example, I used to be really bad so I spent time learning. I don't do it every day but now I understand how bread is made. I bought a 3D printer so I could print parts to fix stuff myself. I learned to do my own oil changes, I learned how engines work, etc.
My point is that I try to learn more, not less, which is what AI is trying to achieve
And I would understand how to bake bread from scratch.
Now in the entire chain, we will get to a point where no one knows anything.
E.G. over time we’d gained two client-side caches of related server state. This started out as two different parts of the same model, because we couldn’t get all the data we needed from one microservice and had to merge in the client. Over time, more and more features used both caches for different aspects of related processes. At some point one of the microservices changed so as to return all the data in one call. The update to consume that kept both caches, adding code to sync them, because so many parts of the code were using one as a fallback for the other, so they both looked “necessary”. Because they were separate, and “live” sometimes they’d go out of sync after the initial load. Worse: the consumers alternated about which cache was treated as the fallback, making it very hard to see that either might be redundant. Eventually I noticed they were filled by the response to a single call. We all know paying back tech debt never gets prioritised, so I rolled the payback into two feature tasks, and just took longer about them.
My employer expects we use LLMs and provides some budget, but it’s not enough to use even Open4.7 or GLM-5.2 on every task. I do the bulk of my work with Composer 2.5. It’s quite good for “going forward” on smallish tasks and it’s written most of my code this year. It’s possible smarter models would spot these refactorinh opportunities and action them proir to building features or fixing bugs. But I wouldn’t know because I can’t afford it. I’ve never seen even a 4.8 era model spot a refactor and plan to do it prior to a “new build”.
I’m pleased I’ve spotted these trends and started to build the habit of (telling the agent to)“refactor to make the change easier”, but my percieved productivity will go down and I risk the ire of my leaders.
I very regularly use plan mode not to even make a plan of action itself, but to better understand what possible issues might come up when implementing some feature or fixing some bug. And it is quite common for me to fix or rewrite certain findings that AI comes up because its assumptions are not quite right or don't align with overall goal.
And yet so many seem to be perfectly fine leaving all the decisions to AI - even if it's going in the wrong direction. I suppose that's all the people who got into software purely for money or status - never really caring about the actual thing they are working on.
The funny thing is that the AI adopters are in the middle of the bell curve. Our worst devs continue to perform worse than AI yet refuse to use it and our best devs continue to insist AI sucks despite it finding issues in their code and the reviews and designs they've approved.
Shouldn’t those “fixing bugs we gained in the past” be their own MR that can be read, reasoned about and have evaluated test coverage?
In the case of what I'm currently working on, filing bugs for every issue I found, and then factoring out each fix, and then running each change through the 8 hour ci/cd system, and hoping an unrelated issue doesn't get misattributed to me... No, I'd rather just wrap it up into one coherent refactoring change and be done with it because when I'm done there are several more like it waiting for my attention.
Couple of WTFs that come to mind:
* How many bugs did one have per commit, that commits have to noticeably grow in order to not have those bugs in the first place?
* How does one even do software engineering if the (best) developers can’t reason about the code?
Software engineering is possible but largely a myth in practice.
At a company I had setup scripts to build our packages, and the CI was running those scripts. Someone more junior (only a few years, not decades) found it strictly superior to remove my scripts and replace them with GitHub actions: people could now know even less about it (as in, no need to know how to copy-paste and adapt the recipe for a new package), but now it depended on GitHub. GitHub is down, nobody can build anything anymore. And it happened once every few weeks, so people would just go have a coffee during the outage.
You know what happened next? That person got promoted for their good work. That was before AI.
If you don't understand the codebase, ask the agent to explain it to you. I'm not not kidding. Modern frontier models are fantastic as this - even more so than actually writing the code. It can tell you in words. It can generate architectural diagrams and sequence diagrams. It can write tests and scripts that prove it's assumptions. It can happily refactor so that the system design is aligned with your preferences.
Once you accept this, you can stop worrying so much about it and instead focusing on building the architectures and tools that lets the agents succeed better and faster - so called closed loops or agents prompting agents. Build systems that are more easily verifiable and deterministic so the agent can write very powerful property based tests. Focus more on what and why you are building, how to make sure all external properties are verifiable and leave the internals to the agents. The code is not really for us anymore.
Then when you actually dig into the code, there are many things that are not like you'd expect.
When you've experienced that a few times, you stop trusting that the agent gives you the full picture - for good reason.
When I review AI generated code I generally find so many flaws that it makes it hard for me to believe that those who are not reviewing their output are not just fooling themselves. Maybe not all the time, but quite often.
One such recent example was an SSO simulator for a local env. Instead of using a cookie to remember who was logged in, the agent remembered the last log in a variable, assuming the the next requests would come from that login.
This snowballed into our tests, where later agents had created helper tools for working around the SSO simulators statefulness.
Things improve drastically however if you spin up a second session and ask it to adversarially review everything that the first session produces (this goes for everything: not just code, but also design, planning, and explanations).
This works even better if you use models from different families to do so.
The quote is "so simple that there are obviously no deficiencies"
I agree with this, but the reality is that it's only the result of models empowering devs, and power in good hands amplifies positive results while power in mediocre hands amplifies technical debt.
It's a good time to choose wisely who you work with.
Very true, but this also makes me think what kind of ridiculous obstacle course future hiring process would look like.
In a land where anyone with a pulse can prompt AI to make an app for them - how would future hiring managers and team leads figure out who will drag codebase down with tech debt and who wouldn't?
The tech debt concerns are much ado about nothing. Use the next model to clean it up, big deal. Code is cheap.
The people that sat around handwringing about tech debt and trying to read every line of LLM code will really struggle to find a job. The profession fundamentally changed, and these people did not catch up.
I think there has to be a better rubric by which person would be evaluated, not just amount of tokens they managed to waste.
I'm inclined to agree - the latest models seem to have crossed a threshold where trying to review by hand becomes akin to a manager insisting on reviewing PRs.
The reality is that models just keep getting better and are very good at cleaning up the debt they created. The "tech debt" bill never came due. It won't.
> The "tech debt" bill never came due.
Companies paying $200k a day for coding models to churn on what the coding models are messing up is one thing.
I’m not even worrying about tech debt, I’m talking full on defects, production incidents, security holes, and reputational damage.
If it turns into a hairball, just have a few agents rewrite it.
For me, this phase still happens, but a distinct "plan mode" is unnecessary: I just tell the model, "This is discussion; no code changes yet." and spend hours figuring out what will and will not be done.
vs
Press "Tab"
Like - you really think models won't be able to clean up the tech debt they created!? They are very good at this already. Ask Opus 5.5 to clean up the tech debt from some Opus 4.6 vibe coded app.
Code is cheap now. The most important thing is to ship, ship, ship. If you are handwringing over "tech debt" you have already lost - and you deeply misunderstand how good this technology is getting!
If we get to post-scarcity you never needed the money. But if we end up in some dystopian hellhole where people have no jobs but capitalism still exists, you'll be thankful.