AI coding tools are changing how developers write, review, test, and ship software. But if your team uses Apache Subversion (SVN), you might be wondering where that leaves you.

Much of the conversation around AI-assisted development happens in a Git-first world. That can make it seem as though adopting AI also means changing your version control system.

It doesn’t.

AI coding tools can work with code stored in SVN repositories, and emerging technologies such as the Model Context Protocol (MCP) are creating new ways for AI agents to interact with development tools and repositories.

The more useful question for SVN teams isn’t whether SVN was designed for AI. It wasn’t. Neither were most of the development tools teams rely on today.

The question is: How can you introduce useful AI capabilities into an existing SVN workflow without adding unnecessary time, cost, or risk?

In Short

AI coding tools can work with SVN. Teams do not need to migrate to Git simply to adopt AI-assisted development. AI can work with SVN code, repository history, diffs, and other context, while integration layers such as MCP can give AI agents controlled access to repository tools. The key consideration is deciding what level of access AI should have while maintaining security, governance, and human oversight.

Can AI Coding Tools Work With SVN?

Yes.

At the simplest level, an AI coding assistant can work with files in an SVN working copy just as it can work with other local project files. The source code doesn’t become inaccessible to an AI assistant because it is versioned with SVN.

Where things get more interesting is when an AI agent needs to understand or interact with the version control system itself.

For example, an AI agent might need to:

• Inspect which files have changed
• Review a diff
• Look through repository history
• Examine previous changes to a file
• Summarize changes before a commit
• Update a working copy
• Perform a repository action after receiving approval

Those tasks require more than access to the files. The AI needs a way to interact with SVN.

That’s where tools and protocols such as MCP become relevant.

Why Does AI Development Feel So Git-First?

Git dominates much of modern software development, so it makes sense that many AI developer tools have built their first source control integrations around Git and Git-based platforms.

But that doesn’t mean AI itself depends on Git.

There is an important distinction between an AI coding tool and the version control integrations built around it.

An AI model can analyze or modify code regardless of whether that code ultimately lives in Git, SVN, Perforce, or another version control system. Repository-aware capabilities depend on the tools, context, and permissions available to the AI.

SVN teams have encountered this situation before.

Development tooling doesn’t always support every version control system equally from day one. CI/CD systems, code review tools, IDEs, and other parts of the development stack have all required integrations with source control.

AI is creating the next version of that integration challenge.

How Can AI Work With SVN?

It helps to think about AI access to SVN in layers.

1. Code Access

The simplest level is access to the code itself.

An AI coding assistant can analyze files in an SVN working copy and help a developer understand, write, refactor, document, or troubleshoot code.

For many AI-assisted development tasks, this may be enough.

2. Repository Context

An AI agent becomes more useful when it can understand what is happening in the repository.

For example, a developer might ask:

• What changed in my working copy?
• What did this file look like before the last change?
• Which revision introduced this code?
• What changed between these revisions?
• Which files are currently modified?
• Can you summarize these changes before I commit them?

Answering those questions accurately requires access to SVN information such as status, logs, history, and diffs.

3. Repository Actions

The next level goes beyond reading information.

An AI agent could potentially update a working copy, add files, revert changes, or perform other SVN operations.

Eventually, teams may also choose to allow agents to initiate commits or other higher-impact actions.

That changes the risk considerably.

An AI system reading an SVN log is very different from an AI system being allowed to modify or commit code.

So the important question isn’t simply:

Can AI access SVN?

It’s:

What should AI be allowed to do with SVN?

What Does MCP Change for SVN?

The Model Context Protocol provides a standardized way for AI applications to connect with external tools and data.

In simple terms, an MCP server can make specific capabilities available to an AI application. Instead of expecting an AI model to understand and control every external system on its own, the integration provides defined tools that the AI can use.

For an SVN environment, that creates an interesting possibility.

An SVN-aware MCP server could expose operations such as:

