AI Is Not a Tool  🔗 **Source:** [AI Is Not a Tool](https://aurooba.blog/ai-is-not-a-tool/) > [!note]+ Document Notes > tags: [ai-first, ai-assisted, developer-workflows, scarcity-economics, engineering-leadership, mental-models, automation] > author: Aurooba Ahmed > source: Working Notes (aurooba.blog) > reference: https://aurooba.blog/ai-is-not-a-tool/ > date created: 2026-06-22 12:00 > > # 🏷️ Title: AI is not a tool > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [AI is not a tool — Aurooba Ahmed](https://aurooba.blog/ai-is-not-a-tool/) - Related: [Shipping for Today, Designing for Tomorrow](https://aurooba.blog/shipping-for-today-designing-for-tomorrow/) - Related: [The Shock Absorber](https://aurooba.blog/the-shock-absorber/) ## 📝 Summary - What happened: Aurooba Ahmed, a WordPress developer and engineering leader, argues that the popular phrase "AI first" blurs two distinct things — workflows that merely add AI as an assistant, and workflows built so they only exist because of AI. She proposes a single diagnostic test to tell them apart. - Why it matters: The "tool" framing keeps teams optimizing old processes for speed. Reframing AI as a "building block" (closer to a programming language than an editor) lets teams ask which parts of their process only existed to ration scarce human understanding. - Key stakeholders: Engineering leaders, team leads, developers adopting AI, and non-engineering staff (marketing, design, ops) who were previously blocked by a dependency on engineers. - Risks and tradeoffs: Building "from" AI means letting go of control over the "how," accepting a hand-off of process, and dismantling structures that have "felt like good engineering for a long time." Quality control shifts to defining the outcome precisely. - Bottom line: The real question of an "AI first" team is organizational, not technical — which approvals, handoffs, queues, and roles are load-bearing, and which are scaffolding built to protect a resource (intelligence) that is no longer rare. ## 📖 Main Content - The core argument rests on a subtraction test: "If you take the AI out of the workflow, does the workflow still make sense?" If yes, the workflow is AI assisted — the shape of work is unchanged and AI just makes each step smoother. If no, the workflow is AI first — there is no slower manual version, because the AI was holding up part of the work rather than sitting beside it. - Ahmed challenges the word "tool." She concedes the literal point (a programming language is technically a tool too) but draws a layer distinction: an IDE or linter is an instrument you bring to work you've already designed; a programming language is a material you build the work out of. She places AI at the second layer — "a building block rather than a tool." - The consequence of the framing: AI assisted workflows degrade when AI is removed (it was an addition); AI first workflows revert — they fall back to needing a person, because the capability had only ever existed through a person who already understood the system. - Worked example: a non-engineer (marketing, design, ops) who cannot read the codebase hits a question that previously had one answer — find an engineer and wait. With AI they ask in plain language and get unblocked. Remove the AI and that workflow doesn't slow down, it vanishes; the old dependency slides back. "There was never a manual version of someone who cannot read code reading the code." - The deeper claim is economic: software process has long been shaped by the fact that human attention is scarce and expensive. Much of "good process" — routing questions, queuing work, writing docs to reduce interruptions — is a strategy for rationing a scarce supply of understanding. AI makes a *usable version* of that understanding abundant ("synthetic attention" available at 2am for the hundredth time without resentment). Once a scarce thing becomes abundant, every workflow built to ration it is up for question. - The leadership shift: when AI is a tool, you stay in charge of "how." When AI is a building block, your job moves to holding the outcome and being "almost uncomfortably clear about what a good result actually is," while handing off the "how." She analogizes to a tech lead directing a developer — define the goal and what "done" looks like, release the route. - Uncertainties/contested claims she flags herself: she is "still learning to do this well," has "not fully made peace" with whether letting go of the path is hard or a relief, and footnotes that she is "not against process," only examining its source. She also defers her strongest evidence — a large bet she "built with my team" — to a future case study, so it is asserted, not shown here. ### 🗒️ Notes - The essay opens with a concrete framing device: skepticism about "we are becoming an AI first team" and the question "what does that actually look like on a Tuesday?" — grounding an abstract claim in lived practice. - The diagnostic question is presented as "almost embarrassingly simple," a rhetorical move that lowers reader resistance before the heavier economic argument. - Pivot terms: "AI assisted" = addition, degrades on removal. "AI first" = building block, reverts on removal. The whole essay hangs on this binary. - "Tool vs building block" is the central metaphor; "instrument I carry" vs "material the work is made of" is the crisp version. - Strongest novel idea: scarcity economics of intelligence. "Synthetic attention" is cheap and plentiful; "human attention is still scarce, still expensive, still the thing I would protect first." The distinction prevents the argument from sliding into "AI replaces people." - The leadership analogy (tech lead → developer; leading people who lead work) connects the AI claim to a general management lesson — "hold the outcome and let go of the path." - Honest hedging throughout: footnote disclaiming anti-process stance, admission of unresolved feelings, deferral of the case study. This raises credibility but also means the load-bearing evidence is off-page. - Closing reframe: the question is organizational, not technological — "which roles are load bearing, and which are scaffolding." ## 📚 References - [AI is not a tool — Aurooba Ahmed (Working Notes)](https://aurooba.blog/ai-is-not-a-tool/) - [How to Be Yourself Despite Yourself — Aurooba Ahmed](https://aurooba.blog/how-to-be-yourself-despite-yourself/) - [Shipping for Today, Designing for Tomorrow — Aurooba Ahmed](https://aurooba.blog/shipping-for-today-designing-for-tomorrow/) - [The Shock Absorber — Aurooba Ahmed](https://aurooba.blog/the-shock-absorber/) ## 🗣️ Paraphrase - People keep saying their teams are going "AI first," but when you ask what that means day to day, the answer is usually just "AI is in our editor and we ship faster." That's real, but it describes adding AI to existing work, not reorganizing around it. - A clean test separates the two: remove the AI and ask whether the workflow still makes sense. If it just gets slower, it was AI assisted. If it disappears entirely, it was AI first — the AI was holding up part of the work, not standing beside it. - Calling AI a "tool" is the source of the confusion. A tool is an instrument you bring to work you've already designed; AI behaves more like a programming language — a material you build the work out of. Tools get added to old workflows; building blocks get built from. - A non-engineer asking the codebase a plain-language question is a capability with no manual version. Take the AI away and it doesn't slow down — it vanishes, and "go find an engineer and wait" returns. - The deeper shift is economic. Software process exists largely to ration scarce, expensive human understanding. AI makes a usable version of that understanding abundant, so every process built to ration it deserves re-examination. - For leaders, the job changes from controlling the "how" to defining the outcome precisely and releasing the route — the same muscle as leading people who lead work. The honest question for an "AI first" team is organizational: which of our structures only existed because intelligence was scarce? ## 📰 Newsletter This week's read comes from WordPress developer and engineering leader Aurooba Ahmed, who has a knack for naming things you half-noticed but couldn't articulate. In "AI is not a tool," she hands you one pocket-sized test: take the AI out of your workflow — does the workflow still make sense? If it just gets slower, you're AI *assisted*. If it disappears, you're AI *first*. Her sharper move is reframing AI as a building block (think: closer to a programming language than to your linter) rather than a tool you carry to work you've already designed. The payoff is an economics lesson disguised as a vibe check: a lot of "good process" — your queues, your handoffs, your docs-so-they-stop-interrupting-the-senior-dev — was scaffolding to ration scarce human understanding. When a usable version of that understanding gets cheap, the scaffolding is up for question. For WordPress teams wiring Claude into editors and pipelines, it's a useful gut-check before you call yourself "AI first." Worth a read, and she's promised a case study next. ## ✅ Action Items #### DevRel - Developer advocacy: produce a talk/demo built on the "subtraction test" — show one AI-assisted and one AI-first workflow side by side with the AI removed. - Education: workshop teams on distinguishing "added to" vs "built from" AI in their own pipelines; office hours to audit one workflow each. - Developer experience: ship a templates/quickstart that demonstrates an AI-first capability (e.g., plain-language codebase Q&A) with success criteria baked in. - Developer marketing: content series mapping "tool framing vs building-block framing" with measurable engagement. - Community management: survey contributors on which processes feel like "rationing scarce understanding." - Internal/external/cross-project: align on shared vocabulary (assisted vs first) before claiming "AI first." #### OSPO - Policy & Governance: define contribution policy for AI-built artifacts where no manual version exists (review, provenance, ownership). - License Compliance: scanning/training for AI-generated code that's load-bearing, not just boilerplate. - Security Management: vuln intake for capabilities that revert to a human dependency when the model is unavailable (graceful-degradation policy). - Software Inventory: SBOM ownership for AI-dependent capabilities; mark which features have no non-AI fallback. - Developer Support: consultation hours on outcome-definition skill (clear "done" criteria) as a governance practice. - Community Engagement: upstream the "scarcity-of-understanding" audit as a shared OSPO worksheet. - Strategic Alignment: KPIs that distinguish speed gains (assisted) from capability gains (first). #### Community - Maintainers: roadmap clinic on which review queues exist only to ration maintainer attention. - Contributors: "first issue" rotations that let non-code contributors use AI to self-unblock. - Sponsors: transparent milestones for any AI-first capability with no manual fallback. - Ecosystem: cross-project drill for "model unavailable" reversion scenarios. #### WordPress - Core: triage which processes are scaffolding around scarce committer attention. - Core Performance: profile whether AI-first tooling shifts bottlenecks elsewhere. - Core AI: responsible-AI guardrails plus evaluation sets for plain-language codebase Q&A. - **Core Program Team:** coordination ritual to classify each cross-team handoff as load-bearing or scaffolding. - Mobile: assess offline UX for AI-dependent features (reversion behavior). - Playground: reproducible lab showing an AI-first capability in-browser. - Community: meetup kit on "assisted vs first" for organizers. - Training: lesson path on writing precise outcome/"done" definitions. - Marketing: narrative that resists the "tool framing makes the old thing faster" trap. - Support: knowledge-base entry for "what breaks when the model is down." - Design: UX audit of approval flows built to protect scarce expertise. - Documentation: examples-first patterns that AI can answer questions against. - Photos: taxonomy hygiene so AI search answers are accurate. - TV: caption quality for any AI-narrated explainer of this concept. - Polyglots: translate "assisted vs first" framing with glossary alignment. - Accessibility: ensure AI-first self-service flows meet WCAG for non-engineers. - Meta: API reliability for contributor tools that non-coders now query. - CLI: command UX docs for AI-built scaffolds. - Hosting: cross-host checklist for graceful degradation of AI features. - Tide: false-positive review loops when AI generates load-bearing code. - Openverse: education tie-ins on building from vs adding AI. - Themes: review throughput where AI removes the engineer-dependency bottleneck. - Plugins: provenance checks for AI-built plugin logic. #### The WPCC - Programs: fellowship track on engineering leadership in an abundant-intelligence environment. - Projects: governance clinic on dismantling rationing-era process. - Funding experiments: microgrants for teams building one genuinely AI-first capability with documented success criteria. ### FAIR - Technical independence: provenance and signature checks for AI-built artifacts lacking a manual version. - Policies and covenants: transparency on which capabilities depend on a specific model vendor (anti-capture). - Productized governance artifacts: a scorecard classifying each workflow as assisted vs first. ## 🧪 Hypotheses - Teams that classify each workflow with the subtraction test will identify at least one process that is pure scaffolding (no longer needed) within a single audit. - "AI first" capabilities (no manual version) deliver disproportionate value to non-engineering roles compared to "AI assisted" speed gains for engineers. - Leaders who write explicit "done" criteria before delegating to AI produce higher-quality outputs than those who specify steps. - Organizations that adopt the "building block" framing will retire more legacy approval/queue structures than those using the "tool" framing. - Capabilities built entirely "from" AI carry higher operational risk (full reversion to human dependency) when the model is unavailable. ### 📊 Methodology - Survey + workflow audit: have teams apply the subtraction test to a sample of workflows and code each as assisted vs first; measure how many scaffolding processes get retired over a quarter. - Controlled comparison: A/B leaders delegating by steps vs by outcome criteria; rate output quality blind. - Value attribution: instrument non-engineer self-service AI queries vs engineer-interruption baseline; measure unblock time and engineer interruption volume. - Resilience test: simulate model outage; measure which capabilities slow vs vanish. ### ❓ Questions - Where exactly is the boundary between "addition" and "material"? Many real workflows are mixed. - Does abundant synthetic attention create new bottlenecks (verification, trust, hallucination review) that re-ration a different scarce resource? - What's the failure mode when an AI-first capability is wrong but confident and the non-engineer can't evaluate the answer? - How do you price/own a capability that has no manual fallback? - Is the tech-lead analogy sound, or does delegating to a model differ fundamentally from delegating to an accountable human? ### 🔮 Future Research - The promised case study: a concrete AI-first build that "would be incoherent" as a faster version of prior work. - Taxonomy of "scaffolding vs load-bearing" process across team types. - Empirical study of where the new bottleneck lands once intelligence is abundant. - Governance models for capabilities with no manual version. ### 💡 Implications - Practice: process audits should ask "what was this built to ration?" not just "how do we speed this up?" - Policy: graceful-degradation and fallback-ownership policies become necessary for AI-first capabilities. - Security: capabilities with no manual version concentrate single-point-of-failure risk on the model. - Education: the durable skill shifts from "directing steps" to "defining outcomes precisely." - Funding: invest in capability creation (first) distinctly from efficiency gains (assisted). ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch–Kincaid Grade ~8–9 (Flesch Reading Ease ~60–65). Conversational, short sentences, minimal jargon, one footnote. #### 👀 Visual learners - Present: none — no diagrams, charts, or code. One bolded blockquote (the subtraction question) serves as a visual anchor. - Improve: a 2x2 (assisted/first × removed/intact) or a before/after diagram of the non-engineer workflow; a "tool layer vs material layer" stack diagram. #### 🔊 Aural learners - Present: none — text only. - Improve: a 3-minute audio reading or TTS version; a short narrated walkthrough of the subtraction test. #### 🗣️ Verbal learners - Present: strong — clear definitions (assisted vs first), the tool/building-block analogy, the tech-lead analogy, the 2am "synthetic attention" example. - Improve: a one-line glossary box for "AI assisted," "AI first," "synthetic attention," "load-bearing process." #### 🧩 Kinesthetic learners - Present: the subtraction test is a hands-on prompt readers can apply immediately. - Improve: a downloadable worksheet to audit three real workflows; a checklist for classifying each as scaffolding or load-bearing. #### 🧠 Logical learners - Present: clean if/then structure (remove AI → degrades vs vanishes); economic causal chain (scarcity → process → abundance → re-examination). - Improve: a decision tree and a small table mapping rationing structures to their newly-abundant resource. #### 🧑‍🤝‍🧑 Social learners - Present: a comment section invites discussion; framing is conversational. - Improve: discussion prompts for team retros; a peer-audit rubric. #### 🧘‍♀️ Solitary learners - Present: reflective tone, self-directed question to "sit with." - Improve: journaling prompts ("which of my processes ration scarce understanding?"). #### 🌿 Naturalistic learners - Present: none directly. - Improve: lifecycle framing — process as an ecosystem that adapts when a once-scarce resource becomes abundant. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: clear H2 heading structure, single H1 title, a skip link, descriptive link text, an og:image with alt text. - Improve: confirm the footnote back-and-forth links announce purpose; ensure blockquote is conveyed as a quote, not just visual emphasis. #### Keyboard navigation - Present: standard WordPress theme with skip-link target; links are reachable in logical order. - Improve: verify visible focus indicators on the comment form and footnote links. #### Contrast and readability - Present: short paragraphs, generous structure aids readability. - Improve: verify body text meets 4.5:1; confirm link color contrast against background. #### Text resizing and reflow - Present: responsive viewport meta tag set. - Improve: confirm no clipping at 200% zoom; respect prefers-reduced-motion if any animation exists. #### Media and captions - Present: text-only article; no media to caption. - Improve: if an audio version is added, ship a transcript and avoid autoplay. #### Forms and interactions - Present: comment form with labeled fields (Name, Email, Website, Comment) and required-field marks. - Improve: inline validation and accessible error messaging on the comment form; confirm required fields are programmatically marked, not just visually. #### Standards reference - Map gaps to WCAG 2.2 AA: 1.4.3 (Contrast), 2.4.7 (Focus Visible), 3.3.1/3.3.3 (Error Identification/Suggestion), 1.4.10 (Reflow), 2.5.8 (Target Size). ### 🌍 DEIB Assessment #### Cultural breadth - Present: examples are role-based (marketing, design, ops, engineering) rather than region-specific, giving broad relatability. - Improve: global team case studies; note time-zone framing ("2am") may vary in meaning across distributed teams. #### Inclusive language - Present: gender-neutral throughout; jargon ("AI first," "building block") is defined in plain language. - Improve: a short glossary for non-native readers; the footnote has a typo ("procsses") worth fixing for clarity. #### Neurodiversity support - Present: consistent structure, short chunked paragraphs, frequent headings, predictable flow. - Improve: add a TL;DR box and icon+text section labels for scannability. #### Representation - Present: explicitly centers non-engineers (marketing, design, ops) as people empowered by the shift, broadening who "belongs" in technical workflows. - Improve: name varied team contexts (small teams, agencies, enterprise) to avoid an implicit large-team assumption. #### Psychological safety - Present: humble, non-prescriptive framing; the author admits she's "still learning" and "not against process," lowering defensiveness. - Improve: explicitly acknowledge job-security anxieties the "AI first" framing can trigger, with reassurance that human attention stays the protected resource. ### ✅ Logical Validity #### Strong reasoning - Definitional/deductive (the subtraction test, throughout): The remove-the-AI test is a clean dichotomy — degrade vs vanish — that operationalizes an otherwise fuzzy distinction. Strength: it's falsifiable per workflow. To clarify further, acknowledge mixed cases that partially degrade and partially vanish. - Analogical (tool vs programming language; tech-lead vs developer): The "material you build from vs instrument you carry" analogy is apt and self-aware — she preempts the obvious objection ("a language is technically a tool too"). Strength: the author bounds her own analogy. Clarify by specifying which properties of a programming language transfer and which don't. - Causal/economic (scarcity → process → abundance): "A surprising amount of what I once thought of as good process is... a strategy for rationing a scarce supply of understanding" is a strong, generative causal claim. Strength: it reframes process as a dependent variable of resource scarcity. Clarify by quantifying how much process is actually rationing vs coordination/quality control. #### Fallacies - Hasty generalization / anecdotal evidence: The load-bearing proof (a "fairly large bet" built with her team) is deferred to a future case study, so the central claim rests on one undisclosed example plus a hypothetical (the non-engineer Q&A). Fix: present at least summary outcomes now, or label the thesis explicitly as a hypothesis pending the case study. - False dichotomy (mild): "AI assisted vs AI first" is framed as binary ("does it still make sense — yes or no"), but real workflows often partially revert and partially degrade. Fix: allow a spectrum and address blended workflows. - No-true-Scotsman risk: Defining "AI first" as "vanishes when removed" makes the claim near-unfalsifiable — any counterexample of a still-functioning workflow can be reclassified as "merely assisted." Fix: give independent criteria for "first" beyond the subtraction outcome. - Suppressed cost / one-sidedness: The abundance-of-intelligence claim treats "usable version of understanding" as reliable without weighing hallucination, verification cost, or the non-expert's inability to judge a wrong answer. Fix: account for the new scarce resource (trustworthy verification) the abundance creates. #### Tone of voice - Reflective, humble, essayistic, and self-questioning. Examples: "almost embarrassingly simple," "I have not fully made peace with which one it will be," and the footnote "I'm not against process, I'm just examining the source." The tone invites rather than asserts, which strengthens persuasion while softening the thinner evidence. ### 🛡️ DARVO Analysis - Deny: No DARVO present. The author does not deny wrongdoing or minimize a critique aimed at her; if anything she over-discloses her uncertainty. - Attack: No attacks on accusers or credibility-undermining. She critiques a framing ("tool," "AI first" hype), not people, and credits the speed gains of AI assistance as "real." - Reverse victim/offender: Not applicable — there is no accuser/accused dynamic. This is a reflective opinion essay, not a defensive response. - Emotional cues/rhetoric: The emotional register is curiosity and mild self-doubt, not grievance or victimhood. No related manipulative fallacies detected in a DARVO sense. ## 🎯 Conclusion - Bottom line: "AI first" is worth the label only when removing the AI makes the workflow vanish, not merely slow down. The "tool" framing keeps teams making the old thing faster; the "building block" framing lets them ask what the old thing was for — and which of their processes only existed to ration a now-abundant resource. - Practical next steps for readers: run the subtraction test on three real workflows; classify each as assisted or first; flag any process whose only job was rationing scarce expertise; practice defining outcomes and "done" criteria precisely, then delegate the route — to AI or to people. Watch for Ahmed's promised case study for the concrete proof this essay defers. ## 🔄 Refactor Appendix — AI is not a tool > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. ### 📚 Literature Atoms (H3) #### [H1] Subtraction test distinguishes AI-assisted from AI-first work > [!quote] ID:rw_subtraction > If you take the AI out of the workflow, does the workflow still make sense? **Context & use**: - Section "The line I keep looking for" — the essay's central diagnostic. - Operationalizes a fuzzy distinction into a one-question check teams can run. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H2] AI is a building block, not a tool > [!quote] ID:rw_buildingblock > Closer to a programming language than to an editor. A building block rather than a tool. **Context & use**: - Section "Where 'tool' stops fitting" — material you build *from* vs instrument you carry. - Reframes the mental model that keeps teams optimizing instead of redesigning. **Tags**: #xref #articleseed **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H3] Much process exists only to ration scarce understanding > [!quote] ID:rw_scarcity > A surprising amount of what I once thought of as good process is... a strategy for rationing a scarce supply of understanding. **Context & use**: - Section "When intelligence stops being scarce" — the economic core. - Once a usable version of understanding is abundant, every rationing process is up for question. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H4] AI-first leadership means holding outcome, releasing path > [!quote] ID:rw_outcome > You have to hold the outcome and let go of the path. **Context & use**: - Section "Holding the outcome, letting go of the path" — the leadership shift. - The durable skill becomes defining "done" precisely, not directing steps. **Tags**: #xref #addendum **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Abundance reframes process as a rationing artifact **Claim** (one sentence, Courtney's voice): When a once-scarce resource becomes abundant, the processes built to ration it become optional scaffolding rather than good engineering. **Evidence pointer**: [[#H3]] **Scope & conditions**: Holds when the abundant substitute is genuinely usable; breaks when verification of the substitute is itself the new scarce resource. **Links**: - [[Scarcity economics]] — because extends - [[Good process vs scaffolding]] — because contrasts on intent - [[AI workflow design]] — because applies-in engineering teams <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Does abundant synthetic attention just relocate the bottleneck to verification/trust? — aurooba.blog/ai-is-not-a-tool #fleeting #inbox - [F2] Watch for Ahmed's promised AI-first case study; it carries the deferred evidence. — aurooba.blog/ai-is-not-a-tool #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Run the subtraction test on three current workflows and label each assisted vs first — #things - [ ] Draft a "scaffolding vs load-bearing" process audit worksheet — #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/AI Is Not a Tool.md|AI Is Not a Tool by aurooba.blog]] ## Highlights - **If you take the AI out of the workflow, does the workflow still make sense?** ([View Highlight](https://read.readwise.io/read/01kvrpe9f0mwf98bg3pkjymk9h)) - Note: The subtraction test that separates AI-assisted from AI-first. - Tags: atom/literature/h1 - I want to be careful here, because I do not mean this literally. A programming language is technically a tool too, if you want to be precise about it. But a language does not sit at the same layer as an IDE or a linter. You do not bring it to your work the way you bring an editor to your work. You build the work out of it. **And that is the layer AI has started to occupy for me. Closer to a programming language than to an editor. A building block rather than a tool.** It is one of the materials the work is made of, not one of the instruments I carry to work I have already designed. Tools get added to old workflows. Building blocks get built from. ([View Highlight](https://read.readwise.io/read/01kvrpebvmcgyx4498pvmxkmd0)) - Note: Core reframe: AI is a building block you build from, not a tool you carry to an existing workflow. - Tags: atom/literature/h2 - For as long as I have worked in software, one fact has shaped every workflow I have ever designed, usually without my noticing it was doing the shaping. Human attention is scarce and expensive. The person who understands the system is a bottleneck, so you build careful structures around protecting their time. You route questions to them. You queue work for them. You write documentation so people will interrupt them less. A surprising amount of what I once thought of as good process is, when I look at it honestly, a strategy for rationing a scarce supply of understanding.[1](https://aurooba.blog/ai-is-not-a-tool/#a77c13c2-1236-49a2-bd70-31dcd10a2c95) ([View Highlight](https://read.readwise.io/read/01kvrpef2htjhzfv5xx4t8ktvh)) - Note: Economic core: much of "good process" is rationing scarce understanding — which AI changes. - Tags: atom/literature/h2 - I have been learning a version of this same lesson somewhere completely outside of AI. When you stop leading the work directly and start leading the people who lead the work, you run straight into it. You have to hold the outcome and let go of the path. Some days that letting go is the hardest thing in the world, and some days it is a quiet relief, and I have not fully made peace with which one it will be on any given morning. It turns out an AI first workflow asks for the same muscle. Define the outcome with real care. Release the route. ([View Highlight](https://read.readwise.io/read/01kvrpeh5dy5v7zge4t5jv07xd)) - Note: AI-first mirrors leadership: hold the outcome, let go of the path. - Tags: atom/literature/h3