Blogging in 2026: Building Your Own Knowledge Base

4th January 2026 • 12 min read — by Aleksandar Trpkovski

I published my first tech blog article in 2021. Since then, I've written 39 more - making this my 40th. That number isn't massive, but it's meaningful to me. Hitting this milestone in 2026 felt like the right moment to pause and reflect on what blogging has meant to me - and how dramatically it has changed along the way.

My Blogging Journey

For a long time, I thought about starting a blog about my development career. I wanted to share things I was learning, small discoveries, and practical tips - but I wasn't convinced I had anything valuable to say. That mindset changed after I read The Coding Career Handbook by Shawn Wang.

One piece of advice from that book stuck with me: start your own blog and share things you've learned that don't already have clear answers online. It sounds simple, but for me, it was a turning point. After reading that book in 2020, I finally took the leap and published my first article the following year.

Before that, I genuinely believed I wasn't "good enough" to contribute to the tech space. I worried that smarter people would call me out, point out mistakes, or dismiss my ideas entirely. Looking back, that fear kept me silent far longer than it should have.

How I Used to Write Articles (Before AI)

Almost every article began with code. I'd experiment with a new framework feature, a language update, or a small side project. Sometimes it was driven by frustration: a problem I couldn't find a solution for anywhere online.

Those experiments could take days, weeks, or even months. Quite a few never saw the light of day. But when something finally felt solid - something I would actually use myself - that's when I'd consider turning it into a blog post.

Writing the article itself was slow and deliberate. I'd spend weeks shaping a draft. Since English isn't my first language, grammar and spelling were always a challenge. I'd then ask my partner - whose first language is English - to proofread it, which added another layer of waiting and coordination.

And that still wasn't the end. I needed a cover image, often involving a fair bit of Photoshop work. Publishing each article required a serious time commitment.

Fast-Forward Five Years

Compare that process to how I publish articles today, and the difference is night and day - even though my career as a blogger is relatively short, only half a decade.

I now spend far less time scaffolding new projects. Coding agents truly took over in 2025, helping not just me, but the entire industry, move faster. Exploring new ideas no longer feels heavy or slow - and because the build phase is quicker, I can jump into writing much earlier.

Another big shift is context. Since agents help me build the codebase, they already "know" what the project does and why certain decisions were made. That makes generating an initial draft surprisingly easy. The first version isn't perfect - but it doesn't need to be.

That draft is just the starting point. I still do quite a bit of manual work - removing fluff, reshaping explanations, adding missing insights, and making sure the article sounds good to readers and brings real value. I think carefully about visuals, structure, and how someone else will experience the content.

Once that's done, I lean on tools like Notion AI to clean up grammar and polish the language. What used to take weeks now takes hours.

Finally, I use tools like Google Gemini or ChatGPT to generate cover images, diagrams, and flowcharts. Visuals that once took days of effort are now quick to iterate on.

The result? I'm easily five times more productive than I was before.

So… Are Blogs Dying?

Over the past year, my feeds have been flooded with bold claims: blogs are dead, AI has killed content, no one reads anymore, LinkedIn posts are garbage. It's a familiar narrative - and an understandable fear.

But is this really the end of blogging? I don't think so. Not even close.

In fact, I find more valuable content online today than I used to. People are publishing more frequently, sharing their personal struggles, and celebrating their "wins." Because the barrier to entry is lower, everyone feels more productive. We are learning from each other at a faster rate than ever before. To me, this isn't a funeral for blogging - it's a win-win situation for the entire community.

Efficiency Didn't Kill Creation - It Multiplied It

I recently came across an article called The Efficiency Paradox by Addy Osmani that captures something we've seen repeatedly in software: every time we make creation easier, we don't create less - we create more.

Higher-level languages didn't reduce the number of programs. Frameworks didn't shrink the number of apps. Cloud infrastructure didn't make teams obsolete. Each step removed friction and expanded what was possible.

The same pattern applies to writing.

In my case, AI hasn't replaced blogging - it's removed the friction around it. I can ship code faster, explore ideas more freely, and move from "this might be interesting" to "this is worth sharing" without weeks of overhead. That efficiency doesn't disappear. It compounds.

