DEV Community: Kudzai Murimi

REST vs GraphQL vs tRPC in 2026

Kudzai Murimi — Wed, 17 Jun 2026 20:24:20 +0000

Every new project. Same argument.

"Let's use REST, everyone knows REST."
"Actually, GraphQL would be cleaner here."
"Have you looked at tRPC? It's basically magic if you're on TypeScript."

This debate has been happening in Slack channels and architecture meetings for years. In 2026, we finally have enough real-world data to end it.

Spoiler: there's no winner. But there is a right answer for your project — and it takes about 60 seconds to figure out.

The 30-Second Summary

	REST	GraphQL	tRPC
Best for	Public APIs	Complex data, many clients	TypeScript full-stack
Learning curve	Low	High	Medium
Type safety	Manual	Generated	Built-in
CDN caching	✅ Excellent	❌ Painful	✅ Good
Non-TS support	✅ Any language	✅ Any language	❌ TypeScript only
Hidden cost	Versioning debt	Query complexity tooling	TS monorepo required

REST: Old But Not Dead

REST still powers over 80% of public APIs and that's not changing anytime soon. Here's why it's still the default for most teams:

Every language has an HTTP client. Your Python service, your mobile app, your third-party partner — they all speak REST without any special setup.
CDN caching works out of the box. GET /products/123 can be cached at the edge. That's free performance most teams leave on the table with other approaches.
It's debuggable in a browser tab. That matters more than people admit.

The real cost no one talks about: versioning. Every breaking change means a new endpoint, a deprecation timeline, and years of maintaining /v1 alongside /v2. REST's hidden cost is API versioning maintenance — and it compounds over time.

Use REST when: you're building a public API, third-party integrations, webhooks, or anything consumed by clients you don't control.

GraphQL: Powerful, But You're Going to Pay For It

GraphQL solves a real problem. When your frontend needs exactly 7 fields from a user object, 3 fields from their orders, and 2 fields from their subscription — REST makes you do 3 round trips or build a bespoke endpoint. GraphQL lets the client ask for exactly what it needs in one request.

GraphQL achieves 28% lower latency for complex queries that would otherwise require multiple REST calls. For mobile apps and data-heavy dashboards, that's meaningful.

But here's what the tutorials leave out: at scale, GraphQL requires query complexity analysis, persisted queries, depth limiting, and specialized monitoring tools — an infrastructure tax that's real and often overlooked.

GraphQL adoption has surged 340% since 2023, yet 93% of development teams still rely on REST. The growth is real. So is the operational overhead.

Use GraphQL when: you have a complex data graph, multiple client types (web, mobile, third-party) with very different data needs, and a team willing to invest in the tooling.

tRPC: The Quiet Game-Changer For TypeScript Teams

tRPC is the youngest of the three and the least understood outside TypeScript circles. Here's the pitch: you define your API procedures on the server, and the client calls them with full type inference — no schemas, no code generation, no extra build steps.

tRPC appears in 15% of full-stack job listings and climbing fast, almost exclusively in listings that also mention TypeScript and Next.js. That's a telling pattern.

The developer experience is genuinely different. Rename a server function and your IDE instantly tells you every place the client calls it. Change a return type and TypeScript catches every consumer that breaks. No GraphQL complexity, no OpenAPI code generation — just pure TypeScript type inference.

The hard limit: tRPC only works when client and server share a TypeScript codebase. The moment you need a mobile app, a third-party integration, or a Python service calling your API — you need REST or a separate layer.

Use tRPC when: your entire stack is TypeScript, you're in a monorepo, and all your clients are your own frontend.

The Real Answer: Most Production Apps Use All Three

Here's the truth nobody puts in their REST vs GraphQL blog posts: most production systems use more than one.

The typical 2026 SaaS stack looks like this:

Public API (for partners, webhooks, SDKs) → REST
Your own frontend (Next.js, React) → tRPC or GraphQL
Service-to-service (internal microservices) → REST or gRPC

This isn't over-engineering. It's matching the right tool to the right consumer.

The 60-Second Decision Framework

Answer these three questions:

1. Who consumes this API?

External developers or partners → REST
Only your own TypeScript frontend → tRPC
Multiple client types with wildly different data needs → GraphQL

