DEV Community: Chizurum Chidimma Enyinnaya

The Developer Who Only Knows How to Code Is Becoming Easier to Replace

Chizurum Chidimma Enyinnaya — Wed, 23 Sep 2026 08:31:34 +0000

Writing code used to be the hard part. It's turning into the easy part, and that's a problem for a lot of developers.

A few months ago, I sat in on a conversation between a startup founder and his lead engineer. The founder asked a simple question: "If I gave you an AI tool that could write eighty percent of our codebase tonight, what would you do tomorrow?" The engineer paused for a long time before he answered. That pause told me more about the state of software careers than any report I've read this year.

For the last twenty years, knowing how to code was the whole job. You learned a language, you learned a framework, you memorized syntax, you practiced until the logic came naturally, and that was enough to build a career. Companies paid well for people who could translate a business need into working software, because that translation required years of training most people didn't have.

That scarcity is gone. It didn't disappear overnight, but it disappeared.

What changed isn't the code. It's who can produce it.

AI coding tools can now write functions, debug errors, refactor messy files, and explain unfamiliar codebases faster than most humans can type the question. A junior developer with six months of experience and a good AI assistant can now produce output that used to take a mid-level engineer a full day. The tools aren't perfect, and they still make mistakes that require a trained eye to catch, but the baseline skill of "I can write working code" is no longer rare. It's becoming a commodity.

This is uncomfortable to say to people who spent years building that skill, so most articles avoid saying it directly. I won't avoid it. If your entire professional identity is "I know how to code," you are standing on ground that is shifting under you, and the shift isn't slowing down.

The developers who are safe aren't the ones who code the fastest.

I've spent close to a decade writing for founders, engineering leads, and technical consultants, which means I've had a front row seat to hundreds of conversations about what actually makes a developer valuable to a team. A pattern shows up again and again. The developers who survive every round of budget cuts, every reorg, every "we're exploring AI tools to cut headcount" conversation, are rarely the ones with the cleanest syntax. They're the ones who can do the things a language model still can't do on its own.

They can sit in a room with a confused stakeholder and figure out what the business actually needs, because half the time the stakeholder doesn't know how to ask for it correctly. They can look at a piece of AI-generated code and know, almost instinctively, where it will break in production, because they understand the system it's sitting inside, not just the function in front of them. They can make a judgment call about which technical debt is safe to leave and which will sink the product in six months. They can explain a technical trade-off to a non-technical founder without making that founder feel small.

None of that shows up on a resume as a skill. It shows up as trust. And trust is exactly what's hard to automate.

A story that stuck with me.

Two developers I've worked with, both at similar tech companies, both roughly the same experience level, ended up on opposite paths within a year of AI coding tools becoming standard at their companies. One treated the tools as a threat and quietly kept doing things the old way: writing everything by hand, resisting the new workflow, measuring his worth by how much of the code was "his." Within a year, he was being managed more closely, given smaller tasks, and eventually let go during a round of layoffs that targeted redundant technical roles.

The other developer did something different. She used the AI tools aggressively, but she spent the time she saved on the things the tools couldn't do. She started sitting in on product meetings she wasn't required to attend. She began writing short internal notes explaining why certain technical decisions mattered for the business, not just the codebase. She became the person other engineers asked when something felt "off" about a piece of AI-generated code, because she had the judgment to explain why. A year later, she wasn't just still employed. She was leading a small team.

The difference between them wasn't talent. It was what they chose to build once the coding itself stopped being the bottleneck.

Coding is becoming the floor, not the ceiling.

For a long time, the industry treated "can this person write code" as the finish line of hiring. It's turning into the starting line. The real questions companies are starting to ask sound different: Can this person understand a problem well enough to know what to build in the first place? Can they catch what a machine misses? Can they explain their reasoning to someone who isn't technical? Can they take ownership of an outcome, not just a ticket?

These are the same questions companies have always claimed to care about. What's new is that they no longer have a reason to settle for less, because the pure coding skill they used to have to pay a premium for is now available on demand.

This doesn't mean coding skill is worthless. A developer who deeply understands how systems work will always write and review code better than one who doesn't, AI tools or not. But knowing how to code is no longer a career on its own. It's a foundation that something else has to be built on top of.

What I'd tell a developer trying to stay ahead of this.

Stop treating your value as the number of lines you can produce. Start paying attention to the parts of your job that involve judgment: deciding what should be built, catching what's wrong before it ships, explaining decisions to people who don't share your technical background. Use AI tools without shame, the developers pretending they don't exist are the ones falling behind fastest. Spend the time you save learning the business side of whatever you're building, because understanding the "why" behind a project is exactly the layer that's hardest to replace.

And if you're early in your career, don't chase the version of "good developer" that existed ten years ago. That version is already being phased out. Build the version that knows how to think, not just how to type.

The developers who only know how to code aren't disappearing because coding stopped mattering. They're becoming easier to replace because coding stopped being enough.

A must read

Chizurum Chidimma Enyinnaya — Thu, 17 Sep 2026 19:11:16 +0000

Chizurum Chidimma Enyinnaya

Sep 17

Why Technical Skills Alone Don't Always Create Opportunities

#tfhdailystandup #ai #webdev #productivity

4 min read

Why Technical Skills Alone Don't Always Create Opportunities

Chizurum Chidimma Enyinnaya — Thu, 17 Sep 2026 19:09:52 +0000

I once worked with a developer who could solve problems most senior engineers struggled with, yet he spent two years applying to roles and getting silence in return. Meanwhile, people with far thinner resumes were landing interviews, speaking at meetups, and getting pulled into projects through people who already knew their names. The gap wasn't ability. It was everything sitting around the ability that nobody had taught him to build.

This is one of the harder truths in any technical or creative field: skill gets you in the room only if someone already knows the room exists and thinks to invite you into it.

The myth that skill speaks for itself

There's a comforting idea that quality work eventually gets noticed on its own, that if you just keep getting better, the right people will find you. It's a nice story, and it's rarely how things actually play out. The internet is full of excellent code nobody uses, well-written books nobody reads, and strong portfolios nobody opens. Being good is not the same as being visible, and being visible is not the same as being connected to the people who can actually hand you an opportunity.

Opportunities don't flow toward competence in a straight line. They flow through relationships, referrals, reputation, and timing, with competence acting as the thing that keeps the opportunity once you have it rather than the thing that gets it to you in the first place.

