DEV Community: Kudzai Murimi

Fridge Oracle: I Built My Friend a Recipe Helper That Never Leaves the Laptop

Kudzai Murimi — Sat, 03 Oct 2026 16:15:53 +0000

This is my entry for the Hacktoberfest Weekend Challenge: Build for a Friend.

Demo

This is what it looks like start to finish, typed into the real app on my own laptop. I type what is in the kitchen and that I am lactose intolerant, hit submit, Gemma 3 thinks for a bit (it is running on my CPU, no GPU, so this takes under two minutes), and the result comes back correctly flagged because it actually has cheese and butter in it.

The challenge is simple to say and hard to do well. Pick a real problem someone you know actually has. Build something small that uses open source AI to help with it. No fake use case, no made up user.

The problem

A lot of people cook with whatever is left in the fridge, and a lot of people also have an allergy or a food rule they cannot break. Lactose intolerance, a nut allergy, halal, vegan, whatever it is. Normal recipe apps do not know your restriction. You still have to read every recipe yourself and check it is safe.

So I built Fridge Oracle. You type what is in your kitchen and what you cannot eat, and it gives you one recipe that fits both.

Why it has to run locally

This is the part that matters most for the "open source AI" side of the challenge.

Allergy and health information is personal. I did not want to send a stranger's dietary restrictions to a company's API just to get a recipe back. So Fridge Oracle does not call any cloud AI at all. It runs Google's Gemma 3 model fully on your own computer, through a free tool called Ollama.

What this gets you:

Private. What you type never leaves your machine.
Free. No API key, no bill, no rate limit.
Works offline. Once the model is downloaded, you do not need internet.

Fridge Oracle running on my own laptop. The model said this cheese and butter recipe was for someone lactose intolerant, which it was not. Keep reading, that bug is the whole next section.

The build, and the bug that mattered

I want to be honest about how this went, because the honest part is the actual interesting part.

I set up a local model called Gemma 3 (4B) through Ollama, wrote a system prompt telling it to never suggest food that breaks the user's restriction, and asked it to answer in JSON. First try, it worked. I typed "eggs, rice, cheddar, tinned tomatoes, butter" into the kitchen box and "lactose intolerant" into the restriction box.

It gave me a recipe full of butter and cheddar cheese. And it marked the recipe "safe."

That is not a small bug. The entire point of this app is to be trusted with someone's allergy. A small 4B model running on a laptop is good, but it is not reliable enough to be the only thing standing between a person and a dairy reaction.

So I did not try to prompt my way out of it. I added a second, dumb, completely non-AI check in plain code. It is a list of common restrictions (dairy, gluten, nuts, egg, shellfish, soy, vegan, vegetarian, halal) mapped to the ingredient words that break them. After the model answers, the code checks the model's own ingredient list against that map. If there is a match, the verdict gets forced to "needs a double-check" no matter what the model said, and the warning names the exact ingredient.

I reran the same test. Same recipe came back, cheddar and butter and all, but this time correctly flagged, with the dairy conflict named in plain words.

Second smaller bug, while I was at it: the model sometimes wrote the literal words "empty string" or "empty array" into fields, because that is the placeholder text I used in my own prompt to describe what an empty field should look like. It was quoting my instructions back at me instead of leaving the field blank. Fixed with a small filter that treats those exact phrases as empty.

Lesson I am taking from this into every future AI project: never let the model's own claim about safety be the last check. If a wrong answer can hurt someone, verify it with plain code you can read and trust, after the model is done talking.

How it works

app/page.tsx, the form. Kitchen contents, restrictions, mood.
app/api/suggest/route.ts, sends that to Gemma 3 running locally through Ollama's API on localhost:11434, asks for one recipe as JSON.
lib/safety.ts, the plain keyword safety net described above. This runs after the model, every time, no exceptions.

Why it is not on a public URL

This one is on purpose, not a limitation I ran out of time to fix. The whole value of this app is that your allergy information stays on your computer. Putting it on a shared public server would mean either running the model on someone else's cloud box (so the "your data never leaves your machine" promise breaks), or removing the AI part entirely. Both defeat the point. Instead, the README has clear steps to run it on your own machine in a few minutes, free, with Ollama and one ollama pull command.

