I was out jogging again this morning, thinking about a LinkedIn post from an old friend. He’s sharp — the kind of person you genuinely enjoy disagreeing with because it makes you think harder.
His argument was essentially this:
AI can help you build the first MVP.
But you still need real engineers to take it to the next level.
If you had asked me several months ago, I would have said, “Absolutely.”
If you ask me today?
I’d say: There are some strong caveats that make me lean toward no.
What Has Actually Changed?
In the past, a lot of engineering value came from knowing:
- The language syntax
- The framework quirks
- The AWS Well-Architected pillars
- The exact PowerShell command
- The right SQL query
- The plugin nobody else understood
Complexity was gated behind people.
If you wanted to generate a report pulling data from multiple systems, you either:
- Knew how to script it, or
- Knew the person who did
Today?
You write a prompt.
You iterate.
You refine.
The complexity is no longer in remembering syntax. It’s not even primarily in knowing the exact architecture document by heart.
The efficiency curve has shifted.
Instead of reading the entire AWS Well-Architected Framework, you can prompt your way directly to the relevant pillars and implementation patterns in minutes.
That’s not trivial.
That’s transformational.
The Real Shift: Where Value Is Moving
I think the value of engineers is shifting in two major ways.
1. The Ability to Learn and Study Still Matters — But Differently
I will always believe the ability to study systems deeply is core.
Understanding distributed systems, security boundaries, failure modes — that still matters.
But the bottleneck isn’t information access anymore.
It’s synthesis.
You don’t need to manually comb through 200 pages of documentation to find the three things that matter.
AI compresses discovery time.
So the differentiator isn’t “who knows the most syntax.”
It’s:
- Who understands systems?
- Who can validate outputs?
- Who can refine intent?
- Who can steer iteration?
And this leads to something equally important:
Documentation still matters.
Engineers still need to write it.
Engineers still need to revisit it.
Engineers still need to refine it.
But now documentation isn’t just static reference material.
It can be ingested into RAG (Retrieval-Augmented Generation) models and surfaced instantly in context.
That changes its utility.
Instead of hoping someone reads a Confluence page from three years ago, you can structure documentation so it becomes living, queryable organizational memory.
2. Organizational Knowledge Is No Longer Forced to Be Siloed
Historically, institutional knowledge lived inside engineers.
We all know this dynamic. It’s practically the premise of The Phoenix Project.
One person knows how the deployment works.
Another knows the “right way” to build the plugin.
Another knows the one security exception nobody documented.
That’s power concentration.
But now?
You can externalize that knowledge.
You can write:
skills.mdrules.mdsecurity_controls.mdservice_patterns.md
You can encode organizational constraints:
- “When we build services, use this logging pattern.”
- “When interacting with this database, use this SQL structure.”
- “When handling auth, use this design.”
- “Never deploy without these security controls.”
- “Use these naming conventions.”
You’re not just documenting.
You’re building reusable context.
And when that documentation is structured correctly and fed into AI systems, the next engineer doesn’t start from scratch. They inherit guardrails.
The same speed and discipline you gain…
Everyone gains.
The Security Angle: Thinking Beyond the MVP
From a security engineering perspective, this is where it gets interesting.
When we build an MVP or ship a new feature, the real question shouldn’t just be:
“Does this work?”
It should be:
“How do we make sure the next team building something similar inherits the right controls by default?”
Every service we deploy teaches us something:
- Which IAM patterns worked
- Which logging controls were essential
- Which security assets mattered most
- Which failure modes were painful
- Which compliance checks slowed us down
The future of security engineering isn’t just reviewing deployments.
It’s capturing lessons learned in a way that future builders can automatically inherit them.
That means:
- Encoding security controls as patterns
- Documenting service-level security expectations
- Structuring knowledge so AI can retrieve it
- Reducing legacy friction when someone asks, “How do we build this safely?”
If done well, the next person building a similar service shouldn’t have to rediscover:
- What controls apply
- What assets are sensitive
- What logging is required
- What “good” looks like
They should be able to inherit it.
So What About MVPs?
The idea that “AI builds the MVP, engineers build the real thing” assumes:
- AI output is inherently shallow
- Organizational nuance can’t be encoded
- AI cannot operate within constraints
I’m not convinced that’s true anymore.
If your prompts include:
- Your organization’s design principles
- Your security posture
- Your architectural standards
- Your deployment patterns
- Your documented lessons learned
You’re not building a toy MVP.
You’re building something very close to your desired end state.
Not perfect.
But far closer than people are willing to admit.
The New Engineer
I don’t think engineers are becoming obsolete.
I think we’re evolving into:
- Organizational translators
- Constraint definers
- Context builders
- Systems validators
- Pattern curators
The value is shifting from:
“I know how to build this.”
to
“I know how we build this.”
And once that knowledge is encoded, versioned, refined, and made queryable — the organization compounds.
Final Thought
I still believe study matters.
Deep understanding matters.
Security knowledge matters.
But I strongly disagree that AI is only good for MVPs now.
If done correctly — with context, guardrails, structured documentation, and encoded institutional knowledge — AI can help you build faster and get surprisingly close to a production-ready system aligned with your organization’s constraints.
And that changes the game.
Just one thought from a jog on February 19th, 2026.