Assistance That Works On Its Own

The other half of the field does not wait for you.

You give a tool a goal, it works for a while on its own, and it comes back with something finished. This is the part that has moved fastest, and it is genuinely impressive.

Agents

A coding agent gets a goal and permission to act. It reads the project to work out how things are arranged, forms a plan, edits files, runs commands and tests, reads what failed, and tries again. Then it hands you a complete proposed change.

They turn up in three shapes. Inside your editor, where you watch it work and can interrupt. On the command line, pointed at a project folder. And running remotely, where you describe a task, go and do something else, and come back to a proposed change waiting for review.

You are handing over a piece of work in the way you would hand it to a capable colleague who does not know your product. Which means the two moments that matter are the handover and the return.

Review bots

Related, and increasingly ordinary: an AI that reads proposed changes and comments on them before a person does.

They are good at the things people are bad at reviewing, which is the boring, consistent stuff. Forgotten error handling, a variable that is never used, a pattern that does not match the rest of the project, an obvious security mistake.

They are weaker at the thing human review is actually for, which is asking whether this change should exist and whether it fits where the product is going.

Prompt to application

Then there are the tools you describe an application to, and a working one appears. Screens, a database, sign-in, deployed somewhere you can click.

For getting an idea in front of people, this is remarkable, and it has genuinely put building software in reach of people who would never have got past the setup instructions. Much of what people mean by vibe coding happens here.

What arrives is a real application, and real applications have questions attached: where is the data stored, who can reach it, what happens when two people use it at once, what does it cost when a thousand do? Are there regular backups of the data?

Verification is what your judgment is for

Here is the shift. With in-editor help you check as you go, and a bad suggestion costs you the second it takes to reject it. With an agent you get a finished result, and checking becomes a deliberate act.

Verifying generated code means asking three separate questions.

Was the request right? An agent builds what you asked for. Ask for the wrong thing and you get it, quickly, and it works. This is the failure people underestimate.

Does it do what it claims? The change runs and the tests pass. Do the tests cover the behavior you actually care about, or only the behavior the code happens to have? An agent that writes its own tests can produce a beautifully green run around a misunderstanding.

Should it be in the product? Whether it touches the right files, keeps private data private, works with everything around it, and can be understood by whoever inherits it. Nothing about a passing test answers any of that.

None of this is a reason to avoid agents. It is a description of where your attention goes once you use one. It’s the reason why you still need to understand software, programming, hardware, networking, and the rest of it.

Permissions are a real decision

An agent that can edit files, run commands, and reach the network is a program with your access. Most tools let you decide how far that goes: read only, edit but ask before running anything, use a sandbox where mistakes stay contained, or give it complete freedom.

Match that to what it is working on. A scratch project and the system that holds your customers’ data do not deserve the same latitude, and “it has been fine so far” is not a security model. Language models make mistakes, and I have seen it first hand. They can cause data loss in unexpected ways. Let me just name one that happened to me: by running tests against the production database instead of the test data, a coding agent once removed all my production data. I’m old and wise enough to make daily backups, so what I lost was a day’s worth of work, which still hurts. Lesson learned.

The same tool, two very different outcomes

An experienced developer hands an agent a well-scoped task, reads the change, spots that it silently dropped a check, asks for a fix, and ships something good in an hour.

Someone without that reading ability gets the same change, sees the app still works, and ships it. The dropped check surfaces months later as a bug nobody can trace.

Same tool. Same output. The difference is entirely in what the person could see.

That is why this chapter sits in a course about whether to learn programming, and it is the honest answer to whether these tools make learning unnecessary. They make it worth more. The final lesson puts that together with everything else.