Building an AI-Augmented Knowledge Work Workflow
After two-plus years of daily use, I have developed a clear-eyed view of where large language models actually help and where they create the illusion of help while quietly burning more of your time than they save. The honest answer is not that AI is good or bad for knowledge work. The honest answer is that it depends entirely on the task, and most people — including experienced practitioners — are poor at matching the tool to the task.
This post is not a celebration of AI productivity hype. It is also not a contrarian dismissal. It is an attempt to describe, as precisely as I can, a workflow that has genuinely improved the quality and speed of my knowledge work across writing, research, and code review — including the places where I tried to use AI, failed, and had to build guardrails to stop myself from making those mistakes again.
The audience is people who already understand what LLMs are, already have access to Claude or ChatGPT or both, and want to move past the “paste a question and see what you get” phase into something more systematic. Everything here is reproducible. Most of the prompts below can be copied directly and used today.
The Honest Accounting: What Two Years of Daily Use Actually Shows
Let me start with some numbers before getting into workflow mechanics, because the productivity research is more nuanced than either the hype or the backlash suggests.
A series of randomized controlled trials across customer support, software development, and professional writing published between 2023 and 2025 documented 14-55% improvements in task completion speed across a range of knowledge work tasks. Microsoft’s research across nearly 5,000 developers using AI coding assistants found a 26% increase in completed pull requests. Customer support agents using AI assistance resolved 14-15% more issues per hour on average, with the gains concentrated among less experienced workers (30-35% gains for newer agents). These are real effects on real metrics at scale.
The productivity cliff research complicates this picture in an important way. The gains are not smoothly distributed. Below a capability threshold — where users have not internalized when to trust AI output and when to verify it — AI can actually reduce output quality while creating an illusion of productivity. Users generate more content faster but that content requires more editing passes. They ask AI to do complex analysis they should do themselves and end up with confidently wrong conclusions they then have to debug. The Microsoft New Future of Work Report (2025) observed this explicitly: AI-assisted knowledge workers sometimes show reduced performance on tasks requiring genuine domain reasoning when they over-rely on AI output without critically evaluating it.
The task-level picture, from my own experience and from the research, looks something like this:
| Task Type | AI Value | Caveat |
|---|---|---|
| First-draft generation | High | Requires significant editing; saves initial paralysis |
| Brainstorming and ideation | High | Excellent at lateral thinking, low risk if evaluated |
| Format conversion (e.g., prose to bullets) | High | Mechanical transformation; low error rate |
| Summarization of content you provided | High | Accuracy scales with source quality |
| Tone adjustment and register shifting | High | Technical to executive summary — works well |
| Boilerplate and scaffolding code | High | Needs review but saves time on standard patterns |
| Research synthesis across documents | Medium | Fast, but high verification cost for key claims |
| Factual questions about current events | Low-Risky | Knowledge cutoffs and hallucination risk make this treacherous |
| Complex logical analysis | Low-Risky | AI can reason, but confidently wrong reasoning is worse than no reasoning |
| Any output you cannot verify | Risky | The less expertise you have to evaluate output, the more dangerous this gets |
The productivity gains are real. They are also highly concentrated in a subset of tasks. The biggest mistake I see skilled knowledge workers make is pattern-matching on “AI was great for X” and extending that pattern to Y, where the error rate is far higher and the errors are far harder to detect.
Task-to-Tool Matching: The Framework
Before you open a chat window, ask four questions:
1. Is the output structured or unstructured? Structured output — code, tables, JSON, formatted documents — is easier to verify. A Python function either works or it does not. A markdown table either has the right columns or it does not. Unstructured prose is harder to audit because the errors hide in plausibility.
2. How verifiable is the output? If you can check the output with a test, a search, or a calculation, do it. If you would have to trust the output by reading it carefully and hoping you catch errors, your confidence in the AI’s accuracy needs to be commensurate with its actual accuracy — which varies a lot by task type.
3. What are the stakes of being wrong? A brainstorming session that contains one bad idea costs nothing; you filter it out. An internal memo that states the wrong quarterly revenue figure costs real trust. A code snippet with a SQL injection vulnerability in production costs customers. Calibrate verification effort to stakes.
4. How much domain expertise do you have to evaluate the output? This is the one most people underestimate. If you are a senior engineer reviewing AI-generated code in your own stack, you will catch most errors on a quick read. If you are a product manager asking AI to explain a security architecture, you may not catch subtle errors at all. The less expertise you have, the less you should trust AI output without external verification.
These four questions give you a rough decision tree:
Can you verify the output?
/ \
YES NO
/ \
What are the stakes? High expertise?
/ \ / \
Low High YES (use carefully) NO (don't use)
/ \
Use freely Use + verify
(brainstorm, (code review,
first drafts, research claims,
format conversion) factual writing)
Now let me apply this to specific task types.
AI for brainstorming (high value, low risk): AI is genuinely excellent at generating a wide range of ideas quickly. It does not get fatigued, it does not self-censor as heavily as a human in an early brainstorm, and it has encountered an enormous range of contexts. When I need to generate ten angles for a technical post, five alternative architectures for a system, or a set of objections to a proposal I am drafting, AI reliably gives me material I would not have generated alone. The risk is low because you are filtering ideas, not accepting them wholesale.
AI for first drafts (high value, requires editing): The blank page is the enemy of writing productivity. AI eliminates the blank page. A 400-word AI-generated first draft of a section, even a mediocre one, is dramatically easier to edit into something good than writing from zero. But — and this matters — the editing pass cannot be light. AI first drafts tend to be structured correctly and full of plausible-sounding sentences that do not reflect your actual thinking. If you do not edit heavily, you end up with writing that sounds like AI, which is to say: competent, generic, and not quite what you meant.
AI for research synthesis (medium value, high verification cost): This is the highest-risk place to deploy AI in knowledge work because the errors are subtle. AI is fast at summarizing multiple documents and identifying themes across them. It is also prone to making plausible-sounding connections that the underlying documents do not actually support, dropping nuances in summaries, and occasionally inventing citations or misattributing quotes. Research synthesis with AI should always be treated as a first pass that requires careful verification against primary sources for any claim you plan to use.
AI for factual questions (risky without citation): If you ask AI a factual question and it does not cite a source you can check, the answer may be accurate or it may be a plausible-sounding confabulation. Knowledge cutoffs compound this: AI training data has a cutoff, and any question about recent events, recent research, or current best practices risks a confidently stated answer based on outdated information. For factual questions, use AI to generate hypotheses and search terms, then verify with primary sources.
AI for code generation (high value if you can review): A 2025 study across 300 engineers over a year found AI-assisted code generation reduced PR cycle time by 31.8% and showed a 76% reduction in syntax errors. The security picture is darker: AI-generated code was insecure in 45% of cases when no specific security instructions were given, with particularly high failure rates for cross-site scripting (86%) and injection vulnerabilities. The value is real, the risk is real, and the mitigation is straightforward: you must be able to review what AI generates. Code generation without review is not AI-assisted development; it is gambling.
AI for code review (underutilized, genuinely valuable): Most developers have not fully explored AI as a code reviewer rather than a code writer. Pointing AI at an existing PR or a function you wrote yourself and asking it to find bugs, edge cases, and security issues is one of the highest-ROI uses I have found. You provide the context, you retain judgment, and the AI is doing the exhausting pattern-matching work of asking “what if this is null?” and “what if this loops forever?” for every conditional and loop in the diff. More on this in the worked examples section.
Prompt Engineering That Actually Matters
The internet is full of prompt engineering content that overcomplicates a simple thing. Let me give you the three principles that actually matter after two years of daily use.
Principle 1: Role + Context + Format is the template for almost everything.
Role: who the AI should be. Context: what the AI needs to know about the situation. Format: what the output should look like.
Most failed prompts are missing one of these three. The role shapes the quality and register of the output. The context prevents the AI from filling in gaps with plausible guesses. The format prevents you from having to reformat the output before using it.
POOR PROMPT:
"Summarize this architecture document"
BETTER PROMPT:
"You are a senior software engineer preparing briefing materials for a team
that has not read this document. Summarize the key architectural decisions,
the trade-offs that were considered, and the unresolved questions. Format
as a markdown document with three sections: Decisions Made, Trade-offs
Considered, and Open Questions. Bullet points within each section."
The improved prompt takes an extra 30 seconds to write and produces output that requires significantly less post-processing.
Principle 2: Chain-of-thought for complex problems; zero-shot for simple ones.
Chain-of-thought prompting — asking the AI to reason through a problem step by step before giving its answer — measurably improves accuracy on complex reasoning tasks. The mechanism is that generating the reasoning forces the model to “show its work” and reduces the probability of a confident but shallow answer.
ZERO-SHOT (fine for simple tasks):
"Write a Python function that removes duplicate values from a list while
preserving order."
CHAIN-OF-THOUGHT (for complex analysis):
"I need to decide between a pull-based vs push-based architecture for this
event processing system. Think through the trade-offs step by step:
consider throughput, latency, operational complexity, and failure modes.
After the analysis, give your recommendation with the key deciding factors."
The chain-of-thought prompt will produce reasoning you can follow and push back on. The model is committed to a chain of reasoning, which both improves accuracy and makes errors more visible when they occur.
Principle 3: Iterate, do not over-engineer a single prompt.
The tendency, especially when starting out, is to try to write a perfect prompt in one shot. This is inefficient and unnecessary. A better pattern is to write a simple prompt, evaluate the output, and add a follow-up that corrects the specific things you did not like. This is faster, and it teaches you what the AI actually needs to know about your situation versus what it can infer.
Here is the prompt structure that covers most knowledge work tasks:
+----------------------------------------------------------------------+
| PROMPT STRUCTURE |
| |
| [ROLE] |
| You are a [specific expertise, not just "expert"]. |
| e.g., "You are a principal engineer reviewing code for production |
| readiness. You prioritize security, reliability, and maintainability |
| in that order." |
| |
| [CONTEXT] |
| Relevant background the AI needs. |
| e.g., "This function handles payment processing. The system uses |
| Postgres. The team's coding standards require error handling at |
| every external call." |
| |
| [TASK] |
| The specific thing to do. |
| e.g., "Review the following function for bugs, edge cases, and |
| security vulnerabilities." |
| |
| [FORMAT] |
| How the output should be structured. |
| e.g., "Format as a markdown list with severity levels: CRITICAL, |
| WARNING, SUGGESTION. For each item: the issue, the specific code |
| it applies to, and the fix." |
+----------------------------------------------------------------------+
The meta-prompt: “Critique this”
One of the most useful prompts in my toolkit is what I call the critique prompt:
"I've written the following [document/argument/design/code]. Act as a
thoughtful critic. What are the weakest parts of this argument? Where
does the logic break down? What have I overlooked? What would a
skeptical expert object to? Be direct and specific — I want genuine
critique, not encouragement."
This prompt is valuable for exactly the reason that first-draft generation can be dangerous: AI’s tendency toward agreeableness. A plain revision request will often result in the AI polishing your text while preserving its structural weaknesses. A critique prompt explicitly overrides that tendency and asks for honest adversarial review. It does not always succeed — AI can still be sycophantic even when asked not to be — but it produces significantly more useful feedback than asking for revisions.
The steelman prompt:
When I have written a position or made a recommendation, I run this before finalizing:
"Here is my position on [X]. Give me the strongest possible argument
against this position — not a weak strawman, but the genuine best
case an intelligent, informed person who disagrees would make. Do not
tell me at the end whether you agree or disagree."
The constraint at the end matters. Without it, AI will often soften the steelman by appending “of course, your position has merit because…”. That softening undermines the point, which is to genuinely stress-test the argument before you commit to it.
Practical prompt reference table:
| Use Case | Prompt Pattern |
|---|---|
| First draft | “Draft a [type] on [topic] for [audience]. Tone: [tone]. Length: [length]. Key points to cover: [list].” |
| Document summarization | “Summarize this document. Extract: main argument, key evidence, unresolved questions, and any claims I should verify independently.” |
| Code review | “Review this code as a security-focused senior engineer. Severity: CRITICAL / WARNING / SUGGESTION. Quote specific lines.” |
| Tone conversion | “Rewrite this for [target audience]. Original is [technical/casual/academic]. Target is [executive/technical/general]. Preserve all substance.” |
| Brainstorming | “Give me 10 approaches to [problem]. Include both conventional and unconventional options. Be concise — one sentence per option.” |
| Critique | “What are the weakest parts of this argument? Where would an expert disagree? Be direct.” |
| Steelman | “Give the strongest possible argument against my position. No softening at the end.” |
| Gap analysis | “What questions does this document not answer that a reader would want answered? What’s missing?” |
| Research synthesis | “Given these three documents, what are the points of agreement, the points of conflict, and the most important unresolved questions?” |
| Title generation | “Generate 10 title options for this piece. Target: [audience]. Goal: [inform/persuade/intrigue]. Avoid clickbait.” |
Writing and Editing Workflows
There are two distinct AI-assisted writing philosophies, and choosing between them matters more than most people realize.
Philosophy 1: AI writes the first draft, you edit. You provide an outline, key points, or a detailed brief. The AI generates a full draft. You edit that draft heavily — restructuring arguments, cutting AI-generic phrasing, adding your own voice and specific examples, correcting anything imprecise. The advantage is speed on the initial blank-page problem. The risk is editing a document that was never quite yours to begin with, which can result in writing that sounds polished but hollow.
Philosophy 2: You write the first draft, AI edits. You write a rough draft — imperfect, possibly out of order, but yours. The AI edits for clarity, structure, gaps, and tone. The advantage is that you retain your actual thinking throughout. The disadvantage is that it is slower and requires you to overcome the blank-page problem yourself.
After extended use of both, I have converged on a hybrid: AI for the outline and structure, me for the prose. I use AI to generate a structured outline with the main argument, supporting points, and section order — then I write the sections myself. For sections that are mostly mechanical (a comparison table, a how-to sequence, a list of caveats), I let AI draft them and edit lightly. For sections requiring genuine argument or personal experience, I write them myself. The AI does not know what I actually think, and it cannot fake the specificity of real-world experience. Writing that has both structure (AI is good at this) and genuine substance (only you have this) is better than either alone.
The writing workflow in practice:
Step 1: Brief
Describe the piece to AI: topic, audience, angle, key claims you want to make,
things you want to avoid. Ask for an outline.
Step 2: Critique the outline
Ask AI: "What sections are missing? What would a reader want that this outline
doesn't give them? Where is the argument weak?"
Step 3: Write sections
Write key sections yourself. Use AI to draft mechanical sections.
Step 4: Structural review
Paste the full draft and ask: "Does the argument flow logically? What are the
weakest transitions? Where does the evidence not support the claim?"
Step 5: Tone/register pass (optional)
If the draft needs to work for a different audience: "Rewrite this for [audience],
preserving all substance."
Step 6: Headline generation
"Generate 10 headline options. Target reader is [description]. Goal is [goal]."
Register conversion is one of AI’s most reliable tricks. A technical post-mortem becomes an executive summary. A casual Slack message becomes a formal stakeholder update. A dense RFC becomes a readable blog post. The AI does not need to understand the content deeply to perform this transformation — it is essentially a style transfer operation, which is a well-understood task for LLMs. The caveat: always read the converted output carefully for dropped details or changed meaning, especially when converting from technical to non-technical registers. AI sometimes simplifies by omitting rather than by clarifying.
Research and Synthesis Workflows
Research synthesis is where I have learned the hardest lessons about AI error rates. The workflow that works requires treating AI as a research assistant, not as a research authority.
Paste-in vs retrieval-augmented synthesis: For documents under roughly 50,000 tokens, pasting the full text into the conversation and asking for synthesis is straightforward and works well. For multiple long documents, you need a strategy. Either summarize each document separately before synthesizing the summaries, or use a retrieval-augmented generation (RAG) setup where the AI can query relevant sections from a larger corpus.
The single-document prompt pattern that I use most:
"Read this document carefully. Then:
1. What is the central argument or finding?
2. What evidence supports it? Distinguish between strong evidence
(direct data, replicated studies) and weak evidence (anecdotal,
single source).
3. What does this document not address that a skeptical reader would
want to know?
4. Are there any claims in this document that seem imprecise, overstated,
or that I should verify independently?"
This prompt forces the AI to make its own uncertainty visible rather than smoothing over everything into confident prose. The fourth question is particularly valuable — it tends to surface the claims that are plausible-sounding but weakly supported.
Multi-document synthesis:
"I have three documents on [topic]. I'll paste them below separated by
'---'. After reading all three:
1. What do all three agree on?
2. Where do they conflict or contradict each other?
3. What is the most important question that none of them answers?
4. Which document do you consider most authoritative on the core claim,
and why?"
The “which is most authoritative” question is useful specifically because it forces prioritization. Without it, AI synthesis tends to treat all sources equally, which produces mush when sources conflict.
Generating questions you haven’t thought to ask:
This is one of AI’s underused research capabilities. After reading a document or completing a synthesis, ask:
"What are the 5 most important questions that this analysis doesn't
answer but should? What would an expert in this field ask that I
haven't asked?"
This can surface genuine blind spots in your research. It is not magic — AI is generating these questions from patterns in its training data, not from any deep insight into your specific situation — but it is a fast way to pressure-test whether your research is complete enough.
Knowledge cutoffs and current information:
Every model has a knowledge cutoff, and every model will continue to answer questions after that cutoff as if it knows. Claude 3.7 Sonnet has a training cutoff of early 2025. GPT-4o’s training data extends to approximately April 2024. Any question about events, research, product versions, or best practices that postdate these cutoffs is at risk of a plausible but outdated or simply wrong answer. Never use AI for current facts without independently verifying those facts against sources with explicit dates. This applies especially to: software versions, security advisories, API specifications, regulatory requirements, and anything you plan to state as fact in a document that others will rely on.
Managing Context Window Limitations
Context window management is one of the most underappreciated skills in working effectively with LLMs. The mechanics are simple; the implications are not.
Current context windows (as of mid-2026):
| Model | Context Window | Notes |
|---|---|---|
| Claude 3.5 Sonnet | 200,000 tokens | ~150,000 words of input |
| Claude 3.7 Sonnet | 200,000 tokens | Extended output up to 128K tokens in thinking mode |
| Claude Sonnet 4.6 / Opus 4.6 | 1,000,000 tokens | Standard at these tiers |
| GPT-4o | 128,000 tokens | ~96,000 words of input |
| Gemini 1.5 Pro | 1,000,000-2,000,000 tokens | Largest context window of mainstream models |
For most practical knowledge work — single documents, single code files, most research synthesis tasks — 200,000 tokens is plenty. Problems arise in two scenarios: very long conversations (where the cumulative history of the conversation fills the context) and multi-document synthesis at scale.
What happens at the context limit:
When a conversation approaches the context limit, models behave differently. Some refuse to continue. More dangerous: some continue but silently drop earlier parts of the conversation from their “memory,” producing answers that contradict what was established earlier or fail to incorporate information you provided. This is not random — models tend to weight recent information more heavily, which means information you provided at the beginning of a long conversation is the most likely to be effectively forgotten.
Context Window Model:
+------------------------------------------------------------------+
| Full Context Window (200K tokens for Claude 3.5/3.7) |
| |
| [System Prompt] [Conversation History] [Current Message] |
| |<-- 1-2K -->| |<-- accumulates -->| |<-- your input -->| |
| |
| As conversation grows, earlier messages are compressed/dropped |
| Models weight RECENT tokens more heavily than EARLY tokens |
| Important context from early in conversation can be "lost" |
+------------------------------------------------------------------+
Mitigation strategies:
1. Keep conversations focused — one topic per session
2. Use briefing documents to restore context in new sessions
3. Summarize and restart for long-running work
4. Put the most important constraints in the system prompt or first message
Briefing documents for session continuity:
When I am working on a long-running project with AI — a multi-part technical document, a complex code refactor, a research synthesis across many sources — I maintain a briefing document. This is a short (typically 500-1000 word) text file that contains:
- The project goal and current status
- Decisions already made and why
- Constraints that must be respected
- Key vocabulary or naming conventions
- Context the AI needs to understand the project that it would not infer from any single session
When I start a new session, I paste the briefing document first. This bootstraps the AI’s understanding of the project in about 1,000 tokens rather than requiring it to reconstruct context from a conversation history that does not exist.
Chunking strategies for long documents:
For documents that exceed what you can fit in a single context window, the strategy depends on the task:
- Summarization: Chunk the document into sections, summarize each section independently, then synthesize the summaries. The summary of summaries loses some nuance but preserves the main content.
- Q&A over a long document: Identify the most relevant sections manually (or with search/grep), paste only those sections, and ask your question with the note that you have provided only the relevant excerpts.
- Code review of a large codebase: Review files or modules independently. Use a manifest or summary of the overall architecture as context at the start of each session.
When to start a fresh conversation vs continue:
Start fresh when: the topic has shifted enough that earlier context is more confusing than helpful; you have hit errors that seem to reflect context confusion; the conversation is over 40-50 turns; or you notice the AI contradicting earlier constraints.
Continue when: you need the AI to remember specific decisions it made in the current session; you are in the middle of an iterative task; the context is genuinely cumulative (debugging a specific bug, writing a specific document).
Hallucination Risk Management
This section is the most important one in this post. Hallucination is not a flaw that will be engineered away next quarter. It is a structural property of how language models work. They generate plausible text. Plausible text is not always accurate text. Even the best current models hallucinate at rates that make verification a requirement, not a nice-to-have.
The taxonomy of AI errors:
Not all errors are equal, and recognizing the types helps you build the right defenses.
Confident wrong facts: The AI states something that is simply untrue, with the same confidence it uses to state things that are true. There is no difference in tone, hedging, or linguistic markers between a correct statement and a hallucinated one. Studies in 2025 found enterprise chatbot deployments have roughly 18% hallucination rates in live interactions, with open-ended generation tasks showing hallucination rates as high as 40-80%.
Plausible but made-up citations: Ask AI to cite sources for claims and it will generate citations that look exactly like real academic papers, complete with plausible authors, journals, and years. These citations are often fabricated. The paper does not exist. This is arguably the most dangerous error type because it provides false confidence — the presence of a citation feels like verification.
Subtle reasoning errors: The AI constructs a chain of reasoning that seems logically valid but contains a hidden error — a false premise, an invalid inference, a dropped qualifier. These are the hardest errors to catch because they require you to follow the argument carefully rather than just check a fact.
Code that looks right but has bugs: Code generation errors come in multiple varieties. Syntactically correct code that fails at runtime. Logically correct code with edge-case failures. Code that appears secure but has injection or authentication vulnerabilities. Code that works in the version the model was trained on but is deprecated or broken in the version you are using.
Verification strategies by task type:
For factual claims: never use AI output as the primary source for any fact that matters. Use AI to generate hypotheses and search queries, then verify against dated primary sources.
For citations: never quote a citation an AI provides without independently confirming the source exists, says what the AI claims it says, and is accurately attributed.
For code: run it. Test edge cases. Review security-sensitive sections by hand, especially around authentication, authorization, input validation, and data serialization.
For complex analysis: check the logic step by step, not just the conclusion. The most dangerous AI errors are conclusions that follow logically from premises that are wrong.
The “cite your sources” prompt and its limits:
Asking AI to cite sources does reduce hallucination in some contexts. It forces the model to ground its claims in specific sources rather than generating from general priors. However:
- AI can and will fabricate citations that look real. The prompt reduces this but does not eliminate it.
- AI may cite real sources that do not actually say what the AI claims they say.
- AI may accurately cite sources but present only the parts of those sources that support its answer, omitting relevant contradictions.
The cite-sources prompt is a useful addition to your workflow. It is not a substitution for verification. If you use it, plan to spot-check at least the most important citations.
Building verification into workflow:
The most robust approach is to treat AI output as a draft that requires a verification pass rather than a deliverable that can be used as-is. For knowledge work, this means:
- Identify the top 3-5 claims in any AI-generated document that would be harmful if wrong
- Verify those claims independently before the document leaves your hands
- For code, establish a review step as a mandatory gate before any AI-generated code is merged or deployed
- For research synthesis, maintain a list of primary sources that support each key claim; do not allow AI synthesis to be the only record of where a claim came from
The 2025 research found that knowledge workers who use AI heavily spend an average of 4.3 hours per week verifying AI output. This is not wasted time — it is the cost of using a powerful but imperfect tool correctly. Build that time into your estimates.
Practical Workflow Examples
Three end-to-end worked examples. These are condensed versions of real workflows, with the messy iteration compressed but the key steps preserved.
Example 1: Writing a Technical Blog Post
Task: Write a 2,500-word technical post on Kubernetes resource limits and requests for an audience of developers who know Kubernetes basics but have not configured resource management in production.
Step 1: Brief and outline (5 min)
"You are writing a technical blog post for experienced developers. The topic is
Kubernetes resource limits and requests in production. The audience knows what
pods and deployments are but has not configured resources in production.
The argument is: not setting resource limits is the most common cause of
production cluster instability, and it's easy to fix once you understand the
model. Generate a detailed outline with section titles and 2-3 bullet points
of what each section covers. Flag any sections where you think I'd want to use
real example output rather than AI-generated prose."
Review the outline, revise the section order, identify sections I can draft in my own voice.
Step 2: Draft mechanical sections (10 min) For the sections that are largely reference material — the CPU vs memory model explanation, the QoS class table, the recommended values by workload type — I ask AI to draft these and edit lightly. AI is accurate on well-documented Kubernetes mechanics because they are heavily represented in training data.
Step 3: Write argument sections myself (30-45 min) The sections making an actual argument — why you should set limits even when it is inconvenient, what production incidents look like when you have not, the prioritization logic for which workloads to configure first — I write myself. AI does not have my experience with specific incidents or the genuine conviction that comes from having debugged production at 2am.
Step 4: Structural review (5 min)
"Read this draft. Does the argument build logically from section to section?
Where is the evidence weakest? What would an experienced Kubernetes engineer
object to? What questions does this leave unanswered that the reader will have?"
Incorporate the feedback that is correct, ignore the feedback that is off-target, add a section addressing the main objection raised.
Step 5: Title generation (2 min)
"Generate 10 title options for this post. The reader is a developer who
occasionally has production incidents. The title should create mild anxiety
about what happens without resource limits while implying there is an easy fix.
No clickbait. No question marks."
Pick the best, or combine two.
Total time: 50-60 minutes for a solid draft. Without AI, this is 90-120 minutes. The gain is real. The key is that I am not letting AI write the argument — only the parts where the task is explaining established mechanics.
Example 2: Synthesizing a Technical RFC or Research Paper
Task: Extract the decision-relevant information from a 40-page RFC on a distributed system’s consensus mechanism, for an engineering team that needs to decide whether to adopt it.
Step 1: Initial summarization
Paste the full document (checking token count first with a tool like ttok) and run:
"This is an RFC for a distributed consensus protocol. Summarize it for an
engineering team making an adoption decision. Structure:
1. What problem does this solve?
2. What are the design trade-offs (explicit: what does this sacrifice for
what gains)?
3. What does this require that we don't already have?
4. What are the stated limitations or known failure modes?
5. What claims in this document should I verify independently before
trusting them?"
Step 2: Extract decision-relevant specifics
"Based on the document above: what performance claims are made? What are
the exact conditions under which those claims hold? What workload sizes or
patterns were tested? Give me the numbers, not summaries of the numbers."
Verify the numbers by checking the document directly. AI summaries of quantitative data are where I most frequently catch small errors — an order of magnitude shift, a percentage stated as a rate, a figure from a specific test condition generalized beyond its actual scope.
Step 3: Generate the questions the team will ask
"What are the 10 questions an experienced distributed systems engineer would
ask before recommending this protocol for production use? Include questions
about operational burden, failure modes, and the assumptions the protocol
makes about the environment."
Compare this list against questions the team has already raised. Identify any the AI surfaced that were not on the team’s list. Often 2-3 of these are worth pursuing.
Step 4: Prepare the recommendation document I write the recommendation. The AI provides structure and catches gaps. The judgment call — adopt, defer, or reject — is mine.
Example 3: AI-Assisted Code Review for a Pull Request
Task: Review a PR that modifies the authentication flow of a web application, roughly 400 lines across 6 files.
This is one of the highest-value uses of AI in engineering workflow, and also one of the highest-risk for missed errors if you treat it as a substitute for human review rather than a complement to it.
Step 1: Provide context, then paste the diff
"You are a security-focused senior engineer reviewing a pull request for a
production web application. The system uses JWT for authentication. The
framework is Express.js / Node.js. I'll paste the diff. Review it for:
1. Security vulnerabilities (authentication bypass, token validation errors,
session management issues, injection risks)
2. Edge cases and error handling gaps
3. Correctness of the JWT implementation (algorithm, expiry validation,
signature verification)
4. Anything that looks like it would work in testing but fail under
production conditions
Format: markdown list. Severity: CRITICAL / WARNING / SUGGESTION.
For each item: description, the specific lines it applies to, the fix.
If you see nothing wrong in a category, say so explicitly — don't omit it."
Step 2: Targeted follow-up on critical areas If the diff involves session management:
"Look specifically at the session invalidation logic. Walk me through the
sequence of events when a user logs out: what happens to existing tokens?
What about tokens issued before the password was changed? Are there race
conditions?"
This targeted follow-up often surfaces issues the broad review missed. AI doing a comprehensive review of everything is less focused than AI being asked to trace a specific code path.
Step 3: Verify the critical findings yourself Every CRITICAL finding from the AI review, I trace myself in the code. Not because I distrust the AI’s pattern recognition — it is often right on CRITICAL findings — but because the consequences of a false positive (blocking a legitimate change) and a false negative (approving a security bug) are both costly. My own read is the final gate.
Step 4: Generate the review comment
"Based on the review above, write a code review comment for the PR author.
Tone: collegial, direct, not condescending. Lead with the blocking issues,
then the suggestions. Be specific about what you want changed vs what is
a style preference."
This step is pure time savings. Writing a clear, well-organized code review comment is itself a writing task, and AI produces a good draft that I edit lightly.
The security vulnerability hit rate with this workflow, in my experience: AI reliably catches common patterns (missing input validation, JWT algorithm confusion, error responses that leak internal state) and sometimes misses subtle logical errors in complex conditional logic. The hit rate for CRITICAL severity findings that it labels as CRITICAL is high. The false negative rate — things it misses entirely — is where the risk lives, which is why step 3 is non-optional.
The Over-Reliance Problem
There is a failure mode that is harder to observe than hallucination but may be more consequential over time: the atrophying of skills you have outsourced to AI.
If you use AI to draft every document, you write fewer rough drafts. If you use AI to think through every problem, you exercise the problem-solving muscle less. If you use AI for code review so consistently that you skip your own read, you lose calibration on the vulnerability patterns you used to catch by instinct.
I am not making a luddite argument. The productivity gains are real and the time savings are real. I am observing that AI tools, like any tool that automates cognitive work, can reduce the cognitive exercise that maintains the underlying skills. The engineers who relied on GPS navigation and lost their ability to navigate without it are a mild parallel.
The mitigation is intentional: periodically do the task without AI. Write a first draft yourself before looking at what AI would generate. Review the code yourself before asking AI to review it. The goal is to maintain independent judgment about what good output looks like so that you remain a capable evaluator of AI output. The moment you can no longer tell whether the AI’s code review is good is the moment the whole workflow breaks down, because you have no remaining check on the AI’s errors.
Putting It Together
The workflow described in this post is not complicated, but it has specific shape:
- Choose the task. Apply the decision framework (verifiability, stakes, expertise) to decide whether AI belongs in this task at all and in what role.
- Write a structured prompt using role + context + format. Do not start with a one-liner.
- Evaluate the output critically. Use the critique prompt and the steelman prompt when argument quality matters.
- Verify the claims that matter. Build verification into your workflow rather than treating it as optional.
- Maintain the skill. Use AI to accelerate, not to replace the judgment that makes acceleration useful.
The people getting the most value from AI in knowledge work are not the ones using it most aggressively. They are the ones who have developed accurate intuitions about where AI is reliable and where it is not, built workflows that play to AI’s strengths, and kept their own judgment sharp enough to catch the errors AI will inevitably produce. That calibration takes deliberate practice, and it is the most important skill in the AI-augmented knowledge work toolkit.
Comments