← All AI Engineer talks

AI Engineer World's Fair 2025

Designing AI to Scale Human Thought

Jun Yu Tan· Tusk12:24

Read the talk

Designing AI to Scale Human Thought

AI can do more than complete tasks: it can expose overlooked risks, adapt to how people think, and help them develop better judgment while keeping them responsible for the work.

From a talk by Jun Yu Tan

What happens to judgment when we outsource the work?

If an AI writes your code, but you never review it carefully or understand its inner workings, how do you know what you are building—and how do you maintain the skills to judge it? That question sits behind Jun Yu Tan’s exploration of interfaces that develop human capabilities. Some of the interaction patterns are proposals rather than established product behavior, but they address a practical gap in the prevailing approach to agents.

Discrete tasks make an attractive target for automation: the unit of work is measurable, the promise of removing tedious labor is easy to explain, and completion provides a basis for comparing systems. Yet coding and design still require experience, taste, and close supervision. Much of the context needed to make a good decision lives in the minds of experienced professionals; it cannot always be packaged into a prompt. Removing the work can therefore also remove opportunities to exercise the judgment that makes the work good.

Limitations slide listing deskilling, amplified biases, missed improvement opportunities, human supervision, and difficulty supplying context.
Limitations of AI focused on automating tasks and accelerating existing workflows.
0:000:13
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:00 · section reference included

Spend compute on better human work

Augmentation uses compute to help people produce better work while retaining responsibility for it. Instead of requiring a person to accommodate an AI system’s imperfect attempt at a complex task, the interface can help them notice omissions, explore alternatives, and make a more thoughtful decision.

Consider email. An automated assistant writes the whole message and sends it on your behalf. An augmentative assistant helps brainstorm the key points, offers alternative phrasings, and checks the tone. It might notice that a sentence sounds harsh relative to your past correspondence with this recipient or your usual writing style. You decide whether to soften it, review the result, and hit send.

The same distinction applies to code. An automation workflow takes an assigned Slack message, writes the implementation, and opens a pull request. An augmentation workflow reviews a pull request you created and points out an overlooked edge case or a pattern that could fail under high load. The assistance changes what you can see before you approve the work.

Automation vs Augmentation slide contrasting autonomous email and code creation with brainstorming, tone checks, and finding potential bugs in a user-created pull request.
Automation and augmentation compared through email and pull-request examples.

The distinction is therefore partly about where responsibility remains, and partly about the relationship that develops. A thinking partner expands your field of view while you stay in control. Tan compares the difference to working with an offshore contractor versus a new teammate whose capabilities grow alongside yours.

1:542:07
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

1:54 · section reference included

Turn blind spots into reviewable evidence

The first interaction pattern, blind spot detection, asks what you have not considered. A blind spot can be temporal, such as making poor decisions when tired on Friday afternoons, or social, such as technical feedback that reads as personal criticism. Identifying it is only part of the problem. The interface also has to control noise and avoid making the recipient defensive. A useful moment to intervene is when a unit of work appears ready for review.

In the testing workflow Tan describes at Tusk, a committed code change becomes the starting point for evidence rather than a stream of speculative warnings:

  1. Generate unit tests targeting potential edge cases and bugs in the changed code.
  2. Execute those tests in the codebase’s test environment.
  3. Surface issues supported by the test results.
  4. Let the developer choose whether to commit the generated tests, including passing tests, into the pull request for future regression coverage.

Execution makes the report more concrete, but the developer still decides what belongs in the repository.

A failing test also contains assumptions about what the program ought to do. Tusk exposes its business and engineering assumptions and outlines possible fixes so reviewers can evaluate those assumptions. A thumbs-up, thumbs-down, or written explanation lets the user indicate whether an issue is worth considering and helps the system learn from that review.

Tan calls this systematic pessimism: examine every changed symbol, ask what could go wrong, and consider second-order effects through the call stack. That search becomes tedious for a human as changes grow larger and more interconnected. AI can perform the broad search while tests and explicit assumptions give the reviewer something specific to assess.

Tan reports verified bugs in 43% of pull requests and almost 1,000 new tests in two months while discussing Tusk’s work with enterprise and growth-stage customers, including DeepLearning.AI and TeamFeePay. These are reported product results, not a general benchmark for AI testing.

3:514:03
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

3:51 · section reference included

Allocate attention by novelty and criticality

Not every valid suggestion deserves the same presentation. The novelty–criticality framework separates how unfamiliar an issue is from how consequential it is. In code review, those two dimensions suggest four different interface behaviors.