2. Do you control all the clients?

Yes, and they're all TypeScript → tRPC
No → REST or GraphQL

3. How complex is your data?

Simple CRUD → REST or tRPC
Deeply relational, clients need flexible queries → GraphQL

Stop picking based on what's trending. Pick based on who's consuming your API and what they actually need.

The teams that ship fast in 2026 aren't the ones who picked the right framework. They're the ones who stopped arguing about it.

Which are you currently using — and would you pick the same if you started over today? Drop it in the comments.

# 10 VS Code Extensions Every Developer Needs in 2026

Kudzai Murimi — Wed, 17 Jun 2026 19:13:52 +0000

Before we start — a warning.

This isn't one of those lists where I throw 25 extension logos at you and call it a day. There are over 50,000 extensions in the VS Code marketplace. Most of them are garbage. Some duplicate features that are already built in. Some haven't been updated since 2021 and are silently slowing your editor down right now.

This list is 10. Intentionally. Because a bloated extension setup is its own kind of technical debt.

Let's get into it — opinions included.

1. ESLint — Non-Negotiable

The take: If you're writing JavaScript or TypeScript without ESLint running in your editor, you're just sending bugs to code review instead of catching them yourself.

ESLint enforces your project's coding rules in real-time, flags problems as you type, and saves your team hours of review comments on things a machine should be catching. It's been around forever and it's still irreplaceable.

Unpopular opinion: Most developers have ESLint installed but misconfigured. Default rules are nearly useless. The value comes from setting up rules that match your actual project. If you haven't touched your .eslintrc in six months, you're not really using ESLint.

2. Prettier — Just Let It Format Your Code

The take: Code formatting debates are a waste of everyone's time. Tabs vs spaces, semicolons or not, single quotes or double — none of it matters as long as the whole team is consistent. Prettier enforces consistency automatically on save. End of discussion.

Unpopular opinion: If your team is still arguing about formatting in 2026, that's a culture problem, not a tooling problem. Install Prettier, set "editor.formatOnSave": true, and move on to actual work.

3. GitLens — Git Blame That Doesn't Make You Leave the Editor

The take: GitLens is the most downloaded Git extension for VS Code for a reason. Inline blame annotations showing who changed each line and when, interactive commit graphs, file history — all without leaving your editor. The free tier covers everything most developers will ever need.

Unpopular opinion: If your first reaction to a bug is "whose fault is this?" rather than "how do we fix this?", GitLens will make you a better developer or a more toxic teammate. Depends entirely on you.

4. Error Lens — Errors Where You Actually Look

The take: By default, VS Code shows errors in the Problems panel at the bottom of the screen. Nobody is looking at the bottom of the screen. Error Lens moves error messages inline, right next to the line that caused them. It sounds minor. It's not. Once you use it, going back feels broken.

Unpopular opinion: This should be VS Code's default behavior. The fact that it's an extension in 2026 is a minor embarrassment for Microsoft.

5. GitHub Copilot — But Not For the Reason You Think

The take: GitHub Copilot is the most widely adopted AI coding assistant in VS Code. It does more than autocomplete now — it writes full functions, generates tests, and handles natural language to code. For repetitive code, boilerplate, and "I know what I want but don't want to type it" moments, it's genuinely fast.

Unpopular opinion: Copilot is making junior developers worse at problem-solving and senior developers lazier about documentation. The productivity gain is real. The skill atrophy is also real. Use it intentionally, not reflexively. And always read what it generates before you ship it — 45% of AI-generated code contains at least one security vulnerability.

6. Thunder Client — Because Postman Got Too Big for Its Own Good

The take: Thunder Client is a lightweight REST API client built directly into VS Code. Test your endpoints without leaving your editor, without opening another app, without waiting for Postman to load.

Unpopular opinion: Postman in 2026 is bloatware. What started as a simple API testing tool is now a platform with workspaces, teams, flows, and a pricing page with four tiers. Thunder Client does 90% of what most developers actually need in a fraction of the weight. If you're still defaulting to Postman out of habit, try Thunder Client for a week.

7. Tailwind CSS IntelliSense — If You're Using Tailwind, This Is Mandatory