Skill has become table stakes

Part of why this matters more now than it used to: technical skill is far less rare than it once was. Free courses, open documentation, AI coding assistants, and a decade of online tutorials have made it possible for a motivated person almost anywhere to reach a competent level in most technical disciplines. That's a genuinely good thing, but it also means competence alone doesn't separate you from thousands of other competent people.

The same shift has happened in creative work. Anyone can learn to write clean prose, design a decent interface, or edit a passable video. What's harder to copy is a track record people trust, a network that vouches for you, and a body of visible work that lets a stranger judge your thinking before they ever talk to you. Those things take longer to build than a skill does, and they're exactly what decides who gets picked when two similarly skilled people are competing for the same opportunity.

What actually moves the needle

A few things consistently separate people who turn skill into opportunity from people who stay skilled and stuck.

Visibility. If nobody outside your immediate circle knows what you can do, you're relying entirely on the small number of people who already know you to hand you every opportunity you'll ever get. Writing about your work, sharing what you're building, answering questions publicly in your field: all of it does the quiet work of letting strangers discover you before they need you.

Communication. Being able to explain your thinking clearly, in writing or out loud, matters almost as much as the thinking itself. A brilliant solution nobody can understand rarely gets chosen over a decent solution someone can clearly follow and trust.

Relationships. Most real opportunities, the well-paid ones, the interesting ones, the ones that change the trajectory of a career, arrive through a person, not a job board or a cold application. Someone remembers you, thinks of you when a need comes up, and makes the introduction. That only happens if you've spent time actually being known to people, not just skilled in private.

Reputation. Skill tells people what you can do in theory. Reputation tells people what you're actually like to work with: reliable, easy to communicate with, someone who finishes what they start. Reputation is built slowly, through consistent behavior over time, and it does more to open doors than any certificate.

Timing and proximity. Sometimes it really is about being in the right conversation at the right moment. You can't fully engineer that, but you can raise your odds by being present in more of the places where those conversations happen: communities, events, comment sections, group chats, open-source threads.

Why this hits developers especially hard

Technical culture sometimes teaches people to distrust anything that isn't strictly measurable, and that includes distrusting the soft, relational work of building visibility and connection. It can feel like self-promotion, or worse, like something separate from "real" work. But a developer who writes about the problems they solve, contributes visibly to projects, and shows up consistently in developer communities is playing a completely different game than one who only ever writes code in private repositories. Both might be equally skilled. Only one of them is findable.

The same applies to creators. A skilled writer who never publishes where other writers gather, never comments, never shares process, is invisible in a field full of people who do all three. Talent stays private until you decide to make it public.

Community as the missing piece

This is where community earns its place again, separate from audience-building. A community isn't just where you find feedback on your work. It's where opportunities actually travel: the referral someone makes because they've watched you show up consistently, the collaboration that starts because someone already trusts how you think, the client who comes through a member who vouched for you instead of a cold pitch that got ignored. Skill sits inside you. Opportunity moves through people. Community is the structure that lets it move toward you instead of past you.

If you've been doing the harder, quieter work of building your skills and wondering why the opportunities haven't matched the effort, the missing piece is rarely more skill. It's usually the visibility, relationships, and community that skill alone can't buy.

That's exactly what I built The Growth Room for: a space for developers and creators to be seen, to connect with people who can actually open doors, and to grow alongside others instead of in isolation. If that's what you've been missing, come join us: The Growth Room.

Why Developers and Creators Need Communities, Not Just Audiences

Chizurum Chidimma Enyinnaya — Thu, 17 Sep 2026 18:59:26 +0000

The difference between people who consume your work and people who build alongside you

A year ago, I sent a newsletter to several thousand subscribers and felt nothing back. No replies, no discussion, just open rates and click counts telling me people had seen the words without ever really meeting me in them. That gap, between being seen and being known, is the reason this topic sits close to me.

An audience watches. A community works.

An audience is a collection of people paying attention to you. A community is a group of people paying attention to each other, with you somewhere inside that circle instead of standing in front of it. The difference sounds small until you need something an audience can't give you: honest feedback on unfinished work, a second pair of eyes on a bug you've stared at for six hours, someone who remembers your last project and asks how the new one is going.

Developers understand this instinctively when they're inside a good open-source project or a well-run Discord for a language or framework. Nobody there is performing for followers. People are trading real problems and real answers, in public, where anyone can learn from the exchange. That's a community. The GitHub stars and the download numbers are the audience layer sitting on top of it, and they matter, but they aren't where the actual value gets made.

Why audiences alone leave you exposed

An audience is rented, not owned. It lives on a platform that can change its algorithm, shadowban your account, or shut down entirely, and the relationship you thought you had disappears with one policy update. I've watched writers with six-figure follower counts on a single platform lose most of their reach overnight because a feed changed how it ranked content. Nothing they had built was actually theirs.

Audiences also give you a strange kind of loneliness. You can have ten thousand people reading your code tutorials or your essays and still have no one to call when the ideas run dry or the project stalls. Attention flows one direction. It tells you that people are watching, not that anyone is with you.

What developers specifically get from community that they don't get from followers

Developers live inside fast-moving tools, frameworks, and standards that shift every few months. No single person keeps up with all of it alone. A real community becomes a distributed brain: someone has already hit the exact error you're hitting, someone has tested the library you're about to depend on, someone knows the workaround that isn't in the documentation yet. That kind of help doesn't come from an audience. It comes from people who have some stake in seeing each other succeed.

Community is also where a lot of developers get their first real users, their first collaborators, and eventually their first hires or co-founders. The person who tested your side project at 2 a.m. and left a detailed bug report cares more about you shipping something good than any passive follower ever will. Those relationships compound in ways a follower count never does.

What creators get that followers can't give

For writers, designers, and other creators, community solves a different problem: the isolation of making things alone. Writing is already a solitary act. Add a platform that only lets people like or scroll past your work, and you can spend years creating without ever having a real conversation about what you made. A community changes that. People ask questions about your process. They tell you which parts landed and which didn't, and they mean it, because they're invested in more than a single post.

Community also solves for retention in a way audiences never do. A follower can vanish the moment the algorithm stops showing them your content. A community member who has made friends inside your space, who has a reason to show up beyond your latest post, stays. That's the difference between building something that needs constant new attention to survive and building something that sustains itself.

