menu

AI Coding: Architecture or Archaeology?

●2 ●19 ●51
calendar_today • schedule1 min read
— Originally published at valentineshi.dev

One of the loudest claims around AI coding tools is that one developer can now do the work of a whole team. Ship features in hours. Replace weeks with prompts. Move 10x faster.

Well, maybe. But only if you pretend that software development is mostly typing code. It isn't.

For any system more complex than basic CRUD, the hard part is not producing source files. The hard part is knowing what the source files must preserve.

The model. The boundaries. The contracts. The states. The invariants. The failure modes. The tests that actually prove something. The decisions that stop the system collapsing under its own ambiguity six months later. AI does not remove that work.

It can help draft it. It can challenge it. It can produce options. It can fill in boilerplate once the shape is clear. But it cannot own it.

If you let the tool discover the model by generating code, you don't get architecture. You get archaeology. Later, someone has to dig through the result and work out what assumptions accidentally became real. That's not acceleration. That's debt with better autocomplete.

That's the difference between using AI as a tool and letting AI smear decisions across a codebase. For production systems, modeling is not optional. Correctness is not optional. Evolvability is not optional.

So no, AI coding agents do not make software engineering disappear. They make weak engineering visible faster. And in the hands of a good engineer, they can be useful. Sometimes very useful.

15 Comments

•

Very interesting perspective, thanks for sharing!

3 votes
•

@[Emmanuel Cortes] My pleasure :)

1
•

Yes, agreed.
While AI can greatly accelerate the coding process, it can't replace the fundamental work of architecture and design. The model, boundaries, states, failure modes, and tests are the backbone that ensures the system works correctly and can evolve over time. AI should be seen as an enabler, not a replacement, for the core responsibilities of software engineering.

3 votes
•

@[Gimi] Absolutely. Coding with AI, when you know what to ask it and how the result should look like is free from code typing, that, to my liking, feels great surprisingly. Like someone has taken from me a boring part and making interesting things to appear faster and feel more rewarding.

1
•

To a certain extent, this is true. It doesn't have to be, but for most prompt engineers it is.

Did you know you can direct the AI to program according to principles? The same principles you use that lift you above the neophyte in terms of competence. The model contains all of the knowledge you yourself have absorbed and internalized and probably not even named. Design patterns. SOLID. All the good stuff is out there, waiting to be internalized by your agent.

You just have to direct it to go out and get it and synthesize.

"You are an expert programmer" does not do that. That's cosplay.

3 votes
•

@[demoran] Right, a practical note of yours. AI does not do what you describe out of the box, one has to instruct it clearly that is normally done with skills/rules (depending on LLM or a coding environment, e.g. Cursor) or just a project guide markdown files. AI would follow (99% of time) exact patterns (beyond SOLID or GoF) you describe in these files up to the giving it templates. In this regard it does really good job.

0
•

Valentine Shi hit the nail on the head. AI coding often leads to 'Archaeology'—digging through accidental assumptions.

This is why I built Penta-V Kernel. It provides the Architectural Anchor that AI lacks. While AI drafts the code, Penta-V enforces the invariants and the boundaries at a sub-nanosecond scale (845ps).

We don't let AI 'smear decisions' across the codebase; we lock them into a sovereign geometric manifold. Architecture is not optional, and Penta-V makes it enforceable.

1 vote
•

The deeper problem isn't that AI writes bad code — it's that it flattens architectural decisions into local code suggestions. It re-applies generic patterns without seeing the boundaries, contracts, or invariants the team has already committed to. For a junior engineer this looks like authority; for the system, it's slow erosion. Disciplines like DDD exist precisely because those decisions can't be inferred from the file you're editing — and that's the layer AI agents currently can't see. The result is what the post calls archaeology: speed of delivery wins, and quality, scalability, permissions, and privacy quietly lose.

2 votes
•

@[Hussein Mahdi] Thanks for pointing out this. All those things, including code templates can/should be built into AI's reasoning with the guiding files. They can be re-used across projects, and customized per project. The thing is one has to know what to write in these guidelines and what the desired AI output should look like. The bad code and generic system decisions come as out-of-the-box behavior that can be redefined.

