Your 20 years of experience just became more valuable, not less.

Everyone's worried AI will replace senior engineers. I get it. But here's what I'm actually seeing:

The market is rewarding depth + judgment, not just speed.

Junior devs can prompt Claude. Senior engineers know when Claude is wrong.

That's the difference. And it's massive.

Here's what's changed:
• You can't compete on "I write code fast" anymore. AI does that.
• You win on "I know what code should do" and "I catch what AI misses."
• Experience matters more than ever because you've seen what breaks at scale.

The engineers thriving right now aren't the youngest. They're the ones with judgment.

They understand systems. They've debugged production disasters. They know why architectural decisions matter. They catch edge cases AI misses.

If you've got 10+ years in, you're not behind. You're ahead. You just need to shift from "I write code" to "I direct AI and validate it."

That's a skill you already have. You've been reviewing junior devs' code for years. Now you're reviewing AI's code.

Same skill. Different tool.

What's your biggest advantage as a senior engineer in the AI era?

My thoughts on AI-assisted programming.

Not the idealized version. The actual one.

I lead a distributed engineering team at Kaz Software. We ship across multiple projects simultaneously, which means PR queues pile up fast. Two years ago, every review was entirely human. Today, roughly 60% of the first-pass review work is handled by AI before a human engineer ever opens the diff.

This is not a post about what AI could do for your review workflow. This is a walkthrough of what I actually do, the tools I rely on, and where I still refuse to let AI make the call.

Three tools do almost all the work:

GitHub Copilot handles in-editor, inline review and the PR summary layer directly inside GitHub.

Claude Code handles deep architectural review, spec alignment checks, and the pre-commit audit that I run before any significant PR goes up.

Codex CLI handles the command-line tasks: automated diff analysis, generating test scaffolding for uncovered paths, and batch processing when I need to review multiple files with a specific lens.

I spent my first 6 years as an engineer debugging without Claude Code or Codex, reading docs that hadn't been summarised by AI, and struggling through concepts until they stuck.

That struggle built something AI can't replace: judgement.

Now I use AI every day. And it's the best thing that's happened to my productivity. But it only works because the fundamentals came first.

I can review AI-generated code because I understand system design. I can spot bad architecture because I've built and operated real systems. I can tell when the output looks confident but is completely wrong because I've been wrong enough times myself.

Pre-AI fundamentals plus post-AI speed. That's the combo.

AI makes fast engineers faster. But it also makes uninformed engineers more dangerous.

Don't skip the fundamentals to chase the tools. Learn both. But learn them in the right order.

---
♻️ Repost to inspire another engineer to learn the fundamentals
➕ Follow Abdirahman Jama for software engineering tips

I didn’t start because it was trendy. I started because I was tired of the repetitive friction.

I didn’t pick up AI because everyone was talking about it.

I picked it up because I was doing the same kind of work every day.

Writing similar test cases.
Debugging the same API failures.
Reading requirements that looked complete but clearly weren’t.

At some point, it stops being interesting.

AI didn’t change my role. It just removed a lot of the low-value effort that comes with it.

This is how I actually use it now.

I Don’t Start From Zero Anymore

This is the biggest change for me.

Earlier, every feature meant opening a doc and thinking from scratch. What are the scenarios? What can break? What should I validate?

Now I take the requirement and drop it into tools like ChatGPT or Claude and ask for a rough set of:

Functional scenarios

Negative cases

Edge cases

Collectively, we're only really months into AI-assisted software development, and the abyss is already clearly visible.

I'd say I'm (currently) a 'maximalist traditionalist' - I use AI to help me build better, reusable code as well as deeper test suites than I would previously have had the patience to grind out. I'm getting more of a feeling for when it's bullshitting me. I'm also able to debug things more effectively. Overall, I'd say I'm operating about 1.8x than before, with a probable ceiling of 2.0x. That's a combination of a bit faster, a bit more comprehensive, and a bit more effective all at the same time.

But for the kind of high-stakes embedded codebases I work on, I don't want to ship code I don't understand or can't completely explain or justify. In many ways, my ideal scenario would be finding ways to use AI to help me ship less code than before (i.e. that's compact, easy to understand and share, and better all over).