The take: Autocomplete, syntax highlighting, and linting for Tailwind classes directly in your editor. Hovering over a class shows you the exact CSS it generates. This extension makes Tailwind actually pleasant to write.

Unpopular opinion: Tailwind itself is still controversial and that's fine. But if your team has decided to use it, not having this extension is just self-inflicted pain. Arguments about whether Tailwind is good belong in a different article.

8. Path Intellisense — The Smallest Extension With the Highest Return

The take: Autocompletes file paths as you type import statements. That's it. It's tiny, it's fast, and it eliminates an entire category of annoying errors — the ones where you typed ../components/Button when you meant ../../components/Button.

Unpopular opinion: This is the most underrated extension on this list. Nobody talks about it. Everyone who installs it wonders how they lived without it.

9. Docker — If Containers Are Part of Your Workflow

The take: The official Docker extension for VS Code lets you manage containers, images, volumes, and networks directly from the editor. Build, run, inspect logs, and exec into containers without touching the terminal for Docker commands.

Unpopular opinion: If you're running Docker in 2026 without this extension, you're memorizing commands you don't need to memorize. That mental space could go toward something more interesting.

10. VS Code Icons — Last On The List, Not Least

The take: Replaces VS Code's default file icons with a comprehensive set that makes different file types visually distinct at a glance. Python files look different from JavaScript files. Config files are obvious. It sounds cosmetic. It's actually a real time saver when navigating large projects.

Unpopular opinion: Developers who dismiss visual organization as "unimportant" are the same ones who spend 10 seconds finding a file they've opened before. Your environment shapes how you work. Make it work for you.

The Extensions That Didn't Make the List (And Why)

Bracket Pair Colorizer — VS Code has had built-in bracket pair colorization since 2021. You don't need the extension anymore.
Auto Close Tag / Auto Rename Tag — Built into VS Code for HTML and JSX. Check your settings before installing.
Live Share — Great concept, unstable in practice. If you're pair programming regularly, a purpose-built tool handles it better.
indent-rainbow — Pretty. Doesn't solve a real problem. Skip it.

The Rule Behind This List

Before you install any extension, ask yourself three things:

Does VS Code already do this natively?
When was the last update? (Anything not updated in 12+ months is a risk)
Will I actually use this daily, or is it just satisfying to install?

A tight extension setup makes VS Code fast, focused, and actually pleasant to work in. Every extension you add is a trade-off. Make them deliberately.

Which extensions am I wrong about? Drop it in the comments — I want the pushback.

# Python vs JavaScript in the AI Era: Which One Should You Actually Learn?

Kudzai Murimi — Wed, 17 Jun 2026 16:58:50 +0000

Let's get the obvious out of the way first.

Both languages are thriving. Both are in high demand. And if someone tells you one is dead or irrelevant, they're wrong.

But the AI era has quietly shifted how these two languages are used — who uses them, for what, and where the opportunities are heading. If you're picking up a new skill, switching stacks, or just trying to understand the current landscape, this breakdown is for you.

No fluff. Real numbers. Honest take.

First, Where Things Stand in 2026

The data tells an interesting story — because both languages are winning, just in different arenas.

JavaScript still holds the top spot for overall usage. According to the 2026 Stack Overflow Developer Survey, 62.3% of all developers used JavaScript in the past year — a position it has held since 2013. That's remarkable consistency.

Python, meanwhile, just pulled off something historic. For the first time in a decade, Python overtook JavaScript as the number-one language on GitHub by pull request volume. Python pull requests grew 48% year over year — driven almost entirely by AI, machine learning, and data science workloads. It now sits at #1 on the TIOBE index with the largest lead over a second-ranked language in the index's 23-year history.

So JavaScript is everywhere. Python is growing faster than it ever has. Both are true at the same time.

What Each Language Actually Does Best

Python: The Language of AI

There's no polite way to say this — if you want to work in AI, Python is not optional. It's the default.

71% of all generative AI projects on GitHub are written in Python
AI project repositories on Python grew 50.7% year over year
PyTorch, TensorFlow, Hugging Face, LangChain, scikit-learn — the entire ML stack is Python-first

