The Future of Work by Henrik Kniberg

Jfokus · video · 2025-02-09 source ↗ Reader 🖥️

practical · mixed — A conference keynote built almost entirely from live demos (UX prototyping, building an agent, agentic coding on a real codebase), interleaved with explicit reflective claims about what AI agents mean for the future of developer work. Practical in intent (showing what to do and expect) but argues toward a theoretical claim (AI takes tasks, not jobs).

Structure

Key terms

• Agent Agentic AI
  An LLM given tools (e.g. access to email, Slack, GitHub) plus some level of autonomy, so it doesn't just sit waiting for a prompt but can act and take initiative on its own.
• Capability
  A named bundle of related tools exposed to an agent for one integration (e.g. all the different Slack actions together are 'the Slack capability').
• Laziness
  A developer trait reframed positively as the motivation to invent automation that removes drudgery, not a vice to be corrected.

Propositions

• explicitGenerative AI's practical usefulness to a given person is jointly determined by model quality, product quality, the person's product skill, and their prompt-engineering skill — not model capability alone — which is why most people radically underestimate what today's AI can already do.conf: high
• explicitAn agent is an LLM given tools and some level of autonomy; autonomy — acting without being re-prompted for every step — is specifically what opens up genuinely new use cases beyond chat.conf: high
• explicitAn agent can meaningfully improve itself by rewriting its own operating instructions, turning a messy, informal human request into a clean, structured prompt that is arguably better than the one the human would have written.conf: high
  extendsHenrik Kniberg's Post · p5 — Kniberg's earlier LinkedIn post claims an agent 'editing the platform it runs on' with no detail on scope or approval; this talk shows the concrete mechanism — the agent adds one tool via a code change, opens a PR, and the human explicitly withholds merge pending review with colleagues.
• explicitGiving an agent basic tools, instructions, and autonomy produces emergent behaviors that were not explicitly programmed — such as an agent diagnosing a recurring failure from its own activity log and proactively escalating to a human support channel.conf: high
  supportsHenrik Kniberg's Post · p6 — Both describe emergent, unplanned agent behavior (here: self-diagnosing and escalating a recurring failure) as a notable, desirable property rather than a risk to be designed against.
