AI Coding, GIGO, and the Return of First Principles

I had a coffee cup in 1979 that said GIGO: Garbage In, Garbage Out.

That pretty much sums up where we are with AI coding today.

Everybody wants to believe this time is completely different. In some ways, it is. The speed is different. The cost curve is different. The tooling is different. The accessibility is different. A single person can now build what used to take a small team, and they can do it in days instead of months.

But the fundamentals are not different.

Everything we really needed to know about building software, we basically learned in the 1950s, 60s, and 70s: requirements matter, design matters, testing matters, debugging matters, architecture matters, and bad assumptions compound over time.

AI does not repeal computer science. It accelerates it.

And that is both the opportunity and the danger.

The Early-Innings Problem: AI Can Create Code Debt Faster Than Humans Ever Could

The biggest mistake people are making right now is assuming that because AI can generate code quickly, the resulting system is automatically better.

It is not.

AI can generate working code. It can generate beautiful code. It can generate tests, APIs, UI screens, infrastructure templates, database schemas, and deployment pipelines.

But it can also generate code debt at machine speed.

That is the pitfall.

In the old world, a bad developer might create technical debt slowly. In the AI world, a non-technical or under-directed builder can create a giant pile of plausible-looking complexity in a single afternoon.

The code compiles. The screen renders. The demo works.

But underneath, you may have:

• Poor separation of concerns.
• Duplicated logic.
• Inconsistent naming.
• Weak error handling.
• Bad security assumptions.
• No real observability.
• Half-baked data models.
• Broken edge cases.
• Fake tests that don't prove anything.
• Infrastructure that "works" but won't scale.
• Authentication flows nobody fully understands.
• And features duct-taped together by prompts instead of design.

That is the new version of technical debt.

It does not look like broken code at first.

It looks like progress.

Hallucination Is Not Just Wrong Answers — It Is Wrong Architecture

People talk about AI hallucination as if it only means the model made up a fact or invented a library call.

That is only the obvious version.

The more dangerous version is architectural hallucination.

The model confidently builds a pattern that seems reasonable but is not appropriate for the actual system. It picks the wrong abstraction. It creates services you do not need. It adds complexity too early. It invents configuration that looks real. It mixes responsibilities across layers. It makes an assumption about security, identity, deployment, or state that is slightly wrong — and then builds 3,000 lines of code on top of it.

That is where teams get hurt.

Because AI-generated code often looks professional enough that people stop questioning it.

And that is exactly when you need to question it the most.

The Same Old Problem: Bad Requirements Still Produce Bad Software

This is why GIGO still matters.

If you give a developer bad requirements, you get bad software.

If you give AI bad requirements, you get bad software faster.

The model is not magic. It is an amplifier. It amplifies clarity, but it also amplifies confusion.

If your prompt says, "build me a journaling feature," you will get a journaling feature. Maybe even a decent one. But what does that mean?

• Is it private by default?
• Does it support mood tagging?
• Is it searchable?
• Can AI analyze it?
• Can a user delete it?
• Is deletion hard delete or soft delete?
• Is it encrypted?
• Does it sync across devices?
• Can it be shared with a provider?
• Does it need moderation?
• Does it need audit history?
• What happens when the network fails?
• What happens when AI analysis fails?
• What happens when the user is anonymous?
• What is the data retention policy?

That is not "coding."

That is product thinking, architecture, requirements, privacy, workflow, and design.

AI can help with all of it, but it cannot own it.

That is still on us.

Software Is Physics: Energy In, Quality Out

I think about software almost like physics.

There is an energy density per line of code — or more importantly, per feature.

The quality of the software is proportional to the quality of energy put into the system.

That energy can come from a developer, architect, product owner, designer, QA engineer, user researcher, or AI engineer. But the energy has to come from somewhere.

AI lowers the cost of implementation. It reduces the friction of coding. It makes syntax, boilerplate, scaffolding, refactoring, and test generation dramatically cheaper.

But it does not eliminate the need for clear thinking.

You still need the energy of:

• Design
• Intent
• Constraints
• Tradeoffs
• Architecture
• Testing strategy
• Security thinking
• User experience
• Operational thinking
• Failure analysis