How to tell a real community from a group chat with a name

Not every group with a name and a join link is actually a community. The test is simple: do the members talk to each other when you're not in the room? Does the group solve real problems, or does it just react to whatever you post? A real community has its own momentum. People show up for each other, not only for you.

That's the standard I've been building toward with my own work, and it's the reason I started The Growth Room. It isn't a place to watch me post. It's a place for developers and creators to trade real feedback, real accountability, and real help with the work you're actually trying to build, alongside people who are building too.

If that's the kind of space you've been missing, come join us: The Growth Room.

Before You Add Another AI Tool, Find the Task Slowing You Down

Chizurum Chidimma Enyinnaya — Wed, 16 Sep 2026 16:38:57 +0000

The problem was never the software. It's the step you never named.

I have a folder on my laptop called "Tools to try." It has forty two entries. Some are apps I downloaded and opened once. Some are browser tabs I bookmarked and never returned to. A few are subscriptions I forgot to cancel, quietly draining five or ten dollars a month for a feature I used exactly once, back in March, for a project I can barely remember now.

For a long time I believed the folder was proof that I hadn't found the right tool yet. Each new AI product felt like it might be the one that finally closed the gap between how much I wanted to produce and how much I was actually producing. So I kept adding to the list. A transcription tool. A summarizer. Something that promised to turn a messy voice note into a clean outline. Something else that claimed it could write a first draft so good I'd barely need to edit it.

None of them fixed the thing that was actually slowing me down. And it took me embarrassingly long to admit that the thing slowing me down wasn't a missing tool at all.

The tool is the easy answer

When work feels slow, adding a tool is the most comfortable response available. It requires no confrontation with your own process. You don't have to sit with the uncomfortable question of why a task takes as long as it does. You just open a new tab, sign up for a free trial, and tell yourself that this time, things will move faster.

This isn't a character flaw. It's a completely reasonable reaction to how AI products are marketed. Every tool promises to remove friction. Every landing page shows a before and after: hours of manual work reduced to minutes. It's an appealing story, and sometimes it's even true. But it's only true if the tool is solving the actual bottleneck, and most of the time, we don't know what the actual bottleneck is. We just know that something feels hard, and a new tool feels like relief.

So we chase relief instead of diagnosis. And a year later, we have forty two tools in a folder and the same task still takes just as long as it did before.

The task you haven't named

Here's what changed things for me. I stopped asking "what tool would help" and started asking a much smaller, much more specific question: which exact step, in which exact task, takes longer than it should?

Not "content creation is slow." Content creation isn't one task. It's a chain of small tasks stitched together: coming up with an idea, researching it, structuring it, writing a first draft, editing that draft, formatting it, publishing it, and sometimes repurposing it into three other formats. Each of those steps has a different shape. Each one can be slow for a completely different reason.

When I actually sat down and timed myself through a single piece of writing, start to finish, I found that the draft itself wasn't my slow part. I write fast once I know what I'm writing. My slow part was the fifteen minutes before I started, when I'd open a blank page and stare at it, unsure of the angle. That fifteen minutes happened almost every single time, and it added up to hours across a month. No writing tool in the world was going to fix that, because the problem wasn't writing. The problem was deciding what to write about before I wrote it.

Once I named that specific task, the fifteen minutes of staring at a blank page, I could actually evaluate whether a tool would help with it. Not content tools in general. Just that one narrow thing. And the answer turned out to be a simple prompt template I built myself, not a new subscription.

That's the pattern worth noticing. A vague problem invites a vague solution, and vague solutions rarely stick. A precise problem, on the other hand, tells you exactly what to look for, and sometimes it tells you that you don't need a new tool at all.

How to find your actual bottleneck

If you want to try this yourself, the method doesn't require anything complicated. For one full day, or even just one task, write down how long each step takes. Not the whole project. The steps inside it.

If you're doing client work, break it into: understanding the brief, researching the topic, drafting, revising, formatting, and delivering. If you're managing a team, break it into: checking messages, deciding priorities, delegating, following up, and reviewing finished work. Whatever your work looks like, it's made of smaller pieces, and one or two of those pieces are almost certainly eating more time than the rest combined.

Once you see it written down, the slow step usually surprises you. It's rarely the part you assumed. People often think their writing is slow when really their research is slow. People think their design work is slow when really it's the back and forth approval process that drags on for days. The tool folder gets filled with solutions to problems we haven't actually confirmed we have.

Testing a tool against the real problem

Once you know your actual bottleneck, testing a tool becomes much simpler. You're no longer asking "is this tool impressive." You're asking one narrow question: does this tool make my specific slow step faster, without creating a new slow step somewhere else.

That second part matters more than people expect. A tool that saves you twenty minutes on drafting but adds fifteen minutes of prompt writing and cleanup hasn't actually saved you much. A tool that automates one task but requires you to learn an entirely new interface, migrate your files, and retrain your habits might cost you more time in the first month than it saves in the next six.

I've started giving every new tool a short, honest trial against my actual bottleneck, not against a vague sense of whether it seems useful. If it doesn't touch the specific step I identified, I don't add it. It doesn't matter how good the tool looks in a product demo. A brilliant tool solving a problem I don't have is still a distraction.

What this looks like in practice

These days, before I open a new AI tool, I ask myself three things. What exact task takes longer than it should. What would "faster" actually look like for that task, in minutes, not vibes. And what would I need to change about how I work in order to use this tool well, and is that change worth it.

Most tools fail on the third question. They ask you to change your workflow more than they change your output. And workflow changes are expensive, even when they're small, because they ask for something harder to give than money: attention, habit, and trust that this new way will actually work once the trial excitement wears off.

I still try new tools. I'm not arguing against curiosity, or against experimenting with what's available. But I've stopped treating every new release as something I need to adopt immediately. My folder of "tools to try" is much shorter now, not because I lost interest in AI, but because I finally know what I'm looking for before I go looking.

The slow task was never a mystery that needed a new gadget to solve. It needed fifteen minutes of honest attention, a stopwatch, and the willingness to admit that the problem might be smaller, and more specific, than "I need better tools." Most of the time, it is.

[Boost]

Chizurum Chidimma Enyinnaya — Tue, 15 Sep 2026 07:56:07 +0000

Chizurum Chidimma Enyinnaya

Sep 15

Are You Automating a Business That Hasn’t Found Its Customers Yet?

