I liked this article, and I see a lot of other commenters didn't, so I'll give my take:
When starting on a new codebase, how do you make yourself into a helpful contributor as quickly as possible? I go straight for the humans and their human docs. What problem was the system originally built to solve? What was the original design, and what were its biggest problems? Who is currently using it? If you know these, reading the code is much easier because you can guess why things were done the way they are.
I think Charity is observing a very old problem and expecting the new technology to lead to a new solution of some kind. I doubt she thinks even the current generation of tools are the end of the AI software development story. She's not saying we'll drop design docs right into Claude code and walk away (design docs aren't complete either, that's why when you're ramping up you also have to talk to people, read old tickets and postmortems, etc.)
What she's observing is that, in prod, people don't like infra where it's hard to tell how it got into is current state, and so infra-as-code is what we do now. She's also observing that, "it's hard to tell how it got into its current state" is the status quo with codebases, which other people have observed going back to "Programming as Theory Building" and earlier. And she's expecting that, analogous to infra, software development will somehow be done with tools focused on making "how the code got into its current state" clearer.
I wonder if the reception is so variable due to differing exposure to 1) infra as code and 2) engineering teams that don't produce any artifacts outside of their code.
> When starting on a new codebase, how do you make yourself into a helpful contributor as quickly as possible? I go straight for the humans and their human docs. What problem was the system originally built to solve? What was the original design, and what were its biggest problems? Who is currently using it? If you know these, reading the code is much easier because you can guess why things were done the way they are.
This is the way but plenty of engineering teams don't have any human docs at all. Decisions are made in one engineer's head or in a chat that isn't saved. The spec was just a few notes in a ticket that was deleted during cleanup or lost when the team changed trackers. There's no map of the codebase or features, no ADRs, minimal observability. All you have is the code. You read the code to try and figure out what is going on then ping an engineer who made a recent commit to a specific area to ask if they remember why something was done the way it was. Someone makes a change and it breaks something on the other side of the codebase that they thought was totally unrelated, etc.
Talking to an LLM is often still a lower quality result than asking the lead engineer themselves or the collaborators they left behind. You're making a tradeoff between time taken and result quality.
Even the most AI-positive teams prefer human discussion when things get that tough. Given enough time, things will "click" for humans. LLMs don't work that way.
Even a team of all-new unfamiliar devs forced to study an old codebase will eventually figure out what it was about and pick up tons of nuance the LLM cannot. This is the nature of writing. It exists in a time and place beyond the pure literal text. Humans live in this context and can get into the headspace of the original dev(s).
Agreed and I think the author agrees with this too. One of the ideas is that the devs should be discussing and documenting their intent outside of the code then letting AI tools generate the code as specified. "Engineering" should occupy the time that was previously occupied by "coding" and the context and writing should exist as intentional written context, not just poorly documented code.
That still so much assumes a "waterfall" ideal world where specs can be captured up front perfectly and coding is just an inevitable artifact of that with no creative input/feedback into the spec.
At least in my experience, that ideal has never existed. "Engineering" (and "re-engineering" and "re-re-engineering" in the agile worlds) was always what I was spending the majority of my time on. Coding was a medium for the engineering. By the time I finished the engineering the code was either already finished, being discovered in the written code and then documented, or the code was "the fun part" reward for all the hard engineering work that lead to it (and all the ugly specs documents it took to get there).
I agree that documentation should be made higher priority than "coding", but letting AI code everything is throwing the baby out with the bathwater.
It's from this perspective that a lot of engineers feel strong negative sentiment towards AI.
There are always going to be some critical sections of code that one must consider carefully. These tend to be at the extreme ends of choice. Either there's only one way to do it and it probably sucks, or there are many ways to do it and staying optimal is very slippery for maintainers. Identifying and describing these critical sections is also the most important part of the documentation. This is precisely where LLMs fail to do a good job and where people curse the original devs for not writing docs.
But as well, the overall architecture is just as important. The code for this tends to look like the "boring" boilerplate. This is the skeleton of the codebase and LLMs can be bad at this too, haphazardly jamming together design patterns that clash. We're in luck that, usually, a framework or library will provide this code along with documentation to be copypasted verbatim. The rub is when the developers are having to shoehorn it onto existing code they will have to carefully craft some custom interfaces and document them very well.
So in the end, what's left for the LLM to do? When it does a good job, it's usually cribbing so heavily from existing solutions by humans you could have copied it yourself if you knew where it got it from. The LLM is automating copypasta, not deliberate coding. When it's bad, it's making a mess only suitable for a rough proof of concept, if it even works.
From the perspective of a diligent engineer trying to avoid technical debt and other incidents down the road, burning an extra couple of days to get it done right by hand isn't that big of a deal. LLMs become about as useful as a google search. Assuming one does not work at a coding sweatshop, why not just use the google AI summary 90% of the time? The agentic workflow doesn't look promising for a significant chunk of experienced engineers working on maintenance more often than new projects.
> When it does a good job, it's usually cribbing so heavily from existing solutions by humans you could have copied it yourself if you knew where it got it from. The LLM is automating copypasta, not deliberate coding
I've been saying this a lot lately. I agree completely. Most of the impressive stuff I see people talking about AI, they could have just copied and pasted from open source repos in the past
I think that was sort of a taboo in the past though, for several reasons. First off, most teams I've worked on were reluctant to take on the additional maintenance of unvetted open source code if there were other options. For some reason this reluctance has flown completely out the window with AI, even though the cost of code maintenance hasn't really decreased.
Secondly, there was always the question of code licenses when copying from an open source repo. Companies were reluctant to risk anything that could be viewed as code theft
Now the code theft part is solved by training LLMs instead of just copying and pasting, which just feels like theft with extra steps to me
> From the perspective of a diligent engineer trying to avoid technical debt and other incidents down the road, burning an extra couple of days to get it done right by hand isn't that big of a deal. LLMs become about as useful as a google search. Assuming one does not work at a coding sweatshop, why not just use the google AI summary 90% of the time?
If there's one thing that seems unclear from AI proponents, that is the number of technology they're using at the same time. After months or so on a project there should be enough that should be in longterm memory or resources that are part of your browser history that things that require deep research should be a small part of each ticket. And it would be important enough to get it right.
"Asking the lead engineer" doesn't scale though. Writing shit down does.
So if your whole process is "just ask the lead eng" and you keep hiring new people, everyone keeps asking the lead and the lead quits beause nobody wants to do that.
If you write shit down, the new hires can ask your company internal AI system that has access to all of the docs and get the answer - with direct links to official decision documents telling the "why".
At the very least the lead engineer should write the answers down every time they're asked something and reply with RTFM after that =)
I liked the article. It was a long (and entertaining) build up to the conclusion, but I'm scratching my head how the author got there.
AI needs more discipline, yes. But theoretically that discipline can be learned much easier than becoming a good engineer.
Think of it this way... 20 years ago, to write good, scalable C code - you needed to 1) either be a genius, or 2) dedicated to the craft.
You need to learn dozens of tools like the back of your hand.
* ASan
* LSan
* UBSan
* TSan
* GDB
etc... God forbid if you needed to manually read DWARF files. Unless you're a pure genius, this is not feasible to master in a short amount of time. And in parallel, you need to learn how to design systems, too, otherwise, you're still not very good, and that's an almost completely orthogonal skillset.
Now, you simply need to be aware of the hazards in your language/framework, tell your LLM to test for them, have the infrastructure set up to see if they've adequately tested for those hazards, and maybe read the actual tests and implementation.
It is pretty easy to be able to read and understand Rust compared to debugging all the sorcery-like errors that come during Rust development... It is easy to see that you need a Loom test for certain scenarios, and to write a tool to detect if you did it.
Even if you're still working in C or Zig, it far easier to know and detect when you need to use those tools then to learn to use them all individually.
It is not hard to learn to read SQL. Almost ~50% of business professionals can. Python is barely harder. Rust can look like sorcery if you don't read a 50 page guide to understand to read it, but that's a VERY small price to pay compared to spending ~10 years learning the craft painfully by trial and error.
I'm not sure how you get from "LLMs work in mysterious ways" to "So we need more discipline" to "everything is fine."
I agree that everything is fine. I just don't think this is the clear path and thought process.
Anyone who has the determination to get things to actually work, and takes a little bit of time to understand what makes them not, should be able to leverage LLMs to work wonders.
In my opinion, LLMs are going to make things far more complicated, because the cost of building something complicated is becoming almost free.
Engineering was always about discipline and getting things to work. But you needed a set of prerequisite skills to have much value. Most of those are gone now.
It is simply far easier than before. It does require discipline, yes. But discipline is cheap compared to ~10 years of trial by fire.
> I'm not sure how you get from "LLMs work in mysterious ways" to "So we need more discipline" to "everything is fine."
Are you referring to this part:
> I am not worried, at least in the near term, about AI creating massive, discontinuous returns on investment in the absence of engineering discipline. (Many will try, and it will be entertaining to watch.)
She's saying, "the amazing thing about LLMs isn't that they generate lots of code fast, so don't worry about people using LLMs for that taking over the industry"
She's making two points:
1. Before infra-as-code, people would be afraid to touch parts of production due to lost knowledge about how and why it got that way. Now that we have infra-as-code, you aren't allowed to change infra the old way (ad-hoc changes via dashboard/CLI), even if doing so would be faster and easier. Experienced SREs were required to abandon lots of their old skills with CLIs and dashboards and start working in a completely new way, because the knowledge captured in a terraform repo's commit history is so valuable.
2. In the past, the way code got written was through people making changes in ways that are specific to their current knowledge, the org's current problems, the current users, etc, some or all of which is not written down. Eventually, everyone is afraid to change certain things because they don't know or remember all the considerations that went into them (not just afraid to touch parts of the code, but afraid to delete seemingly-unused features, or migrate the schema, or whatever).
Charity is saying that problem 2 is a hidden/lost-knowledge problem like problem 1, and the amazing thing about LLMs is you have to write down all the knowledge you want them to have, which may lead to a better solution to the "lost knowledge" problem in software development, which would be so valuable that experienced software engineers have to abandon lots of old skills and start using it.
(Not only writing down all the knowledge you want the LLM to have, since they're flaky enough to ignore instructions and miss implications sometimes, but building test suites and tools and so on that adequately guide their solution. This is the "more discipline" she's referring to.)
When starting on a new codebase, how do you make yourself into a helpful contributor as quickly as possible? I go straight for the humans and their human docs. What problem was the system originally built to solve? What was the original design, and what were its biggest problems? Who is currently using it? If you know these, reading the code is much easier because you can guess why things were done the way they are.
Also, this blog post has gotten popular: https://blog.gpkb.org/posts/just-send-me-the-prompt/
I think Charity is observing a very old problem and expecting the new technology to lead to a new solution of some kind. I doubt she thinks even the current generation of tools are the end of the AI software development story. She's not saying we'll drop design docs right into Claude code and walk away (design docs aren't complete either, that's why when you're ramping up you also have to talk to people, read old tickets and postmortems, etc.)
What she's observing is that, in prod, people don't like infra where it's hard to tell how it got into is current state, and so infra-as-code is what we do now. She's also observing that, "it's hard to tell how it got into its current state" is the status quo with codebases, which other people have observed going back to "Programming as Theory Building" and earlier. And she's expecting that, analogous to infra, software development will somehow be done with tools focused on making "how the code got into its current state" clearer.