NoveltyCriticalityExamplePresentation
HighHighUnfamiliar race condition; customer-data exposureInterrupt for a critical discovery
HighLowNew language feature; alternative approachOffer a gentle, expandable suggestion
LowHighCommon bug; standard security checkWarn clearly; vary interruption by context
LowLowFormatting; minor optimizationBatch and make optional

A familiar but serious problem still needs a warning, but it does not need a long explanation of a concept the user already understands. An unfamiliar improvement can be valuable without being urgent. Formatting preferences should not compete for attention with a data leak.

The purpose is to spend a limited attention budget well. Tan’s prioritization argument does not establish a validated numerical cap on suggestions per review. The actionable design principle is to distinguish discoveries, learning opportunities, reminders, and polish before deciding what should interrupt the user.

5:566:00
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

5:56 · section reference included

Adapt to how the user thinks

The second pattern, cognitive partnership, moves beyond stateless answers toward a system that adapts to a person’s mental models. Knowing the desired output is not enough. The assistant may also need to understand whether someone learns through analogies or visual explanations, prefers time to reflect, or thinks through rapid iteration.

A proposed code editor could learn a developer’s refactoring patterns and suggest similar improvements in new contexts. A research assistant could learn whether its user synthesizes information chronologically or thematically, then organize its help accordingly. The useful continuity is in the way the person works, not just the facts remembered about them.

This creates a privacy constraint: personalization must make people feel understood without making them feel surveilled. A system’s ability to infer a preference does not by itself make acting on that inference comfortable or welcome.

Cognitive Partnership slide describing adaptation to mental models, learning styles, and familiar analogies, with a warning about intrusive personalization.
Cognitive partnership adapts to users while making them feel understood, not surveilled.
7:097:20
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

7:09 · section reference included

Choose the moment to help

The third pattern, proactive guidance, makes timing central. A suggestion can be relevant and still arrive at the wrong moment. Good guidance should feel like a fortunate discovery rather than an interruption.

A calendar application might propose meeting times based on energy patterns as well as availability. A writing tool might recognize that the writer is stuck and suggest a break instead of encouraging more effort. Both proposals use context to decide when—and in what form—to intervene. The design challenge is to find a middle ground between waiting passively for every request and overwhelming the user with unsolicited help.

7:508:01
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

7:50 · section reference included

Let trust develop through collaboration

These patterns depend on an ongoing relationship. When AI participates in how someone thinks and works, trust becomes more than confidence that a single transaction will succeed. Tan proposes three properties for that relationship.

  • Progressive trust: Establish reliability through low-stakes suggestions before asking the user to rely on the system for high-impact decisions.
  • Contextual trust: Keep competence specific to the domain and situation. Strong code review does not establish good design judgment; insufficient context should be visible.
  • Bidirectional trust: Let both sides adapt. The AI learns preferences while the person learns its capabilities, and the system adjusts its behavior to the trust placed in it in different scenarios.

This makes trust something the interface develops and calibrates over time, rather than a blanket permission granted once.

8:268:37
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

8:26 · section reference included

Evolve the interface with the person

If augmentation helps someone learn, the interface should change as their competence grows. It can visualize increasing expertise, introduce more complex features gradually, and adjust explanations to reflect what the user now understands. Repeating the same introductory guidance indefinitely would ignore the development the product is meant to support.

The target is real skill enhancement, not merely the feeling of being capable while the assistant is present. Learning may initially be difficult, but users should experience improvement in their core work and the satisfaction that comes with it. Increasing dependence on the tool is not sufficient evidence that augmentation is working.

9:279:36
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

9:27 · section reference included

Measure capability alongside engagement

That goal changes product evaluation. Usage, retention, and engagement still matter, but they do not establish that users are becoming more capable. A learning application can retain people without improving their performance in real-life situations. An augmentation product needs to ask how its users are growing as well as how often they return.

There are product reasons to care about that growth. First, learning a user’s preferences and intellectual needs can create a stronger relationship. Tan points to ChatGPT’s memory feature as an example of continuity across conversations; the emotional value of feeling understood is his interpretation of that experience.

Second, lasting value can come from making a team better, not only faster. Capability building gives buyers another reason to invest beyond immediate productivity. Third, users have their own stake in the outcome: time spent with an AI tool is also time spent developing—or neglecting—their abilities. Choosing tools intentionally means asking whether that investment supports learning alongside the work.

