Why Humans Shouldn’t Write First Drafts with Prince Eze

Gowri: Good day, everyone. Welcome to the Knowledge Base Ninjas podcast. So with us today we have Prince Eze Onyeanuna. Hi, Prince. How are you doing today?

Prince: Hi. I’m good, I’m good. I hope you’re doing well too.

Gowri: Fantastic. Thank you for taking your time and sharing your experience. It’s very important that people like you, coming from a different background and a different continent, share your experience. Before I ask any further, help me understand  how did you choose this as your career? Who motivated you, and most importantly, how is it going? Are you still enjoying it?

Prince: First things first, thank you so much for having me here. I will say I am more excited to be here than you can actually imagine. Now, how did I get into tech writing and documentation? So my background is in DevOps. I started off as a DevOps engineer. And if you’re familiar with DevOps, what happens is when you’ve documented something, you want to show people you want to show your recruiter, you want to show that you’re building in public- so you want to show people what you’ve done, make a post about it.

Now, what happens is you’re actually deploying stuff on paid instances and get billed for whatever you keep running. So as much time as you have something running on AWS or GCP, you get billed. And I didn’t have a job at the time, so I had to rely on writing, which is what everybody does you write about stuff. So you build, you quickly pull down what you built, and write and document the process. So it goes to show that you actually know what you’re doing.

So I started off doing that, just writing blogs. And then in the process of writing blogs, I one day pushed out a blog to a public group and said, “Can anybody help me just review this?” And someone reached out to me, got on a call with me  I didn’t know who that person was and he ended up being my mentor.

I got to find out that tech writing is not something you pair up with a career, because when I started, you could find people that are like, “Oh, I’m a front-end engineer and tech writer,” or “I’m a DevOps engineer and tech writer.” It was always more like a side thing for most people. So from him, I got to find out this is an actual career, and it doesn’t just mean you’re writing blog posts. I got to know you can actually build developer documentation, product documentation, API documentation, how-to guides, manuals a whole lot of other things. I’m like, “This is a whole lot of information. This is an entire ecosystem I did not know anything about.”

So I had my mentor, and he pushed me through. I worked with him on several projects, and over the line, I dropped DevOps. Now, the fun part is that because I started working with him, it was easier for me to get into the skill. I struggled with DevOps because I was figuring it out on my own I took a diploma course, but after the course I wanted to upskill, and it was quite difficult even to land a role. But with writing, it came to me naturally, and he’d say, “You actually know how to do this thing; you just have to get better at learning structures and stuff.” So it came to me naturally, and I dropped DevOps I’m like, “Okay, I’m going to focus and double down on this.”

I grew, learned from him, and got so much experience. I’ve worked in the medical field for an open source community called OpenMRS worked with them twice, the first year and then the next year they came back and wanted me to work with them again. I worked with a web company that transitioned into a payments company, my previous company, Pi² Labs. And before all of that, I worked with several freelance companies: Ambassador Labs, Semaphore, Medusa, so much.

So I can say I’ve come a long way, and it’s been very exciting. You asked if I’m still excited  I am, because we’re in a very promising time, and it’s very defining. Where we are right now is very defining.

Gowri: So that nicely puts me to the next question, which is new possibilities you see for creating, managing, and of course delivering knowledge when both human and AI are working together. How do you see this?

Prince: Okay. So the first thing I know that’s very obvious right now is that you can produce anything at scale because of AI. If you could do two blogs a month for a company because of AI, first of all speeds up the process of development. So if you were building a product, if it would take you two months to push out a feature, it has shortened that time. And because your docs are moving with the speed of your product — if you’re putting out new features or new PRs for docs on a biweekly basis, it’s now faster, so you can scale out production.

Creating Content

You mentioned three things: creating, managing, and delivering. So for creating information, creating content with humans and AI, personally, I believe that humans should no longer write first drafts. So the process of writing a blog, for instance the process starts with an idea, and then you have to go on to do research. If you have this locked down already, with good enough context, an LLM can give you a good first draft. So far it has your voice — you’ve worked with it, you’ve trained it to give you something good. It has the context of your company and the context of what you’re writing about. It can give you a very good first draft that you can take on and refine.

Now, this part here is where most people get it wrong when they say they’re using AI. Some people skip this entire part get the entire idea from AI, get the entire research from AI, do not check the research on where it’s coming from, and just do everything straight with AI, and then say, “Oh, we can now create content without humans,” which is wrong, because the idea has to come from something.

