Coder Legion - Recent posts tagged writing

The Maintainer Who Wrote "Sorry, I Missed the Request!"

Fri, 30 Oct 2026 20:21:47 +0000

Sixteen days of silence, one polite reminder, and a surprisingly good Friday in open source.

My favorite GitHub notification this month wasn't a new star, a detailed code review, or someone telling me my project had changed their life.

It was a maintainer saying:

"Sorry, I missed the request!"

That's it.

No technical discussion. No complicated review. No debate about architecture. Just five words, an exclamation mark, and a merged pull request.

And somehow, that little interaction made my Friday.

Let me explain.

The world's least dramatic pull request

On October 14, I opened a pull request to in-toto/friends.

If you're unfamiliar with in-toto, it's an open-source framework focused on software supply-chain security. The friends repository maintains a list of projects that integrate with it.

I maintain a tool called workproof, which generates verifiable engineering reports from private repositories.

I wanted to add it to the list.

The pull request was about as exciting as it sounds.

One row in a Markdown table.

Not a new feature. Not a performance improvement. Not a security patch that would save thousands of production servers from catching fire.

A row.

If GitHub had an award for the least dramatic contribution of the week, I might have been a serious contender.

I opened the PR, checked that everything looked right, and moved on to other work.

Then I waited.

And waited.

Not in the cinematic sense. There was no staring at the screen, refreshing GitHub every seven seconds while dramatic music played in the background.

I had other things to build.

But every so often, I'd check the pull request.

Still open.

No comments. No review. No labels.

Nothing.

Sixteen days passed.

The strange psychology of an unanswered PR

Here's something I've noticed about contributing to open-source projects.

When you submit a pull request, you know intellectually that nobody owes you an immediate response.

Maintainers have jobs, families, other repositories, notifications, issues, bugs, releases, and probably an impressive collection of browser tabs they'll never close.

I understand that.

But there's still a small part of your brain that starts inventing explanations when a PR sits unanswered.

Did I submit it incorrectly?

Is this repository still maintained?

Was the contribution inappropriate?

Should I say something?

Would saying something make me annoying?

The last question is particularly interesting.

As contributors, we often worry about bothering maintainers. We don't want to appear impatient or entitled, especially when the change is small.

So we wait.

Sometimes a week. Sometimes a month.

Sometimes until the repository becomes a historical artifact and someone discovers our pull request while researching ancient civilizations.

Meanwhile, the maintainer might simply have missed the notification.

That's the funny part.

We can spend days interpreting silence that contains absolutely no information.

Thirty-five minutes

On October 30, I decided to write a follow-up.

Nothing elaborate.

I mentioned that the pull request had been open since October 14, that the change still merged cleanly, and that a quick yes or no would help me plan.

That was the whole point.

I wasn't asking the maintainer to prioritize my contribution. I wasn't explaining why my project was important. I wasn't trying to turn a Markdown table update into a philosophical argument about the future of software supply chains.

I just wanted to know whether the contribution made sense.

Thirty-five minutes later, the maintainer approved it.

The response:

"Sorry, I missed the request!"

At 11:02 UTC, the PR was merged.

Sixteen days of silence.

Thirty-five minutes after a reminder, done.

I laughed a little when I saw it.

Not because the maintainer had done anything wrong. Quite the opposite.

The answer was so ordinary and so human that it immediately made the entire situation feel smaller.

There had been no hidden disagreement.

No mysterious review process.

No elaborate technical objection waiting to emerge.

The request had simply been missed.

And now it wasn't.

We talk a lot about automation. We talk less about attention.

I spend a lot of time around software engineering, open-source tooling, and AI-assisted development.

Every week, there's a new discussion about agents writing code, agents reviewing code, agents fixing bugs, and eventually agents doing practically everything except remembering where we left our coffee.

Some of those developments are genuinely exciting.

But this little experience reminded me of something that doesn't get nearly as much attention.

Open source isn't just a collection of repositories.

It's also a collection of people trying to coordinate their limited time and attention.

A pull request can be technically correct, perfectly formatted, and ready to merge.

That doesn't mean someone has seen it.

And even when someone has seen it, that doesn't mean they've had the time or context to respond.

Those are different problems.

As engineers, we're very good at building systems that track code changes. We have statuses, checks, notifications, dashboards, review requests, and activity histories.

Yet a perfectly valid contribution can still disappear into the noise.

The software is doing its job.

The humans are just busy being humans.

A reminder doesn't have to be a demand

I've seen contributors handle unanswered pull requests in very different ways.

Some wait indefinitely.

Some send repeated messages.

Some become frustrated and start questioning whether the project is actively maintained.

And occasionally, a simple follow-up turns into an argument that nobody really wanted to have.

I'm not convinced any of those extremes help.

What worked for me was making the request easy to answer.

Not:

"Why hasn't anyone reviewed my PR?"

Not:

"This is a very important contribution and deserves your attention."

And definitely not:

"Hello??? @maintainer @maintainer @maintainer"

Just a little context, a specific question, and room for the answer to be no.

That last part matters.

When you ask for a review, you're asking another person to spend time on something you care about.

They might agree.

They might disagree.

They might need another week.

They might decide the contribution doesn't belong in the project.

All of those are legitimate outcomes.

A polite reminder doesn't guarantee a merge, and it shouldn't.

It just gives the conversation another chance to happen.

Of course, every project has its own contribution guidelines and review expectations. Some maintainers explicitly ask contributors not to ping them. Those boundaries deserve respect.

But where follow-ups are welcome, one clear message can be more useful than two weeks of silent speculation.

At least, it was in this case.

Small contributions are still real contributions

I also want to avoid exaggerating what happened here.

My PR added one row to a README.

It wasn't a significant engineering breakthrough. It didn't prove the quality or security of workproof. Being listed in a repository isn't the same thing as receiving an independent endorsement.

And I don't think we should pretend otherwise.

There's already enough inflated language in technology.

Not every commit is revolutionary.

Not every feature is groundbreaking.

And not every merged pull request needs a LinkedIn post explaining how it transformed the future of engineering.

Although, apparently, one Markdown row can inspire an entire article.

So perhaps I'm not completely innocent.

But small contributions do matter in a different way.

They help projects stay connected.

They improve documentation, update integrations, correct outdated information, and sometimes simply make it easier for the next person to discover something useful.

They also give contributors opportunities to interact with communities outside their own projects.

That last part matters to me.

I maintain my own tools, but I don't want all my engineering work to happen inside repositories where I'm the person making every decision.

Contributing elsewhere means learning how other projects work, respecting their processes, and occasionally discovering that the person on the other side of the pull request is just as human as you are.

It's a modest kind of connection.

But I like it.

The other side of the notification

There's another perspective worth considering.

Imagine maintaining a popular open-source project.

You've spent months or years building something useful, often without compensation proportional to the work involved.

Your inbox is full.

Someone reports a bug.

Someone requests a feature.

Someone opens a PR that breaks three tests.

Someone asks whether the project supports a configuration you documented two paragraphs above their question.

And somewhere among all of that is a perfectly reasonable one-line contribution.

You miss it.

Sixteen days later, the contributor sends a polite reminder.

You take a look, realize it's fine, and merge it.

What do you say?

In this case:

"Sorry, I missed the request!"

I appreciated that response because it didn't try to turn a small oversight into something complicated.

No excuses.

No defensiveness.

Just an acknowledgment and an action.

That's a pretty good way to handle many situations, not only pull requests.

And if you're a maintainer reading this, I don't think the lesson is that you need to respond to everything immediately.

That would be a terrible expectation.

It's that even a short answer can be valuable.

"Not right now."

"Needs changes."

"This doesn't fit the project."

"Sorry, I missed this."

A response doesn't have to be positive to be useful.

Sometimes it just needs to exist.

One more thing before I close GitHub

I have a couple of other pull requests waiting in different projects.

After this experience, I'm going to check their statuses and see whether a follow-up makes sense.

Not because I suddenly believe every unanswered PR is one message away from being merged.

Some changes need discussion. Some need substantial review. Some may never be accepted.

That's part of contributing to projects you don't control.

But I'm less inclined to interpret silence as a decision.

And I'm a little more comfortable asking a reasonable question when enough time has passed.

If you've contributed to open source, you've probably experienced that strange waiting period where you can't tell whether your PR is being considered, forgotten, or quietly ignored.

My experience isn't proof that reminders always work.

It's just one example of why they sometimes do.

Sixteen days of silence turned out to mean exactly what the maintainer said:

They missed the request.

Nothing more dramatic than that.

So thank you to the maintainer who took the time to respond and merge the change.

You probably spent less than a minute writing that sentence.

I ended up writing an entire article about it.

That's a pretty impressive return on five words.

I'm Efe Genc, an independent software engineer building open-source developer tools. I write about engineering, experiments, and the things that happen when software meets actual human beings.

First published on my site: https://efegenc.me/writing/the-maintainer-who-wrote-sorry-i-missed-the-request/

Cross-posting to dev.to without giving away your SEO.

Tue, 27 Oct 2026 21:03:41 +0000

Every article I write lives on my own site first. A copy goes up on dev.to a day or two later, and that copy reliably gets more readers than the original does. One piece has 106 views over there. My own analytics can't honestly tell me how many humans read it here, which is a separate mess I wrote about last week.

So I am deliberately publishing my best work somewhere with more traffic than my site, under a domain I don't own. The thing that makes this a syndication strategy instead of a slow act of self-harm is one field in the dev.to API:

const canonicalDi = (slug) => `https://marcobellingeri.dev/en/writing/${slug}`;

That is the whole trick, and it is also the least interesting part. What took me longer to learn is that canonical-first is not a field you set. It is an order you have to keep.

What the tag actually buys you

When two URLs serve the same article, a search engine has to pick one to rank and one to treat as a duplicate. Left alone it will usually pick the one with more authority, which on any given week is dev.to and not you. rel="canonical" is how the copy points back and says the other one is the original.

dev.to honours this properly. Set canonical_url on a post and it renders the tag in the head, and it also shows a small line to readers saying the piece was originally published elsewhere, with a link. Some people click it. That link is worth more to me than the view count.

The part worth being precise about: the canonical is a hint, not a directive. Google treats it as one signal among several, and one of the others is which URL it saw first. That is where the ordering comes in.

The house has to be older than the mirror

If dev.to publishes on Monday and your site publishes the same piece on Thursday, you have handed a crawler a strong reason to believe dev.to is the original and you are the copy, no matter what your tag says. You are asking it to disregard the evidence of its own crawl on the strength of an annotation.

So the rule my pipeline enforces is that the canonical URL must resolve, with the right date on it, before the mirror goes live. Not at the same time. Before.

This is enforced by refusing to publish. The workflow that talks to dev.to on every merge is only allowed to create drafts:

on:
  push:
    branches: [main]
    paths: ["astro-project/src/content/writing/en/**"]

It runs node engine/devto.mjs <slug> with no --publish flag, ever. Merging an article deploys it to my site and leaves an unpublished draft sitting on dev.to. Nothing is live over there until a second, separate thing happens.

That second thing is a daily cron at 07:00 UTC that reads the date in each article's frontmatter and flips the ones whose day has arrived:

devto: niente in uscita oggi (2026-08-19)
DOMANI=

Most mornings it has nothing to do and says so. The same run also opens a GitHub issue listing anything going out tomorrow, which gives me a real 24 hour window to move a date or delete a file if a piece has aged badly since I wrote it. Nobody has to approve anything for publication to happen. Silence publishes. The one human decision is the merge, and it already happened.

The date that lied

I would like to report that this held. In July I merged an article about source licences with date: 2026-08-18 in its frontmatter, scheduling it for a Tuesday. In August I noticed it had been public on dev.to since the 11th.

Seven days before its own publication date.

It wasn't the draft workflow, which never passes --publish. It wasn't the cron, which skips future dates. It was me, publishing that one by hand from the dev.to UI weeks earlier and forgetting. The automation was innocent and had no way to notice.

What made it a real problem rather than an embarrassing one is what my own site was serving in the meantime. The article page builds its JSON-LD from that same frontmatter field:

"datePublished": "2026-08-18"

So for seven days the canonical URL told every crawler that the original was published on the 18th, while the copy it pointed at was demonstrably live on the 11th. The one signal I control was actively arguing that my site came second.

The fix was a one line change to a date, which is the sort of fix that makes you want to check what class of thing it belongs to. It belongs to this one: the frontmatter date is not decoration. It is the claim my canonical makes about which came first, and anything that publishes outside the pipeline can make that claim false without touching the repository.

I also checked what would have happened on the 18th if I hadn't noticed. Nothing at all, as it turns out, because the cron skips pieces that are already live. The bug would have quietly persisted rather than announcing itself. Those are the ones worth going looking for.

Re-running has to be free

The other property that matters is that pushing the same article twice must not create a second post. dev.to has no upsert, so the script builds one by asking what already exists and matching on the canonical URL:

const canonicalPubblicati = (await publishedArticles()).map((a) => a.canonical_url);

