DEV Community: Kudzai Murimi

How to Write a Developer CV That Survives ATS and Still Reads Like a Human Wrote It

Kudzai Murimi — Tue, 25 Aug 2026 06:18:03 +0000

Most CV advice picks one side. Either you optimize for the applicant tracking system. Or you write for a human. You need both. A bot filters your CV first. A human decides later whether to call you.

What the ATS Actually Does

It is not smart AI. It mostly parses your document into fields. Name. Contact info. Work history. Skills. Then it matches keywords against the job description. Here is what that means for you.

Use standard section headers. Call them "Professional Experience" and "Education" and "Skills." Do not get creative with names like "My Journey." That can break the parser.

Avoid tables. Avoid text boxes. Avoid multi column layouts. Many parsers read left to right and top to bottom. A two column layout can scramble your work history into nonsense.

Match the language in the job posting. Do not just use your own words. If they say "Node.js" and you wrote "backend JavaScript," you might not match. Even if you clearly qualify.

Save your CV as a .docx file or a text based PDF. Do not use an image based or heavily designed PDF. If you cannot select and copy the text yourself, the parser probably cannot either.

What Makes a Human Want to Talk to You

Once you pass the filter, the CV has a new job. It needs to convince a person you are worth thirty minutes of their day.

Quantify your impact when you can. "Reduced page load time by 40 percent" beats "improved performance." No number to use? Describe the before and after instead.

Start each bullet with what changed. Not what you were assigned. "Migrated the checkout flow to a queued job to eliminate timeout errors" tells a real story. "Responsible for checkout flow" does not.

Cut anything you cannot back up. Skip vague lines like "great communicator" or "team player." Show it instead. Let your accomplishments prove it.

Keep the length matched to your experience. Early career means one page. Deep into your career means two pages. Keep it tight. Do not write a full chronological diary.

The Trap

Do not over optimize for one reader at the other's expense. A CV stuffed with keywords reads like noise to a human. A CV written only for flow can get filtered before anyone sees it. The fix is not a trick. Write the true version of your experience. Use the words the industry uses. Use the words this job posting uses.

Do This Before Every Application

Read the job posting slowly. Underline the specific technologies and responsibilities they name. Then check your CV against that list. Do not fabricate experience you don't have. Just make sure your real experience uses their words, not only your own. This one step fixes more rejections than any template swap.

The Remote Job Search Playbook for Developers Outside the US/EU

Kudzai Murimi — Tue, 25 Aug 2026 06:15:57 +0000

The Remote Job Search Playbook for Developers Outside the US/EU

Remote work opened the door for developers outside major tech hubs to compete for roles that used to be geographically gated. It also created a much bigger applicant pool for every posting. If you're searching from outside the US/EU, here's what actually affects your odds — beyond "just apply to more jobs."

Timezone overlap is a real filter, not a footnote

A lot of "remote, worldwide" postings quietly mean "remote, but we need 4+ hours of overlap with our core team." Before you apply, check what timezone the company or their existing team is in. If you can genuinely offer a workable overlap, say so explicitly in your application — don't make a recruiter guess whether a 7-9 hour time difference is going to be a problem later.

Sourcing channels that actually produce interviews

Recruiting-as-a-service platforms (Rightfit-style agencies, Toptal, Turing) — they pre-filter for companies actively hiring remote and internationally, which saves you from applying into a black hole on a generic job board.
Company engineering blogs and changelogs — companies that write publicly about their engineering tend to also be more remote-mature and less nervous about hiring outside their home country.
Referrals inside communities you're already part of — dev.to, Discord servers for your stack, open-source project maintainers. A referral skips the "will this person actually work out remotely" anxiety that a cold application can't answer.
Direct outreach to smaller, funded startups — they often can't afford local senior talent and are more open to global hiring than enterprise companies with rigid HR policy.

What to lead with in your application

Recruiters hiring internationally are quietly screening for risk: will this person disappear, will communication be a problem, will payment/compliance be a headache. Address these before they have to ask:

State your availability and overlap hours plainly.
Link to async-friendly proof of work — a deployed project, a GitHub history with real commit activity, a technical article. This substitutes for the "vibe check" an in-person interview would normally give them.
If you've done contract/freelance work with international clients already, say so explicitly — it signals you already know how to work across time zones and payment rails.

The payment/compliance reality

Get familiar with how you'll actually get paid before it becomes a blocker mid-negotiation — platforms like Deel, Payoneer, or Wise exist specifically because cross-border payroll is messy. Knowing your own answer to "how do you want to be paid" makes you look more prepared, not more high-maintenance.

Compensation framing

Salary ranges posted for a specific country's cost of living don't always translate cleanly, and currency conversion can make a number look smaller or larger than it actually is locally. Do the math in your own currency and cost of living before deciding a range is or isn't worth pursuing — a number that looks modest in USD can be very solid depending on where you live, and vice versa.

The uncomfortable truth

You are competing against a genuinely global pool now, which means portfolio and communication quality matter more than they used to, because there's no in-person interview softening a rough resume. The upside is that a strong deployed project and a clear, well-written application travel just as far as being physically local ever did — this is the first time in tech history where that's fully true.

Breaking Into Full-Stack Development Without a CS Degree: What Actually Worked for Me

Kudzai Murimi — Tue, 25 Aug 2026 06:14:22 +0000

Breaking Into Full Stack Development Without a CS Degree: What Actually Worked for Me

I didn't go through a computer science program. What I have instead is about seven years of shipping production code. I learned almost all of it from official documentation, open source repos, developer communities, and a lot of trial and error on real client work. If you're on that same path and wondering if it's enough, here's what actually moved the needle for me. And what turned out to be a waste of time.

What Worked

Building things that had to work, not things that looked good on a syllabus. Tutorial projects teach syntax. Client work teaches you what happens when a payment webhook fires twice. Or when your "simple" CRUD app suddenly needs to survive ten times the traffic you designed for. The fastest learning happened on real, slightly terrifying production systems. Not curated coursework.

Reading source code and official docs before reaching for a course. Anyone can follow a video tutorial. Fewer people will sit with Laravel's own documentation. Or actually read through a library's source when the docs run out. That habit compounds. You stop depending on someone else pre chewing the material for you. And you get faster at picking up whatever stack a client happens to be using.

Writing about what I learned. Technical writing forced me to actually understand things well enough to explain them. Not just well enough to copy paste them into working code. If you can't write a clear paragraph about why you chose NgRx over plain component state, you probably don't understand it as well as you think.

Taking freelance and agency work early, even underpriced. Nobody hands a self taught developer a senior role on day one. What they will do is pay you to fix their bug. Or build their MVP. Or maintain their legacy app. That's your CS degree. It's just spread across a dozen small, real engagements instead of four years in one building.

What Didn't Work

Collecting certificates. They're fine as a signal that you sat through material. But nobody has ever hired me because of a certificate. Every real opportunity came from a portfolio piece, a referral, or a conversation where I could clearly explain a decision I made on a past project.

Waiting to feel ready. I never felt ready. The gap between self taught and professional isn't a knowledge threshold you cross. It's a body of shipped work you accumulate. Start billable work earlier than feels comfortable.

Studying algorithms in isolation, disconnected from anything I was building. Data structures and algorithms matter. But grinding them with no applied context is one of the slowest ways to learn them. They stuck a lot better once I hit an actual performance problem that a better data structure solved.

The Real Difference Maker

Nobody on a hiring panel has ever asked me where I studied. They've asked me to walk through a decision on a real project. Why Laravel over a plain PHP framework. Why I chose to denormalize a specific table. How I debugged a flaky third party API integration. A CS degree can hand you vocabulary for those conversations. Shipped, explainable work hands you the actual substance.

If you're self taught and stuck comparing yourself to a traditional path, stop comparing credentials. Start counting shipped, working systems you can talk through in detail. That's the real currency in this field.

