How AI Coding Agents Are Changing Software Development
A coding agent is not a chatbot that happens to know Python. It is a system that can look at a repository, propose changes across files, run commands, read the errors, and try again. Used well, it compresses the boring middle of implementation. Used carelessly, it produces a large volume of almost-right code that nobody is prepared to own.
That distinction matters more than the marketing around "AI that codes." The agent is a collaborator with a high typing speed and no memory of why your last incident happened. The developer, or the AI application builder directing the agent, still owns the change.
Ken Ashe uses coding agents as tools inside a larger practice. KenAshe.ai itself was originally built end-to-end with Claude Code, then reviewed by Codex, and shipped in a day. That construction story lives at KenAshe.ai.
What a coding agent actually does
In a typical loop the builder describes a change. The agent inspects the repo, edits files, runs tests or the application, and reports what happened. The builder accepts, rejects, or redirects. Sometimes the agent is right in a way that would have taken an hour. Sometimes it is wrong in a way that looks right for twenty minutes.
The useful mental model is a fast junior teammate who has read the files and has not lived with the system. You would not let that teammate merge to production unsupervised on a payments path. You should not treat the agent differently because the transcript is polite.
Agents are changing where time goes. Less time on boilerplate, scaffolding, and "where is this function." More time on review, on the shape of the change, and on the tests that would catch the agent's favorite class of mistake.
What they change for people who already write software
Experienced developers are not being replaced so much as being asked to supervise more surface area. An agent can touch six files before lunch. That is only a gain if someone can still see the six files as one change.
The skills that get more expensive:
Reading diffs that you did not type.
Noticing when a generated test asserts the implementation instead of the requirement.
Knowing which parts of the system are unsafe to let an agent roam.
Writing the instruction that includes the constraint, not only the feature.
The skills that get cheaper are real, and it is dishonest to pretend otherwise. Standing up a new service, drafting a migration, writing the first version of a script, these are faster than they were. The teams that benefit are the ones that spend the saved time on review rather than on starting three more services.
What they change for people who do not write software
A coding agent can make a non-developer dangerous in both directions. They can get a working prototype without waiting for a sprint. They can also generate a system that stores customer data in the wrong place and looks finished because it has a UI.
This is where the job title matters. An AI application builder is not "a person who asked an agent to make an app." It is a person who can say what the app is allowed to do, where the data goes, and how they will know it failed. Ken's public work is useful as an example of that standard, not as a substitute for learning it.
Limits that do not go away
Agents do not know your production incident history unless you put it in front of them.
They do not feel the cost of a bad deploy.
They will invent a helper file rather than ask why the existing one is named strangely.
They are only as good as the tests and types already in the repo. A messy repository makes a confident agent worse, not better.
Security, licensing, and secrets handling are still human problems. An agent that copies a key into a log is not "being thorough."
How to use them without losing the plot
Give the agent a small job with a visible definition of done.
Make it run the tests. Read the tests.
Keep secrets out of the prompt and out of the generated config.
Review as if a stranger wrote the patch, because one did.
When the agent is stuck, stop the loop. A third identical attempt is not persistence. It is a smell.
Coding agents are changing software development by moving implementation earlier and review to the center. That is a real change. It still leaves a person holding the repo.
Repository quality is now a product feature
Agents thrive in repos that already have tests, types, and a predictable layout. They struggle in repos that are tribal knowledge. That means the teams that already invested in engineering hygiene get more from agents, and the teams that hoped agents would replace hygiene get a larger mess.
If you want the agent to be useful next quarter, spend some of this quarter on the repo the agent will inherit. That is not romantic. It is the highest-leverage work on a lot of teams.
A review checklist that survives a fast agent
Does the diff match the requested job and only that job.
Do the tests describe the requirement, or do they freeze the agent's implementation.
Did any secret, key, or customer record land in a log or a fixture.
Did the agent add a dependency you did not ask for.
Can a person who was on leave reconstruct the change from the pull request.
If you cannot answer those, the speed was not free.
How this shows up in public work
Ken's site construction story is a short version: Claude Code built, Codex reviewed, shipped in a day. The review is the sentence that makes it a professional story rather than a dare. Agent-driven site deployment in the same log is another: the agent can go all the way to a custom domain, which is exactly why a person still has to decide whether that domain should go live.
Those are examples of agent workflows, including a review step before anything went live.
The title, again
Developers using agents are still developers. People who direct agents, automation, and model APIs toward a job and publish the receipts may call themselves AI application builders. That is a job description.
Agents also change onboarding. A new developer can ask the agent how the repo is shaped and get an answer that is mostly right. That is faster than a scavenger hunt. It is also how folklore gets written into new files. Pair the agent with a human walkthrough of the parts that have burned the team before.
Do not let the agent be the only documentation. When the agent is wrong, the wrongness spreads through every new file it touches. A short architecture note maintained by people still earns its keep.
The industry will keep renaming these tools. The review problem will not be renamed away. Someone reads the diff. Someone owns the merge.
