AI is writing more code than ever. Software specialist Sonar’s 2026 State of Code Developer Survey, based on more than 1,100 professional developers, found that 72% of those who’ve tried AI coding tools now use them every day, and that today, AI now accounts for 42% of committed code, a number that’s expected to reach 65% by next year.

But while developers embrace AI-enabled coding services, many professionals are uncertain about how their businesses will cope with this influx of AI-generated code. Sonar’s research additionally discovered that 96% of developers don’t fully trust it, and only 48% always verify it before committing.

In fact, 38% of developers told the researchers that reviewing AI code requires more effort than analyzing code written by human colleagues. That’s a pattern recognized by Tim Chilton, a managing geospatial consultant at UK mapping agency Ordnance Survey (OS). “There’s truth in the headlines that AI can get carried away, and developers spend more time fixing the code that’s been created than not,” he says.

While that’s not a pattern he sees at the OS, Chilton says his organization is cautious about how developers use AI coding tools, and conversations with other digital leaders suggest a similar approach. AI-enabled coding is indeed almost ubiquitous, and it can allow developers to reach new, higher levels of productivity, but more doesn’t necessarily mean better code.

To ensure that such coding services produce business benefits, CIOs must take control of the development process. They should exploit agents carefully, set professional responsibilities, and establish guidelines, policies, and organization-wide training.

Exploiting the agents

Snowflake co-founder and president Benoît Dageville suggests there are two ways to view AI-powered coding. One is the scary way, where AI takes over your tasks without human input. The second is the efficient way, where AI helps you do the same things as before, but at a fraction of the cost. He’s a big believer in the latter, both for himself and his teams.

“The route depends on the organization; their application of AI coding depends on their priorities,” he says. “However, I hope that overall, AI will have a positive effect on humans. I’m using AI every day to code, and if I compare myself to one or two years ago versus now, I’m more efficient and productive, but I’m also writing five times more code.”

Steve Lucas, CEO of integration technology specialist Boomi, also notes the increase in output. He quotes research that suggests 4% of GitHub public commits are already being authored by Claude Code. That proportion is expected to rise to 20% of all daily commits by the end of this year. Staff at Boomi already use AI tools to produce more code.

“We’re writing 10 times the amount today than we did two years ago,” says Lucas. The increase in AI-enabled coding is so significant that he’s spoken with Boomi chief product and technology officer Ed Macosky about goals for the proportion of self-modifying code.

“I believe AI should recursively modify 80% of a software organization’s code,” Macosky says. “Infinite improvement is demanded. If AI is extraordinarily good at breaking security protocols, the only way to keep up isn’t the kind of accordion model of human code design. AI use must be linear in scale and continuous.”

Crucially, Lucas suggests using AI to check and modify that AI doesn’t mean coders go away. “In fact, I think we’ll need more engineers, not fewer,” he says. “We need these professional experts to ensure the quality of the code that’s written.”

At OS, Chilton uses Coco, Snowflake’s coding agent. The tool does as much as 90% of a development task that he would otherwise complete from scratch. “It’s taken an hour to finish, instead of weeks or never,” he says, reflecting on the power of AI coding services.

However, the tool’s influence is carefully constrained. The agent doesn’t work in isolation, and Chilton checks its output in detail. He says all organizations need a similar process and should value experienced professionals who can use AI coding tools effectively.

“If you’re giving a tool to someone who isn’t capable of checking an agent’s work, as a digital leader, you run the risk of putting too much faith in AI just running with its output,” he says. “I think that’s a big risk, so there’s still a need for experienced developers.” 

Setting clear responsibilities

While placing humans in the loop can help ensure AI-enabled code is safe and effective, developers shouldn’t be weighed down by their new management responsibilities.

Gill Haus, CIO at Chase, the consumer banking arm of JPMorgan Chase & Co, says AI coding benefits can only be realized when agents are introduced with a strong focus on automating supporting technology and processes, which reduces the need for too much human input.

“If you have 12,000 engineers, they can write 12,000 engineers’ worth of code in a day,” he says. “If those 12,000 engineers have agentic technology, they can write much more. But if you don’t have automation left to right with confidence, you create more manual processes. You can’t move as quickly since there are only so many humans you can put in the middle.”

