rnc.sh

Blog

The End of Programming as We Know It

Why I think writing code by hand is becoming optional, and what that changes for programmers.

The End of Programming as We Know It

I no longer think writing software line by line is a sensible default. LLMs have changed the work enough that writing all the code yourself is starting to look more like a hobby.

Consider the tasks: modernizing a library for UTF-8, fixing a transient TCP deadlock, or building an inference engine in C. Work like this can now take minutes instead of weeks. That changes what a programmer should spend time on.

The consumer app market is growing, as the data highlighted by a16z shows. Building an app takes less time and money than it used to.

If a developer can reproduce much of a SaaS product in a week with an AI coding tool, the code offers less protection from competitors. Product judgment, distribution, and access to useful data matter more.

Working with agents

In 2025, coding tools moved beyond suggesting code. Agents can run commands, edit files, and debug. These workflows let a programmer delegate much larger pieces of work.

Whether the tool runs in a terminal or an IDE matters less than whether it can carry a task through to a working result.

There’s something strange about working with a tool that remembers instructions and changes its behavior as you teach it. It’s easy to start treating it like a person. The programmer still has to own the decisions and the result.

Building it yourself

AI gives small teams more room to compete with large companies. It reminds me of what open source did in the 1990s. An SDK generator or a custom observability tool becomes a plausible project for one person.

Describing the problem clearly is a large part of the work. You still need enough understanding to judge whether the result is any good.

For years, the default advice was to buy: authentication from Clerk, documentation from Mintlify, billing from Stripe. Those services raised expectations for how software should work.

Agents change the cost of building some of that software yourself. Buying still has advantages, but more tools are within reach of a small team. Keeping the code simple matters when that team also has to maintain it.

Where the tools fall short

Git and GitHub were designed around people writing and reviewing code. A pull request shows the diff, but usually leaves out the prompts and failed approaches that explain how an agent got there.

I’d like version control to keep that context, including the dead ends. An agent shouldn’t have to repeat a failed approach because the record of it disappeared with the conversation.

Code review has a similar gap. Working with an agent involves questions, experiments, and revisions that don’t fit comfortably into a diff and a comment thread.

I also want better ways for agents to investigate running systems: search logs, query databases, and use debuggers. A dashboard is useful, but it doesn’t answer every question that comes up during an investigation.

Responsibility for the work

Unreviewed AI-generated contributions create work for open-source maintainers. Producing a patch is cheap; checking it may take someone else hours. Submitting code you haven’t understood or tested passes that cost to them.

Projects need contribution rules that make the submitter’s responsibility clear, including when an agent wrote the code.

The employment question is harder. If fewer people are needed for some kinds of work, we need to take income support and worker protections seriously. Universal basic income belongs in that discussion.

We can’t undo the technology. I think we should vote for policies that account for its effects on work, while also using it to tackle scientific and other problems worth solving.

Keep building

If you got into programming because you wanted to build things, that reason still holds. Having a tool write more of the code gives you room to try projects you wouldn’t otherwise have time for.

My advice is to spend a few weeks using these tools on real work. A quick test won’t tell you much. Learn where they help, where they fail, and how to check what they produce.

There’s still plenty of work in choosing a useful problem, understanding it, and getting the solution right. That’s where I’d put my effort.