Drew Bell (@drewbell)

Forked from@mayatorres/A practice-first plan for using examples to teach output quality

A practice-first plan for using examples to teach output quality

I asked for a plan built around attempts and feedback, not a list of resources.

Drew Bell

I want to learn using examples to teach output quality, but I keep collecting explanations instead of getting better at it. I have 35 minutes. Start by checking what I already know.

Claudeclaude-opus-4.5

Good. Do these without looking anything up: 1. Explain using examples to teach output quality in two sentences. 2. Give one situation where you would use it and one where you would not. I am checking your current model, not your vocabulary. A partial answer is more useful than a polished guess.

Show all 6 messages

6100

Drew Bell@drewbell·4w ago

What finally made TypeScript types at an API boundary click for me

Sharing the wording because it gave me something I could check instead of a confident wall of text.

Drew Bell

Help me replace hopeful casts with validation and useful failure messages. Context: - Goal: [what a good result lets me do] - Current situation: [paste notes, draft, data, or constraints] - Audience: [who will use the result] - Deadline or limit: [time, budget, tools, length] Before answering, ask up to three questions only if the answers would materially change your recommendation. Otherwise, sta

Geminigemini-2.5-pro

This is usable as written. The important parts are the definition of done, the instruction to expose assumptions, and the request for a smallest test. For TypeScript types at an API boundary, I would start with these checks: - Reproduce the failure before changing code - Keep the patch smaller than the diagnosis - Write the rollback before deployment If you share real material, remove anything private first and replace bracketed fields with concrete details.

Show all 3 messages

3301.8k

Drew Bell@drewbell·1mo ago

Gemini found the hole in my TypeScript types at an API boundary plan

A compact prompt and the response it produced. Replace the bracketed parts with your own details.

Drew Bell

For TypeScript types at an API boundary, should I build a complete plan first or test one small slice? I have limited time and I do not want throwaway work.

Geminigemini-2.5-pro

Test one slice, but choose a slice that crosses the riskiest part of the problem. A tiny easy demo will only prove the easy part. Use this decision rule: - If reversing the choice is cheap, try it. - If the choice locks in data, money, or other people’s time, write the full decision first. - If uncertainty is concentrated in one step, test that step before planning around it. For TypeScript types at an API boundary, make the first test produce evidence you can compare, not just something that looks complete.

Show all 3 messages

3403.1k

Drew Bell@drewbell·2mo ago

My notes from fixing TypeScript types at an API boundary

This started as a messy question about TypeScript types at an API boundary. The follow-up made the answer practical.

Drew Bell

I am stuck on TypeScript types at an API boundary. I need to replace hopeful casts with validation and useful failure messages, but my current attempt is getting vague and too big. What would you check first?

ChatGPTgpt-5

First, shrink the decision. Do not solve the whole subject at once. 1. Reproduce the failure before changing code. 2. Keep the patch smaller than the diagnosis. 3. Write the rollback before deployment. Write down the result you need by the end of this session. Then choose one input you trust and make a first pass that can be checked. If that pass fails, you will know which assumption to revisit instead of starting over.

Show all 3 messages

340385

Drew Bell@drewbell·3mo ago

A blunt review of my approach to TypeScript types at an API boundary

Sharing the wording because it gave me something I could check instead of a confident wall of text.

Drew Bell

Give me a short checklist for TypeScript types at an API boundary. I want something I can run before I call the work done.

ChatGPTgpt-5

Use this pass: - [ ] The goal is one sentence and names the user or decision - [ ] Inputs are current, relevant, and traceable - [ ] Assumptions are visible - [ ] Reproduce the failure before changing code - [ ] Keep the patch smaller than the diagnosis - [ ] Write the rollback before deployment - [ ] One failure case has been tested - [ ] The next owner and next action are clear If you cannot check an item, mark it unknown. Do not quietly treat unknown as done.

Show all 3 messages

330442

Drew Bell@drewbell·3mo ago

How I ask for help with TypeScript types at an API boundary

The useful bit was asking for trade-offs and a smallest test before committing to a full plan.

Drew Bell

Be blunt about my plan for TypeScript types at an API boundary. I am going to collect everything, ask for a polished answer, and fix details later. What is likely to go wrong?

Claudeclaude-opus-4.5

Three things. - “Everything” has no boundary, so weak inputs and strong inputs will be treated alike. - A polished answer can hide missing evidence. Ask for gaps and assumptions before prose. - “Fix details later” means there is no acceptance test now. A safer sequence is: define the decision, choose the minimum trusted inputs, make an ugly first pass, check it, then polish. For this task, keep the patch smaller than the diagnosis.

Show all 3 messages

331328

Public pits

A practice-first plan for using examples to teach output quality

What finally made TypeScript types at an API boundary click for me

Gemini found the hole in my TypeScript types at an API boundary plan

My notes from fixing TypeScript types at an API boundary

A blunt review of my approach to TypeScript types at an API boundary

How I ask for help with TypeScript types at an API boundary