Code Is Worthless, Senior Developers Are Priceless!

Once upon a time, code was one of the most valuable assets a company could own.
It took years to build a serious codebase, and that effort created a real competitive advantage.

That is no longer true in the same way.

Today, with the right AI tools and a small number of strong engineers, it is possible to build in weeks what used to take years. The cost of producing code is collapsing.

But that does not mean software engineering is becoming less important.
It means the real value is moving somewhere else.

The advantage is no longer in writing code line by line.
The advantage is in shaping systems: architecture, domain design, performance, governance, maintainability, and delivery discipline.

That shift is exactly why senior engineers matter more now — not less.

I was fortunate to be among the early engineers who got access to AI-assisted coding through GitHub Copilot before it was publicly released. In the beginning, it felt like a fascinating experiment — useful, fun, and occasionally impressive — but still far from something I would trust for serious engineering work.

That changed.

Since January 2026, the models have taken a clear leap forward. We are now in a phase where AI can generate stable, repeatable, and increasingly production-capable code in ways that simply were not realistic before. And the curve is still moving.

Since 2025, I have made it a habit to periodically challenge myself to build software without manually touching the code at all — That is the rule of the game, not even a single character directly in the code. These are not customer projects. They are personal challenge projects I use to test a bigger hypothesis:

Can a senior engineer use AI to drive the full application delivery lifecycle while still preserving software quality, architecture integrity, and long-term maintainability?

That is the real goal.

For me, this is not about shortcuts. It is about understanding where AI genuinely improves engineering throughput, where it still fails, and what kind of leadership is required to make AI-generated code viable in an enterprise context.

This Is Exactly Where AI Code Quality Becomes a Leadership Problem

A lot of people are understandably impressed by what AI can generate today. And they should be.

With the right setup — good prompts, clear boundaries, agent instructions, architecture context, and tools like OpenCode, codex, or claude code — it is now possible to generate large portions of an enterprise-style codebase remarkably fast.

But that does not mean AI automatically produces enterprise-grade software.

That distinction matters.

In enterprise environments, the standard is not “it runs.” The standard is:

Does it meet AI code quality expectations?
Does it follow architectural and domain boundaries?
Is it maintainable by humans and future agents?
Does it support traceability, reviewability, and governance?
Can it fit into a disciplined ASDLC / ADLC process?

This is where I think the market conversation is still too shallow. AI code generation is real. AI code quality is still highly dependent on the person directing it.

My Ongoing Prompt-Only Engineering Challenge

During my prompt-only or AI-first build challenge instead of manually writing the implementation myself, I try to get the system built by directing the AI through:

product intent,
user stories,
architecture constraints,
coding principles,
review loops,
and corrective prompts.

I do this deliberately because it reveals something important:

If you know how to build software well, AI can dramatically accelerate you. If you do not, AI will accelerate your mistakes.

That difference is easy to miss when the output looks polished.

GoGetCV Was One of Those Challenge Projects

One of my latest personal challenge projects was GoGetCV.

This is important to clarify: GoGetCV was not a customer delivery project. I was suppsed to help my wife to get her CV in order, then I said lets turn it to one of my own experiments in pushing AI-first engineering further and testing what is now realistically possible.

The product itself also makes the challenge more interesting.

GoGetCV is not just a generic CV builder. Its value is in the domain logic: it creates evidence-based, job-tailored CVs and cover letters based on role requirements, and it learns from a user’s previous evidence to suggest new relevant evidence. That makes it much more than a form-based content generator.

In other words, it looks simple from the outside, but the useful part is hidden in the logic.

And that is exactly why it is a good test case for AI-generated software quality.

Could a non-developer — or a less experienced developer — generate an application that looks similar on the surface?

Absolutely.

Could they generate one that behaves correctly, performs well, keeps its domain logic coherent, and remains maintainable over time?

Not reliably. Not yet.

What AI Still Gets Wrong Without Senior Oversight

1) It optimizes for task completion, not code quality

The first thing I keep seeing is that the models optimize for satisfying the prompt at the most immediate level. They do what was asked — but rarely what an experienced engineer knows should also be true.

In one early iteration of GoGetCV, loading a candidate page took 85 seconds.

The reason was simple:

the generated solution fetched entities sequentially,
resolved dependencies one call at a time,
and never recognized that the read path should be redesigned.

Technically, the feature worked.

From an AI code quality perspective, it was unacceptable.

I reworked it using a more appropriate read model, following CQRS properly and switching to a more suitable query approach where needed.

The result dropped to 23 milliseconds.

What’s interesting is not just the improvement itself. It’s that the AI did not independently identify the architectural optimization path when I simply asked the agent to fix the problem, provided logs, and tried to help it reason its way through. It was only able to solve the issue once I handed it the answer on a silver platter: use a complex SQL join query for read-only operations.

AI can implement improvements. It still often needs a human to define what “good” means.

2) It drifts toward weak domain design

Another recurring issue is that the model tends to push business logic into the wrong places.

For example, I repeatedly saw it writing application logic directly inside command handlers, while domain entities remained little more than get/set containers.

That may still produce a functioning system, but it creates long-term structural damage:

domain knowledge becomes fragmented,
change becomes riskier,
boundaries become blurry,
and the codebase becomes harder for both humans and AI agents to reason about later.

This is where ASDLC discipline matters.

If we treat AI-generated code as just output to merge, without enforcing architectural review and design intent, we are not modernizing software delivery — we are simply automating technical debt creation.

3) It produces verbose, duplicated, agent-hostile code

Even strong models still prefer to generate large blocks of code in one go.

If similar functionality is needed in multiple places, they often regenerate it instead of extracting reusable abstractions. The result is usually:

long functions,
duplicated logic,
inconsistent patterns,
and fragmented maintainability.

That creates two serious problems.

First, the code becomes harder for humans to review and evolve. Second, future AI agents also struggle more, because they depend on a codebase that is discoverable, modular, and semantically structured.

This is a point many teams still underestimate: bad code quality does not only hurt developers. It also degrades future AI effectiveness.

Why This Is Really About AI Governance

In enterprise settings, the conversation should not be limited to “Can AI generate code?”

The more important question is:

How do we govern AI-generated code so that speed does not erode engineering standards?

That is where AI governance comes in.

To me, AI governance in software delivery includes at least the following:

clear architectural constraints,
explicit domain modeling rules,
traceable prompt-to-output workflows,
review checkpoints,
coding standard enforcement,
performance and security validation,
and accountability for what gets merged into production.

This fits naturally into an ASDLC / ADLC way of working.

If AI is part of the delivery chain, then AI cannot sit outside the lifecycle. It has to be included in:

design,
generation,
verification,
review,
and continuous improvement.

Otherwise, organizations will gain speed in the short term and lose maintainability, auditability, and trust in the long term.

My View: AI Has Made Senior Engineers More Valuable, Not Less

Based on my latest experiments, I believe it is now fair to say this:

Generating enterprise-style code is becoming easy. Generating enterprise-grade software is still needs expertise.

And the difference between those two things is exactly where senior engineers create disproportionate value.

A seasoned developer does not just check whether the code compiles. They shape:

the domain model,
the boundaries,
the trade-offs,
the performance characteristics,
the governance model,
and the long-term maintainability of the system.

That is why I do these challenge projects.

I want to understand, in practical terms, how far AI can go when it is directed properly — and where human engineering judgment remains non-negotiable.

So when I say that I built something like GoGetCV through an AI-first approach, the point is not “look, AI replaced software engineering.”

The point is almost the opposite.

It is proof that when AI code generation is guided by strong engineering principles, AI governance, and ASDLC discipline, it becomes a force multiplier.

But without that? You may still get a nice demo. You just do not get a system you should trust.

Final Thought

The most misleading thing about this moment in our industry is that polished output is easy to confuse with mature delivery capability.

Yes, almost anyone can now produce a nice-looking app with thousands of lines of generated code.

But if the goal is real software quality — the kind enterprises depend on — then AI code quality, AI governance, and ASDLC maturity matter more than ever.

That is why I keep running these personal AI-first engineering challenges.

Not to prove that developers are obsolete. Not to claim that AI can do everything. But to understand how software should be built in the next era — and how experienced engineers can use AI responsibly to build better systems, faster.

And occasionally, those experiments become products with real value.

GoGetCV is one of them.