--- schema_version: 1 type: "essay" id: "essay-10-things-ai-has-taught-me" slug: "10-things-ai-has-taught-me" title: "10 things AI has taught me so far" summary: "Ten working principles for using AI without outsourcing taste, evidence, or accountability." dek: "The models keep changing. The parts that matter don't: context, taste, verification, and ownership." status: "published" visibility: "public" indexing: "index" categories: - "ai" - "thinking" - "building" tags: - "AI practice" - "judgment" - "verification" - "workflows" created: "2026-03-19" updated: "2026-07-25" published: "2026-07-23" canonical_path: "/writing/10-things-ai-has-taught-me" canonical_url: "https://rahilchamola.com/writing/10-things-ai-has-taught-me" preferred_citation: "Chamola, Rahil. “10 things AI has taught me so far.” Curated Randomness, 2026." reading_minutes: 10 authors: - id: "rahil-chamola" name: "Rahil Chamola" role: "author" legacy_slugs: - "10-rules-for-ai" - "10-rules-for-using-ai" series: id: "building-with-models" title: "Building with models" part: 2 related_slugs: - "the-model-is-not-the-product" - "co-writing-with-language-models" citations: [] --- # 10 things AI has taught me so far _The models keep changing. The parts that matter don't: context, taste, verification, and ownership._ I published a claim I had not verified. I defended a number I could not source. I shipped a paragraph so smooth that neither I nor anyone else could say whose argument it was. None of that was the model failing. It gave me what I asked for, faster than I could notice I had asked for the wrong thing. Every rule below is something I broke first. They are written as instructions because that is how I use them. None of them protect you from a bad idea. Speed just gets the bad idea in front of people sooner. That is the risk that grew when the tools got good, and it is the one thing a better model cannot fix. > Speed is the tool. Judgment is the craft. ## 1. Use the model you have. Switch when the evidence earns it. The useful model is the one that can do today's work inside today's constraints. A launch announcement is not evidence that your entire workflow should move. **In practice.** When a new model looks better, I run the same small set of difficult tasks through both. I switch for a demonstrated gain in quality, speed, tools, privacy, or cost. A loud leaderboard is not enough. I have watched people spend months evaluating tools instead of building with them. Waiting for the perfect setup is a way of not starting. ## 2. Inject perspective, not prompt theatre. Background, frameworks, taste, values, and real evidence shape output more than ornamental prompt language. Give the model your thesis, your angle, and your constraints, then let it help you say what you already think. **In practice.** “Write about AI products” produces an average article. “My thesis is that models are becoming infrastructure; this is for builders confusing capability with experience; use these three failures and challenge this counterargument” produces something I can work with. Scope the perspective. The model does not need my whole life. It needs the smallest packet that makes this task legible: who it is for, what I believe, what counts as evidence, and what is off limits. ## 3. Define the job before you ask for output. A useful request names the outcome, audience, evidence, constraints, failure policy, and output shape. Clever phrasing is secondary to a clear contract. **In practice.** For an essay: 1,400 words, four sections, first-person, preserve two authored lines, mark unsupported claims [SOURCE NEEDED], and end with the strongest counterargument instead of a motivational conclusion. It also makes weak output diagnosable. Was the evidence thin? Was the audience vague? Did I ask for three incompatible things at once? “The model is bad” is usually a way of not looking at where the contract broke. ## 4. Separate making from judging. Ideation, selection, drafting, critique, and polishing are different cognitive jobs. Do not ask one completion to perform all five and then certify its own work. **In practice.** I ask for three structures, choose one, draft a section at a time, then review the stable draft against explicit criteria. For higher-stakes work, the critic gets fresh context and does not inherit the writer's confidence. Keep widening and choosing in separate passes. Collapse them and the thing that wrote the draft is also the thing that grades it, and it will always pass. ## 5. Treat every answer as a proposal. Fluency is not verification. Facts need sources, code needs tests, and consequential choices need an accountable owner. A fabricated sentence reads exactly like a true one. **In practice.** A plausible statistic remains unusable until I find the primary source. A generated component is unfinished until the behavior works in the browser. An architectural recommendation remains a recommendation until I accept the tradeoff. An AI draft is raw material. Never publish a first one. The number of passes you make is roughly how much the output sounds like you. ## 6. Edit for taste. Accurate and dead is still dead. A model extends your taste. It cannot lend you any. If you do not know what good looks like, you will not notice when the output is mediocre. The human is the quality function. **In practice.** I read the draft aloud and cut the competent line that could appear in anyone's essay. I keep the awkward specific observation that could only have come from the actual experiment, then make it clearer without sanding it flat. Use AI to raise the floor, not lower the ceiling. If it is making your worst work better, you are using it right. ## 7. Keep the collaboration legible. Disclose the process. Transparency means honest provenance, visible uncertainty, and no theatre about who did what. It does not require a disclaimer for every corrected comma. **In practice.** I can distinguish my thesis, the model's suggested structure, the evidence I verified, and the claim still marked uncertain. If assistance materially changes what the audience would assume about the work, I say so plainly. Honesty about your tools is an advantage while everyone else is pretending. Visible provenance makes the work easier to challenge. Hiding it protects only the appearance of competence. ## 8. Build systems, not one-offs. One good output is a novelty. A repeatable workflow is leverage. The durable asset is rarely one giant prompt. It is the brief, source packet, examples, rubric, checks, and restart point that make a good outcome repeatable. **In practice.** If a writing session works, I save the content contract and review checklist, not the whole transcript. If a build fails, I turn the fixed failure into a test. The system should remember the lesson without replaying the conversation. Systems also make switching models less dramatic. The model may change. The task, evidence, output contract, and acceptance bar do not. ## 9. Use AI for velocity. Keep judgment on the critical path. Automate repeatable transformations. Stay close to claims, privacy, publication, permissions, money, and irreversible choices. **In practice.** The model can clean notes, compare options, generate headline variants, or prepare a reversible draft. It does not quietly publish, message another person, expose private context, spend money, or settle a product decision. AI should make you more accountable, not less. When shipping stops being hard, the quality of your thinking is the only variable left, and you find out quickly what it is worth. ## 10. Stay editor-in-chief. AI proposes. You dispose. The model can surface, synthesize, challenge, and recommend. You decide what you believe, what leaves the room, and what you are willing to defend. **In practice.** “The model suggested it” is never a defence for a published claim. If my name is on the work, the final choice is mine. That includes the choice to keep a model-generated line because it is good. ## The division of labour - AI: generate, transform, compare, critique, and help retrieve within a defined boundary. - Shared: structure, draft, test, refine, and make tradeoffs visible. - Human: belief, taste, permission, publication, and accountability. I write them in the second person because that is how I hear them, usually on the day I want to skip one. Take what survives contact with your own work. They will change again, which is the point: a way of working should improve when the tools and the evidence improve. The technology will drift. The responsibility does not. --- Creator: Rahil Chamola Canonical source: https://rahilchamola.com/writing/10-things-ai-has-taught-me Preferred citation: Chamola, Rahil. “10 things AI has taught me so far.” Curated Randomness, 2026.