Here's what that looks like in practice. Since I started blogging, I've published 40 articles, including this one. Broken down by year:

That jump in 2025 wasn't accidental. It came from better tooling around LLMs - agentic workflows that let me move faster without compromising quality.

And here's what often gets missed:

AI can generate words faster. That doesn't make writing meaningless. It makes decisions more meaningful.

• Getting unstuck: When you have a topic but can't get the draft moving, AI helps brainstorm approaches that make tricky sections easier for readers to follow.
• Simplifying content: If you tend to overwrite, AI can help trim and simplify sentences so key points land clearly.
• Spotting weak ideas: When a concept isn't strong enough to publish, AI helps you test, refine, or rethink it before hitting "publish."
• Grammar and clarity: If English isn't your first language, AI catches mistakes and smooths out phrasing - saving time and building confidence.

Efficiency didn't remove the human from the loop - it moved the human to the most important part of it.

Why I Write

This brings me to the question I haven't really answered yet: what actually keeps me writing? What do I get out of all this?

If I'm being honest, the most important reader of my blog has always been… me. I know how that sounds 🙂 but it's true. I've gone back to my own articles more times than I can count - usually when I've forgotten how I solved a problem months or years earlier.

Over time, my blog has quietly become a second brain. It's a searchable record of my thinking, experiments, trade-offs, and mistakes. Not polished textbook knowledge - but lived knowledge. And for me, that's far more valuable than perfectly curated tutorials written for an imaginary audience.

Another thing that doesn't get talked about enough: you don't truly understand something until you try to explain it.

Most of my posts don't start with expertise. They start with curiosity. I stumble across a new tool, pattern, or idea I want to explore. I try it. I break things. I hit dead ends. Then I write about what actually happened.

Writing forces me to slow down and be honest about what I do and don't understand. If I can't explain something clearly to a reader, that's usually a sign I don't understand it well enough myself. That friction isn't a problem - it's the point. The real learning happens in those "wait, that's not quite right" moments.

There's also a benefit I didn't fully appreciate until recently, especially relevant in an AI-driven world: well-documented blogs are AI-friendly by default.

Most of my articles come with a GitHub repository and a clear explanation of why things are built the way they are. I've started referencing my own posts when working with coding agents - asking them to read an article I wrote before extending a feature or refactoring a project. That feedback loop is surprisingly powerful. The blog isn't just content anymore - it's part of my tooling.

I'd write this blog even if I had zero readers.

Because the person who benefits most is my future self.

These posts save me time, sharpen my thinking, and make me a better engineer. If others get value from them too, that's a bonus - but it's no longer the primary reason I write.

My Approach

This post wouldn't feel complete without sharing how I actually write today - my workflow and the tools I use to turn an idea into a published article.

This is my current approach. It wasn't always like this. For years, the process was slower, more manual, and far more time-consuming. What I'm describing is a workflow I gradually adopted over the past year as my tools - and my mindset - changed.

Starting with an Idea

Like most things I write, everything starts with an idea.

That idea might come from a new CSS feature, a JavaScript or TypeScript language update, an interesting AI experiment, or a pattern I see someone else exploring. Sometimes it's genuinely new, other times it's an existing idea I want to investigate deeper and add my own perspective to.

Research Phase

Once I have a rough idea, I move into research.

Today, that looks very different from traditional "Googling." I rely heavily on tools like ChatGPT and Gemini - especially their web search and deep research capabilities. For me, these tools have largely replaced classic search engines. I use them to gather context, surface sources, and challenge my assumptions. That said, I don't blindly trust the output. I still manually review sources, decide what's relevant, and filter noise from genuinely useful information.

Proving the Idea

If the article involves code - which most of my posts do - the next step is proving the idea.

This phase decides whether an idea becomes a blog post or gets abandoned. If I can't make it work in practice, it's usually not worth writing about. The tools I use change from time to time, but the approach stays the same. I work with coding agents - Claude Code, Antigravity, GitHub Copilot, and similar tools - to build out the codebase and experiment with the idea.