This isn't a coincidence or community preference. Python's clean syntax, dynamic typing, and rich ecosystem of scientific libraries made it the natural home for researchers and data scientists years ago. That early adoption created a flywheel that now powers the entire AI industry.

If you're building models, training neural networks, working with data pipelines, or doing anything research-adjacent — Python is where you live.

JavaScript: The Language of the Web (and Increasingly AI Products)

JavaScript's dominance comes from a simple fact: it's the only language that runs natively in the browser. Nothing has changed that, and nothing is likely to soon.

But what's interesting in 2026 is how JavaScript has adapted to the AI era rather than been left behind by it. Developers are building AI-powered products with JavaScript every day — calling LLM APIs, integrating AI features into full-stack apps, building the interfaces that users actually interact with.

The framework ecosystem is thriving too. React remains dominant. Next.js continues to mature. The JavaScript/TypeScript ecosystem now accounts for over 4.5 million active developers.

Python may power the brain. JavaScript builds the face.

The AI Era Breakdown: What Each Is Actually Used For

Category	Python	JavaScript
Training ML models	✅ Dominant	❌ Rarely used
Data science & analysis	✅ Primary choice	❌ Limited tooling
AI research	✅ Industry standard	❌ Not applicable
Building AI APIs	✅ Strong (FastAPI, Flask)	✅ Strong (Node.js)
AI-powered web apps	⚠️ Backend only	✅ Full stack
Browser-based AI features	❌ Not possible	✅ Only option
Automation & scripting	✅ Excellent	✅ Good with Node
General web development	⚠️ Limited frontend	✅ Dominant

Career Paths: Where the Jobs Are

This is where the choice gets personal.

Python opens doors to:

Machine Learning Engineer
Data Scientist
AI Engineer
Backend Developer (API-focused)
Automation Engineer

These roles tend to be highly specialized and increasingly well-compensated. Python AI roles are increasingly bundled with cloud architecture skills (AWS, Azure) and data ethics knowledge — companies aren't just looking for coders anymore; they're looking for "AI architects."

JavaScript opens doors to:

Frontend Developer
Full-Stack Engineer
Backend Engineer (Node.js)
AI Integration Developer
Product Engineer

JavaScript's strength is versatility. A solid JavaScript developer can own an entire product from database to user interface. With TypeScript now the fastest-growing language on GitHub (up 66% year over year), that ecosystem is only getting more robust.

The Honest "Which Should I Learn" Answer

Here's the thing — the right answer depends entirely on what you want to build.

Learn Python if:

You want to work in AI, ML, or data science
You're drawn to research, automation, or backend data work
You want to be at the center of where the industry is heading

Learn JavaScript if:

You want to build web products people actually use
You enjoy full-stack development and seeing your work in a browser
You want maximum flexibility across frontend, backend, and product work

Learn both if:

You want to build AI-powered web applications end-to-end (this is increasingly the most valuable skill combination in the market)
Python handles your AI logic and API layer, JavaScript builds everything users see

The developers getting the most interesting opportunities right now aren't the ones who went deep on one language in isolation. They're the ones who can sit at the intersection — building AI features that actually ship into real products.

A Thought Before You Decide

Both languages have survived long enough to prove they're not going anywhere. JavaScript has held the top usage spot for over a decade. Python just had its biggest year ever.

The AI era didn't kill one of them. It gave each one a clearer purpose.

Pick the one that fits where you want to go. Then get really good at it.

Which camp are you in — Python, JavaScript, or both? Drop it in the comments. I'd genuinely love to see where this community lands.

The 'Prompt' Is Not a Skill? I Disagree , Here's What 6 Months of AI Development Taught Me

Kudzai Murimi — Wed, 17 Jun 2026 16:31:26 +0000

I almost scrolled past that post.

You've probably seen it. Someone argues that "prompting" is just clever wording — a parlor trick that anyone can pick up in an afternoon. That real developers shouldn't waste time thinking about it.

I used to half-agree with them.

Then I spent six months building real products with AI at the core, and my opinion completely changed.

Let's Be Honest About Where This Take Comes From

The argument usually goes something like this:

"Prompting is just typing in plain English. It's not like learning algorithms or system design. It'll be automated away anyway."