#automation #ai #productivity #performance

11 min read

Are You Automating a Business That Hasn’t Found Its Customers Yet?

Chizurum Chidimma Enyinnaya — Tue, 15 Sep 2026 07:55:45 +0000

How building the perfect system can distract you from finding a real buyer, and how to decide what deserves automation at the beginning.

You can spend an entire afternoon preparing for customers without getting any closer to understanding why someone would become one.

The booking page works. The welcome email sounds professional. The form sends information to the right place. A new project folder appears automatically when you test the process.

Everything is coming together.

Then you open your inbox, and the enquiry you hoped for is still missing.

I can understand the appeal of working on those systems. There is something satisfying about connecting a few steps and watching them happen without your involvement.

You can see the result immediately.

A form is completed. A notification arrives. A task appears.

Finding customers is less predictable. You can explain your offer carefully and receive no response. Someone can sound interested and disappear. A conversation can reveal that the service you were excited to sell does not address the problem the buyer considers urgent.

That uncertainty makes business preparation feel comfortable.

There is always another setting to adjust, another template to improve, or another tool to connect.

As someone interested in writing, AI, and building a business around useful skills, I find this worth thinking about. I want systems that reduce unnecessary work. I also want to recognise when setting them up is taking attention away from a question they cannot answer for me.

Who needs what I am offering enough to pay for it?

Until that becomes clearer, a sophisticated process may be supporting a very uncertain offer.

That does not make the preparation worthless. A reliable way to receive enquiries, arrange calls, and collect the information needed for a project can be useful from the beginning.

The question is how much of the business you are trying to organise before you understand the work it will actually need to do.

Imagine a writer preparing to offer a monthly content package.

They create a detailed onboarding form. They set up automatic emails explaining the process. They build a system for generating topic ideas, moving drafts through review, and sending reminders.

The package looks ready.

Then the first serious conversation reveals something they had not considered.

The prospective client has plenty of topic ideas. What they struggle with is turning the founder’s scattered knowledge into something another person can write accurately.

A second conversation reveals a different issue. That company already has drafts, but the material needs substantial editing before it can be published.

A third prospect wants a small initial project because the team needs to see how the writer handles the subject.

The system was designed around customers arriving with a clear brief and committing immediately to ongoing work.

The conversations reveal that the starting point may be different.

The writer now has useful information about what the service needs to include, how it should be explained, and what a suitable first engagement might look like.

Some of the existing setup will still help. Other parts may need to change.

This is what concerns me about automating too early.

You can build a process around assumptions and then carry those assumptions into every interaction.

The onboarding form asks questions the client cannot answer. The welcome email describes a package they have not agreed to. The reminder sequence addresses an objection that was never the real problem.

The system may run correctly while making the experience less useful.

Before spending more time on it, I would want to understand where the uncertainty sits.

Perhaps the offer is clear, but too few suitable people have seen it.

Perhaps people understand the service but cannot see why they need it now.

Perhaps the price, scope, or amount of client involvement creates hesitation.

Perhaps the work is useful, but the people responding have no authority or budget to buy it.

Those situations need different responses.

An automated follow-up sequence might help with one part of the process. It cannot, by itself, tell you which of those situations you are dealing with.

That understanding comes from looking closely at what happens when real people encounter the offer.

GOV.UK’s user research guidance recommends learning what people are trying to achieve, how they currently handle it, and where they experience problems. Although the guidance is written for public services, I would apply the same approach when investigating a business idea: understand the existing situation before deciding how your solution should work.

For a writing service, that could mean asking a founder about the last article they tried to publish.

What happened? Who contributed? Where did the process slow down? What remained unfinished? How did they handle the problem?

Those details can reveal more than a broad question about whether they would like help with content.

Someone may agree that publishing regularly is important while having no immediate intention of paying for support.

They may enjoy discussing an idea without considering it a priority.

That is why I would be careful about treating enthusiasm as proof of demand.

A person saying “This sounds useful” has given you an encouraging response. They have not necessarily shown that they will make room for the service in their budget or working week.

Even a conversation about pricing leaves questions open.

The buyer may be exploring. They may need approval. They may decide to solve the problem another way.

A paid project gives you stronger evidence that the offer is valuable to that customer under those conditions. Delivering it gives you more information about whether the work is manageable and whether the result meets the need.

Repeat work can reveal something further.

Each stage teaches you something different.

I think this matters because automation can make early signals look more substantial than they are.

A growing list of contacts can look like a healthy sales process. A collection of completed forms can look like strong demand. Scheduled messages can make the business feel active.

Those numbers need context.

Who are the people involved? What have they actually agreed to? What happens after the initial response?

A system can organise these details, but someone still needs to interpret them.

At the beginning, that person is often you.

There is also a useful kind of learning that comes from handling early work directly.

When you read an enquiry yourself, you notice the words the buyer uses. When you discuss the brief, you hear where they hesitate. When you explain your process, you discover which parts make sense and which need clarification.

These details can shape both your service and your marketing.

Y Combinator’s early startup advice encourages founders to work closely with initial customers, including through manual processes, while they are still learning what to build. It warns that creating systems for scale too soon can consume time and effort before those systems are needed.

I find the practical lesson relevant to a small service business too.

If I have only a few serious enquiries, personally reading and answering them may be one of the most useful parts of my work.

I can notice that several prospects misunderstand the same phrase. I can discover that my package includes something buyers do not need while leaving out something they keep asking for.

That information can help me improve the offer.

If I automate those conversations too heavily, I may still receive responses, but I risk paying less attention to what they reveal.

This does not mean every interaction has to remain manual forever.

It means that learning has value, and the process should leave room for it.

A simple booking confirmation can reduce unnecessary back and forth while you still handle the substantive conversation yourself.

A reminder can help you follow up at the right time while you write a response based on the person’s actual situation.

A template can keep important information consistent while allowing you to adapt it.

There are many useful steps between doing everything from scratch and building a fully automated customer journey.

I would start with those.

It is also worth looking honestly at how much time an automation is likely to save.

Suppose a task takes ten minutes and happens twice a month.

That is twenty minutes of work each month.

If automating it takes three hours, it would take nine months to recover the setup time, assuming the automation removes all twenty minutes and requires no maintenance.

That is an illustrative calculation, but it raises a practical question.

Will this task still exist in the same form nine months from now?