• SVN status
• Repository logs
• Diffs
• Repository information
• Updates
• Adds
• Reverts
• Commits

The AI agent can then use those tools when it needs repository context or needs to perform an approved action.

This changes the conversation around SVN and AI.

SVN doesn’t have to become Git for an AI agent to interact with it.

Instead, an integration layer can bring SVN capabilities to the AI.

What Could an AI-Enabled SVN Workflow Look Like?

Imagine a developer working on an established application stored in SVN.

They make changes across several files and ask their AI assistant:

“Review my changes and tell me if anything looks risky.”

With access to the working copy, the assistant can inspect the current code.

With controlled access to SVN context, it could potentially do more.

It could inspect the current diff, identify the files that changed, examine relevant repository history, compare the implementation with previous revisions, and summarize the overall change.

The developer could then ask:

“Create a summary for my commit message.”

The AI generates one based on the actual changes.

The developer reviews the code and the proposed commit message, then commits through the normal SVN workflow.

That’s a relatively conservative implementation of AI-assisted SVN.

AI does the investigation and repetitive work. The developer remains responsible for the repository action.

More autonomous workflows are possible, but more autonomy isn’t automatically better.

How Much SVN Access Should an AI Agent Have?

This may become one of the most important questions for teams introducing agentic AI into software development.

Giving an AI system access to a repository creates a spectrum of permissions.

At one end is read-only access.

The agent can inspect history, status, diffs, or other repository information but cannot alter anything.

The next level might allow an AI agent to modify files in a local working copy while requiring a developer to review and commit those changes.

At the other end, an autonomous agent might be permitted to perform write operations against the repository itself.

Each step increases what the AI can accomplish, but it also increases the potential impact of an incorrect or unintended action.

For SVN teams evaluating AI agents, familiar security principles still apply.

Use the Least Privilege Necessary

An agent that only needs repository history shouldn’t automatically receive write access.

Start with the minimum permissions required for the task.

Keep Humans Involved in High-Impact Actions

AI can automate work without necessarily controlling the entire workflow.

Code changes, commits, deletes, and other significant repository actions may warrant explicit human review or approval.

Limit Repository Scope

An agent shouldn’t automatically have access to every repository simply because it needs access to one project.

Access can be scoped around the job the agent is expected to perform.

Protect Credentials

AI integrations shouldn’t become a shortcut around existing authentication and access controls.

Repository credentials need to be treated with the same care regardless of whether the user is a developer, automation process, or AI agent.

Maintain Auditability

Teams should be able to understand what actions were performed, when they happened, and what system or user initiated them.

AI changes the interface.

It doesn’t remove the need for source code governance.

Where Can AI Save SVN Teams Time?

The biggest opportunity may not be letting an autonomous agent commit code.

It may be eliminating dozens of smaller tasks developers perform around the repository.

Consider investigating an unfamiliar section of a long-lived codebase.

A developer might inspect several files, check SVN history, compare revisions, identify previous changes, read associated tickets, and piece together why a particular implementation exists.

An AI assistant with appropriate repository context could help bring that information together faster.

The same principle can apply to:

• Summarizing changes
• Reviewing diffs
• Understanding legacy code
• Creating documentation
• Troubleshooting problems
• Investigating repository history
• Preparing commit messages
• Explaining unfamiliar code
• Assisting with testing
• Connecting source code context with other development tools

For teams with long-running SVN repositories, this could be particularly valuable.

Those repositories may contain years of development history and institutional knowledge.

AI creates an opportunity to make that information easier for developers to work with.

What About the Risk?

Saving time is only useful if the new workflow doesn’t create bigger problems somewhere else.

AI agents introduce a different operational model from traditional developer tools.

A developer typically makes a deliberate decision to run a command. An agent may be capable of deciding which tool to call as part of completing a broader task.

That means teams need to think carefully about where automation ends and approval begins.

A useful approach is to separate AI-assisted workflows into levels.

Read: Let AI inspect code and repository information.

