Software development is entering one of its biggest periods of change. For years, developers wrote code, tested it, fixed problems, and repeated the process until their software worked. Artificial intelligence helped with small parts of that work, but people still handled most of the steps.
Now, a different way of building software is taking shape. Autonomous coding agents can read existing projects, plan changes, write code across many files, run tests, find problems, and prepare finished work for a developer to review.
This shift is creating a new approach called agentic engineering, where developers spend less time writing every line of code and more time guiding, checking, and improving work completed by AI agents.
The change is especially important for San Francisco, where startups compete to launch products quickly, attract skilled engineers, and make limited funding last longer. A small engineering team that uses coding agents well may be able to build and test more ideas without hiring a large team.
However, there is an important difference between generating code and delivering software that customers can trust. AI agents can make mistakes, introduce security problems, misunderstand business needs, and create changes that become expensive to maintain.
The real question is no longer whether AI can write software. It is whether companies can build a reliable engineering process around AI that produces better software at a lower total cost.
New data suggests this change is happening quickly. GitHub’s October 2026 Octoverse report found that more than 40% of pull requests on its platform began with an agent’s first draft in September, compared with 17% in March. That is a major change in how software work begins, although it does not mean agents independently completed or safely deployed all those changes. The GitHub Blog+1
This article examines how agentic engineering works, the tools driving adoption, the tasks that are becoming easier to automate, and the challenges that startups must solve. It also includes original SFTechScene calculations using published GitHub data, Stack Overflow’s 2026 Developer Survey, and an independently constructed engineering cost model.
The Short Version: Agentic Engineering Is Changing Software Development From Writing Code to Managing Outcomes
The biggest change in software engineering is not that developers have a faster way to type code. It is that software tools are increasingly capable of carrying out entire development tasks with less direct guidance.
An engineer can describe a feature, let an agent study the project, and receive a proposed set of changes with test results. The engineer then checks whether the solution works, meets the business need, and follows the company’s standards.
Several developments explain why this matters now.
First, coding agents have become much better at working across large projects. They can examine how different parts of an application connect instead of treating every file as a separate task.
Second, these agents can use development tools. They can run commands, execute tests, inspect errors, and revise their own work. That makes them more useful than older AI systems that simply suggested code.
Third, developers are starting to use AI as part of their normal work rather than as an occasional helper. Stack Overflow’s October 2026 Developer Survey found that 65.9% of respondents used AI coding assistants or coding agents at work, while 26.2% used AI agents or automated workflows. These categories can overlap, but the difference shows that broad AI assistance is more common than wider agent-based automation. Stack Overflow Developer Survey+1
Fourth, companies are beginning to rethink what engineering productivity means. Instead of measuring how much code a developer writes, they increasingly need to consider how quickly teams deliver useful changes without increasing bugs or operating costs.
For San Francisco startups, this creates an opportunity to reduce the time between a business idea and a working product. But the largest benefits are likely to come from companies that combine automation with disciplined testing, strong technical leadership, and careful review.
What Is Agentic Engineering?
Agentic engineering is an approach to building software in which AI agents perform parts of the development process while human engineers guide the goals, set limits, and verify the results.
Traditional programming requires developers to decide what the software should do and then implement most of the technical steps themselves. Agentic engineering allows them to hand over more of the implementation process.
For example, imagine a San Francisco startup building software for small accounting firms. Customers want a feature that automatically identifies overdue invoices and sends reminders.
Under a traditional process, developers might inspect the existing billing system, build the new feature, write tests, and connect it to the customer dashboard. With agentic engineering, an engineer can explain the requirements and ask an agent to prepare a working version.
The agent may inspect the database, identify the correct files, add the new feature, create tests, and report which checks passed. The engineer still needs to verify that reminders go to the correct people, financial information stays protected, and the feature behaves properly when something goes wrong.
That division of work is the foundation of agentic engineering.
How Agentic Engineering Differs From Traditional AI Coding
AI-assisted coding has existed for several years, but not all AI coding tools work in the same way.
Some suggest the next line of code. Others answer questions about a project. More advanced agents can carry out multi-step tasks and use tools without requiring a new instruction after every action.
| Development approach | How it works | Human responsibility |
|---|---|---|
| Traditional programming | Engineer writes and tests code | Most technical work |
| AI code completion | AI suggests code while someone types | Accepting and correcting suggestions |
| Conversational AI coding | Developer asks AI to explain or generate code | Applying and testing results |
| Agentic coding | AI reads files, edits code, and runs tests | Reviewing and guiding the task |
| Agentic engineering | A team organizes development around agent-led tasks | Architecture, quality, security, and delivery |
The final category is the most important. Agentic engineering is not simply a product feature inside a coding tool. It is a broader change in how people organize software development.
Why the Word “Agentic” Matters
An AI agent is different from a normal chatbot because it can take actions toward a goal.
A chatbot may explain how to repair a broken login system. A coding agent may inspect the login code, identify a possible defect, modify the relevant files, run tests, and present the proposed fix.
The agent can also respond to feedback from the tools it uses. If a test fails, it may read the error, change the code, and try again.
However, the ability to take several steps does not mean the agent understands every business requirement. It can follow the wrong plan or optimize for passing tests while missing an important customer need.
That is why experienced engineering judgment remains valuable.
Why Autonomous Coding Agents Are Becoming Important in 2026
The rise of agentic engineering is being driven by improvements in AI capability, changes in developer behavior, and growing pressure on companies to build software more efficiently.
The strongest evidence comes from looking at actual development activity rather than relying only on product announcements.
GitHub’s 2026 Data Shows a Rapid Change in Coding Workflows
GitHub’s 2026 Octoverse report, published in late October, examined activity from October 1, 2025, through September 30, 2026.
The report found that developers increasingly begin coding tasks by giving instructions to agents and then reviewing their changes. GitHub also reported that agent-started pull requests grew to approximately 110 million in September 2026 alone. The GitHub Blog
Share of GitHub pull requests started by coding agents
March value is 17%; September is reported as more than 40%, plotted at 40% as a conservative lower bound.
Source: GitHub Octoverse 2026. *September’s published share exceeds 40%; the chart uses 40% as a lower bound, not an exact measurement.
These numbers do not prove that coding agents are more reliable than developers. They do show that the process of starting software changes has shifted toward automation.
GitHub also reported that agent-involved pull requests were more likely to change multiple files. About 87% did so, compared with 79% of pull requests without detected agent involvement.
That matters because real software changes often require developers to update several connected parts of an application. An agent that can work across those parts is more useful than one that generates isolated code snippets.
AI Coding Tools Are Moving Into Everyday Development
Stack Overflow’s 2026 Developer Survey provides another view of the shift. The survey received more than 30,000 responses from technologists across 169 countries, although individual questions had smaller response counts.
Among respondents to the relevant coding-agent question, Claude Code had been used by 65.5%, GitHub Copilot by 58.7%, OpenAI Codex by 29.5%, and Cursor by 25.5% during the previous year. Respondents could select multiple tools, so these figures are not exclusive market shares. Stack Overflow Developer Survey+1
AI coding tools used by 2026 survey respondents
Shares are among 12,255 respondents to a multiple-choice question, so totals exceed 100%.
Source: Stack Overflow Developer Survey 2026, AI coding agents question, n = 12,255. Self-selected survey responses are not a measure of global market share.
These results also show that the market has room for several types of tools. Some developers prefer agents that work in a coding editor, while others want systems that operate through a terminal, cloud environment, or assigned task.
For startups, the important choice is not necessarily which product is most popular. It is which tool performs the team’s actual work accurately, safely, and at a reasonable cost.
Original SFTechScene Research #1: How Quickly Is Agentic Engineering Changing Real Software Work?
The public discussion around AI coding often focuses on demonstrations. A company shows an agent building an application, and the demonstration creates the impression that most engineering work can now be automated.
We wanted to test a more useful question: Are coding agents becoming part of the normal software development process, and what does the public data actually tell us about that change?
Our Research Methodology
SFTechScene conducted an original secondary analysis using GitHub’s 2026 Octoverse figures. We used published observations rather than estimates of future behavior.
Our analysis examined three measures: the share of pull requests started by agents, the share of pull requests that changed multiple files, and the share merged within two weeks.
We calculated percentage-point differences and relative ratios. Where GitHub published a rounded figure or a lower bound, we preserved that uncertainty instead of treating the number as exact.
The dataset covers activity on GitHub, not a representative sample of San Francisco startups. We therefore use the findings to understand the broader engineering environment facing SF companies, rather than claiming they measure local adoption.
Finding #1: Agent-Started Pull Requests Grew by More Than 135% Relative to Their March Share
GitHub reported that agent-started pull requests represented 17% of pull requests in March 2026 and more than 40% in September.
Using 40% as a conservative lower bound, we calculated:
\[ \frac{40-17}{17}\times100\approx135.3\% \]
This means the reported share increased by more than 135% relative to its March level over six months.
In absolute terms, the increase was more than 23 percentage points. The September share was more than 2.35 times the March share.
These calculations describe the growth of agent involvement in starting pull requests, not a growth rate for the number of jobs automated.
Finding #2: Agent-Involved Changes Were Eight Percentage Points More Likely to Touch Multiple Files
GitHub’s published data showed that 87% of agent-started pull requests changed multiple files, compared with 79% of pull requests without detected agent involvement.
Our calculation produces an eight-percentage-point difference, or roughly a 10.1% relative increase.
That difference suggests agents are being used in tasks that span more than one file. It does not prove those tasks are more complex, because a change to multiple files can still be simple.
Finding #3: The Reported Merge-Speed Gap Changed Direction During 2026
In February 2026, approximately 83% of agent-involved pull requests were merged within two weeks, compared with 86% of pull requests without detected agent involvement.
By September, the figures were approximately 90% and 86%, respectively.
Pull requests merged within two weeks
■ Agent-involved
■ No detected agent involvement
Source: GitHub Octoverse 2026. Published percentages are approximate. Merge speed alone does not establish code quality.
Our calculation shows a seven-percentage-point improvement in the agent-involved group’s reported two-week merge share. The comparison group stayed near 86%, producing a seven-point change in the difference between the groups.
That is encouraging for workflow speed, but it does not establish cause and effect. Projects, task types, reviewers, and users could have changed between February and September.
SFTechScene Research Summary
| Measure | Earlier observation | Later or comparison observation | Original SFTechScene calculation |
|---|---|---|---|
| Agent-started PR share | 17% in March | Over 40% in September | Over 23 percentage points higher |
| Relative change in share | 17% baseline | Over 40% | Over 135% increase |
| PRs changing multiple files | 79% without detected agent involvement | 87% agent-started | +8 percentage points |
| Agent-involved PRs merged within two weeks | 83% in February | 90% in September | +7 percentage points |
| Merge-rate advantage | −3 points in February | +4 points in September | +7-point change |
Source data: GitHub Octoverse 2026.
What These Findings Mean for San Francisco Startups
The evidence suggests that coding agents are becoming a normal way to begin and prepare software changes. Teams that ignore this development may miss useful improvements in how they organize repetitive engineering work.
However, the data also highlights the importance of review. A pull request that is merged quickly can still contain mistakes, and an agent can produce large amounts of code without solving the correct problem.
For SF founders, the best response is to experiment with agent-based development while measuring the results. Companies should avoid assuming that rising adoption automatically means lower engineering costs.
How Autonomous Coding Agents Actually Build Software
To understand the value of agentic engineering, it helps to examine what happens after a developer gives an agent a task.
A good agentic workflow is not a single instruction followed by a perfect application. It is a series of steps in which the system gathers information, makes decisions, acts, checks the results, and adjusts its approach.
Step 1: Understanding the Developer’s Goal
The process begins with a clear description of what needs to change.
Suppose a startup wants to add an option that lets customers export monthly reports as PDF files. A useful instruction should explain which users can access the feature, what information must appear in the report, and how the completed feature should behave.
A vague request such as “add PDF exports” leaves important decisions unresolved. The agent may create a feature that technically works but exposes private information or produces reports in the wrong format.
Clear requirements reduce that risk before development begins.
Step 2: Reading the Existing Codebase
The agent examines the parts of the project related to the task. It may inspect files, search for existing functions, read technical documentation, and identify how different parts of the software connect.
This is where coding agents can offer more value than simple code generators. They can use the existing project as context rather than producing a general solution that may not fit.
However, large projects can contain outdated documentation and confusing patterns. Agents need useful context, and developers must check whether they have understood the correct parts of the system.
Step 3: Building a Plan
For complex tasks, the agent can create a plan before changing the software.
The plan might identify which files need updates, which tests should be added, and which parts of the system could be affected. A developer can review the plan before allowing the agent to proceed.
This step is particularly valuable for projects involving payments, customer accounts, or sensitive data. Fixing a bad plan before code is written is usually easier than repairing the results afterward.
Step 4: Writing and Modifying Code
After the plan is accepted, the agent makes the required changes.
A single feature may involve updating the user interface, adding a server function, changing a database query, and creating new tests. An agent can work across these connected parts instead of requiring separate instructions for each file.
For well-defined tasks, that can reduce the time engineers spend on routine implementation. More difficult changes still require technical guidance, especially when they affect the design of the wider system.
Step 5: Running Tests and Responding to Errors
Coding agents can run existing tests and examine failures. Some can also write new tests to check the behavior they have introduced.
If a test reports an error, the agent can inspect the result and attempt a fix. This creates a feedback loop that allows the tool to improve its first solution.
Yet passing tests are not proof that a feature is correct. A test may overlook an important business rule, and an agent can write a weak test that approves its own incorrect code.
Step 6: Preparing Work for Human Review
The agent should finish by showing what changed, which tests were run, what remains uncertain, and where a reviewer should focus.
A developer then checks the work and decides whether it should be merged into the main project. For high-risk changes, another engineer or security specialist may need to approve it.
This final step is what turns automated code generation into a controlled engineering process.
The AI Coding Tools Driving the Rise of Agentic Engineering
The market now includes several approaches to autonomous development. Some products help developers work inside their usual coding environment, while others are designed to take on larger assigned tasks.
These categories overlap, and product capabilities change quickly. Startups should test current versions against their own projects rather than choosing a tool from a marketing comparison.
Claude Code: Working Across Real Software Projects
Claude Code is designed to work with existing software projects, including reading code, making changes, and using development tools.
Its appeal is that engineers can describe an outcome and let the agent work through several implementation steps. This can be useful for bug fixes, test creation, code cleanup, and features that require changes across multiple files.
Teams still need to control which commands the agent can run and which information it can access. For sensitive projects, permissions and review rules matter as much as the quality of the code it generates.
OpenAI Codex: Delegating Coding Tasks
OpenAI Codex supports agent-led software development through coding environments and workflows where developers assign implementation tasks.
A developer can ask an agent to inspect a project, make a change, run checks, and report the result. This is useful when an engineer wants to delegate a bounded task while continuing other work.
OpenAI’s security guidance also describes using sandboxes and approval controls to limit what an agent can change or access. Such limits help reduce the risk of an agent affecting unrelated systems. OpenAI
Cursor: Bringing Agents Into the Coding Editor
Cursor focuses on making AI part of the developer’s normal coding environment.
Developers can examine code, request changes, and work with agent features without moving every task into a separate system. This can make AI adoption easier for teams that want to preserve a familiar development process.
For SF startups with existing engineering teams, this approach can be attractive because it changes how developers work without necessarily requiring a complete redesign of their tools.
GitHub Copilot: Connecting AI With Collaborative Development
GitHub Copilot brings AI assistance into the development environments and workflows engineers already use.
GitHub’s 2026 report says that 55% of Copilot’s monthly active users were using agentic features, compared with 35% one year earlier. It also reported strong growth in its cloud agent, which can work on assigned tasks more independently. The GitHub Blog
The broader opportunity is to connect AI-generated changes with the review and testing process that engineering teams already follow.
Devin: Assigning Larger Engineering Tasks
Devin, developed by Cognition, represents a more task-oriented approach to AI software engineering.
Rather than concentrating only on code suggestions, the product is built around completing development work through an agent-based process. This makes it relevant to companies exploring how much engineering work can be delegated.
However, using an autonomous agent does not remove responsibility for requirements, security, testing, and system design. A startup still needs engineers who understand the product and can check the outcome.
Which Type of Agent Should a Startup Choose?
| Startup need | Suitable approach | Main factor to test |
|---|---|---|
| Improve everyday coding | AI-enabled editor | Developer workflow |
| Fix clearly defined bugs | Repository-aware coding agent | Correctness of fixes |
| Create tests | Coding agent with test tools | Meaningful test coverage |
| Delegate isolated tasks | Task-based or cloud agent | Supervision required |
| Modernize existing software | Agent with strong project context | Understanding old code |
| Automate development pipelines | Agent connected to review systems | Security and permissions |
The best product is not automatically the one that completes the most tasks without asking questions. For a real business, an agent that asks for approval before a dangerous change may be more valuable than one that acts without limits.
Original SFTechScene Research #2: The Gap Between AI Coding Adoption and Broader Agent Automation
One of the biggest sources of confusion in the AI coding market is the assumption that using AI means a developer is already working autonomously.
The 2026 Stack Overflow data makes it possible to examine that assumption.
Research Methodology
We used the published results for the survey question asking respondents which AI tools they currently use at work. The relevant response base contained 17,464 respondents.
We selected two categories: AI coding assistants or coding agents, and AI agents or automated workflows.
Because the question allowed multiple answers, we calculated the difference in reported category prevalence, not a count of people belonging exclusively to one group.
Our Findings
Reported AI tool categories used at work
Source: Stack Overflow Developer Survey 2026, n = 17,464. Categories overlap and are not mutually exclusive.
Our calculations produce three useful findings.
| Original calculation | Result | Interpretation |
|---|---|---|
| Difference between reported categories | 39.7 percentage points | Coding assistance is much more common |
| Coding-assistant share divided by agent/workflow share | 2.52× | The first category is reported about 2.5 times as often |
| Respondents selecting coding assistants or agents | 11,509 | Substantial use in the survey sample |
| Respondents selecting agents or workflows | 4,582 | Broader automation is less widely reported |
The difference does not show exactly how many developers have progressed from simple assistance to autonomous work. The categories have different meanings and can include the same people.
It does, however, challenge the idea that widespread AI use means most engineering work has already become agent-led.
Why This Gap Creates an Opportunity for San Francisco
Many startups already have engineers using AI coding tools. Fewer may have established a complete process for assigning, checking, and managing work performed by agents, although the global survey does not measure that local difference.
That leaves room for companies that can make agent-led engineering easier to manage.
The opportunity is not limited to building new AI models. Startups can create useful products around test automation, code review, security checks, task planning, development records, and the handoff between human engineers and AI agents.
For a software company serving other businesses, these supporting systems may be just as important as the coding agent itself.
Original SFTechScene Research #3: When Does Agentic Engineering Actually Save Money?
A common argument for coding agents is that they can reduce software development costs. That may be true for some tasks, but the price of generating code is only one part of the calculation.
An agent that writes code in ten minutes can still be expensive if an engineer spends three hours reviewing and correcting it. Companies need to measure the complete cost of delivering working software.
To make this question useful for San Francisco founders, SFTechScene developed a transparent cost model.
Research Methodology: Measuring the Full Engineering Task
Our model compares the human time required to complete a task manually with the human time required when an agent performs the first implementation.
We include setup, direct human involvement, review, and expected rework. We then apply an illustrative hourly engineering cost to estimate potential financial outcomes.
This is an original scenario analysis, not an experiment using observed SF company payroll records or actual coding-agent performance logs.
The purpose is to identify the conditions under which automation creates real savings.
The main formula is:
\[ T_{\text{agent}}=A+R+(p\times F)+S \]
Where:
- \(A\) is the developer’s direct time guiding the agent.
- \(R\) is the time spent reviewing its work.
- \(p\) is the probability that significant rework is needed.
- \(F\) is the human time required for that rework.
- \(S\) is the setup time allocated to the task.
For this model, unattended agent runtime is tracked separately because it may affect delivery speed without consuming the same amount of engineer time. Subscription, API, and infrastructure charges are also accounted for separately.
Scenario A: A Well-Defined Engineering Task
Consider a startup that frequently adds small features to an existing business application.
Assume a developer normally needs three hours to complete a typical task. With an AI agent, the engineer spends 0.8 hours guiding the implementation, 0.7 hours reviewing it, and an allocated 0.3 hours on setup.
Suppose 20% of agent-assisted tasks require an additional two hours of human rework.
| Time component | Illustrative value |
|---|---|
| Traditional engineering time | 3.0 hours |
| Direct human time with agent | 0.8 hours |
| Review time | 0.7 hours |
| Expected rework | 0.4 hours |
| Allocated setup | 0.3 hours |
| Expected total human time with agent | 2.2 hours |
| Expected saving per task | 0.8 hours |
The saving is approximately 26.7% of the traditional human time.
That is a meaningful improvement, but much smaller than the reduction implied by comparing AI code-generation time with manual coding time alone.
Scenario B: A Difficult Task With Heavy Review
Now consider a change to a complex payment system.
Keep the same three-hour manual baseline for comparison, but increase human review to one hour, expected rework probability to 40%, and allocated setup to 0.5 hours.
Expected human time becomes:
\[ 0.8+1.0+(0.4\times2.0)+0.5=3.1 \]
In this scenario, using the agent increases expected human work by approximately 3.3%.
The difference is not a flaw in the calculation. It shows why coding-agent economics depend heavily on task selection and the quality of review.
Expected human engineering time per task
SFTechScene illustrative model. These are assumed scenarios, not measured performance results.
What Would the Savings Look Like Across 40 Tasks?
Suppose a San Francisco startup completes 40 similar, well-defined engineering tasks in a month.
Using Scenario A, the expected time saving would be 32 human hours.
If the company’s fully loaded engineering cost were an illustrative $110 per hour, those hours would have a value of $3,520.
Assume the agent tools and related computing costs total another $400 for the month. The model would then produce an estimated net labor-cost benefit of $3,120.
| Monthly calculation | Estimated result |
|---|---|
| Eligible tasks | 40 |
| Human hours saved per task | 0.8 |
| Total human hours saved | 32 |
| Illustrative hourly engineering cost | $110 |
| Gross value of saved time | $3,520 |
| Additional agent-related cost | $400 |
| Estimated net benefit | $3,120 |
These figures should not be treated as a forecast for an actual company. They also assume that the saved hours create productive value elsewhere rather than becoming unused capacity.
The Most Important Finding: Review Time Can Eliminate the Savings
The model shows that agentic engineering has an important financial limit.
If reviewing, correcting, and managing AI-generated changes takes nearly as long as completing the task manually, automation produces little benefit. The same is true when agents repeatedly fail because their instructions are unclear.
For startups, the goal should be to reduce the total cost of completing a correct task rather than simply increasing the amount of code generated.
That means selecting suitable work, providing clear requirements, improving automated tests, and avoiding tasks where failure would create costly damage.
Original SFTechScene Research #4: Why Faster AI Coding Does Not Always Mean Faster Software Development
The promise of agentic engineering becomes more complicated when we examine controlled studies of developer productivity.
In 2025, METR published a randomized study involving 16 experienced open-source developers working on 246 tasks in projects they knew well.
The researchers assigned tasks to AI-allowed and AI-disallowed conditions. They found that allowing the early-2025 AI tools used in the study increased completion time by approximately 19%, even though participants had expected AI to make them faster. METR
That result should not be applied directly to every coding agent available in October 2026. The study examined particular tools, developers, projects, and tasks at an earlier point in AI development.
However, it provides an important warning: perceived speed is not the same as measured productivity.
Why Developers Can Feel Faster While Completing Work More Slowly
AI can produce large amounts of code in seconds. Watching that happen creates a strong impression that the task is nearly complete.
But engineering work includes understanding the solution, checking its behavior, identifying errors, and ensuring the changes fit the wider system.
If the generated code is unfamiliar or poorly designed, engineers may spend more time understanding it than they would have spent writing a simpler solution themselves.
Our Analysis: The Three Conditions Needed for Real Productivity Gains
Combining METR’s controlled study with the GitHub adoption data and our cost scenarios leads to a practical framework.
First, the task must be suitable for delegation. Clear, repeatable work with well-defined results is easier to verify than a large, uncertain architecture change.
Second, the development environment must make verification efficient. Good tests, readable code, and clear documentation reduce the cost of checking an agent’s work.
Third, the company must measure the finished outcome. A task should count as successful when the software works correctly, not simply when an agent submits a pull request.
These conditions offer a useful explanation for why different teams can experience very different benefits from the same tools. They are a framework derived from the evidence, not three experimentally proven requirements.
Which Software Engineering Tasks Are Most Likely to Benefit From Autonomous Agents?
Not every part of software development offers the same opportunity for automation.
A task that is easy to describe and easy to test is usually a better early candidate than one that requires complex business decisions.
Writing Automated Tests
Test creation is a strong starting point because teams often have many existing features that need better checks.
An agent can inspect a function, identify important cases, and propose tests. Engineers can then verify that those tests reflect real requirements rather than simply reproducing the current behavior.
This is particularly useful for startups that moved quickly during their early development stages and now need stronger safeguards as their customer base grows.
Fixing Small, Clearly Defined Bugs
Coding agents can be useful when a bug has a clear description and a reliable way to reproduce it.
For example, a customer might report that a dashboard shows the wrong date when exporting data. An agent can inspect the relevant files, propose a fix, and add a test that checks the problem.
The developer should verify that the change fixes the root cause and does not introduce problems elsewhere.
Updating Old Software Dependencies
Modern applications rely on external libraries that require regular updates.
Agents can help identify outdated code, adjust functions affected by an upgrade, and run tests afterward. This may reduce routine maintenance work that developers otherwise postpone.
However, dependency updates can introduce security or compatibility problems. Companies should review the packages being installed and avoid giving agents unrestricted access to development systems.
Building Internal Tools
Many startups need small internal applications for reporting, customer support, scheduling, or business operations.
These tools can be good candidates for agent-assisted development when their requirements are clear and their access to sensitive systems is limited.
The best opportunities are often internal processes where a modest improvement saves employees time every week.
Understanding and Cleaning Existing Code
As software projects grow, older code can become harder to understand.
Agents can help developers trace how a feature works, explain relationships between files, and prepare small improvements. This is valuable when a startup needs to maintain a product that was built quickly.
The key is to keep changes manageable. Large rewrites may introduce more risk than the original code, especially when tests are weak.
Tasks That Still Require Strong Human Control
Some engineering decisions should remain closely supervised.
| Task | Automation opportunity | Recommended oversight |
|---|---|---|
| Basic test creation | High | Engineer validates tests |
| Simple bug fixes | High | Code review and testing |
| Documentation updates | High | Accuracy checks |
| Small internal tools | Medium to high | Access and security review |
| Existing feature improvements | Medium to high | Product and technical review |
| Database design changes | Medium | Experienced engineer approval |
| Payment and identity systems | Limited without strong controls | Strict review and security testing |
| Major software architecture | Supporting role | Human-led decisions |
| Production incident response | Supporting role | Authorized human control |
This table is an SFTechScene qualitative assessment, not a measured ranking of agent success rates. Actual suitability depends on the project, the tool, the quality of testing, and the consequences of failure.
How Agentic Engineering Could Change San Francisco’s Startup Economy
San Francisco has long attracted companies that want to build new technology quickly. Agentic engineering may strengthen this model by reducing some of the labor required to create and maintain software.
However, its effect will not be the same across every startup.
Smaller Teams Could Build More Complete Products
A startup with three experienced engineers may be able to delegate routine tasks to agents while concentrating human effort on difficult technical decisions.
This could allow the team to create more prototypes, test more product ideas, and handle maintenance without increasing its headcount at the same pace as its software workload.
The opportunity is particularly relevant during the early stages of a company, when founders need to learn what customers want before making large investments.
Founders Could Test More Ideas Before Raising Funding
Traditional software development can make experimentation expensive.
If founders must hire several engineers before testing a new product idea, they may need significant capital before learning whether customers will pay for it.
Agentic engineering can reduce the effort needed to create some early versions. But founders still need to validate the business problem, speak with customers, and decide which features are worth building.
Faster development is most valuable when it supports faster learning.
Engineering Talent Could Shift Toward Higher-Value Decisions
When agents take on routine implementation work, developers may spend more time designing systems, defining requirements, investigating unusual problems, and reviewing changes.
Experienced engineers who understand both software and business needs could become especially valuable.
At the same time, companies must think carefully about how new developers will learn. Junior engineers traditionally gain experience by writing code, debugging mistakes, and reviewing feedback.
If those tasks increasingly move to agents, startups will need deliberate training processes to help less experienced engineers develop judgment.
The Opportunity Extends Beyond AI Coding Products
Agentic engineering creates demand for supporting software.
A startup might build systems that help companies manage multiple agents, verify generated code, track engineering costs, or check compliance requirements.
Another might focus on secure deployment, automated testing, or helping development teams understand changes made by AI.
These businesses could create value without developing their own foundation models.
The Biggest Risks Facing Agentic Engineering
The ability to automate software changes also creates new problems.
An agent that can edit files, run commands, and connect to external services can cause damage if it makes a bad decision or follows harmful instructions.
The Open Worldwide Application Security Project, or OWASP, has published guidance addressing risks specific to AI coding agents, including malicious instructions hidden in project content and overly broad access to sensitive systems. OWASP Cheat Sheet Series
AI Agents Can Produce Code That Looks Correct but Is Wrong
One of the hardest problems is that AI-generated code can look professional while containing subtle mistakes.
A function might work for normal customer requests but fail when input is missing. A payment feature might calculate most transactions correctly while handling refunds incorrectly.
These problems are dangerous because the code may pass a quick visual review.
Startups need meaningful tests that examine expected behavior, unusual cases, and failure conditions.
Agents Can Introduce Security Weaknesses
A coding agent might accidentally expose an API key, use an unsafe external library, or remove a security check while trying to fix another problem.
Security failures are particularly serious for startups handling personal information, payments, or confidential business records.
Teams should keep agent access limited, scan proposed code, and require approval for changes affecting sensitive functions.
Hidden Instructions Can Mislead Agents
A malicious actor can place instructions inside an issue, project file, or document that an agent later reads.
The attacker may try to persuade the agent to ignore its normal rules, change unrelated files, or reveal information.
This is known as prompt injection. It matters because agents may encounter untrusted text while carrying out otherwise legitimate tasks.
A secure workflow treats that material as information to inspect, not as instructions that automatically override the developer’s request.
Too Many Changes Can Overload Human Review
A team can create a new problem if coding agents generate more pull requests than engineers can review properly.
Reviewers may feel pressure to approve changes quickly, particularly when the code appears clean and tests pass.
Over time, this can introduce hidden defects and make the system harder to maintain.
The solution is not simply to add more automated code reviewers. Teams should also keep changes small, prioritize important risks, and limit the amount of unfinished work.
Poorly Managed Agents Can Increase Costs
Coding agents can generate costs through subscriptions, model usage, repeated attempts, and computing resources.
The larger hidden expense may be human time spent correcting work.
A startup should track the total cost of completed tasks, not just the amount charged by the AI provider.
How San Francisco Startups Can Adopt Agentic Engineering Without Damaging Software Quality
The best way to introduce autonomous coding agents is through a controlled process. A startup does not need to reorganize its entire engineering department to discover whether the tools are useful.
A better approach is to begin with a narrow group of tasks, measure the results, and gradually expand automation where the evidence supports it.
Phase 1: Establish a Reliable Starting Point
Before introducing agents, measure how the engineering team currently performs.
Choose a group of tasks that the company handles regularly, such as fixing small bugs, creating tests, or updating internal tools.
Record the time required to complete each task, how many changes fail review, how often defects appear after release, and how much engineering effort is spent correcting problems.
Without these numbers, it becomes difficult to tell whether AI is improving performance or simply making developers feel busier.
Phase 2: Select Tasks With Clear Success Criteria
Start with tasks that have understandable requirements and limited consequences if something goes wrong.
A good first experiment might involve adding missing tests to existing features or fixing documented bugs in a noncritical part of an application.
Avoid starting with a major database migration, authentication redesign, or production payment system.
The goal is to create enough reliable examples to understand the agent’s strengths and weaknesses.
Phase 3: Create Clear Rules for Every Agent
Agents need boundaries just as human employees need access rules.
A startup should decide which files agents may change, which commands they may run, what information they can access, and when they must request approval.
Production credentials, customer data, deployment permissions, and sensitive business information should not be broadly available to coding agents.
These controls should be enforced through the development environment rather than relying only on written instructions.
Phase 4: Build a Consistent Review Process
Every agent-generated change should follow the company’s normal quality standards.
That includes automated tests, security checks, and human review where appropriate. Sensitive changes should receive additional attention regardless of whether the code was written by a person or an agent.
Reviewers should examine the purpose of the change, its effect on other features, and whether the tests genuinely prove the required behavior.
A passing test report should support a review, not replace it.
Phase 5: Measure Results Using a Control Group
A useful experiment compares similar tasks completed with and without agent assistance.
For example, a company could select 40 suitable tasks and randomly assign 20 to an agent-assisted workflow and 20 to its existing process. It should use the same quality standards for both groups.
Random assignment reduces selection bias, although a small pilot still cannot support broad claims about all engineering work.
| Performance measure | What to record | Why it matters |
|---|---|---|
| Human effort | Hours spent per completed task | Measures labor savings |
| Delivery time | Time from task start to accepted completion | Measures actual speed |
| Review effort | Minutes spent checking changes | Reveals hidden cost |
| Rework rate | Share of tasks needing material corrections | Measures reliability |
| Defects after release | Problems linked to completed changes | Measures quality |
| AI cost | Tool and computing expense per accepted task | Measures direct costs |
| Security problems | Severity and frequency of findings | Measures risk |
| Customer impact | Whether changes improve the intended outcome | Measures business value |
The company should define what counts as an accepted task before starting the experiment. Otherwise, teams may unintentionally measure different outcomes for human and agent-assisted work.
Phase 6: Expand Only Where the Numbers Support It
After several weeks, examine which types of tasks benefited from AI assistance.
Some may show large reductions in human effort. Others may require enough review and correction that automation is not worthwhile.
Use those findings to decide where agents should be introduced next.
A successful engineering strategy does not require automating everything. It requires automating work where doing so improves the final outcome.
The 90-Day Agentic Engineering Adoption Plan for SF Startups
A 90-day program gives a startup a practical way to test autonomous coding without making a large commitment before the results are clear.
- Days 1–15: Establish the baselineSelect suitable engineering tasks, record current performance, and document existing testing and security rules. Identify one engineering owner who will be responsible for evaluating agent-generated work.
- Days 16–30: Prepare the development environmentChoose an agent, configure permissions, and create a repeatable process for reviewing changes. Run practice tasks using nonproduction data before introducing the tool into routine work.
- Days 31–60: Conduct a controlled pilotCompare agent-assisted work with the existing engineering process. Record human time, cost, review effort, defects, and the number of tasks accepted without substantial rework.
- Days 61–75: Analyze the evidenceSeparate tasks that benefited from automation from those that became slower or more expensive. Check whether any apparent speed improvements created extra defects or security risks.
- Days 76–90: Decide where to scaleExpand the workflow only for task categories with acceptable quality and clear economic value. Update engineering documentation and train the team on the resulting process.
The main outcome should be a repeatable engineering system, not simply a new software subscription.
By the end of the pilot, founders should know which tasks to delegate, which need human ownership, and how much the chosen approach really costs.
What Happens to Software Engineers in an Agentic World?
Agentic engineering will change the work of software engineers, but the evidence does not support assuming that entire development teams will disappear.
As agents handle more implementation steps, people will still need to decide which problems are important, whether proposed solutions are correct, and how software should behave in the real world.
Engineers Will Spend More Time Defining Problems
One of the most valuable engineering skills may become the ability to turn unclear business requests into precise technical requirements.
An agent cannot reliably build the correct feature when the company itself has not decided what the feature should do.
Engineers who understand users, business processes, and technical systems can help close that gap.
Reviewing and Testing Will Become More Important
When code becomes cheaper to produce, reviewing it can become a major constraint.
Companies may invest more in automated tests, security systems, and tools that help developers understand proposed changes.
Engineers will need to recognize solutions that technically work but create long-term maintenance problems.
Technical Leadership Will Still Matter
Software architecture involves decisions that affect future costs, reliability, and the ability to change a product.
An agent can offer options and examine tradeoffs, but someone must take responsibility for choosing a design that fits the company’s goals.
This is especially important for startups preparing to serve thousands of customers or enter industries with strict security requirements.
Junior Engineers Will Need New Ways to Learn
Entry-level developers may face a changing learning environment.
Tasks that once helped them build experience, such as small bug fixes and basic feature implementation, are increasingly suitable for automation.
Companies should avoid removing those learning opportunities entirely.
Instead, junior engineers can learn by examining agent-generated changes, identifying mistakes, writing tests, and explaining why one solution is better than another.
The goal should be to develop strong engineering judgment, not simply teach people to operate AI tools.
The Future of Agentic Engineering: What Could Change by 2027?
The next stage of agentic engineering will likely involve deeper connections between coding agents, testing tools, software repositories, and development systems.
This direction is consistent with the growing use of agent-based workflows reported in 2026. The precise pace of improvement, however, remains uncertain.
Multiple Agents May Work on Different Parts of a Project
Instead of assigning an entire task to one agent, developers may increasingly use several specialized agents.
One could inspect requirements, another could prepare code changes, and a third could review test results. A human engineer would supervise the work and resolve conflicts.
This approach could improve efficiency for some projects, but it also adds coordination costs. Multiple agents can repeat work, misunderstand each other, or introduce conflicting changes.
The useful measure will be the quality and cost of the finished result.
Automated Testing Could Become a Larger Competitive Advantage
As agents generate more code, companies with strong testing systems may be better positioned to use them safely.
Good tests give agents clearer feedback and make it easier for engineers to evaluate proposed changes.
For SF startups, investing in test quality may create more lasting value than repeatedly switching to whichever coding agent appears most powerful.
Software Teams May Become Smaller for Some Types of Work
Some startups may be able to build products with fewer engineers than similar companies needed in the past.
However, smaller teams are not guaranteed. Faster software creation can also lead businesses to build more features, support more customers, and maintain more complex systems.
The number of engineers a company needs will depend on its product, growth, quality standards, and willingness to automate important tasks.
Reliability Could Become the Main Source of Competition
As code generation becomes more widely available, the ability to generate large amounts of code may offer less competitive advantage.
Companies may increasingly compete on whether their software is secure, dependable, useful, and easy to maintain.
For startups selling business software, those qualities directly influence customer trust and long-term retention.
Original SFTechScene Research #5: Why Reliability May Matter More Than Agent Autonomy
Our final analysis combines the adoption trends, developer productivity evidence, and cost scenarios examined throughout this article.
The objective is to identify which engineering capabilities are most likely to matter as agentic tools become more common.
Research Framework
We examined four dimensions of agentic engineering: adoption, task completion, verification, and economic value.
Each dimension answers a different question.
| Dimension | Central question | Supporting evidence |
|---|---|---|
| Adoption | Are developers using agents? | GitHub and Stack Overflow 2026 |
| Task completion | Can agents complete assigned work? | Coding benchmarks and controlled evaluations |
| Verification | Can teams establish that the work is correct? | Testing outcomes, review results, defects |
| Economic value | Does automation reduce total delivery cost? | Human effort, rework, tool costs |
This is an original analytical framework, not a statistically validated prediction model.
Finding #1: Adoption Is Advancing Faster Than Proven General Reliability
GitHub reports substantial growth in agent involvement, while Stack Overflow reports widespread use of AI coding assistance.
Yet those measurements do not establish that agents can complete every type of engineering work reliably.
METR’s research also cautions against equating AI availability with improved performance. Its work on task-completion time horizons measures the difficulty of tasks agents can complete at a given reliability level, rather than the amount of real-world professional work they can independently replace. METR
This distinction matters for founders making investment decisions.
Finding #2: Verification Is an Economic Variable, Not Just a Safety Measure
Our cost scenarios show how review and rework can determine whether automation saves money.
A startup that reduces the effort required to verify correct changes may improve both engineering productivity and software quality.
That creates an opportunity for products and services focused on testing, security, clear requirements, and better development processes.
Finding #3: The Strongest Long-Term Advantage May Be the Engineering System
A company that depends entirely on one coding agent may struggle when model quality, pricing, or product features change.
A company with clear requirements, reliable tests, controlled permissions, and measured development workflows can evaluate new tools more easily.
Our analysis suggests that the engineering process surrounding the agent may become a more durable advantage than the choice of agent alone.
This is a strategic interpretation of the evidence rather than a proven forecast.
Research Methodology, Sources, and Limitations
SFTechScene’s original contribution in this article is a set of independently calculated comparisons, a transparent task-cost model, and a practical framework connecting agent adoption with engineering outcomes.
We did not conduct a new developer survey, run a randomized experiment ourselves, or obtain private engineering data from San Francisco startups. The analysis should therefore be understood as original secondary research and scenario modeling, not original primary data collection.
The core public sources are:
- GitHub Octoverse 2026 — platform activity, agent-started pull requests, file changes, and merge timing.
- Stack Overflow Developer Survey 2026 — AI tool adoption, developer responses, and coding-agent usage.
- Stack Overflow AI Coding Agent Data — individual coding-tool use and response counts.
- METR Developer Productivity Study — controlled evidence about AI-assisted development time.
- METR Task-Completion Time Horizons — methods for evaluating agent performance on software-related tasks.
- DORA 2025 Software Development Research — organizational factors influencing the value of AI-assisted development.
- OWASP Secure Coding With AI — security risks and recommended controls.
The GitHub figures include public and private repository activity and rely on the platform’s ability to detect agent involvement. Undetected agent use may not appear in its classifications. GitHub’s reporting also does not isolate the effect of agents from differences in task complexity, repository characteristics, or developer experience.
Stack Overflow’s survey is self-selected, and usage categories may overlap. Its percentages should not be interpreted as representative market shares for all developers or as measurements specific to the San Francisco Bay Area.
The financial model uses hypothetical assumptions designed to demonstrate break-even conditions. Actual results will vary according to engineering costs, task complexity, agent pricing, review standards, and the quality of existing software.
These limits do not make the analysis useless. They define what the evidence can support and where companies need to collect their own data before making significant decisions.
Final Takeaway: Agentic Engineering Is Making Software Easier to Build, but Reliable Delivery Will Decide Who Wins
Agentic engineering represents a meaningful change in software development. Developers can increasingly assign tasks to AI systems that inspect projects, write code, run tests, and prepare work for review.
The latest public data shows that agent involvement is growing rapidly. GitHub’s 2026 results indicate that agent-started changes have become a major part of development activity on its platform, while Stack Overflow’s survey confirms that AI coding tools are widely used among its respondents.
However, faster code generation is only part of the story. Engineering teams still need to understand customer requirements, check software quality, protect sensitive information, and manage the cost of fixing mistakes.
For San Francisco startups, the opportunity is substantial. Small teams may be able to test ideas faster, automate routine tasks, and direct experienced engineers toward more valuable work.
But companies should not confuse autonomy with reliability. An agent that completes many tasks is not necessarily more useful than one that consistently delivers correct changes with little human rework.
The startups that gain the most from agentic engineering will likely be those that measure the full development process, establish strong testing systems, and introduce automation where it produces clear business value.
The future of software engineering is not simply about having AI write more code. It is about helping people build better software, make smarter technical decisions, and deliver useful products with greater speed and confidence.
For Silicon Valley, that may become the most important competitive advantage of all.
