Forem: Mohamed Abdallah

Claude rewrote my resume and I couldn’t send it, so I built unslop.

Mohamed Abdallah — Thu, 30 Apr 2026 00:27:51 +0000

I built unslop because Claude rewrote my resume and I couldn't send it

I was updating my CV. New experience, new role, the usual. I'd written it myself a few years back. I asked Claude to update the wording with my latest projects.

I read the output. It was AI.

You know the feeling. You read a paragraph, and the first thing your brain says is this is written with AI. It doesn't matter how careful the person was. It doesn't matter that they reviewed every line. The moment the reader thinks "AI", the work gets discounted before they finish the sentence. The effort doesn't transfer.

I'm a developer. I'm not the best at writing in English. I never was. Email, PR comments, Jira tickets — I lean on AI to help me get the wording right because prose isn't the part of the job I'm good at. That was the deal AI was supposed to give me. Help the engineers who can't write.

The deal is broken. Because the output reads as AI. And the moment your reader thinks "AI", everything you wrote loses weight.

There’s a paper on this. Liang et al., 2023 (arXiv:2304.02819). They ran AI detectors against essays written by non-native English speakers and against essays written by US 8th-graders. The detectors consistently flagged the non-native writing as AI. The native writing went through clean. So the tool meant to level the field for ESL writers is actively penalizing them. AI for everyone, except the people who need it most.

That's the detector side. But the same fingerprint that triggers a detector triggers a human reader. We've all gotten good at this. Em dashes everywhere. "It's worth noting that." "Delve." Sycophancy openers. Hedging stacks. Tricolons stacked three deep. You see one or two of them and the brain switches modes.

So I took it on myself. Not pay $9.99 a month for some "AI humanizer" SaaS site. Build something open-source that runs in my terminal, in my editor, inside my Claude Code session. And actually have it work.

I called it unslop.

pip install unslop

Repo: github.com/MohamedAbdallah-14/unslop

What it actually does

I read 38 papers to build this

The full reading list is in docs/RESEARCH_AND_TECH.md. Five things I learned that ended up in the code:

Warmth and reliability trade off. Ibrahim et al. (arXiv:2507.21919, 2025) trained models to be warmer and more empathetic. The result: error rates went up by 10–30 percentage points across safety-critical tasks. Warm-trained models were significantly more likely to validate the user’s incorrect beliefs, especially when the user sounded sad. So the “be friendlier” finetuning isn’t neutral. It’s making the output less reliable. unslop subtracts. It never adds.
Sycophancy is the loudest tell. SycEval (arXiv:2502.08177) measured sycophantic agreement in 58.19% of cases across ChatGPT-4o, Claude-Sonnet, and Gemini-1.5-Pro. Gemini was worst at 62.47%, ChatGPT best at 56.71%. None of them under 50%. The first thing readers notice. The first thing unslop strips.
Detectors read variance, not vocabulary. DivEye (TMLR 2026) shows modern detectors look at intra-document surprisal variance. Even if you swap synonyms, the variance fingerprint persists. So the rewrite has to engineer burstiness — mix sentence lengths across the paragraph — not just swap words.
Verbal uncertainty beats numeric confidence. Tao et al. (arXiv:2505.23854, 2025) found that linguistic verbal uncertainty (“I think”, “probably”, “seems”) consistently outperforms token-probability and numeric-confidence methods on both calibration and discrimination. So unslop preserves real uncertainty in human form, not as confidence intervals.
Voice imitation is harder than it looks. EMNLP 2025 Findings (arXiv:2509.14543) tested LLMs on imitating personal writing styles. They can approximate structured formats like news and email. They struggle on the nuanced, informal voice you’d find in blogs or forums. unslop’s voice-match mode is honest about being a best-effort approximation, not a clone.

There are 33 more papers and they all shaped a specific decision in the code. The point isn't to flex the bibliography. The point is that the standard "make AI sound human" advice you find online — add emoji, add warmth, add filler — is the opposite of what the research says works.

You subtract. You don't add.

Who this is for

If you're a developer who uses LLMs for emails, tickets, PR descriptions, comments — and you've felt that twinge when the output reads as AI — this is for you.

If you're an ESL writer who's tired of having your writing flagged as AI by detectors that can't tell the difference between you and a chatbot.

If you ship a lot of prose with Claude Code and you don't want every response to start with "Great question!"

If you want to humanize your output without paying $9.99/month to a SaaS site that's a worse wrapper around the same models you're already paying for.