AI can help execute those things, but it cannot replace the responsibility for them.

The Real Productivity Gain Is Not "AI Writes Code"

The real productivity gain is not just that AI writes code.

The real gain is that AI can participate in the whole software lifecycle if you know how to use it.

That means using models to do spec-driven development up front, not just asking them to code.

Before writing code, I want the model to help define:

• The feature behavior
• The API contract
• The data model
• The edge cases
• The security model
• The failure modes
• The deployment impact
• The unit test plan
• The integration test plan
• The rollback plan

Then I want it to build from the bottom up.

• CRUD first.
• Services next.
• APIs next.
• Routes next.
• UI next.
• Infrastructure next.
• Deployment next.
• Performance checks next.
• Security scans and best practices throughout.

That is where AI becomes powerful.

Not as a random code generator, but as a disciplined software engineering partner.

QA Is Being Completely Repriced

One of the biggest shifts I am seeing is in QA.

The latest models are already cheaper, faster, and in many cases better than traditional QA for a large class of testing work.

Not all QA. Not human judgment. Not deep product empathy. Not exploratory testing from a real user's perspective.

But for structured testing?

AI is already very strong.

• It can generate unit tests.
• It can test CRUD paths.
• It can inspect API contracts.
• It can test REST routes.
• It can validate templates and deployment files.
• It can check performance assumptions.
• It can look for missing edge cases.
• It can review best practices.
• It can compare implementation against requirements.
• It can identify inconsistent behavior across layers.

That changes the economics.

A lot of traditional QA work that used to require a team can now be done at token cost, continuously, if the process is set up correctly.

That is not a small improvement.

That is a 1,000-to-1 cost curve shift in some parts of the development lifecycle.

But again, only if the requirements and test intent are clear.

AI cannot test what nobody specified.

The Human Role Moves Up the Stack

This is where people get the AI story wrong.

They think AI eliminates developers.

I think AI changes what a good developer, architect, product manager, and QA person actually does.

The human role moves up the stack.

• Less time fighting syntax.
• Less time writing boilerplate.
• Less time wiring repetitive CRUD.
• Less time manually creating obvious test cases.

• More time defining the right thing to build.
• More time validating the business logic.
• More time thinking through user workflows.
• More time designing clean boundaries.
• More time reviewing AI output.
• More time managing risk.
• More time acting like a technical product owner.

That is the real shift.

The best AI builders are not just "prompt engineers." They are technical product owners, architects, QA thinkers, and AI engineers rolled into one.

They know what good looks like.

That is the difference.

This Time Is Different — But Not That Different

So yes, this time is different.

• The productivity curve is different.
• The cost curve is different.
• The speed is different.
• The accessibility is different.
• The leverage is different.

But the fundamentals are not different.

• We still need requirements.
• We still need design.
• We still need testing.
• We still need debugging.
• We still need architecture.
• We still need disciplined engineering.
• We still need humans in the loop.

The difference is that AI compresses the cycle.

What used to take weeks can take days. What used to take a team can sometimes be done by one highly capable person with the right tools. But that only works when the human provides direction, judgment, and taste.

AI gives us accident-free coding as a commodity at token cost.

But it does not give us accident-free thinking.

That is still the job.

The Bottom Line

AI is not the end of software engineering.

It is the return of software engineering fundamentals at a much higher speed.

GIGO still wins.

• Bad requirements still create bad systems.
• Weak design still creates weak products.
• Poor testing still creates brittle releases.
• Bad architecture still creates long-term debt.
• And unclear thinking still produces garbage — only now it produces it faster.

The opportunity is massive. But the winners will not be the people who simply generate the most code.

The winners will be the people who can combine AI leverage with old-school engineering discipline.

• People who can define the feature.
• Shape the requirements.
• Design the system.
• Guide the model.
• Review the output.
• Test from the bottom up.
• And keep the human judgment in the loop.

That is the future role: part product manager, part architect, part QA lead, part AI engineer.

The code is getting cheaper.

The design is getting more important.

And that is still on us.