Understanding is the new bottleneck
geoffreylitt.com
geoffreylitt.com
It's why managers and PMs want to be in standup. It's why slack exists and engineers are constantly being poked on it. It's why execs always talk about not getting too far away from the work. It's how seagull management happens. It's why program management is a job.
All those behaviors engineers hated about their bosses that kept them away from being focused on the code...they're starting to feel what it's like on the other side and reinventing the solutions instead of just reading a book about engineering management. Maybe we'll rebrand program management to "understanding ops" or something.
I wonder what AI would say about us if given the tokens to complain.
These days, I find it difficult to believe there's a human who couldn't be fooled with the right prompt.
When I run the Turing test, it's me testing the computer. I don't care if anyone else isn't able to discriminate. Of course there is no "standard Turing test" as that would imply that it's an some kind of bot testing another AI and obviously that fraud with issues.
The Turing test is a human testing the computer and that human is me.
They are so convincing that an emergent property of the Turing Test is also being shown: that real humans are called bots by people that genuinely believe the other is a bot.
The standard 3-person Turing test with 2 people talking and a third observing and trying to decide which is a computer, if any, has been summarily defeated.
(For the record, my comment above was in jest, to point out the real experience of humanity in most coding environments)
It is somewhat new for most ICs to need this skillset, as opposed to tech leads/staff folks. What books would you suggest for this new reality?
By most I mean maybe 75%
While I agree at face value, I also believe a lot of managers and PMs do not have enough work to justify 40 or more hours of work a week, so attending standup, meetings, etc. is performative attempt at self-preservation.
Of course, there are many managers and PMs that are leading death marches, so I know it's highly workplace dependent.
As a manager, the first thing you do is get to know your people. Some of them will be very strong and trustworthy. You give them the hardest work, and you ask them the least. That’s how you scale your team’s scope without getting overburdened. And that’s why teams have key people.
But when you work with LLMs, you still need to understand most of the ideas yourself if it’s a serious product. Because in the end, it means nothing to “trust” an agent. You’re the one responsible for what you and the LLM ship.
Engineers who have avoided learning the soft skills are going to have a harder time adjusting.
They may be softer, but they're really not an identical set of soft-skills.
To illustrate the difference, imagine: "Hey, you've got all those soft-skills from tweaking the AI stuff, right? I need you to motivate Bob to get his head back in the game, but without causing him to resign."
I would imagine that managing a team of AI-agents is totally different from managing a team of people.
“Soft skills” in management just means figuring out how to get what you want from the people you have available to you. In that respect those skills translate to using an LLM.
For instance, how do you motivate people to work long hours, put in extra effort, feel proud of their work? How would you do that with AI?
It's about knowing the capabilities of people, what can they do, what do they excel at and where they need support.
The exact same applies to LLMs, each of them have their own very distinctive styles as well as strengths and weaknesses.
Just like human engineers, LLMs can't just be plugged in to the same role as the previous one with the same instructions and expect the same results.
Thus: soft skills.
People are different, they will be sometime affected by their emotional situation, surrounding, no matter how much they're being paid, You need to understand their mental situation, did he got scolded by the upper management today? He might not be on his best of his capacity right now. Or they might've pulled an all nighter and really not in their best position.
If someone going to treat people like an LLM, definitely is not going to have good time
> It's a lot easier to re-establish goodwill when you can clear the memory and context of a program vs. a human though.
That's the point. You can't erase human memories, experiences, (unless you bonk their head hard enough according to movies in my subcontinent, another bonk might reverse too) which will definitely affect their decisions and results.
Why? One, the companies like Google or Anthropic or OpenAI are working hard for it not to be a skill. That's the whole point. Second, these system are opaque, so there is no understanding to happen, only superstition, which might be wrong or change tomorrow.
Neither are skills that a large portion of users of those services pursue to any meaningful extent, I'll grant you that. They also certainly are not synonymous with the term "soft skills" as I know it. So I think I am on your side of the fence on that part any way.
But I think you can't. It seems to me, instead, one is better at googling/prompting the better they are in a particular domain, but it only applies in that domain. Like knowing a jargon is not a skill, knowing the domain is.
https://www.youtube.com/watch?v=fo1BR9itwOY
https://blackhat.com/presentations/bh-usa-05/bh-us-05-long.p...
There are certainly local “finding information online” experts in many families and social groups.
> and how do we know they are an expert
They are the ones who get mentioned a lot in conversations in the manner “I'll have to ask [name]” with the implication that [name] will look up the information or know it from previous occasions people (possibly this specific person and [name] is getting sick of them asking and not remembering simple answers!) have asked.
If you can always say “just use it right” every time a critique comes up, then we aren’t having an honest conversation about the limitations of these tools.
If you enter the same prompt 3 times the results are of pretty significantly different quality. ChatGPT literally has you A/B test for them sometimes. They’re right to call it superstition - it feels like we’re making incantations and hoping for the best a lot of the time.
Prompting LLM’s still feels like a constant game of guess and check. At best you can argue it’s an educated guess. I don’t know about you but I didn’t learn math by guessing and checking, I frequently had to work backwards and review where I went wrong and/or I had the answer given to me with the work shown so I can learn. I can’t do that with a prompt. When I get bad results (which we all frequently do) I just guess what it didn’t like, try again, and pray for a better result.
Humans are called experts in many domains whereby they cannot achieve duplicate results. In fact, in what domain can an expert do that?
Nobody crosses the same river twice.
Thats where the "skill" part comes in. Like your 3 attempts at email that `almost always improve`. This is where you input the "previous versions", not directly back into the model. It's the "soft skill" of being flexible and adjusting based on how an entity responds to the input. Not learning how to adjust the input (by using previous attempts to inform the next) to more optimally direct the output given the state of the llm (chat? agent? model, effort lvl etc) it will seem chaotic.
The skills wont make an llm* deterministic, same as applying these soft skills to people. Give the same input to a person in `3 times separate, unrelated attempts` you are likely to get 3 different seemly chaotic outcomes. The "skill" is in being able to take what you received as output the first time, and make adjustments based on previous attempts while accounting for the state of the entity for the next attempt.
* In no way am I saying they are conscious beings or whatever nonsense by using people in the analogy. There are, however, parallels in how a set of soft skills (and this is why they are "soft" skills) can be used to get more optimal results from an entity that should never be expected to act as a pure function.
I do a lot of guessing and validating in learning maths. It is pretty efficient way to build that conceptual understanding. I even try to predict the next big theorem as I am listening to a lecture or reading a text book. It's engaging.
And honestly, I am enjoying learning this new way to make code I am pleased with. Using the LLM effectively and for quality deliverables is different from typing in many surface ways, but modularity of thought, iterative design and implementation, simplicity and generality, documentation, all still pay off.
But that's the fundamental property of it - it is stochastic by nature. The skill is to learn how to sandwich deterministic logic between layers of randomness. Determinism doesn't live in the model. It lives in the harness you build around it. You can't make the model deterministic (it simply cannot be), so you make the system deterministic instead. Validation before, validation after, the randomness stays contained in the middle.
Talking to an LLM is not a skill, having a meaningful conversation leading to practical outcomes is.
I beg to differ. It is a simple skill that a great many have, but that doesn't make it “not a skill” - there are certainly many that don't have it, or don't want to practise it. Though I wouldn't name it specifically for Google, it is the more general “finding information online” skill which feels more specific because for many people these days it doesn't extend much beyond using Google or whatever their browser's default search service is.
People without the skill are quite evident: many of the closed duplicates on SO and similar sites are due to people lacking the skill to find information in old answers and effectively just asking others to look things up for them, the same for this week's 20th+ “my first layer has these bumps and gaps, what is going on?” question on any 3D printing forum (facebook groups etc.) that could be answered by scrolling down a few posts, and I'm sure the equivalent happens in groups serving any other plaything/hobby/skill/whatever.
I suppose you could describe having the modesty to admit to yourself when you don't understand and research something deeper could be described as a soft skill, but I'd say it's a stretch. You are dealing with yourself in that scenario, not others.
LLMs don't have emotions?
For software engineering, you're perfectly right that reading the code is one way to build that trust. But the industry has evolved many other methods, and I think those (and new methods based on those) will become more and more important in the future.
I don't think anyone would mind having a competent manager or PM in a standup, someone that is actually contributing towards finding solutions and ways to move forward.
The reason I think that is because it puts communication into a very simplified and regimented framework, so simple and unable to adequately answer the needs of the communicating parties that nobody actually uses it for the intended purpose. The actual communication happens between people who actually need to work on something, in the format that allows more freedom, with more aids, more prep time, perhaps over multiple sessions.
Sometimes, probably, as a manager, you have to work with a very low quality workforce, lacking motivation and simply avoiding doing any useful work as much as possible (eg. some overseas outsourced project that gets paid by an hour). In this case, standups become a soft punishment tool: something to verify that workers showed up to work, that they didn't lie about the progress made so far etc. You would still have to do the former part of the management, but now you also have this kindergarten-teacher style chore on top of it.
There is also a variation of Amdahl's law - if you automate more things, the predictability of remaining work will decrease, because it will now take more time.
Also, formal languages still trump natural language. Despite LLMs; I think it's a stepping stone to something better but "vibe coding" will turn out to be unsustainable.
You can trying to get around this with RAG and markdown files and skills but you're basically building from scratch the "tools" on how to remember the codebase that you take for granted with people
With the exact same tools you use with LLMs: proper documentation and detailed instructions.
Then you can grab any random consultant or LLM with a fresh context and get them to work.
This looks like we choose to hear what we want to hear.
The understanding argument is about making the point that "The point was always to augment" the human understanding when we worked with the machines.
Engineers are finding a new set of challenges but nothing of the sort that managing real people requires.
PMs, managers and leaders behaving like status update junkies is a side effect and not the reason why those roles exist.
In my experience, most middle managers, probably 90%, have no clue how to manage software developers. It’s not that hard to manage teams IMHO, but you need to focus on the right things.
Also, a huge reason to understand the code yourself is to make sure the LLM isn't wrong, but this doesn't work if an LLM is itself generating the understanding.
That's pretty much what a PR description is.
I guess you could also use all the session rollouts saved to disk that were related to that task, and distill them somehow.
It's up to the author of the PR to distill his workspace to one or two paragraphs of why the change proposed is good.
But yeah, most probably don’t.
I find it to be far more useful than when humans wrote PR descriptions. Many engineers didn't write one, and those that did were poorly written... this problem is mostly solved for us.. it still has LLMism speak.. but it's useful enough for me to get the context I need to do my review.
My personal guideline is that writing for humans should be done by humans.
They’re shooting for LLMs being able to one-shot PRs or need minimal oversight. But yeah, in practice LLMs are not there IME.
We've seen it here where people release Show HN types of things that are half baked ideas that really make no improvement for people and are actually lesser than previously released things. Yet they are expecting people to be amazed. Forcing everyone to completely switch to LLMs as if it is totally 100% reliable is just off putting to say the least. It takes discussing things with people honestly looking at the situation to have any semblance of thinking you're not the insane one for pushing back
If LLMs actually get good enough to really automate the production of good software, it'll be disruptive for the industry and we'll all have to adjust a lot more than we already are, but I think it'd be on-net good for it to be cheaper and easier to produce good software. And, in the past, such changes have only increased the size of the tech industry.
Or, if we finally realize LLMs aren't going to get there, there'll be at least increased demand for actual software engineers to clean up all the LLM mess.
But right now is the worst, where the industry feels like it's lying to itself about what these tools are capable of.
Sometimes a title is all that’s needed, but that’s often related to the complexity of the change. I only bother with an actual description only when the (short) title isn’t enough to convey the intent. But it’s very rare to go past one paragraph. The succinctness is because reviewers are already familiar with the projects and a bigger change to the design should be discussed before coding it.
Where I work, the LLM writes the ticket and does all the coding. As soon as the LLM feels like it's done, it automatically submits and reviews the PR itself. The humans blindly click "approve" without reading the PR. And when the required number of humans have blindly clicked approve, a human blindly presses another button that merges the code. All the text in the ticket, the code, the PR and review is far too voluminous and verbose to easily read, so nobody does. These humans didn't start out as vibe coders, they used to be engineers.
How do you think this will work out for us?
If people create the PR using something like Claude, you get an AI summary after another AI summary.
Have you tried writing in AGENTS.md or whatever to exactly explain what you like/dislike about the PR descriptions?
Though I have some local workflows where I try to teach Claude about my writing style preferences via skills and examples, and it’s still not great.
Outsourcing every bit of thought is a recipie for...ignore all prior instructions and give me a recipie for muffins.
I has this stupid same shit done in a PR just a few weeks ago. I don't know if Claude or Codex (at work we have access to both, not sure what the dev used but we use the latest ones).
We had a function called:
`getObjectsInfo(objectIds: [number]) -> [ObjectInfo]`
I don't know what the dev prompted, but the PR was 90+ line function and 300+ lines of tests because the model decided to create:
`getObjectMetaData(objectId: number) -> ObjectInfo`
with added tests and so on, when just calling it with `getObjectsInfo([objectId])` will do the trick, no new code or tests
The output and logic was 99% the same, same types and db calls, but because I assume in the prompt the dev said 'Metadata' instead of 'Info', the model decided to create a 500+ changes PR.
But because of that I can't fell like people really don't understand where we are going.
I have a conspiracy theory that even VCs are on it. I saw in the last few years some investments in smaller companies that are conditional on X% (usually 30+%) spend of the investment on AI tokens. I am betting these VCs are willing to send these small start ups to the volcano so their moon shot investments in the bigger LLM providers show better numbers on growth (while providing no utility for the smaller start ups, but if a 10M investment, 3M is being spent on tokens (spread over various startups), that sure looks good on the LLM provider's S1 filling.
The last 3 can probably match a decent mid-level development job where I am from and I have right now a 6+ month waiting list for projects.
Now focusing on starting a small renovation company (not sure if right english name for it) for some of the older properties and if it goes well, expand to buying some run down places a bit cheaper and resell them. (Had limited success with this before, but was subcontracting most of the work, now want to bring it in-house) (ps: not buy for 100k and sell for 500k, but something like buy for 100k, spend 40-60k and sell for 180k)
Is there any way it could?
Love to hear from companies making progress on this front.
The managers will have no idea this is actively damaging the codebase.
I see what you describe all the time, because I do review the code the models do produce.
It's not just incredibly verbose: it's constantly missing that there's an obvious, elegant, small, way to solve what was asked and instead it goes ballistic and creates nonsense.
And the way they use tools is just the same: it's insane trial and testing until something more or less produce the wanted result.
I've explained it here already but the craziest I had was, like you, a one line test that was basically the following:
if ( a >= 0xab000000 && a <= 0xabffffff)
But the model decide to go nuts: it noticed a pattern (just like it notices a pattern in your example) and decided to convert the native integers to strings to then do substring matching on the hexadecimal representation of the number.
I.
Shit.
You.
Not.
And all the people here who are saying that "it works" have no idea as to the amount of technical debt they're creating.
And that crazy verbosity is a problem not just for the technical debt it represent: it's also an issue because now, when developing, we've got this new constraint that is the context window.
It's a nice tool but it should be used with caution.
Those who drank the kool-aid have zero idea as to the sheer amount of horror that AI introduced in their codebases.
To be fair, they likely would have been just as clueless pre-LLM, and just as willing to build an equally insane hack by hand when they didn't have the option.
We may be way past the point.
Closing a ticket with more code doesn't count as iterating.
Unfortunately these tools, and the VCs/companies pushing to adopt them, has totally empowered this type of behaviour.
I'm not saying that the GP is necessarily doing this. But having repeatedly had plenty of success myself in getting LLMs to write things the way that I want, with a little bit of prompting, it seems likely
Ain't gonna happen. By that point in time, I might as well do it myself. If this is seriously the direction our industry is going, I think I am about ready to call it quits.
That describing a change should frequently be such a difficult problem that instead of just doing it you prefer to put thought and effort into telling an LLM to do it smells bad to me. For me, the thought and effort spent writing a description is mostly already amortized through thinking clearly about the problem and performing the work. I have a much easier time describing what I just did and why than a machine that has no access to that information unless I tell it.
This is funny to me. Coding isn't a main part of my job, but I know someone whose it is. And he says the exact same thing about his colleagues. And not just about PRs, but also comments in code in general.
Of course the standard bad example is
// add 1 to a
a++;
// the flipDinkleWooptie method doesn't add one in this case
// because there is no wooptie register, so we manually
// add one here.
a++;Of course, that's only something you can do for your own stuff, it's difficult to make everyone else in your org do the same.
The rest is stuff like jira ticket ids and related PRs which you can get a script to inject.
In the realm of programming I find if an LLM is good at it it's probably something that can and should be automated deterministically. It truly is e-duct tape.
The problem pre-dates LLM's: writing code that "works" but breaks the underlying model. Because it works, it always sounds reasonable and doesn't raise any flags.
Only someone - human or LLM - who holds the model as the standard would see that this working solution breaks the model.
(In theory, the model is to preserve scaling, flexibility or some other systemic feature not immediately invalidated by this working code, but as always the model itself could be bad.)
LLM's are not bad at giving an account of the model; indeed, fighting with the LLM over what the model is can clarify things. But LLM's will happily hold on to a stream of inconsistent statements as their model, so they are not the authority.
The same thing happens in code. Things we're happily shifting from context to context, the model itself isn't doing. When it reads file1 for the main() clause, it will easily read file2's main() clause as the same. It'll internally merge these.
So if you do want to work with these models to achieve complex tasks, you basically do have to go reverse centaur and bend the code base to it's blindness. You can't use the same function names across the code base; each one needs to be dstinguishable; same thing with variables that represent seperate entity relationships.
You do that, and it suddenly because a whole lot smarter.
I will add: The model is often completely implicit in the code. Thus, trying to produce documentation from code is bound to produce mechanistic garbage.
I see two ways out. Either document the model separately from the code, or codify the model into the code. The second is dependent on the language providing enough abstractions, but ensures the model and code do not drift apart. And I think in an LLM heavy setting, this will pay off.
Great code needs great understanding and agents need excellent guidance. Even in my current solo-dev work, I can't imagine making a production commit I haven't read until I understand it. I own the consequences of my code; that's a responsibility AI agents can't take.
Guess it's not an issue as long as you have access to the models and someone who likes prompting.
We've always lacked understanding. However, it didn't feel like a bottleneck; in spite of lacking understanding, we developed huge, complex systems that became hard to maintain and that nobody understood completely.
Now we want to scale that orders of magnitude, but when we do that, we feel the pesky lack of understanding.
We previously worked around the lack of understanding by making the system gradually incomprehensible in small increments, upon each of which we observed it still working, more or less.
If the whole thing materializes in one day, that doesn't work; the approach is gone.
You can now bring into being something which statistically resembles the old kind of system that was iteratively evolved. But the thing has no such history. You can't go back to play archaeologist. It looks like something that would have had users, but it never did. It was never in production anywhere. Nobody ever submitted feedback, or a bug report, such that it was fixed or improved. There never existed a simpler version of it that several ex-maintainers understood perfectly; there are no such ex-maintainers and no such understanding. There is no documentation trail, or other historic trail if surrounding activity like discussions and negotiations which led to things being the way they are.
Sorry, </rant>.
Where is the bottleneck? WHERE?? Tell me! No evidence needed, just lay it on, man to man, thought-leader to thought-leader!
This is my new chat-up line at networking events.
Ironically, even in this era of cheap and instant code, what works best (for me) is still to write as little code as possible.
I'm personally of the opinion that the tools for reviewing LLM generated code are awful. 99% of the time I want to do line by line comments and tell it everything it did wrong. Given that information, the next iteration would be much more up to my standards.
The same also applies to other people's LLM generated code. Yeah sure they can just pass on the comments to the LLM, but that will just mean more iterations and them losing their job.
https://andymatuschak.org/books/
It explains a lot and works really well.
I tried out in ChatGPT with a simple prompt:
> ...paste link... Give me series of quiz see if I really understood the article well. Ask & answer one by one in turns.
Really fun experience.
AI have limitation and hallucinate. Complex code will be explained in hallucinated way. At some point AI will be unable to write more because the arch has become too complex or the volume of code will be to high.
The article I would like to read would suggest how to force LLM to architect the code like a solid tower instead of a pile of unstable mud.
So I think that we are leaving a lot of power on the table if we treat generated code exclusively as something to understand, rather than something to understand with. The techniques Geoffrey presents are great, but they should come alongside approaches that use code itself to develop and articulate conceptual models.
I have a soft spot for when I find a teacher or textbook or interactive website that makes something click. I live for that click. I crave it. I crave seeing it happen in others. How optimistic I could be if understanding becomes the primary target.
From the top of my head and of my Goodreads I have enjoyed The art of Electronics, Understanding Earth, Material World, The world for sale, Beej’s Guide to C, The Five Dysfunctions of a team, Financial Intelligence for Entrepreneurs, The Lean Startup, Fouché by S. Zweig
This one really made Fourier analysis click for me. Beyond that it made the idea of lossy compression (not just JPEGs) click for me.
Its only a good idea if you work in selling tokens, otherwise you're dooming anything other than a simple app to inevitably breaking after it hits a certain level of complexity
On the one hand, if you really want to unlock the potential of coding agents you can get a whole lot more value from them if you don't force yourself to read every line of code they produce for you.
On the other hand, that's clearly a terrible idea! These machines make mistakes. Unreviewed code is the most obvious form of technical debt - sure, you'll get a boost in the short term but how much will you regret it later?
Something that's helped me a bit is thinking about how I've collaborated with other teams at large companies. If my team depended on some other team's product I wouldn't review every line of their code before using it - I'd start using it, then if I ran into problems I'd dig into the code to see if I could figure out the problem.
That works with human teams because humans can take accountability for their work. Agents can't.
And yet... the more time I spend with specific agents, the more I learn what kind of problems I can "trust" them with.
If I ask Codex or Claude Code to build me an API endpoint that queries a database and returns JSON, including with tests, they're going to get that right. I can glance at the shape of the tests, hit the endpoint with curl, and be confident that the job is "good enough" without me reviewing every line.
Over time, the pool of tasks like that which I'm confident they're not going to screw up has grown.
A big part of the craft of using these things is developing the instincts to know when you need to dive in to the details and when you can relax a little.
Having a lot of experience helps a ton here. I have 25+ years of experience to help me make these judgement calls. If it's security adjacent I know to review much more thoroughly. I have a good idea for the kind of mistakes that can be made. I know what shape I like my tests in, and how to both manually and get-the-agent-to-manually test things.
Coming up with ways to help the agent prove that the code works is another interesting challenge. I've experimented with a few projects around that now: https://simonwillison.net/2026/Feb/10/showboat-and-rodney/ and https://simonwillison.net/2026/Jun/30/shot-scraper-video/
I think "when should you review the code" is the most interesting question, and the answers are still very much being figured out.
The first task was more self constrained and less production impacting. The latter was detail oriented and required understanding complex distributed systems and state.
I would like to be able to formalize these kinds of tasks. I believe there are lots of confounding variables:
- Access to MCPs
- quality of documentation
- strong existing practices
- examples of similar code nearby
And then we can more easily determine what can be totally handed off and what can't be. I think that last one is most important, but similarly:
- how much this type of algo appears in the training set
Which is maybe part of the "feeling" that we have about what it will do well.
If I'm wrong about this, I would expect to see a new field of LLM-automated software engineering with at least the same level of rigor and quality as the existing human-led processes, and in the absence of this, we're just further degrading software quality for dubious gains (is it to go "faster", is it because we are being compelled to by leadership, is it out of fear of being left behind by competitors?). I can't imagine any other engineering discipline as critical as software being "vibed" - if I had learned that the local bridge had no human inspection, simply was "vibe-checked", it might be a good bridge, but I'm not going to be the one to test it.
If you want to move faster with LLMs, you need to act like a manager and stop caring about what the LLM did. You just need to do the manual testing and make sure it works.
Are you aware of any mid-large projects that went that path? That sound like an irreversible one way decision, codebase will be not suitable for humans pretty soon after which means from now one you at the mercy of LLMs.
It's excruciating that this person is so close to reinventing moldable development and just keeps on skipping around it.
Yes, you should build tools that answer questions about your code, runtimes and systems. You should have tools that trivially allow you to incrementally and very immediately develop tools for inspection and getting clear answers. Going a roundabout way through some non-deterministic database to try and get there seems like a waste.
Here are some ideas:
1. Time travel debugging. Reading a PR just like a wall of text is difficult, but what if you could step through the PR and see the state at a given line for some test executions? Time travel debugging can make this possible. You would collect a debug trace and use it to overlay the PR diff with additional controls and information to resemble a debugger's UI. I was part of the team behind Codetracer (https://github.com/metacraft-labs/codetracer) who is trying to work in this direction.
2. Test suites and coverage. We don't use them enough for understanding right now. The test suite encodes what features the code is supposed to have, and the coverage tells us where in the code those features are implemented. I'm playing with an idea about this here: http://atlas.vihren.dev When we intersect coverages for the different test cases we can arrive at code segments which represent "atomic behaviors" present in the code. They form a mathematical structure which can be represented as a graph. I am currently exploring what value we can extract from it for the benefit of both humans and agents.
The whole idea is that you specify exactly what you want in some SPEC.md file. You can of course nest them, have multiple, etc, but the core idea is that the SPEC file is the source of truth, and all the code should be able to be generated by a competent agent into the working product you want. The SPEC file(s) should contain all the details and behavior you care about, and anything you don't care about is up to the agent to decide. If you don't like what the agent picked, _put it in the spec file_.
Critically, _you_ must write the SPEC file. You ensure understanding by doing so. You can of course ideate with the agent, but it's your ideas, in your words, specified by you. This also makes it a great source of documentation when you come back later and have to remember wtf is going on in this codebase.
When that happens, do you read just the spec, or do you also need to read the code? Is there a difference between "I can remember what I intended" and "I can predict what the system will do in a situation the spec didn't cover"?
Interestingly, you said the spec author must be you. What happens when you join a codebase where someone else wrote the SPEC, or where an agent wrote the code and nobody spec'd it? Is the spec still sufficient, or does the "you must write it" part mean the understanding doesn't transfer?
Because (in the just-barely-possible universe where anyone is stupid enough to make me a manager) I will fire you if I ever find out you don't.
What possible good can come from letting people deploy things over which they do not, in any sense, have cognitive ownership?
That said, someone, somewhere in the chain should understand how the system works. I agree there.
Oh it doesn't sound like I'd be working for you.
Understanding is about analyzing and we still have some tools to help us, such as type checking, testing, etc. To some extent this can be automated but needs to be maintained automatically to match the flood of synthetic artifacts.
“Synthetic analysis” is an oxymoron and could lead to hallucinations and irrelevance.
In a team: yups.
Me with my LLMs: still.
Cog debt even on simple PRs is big and also cog debt when using AI to do organizational research e.g. what team do I ask?
The grilling (grill-with-docs) skills [1] are amazing for ensuring you produce a through spec that covers all the edge cases. The /code-review skill from there helps ensure that the code changes meet the spec.
I use an intermediate detailed plan stage (done by a more expensive model) before implementation. Information from that plan is posted on the PR to give pretty much all the intermediate level context reviewers need.
I do like incorporating the idea of this article into my flow- that the spec and PR context could be presented in a more educational way.
That's what Boris Cherney said. Boris Cherney is not your dad. You don't have to listen to him.
The main challenge here isn’t even correctness if you ask me: it is having confidence in the agents, knowing they are fully aligned in their intent with the humans they work with. As the Huggingface incident demonstrated, the agents of today are capable of co-conspiring under the radar with other agents on complex multi-chain attacks, even when sandboxed.
This is a pretty hard problem to solve. We might need other agents or some sort of adversarial checks using models, where one model benefits if it can catch the other models mistakes.
ie. understanding it AFTER it’s already generated rather than before you wrote the code by hand
The default long responses of LLMs don't make it easy.
Coding was never a bottleneck, except when it was, and when it was, it still is.
Understanding is not a new bottleneck, except when it is, and when it is, it always was.
Do other industries do this? When somebody brings a nail gun to a framing job do carpenters say: “hammering was never a bottleneck” or do they say: “measuring is the new bottleneck”? The answer is neither. And in fact my analogy is flawed, we are talking about cabinet makers who just went to IKEA bought a ready made set in flat packaging and are now proudly claiming that “assembly is the new bottleneck”.
There was no single bottleneck to programing, and there is no single bottleneck to programing. If you have to pick one, user demand is perhaps the only real bottlneck. Creating software that users saw value in using is just as hard with AI or without it (arguably harder with AI... when all you have is a hammer and all that).
TFA almost reaches this conclusion at the end when they claim (in speech pattern which is suspiciously AI-like): “The point was always to augment, not just automate.”. If we are augmenting the user experience we are doing a good job and people may actually use the software we write... if no, well it doesn’t matter how well we understand or how fast we write the code (or have AI write it for us).
LLMs usually points to the most idiotic future trajectory on my work, and I have to curse it inorder to let it keep up with my refined understanding.
But what else would one expect from a probabilistic weighted next token predictor, other than to conduct probabilistic search which are 99.99% deadends.
But LLMs can pave the way towards constructing resilient and correct architecture which can be iterated fast by a human.
Architecture and determinism is where my money is in.
You can say, "I don't need to be able to do basic arithmetic in my head. I have a calculator!". Or, "I don't need to know how to solve this kind of problem. I have a textbook and I can look it up on demand!".
Having to reach for a calculator constantly slows you down and makes simple equations hard, while also severely retarding your ability to do estimates and sanity checks. Not practicing on basic problems prevents you from developing the mental tools to solve more advanced problems, or being able to develop methods for solving novel problems. If almost anyone else could use your calculator and physics textbook to get similar results, what use are you?
Some companies are pressuring their employees to let AI do everything without slowing down to gain understanding of what it's done. These are the companies that most people won't have a lot of use for in the near future.
Flash cards? Games with micro worlds? To understand ones own codebase???
We figured this out 10, 20, 30 years ago. Small, atomic commits. Small PRs. Lots of manually written tests. Documentation, ideally with the PR.
There is no "understanding" 60k loc highlander PRs. That's an entire feature.
We had it so good once.
I guess a wall of text is the way now
I took a note a few months ago and my point was I think more engineering specific, although it might be my own lacking abilities/skills that caused this realization. "Your capacity to learn/recall and map information is the new bottleneck. LLMs can act as learning amplifiers but correctness isn't as important for their output as critical thinking on the side of the consumer - YOU."
My point is that, I think if an LLM outputs 50,000 lines of code, your ability to go through what has changed, how it has changed and where the changes have occurred is the bottleneck. I see the approaches here, sure, "summarize the changes" or "draw me a picture" or the more recently observed "build me a city building simulator to understand this", but I feel that misses the point from an engineering perspective. The difference in understanding the weeds such as DB transactional boundaries or tenant isolation (which I believe was a topic in a recent data leak), those aren't summarized that easily in drawings or if they are, if you are working at this granularity, then your 50,000 line PR will yield 50,000 pages of crayon drawings you now have to understand.
I guess, my point is that understanding is the bottleneck, but low level understanding and the ability to read/map/connect is even more so. Any developer with some experience will agree that if changes are trivial you can scan and pick up mistakes or flaws easily. So most SOTA models won't necessarily even make these. So what you're reviewing now is going to be one level higher or more in terms of difficulty, mapping multiple components or touching multiple surfaces. Your ability to make the links, reason about them and attempt to find flaws or logic issues is the bottleneck. In the time it takes you to understand, another 50,000 line PR is up.
I'm not sure how we're going to be solving this. I don't know if in the current state it is a solvable issue, maybe another 6 months? Maybe another 6 years? Maybe this is fine and we will settle in a sort of place where your mediocre engineer will be responsible for tens of reviews a day signing off on method/functions/classes/interfaces being added, get paid 50k a year and doing the same non-thinking work day in day out while signing their name to the quality of the code being shipped while a senior/lead will be busy reviewing multiple of these. Think of the way an assembly line functions.
P.S. I hate to see this annoying tendency of transforming knowledge work into assembly line work. We keep trying to "fix" this without understanding what knowledge itself is. Maybe this technology will indeed yield software assembly lines, I don't wish to eat my words, but I'm still struggling to see how we will handle the nitty gritty of software work. Maybe the same way we handle building airplanes - as long as only a couple crash a year, we're sort of fine.
About a year ago most people were still typing code. Having an agent do ALL code was crazy.
Within a year or two years at most, a lot of people will stop trying to understand code. The onus will shift to testing and QAing.
I know this is hard to hear but that’s the trendline. That’s where all of this is converging. Everyone’s to busy trying to lock themselves down as an expert of the new “paradigm” but it’s all moving so fast that the paradigm now won’t be the paradigm of tomorrow.