Using AI in Your Job Search: What Actually Helps vs What Looks Lazy to Recruiters

Kudzai Murimi — Tue, 25 Aug 2026 06:12:49 +0000

Almost everyone uses AI in their job search now. Whether they admit it or not. The real gap is not between people who use AI and people who don't. It is between people who use it to sharpen their real experience, and people who let it generate a generic version of them. A recruiter can spot that fake version in the first paragraph.

What Actually Helps

Tailoring your CV language to a specific posting. Feed a job description and your real experience to an AI tool. Ask it to flag mismatched terms. Maybe they say "Node.js" and you wrote "backend JavaScript." This is a fast and useful pass. Just make sure you are only adjusting words for experience you already have. Do not invent experience you don't have.

Rehearsing interview answers out loud. Ask an AI tool to play a skeptical interviewer. Let it push back on your answers. This surfaces the gaps in how you explain your own work. Better to find those gaps now than in front of a real interviewer.

Summarizing and organizing your own scattered notes. Maybe you have a messy pile of past projects and metrics and accomplishments. AI is good at helping you turn that into clear, quantified bullet points. The substance is still yours. It just helps you find the clearest way to say it.

Researching a company or role fast. Get a quick organized summary of a company's product, recent news, and likely tech stack before an interview. This saves real time over digging through their blog and LinkedIn by hand.

What Looks Lazy, and Often Is

Sending an unedited generic AI written cover letter. Recruiters read hundreds of these. A cover letter with no specific detail about the company or the role or your actual experience reads as exactly what it is. Usually within the first two sentences. It signals you didn't care enough to personalize it.

Fabricating experience or skills you don't have. AI will happily write confident sentences about a technology you've never touched. The interview will find that gap fast. It damages trust far more than an honest answer would. Something like "I haven't used that specifically, but here's an adjacent thing I have done."

Using AI generated answers word for word in a live interview. Some candidates try to have AI generate answers in real time during interviews. This is against most companies' policies. It also produces answers that don't sound like a real person who did the work. Interviewers notice the gap between a polished answer and someone who can't naturally follow up on it.

Mass applying without reading the posting. AI makes it easy to blast out fifty near identical applications an hour. That is not a strategy. That is noise. It usually gets a worse response rate than fewer, genuinely tailored applications. Generic submissions are the easiest ones for a human or an ATS to filter out.

The Actual Line

AI is genuinely useful anywhere it helps you present your real experience more clearly and faster. It becomes a liability the moment it starts generating experience or opinions or answers that aren't actually yours. Interviews are built to find that gap. Finding it costs you a lot more trust than skipping AI ever would.

The best use of these tools in a job search is not writing your story for you. It is helping you tell your own story faster and more clearly than you could alone.

TrendHub: I Was Tired of Checking Six Sites a Day, So I Built One Feed Instead

Kudzai Murimi — Mon, 24 Aug 2026 13:13:23 +0000

Every morning looked the same for me. dev.to, then Hacker News, then Stack Overflow's hot questions, then Product Hunt, then Lobsters, then Mastodon if I had the energy left. Six tabs. Six different ranking systems. Six different "what's hot right now" signals. No way to tell if the same story was blowing up on more than one of them at once.

So I built TrendHub. It is a single unified feed that pulls what's trending across dev.to, Hacker News, Stack Overflow, Product Hunt, Lobsters, and Mastodon. It ranks everything on one comparable scale. I can read it like one site instead of six.

The problem was never that any one platform was bad. The problem is that trend checking had become a tax on my attention. This is my attempt to get that time back. And to make it something other developers could use too.

What TrendHub Actually Does

At its core, TrendHub is a fetch and rank pipeline. Background jobs pull the latest posts from each source on their own schedule. They normalize each post's engagement signal, reactions, points, votes, favourites, whatever that platform measures, onto a common 0 to 100 trending score. Then everything drops into one feed you can scan in a few minutes.

Features

Unified, ranked feed. Every post from every source lands in one timeline. Sorted by a trending score, not by which tab you happened to open first.