And I get it. On the surface, prompting looks trivial. You type something, the model responds. How hard can it be?

Here's the thing — the same argument was made about Google Search in 2002. "It's just typing words into a box." But we now know that knowing how to search — what terms to use, how to evaluate results, how to iterate — separates people who find answers in 30 seconds from those who give up after 5 minutes.

Prompting is search. Just for intelligence instead of links.

What I Actually Learned After 6 Months

1. Bad prompts don't fail loudly — they fail silently

This one surprised me the most.

When you write bad code, you usually get an error. The program crashes. Something breaks visibly.

When you write a bad prompt, the AI gives you a confident, well-structured, completely wrong answer. And if you're not careful, you ship it.

Learning to write prompts that surface uncertainty, expose assumptions, and force the model to "show its work" — that is absolutely a skill. It took me weeks to get right.

2. Prompt structure changes outcomes more than prompt length

Early on, I thought better prompts meant longer prompts. More context, more detail, more examples.

That's only half true.

What actually matters is structure. Separating the role from the task from the constraints. Telling the model what format you want the output in. Specifying what you don't want as clearly as what you do.

A 3-line structured prompt consistently outperformed my 15-line rambling ones. That intuition doesn't come naturally — you develop it through practice and failure.

3. Domain knowledge makes prompts dramatically better

Here's where the "it's just English" argument falls apart completely.

Two people can type the same words to an AI and get very different results — because one of them knows the domain and one doesn't.

A developer who understands REST API design will write prompts that produce cleaner, more realistic API schemas. A data analyst who knows SQL will prompt their way to better queries. Knowledge shapes how you frame problems, what edge cases you think to mention, what output you know to reject.

Prompting doesn't replace expertise. It multiplies it.

4. Iteration is the real skill

The people I've seen get the most out of AI tools aren't the ones who write perfect prompts on the first try. They're the ones who iterate fast and intelligently.

They know when to push back on an output. They know how to reframe a question when the first answer misses the mark. They build mental models of what kinds of tasks AI handles well and where it consistently falls short.

That's not luck. That's a learned skill.

"But It'll Be Automated Away"

Maybe. Eventually.

But so will a lot of things. The question is: what do you do right now, with the tools that exist right now?

Right now, the gap between a developer who prompts well and one who doesn't is massive. I've seen it in code review speed, in the quality of generated tests, in how quickly someone can go from idea to working prototype.

Dismissing that gap because the skill might become easier in five years is like refusing to learn Git in 2010 because "version control will probably get simpler someday."

What "Getting Good at Prompting" Actually Looks Like

In case you're wondering what to actually practice, here's what moved the needle for me:

Write prompts like you're briefing a smart intern, not commanding a robot. Context, goal, constraints, format.
Use negative instructions. "Don't include boilerplate" is sometimes more powerful than describing what you do want.
Ask the model to reason before it answers. "Think step by step" isn't a magic spell — it's a structural cue that changes how the model processes the problem.
Build a personal library of prompt patterns that work for your specific use cases. Treat them like reusable functions.
Study failures. When a prompt produces a bad result, figure out why. That's where the real learning happens.

The Honest Conclusion

Prompting is not a replacement for software engineering skills. It doesn't substitute for system design, data structures, or deep domain knowledge.

But it is a genuine skill that lives alongside those things. One that compounds with your existing expertise. One that, if you ignore it, will quietly slow you down while the people around you move faster.

Six months ago I thought prompting was a shortcut.

Now I think it's a craft.

What's your experience been? Have you found prompting makes a difference in your day-to-day work? Drop it in the comments — I'm genuinely curious where people land on this.

5 Claude AI Pro Features Developers Are Obsessed With in 2026

Kudzai Murimi — Fri, 29 May 2026 08:36:57 +0000

You know that feeling when a tool clicks and suddenly you're 3x faster? That's what's happening right now in dev communities with Claude Pro.

This isn't about autocomplete or suggestions anymore. The latest Claude Pro features are fundamentally changing how developers work—from solo builders shipping features in hours instead of days, to engineering teams automating entire workflows.

Here are the 5 Claude Pro features every developer should know about in 2026.

1. Claude Code: The AI Junior Developer You've Been Waiting For