Why should we care slide with three bullets about emotional connections, productivity and capability, and intentional learning while using AI tools.
Why capability-building AI matters: emotional connections, more capable users, and learning alongside tools.
10:0610:18
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

10:06 · section reference included

Interfaces that make thought more visible

Efficiency is only part of the opportunity. Tan’s larger ambition is for AI to strengthen intuition, taste, and creativity. Blind spot detection, cognitive partnership, and proactive guidance provide possible ways to pursue that ambition, but they depend on interfaces that preserve agency, earn trust, and learn alongside their users.

The next-decade vision is an aspiration: tools that help people think in ways they could not before. An interface can act as a mirror for cognitive patterns, making habitual omissions visible and suggesting perspectives a person repeatedly misses. The value lies in what the person comes to notice and understand, as well as what the system produces.

How to build such systems remains an early design problem. The durable criterion is whether an interface enhances human capability as understanding of the technology evolves—whether using it helps people become more thoughtful, more creative, and more able to judge their own work.

11:0811:17
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

11:08 · section reference included

Resources

From the talk

Updates since the talk

  • Tusk Is SunsettingArticle

    Official notice of Tusk's June 10, 2026 product sunset and transition guidance for existing customers.

Read the complete timestamped transcript
  1. 0:00

    Hi, everyone. I'm Jun, Founding Engineer at Tusk. I'm excited to share about a paradigm for building the next generation of AI interfaces, the ones that put humans in the center, augmenting our capabilities and helping us be more thoughtful and creative.

  2. 0:13

    It's a collection of ideas that I've been thinking about for a while now. Though some of these concepts might be a little bit more speculative, I do hope to encourage more builders in this space to consider these patterns and principles.

  3. 0:24

    Now, it's often said that twenty-twenty-five is the year of the agents, and rightfully so. Um, from general agents performing research and browser use for you to deeply verticalized apps across all industries, AI agents are everywhere, ready to offload your tasks from you.

  4. 0:38

    And as agent-based tooling and protocols get more and more mature and sophisticated, it's no doubt that large chunks of knowledge work will be automated away in time to come.

  5. 0:47

    A lot of agents are focused on automating discrete tasks and for good reason. Well, it's easier to quantify the unit of work performed and sell the promise of eradicating tedious and boring work that people don't like doing.

  6. 0:59

    It's also easier to benchmark the completion of these tasks quick, and quickly compare one system against another.

  7. 1:05

    But it's also not difficult to spot the potential drawbacks of such a future if it's not carefully managed. Firstly, there's a notion that, you know, over-reliance on automating work away breeds general laziness and atrophy of skills.

  8. 1:18

    I'm sure most of you are discerning users, but when you write code in an app without thoughtful review or at least bother to sufficiently understand its inner workings, how are you maintaining this as skills?

  9. 1:28

    H-are you sure you know what you're bu- actually building? Many high-judgment domains like coding and design still require tight human supervision, relying on human experience and taste for approval.

  10. 1:39

    A lot of these are also like high context tasks, where it's often difficult to just upload perfect context and encapsulate them in prompts or for accurate judgment, since a lot of them, a lot of these like live in the minds of experienced professionals anyway.

  11. 1:54

    So the main thesis of this talk is this. Instead of getting humans to accommodate to AI systems, uh, attempting to automate complex tasks and doing so sub-optimally, why not spend that compute just helping humans produce high-quality work in the first place?

  12. 2:07

    So in this talk, I'd like to introduce some ideas for augmentation-based UX. We look at interaction patterns for how AI can help users review blind spots, spark creativity, and amplify thoughtful decision-making.

  13. 2:20

    Some principles for designing AI products to emphasize and grow human capabilities, um, and trustworthy human-AI partnerships. Let me make this concrete with a simple comparison. Um, the automation approach to AI emails might look like this, right?

  14. 2:35

    The AI writes the entire email for you and, and sends it on your behalf. Um, you're out of the loop, basically. The au- the augmentation approach is a little bit different.

  15. 2:44

    Um, AI could help you, uh, brainstorm key points, for example, suggest alternative phrasings, um, check your tone. Maybe it says, "Hey, this might come across as a bit harsh.

  16. 2:54

    Do you want to soften it based on your past emails with this person or usual writing style?" And then you review and hit send. Same with coding, right? With automation, AI writes the code, creates a pull request based on a Slack message that you have assigned to it.

  17. 3:07

    Augmentation could be something like AI reviewing your pull request and says, "You might have missed this edge case. This pattern you're using here could cause issues on a high load."

  18. 3:17

    Now, the difference is that in augmentation, you're still in the driver's seat, but you have a thinking partner or co-pilot who can see things that you might miss.

  19. 3:26

    And this cap-- And this table captures the, the fundamental shift in this mindset. In a nutshell, many differences, uh, arise based on a shift of responsibility of the task itself and the relationship-- and our relationship with the AI system that helps us with these tasks.

  20. 3:39

    It's almost like working with an offshore contractor versus a new team member that we grow together with. And if you're interested in knowing more about this in further detail, I wrote about it in my blog post linked below.

  21. 3:51

    Now, let's get to the meat, the three core interaction patterns. I want to start with blind spot detection because it's the most immediately compelling. Now, think about it. We all have blind spots, patterns that we can't see in our own thinking.

  22. 4:03

    Uh, the question for AI isn't what you do wrong, but what didn't you consider as you're working on this task?

  23. 4:09

    This could be temporal blind spots, like noticing you always make poor decisions when tired on a Friday afternoons, um, or social blind spots, flag-flagging when your technical feedback might come across as personal criticism.

  24. 4:21

    Um, the key challenge is managing that signal-to-noise ratio and nudging someone or challenging their thinking without making them feel defensive. Um, ideally, the AI should be designed in a way that reviews something at the right time, uh, when a unit of work, um, can be assumed to be ready.

  25. 4:36

    Here's how we implemented this at Tusk. Now, Tusk is an AI testing platform that finds edge cases and bugs based on your pull requests. When you commit your code changes, instead of just surfacing potential bugs, we create unit tests and actually validate them, execute them against your, your code-based test environment, and surface to you verified issues that

  26. 4:52

    we can prove will cause problems in the future. You can then choose whether to commit these tests alongside other passing ones into your pull request so that, you know, there's, uh, extra coverage against future regressions.

  27. 5:04

    One thing we try to help make reviewing these tests easier is also to surface any assumptions that Tusk is making, be it from a business or engineering standpoint, and also outline potential fixes.

  28. 5:15

    Um, users can provide feedback by clicking thumbs up or thumbs down or explain why it's something worth considering or not. So that Tusk learns from your, from, from your review of its assumptions.

  29. 5:26

    I also like to call this systematic pessimism. We're using AI to systematically look through, um, every symbol that has been changed, finding what could go wrong, um, consider second-order effects in the call stack, even though this is something very tedious for humans to manually perform effectively, um, especially in larger, more complex code changes.

  30. 5:44

    With this pattern, we have helped, uh, enterprise and growth stage companies like Deep Learning AI and TeamVpay catch verified bugs in forty-three percent of pull requests and add almost a thousand new tests in two months.

  31. 5:56

    In the blind spot detection pattern, not all suggestions are created equal.

  32. 6:00

    I've been thinking about how we can manage, uh, noise with thoughtful UX. Uh, one mental model is the Novelty-criticality framework. And let's again consider the code review scenario. High novelty, high criticality, these are critical discoveries.

  33. 6:14

    Things like race conditions that you, that you have never encountered before, accidentally exposing customer data. These deserve to interrupt you. Novelty, low criticality. These are learning moments. Suggestions like alternative approaches, new language features, recognizing ineffective patterns.

  34. 6:29

    You might wanna present this gently as maybe as expendable suggestions. Low novelty, high criticality. These are more of essential reminders. Uh, things like column box, standard security checks, performance issues might help to give clear warnings and have a little bit more flexibility when it comes to interruption.

  35. 6:47

    But we don't have to overexplain since users probably already know the concept. Low novelty, low criticality. These are more matters of polish and preference. Code formatting, minor optimizations, and things of that nature.

  36. 6:58

    We want to batch these, make them optional. The magic is in the prioritization because people tend to only process three or more meaningful suggestions per review session. This framework helps to spend the attention budget wisely.

  37. 7:09

    The second pattern is cognitive partnership, moving from stateless answering machines to systems that adapt to your mental models, right? This means building a theory of mind about users, not just knowing what they want, but how they think.

  38. 7:20

    Do they learn through analogies? Do they prefer visual explanations? Do they prefer to sleep on it or prefer, like, rapid iteration?

  39. 7:29

    Um, imagine a code editor that learns your refactoring patterns and proactively suggests similar improvements in new contexts. Or, or a research assistant that understands whether you synthesize information chronologically or thematically.

  40. 7:42

    The challenge here is building this personalization without being creepy. Um, users need to feel understood, but not surveyed.

  41. 7:50

    And the third pattern, proactive guidance, is probably the hardest to get right. Um, the challenge isn't knowing what to suggest, but when. Um, and great proactive guidance feels like serendipity, not interruption.

  42. 8:01

    It's like having a calendar app that suggests meeting times based on your energy patterns and not just availability, or a writing tool that notices when you are stuck and suggests taking a break rather than pushing through.

  43. 8:13

    And the key is finding that Goldilocks zone, right? We don't wanna be too reactive. We also don't wanna be too overwhelming, just right. Now let's shift gears into principles for designing auto-- augmentative AI, because without trust, none of this matters.

  44. 8:26

    How-- So how do we build that trust in these augmentation systems? Trust becomes, uh, particularly crucial in augmenta-- uh, augmentation interfaces because the relationship between human and AI is more collaborative than transactional, right?

  45. 8:37

    Again, think about how two humans begin to trust each other. In augmentation paradigm, especially cognitive partnerships, it's likely that we see human and AI interact more like human-to-human interaction.

  46. 8:45

    I believe trust needs to be progressive, contextual, and bidirectional. Progressive in a sense that it's easier to build trust with low-stake suggestions before moving to high-impact decisions. Um, let a system prove itself, um, on small things first.

  47. 8:59

    Trust is also contextual, um, because we trust people differently across different domains and for different situations. So the same should apply to AI. AI might be brilliant at code reviews, but terrible at design feedback, or it might not have the right or sufficient context to make certain decisions, so let's make that transparent.

  48. 9:15

    And bidirectional because true partnership means both parties adapt. The AI learns your preferences while you learn its capabilities. It should adjust its behavior based on how much you trust it in different scenarios.

  49. 9:27

    For AI to augment us, it implies facilitating some sort of skill growth. Unlike automation interfaces that stay static, augmentative AI that helps you learn should also evolve with you.

  50. 9:36

    This means some sort of skill visualization, showing people their growth, their growing expertise over time, and graduated complexity, right? Like unlocking or adapting features as competence increases or shifting explanation patterns based on a user's understanding over time.

  51. 9:51

    The goal is generating skill enhancement, not just the illusion of it. Um, users should feel themselves getting better, um, at their core work and derive joy from self-improvement, even though it may be hard at first, not just more, being more dependent on AI.

  52. 10:06

    Um, and a little note about, um, product metrics. If you truly care about your users, you should track how they're growing as they use your product beyond traditional engagement or usage metrics, even though they are important as well.

  53. 10:18

    Um, I think a lot of learning apps, for example, focus on user retention and engagement, but are users actually improving themselves and getting more and more capable in real-life situations?

  54. 10:27

    It's hard to say. So why does this matter? Beyond a normative argument that AI should serve to make people better, we have three main reasons. First, building an emotional connection.

  55. 10:37

    AI products that make an effort to learn from users and fulfill intellectual needs build stickier relationships. ChatGPT's memory feature is a great example. People love feeling understood across multiple chat sessions.

  56. 10:47

    Second, long-term value. Buyers increasingly care, uh, not just about productivity, but capability building. Um, can this tool make my team not just faster but better? Um, thirdly, as consumers, we should be more intentional about how we learn alongside these AI tools.

  57. 11:02

    We are investing our precious time using them, so let's make sure we are growing, not just grinding.

  58. 11:08

    As we come to the end of this talk, I'd just like to summarize what we have walked through so far. Um, technological revolutions have seemed to always been focused on efficiency.

  59. 11:17

    For AI, though, um, I'm particularly excited because never had humanity advanced a piece of technology to a point where it can help us think better, amplify our intuition, taste, and creativity.

  60. 11:29

    This may take the form of blind spot detection, cognitive partnerships, and proactive guidance. And to get there, we need to invest in better UX that enable high trust, thoughtful agency, and learn alongside users.

  61. 11:40

    I think the most profound technologies don't just replace humans, they unlock what makes us uniquely human. The next decade won't be about AI doing our work, but AI helping us think in ways that we couldn't before.

  62. 11:51

    What's transformative isn't just making us more productive, it's for making us more thoughtful and more aware of our cognitive patterns, like mirrors for our minds, showing us blind spots and suggesting perspectives that we habitually miss.

  63. 12:03

    And no doubt, uh, we are still at the starting line of understanding how to build these systems. But the core insight that technology should enhance rather than replace human capability will remain true even as our understanding evolves.

  64. 12:14

    And the future belongs to interfaces that help us, uh, become more fully human, not less. With that, thank you for listening, and let's stay connected to continue our conversation.