Free and open source · Focused on engineers, built for agents
Do you know what your agent just shipped?
It moves faster than anyone can follow, so decisions get made that nobody chose. Scroll, and listen.
Make it show you.
Not less agent, and not more trust. A better way to work with the one you have: it shows you each decision on the lines where it lives, you push back where you disagree, and what ships is something you both chose.
Without deck
You ask. It answers. All of it. You push back. Then the menu.
A fair question about your own code. The decision is in there somewhere. Go and find it. Ask about one line. Get another essay. You pick Recommended. Everyone does.
- words
- 0
- file:line
- 0
- lines shown
- 0
⏺ The stall comes from a cache stampede. In services/catalog/src/pricing/pricing.service.ts:26-40, priceFor() reads from Redis through this.cache.get() at pricing.service.ts:29, and on a miss falls back to Postgres with effective_price() at pricing.service.ts:33. Every key is written at pricing.service.ts:38 with ONE_HOUR, defined at pricing.service.ts:10, so they all expire together.
When they expire, every in-flight request misses at once. Each miss takes a connection from the pool configured in src/config/database.ts:9 with a maximum of 40, and requests beyond that queue until one frees, which is why the p99 reaches roughly four seconds on the dashboard referenced in docs/runbooks/checkout.md:112.
Note also that CheckoutController.quote() at checkout.controller.ts:33 calls priceFor() once per line item rather than batching, which amplifies the effect for larger carts, and CartService.total() at cart.service.ts:87 calls it again…
There are several ways to address this. Option A is to add jitter to the TTL at pricing.service.ts:38. Option B is request coalescing with a single-flight lock around the miss at pricing.service.ts:33. Option C is a background refresher in src/jobs/refresh.ts. Option D is raising the pool in database.ts:9, though this may shift load onto Postgres…
⏺ Great question! Let me break this down in detail.
## 1. Where the TTL is set
The TTL is passed as the third argument to this.cache.set() at pricing.service.ts:38, using ONE_HOUR from pricing.service.ts:10. It may also be influenced by the default ttl in cache.module.ts:14, although that value appears to be overridden…
## 2. Staleness considerations
Whether stale prices are acceptable depends on several factors:
• How often prices change in your catalog
• Whether flash sales or time-limited promotions exist
• Regulatory requirements around displayed versus charged price
• Customer trust implications of…
## 3. Trade-offs
| Approach | Staleness | Complexity | Load |
Do you understand all the options and trade-offs?
Did you decide anything at all?
With deck
Same question. Same agent.
deck never runs a model. The agent you are already talking to, in the same session with everything it just read, writes the deck with a few shell commands and puts it on your screen.
- You ask, exactly as before.
- It reads the code, exactly as before.
deck newstarts a deck.deck openputs a bar on your screen.deck groupadds one claim and the code that proves it. A ref to a line that does not exist is refused.deck seal. Open it when you are ready. The agent cannot open it for you.
--ref
--diagram
In the window
Every claim arrives with its evidence. See the failure, not a description of it. Judge the fix against the same moment. Big changes, one concern at a time. Push back where the decision is. Questions come back with proof.
Your agent states what it found, and the lines that prove it are already in view. You check the reasoning instead of hunting for it. At ten o'clock the requests queue behind forty connections. A timeline you can watch is harder to misread than a paragraph about one. The proposed fix replays the same seconds with the expiry spread out, so you weigh it against the failure it claims to remove. A large branch comes as chapters. Each one brings only the files its argument needs, and the change lands as a diff beside its reason. Select the lines and say what you would change. Ask now, or hold it for the review; either way it reaches your agent pinned to those lines. Ask why popularity counts for 30 per cent, and the answer is the experiment that chose it: from the same agent, in the same session.
Real recordings of deck 0.1.4. Nothing on the right is a mock-up.
Try it
A real deck. Review it yourself.
Your agent was asked to take the receipt off checkout. This is the plan it wrote, before a line of code changed. Tap a sentence to see what it rests on. Use Next and Previous to move through the plan. Select a line, choose Comment, and say what you would change. On a keyboard, use n, p and c.
This deck runs in your browser, with answers written in advance. In the real window, your own agent answers whatever you type.
Then
You decide. It implements.
When you submit, deck open ends and hands your agent what you said, pinned to the lines you said it about. It picks up where it was, with your decision in hand.
Free and open source
No price. No plan to charge.
I built deck to give something back to the community that taught me most of what I know. There is no paid tier, no account to make, and nothing to upgrade to later. The code is all on GitHub under Apache-2.0.
Henit
- Apache-2.0
- No account
- No paid tier
- Built in the open
Install deck
Free, now and later. One script: it downloads deck for your machine, checks the download, puts it on your PATH and runs deck setup. Run it as yourself, not with sudo.
$ curl -fsSL https://raw.githubusercontent.com/henit-chobisa/deck/main/install | sh
> irm https://raw.githubusercontent.com/henit-chobisa/deck/main/install | iex
Then ask your agent about some code. Read the docs · Build from source · Star on GitHub