DEV Community: Demilade Ayeku

Take time to read

Demilade Ayeku — Tue, 21 Jul 2026 05:58:49 +0000

Demilade Ayeku

Jul 21

You Didn't Build a System. You Wrote a Script.

#ai #programming #productivity #career

6 min read

You Didn't Build a System. You Wrote a Script.

Demilade Ayeku — Tue, 21 Jul 2026 05:58:13 +0000

Somewhere in the last two years, everything became a system.

A Python script that calls the OpenAI API and writes to a database? System. A Zapier automation that pings Slack when a form gets submitted? Integration. Two prompts chained together? Agent architecture. A dashboard with three widgets? Platform.

If you've been reading tech LinkedIn or tech Twitter recently, you've felt this. The vocabulary has inflated. And if we're being honest, I've done it too. Somewhere in a bio, a repo README, or a hackathon submission last year, I called something a "system" that wasn't. On inspection, a script with delusions of grandeur.

The AI era gave everyone new vocabulary. What it didn't give everyone is the actual thing the vocabulary describes. And the gap between the words we use and the things we've built is turning tech writing into a costume party.

How we got here

Two forces pointing the same direction.

First, LLMs write like corporate blog posts. Large language models are trained on the internet's dominant register, which was already inflated. When someone opens ChatGPT and asks it to "help me write a post about my project," the model reaches for the vocabulary it saw most in its training data: system, integration, pipeline, orchestration, seamless, robust, production-ready. The model doesn't know your project is a 60-line script. It just knows this is how tech writing sounds. So it makes your script sound like AWS.

Second, the AI wave itself created a whole category of things that genuinely are systems. Real agent frameworks. Real model routing infrastructure. Real retrieval pipelines with real error modes. That vocabulary is legitimate when applied to those things. But it's bled sideways into projects that are nothing like them because when a "real" AI agent is one thing and a script with an LLM call is another, calling both agents makes the second one feel current.

The net effect: we're all writing above our own actual complexity level. And most readers can't tell, which is exactly why it works, and exactly why we should stop.

The catalog

Five of the biggest offenders. For each: what it's become, what it actually was, and what a more honest sentence looks like.

"System"

Inflated: "I built a system for tracking user behaviour on our platform." Actual: "I wired up PostHog and added event calls in the frontend."

A system has components. Architecture. Tradeoffs between parts. If your "system" is one script or one integration and one place data ends up, it's not a system. It's a hookup. Call it that.

"Integration"

Inflated: "I integrated Stripe with our platform for seamless payments." Actual: "I imported the Stripe SDK and wired up a checkout page."

Integration used to mean two systems learning to talk to each other in a durable, maintained way with error handling, retries, monitoring, and someone who owns the seam. Calling an SDK import an "integration" flattens what the word used to carry. The honest version is often just: I used their SDK.

"Agent"

Inflated: "I built an agent that summarises meeting notes." Actual: "I wrote a function that sends the transcript to Claude and returns the summary."

The word "agent" now implies autonomy, planning, tool use, and decision-making across multiple steps. A one-shot LLM call in a for-loop isn't an agent. It's a function that happens to call an LLM. There's nothing wrong with that; it's often exactly the right level of complexity for the job. But calling it an agent oversells the thing and underprices what a real agent is.

"Pipeline"

Inflated: "I built a data pipeline that ingests customer signals across sources." Actual: "I wrote a script that pulls from three APIs into a Google Sheet on cron."

A pipeline has stages, transformations, error boundaries, retries, backpressure handling, and observability. Sequential API calls into a spreadsheet are not that. It's a fetch job.

"Production-ready"

Inflated: "The system is production-ready and enterprise-grade." Actual: "It runs on my machine and hasn't crashed in the last hour."

Production-ready means specific things: error handling, structured logging, observability, tested under load, deployable, secure, and someone on-call when it breaks. Enterprise-grade means those things plus SLAs, compliance, and multi-tenant safety. If your thing has none of that, it isn't either. It's a working prototype which, again, is a fine thing to have.

Why this matters (beyond aesthetics)

Two reasons that go past "it's annoying."

One: the informed reader can tell instantly. Every senior engineer, every experienced DevRel person, every technical founder who reads your inflated post is doing the same mental subtraction, reading through the vocabulary to figure out what you actually built. When they get to the bottom and realise it was a script, the vocabulary has cost you their trust. You lost credibility with the exact readers you most wanted to reach. The words that were supposed to make you sound smart made you sound the opposite.

