AI Coding Is Powerful. But Only If You Still Know How to Engineer.

AI is changing software development quickly.

There is no serious argument against that anymore. Anyone who has spent real time with modern coding models can see the productivity gains. Used properly, they can accelerate refactoring, generate boilerplate, help review code, explain unfamiliar codebases, write tests, document systems, and speed up the movement from idea to implementation.

But there is a dangerous misunderstanding spreading through the industry.

AI does not remove the need for engineering judgement.

It amplifies the engineer using it.

If the person driving the model does not understand architecture, requirements, trade-offs, failure modes, security, performance, deployment, and maintainability, the model will not magically compensate for that weakness. In many cases, it will make the problem worse because it can produce convincing output at high speed.

Bad engineering, generated faster, is still bad engineering.

The Real Value Is Not “Prompting”

A lot of the public conversation around AI coding focuses on prompting. That is part of it, but it is not the core skill.

The real skill is knowing how to structure the work.

In my own workflow, the most important step is not asking the model to write code. It is defining the problem properly first.

That means starting with:

clear requirements
a proper specification
an understanding of the existing codebase
a defined architecture
constraints around performance, security, data, and maintainability
small, scoped implementation tasks
rigorous review of the output

The model needs structure. Without structure, it drifts. It guesses. It fills gaps with plausible nonsense. It produces code that may look correct but does not fit the system.

This is where experienced engineers have a major advantage. They know what good looks like. They know when the model is guessing. They know when a solution is over-engineered, under-specified, unsafe, inefficient, or simply solving the wrong problem.

My Current AI Development Method

Over the last six months, I have gone deep into practical AI-assisted development while modernising our own internal recruitment and ATS platform.

The original system was an older PHP 5.1 codebase. The first stage was refactoring it to PHP 8.1. From there, I rebuilt large parts of the UI and started adding AI-first functionality into the platform.

That process forced me to deal with AI in the real world, not in toy examples.

Large legacy codebases expose the weaknesses of AI very quickly. Context gets lost. Tokens get wasted. The model forgets earlier decisions. It confidently suggests changes that break other parts of the system. It can misunderstand dependencies, duplicate logic, or solve a problem in a way that does not match the architecture.

So I built a more structured workflow around it.

At a high level, I use one model for architecture and specification, and another for implementation. Claude acts more like the senior architect or project manager. Codex acts more like the coding agent.

The process looks roughly like this:

Define the requirement clearly.
Turn it into a detailed specification.
Break the implementation into smaller tasks.
Feed scoped work to the coding model.
Review the output carefully.
Check it against the existing architecture.
Update the documentation and memory.
Move to the next task.

That separation matters.

If you ask an AI model to “just build the feature,” you are inviting chaos. If you give it a narrow task with clear inputs, constraints, expected behaviour, and reference documents, the quality improves dramatically.

Specifications Still Matter

This is the part many people miss.

AI does not make specifications obsolete. It makes them more important.

A weak specification produces weak output. A vague requirement produces vague code. A poorly defined problem produces a solution that may look impressive but solves the wrong thing.

The better the specification, the better the model performs.

I treat specification documents as the control layer. They tell the model what the system is, what the feature is meant to do, what constraints exist, what not to change, and how the output should fit into the broader architecture.

I also use markdown documents to preserve context. When a model starts to drift, I reset the session and feed it back the edited specification. That keeps the work grounded and avoids the slow collapse that often happens when a conversation gets too long.

This is not very different from managing a junior developer.

You do not give them a vague idea and hope they architect the whole system correctly. You give them context, constraints, direction, review, and feedback.

AI is no different.

Context Management Is Now an Engineering Skill

One of the biggest practical lessons has been context control.

The model does not need everything. It needs the right things.

Dumping an entire codebase into a model is expensive and often ineffective. The better approach is to map the codebase, retrieve the relevant parts, and give the model enough context to complete the task without overwhelming it.

That is why I built additional tooling around:

memory retention
token saving
codebase mapping
structured project documents
API-first architecture
local and cloud deployment workflows
controlled handoff between models

This is where the real productivity gains start to appear.

The coding model becomes much more useful when it can see the right files, understand the relevant dependencies, and work from a strong specification.

Without that, it behaves like a smart but careless developer with no memory and too much confidence.

AI Is Stronger in Some Domains Than Others

One of the more interesting points from recent conversations with embedded engineers is that AI is currently much stronger in application software than it is in serious embedded systems.

That makes sense.

Large language models have been trained on huge volumes of public web, application, scripting, and open-source code. There is far more public JavaScript, Python, PHP, C#, Java, and web application code available than there is high-quality proprietary embedded firmware.

The best embedded code is usually locked inside companies.

Safety-critical control systems, power electronics firmware, medical device firmware, automotive systems, industrial control platforms, aerospace systems, communication stacks, metrology systems. These are not sitting in public GitHub repositories for models to train on.

That creates a real limitation.

AI can help embedded engineers with boilerplate, documentation, stack traces, review, test scaffolding, and some driver-level work. But I would be very cautious about relying on a general-purpose model for embedded architecture, timing-sensitive design, memory-constrained systems, safety-critical logic, or hardware-specific debugging.

Those areas still require deep human expertise.

The model does not know your RAM budget unless you tell it. It does not feel the cost of heap churn. It does not understand your interrupt timing unless the information is explicit. It does not know your hardware errata, your board quirks, your manufacturing issues, or the field failures that shaped your design decisions.

The engineer still matters.

AI Can Move Fast. That Is Both the Opportunity and the Risk.

The productivity gain is real.

I can now take an idea, turn it into a specification, generate implementation scaffolding, build an API, connect components, test behaviour, and iterate far faster than before.

That speed is addictive.

But speed cuts both ways.

If you have strong engineering discipline, AI lets you move faster without losing control. If you lack discipline, AI lets you create technical debt at a rate you could never achieve manually.

That is the blind spot.

The industry is full of people treating AI coding as a replacement for software engineering. It is not. It is a force multiplier.

For a strong engineer, it can be a serious advantage.

For a weak engineer, it can create a very convincing mess.

The Best AI Users Will Be the Best System Thinkers

The engineers who get the most value from AI will not necessarily be the people who write the cleverest prompts.

They will be the people who can think clearly.

They will understand:

what problem is actually being solved
what the system constraints are
how to split work into clean components
where the risks are
what the model is likely to get wrong
how to verify the output
when to stop and rethink the design
when the model is guessing

This is why senior engineers, architects, and technical leads should not dismiss AI.

They are exactly the people best placed to use it properly.

AI does not remove the need for experience. It increases the leverage of experience.

The Bottom Line

AI-assisted development is not about replacing engineers.

It is about compressing the distance between problem definition and implementation.

But the quality of the result still depends on the quality of the thinking behind it.

The future does not belong to developers who blindly outsource their judgement to AI. It belongs to engineers who can combine deep technical understanding with structured AI workflows.

Clear requirements. Strong architecture. Tight specifications. Controlled context. Human review. Relentless testing.

That is where AI becomes useful.

Not as a magic coder.

As an accelerator for people who already know how to build.