Structuring a modern AI team

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.