This is the headline feature.

Claude Code isn't just an autocomplete. It's an actual coding agent that:

Reads your entire codebase and understands your architecture
Writes full features from requirements
Runs tests to validate code
Debugs errors with reasoning
Refactors files across repos
Creates pull requests ready to review
Executes terminal commands directly

It behaves like a junior developer who knows your project inside and out.

What developers love most

"I can describe a feature in natural language and Claude Code builds it, tests it, and creates a PR. The code actually works on the first try 80% of the time."

Huge productivity boost for Laravel, React, Next.js, Node.js, Python
Excellent at large codebases (understands context across 50+ files)
Strong reasoning for debugging (knows the stack trace, follows the logic)
Perfect for "implement this feature" prompts

Best use cases

✓ Fixing bugs (1-2 hour bugs → 5 minutes)
✓ Database migrations (write schema, tests, seeds)
✓ Writing APIs (OpenAPI specs → working endpoints)
✓ Generating test suites (coverage gaps → full test files)
✓ Repo-wide refactors (rename, restructure, patterns)
✓ DevOps automation (Docker, CI/CD scripts)


**Pro tip:** Start with "read my codebase structure" to let Claude map your project, then ask for specific features.



## 2. Artifacts: Ship UIs Without Leaving Chat

**This is the feature that makes prototyping instant.**

Artifacts turn Claude into a mini app builder. In the same chat, you get:

- **Live previews** of React components
- **Interactive dashboards** (fully functional)
- **HTML/CSS pages** you can download immediately
- **Diagrams** (flowcharts, architecture, ERD)
- **Markdown docs** formatted and ready
- **Visual tools** (calculators, generators, trackers)

Everything renders in an **editable, downloadable workspace** inside Claude.

### Why developers actually use this

Instead of:

Claude: "Here's the code for a dashboard. Copy it into your React project..."
You: copies, debugging imports, fighting dependencies for 30 min


You get:

Claude: renders interactive dashboard with live data
You: sees it working instantly, tweaks it in the editor, downloads it


### Real examples from production

- **Admin dashboards** (user management, analytics, settings)
- **Landing pages** (fully styled, responsive, SEO-ready)
- **Quick prototypes** (for client demos or internal tools)
- **SaaS mockups** (onboarding flows, payment pages)
- **Component generation** (reusable form builders, tables)
- **Living documentation** (interactive API docs)

Frontend teams have cut prototyping time by 70%.



## 3. MCP: Claude Connects to Your Entire Development Stack

**This transforms Claude from a chat tool into an automation agent.**

MCP (Model Context Protocol) lets Claude directly connect to:

GitHub → Create/update issues, open PRs, inspect code
Databases → Query production data, generate migrations
Notion → Read docs, update wikis, create changelogs
Slack → Send alerts, read threads, update status
APIs → Call your backend, fetch real-time data
IDE tools → Debug locally, run commands, inspect logs
Custom systems → Your internal tools, dashboards, services


Through **standardized connectors** Claude can orchestrate workflows.

### What this actually means

You can:

"Check the last 10 production logs and create a GitHub issue
with the error pattern. Post a summary to #engineering."


Claude does all of it—reads logs → finds pattern → creates issue → posts update.

### Startup builders are already doing this

- **Generating reports** from databases on a schedule
- **Updating GitHub issues** from Slack conversations
- **Automating DevOps tasks** (deployments, rollbacks, monitoring)
- **Building internal tooling** that talks to multiple systems
- **Game engine control** (Godot MCP has 162 tools—Claude can build 3D games autonomously)

MCP is why some teams now think of Claude as an "engineering assistant" not a "chat tool."

## 4. Huge Context Window: Understand Your Entire Codebase at Once

**This changes everything about how Claude reasons about your code.**

Claude Pro's large context window means you can paste:

✓ Entire repositories (100+ files)
✓ Multiple service boundaries
✓ Architecture documentation
✓ API specifications
✓ Database schemas
✓ Production logs
✓ Test suites


**All at once. Without losing context.**

### Why this matters

**Before:** Ask Claude about a bug → limited to a single file → misses root cause
**After:** Show entire codebase → Claude sees the full dependency chain → finds the real bug in 10 seconds