Haus says Chase never releases services in production that don’t pass its high bar for quality and security. Strong engineering practices, pipelines, and architecture, plus a tried-and-tested approach to automation, can help ensure AI coding produces solid outputs without a burdensome amount of human intervention.

“We’re focused on effective automation so we’re able to unleash this technology safely and effectively,” he says. “This is something many other companies should be focused on if they aren’t already, because otherwise you can’t keep up with the pace of change.”

François-Xavier Pierrel, group chief data and ad tech officer at French TV network TF1, is another digital leader who says maintaining control as AI writes more code means keeping the human in the loop in a clearly defined manner. His team documents agentic processes using Atlassian project management and collaboration tools, such as Confluence.

Pierrel says policy management is crucial as the agentic transformation gathers pace.  One key step is ensuring professionals who use agents conform to internal standards. Smart businesses set policies that state clearly when staff can explore an agent, delegate work to it, or release it in production.

“We don’t have hundreds of agents deployed yet,” he says. “But the moment you reach a certain level of volume, if you don’t have compliance and policies in place, AI becomes a critical mess, and then it can be disruptive in a negative way.”

Building strong foundations

Kirsty Roth, chief operating officer at content and technology specialist Thomson Reuters, agrees digital leaders must be proactive. Her firm’s explorations with models and agents suggest that AI can help with time-intensive coding processes, such as writing. This capability means her organization carefully considers the roles people fulfil.

“In the last 12 months, we’ve put lots of thought into where we’re seeing benefits,” she says. “It’s great AI can do some of the coding work, but what does that mean for people’s jobs? We used to have thousands of engineers. Do we now need more architects or product people?”

Roth refers to security. While cyber is always a priority for Thomson Reuters, the firm dedicates significant resources to controlling threats in the AI age. Developing high-level development and security skills requires a concerted effort. Yet Roth says ensuring people have the right skills to manage AI is in many ways a familiar IT trend.

“All this effort is no different than digital, cloud, mobile, social, or other big tech trends,” she says. “They all take several years to have an impact as the initial hype comes, and then you’ve got to work through the reality and think about how you upskill people for the new world.”

Crucially, coding is no longer the sole preserve of the software developer. AI coding tools make it much easier for non-IT professionals to vibe code applications. Tal Carmi, CIO at technology specialist WalkMe, says non-developers can create useful tools. However, effective outputs rely on a careful balance between enablement and guidance.

He adds that most of these employees don’t need in-depth capabilities, such as a database or a content delivery network. Instead, non-IT staff require a dedicated place to upload their products. WalkMe’s engineering specialists ask key questions to ensure their outputs are safe, considering credentials and potentially problematic packages.

“You need to add guardrails,” he says. “A lot of the work for in-house engineers is shifting from building to testing. The people who aren’t coders don’t necessarily have security in mind.”

The key takeaway, suggests Emmanuel Frenehard, chief digital officer at biopharmaceutical giant Sanofi, is that digital leaders must help professionals feel comfortable. Successful digital leaders ensure the business generates value from agents, and his firm is helping its staff, particularly its developers, to embrace these tools.

“I genuinely worry for professionals who don’t use AI to code, because in five years, they may not have jobs,” he says. “So we’re guiding, coaching, and training them, but people must take the journey. The train has left the station. You can decide to be on it, or just look at it.”

When juniors take naive questions to an AI assistant instead of a colleague, dashboards record fewer interruptions and higher velocity. What they miss is the erosion of senior engineers’ architectural fluency, and the single point of failure that hardens until an outage forces someone to explain the system out loud.

Over the past year, I watched engineering teams celebrate a quiet drop in Slack interruptions. A junior used to ask a foundational question in a channel: why does this service retry three times instead of once? Today that junior asks an AI assistant first, messaging a senior only if the answer fails in testing. Already, 51% of developers ask generative AI for help they once asked a colleague, and 62% do so to avoid looking uninformed.

Because AI now absorbs routine implementation and debugging, it strips away the trial-and-error juniors once needed to grow into seniors.

Most writing about this shift worries about what juniors lose: less mentorship, thinner context and a shallower feel for production systems. That worry is real, but it is only half the balance sheet.

The costlier loss belongs to the senior engineer and the organization paying them to hold the architecture together. It rarely gets discussed because from the inside it looks like uninterrupted focus time.

What a naive question actually did