Two: AI assistants can't extract specific claims from vague writing. In a previous post, I wrote about William Imoh's framing of AEO — how content now has to be citable by AI assistants (ChatGPT, Perplexity, Claude), not just rankable on Google. Inflated writing fails at exactly this. When Perplexity is generating an answer to "how do I connect Stripe to my Next.js app," it needs to pull a specific instruction, a real example, a named library, a working pattern. A blog post that says "we integrated Stripe seamlessly into our production-grade platform" gets skipped. A blog post that says "we added @stripe/stripe-js in the client and set up a /api/checkout handler with the secret key in an env var" gets quoted.

Specificity is the new SEO. Vocabulary inflation is the opposite of specificity. That's the DevRel cost.

How to write like you actually built it

A few working principles I've been trying to hold myself to. Not rules. Habits.

Use the smallest accurate word. Script if it's a script. Function if it's a function. SDK call if that's what it is. Reach for bigger words only when the smaller ones stop being accurate.

Prefer verbs over nouns. "I connected X to Y" lands harder than "I built an integration between X and Y." Verbs describe action. Nouns describe abstractions. Action is what actually happened.

Name the specific pieces. "An LLM call using Claude Sonnet 4.5 with a system prompt and a tool definition" beats "an AI-powered agent workflow" every time, and it's shorter.

Show, don't classify. Instead of describing what category your project belongs to ("a scalable, production-ready AI observability platform"), describe what it does in a single specific sentence a reader could verify. If a reader couldn't verify it, don't claim it.

Cut the two most dangerous adjectives: robust and seamless. Both mean nothing. Both signal that you're describing rather than building. If your work is robust, the description of what it handles will make it obvious. You don't need the word.

Re-read your draft as a skeptical senior engineer. For every claim, ask: if I said this at a whiteboard, could I defend it? If not, cut it or downgrade it. Most inflated writing dies the moment it's read out loud.

The meta point

DevRel is, at its core, an act of translation, taking something real and complex and rendering it so the reader actually gets it. Every word that inflates instead of clarifies is a step against the job.

In an era where anyone can generate confident-sounding tech writing in three seconds, precision is the differentiator. Not vocabulary. Not tone. Not tables. Precision.

The best technical writers I read now are moving in the opposite direction from the AI-inflated norm. Shorter words. More specific verbs. Fewer adjectives. A quiet confidence that comes from actually knowing what they built.

So, that project on your GitHub? Read the README. If the first paragraph reads as it came out of a corporate deck, it probably did. Rewrite it as if you were telling a senior engineer at a bar what you actually built. That version is the one people will trust. That version is the one AI assistants will cite. And that version is, funnily enough, the one that will make you sound smarter, because it will make you sound like someone who actually built the thing.

This is the third piece in a series on honest technical writing. The first covered what DevRel actually is; the second, the Comparison Test for honest "X vs Y" content. Common thread: specificity beats performance, every time. 🥑

Most "X vs Y" Developer Content Wouldn't Survive a Real Build

Demilade Ayeku — Tue, 30 Jun 2026 09:57:50 +0000

The problem with most comparison content

If you've ever searched "Solana vs Sui" or "Drizzle vs Prisma" or "Polars vs Pandas," you know the shape of what comes back.

A clean feature table. A vague "best for" paragraph at the bottom. Maybe a chart of GitHub stars. And nothing in it would help you make an actual decision.

That's because most "X vs Y" content is written from documentation. Not from builds.

A writer opens both sets of docs, extracts the feature lists, organises them into a table, and adds enough hedging that no vendor gets upset. The post ranks. It gets cited. And it leaves the reader exactly where they started, except now they think they've done their research.

In a recent DX mentorship session, William Imoh (founder of HackMamba) walked us through why this matters more right now: comparison content is the AEO wedge. When a CTO asks ChatGPT or Perplexity "which of these tools should I use for X", the model surfaces whatever comparison content best answers the question. The comparisons that win citations from AI assistants are not the ones with the prettiest tables. They're the ones with the most specific, evidenced answers.

Which means we have an honest content gap and the people who can fill it aren't writers. They're builders who write.