Recommend: Let AI propose changes or actions.

Prepare: Let AI modify a working copy or prepare an action for review.

Execute: Allow AI to perform repository operations.

Not every organization needs to reach the final level.

In fact, some of the highest-value AI use cases may come from the first three.

The goal isn’t maximum autonomy.

The goal is to remove work that doesn’t need to consume engineering time while maintaining appropriate control over critical source code.

Do You Need to Change Version Control Systems to Adopt AI?

Not automatically.

If your current version control system no longer meets your technical or business requirements, that’s a legitimate reason to evaluate alternatives.

But adopting AI doesn’t inherently require replacing SVN.

Before considering a major infrastructure or workflow change, start with the capability you’re actually trying to add.

Do developers need an AI assistant to understand code?

Do they need AI to inspect repository history?

Do you want AI-assisted reviews?

Do agents need access to tickets or CI/CD information?

Do they need permission to perform repository actions?

Once you define the desired outcome, you can determine what integration and repository access is actually required.

That matters because changing development infrastructure has a cost.

There is the time engineers spend implementing and maintaining the change.

There is the operational risk of changing systems that may support critical development workflows.

And there is the broader cost of retraining teams, rebuilding integrations, changing automation, and maintaining new infrastructure.

The goal should be to adopt AI where it creates meaningful value—not to rebuild working systems simply because AI is the latest addition to the development stack.

What Should SVN Teams Do Now?

For most SVN teams, the sensible starting point is relatively conservative.

First, identify one or two repetitive development tasks where AI could save meaningful time.

Maybe developers regularly spend time understanding legacy code.

Maybe reviewing changes requires digging through repository history.

Maybe creating documentation or summarizing commits is repetitive.

Start there.

Then determine what context the AI actually needs.

If it only needs source files, don’t give it repository credentials.

If it needs SVN history, consider read-only repository access.

If it needs to modify code, keep the changes in the working copy and maintain human review before they reach the repository.

And measure the result.

Did developers actually save time?

Did the integration introduce additional maintenance?

Did it create new security concerns?

Did developers trust the output?

Did it make an existing workflow simpler or more complicated?

Those answers will tell you far more about the value of AI in your development environment than adopting AI simply because everyone else is doing it.

The Future of SVN in an AI World

SVN wasn’t built for AI agents.

But that doesn’t mean SVN teams are excluded from AI-assisted development.

The emerging agentic development model is increasingly about connecting AI systems to the tools, data, and workflows teams already use.

Technologies such as MCP make that model particularly interesting because they create a common way for AI applications to interact with systems that existed long before today’s generation of AI coding tools.

For SVN teams, that creates another path forward.

Instead of starting with:

“How do we replace SVN so we can use AI?”

start with:

“How can AI improve the SVN workflow we already have?”

Sometimes changing the underlying version control system will still be the right decision.

Sometimes it won’t.

What matters is making that decision based on your development requirements, engineering time, operational risk, and total cost—not on the assumption that modern development automatically requires abandoning SVN.

Bringing AI Into an Existing SVN Environment

Assembla has supported SVN alongside Git and Perforce for years because different development teams have different requirements.

For teams that continue to rely on SVN, the challenge isn’t simply keeping the repository running. It’s making sure the development environment can evolve without creating unnecessary operational work.

AI is part of that evolution.

The opportunity is to introduce AI where it can make developers more productive while maintaining the security, control, and reliability your source code requires.

And that fits a much broader principle:

Your engineering team should spend its time building products—not maintaining the infrastructure and integrations behind them.

Assembla’s SVN Cloud Hosting provides a managed environment for teams that want to keep using SVN without taking on the operational burden of hosting and maintaining the infrastructure themselves.

Explore Assembla SVN Cloud Hosting →

Frequently Asked Questions

Can AI coding assistants work with SVN?

Yes. AI coding assistants can work with files stored in an SVN working copy. More advanced repository-aware capabilities, such as examining SVN history or performing SVN operations, require appropriate tools or integrations.