A junior engineer’s question was never just a request for a file path. It did three distinct jobs at once, and all three required a human on the receiving end.

First, it transferred tacit institutional memory that documentation never captured. When a senior explained why a payment service retried three times, they rarely recited the config. They narrated an incident from a year ago involving a partner’s rate limiter that never made it into a wiki. Documentation misses that history because nobody writes a design doc after the fact unless something breaks again.

Second, the question gave the senior a live audit of where the system had become needlessly opaque. A staff engineer who has owned a core service for three years goes blind to its rough edges; everything feels obvious once you know the history behind every compromise. A newcomer’s confusion is a free signal showing where the code no longer speaks for itself.

Third, and most overlooked, answering forced an articulation that kept the senior’s own mental model sharp. Explaining a state machine out loud to a colleague who asks follow-ups is a different mental discipline than silently knowing it. Teachers have known this forever: structuring knowledge for someone else exposes gaps and outdated assumptions in your own head. Seniors used to get that workout dozens of times a quarter for free.

The channel disappears without an alarm

Because those informal questions were never scheduled on a calendar or tracked in Jira, their disappearance triggers no alarm. When an AI assistant intercepts the first tier of naive questions, the senior simply gets interrupted less often. Over a single sprint, that silence feels like focus time. Over several quarters, it quietly erodes a senior engineer’s active command of the architecture they own on paper.

In practice, this decay stays hidden during routine code review because spotting a local bug on screen only requires passive recognition. Failure surfaces in postmortems when an incident demands active cross-system recall: tracing how failures cascade across service boundaries during a 2 a.m. outage. Across 211 million lines of analyzed code, structural refactoring has already collapsed from 25% of changes to under 10%, while duplicated code blocks jumped eightfold. Answering a junior’s “what happens if this service times out?” used to force seniors to trace those paths out loud every week. Without that rehearsal, the first live cross-boundary trace happens during an outage.

Why velocity dashboards hide the risk

For a CIO or VP of Engineering, this creates a treacherous blind spot. Standard engineering health metrics do not merely miss this erosion; they actively misread it as progress.

When juniors turn to AI assistants instead of pinging seniors, short-term output metrics look healthier. Pull request cycle times tighten, ticket velocity ticks upward and seniors report fewer context switches on surveys. On throughput dashboards, the organization appears to scale effortlessly.

Underneath those green indicators, three structural risks accumulate.

• Shared ownership collapses into a single point of failure. When architectural rationale stops circulating verbally, it stays trapped inside the heads of the veterans who wrote the code. If one leaves, what looked like shared ownership turns out to be unshared memory.
• Outage recovery times creep upward on complex incidents. Routine bugs get fixed faster with AI, but cross-boundary outages take longer. Every 25% increase in AI adoption correlates with a 7.2% drop in delivery stability, including mean time to recovery (the time required to restore service during an outage). When AI-generated changes hit production without shared context, seniors on the call spend precious minutes re-deriving how subsystems interact.
• Senior engineers’ verification load rises even as mentoring drops. In a 2026 study on developer skill formation, Anthropic found developers who delegated coding to AI suffered their steepest drop in debugging comprehension, creating a downstream “debugging tax.” In practice, seasoned engineers spend up to 19% more time verifying and fixing AI-generated code. When juniors skip foundational questions upfront, they still need a senior engineer’s help later, shifting the senior’s role from upstream architectural teaching to downstream code forensics.

An organization can coast on accumulated fluency for many months before the deficit shows. By the time it surfaces in postmortems or failed handoffs, the habits keeping senior engineers’ understanding sharp have been dormant for quarters.

Rebuilding the channel on purpose

When leaders notice institutional context slipping, their first instinct is more aggressive documentation or indexing wikis into AI retrieval tools. That solves lost context for readers, but not the senior engineer’s problem. Writing a static wiki page never forces a veteran to defend trade-offs or trace failure cascades under questioning. Documentation captures static answers; only live human friction keeps architectural fluency sharp.

Restoring that friction does not mean restricting juniors from using AI assistants, nor does it mean adding optional team meetings that get cut the moment a deadline tightens. If directors are rewarded solely on ticket velocity, informal coaching will always lose to the sprint board. Instead, leadership must embed live human articulation across the four moments where architecture is built, rehearsed, stress-tested and passed on.

