AI in Software Engineering: Not One Tool, Multiple Facets
AI is not one tool. That is the ubiquitous judgment mistake across posts in social networks. AI is a set of very different capabilities, and treating them as one thing is where most confusion starts.
Some parts are genuinely useful in engineering. Some are neutral. Some are actively dangerous if you lean on them wrong.
Structure Discovery
It’s great at exploration and discovering structure when the problem is unclear. Reading unfamiliar codebases, summarizing messy logic, exploring hypotheses. This is where real engineering starts. It speeds up understanding, enabling faster, more robust delivery.
Drafting
It is useful for drafting. Once the shape is known - contracts, states, invariants - AI is decent at filling space with boilerplate, adapters, code scaffolding, test cases and fixtures, workflow samples, etc.
It only works after initial exploration is done so you can judge the validity of outcomes. If you skip that and let it "figure things out", your design becomes implicit and accidental, opening the door to rapidly accumulating complexity.
Greenfield Code Generation
AI coding-first in greenfield projects is an accessible prototyping tool for owners or product people without engineers. The result is an interim model capturing founders’ intentions, to be reverse-engineered into a proper engineering model. The ultimate goal is a robust, evolvable production system, not a complex throwaway.
Brownfield Code Generation
There is another facet. When the system already exists, the resulting code generation quality and human validation cost may differ diametrically. High-quality codebases enable high-quality generated code, lower validation cost, fewer errors, and sustainable evolvability. Poorly engineered codebases lead to the opposite: higher validation costs, increasing, unsustainable complexity and more errors.
Validation
AI validation is not self-sufficient. Human validation is required, ranging from none for “cosmetic” decisions to line-by-line professional checks for critical ones. The critical use cases may exclude AI validation altogether.
Deterministic Systems
In systems where correctness matters (state machines, financial flows, ingestion pipelines), AI-assisted coding becomes unreliable, human validation becomes time-consuming and still brittle for the things that must never break.
System-Wide Consistency
There is a parallel with tech debt: good systems stay clean because engineers continuously shape them, not because tools generate better code. AI does not replace competent engineering judgment. If anything, it makes lack of it visible faster.
So the practical takeaway is when AI is used well, it compresses time around decisions. Used poorly, it spreads implicit decisions across a codebase where no one owns them with unexpected results.
Finally, one of my favorite quotes revealing its truth in software engineering:
"Questions about whether design is necessary or affordable are quite beside the point: design is inevitable. The alternative to good design is bad design, not no design at all." - Douglas Martin