Does SVN support MCP?

MCP is an integration protocol rather than a native SVN feature. An MCP server can expose SVN capabilities as tools that an AI application or agent can use.

Do I need Git to use AI coding tools?

No. AI models can work with code regardless of whether it is versioned with Git, SVN, Perforce, or another version control system. However, individual AI products may provide deeper built-in integrations with some version control systems than others.

Can an AI agent commit code to SVN?

Technically, an AI agent can be given tools capable of performing SVN write operations. Whether it should have that permission is a separate question. Teams should consider least-privilege access, human approval, credential security, repository scope, and auditability before allowing autonomous repository changes.

Is SVN still relevant in the AI era?

Yes. AI doesn’t inherently change the reasons organizations use SVN. Teams with established repositories, centralized workflows, large files, or specific governance requirements can still introduce AI-assisted development without automatically replacing their version control system.

Should we replace SVN to use AI?

Not solely because you want to adopt AI. First identify the AI capabilities your team actually needs and determine whether they can work with your existing SVN environment. A version control migration should be based on broader technical and business requirements, not simply the assumption that AI requires Git.

I am boyter, and I’m here to ask you a question.

Is a developer not entitled to the relevance of his own query?

• “No!” says the man in Algorithms, “It belongs to the poor… performance on cold starts.”
• “No!” says the man in the Search Engine Temple, “It belongs to the inverted index.”
• “No!” says the man in the Trigram Cathedral, “It belongs to the trigram postings list, pre-computed and eternal.”

I rejected those answers; instead, I chose something different.

This blog post was created with the help of AI tools. Yes, I used a bit of magic from language models to organize my thoughts and automate the boring parts, but the geeky fun and the in C# are 100% mine.

Hi!

During the live Q&A in the second session of the From Model to Agent: The Agent Framework Harness, Live in C# series on September 10, 2026, someone in the audience asked a practical question:

What happens if an agent requests approval, but the user does not answer? Can the approval expire or retry?

That question is easy to overlook in a happy-path demo. We usually show the agent requesting a tool, the user selecting Approve or Deny, and the workflow continuing. Real applications also need to handle silence, invalid answers, repeated approval requests, cancellation, and unavailable input.

So, after the session, I created a new sample: 22 – Approval Retries and Timeouts.

The sample adds a bounded approval policy to a Microsoft Agent Framework agent running with Harness:

• five seconds to answer each approval request
• five attempts maximum
• y or yes approves immediately
• n or no denies immediately
• missing or invalid input retries
• cancellation and input failures deny the action
• exhausting the attempts denies automatically
• one denial remains in effect for the rest of the prompt
• repeated approval rounds from the model are also bounded

The important principle is simple:

Silence is not consent.

About the MafClaw series

MafClaw is a four-part Microsoft Reactor live-coding series where we build a C# agent incrementally with .NET, Microsoft Agent Framework, and Harness.

The running sample is a finance education assistant. We start with a model, turn it into an agent, add tools and planning, introduce safe access to data, require human approval for side effects, add memory, and then move toward more advanced and production-ready scenarios.

• Microsoft Reactor series page
• Sample repository
• Series introduction

You can also follow the four sessions on the .NET YouTube channel:

1. Meet Your Claw: A Harness in Three Lines of C#
2. Working With Your Data, Safely: Files, Approvals and Memory
3. Scaling the Claw: Skills, Shell, CodeAct and Background Agents
4. Production Ready: Observability, Governance and Deployment

The audience question that inspired this sample came from session 2, where we explored file boundaries, human approval, and agent memory.

The scenario

The user asks the agent:

Buy 10 shares of MSFT.

This is a simulated trade. No real transaction is created, but it represents a side effect that should not execute only because a model requested it.

The tool is wrapped with ApprovalRequiredAIFunction:

