What If Coding Isn't the Hard Part Anymore?

Over the past few months, I’ve watched two very different journeys unfold with the same sense of fascination. Both journeys led to the same unexpected conclusion. On one side is my own experience. I’ve been building software for three decades and have seen coding assistants evolve from simple IDE autocomplete features to agents that can autonomously navigate large codebases. On the other side is a close friend with no programming background who decided to build a fully-fledged web application using nothing but modern coding agents.

What surprised me most was not our differences but our similarities. Our parallel experiences highlight not only how far the technology has come but also how profoundly it is reshaping who gets to build software and what it now means to be a “developer.”

From Autocomplete to Overnight Pull Requests

Like most experienced developers, I was gradually introduced to coding assistants. At first, they were little more than clever autocomplete functions inside the IDE. Helpful but limited. Eventually they began suggesting entire blocks of code. This sometimes felt more intrusive than useful. It was often quicker to write the code myself than to evaluate the suggestion. But when dealing with repetitive, predictable patterns, the agents genuinely helped.

Everything changed in the past 18 months with the release of a wave of coding agents. Some sit inside IDEs, others run in cloud development environments and some operate entirely through the terminal. What distinguishes them from the assistants of even a couple of years ago is their ability to work autonomously across large codebases.

The first time I assigned a task to GitHub Copilot and logged in the next morning to find a pull request waiting for review was a revelation. On another occasion, while half-watching TV, I stumbled across a paper describing ACE, a technique allowing AI agents to build playbooks of strategies. I dropped the paper into a repository for an agentic AI project, gave Claude Code instructions to implement it and went to bed. In the morning, the changes were committed. Two days later, the feature was running in production.

These moments made us excited about how quickly agents could accelerate development. So, a few months on, what have we learned?

Most of the time, agents write elegant code, especially in widely used languages like Python or TypeScript. They’re surprisingly capable planners too. Ask a coding agent to outline a new web application and it will likely suggest a sensible architecture, build a well-structured implementation plan and generate a detailed breakdown of tasks. Even better, as you execute that plan, the agent writes large pieces of functionality in minutes, often generating and running unit tests as it works.

But it’s not all smooth sailing.

For an experienced developer, the pace of code generation can feel uncomfortable, even disorientating. Very quickly, you’re surrounded by large volumes of code you didn’t write. That isn’t inherently a problem, working with a team produces the same effect but working with AI agents isn’t (yet) like working with people. If you’re not careful, fundamental issues become embedded deep in your codebase.

For example, following a detailed plan to build an agentic dashboard designer, I ended up with “agents” that never actually connected to the LLM. When I gave the coding agent an example dashboard template to help it build a function to populate it with live data, it overfitted the example completely, baking in specific column names rather than producing a generic solution.

These are mistakes even junior developers wouldn’t typically make. Looking deeper into the code, I found multiple functions that did the same thing and abandoned chunks of logic left behind without being deleted. Confidence starts to slip when this happens.

My own experience and the consensus among colleagues, is that investing more time planning to break work into smaller, well-scoped tasks helps significantly. But even this can be challenging, as agents often insist on writing code even when explicitly told not to. Thankfully, most tools now offer a planning mode where the agent cannot modify files, though sometimes it simply writes code in the chat instead. Agents also tend to overfit to test expectations, producing code that satisfies the test but is useless in the real world.

Yet despite all these pitfalls, coding agents have made me far more productive. I can deliver larger projects in less time and contrary to what I expected, with better quality. Traditionally, developers hesitate to admit mistakes or restart work. We patch around earlier decisions and end up with something that’s merely acceptable. With coding agents, code is so quick to generate that I’m far more willing to start over and build something properly from scratch.

A Non-Coder Builds a Polling Platform

Ahmad and I met at university. Whilst I studied software engineering, he studied civil engineering. He then spent years working in project management. His exposure to coding was limited to building Excel spreadsheets filled with IF statements to track contractor deadlines. Later, after moving to the UK, he did take a data science course where he learned a little PostgreSQL and Python but nothing that prepared him to build a web application. By his own admission, he couldn’t even get Python to generate a random number.

Having moved to the UK from Syria and developed a deep interest in democracy, he came up with the idea of building a polling platform to help people track how elected representatives vote, making parliamentary data accessible to ordinary citizens. The kind of project that would normally require hiring a developer.

He began with the Gemini chat interface, using it as an advisor. He’d ask it to generate code, then copy and paste it into VS Code, attempting to build something using Nuxt.js. Surprisingly, he got quite far. The AI helped him set up his development environment, install Node.js, configure PostgreSQL and scaffold the project. But as the app grew more complex, everything fell apart. He struggled to articulate what he wanted and when errors appeared, he couldn’t describe them clearly enough for the AI to help. He’d paste an error into Gemini, try the fix and end up back where he started. His deployed site crashed and hours of troubleshooting went nowhere. Eventually he concluded he would have to hire someone. Using AI alone wasn’t enough.