For a new business, the offer, process, tools, and customer needs may change considerably during that period.

The automation might still be worthwhile if it prevents a costly mistake or makes the business more accessible. Time saved is only one consideration.

But the calculation helps expose the difference between a task that feels repetitive and one that is consuming a meaningful amount of time.

A complicated setup can be difficult to justify when the task barely occurs.

The cost is also broader than the initial build.

Someone needs to test the process, check whether it still works, update messages, and handle situations that fall outside the expected path.

An automated workflow can reduce work. It can also create a new responsibility.

I would want to account for both.

The same applies to subscriptions.

A tool may have useful features, but its usefulness to another business does not establish its usefulness to mine at this stage.

If I am paying for capacity I rarely use while still trying to find suitable buyers, I would want to review that decision.

The money matters. So does the attention spent learning and maintaining the tool.

An afternoon used to configure an elaborate client portal is an afternoon unavailable for improving a sample, speaking with a prospective buyer, or delivering a small paid project.

That does not make the portal a bad idea.

It makes timing part of the decision.

There are situations where early automation makes sense.

A booking tool may help someone manage availability around another job. Automatic delivery may be essential to providing a digital product properly. Reminders can support a person who struggles to keep track of administrative tasks.

A small automation might also make customer research easier by organising responses or keeping agreed appointments visible.

Those benefits can exist before the first sale.

I would judge the setup by the real difficulty it removes and the effort required to maintain it.

For some businesses, automation is part of the product itself.

If the offer is an automated reporting service, the founder may need a working prototype to test whether it can produce a useful report accurately and consistently.

That is a meaningful part of testing the business.

The important distinction is between building what is needed to evaluate the core promise and constructing every surrounding process before that promise has been tested.

A prototype may need to generate the report. It may not yet need a complicated referral programme, several subscription levels, and an elaborate customer dashboard.

The work should match the question you are trying to answer.

I would apply similar judgement to AI.

AI can help draft interview questions, organise notes, suggest possible objections, or examine how clearly an offer is written.

Those activities can support preparation.

But an AI generated description of an ideal customer remains a proposal about who might buy. It needs to be checked against real people and their circumstances.

A simulated buyer can point out a confusing sentence. They cannot commit a real budget, reveal what happened inside an actual company last week, or decide to renew a service after using it.

I want tools to help me make better use of customer evidence.

I would be cautious about letting simulated responses become a substitute for finding that evidence.

This is particularly relevant when the work of reaching people feels uncomfortable.

I do not think everyone needs to adopt the same approach to selling. There are ways to learn about potential customers without sending large volumes of cold messages.

You can pay attention to relevant requests in professional communities. You can speak with people who already engage with your work. You can ask former clients about problems they are now trying to solve.

You can publish a specific example and invite people facing that situation to discuss it.

A referral or an introduction can also create a useful conversation.

What matters is whether the interaction helps you understand a real need and gives a suitable person a clear opportunity to consider your offer.

Publishing can support that process, but a full content calendar is not proof that it is working.

If I schedule a month of posts, I would want to know what those posts are intended to help me learn or achieve.

Are they explaining a service? Demonstrating relevant ability? Addressing a question buyers repeatedly ask? Creating a reasonable path to an enquiry?

Or am I mainly increasing the amount of content moving through the system?

That is a question I would ask without dismissing the value of visibility.

A consistent presence can help people become familiar with your work. It still needs a connection to the customers and projects you hope to attract.

The same care applies when the first sale arrives.

It is tempting to take one successful project as permission to automate the whole business.

I would celebrate the sale and study it.

Why did that person buy? What were they trying to achieve? How did they find me? Which part of the offer mattered? How much work did delivery require?

A first client gives you a real experience to examine.

They may also have unusual needs, a personal relationship with you, or circumstances that make their purchase difficult to repeat.

That does not reduce the value of the project. It means there is more to learn.

I would look for patterns across suitable customers over time.

Which questions keep appearing? Which steps stay the same? Which parts of the work require judgement each time?

The repeated, stable steps are stronger candidates for automation.

Suppose every agreed project requires the same basic information, and you have learned which questions clients can answer easily. An intake form now has a clearer purpose.

Suppose you repeatedly spend time creating the same folder structure after a project is confirmed. Automating that task may be straightforward and useful.

Suppose delivery is frequently delayed because reminders are being forgotten. A simple reminder process may address a problem you can already identify.

Those decisions are grounded in work that is happening.

You have a better idea of what the system needs to do and how you will know whether it helps.

I would also keep a way to notice exceptions.

If a client replies to an automatic message with a question, that reply should reach someone who can respond. If a step fails, it should not disappear silently. If the process stops matching the offer, it should be possible to change it without rebuilding everything.

A useful system should leave the business easier to manage.

For someone who already has an elaborate setup and very few customers, I would begin with a review rather than a dramatic reset.

Look at what is actually being used.

Keep the tools that make the basic experience reliable. Identify the unused features and sequences that depend on assumptions you have not tested. Pause additional building while you investigate the most important uncertainty.

That uncertainty might be the audience, the problem, the offer, the price, or the way people discover you.

Choose a manageable way to learn more about it.

If the offer is unclear, show it to suitable people and listen to what they think it includes.

If you are unsure about the service itself, discuss recent examples of the problem and consider a clearly scoped paid pilot.

If delivery takes too long, examine where the time goes before deciding which step to automate.

The next useful action depends on what you need to learn.

I would also keep a record of what changes after each conversation or project.

Perhaps you revise the package description. Perhaps you simplify the first engagement. Perhaps you remove a deliverable that sounded attractive but did little for the customer.

Those changes are business progress too.

They may be less visually satisfying than a connected workflow, but they can give that workflow a much stronger purpose later.

This is what I want to remember when another tool makes me feel that my business is behind.

A small business can be organised without being complicated. A professional service can begin with a clear offer, a reliable way to communicate, and a process simple enough to adjust as the work develops.

I want room to learn before I make every decision difficult to change.

And I want automation to respond to something real.

A task that is consuming time. A repeated mistake. A process customers already use. A necessary part of the product’s promise.

Before building another sequence, I would like to be able to point to the need it serves.

Then, when a new enquiry arrives, I can concentrate on understanding the person behind it. The system can handle the routine steps I already understand, while I pay attention to what this customer still has to teach me.

Why Copy-Paste Code Examples Need the Same Care as Production Code

