Live data from Hacker News

The end of "Just ask Sarah"

simme.dev

21–28 of 28 posts

Re: The end of "Just ask Sarah"

#21

>None of the three can easily be captured in code, but are trivial to capture as documentation. Posts like this frustrate me. Not because of what they ask, but because of what they incorrectly assume. They assume that documentation can provide enough context, and that human knowledge is not needed. Every bit of written documentation can and will be misinterpreted. And perfect clarity is impossible. A well-written ADR…

People would often ask me why I would just read the code for a project rather than ask whoever wrote it. At the end of 30 minutes talking to someone, I may not have learned anything. Or I may have learned the wrong thing because they wrote it 3 years ago and forgot about it.

At the end of 30 minutes I either understand how the project works at a high level or know enough to know I'm not going to be improving anything with this project, ever.

Re: The end of "Just ask Sarah"

#22
> We’ve all been in that 30-minute meeting that could just as well have been a two-paragraph ADR, if anyone would have bothered writing the decision down as it happened. Organizations learned to run on oral tradition because the alternative required discipline that was hard to reward, and not documenting it properly rarely turned into a real problem - at least not immediately. With agents, on the other hand, the full cost of a missing paper trail is paid every time the session terminates.

I just think this is entirely wrong. Oral tradition is valuable because it's flexible in a way that written tradition struggles to be. Just a handful of oral-tradition decisions I routinely see that could never be written up as persistent documentation:

* The CEO said X is our top priority, but we think Y is more important and we can do it without compromising too much on X, so we're going to do both.

* Team A has a track record of quality and success, so their decisions are subject to less review and receive more deference

* Team B is sloppy and makes a lot of bad calls, so we don't trust their judgments when doing so might lead to an outage for us.

Re: The end of "Just ask Sarah"

#23
the agent still has a sarah.

the agent has the operator, and the operator has a sarah

i have spent a lot of time answering colleague's agent's questions as a sarah.

my thought has been to try to commit any of the answers to those questions into the relevant codebases so that they become findable.

same with anytime i have to give the agent extra context about some code. The end goal being that as much knowledge as possible is out of my head, and put nearby the code where its most useful

Re: The end of "Just ask Sarah"

#24
It requires surprisingly few lines of AGENTS.md to ensure before a line of code is patched, SPEC.md has the new target and a DEVLOG.md has a journal of why, then after the code tests OK, the commit carries not only the change but the motivation, and any DOCS.md is updated with new context.

It turns out wrapping the patch with these things makes the patch better. Plus, you have docs. All this goes in the PR.

Humans think docs cost/waste time. Agents not only don't care, but code better when doing SDLC (because once you get rid of the cult ceremonies, the core principles work). And so do humans.

Maybe Sarah can write it down, and maybe so can anyone that gets an answer from her, and maybe so can the LLM.

Re: The end of "Just ask Sarah"

#25

> We’ve all been in that 30-minute meeting that could just as well have been a two-paragraph ADR, if anyone would have bothered writing the decision down as it happened. Organizations learned to run on oral tradition because the alternative required discipline that was hard to reward, and not documenting it properly rarely turned into a real problem - at least not immediately. With agents, on the other hand, the full…

All three of those should be written down. The first one, write down well justified but also open to learning context you don't have, and discuss that with the CEO.

The next two don't have to name names, but absolutely can name practices and privileges. Do these things, participate this way, get bonus. Do other things, no participation, and no bonus. Be written-clear about the expectations and consequences. And then hold teams accountable.

Re: The end of "Just ask Sarah"

#26
post #11

>None of the three can easily be captured in code, but are trivial to capture as documentation. Posts like this frustrate me. Not because of what they ask, but because of what they incorrectly assume. They assume that documentation can provide enough context, and that human knowledge is not needed. Every bit of written documentation can and will be misinterpreted. And perfect clarity is impossible. A well-written ADR…

> They assume that documentation can provide enough context, and that human knowledge is not needed. It's funny actually, because I fully agree with your reasoning. The only part were we differ is whether that's assumed, or even implied. No documentation means running fully on tribal knowledge, or institutional knowledge if you prefer. Even if you capture your intent, imperfect and incomplete, in as little as 2 parag…

I can’t tell from the text if the first paragraph of your response is meant to be ironic or tongue-in-cheek, but it certainly works that way.

It feels hard to recognize that you agree with me from the following paragraph of your post > This is similar to asking Sarah why the team went for A over B, but without the imperfections of human memory, and available to agents as well. When an agent reads it, the decision isn’t an arbitrary historical fact - it’s the conclusion of an argument the agent can now evaluate and extend.

I definitely agree that human knowledge is imperfect, and that documentation is needed. But I just cannot get around the fact that the following sentence, out of context, can refer to football, American football, and basketball : ‘I passed to the center, and we scored’ and without more context, each of those can have multiple meanings even in each of the sports I named.

const hello = ‘world’

Is valid in so many programming languages that need more context.

No, the agents don’t ask Sarah, but maybe they should. And maybe I’m on this soap box because the thing is that I write internal line of business software and the technical stuff is easy. But when Sarah is the inside sales manager or the industrial engineer a continent away who speaks a different language, the reality of adequately capturing context for decisions that others have made that our software has to implement, and in a context rich enough for documentation to be succinct, is enough to make me frustrated with articles like yours that hand-wave that into ‘trivial to capture in documentation.’

Re: The end of "Just ask Sarah"

#27

>None of the three can easily be captured in code, but are trivial to capture as documentation. Posts like this frustrate me. Not because of what they ask, but because of what they incorrectly assume. They assume that documentation can provide enough context, and that human knowledge is not needed. Every bit of written documentation can and will be misinterpreted. And perfect clarity is impossible. A well-written ADR…

>Every bit of written documentation can and will be misinterpreted. Yes, humans (and human languages) are flawed and lossy. >A well-written ADR does not eliminate all ambiguity, True: no docs can ever eliminate all ambiguity (on a decent sized project at least). But this entire argument seems to be "letting perfect be the enemy of the good". Documentation doesn't have to be perfect or 100% unambiguous to be useful .

I agree. But that usefulness can be deceptive, especially when one thinks enough context has been captured to prevent misunderstandings. An LLM (or human, to be clear) can easily go down the wrong path from their own assumptions, and now you have three problems.

My main complaint is that articles like this lead people to think they they can avoid those three problems, without understanding why there are three.

Re: The end of "Just ask Sarah"

#28

It requires surprisingly few lines of AGENTS.md to ensure before a line of code is patched, SPEC.md has the new target and a DEVLOG.md has a journal of why, then after the code tests OK, the commit carries not only the change but the motivation, and any DOCS.md is updated with new context. It turns out wrapping the patch with these things makes the patch better . Plus, you have docs. All this goes in the PR. Humans t…

This - oh, so much this!
Post reply on HN