The Comparison Test

Here's the test I run on any "X vs Y" piece I read now. Four questions. A piece that passes all four is rare, and worth bookmarking. A piece that fails any of them is decoration.

Did the author actually ship something end-to-end on both sides?

Not a hello-world. Not a sample app cloned from the README. Something that has a real user flow, real state, real failure modes. If they only built on one side and read about the other, the comparison is theatre.

You can usually tell within two paragraphs. Real builds produce specific complaints about toolchain bugs, missing primitives, weird gotchas in the deployment story. Doc-readers produce generalities "developer-friendly," "well-documented," "growing ecosystem."

Can they name a bug they hit on each side?

This is my favourite question because nobody can fake it. If you genuinely shipped on a tool, you have stories. The 3am moment when something compiled fine but produced wrong output. The version mismatch that ate two hours. The undocumented edge case in the SDK.

A comparison post with no bugs in it is a marketing document. A comparison post that names two bugs one per tool is a signal that the author actually wrestled with both.

Do they tell you which one not to use, and when?

The cleanest tell that a comparison is honest. Most posts are scared to say "don't use X if you're doing Y" because they want to stay friends with everyone. But that's exactly the recommendation a reader needs.

Honest comparison content has opinions that could cost the author a partnership. That's the entry fee.

Would the author's recommendation change if the reader's stack was different?

This one separates the thoughtful comparisons from the merely opinionated. A real builder knows that "X is better than Y" is almost never true in isolation, it's true for a specific stack, team size, scale, or workflow. A good comparison helps you locate yourself on the map, not just pick a winner.

If a post recommends the same tool to a solo founder and to a 50-person engineering org, the author isn't thinking carefully enough.

Why this matters more in the AEO era

The shift William named in our session that content now has to be cited by AI assistants, not just ranked on Google changes the economics of comparison content in a specific way.

Google rewarded coverage. A long comparison post with all the keywords could rank even if the actual analysis was thin. AI assistants reward specificity. When Perplexity is generating an answer to "should I use Drizzle or Prisma for a small team building an API," it needs to extract a specific recommendation grounded in specific reasoning. Vague comparison content gets passed over because the model can't pull a clean answer from it.

The result: comparison content written by people who've actually shipped is going to start outperforming comparison content written from docs, because the former has the specific evidence the model needs to cite.

Which is funny, because for years the incentive was the opposite. Doc-readers could spin up volume. Builders were too busy building. AEO inverts that,the build is the moat.

What this means if you build in public

If you're a developer who ships across multiple ecosystems — even informally, even just at hackathons, you already have raw material that most content marketers don't.

Every multi-chain project you've shipped is a comparison post you haven't written. Every time you tried a new framework and bounced off it is a "Why I moved from X to Y" piece you haven't written. Every time you debugged something at 3am on one platform that worked first-try on another is a paragraph that would beat a thousand feature tables.

The bar for AEO-grade comparison content isn't writing skill. It's specificity. And specificity is just the residue of having built.

A small invitation

I'm going to start writing more comparison content from inside my builds; multi-chain stuff first, since that's where most of my recent work has been. If you've shipped on multiple competing tools and have honest opinions about which one to use when, I'd genuinely love to read what you'd write.

Drop the URL of an "X vs Y" comparison you've actually read and trusted in the comments. I'm collecting examples of comparison content that passes the test, for my own reference and for anyone else trying to write it.

This post builds on a session with William Imoh in the DX mentorship program (founded by Ekene Eze). The comparison-as-AEO-wedge framing is his. The Comparison Test is mine. 🥑

