← All AI Engineer talks

AI Engineer World's Fair 2025

Structuring a modern AI team

Denys Linkov· Head of ML, Wisedocs17:40

Read the talk

Structuring a modern AI team

Start with the work your company cannot yet do, then balance generalists, specialists, domain expertise and human accountability around that constraint.

From a talk by Denys Linkov

What does AI-first change about hiring?

What should an AI-first company hire people to do? Denys Linkov, who leads machine learning at Wisedocs, points to announcements from Shopify, Duolingo and Zapier. Alongside this movement comes a new expectation: before hiring someone, explain why an AI agent or another AI tool cannot do the work.

Editor’s note: These companies’ policies are not identical. Zapier’s published announcement establishes AI fluency expectations for hires, not that specific headcount test.

Slide titled “New Expectations” displaying the quote “Explain why you can’t use AI before hiring.”
New expectations: “Explain why you can’t use AI before hiring.”

Claims about how much code AI writes intensify that pressure, especially when presented as evidence that software engineers will become obsolete. But code production alone does not tell a manager which capabilities a business needs. The practical questions are how to structure the team, where generalists can contribute, and when another person is necessary.

0:150:23
Suggest correction

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

0:15 · section reference included

Start with the company’s missing capability

A technology company sells technology as its core value proposition. A vertical provider, such as Palantir or Wisedocs, applies technology within a particular domain or service. A technology-enabled business uses technology to improve another core product: banks, retailers and many small or medium businesses fit here. These positions create different starting conditions for an AI team.

Company typeTypical constraint in Linkov’s framingWhat it may buy
Technology companyMissing domain knowledge or misalignment between technology and the businessExpertise or labeled data
Vertical providerMay possess both technical and domain capabilities—or lack bothDepends on which capabilities are present
Technology-enabled businessTechnical execution, because technology is not its core offeringA service provider or a complete technology solution

These are broad tendencies, not fixed rules. Their usefulness is in locating the missing capability: a company with strong engineering but weak domain understanding faces a different hiring problem from a domain business that cannot deliver the technology.

1:131:21
Suggest correction

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

1:13 · section reference included

Available technology still has to be adopted

Linkov’s starting view is that 90% of the technology needed to solve humanity’s problems already exists; he presents this as a conviction, not a measured result. That perspective shifts attention from inventing another capability to understanding why existing capabilities have not become useful in practice.

He describes a fax market with billions of dollars in spending that is still growing. He cites contactless payments as 3% of U.S. payments in 2017, while acknowledging later growth and the continued use of checks. Both examples illustrate the persistence of established ways of working after alternatives become available.

Editor’s note: The Boston Fed’s historical contactless-payment report reports a different measure—Visa’s U.S. payment transactions—so its figure cannot be substituted for a share of all U.S. payments.

He describes medical-record digitization as arriving roughly 40 years after the introduction of personal computing and the internet, while acknowledging that adoption has since increased. This is an approximate adoption illustration, not a precisely defined historical interval. Across these examples, the relevant distinction is between having technology available and making it part of everyday work.

Slide combining a $6.5 billion fax-services market headline with text about U.S. contactless card transactions and hospitals using digital records.
Adoption examples: fax services, contactless payments, and hospital digital records.

Team design should follow the obstacle to successful use. Ask whether technology is actually limiting progress. If the obstacle lies in applying it, the team needs the capabilities to change workflows and make the technology useful. That does not mean technical limitations never matter; it means they should be identified rather than assumed.

2:362:45
Suggest correction

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

2:36 · section reference included

Match research expertise to the whole product problem

The arrival of ChatGPT prompted many teams to seek an AI engineer or researcher immediately. But dedicated model research becomes useful at a particular scale or when a specialized requirement demands it. Pretraining, and even substantial fine-tuning, need not be the first route to value; considerable transformation work may come first. For model providers such as OpenAI, Anthropic and Google, the calculation differs: leading technical capability is essential because the model itself is the product.

Linkov turns that distinction into Ampere’s wager, a graphics-architecture joke built on Pascal’s wager: would you trade your existing team for five researchers from the top AI labs? The researchers bring exceptional model expertise. The existing team brings knowledge of the domain and experience working in it. The thought experiment asks which capability would actually improve the company’s prospects.