Meanwhile, I had begun experimenting with different coding agents. I suggested Replit might be a good fit, as the hosted cloud platform meant agent could not only help write the code but also handle administering the development environment. Ahmad didn’t need much convincing.

When he imported his broken project into the platform, it found and fixed the crashing error in about six minutes. Was it really this easy? He watched it work, impressed by how it ran tests, coordinated between what it calls the "architect" agent and the coding agent. However, he soon decided to start fresh from scratch and this time agent chose React instead of Nuxt. By the second day, he felt confident he could build anything with it.

He still encountered frustrations. The agent cannot see what you see. When building UI components, it reads the code and writes what should work but has no idea that something intended to sit “on top” is rendering in a completely different part of the screen. Ahmad tried providing screenshots. The agent acknowledged the issue and attempted fixes but often missed the real cause. It tests logically, not visually.

He also ran into the same misinterpretation problems I experienced. When he asked the agent not to show Arabic-only content cards to English users if the English name field was empty, the agent interpreted this as “block all Arabic content from English users entirely,” breaking direct links and producing 404 errors. A simple request turned into an over-engineered, incorrect solution. It turns out that articulating instructions in ways AI won’t misinterpret is hard.

One episode was particularly striking. Ahmad needed to anonymise voting data while preserving analytics. Guided by Gemini, he asked the agent to use salted hashes to disconnect user identities from votes. The agent dutifully created the hash and added an analytics ID column but then also added that analytics ID into the user table, completely undermining the privacy design. Again, the kind of mistake even a junior developer would rarely make.

Despite all this, Ahmad built a working polling platform. It includes user registration, surveys, real-time charts, GDPR-compliant handling of user data and localisation. The site is deployed and functional. When I asked what percentage of the coding the agent handled, he didn’t hesitate: “All of it. 100% of the coding.”

Did he code the app or collaborate with the agent? “I designed the app. I didn’t code the app. I can’t code a single window in that app.” The agent wrote it. He instructed it. And that distinction matters. He isn’t pretending to be a developer. He’s someone with an idea and the persistence to see it through, using tools that made the technical execution possible.

If he were to start again, he’d sketch the interface on paper first, every button, every interaction, before asking the agent to do anything. He’d also try to work in smaller pieces, though he admits he often doesn’t know what counts as “small.” Something that feels trivial to him may require extensive restructuring and he often can’t tell until the agent has already gone too far.

Same Lessons, Opposite Starting Points

What I find remarkable is how similar our experiences were despite coming from opposite backgrounds. We both found that coding agents excel when the task is well documented. We both ran into the same kinds of errors when instructions were misunderstood or when the agent made surprisingly basic mistakes. We both learned to work in small increments, verify each change and accept that agents often leave behind unused functions simply because they don’t remember creating them.

The central lesson was the same. You need a clear understanding of the agents’ strengths and limitations. They do not retain context across sessions. They forget decisions, assumptions and even the structure of code they wrote the day before. That’s why duplicated logic appears so easily and why it helps to keep notes or markdown files the agent can refer to. We also both saw hallucinations, agents inventing library methods that don’t exist when documentation is incomplete. Human developers instinctively know this won’t work; agents don’t.

Ahmad believes these tools will allow many more people to build software but he’s realistic. It requires a mindset comfortable with trial and error, with sitting alongside complexity and with patiently adjusting instructions when the agent misfires. Not everyone will want that and many will give up early. But for those who persist, something genuinely new is possible. Someone with no coding experience can now build a functioning application. They aren’t learning to code in the traditional sense, they’re learning to guide something that codes for them.

For experienced developers, the shift is equally significant. We’re moving from writing code ourselves to shaping the work of systems that generate it at extraordinary speed. Our value increasingly lies in how we structure problems, identify subtle errors and steer agents away from traps they cannot perceive.

Even in the short time since we finished these projects, the landscape has shifted again. Anthropic released Opus 4.5, Google launched Gemini Pro and many of the frustrations we described have eased. Context stays consistent across long sessions. The agents that needed constant handholding now carry complex tasks through to completion largely on their own.

Taken together, these experiences highlight a profound redefinition of software development. Tools like these are advancing at such an astonishing pace that the problems Ahmad and I wrestled with will soon feel like early growing pains. Code is no longer the bottleneck. The craft is shifting from typing to directing, from writing the solution to defining the problem. The question isn't whether this transformation is coming, it's whether you'll be ready when it arrives.