[dead]
Understanding is the new bottleneck
191–200 of 259 posts
Re: Understanding is the new bottleneck
#192> Why? Why understand?
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?
Re: Understanding is the new bottleneck
#193We have LLMs try to generate descriptions of PRs for us and they're pretty universally disliked. They're always overly-complex descriptions of the mechanical changes and have no sense of motivation. 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.
It gets better if you tell it what you expect, but maybe even better is to keep some examples of "this is a good PR description" and feed it into the LLM generating another.
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.
Re: Understanding is the new bottleneck
#194Improving code understanding is the main focus of my work and thinking right now. If we want to make advances I believe that we should rely more heavily on one key quality of the program code: It is meant to be executed.
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.
Re: Understanding is the new bottleneck
#195Understanding has always been the bottleneck, everywhere for everything. And now, with this new realization, are you going to finally realize that Communications and your skills with it are basically everything?
Re: Understanding is the new bottleneck
#196Earlier quoted context omitted.
Talking to an LLM is not a skill, just like using Google is not a skill. 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.
I disagree, both of those are skills. 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.
I feel like if they were skills under a reasonable definition, you should be able to name an expert in these skills, and how do we know they are an expert.
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.
Re: Understanding is the new bottleneck
#197If you start with a spec you understand at the beginning then you don't need the LLM to generate high-level information about the changes at review time.
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.
Re: Understanding is the new bottleneck
#198We have LLMs try to generate descriptions of PRs for us and they're pretty universally disliked. They're always overly-complex descriptions of the mechanical changes and have no sense of motivation. 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.
90% of what I want to see in a PR is "why" and an LLM is entirely incapable of knowing that.
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.
Re: Understanding is the new bottleneck
#199Earlier quoted context omitted.
Talking to an LLM is not a skill, just like using Google is not a skill. 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.
I disagree, both of those are skills. 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.
It is impossible to duplicate results with an LLM. This strikes me as a serious barrier to calling it a proper skill. If you can’t even somewhat replicate the results you can’t really improve the input consistently. You can’t become “skilled” at it if you can’t even reproduce what you did.
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.
Re: Understanding is the new bottleneck
#200Earlier quoted context omitted.
A PR with a minimal title and empty description should be refused at submission. If the human is so disinterested that they're using LLM generated code and then can't explain the purpose, that human should be prevent from making the PR. Working as a solo dev, it is very easy to be lazy like that, and I'm as guilty as anyone. Working in teams with actual reviews should absolutely have much more strict policies of what…
Even before AI this was common.
I'd rather have an empty description than a giant wall of LLM-generated text that says nothing useful and that the submitter probably didn't even read.