Right now, because AI can spit out millions of ideas, you can have a content calendar for every week from now to the end of this year. But are those information valid? Question. Are they good information that your audience wants to read? Question. Are they tied to your product you’re building? Question. And these are things your LLM can’t answer for you. You have to answer it, because you’re building your human there.

So if you can get a good idea, and using LLMs and AI, pull out good research, fact-check the information that’s given to you, have a good enough body of work AI can give you a good draft. So I don’t think anybody should be creating first drafts. When it comes to creating stuff, you should not be doing that.

Managing Documentation

Now, when it comes to managing content, managing knowledge, there’s a gap in this stage I’ve seen. Before now, there was a mindset that when you’re building documentation, you could get a writer, and while you’re building your product on the side, you’d say, “I’m almost done with my product, let me just get somebody to build these docs,” and they just do it. You’d see the docs up, and you could let that person go. And then you keep pushing changes with your product, and what happens is your docs get unattended to.

I’ve seen this time and time again it happens in the freelance world. What happens is they hire you because they’ve already built a product, get you on the team, and say, “Create our documentation for us.” You create the documentation, and then they cut short your contract. But your process of development doesn’t stop; they keep iterating, and their docs get unattended to.

But now with AI, you can fix that gap; you can get your documentation monitored, in the sense that you can watch for when there’s a drift between your product and your docs. This is by watching your repository: when you’ve made changes to your product, you also have to update your documentation. This way, there’s no difference between what your product is saying and what your docs are saying, because if a reader cannot trust your documentation, it says the same thing about your product.

There’s a very popular saying that the docs is the product. So it goes for trust. If I come to your documentation and find that your product says A, but your documentation is saying something outdated, it’s a trust issue, and people can’t trust that anymore. So when it comes to managing information now, we can have our documentation monitored, so nothing is breaking we’re all in sync. I’m pushing out content, and my documentation is getting updated at once.

Distribution

Now, for distribution, before now, we knew that only humans could read information; we read content. But that’s not the case anymore. Before now, we’d go to Google, search up something, and read the blog. Most people are not even going to Google anymore; that’s why Google had to insert Gemini into its search engine, so when you search, it gives you a Gemini response first. Everybody’s going to Claude, ChatGPT just give me what I want. So agents, LLMs are now an audience that people are creating information for, and with that, there’s a way and manner that information is now made for them using things like AEO and GEO.

Before now, you could have somebody spam a blog post with 50 keywords for a particular search you’re trying to make. But right now, if you did that, your blog would actually be flagged for it you cannot be trusted, because spamming keywords is a lack of trust. So right now, with AEO and GEO, which in my opinion is just SEO done really well, you structure your content in a way that’s easy to break down. Because right now, you’re not giving a human that’s reading line by line you’re giving an LLM or agent that’s chunking your information. So it has to be properly ordered in a way that’s easily accessible for them as well.

So these are various places where I see that in creation and management, we can actually infuse AI.

Gowri: So another question that often comes to everybody’s mind is now that we have AI, what are we now? How do you answer this?

Prince: A very simple answer is rather than saying “builder,” since this is a technical talk  we’re engineers rather than just writers. And what are we engineering, what are we building? We’re building systems, we’re building structures that these tools can work on.

Let me explain. Before now, our work was mostly tied to writing the content, and we let the engineering team figure out the building. But right now, if you check the job roles that we have content engineer, documentation engineer, information architect, AI content reviewer, context curator, and so on and so forth. You keep hearing “engineer” coming up in these roles because the industry now requires you to build systems around what you’d normally done manually.

This isn’t very different from what we did before if you’re going to onboard somebody into your team, it requires that your team lead pass on the information to that person in a systematized way that they can pick up. But right now, you’re systemizing your process in a way that you can give it to an AI agent or a tool to do for you. And this was something that was left for top-level people, the team lead and all. But what it calls for now is that every single person — if you’re a tech writer, mid-level or advanced you’re thinking in systems.

If you’re writing a blog, what are the processes in creating a blog post? How can I systemize the process? How can I share the process in a 50/50 or 60/40 way, in different partitions between an AI agent and myself? How can I shorten the time it takes me to create one blog post?

I’m saying this from a practical scenario, because I was in an interview about a month ago for a content and AI role, and the interviewer didn’t ask any questions about my writing. He asked what tools I’ve built around my writing, because these are what will feed your LLM: how fast can you create long-form content. Questions like this, because they want to see someone who thinks in systems and processes.

