Software Engineering Teams in an AI-Native World
TL;DR
What did a Series D SaaS engineering team look like in 2020?
A familiar structure combined technical and engineering leaders, engineering managers, product teams, and shared infrastructure, quality, security, and data specialists. Funding stage alone never established a standard headcount.
What is an AI-native engineering team?
An AI-native team designs its product or its development process around AI capabilities. Companies building AI products must manage model behavior, while companies using coding agents must manage how automated work reaches production.
What changes if AI writes and deploys most of the software?
AI can handle coding and deployment, letting one person own responsibilities previously split across several roles. Product decisions, system design, evaluation, and ownership of production still need clear authority.
Who guides the team when AI handles coding and deployment?
In the proposed organization, product and technical leaders set priorities and system constraints; domain leads and forward-deployed engineers direct delivery. Shared specialists establish the infrastructure and evidence needed to operate the result.
Can a forward-deployed engineer replace traditional product roles?
A forward-deployed engineer (FDE) can absorb some product management work on a customer engagement, particularly discovery, requirements, and delivery coordination. The company still needs someone deciding which requests belong in the shared product.
Which engineering roles could retain value?
Roles that own consequential decisions have a strong claim: domain technical leads, systems engineers, product leaders, and specialists in evaluation, platforms, security, and reliability. Several responsibilities may fit within one position.
Will AI make engineering teams smaller by 2030?
Gartner forecasts that 60% of organizations will adopt smaller engineering teams at scale by 2029, up from 15% in 2026. Gartner also expects demand for engineers to grow; team size and total employment measure different things.
The most consequential change AI could bring to a software engineering team might be more about who does what.
If AI produces production-ready code, a company must reconsider roles and responsibilities and how it divides work across the team. Does each product team still need a separate product manager, engineering manager, technical lead, several developers, and dedicated testing support? Could someone who understands the customer’s business and the system architecture own work previously spread across several positions? Which decisions still justify a specialist?
Our working view is that AI-native engineering will increasingly favor people who can connect a business problem to a sound technical approach and remain responsible for the result. Forward-deployed engineers, technically strong product leaders, and experienced systems engineers are well positioned for that work. Their responsibilities can become more important even if companies need fewer separate positions to carry them out.
Our reference point is an enterprise software-as-a-service (SaaS) company around Series D, with several product areas, meaningful customer integrations, and ongoing production obligations. Series D identifies a financing round; companies at that stage vary considerably in headcount and complexity. The charts use the same broad business scope across periods and show illustrative organizations. A SaaS company building applications with AI also has a different staffing problem from a frontier lab training the models.
The 2020 SaaS engineering organization
A familiar 2020 organization divided responsibility across product development, technical leadership, people management, and shared operational functions. Humans designed systems and wrote most of the code. Expanding a product usually required more time.
The chief technology officer (CTO) and VP of Engineering often carried different responsibilities. In his 2011 account, investor Fred Wilson described the CTO as concentrating on technical direction and the VP of Engineering on building and running the engineering organization. Companies could arrange these leaders as peers or have one report to the other.
Below that leadership, larger organizations added directors and engineering managers. Product teams brought together engineers with product and design partners. Intercom’s May 2020 description is a useful example: a team owned a piece of the product and included a product manager, a designer, and several product engineers.
An illustrative 2020 org chart
Solid lines show one possible reporting structure. The dotted line shows a partnership between product and design. Some companies combined leadership roles, omitted layers, or placed security and data elsewhere.
| Role or function | Typical responsibility in this model |
|---|---|
| CTO and senior technical leadership | Architecture, technical strategy, major technology choices, and difficult technical decisions. |
| VP Engineering, directors, and engineering managers | Hiring, staffing, coaching, performance, coordination, and delivery. |
| Tech leads, staff engineers, and principal engineers | Technical direction within or across teams, design decisions, mentoring, and complex problem solving. |
| Frontend, backend, and full-stack engineers | Building, testing, debugging, maintaining, and operating product capabilities. |
| Product managers and designers | Customer problems, priorities, product requirements, user experience, and validation. |
| Platform, development and operations (DevOps), and site reliability engineering (SRE) | Development infrastructure, deployment, service reliability, monitoring, and incident response. |
| Quality assurance (QA) and test automation engineers | Test coverage, frameworks, exploratory testing, and evidence that workflows behaved correctly. |
| Data and security specialists | Data infrastructure, access, protection, and specialized requirements shared across products. |
The individual contributor path offered engineers broader technical responsibility without requiring people management. GitLab’s February 2020 account described senior engineers choosing between an engineering management track and a staff technical track. Staff work included systemic problems and alignment across technical and product concerns.
Automation was already part of the work. GitLab discussed automated testing, unreliable tests, and business workflow validation in 2019. Google’s 2016 Site Reliability Engineering book treated automation, reliability, capacity, and incident response as engineering responsibilities.
Architecture, product judgment, mentoring, and operational responsibility were already valuable in 2020. The coming change concerns how those responsibilities are distributed and how much coding the company needs people to do. Treating the old engineering team as a collection of ticket processors misses what experienced engineers actually contributed.
The traditional structure also created opportunities to learn. Smaller features, bug fixes, tests, code reviews, and production support gave less experienced engineers progressively more context. It was imperfect, but it connected writing, reviewing, and running software with the development of judgment. Any replacement model has to deal with that connection.
What AI-native engineering looks like in 2026
AI agents use models and tools to carry out tasks across several steps. For an engineering organization, AI has two distinct uses to account for.
The first is AI inside the product customers buy. That might be an agent resolving a service request, a system analyzing documents, or a workflow that takes actions across enterprise software.
The second is AI inside the process used to build and operate that product. Coding agents, automated investigation, generated tests, and agent-assisted reviews change how engineering teams work.
A company can be advanced in one use of AI and immature in the other. Each requires decisions about operating costs, failure modes, and ownership.
Decagon, which announced a Series D financing in January 2026, provides a useful example. Its engineering roles include infrastructure for the agents customers use and a developer platform that serves the people and coding agents who build the software. Its Agent Orchestration role describes ownership of the production runtime and model coordination; its AI Platform role describes internal developer infrastructure.
An illustrative 2026 org chart
The boxes group capabilities. A smaller company could combine several in one team. Security and reliability may sit within infrastructure or have independent leadership.
The product team still needs user interfaces, application programming interfaces (APIs), integrations, permissions, billing, and maintainable software. AI adds further questions. Which model should handle a task? What information should it receive? Which tools may it use? How should the system respond when it is uncertain, wrong, slow, or unavailable?
Evaluations are repeatable checks of AI behavior on representative tasks. Glean’s AI Evaluations leadership role covers evaluation infrastructure, datasets, assessment methods, production traces, and measurements spanning quality, response time, reliability, and cost. That is substantial technical work that requires its own engineering leadership.
Quality must cover model behavior
A conventional software test might check whether a workflow saves the right record and returns the expected status. An AI product also needs evidence that it interpreted the request correctly, used appropriate information, followed the relevant policy, and took a useful action.
Application tests can check whether software handles permissions, retries, and recovery as specified. Model evaluations examine whether the AI reaches useful, policy-consistent results on representative tasks. Release decisions need evidence from both.
The work also extends beyond evaluating an isolated response. An agent might make a reasonable first decision and still mishandle a longer sequence of actions. A production team needs to understand how those failures appear, how they are detected, and what happens next.
The engineering process is changing too
In February 2026, OpenAI described an internal beta product built without manually written code. Engineers specified intent, designed the working environment, and established feedback loops. The reported autonomy depended on the repository’s tools and structure, so the surrounding engineering work also explained the result.
At Linear, engineer Maciek Pekala described a related shift in June 2026. With agents handling much of the bug-finding and logic checking in his review workflow, he spent more time ensuring a change fit the system and solved the right problem.
An October 14, 2026 OpenAI maintenance report adds a more recent example. Five engineers using coding agents merged more than 1,400 maintenance changes, doing the bulk of the work part-time over two weeks. Reviews went to other teams familiar with the affected systems. Some proposed changes added more complexity than their benefit justified, so prioritization and measurement remained part of the work.
What changes when AI handles coding and deployment
Assume AI can handle most coding and deployment, including writing and testing application code, configuring infrastructure, and running routine migrations and releases. It can also produce documentation, investigate failures, propose architectures, and run evaluations. Under that assumption, preserving every existing job boundary would need a business justification.
A company still needs a useful product, a coherent system, and dependable operations. It may need fewer people to meet those requirements. Some responsibilities could move into broader roles; others could be shared across product areas or supplied by a vendor.
This is the point at which a standard staffing formula becomes less helpful. A PM, an engineering manager, a technical lead, and a group of developers may no longer be the natural starting unit for every initiative.
We expect the strongest roles to combine more of the decisions previously distributed across that group. The forward-deployed engineer offers one of the clearest examples.
The forward-deployed engineer and the shrinking number of handoffs
A forward-deployed engineer works close to the customer and carries technical responsibility for solving a real operating problem. Customer understanding and engineering ownership sit within the same job.
Anthropic’s current U.S. Staff FDE role includes leading discovery, deciding what should be built, guiding architecture, and owning technical strategy for an account or vertical. It specifically calls for system design and problem decomposition in complex enterprise environments.
OpenAI’s FDE description similarly spans discovery, technical scoping, system design, deployment, and measurable customer impact. Both descriptions still include coding today. Their broader responsibilities show what could remain when more of the coding is delegated.
Where enterprise customer delivery is split across several functions, information may move through a long chain. A customer explains a problem to an account team. An analyst turns it into requirements. A PM interprets and prioritizes the request. An architect proposes a solution. An engineering team codes and deploys it. Another group helps the customer adopt it.
There are good reasons to specialize. There are also opportunities for context to disappear at every transfer.
A sufficiently capable FDE can stay with the problem through much of that sequence. With AI handling much of the coding and deployment, the person who discovers the problem can also direct the build and judge the result. Some separate requirements, delivery, and product coordination positions become harder to justify for that engagement.
Product decisions still need an owner
The most exposed product work is translating an already understood request into documentation and tasks for someone else. A broader technical owner can absorb some of it, with AI handling much of the administrative effort.
The company still needs authority over the product as a whole. One customer’s request may create costs for everyone else. Several customers may want incompatible behavior. A lucrative custom project may take the business away from the market it intends to serve.
Someone must decide what becomes a shared capability, what remains an extension, and what the company declines. That person could be a founder, product general manager, head of product, CTO, or senior FDE leader. A senior product owner could cover those decisions across several delivery teams.
Without that authority, a SaaS company can accumulate custom deployments faster than it develops a coherent product. AI can make each customization easier while leaving the maintenance obligation intact.
Current practice also shows that complexity can justify separating roles. Decagon created Agent Deployment Engineering alongside Agent Product Managers because demanding deployments required sustained customer partnership and sustained technical depth. The product role retained the relationship and broader transformation; deployment engineering concentrated on agent behavior and production improvement.
The useful test is whether a division of labor improves the outcome enough to justify the handoff. It should not survive solely because it appeared on the previous org chart.
Systems architecture becomes more consequential
When AI can code and deploy changes quickly, the quality of the decisions guiding that work matters enormously. A mistaken requirement can become working software. An unnecessarily complicated design can spread across a product before anyone has examined its operating consequences.
Companies could need systems knowledge in more decisions while employing fewer dedicated architects. The value of the expertise and the number of positions are separate questions.
Under our assumption, AI can generate diagrams, propose familiar patterns, and draft design documents. An architect earns a place in the organization by understanding the actual business constraints, choosing among imperfect options, and staying responsible when the system meets production.
Decisions include data ownership, service boundaries, permissions, failure recovery, migration strategy, performance, and the cost of operating the design. They also include knowing when a problem doesn’t require another model, agent, or service.
Follow one enterprise problem through the organization
Consider a hypothetical logistics SaaS customer that wants an agent to resolve freight invoice exceptions.
The initial request sounds like a software feature. The underlying problem could involve inconsistent shipment records, unclear approval rules, different interpretations of a charge, or a slow escalation process. An FDE needs to understand how the customer’s people resolve those cases today and what a useful improvement would mean.
The systems owner then has to decide which records are authoritative, how the workflow interacts with billing, and what actions the agent is permitted to take. If a request is retried, the system must avoid taking the same consequential action twice. If information changes during a review, the system needs a defensible way to handle the disagreement.
The product leader has a different decision: which parts of this request should become capabilities for all customers? A local workaround that satisfies one account may be a poor foundation for the shared product.
Quality ownership determines the evidence needed to release the change. Useful measures would include incorrect case closures, manual reopen rates, resolution time, and cost per resolved case. Evaluation needs representative examples and failures that reflect the customer’s actual operating requirements.
The production owner needs to know what happens when a dependency fails, how a customer can correct a result, and whether the workflow remains economical as usage grows.
Under this assumption, AI can write, test, and deploy the software. It can assist with every analysis in this example. The organization still needs to allocate decision authority and responsibility for the consequences.
Several of those responsibilities could belong to one person. A technically deep FDE could own discovery, solution design, and deployment. A principal engineer could provide architectural oversight across several such engagements. Product and quality decisions could be shared where that is practical.
The shared platform becomes part of the staffing model
Small product teams depend on capabilities they don’t have to rebuild. If every team must create its own agent environment, permissions, deployment process, evaluation infrastructure, and monitoring, a smaller headcount can quickly become an overloaded headcount.
This is why the support behind a small team matters as much as the number of people inside it. A tiny delivery group may be supported by a substantial platform, shared specialists, and external services.
RedMonk’s July 2026 discussion with Stephen O’Grady describes the pressure that cheaper code production places on review, security, governance, and infrastructure. The organizational implication is that generating more code can create work elsewhere in the system.
O’Grady’s September analysis adds another dimension: agents themselves are becoming users of software infrastructure and influencing technical choices. He expects different product categories to support different mixtures of human and agent workflows.
For engineering leaders, that means designing environments in which automated work can proceed within clear boundaries. It also means limiting the unnecessary work those systems perform.
James Governor’s October 2026 RedMonk article makes model efficiency a practical team and company issue. It discusses routing work to suitable models and using repeatable automation where a model call is unnecessary.
The budget question therefore expands beyond salary and cloud hosting. Leaders need to understand the full cost of a completed, accepted change, including agent usage, review, rework, and the resulting system’s operating expense.
Automation that produces an impressive queue of proposed changes can still leave the company with an expensive queue.
What the forecasts suggest about 2030
Gartner forecasts that 60% of organizations would adopt smaller software engineering teams at scale by 2029, up from 15% in 2026. These percentages measure organizational adoption of a team structure.
Gartner’s September article expects smaller, more numerous teams by 2030, supported by shared platforms. Gartner also expects growing software demand to increase the need for engineers. That outlook depends on demand expanding enough to absorb the added capacity; our scenario about consolidating positions examines what happens when a company can serve its intended business scope with fewer people.
The Pragmatic Engineer provides a useful view of the variation behind those predictions. In February 2026, Gergely Orosz reported conversations with roughly 20 leaders describing smaller teams. The same article included Atlassian CTO Rajeev Rajan describing teams producing more without necessarily becoming smaller.
Orosz’s July reporting inside Anthropic makes another distinction: projects could involve at most two engineers while larger, stable teams continued to exist. Small project staffing and total organization size are different measurements.
That gives us several possible outcomes. A company can reduce the people assigned to a project, run more projects within the same team, add product areas without increasing headcount, or reduce its total workforce. Demand, competition, capital, operating costs, and management decisions will influence which path a company takes.
Frontier capability targets are more ambitious
OpenAI’s September 2026 research update describes its goal of an automated AI researcher by March 2028. In the work it reports, people still set priorities and choose which ideas and results to pursue. The target is a frontier lab’s ambition, with a research mission and operating environment that differ from those of an application company.
METR’s published task-horizon series estimates difficulty using the time a human expert would need to complete a task, at a specified AI success rate. Its tasks cover bounded software, machine learning, and cybersecurity problems. The series was last updated on September 8, 2026, and is no longer actively maintained. METR warns that measurements above 16 hours are unreliable with that task suite.
These signals make substantial further delegation plausible. They cannot tell an employer how many architects, product managers, or engineers to hire four years from now.
A plausible 2030 organization when AI handles coding and deployment
Our stronger 2030 model starts with product and technical authority, a small number of people owning customer or product outcomes, and shared specialists responsible for the system they all depend on.
An illustrative 2030 org chart
Solid lines show one possible human reporting structure. Dotted lines show direction, support, and constraints on AI work. The boxes group responsibilities that could be combined within jobs or shared across teams. Product and technology leadership could be one person or a close partnership.
In this model, the business or product leader decides which outcomes merit investment and what belongs in the shared product. The technical leader sets system constraints and resolves architectural conflicts. An FDE or domain lead owns delivery within those boundaries. Quality and security owners establish release requirements and escalate unresolved risks to the accountable leadership.
A complex product area might still justify a dedicated multidisciplinary team. The reason to separate roles would be the remaining work and the quality of the decisions.
Applied AI expertise would also spread. If models and agents are core product components, working with them becomes part of ordinary product engineering. A centralized specialist group would remain useful where difficult model behavior, adaptation, or research creates a real advantage.
Which roles have the strongest claim on the hiring plan
| Role profile | Decision or responsibility that supports its value | Work AI could perform on its behalf |
|---|---|---|
| Technical business leader | Choose investments, connect product strategy to technical capability, and resolve competing priorities. | Research, modeling, options analysis, prototypes, and planning support. |
| FDE or domain technical lead | Understand the customer’s operation, shape a useful solution, and own adoption and results. | Coding, deployment, documentation, investigation, configuration, and testing. |
| Principal engineer or systems architect | Maintain coherence across systems and make consequential architecture and integration decisions. | Design alternatives, diagrams, code analysis, simulations, and migrations. |
| Evaluation and quality owner | Establish credible evidence of useful behavior and determine appropriate release criteria. | Test generation, execution, grading, monitoring, and failure triage. |
| Platform, data, reliability, and security specialists | Maintain the shared environment, trustworthy information, operating boundaries, and recovery capabilities. | Provisioning, checks, routine remediation, analysis, and maintenance. |
| Product or experience designer with domain depth | Improve the workflow and help users understand, control, and correct system behavior. | Prototypes, interface production, research synthesis, and experimentation support. |
These profiles overlap. A strong individual could cover several rows. A required capability can also be supplied by a platform or specialist vendor rather than a dedicated employee.
An experienced engineering manager can still add substantial value through hiring, coaching, organizational design, and resolving difficult coordination problems. Directing agents can be part of an individual contributor’s job. A separate management position needs enough hiring, coaching, or coordination work to justify it.
The technical knowledge remains important even when code writing is delegated. Someone accountable for a system needs a credible way to interrogate its behavior and diagnose failures. Knowing how software works is a different capability from spending most of the day typing it.
The roles under pressure are defined by their contribution
Assuming AI handles coding and deployment, jobs centered on producing a specified artifact face obvious pressure. That includes routine code production, repetitive test execution, standard documentation, and parts of interface production.
The pressure can also reach product and management. Requirements transcription, status collection, ticket administration, and information relay are difficult to defend as separate positions if a broader owner and automated tools can handle them effectively.
These tasks occur at every seniority level. If AI becomes much better at architecture, product analysis, and coordination, consolidation can extend to senior technical and management roles. Keeping a human accountable may justify one owner where the company previously employed several specialists.
How junior engineers build judgment
Anthropic’s October 16, 2026 employment study reports that junior hires’ share of technical hiring fell from 27% to 9% since early 2025, while technical hiring grew in absolute terms. The study uses internal company records and 17 employee interviews. It describes hiring at one rapidly growing frontier company.
The risk for employers is a break in the development path: they may place greater value on judgment while automating some of the tasks through which engineers traditionally acquired it.
A durable talent pipeline needs routes into experienced work. If small fixes, routine tests, and straightforward features increasingly go to agents, employers need to give junior engineers other supervised opportunities to build context and take responsibility.
That could include supervised ownership of a narrow product area, paired investigation of production problems, participation in customer discovery, and responsibility for explaining why an AI-generated change works. The goal is to build understanding through consequential work with appropriate support.
Anthropic’s June 2026 analysis examined roughly 400,000 Claude Code sessions from October 2025 through April 2026. Task-specific expertise was associated with stronger session-level success signals, with most of the difference appearing between sessions rated novice and sessions rated intermediate. Claude inferred expertise and success from transcripts, so the findings concern evidence visible in those sessions. The study leaves downstream business outcomes unobserved.
What employers and candidates should do with this
For U.S. employers, the useful starting point is the next hiring decision.
Before replacing a departing engineer, PM, or delivery manager with the same job description, identify the work that still requires a person. What decision will the hire own? What context do they need? Which responsibilities can be combined without overloading the role? What platform or specialist support will make that broader ownership realistic?
That last question matters. Removing positions while leaving every responsibility untouched can produce an impossible job. A smaller team needs dependable support, clear priorities, and a manageable decision load.
Candidate assessment should reflect the proposed work. Give someone an ambiguous customer problem and examine the questions they ask, the assumptions they challenge, and the system they propose. Let them use AI. Then ask them to evaluate the output, explain the failure cases, and decide whether the solution belongs in the shared product.
For candidates, several credible directions exist. An engineer can deepen knowledge of the business and customer workflow. A product manager can develop enough systems understanding to direct technical work. A domain specialist can learn to turn expertise into testable requirements and useful automated workflows. A platform engineer can make a larger organization effective through dependable shared capabilities.
A skill can become more important to a business while fewer people are hired to apply it. Employers and candidates need to hold both parts of that sentence in view.
Building out your AI-native team
The organizational shift toward AI-native engineering affects companies differently depending on scale, capital, and legacy infrastructure. Whether supporting a zero-to-one team building its initial product, a Series D organization evaluating teams and roles, or an enterprise modernizing its development pipeline, STEM Search Group is uniquely positioned to help.
Our approach relies on active market intelligence and real-time industry signals rather than superficial candidate sourcing. Through ongoing conversations with technical executives and founders, we hear how leading organizations restructure roles, evaluate agentic workflows, and adapt their hiring bars. We clearly distinguish between engineers who are vibe coding and candidates who bring scalable, AI-native skills, such as spec-driven development and bounded prompting.
We are more than keyword jockeys. If you are building an engineering team and need disciplined AI engineering talent, let’s talk.
Sources
The sources below support the historical examples, current company practices, and attributed forecasts. Job descriptions were reviewed on October 21, 2026.
- Fred Wilson, AVC. VP Engineering Vs CTO. October 31, 2011. Historical distinction between technical and organizational leadership.
- Intercom. Reading list: Analyzing great product teams. May 19, 2020. Product teams combining product management, design, and engineering.
- GitLab. What does Staff level mean at GitLab?. February 18, 2020. Parallel management and technical career paths.
- GitLab. An inside look at software testing at GitLab. August 30, 2019. Quality engineering, automation, and business workflow validation.
- Google. Site Reliability Engineering, Chapter 1: Introduction. 2016 book. Reliability and operational engineering responsibilities; publication record.
- Decagon. Decagon’s $250 million commitment to the AI concierge future. January 27, 2026. Series D financing and company context.
- Decagon. Senior Software Engineer, AI Platform. Undated employer posting. Full description verified through the employer’s public job feed. Internal infrastructure for engineers and coding agents.
- Decagon. Engineering Manager, Agent Orchestration. Undated employer posting. Production agent runtime and orchestration.
- Glean. Tech Lead Manager, AI Evaluations. Undated employer posting. Evaluation infrastructure and quality ownership.
- Ryan Lopopolo, OpenAI. Internal product development with coding agents. February 11, 2026. An internal beta developed without manually written code.
- Maciek Pekala, Linear. Reviewing code in the agent era. June 10, 2026. Product and system judgment in code review.
- Anthropic. Staff forward-deployed Engineer. Undated U.S. employer posting. Discovery, technical strategy, architecture, and customer ownership.
- OpenAI. forward-deployed Engineer, San Francisco. Undated U.S. employer posting. Discovery through deployment and customer impact.
- Alex Lewis, Decagon. Getting closer to the build: How I helped create agent deployment engineering. August 12, 2026. Separating product and technical responsibilities in complex deployments.
- RedMonk. What Happens When Every Developer Has 20 AI Agents?. July 14, 2026. Discussion with Stephen O’Grady about downstream constraints.
- Stephen O’Grady, RedMonk. Agents: The new, New Kingmakers. September 16, 2026. Agents as infrastructure users and influences on technical choices.
- James Governor, RedMonk. The best token is one you don’t use. October 15, 2026. Model routing and efficient usage.
- Gartner. Gartner Predicts 60% of Organizations Will Adopt Smaller Software Engineering Teams by 2029. July 7, 2026.
- Gartner. The Future of Software Engineering: Smaller Teams, Bigger Ambitions. September 25, 2026. Smaller, more numerous teams and shared platforms.
- Gergely Orosz, The Pragmatic Engineer. The Future of Software Engineering with AI: Six Predictions. February 24, 2026. Practitioner observations and forecasts.
- Gergely Orosz, The Pragmatic Engineer. How building software is changing at Anthropic. July 28, 2026. Project staffing, persistent teams, and verification work.
- OpenAI. Research acceleration: The view inside OpenAI. September 6, 2026. Research workflows and the automated researcher target.
- METR. Task-Completion Time Horizons of Frontier AI Models. Last updated September 8, 2026. Benchmark definitions and limitations.
- Nathan Wilmers and colleagues, Anthropic. How employment is changing at Anthropic. October 16, 2026. Hiring composition and changing responsibilities.
- Anthropic. Agentic coding and persistent returns to expertise. June 16, 2026. Domain understanding and interactive coding-agent use.
- Rodrigo Roim, OpenAI. Maintaining software with the GPT-6 family. October 14, 2026. Agent-supported maintenance, distributed review, and the need to assess complexity and benefit.