Most teams say the same thing when they roll out AI tools. "We'll let the models handle the busywork so people can focus on higher-value tasks." Sounds clean. Then you watch what actually happens. People paste entire problems into a chatbot.
The model spits out something plausible.
Someone skims it, tweaks a few words, and ships.
Nobody is quite sure who really did the work or how good it actually is. The gap is simple: organizations talk about "augmentation" and "copilots," but they almost never do the boring, explicit work of deciding which tasks belong to humans, which to models, and under what conditions. So the repartition happens by accident. If you want AI to make your team better instead of fuzzier, you have to design that repartition on purpose. ## What the slide says versus what people do On the slide, the story looks like this: Human rlhf constitutional methods alignment tricks sets direction
AI drafts and analyzes
Human reviews, corrects, and decides In real teams, three patterns show up. ### Prompt-and-hope
Someone throws a vague prompt at a model, gets an answer, edits lightly, and uses it. There is no clear definition of what the model is responsible for, what the human is checking, or what "good" means. ### Review theater
Teams insist "a human reviews everything," but the review is a quick skim right before a deadline. The model is doing 90 percent of the work; the person is providing legal cover, not real oversight. ### Shadow dependence
Juniors never learn to do tasks without a model. Seniors quietly redo important pieces by hand because they do not trust the outputs. Nobody says this out loud. You end up with work that looks faster, but where ownership and quality are muddy. To fix that, you have to start one level down: at the task, not the tool. ## The four basic chunks of knowledge work Across most white-collar jobs, the work breaks down into a handful of recurring moves. ### Understanding
Clarifying the problem, digging through context, reading source material, talking to stakeholders, spotting constraints. ### Structuring
Deciding on a plan, choosing the level of detail, outlining documents or systems)-reliability engineering, defining steps and dependencies. ### Producing
Writing, coding, drafting slides, building dashboards, filling in details, running analyses. ### Judging
Checking facts, stress-testing logic, weighing trade-offs, making decisions, negotiating, taking responsibility. Every job uses these in different ratios, but the pattern holds. Models are good at some of these. Humans have to own others. The repartition question is just: for this specific workflow, who does what? ## Where models are genuinely strong If you strip away hype, models do three things well for knowledge work. ### Generate variations at low marginal cost
Drafts, alternatives, rewrites, test cases, hypotheses, examples. They let you explore more options than you would by hand, as long as you know what space you are exploring. ### Compress and reformat information
Summaries, bullet points, tables, extractions, translations between styles and registers. They can turn messy inputs into more workable shapes quickly. ### Fill in patterns
Code that follows known idioms, email replies that follow consistent tone, boilerplate documentation, standard clauses, template-based content. These strengths map naturally onto pieces of work you can offload with low risk. Typical candidates: – First-pass summaries of long documents
– Starter outlines for standard types of content
– Routine code in familiar stacks
– Standard operating procedures, checklists, templates
– Expanding sparse notes into full drafts If a step is pattern-heavy, well-bounded, and cheap to redo, the model can carry most of it. ## Where humans cannot abdicate On the other side, there are moves that do not survive delegation. ### Choosing the problem
Deciding what to aim at, which constraints matter, which trade-offs are acceptable. Models can help you explore, but they have no stake in whether you are solving the right thing. ### Owning the risk
Understanding what happens if this is wrong. Legal exposure, patient harm, financial loss, brand damage, breach of trust. That responsibility lives with humans, whether you like it or not. ### Holding context over time
Remembering why a decision was made six months ago, how it interacts with adjacent projects, what politics are in play, which promises have been made. Models see text; teams live history. ### Negotiating and persuading
Aligning stakeholders, reading subtext, adjusting tone based on who is in the room, choosing when to push and when to back off. You can get help drafting words, but not running the relationship. ### Ethical and value judgments
Where the right answer depends on values, not patterns in a dataset, you cannot outsource the call. You can ask models for arguments on all sides. The decision is still yours. If you let models leak into these domains without explicit guardrails, you do not just change workflows. You change where accountability sits, usually without saying it out loud. ## How teams actually repartition, function by function Look into real organizations that have been using AI for a year or two and some patterns emerge. ### Writing and marketing Models take: – First drafts of blog posts, emails, ad variants
– Rewrites for tone and reading level
– Idea generation for campaigns and headlines
– Localization starting points Humans keep: – Positioning, narrative, and messaging strategy
– Brand voice guardrails and approvals
– Final fact checks on claims
– Segmentation and channel choices In healthy teams, the model is treated like a fast junior copywriter. It never publishes alone. ### Product and design Models take: – Condensing user feedback and tickets into themes
– Generating alternative phrasing for UX copy
– Turning structured notes into PRDs and specs
– Brainstorming edge cases and test scenarios Humans keep: – Product direction, prioritization, and trade-offs
– Interaction patterns and information architecture
– Calls about scope, constraints, and timelines Here, the model is a research and documentation helper, not a product owner. ### Engineering Models take: – Boilerplate code, tests, and refactors in familiar languages
– Skeleton implementations from clear specs
– Migration scripts, one-off data transformations
– Code review hints and suggestions Humans keep: – System design and architecture
– Security, performance, and reliability decisions
– Final merges and production changes
– Incident handling and root-cause analysis Teams that do this well treat models as aggressive autocomplete with guardrails, not as fellow engineers. ### Operations and support Models take: – Draft responses for common tickets
– Classification and routing of incoming requests
– Summaries of incidents and runbooks
– Suggestions for next actions in standard workflows Humans keep: – Handling of novel, sensitive, or angry cases
– Policy policy why governments care about your gpu cluster decisions and exceptions
– Escalations and postmortems The line is clearer here: anything that touches emotion, escalation, or policy drift goes to a person. ### Analytics and research Models take: – First-pass EDA narratives on prepared datasets on the open web
– Draft SQL for simple questions
– Rewriting charts and tables into English
– Generating candidate hypotheses Humans keep: – Choice of metrics, cohorts, and definitions
– Study design and sampling
– Interpretation of results in context
– Calls on causality versus correlation Letting a model define metrics or success criteria is how you end up optimizing the wrong thing, faster. ## The silent failure modes when you do not design the split If you do not talk explicitly about who does what, you see the same pathologies. ### Invisible delegation
People quietly let the model do the heavy lifting, then present the output as their own judgment. When something goes wrong, nobody can tell where the failure started. ### Quality drift
As models get better, review tightens for a while, then relaxes. Over time, assumptions change, prompts evolve, but no one recalibrates what "good enough" means. ### Seniority inversion
Mid-level and senior people are comfortable deciding what to delegate. Juniors are not. They either over-trust outputs or avoid the tools entirely. Skill development gets uneven. ### Review bottlenecks
A small number of cautious people end up as reviewers for everything. They become overloaded. Either throughput dies, or they start rubber-stamping. ### Shadow policies
Some teams quietly decide "we never use AI for X," others use it heavily for the same X. The organization has no shared view of acceptable use. All of this can be avoided with a few blunt agreements. ## Doing repartition on purpose instead of by accident You do not need a 50-page policy. You need a simple map for each major workflow. ### Step one: map the work Take a concrete process: writing a client proposal, triaging bugs, publishing a feature, running a quarterly analysis. Write down its steps: – Inputs
– Transformations
– Decisions
– Outputs Do this in plain language, not org-chart speak. ### Step two: tag each step with three labels #### Risk What happens if this step goes wrong? Low: mildly annoying, reversible
Medium: costly but containable
High: legal, safety, or major business impact #### Complexity Is this step mostly pattern application or does it require deep context and judgment? Low: mostly templated
Medium: mix of pattern and context
High: heavy reliance on tacit knowledge #### Repetition How often does this happen? Rare, occasional, frequent, continuous ### Step three: apply a simple rule #### For low-risk, low-complexity, frequent steps Let the model lead. Humans spot-check. Automate aggressively. #### For medium-risk or medium-complexity steps Use the model as a first pass or suggestion engine. Humans own the final output. #### For high-risk or high-complexity steps Humans lead. Models provide drafts, checks, or alternative views, but cannot close the loop alone. You will still argue about edge cases. That is fine. The point is to stop pretending all tasks are equal. ### Step four: encode this in how you actually work Change what you ask in tickets, briefs, and templates: – "Which parts of this can be safely offloaded to a model?"
– "What is the human reviewer expected to check?"
– "What are the failure modes we care about here?" Add small, concrete rules like: – "No model-written text goes to customers without a named human approver."
– "Models can propose legal language; only counsel can approve it."
– "Any forecasting used for external commitments must be double-checked by an analyst." Boring? Yes. But it turns AI from a vague presence into a defined collaborator. ## New skills that actually matter under this split Once you see work this way, the useful skills change. ### For individual contributors – Decomposing tasks into human and model pieces
– Writing prompts that respect constraints, not just styles
– Knowing when to stop asking the model and think alone
– Building small evaluation habits: spot-checking, back of the envelope math, sanity checks ### For leads and managers – Designing workflows that use models without eroding accountability
– Setting quality bars and deciding where human review must never disappear
– Reading metrics about AI usage and linking them to outcomes, not vanity numbers
– Coaching people away from both over-reliance and under-use ### For organizations – Making it acceptable to say "I used a model for this part"
– Logging where AI was involved in decisions when it matters
– Investing in internal libraries of prompts, patterns, and examples that encode institutional knowledge The theme is the same: you treat models as part of the system, not as magic. And you admit they are there. ## What changes in team dynamics The repartition is not just technical. It shifts how people interact. ### Velocity expectations Once you have models handling first drafts and mechanical steps, the baseline for "how long this should take" changes. That can be good, but only if you protect the human parts that can't be compressed: deep thinking, negotiation, careful review. ### Career paths If juniors spend more time editing and less time drafting from scratch, you have to make sure they still get reps on the underlying skills: structuring problems, arguing positions, debugging hairy issues. Otherwise you hollow out your future seniors. ### Ownership When a deliverable is part human, part model, you must be crystal clear: – Who is the accountable person
– What they are expected to have checked
– How you treat "but the model said" in postmortems Done right, AI becomes a force multiplier. Done lazily, it becomes a convenient scapegoat. ## The point Knowledge work under AI is not a sci-fi future. It is the current mess on your team's shared drive. You are already repartitioning tasks between humans and models. You are just doing it informally, through individual habits and quiet shortcuts. If you want that repartition to make the team sharper instead of sloppier, you have to: – Name the actual tasks
– Decide which belong where
– Make the boundaries visible
– Accept that some work should never be fully automated The promise was that AI would free humans for higher-value work. That only happens if you decide, concretely, which work that is.