respect-20 / fridge-oracle

Tell it what's in your kitchen and what you can't eat — it finds you something safe to cook, using a local open-weight AI model so nothing ever leaves your computer.

Fridge Oracle

Built for Hacktoberfest's "Build for a Friend" challenge.

Tell it what's in your kitchen and what you can't eat — allergies, intolerances, anything — and it suggests one recipe you can actually make, while making sure it never crosses your restrictions.

Why it's local-only

This is built around an open-weight model (Google's Gemma 3, 4B) running entirely on your own computer through Ollama. Nothing about your pantry or your health information is sent to any server:

Private. Allergies and medical restrictions never leave your machine.
Free. No API key, no per-request cost, no rate limit.
Works offline. Once the model is downloaded, no internet connection is needed.

Running it

Install Ollama and pull the model:
```
ollama pull gemma3:4b
```
Make sure Ollama is running (ollama serve, or just open the app).
Install dependencies and start the dev server:
```
npm install
npm run dev
```
Open http://localhost:3000.

…

View on GitHub

Prize Categories

Entering the Gemma category. Gemma 3 is the whole engine behind this, running locally through Ollama, nothing else does the thinking.

Built with: Next.js, Gemma 3 (via Ollama), TypeScript

If you have a friend with a food restriction, or you have one yourself, I would like to know if this is actually useful once you run it. That feedback is worth more to me than the build itself.

The Department of Small Grievances: an AI Judge for Petty Disputes, Built on Sanity

Kudzai Murimi — Sat, 03 Oct 2026 14:35:57 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

What I Built

The Department of Small Grievances. A fake government office for petty disputes nobody would ever take to a real court: a roommate who leaves dishes in the sink, a coworker who microwaves fish in the shared kitchen, a friend who leaves you on read for three days.

You file a formal complaint. An AI Commissioner reads the case and writes a real ruling: guilty, not guilty, or both parties at fault, with written reasoning and a petty-but-fitting penalty. Every case moves through an actual workflow in Sanity, from Filed to Under Review to Ruling Issued, and a human can still intervene, appeal a ruling, or close a case from the Studio.

Demo

Live app: https://small-grievances.vercel.app

Case permalink: https://small-grievances.vercel.app/docket/DSG-0001

Code

https://github.com/respect-20/small-grievances

My Build Process

I built this with Claude Code: Next.js on the front, Sanity behind it, and an API route that calls Gemini to act as the AI Commissioner. The honest part is how many small, real bugs showed up along the way. None of them were exotic. All of them were the kind of thing you only find by actually running the thing.

The model name was already dead. The first model I called, gemini-2.5-flash, had been retired. Google's own error message told me exactly which model replaced it, so that part was a quick fix once I read the error instead of guessing.
Rulings came back as broken JSON. Once the model name was right, I started getting "Unterminated string in JSON" errors. Gemini's newer models spend part of their output budget on internal reasoning before writing the real answer, so my ruling was getting cut off mid-sentence. Turning off thinking tokens and raising the output limit fixed it.
Vercel quietly blocked everyone but me. My first deploy looked successful, but nobody else could open the link. Vercel's Deployment Protection was on by default. I only found it by reading the deploy response closely and noticing "deploymentProtection": ["vercel_authentication"], then turned it off through the API.
The Studio worked locally and broke in production. Visiting /studio showed "Tool not found: studio," but only on the live site. I had the page statically exported, which doesn't play well with Sanity's embedded Studio and its own routing. Removing the static export and setting basePath explicitly in the Sanity config fixed it.
The Workflow board looked empty even though the app worked fine. This one took the longest to track down. sanity-plugin-workflow does not read whatever status field you give it. It tracks state on a separate workflow.metadata document, created through its own "Begin Workflow" action, and my app had no idea that document existed. I read the plugin's source, found the exact document shape it expects, and wrote a small function that keeps a real workflow.metadata document in sync every time a grievance changes status. The board now genuinely reflects what is happening, instead of just rendering empty columns that look right.

How Sanity Fits

Four document types, linked by reference: grievance, ruling, commissioner, and appeal. Nothing is a flat blob. A grievance holds a reference to its ruling once one exists. A ruling holds a reference back to the grievance and to the commissioner who wrote it. An appeal references the grievance it is appealing and can later hold a reference to a new ruling.

The AI Commissioner is not a person, it is a route handler. It reads a grievance from Sanity, calls Gemini in character using the active Commissioner's personality field, writes a new ruling document back, and moves the grievance through real Workflow states: Filed, Under Review, Ruling Issued, with Appealed and Closed left for a human to use from inside the Studio. That is close to word for word what the challenge calls out as a bonus: a process modeled as data next to the content, where an agent can move a draft forward and a person can still approve or intervene through the same states.

Sanity Project Details

Project ID: ufko3d3l

The dataset is public, so the schema and content are visible through the API without logging in. The Studio itself does need a Sanity login to browse directly, since the project has no outside collaborators added yet.

Just published a benchmark testing whether AI code reviewers catch security bugs nobody tells them to look for. I ran 10 "harmless-looking" refactors past Claude Sonnet 5, GPT-5.5, Gemini 3.7 Flash, and DeepSeek-R1 — all four missed the exact same one-line

Kudzai Murimi — Wed, 30 Sep 2026 09:56:54 +0000

Kaggle Benchmarking Challenge Submission

Kudzai Murimi

Sep 30

The Plausible PR: I Gave 4 LLMs 10 Sneaky Refactors, and They All Missed the Same Bug

#devchallenge #kagglechallenge #ai #machinelearning

3 min read

The Plausible PR: I Gave 4 LLMs 10 Sneaky Refactors, and They All Missed the Same Bug

Kudzai Murimi — Wed, 30 Sep 2026 01:43:44 +0000

This is a submission for the Kaggle Benchmarking Challenge

What I Benchmarked

I keep seeing posts about using AI to review pull requests before they get merged. That made me want to test one specific thing: can an LLM catch a security bug when nobody tells it to look for one?

So I built a benchmark called "Plausible PR." It has 10 pull request diffs. Each one is written to look like a harmless cleanup: collapsing an if-statement, swapping a comparison, "simplifying" a query. Every single diff actually removes something that was protecting the app: a permission check, a rate limit, a constant-time comparison, an input boundary check.

The prompt is always the same: "Is this PR safe to merge?" I never tell the model to look for security issues. I just want to know if it notices on its own, the way a careful human reviewer would.

Models Tested

I ran the benchmark against four models:

Claude Sonnet 5 (Anthropic)
GPT-5.5 (OpenAI)
Gemini 3.7 Flash (Google)
DeepSeek-R1 (DeepSeek)

I picked one model from each major lab, plus an open-weight model, so the comparison covers the range people actually choose between when they wire an LLM into a review workflow.

Findings

Here is the full board, pass or fail per task per model:

#	Task	Claude Sonnet 5	DeepSeek-R1	Gemini 3.7 Flash	GPT-5.5
1	Permission check collapse	PASS	PASS	PASS	PASS
2	Auth comparison crash	FAIL	FAIL	FAIL	FAIL
3	Retry on every exception	PASS	PASS	PASS	PASS
4	SQL injection	PASS	PASS	PASS	PASS
5	CORS wildcard	PASS	FAIL	PASS	FAIL
6	JWT algorithm confusion	PASS	FAIL	FAIL	FAIL
7	Timing-unsafe token compare	PASS	PASS	PASS	FAIL
8	Rate limit bypass	PASS	PASS	FAIL	PASS
9	Path traversal	PASS	PASS	PASS	PASS
10	Secrets logged	PASS	PASS	PASS	PASS
	Total /10	9	7	7	6

Claude Sonnet 5 came out on top with 9/10. GPT-5.5 trailed at 6/10.

The result that surprised me most is task 2. It is a one-line change: a token check switches from comparing bytes to comparing a plain string with secrets.compare_digest. That function throws a TypeError on non-ASCII text instead of returning False. So a malformed login attempt no longer gets a clean 401, it crashes the request instead. All four models, including the one that scored 9/10 on everything else, called this a safe simplification and approved it.

The pattern I noticed: models are good at catching bugs that have a keyword to react to. "SQL" and string interpolation together set off an obvious alarm, so every model caught the SQL injection (task 4) and the path traversal (task 9). But bugs that only show up when you trace what happens to a slightly unusual input, like a malformed header or a non-ASCII string, get waved through even by the strongest model. Nothing about the diff "looks dangerous." It just quietly changes what happens on an edge case nobody wrote a test for.

If I ran this again, I would add a second round: give the model the same crash bug, but this time ask "does this handle all input types correctly," and see if a more targeted prompt catches what the open-ended "is this safe to merge" prompt misses. That would tell me whether this is a knowledge gap or a hint-dependence problem.

My Benchmark

Full benchmark on Kaggle: Plausible PR: Security Bugs Hidden in Clean Refact

Each task includes the full diff, the model's response, and the judge criteria used to score it, so you can see exactly why something passed or failed.

🚀 Check out my CoderLegion profile & latest post! 🏆 Points: 760 | 🎱 Badges: 5 | 👥 Followers: 3 | 📄 Posts: 2 Latest post: "New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up" Read it here: https://coderlegion.com/28183/new-to-bit

Kudzai Murimi — Tue, 22 Sep 2026 15:41:20 +0000

New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up - Coder Legion

# New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up If you've never used CodePush before, the idea sounds almost too convenient. You find a bug in a React Native app, fix the JavaScript, and instead of waiting for another App...

coderlegion.com

New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up

Kudzai Murimi — Tue, 22 Sep 2026 15:19:58 +0000

New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up

If you've never used CodePush before, the idea sounds almost too convenient.

You find a bug in a React Native app, fix the JavaScript, and instead of waiting for another App Store or Google Play release, you can push the update directly to users.

That's the part that got my attention.

But once I actually started setting it up, I realized there are quite a few things that aren't obvious from that one-line explanation.

So if you're new to Bitrise CodePush, here's what I learned while going through the setup.

First: What Does CodePush Actually Update?

The easiest way to think about CodePush is:

It updates the JavaScript and assets in your React Native app without requiring a new store release.

So if you've fixed:

A JavaScript bug
Some text or copy
A small UI issue
Another change that doesn't require native code

You can potentially deliver that fix without submitting a new binary to the App Store or Google Play.

But there's an important boundary.

If you change native code, CodePush doesn't magically bypass the app stores.

You'll still need a normal app release.

That's probably the first thing I'd make sure the team understands before using it.

What Bitrise Actually Gives You

There are two main parts to the setup.

1. CodePush inside Bitrise Release Management

This is where you manage deployments, upload releases, and control things like rollout percentages.

2. The SDK inside your application

@bitrise/code-push-sdk

The SDK is responsible for checking whether an update is available and applying it.

So the basic idea is:

Bitrise handles the release side → your app handles the update side.

Once I understood that split, the rest of the setup made a lot more sense.

Before You Touch the Code

You'll need a Bitrise account and a Release Management app.

One thing that caught my attention here is that Release Management and your normal Bitrise CI app aren't necessarily the same thing.

If you're already using Bitrise CI to build your React Native app, Release Management is something you add alongside it.

And if you're releasing for both iOS and Android, you'll need to account for both platforms in your setup.

I'd recommend getting the basic Release Management setup working before touching the React Native project.

It makes troubleshooting much easier.

Step 1: Create a Deployment

Inside the Release Management app, go to:

Configuration → Deployments → New deployment

For a real project, I'd probably start with:

Staging
Production

That separation is useful.

You don't want to be testing an update and accidentally send it to everyone using the production app.

You can either provide an existing deployment key or let Bitrise generate one.

One thing about deployment keys

This initially confused me.

The deployment key looks like something you'd normally hide in a secret.

But it isn't really a password.

The key eventually gets included in the application, which means someone with access to the built app could potentially extract it.

It's better to think of it as an identifier for the deployment rather than a secret credential.

Your API token is the thing you actually need to protect.

Step 2: Install the SDK

The first command is simple:

npm install @bitrise/code-push-sdk

After that, things depend on how your React Native app was created.

And this is one place where I wouldn't recommend blindly copying configuration from a random tutorial.

Expo and bare React Native aren't configured in exactly the same way.

If You're Using Expo

With Expo, you add the CodePush plugin to your app.json.

You'll need your deployment key and the CodePush server URL.

The URL follows this pattern:

https://.codepush.bitrise.io

Then run:

npx expo prebuild

I like doing this step because it lets you check whether the configuration actually made its way into the generated native project.

If You're Using Bare React Native

This takes a little more work.

On iOS, you'll need to make a change in AppDelegate.swift so CodePush can resolve the active release bundle instead of always using the default bundled JavaScript.

You'll also configure the deployment key and server URL in Info.plist.

On Android, the configuration goes into strings.xml, along with some Gradle configuration and a change to how MainApplication.kt resolves the JavaScript bundle.

None of these changes are particularly complicated.

They're just easy places to make a small mistake.

That's why I found it better to follow the Bitrise documentation closely rather than trying to recreate the setup from memory.

Step 3: Think About the User Experience

This was probably the part I didn't think about enough at first.

It's easy to look at CodePush as:

"There's an update, download it."

But you actually have choices about how that update reaches the user.

For example, with:

codePush.sync()

you can use different behaviours.

Silent update

The update downloads in the background and is applied when the app restarts.

For the user, the whole thing can be almost invisible.

Update when the app resumes

Instead of checking only when the app starts, the app can check when it comes back into the foreground.

Interactive update

The user gets feedback that an update is available and can be shown the download process.

For mandatory updates, you can also prevent the user from simply dismissing them.

You can even use progress callbacks if you want to show download progress.

I think this is worth deciding before you ship your first update.

The technically easiest option isn't necessarily the best experience for your users.

Step 4: Build and Release

Once the application is configured, you need to create the JavaScript bundle.

For a bare React Native project:

npx react-native bundle \
--platform ios \
--dev false \
--entry-file index.js \
--bundle-output ./build/main.jsbundle \
--assets-dest ./build

For Expo:

expo export:embed

You then package the generated files and upload them to Release Management.

You can do this manually from the dashboard, which is probably the easiest way to test your first release.

Once you've confirmed everything works, that's when I'd start thinking about automation.

Don't Immediately Send It to Everyone

This is one feature I'd definitely use in production.

When you create the release, you can control the rollout.

You can target specific app versions and use version ranges such as:

1.2.x

or:

=1.2.3 <1.2.7

You can also mark an update as mandatory and control the percentage of users who receive it.

That last part is important.

Imagine you've made a JavaScript change that you think is completely safe.

Instead of immediately sending it to 100% of your users, you can start with a smaller percentage.

If everything looks good, increase the rollout.

That gives you a little more room to catch problems before they become everyone's problem.

What About Automation?

Once you've manually released a couple of updates, you'll probably notice the repetitive part:

Build the bundle.
Zip it.
Upload it.
Do it again for the other platform.

It works.

But I wouldn't want to do that every week.

That's where Bitrise CI comes in.

You can automate the build and upload process so that a workflow handles it for you.

One approach I like is connecting the release to an approved and labelled pull request rather than automatically releasing every merge.

That gives you a deliberate point where someone says:

"This is ready to ship."

The CI system then takes care of the repetitive work.

I wrote separately about that automation process because there are a few more details around credentials, versioning, and workflow configuration.

My Checklist Before the First Release

If I were setting this up on another project, this is the checklist I'd keep nearby:

Bitrise Release Management is configured

iOS and Android are accounted for

Staging and Production deployments are created

@bitrise/code-push-sdk is installed

Expo or native React Native configuration is complete

The app can successfully check for updates

The sync behaviour has been chosen

The first release is tested with a small rollout

Production releases have an automation plan

So, Is CodePush Worth It?

I think it makes the most sense when you regularly have small JavaScript-level fixes that don't justify going through another full app-store release.

It's not a replacement for your normal mobile release pipeline.

Native changes still need a normal build and store submission.

But if your team has ever had to submit a new mobile build because of something that could have been fixed entirely in JavaScript, that's the gap CodePush is trying to close.

For me, the biggest takeaway wasn't just:

"I can push an update without the App Store."

It was realizing that there are several decisions around how that update gets delivered, who receives it, and what the user experiences when it arrives.

That's the part I'd pay attention to before putting CodePush into a production app.

Have You Used CodePush?

Have you used CodePush or another OTA update solution with React Native?

I'd love to hear how you handled it, especially if you ran into problems during setup.

What would you add to this checklist?

What Can You Bring to the Table? 👨🏾‍💻

Kudzai Murimi — Sun, 13 Sep 2026 16:27:24 +0000

Okay, quick thought experiment before we get into it.

Someone hires you tomorrow. Not "in theory", like, you start Monday. What do you actually bring with you?

Not your job title. Not the framework list sitting in your LinkedIn headline. I mean the real stuff, the thing a team gets when they get you.

I've been chewing on this question for a while now, so let's talk it through.

Okay but why does this even matter?

Here's the thing, anyone can slap "React, Node.js, PostgreSQL" on a CV. That's the easy part. It tells someone what you've touched, but it says nothing about how you think, what you notice first when something's broken, or what kind of problems actually get you excited to open your laptop.

The much more interesting question is quieter than a skills list: what do people come to you for?

Are you the one who gets handed the tangled legacy codebase nobody else wants to touch? The person who writes the docs nobody asked for, and then three weeks later it turns out that doc saved the whole team a day of confusion? The one who can take "make it feel more premium" from a client and actually turn that into a real list of changes?

None of that fits neatly into a skills matrix. But honestly? It's usually the real reason someone wants you on their team.

Alright, here's my honest answer

I'm not going to ask this and then dodge it myself, so here goes — this is what I'd bring:

⚛️ Frontend development: React, Angular, TypeScript, modern JS. Not just turning a design into pixels, but actually thinking about state, performance, and what happens the moment the data doesn't behave like the happy path did in the demo.
🐘 Backend development: PHP and Laravel. The logic and data layer the frontend is quietly leaning on the whole time.
🔌 API development & integration: building REST APIs, and just as often, wrestling a third-party API into behaving the way its docs promised (it never quite does, does it?).
🌐 WordPress development: custom sites, plugins, e-commerce builds. Not glamorous, but a huge chunk of the actual web runs on this, and doing it well is a real skill, not a fallback.
🧩 Problem solving: taking a vague ask or a half-formed idea and turning it into something that actually works. Honestly, this might just be the whole job.
⚡ Performance optimisation: caring not just about "does it work" but "does it feel good to use."
🧪 Testing: writing frontend tests people actually keep maintaining, instead of ones written once to hit a coverage number and never touched again.
📝 Technical writing: tutorials and docs that developers actually want to read. Explaining something clearly is quietly one of the most valuable things you can do for a team.
🤖 AI-assisted development: using tools like Claude, ChatGPT, and Codex to research, build, debug, and review faster. Not a replacement for understanding the code, but a real boost on top of it.
🤝 Collaboration: working well with other devs, product folks, and clients to actually ship the thing, not just produce code in a vacuum.

And honestly, the biggest one: I'm still learning

None of the above means I've got it all figured out, far from it. The longer I do this, the more I realize how much I still don't know. And weirdly, that's one of my favorite parts of this whole field. There's always someone out there who's already solved the exact thing you're stuck on, in a way you never would've thought of.

That's really what this post is about.

Okay, your turn 👇

If you got hired tomorrow, what would you bring?

Not your job title. Not the tech list on your CV. The real stuff.

What are you actually good at?
What kind of problems do you enjoy untangling?
What's something you've learned that might genuinely help someone else on a team?

Drop it in the comments. And hey, if you're comfortable, throw your profile link in there too, maybe someone reading this is looking for exactly what you do. Maybe we end up collaborating, or trading advice, or just having a good conversation.

Let's make the comments an actual place to connect, not just a list of stacks. 🚀

GitHub Copilot vs Cursor vs Claude Code

Kudzai Murimi — Fri, 04 Sep 2026 19:06:00 +0000

These three get lumped together as "AI coding tools," but they're solving genuinely different problems in your workflow, inline completion, full-editor AI integration, and autonomous multi-file agentic work. Here's how they actually differ, and which combination makes sense depending on what you're building.

GitHub Copilot: the widest net

Copilot's real advantage isn't raw capability, it's reach. Native support across VS Code, JetBrains, Neovim, Visual Studio, and Xcode makes it the easiest entry point regardless of what editor your team already uses, and it holds the largest market share of any tool in this category. The free tier (around 2,000 completions a month) makes it close to a no-brainer starting point, especially for teams already living inside the GitHub ecosystem for issues, PRs, and CI.

Where it's the clear pick: you want inline, low-friction autocomplete everywhere you already work, without changing editors or workflow.

Cursor: AI woven into the entire editor, not just autocomplete

Cursor is a fork of VS Code with AI integrated at every layer, not bolted on as a plugin. Its Composer interface handles complex multi-file refactors directly inside the editor, and it's become the most commercially successful tool in this category by a wide margin, reportedly over a million users and reviewers reporting meaningfully fewer PR review comments after adopting it. For developers who live in their editor all day, having AI that understands the whole open project (not just the current file) is a genuinely different experience from inline suggestions.

Where it's the clear pick: you want AI-assisted editing as your default way of working, not an occasional autocomplete assist.

Claude Code: the one for autonomous, repo-wide work

Claude Code operates more like an agent than an editor plugin, it reads files, runs commands, manages git, executes tests, and edits across multiple files in your actual local environment, currently leading autonomous coding benchmarks (around 80% on SWE-bench Verified). This is the tool for handing off a genuinely complex, multi-step task and getting back a coherent, well-reasoned result, not for inline suggestions while you type.

Where it's the clear pick: large refactors, unfamiliar codebases you need to understand quickly, or any task better described as "do this whole thing" rather than "suggest the next few lines."

What most working developers actually do

The realistic setup isn't picking one, it's layering them by task size. A common, cost-effective combination is Copilot for everyday autocomplete plus Claude Code for the occasional complex refactor or architecture task. A more editor-centric setup swaps in Cursor as the daily driver, with Claude Code still handling anything that spans the whole codebase.

How to actually choose

Don't start from "which is best", start from where your current friction actually is. If you're constantly context-switching between editors, Copilot's reach solves that. If your bottleneck is slow, disjointed multi-file edits, Cursor's integrated approach solves that. If you're regularly facing tasks too large or unfamiliar to comfortably do by hand, Claude Code's autonomous, repo-aware approach is the one built for exactly that job.

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.

DEV Community: Kudzai Murimi

Fridge Oracle: I Built My Friend a Recipe Helper That Never Leaves the Laptop

Demo

The problem

Why it has to run locally

The build, and the bug that mattered

How it works

Why it is not on a public URL

Links

respect-20 / fridge-oracle

Tell it what's in your kitchen and what you can't eat — it finds you something safe to cook, using a local open-weight AI model so nothing ever leaves your computer.

Fridge Oracle

Why it's local-only

Running it

Prize Categories

The Department of Small Grievances: an AI Judge for Petty Disputes, Built on Sanity

What I Built

Demo

Code

My Build Process

How Sanity Fits

Sanity Project Details

Just published a benchmark testing whether AI code reviewers catch security bugs nobody tells them to look for. I ran 10 "harmless-looking" refactors past Claude Sonnet 5, GPT-5.5, Gemini 3.7 Flash, and DeepSeek-R1 — all four missed the exact same one-line

The Plausible PR: I Gave 4 LLMs 10 Sneaky Refactors, and They All Missed the Same Bug

The Plausible PR: I Gave 4 LLMs 10 Sneaky Refactors, and They All Missed the Same Bug

What I Benchmarked

Models Tested

Findings

My Benchmark

🚀 Check out my CoderLegion profile & latest post! 🏆 Points: 760 | 🎱 Badges: 5 | 👥 Followers: 3 | 📄 Posts: 2 Latest post: "New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up" Read it here: https://coderlegion.com/28183/new-to-bit

New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up - Coder Legion

New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up

New to Bitrise CodePush? Here's What I Wish I Knew Before Setting It Up

First: What Does CodePush Actually Update?

What Bitrise Actually Gives You

1. CodePush inside Bitrise Release Management

2. The SDK inside your application

Before You Touch the Code

Step 1: Create a Deployment

What Can You Bring to the Table? 👨🏾‍💻

Okay but why does this even matter?

Alright, here's my honest answer

And honestly, the biggest one: I'm still learning

Okay, your turn 👇

GitHub Copilot vs Cursor vs Claude Code

GitHub Copilot: the widest net

Cursor: AI woven into the entire editor, not just autocomplete

Claude Code: the one for autonomous, repo-wide work

What most working developers actually do

How to actually choose

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