Per platform toggles. Don't care about Product Hunt today? Flip it off in the sidebar. Preferences save per user. Your feed stays exactly the way you like it.

Search, tags, and time range filters. Search matches both post titles and tags. You can restrict the feed to the last day, the last week, or all time.

Cross platform duplicate detection. Sometimes the same story trends on both Hacker News and Lobsters at once. It happens more than you'd think. TrendHub tags it "also trending on" instead of showing it to you twice.

Trending velocity, the rising fire icon. Posts don't just get a static score. They get a velocity indicator based on how their score moved since the last fetch. You can spot what's accelerating, not just what's already popular.

Bookmarks and hide or dismiss. Save something to read later. Hide a post you're not interested in. Hidden posts stay hidden until you choose to bring them back.

Daily digest email. Opt in and get a daily rollup of what's trending sent to your inbox. No login required to stay in the loop.

Personal RSS feed export. Every user gets their own token based RSS URL. Your filtered, ranked feed can slot into whatever feed reader you already use.

Keyboard shortcuts. j and k to navigate. o to open. b to bookmark. x to hide. Built for people who'd rather not touch the mouse.

Dark mode. Because it's a developer tool. Developer tools ship in dark mode.

Per post share menu. Share to X, Facebook, LinkedIn, Reddit, WhatsApp, email, or just copy the link. Straight from the feed.

Source health panel. A small sidebar panel shows the last fetch time and status per platform. You always know how fresh the data is. And if a source's API is having a bad day.

Under the Hood

TrendHub is built on Laravel 10, Inertia.js, Vue 3, and Tailwind CSS. Postgres runs in production. SQLite runs for local development. Each source has its own dedicated fetcher class. A scoring service normalizes engagement metrics across wildly different scales. A Hacker News point is not a Mastodon favourite. A grouping service handles the cross platform duplicate matching.

It's deployed on Render, running as a single web service with a managed Postgres database.

Try It

Live: trend-hub-204c.onrender.com

It runs on a free tier. If it's been quiet for a while, the first load might take 30 to 50 seconds to wake back up. That's not a bug. Just a cold start. Register an account. It's instant, no email verification loop. Toggle platforms on and off to make it yours.

What's the trend checking equivalent of "context switching fatigue" in your own workflow? Do you have a tool for it, or are you still juggling tabs like I was? I'd love to hear what I'm missing.

RTK Query Made Easy for Beginners 🎓 (With Real-Life Analogies)

Kudzai Murimi — Sun, 12 Jul 2026 12:09:21 +0000

If you've ever felt intimidated by Redux Toolkit Query (RTK Query), you're not alone. The docs https://redux-toolkit.js.org/tutorials/rtk-query assume you already know what a "reducer" or "middleware" is — but what if you're brand new to this?

This article explains RTK Query using everyday analogies, so by the end you'll actually understand what's happening instead of just copy-pasting code.

Let's build a tiny app that shows a list of students from a server. 🧑‍🎓

The Big Picture

Imagine our school website asks a server:

"Can I have the list of students?"

And the server replies:

[
  { "id": 1, "name": "John" },
  { "id": 2, "name": "Mary" }
]

RTK Query is the tool that handles that entire conversation for you — asking, waiting, and remembering the answer — so you don't have to write fetch() calls by hand.

Step 1: Project Structure

Here's what our project will look like:

src/
    App.jsx
    main.jsx
    store.js
    services/
        studentApi.js

Think of it like a school: the School is your app, the Classroom is your store, and the Students are your data. Everything has its own place.

Step 2: Install Redux Toolkit

npm install @reduxjs/toolkit react-redux

This gives you RTK Query for free — it's built right into @reduxjs/toolkit.

Step 3: Create the API Service

Create src/services/studentApi.js:

import { createApi, fetchBaseQuery } from "@reduxjs/toolkit/query/react";