Matching on canonical rather than on title means an edited headline updates the existing post instead of forking a duplicate, and duplicates are exactly what the canonical tag exists to prevent. A syndication script that can create two live copies of one article is doing the opposite of its job.

Editing a published piece and re-merging updates the draft body and leaves its published state alone. I have re-run the whole thing more times than I would like to admit while debugging, and it has never republished anything.

One more thing, since it belongs to the same function. The slug comes from a filename, gets interpolated into a URL, and gets used to open a file, so it is validated before either:

if (!slug || !/^[a-z0-9-]+$/.test(slug)) { /* exit 1 */ }

Filenames in my own repository are not attacker controlled, and I validate them anyway. The check costs one line, and the day someone else can open a pull request against this repo is the day I would otherwise have to remember to add it.

What I would check on your setup

If you already cross-post, three things are worth ten minutes.

Open the mirrored copy and view source. Confirm the canonical tag is actually there, because plenty of platforms accept the field and then drop the tag on some templates.

Then compare the two publication dates, not the two URLs. If any mirrored copy is older than the original it points at, your canonical is arguing against you right now, and no amount of correct configuration fixes an ordering you got backwards.

Then find whatever can publish outside your pipeline. A CMS button, a scheduled post, a colleague with access, you three weeks ago. Mine was me, and the automation I had spent a weekend making careful had no idea.

The tag is easy. Staying first is the work.

Humanizer has about 60,000 stars. On 12 public tasks my linter plugin scored 2.67 higher

Sat, 24 Oct 2026 10:06:25 +0000

I wanted to know whether a linter for AI writing tells helps an agent rewrite a file better than a good prompt does. So I ran a benchmark with 11 arms: the linter packaged as a Claude Code plugin, six other Claude Code skills that claim to remove AI-sounding prose, and Claude with no plugin. Three of those skills (Humanizer, unslop and everwrite) were also run a second time with the prompt calling them by name, which is where the count of 11 comes from. Each arm ran each task three times on Sonnet 5.5.

The short result: on 12 public tasks the linter scored 58.67 of 60 and the best other arm scored 56.00. On 6 held-out tasks, written by an author who had not read the code, four arms scored 29.67 or more of 30, so that set does not separate them.

What was measured

Each task asks an agent to edit a real file in place: a French launch note, a README intro, a pull request description, release notes, a mixed-language guide, a repository set-up. A task scores only what the file contains afterwards, so talking about the problem earns nothing. Each task also carries facts a careless rewrite would break, such as numbers, names, code and links, and scripted checks look for them. Some criteria need judgment, and those went to a blind grader: outputs of all arms were shuffled and anonymised, and the grader gave its reason before its verdict, five votes per cell. Of 99 blind cells, 92 were unanimous.

The other six tools are Humanizer (blader/humanizer, about 60,000 GitHub stars per the GitHub API on 2026-10-24), unslop, everwrite, slopless, avoid-ai-writing and slop-cop. The protocol was written and committed before the first cell ran. A total below is the sum over tasks of the mean over the three runs, with a maximum of 5 points per task. The result applies to those tasks only and ranks nothing in general.

Public tasks

arm	total of 60	95% interval
this linter	58.67	[57.67, 59.67]
Humanizer, called by name	56.00	[54.67, 57.33]
Humanizer	54.67	[53.33, 56.33]
everwrite, called by name	54.33	[52.67, 56.33]
everwrite	53.33	[52.00, 54.67]
unslop, called by name	51.67	[51.00, 53.00]
unslop	51.00	[50.33, 51.67]
slopless	50.67	[49.33, 52.00]
avoid-ai-writing	50.33	[49.33, 51.67]
slop-cop	49.00	[47.67, 50.33]
no plugin	48.67	[47.00, 50.00]

The difference between the linter and the best other arm, Humanizer called by name, is 2.67 points, with a 95% bootstrap interval of [1.00, 4.33]. The lower bound is above zero.

It did not win every task. On h11 and h15 it scored 4.67 where the best rival scored 5.00, and on h18 it tied at 4.67. The benchmark's stricter per-task rule (rule B) fails on those three tasks.

Held-out tasks

Six further tasks were written by an author, a Sonnet agent, who had seen no code of this repository. The person running the measurement had not read them before it.

arm	total of 30	95% interval
unslop	30.00	[30.00, 30.00]
avoid-ai-writing	29.67	[29.00, 30.00]
this linter	29.67	[29.00, 30.00]
unslop, called by name	29.67	[29.00, 30.00]
no plugin	28.67	[28.00, 29.00]
Humanizer	28.67	[28.00, 29.00]
Humanizer, called by name	28.00	[27.00, 29.00]
slopless	28.00	[28.00, 28.00]
everwrite, called by name	27.33	[26.33, 28.33]
slop-cop	27.00	[25.67, 28.33]
everwrite	26.67	[26.00, 27.00]

Here the linter is 0.33 behind unslop, with an interval of [-1.00, 0.00], so the claim that it is first does not hold on this set. It lost that 0.33 on one task, ho1, where it scored 4.67 against 5.00. Four arms sit at 29.67 or higher and even the no-plugin baseline reaches 28.67, so these tasks cannot separate the top arms. Across both sets: first on the public set, and within 0.33 of the best of the 11 arms on the held-out set.

Other models

I also ran Haiku 5.5 and Opus 5.5 once per task, with only the linter, the best other arm of each set and the no-plugin baseline. These totals are descriptive. With one run per task, a difference of one or two points is inside the run-to-run variation. These runs were not blind-graded, so the public scores use the scripted criteria only and their maximum is 57.

model	set	this linter	best other arm	no plugin
Haiku 5.5	public, of 57	54	52 (Humanizer, called by name)	43
Haiku 5.5	held-out, of 30	28	28 (unslop)	26
Opus 5.5	public, of 57	54	54 (Humanizer, called by name)	45
Opus 5.5	held-out, of 30	29	27 (unslop)	25

What a prompt cannot do

The linter is a command line tool that calls no model and has no dependencies. Its rules are deterministic: the same text gives the same findings. A rewrite can pass every check and still lose a fact, so the tool also has --compare. It lists each number, version, date, link, quotation, code span and name that appears in one text and not the other, and exits 1 when it finds one. It also reports a qualifier that went missing next to a number, and first-person or claim words that the rewrite added.

This is real output on a two-line example I wrote for this post:

$ npx ai-slop-linter --compare before.md after.md
facts: 1 kept, 4 lost, 0 added
lost   date     3 March 2026
lost   number   1200
lost   qualifier up to 40
lost   version  2.4

The plugin's skill runs this after each rewrite and treats a failing comparison as blocking. --compare compares facts and not wording, so it cannot say whether a rewrite is good.

What it costs

This arm cost 2.43 times the no-plugin baseline per cell at list price, on both sets, because it takes more turns and more tokens. In the public set that was 0.125 US dollars per cell against 0.051. The runs were charged to a subscription, and the whole measurement would cost about 91 US dollars at list price.

What went wrong in the measurement

The session limit stopped the runs twice. 236 public and 160 held-out attempts failed with usage_limit_reached, were kept and never scored, and the same commands ran them again.
The public and held-out runs went on at the same time. The held-out runs used a later commit, because the harness refuses a working tree whose benchmark folder differs from the commit. The product files are byte-identical between the two commits.
The blind grader loop died once and was started again, so for a while two copies wrote vote files. All 165 vote files of the re-grade are valid, and none was dropped by hand.
A re-grade of 33 sampled blind runs agreed with the first grading on 99.4 percent of criteria. Of 60 sampled cells run a second time, 38 of 40 public and 19 of 20 held-out re-runs fell inside the range of the original three runs.

Try it and check it

npx ai-slop-linter README.md
npx ai-slop-linter --compare before.md after.md

To install it as a Claude Code plugin:

/plugin marketplace add Bubblegunn/ai-slop-linter
/plugin install ai-slop-linter@ai-slop-linter

Every cell, the departures from the protocol and a recompute step are in the round 8 evidence folder. REPRODUCE.md in that folder gives the commands for a re-run, which needs Claude Code 2.1.308, Node 24 and about 9 hours. The tasks, criteria and harness are public in bench/head-to-head/, and the earlier rounds and rulings are in docs/HEAD-TO-HEAD.md. The repository is Bubblegunn/ai-slop-linter, and version 0.2.0 is on npm.

Simplify Your Writing

Fri, 11 Sep 2026 17:09:29 +0000

I've always found that a lot of writing can be improved just by getting rid of unnecessary words.

The hard part is noticing them.

For example, there's not much reason to write:

due to the fact that

when you could just write:

because

Or:

in close proximity to

instead of:

near

These aren't huge changes, but when you have a whole page full of them, they add up.

Removing that extra wording can make something much easier to read.

So I built a small tool to help find them.

You paste your writing into it and it highlights phrases that can be shortened.

You can hover over a phrase to see the suggested replacement and choose whether you want to use it.

There's also a Replace All button if you want to apply the shortest suggestion everywhere.

I didn't want to use AI

There are already a ton of AI tools that will rewrite your writing.

That's actually why I didn't want to make another one.

I don't necessarily want an AI to rewrite something I've written. I might like the way I phrased something, but still want to get rid of a few unnecessary words.

I also like knowing exactly why something is being suggested.

Simplify Your Writing is just a dictionary of phrases and replacements. There isn't an AI model deciding what your sentence should say.

If the dictionary says:

due to the fact that → because

that's what it suggests.

Every time.

The whole thing runs in the browser, so there are no API calls or accounts either.

The part I need help with:

The code isn't really the biggest problem.

It's the dictionary.

There are a ridiculous number of phrases that could probably be shortened, and I obviously haven't found all of them.

More importantly, I don't want to add replacements that technically make a sentence shorter but make the sentence worse.

That's where other people can help.

You don't have to be a programmer to contribute.

If you write, edit, or work with documentation, you probably know a bunch of phrases that could be simplified.

You could contribute something as simple as:

at the present time → now

Or find an existing rule that doesn't actually work in every situation and suggest changing it.

I'd particularly like to get contributions from people who work with:

Technical writing
Documentation
Business writing
Copywriting
Academic writing
Editing

Developers are obviously welcome too. There's plenty of work that could be done on the JavaScript, UI, tests, accessibility, performance. Also there are opportunities to expose this as an API or MCP tool but still serve the deterministic logic under the hood.

Why I'm making it open source

I think a dictionary like this gets better when more people can look at it.

If it's just my list of phrases, it's going to reflect my own writing habits and the things I've happened to notice.

I'd rather have people contribute phrases, argue about whether replacements actually work, and improve the rules over time.

That's really the goal here.

Not to build another AI writing assistant.

Just to make it a little easier to write clearly.

If you find a phrase that should be included, or one of the suggestions is wrong, feel free to open an issue or submit a PR.

The Bach Faucet: Why Infinite AI Content Is Infinite Devaluation

Sun, 30 Aug 2026 12:06:25 +0000

When recorded music went free, its value did not vanish. It moved to the seat in the room, and rushed to a handful of winners.

Between 1996 and 2003, the average concert ticket for a rock or pop act nearly doubled. The economists Maria Connolly and Alan Krueger put the number at 99 percent in their 2005 study of the music business. Over the exact same years, a jazz ticket rose only 20 percent. Same economy, same inflation, same kinds of venues, wildly different curves. The one variable that cleanly separated the two: rock and pop were the genres whose recordings were being copied for free, over Napster and burned CDs, while jazz fans mostly kept buying the albums.

Sit with that, because it is the opposite of what everyone predicted. When recorded music became effectively free and infinitely copyable, the thing you could suddenly get for nothing did not drag everything down with it. Its value moved next door, into the one thing you could not copy, which is a seat in the room while the band plays. And it moved fastest precisely where the copying was worst. The genre that got Napstered hardest is the genre whose live prices ran away. Krueger's own explanation, in the paper: records and concerts are complements, and "record sales are down because many potential customers frequently download music free from the Web or copy CD's."

I open on a twenty-year-old number because the software industry is now running the same experiment at a thousand times the scale, and most of the confident predictions about it are wrong in the same specific way.

The faucet, and the wrong thesis

The vivid image for what we have built is the "Bach faucet," a coinage generally credited to the computational-creativity researcher Kate Compton around 2022 (the attribution travels through a community wiki, so hold it loosely). A Bach faucet is a tap you can turn on to get an endless stream of creative work at least as good as a human master's. We have roughly built one. Large language models will write you a competent blog post, a passable short story, a serviceable market analysis, on demand, for a fraction of a cent, until the sun burns out.

The intuitive economics of that is a straight line to zero. Infinite supply, zero marginal cost, price collapses, content becomes worthless. It is the natural thing to say, and it is wrong, or at least wrong in a way that will lead you to defend the wrong castle. We have the receipts from the last time an entire creative economy went infinite, and recorded music in 2025 pulled in 31.7 billion dollars, up 6.4 percent on the year, according to the industry's own global report. Twenty years after Napster was supposed to end it, the recorded-music business is bigger than ever. "Infinite copies make the thing worthless" is simply not what happened.