• explicitModern agentic coding tools represent a qualitative step beyond IDE autocomplete and manual copy-paste between a chat window and an editor, because they autonomously locate relevant context in the codebase, apply edits directly to files, and can run version-control operations themselves.conf: high
• explicitAn agent that digs around in an existing codebase for context before changing it (rather than relying only on what's pasted into the prompt) tends to extend existing conventions and patterns rather than bolting on unrelated code.conf: medium
• explicitAn agent performing consequential actions (git commits, pushing branches) should ask for explicit permission before acting, and should be able to recover from its own mistakes — such as retrying under a new branch name after a collision — rather than simply failing.conf: high
• explicitEven when an agent fully implements a change and opens a pull request on its own, a human should still review the code before merging; the agent does the grunt work, but merge authority stays human ('I'm not going to merge this... human in the loop').conf: high
• explicitThe enjoyment of programming was never really about the typing of code — it was about 'the making' — so offloading code-writing to AI does not reduce a developer's satisfaction; it can increase it by freeing attention for the big picture.conf: high
• explicitIn most knowledge-work roles, AI primarily eliminates individual tasks within a job rather than eliminating the job itself — a 'theory,' in the author's own words, not a settled finding.conf: medium
• explicitAs AI absorbs more of the mechanics of writing code, developers will increasingly focus on problem framing, feedback loops, and architecture — continuing a decades-long trend of raising the abstraction level (punch cards -> assembly -> compiled high-level languages -> AI-generated code).conf: high
• explicitA developer's attention is a scarce resource, and because AI removes much of the earlier forced drudgery, developers now have real discretion over where to spend it — ranging from trusting AI output fully, to skimming it, to writing code by hand.conf: high
• explicitPeople and companies that use AI agents well will have dramatically higher productivity than those that don't — comparable to the gap between using and refusing to use the internet.conf: high
• explicitcontestedHumans remain in the driver's seat in agent-assisted work — deciding what to ask, evaluating results, providing context, and watching for hallucinations — a supervisory role the author compares to a doctor, lawyer, or CEO using AI as support rather than replacement.conf: high
  contradictsResearch: Why You Shouldn't Treat AI Agents Like Employees · p1 — Kniberg unreflectively promotes an AI-as-colleague/team-player framing throughout the talk without acknowledging the controlled-study finding that this exact framing reduces personal accountability and reviewer scrutiny.

Arguments

Narratives

• Rebuilding the UI of Sweden's failed Millennium healthcare-records system by pasting a screenshot into Claude, asking for a UX critique, and getting a redesigned working app in about 27 seconds, iterated once more in under a minute.
  → Grounds the opening 'usefulness formula' claim (p1) in a real, named, high-profile public-sector failure rather than an abstract toy example, making the speed claim concrete and checkable by anyone who remembers the Millennium controversy.
• The agent that debugs itself: it notices its 6pm Gmail-send step failed due to invalid credentials, searches its own activity diary, recognizes the failure is recurring rather than one-off, sends an initial Slack message about the issue, escalates to a support channel on its own initiative, and logs a diary entry documenting what it did — none of which it was explicitly told to do.
  → Implicitly supports the claim (p4) that basic tools plus autonomy produce real emergent, goal-directed behavior, and quietly supports the talk's unexamined 'colleague, not tool' framing of agents by showing behavior that reads as conscientious teamwork rather than a programmed routine.
• The imagined future grandchild who asks 'Grandma, is it true that humans used to write code manually?' and is amazed, echoed back against the real history of punch cards and assembly language giving way to trusted compilers.
  → Functions as an analogy-argument for the abstraction-raising claim (p11): it recruits the audience's own confidence in the assembly-to-compiler-to-high-level-language progression to make trusting AI-generated code feel like the next uncontroversial step in a lineage everyone already accepts, rather than a new kind of trust problem.

Questions addressed

• ✅ What is an AI agent, as opposed to a chatbot?
  An LLM plus tools plus instructions plus some level of autonomy; autonomy is specifically what separates an agent from a chatbot.
• ✅ Will AI take developers' jobs?
  The author's own 'theory': AI mostly takes tasks, not whole jobs — a role like developer persists but changes composition, with humans staying in a supervisory, judgment-providing position.
• ✅ Does offloading code-writing to AI make coding less fun?
  No — the fun was never the typing, it was 'the making,' so a developer can get equal or greater satisfaction while writing less code by hand, because attention shifts to the parts they actually care about.
• ⭕ What happens when an autonomous agent's actions go wrong?
  Only one concrete case is shown (a Gmail credential failure that the agent self-diagnoses and escalates) plus a minor git-branch-collision recovery; general failure rates, guardrails, or what a bad outcome from an autonomous action looks like at scale are not discussed.

Gaps

• incompleteThe entire talk is built from live demos chosen, prepared, and run by the presenter at his own company on his own agent platform. There is no discussion of failure rate, what a bad outcome from an autonomous git operation looks like, or how often agents get it wrong under less favorable conditions than a curated 15-minute conference slot (larger codebase, adversarial input, ambiguous instructions).
  Read next: Corpus pieces that report failure rates and guardrail design for agentic coding rather than demo success — e.g. extract-fowler-orchestrators-tax and extract-what-survived-contact — for what happens when the review/merge step this talk relies on doesn't catch a subtly wrong change.
• illogicalKniberg treats 'ask permission before risky git actions, then a human merges the PR' as sufficient grounds that extending agent autonomy is safe, without addressing that a human reviewer's own scrutiny degrades under the very 'colleague'/employee framing the talk promotes throughout (Freddy as 'a colleague,' 'team player').
  Read next: extract-ai-agents-not-employees#p1 and #p3, which find the AI-employee framing reduces personal accountability and causes managers to catch 18% fewer errors — directly undercutting the review step this talk's safety argument leans on.
• incompleteThe 'AI takes tasks, not jobs' theory is offered as the author's own guess with no mechanism for which tasks are safe to automate first, how task-elimination accumulates into job elimination past some threshold, or what happens to junior developers who historically learned their craft through exactly the 'nitty-gritty' tasks now being removed.
  Read next: extract-engineer-career-advice-age-of-coding-agents and extract-laycock-conductor-developer, which address career-ladder and skill-formation questions this talk raises but doesn't develop.

Closes gaps elsewhere

• Henrik Kniberg's Post · g2 — The LinkedIn post's unanswered question — what is the scope of self-improving changes, and what approval process governs them? — is answered concretely here: scope is one capability/tool per change, submitted as a pull request; approval is a human reviewing the diff and choosing when to merge, with the agent asking permission before git actions.

Related documents

• Addy Osmani’s Post
  AI Employee vs Tool Framing Code Was Never the Bottleneck Human as Orchestrator of Agents Human-in-the-Loop
• The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering
  Agent Harness Code Was Never the Bottleneck Coding Agents Human as Orchestrator of Agents
• Software Factories, Light and Dark
  Agent Harness Human as Orchestrator of Agents Human-in-the-Loop
• Finding Comfort in the Uncertainty
  AI Employee vs Tool Framing Code Was Never the Bottleneck Human as Orchestrator of Agents
• From AI Code to Trusted Software: Harness Engineering in Practice
  Agent Harness Code Was Never the Bottleneck Human-in-the-Loop
• Research: How AI Agents Broaden the Scope of Knowledge Work
  Agentic AI Human as Orchestrator of Agents Human-in-the-Loop
• Papers on the UX of AI programming assistants
  Code Was Never the Bottleneck Coding Agents Human as Orchestrator of Agents
• Co-Existence and the End of Co-Intelligence
  Agentic AI Coding Agents Human-in-the-Loop
• What Survived Contact
  AI Employee vs Tool Framing Human as Orchestrator of Agents Human-in-the-Loop
• 11 Tips For AI Coding With Ralph Wiggum
  Agent Harness Human-in-the-Loop