The strangest thing about AI coding tools is how quickly they make you feel productive.

You type a request, watch several files appear, and suddenly there is a login page, a database connection and a button with a tasteful blue gradient. Ten minutes earlier you had an empty folder. Now the terminal is scrolling like you work at NASA.

Then you click the button.

Nothing happens.

This is roughly where the real story of AI and software engineering begins. AI is getting very good at producing code. Software, unfortunately, has never been only code.

The blank screen has lost some of its power

I don’t miss starting from zero.

There was a time when building a small feature meant opening documentation, searching old Stack Overflow answers and copying a configuration file from another project while quietly hoping it still applied. A missing comma could consume half an evening.

AI removes a lot of that.

It can sketch an API, explain an unfamiliar function, write a test or tell you why an error message is less mysterious than it looks. Routine work is faster, and learning an unfamiliar codebase is less painful than it used to be. That shift is already visible in engineering work.

This is good. I don’t believe people become wiser by manually typing boilerplate for the fiftieth time.

But there is a catch.

Fast code creates slow problems

A friend recently used an AI assistant to add email login to a side project. The code looked sensible. The screen worked.

A few days later he discovered that different users could sometimes see the same cached data.

The AI had completed the task he described. The problem was that the task was too small. He had asked for login, not isolation between users, safe session handling or protection against odd behaviour in two browser tabs.

This happens constantly now. AI makes the visible part arrive quickly, which creates the impression that the feature is almost finished. Often it is just beginning.

Software engineering has always contained hidden questions. What happens if the payment succeeds but the confirmation request times out? Can someone press the button twice? What should the app show when the database is unavailable?

AI can help answer these questions. It rarely volunteers all of them at the right moment.

The job is shifting away from typing

For years, programming skill was easy to confuse with typing speed and memory. The developer who remembered a library function looked impressive. So did the person who could produce a page without checking documentation.

That advantage is shrinking.

The valuable engineer now is often the one who notices that the request itself is wrong. They ask why the feature exists, which failure matters, what data should never leave the system and whether a simpler solution would work.

Here’s the thing: most engineering meetings were never about semicolons. They were about trade-offs disguised as technical discussions. Should the team release today with a known limitation? Is the faster database worth the migration risk? Do customers need another setting, or are we avoiding a difficult product decision?

AI has not removed those conversations. It has made them more central.

Junior developers have a new problem

I’m not convinced AI makes learning to code automatically easier.

It makes getting an answer easier. Those are different things.

A beginner can now generate a working feature before they understand the language, the framework or even which file controls what. That feels wonderful until something breaks. Then every line is equally unfamiliar.

I’ve seen people paste an error into an assistant, apply the suggested fix, receive a second error and repeat the process six times. Eventually the app works, but nobody knows why. The code has become a pile of successful negotiations with a machine.

That is dangerous—not because beginners are cheating, which is a silly way to describe tool use, but because confusion is being postponed rather than resolved.

Use the assistant. Ask it to explain the call stack. Ask why one fix is safer than another. Delete a generated function and rebuild it yourself. Keep the parts you can roughly describe to another person.

You don’t need to memorise everything. You do need some ownership.

Code review is becoming the main event

Reading code may soon matter more than producing the first draft.

Generated code often looks polished. Names are clean. Comments are confident. The structure feels familiar enough that reviewers relax. This is exactly when strange assumptions slip through.

The hard bugs sit inside normal-looking logic. A discount is applied before tax instead of after it. A background job retries forever. A support dashboard exposes information that only finance should see.

Reviewing this properly requires context, and context is the thing AI usually has least of.

A company’s codebase contains years of awkward decisions, customer promises and shortcuts made during bad weeks. Some rules exist because of regulation. Others exist because one important client still uploads a spreadsheet in a format last popular in 2014.

No model understands that history merely because it can read the repository.

More software will be built, including bad software

The cost of creating a small app has fallen. People who would never have hired a developer can now build internal tools, prototypes and personal automations. I like this part.

It also means the internet will receive more abandoned dashboards, insecure login systems and subscription products whose founders cannot repair them after the first API update.

We are not heading toward less software. We’re heading toward far more of it.

And maintenance will remain unfashionable. Everyone enjoys generating version one. Nobody posts a cinematic video about updating dependencies, fixing permissions and explaining why last month’s data no longer matches.

Anyway, that work is where engineering lives.

The useful skill is knowing when not to trust it

Good developers won’t prove themselves by refusing AI. That would be like refusing autocomplete because “real programmers type every character.”

They’ll use it aggressively for the right things: exploring unfamiliar code, drafting repetitive tests, comparing approaches or summarising a long error log. They’ll slow down around authentication, payments, permissions, privacy and anything difficult to reverse.

The distinction is judgment.

AI is changing software engineering because it has made code abundant. The scarce part is now deciding what the code should do, checking what it actually does and accepting responsibility when those two things are not the same.

The cursor still blinks. It just isn’t the frightening part anymore.