What happened is subtler and, if you make things for a living, considerably more useful to understand. Infinite supply did not destroy value. It relocated value, and it concentrated value, and both of those moves were brutally unequal. To see why, you have to pull apart three different mechanisms that the phrase "AI slop" usually mashes together.

Three mechanisms, only one of which is really "infinite devaluation"

The first mechanism is the obvious one, the supply glut. More stuff, so each piece is worth less. This is the weakest of the three, because content was never the scarce resource. Attention is. There were already more good books than you could read in ten lifetimes before a single model wrote a word. Doubling an infinity of things you were never going to read does not change your day. Zero marginal cost on the supply side runs straight into a hard fixed budget on the demand side, which is the twenty-four hours in a reader's day, and that budget does not grow because a faucet turned on.

We have written before about what cheap AI creation does to volume — the Jevons paradox of AI content, where falling cost explodes consumption. This essay is about the other blade: not how much gets made, but what the flood does to a reader’s ability to trust any of it.*

The second mechanism is the one that actually earns the phrase "infinite devaluation," and it is the sharp one. In 1970 the economist George Akerlof published "The Market for Lemons," which won him a Nobel Prize, and its logic is the key to this entire essay. Akerlof showed that when buyers cannot tell good from bad before they buy, they will only pay a price for the average. That average price is too low to be worth a good seller's while, so good sellers leave. Their exit drags the average quality down, which drags the price down again, which pushes out the next tier of sellers. The market can unravel completely even though excellent goods exist and buyers would happily pay for them, purely because nobody can verify which is which at the moment of choosing.

Now map that onto a channel flooded with AI writing. The damage is not to any individual AI article. The damage is to the channel. Once a reader cannot tell, at a glance, whether a blog post or a product review or a research summary was written by someone who actually knew something, the rational move is to discount everything arriving through that channel, including the genuinely expert work. This is the devastating part, and it is worth saying slowly: the flood does not primarily devalue the slop. The slop was near-worthless already. The flood devalues your work, the good stuff, by destroying the reader's ability to trust the channel it arrives in. The honest writer is taxed for the liar's output. That is what "infinite" means here. It is not that any one thing goes to zero. It is that a whole category of trust can collapse while the good work is still sitting right there, unread because it is now indistinguishable from the noise around it.

The third mechanism is the one the music data makes undeniable, and it is the opposite of what "democratization" promised. More supply does not spread attention out. It concentrates it. In the Connolly and Krueger data, the top 1 percent of performers captured 26 percent of all concert revenue in 1982. By 2003, deep into the file-sharing era, the top 1 percent captured 56 percent. The top 5 percent went from 62 percent to 84 percent. As the copyable good flooded the world, the live economy did not become a broad meadow of working musicians. It became a spike. When everyone can access everything, attention does not fan out across the abundance. It rushes to a handful of winners, because the abundance is precisely what makes curation, reputation, and being-already-famous so valuable. Abundance is a superstar machine.

The faucet is running, but check where the water goes

Bring this to the present, and the numbers rhyme with the music story in a way that should reorganize how you think about the threat.

The flood is real. The web-analytics firm Graphite studied roughly 55,000 web pages published from 2020 through early 2026 and found that in the fourth quarter of 2025, primarily AI-generated articles crossed 50 percent of new published articles for the first time, then settled back to just under half in early 2026. Depending on the quarter, something close to half of the new articles appearing online are mostly machine-written. The faucet is not a metaphor. It is a measured fact.

Here is the part that almost nobody quotes, and it is the whole game. Graphite also looked at what actually gets read and cited, and found that of the articles cited by ChatGPT and Perplexity, 82 percent were written by humans and only 18 percent by AI. Half the new web is AI-written, and the machines' own answer engines overwhelmingly cite the human half. The production flood and the attention flood are two completely different things, and only the first one has happened. The water is pouring out of the faucet at full blast and running almost straight down the drain, because the AI articles largely do not surface in search or in AI answers. Axios summarized the same finding with the headline that AI writing has not overwhelmed the web. The doom take and the doomers' own dataset disagree.

So the naive picture, infinite content burying everything, is not what the data shows. What the data shows is the music story again. A copyable good has gone effectively infinite and effectively free, its sheer volume is enormous, and value is not evaporating. It is relocating toward whatever cannot be copied and cannot be faked, and it is concentrating on the few who own that uncopyable thing.

You can watch a platform draw the line in real time. In early 2024 Spotify changed its royalty rules so that a track now has to reach at least 1,000 streams in the previous twelve months before it earns any recorded royalties at all. Spotify's stated reason is that "99.5% of all streams are of tracks that have at least 1,000 annual streams," and that the sub-threshold tracks were each generating about three cents a month, which added up to 40 million dollars a year that mostly vanished into distributor fees before reaching any artist. Read that as an institution formally metering the Bach faucet. It is a platform declaring, by rule, a floor below which a piece of content is worth not "very little" but exactly zero. The infinite tail of songs nobody streams is not underpriced. It is officially priced at nothing, and the 40 million dollars that used to trickle toward it is being swept up to the tracks that clear the bar. Relocation and concentration, written directly into the payout code.

What to do when the faucet is pointed at you

If you make things, or run a company that does, the music experiment hands you a strategy rather than a eulogy. The mistake is to fight the flood on its own terms, by producing more, faster, cheaper, because that is the one contest the faucet wins by definition. The move is to figure out what your live show is.

Find the uncopyable complement. For musicians it was presence, the specific room and night and the fact of being there. For a writer or an analyst or a developer, ask what about your work survives being trivially reproduced. It is usually one of a few things: a reputation staked over years, proprietary data or access nobody else has, judgment on a specific hard problem, a relationship of trust with a particular audience, or the ability to actually do the thing rather than describe it. Those are your concert tickets. The article, the report, the sample code, those increasingly are the free recording that markets the ticket. Krueger's word for records and concerts was complements, and the strategic question is which of your outputs is the recording and which is the show. Give the recording away with less anguish, and price the show.

Attack the lemons problem directly, because it is the mechanism aimed at you specifically. If the flood devalues your good work by making your channel unverifiable, then verifiable quality is the entire ballgame. Anything that lets a reader tell, before they commit their scarce attention, that this came from someone who knew something, is now load-bearing: a real name with a real track record attached, provenance a reader can check, a reputation with skin in it, an institution that vouches. In a market drowning in indistinguishable goods, the cheapest thing to fake is the product and the most valuable thing to own is a signal that cannot be faked. Build that signal, guard it, and never spend it on slop, because the moment your channel becomes a place lemons appear, Akerlof's math starts running against everything you publish there.

And plan for concentration, because it is the part that will surprise the optimists. Abundance did not make a thousand mid-list musicians comfortable. It made a few of them enormous and squeezed the middle toward the Spotify floor. The same spike is coming for content, for software, for any field the faucet touches, and the median producer is the one who gets hurt while total value rises. The goal is not to out-produce the machine. It is to be the complement the machine's output points at rather than the copy it replaces, to own an uncopyable thing and a signal that proves it, and to understand that the water was never going to make everything worthless. It was only ever going to decide, very unequally, where the value went to live.

Sources

Maria Connolly & Alan B. Krueger, "Rockonomics: The Economics of Popular Music," NBER Working Paper 11282 (April 2005): "from 1996 to 2003 concert prices increased by only 20 percent for jazz musicians, but by 99 percent for rock and pop performers"; touring income exceeded record-sales income 7.5 to 1 for the top 35 artists in 2002; and the concentration series (top 1% of performers 26% to 56% of concert revenue, 1982 to 2003; top 5% 62% to 84%). Data ends ~2003; presented here as the historical experiment, not current fact.
George A. Akerlof, "The Market for 'Lemons': Quality Uncertainty and the Market Mechanism," Quarterly Journal of Economics 84, no. 3 (1970): 488–500, the standard statement of adverse selection.
Graphite, "AI now writes as many online articles as humans do" (~55,000 pages, 2020 to early 2026): primarily-AI articles peaked at 50.9% in Q4 2025 and sat near half (49.9%) in Q1 2026; 82% of articles cited by ChatGPT and Perplexity were human-written. See also Axios, "AI-written web pages haven't overwhelmed human-authored content" (Oct 2025).
Spotify for Artists, "Modernizing Our Royalty System": the 1,000-annual-stream threshold from early 2024; "99.5% of all streams are of tracks that have at least 1,000 annual streams"; ~$0.03/month sub-threshold tracks; ~$40 million/year redirected.
IFPI Global Music Report 2026 (recorded-music revenue 2025 of US$31.7bn, +6.4%), as reported across music trade press.
The "Bach faucet" coinage is generally credited to Kate Compton (via the cyborgism wiki), a single-source attribution held loosely here.

The cheapest thing to fake is the product. The most valuable thing to own is a signal that cannot be faked.

Akerlof's math runs against everything you publish the moment a reader cannot tell your work from the slop beside it. The counter is a signal a reader can check before they spend their attention: provenance of who actually did the work, and a reputation with skin in it. That is what the agent trust stack is for, and it is doubly true for agent output: chain-of-consciousness for a provenance record of what an agent actually did, plus agent-rating-protocol for a reputation that survives adversarial checking, so your good work carries a fakery-resistant mark through a channel full of lemons.

See Hosted Chain of Consciousness · Read the Theory of Agent Trust

pip install agent-trust-stack · npm install agent-trust-stack

Or the pieces: pip install chain-of-consciousness / npm install chain-of-consciousness · pip install agent-rating-protocol / npm install agent-rating-protocol

Why I'm Building an Engineering Publishing Platform

Sun, 30 Aug 2026 02:46:00 +0000

Over the past several months, I've made a commitment to write more.

Not because I want to become a content creator, but because I've come to appreciate how much engineering knowledge quietly disappears every day. Architecture discussions end when the meeting is over. Production incidents become stories that fade with time. Lessons learned on one project rarely make it to the next. As engineers, we spend years building experience, but very little of it ever becomes knowledge that others can benefit from.

Writing has become my way of changing that.

Like many engineers, I started publishing wherever I could. I have a blog on my own website, along with accounts on Medium, Hashnode, DEV.to, and Coder Legion. Each platform reaches a different audience, and I genuinely like the idea of meeting engineers where they already are. If someone prefers reading on Hashnode instead of my website, that's perfectly fine with me. My goal has never been to drive traffic to a particular platform. It's to share ideas.

Unfortunately, that turned out to be much harder than I expected.

Every article followed the same routine. Once the writing was finished, I still had to copy Markdown between editors, upload images multiple times, recreate tags, tweak formatting, update SEO metadata, generate excerpts, and create social posts. By the time I finished publishing everywhere, I had spent almost as much time managing content as I had writing it.

As an engineer, my first instinct was simple.

Automate it.

I envisioned a small service that would let me publish an article once and have it automatically appear everywhere else. My website would remain the source of truth while Medium, Hashnode, DEV.to, and every future platform would simply become destinations. It felt like a straightforward integration problem—build a few connectors, push the content out, and move on to the next article.

Then I started designing it.

Like many software projects, it didn't take long before I realized I was solving the wrong problem.

The more I thought about the architecture, the less it resembled a collection of publishing scripts. If every platform was going to behave differently, I needed a common deployment model instead of a collection of one-off integrations. Articles would become immutable releases. Releases could be deployed to one or more publishing targets. Each destination would have its own connector responsible for understanding that platform, while the orchestration layer would manage deployments, retries, status, and lifecycle. The result was an architecture that felt much more like a software delivery pipeline than a blogging tool.

That solved the technical problem.

It didn't solve the real one.

Somewhere in the middle of working through the design, I realized that publishing was never the difficult part.

Thinking is.

Every article I've written over the past few months has started long before a Markdown file ever existed. Sometimes it begins with a conversation. Sometimes it's a lesson I didn't fully appreciate until years later. Other times it's an architectural decision that seemed obvious in hindsight but required hours of discussion to reach. The words themselves are usually the final step in a much longer process of reflection.

That's the process I don't want to lose.

Most writing tools begin with a blank editor. They assume you already know exactly what you want to say. My experience has been almost the opposite. The most valuable part of writing is discovering the idea. It's connecting experiences that didn't seem related, questioning assumptions, and slowly uncovering the principle hidden underneath the story. By the time I begin writing, the real work has already happened.

That realization changed the project entirely.

I'm still building the cross-posting platform because I genuinely want to publish once and distribute everywhere with as little manual effort as possible. But that's no longer the vision.

The vision is to build a platform that supports the entire journey from idea to publication. Conversations become drafts. Drafts become articles. Articles become releases that can be published anywhere. The platform should help organize ideas, generate summaries and metadata, manage revisions, and eventually understand the relationships between everything I've written. I don't want another tool that stores Markdown files. I want a system that helps preserve engineering judgment.