• At code review: require verbal design defense on cross-boundary pull requests. Instead of letting seniors review large AI-generated diffs silently, require a ten-minute live walkthrough whenever a change touches service boundaries, retries or state machines. The junior explains what the code assumes about upstream systems; the senior explains why the boundary exists, replacing downstream code forensics with upstream architectural dialogue.
• Between incidents: run live system walkthroughs without slides. Once a month, a senior engineer walks peers through a critical production workflow on a whiteboard, tracing failure modes and historical trade-offs out loud. Where the explanation stalls or relies on guesswork, institutional memory has decayed before an outage can expose it.
• After an outage: require unscripted architectural narratives in postmortems. Do not let seniors satisfy an incident review by pasting a runbook link or an AI-generated summary. Require the service owner to explain live to adjacent teams how a failure propagated and why the boundary exists. Unscripted explanation under peer questioning is the only reliable test of whether a team still understands the software it runs.
• At the 90-day check-in: test architectural handoff, not just ticket count. AI makes it easy for a new hire to close starter tickets in week two without learning how the system fits together. Use the first structured performance check-in to verify whether the new engineer can modify a core workflow and explain its failure modes without escalating to the senior owner. If early ticket velocity is high but every structural change still routes back to one veteran after a quarter, AI is accelerating surface work while core architecture stays trapped in one head.

Every seasoned engineer knows the feeling of trying to explain a familiar system out loud and finding the words no longer come cleanly. That stumble rarely means they lost their edge. It means the friction that kept their understanding sharp was automated away, and leadership must put it back before the next outage asks for an answer.

Tools such as Anthropic Claude Code or OpenAI Codex have changed the face of software development, and all the signs are that this investment is set to increase further. But is paying a monthly subscription (and perhaps additional usage fees) cost-effective? Will the increasing level of investment in AI-generated software prove to be worthwhile?

That’s a question several economists from the US National Bureau of Economic Research have attempted to answser, at least indirectly. Their paper, snappily entitled The Macroeconomic Effect Of AI: Sizing The Software Engineering Channel, attempts to calculate how much AI has increased the productivity of software engineers in enterprises outside the software and semiconductor industries by looking at their share prices.

“The main idea is that if AI raises the productivity of software engineers, then firms that rely more heavily on them should benefit more. Therefore news about AI generates higher expected profits for these firms. These profits are capitalized into larger stock price responses. Combining these stock price responses with a model, we can pin down the increase in software engineering productivity expected by financial markets,” the researchers wrote.

And the answer? “From November 2022 to December 2025, AI increased the market’s expected present value of software engineering productivity by the equivalent of a permanent 32.6% productivity increase.”

That’s not to say that your software engineers will be that much more productive, but it’s a starting point for allocating budget between AI tool use and payroll.

Every technology professional working today owes their career, in part, to someone who took a chance on them. The software engineers, cybersecurity analysts and infrastructure specialists on our teams didn’t arrive fully formed and ready to perform. Someone hired them, trained them and gave them room to grow. That’s worth remembering now, because the tech talent pipeline is shrinking, and history shows it can take more than a decade to recover from a decline like this.

The pipeline is at risk on two fronts: fewer students are choosing to study computer and information science, and hiring managers anticipate weaker near-term demand for these graduates. This isn’t unprecedented. The computing profession has weathered two major talent declines in its short history, and each took more than a decade to recover.

After 15 years of growth, computing enrollment reverses

According to the U.S. National Center for Education Statistics, the number of computer science and information science B.S. graduates has grown steadily since 2010. A tech degree once meant a well-paying job and a career with a future, driven largely by increased demand for technology. That momentum now appears to be reversing across several regions of the world.

Research from the National Student Clearinghouse Research Center indicates that enrollment in CS and IS degree programs at U.S. colleges and universities fell by more than 8% in 2025, even as overall undergraduate enrollment grew by 1%. The trend is not confined to the U.S. According to BCS, the Chartered Institute for IT, the UK saw a similar decline, with 18-year-old UK students entering computing degree programs down 9% in 2025. In Australia, the decline appears even steeper. ACS/Information Age reports that the Australasian Conference of Tertiary Admissions Centres’ (ACTAC) January 2026 report shows a 21% decline in enrollment for IT-related degrees heading into 2026.

