Forem: Kudzai Murimi

How I Use AI to Code 10x Faster (With Real Examples)

Kudzai Murimi — Sat, 28 Mar 2026 11:28:25 +0000

I'm not exaggerating when I say AI changed how I write code.

Not because it writes everything for me — but because it eliminates the parts of coding that used to slow me down the most: staring at boilerplate, Googling the same errors, writing repetitive tests, and trying to understand unfamiliar concepts from scratch.

I use four tools daily: GitHub Copilot, ChatGPT, Claude, and Cursor. Each one has a specific role in my workflow. Here's exactly how I use them — with before/after examples.

1. Writing Boilerplate Code — GitHub Copilot

Boilerplate is the biggest time thief in any project. Form requests, controllers, service classes, migrations — it's all necessary but mentally draining to write from scratch.

GitHub Copilot handles this inside my editor before I even finish typing.

Before AI

Writing a Laravel form request used to look like this: open a new file, remember the method names, type out every rule manually, look up validation syntax I half-remember…

// I'd write this entirely by hand — slowly
class StorePaymentRequest extends FormRequest
{
    public function authorize(): bool
    {
        return true;
    }

    public function rules(): array
    {
        return [
            'amount'    => 'required|numeric|min:1',
            'reference' => 'required|string|max:100',
            'gateway'   => 'required|in:ozow,yoco',
        ];
    }
}

After AI (Copilot)

Now I just type the class name and a comment describing what I want:

// Form request for processing a payment — amount, reference, gateway
class StorePaymentRequest extends FormRequest
{
    // Copilot fills in the rest instantly ✅

Copilot suggests the full class — rules, messages, even custom error messages — based on context from the rest of my project. I review, adjust, and move on in seconds.

2. Debugging Errors — ChatGPT

When I hit an error I don't immediately understand, ChatGPT is the first place I go. Not Stack Overflow. Not Google.

I paste the error + the relevant code and ask: "What's causing this and how do I fix it?"

Before AI

SQLSTATE[42S22]: Column not found: 1054 Unknown column
'payments.user_id' in 'where clause'

I'd spend 10–20 minutes checking migrations, re-reading docs, and Googling the exact error hoping someone had the same setup.

After AI (ChatGPT)

I paste the error with my model and migration, and get a precise explanation back:

"Your payments table migration doesn't include a user_id column, but your Eloquent model has a belongsTo(User::class) relationship that's trying to query it. Add the column to your migration or check that you're running the latest migration."

// Fix: add this to your payments migration
$table->foreignId('user_id')->constrained()->cascadeOnDelete();

What used to take 20 minutes now takes 2. The difference isn't just speed — it's that I understand why something broke, not just how to patch it.

3. Writing Tests — Claude

Writing tests is something most developers know they should do more of — and don't, because it's time-consuming and repetitive.

I use Claude specifically for test generation because it's excellent at understanding context across a whole file and writing thorough, meaningful tests.

Before AI

Writing a test for a payment controller meant manually thinking through every scenario:

// I'd write one test, maybe two, and move on
public function test_payment_is_processed_successfully()
{
    $response = $this->post('/pay', ['amount' => 100, 'gateway' => 'yoco']);
    $response->assertRedirect('/success');
}

After AI (Claude)

I paste my controller and ask: "Write PHPUnit tests for this controller covering success, failure, validation errors, and invalid gateway."

// Claude generates full coverage automatically

public function test_payment_succeeds_with_valid_data()
{
    $response = $this->post('/pay', [
        'amount'    => 500,
        'reference' => 'INV-001',
        'gateway'   => 'yoco',
    ]);

    $response->assertRedirect(route('payment.success'));
    $this->assertDatabaseHas('payments', ['reference' => 'INV-001', 'status' => 'paid']);
}

public function test_payment_fails_validation_without_amount()
{
    $response = $this->post('/pay', ['gateway' => 'yoco']);
    $response->assertSessionHasErrors(['amount']);
}

public function test_payment_rejects_invalid_gateway()
{
    $response = $this->post('/pay', ['amount' => 100, 'gateway' => 'stripe']);
    $response->assertSessionHasErrors(['gateway']);
}

public function test_payment_handles_gateway_failure_gracefully()
{
    Http::fake([
        'online.yoco.com/*' => Http::response(['error' => 'Declined'], 400),
    ]);

    $response = $this->post('/pay', [
        'amount'    => 100,
        'reference' => 'INV-002',
        'gateway'   => 'yoco',
    ]);

    $response->assertRedirect(route('payment.error'));
}

Four solid tests in under a minute. Before AI, I might have written one and told myself I'd come back to it.

4. Understanding New Concepts — Cursor + ChatGPT

Instead of reading through entire documentation pages, I use Cursor (which has AI built directly into the editor) to explain code inline, and ChatGPT to teach me concepts with examples tailored to my stack.

After AI (ChatGPT)

I asked: "Explain Laravel Pipeline to me like I'm a developer who knows Laravel but has never used Pipeline. Show me a real example using payment processing."

// ChatGPT explained it with an example I could use directly

$result = app(Pipeline::class)
    ->send($paymentData)
    ->through([
        ValidatePaymentData::class,
        CheckForDuplicateTransaction::class,
        ChargeGateway::class,
        SendConfirmationEmail::class,
    ])
    ->thenReturn();

Understanding that took me 5 minutes instead of 45.

Cursor — Inline Code Explanation

When I open an unfamiliar file, I highlight confusing code in Cursor and ask it to explain inline:

// I highlighted this line and asked Cursor: "what does this do?"
$order->loadMissing(['payments' => fn($q) => $q->where('status', 'paid')]);

// Cursor explained:
// "loadMissing() lazy-loads the 'payments' relationship only if it hasn't
//  been loaded already. The closure filters it to only load paid payments,
//  preventing unnecessary queries if the relation is already in memory."

No context switching. No browser tabs. The explanation comes to where I'm working.

How These Tools Fit Together

Task	Tool	Role
Boilerplate	GitHub Copilot	Generating code & scaffolding
Debugging	ChatGPT	Quick fixes & error explanations
Testing	Claude	Deep logic & edge case coverage
Inline Help	Cursor	Understanding existing code
Learning	ChatGPT	Learning new concepts deeply

⚠️ The One Thing to Remember

AI makes you faster, not infallible.

I've had Copilot suggest code that looked right but had a subtle security flaw. I've had ChatGPT confidently give me outdated API syntax. Always review what AI generates — especially anything touching security, payments, or data.

Use it as a fast, knowledgeable pair programmer — not as the final word.

Final Thoughts

If you're not using AI in your development workflow yet, you're spending time you don't need to spend.

The developers who will stand out in the next few years aren't the ones who avoid AI. They're the ones who know how to use it well.

💬 Working on an app and need help?

I specialize in Laravel applications, API integrations, and payment gateway setups (Ozow, Yoco, and more).

hgtvrfc

Kudzai Murimi — Fri, 27 Mar 2026 21:47:48 +0000

vgrfcd

Your AI Agent Demo Was Impressive. Your Production Deploy Was a Disaster. Here's Why.

Kudzai Murimi — Fri, 27 Mar 2026 13:40:46 +0000

The demo took me four hours to build and six minutes to present.

The room loved it. My agent could browse the web, summarize documents, write follow-up emails, and update a Notion database, all from a single natural language prompt. Someone said it looked like "the future." A few people asked if it was for sale.

Three weeks later, I tried to deploy a production version of it for a small internal team.

It lasted two days before I quietly killed it.

What Happened

On day one, it summarized the wrong document because the filename had an emoji in it.

On day two, it sent a half-finished email because the LLM hit a rate limit mid-task, the retry logic didn't pick up where it left off, and nobody had built a way to detect incomplete success.

By day three, a team member asked it to "clean up the project folder." It deleted 11 files it had "decided" were duplicates. They were not duplicates. There was no undo.

The demo had none of these problems because I was watching it the entire time. I was the error handler. I was the safety check. I was the undo button.

In production, I wasn't there. And the agent had no idea how to handle a world that doesn't behave like a demo.

Why AI Agent Demos Always Lie To You

Here's the uncomfortable truth: demos are optimized for the happy path.

You pick a clean input. You run it three times before presenting until you get the best output. You quietly skip the edge case that produces garbage. You're present to nudge it when it stalls.

Production is only edge cases. Real users have typos, weird file names, ambiguous instructions, slow internet connections, and zero patience for "the AI got confused."

The gap between demo and production isn't a bug in your agent. It's a gap in the assumptions baked into how most of us build agents in the first place.

The 5 Things That Break Every Agent in Production

1. No concept of partial failure

LLM pipelines fail in partial, silent ways. Your API call times out after step 3 of 7. Does your agent know it didn't finish? Does it retry from step 3, or start over, or just... stop? Most demo agents have no answer to this. Build checkpointing from day one.

2. Tool trust without tool validation

Agents use tools, file systems, APIs, databases. In demos, those tools behave perfectly. In production, APIs return unexpected schemas, files don't exist where they should, and databases time out. If your agent doesn't validate tool outputs before acting on them, you will have a bad time.

3. Ambiguity without escalation

LLMs are great at filling in gaps with confident-sounding guesses. That's the magic of demos. In production, a confident wrong guess can delete files, send emails to the wrong person, or overwrite real data. Your agent needs a way to say "I'm not sure, should I proceed?" instead of always charging forward.

4. No observability

You can't debug what you can't see. Most agents are black boxes — you know the input, you know the output, and you have no idea what happened in between. Add structured logging at every tool call and every LLM inference. When it breaks (and it will), you'll want a paper trail.

5. Memory that doesn't exist

The demo runs in one shot. Production agents often work across sessions, users, or long time horizons. If your agent has no persistent memory, it will re-discover the same information, repeat the same mistakes, and feel frustratingly stateless to anyone using it more than once.

What Actually Works in Production

After rebuilding (and breaking, and rebuilding) a few agents, here's the architecture shift that made the biggest difference:

Stop thinking "autopilot." Start thinking "co-pilot."

The agents that survive production aren't the ones that do everything autonomously, they're the ones that do the tedious parts autonomously and hand off to a human at every decision point that matters.

My most reliable agent today does exactly one thing: it reads my inbox, categorizes emails, drafts replies, and puts them in a queue. It sends nothing without me clicking approve. That feels less impressive than the demo version. But it's been running for four months without incident.

The most dangerous word in AI agent design is "automatically."

The Industry Is Just Starting to Figure This Out

You're not alone in this. Surveys consistently show that the vast majority of companies experimenting with AI agents haven't shipped them to production yet, not because the technology isn't there, but because production-readiness is a completely different engineering problem than demo-worthiness.

The companies that will win with agentic AI aren't the ones who built the flashiest demos in 2024. They're the ones who quietly invested in error handling, observability, and human-in-the-loop design through 2025 and into 2026.

That's unsexy work. It doesn't make for a great conference talk. But it's the only version that actually ships.

Before You Build Your Next Agent, Ask Yourself:

What happens when a tool call fails halfway through?
How does my agent signal uncertainty instead of guessing?
Can I replay a failed run from the point of failure?
Would I trust this agent to act without me watching?
If the answer to that last one is "only in a demo", what would have to change?

I'm still building agents. I'm just a lot more boring about it now.

Have you shipped an AI agent to production? What broke first? I'd love to hear the horror stories, drop them in the comments.

I Stopped Chasing Shiny Dev Tools — Here's What Actually Stuck in 2026

Kudzai Murimi — Wed, 25 Mar 2026 19:50:59 +0000

There's a specific kind of developer shame nobody talks about.

It happens at 11pm. You're supposed to be finishing a feature. Instead, you're reading a Hacker News thread titled "Is Bun finally ready to replace Node?" and you have 14 tabs open — Bun's docs, a Reddit post comparing Deno vs Bun, a YouTube video you paused at 3 minutes, and a GitHub repo you starred but will never open again.

Sound familiar?
That was me. Every. Single. Month.

I spent the better part of three years in what I now call the shiny tool loop, a cycle of discovery, excitement, shallow learning, abandonment, and guilt. New framework drops? I'm on it. New AI coding assistant? Installed by lunch. New build tool that promises to be "10x faster"? Benchmarks read. Migration started. Migration abandoned.
My GitHub graveyard is full of half-migrated "test projects" with commit messages like chasing bun again and trying out astro (again).

Then, in late 2025, I burned out. Not dramatically, just quietly. I sat down to work one morning and couldn't remember why I'd started programming in the first place.
So I stopped. And I made a rule.

The Rule: Nothing New for 90 Days
No new frameworks. No new tools. No new AI assistants (yes, I had four installed at once). I would finish things with what I had.
It was uncomfortable for about two weeks. Then it got very, very quiet.
And in that quiet, I actually shipped things.

What I Kept (And Why)
Here's my stack going into 2026, chosen not because it's trendy, but because I can build almost anything with it without Googling the basics:

1. VS Code — still my main editor
I tried Cursor. I tried Zed. I tried going full Neovim for three weeks (don't). VS Code with a handful of extensions just works, has a massive plugin ecosystem, and I can pair it with any AI assistant I want. Stability > novelty.

2. Next.js — for anything that ships to users

Yes, the App Router has rough edges. Yes, I understand the React Server Components discourse. But Next.js has a gigantic community, excellent docs, and Vercel's deployment story is nearly effortless. When I'm building a product, I want to think about the product.

3. Claude / GitHub Copilot — as assistants, not crutches
This was the big mindset shift. I stopped using AI to write my code and started using it to review my code. I'll draft a function, then ask: "What edge cases am I missing?" or "How would you refactor this?" The quality of my output went up; the time I spent debugging AI-generated bugs went down.

4. Supabase — for anything that needs a backend fast
Postgres with a nice dashboard, auth built-in, and real-time out of the box. Not glamorous. Incredibly useful.

5. Plain CSS + Tailwind — I stopped framework-hopping here too
I used to switch between styled-components, CSS modules, Vanilla Extract, and Tailwind every few months. I picked Tailwind, learned it properly, and now I write UI fast. That's the whole story.

What I Actually Learned
The tools were never the problem. The problem was that learning a new tool feels like progress. It triggers the same reward center as actually shipping something, but without the hard parts. It's the intellectual equivalent of rearranging your desk instead of doing your work.
The developers I most admire aren't the ones using the newest stack. They're the ones who are dangerous with boring tools, who can build something meaningful with Next.js + Postgres + a bit of CSS faster than I could set up my seventh new monorepo boilerplate.
Mastery requires repetition. And repetition requires staying.

A Challenge for You
If you recognize yourself in that 11pm Hacker News tab spiral, try this: write down every tool you've "tried" in the last six months. Be honest. Now circle the ones you actually shipped something with.
That gap? That's the shiny tool tax.
Pick your core stack. Use it until it's boring. Then it gets interesting.

What's in your "I'm actually shipping with this" stack? Drop it in the comments, I'm genuinely curious whether the community is converging or fragmenting in 2026.

If this resonated, I write about developer productivity and building in public. Follow along, no newsletters, just posts when I have something real to say.

I Just Earned the GitHub Copilot CLI Challenge Badge — And It Means More Than I Expected 🏅

Kudzai Murimi — Wed, 11 Mar 2026 11:09:42 +0000

I didn't expect to feel this way about a digital badge.

But when I saw the notification — "Congratulations, Kudzai Murimi! You received the **GitHub Copilot CLI Challenge Completion* badge!"* — I genuinely paused for a moment. Not because of the badge itself, but because of what it represented: proof that I had intentionally levelled up how I work in the terminal, with AI as a true co-pilot.

What the Challenge Was About

The GitHub Copilot CLI Challenge pushed developers to explore and demonstrate how GitHub Copilot can be used directly inside the terminal, not just inside a code editor. We're talking about using gh copilot suggest and gh copilot explain to power up everyday shell workflows: writing commands, understanding cryptic outputs, fixing errors on the fly, and more.

It sounds small. But once you try it, you realise how much mental overhead you've been carrying every time you've had to tab away to Google or Stack Overflow just to remember a git rebase flag or an awk one-liner.

Why This Badge Matters to Me

I've been on a deliberate journey to make my development environment smarter — not just faster, but genuinely intelligent. This challenge was the perfect intersection of that goal and something I had already been thinking deeply about: AI-powered terminal workflows.

In fact, just before taking on this challenge, I published an article exploring exactly that idea:

👉 I Taught My Terminal to Predict the Weather — AI-Powered Development Environment Optimization

That piece was my way of showing how AI tools can do more than autocomplete code — they can reshape how your entire local environment thinks and responds. The Copilot CLI challenge brought that philosophy into a structured, community-wide conversation, and earning this badge feels like a stamp of validation on that path.

What I Took Away From This

Here are a few honest reflections after completing the challenge:

1. The terminal is underrated as an AI interface.

Most AI tooling lives in GUIs. But the CLI is where developers actually live. Bringing Copilot there removes friction from the most critical part of your workflow.

2. It changes how you learn commands.

Instead of memorising syntax, you describe intent. gh copilot suggest "compress this folder and exclude node_modules" — and you get a working command, explained. That's not cheating. That's how experienced developers have always worked: knowing what to do, and looking up how.

3. Community challenges are underestimated.

Participating in a structured challenge — even one you could technically "do on your own" — adds accountability, momentum, and the thrill of knowing thousands of others are learning alongside you. That energy is real.

Your Turn 🚀

If you haven't explored DEV Community challenges yet, you're missing out on some of the best structured learning opportunities in the developer ecosystem.

Check out what's currently running — and what's coming up — right here:

👉 dev.to/challenges

Whether it's an AI challenge, a writing sprint, or a build competition, there's always something to sharpen your skills and earn recognition for it.

Stay in the Loop 🔔

Want to stay updated on new challenges, community highlights, and what's happening across DEV? Give @jess a follow — she's one of the best people to keep up with for all things DEV Community.

To every developer who completed the GitHub Copilot CLI Challenge: well done. You didn't just earn a badge — you made a deliberate choice to evolve how you work. And in this industry, that habit matters more than any single tool.

Now go check those challenges. Something good is waiting for you. 💪

Your Unfinished GitHub Projects Are More Valuable Than You Think

Kudzai Murimi — Thu, 26 Feb 2026 14:29:29 +0000

And why that half-built todo app might land you your next job

Hey dev community 👋

Let me ask you something uncomfortable.

How many repos are sitting in your GitHub right now, dusty, half-finished, last committed to "6 months ago", that you're secretly ashamed of?

A weather app that never got a UI. A CLI tool you built for a weekend, then forgot. A Discord bot that almost worked. A SaaS idea that made it to the landing page and then... nothing.

Yeah. Me too. We all have them.

But here's the thing nobody talks about: those unfinished projects are not failures. They might actually be your most powerful asset.

Let me explain.

The "Graveyard" Problem

Most developers have what I call a GitHub Graveyard, a collection of repos that were born with ambition and died with a half-written README.

The reasons are always the same:

Life got busy
The problem turned out to be harder than expected
A shinier idea came along
You learned what you needed and moved on
The scope kept expanding and you never shipped

Sound familiar? Of course it does. Because this is just how developers learn.

The mistake is treating these repos as embarrassments to hide rather than evidence to showcase.

Why Recruiters and Hiring Managers Actually Care

Here's a secret from the other side of the hiring table: a thoughtful, incomplete project tells a better story than no project at all.

When a recruiter or senior engineer looks at your GitHub, they're not checking if everything is polished and production-ready. They're asking:

"Does this person write real code when nobody's watching?"

An unfinished project that shows:

Real problem-solving thinking
Clean commit history with meaningful messages
A proper README explaining the why, not just the what
Honest documentation of where it stands and what's next

...is worth 10x more than a repo with one commit that says "initial commit" on a todo app copied from a tutorial.

What hiring managers actually look for:

Signal	What it says about you
Consistent commits over time	You're a builder, not just a learner
Multiple tech stacks explored	Curiosity and adaptability
README with context	Communication skills
Issues / project boards	Engineering maturity
Branches and PRs (even solo)	You understand workflows

An abandoned project with 47 commits, a proper README, and an open TODO.md screams "this person builds things."

The Personal Project Angle: Ship the Damn Thing

Now, let's flip this around.

Some of your unfinished projects deserve to be finished. Not because someone is watching, but because the problem you were solving was real.

Ask yourself this about each repo in your graveyard:

Did I build this because I actually needed it? → High potential.
Would I use it if it worked? → Ship it.
Did other people ask for it? → Definitely ship it.
Did I learn something that could help others? → Write it up and open-source it.

The bar for "launching" a personal project is lower than you think. You don't need:

❌ A perfect UI
❌ Full test coverage
❌ A marketing strategy
❌ A monetization plan

You just need:

✅ It solves a real problem
✅ A clear README
✅ A way for someone to run it or use it
✅ A v0.1 tag pushed to GitHub

Done beats perfect. Every time.

Real Talk: How to Revive a Dead Project (Without Losing Your Mind)

Before you doom-scroll through your repos feeling overwhelmed, here's a practical system:

Step 1: The Audit (30 minutes)

Go through every repo. For each one, ask: "Is the core idea still interesting?" If yes, add it to a shortlist.

Step 2: The One-Line README Fix

For every shortlisted repo, write one sentence that explains what it does and why you built it. Add that to the README today. Just that. Nothing else.

Step 3: Pick ONE to Finish

Not five. Not two. One. The one that's closest to done, or the one you'd actually use.

Step 4: Define "Done" (for real this time)

Write down the three features that would make this thing usable. Not impressive. Not scalable. Just usable. That's your v1.

Step 5: 20 Minutes a Day

Set a recurring calendar block. 20 minutes. No context switching. Just that project. You'll be amazed what happens in two weeks.

The Community Power Move

Here's something almost nobody does: talk about your unfinished projects publicly.

Write a dev.to post that says "I'm building X, here's where I am". Post a thread on Twitter/X. Share in a Discord. Even just update your README with a "current status" badge.

Why? Because:

Someone might offer to contribute
Someone might tell you they have the same problem
Accountability makes you actually ship
The process story is often more interesting than the final product

The dev community loves a builder who shares their journey, not just their wins.

The Mindset Shift

Stop thinking of your GitHub as a portfolio of finished products.

Start thinking of it as a log of your thinking and growth.

Every repo, finished or not, represents a problem you cared about, a skill you were developing, a curiosity you followed. That's the resume. That's the story. That's what makes you interesting to work with.

The developer with 50 half-finished repos who's constantly building and shipping things in public will always outcompete the developer who's waiting until their code is "ready" to show anyone.

Now I Want to Hear From You

I'm genuinely curious about the dev community here on dev.to:

What's sitting in YOUR GitHub graveyard that deserves to be finished?

Drop a comment with:

The repo (or just describe it)
What it does / was supposed to do
Why you stopped
Whether you think it's worth reviving

I'll personally check out every project linked in the comments and leave feedback. Let's turn some of these graveyards into launch pads.

And if this post helped you look at your old repos differently, give it a , share it with a dev friend who needs to hear it, and let's build more stuff in public.

You Don't Need to Be an AI Expert BUT You Need to Be AI-Aware

Kudzai Murimi — Fri, 13 Feb 2026 15:12:58 +0000

The panic spreading through developer communities is creating more problems than it solves

A recent industry survey revealed that 73% of developers now use AI tools daily. On the surface, this seems like a success story—a testament to rapid adoption and innovation. But beneath these numbers, a dangerous trend is emerging that threatens to derail countless careers.

Developers are panicking.

The Fear That's Holding Developers Back

Last month, a senior developer with eight years of solid experience sat across from me during a mentoring session. His voice cracked slightly as he confessed: "I feel worthless because I haven't built an AI chatbot yet."

Here was a professional who had shipped production code serving millions of users, who had mentored junior developers, who had architected complex systems—convinced his career was over because he hadn't jumped on the AI bandwagon fast enough.

He's not alone. After mentoring over 200 developers through career transitions, I've watched this fear create more problems than solutions. Talented professionals are abandoning their strengths, frantically trying to reinvent themselves overnight, convinced that unless they become AI experts immediately, they'll be obsolete by next quarter.

This mindset is completely backwards.

The Critical Distinction: AI Expert vs. AI-Aware

You don't need to become an AI expert overnight. You need to become AI-aware. And there's a massive difference between the two.

An AI expert:

Builds neural networks from scratch
Understands backpropagation algorithms
Can explain transformer architectures in detail
Spends years studying machine learning theory
Publishes research papers

An AI-aware developer:

Knows when and how to leverage AI tools
Understands which problems AI solves well (and critically, which it doesn't)
Can integrate AI tools into existing workflows seamlessly
Recognizes when human judgment beats algorithmic decisions
Validates AI-generated code effectively

The developers who are thriving right now? They're not the ones frantically watching TensorFlow tutorials at 2 AM. They're the ones who've taken a strategic approach to understanding AI's role in their work.

The Six-Month Trap

I've watched talented developers waste six months trying to become "AI experts" when they could have spent six weeks becoming AI-literate and started adding value immediately.

They fall into what I call the "deep learning rabbit hole"—convincing themselves they need to understand every mathematical formula behind neural networks before they can use GitHub Copilot effectively. It's like refusing to drive a car until you can rebuild an engine from scratch.

The real skill isn't building AI. It's knowing how to work alongside it.

Your Domain Expertise Doesn't Disappear—It Compounds

Here's what many developers miss in their panic: Your years of experience don't evaporate because ChatGPT exists. They don't become worthless because AI can generate boilerplate code.

In fact, they become MORE valuable.

The unstoppable combination isn't:
AI replacing developers

It's:
Domain expertise + AI tools = Amplified impact

Your years of debugging production issues? That experience helps you spot the subtle bugs in AI-generated code that less experienced developers miss.

Your system design knowledge? That guides you in architecting solutions where AI tools enhance rather than complicate your systems.

Your problem-solving skills? Those help you frame problems in ways that AI tools can actually assist with effectively.

What AI-Aware Actually Looks Like in Practice

Being AI-aware means developing a new set of meta-skills:

1. Pattern Recognition for AI Suitability
Knowing which tasks are AI-appropriate versus which require human expertise. Code generation for CRUD operations? Great use case. Debugging a complex race condition in a distributed system? You'll still need human insight.

2. Effective Prompting
Learning to communicate with AI tools effectively—not as magic boxes, but as tools that require clear input to produce useful output.

3. Critical Validation
Developing the discipline to review and test AI-generated code rigorously. AI can be confidently wrong, and catching those errors requires expertise.

4. Workflow Integration
Understanding where AI tools fit in your development process without disrupting the practices that already work.

5. Continuous Calibration
Keeping a pulse on AI capabilities as they evolve, without getting distracted by every new tool that launches.

The Questions That Actually Matter

Instead of asking "How do I become an AI expert?", ask:

Which parts of my workflow could AI tools accelerate?
Where does my human judgment add the most value?
How can I validate AI outputs effectively in my domain?
What problems am I solving that AI genuinely can't?

These questions lead to productive learning, not panic-driven credential collecting.

Moving Forward Without Panic

If you're feeling the pressure to master AI immediately, take a breath. You have permission to approach this strategically rather than frantically.

Start small:

Pick one AI tool relevant to your daily work
Use it for one specific task for two weeks
Evaluate what worked and what didn't
Adjust and expand gradually

Your career won't end because you didn't learn PyTorch last month. But it might stagnate if fear drives you to abandon the expertise you've spent years building.

The future belongs to developers who can blend human insight with AI capabilities—not to those who panic-learned the latest framework because a LinkedIn post made them feel inadequate.

The Real Conversation We Need to Have

Rather than letting fear dominate the narrative around AI and development, we need honest conversations about:

What's genuinely changing versus what's hype
Which skills remain irreplaceable
How to evaluate AI tools critically
Where the real opportunities lie
What we should be concerned about (and what we shouldn't)

The 73% of developers using AI tools daily didn't all become AI experts. They became AI-aware. They learned to work with these tools pragmatically, without abandoning the expertise that made them valuable in the first place.

That's the path forward. Not panic. Not overnight transformation. Strategic awareness combined with the strengths you already have.

What's your biggest concern about AI in development right now? Where do you see the real opportunities versus the overblown hype? Let's have an honest conversation about navigating this shift without the panic.

Top 5 Developer Skills That Will Print Money in 2026 (And the Ones Bleeding Your Career Dry)

Kudzai Murimi — Fri, 13 Feb 2026 14:25:03 +0000

The gap between what boot camps teach and what CTOs actually hire for has never been wider. While junior devs grind LeetCode and memorize framework syntax, the market has fundamentally shifted. Here's what separates the $200K developers from the ones still fighting for $80K contracts.

The 5 Skills That Actually Matter

1. AI Integration Architecture (Not Just "Using ChatGPT")

Every company is now an AI company, whether they admit it or not. But here's what matters: you need to architect systems that incorporate LLMs, not just use them as glorified autocomplete.

What this actually means:

Designing prompt chains and workflows that are deterministic and testable
Building RAG (Retrieval-Augmented Generation) systems that don't hallucinate
Understanding token economics and latency implications
Managing context windows and implementing semantic caching
Building guardrails and validation layers

Why it prints money: Every SaaS product, every enterprise tool, every consumer app is rushing to add AI features. The developers who can actually ship reliable AI features (not just demos) are commanding 40-60% premiums.

The trap to avoid: Don't just become a "prompt engineer." That's the modern equivalent of being "good at Google searches." Build actual systems.

2. Platform Engineering (DevOps Grew Up)

If you're still calling yourself a "DevOps engineer," you're already behind. The role evolved. Platform engineering is about building internal developer platforms that make your entire eng org 10x more productive.

What this actually means:

Creating self-service infrastructure with Terraform/Pulumi
Building internal developer portals (Backstage, Port)
Implementing GitOps workflows that actually work
Setting up observability that doesn't require a PhD to read
Managing Kubernetes clusters that don't wake you up at 3 AM

Why it matters: Companies are desperate to reduce cognitive load on developers. A single platform engineer can unlock velocity for 50+ developers. The ROI is obvious, which is why these roles pay $180K-$250K.

Real talk: If your current company doesn't have a platform team, that's your opportunity. Build it and you'll either get promoted or have a killer portfolio.

3. System Design (Not Algorithms, Not Syntax)

Here's the uncomfortable truth: nobody cares if you can invert a binary tree in O(log n) time. They care if you can design a system that handles 10,000 requests per second without falling over.

What this actually means:

Understanding distributed systems patterns (event sourcing, CQRS, saga patterns)
Knowing when to use queues vs. streams vs. CDC
Designing for failure (circuit breakers, retries, idempotency)
Database architecture decisions (SQL vs. NoSQL vs. NewSQL)
Caching strategies that actually work

Why senior engineers make $300K: They don't write more code. They make architectural decisions that save millions in infrastructure costs or prevent catastrophic outages.

The shortcut: Read "Designing Data-Intensive Applications" by Martin Kleppmann. Then build something that breaks under load and fix it. Real experience trumps theory.

4. Security Engineering (Zero Trust is Now Table Stakes)

Every startup pitch deck now includes "enterprise-ready security." Every compliance checkbox (SOC 2, GDPR, HIPAA) requires developers who actually understand security beyond "sanitize your inputs."

What this actually means:

Implementing OAuth 2.0/OIDC correctly (shocking how few do)
Understanding certificate management and mTLS
Building zero-trust architectures with identity-based access
Knowing the OWASP Top 10 beyond just XSS
Implementing proper secrets management (Vault, AWS Secrets Manager)

Why this matters: Security breaches cost companies millions. Security-conscious developers become unfireable. Plus, "security engineer" roles start at $150K because there aren't enough of them.

Quick win: Get certified (CISSP, Security+, CEH) and immediately stand out from 90% of developers.

5. Technical Communication (The Skill Nobody Teaches)

The most underrated skill that separates IC4 from IC6 isn't technical at all. It's the ability to explain complex technical decisions to non-technical stakeholders and write documentation that doesn't suck.

What this actually means:

Writing RFCs and design docs that get approved
Creating ADRs (Architecture Decision Records) that explain the "why"
Presenting to executives without making their eyes glaze over
Mentoring junior developers through code reviews that actually teach
Writing documentation that onboards new hires in days, not weeks

Why this is a multiplier: Staff+ engineers spend 60% of their time communicating. If you can't influence decisions through writing and speaking, you'll cap at senior engineer forever.

The hack: Start a technical blog. Write one article per month. You'll simultaneously improve your communication skills, build your personal brand, and have a portfolio that proves your expertise.

The Skills That Are Dying (Stop Wasting Time)

1. Memorizing Framework-Specific Syntax

jQuery is dead. Angular is legacy. Even React patterns from 2020 look ancient. Frameworks churn faster than you can learn them.

What to do instead: Learn the underlying patterns. Understanding closures, promises, and reactive programming transfers across frameworks. Syntax doesn't.

2. Pure Algorithm Grinding

Yes, you'll still face LeetCode in FAANG interviews. But outside of that bubble, companies care about shipping products, not inverting trees.

What to do instead: Learn algorithms in context. When you need to optimize a slow query, then learn indexing strategies. When you're building a recommendation engine, then learn collaborative filtering.

3. Manual Testing and QA

If you're manually clicking through your app to test it in 2026, you're doing it wrong. AI-powered testing tools are eating this space.

What to do instead: Learn test automation, property-based testing, and chaos engineering. These skills actually scale.

4. Being a "X Language Expert"

Nobody cares if you're a "Python expert" or "Java guru" anymore. Languages are tools. Companies hire problem solvers, not syntax memorizers.

What to do instead: Become polyglot. Learn one language from each paradigm (OOP, functional, systems). You'll adapt to any codebase.

5. Working in Isolation

The "10x engineer who works alone" is a myth from 2010. Modern software is too complex for solo heroes.

What to do instead: Learn to work asynchronously with remote teams, contribute to open source, and build your network. Your next job will come from connections, not cold applications.

The Playbook: How to Actually Level Up

For Junior Devs (0-2 years):

Pick one modern framework and build something real with it
Deploy it to production (Vercel, Railway, Render)
Add authentication, error handling, and logging
Break it, monitor it, fix it
Write about what you learned

For Mid-Level Devs (3-5 years):

Identify the biggest pain point in your current system
Propose a solution with a proper RFC/design doc
Get buy-in from stakeholders
Implement it and measure the impact
Give a tech talk about it internally

For Senior Devs (5+ years):

Find a cross-team problem nobody's solving
Build a coalition to support your solution
Drive the technical decision while mentoring others
Measure and communicate the business impact
Share your learnings externally (blog, conference talk)

The Uncomfortable Truth

The skills that matter in 2026 aren't necessarily the skills you want to learn. They're not as sexy as learning the latest JavaScript framework or as satisfying as solving algorithm puzzles.

But here's the reality: the market doesn't care what you want to learn. It cares what problems you can solve.

The developers making $200K+ aren't necessarily the best coders. They're the ones who can:

Ship AI features that users actually want
Design systems that scale without constant firefighting
Build platforms that make entire teams more productive
Prevent security breaches before they happen
Communicate technical decisions that influence millions in revenue

The choice is yours: keep collecting framework badges and algorithm medals, or start building skills that actually move the needle.

The gap between "good developer" and "highly paid developer" isn't as wide as you think. It's just different skills than what everyone else is learning.

And that's precisely why it's valuable.

Are We Actually Building Faster Websites, or Just Using Fancier Tools?

Kudzai Murimi — Thu, 12 Feb 2026 14:23:37 +0000

Let's talk about something that's been bugging me lately.

Every few months, there's a new framework promising to make our websites faster. React Server Components. Astro. Svelte 5 with its new runes. Fresh. Qwik. The list keeps growing.

And here's my question: Are our websites actually getting faster, or are we just moving complexity around?

The Promise vs. The Reality

These frameworks all sound amazing on paper:

"Zero JavaScript by default!"
"Instant page loads!"
"Better developer experience!"

But then I look at real websites in the wild, and I still see:

Loading spinners everywhere
Slow interactions
Massive JavaScript bundles
Sites that feel sluggish on mobile

What's Actually Changed?

React Server Components - Mixing server and client code sounds great. But how many teams actually need this? Are we solving real problems or just adding complexity?

Astro - The islands architecture makes sense. Send less JavaScript. But couldn't we have just... written less JavaScript in the first place?

Svelte 5 - Runes look cleaner than the old reactive syntax. But does cleaner code mean faster websites for users?

My Controversial Take

Maybe the framework doesn't matter as much as we think. Maybe the real problem is:

We're building bloated apps when simple pages would work
We're not measuring real user performance
We're optimizing for developer experience, not user experience
We're adding frameworks when vanilla JS would be fine

The Questions I'm Wrestling With

Have you actually measured performance improvements after switching frameworks? What did you find?
When was the last time a framework choice actually solved a real user problem vs. a developer problem?
Are we being honest about whether we need all this tooling, or are we just chasing shiny new things?
What about the sites that are actually fast? A lot of them use "boring" tech. WordPress sites with good caching. Static HTML. Simple server-rendered pages.

Let's Be Real

I'm not saying these frameworks are bad. React Server Components are genuinely useful for certain apps. Astro is perfect for content sites. Svelte is a joy to write.

But I wonder if we've lost sight of the fundamentals:

Optimize images
Lazy load what you don't need immediately
Cache aggressively
Ship less code
Measure real-world performance

These work regardless of your framework.

My Challenge to You

Next time you reach for a new framework, ask yourself:

What problem am I actually solving?
Will users notice the difference?
Am I adding complexity just because it's trendy?

Let's Discuss

What's your experience? Have these new frameworks actually made your sites faster? Or are we just rearranging deck chairs?

What metrics matter to you? Time to Interactive? First Contentful Paint? Or just "does it feel fast?"

What's working in production? Forget the demos and benchmarks. What actually ships fast in real projects with real deadlines and real teams?

Drop your thoughts below. Let's have an honest conversation about this.

What framework are you using right now, and why? Would you choose it again?

What's Your Superpower and How Can Teams Find You?

Kudzai Murimi — Tue, 10 Feb 2026 14:47:39 +0000

Hey! I'm a developer who writes about the messy reality of modern development—from AI-assisted coding to abstraction overload. I believe in learning fundamentals while embracing new tools, and I'm always curious about how others navigate this fast-changing field.

I've noticed something: dev.to is full of incredibly talented developers sharing knowledge, but we don't always make it easy for opportunities to find us. Meanwhile, recruiters and CTOs are definitely browsing these articles looking for people who think clearly and solve real problems.

So let's make this easier for everyone.

How This Works

If you're a developer, drop a comment sharing:

Your specialty - What do you build best?
Your experience level - Junior, mid-level, senior, or "it's complicated"?
Your current focus - What are you working on or learning?
What you bring to teams - Your unique value (beyond just tech stack)
Where to find you - LinkedIn, GitHub, portfolio, Twitter/X
Your situation - Open to work? Open to opportunities? Just networking?

If you're hiring or recruiting, feel free to:

Browse the comments
Reach out to people directly
Share what you're looking for

No pressure, no sales pitches. Just real developers sharing what they're about.

I'll Start

Here's my template (feel free to copy and adapt):

Specialty: Full-stack web development with a focus on developer experience

Experience: 5+ years building production apps

🔧 Current Focus: Exploring how AI tools change development workflows while maintaining code quality

What I Bring:

Strong fundamentals (can debug through any stack)
Clear technical writing and documentation
Balancing modern tools with pragmatic choices

Find Me:

GitHub: http://github.com/respect17
LinkedIn: www.linkedin.com/in/kudzai-murimi-50b7262bb
Portfolio: http://bitwisesoftware.co.za/

Status: Always open to interesting conversations

Why Share This?

Because visibility matters. Some of the best opportunities come from:

Someone reading your comment
A recruiter finding your GitHub through this thread
Another developer reaching out for collaboration
A connection that happens 3 months from now

And honestly? Sometimes you don't realize you're open to new opportunities until the right one finds you.

Ground Rules

Let's keep this valuable:

✅ Be genuine about your skills and experience
✅ Share actual profiles (not just "DM me")
✅ Respect people's time and status
✅ Network authentically
❌ No spam or recruiting pitches in top-level comments
❌ Don't oversell or misrepresent experience

For Recruiters

If you're here looking for talent, that's great! Just remember:

These are real people, not leads
Read what they've written elsewhere on dev.to
Personalize your outreach
Respect their stated availability

My Ask

If you find this useful or connect with someone through this thread, come back and drop an update. Let's see if we can create some real opportunities here.

Alright, your turn! Drop your details in the comments below.

Template for easy copy-paste:

🎯 Specialty: [What you build best]
💼 Experience: [Your level]
🔧 Current Focus: [What you're working on]
🌟 What I Bring: [Your unique value]
🔗 Find Me:
- GitHub: [link] (X followers)
- LinkedIn: [link]
- Portfolio/Twitter: [link]
🌍 Status: [Open to work / Open to opportunities / Just networking]

Let's make some connections! 🚀

The Hidden Cost of 'Just Install This Library'

Kudzai Murimi — Tue, 10 Feb 2026 14:31:28 +0000

The Button That Taught Me a Lesson

Last week, I needed a button. Just a simple button with rounded corners and a loading state.

Old me would have written some HTML and CSS. Done in 15 minutes.

New me, swimming in the modern ecosystem, did this:

npm install @radix-ui/react-button
npm install class-variance-authority
npm install clsx

Two hours later, the button worked beautifully. Then I tried to add a custom style and... nothing. The styles just wouldn't apply. Turns out, the component library uses Shadow DOM, and now I'm reading documentation about CSS encapsulation at midnight.

I saved myself from writing a button. I created a debugging adventure.

The Abstraction Trade-Off

Here's the thing: modern libraries solve real problems! They give us:

Accessibility out of the box
Cross-browser compatibility
Battle-tested patterns
Beautiful defaults

But they also come with a cost that's easy to miss: complexity debt.

Every layer you add is another thing to understand when debugging. Your "simple" stack might look like this:

<Button variant="primary">Submit</Button>

But under the hood, you've got:

Your component library
The primitive component it wraps
The styling system
The CSS framework
The build tool processing everything

When something breaks, you need to debug through all of them.

How Abstractions Stack Up

I think about this as layers of trade-offs:

Plain HTML/CSS/JS: Total control, more code to write
Utility libraries (like lodash): One dependency, solves one problem
Frameworks (React, Vue): Learning curve, but gives you reactivity
Component libraries: Accessibility + UX, but harder to customize
Full solutions (Next.js, etc.): Everything integrated, lots of moving parts

Each level up gives you more out of the box, but takes more effort to customize or debug.

My Simple Rules

After getting burned a few times, here's what I ask before installing anything:

1. Do I understand the problem this solves?

If I can't explain why I need it, I probably don't need it yet.

2. Can I explain how it works in two sentences?

If not, I'm adding complexity I can't debug.

3. What's my escape hatch?

If this library gets abandoned or doesn't work, can I replace it without rewriting everything?

4. Am I choosing this because it's popular or because it fits?

Twitter hype is not a good reason to add a dependency.

Start Simple, Add Complexity When You Feel the Pain

My favorite strategy now: start boring.

// Start here
<button className="btn" onClick={handleClick}>
  Submit
</button>

// Only upgrade when you actually need:
// - Complex keyboard navigation
// - Advanced accessibility
// - Loading states
// - Multiple variants

Let the pain guide you. If you find yourself writing the same button code 10 times, then reach for a library.

When Abstractions Are Worth It

Don't get me wrong, I still use libraries! But now I'm more intentional:

✅ Use them for:

Accessibility (screen readers, keyboard nav)
Complex UI patterns (date pickers, modals)
Things I'd likely get wrong (form validation, security)

❌ Skip them for:

Styling simple components
One-off features
Things I understand well

The Real Lesson

Every abstraction is a trade-off. You're borrowing time today and potentially paying debugging time later.

That's not bad! Sometimes it's absolutely worth it. But we should make that choice consciously, not automatically reach for the shiniest tool.

The best developers I know aren't the ones using the most libraries. They're the ones who can explain why they chose each one.

Your Turn

Before your next npm install, pause and ask:

What problem am I solving?
Can I start simpler?
Do I understand how this works?

You might still install the library. But you'll do it with your eyes open.

What's your take? Do you prefer starting simple or using battle-tested libraries from the start? Let me know in the comments!

The Junior Developer Paradox: Why AI Makes Fundamentals More Important, Not Less

Kudzai Murimi — Sun, 08 Feb 2026 11:18:35 +0000

The Rote Work is Disappearing. Good.

Let's address the elephant in the room: yes, AI is automating away many of the tasks that junior developers traditionally cut their teeth on. Boilerplate code, CRUD operations, simple API integrations, these are increasingly being handled by tools like Copilot, Cursor, and ChatGPT.

And frankly? That's a good thing.

The real question isn't whether junior developers are becoming obsolete. It's whether we're ready to redefine what it means to be one.

The Old Junior Developer Playbook is Broken

For years, the junior developer journey looked something like this:

Spend months writing repetitive code
Gradually understand patterns through repetition
Eventually build enough context to understand why things work
Transition to more complex problems

This worked when implementation was the bottleneck. But in 2025, implementation isn't the bottleneck anymore. Orchestration is.

The new junior developer faces a different challenge: learning to direct AI agents while building enough mental models to know when those agents are leading you astray.

Welcome to the Era of "Vibe Coding"

We're seeing a new pattern emerge—what some call "vibe coding." Developers who can describe what they want, get AI to generate it, and ship quickly without necessarily understanding every line.

This works great... until it doesn't.

The problem? When you're vibing your way through code, you're building on a foundation of assumptions. And assumptions have a nasty habit of compounding:

// AI-generated code that "just works"
const handleUserAction = async (userId, action) => {
  const user = await db.query(`SELECT * FROM users WHERE id = ${userId}`);
  // Wait, did we just open ourselves to SQL injection?
  // Why is this query slow with 10k users?
  // What happens if userId is null?
}

You can ship this. It might even work in production for a while. But without understanding the fundamentals—SQL injection, query optimization, null handling—you're accumulating technical debt you can't see.

The Abstraction Paradox

Here's the cruel irony: the more we abstract away complexity, the more important it becomes to understand what's beneath those abstractions.

Consider the Shadow DOM drama. Developers choose React or Vue for convenience, add a component library for speed, then discover their styling is broken because of Shadow DOM encapsulation. The abstraction that was supposed to make things easier just made debugging exponentially harder.

You can't debug what you don't understand.

This is why the new junior developer role isn't about writing less code—it's about developing a different kind of expertise:

Pattern recognition: Knowing when AI-generated code smells wrong
System thinking: Understanding how components interact, even when you didn't write them
Debug fluency: Tracing issues through layers of abstraction
Fundamental literacy: Grasping HTTP, databases, state management, security

The Mental Game Has Changed Too

Let's talk about the psychological toll of this transition.

Imposter syndrome hits different when AI can generate in seconds what took you hours to learn. You watch your AI pair programmer spin up a complex auth flow while you're still Googling "how does JWT work" and think: "Am I even needed?"

Then there's the Dunning-Kruger cliff. You can now ship features without understanding them, which creates a dangerous confidence. You feel productive—until you hit a bug that requires actual understanding to fix.

The hardest part? Admitting what you don't know while surrounded by tools that make it seem like you should know everything.

So What Should Junior Developers Actually Learn?

If you're entering the field in 2025, here's my honest advice:

1. Build Things That Break

Don't just use AI to build things that work. Intentionally build things that break, then fix them without AI assistance. This is where learning happens.

# Try this exercise
1. Ask AI to build a REST API
2. Deploy it
3. Load test it until something breaks
4. Fix the bottleneck yourself
5. Understand why it broke

2. Learn to Read, Not Just Write

Your most valuable skill will be reading and understanding code—including AI-generated code. Practice:

Reading open-source codebases
Code reviews (even of your own AI-generated code)
Debugging without Stack Overflow

3. Master the Fundamentals That Don't Change

These are your leverage points:

How databases actually store and retrieve data
How networks transmit information
How browsers render pages
How operating systems manage resources

These concepts don't change every six months. They compound.

4. Develop "Smell Detection"

Learn to recognize code smells:

N+1 queries
Memory leaks
Race conditions
Security vulnerabilities

AI can generate vulnerable code convincingly. Your job is to catch it.

5. Build Without the Safety Net

Regularly practice building features from scratch without AI:

Implement a basic router
Write a simple state management system
Create a mini ORM

You don't need to use these in production, but you need to understand how they work.

The New Junior Developer Advantage

Here's what gives me hope: junior developers entering the field today have an unprecedented opportunity.

You get to learn with a pair programmer that never gets tired, never judges, and can explain concepts a hundred different ways.

The seniors who spent years writing boilerplate? That muscle memory doesn't transfer to AI-assisted development. You're all learning this new paradigm together.

Your advantage is adaptability. You're not unlearning old workflows. You're building mental models for a world where:

Implementation is fast
Orchestration is hard
Understanding is everything

The Real Extinction Risk

Junior developers aren't going extinct. Junior developers who refuse to understand fundamentals are.

The market will always need people who can:

Debug complex systems
Make architectural decisions
Understand trade-offs
Recognize when AI is confidently wrong

What's disappearing is the luxury of learning these things slowly through years of repetitive tasks.

Your Training Ground Has Changed

The rote work that used to be your training ground? It's gone. And that's fine, because it was never the point.

The point was always understanding.

You just used to get there through repetition. Now you need to get there through curiosity, intentional practice, and yes—occasionally building things the hard way to understand why the easy way works.

The Bottom Line

We're not moving from a world where developers write code to a world where AI writes code.

We're moving from a world where developers implement features to a world where developers orchestrate systems.

The developers who thrive will be those who can:

Direct AI effectively
Recognize its mistakes
Understand the systems they're building
Debug across layers of abstraction

That requires deeper technical understanding, not less.

So if you're a junior developer worried about AI taking your job, I'll leave you with this: AI can generate code, but it can't (yet) develop the judgment to know which code to write, when to write it, and why it matters.

That's still your job. Make sure you're ready for it.

*What's your experience learning to code in the AI era? Are you finding the fundamentals more or less important?

Let's discuss in the comments below.