Truthfully and this is me having engineering friends and talking about it you meet an engineer right now in any company; most times, they’ll tell you they’re not writing code anymore. They are prompting, and they’re talking to Claude, trying to get things done, because they’re all systemizing processes they’ve done for years manually and giving it to the agents to do for them, and all they have to do is review. So we are all now managers we’re managing these systems. We’re just engineers, and what we’re doing is building systems around all we’ve known before now. That’s what I think we are now.

Gowri: Now, from the place where you’re coming from in your experience, how are technical and knowledge professionals across Africa adopting and exploring AI?

Prince: I think you’re the best person to ask this question! I’d say the same as anywhere in the world. When I first started using LLMs, that was in 2023 it was just like anybody else was using it. If you go to the average company here in Lagos, Nigeria, where I am, everybody’s using AI. Everybody. And this is outside of my tech/IT field; in every field, it has penetrated. It’s not something that’s hidden anymore.

The funny thing is, just last year, there was this notion that nobody should use AI if you smelled AI in something, it was a problem. Right now, it’s something everybody has accepted. We’ve all accepted it; we’re all using AI now. Now the question is, how are we using it?

We’re doing the same as anybody in the world, because we may not be on the front cover of the news we may not have a whole lot of headline activities that shine a light on us for now. But we’ve pushed global talent for years, even before AI came in. I’ve met writers here in Nigeria, I’ve met writers in Kenya so many amazing people who’ve done amazing things even before AI came into play. So the same way anybody’s using AI outside is the same way we’re using it right here.

And funny enough, we have a program called OSCA a gathering of open source enthusiasts, basically. And they usually give tracks for documentation people, people that create documentation. Last year was my first time attending it, but even before then, they always have tracks for documentation people and engineers, and you see the amazing things people are building across Africa. I’m looking forward to it this year.

There’s so much creativity with how we’re using it you could find tools, even outside of writing, the amount of tools we’ve built around this thing is amazing. So I’d just say the same as anybody else. And in a couple of months, a couple of years, that headline we’ve not been able to achieve, we’ll get very close to, and you’ll hear so much more about the things we’ve been able to build and systems that come out to serve the rest of the world.

Gowri: So congratulations for already adopting AI in almost all job roles, and we’re looking forward to much more from you as well. Anything else you’d like to add in terms of skills, perspectives, or opportunities that you believe a technical writer should have?

Prince: I think I might have mentioned this while I was talking, but let me emphasize it: systems thinking. There are a couple of books you can read, but the practical way to learn this is: whenever you take a task, break it down. It’s very simple computer science we learned back in school, or a simple way of programming. When you have a problem, break it down. If you’re asked to write a blog, break it down. If you’re about to create documentation, break it down. Break each process down.

For instance, I have a system for writing a blog: ideation, research, first draft, review, and then publishing. Now, when you have these five processes, you figure out in each of them this is something you can give to Claude. Look at these processes; how can we collaborate on this. Tell it to put it on a calendar. It could say, “Give me your idea,” or “let me refine it, let me see if it’s viable.” You could test the idea. If you didn’t have an idea, you could ask it for one and test that. The worst thing you want to do is let it think for you.

So let me give you an example if you wanted to do a blog. First, you figure out the idea. If you’re sure the idea is viable, no need to check that part. Now, research do you already have a body of knowledge around the information, or do you need more? “Give me information around this topic,” it could give you that. If you had it, you could give it to the tool and it could compress the information “tell me what you understand about this information.” That gives you a first draft. After the idea and the research, next is outlining what I want to cover in this blog so it’s not boring.

Because most people give this information to LLMs like it’s supposed to figure out what you’re supposed to think about, which is wrong. If you’re going to think in a system and pass this information along, always think of these tools as junior colleagues. They just came into your company; they don’t understand anything, so you don’t just say “write this blog post.” You tell them: how did you write blog posts before? What’s the structure? How long are your blog posts? What am I supposed to cover, what am I not supposed to cover? Are there certain things I’m supposed to feature? Am I supposed to add images? How do I reference them? That kind of thing. You’re supposed to give it context and have it all in systems you can pass on to the tool.

Once you figure out the first draft, then it goes to review and that’s on you. If AI is giving you a first draft, you must review. Always be the last reviewer for everything, even if AI reviewed it; review what it reviewed. Make sure it didn’t take out important context you wanted to add, and make sure it didn’t twist things, because it can do that.