export const studentApi = createApi({
  reducerPath: "studentApi",

  baseQuery: fetchBaseQuery({
    baseUrl: "https://jsonplaceholder.typicode.com/",
  }),

  endpoints: (builder) => ({
    getStudents: builder.query({
      query: () => "users",
    }),
  }),
});

export const { useGetStudentsQuery } = studentApi;

Let's break down every part of this, piece by piece.

`createApi` and `fetchBaseQuery`

Think of building a toy car — first you need your tools: a hammer, a screwdriver, a spanner. createApi and fetchBaseQuery are your tools for building an API layer.

`reducerPath`

Think of a cupboard with labelled shelves — one for books, one for toys, one for shoes. reducerPath: "studentApi" tells Redux: store all the student information on the "studentApi" shelf.

`baseQuery`

Imagine your friend lives at 12 Green Street. Every time you visit, you start from that same address. baseQuery works the same way — it's the address every request starts from:

https://jsonplaceholder.typicode.com/

`endpoints`

Think of a restaurant menu: Pizza, Burger, Chicken, Juice — each dish is a menu item. In our app, each endpoint is one thing we can ask the server for: Get Students, Get Teachers, Delete Student, and so on.

`builder.query()`

This means "I only want to READ." It's like asking your teacher, "Can I see today's attendance list?" — you're not changing anything, just looking.

`query: () => "users"`

This tells RTK Query which path to visit. It joins the base URL and this path together:

https://jsonplaceholder.typicode.com/  +  users
=  https://jsonplaceholder.typicode.com/users

That's the actual address it fetches.

Step 4: Add the API to Your Store

Create store.js:

import { configureStore } from "@reduxjs/toolkit";
import { studentApi } from "./services/studentApi";

export const store = configureStore({
  reducer: {
    [studentApi.reducerPath]: studentApi.reducer,
  },

  middleware: (getDefaultMiddleware) =>
    getDefaultMiddleware().concat(studentApi.middleware),
});

Imagine your teacher asks, "Where should I keep the student register?" You say, "Put it in this cupboard." That's the reducer — it decides where the data lives.

Now imagine a school messenger: the teacher says, "Take this letter to Class 4," and the messenger delivers it. That messenger is the middleware — it carries requests to the server and brings the response back.

Step 5: Wrap Your App with Provider

import { Provider } from "react-redux";
import { store } from "./store";

<Provider store={store}>
  <App />
</Provider>;

Think of electricity. Without it, your TV, fridge, and computer don't work. Provider supplies the Redux store to your entire app — without it, nothing connects.

Step 6: Use the Hook

Inside App.jsx:

import { useGetStudentsQuery } from "./services/studentApi";

function App() {
  const { data, isLoading, error } = useGetStudentsQuery();

  console.log(data);

  return <div>Hello</div>;
}

The moment useGetStudentsQuery() runs, RTK Query automatically says "Hello server, can I have the students?" — no fetch(), no axios(). It's all handled for you.

Step 7: Understanding `data`

Imagine asking your mom, "Can I have some apples?" and she hands you a bag of 🍎🍎🍎. That bag is your data.

For our app, console.log(data) might print:

[
  { "id": 1, "name": "Leanne Graham" },
  { "id": 2, "name": "Ervin Howell" }
]

Step 8: Understanding `isLoading`

Imagine ordering pizza. Before it arrives, you're waiting — that's isLoading. While it's on the way, isLoading is true. The moment it arrives, isLoading becomes false.

Step 9: Showing a Loading State

if (isLoading) {
  return <h1>Loading...</h1>;
}

Users see "Loading..." until the server responds.

Step 10: Understanding `error`

If the internet drops or the server fails to respond, error will contain details about what went wrong:

if (error) {
  return <h1>Something went wrong.</h1>;
}

Step 11: Rendering the Students

return (
  <div>
    {data.map((student) => (
      <h2 key={student.id}>{student.name}</h2>
    ))}
  </div>
);

If the server returns John and Mary, the screen shows:

John
Mary

What's Actually Happening Behind the Scenes?

👦 React: I need students.
      ↓