Chizurum Chidimma Enyinnaya — Mon, 14 Sep 2026 04:45:05 +0000

A developer I once worked with told me his worst outage came from a snippet he found in an official documentation page. Not a sketchy forum post, not an AI chatbot answer, the actual docs for the library he was using. The example worked exactly as shown. It just wasn't written for his setup, and nobody on his team checked before it shipped. The bug sat quiet for two weeks before it cost the company a chunk of customer data.

That story sticks with me because it breaks the usual assumption people make about copied code. The concern isn't only "did this come from a sketchy source." It's that any code you didn't personally reason through carries risk, regardless of where it came from. Tutorials, official docs, Stack Overflow, AI-generated snippets, a coworker's old project, all of it needs the same scrutiny you'd give code you wrote yourself, because the moment it enters your codebase, it becomes your code. Nobody is going to trace a production bug back to a blog post. They're going to trace it to your commit.

A snippet is written to answer one question, not your whole system.

Tutorials and examples exist to illustrate a concept clearly. That means they're often stripped of the things production code actually needs: error handling, input validation, logging, security checks. A snippet that shows how a function works will skip the part where you check if the input is empty, because that would clutter the point being made. The author isn't being careless. They're teaching a concept, not shipping a feature.

The problem starts when that stripped-down version gets pasted directly into a real application and treated as finished. What was a clear example becomes a silent gap in your error handling, sitting in production, waiting for the one input nobody planned for.

Code ages, even when nobody touches it.

An example written two or three years ago may have been the right approach at the time and the wrong approach today. Libraries get updated. Security recommendations change. A method that was standard practice becomes deprecated, or worse, becomes a known vulnerability that the community has since patched around. Copying code from an older tutorial can mean copying a security hole along with it, and the code will run fine, which is exactly why nobody notices until something goes wrong.

This is worth remembering with AI-generated snippets too. A model can generate code that looks confident and clean while quietly relying on an outdated pattern, an unsupported version of a package, or a method that doesn't exist anymore. Fluent code and correct code are not the same thing, and a snippet that reads well is not proof that it's safe to run.

Hardcoded secrets and defaults hide in plain sight.

A huge number of code examples include something like a placeholder API key, a sample password, or default configuration values meant purely to demonstrate the syntax. People copy the whole block, forget to change the placeholder, and ship it. Or the example uses a permissive default setting, like open access rules on a database call, because that's the fastest way to show a concept in a short tutorial. That default was never meant to reach a live product, but it does, constantly.

Reading every line before running it isn't about distrust of the source. It's about knowing exactly what a piece of code touches, what it assumes, and what it exposes, before it becomes part of something real people rely on.

"It worked in the tutorial" isn't the same as "it works here."

A snippet is tested in one specific environment: the author's machine, their version of the language, their dependencies. Your environment is different, even slightly, and slight differences are where quiet bugs live. A function that behaves one way on one version of a library can behave differently on another. An example built for a small dataset can fall apart under real load. None of this shows up until the code meets conditions the original author never tested against, which is precisely the situation production creates every day.

This is why copied code deserves the same testing discipline as anything else: run it against your actual data, your actual scale, your actual edge cases, not just the one clean example it was demonstrated with.

Review it like you'd review a stranger's pull request.

Treating copied code with less scrutiny than your own is an easy habit to fall into, because it already "works," so it feels done. The healthier standard is to treat every pasted snippet as if a stranger just opened a pull request against your codebase. Would you merge that without reading it fully? Would you approve it without knowing what each line does? If the answer is no, the same standard applies whether the code came from a coworker, a tutorial, a forum, or a model.

Teams that build this into their process, even briefly, catch a surprising number of problems early: an unnecessary permission, an unhandled error case, a function doing more than the task actually calls for. It takes a few extra minutes. It costs far less than the incident that follows when nobody looked closely.

Convenience isn't the problem. Ownership is.

There's nothing wrong with reusing code. Nobody writes everything from scratch, and good examples save real time. The issue is what happens after the paste: whether someone actually understands what the code does, checks that it fits the system it's landing in, and takes responsibility for it the same way they would for a function they wrote line by line.

Code doesn't ask where it came from before it runs. It just runs, with whatever assumptions, gaps, or leftover defaults it was written with. The only thing standing between a helpful shortcut and a production incident is whether someone gave it the same attention they'd give their own work. That attention isn't optional just because the code was fast to find.

Your AI Demo Works. Here's What Can Break in Production

Chizurum Chidimma Enyinnaya — Mon, 14 Sep 2026 04:36:23 +0000

The gap between a working demo and a system people can actually depend on.

A founder once showed me an AI feature that answered customer questions with startling accuracy. It handled tricky phrasing, pulled the right information, and responded in seconds. Three weeks after launch, that same feature was quietly the top source of support tickets. Users asked questions the demo never anticipated, the model gave confident answers that were wrong, and nobody had built a way to catch it before customers did.

This pattern shows up constantly with AI products. A demo is a curated performance. Production is an uncontrolled environment full of real people typing real things, using slow networks, pasting messy data, and doing exactly what you didn't expect. The distance between those two worlds is where most AI projects run into trouble, and it has nothing to do with the model being bad. It has to do with what a demo is actually built to prove, versus what a live system has to survive.

A demo proves a concept. Production proves everything else.

When you build a demo, you're answering one question: can this work at all? You pick clean inputs, you test the happy path, and you show the version of the product where everything goes right. That's not dishonest. It's just a different job than the one production has.

Production has to answer harder questions. What happens when the input is in a language the model wasn't tuned for? What happens when ten thousand people use the feature at once instead of one person in a conference room? What happens six months later when the underlying data has shifted and the model's assumptions no longer hold? A demo was never built to answer these questions, so it's not a failure of the demo when production surfaces them. It's a sign the demo did its one job and stopped there.

Edge cases aren't rare. They're just unseen until launch.

Every AI team I've talked to underestimates how many "edge cases" actually make up daily usage. A support bot trained on polite, well-formed questions meets customers who are frustrated, typing in fragments, switching topics mid-sentence, or asking about something the product doesn't even do yet. None of that shows up in a controlled demo because nobody scripts frustration into a test script.

The fix isn't trying to predict every possible input before launch. That's impossible. The fix is building the system to expect that inputs will surprise it, with fallback responses, clear boundaries on what the AI should and shouldn't attempt, and a way to flag confusing cases for a human instead of letting the model guess.