Consider the work an AI team must cover:

  • Define the opportunity: Identify use cases, integrate with existing products rather than assuming a greenfield project, measure return on investment and find suitable data.
  • Make the product useful: Test and refine workflows, build the necessary interfaces, sell the product and give customers a reason to care.

These responsibilities normally exceed one person or research role. Hiring a researcher does not automatically supply all the capabilities needed to turn a model into a business.

A comprehensive team also needs working relationships beyond its own boundaries. If the AI group owns only an isolated deployment or subsystem, the product can reproduce those organizational divisions as awkward behavior. The unit of success is the complete product, not the portion assigned to one team.

The hiring decision therefore starts with a bottleneck: feature delivery, user acquisition, retention, monetization, scalability, reliability or observability. These are different problems and may require different people. Prioritize the constraint before choosing the role. The right composition follows from what is preventing this company from succeeding.

3:534:01
Suggest correction

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

3:53 · section reference included

The 2021 team: generalists supported by a platform

In 2021, Linkov built his first machine-learning team around generalists supported by automation. The setting was a conversational AI platform, which he also describes as an AI agent-building platform. His initial mandate was simply to add machine learning—or AI. Working with business teams and leadership converted that vague ambition into an engineering problem. The resulting requirements were to support hundreds of thousands of concurrent models across multiple domains, keep costs low, and provide real-time training and serving. These were targets for the platform, not reported benchmark results.

The team built a custom MLOps platform for deployments, primarily fine-tuned encoder models and offered retrieval-augmented generation, or RAG, as a service. The team owned six microservices end to end. Its responsibility therefore extended beyond model development into operating the services that delivered the capability.

Hiring balanced three dimensions: model training, model serving and business acumen. Maximizing all three in every hire would have exceeded the available budget, so Linkov set thresholds based on the work.

DimensionRequired capability
Model trainingRoughly the upper half of the skill spectrum: understand model architectures, fine-tune encoders and handle data engineering with Hugging Face. Training GPT-3 was beyond the requirement.
Model servingLinkov used his cloud-engineering background to build the initial platform. Later hires needed to use its abstractions and understand trade-offs, without mastering Kubernetes or every training and serving internal.
Business acumenEngineers needed to participate in customer calls. They did not need to become dedicated sales representatives, but could not treat customer contact as outside their job.

The platform changed what later hires needed to know. Infrastructure expertise went into the abstractions; the broader team could then use those abstractions while staying close to customers and delivery.

6:476:51
Suggest correction

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

6:47 · section reference included

The 2024 team: mature tools change the skill budget

When Linkov built another team in 2024, the approach remained similar, but the available tools had changed. During the earlier platform work, many offerings lacked capabilities his use case needed, including shadow deployments and A/B testing. By the later effort, open-source tooling had advanced. The skills also did not have to reside in one exceptional person: complementary people could supply them, provided the team could work together.

AreaWhat mattered in the later team
Model workCommercial APIs, prompt tuning and fine-tuning commercial models became important. The scope included both encoder and decoder models, with their different nuances.
ServingAn open-source offering removed the need to build another serving platform from scratch.
Domain knowledgeMedical-record processing required a more specific understanding of the domain.

Better tooling reduced one category of custom engineering while the model and domain requirements changed. The hiring profile had to move with those requirements rather than repeat the earlier team unchanged.

Once the required capabilities are explicit, the team can set a sufficient threshold in each area and balance those thresholds against its budget. The objective is a team that can perform the work, not the highest possible score on every individual skill.

9:189:36
Suggest correction

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

9:18 · section reference included

Organize feedback loops, then specialize

For an established team, the question becomes how to reorganize, reskill or upskill the people already present. Linkov separates the work into inner and outer loops. The inner loop contains activities people must accomplish together every day. The outer loop supplies broader activities and expertise that differentiate the company, even when they do not require constant interaction.

In his current team, the inner loop includes model training, prompting, product requirements, model serving, domain experts and the ability to build business cases. The outer loop adds further differentiating expertise. This is not a division between technical people on the inside and domain people on the outside: both kinds of knowledge can belong in the daily collaboration. Their placement depends on the company’s priorities.