Over the coming weeks, I'll be documenting the architecture, implementation, tradeoffs, and inevitable mistakes as I build this into the M²S² platform. Some articles will be technical deep dives into the connector architecture or deployment pipeline. Others will focus on the decisions that shaped the system and the lessons learned along the way. My hope is that readers don't just see the finished product—they understand the thinking behind it.

If there's one thing I've learned throughout my career, it's that good engineering rarely starts with the perfect solution. More often, it starts with solving one problem, discovering a better question, and allowing the architecture to evolve alongside your understanding.

That's exactly what happened here.

I thought I was building a way to publish blog posts.

Instead, I found myself designing a platform for capturing and sharing engineering experience.

And I think that's a much more interesting problem to solve.

Coming Back to Writing - and My First Cybersecurity Project

Sun, 19 Jul 2026 11:23:26 +0000

It's been a while since I've written anything publicly. I used to be fairly active documenting what I was building as a developer, and somewhere along the way - between shipping products and then pivoting toward cybersecurity - I went quiet. This is me picking that habit back up, starting with the most honest thing I can write about: a small, beginner-level tool I just finished.

I'm not writing this to announce a launch. I'm writing it because documenting the learning is the actual point.

Where I'm At

I come from a full-stack development background - I've shipped a few SaaS products solo. Over the past several months I've been transitioning into cybersecurity, specifically working toward a SOC Analyst role. I'm doing hands-on labs on LetsDefend, going through ISC2 CC and Google Cybersecurity material, and generally trying to learn by doing rather than just collecting certificates.

One thing I noticed early: every SOC case follows a similar manual pattern. You get an IOC - an IP, a domain, a file hash - and you check it across two or three different threat intel sources by hand. VirusTotal here, AbuseIPDB there, MalwareBazaar if it's a hash. Same value, three tabs, three logins, three waits.

So as a first project bridging my dev background with what I'm learning in security, I built a small tool that does that lookup automatically.

