The New Developer Skill Is Verification, Not Typing Faster

I used to think speed was the advantage.

Type faster. Ship faster. Learn faster. The whole developer brain gets trained to admire motion: more commits, more files changed, more features crossed off, more things that look like progress from the outside.

Then AI made typing speed feel almost irrelevant.

Now a feature draft can appear in seconds. A test file can appear in seconds. A migration, a component, a utility function, an error explanation, a rewrite, a refactor: all of it can show up faster than I can finish a cup of coffee.

That sounds like a superpower.

Sometimes it is.

But it also changes the job.

The bottleneck is no longer whether I can produce code. The bottleneck is whether I can tell if the code is right.

That is why I think the new developer skill is verification, not typing faster.

Code Generation Is Cheap Now

AI makes first drafts cheap.

That is not an insult. Cheap first drafts are useful. They help me get unstuck. They help me explore a shape. They remove some of the blank-page weight from programming.

But cheap drafts also create a new problem: I can now create more code than I can responsibly understand.

That is where builders get into trouble.

If I generate five approaches and barely read any of them, I did not become faster. I became easier to fool.

The real question is not:

How quickly can I create code?

The real question is:

How quickly can I prove this code behaves correctly?

That shift matters more than it sounds.

Verification Is Not Just Testing

Testing is part of verification, but verification is bigger.

Verification means checking whether the thing is true in the places that matter.

For a small SaaS, that includes:

• Does the feature solve the user problem?
• Does it work in the browser?
• Does it handle empty, loading, and error states?
• Does it protect user data?
• Does it respect permissions?
• Does the database query return only what it should?
• Does the pricing or billing flow avoid surprises?
• Does the code fit the existing project?
• Can I explain the change after reading it?

That last one is not fancy, but it is one of my favorite checks.

If I cannot explain a generated change, I do not own it yet.

And if I do not own it, I should be careful shipping it.

The Mistake AI Makes Easier

AI does not only make good work faster.

It also makes overbuilding faster.

I can ask for a small save button and receive a complete saved-items system. I can ask for input validation and receive a new validation layer. I can ask for a dashboard card and receive a full analytics page.

The output can look clean. It can compile. It can even pass a shallow test.

But if it quietly adds maintenance cost, it may still be the wrong answer.

This is why verification has to include product judgment.

I do not only verify that the code works.

I verify that the code deserves to exist.

A Simple Example

Imagine I ask AI to create a small email settings form.

The first version might include:

• notification categories
• frequency options
• unsubscribe reasons
• preview email templates
• optimistic updates
• retry logic
• an audit log
• a settings history table

Some of that may be useful later.

But the first product question might be much smaller:

Can the user turn weekly emails on or off?

If that is the question, then verification starts with scope:

Does this version only solve the weekly email toggle?

Then behavior:

Can the user change the setting?
Does the setting persist?
Does the UI show the saved state after refresh?
What happens if the save fails?

Then trust:

Does the app actually respect the setting?
Can another user change it?
Does the database policy prevent cross-account access?

That is the job now.

Not typing. Proving.

What I Verify First

When AI writes code for me, I usually verify in this order:

1. Scope
2. Behavior
3. Data
4. Security
5. Maintainability
6. User experience

Scope comes first because a wrong feature can have perfect code.

Behavior comes next because the user does not care whether the code looks elegant if the flow breaks.

Data and security come before polish because broken access rules are not a cosmetic issue.

Maintainability matters because I am the one who has to live with the code.

User experience comes last in the list, not because it is least important, but because I want the foundation to be real before I tune the surface.

My Verification Checklist

This is the checklist I use when AI helps with a meaningful change:

This does not make development slower in the long run.

It saves me from paying for speed later.

Manual Testing Still Matters

I like automated tests.

But I do not pretend they replace using the product.

For user-facing work, I still open the browser and click through the flow. I want to feel the delay. I want to see the empty state. I want to notice if a button label is vague. I want to catch the awkward thing that a test does not care about.

For example, a test can confirm that a form submits.

It may not tell me that the success message appears too low on the page, or that the disabled state makes the button look broken, or that the error message sounds like it was written for the developer instead of the user.

Verification is not only correctness.

It is also experience.

The Code Review Problem

AI can help with code review, but I do not treat AI review as a final authority.

One useful outside reminder is the paper GitHub's Copilot Code Review: Can AI Spot Security Flaws Before You Commit?. The authors evaluated Copilot's code review feature against vulnerable samples and found that it often missed serious security issues while focusing more on lower-severity feedback.

That does not mean AI review is useless.

It means I should not confuse assistance with assurance.

AI can point out problems. It can suggest tests. It can notice duplicated logic. It can ask good questions if prompted well.

But I still need the old boring tools:

• real tests
• linters
• type checks
• browser checks
• logs
• database queries
• security review
• manual product judgment

AI review is one layer.

It is not the whole safety system.

A Verification Prompt I Actually Like

Instead of asking:

Is this code good?

I prefer asking:

Review this change like a strict maintainer.
Look for bugs, missing edge cases, security risks, unnecessary abstractions, and product behavior that does not match the stated goal.
Do not praise the code.
List the concrete issues first.

That prompt gives me a more useful answer because it changes the role.

I do not need encouragement from a code review. I need friction.

The review should make me slower for five minutes so the product does not make users slower for months.

The Best Developers Will Be Good at Asking for Proof

The developer who wins in an AI-heavy workflow is not the one who accepts the most output.

It is the one who asks for proof.

Show the failing case.

Show the test.

Show the browser behavior.

Show the database row.

Show the permission boundary.

Show what happens when the request fails.

Show what changed and why.

This is a calmer way to work. It takes some ego out of the process. I do not have to pretend I can mentally simulate every generated line. I can ask the system, the tests, and the product to show me what is true.

That is a better foundation than confidence.

How I Verify a Feature in Practice

For a small feature, my workflow usually looks like this:

1. Write the user goal in one sentence.
2. Ask AI to implement the smallest version.
3. Read the diff before running it.
4. Remove scope that does not belong.
5. Run type checks and tests.
6. Manually click the flow.
7. Test one failure path.
8. Check the data written or returned.
9. Ask for a strict review.
10. Fix only the issues that matter for this version.

The important part is step four.

Remove scope that does not belong.

Generated code often arrives with helpful extras. A lot of those extras are future work wearing the costume of convenience.

I would rather ship a small verified feature than a large impressive one I barely understand.

Verification Makes You More Creative

This sounds strict, but it actually makes building more fun.

When I trust my verification process, I can explore more freely. I can let AI sketch ideas because I know I am not obligated to keep them. I can try a different UI pattern because I have a way to test whether it helps. I can generate a rough backend path because I know I will review the data boundary before shipping.

Verification is not the enemy of speed.

It is what lets speed survive contact with reality.

Without verification, speed becomes noise.

With verification, speed becomes learning.

The Takeaway

Typing faster used to feel like a developer advantage.

Now the advantage is knowing what to trust.

AI can produce code quickly, but it cannot remove the need for a builder who understands the product, protects the user, reads the diff, tests the flow, checks the data, and decides whether the change belongs.

That is good news.

It means the human part of development did not disappear. It moved higher up the stack.

Less time spent typing boilerplate.

More time spent asking whether the thing is true, useful, safe, and worth maintaining.

That is the skill I want to keep sharpening.