Three countries, three distinct education systems, one common outcome. What makes this notable isn’t any single data point but the swift, dramatic downturn across all three countries. If this were confined to one market, it could be dismissed as a local correction; however, a similar pattern across the United States, the United Kingdom and Australia at roughly the same time suggests a structural shift in how the next generation views a tech career.

What 1,200 tech leaders expect: Lower demand for graduates

If the problem were only fewer graduates, but hiring demand were strong, the situation would probably correct itself. Talent scarcity would drive up wages and attract more students. However, the demand side appears to be contracting as well.

In the second quarter of 2026, I surveyed more than 1,200 senior technology leaders across 53 countries and what they expected their organization’s hiring demand to look like five years from now for entry-level roles filled by graduates with bachelor’s degrees in computer science or information science. Respondents held titles including CIO, CTO, VP of IT and Head of IT. More than 6,600 surveys were sent to technology leaders via LinkedIn, resulting in a 19% response rate.

The results were sobering: 45% anticipated lower demand, 28% expected demand to remain the same, while 27% anticipated it to increase. (You can download a summary of the survey at https://www.impactfultechnologyleader.com).

Chris Caruso

This result was not limited to a specific country or region. Those expecting hiring demand to be lower in five years were in the majority across almost every country, industry and company size.

The reason, cited across every group, was the same: artificial intelligence. Leaders expect AI to automate much of the entry-level technical work, including routine coding, service-desk tickets and administrative tasks. This is the work where new graduates have traditionally begun their careers. The logic is that existing teams, aided by AI, can do more without adding entry-level employees.

Regardless of their responses to the survey question, many of the leaders noted that reducing the number of junior roles in their organization was problematic. They recognized that it would erode the pipeline for future senior talent and that recovery from this gap would take years.

We’ve seen this movie before

This is not the first time CS and IS graduate numbers have fallen. In the mid-1980s, universities were overwhelmed by demand for computing degrees and couldn’t staff their programs adequately. When computer science programs could no longer accommodate surging student interest, universities capped enrollment and tightened admission standards. The effect was dramatic: bachelor’s degrees in computer and information sciences fell sharply beginning in 1987. It was not until 2001, fifteen years later, that graduation rates recovered to their earlier level.

The second decline came in the early 2000s, in what might be called a perfect storm. The winding down of Y2K remediation, the bursting of the dot-com bubble and a rising wave of IT offshoring converged to shake confidence in technology as a career. Mass layoffs swept through IT departments and dot-com firms, and enrollment in computing programs fell once again. The resulting drop in tech degrees awarded began around 2005, and it was not until 2016, eleven years later, that graduation rates recovered to the same level.

The chart below from the U.S. National Center for Education Statistics depicts these two significant declines in graduates with technology degrees.

Chris Caruso

Is AI the new perfect storm?

If you map today’s forces onto that history, the parallels are hard to miss. AI-driven automation is creating a demand shock, declining technology enrollments are creating a supply shock, and growing skepticism about the value of a technology degree is creating a confidence shock. This mirrors the erosion of faith in the career path after the dot-com bubble burst.

What took three separate crises to unfold in the early 2000s is converging today into a single, self-reinforcing cycle: fewer students entering the field, fewer opportunities perceived to be waiting for them, and growing doubts about whether a technology career is still worth pursuing.

But the parallel to those earlier declines carries a warning, not a reassurance, and the difference is in how each one ended. The recoveries of 2001 and 2016 happened because demand never left. In both prior declines, the supply of graduates fell while the underlying need for tech professionals rebounded. That gap between shrinking supply and steady demand is exactly what refilled the pipeline: scarcity pushed up wages, wages pulled students back and the market corrected itself, however slowly. What makes today different is that supply and demand are falling together. If leaders are correct that AI will replace entry-level work, this is not a demand dip waiting to rebound, it is a demand replacement, with no scarcity signal to trigger the correction that saved the field twice before.

The most dangerous feature of a talent pipeline is its lag. The decisions made, or not made, over the next few years will not trigger a crisis next quarter or even next year. Their consequences will surface a decade or more from now, when today’s would-be entry-level personnel should have become tomorrow’s architects, technical experts and leaders.

By then, the shortage will already be baked into the pipeline. And that is not speculation. It is the exact pattern the historical record has already shown us, twice.

What is a technology leader to do?

It would be easy to read my survey results and conclude that the market will sort itself out. Nearly half of the IT leaders I surveyed plan to hire fewer entry-level computing graduates over the next five years. Many dismiss this: education will adapt, five years is an eternity and better tools will make new graduates more capable than ever. They may be right. But hope is not a workforce strategy, and the leaders best positioned five years from now will be those who treat this as a problem to solve, not a trend to watch.

The uncomfortable truth is in one respondent’s warning: “We will have to find a way to invest in new grads, or we will not have a pipeline of middle and senior talent later.” If every organization cuts entry-level hiring because AI now handles the routine work, our profession will slowly stop developing the senior engineers it will desperately need a decade from now, because senior people are simply junior people who were given room to grow. No single leader can solve this problem, but every leader can refuse to be the one who lets it happen to their organization.

That starts with treating early-career hiring as a strategic investment, not the first line item to cut. Set aside several junior roles intentionally as an investment in your future leadership, rather than as just headcount to cut in the upcoming budget cycle.

It also means redefining what “entry-level” even means. Survey respondents were consistent: the bar is changing. They want applicants with a strong portfolio over a strong transcript, demonstrable AI fluency over rote coding, and, in the words of one, “people who can ask the right questions” now that AI supplies the answers. Rewrite your junior roles and interviews around critical thinking and judgment, and recognize that a new graduate’s value now lies in growth potential and the ability to direct AI-assisted work, not raw output.

Finally, the talent pipeline begins with encouraging high school students to seriously consider a career in technology, and guiding them will take all of us. If history holds, many will steer away from computing if they believe it has no future. Before committing to an investment as large as four years of tuition, parents will point their children toward fields with steady or rising demand.

Technology leaders and their teams can cut through the hype and help students understand what a career in technology looks like in the age of AI. Through classroom talks and on-site job shadowing, they can give students a real chance to discover the opportunities computing offers. Through mentoring and hands-on, real-world projects, they can support STEM programs at both the primary and secondary education levels.

With the aid of other technology professionals and leaders, I have developed a directory of organizations that promote and support careers in computing across the globe. The directory, which can be found at impactfultechnologyleader.com, includes:

• Programs for grade school, high school and university students
• Support for working professionals, whether already in tech or breaking into it
• Groups serving those transitioning from the military, returning to work or navigating any other path
   

Every one of us in this profession got here because someone decided we were worth the investment before we had proven it. That decision was never really about what a junior professional could contribute on day one. It was a bet on who they could become. AI may change what that first job looks like, but it doesn’t change a fundamental truth: to become a senior technology professional, you first had to be a junior one. The leaders who understand that over the next five years won’t necessarily be the ones who predicted AI correctly. They’ll be the ones who understood that some risks are worth hedging against even when you can’t be certain, and that a talent pipeline, once broken, takes a decade or more to rebuild.

The question isn’t whether the pipeline is at risk; it’s what you will do to make sure it doesn’t break.

There’s something very attractive about saying “we embed very closely with our customers and just figure it out with them”, especially since the company that started “forward deploying engineers” is growing 84% with $5B+ revenue. But “forward deployed engineer” is a vague term and means different things depending on the business you’re running.

I spent almost 5 years at Palantir as a forward-deployed software engineer, and Palantir’s version of an “FDE” does not make sense for most companies I now meet as an early-stage VC. Depending on the type of business you’re building, this role could broadly mean one of two things: “the product builder” or “the platform operator.” Clearly defining which bucket you fall into will make it easier to hire for this role and run your FDE org.

Kabir Sial

The product builder: The OG Palantir version

The north star is: do whatever it takes to actually solve the user’s problem. FDEs are not just responsible for making the platform work, but also discovering what to build and building it (actually creating software) in service of the customer.

The platform operator: Solutions + technical customer success

The north star is: make the product work for the customer – deploy and operationalize it. This is what most startups today really mean when they want FDEs. FDEs here configure the core platform, manage account relationships and drive adoption. This is not new – companies have always had solutions engineers, sales engineers, customer success etc., although the work looks different as FDEs are increasingly building prototypes, configuring evals and building MCPs.

Which FDE is right for you

Kabir Sial

For most situations, hiring product builder FDEs is a mistake.

At scale, the FDEs should be the platform operator. It’s hard to have FDEs build and maintain highly custom product features, especially as the company scales. Over time, the custom product surface area distracts from building the core product, even though AI coding tools make it easy to ship new features quickly and maintain them.

Many fast-growing AI startups recognize these constraints and structure the FDE role more like the platform operator. This also allows them to have 5-10 accounts per FDE, which is a much higher ratio than Palantir had (at least in 2023). Even the Palantir FDE role has evolved to look more like the platform operator.

There are, however, situations when your FDEs should be the product builder archetype.

1. You have very large customers (F500 scale)

Technical complexity: Large customers have complex environments with legacy infrastructure that often requires “out-of-platform” engineering work. I often encountered bespoke data infrastructure, privacy requirements, etc. at various Palantir customers that required me to build “out-of-platform” connectors, UIs and backends.

Organizational inertia and trust: Serving large enterprises is about building trust. In short time periods, overfitting product to a specific user/workflow is often what delivers the most value, builds trust and helps organizations get over the inertia of moving away from Excel and legacy software tools that are part of their day-to-day workflow. For AI-native startups, it’s arguably even more important to invest in doing “unscalable” development with engineering boots on the ground, as it helps solidify your right to exist and eventually expand the customer relationship.

2. You have many ICPs and workflows

If you have a broad range of ICPs and workflows that you serve, your product probably is not walk-up usable on day 1 of deployment. The short-term hacky things that product builder FDEs build to make the product work for these heterogeneous users/workflows will help you shape the product long-term.

Kabir Sial

Note: see Palantir Foundry’s architecture here.

This was a big reason why Palantir FDEs were more like product builders (and are still able to – see the Forward Deployed Software Engineer job profiles as an example). The vision for Foundry was to be the operating system for an enterprise’s critical decisions – inherently multiple industries, users and workflows. A lot of FDE-led development showed that solving many of these use cases required complex data integrations, which led to the early versions of Foundry being best-suited for complex data integrations and building a customer’s “Ontology”. Similarly, FDEs like myself built custom frontend applications for fraud analysis, pricing, etc. As certain patterns of what these applications required became more clear, they were centralized into an application-layer product.

Who you should hire

Kabir Sial

Kabir Sial

Platform operator: There is a much broader set of people you could hire, testing for technical fluency (e.g., being good at data analysis, complex Excel work, even SQL), product intuition and an inclination to build customer relationships. Backgrounds like technical customer success, solutions engineering, software engineering, product management and consulting are all strong fits.

Product builder: You want candidates that are high ownership and missionary software engineers, or technical PMs who want to ship products themselves.

Hiring for these profiles, especially product builders, is hard. It’s worth calling out two things that helped Palantir hire software engineers into what might be considered a less sexy role.

1. Culture of building at the edge: Strong engineers are motivated to build things. Palantir gave FDEs a lot of ownership to build products, which is why much of the core product leadership was former FDEs.
2. Cult built around mission: Internally, there was a cult-like devotion to the mission. Everyone always talked about why outcomes were far more important than software, and why most companies building tools had it wrong. I’ve never been at a company where people feel so closely bonded around a mission.

As founders building AI startups think about hiring FDEs, it’s worth being specific about your culture and asking: Am I just hiring people to support development teams, or am I hiring people to shape and build product? It’s hard to get software engineers (even today) to be excited about an FDE role that might just be technical customer success.

What FDEs should be doing (regardless of archetype)

You’ve hired the right people. How do you best leverage your team of FDEs?

FDEs were Palantir’s way of delivering outcomes rather than tools. AI-native startups can take this much further and FDEs can help in a few unique ways by leveraging their proximity to customers.

1. Find the most critical workflows: As AI lowers the cost of producing software, companies will face a lot more competition. FDEs at AI startups should be constantly finding ways to serve the most critical workflows for a customer and paying attention to how customers do work across newer and legacy tools. For example, FDEs at Harvey should pay attention to which workflows are in Westlaw, which ones are moving to ChatGPT/Claude, and how the Harvey product can stay ahead.
2. Build around nondeterminism: In more regulated environments, FDEs should be hyper-focused on making products reliable for specific use cases using evals and configs. Previously, product reliability lived with product and support. As companies provide outcomes instead of tools, configuring products appropriately and managing evals shifts towards FDE teams.