The software industry is going through one of the biggest changes in its history. For decades, building software meant hiring people who could write code, fix bugs, test applications, and keep complex systems running. Today, AI coding agents can perform many of those tasks with surprisingly little human help.
That raises an uncomfortable question for software engineers in San Francisco and across Silicon Valley. If AI can write code, understand existing projects, find problems, and create working applications, what happens to the people who have built their careers doing those things?
The answer is more complicated than the headlines suggest.
AI coding agents are already changing how software gets made. Developers can hand an agent a task, allow it to explore a project, and review the changes it produces. Some teams are building software faster, while others are discovering that checking AI-generated work can take longer than expected.
The latest evidence shows both sides of this change. GitHub’s October 2026 research reports that more than 40% of pull requests started with an AI agent by September 2026. Yet controlled research has also found situations where experienced developers became slower when using AI tools. The GitHub Blog+1
For San Francisco, the stakes are especially high. The region is home to companies creating AI coding tools, startups adopting them, and engineering teams working on software that millions of people depend on.
To understand what happens next, SFTechScene examined public data from GitHub, Stack Overflow, the U.S. Bureau of Labor Statistics, METR, and software engineering benchmarks. We also developed original calculations and business models to examine which engineering tasks are most exposed, how developer roles may change, and when AI coding agents make financial sense.
The findings point toward a different future from either mass replacement or business as usual. Software engineering is not simply disappearing. The work is being divided between tasks that machines can increasingly handle and decisions that still require human judgment.
The Short Version: AI Coding Agents Are Replacing Parts of Software Engineering, Not the Entire Profession
AI coding agents are moving beyond simple code suggestions. They can now work across multiple files, run tests, repair some errors, and prepare changes for human review.
That is a serious shift because many software developers have traditionally spent large amounts of time doing exactly this kind of work. But writing code is only one part of building reliable software.
GitHub, September 2026
40%+
Pull requests started with an AI agent
Stack Overflow, 2025
46%
Developers who distrust AI output accuracy
METR, 2025 experiment
+19%
Task completion time with AI in the studied setting
BLS, 2025–2035 projection
+10.2%
Projected U.S. software developer employment growth
Sources: GitHub Octoverse 2026, Stack Overflow Developer Survey 2025, METR, and BLS. These measures have different populations and time periods and should not be treated as directly comparable. The GitHub Blog+3
The most important distinction is between generating software and being responsible for it.
An AI agent may create a working payment feature, but someone must decide whether it handles refunds correctly, protects customer information, works during heavy traffic, and follows the company’s business rules.
That responsibility becomes even more important when software controls money, medical records, transportation, or business operations.
For developers, the biggest career risk may not be that AI suddenly replaces every engineer. It may be that companies need fewer people to complete routine programming tasks, while expecting the remaining engineers to manage more complex work.
For employers, the biggest opportunity is not eliminating developers from the payroll. It is helping engineers deliver better software with less repetitive work and fewer expensive mistakes.
What Exactly Is an AI Coding Agent?
An AI coding agent is software that uses artificial intelligence to complete programming tasks through a series of actions.
Traditional coding assistants usually respond to what a developer is doing. They might suggest the next line, explain a function, or generate a small piece of code.
An agent can take a broader instruction and work through several steps to complete it.
For example, a developer might ask an agent to investigate why a customer dashboard loads slowly. The agent could search the codebase, identify likely causes, modify files, run tests, and prepare a proposed fix.
That does not mean the agent always finds the correct answer. It means the system can perform more of the work before returning control to a person.
How AI Coding Agents Differ From Traditional Coding Assistants
| Capability | Traditional AI assistant | AI coding agent |
|---|---|---|
| Suggest code | Yes | Yes |
| Explain existing code | Yes | Yes |
| Search a large project | Often, with tools | Usually part of workflow |
| Edit multiple files | Sometimes | Common capability |
| Run tests | Through integrations | Can execute tests |
| Investigate failures | Guided by developer | Can attempt independently |
| Prepare a proposed change | Limited or assisted | Often supported |
| Guarantee correct software | No | No |
| Accept business responsibility | No | No |
These categories overlap because coding tools are changing quickly. Many products now combine chat, editing, automation, and agent features in the same interface.
The New Generation of AI Coding Tools
Several products are helping define this market.
Cursor
Cursor brings AI-powered editing and agent workflows into an environment built around software development. Its appeal is that developers can work directly with code while delegating larger changes.
Claude Code overview – Claude Code Docs
Claude Code
Claude Code allows developers to assign programming work through terminal-centered and connected workflows. It is designed to inspect projects, make changes, and use development tools.
OpenAI Codex Download | TechSpot
OpenAI Codex
Codex supports software engineering tasks such as modifying code, working with repositories, and preparing changes for review. It represents the move from answering coding questions to carrying out coding work.
GitHub Copilot · Agents on GitHub · GitHub
GitHub Copilot
GitHub Copilot connects AI assistance with the tools many teams already use to build and review software. Its agent features help move work from an assigned task toward a proposed code change.
The competitive question is shifting. It is no longer only about which tool writes the best function, but which system can complete useful work while making its decisions easy to inspect.
That difference matters because software teams do not get paid for generating code. They get paid for delivering products that work.
Original SFTechScene Research #1: AI Coding Agent Adoption Has Entered a New Phase
The strongest evidence of change comes from what developers are doing rather than what technology companies promise.
GitHub published its 2026 Octoverse report on October 28, 2026. The report covers activity from October 1, 2025, through September 30, 2026, and includes activity from public and private repositories where applicable.
One of its most important findings concerns pull requests. A pull request is a proposal to add or change code in a software project.
In March 2026, 17% of pull requests on GitHub started with an AI agent. By September, the share had risen above 40%. The GitHub Blog
SFTechScene Calculation: How Quickly Did Agent Adoption Grow?
Share of GitHub pull requests started by AI agents
March and September 2026; September shown at the reported lower bound of 40%.
Using 40% as the conservative September threshold, SFTechScene calculates a minimum increase of 23 percentage points.
The relative increase is at least 135%, meaning the share of agent-started pull requests became more than 2.35 times its March level in six months.
This is an important change in developer behavior. It suggests that AI agents are becoming a common starting point for software changes rather than an occasional experiment.
However, it does not mean AI completed 40% of software engineering jobs. An agent-started pull request may still involve extensive human review, editing, testing, and correction.
Original Research: Are AI-Generated Changes Getting Accepted Faster?
GitHub also reported how quickly pull requests with detected agent involvement were merged.
A merged pull request is a proposed change that has been accepted into a project’s codebase. Merge speed is useful to measure, but it does not establish whether the change was necessary, safe, or valuable.
| GitHub measure | Earlier period | September 2026 | SFTechScene interpretation |
|---|---|---|---|
| Agent-started share of pull requests | 17% in March | Over 40% | Rapid growth in agent use |
| Agent-involved PRs merged within two weeks | 83% in February | 90% | 7 percentage-point increase |
| PRs without detected agent involvement merged within two weeks | About 86% | About 86% | Broadly stable comparison |
| PRs changing multiple files, agent-involved | — | 87% | Agents often work across files |
| PRs changing multiple files, comparison group | — | 79% | 8-point difference |
Source: GitHub Octoverse 2026. Merge rates describe observed groups and are not proof that agents caused faster merging. The GitHub Blog
The September comparison is particularly interesting. Agent-involved changes had a reported two-week merge rate about four percentage points higher than changes without detected agent involvement.
It would be tempting to conclude that AI creates better code. The published numbers do not justify that conclusion.
Teams may be assigning simpler work to agents, using them on projects with different review rules, or relying on automated checks that speed up merging. Without controlling for those differences, the result is descriptive rather than causal.
What This Means for San Francisco Engineering Teams
For local startups, the lesson is that agent-assisted development has reached a scale where ignoring it may create a competitive disadvantage.
But simply producing more pull requests is not a business strategy. Leaders need to ask whether those changes reduce customer problems, shorten delivery cycles, and improve product reliability.
A startup producing twice as many code changes but also twice as many serious bugs has not necessarily become more productive.
Research Methodology and Limits
This analysis uses GitHub’s publicly reported adoption shares, merge rates, and file-change figures. SFTechScene calculated the percentage-point changes, relative increases, and differences between reported groups.
No unpublished GitHub repository-level dataset was available for independent causal analysis. Our calculations are original secondary analysis, not a new experiment, and the results cannot be treated as San Francisco-specific adoption estimates.
GitHub also has a commercial interest in AI coding through Copilot. Its large platform dataset is valuable, but independent productivity evidence remains necessary.
Original SFTechScene Research #2: The Gap Between AI Adoption and Developer Trust Is the Real Story
Developers are adopting AI tools, but adoption does not always mean confidence.
Stack Overflow’s 2025 Developer Survey included responses from more than 49,000 developers across 177 countries. It offers an important look at how developers think about AI in their everyday work.
The survey found that 84% of respondents were using or planning to use AI tools. At the same time, 46% actively distrusted the accuracy of AI-generated output, while 33% expressed trust. Stack Overflow+1
AI Adoption and Trust Are Moving in Different Directions
Developer sentiment toward AI coding tools
Selected results from Stack Overflow’s 2025 survey. Adoption includes planned use.
The figures describe different survey questions, so they should not be added together. They reveal a growing gap between the willingness to use AI and the willingness to rely on its answers without careful checks.
SFTechScene Calculation: The Developer Trust Gap
Using Stack Overflow’s reported trust figures, we calculate a 13-percentage-point gap between developers who distrust AI accuracy and developers who trust it.
The survey also found that 66% of respondents experienced AI answers that were close to correct but still needed fixing. Another 45% identified time-consuming debugging of AI-generated code as a frustration.
Those problems help explain why companies cannot treat AI-generated code as free output. Every incorrect answer may create additional work for a developer who must find, understand, and fix the problem.
Why Almost-Correct Software Can Be More Dangerous Than Obviously Wrong Software
Consider two AI-generated features.
The first feature crashes during testing. The developer immediately knows something is wrong and investigates the failure.
The second feature works during ordinary testing but calculates taxes incorrectly for customers in one state. It may be released, used by customers, and discovered weeks later.
The second failure can be far more expensive because the system appears to work.
That is why software engineering includes much more than making an application run. Developers must understand unusual cases, business rules, security risks, and how different systems behave together.
The Business Opportunity Hidden in the Trust Gap
The growth of AI coding creates demand for tools and services that check code quality.
San Francisco startups could build businesses around automated testing, security review, code history analysis, system monitoring, and independent checks of AI-generated changes.
The key opportunity is not simply generating more code. It is making faster software development safe enough for businesses to trust.
Methodology and Limits
SFTechScene calculated the 13-point trust gap from the published survey shares and examined the reported frustration measures as supporting evidence.
The Stack Overflow survey is not a random sample of all developers. Its figures are global rather than San Francisco-specific, and the questions cover AI tools broadly rather than coding agents alone.
The results therefore indicate reported attitudes among respondents, not a verified local population rate.
Original SFTechScene Research #3: What Employment Data Reveals About the Future of Software Developers
One of the most common predictions about AI coding agents is that software development jobs will disappear.
Employment data tells a more complicated story.
The U.S. Bureau of Labor Statistics publishes projections for different technology occupations. Its 2025–2035 projections show that software developer employment is expected to grow, even while employment in the narrower category of computer programmers is projected to decline.
This difference matters because the two occupations are not identical.
A computer programmer typically focuses more directly on writing, changing, and testing code. A software developer may also design systems, understand business requirements, plan software features, and make decisions about how applications should operate.
AI’s growing ability to produce code could affect those occupations differently.
Software Developers Versus Computer Programmers: The Employment Outlook
Projected U.S. employment growth by technology occupation
BLS projections for 2025–2035. National figures, not San Francisco forecasts.
Source: U.S. Bureau of Labor Statistics, 2025–2035 employment projections. Bureau of Labor Statistics
The BLS projects software developer employment to increase from approximately 1.718 million jobs in 2025 to 1.893 million in 2035.
That represents an increase of roughly 175,000 jobs.
Meanwhile, employment for computer programmers is projected to decline by about 8,100 jobs, or 7.3%.
SFTechScene Calculation: The Software Development Employment Divide
Subtracting the projected computer programmer growth rate from the software developer growth rate produces a difference of 17.5 percentage points.
This does not prove AI is causing that divide. The BLS forecasts reflect many economic forces, including business demand, productivity, technology spending, and changes in how occupations are classified.
Nevertheless, the contrast provides a useful way to think about the future.
| Occupation | 2025 employment | 2035 projected employment | Projected change |
|---|---|---|---|
| Software developers | 1,717,800 | 1,892,600 | +10.2% |
| Computer programmers | 110,800 | 102,700 | −7.3% |
| Software QA analysts and testers | 187,600 | 198,200 | +5.7% |
| Computer and information research scientists | 38,600 | 47,000 | +21.8% |
Figures rounded from published BLS estimates. Categories are distinct occupations and should not be combined into an overall software engineering forecast. Bureau of Labor Statistics
The most reasonable interpretation is that the market may continue to need people who can design, improve, and manage software, even as some narrower programming activities become easier to automate.
A developer who only knows how to turn detailed instructions into code may face greater competition from AI tools.
A developer who can decide what needs to be built, understand a complex system, manage security risks, and verify results offers a broader set of skills.
Why These Projections Should Not Be Treated as a Guarantee
The BLS figures are national projections, not promises about individual careers or forecasts of San Francisco hiring.
They also cannot show exactly how AI technology will change between now and 2035.
A future AI agent might handle tasks that currently require expert engineers. Alternatively, cheaper software development could create more demand for software products and the people who manage them.
Both outcomes are possible, and they may happen at the same time.
The practical lesson for developers is to prepare for changes in job responsibilities rather than rely on either optimistic or pessimistic predictions.
Original SFTechScene Research #4: Why San Francisco Has More Financial Incentive to Adopt AI Coding Agents
The economics of software engineering are particularly important in the San Francisco Bay Area.
Local technology workers are highly paid, and startups must compete with established companies for skilled engineers. That makes even modest improvements in development productivity potentially valuable.
The latest BLS metropolitan wage release available for this analysis, published in July 2026 and covering May 2025, reports that workers in computer and mathematical occupations earned an average of $80.51 per hour in the San Francisco-Oakland-Fremont metro area.
The corresponding national average was $57.73 per hour. Bureau of Labor Statistics
SFTechScene Calculation: The Bay Area Technology Wage Premium
Computer and mathematical occupations: average hourly wage
BLS May 2025 wages, published July 2026. Includes multiple computer and mathematics occupations.
The Bay Area average is $22.78 higher per hour.
Dividing that difference by the national figure gives an estimated local wage premium of 39.5%.
There is another important difference. Computer and mathematical occupations accounted for 6.6% of employment in the San Francisco metro area, compared with 3.4% nationally.
SFTechScene calculates that the local employment share was approximately 1.94 times the national share.
These two figures demonstrate why software development productivity is such an important issue for the regional economy.
The Bay Area has both a relatively high concentration of technical workers and significantly higher average wages in the broader computer and mathematical category.
What Happens When AI Saves Engineering Time?
Consider a hypothetical San Francisco startup with five engineers.
Suppose each engineer spends 20 hours per month on tasks that an AI coding agent could help complete. If the company achieves a genuine 25% reduction in total time spent on those tasks, the monthly saving would be 25 engineering hours across the team.
At the BLS regional average of $80.51 per hour, that is equivalent to approximately $2,013 in wage value per month.
This calculation is not the same as actual cash savings. It does not mean the startup can immediately reduce payroll by that amount.
Instead, those hours could be redirected toward product improvements, customer requests, testing, or work that otherwise would have required additional staff.
The value depends on whether the saved time can be used productively.
A More Rigorous Cost Model for AI Coding Agents
Software teams should consider the complete cost of using AI rather than focusing only on the monthly subscription fee.
The total cost includes the time spent preparing instructions, checking generated work, fixing errors, running tests, and maintaining the resulting software.
We can express the net value of AI assistance as:
\[ V=(T_b-T_a)\times C_h-C_{ai}-C_r \]
Where:
- \(T_b\) is the total engineering time without AI.
- \(T_a\) is the total engineering time with AI, including review and correction.
- \(C_h\) is the relevant hourly labor cost.
- \(C_{ai}\) is the AI tooling cost.
- \(C_r\) is additional risk or failure cost.
The most important variable is the difference between total engineering time before and after adoption.
A coding agent that generates a feature in five minutes may still be expensive if a developer spends three hours repairing it.
SFTechScene Scenario Analysis: The True Value of Faster Coding
We built a simple model around a hypothetical project that normally requires 100 developer hours.
For illustration, we use the published $80.51 hourly wage for San Francisco’s broader computer and mathematical occupational group. This is a regional wage proxy, not a software developer-specific compensation rate or a fully loaded employment cost.
The model assumes the same final quality standard and ignores tool fees, benefits, and incident costs. It is designed to isolate the financial effect of engineering time.
Interactive SFTechScene engineering cost model
Adjust the baseline hours and hourly wage to calculate how different AI productivity outcomes affect labor costs.Hours without AIHourly wage ($)
| Productivity scenario | Hours with AI | Labor value gained/lost |
| AI slows work by 19% | 119 | −$1,530 |
| No net time change | 100 | $0 |
| AI saves 10% of time | 90 | +$805 |
| AI saves 25% of time | 75 | +$2,013 |
| AI saves 40% of time | 60 | +$3,220 |
Illustrative scenarios, not measured productivity outcomes. The 19% slowdown matches the point estimate in METR’s early-2025 experiment but does not predict performance for a new project. Negative amounts represent additional labor costs. All calculations exclude AI fees and other costs.
This model reveals an important economic truth.
A useful coding agent does not have to replace a developer to create meaningful value. Even a 10% reduction in total engineering time can matter for a startup with limited resources.
But an agent that increases review and debugging work can destroy that value just as quickly.
Why San Francisco Startups Need Their Own Measurements
There is no reliable universal AI productivity percentage that applies to every engineering team.
A developer working on a small web application may get excellent results from AI. Another working on a mature financial system may spend considerable time reviewing changes that are difficult to verify.
San Francisco founders should therefore measure gains by task type, project complexity, and quality rather than applying a single industry productivity claim to the entire company.
Research Methodology and Limitations
SFTechScene used publicly reported BLS wage and employment-share figures to calculate the San Francisco wage premium and relative employment concentration.
The cost scenarios are independently constructed sensitivity models. Their assumptions are explicit and they do not represent observed outcomes at a sampled group of San Francisco startups.
The wage measure covers computer and mathematical occupations, not software developers alone. It also excludes employer benefits, equity compensation, office costs, and other expenses. Therefore, the calculated dollar values should be treated as illustrative labor equivalents.
Original SFTechScene Research #5: Can AI Actually Make Experienced Developers Faster?
Many discussions about AI productivity rely on demonstrations where an agent builds an application in minutes.
Those demonstrations can show that AI is capable of impressive work. They do not necessarily establish how much faster a professional engineering team becomes.
To answer that question, researchers need to compare similar tasks completed with and without AI.
That is what METR attempted in a randomized controlled experiment published in July 2025.
The METR Experiment: An Important Warning About Productivity Claims
METR worked with 16 experienced open-source developers who were already familiar with the repositories they maintained.
The researchers examined 246 real programming tasks, assigning tasks randomly to conditions that allowed or prohibited AI assistance.
Developers expected the tools to reduce task completion time. The measured result was different.
Tasks completed with AI took 19% longer on average in the studied setting. METR
Why the Result Was Surprising
Before completing the tasks, developers expected AI to make them approximately 24% faster.
Even after finishing the experiment, they believed they had experienced a productivity improvement.
The measured slowdown highlights a problem with relying entirely on developer impressions.
AI can make work feel faster because it generates visible output quickly. Developers may not fully account for the time spent checking, rewriting, and understanding that output.
But the study has important limits. It involved a small group of experienced developers, mature repositories, and AI tools available in early 2025.
It cannot establish that AI coding agents slow down all developers or that newer systems have the same limitations.
The 2026 Update Changes the Picture
In February 2026, METR reported additional work examining developer productivity.
The researchers found some evidence of speedups with newer AI systems, but they also identified problems with participant selection and time measurement.
For developers who had participated in the earlier research, the later estimate suggested an 18% speedup. However, its confidence interval extended from a 38% speedup to a 9% slowdown.
For newly recruited developers, the estimated speedup was 4%, with a confidence interval spanning a 15% speedup to a 9% slowdown.
These intervals include zero, so the results do not establish a statistically clear positive effect for those groups. METR itself described the evidence as too weak to determine the size of the improvement with confidence. METR
What Businesses Should Learn From These Studies
The research does not support dismissing AI coding agents. It also does not justify assuming that every developer becomes dramatically more productive after adopting them.
The useful conclusion is that productivity is a measurement problem.
Companies should run controlled internal comparisons using representative tasks and record total completion time, testing effort, review time, and later corrections.
A tool that consistently saves time on routine tasks may deserve broader use. A tool that performs poorly on complex work may need tighter limits.
In other words, companies should let measured results determine where agents are deployed rather than expecting one tool to improve every form of software engineering.
Which Software Engineering Tasks Are Most Likely to Be Automated?
AI exposure depends heavily on the type of task.
Work that has clear instructions, limited scope, reliable tests, and visible success conditions is generally easier to delegate to an agent.
Tasks involving unclear goals, difficult decisions, major security risks, and complex coordination are harder to automate safely.
This distinction is more useful than trying to predict whether the entire profession will disappear.
A Practical Task Exposure Framework
SFTechScene developed the following qualitative framework to help engineering leaders decide where to test coding agents.
The classifications are analytical judgments based on task characteristics, not observed automation probabilities or validated predictions of job loss.
| Engineering activity | Exposure to agent automation | Human responsibility |
|---|---|---|
| Basic code generation | High | Confirm requirements and quality |
| Repetitive code changes | High | Review unusual cases |
| Documentation drafts | High | Verify accuracy |
| Simple unit tests | High | Assess meaningful coverage |
| Routine bug investigation | Medium–high | Confirm root cause |
| Code modernization | Medium–high | Check system behavior |
| Database changes | Medium | Protect data and performance |
| Security review | Medium | Validate risks and fixes |
| System architecture | Lower | Set constraints and tradeoffs |
| Product requirements | Lower | Understand customer needs |
| Incident management | Lower | Coordinate decisions and response |
| Business-critical engineering approval | Lower | Accept accountability |
The exposure ratings should be tested against real work. A simple-looking change can be difficult in a poorly documented system, while some complex tasks can be automated when the environment provides strong tests and clear rules.
Basic Coding Is Becoming Easier to Automate
A large amount of programming involves predictable patterns.
Developers create forms, connect services, transform data, update interfaces, and write code that follows familiar structures.
AI coding agents are well suited to attempting these tasks because they can draw on widely used programming patterns.
For junior developers whose work consists mostly of implementing clearly defined changes, this creates a challenge.
Companies may need fewer hours of manual coding to complete certain assignments. Junior engineers will increasingly need to show that they can understand and verify code rather than simply produce it.
Debugging Will Become a Shared Human-AI Activity
Debugging is the process of finding and correcting software problems.
An AI agent can search logs, compare files, identify suspicious changes, and suggest possible fixes. This makes it useful when the failure is easy to reproduce and the codebase has reliable tests.
The harder problem is deciding whether the agent has identified the real cause.
A broken customer checkout might appear to come from a recent software change. The actual cause could be a payment provider outage, an expired certificate, or an unexpected interaction between several systems.
Experienced engineers understand how to investigate those possibilities without creating additional failures.
Software Architecture Will Remain a High-Value Human Skill
Architecture involves deciding how the major parts of a software system work together.
These decisions can affect performance, reliability, security, and future development costs for years.
An AI agent can suggest architecture patterns and explain their advantages. It cannot automatically know every business constraint or accept responsibility for the outcome.
For example, a startup may need to choose between building a feature quickly and designing a system that can support millions of future users.
The correct decision depends on funding, customer demand, expected growth, and the cost of changing direction later.
That judgment goes beyond writing code.
Security Engineering May Become More Important
AI can generate code faster than humans can comfortably inspect it.
That creates a potential increase in the amount of code requiring security review.
Agents may also help identify weaknesses, explain unsafe patterns, and suggest fixes. But giving autonomous systems broad access to sensitive repositories, production data, or credentials introduces additional risk.
Engineering teams need strong access controls, isolated test environments, approval rules, and records of what agents change.
Security engineers who understand both software weaknesses and AI-assisted workflows may become especially valuable.
Testing Will Change From Writing Checks to Designing Confidence
AI agents can generate automated tests, but a large number of tests does not guarantee that a product works correctly.
A test may repeat a mistaken assumption in the code it is supposed to verify.
Imagine an AI agent implementing an incorrect refund calculation. If it generates tests based on the same incorrect rule, the tests may all pass.
A skilled engineer must understand the business requirement independently and check whether the test actually reflects it.
The future of testing may therefore involve less manual production of simple test cases and more careful design of what must be proven before software is released.
Will AI Coding Agents Replace Junior Software Developers First?
Junior developers are often considered especially vulnerable because many entry-level assignments involve well-defined tasks.
A new engineer might spend time creating basic interfaces, fixing simple defects, adding tests, or updating documentation. AI coding agents can already attempt many of these activities.
That creates a genuine risk for traditional entry-level hiring models.
However, there is an important problem with assuming companies can simply eliminate junior positions.
The Software Industry Still Needs a Way to Train Future Senior Engineers
Experienced developers do not appear fully trained.
They become valuable by working on real projects, making decisions, investigating problems, and learning from more experienced colleagues.
If companies stop hiring junior engineers, they may reduce their immediate staffing costs while damaging their future supply of experienced talent.
That could create a serious long-term problem for San Francisco’s startup ecosystem.
The Junior Developer Role Needs to Change
A junior engineer in an AI-assisted company should not be judged primarily by how many lines of code they can write.
Instead, employers should evaluate whether the person can understand a requirement, explain the proposed solution, identify mistakes, and test the result.
Junior developers should also learn how to use coding agents without becoming dependent on them.
For example, a new engineer might ask an agent to generate a feature but then be required to explain every important design decision before the change is approved.
This approach allows the company to benefit from faster code generation while continuing to develop genuine engineering skills.
What Entry-Level Developers Should Build to Stay Competitive
A strong portfolio in 2027 should demonstrate much more than a collection of applications built with AI.
A useful project should show how the developer identified a problem, selected an approach, tested the application, addressed security concerns, and improved the product after feedback.
Developers should document the mistakes their AI tools made and explain how they found and corrected them.
This demonstrates the ability to manage AI-generated work rather than merely request it.
How Senior Software Engineers Will Change in the Age of AI Agents
Senior developers will not be unaffected by automation.
In fact, AI coding agents may change their jobs substantially because experienced engineers are often responsible for coordinating work across multiple systems and team members.
An experienced engineer may eventually supervise several agents that work on different parts of a project.
Instead of implementing every change personally, the engineer could divide a project into smaller tasks, assign suitable tasks to agents, review results, and make final architectural decisions.
From Writing Code to Managing Software Outcomes
Consider a senior engineer responsible for improving a subscription platform.
The engineer might ask one agent to investigate slow database queries, another to prepare test cases, and a third to update part of the payment interface.
The human engineer would need to ensure that the proposed changes work together and do not interfere with customer billing.
This kind of workflow could increase the amount of work one person can supervise.
But it also makes the engineer responsible for understanding a larger volume of code, identifying hidden failures, and deciding which changes are safe.
Why Code Review Could Become a More Important Skill
As AI agents generate more changes, review may become a central part of software engineering.
GitHub’s October 2026 report reinforces this direction. It describes growing use of AI-assisted review and security tools alongside the rapid increase in agent-driven coding. The GitHub Blog
The challenge is that reviewing code requires attention, context, and experience.
A developer cannot safely approve a complex change simply because an AI system says it has passed tests.
Companies that produce more code than their engineers can properly review may create a new bottleneck.
The strongest teams will design workflows that make changes smaller, easier to understand, and simpler to reverse when something goes wrong.
Original SFTechScene Research #6: How Much Engineering Work Can a Company Safely Delegate to AI?
The central question for businesses is not what percentage of all code an agent can generate.
It is what percentage of engineering work can be delegated while maintaining acceptable quality, security, and cost.
These are very different questions.
To examine the issue, SFTechScene created a scenario-based delegation framework that separates engineering work into three categories.
The Three Levels of AI Coding Delegation
| Delegation level | Suitable work | Required human involvement |
|---|---|---|
| Assisted development | Complex code, uncertain requirements | Developer works directly with AI |
| Supervised delegation | Defined tasks with reliable tests | Developer reviews completed work |
| Restricted autonomy | Low-risk repetitive changes | Automated checks plus risk-based human approval |
These are proposed operating categories, not measured industry adoption levels.
A team should assign tasks according to the consequences of failure, not simply according to how capable an agent appears during demonstrations.
An Illustrative Engineering Workload
Consider a hypothetical startup with 1,000 engineering hours of planned work in a month.
Suppose the work is divided into three categories.
Illustrative allocation of 1,000 monthly engineering hours
SFTechScene hypothetical planning model, not an observed industry distribution.
■ Architecture, coordination and high-risk work
■ Complex implementation and debugging
■ Routine, well-defined work
If agents save 40% of the time spent on the first category, 15% on the second, and nothing on the third, the total saving would be:
\[ 300(0.40)+450(0.15)+250(0)=187.5 \]
The model produces 187.5 hours saved, equivalent to an 18.75% reduction in total project effort.
That is substantial. But it is far below the 40% improvement applied to the easiest work.
Why Task-Level Productivity Cannot Be Applied to the Entire Company
This example reveals a common mistake in AI business planning.
If AI makes one programming activity twice as fast, that does not mean the entire engineering team becomes twice as productive.
The organization may still need the same time for customer interviews, planning, design decisions, incident response, and management approval.
Other tasks may become slower when developers must review unfamiliar AI-generated code.
The correct company-level productivity measure must account for every important part of the software delivery process.
Methodology Behind the Delegation Model
The model uses hypothetical task shares and productivity changes rather than observed company data. Its purpose is to illustrate how task-level gains translate into overall engineering effort.
The calculation assumes that each category’s workload remains constant, that the estimated time savings include review and correction, and that work quality is unchanged.
The model is not a forecast of AI’s industry-wide labor impact. A real company would need task-level observations, quality measurements, and sensitivity testing before applying its results to staffing decisions.
Why AI Coding Benchmarks Cannot Tell Us Whether Developers Will Disappear
Coding benchmarks measure how well AI systems perform on selected programming problems.
They are useful because they make it possible to compare different systems using a defined set of tasks.
One well-known example is SWE-bench Verified, a set of 500 human-validated programming issues. AI systems attempt to solve the issues, and their performance is measured against the benchmark’s evaluation process. SWE-bench
A High Benchmark Score Is Not the Same as Replacing an Engineer
A benchmark may show that an agent can solve a large share of selected issues.
It does not necessarily show that the agent can independently manage a product for several years.
Real software engineering includes work that is difficult to capture in a short benchmark, such as understanding unclear customer requests, handling incidents, making long-term design decisions, and coordinating with other departments.
Benchmarks can also be sensitive to testing conditions, tool access, and the particular problems selected.
That is why a result achieved in a controlled evaluation should be treated as evidence of capability in that evaluation, not proof of full job replacement.
What San Francisco Companies Should Measure Instead
A practical engineering team should evaluate agents on its own codebase.
The tests should include normal development work, difficult bugs, old systems, and tasks involving several components.
Managers should measure whether the AI-produced changes are accepted, how long they take to review, whether they pass independent tests, and whether they cause problems after release.
This gives businesses a clearer picture of value than a leaderboard position alone.
How San Francisco Startups Can Adopt AI Coding Agents Without Damaging Software Quality
The most effective adoption strategy starts with controlled experiments.
A company should not give an autonomous agent unrestricted access to its entire software system simply because the latest model looks impressive.
A better approach is to introduce agents gradually, measure results, and expand their responsibilities only when the evidence supports doing so.
Step 1: Establish the Engineering Baseline
Start by measuring how the team works today.
Choose a representative sample of completed tasks from recent development cycles. Include routine changes, feature work, debugging, and tests.
Record the time spent on implementation, review, correction, and release.
Also examine how often work is reopened, how often urgent fixes are needed, and how frequently changes create problems for customers.
These measurements form the baseline against which AI-assisted work can be compared.
Step 2: Choose the Right Tasks for the First Experiment
The first pilot should focus on low-risk tasks with clear success conditions.
Suitable examples may include documentation updates, simple interface changes, routine tests, and narrowly defined bug fixes.
Avoid starting with payment systems, critical security changes, or major database migrations.
The aim of the first experiment is not to demonstrate the maximum possible autonomy. It is to establish whether the tools deliver repeatable value in a controlled setting.
Step 3: Compare Similar Tasks Fairly
Randomly assign suitable tasks to AI-assisted and ordinary development where practical.
Ensure that both groups include work of similar complexity and that the same quality checks apply.
Track total time rather than just code generation time.
A developer who spends five minutes generating a change and two hours fixing it has not completed the task in five minutes.
For small startups without enough tasks for a formal experiment, matched comparisons may be more practical. However, those comparisons should be described as observational because differences in task difficulty could affect the result.
Step 4: Build Clear Approval Rules
Every team should define what AI coding agents are allowed to do.
For example, agents might be permitted to create branches, change code in isolated environments, and run automated tests.
They might be prohibited from directly changing production systems, viewing unnecessary customer data, or modifying access permissions without human approval.
These controls protect the company even when the agent behaves unexpectedly.
Step 5: Measure Quality After Release
A change that passes automated tests can still fail in production.
Teams should track whether agent-assisted changes lead to customer complaints, errors, security problems, or urgent fixes.
The evaluation period should extend beyond the moment a change is merged.
For many companies, a useful approach is to monitor outcomes for at least one or two normal release cycles, then revisit the findings before expanding AI access.
Step 6: Expand Only Where the Results Are Consistent
If agents repeatedly save time without hurting quality, expand their use to similar tasks.
If benefits are inconsistent, identify why.
The cause may be weak instructions, poor test coverage, complex systems, or tasks that require more context than the agent can manage.
Rather than declaring AI a success or failure across the company, leaders should build an evidence-based map of where it helps.
A 90-Day AI Coding Adoption Plan for San Francisco Engineering Teams
The following plan is designed for a startup or mid-sized engineering organization introducing coding agents into an existing development process.
| Period | Priority | Deliverable |
|---|---|---|
| Days 1–15 | Measure current engineering performance | Baseline time and quality report |
| Days 16–30 | Set security and approval rules | Written AI usage policy |
| Days 31–45 | Run limited agent-assisted trials | Task-level comparison dataset |
| Days 46–60 | Evaluate speed, review effort and defects | Initial productivity assessment |
| Days 61–75 | Improve workflows and testing | Revised agent instructions and checks |
| Days 76–90 | Decide where to expand adoption | Approved deployment plan and ownership model |
The first month should establish what the company is trying to improve.
For example, a team might want to reduce time spent on simple bug fixes or shorten the delay between a completed feature and its release.
That goal should remain visible throughout the pilot.
The second month should produce measurable evidence. Engineering managers should resist the temptation to evaluate success by counting how many times employees used an agent.
The final month should turn the findings into operating rules. Tasks that consistently benefit from AI can receive wider access, while risky work remains subject to stricter controls.
How AI Coding Agents Could Reshape San Francisco’s Startup Economy
The impact of AI coding agents goes beyond individual engineering jobs.
Cheaper and faster software development changes who can start a company, how much funding a startup needs, and how quickly competitors can build similar products.
These changes could reshape Silicon Valley entrepreneurship.
Smaller Teams May Be Able to Build More Software
A startup that previously needed several developers to build an early product may be able to produce a working version with fewer people.
Founders who understand customers and can manage AI-assisted development may be able to test business ideas at lower cost.
This could help entrepreneurs launch products without raising large amounts of outside funding.
However, building a prototype and operating a successful software business are different challenges.
The company still needs customers, reliable systems, support, sales, security, and a product that solves a valuable problem.
AI may lower the cost of entry without lowering the difficulty of building a lasting business.
More Software Could Mean More Competition
When development becomes cheaper, more companies can attempt to solve the same customer problem.
This can be good for buyers because they may receive more choices and faster product improvements.
For startups, however, the competitive pressure increases.
A company that relies entirely on a feature competitors can reproduce easily may struggle to keep customers.
The strongest advantages may increasingly come from customer relationships, unique information, trusted service, specialized industry knowledge, and the ability to operate reliably.
The Value of Engineering Talent May Become More Uneven
AI may reduce the value of some repetitive programming work while increasing the importance of experienced technical judgment.
That could create a more divided engineering labor market.
Developers who can work effectively with AI, manage complex systems, and make important product decisions may command strong demand.
Others may face more competition if their skills are limited to routine implementation.
This is a plausible scenario, not an established forecast of future wages. Actual outcomes will depend on business demand, technology performance, labor supply, and how employers redesign their teams.
San Francisco Could Become a Center for AI Software Quality
The region already has a strong concentration of technical talent and companies building developer tools.
As coding agents become more common, the demand for reliable testing, code review, security, and monitoring could create new opportunities.
Instead of competing only to build the fastest code generator, startups could help businesses understand whether AI-generated software is safe and dependable.
This market may become particularly important for industries where software failure carries serious financial or legal consequences.
The Biggest Risks Facing AI-Driven Software Engineering
AI coding agents offer meaningful opportunities, but the risks are not limited to incorrect code.
They can also change how companies develop expertise, control sensitive systems, and understand their own products.
Technical Debt Could Grow Faster
Technical debt refers to software decisions that make future changes harder or more expensive.
AI-generated code can contribute to this problem when agents repeatedly choose short-term fixes without understanding the broader design.
A startup may initially celebrate the speed of development, only to discover that the resulting system has become difficult to maintain.
The solution is to require clear design standards, regular code reviews, and time for improving existing systems.
Security Problems Could Spread Across More Code
Agents may introduce unsafe patterns, expose sensitive information, or use software packages that create security concerns.
They may also be influenced by harmful instructions hidden in external files or other material they read.
Engineering teams should limit access, separate development from production, and review sensitive changes before deployment.
The more autonomy an agent receives, the more important these safeguards become.
Developers Could Lose Important Skills
A developer who relies entirely on AI to understand and write code may struggle when the tool produces an incorrect answer.
This becomes especially dangerous during major incidents, when teams need to diagnose unusual failures quickly.
Companies should continue training engineers in core programming, debugging, system design, and testing.
AI should reduce repetitive work without removing the learning experiences that make engineers capable of handling difficult problems.
Companies May Confuse Activity With Progress
AI tools can dramatically increase the volume of code changes.
But more commits, more files, and more pull requests do not necessarily mean better products.
Engineering leaders should focus on customer outcomes, reliability, and total cost.
If a company measures only activity, it may reward teams for producing large amounts of work that creates little business value.
What Software Engineering Jobs Could Look Like in 2030
Predicting the exact state of AI in 2030 is impossible.
But today’s evidence suggests several plausible changes in the way engineering teams operate.
Developers May Spend Less Time Producing Routine Code
More routine programming tasks may begin with AI-generated drafts.
Developers will spend more of their time setting requirements, reviewing changes, investigating failures, and coordinating complex work.
The amount of change will vary by industry and software environment.
A team building a simple internal dashboard may adopt much more automation than one responsible for critical transportation systems.
Software Engineers May Supervise Multiple Agents
Some engineers could manage several coding agents working on separate tasks.
That would make planning, task design, and review increasingly valuable skills.
However, the number of agents one engineer can supervise safely will depend on the difficulty of the work and the quality of the tools.
A company should not assume that assigning ten agents to one engineer automatically multiplies productivity by ten.
Teams May Become Smaller but More Specialized
Some startups may be able to operate with fewer general-purpose programmers.
At the same time, they may need stronger expertise in security, architecture, infrastructure, and product design.
The result could be leaner teams with broader responsibilities.
This does not mean every company will reduce engineering headcount. Lower development costs may also encourage businesses to build more software than they previously could afford.
The Meaning of a Good Software Engineer Will Change
A strong engineer will still need technical knowledge.
But the ability to manually produce large amounts of code may become less important than the ability to understand systems and judge whether proposed solutions are correct.
Engineers who combine technical depth with product knowledge, communication, and responsible AI use may be especially well positioned.
What Software Developers Should Learn Now to Stay Relevant
Developers do not need to abandon programming to prepare for AI.
They need to build skills that help them solve problems even when code generation becomes easier.
Learn to Work With AI Without Depending on It
Become comfortable using coding agents for investigation, implementation, testing, and documentation.
At the same time, practice explaining and reviewing the changes they produce.
A useful habit is to ask an agent to propose a solution, then independently evaluate the assumptions and risks before accepting it.
Strengthen System Design Skills
Learn how databases, services, networks, and application components interact.
Understand how systems behave under heavy load and what happens when individual components fail.
These skills help developers judge whether a proposed solution will work beyond a simple demonstration.
Become Better at Testing and Debugging
Develop the ability to design tests that identify meaningful errors.
Learn how to investigate failures using logs, measurements, and controlled experiments.
As AI-generated code becomes more common, the ability to find mistakes may become as important as the ability to create features.
Understand the Business Behind the Software
Learn why customers use the product and what problems the company is trying to solve.
A developer who understands the business can make better decisions about which features matter and how they should work.
That knowledge is difficult to replace with generic code generation alone.
Learn Security and Responsible AI Practices
Understand access controls, secure software design, protection of sensitive information, and the risks of allowing automated tools to act independently.
These skills are useful even for developers who do not specialize in security.
They help engineers recognize when an otherwise convenient AI workflow could create serious problems.
What San Francisco Founders Should Do Before Reducing Engineering Headcount
The availability of AI coding agents should not automatically trigger a decision to reduce developer staffing.
A better approach is to determine what the company can actually deliver with its existing team and where AI produces lasting productivity gains.
Founders should first examine whether engineering delays come from coding itself.
Sometimes the real problem is unclear product requirements, slow approvals, changing priorities, or weak coordination between departments.
AI code generation cannot solve those problems on its own.
Companies should also consider the cost of losing experienced engineers.
A senior developer may hold important knowledge about old systems, unusual customer requirements, and past technical decisions.
Replacing that knowledge with an AI tool may prove much harder than replacing routine code production.
Finally, founders should distinguish between reducing unnecessary work and removing essential responsibility.
Even highly automated engineering organizations need people accountable for product behavior, security, reliability, and customer outcomes.
Frequently Asked Questions About AI Coding Agents and Developer Jobs
Will AI replace software engineers completely?
There is currently no convincing evidence that AI coding agents can replace every responsibility of a professional software engineer. Agents are already automating parts of programming, but engineering also requires decisions about architecture, security, customer needs, and reliability.
The degree of automation could increase considerably, so developers should prepare for changing responsibilities rather than assume today’s limits will remain permanent.
Will AI replace junior developers?
Routine entry-level programming work is exposed to automation, which could change hiring patterns and reduce demand for some traditional junior assignments. However, companies still need to develop future engineers, and junior employees can contribute to testing, investigation, product work, and supervised AI workflows.
The strongest entry-level candidates will be able to demonstrate understanding and judgment, not just code generation.
Are AI coding agents faster than human developers?
Sometimes, but not consistently across all kinds of work. GitHub’s 2026 report shows rapidly growing agent use, while METR’s controlled research demonstrates why tool adoption and productivity gains are not the same thing. The GitHub Blog+2
The answer depends on the task, the tools, the developer, and the amount of correction required.
Which software engineering skills are most valuable in the AI era?
System design, debugging, security, testing, product understanding, and the ability to review AI-generated work are likely to remain important.
Developers also benefit from learning how to divide complex problems into clear tasks and decide which tasks can safely be delegated.
Will companies need fewer programmers in the future?
Some organizations may need fewer hours of manual programming for the same amount of work. However, lower development costs could also increase demand for new software products.
The BLS currently projects growth in the broader software developer occupation and a decline in the narrower computer programmer occupation through 2035. These national projections should not be mistaken for a precise forecast of AI-driven job losses. Bureau of Labor Statistics
Should San Francisco startups use AI coding agents?
Yes, when there is a clear business use case and appropriate oversight.
The best approach is to run measured pilots, establish security rules, compare total engineering time, and expand agent use only where it consistently produces acceptable results.
Final Takeaway: AI Coding Agents Will Change What Developers Do, but Reliable Software Still Needs Engineering Judgment
The future of software engineering is unlikely to be a simple contest between humans and machines.
AI coding agents are already taking over a growing share of the work involved in creating software changes. GitHub’s latest data shows how rapidly developers have begun using agents as part of their normal workflows.
But generating code and delivering dependable software remain different challenges.
The original SFTechScene analysis in this article highlights four important findings.
First, agent-started pull requests grew from 17% to more than 40% of GitHub pull requests between March and September 2026. That shows a major change in how software work begins.
Second, developer trust remains a serious limitation. Stack Overflow’s survey found that more respondents distrusted AI accuracy than trusted it, reinforcing the need for independent checks.
Third, the labor market outlook is not uniformly negative. BLS projections show growing demand for software developers even while the narrower computer programmer occupation is expected to decline.
Fourth, San Francisco’s relatively high technology wages create a strong incentive to improve engineering productivity. However, the financial value depends on reducing total time and maintaining quality, not just generating code faster.
None of these findings proves that traditional developers will disappear. Together, they point toward substantial changes in how software teams work.
For San Francisco startups, the winning strategy is to combine the speed of AI coding agents with strong human judgment.
For developers, the safest long-term investment is to become better at understanding problems, designing systems, verifying results, and making decisions that matter to customers.
The next generation of great software engineers may write less code by hand. Their work may instead focus on deciding what should be built, directing intelligent tools, and ensuring the finished product deserves to be trusted.
That is a meaningful change in the profession, but it is not the same as the end of software engineering.
Research Sources and Reproducibility Notes
Research cutoff: October 29, 2026. The SFTechScene analyses above are original calculations and illustrative models based on public information. They are not new surveys, locally collected developer samples, or independently replicated field experiments.
| Public source | Data used in this article |
|---|---|
| GitHub Octoverse 2026 | Agent-started pull requests, merge rates, developer activity |
| Stack Overflow Developer Survey 2025 | AI adoption, trust, workflow frustrations |
| METR developer productivity experiment | Randomized comparison of AI-assisted and unassisted work |
| METR February 2026 update | Later experimental estimates and research limitations |
| BLS employment projections | National technology occupation outlook for 2025–2035 |
| BLS San Francisco wage data | May 2025 metropolitan wages and occupational shares |
| SWE-bench Verified | Benchmark definition and evaluation context |
How SFTechScene Calculated the Original Findings
The adoption analysis compared GitHub’s March and September 2026 agent-started pull request shares. Because the September figure was reported as more than 40%, calculations using 40% are conservative lower bounds, not exact growth estimates.
The trust analysis used published Stack Overflow percentage shares and calculated the difference between reported trust and distrust. These results are descriptive and cannot establish the causes of developer attitudes.
The employment analysis used the latest BLS 2025–2035 occupation projections and compared their reported growth rates. The San Francisco economic analysis used BLS May 2025 metropolitan wage and employment shares, with the correct occupational scope retained.
The financial and delegation models used explicitly stated assumptions so readers can see how changes in productivity affect total labor effort. The example task allocations, efficiency gains, and cost savings are scenarios rather than observed startup outcomes.
The central research limitation is geographic: public sources provided strong national, global, and platform-wide evidence, alongside San Francisco-specific labor figures, but not a representative local dataset linking individual companies’ AI coding-agent usage to engineering productivity or employment outcomes.
A rigorous next stage for SFTechScene research would be a San Francisco company-level study using task records, measured engineering hours, defect outcomes, and matched AI-assisted and non-AI workflows. Until such data is collected, claims about the precise number of San Francisco developer jobs that AI will replace would be speculative.