The quality of those loops matters as much as the list of roles. A weak technical loop makes execution difficult. A weak domain loop makes product-market fit difficult. Team design therefore includes understanding how feedback travels and how people collaborate, not just ensuring that every specialty appears somewhere on an organization chart.

The balance between generalists and specialists also changes with the maturity of the AI effort. Generalists help a team find fit and make initial progress. Specialists become useful when the team exhausts its knowledge and needs deeper expertise in areas such as training or serving. Linkov uses an extra 5% of performance as an illustration of that later optimization work, not as a measured gain.

Chart titled “Hiring Should Reflect the Stage of the AI Strategy,” with Maturity and Stage axes, generalist and specialist regions, and labels for AI as an API, Data Loops, Training Layer, and Win on Modeling.
Hiring generalists and specialists at different stages of an AI strategy.

Generalists remain valuable because they adapt and contribute beyond writing code. During much of a company’s transformation, that breadth can meet the actual requirement. Specialization becomes a response to a constraint that broad competence can no longer resolve.

10:4410:53
Suggest correction

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

10:44 · section reference included

Upskilling changes how the work gets done

The upskilling priorities are practical: learn to build, develop domain expertise and work directly with people. Each changes a feedback loop.

  • Learn to build: Replace static product requirements with functional prototypes that make behavior and edge cases tangible. This reduces the gap between what a product manager intends and what an engineer understands.
  • Develop domain expertise: Domain experts should do more than provide occasional feedback. They should define use cases, write evaluations and develop enough literacy to work directly with LLMs.
  • Work with people: Engineers should join customer calls so customer needs reach the people implementing the system. Difficulty talking to customers is a development opportunity. The team also still needs someone to sell the product.

These practices bring requirements, evaluation and customer understanding closer to the work of building.

Linkov’s team holds a 30-minute learning session every week, led by him or another team member on a new topic tied to team and company priorities. Learning is a recurring part of the team’s work rather than an occasional response to falling behind. He considers the consequences of not maintaining that cadence greater than the effort it requires.

12:4612:55
Suggest correction

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

12:46 · section reference included

Hire for context, accountability and the actual job

People are hired to hold context and act on it. Too few people means important details get dropped and priorities go unexecuted. Large-context AI agents may help with both functions, but someone still needs enough expertise to verify that their understanding and execution are correct. That expertise itself depends on retaining context. Humans also remain accountable for the systems they build.

The hiring budget follows from the existing team and its missing capabilities. Linkov contrasts the expense of a top researcher with the lower cost of a generalist AI engineer. Neither is automatically the right purchase: the relevant question is which capability the team needs enough to justify its cost.

The same reasoning applies to claims that companies should stop hiring junior engineers and use agents instead. Linkov points to YC’s AI Startup School, announced for 2,000 students and recent graduates in San Francisco roughly two weeks after the talk. He treats that educational investment as a counterpoint to dismissing entry-level talent, not as evidence of actual attendance or subsequent hiring outcomes. A trend deserves examination before it becomes a staffing rule.

New graduates, people with decades of experience and existing employees who can retrain all belong in the decision. Choose among them according to the work and the team composition. Then assess that work in interviews. Linkov objects to LeetCode exercises unrelated to the job, and argues that LLMs’ ability to solve them further weakens their usefulness as an assessment. The interview should test the capability the person is being hired to supply.

14:0614:17
Suggest correction

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

14:06 · section reference included

Resolve the trade for your domain

Returning to Ampere’s wager makes the choice concrete: five researchers from top labs, or a team assembled for the domain? The slide puts a hypothetical $5M budget behind Ampere’s wager. One side combines nurses, army veterans and insurance professionals with a designer, a product manager, and backend, frontend and ML engineers. The other lists researchers associated with leading AI labs. For Wisedocs, Linkov prefers the team with domain expertise, the ability to sell work and empathy for customers. His answer follows from that company’s domain and structure; it is not a universal rejection of research talent.

Slide asking “You have a $5M budget, who’s on your team?” The left lists nurses, army vets, insurance pros, a designer, a PM, backend, frontend, and ML engineers. The right lists two Open AI entries, two Deepmind entries, and one Anthropic entry.
A $5M team choice: domain and engineering roles alongside AI lab names.