Confidence is not the same as correctness.

This is the part that catches founders off guard the most. A language model can sound completely certain while being completely wrong. In a demo, you notice the two or three answers you tested and they happened to be right. In production, at scale, the wrong answers show up too, and they show up with the same confident tone as the right ones.

I've watched teams treat this as a rare glitch instead of a built-in trait of how these models work. It isn't rare. It's expected behavior from a system that generates plausible text, not verified fact. The teams that handle this well build in checks: citations back to real data, confidence thresholds that trigger a human review, and honest phrasing when the system isn't sure. The teams that struggle treat every fluent answer as a correct one, until a customer proves otherwise in public.

Scale changes the economics, not just the traffic.

A demo runs one request at a time, usually on a good connection, usually paid for out of a small testing budget. Production runs thousands or millions of requests, and every one of them costs money and takes time. What felt fast and cheap in testing can become slow and expensive once real usage kicks in.

I've seen a founder build a feature that worked beautifully, only to discover the per-request cost made the business model unworkable at real volume. That's not a technical bug. It's a business assumption nobody stress tested until the invoice arrived. Anyone building on top of AI needs to ask, early, what this costs at ten times the current usage, and at a hundred times. If the answer changes the entire pricing plan, that's worth knowing before launch, not after.

Your systems weren't built with AI's quirks in mind.

Most AI features don't live alone. They sit inside an existing product, pulling from a database, connecting to a payment system, feeding a dashboard someone checks every morning. A demo often skips this entirely and calls the model directly with a clean, small example. Production has to connect the AI to everything else the business already runs on, and that's where a lot of the real engineering work actually lives.

This is also where failures get expensive. If the AI writes bad data into a system nothing else checks, that mistake can travel. A support bot that quietly mishandles a refund policy, an assistant that logs incorrect data into a CRM, a summarizer that skips a legal disclaimer, these problems don't announce themselves. They surface weeks later, in a place far from where the AI made the mistake.

Nobody is watching until something breaks.

A demo has an audience. Someone is sitting there, paying attention, ready to notice if something goes wrong. Production usually doesn't have that. The AI runs quietly in the background, and unless someone built proper monitoring, the first sign of trouble is a customer complaint or a founder's own inbox filling up with confused messages.

This is the piece teams skip most often, because monitoring isn't exciting work. It doesn't demo well. But knowing how often the model gives an answer it later needs correcting, tracking which types of questions it struggles with, and having a real alert system when something looks off, this is what separates a product that improves after launch from one that just accumulates quiet damage until someone notices too late.

What actually holds up.

None of this means AI features are too risky to ship. It means the gap between demo and production is a known, predictable gap, and closing it is part of the work, not an unexpected setback. The founders I respect most treat launch day as the start of the real testing, not the finish line. They build in fallback behavior for the unexpected. They watch the system closely in the first weeks instead of assuming it will behave the way it did in the demo. They budget for the version of this feature that runs at real scale, not the toy version that ran in a meeting.

An AI demo that works is proof of possibility. A product that works in production is proof of readiness. The two are related, but they are not the same thing, and mistaking one for the other is how a lot of promising AI features end up quietly pulled a few months after their impressive launch.

When You Shouldn’t Automate a Workflow With AI

Chizurum Chidimma Enyinnaya — Sat, 12 Sep 2026 14:44:17 +0000

Not every process is ready for a shortcut. Some aren't supposed to have one.

I automate a lot of my work now. Drafting, research, formatting, first passes on edits. It's changed how much I can take on in a week. But somewhere in that shift, I also learned the harder lesson: automation is not automatically good, and the instinct to hand a process over to AI the moment it becomes repetitive has cost me more than it saved a few times. Here's what I've learned about when to leave a workflow alone.

1. When you don't fully understand the process yourself

If you can't explain, step by step, why a task works the way it does, you're not ready to automate it. You're ready to automate your guess at how it works, and that guess will get encoded into every output from then on.

I made this mistake early with a client onboarding sequence. I didn't fully understand why certain questions mattered more than others, I just knew the sequence "worked." When I automated it, the AI followed my structure exactly and missed the judgment calls I'd been making without realizing it. The fix wasn't a better prompt. It was going back and doing the process manually a few more times until I actually understood it well enough to hand it off.

2. When a mistake would be expensive or hard to undo

Automation is forgiving when the cost of a bad output is small: you catch it, fix it, move on. It's a different story when the output goes straight to a client, gets published, or triggers something that can't be quietly pulled back.

For anything with real stakes attached, whether that's a legal document, a public statement, or a message that affects someone's money or reputation, I keep a human step between the AI and the outcome, always. Not because the AI is unreliable in general, but because the one time it gets something subtly wrong is exactly the time you can't afford it.

3. When the value of the task is in doing it, not just finishing it

Some tasks exist to produce an output. Others exist to produce understanding, and the output is secondary. Writing a first draft to figure out what you actually think about a topic is the second kind. Automate that too early and you get a polished piece built on a shallow understanding, because you skipped the part where the thinking happens.

This shows up constantly in creative and strategic work. If I let AI generate the outline for a piece before I've wrestled with the argument myself, the piece reads fine but says nothing sharp. The struggle wasn't friction to remove. It was where the actual value came from.

4. When the process is still changing

Automating a workflow locks it in. That's the entire point of automation, and it's exactly why it backfires when the process underneath is still unstable. If you're still adjusting your approach week to week, testing what works, changing your mind about the right sequence of steps, automation just means you're now consistently repeating a version of the process you already know is incomplete.

I wait until a process has held steady for a while, with no major changes, before I build it into a repeatable AI workflow. Automating too early doesn't save time. It just makes the next change harder, because now you have to unwind a system instead of adjusting a habit.

5. When trust is the actual product

Some interactions aren't really about the content, they're about the fact that a specific person showed up for them. A personal note to a long-term client. A difficult conversation. A message meant to repair something, not just inform someone. Running these through AI, even well, can hollow out the one thing that made them work in the first place: that someone took the time.

I still write these myself, slowly, badly at first, because the effort is part of the message. The moment the other person suspects it was generated, whatever trust the message was supposed to build gets undercut instead.

6. When the volume doesn't justify the setup

Automation has a real cost before it saves you anything: the time spent building the workflow, testing it, fixing what breaks. For a task you do fifty times a month, that cost pays for itself fast. For a task you do twice a year, it usually doesn't.

