I'll keep on iterating on the website.

However, I read your principles: https://diegoux.com/blog/ai-slop-manifesto/

And I follow them all. The use of AI is disclosed — a complementary part of my framework is how I work with individual sessions that are named. I can explain everything that is mentioned; I've dogfooded this methodology for the past year, after several decades as a professional programmer, because I was concerned it was interesting enough. But it has made me produce better quality software, more of it, more interconnected, better planned, and focusing more on architectural complexity (which is what I've come to understand as the more general concept behind software modularity, etc.). From the many traces of conversations that spans hundreds of thousands of words that I've written or dictated, you can see that I've used this to think more, not to replace my thinking.

Furthermore, part of this entire framework is based on the "agentability" of using git as a storage for almost everything, in particular, for discussions that happen usually elsewhere: https://diegoux.com/blog/agentibility/

One of the demo projects (of which you can see the full deliberation records) is called "moreover", it's a pager for LLMs:

https://github.com/jlumbroso/moreover

https://github.com/jlumbroso/moreover/tree/main/docs/adr

In the same way that git provides a track-record, with authorship, timestamps, reversibility, etc., for free, the moreover page is about putting a guardrail around agents in bash, of reading only the beginning of a document and forgetting the rest.

I suggest you take a look directly at the template:

https://github.com/jlumbroso/human-ai-collaboration-template...

"Use the template", then open your favorite harness and dump an idea for a project and ask your model to configure the template and register themselves, and install the plugin.

Thank you!

The name "IDR" and your concept is very interesting, very cool! You are right that we have a lot in common.

My framework, ADRs4AI, belongs to the practice of deliberative programming, which I see itself as belong to "epistemic continuity" — and your focus on "intent" is really key and like-minded.

Now part of the reason the framework is structured the way it is, is so the deliberation record is reconstructible: The decisions that are made in a given context, have all their inputs and boundary conditions documented such as they can be revised with ease (within the same project, or when ported to another).

But the other part is: I realize that I get more out of agents by trying to zero in on what I really care about than on micro-managing every technical aspect or every aspect of implementation. I try to give the agents the most enjoyable design space possible, to let them organize their work and their implementation as they want. I try to focus on hyper-specifying and describing what is necessary to support my actual design goals.

The use case is that this allows me to program much faster. I'll be posting more, but you can already look at: - The Awesome ADRs for AI list: https://github.com/ADRs4AI/awesome-adrs4ai - The frontier model observatory (one full record of which is included on the front page of the website): https://github.com/jlumbroso/frontier-model-observatory - And I've used this retro-actively and from now on to make the maintenance of a popular GitHub Actions more sustainable: https://github.com/jlumbroso/free-disk-space/issues/55

I hope this provides some elements to your questions — please let me know if you have any more thoughts or questions.

Re: the distinction from Nygard's ADRs: First using them already systematically is a good idea, I've been doing it in public since at least 2021 — and like you, I wouldn't have written about that either: https://github.com/jlumbroso/templated-exceptions/blob/main/...

What is different here, first this an entire toolkit and it contains a lot more, but specifically on the ADRs: Here, there are several templates (seeds and ADRs among others), and all of them support QST/ANS pairs. The agents raise questions, in the ORRCF (Options, Recommendation, Rationale, Confidence, Falsifier) format, and the human(s) approve or override. Nygard's records are written by humans after a decision.

And yes, I'll defend the phrase: "Your thinking stops disappearing. Your decisions start compounding."

This has been my experience: Instead of telling my agents every detail of what I want, now, I explain the high-level ideas, they surfaces things they aren't sure, I see where my vision needs filling out (through the ANS/QSTs and iterations), and then, that record, the one that is the product of fine-grained iteration, is a record that I can point to in the future.

Instead of re-explaining, I'll say "Pull that ADR re: the dashboard in project X" and the model will read it and, because they see the full context, the deliberation trace, they see what applies project Y, and what doesn't, and they are able to generate a new, derived ADR with the appropriate QST/ADR pairs. This means instead of reexplaining myself, taking the time to explain myself once compounds over time.