What I Thought DevRel Was vs. What It Actually Is (A Mentee's Honest Take)

Demilade Ayeku — Mon, 25 May 2026 11:20:40 +0000

A few weeks ago, if you'd asked me what "DevRel" stood for, I would've squinted, smiled, and given you a confident-sounding non-answer. Today I'm in a DevRel mentorship program so let me close that knowledge gap for you the way it got closed for me

The "Before": What I Thought DevRel Was

When I first heard the term Developer Relations (DevRel), my brain did what most people's brains do; it grabbed the two words and built a half-decent guess.
"Oh, so… you relate to developers? Like, customer support for developers?"

Not quite.

I also assumed it was basically being a tech influencer. Someone who posts on Twitter/X, shows up at events with a branded hoodie, and tells everyone how amazing their company's product is. Half marketing, half cheerleader.
Also not quite.

The "During": What DevRel Actually Is

Here's the cleanest definition I can give you:
DevRel is the bridge between a company that builds tools for developers and the developers who actually use those tools.

Think of it like this: imagine a company builds a really powerful kitchen appliance, but only professional chefs can figure out how to use it. That appliance will flop; not because it's bad, but because nobody knows how to get value out of it. DevRel is the team that writes the cookbook, hosts the cooking class, listens to chefs complain about the buttons, and then walks back to the engineers and says, "Hey, can we move this button?"

In tech, that "appliance" is usually an API, an SDK, or a developer tool. The "chefs" are software developers around the world. And DevRel is the function that makes sure the two actually connect.

One thing my mentor said in our first session that stuck with me:
"You should be a developer(Even at beginner level) before you become a developer advocate."

This is the part that demolished my "tech influencer" theory. You can't honestly bridge two worlds if you only live in one of them. If you've never written code, you don't know which parts of a product are confusing, broken, or magical. You can talk to developers, but you can't speak with them.

The Three Cs of DevRel
The work itself breaks down into three pillars what folks in the field call the 3 Cs:
🧑🏽‍💻 Code — DevRel folks build things. They use the product themselves, ship demo apps, write sample code, and feel the same friction real developers feel. This is how they earn the right to speak.
✍🏽 Content — They turn the product into something learnable. Documentation, tutorials, blog posts, videos, livestreams, conference talks. If you've ever Googled "how to do X with [some tool]" and landed on a guide that actually made sense; that was probably DevRel's work.
🤝🏽 Community — They show up where developers gather. Hackathons, meetups, conferences like DevFest Lagos, Discord servers, Twitter/X spaces. They're not there to sell; they're there to listen, teach, and build genuine relationships.
A DevRel person who only does one of the three? good but can be better. A DevRel person who weaves all three together? That's the real job.

The "After": How I'm Actually Getting Started

I won't pretend I've figured this out. I'm at the very beginning; accepted into a mentorship program. But here's what "getting started" looks like in practice:

Becoming a developer first. Not optional. Before I can advocate for developers, I need to be one, even at a beginner level. Code is the foundation that everything else stands on.
Learning from people already doing it. A few I'm watching closely:
Tejas Kumar — chief developer advocate, podcast host, and one of the clearest voices on what DevRel actually is and isn't. His ConTejas Code podcast has a whole episode dedicated to a deep dive into DevRel.
Sodiq Akinjobi — Developer Ecosystem Community Manager at Google and one of the organisers behind GDG Lagos and DevFest. If you want to see community-building done well in Africa, watch what he ships.
Joshua Omobola — a true polymath whose work cuts across engineering, writing, and community from Supertokens to Web3Afrika. The kind of multidisciplinary profile that DevRel rewards.
Timonwa Akintokun — DevRel Engineer at IQ AI, working on ADK-TS (the Agent Development Kit for TypeScript). She literally sums up the job on her site as "Code, content, and community that's what I do." Iconic. Also, a reminder that this field has space for women doing absolutely cracked work, and the more visible that is, the better.
Putting myself out there. Which is what this blog post actually is. Writing in public is one of the best things you can do, you're practising content, learning to explain, and inviting feedback at the same time. (This is me practising.)

A Quick Word on Career Paths

DevRel isn't one job; it's a family of jobs. You can specialise as a Developer Advocate, a Technical Writer, a Community Manager, a Developer Experience (DX) Engineer, or a DevRel Engineer. Some lean more toward code, some toward content, some toward people. There's no single ladder, which is intimidating at first but freeing once you accept it.

So… What Do You Take From This?

If you're a fellow developer wondering whether DevRel could be a fit, it is if you like teaching and you don't mind being visible.
If you're non-tech and you've read this far, congratulations! You now understand a corner of tech that even a lot of tech people don't fully get. The next time someone says they work in DevRel, you'll know they're not doing tech support, and they're not just an influencer. They're the bridge.
And if you're somewhere in between, welcome to the club. I'll see you out there!

This post is part of my journey through the DX mentorship program. I'll be writing more as I learn. Feel free to follow along, or share your thoughts in the comments on what you thought DevRel was before reading this. I'm collecting answers!🥑