The key is that I guide the agent closely. I provide context, constraints, and often the research sources I gathered earlier. This isn't a one-shot process. It requires iteration, feedback, and supervision. These tools are far better than they were a year or two ago, but they still need careful direction.

I also use a coding agent even for small changes. The reason is simple: context. The more context the agent has about the project, the more useful it becomes later - especially when drafting the article.

Once the idea is stable and proven, and I'm confident it's worth documenting, I generate a README.md for the repository and publish the code on GitHub. That becomes the foundation for the written piece.

Not every article follows this step. This post, for example, has no code - so there's no coding agent phase here.

Drafting the Article

Next comes the draft.

If there is a codebase, I start by asking the coding agent to produce an initial draft. At this point, the agent has the most context - it understands the code, the decisions, and the trade-offs - so it's surprisingly effective at generating a beginner-friendly, step-by-step outline.

That first draft is never great. It lacks personality and voice. But that's fine. It's a starting point.

I then move the draft into Notion, my primary writing tool. From there, I reshape everything: reordering sections, rewriting explanations, adding missing context, cutting unnecessary details, and injecting my own experiences and opinions.

Polishing with AI and Voice

Recently, I've also started using voice dictation more. I'll speak ideas out loud while walking, driving, or doing household chores. It's a small change, but it's made a big difference in keeping momentum - letting me add content even when I'm not at my desk.

Once the content is there - and it doesn't need to be perfect - I use Notion AI for polishing. I don't ask it to generate new content. I use it strictly to improve clarity, grammar, and flow. The article remains mine, the AI just helps clean it up.

Creating Visuals

The final step is visuals.

For cover images, diagrams, flowcharts, or charts, I rely on image generation models like Gemini and ChatGPT. For cover images, I'll often feed the entire article to the model and ask it to generate multiple prompt ideas from different angles. I refine the prompt I like most and generate variations until something feels right.

I'm aware that AI-generated images are often recognisable - and I'm okay with that. Perfection isn't the goal. Clarity and usefulness are.

For charts or data-driven visuals, I provide the data directly and have the model generate charts (often via Python), then iterate on them - making them more playful or better aligned with my branding.

As you can see, AI shows up at almost every step of this process.

That's just the reality of how I work today, and I'm not particularly precious about it.

Publishing

Once everything is ready, I publish the article on my personal blog. Since my blog articles are written in Markdown and Notion content converts cleanly, the final step is simple: copy, paste, publish.

And that's it.

That's how an idea turns into a blog post for me, right now.

How I Use My Own Content

Earlier, I mentioned that the most important reader of my blog has always been me. That isn't a throwaway line - it's the core reason this blog exists.

The articles I write are long-lived documents. I return to them months or even years later when I need to remember how I approached a problem, why I made a certain trade-off, or what didn't work the first time.

In the early days, that reuse was completely manual. I'd open an old article, reread it top to bottom, and retrace my steps line by line until the solution clicked.

That has changed.

Today, I still revisit my own writing - but now I reference my articles and repositories directly inside coding agents. When I'm working on a new feature or revisiting an old idea, I'll point the agent to a specific blog post or GitHub repo and ask it to use that context before suggesting changes or extensions.

That shift has been surprisingly powerful.

My blog has effectively become a structured knowledge base - one I can feed back into my tools.

One of my goals this year is to build an MCP server over my entire blog - making the archive natively accessible to agents. When that's ready, I'll update this section and document the process. I'm confident it'll become another feedback loop: writing improves tooling, and better tooling makes writing even more valuable.

Final Thoughts

After 40 articles, I've learned that blogging is about keeping up with yourself - not the internet.

AI-generated content is accelerating - more tools, more automation, more output. That's not a problem. It's how every major shift in technology begins. We're in the middle of another adjustment period, and like all revolutions, it feels noisy before it settles.

This is why I encourage more people to build their own knowledge base. Writing clarifies thinking and creates a trail you can return to later. These articles now save me time, guide my decisions, and feed directly back into the tools I use every day.