These tools are powerful. Nobody lets a lion walk around because it’s just a very cool pet; it’s dangerous. These tools can do a lot of things, so make sure you’re checking, make sure there are a lot of guardrails so you don’t push out something that’s not supposed to be out there for your product or your team. So that’s systems thinking: the first important thing you should do, or you’ll be replaced easily.

Two don’t lose taste. I define taste as your ability to judge, judge the output you’re getting from anything. For instance, I was having a conversation the other day, and I figured I think I started to sound like AI. When you interact with these tools a lot, when it gives you content a lot and you’re reading it, the way we learn how to talk and get our everyday vocabulary is based on the things we’ve read. So if you’re reading this content a lot, it gets into you whether you like it or not, and before you know it, you start sounding like these things. So do not lose taste, whether you like it or not. When it comes to writing, make sure your voice is what it’s giving you. When you’re reviewing, make sure “I don’t want to sound like this, don’t give me this, this is AI-generated.” That’s what the review part of a blog post or any content that goes out should be for.

This is a problem I have with C-level execs and people who judge these things most times they don’t care about this, they just want it done. They want results, and results are very important, because that’s what gives us money for the company. However, there are certain things that should be considered. We don’t want our blog spammed with AI content; how is our audience going to still trust us? If you’re having somebody on the job, they should already have a voice in how they communicate. It’s very important to keep your voice, to keep good judgment what should go on our blog, what shouldn’t. It shouldn’t all be left to AI to figure out. This is why we still have humans in the loop.

As long as we’re still creating content that a few humans still read, it’s still important. Until we get to the point where no human is reading anything again, and we just let LLMs decide what they do and go back to farms, until we get to that point, it’s very important that you do not lose taste. A practical way to ensure this is by reading non-AI-generated stuff; you can find that in fiction, books, other things that keep your mind and keep you talking like a human.

Gowri: I think human in the loop is the most important element here, isn’t it?

Gowri: Absolutely wonderful, Prince. I’m just going to move on to the Rapid Fire round, cautious of everybody’s time. Any resources you can help us with today could be blogs, could be another podcast you might be listening to often that inspires you?

Prince: There’s a book I think anybody should read when it comes to product documentation it’s called The Product is the Docs, by the Splunk team. That was the book that helped me change the way I see documentation. You should also read the Diátaxis Framework it’s a very amazing framework for how you structure documentation. If you’re going to train an LLM to help you with this, these are a couple of things you could ingest for yourself and feed to these tools.

And the guide that started all of this for me when I started writing was the Google Developer Documentation Guide. I once worked with someone who decided what the style guide was going to be I feel like every team, every company should have a style guide that they follow. You don’t make decisions off of what you want, but what is the standard for what we’re trying to create. So you should get these three the first two, The Product is the Docs and the Diátaxis Framework, and the last one, the Google Developer Documentation Guide, which is also on the web page.

Gowri: One word that comes to your mind when you hear “documentation”?

Prince: Pages.

Gowri: My last question a piece of advice you would give to your 20-year-old self?

Prince: Read more fiction. Get into open source early, as soon as possible. And have more fun I don’t think I had so much fun in my life.

Gowri: Prince, it’s been an absolute pleasure hearing your experience, and what really makes me very happy is the way you presented very complex topics, but very nicely put down, which shows how clear you are in your thought process. I wish you all the very best in your upcoming projects, and I’m sure you’ll do many wonders in your new role, or any role you take. So, anything else you missed adding?

Prince: I would say, personally, via my career, I’ve come quite a distance. And I’m saying this because just today I made a post on LinkedIn that was very personal coming from somebody who met me when I started my career, and he just sent me a message a few days ago reminding me of how far I’ve come.

And I just want to say that regardless of how things are with AI now, if you make yourself irreplaceable, you cannot be replaced by a machine. It will take you settling down, looking at the highest level of difficulty, and placing yourself there because the easiest things are being cut off. If you choose to do the easy thing now, it will be cut off as soon as possible. So look for the highest level of difficulty, and ask yourself if you really want to grow or not. If you decide that you’re going to grow, dive into the deep end, and it will be rewarding. It might not be as soon as you want it, but when you look back, you will not be the same. That’s something I want to share with anybody who watches this.

Gowri: Wow. I didn’t want to finish the podcast, but I have to. Hopefully we’ll do a part two sometime.

Prince: I really hope so. I told you I was very excited to be here, so I really hope there’s a part two.

Gowri: So all the very best once again, and enjoy the rest of the day and the week. Thank you, Prince.

Prince: Thank you very much for having me.