1
•

This hits exactly right, and I say that as someone who uses AI agents every single day to ship production Flutter and Firebase apps.
The productivity gain is real. I've built complete multi-role platforms — customer app, provider app, driver app, admin panel, backend — in a fraction of the time it would have taken before. But that speed only existed because I already knew what I was building. The data model was clear in my head. The auth flows were designed. The state boundaries were decided. The edge cases were mapped.
The AI filled in the implementation. I owned the thinking.
The times I've seen it go wrong — including in my own work early on — is exactly what you described. Letting the tool discover the shape of the system by generating code. You end up with something that works until it doesn't, and debugging it feels like excavating someone else's bad decisions.
The "10x developer" claim is only true for the engineer who already thinks clearly about systems. For everyone else it's just 10x the confidence with the same amount of understanding. That combination is genuinely dangerous in production.
AI didn't replace engineering judgment. It just made the gap between good and weak engineering impossible to hide.

2 votes
•

@[MorningStar47] That is greatly put real life example. Thanks for elaborating.

1
•

This is a profound way to frame the current shift. We’ve spent decades training developers to be Architects—to prioritize clean blueprints, dry code, and intentional structure.

But with the rise of LLM-generated code and massive legacy debt, the job is increasingly becoming Archaeological. We aren't just building; we’re excavating intent from a layer of 'hallucinated' soil.

I’ve been leaning into this lately through the lens of Technical Forensics. If we accept that we are archaeologists, then our tools shouldn't just be 'builders' (IDE extensions)—they should be 'calipers' (auditors).

  • The Architect asks: 'How do I build this feature?'

  • The Archaeologist asks: 'Why does this existing pattern exist, and what is the provenance of this logic?'

In my recent work with the Model Context Protocol (MCP), I’ve found that the most valuable AI agents aren't the ones that write the most code, but the ones that provide the best 'stratigraphy'—helping us understand the layers of context that lead to a specific implementation.

We need to stop teaching developers only how to lay bricks and start teaching them how to use a brush and a magnifying glass. The future of senior engineering is 20% construction and 80% forensic verification.

2 votes
•

@[Ken W. Alger] Agree. I increasingly think the same. The cost of producing code is collapsing much faster than the cost of validating and understanding it.

1
•

@[Valentine Shi] Spot on. We are rapidly moving from an era of execution scarcity to an era of verification scarcity.

When LLMs can generate 10,000 lines of syntactically correct code in seconds, the role of the senior leader shifts entirely. We aren't authors anymore; we are forensic auditors ensuring system integrity, state management, and deterministic boundaries. The real enterprise bottleneck isn't the pipeline—it's the chain of custody for code validity. Exceptional framing.

1
•

@[Ken W. Alger] Exactly.

1
🔥 Join developers growing publicly
Share your knowledge, build in public, and grow your developer presence with a global community.
Join CoderLegion

More Posts

Local-First: The Browser as the Vault

Pocket Portfolio - Apr 20

The Sovereign Vault — A Comprehensive Guide to Protocol-Driven AI

Ken W. Algerverified - Jun 4

Your AI Doesn't Just Write Tests. It Runs Them Too.

Kevin Martinez - May 12

Split-Brain: Analyst-Grade Reasoning Without Raw Transactions on the Server

Pocket Portfolio - Apr 8

I’m a Senior Dev and I’ve Forgotten How to Think Without a Prompt

Karol Modelskiverified - Mar 19
chevron_left
Valentine Shi
2.1k Points • 72 Badges
Eastern Europe • valentineshi.dev
16Posts
37Comments
14Connections
Senior Backend / Full-Stack / Founding Engineer specializing in complex business systems. Node.js, T... Show more

More From Valentine Shi

AI and Skill Offloading: from 2023 to 2026

Software Engineering After the AI Hype

Is Spec-Driven Development The Same As Vibe Coding?

Related Jobs

View all jobs →

Commenters (This Week)

1 comment
1 comment

Contribute meaningful comments to climb the leaderboard and earn badges!