What I Built (and What It Isn't)

IOC Enricher - paste an IP, domain, or hash, it queries VirusTotal, AbuseIPDB, and MalwareBazaar in parallel, and gives back a combined risk score with a plain-English AI summary.

I want to be upfront: this is not a novel idea. Tools like this already exist - some far more polished, built by people with actual SOC experience. I'm not claiming to have invented anything. What this project actually is: a way to force myself to touch real APIs, handle real failure cases, and understand the manual workflow well enough to automate a small piece of it.

It's a beginner project. I built it knowing that.

Live: https://ioc-enricher-abd.vercel.app/
Code: github.com/m-abdullah-06/ioc-enricher

What I Learned Building It

The stack itself was straightforward - FastAPI backend, Next.js frontend, Groq for the AI summary. Nothing exotic. The useful part was what went wrong.

MalwareBazaar, for instance, silently returned "not found" for every hash I tested - including ones I knew were malicious. My first assumption was that the hashes just weren't in their database. Turns out abuse.ch now requires an Auth-Key header on every request, and my code was getting a 401 that my error handling quietly swallowed. The tool wasn't broken - it just looked like it was working while giving me nothing.

That was the real lesson. Not the fix itself, which took five minutes once I found it, but the realization that a silent failure that looks like a valid result is worse than an obvious crash. If this were a real SOC tool and not a portfolio piece, that bug would mean telling someone a file was clean when it was never actually checked.

Why I'm Writing This Instead of Staying Quiet

I could've kept this to myself until I had something more impressive to show. But I think there's more value in documenting the beginner version honestly - partly for my own record of where I started, and partly because I know there are other people making the same dev-to-security switch who might find the process more useful than a polished result.

I'll keep building on this - bulk lookups, maybe Shodan integration, better error handling than the silent-failure lesson taught me I needed. But this version, the rough first one, is the one worth writing about.

More writeups coming as I close more SOC cases and keep building. Good to be back.

Muhammad Abdullah - learning SOC analysis, building things along the way. GitHub: m-abdullah-06

The Hardware Every Programmer, Sysadmin, and Linux Nerd Actually Needs in 2026 (No Marketing Fluff)

Mon, 06 Jul 2026 16:08:03 +0000

What year is it again? 26? I haven't left the terminal long enough to notice — my system clock drifted and I only just caught it. Anyway, hello to all the engineers out there, junior and senior, and of course to my fellow Linux nerds.

In this post I want to break down what hardware is actually worth buying if you're a programmer, a Linux user, a sysadmin, a technical writer (like me, ha), or a manager. I'll throw gamers a bone too, but consider that section a footnote — I'm not much of a gamer myself, though I did once have to sit inside a game engine for work, so I've earned the right to an opinion.

Before we get into the actual picks, let's lay out the facts and the needs of each of these roles. Everyone has different priorities, sure, but they overlap more than people think — and once you strip away the marketing copy, the actual requirements for "good machine to work on" are almost identical across all of them.

I've spent a genuinely unreasonable amount of time comparing processors, GPUs, and laptops across brands — corporate, flagship, gaming, all of it. I've read the spec sheets, I've read the community threads where people complain about coil whine at 2am, I've watched the durability teardown videos so you don't have to. Here's what actually matters, in order.

The Keyboard Comes First. Always.

For every single one of these roles — coder, writer, sysadmin, manager — you need a keyboard you want to type on. And here's the uncomfortable truth about the current market: most of it is 1.5mm, 1.3mm, sometimes less. Can you write on that? Sure. It's a solid "okay." It exists to let you exist. It's not going to hurt you, and it's not going to inspire you either.

If you actually want a keyboard that makes typing feel good, your options collapse fast: ThinkPad (not every line — pay attention, this matters more than you'd think) and, to a lesser extent, select Dell Latitude models. And that's basically it. If you're on desktop, obviously the market opens wide up — you can buy something that clacks like a 1985 typewriter if that's your thing, mechanical switches, hot-swappable, the whole ritual.

Why does this matter so much for these particular jobs? Because a writer writes text all day. A Linux user is constantly fixing configs, running fastfetch in their terminal just to feel something. A sysadmin is deep in Docker configs and SSH sessions, typing constantly, half the time over a flaky VPN tunnel at 2am because production decided to have opinions. A developer is fixing bugs, replying to painfully dumb emails, arguing in Slack with coworkers about tabs versus spaces for the hundredth time. It's all typing. The keyboard is the interface to your entire professional life — treat it like one, not like an afterthought bolted onto a chassis to check a box.

The Screen: Second Priority, First for Some

If your work touches design, video, or imagery, a good display isn't optional — it's oxygen. ThinkPad P-series and select T-series configurations cover this too: OLED, 2K/4K, 16:10, no problem. Just know that the panels with the nicest color and contrast tend to come on the models where key travel has already crept down toward that 1.5mm territory. Nothing is free — every laptop is a stack of compromises, and your job is to pick which compromises you can live with.

If your priority is design work and raw power and you're constantly traveling — because let's be honest, rendering 4K footage makes any laptop sweat — then a MacBook on an M-series chip is a legitimate outlier worth considering, purely on the merits of thermal efficiency and color accuracy per watt. It's not Linux, and yes, you'll spend a weekend re-training your muscle memory if you're coming from a tiling window manager. But nobody serious is pretending Apple Silicon isn't good hardware. Just don't buy the oldest chip on the shelf because it's the cheapest — buy something current, or at minimum one generation back. Old silicon for the sake of saving two hundred bucks is how you end up bottlenecked in eighteen months.

CPUs: Just Buy AMD, Especially on Linux

I'll say it plainly: AMD is the better call, particularly if you live on Linux. Open drivers, better long-term support, a healthier open-source relationship, strong new architectures, decent battery life, and — unlike certain competitors — they don't turn your lap into a stovetop by hour two.

Core count matters more than clock-speed bragging rights:

6 cores / 12 threads — the bare minimum for comfortable daily work. Fine for scripting, light web dev, general sysadmin tasks.
8 cores / 16 threads or more — where you actually want to be if your day involves compiling, running heavier Docker containers (RAM matters here too), databases, or a background full of questionable systemd units doing who-knows-what while you're trying to focus.

So why the cold shoulder to Intel? It's not personal — it's architectural. Their recent generations look exciting on paper: new process node, more cores, an NPU nobody asked for. But what kind of cores? P-cores and E-cores. So you look at a spec sheet that says "10 cores, 12 threads" and think you're getting a beast, except only 4 of those cores are the real performance ones and the rest are efficiency cores doing background busywork. Compile something heavy on that setup and you'll feel the difference immediately compared to a chip with 8 full, real, performance cores across the board that don't need to negotiate with the scheduler about who gets to do actual work.

This isn't an "Intel is bad" take — for pure single-thread desktop work with light multitasking, their newer chips are fine. But for sustained, parallel, compile-heavy, virtualization-heavy workloads on a laptop that also has to survive a battery-only train ride, AMD's approach is currently just a better fit for how we actually work.

RAM: The Single Biggest Priority

Minimum 16GB. Realistically 24–32GB. Why? One word: Electron.

Most of the apps we use daily are Electron shells with a full Chromium instance riding shotgun inside them, quietly drinking your memory like it's an open bar. Is the result nice? Sure, the design and styling are genuinely great, cross-platform consistency is genuinely convenient for the people building these apps. Does it cost you dearly in resources? Also yes, painfully so. Browsers in general (any engine that actually runs JS) eat more RAM than should be legal, and Discord — which is Electron through and through — will happily consume everything you give it on its own, no roommates required, no apology given.

If you run a browser with two dozen tabs, a couple of Electron apps, a Docker stack, and an IDE with a language server chewing through your codebase — 16GB is a survival number, not a comfort number. 32GB is where you stop thinking about memory pressure and go back to thinking about your actual work. If you can afford it and your workflow includes VMs or multiple containerized services running locally, don't be shy about going higher. RAM is one of the few upgrades that pays for itself in reduced daily frustration almost immediately.

Storage: Don't Cheap Out on the One Part You'll Never See

NVMe SSD, non-negotiable, minimum 512GB if you're a developer running multiple project directories, Docker images, node_modules folders that multiply like rabbits, and language toolchains that all insist on their own isolated environments. If you do anything with local ML models, containers, or VMs, go 1TB. Rotational drives died for a reason — let them rest in peace, they served their purpose in an era that is not this one.

One practical note: if you're buying a ThinkPad T or P series, check whether the SSD is user-replaceable before you buy. On most of these lines it still is, which means you can start at a reasonable storage tier and upgrade later instead of overpaying the manufacturer's storage markup on day one. That flexibility alone is worth factoring into the price comparison.

What Not to Buy (and Why)

This is the part of the post where I stop being diplomatic. Every category above tells you what to look for. This section tells you what to walk past in the store, no matter how nice the marketing photo looks.

Dell XPS (and its consumer-ultrabook cousins)

The XPS is the laptop world's answer to "what if we made a MacBook Pro, but beige-brained." It's a flagship consumer ultrabook, frequently benchmarked against the MacBook Pro, and on a shelf under store lighting it looks genuinely great. The screen is usually excellent.

Here's why it's still not our pick:

Keyboard: Perfectly fine for a normal person writing emails. Not ThinkPad-tier. Shorter travel, mushier feedback, and after eight hours of real work you'll feel the difference in your fingers.
Repairability: RAM is frequently soldered, the battery is a project to replace rather than a five-minute job, and the chassis isn't exactly inviting you to open it up.
Ports: Increasingly dongle-dependent. Standard USB-A and Ethernet are treated as optional extras rather than baseline expectations.
Price: You're paying a premium for the industrial design. For the same money you could get a ThinkPad with enough RAM to run a small datacenter and still have cash left for a proper docking station.
Thermals: Manufacturers keep cramming increasingly powerful Intel chips into increasingly thin chassis, which means fan noise and thermal throttling the moment you ask it to do something for longer than five minutes.

If you want a good-looking laptop for coffee shops and PowerPoint demos, the XPS will make you happy. Just don't try to compile a kernel on it — your fingers, and your ears, will file a formal complaint against the fan noise.

ASUS, Acer, and HP (the mass-market consumer lines)

This is where roughly ninety percent of the "consumer laptop" market actually lives, and it's also where most of the disappointment lives.

Keyboard: This is exactly the 1.0–1.3mm travel we talked about earlier, frequently paired with creaky plastic, backlighting that's somehow both too dim to be useful and too bright to ignore, and key legends that start wearing off within six months. A keyboard that exists purely so that a keyboard technically exists.
Chassis: Plastic, flexy, occasionally rattly. Hinges start feeling loose within a year of normal use.
Screens: Often TN panels, or IPS panels that technically qualify as IPS while offering color coverage and brightness that make you question the term.
Build quality and QC: A genuine lottery. Two units off the same production line can feel like different products.
Cooling: Close to nonexistent on the budget and mid-range models. Some of these throttle running a "Hello, World" compile.

If you go with a consumer-line ASUS, Acer, or HP, budget accordingly: the keyboard will start squeaking before you finish typing your first "Hello, World," and the screen will be actively working against you while you try to read logs at 1am. There are exceptions in their business lines, but the consumer segment is not where you go looking for a daily driver.

Gaming Laptops (Legion, ROG, Razer Blade, and friends)

I touched on these briefly before, but they deserve their own paragraph of roasting, because the mismatch between "gaming laptop" and "daily dev machine" is almost comedic once you actually live with one.

Aesthetics: Looks like a children's toy that got into steroids, glows every color of the rainbow, and generally screams about its own power to anyone within eyeshot — including in the middle of a client call.
Battery life: Lives about three hours away from an outlet, and turns into a paperweight faster than you can get Docker Desktop to finish starting up once it's unplugged.
Weight and portability: Heavier than your cat, and somehow heavier still than your conscience after a Friday-evening production deploy.
Price: You're paying full price for a GPU you don't need for software development, plus an RGB subsystem that will annoy your coworkers on a call far more than it will inspire you at your desk.

If you're a genuine gamer who also happens to code, fine, there's a real argument for a Blade or a Legion — just go in with eyes open about the trade-offs. If you're buying it purely because it looks powerful, you're paying a premium for a light show.

The Actual Recommendations for 2026

Here's where I put my money where my sarcasm is. ThinkPad T and P series are the backbone of this list — they're the machines built around exactly the priorities we've walked through: real keyboards, serious durability, sane thermals, and broad Linux compatibility, several of them formally certified for major distributions rather than just "should probably work." The L and E series exist as the honest budget compromise — you give up some polish and some display options, but you keep the ThinkPad DNA: the keyboard feel, the build quality, the repairability. That's a much better trade than saving the same money on a consumer-line ASUS or HP and losing all three.

For developers who live in Linux and want the best keyboard-to-power ratio:
A ThinkPad T-series AMD configuration is the sweet spot — Ryzen AI PRO silicon, a keyboard that doesn't apologize for existing, and enough balance for daily dev work without workstation pricing. If you need more screen real estate for a multi-pane coding setup, the larger 16-inch T-series models give you that at the cost of a bit more weight in your bag. Most current T-series configurations run mainstream Linux distributions without drama — Ubuntu, Fedora, and Debian derivatives all behave themselves on this hardware, which is exactly what you want when your job depends on your tools not fighting you.

For heavier local workloads — ML, CAD, big compiles, scientific computing:
Look at the ThinkPad P-series AMD line. These are ISV-certified workstation-class machines that let you push RAM capacity well beyond what the T-series offers. They're more expensive for comparable core specs, and some configurations run their fans hard under sustained load — but if you're compiling all day, running local models, or doing simulation work, that extra headroom pays for itself.

For the budget-conscious who still want the ThinkPad DNA:
The entry-level ThinkPad L-series and E-series bring genuine ThinkPad durability and keyboard feel without the flagship price tag. You lose the OLED option and some of the chassis polish, but the bones — the keyboard, the build quality, the general "this thing will survive being dropped in a hallway" attitude — are the same family. This is the honest, no-shame compromise pick, not a downgrade to avoid.

For design, video, and "I travel constantly and it has to just work":
MacBook Pro on an M-series chip. Buy something current, or at most one generation back — don't start with the oldest chip on the shelf just because it's the cheapest, you'll regret it in under two years. Yes, it's not Linux, and yes, you'll fight your muscle memory a little if you're coming from a tiling window manager and full shell control. But for color-accurate displays, battery life, and render performance per watt, this is the one non-ThinkPad exception on the list that earns its place.

A quick honorable mention for the Linux purists: if repairability and long-term upgradeability matter more to you than brand pedigree, it's worth putting a modular, community-favorite laptop brand on your shortlist — the kind built specifically around swapping your own ports, upgrading your own RAM, and running the same chassis for a decade. Not quite ThinkPad-tier keyboard, but the philosophy will resonate with anyone who already runs Arch "btw."

And for the Gamers, Since I Promised

I don't play much, but I've had to sit inside a game engine long enough to have an opinion: if gaming is genuinely your priority and coding is secondary, go in with eyes open about everything covered in the roast section above — the battery life, the weight, the noise. Just don't pretend to yourself that you're buying it "for development." You're buying it for the GPU, and that's a perfectly fine reason, as long as you're honest about it.

Bottom Line

Buy the keyboard first, mentally. Everything else — the CPU, the RAM, the screen — is a variable you tune around that constant. AMD if you're on Linux and value your battery and your sanity. 32GB of RAM if Electron apps are anywhere near your daily workflow (they are, don't lie to yourself). NVMe, always, and enough of it that you're not managing storage like it's 2010. A discrete GPU only if you actually need one, not because it's there.

Stick to ThinkPad T or P series if you can afford them, L or E series if you can't and refuse to compromise on build quality — and steer hard around the consumer-flagship trap of Dell XPS, the budget-plastic lottery of mass-market ASUS/Acer/HP, and the RGB tax of gaming laptops, unless you actually need what those specific categories are built for.

And if your current laptop still has a keyboard you enjoy typing on — for the love of all that's holy, don't "upgrade" into something worse just because it's newer. New isn't always better. It's just newer.

i use arch btw :>

I Turned My Blog Into a Daily Digital Magazine

Wed, 17 Jun 2026 03:44:27 +0000

Building a blog, maintaining a website, and writing consistently may look simple from the outside.

But I think they are one of the best ways to train your ability to think every day.

A blog is not just a place to publish finished thoughts.
It is a place where thoughts become visible.

That is why I decided to change my site into a daily magazine-style blog.

Starting today, I am trying a new routine.

Every morning, at a fixed time, I create a new visual background for the day.
Then I choose one question to think about and write an article around it.
After that, I look for recent AI updates, organize what matters, and place everything together like a daily issue of a small digital magazine.

Part of this process could be automated.

I could probably automate the background generation.
I could automate the content structure.
I could automate the update collection.
I could even make the whole thing feel like a publishing machine.

But I do not want to let go of the process too much.

Because once I automate everything, I might stop paying attention.

And for me, the most important part of this project is not just publishing.

It is the act of showing up every day, asking one question, reading carefully, checking what changed, and arranging those thoughts into something people can read.

That is the real experiment.

The site is becoming a daily digital magazine, but not in the traditional media sense.

It is more like a personal archive with a daily rhythm.

Each day has:

one main question
one written thought
recent AI updates
a new visual mood
a redesigned daily layout

I want the site to feel alive.

Not because everything is automated, but because someone is actually thinking behind it.

Later, I also want to build a subscription system.

If the quality becomes good enough, I would love to share these daily issues with people who are interested in AI, verification, writing, and the process of building something consistently.

For now, I am treating this as a small promise to myself.

One day.
One question.
One issue.

That is the new direction of my blog.

Not just a website.

A daily place to think.

How Readability Scores Work: A Practical Guide for Developers and Writers

Thu, 04 Jun 2026 10:05:14 +0000

Readability scores sound simple — paste your text, get a number, done. But the number is only useful if you understand what it actually measures.

The Two Scores You'll Encounter Most

Flesch-Kincaid Reading Ease runs from 0 to 100. Higher means easier:

| Score | Reading Level | Audience |

|---|---|---|

| 90–100 | 5th grade | Very easy, children's books |

| 70–80 | 6th grade | Easy, conversational |

| 60–70 | 7th–8th grade | Standard, most web content |

| 50–60 | High school | Fairly difficult |

| 30–50 | College | Difficult |

| 0–30 | Professional | Very confusing |

For web content, aim for 60–70.

Gunning Fog Index gives you an approximate grade level (US education system). A score of 8 means 8th-grade level. It counts words with 3+ syllables as "complex". Aim for 8–10 for general audiences; technical docs can go to 12.

What These Metrics Don't Measure

Both scores only look at sentence length and word length. They don't measure:

Whether your argument is logical
Whether jargon is appropriate for your audience
Whether your structure helps readers navigate
Whether your examples are clear

A sentence like "Run npm ci in the project root" would score as "very easy" because the words are short — but it's meaningless to someone who doesn't know Node.js.

When Scores Actually Help

Marketing copy: Aim for Flesch 70+. If you're below 60, you're probably writing for yourself.

Technical docs: Flesch 50–65 is fine. Keep surrounding sentences short even if technical terms are long.

Email: Flesch 70+ consistently performs better. Cut adjectives, shorten paragraphs.

Five Fixes That Actually Improve Scores

Split long sentences at conjunctions — "and", "but", "so", "because" are natural break points
Kill passive voice — find "was/were + verb" and invert it
Collapse noun stacks — "the configuration update process" → "updating the config"
Replace abstract nouns — "utilisation" → "use", "implementation" → "build"
Remove hedges — cut "somewhat", "fairly", "quite", "rather"

Check Your Own Writing

The SnappyTools Readability Checker gives you Flesch-Kincaid, Gunning Fog, reading time, and sentence length distribution in one pass. It highlights long sentences so you can fix them directly instead of rewriting everything.

No account needed. Paste text, get results, fix what's broken.

What kind of writing do you most often need to simplify? Technical docs, marketing copy, or something else?

Word Count, Character Count, and Why They Both Matter for Web Content

Sat, 30 May 2026 16:28:23 +0000

Word count and character count are two numbers writers track constantly — but for different reasons. Word count measures how much you've written; character count determines whether it fits. Here's a practical look at both, with the platform limits that actually come up in day-to-day writing.

Why word count matters

Word count is a rough proxy for content depth. Search engines don't rank by word count directly, but longer content tends to rank better for competitive keywords because it:

Covers the topic more thoroughly
Answers more related questions
Has room for semantically related terms

Empirical data from analysing top-ranking pages:

Highly competitive topics: 1,500–3,000 words for position 1
Medium-competition informational queries: 1,000–2,000 words
Local, transactional, or branded queries: 300–800 words

These are medians, not rules. A 400-word page can outrank a 3,000-word page if it's a better match for the query intent (especially for transactional or navigational searches).

For blog posts targeting informational queries, 1,200–2,000 words is a reasonable target for most topics. For technical documentation, completeness matters more than any word count target.

Word count by content type

| Content Type | Typical Range |

|---|---|

| Tweet | 20–40 words (≈ 140–280 chars) |

| Email subject line | 6–10 words |

| Push notification | 5–8 words |

| Meta description | 20–25 words (~120–155 chars) |

| Blog post intro | 50–150 words |

| Short-form blog post | 600–1,200 words |

| Standard blog post | 1,200–2,500 words |

| Long-form guide | 2,500–5,000+ words |

| Technical documentation page | Varies; completeness over count |

Why character count matters more for platforms

When you're writing for a specific platform — a tweet, a meta description, an email subject line — the character count is the hard constraint. Word count is a secondary concern.

Twitter / X

280 characters for standard accounts. This is not "280 characters approximately" — the tweet button greys out at exactly 280. URLs count as 23 characters regardless of length. Emojis typically count as 1 character (simple) or 2 (complex emoji sequences).

Practical tip: Write your core message in under 230 characters to leave room for a URL and hashtag.

Meta descriptions

~150–160 characters for display without truncation (Google measures pixel width, roughly 155 characters for average text). Under 120 characters and you're leaving available space empty. Over 160 characters and Google truncates with "…"

The meta description doesn't directly affect ranking — it's marketing copy for the SERP. A clear, action-oriented description at 140–155 characters improves click-through rate.

3,000 character limit for posts. Only the first ~210 characters show before "See more". Your opening hook determines whether people expand the post.

Email subject lines

50 characters or fewer for reliable display on mobile without truncation. The preview text (first ~90 characters of body) complements the subject line — write both together.

SMS

160 characters for standard ASCII. One emoji drops you to 70 characters per segment (Unicode mode). A 200-character SMS with one emoji sends as 3 segments — 3× the cost.

Characters to words conversion

Writers often need to convert between characters and words. These are rough averages for English:

| Characters | ≈ Words |

|-----------|---------|

| 100 | ~17 |

| 280 | ~47 |

| 500 | ~83 |

| 750 | ~125 |

| 1,000 | ~167 |

| 2,000 | ~333 |

| 3,000 | ~500 |

| 5,000 | ~833 |

| 10,000 | ~1,667 |

Based on an average English word length of ~5 characters plus a space (6 characters per word). Technical writing and German text skew longer; casual writing skews shorter.

Academic paper context:

| Assignment | Typical Word Count |

|---|---|

| 1-page essay | 275–300 words |

| 5-page paper | 1,250–1,500 words |

| 10-page paper | 2,500–3,000 words |

| Thesis chapter | 5,000–10,000 words |

A printed page is typically 250–300 words (double-spaced, 12pt font, 1-inch margins) or 500–600 words (single-spaced).

Reading time estimation

Reading speed for adults averages 200–250 words per minute for technical content, 250–300 WPM for general reading.

| Word Count | Est. Reading Time |

|---|---|

| 500 | ~2 minutes |

| 1,000 | ~4 minutes |

| 2,000 | ~7–8 minutes |

| 5,000 | ~17–20 minutes |

| 10,000 | ~35–40 minutes |

"X min read" estimates on Medium use 265 WPM as their divisor. This is a reasonable default for general content. Technical content with code blocks reads slower; scannable content with lots of subheadings reads faster.

Sentence and paragraph counts

Word count alone doesn't tell you much about readability. Two additional signals:

Average sentence length: Under 20 words per sentence is readable for general audiences. Over 30 words per sentence and comprehension drops. Academic writing often runs 25–35 words; news writing targets 15–20.

Paragraph length: For web content, 2–4 sentences per paragraph. Longer paragraphs reduce perceived readability on screens, especially mobile. White space is not wasted space.

Practical tools

A word and character counter that shows your word count, character count, sentence count, and reading time in real time makes it easier to hit targets without manually checking. Paste your draft and see immediately whether a meta description is in range, whether an SMS will split, or whether a blog post has reached minimum depth.

The most useful feature isn't counting — it's the instant feedback that tells you whether the text fits before you try to publish it.

Originally published at https://snappytools.app/word-counter/

Keyword Density in 2026: What It Is, What It Isn't, and How to Use It

Sat, 30 May 2026 10:49:49 +0000

Keyword density is one of the oldest SEO concepts, and also one of the most misunderstood. Here's what it actually measures, what the research says about optimal values, and how to use it as a diagnostic rather than a target.

What is keyword density?

Keyword density is the percentage of times a word or phrase appears in a text relative to the total word count.

Formula:

Keyword Density = (Keyword Occurrences / Total Words) × 100

Example: "SEO" appears 10 times in a 500-word article.

<code> <p>(10 / 500) × 100 = 2%</p> </code>`

A keyword density checker automates this calculation for every significant word in your text simultaneously — useful for auditing content without manually counting.

A brief history

In the early 2000s, some SEOs believed higher keyword density directly improved rankings. The practice of "keyword stuffing" — repeating target keywords as many times as possible — was widespread and temporarily effective.

Google's Panda algorithm update (2011) penalised thin and keyword-stuffed content. The industry consensus shifted: keyword density matters, but more as a ceiling (avoid stuffing) than a floor (hitting a magic percentage doesn't help).

By 2015–2016, Google had gotten good enough at understanding topic relevance that the discussion moved toward semantic coverage (covering related concepts) rather than keyword repetition rates.

What does the research say?

Studies of top-ranking pages consistently find:

Primary keyword density of 1–3% is common in high-ranking content
Keyword stuffing (above 5–6%) correlates with lower rankings
Below 0.5% may signal weak topic relevance, but context matters

These are correlations, not causation. Pages rank highly for many reasons; density is one factor among many.

The safest interpretation: 0.5–3% for your primary keyword is a reasonable range. Outside that range, investigate — under 0.5% may mean the topic connection is weak; over 3% risks appearing forced.

What keyword density doesn't capture

Keyword density is a blunt instrument. It doesn't measure:

Keyword placement. Search engines give more weight to keywords in titles, H1/H2 headings, first paragraphs, and anchor text than to keywords buried in body copy. Density doesn't distinguish between these.

Semantic coverage. Modern ranking systems (Google's BERT, MUM) understand topic coverage through related terms and concepts — not just exact keyword repetition. Writing "running shoes" 20 times is less effective than writing naturally about fit, cushioning, heel drop, and pronation.

User intent. A page about "Python" could be about the snake or the programming language. Density doesn't determine which intent you're serving.

Content quality. A 2,000-word page with 2% keyword density but thin information will underperform a 400-word page with 1% density and genuinely useful content.

TF-IDF: the more sophisticated alternative

TF-IDF (Term Frequency-Inverse Document Frequency) is the method search engines traditionally used before neural approaches. It measures not just how often a term appears, but how distinctive it is to your document compared to a corpus.

TF (Term Frequency): How often the term appears in this document. (Like keyword density.)

IDF (Inverse Document Frequency): How rare the term is across all documents. Common words ("the", "and") have low IDF; rare, specific terms have high IDF.

TF-IDF = TF × IDF

A high TF-IDF score means the term is both frequent in your document AND unusual in the broader corpus — a strong topic signal. SEO tools like Clearscope and Surfer SEO use TF-IDF analysis to suggest which terms to include.

For most writers, TF-IDF analysis is overkill. The practical implication is: covering the topic naturally, including related subtopics and terminology, achieves the semantic coverage that TF-IDF formalises.

How to use keyword density practically

During content audit

Paste existing content into a keyword density checker and look for:

Target keyword absent or under 0.5% — the page may not be clearly signalling its topic. Add the keyword more naturally in headings and intro.

Target keyword over 4% — review whether the usage sounds natural. Reduce repetition and use synonyms or related terms.

Unexpected dominant words — if "actually" or a company name appears more than your topic keyword, the page may not be well-focused on its intended topic.

Before publishing

Run a density check on new content to catch:

Accidental repetition from drafting and revising
Under-coverage of the primary keyword you're optimising for
Over-coverage that might trigger a spam filter

For competitor research

Check what words appear at highest density in top-ranking competitor pages for your target keyword. This surfaces related terms they're covering that you may have missed.

What to optimise instead

If you're spending significant time obsessing over keyword density, you're probably optimising the wrong thing. Higher-impact SEO activities:

Content depth and completeness. Fully answering the search intent, including common follow-up questions, outweighs precise density management.

E-E-A-T signals. Expertise, experience, authoritativeness, trustworthiness — demonstrated through accurate information, cited sources, and author credentials.

Page speed and Core Web Vitals. Loading time affects ranking. Minified CSS/JS and properly sized images matter.

Internal linking. Linking to your page from relevant internal content passes authority and helps Google understand the page's relationship to your site's overall topic.

Backlinks. External links from relevant sites remain one of the strongest ranking signals.

A practical rule of thumb

Write for humans first. Cover the topic thoroughly. Read the draft aloud — if a keyword sounds repeated and unnatural, reduce it. If the piece never uses the target term, add it naturally in the opening paragraph and key headings.

After writing, do a quick density check to verify the keyword is present at a reasonable frequency. That's keyword density used properly — as a sanity check, not an optimisation target.

The goal is for the page to be the best available answer to the search query. Keyword density is a proxy for relevance, but relevance comes from content quality, not arithmetic.

Originally published at https://snappytools.app/keyword-density-checker/

Flesch-Kincaid Explained: How to Measure (and Improve) Your Writing's Readability

Sat, 30 May 2026 10:45:34 +0000

If you have ever wondered whether your writing is too complex, or whether your documentation is actually readable, the Flesch-Kincaid readability formula has the answer. Here is what it measures, how to interpret the score, and what to do about it.

What is the Flesch-Kincaid formula?

Rudolf Flesch developed the original readability formula in 1948 while working for the Associated Press. J. Peter Kincaid adapted it for the US Navy in 1975 to evaluate training manuals. The result was two related metrics:

Flesch Reading Ease score:

RE = 206.835 - (1.015 × ASL) - (84.6 × ASW)

Where:

ASL = average sentence length (words per sentence)
ASW = average syllables per word

The score runs from 0 to 100. Higher = easier.

Flesch-Kincaid Grade Level:

<code> <p>GL = (0.39 × ASL) + (11.8 × ASW) - 15.59</p> </code>

Same inputs, different weights. The output maps directly to US school grades — Grade 8 means an average 8th grader can understand it.

How to read the scores

| Reading Ease | Grade Level | What it means |

|---|---|---|

| 90–100 | 5th grade | Very easy. Comics, simple instructions. |

| 70–80 | 6–7th grade | Easy. Plain English. Many newspapers. |

| 60–70 | 8–9th grade | Standard. Most web content targets here. |

| 50–60 | 10–12th grade | Fairly difficult. Academic writing, corporate comms. |

| 30–50 | College | Difficult. Academic journals. |

| 0–30 | Professional | Very difficult. Legal documents, medical literature. |

For most web content — documentation, blog posts, marketing copy — a reading ease of 60–70 and grade level of 8–10 is the target.

Famous publications as benchmarks:

The Sun (tabloid): Reading Ease ~65, Grade 8
The New York Times: ~60, Grade 10
Harvard Law Review: ~32, Grade 16+
IKEA instructions: ~80+, Grade 6

What drives complexity

Looking at the formula, only two things matter: sentence length and word length (in syllables).

Sentence length is the biggest lever. A 30-word sentence contributes far more to complexity than a 15-word sentence with a few long words. When you split a long sentence in two, the score improves noticeably.

Word length (syllables) is the second factor. The formula doesn't care about word frequency or meaning — it counts syllables. "Approximately" (5 syllables) scores worse than "about" (1 syllable) regardless of context.

This means:

Short sentences + short words = high readability
Long sentences + long words = low readability

The formula can be gamed (write nothing but "The dog ran." sentences) but it correlates well with comprehension in practice.

What the formula doesn't measure

Flesch-Kincaid is a formula, not a human. It doesn't evaluate:

Clarity — whether the idea itself is clearly expressed
Logic — whether the argument follows
Vocabulary — whether you're using the right word, just the shorter one
Tone — formality, warmth, authority
Structure — paragraph organisation, headings, visual hierarchy

A text can score Grade 6 and still be incomprehensible if the ideas are jumbled. A Grade 12 text can be perfectly clear if the complexity serves the subject.

Use readability scores as a signal, not a target. If your grade level is consistently above 14 for content aimed at general readers, that's a useful diagnostic.

Checking your writing's readability

You can check the reading level of any text using an online readability checker — paste your text and get all six scores at once. No signup, no character limit, runs in the browser.

Practical improvements

When your readability score is too low:

1. Split long sentences. Find every sentence over 25 words and break it in two. This is the single highest-impact change.

2. Replace multi-syllable words with shorter equivalents:

"approximately" → "about"
"utilise" → "use"
"endeavour" → "try"
"commence" → "start"
"demonstrate" → "show"

3. Cut passive voice. "The report was written by the team" → "The team wrote the report." Active voice is shorter and more direct.

4. Break up paragraphs. For web content, aim for 2–4 sentences per paragraph. Short paragraphs increase perceived readability even when individual sentences are complex.

5. Remove redundant qualifiers. "Very unique", "absolutely essential", "completely finished" add syllables without adding meaning.

6. Use subheadings. Not captured by the formula but dramatically improves reader navigation and comprehension, especially for skimmers.

The right target

Different audiences warrant different targets:

Technical documentation for developers: Grade 10–12 is acceptable and expected — your audience reads this stuff for a living.
Blog posts and marketing copy: Grade 8–10, Reading Ease 60–70.
Healthcare content for patients: Grade 6 or lower, Reading Ease 70+.
Legal content that must be understood by the general public: Grade 8 target (many jurisdictions now require this).

The US government's plain language guidelines recommend Grade 8 for all public-facing documents. The NHS aims for Grade 7.

Readability formulas are over 70 years old and still widely used because they capture something real — the cognitive load of parsing long sentences and complex vocabulary. Use them as a calibration tool, not a constraint, and your writing will almost always be clearer for it.

Originally published at https://snappytools.app/readability-checker/

The Fastest Way to Lose Users Is to Make Them Feel Stupid

Mon, 18 May 2026 12:53:59 +0000

One thing I’ve noticed working around developer products:

Users can forgive bugs.
They can forgive missing features.

But they rarely forgive confusion.

Especially the kind of confusion that makes them feel like they’re the problem.

The Mistake Most Teams Don’t Notice

A lot of products explain things like this:

“Simply configure…”
“Just connect…”
“Obviously, you’ll need to…”

Those words seem harmless.

But to a new user, they create pressure.

Because when something doesn’t feel “simple,” the user starts thinking:

“Maybe I’m missing something.”
“Maybe I’m not technical enough.”

And once users feel that way, they stop exploring confidently.

Good Documentation Does Something Bigger Than Explain

It reassures.

It guides.

It makes users feel capable.

That’s why the best onboarding experiences don’t just teach users what to do…

They help users feel smart while doing it.

What I Focus On When Improving Documentation

I usually look for moments where users might pause and think:

“Wait… what does this mean?”

Those small moments matter more than teams realize.

Because confusion compounds quickly.

One unclear step becomes hesitation.
Hesitation becomes frustration.
Frustration becomes abandonment.

A Small Change That Makes a Huge Difference

Instead of writing:

“Simply authenticate using your token.”

You can write:

“Paste your API token here to connect your account. Once connected, you’ll be able to make your first request.”

Same action.

Completely different experience.

One assumes knowledge.

The other guides the user.

The Truth Most Teams Learn Late

Users don’t leave because they’re not smart enough.

They leave because the product made them work too hard to understand it.

Final Thought

A good product solves problems.

A great onboarding experience removes intimidation.

If users are struggling to get started with your product, API, or platform…

That’s usually the gap I help teams close.

What I Learned About AI Writing Mistakes While Writing Stories

Thu, 12 Feb 2026 21:02:31 +0000

I didn't start using AI to take shortcuts. I was just curious. Could an AI actually help me write better stories? I've worked with words for years, so I wanted to see what happens when human creativity meets machine-generated text.

What I found surprised me. There were clear AI writing mistakes that kept showing up. But these mistakes taught me something important about what makes good storytelling work.

Pretty Words That Feel Empty

The first AI drafts looked great. Perfect grammar. Nice flow. Beautiful descriptions. On paper, everything seemed fine.

But something was missing. When I read those scenes carefully, they felt hollow. Characters talked about being sad or angry, but I didn't feel it. Problems appeared and disappeared too neatly. The writing was polished but emotionally distant.

This is one of the biggest AI writing mistakes in fiction. The surface looks good, but there's no real depth underneath. AI learns from patterns in text, but it hasn't lived a life. It hasn't felt grief or joy. So when it writes about emotions, it's just arranging words, not sharing experience.

Readers can tell the difference, even if they don't know why.

Dialogue That's Too Perfect

AI can write conversations that make sense and sound intelligent. But real people don't talk like that.

Every character in my AI drafts spoke the same way: clear, organized, grammatically perfect. Nobody interrupted anyone. Nobody left sentences hanging. Nobody said one thing while meaning another.

That's not how humans actually talk.

This showed me a key limitation of AI storytelling. Real dialogue is messy. People stumble over words. They contradict themselves. They hide what they really mean. Without fixing this manually, AI conversations sound like robots having a polite chat.

I had to go back and add the messy parts; the pauses, the arguments, the things left unsaid. That's when the dialogue started feeling real.

Everything Wraps Up Too Neatly

After working on several AI-assisted stories, I noticed a pattern. Tension built at predictable times. Problems appeared clearly. Solutions arrived right on schedule.

It was efficient, sure. But it felt fake.

One of the sneakier AI writing mistakes is making everything too clean. Real life doesn't work like that. Consequences stick around. Decisions create new problems. Emotional wounds don't heal on a perfect timeline.

The best change I made? I stopped letting my characters off easy. I delayed solutions, added complications, and left some tensions unresolved. Suddenly, the story felt alive.

Words Without Memory

Here's the big lesson: AI knows the vocabulary of emotion. It can put words like "grief," "joy," "fear," and "hope" in all the right places.

But it doesn't have memories.

When I write about sadness, I'm remembering something: a quiet hospital room, a text message that never got answered, a silence that pressed against my chest. Those memories shape how emotion appears on the page.

AI builds emotion from statistics. It knows what words usually go together. The result reads okay, but it doesn't carry weight. This is at the heart of most AI fiction writing challenges and why editing is so crucial.

Fast Drafts Can Make You Lazy

AI's biggest strength is speed. You can generate entire scenes in seconds. At first, this felt amazing. But I realized something. Speed can make you sloppy.

When drafts appear instantly, it's tempting to skip the hard part: the thinking, experimenting, and deep revision that produce original work. You feel productive, but your writing might actually be getting shallower.

One of the most dangerous AI writing mistakes for writers is treating the first draft as good enough. The real creative work starts after the AI finishes, when you roll up your sleeves and start editing.

How AI Actually Helped Me

Despite all these problems, AI didn't hurt my writing. It made it better.

Editing flawed AI drafts forced me to think harder about storytelling. I started asking better questions: Why does this character want this? Does this emotion feel real? Is the pacing right? Does this conflict matter?

AI became less of a writing tool and more of a mirror showing me what needed work.

When used thoughtfully, AI is helpful for:

Brainstorming ideas
Trying different directions for a scene
Getting rough drafts down fast
Finding weak spots in your structure

But good fiction still needs human judgment, emotional truth, and careful rewriting.

Mistakes That Point Toward What Matters

The biggest shift in my thinking: I stopped seeing AI writing mistakes as just problems to fix.

Instead, they became clues pointing me toward what makes storytelling human.

When AI produced flat emotion, I knew to add specific, lived details. When dialogue sounded robotic, I added psychological tension and subtext. When conflict resolved too easily, I made the consequences stick around.

Each fix made the story stronger and showed me the line between automation and art.

What I Know Now

After all this experimenting, one thing is clear.

AI can generate language. It can build a structure. It can even create interesting story beginnings. But storytelling is more than just putting words together. It's turning memories into meaning, conflict into growth, and emotions into connection.

That still takes a human.

The fact that AI writing mistakes exist doesn't mean AI is worthless. It just shows where human creativity is irreplaceable. The future of writing won't be all AI or all human. It'll be both; machines handling the grunt work, humans protecting the meaning.

And from everything I've seen, the soul of storytelling remains beautifully, stubbornly human.

For more in-depth information

Can AI Actually Improve Your Novel?

Tue, 10 Feb 2026 19:57:05 +0000

A Real Test of ChatGPT for Writing Fiction

AI tools like ChatGPT are changing how people write novels. These tools can brainstorm plots, create characters, and even write full chapters. Many writers are excited. They can finish their books faster than ever.

But there's a big question we need to ask.

Does AI make your novel better? Or does it just make writing faster?

This article shares real results from testing ChatGPT across all stages of novel writing. We'll look at structure, emotion, voice, and editing. The goal is simple: understand what AI really does to your story.

The Main Challenge: Speed vs Quality

Writers have always looked for better tools. First came typewriters. Then word processors. Then grammar checkers and editing software. AI is just the newest tool in this long line.

But fiction writing isn't just about speed.

A great novel needs:

Deep emotions
Real characters
Strong conflict
Unique voice

If AI makes you faster but weakens these parts, it might not be worth it. Every writer needs to understand this trade-off.

How I Tested AI Writing

To test AI fairly, I needed a clear process. Here's what I did:

Step 1: I wrote a rough chapter with basic structure, dialogue, and story direction.

Step 2: I used ChatGPT to improve it. I asked for help with:

Making the structure clearer
Adding more emotion
Fixing the pacing
Making dialogue sound real
Editing at the sentence level

Step 3: I compared both versions. I looked at:

How easy they were to read
Their emotional impact
How clear they were
How well the story flowed

Step 4: I gave an honest review of what worked and what didn't.

This method shows real results, not just theory.

Test 1: Structure and Story Flow: ChatGPT For Novel Outline

AI is very good at finding structure problems. When I gave ChatGPT my rough chapter, it quickly:

Made scene goals clearer
Fixed slow pacing
Removed repeated information
Improved transitions between events

These changes made the story easier to follow. For early drafts, this help can save hours of revision time.

But there's a downside. AI sometimes makes things too simple. It might remove complexity that was artistic on purpose. Writers need to decide: Does your story need clarity or subtlety?

Test 2: Emotion and Character Voice: ChatGPT For Emotional Scenes

Emotional realism makes or breaks fiction. Readers connect with characters who feel real and conflicted.

ChatGPT helped by:

Adding internal thoughts
Making reactions stronger
Improving dialogue tone
Matching character actions to their motivations

These changes made scenes more expressive and immediate. For writers who struggle with flat emotions, AI can be a helpful partner.

But AI has limits here. The writing it creates may:

Over-explain feelings
Make emotions too intense
Use common emotional phrases

True literary subtlety—what's implied, not stated—still needs human judgment.

Test 3: Sentence Editing and Readability: AI Content Refinement

At the sentence level, AI works very well. ChatGPT quickly:

Fixed grammar and punctuation
Made complex sentences simpler
Improved clarity and rhythm
Removed extra words

These fixes took my rough draft to near-publishable quality in minutes. For self-published authors or writers without professional editors, this is huge.

But aggressive editing can erase your unique style. Perfect grammar doesn't always make compelling prose. The best approach is to treat AI edits as suggestions, not final answers.

Where AI Falls Short: AI Writing Mistakes

Despite its strengths, AI has clear weaknesses:

Generic Description AI often uses familiar metaphors and images. This reduces originality.
Too Much Emotion Subtle tension gets replaced with obvious explanation. This weakens the story.
Same Voice Problem Different characters—or different authors—start to sound alike after heavy AI editing.
Missing Deep Themes AI can organize story elements well. But deeper philosophical or symbolic meaning needs human intention.

Understanding these limits is key to using AI responsibly.

The Final Answer: Should You Use AI?

The evidence points to a balanced answer.

In practice, the best novels come from human creativity leading with AI support. Writers provide vision, voice, and emotional intelligence. AI provides speed, organization, and technical polish.

This is a partnership, not a replacement.

The Future of AI in Writing

As AI gets better, its role in fiction will grow. Future tools may offer:

Better voice matching
Improved memory for long stories
More nuanced emotions
Collaborative editing spaces

Even so, storytelling stays fundamentally human. Readers want perspective, meaning, and real experience. These come from consciousness, not computation.

The most successful writers won't rely entirely on AI. They'll learn to guide these tools without giving up creative control.

Final Thoughts

AI can absolutely improve parts of your novel—especially structure, clarity, and editing speed. But better technical quality doesn't automatically mean better art. The real power of AI is in collaboration.

When used thoughtfully, it amplifies imagination. It doesn't replace it. In this partnership between human insight and machine intelligence, a new form of storytelling is quietly taking shape.

References:

Why I Write

Tue, 16 Sep 2025 22:37:59 +0000

I’ve been thinking lately about why I write. Not in the mechanical sense of sitting down with a blank page and stringing words together, but the deeper reason why I keep showing up to it.

For me, writing is not just about publishing a blog post, an essay or a reflection. It’s about clarity. Thoughts tend to be messy when they live only in the mind. Writing forces me to wrestle with them, to order them, and to strip away the fluff until only the essential remains. Each piece I write is an exercise in refining my thought process and communication.

Writing also makes me a better learner. When I’m learning something new, the temptation is to nod along and assume I understand. However, when I try to explain it in writing, the gaps become immediately apparent. I can’t hand-wave my way past them. In this way, writing is a mirror for my own learning, it demands precision and it rewards intentionality.

There’s also a teaching element to it. Teaching is one of the most effective ways to reinforce knowledge and writing is teaching at scale. The internet allows me to connect with people I’ve never met and may never meet. That’s a powerful idea, that by putting my thoughts out there, I can create bridges with strangers across the world.

Beyond skill and connection, writing has a career dimension. A well-written piece can open doors you didn’t even know existed. It signals how you think, how you approach problems and what you care about. Opportunities often flow toward clarity.

But perhaps the most personal reason is this: writing is my way of letting loose my thoughts and spreading ideas. It gives me space to explore, experiment and share without asking for permission.

So why do I write?

To think clearly.
To learn better.
To teach and connect.
To grow.
And to express.

That’s enough reason to keep at it and why getting back to writing felt like returning to something essential.

Brain Dump

Sun, 08 Jun 2025 20:36:49 +0000

Brain Dump is a simple, frictionless, distraction-free note-taking app designed to help you declutter your thoughts, boost clarity, and organize your ideas. With instant search, merge notes, and iCloud sync, it’s a lightweight companion for your brain.

Why BrainDump?

Instant writing, open the app and start writing immediately
Ask any question about your notes
Turn your notes into summaries, meeting reports, to-do lists, tweets, emails, blog posts, presentations, reports, questions, flashcards, translations
Merge notes, combine multiple notes into one note
Sticky notes, open notes in separate windows, choose color, size and whether to keep them on top of everything else
Sync with iCloud, backup your notes automatically and access them across all your Apple devices
Offline & Private, no accounts, no logins, no ads. Just secure, personal note-taking
Available for iPhone, iPad, Mac and Vision Pro

Perfect For:

Writers & Bloggers – Draft articles, brainstorm ideas, and write distraction-free
Students & Researchers – Take lecture notes, study notes, and organize class materials
Professionals & Entrepreneurs – Manage task lists, project notes, business ideas, and meeting notes
Creatives & Thinkers – Capture inspirations, creative ideas, daily reflections, and storyboards

Try it now

How I’ve Been Using AI as a Force Multiplier

Sun, 11 May 2025 13:37:06 +0000

I’ve been optimizing my AI workflow for tasks that aren’t my core passion (writing) but are necessary to sustain it—marketing, sales, admin, etc. Here’s the system:

Task Selection: Pick a repeatable task (e.g., drafting outreach emails).
Expert Sourcing: Find a YT expert or guide who teaches it well.
Instruction Extraction: Use AI to distill their methodology into step-by-step instructions.
Context Injection: Add my own examples, edge cases, or domain-specific tweaks.
Meta-Prompt Creation: Have AI compress everything into a high-agency “employee prompt.”
Iterate: Test, refine, and reuse. The prompt evolves into a specialist.

Why It Works

Precision: Leverages proven frameworks but adapts them to my needs.
Scalability: Once a meta-prompt is battle-tested, it’s a fire-and-forget tool.
Non-Destructive Automation: For creative work (like writing), AI stays in a research/feedback role. For the “business stack,” it’s a tireless executor.

Dev Angle
Think of it like training a model on a custom dataset: the better the input (expert knowledge + your context), the better the fine-tuned output. No black magic—just structured iteration.

P.S. If you’re into this kind of workflow hacking, I break down more of my experiments in Substack. No fluff, just systems.

Getting Started with Technical Writing: A Beginners Guide

Mon, 24 Mar 2025 21:09:47 +0000

Getting Started with Technical Writing: A Beginners Guide

Have you ever been confused about a technical concept and then stumbled across a blog or article that broke it down so simply that it felt like the author was explaining it directly to you? That article was likely written by a Technical Writer.

Technical writing has become crucial across various sectors and fields as it helps companies and teams effectively communicate and share information with their customers or audience. Without clear communication, businesses risk creating a disconnect with their audience—a gap that can ultimately lead to their downfall.

In this article, you will learn more about what technical writing entails and why it is important. In the end, I will also show you things you should know about being a technical writer.

Let's dive right in.

Outline

What is Technical Writing
Applications of Technical Writing
Key Characteristics of Technical Writing
Types of Technical Documents
The Technical Writing Process
Conclusion

What is Technical Writing?

I know you might be asking, "What is technical writing?" So, before we go deeper, let's examine what technical writing is all about.

In technical writing, you break complex information down into simpler, more easily understandable documents. This helps your audience understand and use the tool, programming language, or concept you’re writing about. So technical writing is all about breaking down complex ideas into smaller, understandable chunks.

It’s also important to note that the people who break down this complex information in this way are referred to as technical writers. Now that we’ve gotten this out of the way, let's move on.

Applications of Technical Writing

Now you might be thinking that technical writing is only for people in tech, but that’s not the case. Though it has been traditionally used most often in tech, it’s becoming common in other fields as well.

Below are various fields where technical writing can be super helpful, along with some use cases:

1 Information Technology: Though the tech space is very vast, technical writing can be used for:

Writing product or framework documentation for beginners, mid-level, and senior personnel.
Writing How-to guides
Writing UI docx to help people navigate a product

2 Health Field: Shocking as it may seem, technical writing is also applied in this field. Here are some places it can be applied:

Creating documentation for healthcare software.
Writing how-to guides for manuals for medical devices or equipment.
Producing regulatory and educational documents for both patients and staff.

3 Finance and Banking: Technical writers are also found in the finance and banking sectors. Here are some of their tasks:

Creating training manuals and developing user-friendly guides for services or financial products.
Creating regulatory documents for both staff and customers.

4 Aerospace and Defense: Here are some common tasks for technical writers in this field:

Preparing reports and compliance documents for regulatory bodies.
Creating detailed how-to manuals or guides on how an aircraft or defence system functions.
Writing/creating safety protocols for staff to abide by.

These are a few areas where technical writing has become quite common. But trust me, there are many more fields where it can be applied.

At this point we are done with the surface of what technical writing is and its importance. Now let’s go further to see the characteristics of a technical writer.

Key Characteristics of Technical Writing

To write a technical document, there are three important things you have to keep in mind:

Clarity and conciseness: When it comes to writing documentation, one of the things you should think about is how clear and straightforward the content is. It's best to read and reread it to make sure it’s very easy to understand and that some unnecessary words are filtered out of the documentation.
Audience awareness: Your audience should be one of your top priorities when writing a technical document. It’s essential to identify who they are, their level of education, and what they hope to gain from reading your document. By understanding these factors, you’ll be better equipped to address their needs and solve their problems effectively.
Use of visuals and formatting: Adding visuals can significantly enhance the reader's understanding of your technical document. For instance, if a reader initially grasps only 40% of the content, a well-designed visual (like charts or diagrams) could increase their comprehension to around 90%. Additionally, how your document is formatted is crucial in providing clarity. Proper formatting can maximize the reader's understanding, potentially reaching 100%. This ensures that the reader achieves the purpose of consulting your technical documentation in the first place.

Types of Technical Documents

Just as we previously talked about various fields where technical writing can be applied, you should know that there are various types of technical documents needed in these fields. Below are the most commonly used documents across all fields:

User Manuals and User Guides: These are practical guides designed to help users understand how a product works or how to navigate processes within an organization. They can include step-by-step instructions or serve as a reference for regulations and best practices.
Reports and Proposals: Reports are written to share findings, provide analysis, or give updates on a specific task or decision. They are widely used in organizations, regardless of size, to communicate important information. Proposals, however, are meant to persuade or convince others to support or approve a project or plan.
Documentation: Documentation, just as it sounds, helps users understand and use a product. It provides detailed solutions to possible problems that could be encountered by a user.

The Technical Writing Process

As promised, here are things you need to know as a technical writer. Before you think of writing a technical document, it is important that you know the three stages of writing, and they are:

Pre-Writing Stage
Writing Stage
Post Writing Stage

Pre-Writing Stage

The pre-writing stage is a very important stage in writing, as it takes up the major part of your technical writing process, which is the topic research, information gathering of the agreed topic, etc.

Here are things to consider in the pre-writing stage.

Audience and purpose: This is where you consider who the audience/readers you are writing to are, what their educational background is, and also what issue you are trying to solve for them by writing the document.
Tone and style: After you have figured out the basic/important information about your target audience, the next thing for you to consider is how you can present your technical document to them for them to understand. In most cases, your target audience might be the Chief Executive Officer (CEO) or Chief Financial Officer (CFO) of a large firm/organization, so by identifying them, you should be able to write in a tone and style that resonates with them.
Gathering of Information: This is the point where you do proper research about the information you want to write about. For example, if you want to write a “How-to” manual for a specific product, you must have done deep research about the product or, if possible, used the product for a while; this will give you enough evidence/facts to write about that product effectively.
Outlining: At this point, you’ve figured out who your target audience is, you’ve figured out the tone and style to write to them, and you’ve also gathered enough information on the topic you want to write about. An outline makes the remaining process easy for you. Outlining is more like a guide; it shows you what to do at a particular point, and it also helps in the proper formatting of your technical document.

Writing Stage

This is the phase where the actual writing takes place. During this stage, three key aspects are considered:

The main content or body of the technical document
The development of Paragraphs within the document
Ensuring coherence and adherence to genre conventions.

Post-Writing Stage

This is the final phase of the writing process, where you focus on:

Assessing the quality and organization of your content.
Ensuring grammatical accuracy.
Thoroughly editing your manuscript
Conducting proofreading and seeking peer reviews of your work.

Conclusion

At this point, you can see how important technical writing is and how it closes the huge gap between companies and their audience/customers.

As an individual, getting a technical writing skill is an added advantage to you because of how important it is in our day-to-day lives.

Thanks for reading, and peace.

Discover how to use AI writing tools without losing your authentic voice as a content creator.

Fri, 11 Oct 2024 21:16:13 +0000

Be Real: How to Use AI Writing Tools and Stay Authentic

Once you've read one ChatGPT article, it feels like you've read them all. The phrase "Let's dive in" is forever tainted, and the cheesy metaphors are a dead giveaway that you're reading AI-generated content. In this blog, I'd like to talk about my experience using AI writing tools in my own blog. I'll go over different methods I've tried, their pros and cons, and how I'm using AI to write now. My aim is to share my experience in a way that helps you keep your authentic voice so that you don't come across as just another AI blog writer.

If you’re like me, you've probably experimented with AI at some point and realized that while it can help you pump out blogs quickly, it also removes that human element from your content that it used to have. So why would anyone want to use AI-generated content in their blog? Firstly, it saves time and effort! But don't be fooled! Saving too much time and effort will tank not only the quality of your work but your reputation too! Now, I get it. When ChatGPT first came out, I did what most other people did: "ChatGPT, write me a blog about xyz." Then maybe you do a little proofreading, ask it to make some changes, and post it to your blog. Suddenly, producing new content is so easy that you're able to keep up with publishing a blog a day! Woohoo, right? Not really.

The obvious downside to this approach is what I mentioned in the first sentence of this blog. The cheesy metaphors and the overuse of phrases like "Let's dive in." If you're not a subject matter expert, or lazy, it's really easy to put out either inaccurate or misleading information. Many times, when reviewing AI-generated content, I’ve found much more efficient ways to achieve the same results when I’m trying to produce more technical guides. Additionally, people are tired of reading content generated by AI. They want something from a real person who’s an actual subject matter expert! They want something authentic. So what’s the solution? That’s right—it’s time to ditch AI-generated content!

AI-Generated Content vs. Human-Generated Content

Have you ever read a blog and thought, "This was for sure wrtten by AI"? People don’t want to read an article they feel like was created by an empethic robot. They can easily prompt an LLM to do that themselves. They’re looking for your unique human touch and expertise. When you’re discussing a subject you have years of experience in, there’s so much nuance you can add to your content that AI could never capture. That’s what people crave! They want to hear about your personal experiences. What are some of the real joys and pitfalls you’ve encountered along your journey? Have you run into an issue that’s caused you trouble more than once? It’s anecdotes like these that provide real value and build your authenticity. The brand is you. Sure, AI can pull the facts together, but it’s not living your life or walking in your shoes. It can't bring in that experience or those weird anecdotes that makes your work stand out. You just can’t fake those kinds of things. They have to come from you.

That’s the difference between AI-generated content and human-generated content. But just because it’s human-generated content doesn’t mean that AI can’t play a role in making your life easier. After realizing this, my next evolution was to write human-generated content that was AI-edited. This approach was better but still not perfect. So how can we use AI as a tool to help with our writing without letting it take over and drown out our voice?

Using AI To Edit Your Human-Generated Content

The first way I improved my terrible AI blog-writing workflow was to train a ChatGPT conversation on ALL of my blogs that I wrote before ChatGPT ever came out so that it could understand my “voice” as an author better. Then I would write the rough draft, let whatever I was thinking come out, give that to ChatGPT, and have it turn my loose rough draft into a bonafide blog. This was much better than before. Now I was able to capture my own experiences, nuance, and opinions and have ChatGPT use my “style” to turn it into a final draft blog. This definitely takes more effort, but being able to turn a 30-45 minute-long freewriting session into a final draft blog ready to publish is still a huge win and time saver! Plus, there’s this air of consistency in my blogs now that wasn’t there before.

However, it still wasn’t perfect. Getting comments like, “This feels very LLM generated” on my blog, Why Writing Your Own Tools is More Important Than You Think, really hurt. I took time out of my day to write my honest opinions about writing your own tools and the benefits and even drawbacks that come with it. Regardless of being edited by ChatGPT, that blog still reflects how I feel about the topic. However, it seems like my approach had put a stain on my reputation and damaged my authority as an author. That hurt. But sometimes, experiencing that kind of hurt is exactly what you need! So yes, it was something I wrote, edited by AI trained to sound like me, but it was obvious that the end product still didn't sound like me. The fact was, I was still trying to take a shortcut to the top, and people noticed. Having your real experience and nuance reduced to “This feels very LLM generated” is not a good feeling. So what’s a blogger, author, or content creator to do?

It’s time to stop being lazy!

Do I Still Use AI?

Yes, I do! However, I’m no longer letting AI write or rewrite my content anymore. Not only am I doing my followers and fans a disservice by giving my voice as an author over to AI, but I’m also doing myself a disservice by not continuing to hone my craft and writing style. Writing is a huge passion of mine. If I give that passion away to AI to do for me, what’s to stop me from giving away my other passions to AI? Should I let AI play and write music for me? Should I let AI skateboard for me? No! What makes passions so beautiful is that the joy doesn’t come from the end product, it comes from the process! If I let AI write my blogs for me, what joy do I get out of writing blogs? And for what? I want to build something real and authentic that means a lot, not just to me, but to other people as well. I want to find the joy in this blog and my writing as I go along. I’m not in this game for cheap tricks, and I’m not doing this so I can build some kind of cash cow where one day I’ll sit on the beach and sip on margaritas every day. I want to build something meaningful that lasts, and I’m in this for the long haul.

Using AI Moving Forward

So what’s my plan for using AI in my content generation moving forward? First of all, AI is great at grammar and spelling, which I’m very bad at. If programmers were good at spelling, we wouldn’t have invented spell check! So I plan to use AI to grammar-check my work. Additionally, there are three other key areas where I plan to use AI when it comes to content creation:

Feedback: Bugging friends to pre-read my blogs and give me good feedback isn’t feasible, and I can’t afford to pay people to do that for me. So having something I can ask, “Is this good?” or “What are some ideas for improving xyz?” is very nice. Then I can take that feedback and apply my own voice when implementing it.
Research: AI and LLMs are great research tools! I can have them do Google searches for me and summarize articles and videos I find through my own searches, helping me get the most meaningful data I need to create whatever blog I’m working on.
Blog banner creation: Let’s face it, MidJourney is cool. I love using it, and I plan to continue using it to create banners for my blogs moving forward.

Now, will I be able to produce a blog a day anymore? Not really. However, while the quantity of my blogs will go down, the quality and authenticity of my blogs will rise! I’m really looking forward to creating higher-quality content for you all than ever before. No more shortcuts, no more cheap tricks. Just me. :)

So what about you? How have AI writing tools shaped your writing? Share your thoughts in the comments below!

Join The Community

If you like what you’ve read, love to code, and are a fan of Linux, open source, and building your own projects, you’d probably have a great time in my Discord community, The Developers Lounge! We’re a rapidly growing community with lots of great people with a diverse set of skills among us. I’m super active in here, and we have a ton of cool people just waiting to chat. So what are you waiting for? Hop on in!