📞 RTK Query: I'll ask the server.
      ↓
🌐 Server: Here are the students.
      ↓
📦 RTK Query: I'll save them.
      ↓
👦 React: Thank you! I'll show them.

You never wrote fetch(). You never managed a loading flag by hand. You never stored the response yourself. RTK Query handled all of it.

One More Superpower: Caching

Imagine your teacher asks, "What's 2 + 2?" You answer "4." A minute later she asks again — you already know the answer, so you don't need to think about it again.

RTK Query behaves the same way:

First time:

React → Server → Data → Saved in cache

Second time:

React → Cache ✅ (no new server request)

This makes your app noticeably faster and cuts down on unnecessary network traffic.

Wrapping Up

That's the entire mental model of RTK Query:

Define your API with createApi
Register it in your store (reducer + middleware)
Provide the store to your app
Consume it with an auto-generated hook
Let it cache so repeat requests are instant

Once this clicks, learning mutations (adding, updating, deleting data) is easy — they follow the exact same pattern, just with builder.mutation() instead of builder.query().

Happy coding! 🚀

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).

DEV Community: Kudzai Murimi

How to Write a Developer CV That Survives ATS and Still Reads Like a Human Wrote It

What the ATS Actually Does

What Makes a Human Want to Talk to You

The Trap

Do This Before Every Application

The Remote Job Search Playbook for Developers Outside the US/EU

The Remote Job Search Playbook for Developers Outside the US/EU

Timezone overlap is a real filter, not a footnote

Sourcing channels that actually produce interviews

What to lead with in your application

The payment/compliance reality

Compensation framing

The uncomfortable truth

Breaking Into Full-Stack Development Without a CS Degree: What Actually Worked for Me

Breaking Into Full Stack Development Without a CS Degree: What Actually Worked for Me

What Worked

What Didn't Work

The Real Difference Maker

Using AI in Your Job Search: What Actually Helps vs What Looks Lazy to Recruiters

What Actually Helps

What Looks Lazy, and Often Is

The Actual Line

TrendHub: I Was Tired of Checking Six Sites a Day, So I Built One Feed Instead

What TrendHub Actually Does

Features

Under the Hood

Try It

RTK Query Made Easy for Beginners 🎓 (With Real-Life Analogies)

The Big Picture

Step 1: Project Structure

Step 2: Install Redux Toolkit

Step 3: Create the API Service

createApi and fetchBaseQuery

reducerPath

baseQuery

endpoints

builder.query()

query: () => "users"

Step 4: Add the API to Your Store

Step 5: Wrap Your App with Provider

Step 6: Use the Hook

Step 7: Understanding data

Step 8: Understanding isLoading

Step 9: Showing a Loading State

Step 10: Understanding error

Step 11: Rendering the Students

What's Actually Happening Behind the Scenes?

One More Superpower: Caching

Wrapping Up

REST vs GraphQL vs tRPC in 2026

The 30-Second Summary

REST: Old But Not Dead

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

tRPC: The Quiet Game-Changer For TypeScript Teams

The Real Answer: Most Production Apps Use All Three

The 60-Second Decision Framework

# 10 VS Code Extensions Every Developer Needs in 2026

1. ESLint — Non-Negotiable

2. Prettier — Just Let It Format Your Code

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

4. Error Lens — Errors Where You Actually Look

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

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

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

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

9. Docker — If Containers Are Part of Your Workflow

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

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

The Rule Behind This List

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

First, Where Things Stand in 2026

What Each Language Actually Does Best

Python: The Language of AI

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

The AI Era Breakdown: What Each Is Actually Used For

Career Paths: Where the Jobs Are

The Honest "Which Should I Learn" Answer

A Thought Before You Decide

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

`createApi` and `fetchBaseQuery`

`reducerPath`

`baseQuery`

`endpoints`

`builder.query()`

`query: () => "users"`

Step 7: Understanding `data`

Step 8: Understanding `isLoading`

Step 10: Understanding `error`