internal static class ApprovalGateTools
{
    [Description("Places a demo-only simulated trade after the Harness approval flow allows it.")]
    public static string RequestSimulatedTradeOrder(
        [Description("Trade side, for example buy or sell.")] string side,
        [Description("Ticker symbol, for example MSFT.")] string symbol,
        [Description("Number of shares.")] int shares)
    {
        var normalizedSide = side.Trim().ToLowerInvariant();
        var normalizedSymbol = symbol.Trim().ToUpperInvariant();
        if (shares <= 0)
        {
            return "Denied: share quantity must be greater than zero.";
        }
        return $"Approved: simulated {normalizedSide} order for {shares} shares " +
               $"of {normalizedSymbol}. This is not a real transaction.";
    }
    public static AIFunction RequestSimulatedTrade { get; } =
        new ApprovalRequiredAIFunction(
            AIFunctionFactory.Create(
                RequestSimulatedTradeOrder,
                "request_simulated_trade"));
}

The model can request request_simulated_trade, but Harness pauses before executing the C# function. The host application, not the model, owns the approval decision.

Configure a bounded approval policy

The sample configures the policy with a small block:

const int maxApprovalAttempts = 5;
var approvalTimeout = TimeSpan.FromSeconds(5);
var approvalPolicy = new TimedApprovalPolicy(
    maxApprovalAttempts,
    approvalTimeout);

These numbers are intentionally short for a live demo. A production application should choose deadlines and retry limits that match its user experience and the risk of the requested action.

The policy validates its configuration:

public TimedApprovalPolicy(
    int maxAttempts,
    TimeSpan timeout,
    Func<TimeSpan, CancellationToken, Task<string?>>? readLineAsync = null)
{
    if (maxAttempts <= 0)
    {
        throw new ArgumentOutOfRangeException(
            nameof(maxAttempts),
            "Approval attempts must be greater than zero.");
    }
    if (timeout <= TimeSpan.Zero)
    {
        throw new ArgumentOutOfRangeException(
            nameof(timeout),
            "Approval timeout must be greater than zero.");
    }
    this.maxAttempts = maxAttempts;
    this.timeout = timeout;
    this.readLineAsync = readLineAsync ?? ReadConsoleLineWithTimeoutAsync;
}

The injectable input reader is useful beyond this console sample. It keeps the approval policy separate from the user interface and makes the decision logic deterministic to test.

Retry missing or invalid input

The approval loop retries only when the user has not made a valid decision:

for (var attempt = 1; attempt <= maxAttempts; attempt++)
{
    Console.Write(
        $"Approve tool {toolName}({arguments})? [y/n] " +
        $"Attempt {attempt}/{maxAttempts}, " +
        $"{timeout.TotalSeconds:0}s timeout: ");
    var input = await readLineAsync(timeout, cancellationToken);
    if (input is null)
    {
        Console.WriteLine(attempt == maxAttempts
            ? "Timed out. Approval denied after the final attempt."
            : "Timed out. Retrying approval.");
        continue;
    }
    input = input.Trim();
    if (input.Equals("y", StringComparison.OrdinalIgnoreCase) ||
        input.Equals("yes", StringComparison.OrdinalIgnoreCase))
    {
        return new ApprovalDecision(
            true,
            $"Approved by console user on attempt {attempt}.");
    }
    if (input.Equals("n", StringComparison.OrdinalIgnoreCase) ||
        input.Equals("no", StringComparison.OrdinalIgnoreCase))
    {
        return new ApprovalDecision(
            false,
            $"Denied by console user on attempt {attempt}.");
    }
    Console.WriteLine(attempt == maxAttempts
        ? "Invalid response. Approval denied after the final attempt."
        : "Invalid response. Enter y or n; retrying approval.");
}
return new ApprovalDecision(
    false,
    $"Denied automatically after {maxAttempts} unanswered or invalid attempts.");

There is an important distinction here:

• No response is not a denial yet, so the policy may ask again.
• Invalid input is not approval, so the policy may ask again.
• Explicit n is a decision, so the policy stops immediately.
• Explicit y is consent, so the policy stops immediately.
• No valid answer after the limit becomes an automatic denial.

Retries must never turn uncertainty into approval.

Do not block forever on console input

Console.ReadLine() waits indefinitely and cannot provide the timeout behavior we need for an interactive console.

The sample checks for available keyboard input until the deadline:

var input = new StringBuilder();
var startedAt = Stopwatch.GetTimestamp();
while (Stopwatch.GetElapsedTime(startedAt) < timeout)
{
    cancellationToken.ThrowIfCancellationRequested();
    if (!Console.KeyAvailable)
    {
        await Task.Delay(50, cancellationToken);
        continue;
    }
    var key = Console.ReadKey(intercept: true);
    if (key.Key == ConsoleKey.Enter)
    {
        Console.WriteLine();
        return input.ToString().Trim();
    }
    if (!char.IsControl(key.KeyChar))
    {
        input.Append(key.KeyChar);
        Console.Write(key.KeyChar);
    }
}
Console.WriteLine();
return null;

The complete implementation also supports redirected input and distinguishes an input timeout from caller cancellation. Cancellation, console I/O errors, and unavailable input are converted into denied decisions instead of allowing the tool to run.

Make denial sticky for the prompt

Limiting keyboard attempts is not enough.

After receiving a denial, the model could theoretically request the same tool again when the agent continues. A new request must not silently reopen the approval process during the same user prompt.

The console runner records whether any approval has already been denied:

var approvalRound = 0;
var approvalDeniedForPrompt = false;
while (true)
{
    var approvalRequests = response.Messages
        .SelectMany(message => message.Contents)
        .OfType<ToolApprovalRequestContent>()
        .ToList();
    if (approvalRequests.Count == 0)
    {
        return;
    }
    approvalRound++;
    if (approvalRound > MaxApprovalRoundsPerPrompt)
    {
        Console.WriteLine(
            "Approval denied: the agent exceeded the approval round limit " +
            "for this prompt.");
        return;
    }
    var approvalResponses = new List<AIContent>();
    foreach (var request in approvalRequests)
    {
        var functionCall = request.ToolCall as FunctionCallContent;
        var toolName = functionCall?.Name ?? request.ToolCall.CallId;
        var arguments = functionCall?.Arguments is null
            ? string.Empty
            : string.Join(
                ", ",
                functionCall.Arguments.Select(
                    item => $"{item.Key}: {item.Value}"));
        var decision = approvalDeniedForPrompt
            ? new ApprovalDecision(
                false,
                "Denied automatically because another approval was already " +
                "denied for this prompt.")
            : await approvalPolicy.RequestApprovalAsync(toolName, arguments);
        approvalDeniedForPrompt |= !decision.Approved;
        approvalResponses.Add(
            request.CreateResponse(decision.Approved, decision.Message));
    }
    response = await agent.RunAsync(
        [new ChatMessage(ChatRole.User, approvalResponses)],
        session);
}

This adds two separate limits:

1. The human gets a bounded number of attempts to answer one approval request.
2. The agent gets a bounded number of approval rounds for one user prompt.

Once a request is denied, later approval requests in that prompt are denied automatically. The model cannot negotiate its way around the user’s answer.

Demo paths

Run the sample:

dotnet run --project `
  .\session-02\samples\22-approval-retries-timeouts\MafClaw.Sample22.csproj

Then use the same agent prompt for each path:

Buy 10 shares of MSFT.

Approved

Answer before the deadline:

y

The tool executes and returns a simulated result.

Explicitly denied

Answer:

n

The request is denied immediately. It does not consume the remaining attempts.

Invalid input followed by approval

Answer:

maybe

The policy rejects the value and asks again. Answer y on the next attempt to approve.

No response

Do not type anything.

Each attempt expires after five seconds. After the fifth attempt, the request is denied automatically and the simulated trade does not execute.

Why this matters outside the demo

Human approval is often presented as a yes/no dialog, but the operational behavior around that dialog is part of the security boundary.

A real approval design should answer questions such as:

• How long is approval valid?
• What happens when the approver is unavailable?
• Can an expired request be retried?
• How many retries are allowed?
• Does an explicit denial remain final?
• Can the agent immediately ask again?
• What happens if multiple tools request approval together?
• What audit data identifies the user, tool, arguments, decision, and time?
• Does the approval authorize exactly one execution?

The sample is deliberately small, but it demonstrates the core rule: the host application owns these policies. The language model should not decide how long to wait, how many times to retry, or whether silence means approval.

Try the complete sample

The complete source is available in the public MafClaw repository:

• Sample 22 – Approval retries and timeouts
• Session 2 samples
• MafClaw repository

And if you want to see the audience discussion that prompted this additional scenario, watch Working With Your Data, Safely: Files, Approvals and Memory on the .NET YouTube channel.

You’ve read the social media posts: “Software development has completely changed” exclamation mark exclamation mark exclamation mark.

These are almost invariably about how, before coding agents and LLMs, software developers were essentially just typists, faithfully translating specifications some more enlightened being had created into source code.

“The job is no longer just about syntax”, they excitedly claim. Yeah, I miss the days when I didn’t have to think about semantics. But AI has changed all that.

They typically then go on to list a bunch of skills that were always part – the bigger part – of developing software like architecture, testing, knowing what to build and, of course, knowing what not to build. They tend to be a little vague on how we figure that out, of course. So definitely no change there.

The myth that professional programmers were little more than meat-based transpilers persists, and the “coding is solved” folks deploy it to potentially devastating effect. The intended audience, most likely, is other people who subscribe to the myth – i.e. not actual software developers.

Belittling the work isn’t anything new, of course. The very term “coder” has that typing pool ring to it. These aren’t our ideas. These are just Turing-complete transcriptions of a product specification or requirements document or a UI design or an architecture model. Someone else did the actual thinking. Someone clever. It’s baffling why we get paid so much when our job apparently is so low-skilled.

It dates back to the early days of electronic computers, and conflates two historical facts. Programming really was viewed as relatively low-status work compared to designing the hardware programs ran on. But the people who programmed those early computers were not being handed program specifications and told to “code them”.

Take one of the earliest, ENIAC; the team who programmed it had to study the hardware and come up with ways of programming and testing it for ballistics simulations. They’re credited with inventing subroutines and nesting. It was a million miles from translating program designs into equivalent code.

But they were women. And, arguably, they may have been treated like a typing pool by the more “senior” male staff on the project. The myth conflates the status with the actual nature of the work, and it has persisted to this day – presumably because it serves a purpose.

(When the growing demand for programmers pushed up salaries, of course, it somehow became “men’s work”. Funny how that happens.)

Throughout my career, software development has had that vague sense of being a paradox of professional (and social) status vs. earnings, but this “age of AI” is bringing that into sharp focus. People outside the profession have always been willing to see us as overpaid typists. And if coding agents are proving anything, it’s that their eagerness to believe this is only matched by how very obviously not true it is.

Over the last few years years, we’ve watched many founders set sail on the Good Ship Vibe-Code, only to end up sinking before they’ve even got it out of the harbour. Turns out it takes skills to build seaworthy ships, and “coding” is among the least of them.

Typing or editing code always was and always will be a very small part of the work. Various industry statistics put the average amount of code added, edited or deleted per day by developers in the range of 50-100 lines.

It could be because the average developer is a really slow typist – it’s about 1-2 words per minute. Or it could be because we’re doing other things most of the time. Y’know. Like thinking or reading or talking to each other (your boss may know it as “interruptions”).

These things were always the larger part of the work, and none of them has been replaced by “AI”. Something in the process has to understand. If anything, coding agents have just turned them into worse bottlenecks. Maybe we type slow because we need that time for our brains to catch up?