And so I look across to agentic stuff, and the gap between how I work and how that works seems like an abyss. The appearance of working doesn't mean it is actually working; passing tests doesn't mean the code wasn't gamed to pass those tests; black box code is a liability, not an asset; code review is next to impossible at scale; and so forth.

So where do we go forward from here? I'm guessing traditionalist maximalists like me will find ways of using agentic development for specific kinds of task, such as early prototyping, client-facing UIs, CI support tooling, etc. But that doesn't feel like a major step change.

More and more, I'm coming to think that the programming languages we use aren't fit for purpose at the scale and speed we're now able to develop at. Or perhaps we're missing a whole load of AI development patterns? There's certainly a lot to think about.

The more I use AI tools like Claude Code, the clearer it becomes: engineering skills are what make AI output worth shipping.

AI makes writing code faster. But shipping good software still requires the same judgment it always did. Speed without engineering discipline just means shipping bugs faster.

- I have both claude and codex subscriptions
- I built my own wrapper (web and desktop) using claude agent sdk
- I built my own proxy to route requests from Claude agent sdk to other providers like openai, openrouter

That's my flow:
- I start with Opus 4.6 in a new chat, sometimes I use plan mode and sometimes not (it depends on the complexity of task)
- after opus finishes the task, I create multiple sub threads and each one has different persona with different system prompt like code-reviewer, ux-reviewer, quality-reviewer and each one uses different provider like code-reviewer uses gpt 5.4 and quality-reviewer using opus 4.6 and ux-reviewer using gemini 3.1 pro
- then I take all the findings from the 3 sub-threads and give it to the main thread and ask it to confirm each one then fix them and do the same iteration until everything is good
- then I review the final code myself and might fix it myself or give to back to opus to fix
- then I ask opus to use the skill I created (learn) which checks all the findings and issues we fixed through the session and update CLAUDE.md with useful rules

Whether we like it or not, AI is here to stay. Personally, I am tired of hearing about it and how people "vibe coded" something. That being said, that is pretty much what this post is about. Just to clarify, I am using AI to refer to Large Language Models also known as LLMs.

I was asked to have a meeting to talk to other developers about how I use AI tools to write code. I have over time found it to be a major time saver using AI tools by letting it focus on the coding and let me focus on making sure the product is what the users are looking for.

...

I use AI agents in every step of my development workflow.

Here's what that looks like:

When I first started using AI to code, I'd just open a chat and start prompting.

Vibe coding works for small scripts, demos, and bug fixes. But for real software it falls apart fast.

AI agents don't change how good software gets built. They change how fast.

Having said that - process scales with the task. A bug fix probably doesn't need a full spec or complex workflow.

The key is matching the level of process to the complexity of the work.

Here's the 5-step process I follow:

1. Spec (what, why, how)

AI can't replace good thinking. The best engineers think about design before implementation.

Start with a PRD. Define what's being built and why.

Then write a technical spec covering architecture, data models, and constraints.

A PRD is about requirements. A technical spec is about architecture choices.

2. Tasks

Break the spec into small, well-defined tasks you can hand off to agents.

I push tasks into Linear via MCP.

3. Build

Hand off tasks to agents and ensure they have all the context they need.

4. Review

First-pass AI code works but it's usually full of problems.

Always run a dedicated review pass to check quality, reduce complexity,
and make sure the output matches the spec.

Quality = iteration.

Build, review, fix, improve, simplify. Repeat until it's clean.

5. Ship

Tests, linting, CI gates. Automation catches regressions.

I try to avoid:

1/ Delegating design decisions to AI. The agent follows instructions.
You still have to make the right calls.

2/ Skipping the iteration loop. First-pass AI code always has bugs.

What's your workflow for coding with agents?

---

---

Enjoy this? ♻️ Repost it to your network and follow for more.

PS: I genuinely appreciate you taking the time to read this. I make videos to help people build amazing things with AI (no hype) but I'm a tiny account. If you got value from this, subscribing would mean the world: https://lnkd.in/eUZ3Y96V 🙏