I've caught myself building an elaborate AI process for something I genuinely only needed to do once. That's not efficiency, it's a detour. Sometimes the right call is to just do the task the plain way and save the automation instinct for something that will actually repeat.

7. When automating would mean skipping a skill you still need

There's a difference between automating a task you've already mastered and automating a task so you never have to learn it. The first frees up your time. The second quietly makes you dependent on the tool for something you should be able to do yourself, and it tends to catch up with you the first time the AI is unavailable, wrong, or simply not the right fit for the situation in front of you.

I try to ask myself, before automating anything new, whether I'm removing a chore or removing a skill. Chores are worth automating. Skills are worth keeping, even the ones AI could technically do for you.

The actual question

The question worth asking isn't "can AI do this." Almost everything can be handed to AI in some form now. The better question is whether doing so trades away something you actually needed: your judgment, your understanding, someone's trust, or a skill you're not ready to lose. Automate the rest without a second thought.

7 Things an AI Workflow Needs Beyond a Good Prompt

Chizurum Chidimma Enyinnaya — Sat, 12 Sep 2026 14:40:24 +0000

A great prompt gets you one good answer. A real workflow gets you the same good answer, over and over, without you having to think about it.

I spent a long stretch believing that if I just worded my prompts well enough, everything downstream would sort itself out. It didn't. I'd get a strong result one day and something flat and generic the next, using the same prompt, sometimes in the same sitting. That inconsistency taught me something that most advice about AI skips over: the prompt is one ingredient in a workflow, not the whole recipe. If you want AI to actually carry weight in your work, the prompt has to sit inside a system that supports it. Here are seven things that system needs.

1. A clear outcome, not just an instruction

A prompt tells the model what to do in the moment. It rarely tells it what the output is actually for. "Write a LinkedIn post about productivity" is an instruction. "Write a LinkedIn post that gets a busy solo founder to stop scrolling and save it for later" is an outcome.

The difference shows up in the output immediately. When I define the outcome first, meaning who reads this, what they do after reading it, and what would make them ignore it, the model has something to aim at. Without that, it defaults to the safest, most average version of whatever I asked for. A workflow needs the outcome defined before the prompt is written, not folded into the prompt as an afterthought.

2. Real input, not assumptions

This is the one I underestimated the longest. A model can only work with what you give it. If you feed it a vague topic and expect it to guess your audience, your voice, and your standards, it will guess, and the guess will be generic by default.

The workflows that actually save me time all start with real material: notes, transcripts, past work, client answers, examples of what "good" looks like. When I bring the model actual substance instead of a bare instruction, the output stops sounding like it could have been written for anyone. It starts sounding like it was written for this exact situation. Gathering that input takes longer than typing a prompt, but it's the difference between a first draft you can use and one you have to rewrite from scratch anyway.

3. A repeatable sequence of steps

A single prompt is a moment. A workflow is a sequence: gather the input, generate a draft, check it against a standard, revise, format, deliver. If that sequence lives only in your head, you'll do it differently every time, and your results will drift.

I write the sequence down now, even for tasks I do often. Not because I'll forget the steps, but because writing them down forces me to notice which ones actually matter and which ones I was skipping without realizing it. A documented sequence also means someone else, or a future version of me on a tired day, can follow it and get the same result. That's the actual test of a workflow: can it survive being run by someone who isn't paying full attention.

4. A checkpoint where a human actually judges the work

AI-generated drafts have a specific failure mode: they can be fluent and wrong at the same time. Confident, well-structured, and completely missing the point of why you needed the piece in the first place. A prompt has no way to catch that. Only judgment does.

Every workflow I trust has a point where I stop and read the output as if I didn't write the prompt. Does this actually say what I meant? Does it sound like a person or like an average of the internet? Would I be embarrassed if a client saw this before I touched it? That checkpoint is not optional polish. It's the step that decides whether the rest of the workflow was worth running.

5. Memory across the steps

Most AI tools forget everything the second a conversation ends, and most workflows fall apart because of it. If step three needs to know a decision you made in step one, and the tool has no memory of that decision, you end up repeating yourself constantly or getting output that contradicts earlier work.

This is why I now build workflows that carry context forward on purpose: saved notes, reference documents, a running brief the model can be pointed back to. It's a small amount of setup that removes a huge amount of friction later. A workflow without memory isn't really a workflow. It's a series of unrelated requests that happen to be about the same project.

6. A plan for when the output is wrong

At some point, the AI will give you something off. Not occasionally, regularly. A workflow that only works when everything goes right isn't a workflow, it's a hope. What separates a workflow that holds up under pressure is having a plan for the moment things go wrong: a second pass with different instructions, a fallback template, a person who reviews before anything goes out.

I used to treat a bad output as a reason to abandon the whole approach and start over from a blank prompt. Now I treat it as expected. I have a short list of things I try first: narrow the instruction, add a missing piece of context, ask the model to critique its own draft before I touch it. Having that list ready means a bad result costs me minutes instead of derailing the entire task.

7. A record of what actually worked

This is the step almost nobody builds, and it's the one that compounds the most. Without a record, every project starts from zero. You reinvent the same prompt, rediscover the same fix, relearn the same lesson, over and over, because nothing from last time carried forward.

I keep a running note of what worked: the phrasing that got a good result, the input that made a difference, the checkpoint that caught a problem before it became a real issue. It's not glamorous. It's also the single biggest reason my workflows have gotten faster and more reliable over time, not because the tools improved, but because I stopped throwing away what I learned each time I used them.

The actual shift

None of this means the prompt doesn't matter. It matters plenty. But a prompt is a sentence, and a workflow is a system, and systems are what produce consistent results. The people getting real, repeatable value out of AI aren't the ones with the cleverest wording. They're the ones who built a structure around the prompt: clear outcomes, real input, a defined sequence, a human checkpoint, memory that carries forward, a plan for errors, and a record of what worked.

That structure is unglamorous. It's also the entire difference between a tool you experiment with and a tool you can actually depend on.

Read this

Chizurum Chidimma Enyinnaya — Fri, 11 Sep 2026 10:11:35 +0000

Chizurum Chidimma Enyinnaya

Sep 11

How to Test an AI Feature When There Is More Than One Correct Answer

#database #startup #performance #writing

5 min read