The honest close

It's 2 AM as I'm finishing this post. I'm a solo developer with no following. There's a real chance this dies on the graveyard of GitHub. There's another chance it takes years to be known.

I checked the repo this morning. Three people starred it yesterday. That made my week.

That made my week.

If you read this far and any part of it landed, here's the ask:

pip install unslop

Star the repo: github.com/MohamedAbdallah-14/unslop

If it helps you, tell one person.

That's the whole pitch.

When "no AI in the calculation" is a feature, not a bug

Mohamed Abdallah — Sun, 26 Apr 2026 22:56:39 +0000

I work on an estimation engine where the same input always produces the same output. In 2026 that's apparently a controversial design choice.

Every other tool in the demo deck has a sparkle icon now. The investor slide that doesn't say "AI-powered" feels like it was printed in 2019 and forgotten. So when a B2B platform's pitch says, in plain text, "the calculation contains no AI" — people stop and ask if that's a typo.

It isn't. It's the product.

The thing the engine does

Let me describe the shape without describing the brand. It's a deterministic software-estimation platform I work on with a client. You feed it a structured project description — features, integrations, target platforms, team composition assumptions, a long list of normalized inputs. It returns a number: hours, cost, range. That number lands in a contract. A buyer signs it. A vendor delivers against it. If the estimate is wrong by 40%, somebody loses money.

The engine that produces that number is a few thousand lines of TypeScript. Eighty-something modules. Rules, weights, lookups, modifiers. No model call anywhere in the calculation path. Same inputs in, same number out. Today, tomorrow, next March.

When I describe this to other engineers in 2026, the second question is always: "Why not put an LLM in there? It would handle the edge cases."

It would. That's the problem.

Trust is not vibes

A contract estimate is a number two parties stake real money on. The buyer wants to know what they're paying for. The vendor wants to know what they can deliver. Both want to know the number didn't move because somebody refreshed the page.

If I run the same estimate twice and get 312 hours then 287 hours, I haven't estimated anything. I've sampled from a distribution and presented the sample as a fact. That's a category error. Estimation implies a method. A method implies repeatability. Without repeatability, "estimate" is just a confident-sounding guess in a nice UI.

LLMs sample from distributions. That's their whole architecture. You can pin temperature to zero, but you're still at the mercy of model updates, context formatting, token boundaries, and the silent retraining the vendor pushes on a Tuesday. I've seen the same prompt return materially different answers across a model version bump. In a chatbot, that's a quirk. In a contract, it's malpractice.

Audit is the killer requirement

Estimates get re-litigated. Always. A project goes 30% over. The buyer wants to know why. The vendor wants to know if scope crept or if the original number was wrong. Somebody — usually a project manager who was not in the original conversation — has to reconstruct how the number got built.

With a rule-based engine, that reconstruction is mechanical. You open the calculation log. You see which modules fired, which inputs they consumed, which weights applied. You point at the line that says "multi-tenancy modifier: +18%" and you have a conversation about whether that modifier was correct. The disagreement is bounded.

With an LLM in the path, the audit trail is "the model decided." You can ask it to explain itself, and it will, in fluent English that may or may not reflect what actually drove the output. There's no causal trace from input to output that a human can verify. The model's "reasoning" is a post-hoc story it told itself to keep the conversation going.

This is fine for "summarize this article." It is not fine for a number on a procurement contract. The deeper issue is liability. When the engine is deterministic, the vendor can defend the estimate by walking through the rules. When it isn't, the defense is "trust the AI" — which a lawyer will eat alive.

Reproducibility, plainly

I'll say it the blunt way. An estimator that gives different answers to the same input is not estimating. It's hallucinating with confidence. The fact that the hallucinations cluster around a plausible value most of the time makes it worse, not better, because it lets the failure mode hide.

Determinism here isn't a nostalgia thing. It's a contract with the user that says: if you change the answer, you changed an input. If you didn't change an input, the answer is the same. That contract is what makes the tool a tool and not an oracle.

Where AI actually earns its keep

I'm not anti-AI here. The MCP image-generation server I run in production sits one repo over from this argument. I'm not arguing for a museum.

The argument is about placement. There are three spots in this product where AI does real work and nobody objects:

Input parsing. Customers describe projects in prose. "We need a Flutter app with iOS and Android, two user roles, payment via Stripe, and a moderator dashboard." A model is great at turning that into the structured input the engine expects — feature flags, platform targets, role count, integrations. If it gets it wrong, the user sees the structured form and corrects it before hitting calculate. The AI's output is a draft for a human to confirm.