### Practical benefits

Claude can now:

- **Understand project architecture** (sees design patterns across files)
- **Maintain coding consistency** (notices your style, applies it everywhere)
- **Reason across services** (understands microservice interactions)
- **Debug complex systems** (follows the call stack across 50 files)

### This is crucial for

- Laravel monoliths (10k+ lines of interconnected code)
- Enterprise applications (complex dependency trees)
- Next.js full-stack apps (frontend + API + database all in context)
- Microservices (reasoning across service boundaries)

**Result:** Developers with large codebases see the biggest productivity gains.



## 5. Extended Thinking + Agent Workflows: Let Claude Think Harder

**This is Claude's secret superpower.**

Extended thinking lets Claude engage in **deeper reasoning** for complex problems:

Analyze the problem (read code, logs, specs)
Create a plan (break it into steps)
Write implementation (generate code)
Test thoroughly (run tests, catch errors)
Fix issues (debug, refactor)
Summarize changes (explain what happened)


Claude chains these together **autonomously** without you steering.

### When developers use this

"Our Next.js app has weird caching issues on the production API.
Debug this end-to-end and fix it."


Claude thinks through:
- Request flow (client → server → database)
- Cache layers (browser, CDN, app-level)
- Race conditions (concurrent requests)
- Timing issues (stale data)
- Real fix (not a band-aid)

Then delivers: code changes + test cases + deployment notes.

### Best for

- Complex debugging (race conditions, memory leaks, timing bugs)
- Architecture planning (designing new systems)
- System design (scaling strategies, performance optimization)
- Automation pipelines (multi-step workflows)
- AI coding agents (letting Claude run autonomously)

---

## The Ultimate Claude Pro Stack for Maximum Productivity

Here's what the fastest developers are using right now:

| Feature | What It Does | Your Win |
|---------|-------------|----------|
| **Claude Code** | Full coding agent | Build features 3-5x faster |
| **Artifacts** | Live app builder | Prototype in seconds |
| **MCP** | Connect everything | Automate entire workflows |
| **Large Context** | Understand everything | No more context switching |
| **Extended Thinking** | Deep reasoning | Solve hard problems autonomously |

**Combined effect:** An AI engineer + app generator + automation assistant in one workflow.

---

## Real Productivity Wins (From Actual Developers)

### Backend engineer (Laravel)
> "Used to take 4 hours to build an API. Claude Code does it in 20 minutes with tests."

### Frontend engineer (React)
> "Artifacts let me ship interactive prototypes same-day. Used to take 2-3 days to build mockups."

### DevOps engineer
> "MCP + extended thinking handles deployment automation I'd normally spend a week on."

### Startup founder
> "I'm shipping full features alone. Claude Code handles the coding, Artifacts for landing pages, MCP for automation. Feels like I have a small team."



## How to Get Started Right Now

### Step 1: Start with Claude Code
Ask Claude:

"Read my codebase structure and tell me what you find."

Then:

"Build [feature name]. Here's what I want..."


### Step 2: Use Artifacts for UI
Next time you need a component, dashboard, or prototype:

"Build me a [thing]. I need [requirements]."

Grab the code directly from the rendered artifact.

### Step 3: Connect MCP (Optional but powerful)
Link Claude to:
- Your GitHub repo (issue + PR automation)
- Your database (query, generate migrations)
- Your Slack (notifications, updates)

### Step 4: Try Extended Thinking for Complex Problems
When you have a hard bug or design challenge:

"Debug this [problem]. Think through it step-by-step."




## The Bottom Line

In 2026, Claude Pro isn't a copilot anymore. It's:

✅ **Claude Code** = AI engineer  
✅ **Artifacts** = App builder  
✅ **MCP** = Automation agent  
✅ **Large Context** = Codebase understanding  
✅ **Extended Thinking** = Problem solver  

Together? You ship faster than teams twice your size.

The developers getting the most value are the ones combining these features. Start with Claude Code. Add Artifacts. Then explore MCP for automation.

Your productivity will thank you.


**Have you tried any of these features? What's your biggest productivity win so far? Drop it in the comments—I'm curious what's working for your team.**

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.