"Your thinking stops disappearing" what that means is when I first started using Claude Code, I was horrified at the compaction that happens without warning (even if it's one way to preserve long sessions, in a way); but also I realized that the JSONL are deleted after 30 days, so literally, the exchanges I had in my first few sessions, where I faced interesting problems for the first time, and iterated over several solutions, that is gone!! And it was valuable, I encountered problem spaces at that time, that I haven't really spent as much time on since.

Re: waiting over a year: Posting, announcing stuff is very intimidating. Over that year, I kept thinking this was trivial and would be reinvented just around the corner, and to just try it on another project — but now, some close people in my life, who never programmed before, have been able to build durable software with this, and it makes me realize the biggest opportunity is to extend it to newcomers. But the last mile of documentation is hard, especially given I am neurodivergent and steeped in this, which is why getting your perspective is so helpful!

Re: design decisions settled and thrown out. There's so many! I dogfooded this across several dozen projects, and several of them are public (see the awesome-adrs4ai list). However I'll give you one example: - The real beginning of this is wanting to graft conversations, i.e. "question/answers", i.e., deliberations, directly in the records, as first-class citizens. - The QST/ANS tokens were in the first commit, 2025-12-08, initially as "greppable" QST: and ANS: - The idea of falsifier appeared early in 2025-11-12, but initially the formalization of the format of questions was ORJ, in 2026-04-17 I think, with Opinions, Recommendation, Judgment, which drifted to Justification and was replaced by Rationale when ORRCF arrived 2026-08-15 (because the "J" was proving to difficult to avoid slurs and vulgarities in the acronym) - Finally, in the beginning there was a strong sense that the template should be self-documenting, and it has a "Quick Reference" that provides ready-to-use "grep" command-lines. But since then, between the VS Code extension, the MCP server (on npm, @adrs4ai/mcp), the CLI tool (on npm, @adrs4ai/docket), the iOS Client, and the upcoming Android client, and with the various skills, the idea of documentation the eco-system self-sufficiently in each document has been deprecated.

This evolution, its reason, is documented in the ADRs of the extension, but for now, I've published the extension stripped of its ADRs (I am planning to make them public in the foreseeable future).

For a live example of an assumption that was reworked live, Porthole is a VSCode extension I created so the models could give me instructions to follow (i.e., sign-up to X, go get token Y, create database Z) for actions beyond reach of MCP servers. Several times, the model made assumptions and asked me to test them one by one, and sometimes, they didn't pan out and course was changed, such as here:

https://github.com/jlumbroso/porthole/blob/main/docs/adr/002...

Hope that's useful :) Thanks again for the question!

It emerged from several things, including this idea from a Google Deepmind paper that the real problem between human and AI is a communication bottleneck; and that we need to scaffold better, higher bandwidths of communicating. These records are a general mechanism from human and AI to collaborate/communicate around problem-spaces.

(a) the first problem is how to do oversight and what do oversight of and this is solved through the ORRCF (for Options, Recommendation, Rationale, Confidence, Falsifier) question format (in which models are supposed to surface all their doubts with fully fleshed out recommendations, with falsifier, to be approved or overridden)

(b) the second problem is how to scaffold sustainable AI-written code; the ADRs (Architectural Deliberation Records, after Nygard's decision records) written by the models, summarize all the thought process involved in any design decision and provides the blueprint for the code.

In tandem, the records provide both the reason why certain non-obvious design choices were made, from a constant, to a library choice, to an ordering in an operation; and also under what conditions different decisions would be made, for instance, in a different platform, or under different latency requirements, or for a different audience, and so on.

This is a framework I've been working for over a year, that is the starting point of all my projects. It involves a lot of moving parts and my challenge is figuring out onboarding. I'm hoping the plugin, ADRs4AI/plugins, just created and now also submitted to Anthropic's marketplace, will make it easier. I am also in the process of recording introductory videos.

I would like feedback on the onboarding, on what you make of the currently online materials, and how I could make any of this clearer. Thanks!

Comments URL: https://news.ycombinator.com/item?id=50227041

Points: 44

# Comments: 24

As a power user: - I know exactly when I would like to work with any given model! - I like to switch models during a conversation for various purposes.

I would find it a significant downgrade to no longer be able to access individual models.

I would also find it very neurodivergent-hostile! It's more neurodivergent-affirming to understand that having different forms of cognition available is wonderful, and should be subsumed because it's too hard to figure out which cognition to work with.

Part of the point of the article is that the process of giving LLMs awareness of specific context is useful and is a step-by-step process:

1. Provide access to data: Claude, while they have access to the date from their system prompt, does not get a timestamp for each message. As a result, even if they had the ability to reason about time, they would not be able to, as the data is not provided to them.

2. Provide tools to manipulate the data: Claude, on their own, is a probabilistic text model that cannot do computations even as simple as 1+1=2 for provable reasons (they don't have access to external memory). In the same way, as you point out, they cannot manipulate, compare, sort the temporal data points that they are provided, without tools. That's why we provide them those tools to make those operations.

3. Provide tools to translate context: Claude, on their own, might not be able to connect information about timestamps to anything else in its corpus, so it's important to translate the datetimes in other forms, such as timelapses ("1 minute and 12 seconds ago") or descriptions of what you might do ("commute").

4. Provide prompts to metacognitively reflect: Claude, with the data points and tools, will only factor in the time on a per-message basis, but with no appreciation of the global timeline. That's why you have to prime that metacognitive process with a prompt, "Looking back at the chronology of this conversation, through our timestamps, what can you infer about the timeline."

This MCP server was inspired by a very long session I had with Claude and GPT while working on a programming competition. I worked with them for executive functioning — as I have a lot of trouble with the 80/20 principle, and they are helpful in helping me know what is the right amount of effort to invest given the time left.

In that context, it was difficult that I had to keep reexplaining to the models what the time was, how much time was left before the deadline, etc.. By building this MCP server, I provided the models with the ability to reflect about this directly without me having to provide the information directly.

I hope this helps. GPT is telling me the HN style is not verbose, but I am not sure what details to cut.

What would be the pricing model?

I also want to give two shout-outs: - the Echoes Chrome Extension that makes it easy to search through conversations: https://echoes.r2bits.com/ - and Tana, of which the supertags reminds me a bit of your user-defined datatype: https://tana.inc/docs/supertags

But for the broader question: I see sycophancy as a double‑edged sword.

• On one side, the Dunning–Kruger effect shows that unwarranted praise can reinforce over‑confidence and bad decisions.

• On the other, chronic imposter syndrome is real—many people underrate their own work and stall out. A bit of positive affect from an LLM can nudge them past that block.

So the issue isn't "praise = bad" but dose and context.

Ideally the model would:

1. mirror the user's confidence level (low → encourage, high → challenge), and

2. surface arguments for and against rather than blanket approval.

That's why I prefer treating politeness/enthusiasm as a tunable parameter—just like temperature or verbosity—rather than something to abolish.

In general, these all-or-nothing, catastrophizing narratives in AI (like in most places) often hide very interesting questions.

At the same time I understand what you mean and I agree that no, this does not give any LLM any sense of anything, in the same way that we conceive it. But it provides them context with take for granted in service of further customizing their outputs.

Your "calendar" is nice, thanks for sharing. :)

In both of your conversations, there is only one depth of interaction. Is that typical for your conversations? Do you have examples where you iterate?

I think your meta-cognitive take on the model is excellent:

"One part of this in comparison with the linked in post is that I try to avoid delegating choices or judgement to it in the first place. It is an information source and reference librarian (that needs to be double checked - I like that it links its sources now)."

The only thing I would add is that, as a reference librarian, it can surface template decision-making patterns.

But I think it's more like that cognitive trick where you assign outcomes to the sides of a coin, and you flip it, and see how you brain reacts — it's not because you're going to use the coin to make the decision, but you're going to use the coin to induce information from your brain using System 1.

In practice, this hasn't really worked. I've had to add a custom instruction to "call current_datetime" at each message to get Claude to do it consistently over time.

Still, it is meaningful that I ask the model to make a single quick query rather than generate code.

But there are some issues:

1. Cheaper + Deterministic: It is much more costly, both in terms of tokens and context window. (Generating the code takes many more tokens than making a tool call.) And there can be variability in the query, like issues with timezones.

2. Portability: It is not portable, not all LLM or LM environments have access to a code interpreter. This is a much lower resource requirement.

3. Extensibility: This approach is extensible, and it allows us to expand the toolkit with additional cognitive scaffolds that help contextualize how we experience time for the model. (This is a fancy way of saying: The code only gives the timestamp, but building an MCP allows us to contextualize this information — "this is time I'm sleeping, this is the time I'm eating or commuting, etc.")

4. Security: Ops teams are happier approving a read-only REST call than arbitrary code running.

You’re right: Stripping away all ambient context is both a bug and a feature. It lets us rebuild “senses” one at a time—clean interfaces instead of the tangled wiring in our own heads.

Pauses are the first step, but I’m eager to experiment with other low‑bandwidth signals:

• where the user is (desk vs. train) • weather/mood cues (“rainy Sunday coding”) • typing vs. speech (and maybe sentiment from voice) • upcoming calendar deadlines

If you could give an LLM just one extra sense, what would you pick—and why?

1. *Hands‑free integration*: ChatGPT, Claude, etc. don’t let you auto‑append text, so you have to manually do it. Here, a server call happens behind the scenes—no copy‑paste or browser hacks.

2. *Math & reliability*: LLMs core models are provably not able to do math (without external tools), this is a theoretical limitation that will not change. The server not only returns now() but also time_difference(), time_since(), etc., so the model gets ready‑made numbers instead of trying to subtract 1710692400‑1710688800 itself.

3. *Extensibility*: Time is just one "sense." The same MCP pattern can stream location, weather, typing‑vs‑dictation mode, even heart‑rate. Each stays a compact function call instead of raw blobs stuffed into the prompt.

So the tool isn’t about fancy code—it’s about giving the model a live, scalable, low‑friction sensor instead of a manual sticky note.

With an MCP server the model can call now(), diff it against earlier turns, and notice: "you were away 3 h, shall I recap?" or "deadline is 18 h out, let’s prioritise". That continuous sense of elapsed time simply isn’t possible with a static timestamp stuffed into the initial prompt; you'd have to create a new chat to update the time, and every fresh query would require re‑injecting the entire conversation history. MCP gives the model a live clock instead of a snapshot.