Similar-project retrieval. Given a finished estimate, an embedding lookup over past projects ("here are five engagements with similar shape and scope; here's how they actually came in") is genuinely useful. It contextualizes the deterministic number without replacing it.

Explanation drafting. The engine outputs the number and a structured rationale. A model turns that rationale into a paragraph the buyer can read. The number doesn't move. The prose around it does.

Notice the pattern. AI sits at the interface between human language and structured data, in both directions. It does not sit in the calculation. The calculation is where the math has to be defensible.

The rule, generalized

Here's the rule I've started applying to every product decision involving AI:

AI fits at the human-interface layer. AI breaks anywhere the output needs to be defensible later.

If the output of a step is going to a human who will look at it and decide what to do — translation, summarization, drafting, suggestion, classification with a human-in-the-loop — AI is often the right tool. Slightly different output each time is fine, because the human is the error-correction layer.

If the output of a step is going to feed into another deterministic process, or into a contract, or into a regulated decision, or into something a court or an auditor or a finance team will examine in twelve months — AI is the wrong tool. You need a function. Functions are repeatable. Models are not.

Most products today are picking the wrong layer. They put a model in the calculation path because that's where the magic-feeling happens, then bolt deterministic guardrails around it to clean up the mess. The order is backwards. The deterministic core should be the product. The model should be the helpful assistant standing next to it, translating between humans and the core, never replacing it.

What this looks like as a positioning choice

Saying "no AI in the calculation" out loud, in marketing copy, in 2026 — that's a position. It's a bet that the buyer who actually has to defend an estimate to their CFO values reproducibility more than they value a sparkle icon. So far that bet keeps paying off in customer conversations. The buyers who matter ask one question after the demo: "Will this give me the same answer next month?" When the answer is yes, the conversation gets serious.

Determinism is the product when accountability is the use case. AI breaks accountability. Build the boring math first. Wrap it in the helpful interface second. Don't confuse the two.

— Mohamed

Routing 30+ image models with one MCP server

Mohamed Abdallah — Fri, 24 Apr 2026 20:55:32 +0000

Most image-model wrappers pick one model and call it. DALL-E, Imagen, Stable Diffusion, Flux — pick your favorite, ship an API. The trade-off is fixed: one model's strengths become your whole tool's strengths, and its weaknesses become yours too.

prompt-to-asset takes a different angle. It's an MCP server (Model Context Protocol — the open standard Claude and a growing list of clients use for tool integration) that routes a request to the right image model for the task, out of 30+. The routing decisions live in a JSON table; the hard question this post is about is how that table got built.

Why routing at all

Image models have wildly different strengths. A short list of specifics:

Text rendering. Imagen and Flux Pro are decent. Stable Diffusion and most Midjourney-clones produce garbled letterforms. If your prompt involves in-image text, routing matters.
Transparent backgrounds. Only a subset of models produce clean alpha. The rest force you to matt after generation.
Style adherence. For "flat vector editorial illustration, no 3D," some models comply on first try. Others need 3-4 regenerations.
Aspect ratios. Models have preferred training resolutions. Requesting 2.4:1 when the model was trained at 1:1 produces low-quality output or silent crops.
Cost. Free tiers (Pollinations, Stable Horde, HuggingFace Inference) work for drafts. Paid tiers (Imagen 3, Flux Pro, DALL-E 3) for finals. Picking the wrong tier for the use case wastes either money or quality.

Given all that, one model per tool is a compromise. Routing lets you respect the compromise instead of pretending it doesn't exist.

The routing table

The table lives in data/routing-table.json. Each entry looks roughly like this (simplified):

{
  "task": "app_icon",
  "aspect_ratio": "1:1",
  "constraints": {
    "no_text": true,
    "transparent_background_optional": true
  },
  "preferred_models": [
    {"model": "imagen-3", "tier": "paid", "score": 9},
    {"model": "flux-pro-1.1", "tier": "paid", "score": 8},
    {"model": "pollinations-flux", "tier": "free", "score": 6}
  ],
  "never": ["dall-e-2", "stable-diffusion-1.5"],
  "post_processing": ["center_crop", "alpha_matte_if_needed"]
}

Three things about that structure that took me time to get right:

"Never" is explicit. Routing by best-fit is fine until a user requests "app icon" and the router picks a model that can't handle square aspect. Listing the models to exclude per task prevents the correct-on-average, wrong-on-edge-cases failure mode.
Scores are 1-10, not best-only. If the top-scored model is down or rate-limited, the router falls through. Fallback paths matter more than I initially thought.
Post-processing is part of the route. "Generate a 1024x1024 icon, then center-crop, then alpha-matte" is a single logical route even though it involves multiple steps. Separating model selection from post-processing prematurely made the table harder to reason about.

How the table got built

Honestly? Mostly by running the same ~30 prompts through each of the 30+ models and eyeballing the outputs. There's no automated scoring for "this looks like a good app icon." You see it or you don't.

I tried LLM-based scoring for a while — generate an image, have GPT-4-vision rate it. It was 60% accurate and introduced its own biases (favored photorealism when the target was flat illustration, etc.). Faster than manual but noisier. I ended up with a hybrid: LLM-pre-screening to cut the top 3, then human pick.

What I'd do differently if starting over: build the eval harness first, not the router. An eval harness is a script that takes a set of reference prompts and runs them through a model, spitting out a gallery of results. Even without automated scoring, having the gallery on disk for 30 models × 30 prompts = 900 images laid out in a grid makes routing decisions fast. Without the harness, I was regenerating the same images over and over.

Three execution modes

The server exposes three ways to use it:

inline_svg — the host LLM writes SVG directly. No external model call. For simple logos and wordmarks this is fastest, free, and the LLM often does better than a diffusion model at pure-vector tasks.
external_prompt_only — the server returns a structured prompt you paste into another tool (e.g., dev.to's cover generator, Midjourney, whatever). For when you want to run the model yourself.
api — the server routes to an actual image-generation API, returns the image. Default mode for most use cases.

Mode 1 surprised me. I built it last, thinking it was niche. It turns out "have Claude write the SVG" is correct for probably 40% of icon/logo requests. The LLM writes cleaner, more editable output than any diffusion model can.

Free-tier first

One design decision I'd recommend to anyone building similar tooling: make zero-key usage the first-class path. prompt-to-asset defaults to Pollinations for drafts, falling through to HuggingFace Inference and Stable Horde if Pollinations is down. No API key required to get a first result.

The paid-model routes exist for quality runs. But the first-time user who just wants to see what the tool does shouldn't have to get a Google Cloud billing account set up to see anything.

What's next

The routing table grows as the model landscape changes. Every month there's a new Flux version or a new open-source diffusion model worth evaluating. The tool's longevity depends on the table staying current, not on any single routing decision being optimal.

If you hit a task where the routing picks the wrong model, open an issue with the task description and the output you got. Those reports are how the table stays honest.

Repo: github.com/MohamedAbdallah-14/prompt-to-asset. MIT licensed. MCP server, installable in Claude Code + compatible clients.

The AI writing tic I couldn't stop seeing after building a humanizer

Mohamed Abdallah — Wed, 22 Apr 2026 05:52:37 +0000

The AI writing tic I couldn't stop seeing after building a humanizer

I built unslop to strip the

tells that mark text as AI-generated. I thought I knew what they were. I was
wrong about which ones hurt most.

The one I keep catching: the tricolon.

"X, Y, and Z" where all three are the same abstraction level. Every AI

output does this. Not because the writer means three things. Because the
model learned that three parallel items feel rhetorically complete.

Before:

Modern software engineering requires discipline, patience, and a deep

understanding of systems at scale.

After:

Modern software engineering requires discipline. The rest comes with time.

The second version has one claim and a closer. The first has three, because

the model is filling the shape. Discipline, patience, and understanding of
systems are not three separate things — patience is part of discipline and

understanding systems is what the discipline is for. The tricolon hides

that by flattening everything to a list.

Once I saw it, I couldn't unsee it. Every cover letter I've read from a

junior dev in the last year opens with a tricolon. Every LinkedIn post from

a thought-leader account has one in the third paragraph. Every "humanizer"

tool I tested left it in, because it's grammatically correct and

individually the words are fine.

unslop kills tricolons at the balanced and full intensity levels. It

replaces them with the single claim or pair the writer probably meant. In

the full level, about a third of tricolons get replaced with a period and

a fragment, because that's what the claim usually needed.

If you write with AI assistance: read your output for tricolons. You don't

need a tool. You just need to notice that three things, listed, usually

mean one thing or two, padded.

If you're curious about what else shows up: the tool is MIT-licensed,

installs as a Claude Code plugin, and lists the full pattern catalog in its

README.

—

unslop on GitHub