He briefly extends the joke to Blackwell’s wager: would you choose GPUs or a team? That question remains open; the talk does not develop a compute-versus-headcount analysis.

The starting decision is what team the company needs to succeed. Cross-functional teams can remain effective as responsibilities overlap more and more people work directly with AI systems to contribute to the product. Maintaining that effectiveness requires continued learning as AI capabilities and evaluation practices change. Staying current needs to be part of the team’s culture.

16:1216:23
Suggest correction

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

16:12 · section reference included

Resources

From the talk

Updates since the talk

Read the complete timestamped transcript
  1. 0:00

    [upbeat music] All right.

  2. 0:15

    Thanks, everybody, for joining today. My name is Denys Linkov. I lead the machine learning team at Wisedocs, and I'll be talking about hiring a modern AI team.

  3. 0:23

    So who's heard this message before? We are now an AI-first company. We've seen companies like Shopify, Duolingo, Zapier all make these announcements saying that they're AI-first companies.

  4. 0:35

    And they're saying that there are new expectations that before you hire a person, you need to make the, the claim that you can't hire an AI agent or use AI.

  5. 0:44

    We're now seeing big tech companies and many companies in general sharing how much code is being written by AI systems and how this is going to lead to the extinction of the software engineer.

  6. 0:55

    So now, if you're in the position to hire people, you'll ask the question, now what?

  7. 1:00

    So I'm gonna talk about three main themes today. The first one is the anatomy of an AI team, the second is the evolution of a generalist, and the third is the question of hiring.

  8. 1:10

    So let's start off with the anatomy of a team.

  9. 1:13

    So there is a spectrum of different companies, and this is where we should start. We have technology companies where technology is the core value proposition that is being offered.

  10. 1:21

    We know big tech companies, we know many startups. There's also verticalized solutions or services companies such as Palantir or the company I work at, Wisedocs. And there's also tech-enabled companies where the core product is not technology, but it is something that benefits dramatically from, from good tech.

  11. 1:36

    You can think about banks, retailers, small-medium businesses.

  12. 1:40

    So who here is in each group? Who here is at a tech company?

  13. 1:44

    Who here is at a verticalized or services company? Who here is in tech-enabled? Okay. Pretty good mix.

  14. 1:52

    Now, each of these different companies have different challenges. Typically in a technology company where we've seen blunders is the lack of domain knowledge when launching a product, there's usually some kind of business misalignment with technology.

  15. 2:03

    In the middle, either everything goes right or everything goes awfully poorly. And on the tech-enabled side, there's usually some kinda tech challenge, right? Because tech is not your, your core value proposition.

  16. 2:14

    So you make different decisions based on this, right? You typically buy data or buy expertise if you're a tech company, right? You go to a vendor and say, "Give me labeled data."

  17. 2:23

    In the middle, you either have everything or you have nothing. Uh, and from a tech-enabled company, you usually buy technology either through a service provider or, uh, a true end-to-end solution.

  18. 2:36

    Now, I bring this up because every company, every organization, and every person has a different perspective on the role of technology solving our world's problems. This is my stance.

  19. 2:45

    I think we have ninety percent of the technology to solve the problems of humanity. Now, this might be a controversial perspective, but I'll show you why.

  20. 2:54

    The fax market still exists. Billions of dollars are spent on faxes, and the market is growing. [audience chuckling]

  21. 3:06

    In 2017, only three percent of payments in the US were contactless. That number is n- now higher, but we're still paying in archaic ways. Checks are still a massive part of the market.

  22. 3:18

    And it took forty years after the introduction of personal computing of the Internet for medical systems and electronic medical records to become digital. This number is much higher now, but it takes time for technology to be adopted.

  23. 3:31

    And many of you might have seen this in your industry and your job as well, that technology is not the thing that's stopping you from achieving success.

  24. 3:38

    So this is the core question. Is technology the limitation of our success?

  25. 3:45

    And it's not about technology, it's how we use technology, and the way you build your team should reflect this by understanding the problems that you have.

  26. 3:53

    So going to this question of do you need to hire an AI researcher? A lot of times when ChatGPT was coming out, every team is like, "I need an AI engineer.

  27. 4:01

    I need an AI researcher," and it's not always smart to do so, right? Up until you hit a certain scale or a certain need, a specialty, it does not make sense to hire an AI researcher to work on models.

  28. 4:11

    Pre-training models, even fine-tuning models of a certain capacity is not necessarily the first thing that you need to achieve the value that you need to get. There's a lot of transformation work that, that goes in before that.

  29. 4:23

    Now, in certain domains, the best tech is essential, right? So if you're working at OpenAI or a model provider, Anthropic, Google, or some of the startups, you want the best team who's working on that because that is a product, as we covered.

  30. 4:36

    So here I'll, I'll propose a wager for you. Are people here familiar with Pascal's wager philosophy? I'll give you the successor of that, Ampere's wager, if you're fil- familiar with graphics card architectures.

  31. 4:48

    Here's your trade. You trade your team for five researchers from the top labs, and maybe you need to throw in some cash and first-round picks for that as well.

  32. 4:57

    But do you make this trade? Do you trade your team that has domain knowledge, has worked in the area for five AI researchers? And I want you to think about that.

  33. 5:07

    So we go back to the question of what does an AI team need to do?

  34. 5:13

    There's a lot of stuff, right? We start off with defining use cases. We wanna go through and integrate with products, right? We're not doing greenfield everywhere. We wanna measure ROI, find the right data.

  35. 5:23

    We wanna test and refine workflows, build the interfaces we need for success, sell this product, and make our customers care.

  36. 5:32

    And it's not one person who does this job. You can't just say, "AI researchers, go make me ten million dollars from this product," unless a very specific niche.

  37. 5:43

    So this means your success is not one job, unless you're a founder, but we'll skip that.

  38. 5:49

    So the goal here is that you need to have a comprehensive AI team, and you need to figure out how are you gonna structure that.

  39. 5:56

    And the thing that we need to remember is that companies aren't just one team. It's not just my AI team owns this small segment, this deployment or whatever. Otherwise, you ship your org chart and you get some weird product behaviors.

  40. 6:11

    So identify to yourself what is your bottleneck? What is stopping you from achieving success?

  41. 6:16

    Is it shipping features? Is it acquiring users? Is it retaining users? Are you monetizing correctly? Are there scalability issues? Are there reliability and observability issues, right? All of us have probably run into these things as we were deploying AI products, so we need to make sure we can prioritize all these things and hire accordingly.

  42. 6:37

    And these are all questions that you need to answer when building an AI team.

  43. 6:42

    So key takeaway here is what kind of team do you need? And only you know that answer.

  44. 6:47

    Let's talk about generalists and why I think they're important.

  45. 6:51

    So in 2021, I was building a first machine learning team, and I adopted an approach where we hired generalists. We supported them by automation across the board.

  46. 7:02

    So at the time, I was hired to a conversational AI company working on a platform. Sorry, let me rephrase that. AI agent building platform. Just wanted to make sure you guys understood what that meant.

  47. 7:13

    And I was hired with the mandate of we want ML. That was my job description.

  48. 7:19

    Change that. We want AI. So after working with the business teams and leadership team, the-- this was the, the final set of goals we set. We wanna serve hundreds of thousands of concurrent models.

  49. 7:29

    It needs to be multi-domain. It has to be low cost, and we wanna support real-time training and serving. Those are some tough goals.

  50. 7:36

    So this is what we did. Uh, we wrote a, a custom MLOps platform for deployments to, to match our requirements. We mainly fine-tuned encoder models. We built RAG as a service, and as a team, we own six microservices end to end.

  51. 7:51

    So the three areas I focused on building the team was model training, model serving, and business acumen. Now, you might say, "I want top grades in all these things," but that's a lot of money, right?

  52. 8:03

    And as a, as a team leader, as somebody who manages the budget, you don't have infinite money. So we have to pick along this axis where do we want each of these skills to lie.

  53. 8:13

    For model training, we, we don't want somebody at the very bottom, but we don't need somebody who can train GPT-3. And w- basically, we went across and said, "Okay, what are the key requirements?"

  54. 8:23

    For model training, we said somebody in the, the upper half who knows general architectures of models, uh, can do encoder fine-tuning, does some data engineering using Hugging Face is okay.

  55. 8:33

    That was the bar we set. On the model serving perspective, on the first round, I was the first engineer at the company. I spent a lot of time on building the ML platform, but that was something I was comfortable with coming from a cloud engineering background.

  56. 8:45

    Now, after that, there was enough abstraction built in that we didn't need somebody who knew the intricacies of how Kubernetes works and how we did serving or training, but the capability to use these abstractions and understand the trade-offs that were being made.

  57. 9:00

    And what I did focus on is the ability of our engineers to get on calls with customers, right? We didn't need a business development rep who would just call-- cold call people for fun, uh, but we need engineers who didn't say, "My job is coding in a basement."

  58. 9:13

    Right? So w- we went through and understood these trade-offs that, that needed to happen.

  59. 9:18

    Now, in 2024, I was building another team, uh, the new organization that I joined, and similar approach, but open source had advanced. When I was building the original ML platform, we didn't have things like shadow deployments or A/B testing in a lot of the platforms that existed, and we had a specific use case.

  60. 9:36

    Now, since then, what's important to recognize is that all these skills that you're prioritizing don't necessarily need to be one person. They can be multiple people. You just have to find a way to make the team work.

  61. 9:47

    So once again, we, we set similar, uh, structures. And in this case, because open source ha- had advanced, uh, in a number of different ways and commercial models had advanced, some of the things shifted around.

  62. 10:00

    On the, on the training side, using commercial APIs and, and prompt tuning and model fine-tuning commercial models became important, but we also expanded our scope. We're now using decoder and encoder models, which each have their nuances.

  63. 10:13

    Uh, on the serving side, uh, because we were using a open source offering, we didn't need to write our own platform, which was nice. And on the domain side, again, because of the nature of our business of doing medical record processing, there's a whole nuance of what that domain knowledge was.

  64. 10:29

    So that bar increased in a different way.

  65. 10:33

    So now that we know what kinda skills we need for our team, we can identify this threshold and balance the budget, right? We can't just ask for infinite money unless you're a specific subset of companies.

  66. 10:44

    You might have this question, what if I already have a team? I have forty people, a hundred people. What do I do? How do I reskill, upskill? How do I manage this team?

  67. 10:53

    So we need to figure out what the goal of the team is, as we were referring to, and I typically like to think about it through inner and outer loops.

  68. 11:00

    So inner loops are the daily activities that the team needs to accomplish together every day, uh, to be successful, and the outer loop is the broader set of activities that will set you apart.

  69. 11:10

    And you might not need constant interaction with that, but they're really important.

  70. 11:14

    So in my current team, this is how we typically structure it. Uh, so we'd have model training, prompting, product requirements, model serving, some domain experts, and the capability to build business cases as the core nucleus of our team.

  71. 11:27

    And again, as you're building your team and your function within your domain, these will be different. But this is a framework to understand what are my priorities. And we need to have the expertise in our outer loop as well to, to further differentiate our company and our team.

  72. 11:43

    If you have a weak technical loop on the inside, you're gonna struggle with the technical execution. If you have a weak domain loop, you're not gonna find product market fit.

  73. 11:51

    So you need to make sure that you really understand those feedback loops and the collaboration loops that exist within your company.

  74. 11:59

    Now, depending where you are, uh, at the stage of your AI strategy, uh, all of us fall on a different spectrum. You win with different types of people. You win with generalists at the beginning when you're trying to find that fit, trying to make that basic progress until you get to the point where you exhaust the knowledge,

  75. 12:14

    and you need to move into a more specialist model. So once again, on the general side, most companies, as they're going through transformation, fall in that category. Once you get to a really good stage for your model training, serving, and so forth, you need specialists to push the extra five percent of performance there.

  76. 12:33

    So generally, my perspective is generalists are good because they're adaptable, and in most cases, you're, you're good enough with a general, uh... a generalist who can do many different things beyond just writing code.

  77. 12:46

    Let's talk about upskilling, reskilling, and hiring. So I think there are three main things as we continue go- to go through this AI wave that you need to do.

  78. 12:55

    People need to learn to build, you need to become a domain expert, and you need to be human facing. So we've talked about vibe coding and prototyping. We should go from static product requirements to functional prototypes that take those details and, and elicit them, right?

  79. 13:09

    We never want to have those conversations again, those dreaded conversations with PMs and engineers being like, "That wasn't in the requirements," or, "That was an ed- an edge case," right?

  80. 13:18

    We wanna shorten that feedback loop. We wanna make sure that people are writing evaluations, that domain experts aren't just providing input and feedback, that they're the ones writing the use cases, defining them, and having the literacy to, to work with LLMs directly.

  81. 13:32

    We need to make sure that engineers are on customer calls, so we shorten those feedback loops. If your engineers say, "Sorry, I can't talk to a customer," um, that's a learning opportunity.

  82. 13:43

    Finally, you need somebody to sell your product.

  83. 13:46

    Now, the way my team works is that we have weekly cadences to learn. Every week, we have a new topic, either with myself or other members of the team, that is brought to the table for 30 minutes, and we learn the underlying key priorities of our team and our company, and we make sure that every week we're

  84. 14:00

    upskilling ourselves. If this sounds intense, the consequences of not doing this are much higher.

  85. 14:06

    Let's close out on hiring. When do you need to hire? I believe that people need to be hired for two main reasons. One is to hold context, and the other is to act on context.

  86. 14:17

    So it's important that if you have too few people on your team, things are getting dropped and you can't execute on your priorities. You might ask the question, can't AI agents with a massive context window do this?

  87. 14:28

    Maybe to some extent, but you need expertise to be able to verify that this context and this execution is correct, and to have expertise, you need to have context.

  88. 14:38

    And finally, humans should be accountable for the systems that we build, uh, as we have in the old IBM quote, right? We can't hold a, a machine accountable.

  89. 14:47

    So who do you, who do you need to hire?

  90. 14:50

    So we're hiring on a budget, and going back to everything that we've talked about today, you need to know your team composition and the needs that you have to set up this budget, right?

  91. 14:59

    If you're trying to hire the top researcher, it's gonna be very expensive. If you're gonna hire a, a generalist AI engineer, will be quite a bit cheaper.

  92. 15:07

    Now, it's also important when you're hiring is that you're not just following trends. Who here has heard the trend that junior engineers shouldn't be hired or just using AI agents?

  93. 15:17

    Okay, some people are asleep. [laughs] Now, the counterpoint here is why is YC running a s- a school, an AI school for students and young people on AI? Two thousand people coming to, to San Francisco in two weeks.

  94. 15:33

    Why are they doing that? Certainly, entry level positions, if they were useless, they wouldn't be bringing in all, all these young people. So make sure that you verify the trends that you're seeing, and, uh, think from first principles.

  95. 15:44

    What do I need? What is the team composition? Is it new grads? Is it people with 30 years of experience? Is... What, what are the retraining opportunities, right? Uh, there's lots of ways to, to build a great team.

  96. 15:57

    Now, just repeating this because I've seen so many companies do this, ask relevant questions to the job. Stop putting people through leet codes that have nothing to do with the job, uh, and now that LLMs can solve it, it's not a great way to evaluate either.

  97. 16:12

    So we go back to Ampere's wager. Um, you have the question of, am I going to have five researchers from the top labs, or am I gonna build my team in a domain specific way?

  98. 16:23

    So for example, in my company, I'd rather have the team on the left with the domain expertise, the ability to sell work, have empathy with customers, rather than just having five researchers.

  99. 16:33

    That's the way that our domain and company are structured.

  100. 16:37

    Now, you can also answer Blackwell's wager, which is, do you want GPUs or a team? Uh, so that's a, a story for another day.

  101. 16:46

    So overall, we have three main lessons from today. The first one is it's important to start off from the beginning and say, what tea- what team do you need to win?

  102. 16:55

    Once you know that, you'll start noticing that cross-functional teams will continue to be effective, but they'll be built in different ways. The overlap will be greater, but all of us will have the opportunity to work with AI systems and contribute to our product.

  103. 17:07

    And finally, we need to continue learning. Th- this is a must, right? The world moves too quickly. We, we have Pelican evaluations now for the past six months rather than the past year, right?

  104. 17:18

    Hopefully, that's an illustration of how fast the world works as well. So keep up to date, keep moving, make it part of your culture to keep learning. So thanks everybody for joining.

  105. 17:28

    Uh, this-- these are my handles if you wanna connect afterwards, and I'll be here, uh, later on if you have any more questions. Thank you. [upbeat music]