Elio Struyf

Are We Killing Indie Development with AI?

Elio Struyf — Sun, 15 Feb 2026 17:53:29 GMT

I get this feeling a lot lately. I wake up with an idea, grab a coffee, open my editor, and thanks to the current generation of AI tools, I can have a working prototype before breakfast.

The barrier to entry for software development hasn’t just been lowered; it’s effectively been removed. We are in the era of “vibe coding,” where natural language prompts turn into deployed applications in minutes. It is exhilarating. It is powerful.

But lately, I have started to wonder: Are we killing indie development with AI?

Don’t get me wrong, I love these tools. I use GitHub Copilot and other LLMs daily. But I believe we have reached a tipping point where the speed of building has outpaced the thinking part. We are so focused on how fast we can build that we stopped asking if we should build.

In this post, I want to talk about why we need a new “moral compass” for development in the AI age, and a potential solution to help us get there.

The speed trap

Five years ago, if you had an idea for a SaaS tool, say, a screenshot editor or a niche time-tracker,you had to sit down and plan. The friction of coding was a natural filter. You had to ask yourself: “Is this worth X hours of my life?”

Today, that cost is near zero. If you don’t like the screenshot tool you’re paying $15 a year for, you can prompt an AI to build a clone in an afternoon.

On the surface, this looks like freedom. But look a little deeper. That $15 tool you just cloned? It was likely built by another indie developer. Someone who spent months thinking about edge cases, designing the interface, writing documentation, and supporting users. By cloning it just because you can, you aren’t just saving $15; you are actively devaluing the craft of independent software development and the livelihood of the person behind it.

If we all just clone everything we use, we completely commoditize the market. We create a sea of “good enough” AI-generated noise where no one can actually sustain a business.

The tool is not the issue, it is the mindset

The life of an indie developer in the AI age

Let me paint a picture that I think a lot of developers are starting to recognize.

You spend weeks, maybe months, building something. You think about the problem, you design the interface, you handle the edge cases, you support your users, you write the docs. You pour yourself into it. Then one morning, someone sees your product, opens their AI editor, and builds a “good enough” version in an afternoon. They ship it. Maybe they make it free, maybe they make it open source, maybe they just use it themselves and tell their friends, their community, their followers.

They did not steal your code. They did not copy your product. They just… rebuilt it. Close enough. Good enough. And now your product has competition that cost someone a few hours of prompting while it cost you months of your life.

But it does not stop there. A third developer sees that clone and thinks, “I can do this too, but I want it slightly different.” So they prompt their own version. And a fourth. And a fifth. Each one is not a copy in the traditional sense. Nobody is violating a license. Nobody is stealing intellectual property. They are just building their own version that matches their use case.

It is a lot like art. You create a painting, something original, something you are proud of. Then somebody sees it and recreates it. Not a forgery, just their interpretation. But they have a bigger budget, a larger audience, better distribution. Suddenly their version is the one people see first. Others share that version instead of yours. This is what is happening a lot on social media with AI-generated content. The original creator is overshadowed by the faster, more accessible clone.

In the art world, we have a word for this erosion: it is called devaluation. In the software world, we are doing it at industrial scale, and we are calling it innovation.

I am not saying you should never build something that already exists. Competition is healthy, and sometimes a fresh perspective genuinely improves a category. But there is a difference between thoughtful competition and reflexive duplication. The question every developer should ask themselves is: “If I know someone can clone my work in an afternoon, is it still worth building?”

The answer, I believe, is yes, but only for the things that cannot be cloned in an afternoon. The deep domain knowledge. The community around your tool. The years of user feedback baked into every feature. The trust you have earned. Those are the things AI cannot reproduce with a prompt, and I definitely don’t want to discourage people from building those things.

But you can only build those things if you commit to something long enough for them to develop. And that is the real danger of the current moment: not that AI makes building easy, but that it makes abandoning easy. Why invest years in one product when you can ship a new one every week?

I am guilty of this too

I have no room to preach. I am right there in the trenches with you.

When I built Front Matter CMS, it was way before the AI boom. I had to think deeply about the problem because the investment of time was massive. I looked at the market, saw a gap in Visual Studio Code, and built it because nothing else existed.

Compare that to recently. I built a set of cycling tools (never released by the way) for myself. Did similar tools exist? Absolutely. Were they better? Definitely. But I wanted to see how far I could get with AI. I treated it as a training exercise. In the end, I started paying for a tool called Join, which does the same thing, because it was better and I could focus on my actual work instead of maintaining a tool that was just “good enough” for me.

I did the same with FrameFit. I investigated the market a little, didn’t see an exact match, and just started building.

There is a difference between building for education (learning how AI tools work) and releasing products that dilute the hard work of others. My worry is that we are blurring that line. We are shipping our “training exercises” as products, and it is making the ecosystem messy for everyone.

And I know this because I have been on both sides of it.

What actually survives

Here is the thing that made me stop and reflect. I have projects on both sides of this line, and they feel completely different.

Demo Time is something I have been building for years. Not weeks, not weekends, years. It started because I was a conference speaker who kept running into the same problem: demos failing on stage. Nobody had built a proper solution inside Visual Studio Code, so I did. Over time, it grew because I kept showing up. I used it at conferences, talked to other speakers, iterated based on real feedback from people doing real presentations at events like Microsoft Ignite, GitHub Universe, and OpenAI DevDays. Today it has over 26,000 installations.

None of that came from code. The code is open source. Anyone can see it, fork it, or rebuild it. Someone could probably vibe-code a basic version in a weekend. But what they cannot replicate is twelve years of conference speaking that taught me what presenters actually need. You would need that experience, or a big company and budget behind you, to even come close. The relationships with the community, the trust that comes from being the person who shows up, year after year, and keeps making the tool better because you genuinely use it yourself. That is not something you can prompt into existence.

Compare that to FrameFit. I built it, I use it, and it works. But if it disappeared tomorrow, I wouldn’t lose any sleep over it. Demo Time? That is like a child to me. I put my passion into it.

That contrast taught me something important: AI cannot commoditize the human context around software. Community, trust, domain expertise, showing up consistently over time. These are not features you ship. They are moats you build by caring about something longer than a weekend.

The developers who will thrive are not the fastest shippers. They are the ones who pair AI speed with human judgment. Who build communities, not just codebases. Who invest in trust, not just features. But that only happens if we slow down enough to think about what we are doing.

Problem is much bigger

In the first week of February 2026, the SaaS sector lost approximately nearly $300 billion in market value in just 48 hours. Traders are calling it the “SaaSpocalypse.” Salesforce is down roughly 30% year-to-date. Thomson Reuters dropped 16% in a single day. LegalZoom plummeted 20%.

The trigger? The launch of agentic AI tools like Claude Cowork and the realization that companies might no longer need to buy software when AI can do the work directly. Why pay per-seat licenses for a CRM, a legal research tool, or an analytics platform when an AI agent can handle 80% of those tasks autonomously?

This is the same dynamic I described above, but at enterprise scale. Indie developers see someone clone their $15 tool in an afternoon. SaaS companies see their entire business model questioned because a client can now reproduce “good enough” software internally, powered by AI, at a fraction of the cost.

The investors are not panicking because SaaS products are bad. They are panicking because the moat around those products, the complexity of building and maintaining enterprise software, is eroding fast. The same moat that used to protect indie developers.

The parallel is hard to ignore. Whether you are a solo developer with a screenshot tool or a billion-dollar company with a CRM platform, the question is the same: what do you offer that an AI cannot reproduce in an afternoon?

And the answer, I believe, is the same at every scale: deep domain knowledge, trust, community, and the human judgment to keep improving based on real-world use. The companies and developers who survive this moment will be the ones who invested in those things long before the SaaSpocalypse arrived.

The enterprise advantage

While smaller indie tools face existential threats from AI clones, larger SaaS platforms have built-in protections that are harder to replicate. The difference comes down to breadth and support.

A company using Salesforce isn’t just paying for a CRM. They are paying for integration with their email, their reporting tools, their customer support system, and dozens of other modules that work together seamlessly. Yes, someone could use AI to clone the contact management part in an afternoon. But cloning the entire ecosystem? The years of integrations, the training resources, the 24/7 support team that understands your business? That is not a weekend project.

The same applies to Adobe Creative Suite or Microsoft Office. You could vibe-code a decent text editor or image editor with AI. People will, but you will not replicate the entire suite of interconnected tools that designers and businesses have built their workflows around. The moat is not just the software; it is the ecosystem.

This dynamic actually makes the indie developer position even more precarious. The large SaaS companies can survive the clone wars because they offer a breadth of features and support that cannot be easily replicated. Indie developers, by definition, cannot. We are specialists, not platforms. We are vulnerable to the exact thing that makes enterprise software resilient: the ability to do one thing extremely well means we are easy to clone, while doing one thing well is all we have.

This is why the thinking process matters even more. If you are going to build as an indie developer in this era, it cannot just be “another screenshot tool.” It has to be the screenshot tool with the community, the support, the domain expertise, and the commitment to evolving with your users. You have to be willing to be the long-term partner, not the quick solution.

The thinking process

We need to re-introduce friction into our process. Not the old friction of writing boilerplate code. That friction is gone, and good riddance. I am talking about the friction of thinking. The pause that forces you to examine your intentions before you act on them.

Before AI, “thinking” was mandatory. The cost of building was high enough that it naturally filtered out bad ideas. Now, that filter is gone, and thinking must be a conscious, deliberate choice. When I have an idea now, I am trying to force myself to pause before I open Visual Studio Code or prompt a new agent.

I try to run through these four questions:

What problem does this actually solve? (Is it a real pain point, or just a cool feature?)
Does it already exist? (Have I actually looked, or am I assuming I’m the first?)
If it exists, what is my unfair advantage? (Why will mine be better? Is it just cheaper because I didn’t verify the edge cases?)
Can I make the existing solution better instead of rebuilding it?

That last one is crucial. If there is an open-source tool that does 80% of what you want, the “old” way was to contribute a Pull Request. The “AI way” often tempts us to just rebuild the whole thing from scratch because it feels faster.

But “faster” isn’t always “better” for the community. And here is the irony: we could use AI itself for this thinking step. Instead of prompting an LLM to start building, prompt it to research what already exists first. Use AI for the thinking, not just the building.

Introducing the “Product Moral Compass”

I don’t expect AI platforms that allow you to vibe code to solve this for us. Their business model is predicated on you writing more code (read: prompts), not less. They want you to spin up new projects constantly. They have no incentive to say, “Hey, wait, this already exists.”

Think about it: when was the last time you saw a developer advocate from one of these platforms demonstrate how to contribute to an existing project instead of building something new from scratch? Their marketing is all about speed, novelty, and the thrill of creation. Not about responsibility.

So, I started thinking: What if we used AI to stop us from building with AI? You could say that this is a paradox, but I think it is actually a necessary evolution of our responsibility as developers.

I am exploring the idea of a Product Moral Compass Agent.

Imagine a mandatory first step in your “vibe coding” workflow. Before you start generating code, you pitch your idea to this agent. It interviews you, not to judge you, but to make sure you are making an informed decision.

You: “I want to build a Chrome extension that organizes simple bookmarks.”
Agent: “Okay, analyzing… I found 3 highly-rated open-source projects and 5 indie SaaS products that do exactly this. Here are the links, the pricing, and what each one covers. Do you still want to proceed?”

This agent would act as the “thinking partner” we are skipping. It could:

Perform deep market analysis in seconds.
Surface existing open-source repos you could contribute to instead.
Present paid alternatives with pricing, so you can see what $15 a year actually gets you.
Challenge your unique value proposition with honest questions.

If you still want to build it after that? Great. Go ahead and start coding. But at least you are making an informed, conscious decision rather than reflexively adding more noise to the world.

The challenge

I am currently building this agent. The first version is available on GitHub: Product Moral Compass Agent. Yes, I am aware of the irony, I am proposing to build something new to stop people from building new things. But I ran it through my own four questions first, and nothing like it exists yet.

Once it is ready, I will share it openly so that any developer can use it as part of their workflow. Not as a gatekeeper, but as a guide. A thinking partner that helps you pause, research, and decide before you build.

In the meantime, here is what you can do right now: the next time you have an idea, spend ten minutes with your favorite AI tool and ask it to find every existing solution first. Check your own bank statements. Are you already paying for a tool that solves this? If so, respect that developer’s work. Look at GitHub. Is there a repo that could use your help instead of your competition?

The time to learn is right now, but the time to think is also right now.

I want you to keep building. I want you to be prolific. But let’s not let the ease of creation destroy the value of what we create.

I am curious to hear your thoughts. Is this gatekeeping, or is it a necessary evolution of our responsibility as developers? Let me know in the comments below.

Resources

Stop typing, start talking

Elio Struyf — Fri, 13 Feb 2026 10:12:50 GMT

I must admit, the way I interact with my computer has changed drastically over the last few months. As developers, we are used to living on the keyboard. We learn shortcuts, we buy mechanical keyboards, and we pride ourselves on our typing speed.

But recently, I realized something: I am spending less time writing code and more time writing prompts.

Whether I am communicating with Claude, Gemini, GitHub Copilot, or just replying to messages on LinkedIn, the volume of text I need to produce has gone up. That is why I decided to stop typing and start talking.

In fact, the draft for this very post was created using my voice. It is a shift that has made my workflow significantly faster, even if it took me a while to get comfortable with it.

The awkward phase

This isn’t my first attempt at voice control. A couple of years ago, GitHub released GitHub Copilot Voice, which allowed you to code by talking.

It wasn’t for me. Trying to articulate complex code syntax out loud felt unnatural and slower than just typing it out. I gave it a try, but I quickly went back to my keyboard.

The turning point came recently when Andrew Connell (AC) told me he was using a tool called Wispr Flow to handle dictation. He wasn’t using it to write if statements; he was using it to dump thoughts into documents, emails, AI prompts, and more.

I was intrigued. Since December, I decided to make voice my main method of “typing” for long-form text. I started with a generic Whisper wrapper for about a month, and while it was an improvement, I eventually found a tool that fit my workflow perfectly.

Why Handy won me over

I discovered a tool called Handy, and it has become a daily driver for me.

The beauty of Handy lies in its simplicity. Use tools to remove friction, not add to it. Handy starts up when my device boots, and it stays out of the way until I need it.

Here is how that works in practice:

I press my global hotkey (for me, it’s Option + R).
I start talking.
I release the keys when I’m done.
Handy transcribes the audio and pastes the text directly into whatever window is in focus.

Under the hood

Handy uses the Parakeet V3 model for transcription, but it has many more. I was pleasantly surprised by the accuracy. English isn’t my native language, so I sometimes worry about an AI understanding my accent. However, it does a really good job.

It even handles my mother tongue, Dutch, although I don’t use it often.

The workflow shift

Don’t get me wrong, this workflow has a specific time and place.

I work from home, which is the ideal environment for this. I can talk to my computer without feeling awkward or annoying people around me. I am definitely not going to use this while working from a coffee shop!

But in the privacy of my home office, it is a game-changer for:

AI Prompting: Explaining a complex problem to an AI is much faster when you treat it like a conversation.
Social Media: Replying to comments or scrolling through LinkedIn is effortless when you can just speak your reply.
Drafting Content: Like this interview/article process.

Is this the future?

As we rely more and more on natural language to interface with technology, voice input feels like the logical next step. It is simply more convenient to say what you want than to type it.

Will keyboards disappear? No! AI is evolving so rapidly, and new tools are being created every single day. Perhaps in the future, the models will anticipate what we want before we even speak. But for right now, swapping my keyboard for a microphone has made me a lot faster.

If you find yourself typing endless paragraphs to your AI assistants, give voice dictation a shot. It might just change how you work.

Resources

Is blogging still a thing? Thriving in the AI era

Elio Struyf — Thu, 05 Feb 2026 14:01:59 GMT

Let’s address the elephant in the room immediately: Is blogging still a thing?

With the rise of Large Language Models (LLMs) and generative AI, the internet is flooded with content. You might be wondering if it’s worth investing hours into writing a post when a bot can generate a 1,000-word article in seconds, or when users can just ask ChatGPT for an answer instead of visiting your site.

The short answer is: Yes, it still matters., but the way we blog, the reason we blog, and who is reading our blogs has changed firmly.

I love blogging. It helps me clarify my thoughts and share knowledge. However, my approach has evolved. I’ve stopped fighting the AI wave and started surfing it, using it to amplify my voice rather than replace it. Here is the reality of blogging in 2026 and how you can adapt.

The reality check: where did the humans go?

If you have looked at your analytics lately, you might have noticed a trend: human traffic is dipping, but “visitor” numbers might be steady or even rising. If you dig deeper, you’ll realize those aren’t people. They are bots.

Specifically, they are AI crawlers.

I recently checked my Cloudflare logs, and the activity is undeniable. My site is being crawled heavily by agents like ChatGPT-User (OpenAI), PetalBot (Huawei), and Meta-ExternalAgent.

Here is a snapshot of what that traffic looks like on my end (the last 24 hours):

ChatGPT-User: 2.22k requests
BingBot: 499 requests
Meta-ExternalAgent: 498 requests

Cloudflare - AI Crawl Control

If I dig deeper, for the ChatGPT-User agent, I can see that the most requested pages are my review posts.

Most crawled pages by ChatGPT

The shift in consumption

In the past, a user would search for a problem, click your link, read your tutorial, and maybe leave a comment. Today, an AI model scrapes your content, ingests the knowledge, and summarizes it for the user directly in a chat interface.

This drives users away from your site. It is a harsh reality.

We saw ta brutal example of this recently with Tailwind CSS. Auhenticity and community are vital, but for businesses relying on documentation traffic, AI can be devastating. Adam Wathan, the creator of Tailwind, noted in a GitHub discussion that traffic to their documentation dropped 40% from early 2023, despite the framework being more popular than ever. This loss of direct traffic contributed to significant layoffs because the docs were the primary funnel for their commercial products. Blogs and product documentation are not the same, but the principle remains: if AI can answer your users’ questions without them visiting your site, your direct relationship with your audience weakens.

The problem with “AI slop”

Because AI is eating up traffic, many creators have responded by using AI to churn out mass content to game the system. You have seen these posts. They are soulless.

They overuse emojis 🚀✨
They use dashes and bullet points for everything.
They adopt weird fads, like writing entire articles in lowercase.
The prompt was clearly just: “Hey AI, write a post about X.”

As a reader, when I encounter this, I stop reading immediately, certainly when text is written in all lowercase. My mind cannot focus on it. It breeds distrust. If you didn’t care enough to write it (or at least structure the thought), why should I care enough to read it?

Authenticity is your only moat. The specific reason my reviews are currently my most-read content is that they are deeply personal, subjective, and based on real-world testing, things AI cannot fully fake yet (or maybe it can).

A new workflow: interviewing myself

So, how do we balance efficiency with authenticity? I don’t write entirely manually anymore, but I also never let AI write from scratch.

My secret weapon is getting interviewed by AI (not so secret anymore).

I use a tool called Ghostwriter. It started as AI agents, evolved into an Electron app, and now includes a VS Code extension. Instead of staring at a blank page, I initiate an interview session. That way, I get to speak my thoughts out loud, and the AI captures them. It are my words, my voice, and my opinions, but structured by AI.

How it works:

The interview process

I tell the AI the topic I want to cover (e.g., “Is blogging still a valid career?”).
The AI acts as a journalist. It asks me 10 to 50 specific questions depending on the depth required.
I answer these questions.
Once the interview is complete, a transcript is available for the writer agent to process.

The writing process

Once the interview is complete, I assign the transcript to the writer agent.
It compiles my answers into a structured blog post.
From the draft, I can ask to do further refinements, like adding an introduction, conclusion, or formatting code blocks.

To block or not to block?

Given that bots are scraping our content and lowering our direct traffic, should we block them?

It depends on your goal.

Scenario A: the passion blogger

If blogging is a hobby, a personal brand play, or a way to learn (like it is for me), let the bots scrape.

I am not going to block AI bots. I believe my content provides value, and if that value reaches a user via ChatGPT or via my website, I am generally okay with that. My goal is to share knowledge. I’ve been blogging since 2010 and I know that blogging is not going to generate a source of income for me directly. It is a way to build my personal brand, share knowledge, and connect with like-minded people.

Scenario B: the business

If your blog is your product, like the Tailwind documentation, you need to be strategic. If AI is answering your customers’ questions without them ever seeing your product pitch, your business model is bleeding.

In this case, you are not being hostile to progress by blocking bots in your robots.txt; you are protecting the direct relationship with your audience that keeps your lights on.

The verdict

Blogging is not dead, but the era of “content farming” is over.

If you want to blog in 2026:

Make it YOURS. Authenticity is the only thing AI cannot replicate.
Go Shorter. People (and bots) want concise info. You don’t always need a 2,000-word essay.
Use AI as a tool, not a creator. Let it interview you. Let it format for you. Do not let it think for you.
Diversify traffic. You could build an email list, show up on social, and encourage direct visits. Organic search is less reliable now.
Build a community. Engaged readers matter more than raw traffic. Reply, ask questions, and create a place for people to gather.
Build in public. Show your work, share decisions, and invite feedback. That kind of transparency is hard to fake with AI.
Check your stats. Know who is reading—humans or machines—and decide if you need to protect your content.
Blog to support, not replace, your brand. You won’t build a personal brand through blogging alone. Combine it with speaking, building products, or creating tools. My blog supports my conference talks and Demo Time work—it’s part of the ecosystem, not the whole thing.

I still learn best by writing. I write to clarify my thinking. If that’s why you blog, keep going. The bots can watch, but they can’t replace the human spark.

Resources

Ghostwriter for VS Code - The extension I use for AI interviewing.
Ghostwriter Agent Definitions - The specific “Interview” agent I use.
How I get interviewed by AI - My detailed guide on this workflow.
Tailwind CSS Discussion - Commentary from Adam Wathan on the impact of AI on documentation traffic.
Cloudflare - How to block AI crawlers - Guide on blocking AI crawlers with Cloudflare.

Ghostwriter for VS Code: your AI interviewer in your editor

Elio Struyf — Fri, 30 Jan 2026 10:08:05 GMT

Last week, I was experimenting with the GitHub Copilot SDK to see how to use it within an Electron app. That experiment led to the creation of the standalone Ghostwriter App. But as I was building it, I realized something important.

Why leave the editor?

Most of us live in Visual Studio Code. Switching context to a separate app just to draft a blog post feels like friction we don’t need. So, I decided to minimize that friction.

Ghostwriter for VSCode

In this post, I want to introduce you to the Ghostwriter for VS Code extension. It brings the concept of “interview-based writing” directly into your favorite editor, leveraging the GitHub Copilot Chat API without needing the CLI or complex SDK setups.

The problem with AI writing

We have all seen that kind of AI content. You know the type of content, it sounds smart but says nothing useful. That’s what you get when AI writes for you instead of with you.

The standard workflow usually looks like this:

Open ChatGPT or Copilot.
Type: “Write me a blog post about React hooks.”
Get a wall of text that sounds like everyone else.
Spend an hour rewriting it to sound like you.

I wanted to flip this script.

AI-assisted writing works best when it acts as your interviewer, not your ghostwriter.

Enter Ghostwriter for VS Code

The core philosophy behind the entire Ghostwriter ecosystem is simple: You are the expert. The AI’s job is just to get the information out of your head and organize it.

Instead of prompting an AI to generate content from thin air, Ghostwriter facilitates a conversation. It asks you thoughtful questions to draw out your unique insights, experiences, and specific examples. Then, and only then, does it structure those answers into a polished draft.

And now, you can do this right inside VS Code.

How it works

I already integrated similar chat-based functionality into Front Matter CMS, so extending this logic to a dedicated extension felt like a natural progression.

Here is how the workflow looks in practice:

Open the Extension: You start a new session within VS Code by using the Ghostwriter: Open Ghostwriter command.
The interview: The extension (powered by GitHub Copilot) starts asking you questions based on the topic you want to cover.
Your answers: You answer casually, just like you are talking to a colleague. You share your war stories, your code snippets, and your opinions.
The writing: Once the interview is done, you can use the transcript to generate a draft blog post, article, or documentation.

The result isn’t a generic AI article; it’s your article, organized by AI. It solves the “blank page” problem without sacrificing authenticity.

Ghostwriter extension homepage

The interview process

Writing the draft

The generated draft

Building the extension

Technically, building this was a fun challenge. I wanted to showcase how you can use GitHub Copilot’s capabilities from an extension without actually requiring the heavy lifting of the GitHub Copilot CLI or the full SDK for every little interaction.

By tapping into the chat API provided to VS Code extensions, I could create a lightweight wrapper content creation workflow. It removes the need for you to manually manage agent files or prompts, you just experience the app.

For those interested in the code, or if you want to see how I handled the conversation flow, the project is open-source.

Why this matters

I wrote deeper about the philosophy of “interview-based writing” in a previous post: How I was interviewed by AI to write blog posts.

The gist is this: It is faster than writing everything from scratch, but it is far more genuine than pure AI generation. It captures your voice because the source material is literally your voice.

If you have valuable knowledge to share but struggle to structure it, this tool offers a middle path.

Try it out

The extension is part of a growing ecosystem. If you prefer a standalone experience, you can still check out the experimental Electron App. But for my daily workflow, staying in VS Code is king.

You can install the Ghostwriter extension from the VS Code marketplace.

I am keen to hear what you think. Does being “interviewed” help you write better? Give it a spin and let me know.

Happy writing!

Resources

Ghostwriter Agents: github.com/estruyf/ghostwriter-agents-ai
Ghostwriter App (Electron): github.com/estruyf/ghostwriter-app
Original Article: How I was interviewed by AI to write blog posts

Exploring the GitHub Copilot SDK: Building a Ghostwriter App

Elio Struyf — Mon, 26 Jan 2026 10:10:06 GMT

As a developer, I am always curious about how to optimize my workflow, especially when it comes to writing technical content. That was part of the reason I started to create the Ghostwriter Agents for AI. One of the things I tried to take it a step further was to build a “Ghostwriter” application, but I never got around to finishing it. The reason was the AI layer. Should I build my own? Use an existing API?

With the release of the GitHub Copilot SDK I decided to revisit that idea. This artilce is the story of how I used the SDK to finally build my Ghostwriter app, and the lessons I learned along the way.

The challenge: seamless AI integration

My goal was simple. I wanted an application that could act as an interviewer, asking me questions about a topic, and then use my answers to draft a post.

I already had the prompts ready in my Ghostwriter Agents AI project:

Interviewer: A persona that digs into the topic.
Writer: A persona that takes the interview context and generates the article.

The missing piece was the “glue.” In my previous attempt, managing the AI context and API calls was a headache. I wanted something seamless, where I could just use what is already available in the ecosystem without reinventing the wheel.

Starting with Astro

I must admit, when I first looked at the Copilot SDK, documentation was a bit scarce. There were some videos, but not many concrete samples. But hey, that’s part of the fun of the job, right? The best way I learn is by starting a new project.

I spun up a new Astro project. My plan was to create a simple website with an API that communicated with the Copilot CLI.

Here is the cool part: I actually used GitHub Copilot to write the integration code for me. I pointed it to the GitHub Copilot SDK - Getting started page in the documentation, and it scaffolded the connection almost perfectly. All I had to do was review it to understand how the data flowed.

Ghostwriter as an Astro website

The pivot to Electron

The Astro prototype worked great for the interview logic, but I hit a snag when I thought about distribution.

The Copilot SDK relies on communicating with the Copilot CLI. If I hosted this as a web app, the backend wouldn’t have that local CLI connection. I needed this to run locally on the user’s machine.

I initially thought, “Perfect, I’ll build a Tauri app!” I love working with Tauri, and it seemed like a natural fit. Unfortunately, the SDK doesn’t support Rust just yet. So, I decided to move the project to Electron.

Solving the packaging puzzle

Moving to Electron solved the runtime issue, but it introduced a new one: packaging. When I tried to bundle the application, the communication with the Copilot CLI kept failing. It was one of those “it works on my machine” moments that drives you crazy.

That is when I discovered a feature that saved the project: the Copilot CLI Server.

Instead of relying on the default environment integration, you can manually start the Copilot CLI in server mode on a specific port.

1
copilot --server --port 4321

Once that server is running, you can tell the SDK exactly where to look. Here is how I configured the client in my Electron app:

1
import { CopilotClient } from "@github/copilot-sdk";
2

3
// Connect to the local CLI server
4
const client = new CopilotClient({
5
    cliUrl: "localhost:4321"
6
});
7

8
// Use the client normally to start the interview session
9
const session = await client.createSession();

By spawning the CLI server when the Electron app starts, I established a reliable bridge between my UI and the AI.

The result

With the connection fixed, the app now works exactly as I imagined. It runs the “Interviewer” agent to gather my thoughts, passes that context to the “Writer” agent, and generates a draft. All powered by the Copilot account I’m already signed into.

Don’t get me wrong, it’s still an early version, but the friction of “building the AI” is completely gone. I can focus entirely on refining the prompts and the user experience.

The Ghostwriter app

Conclusion

The GitHub Copilot SDK is a game-changer for developers looking to integrate AI into their applications without the overhead of managing authentication, AI, and API complexity. My journey from a stalled project to a working Ghostwriter app in Electron is proof of that.

What impressed me the most was how smoothly things came together once I understood the core concepts. The SDK abstracts away the messy parts like token management, session handling, streaming responses. It leaves you free to focus on your prompts and user experience.

If you’re sitting on an idea that needs AI capabilities, the Copilot SDK removes one of the biggest barriers to entry. No need to negotiate with multiple API providers or implement your own LLM infrastructure. Just point to your local CLI, define your prompts, and build.

The journey wasn’t completely frictionless. The initial documentation gap and the Electron packaging hurdle taught me a thing or two, but those are the kinds of challenges that are good to think out of the box, use your creativity, or GitHub Copilot to get it solved.

Let me know what you think if you give the SDK a try.

Resources

VS Code Workspaces for better AI assistant context

Elio Struyf — Thu, 15 Jan 2026 10:25:20 GMT

I get this question a lot: “How can I give my AI coding assistant context across multiple projects?” If you’re working with a separate frontend and backend, or any split repository setup, you’ve probably run into this problem yourself. Your AI assistant only sees the code in the current project, which means you end up repeating yourself, explaining data structures, and essentially acting as a translator between your projects.

Here’s a quick tip that changed my workflow: use VS Code Workspaces as a “virtual mono-repo” for AI context.

The problem with separate projects

When you have your frontend and backend in different folders (or even different repositories), opening them in separate VS Code instances means your AI assistant lacks the full picture. Want to create a dashboard that fetches data from your API? You’ll need to be very detailed about the data structures, the API endpoints, and the implementation details in each project separately.

I previously avoided workspaces, preferring separate VS Code instances or actual mono-repos. But not every project allows for a mono-repo structure, and that’s where this trick comes in handy.

The solution: VS Code Workspaces

A VS Code Workspace lets you open multiple folders in a single editor instance. For AI coding assistants, this means they can see both your frontend and backend code simultaneously. Instead of manually specifying data structures, the AI can discover them from your backend and implement matching code in your frontend, all in a single prompt.

Here’s the practical difference:

Without shared context: “Create a dashboard component. The API returns an object with sessionName (string), description (string), and managementUrl (string)…”
With a workspace: “Create a dashboard that displays the session data from the API”, and the AI figures out the data structure from your backend code.

How to set it up

Setting up a workspace takes less than a minute:

Open one of your projects in VS Code
Click File in the menu bar
Select Add Folder to Workspace
Choose your second project folder (e.g., your backend if you started with the frontend)
Both projects now appear in the Explorer sidebar

Tool compatibility

I’ve tested this approach with different AI assistants, and here’s what I found:

GitHub Copilot: Works great. Copilot natively understands the workspace context and can reference code across all folders in your workspace.
Claude: Also works, but takes a different approach. Claude tends to use bash scripts to find the backend location rather than directly leveraging the workspace context. Still functional, just less seamless.

Why this matters

The real value here isn’t just convenience. When your AI assistant has full context, it produces more coherent code. It understands the relationship between your frontend and backend, uses consistent naming, and catches type mismatches before they become runtime errors.

If you’re building full-stack applications and using AI coding assistants, give workspaces a try. It’s a simple change that can make your AI collaboration significantly more effective.

Resources

Why code review and testing matter more than ever with AI

Elio Struyf — Thu, 08 Jan 2026 11:41:14 GMT

A couple of days ago, I posted a tweet that sparked more controversy than I expected. The message was simple: “Always review the code AI generates. Here’s an example where it thought it was a good idea to add a hardcoded file path to load an image.”

The responses? Let’s just say not everyone was on board with my approach.

“Perhaps it is a better solution to write the code yourself in the first place? Microslop and other companies going all-in on ‘AI’ are soon to see it fail them completely, why waste time on it now?”

“Perchance, learn to program yourself. Get good, etc.”

These dismissive comments became the catalyst for this post. Because here’s the thing: those critics are missing the point entirely. This isn’t about whether AI is “good enough” or whether we should use it at all. It’s about how we adapt our workflows to work effectively with AI while maintaining the quality and reliability our users deserve.

The hardcoded path that started it all

Let me tell you about the macOS notch app I built. I wanted a simple utility to show my currently playing music and GitHub Copilot premium request status in the notch area. There’s one small problem: I don’t know Swift. At all.

So I did what any developer in 2026 would do. I created a project plan and handed it over to GitHub Copilot. Within a couple of hours, I had a working application. It ran perfectly on my Mac Mini. Everything loaded, the interface looked great.

Later that day, I switched to my MacBook. The app launched, but something was wrong. The images weren’t loading. That’s when I actually looked at the code.

1
func loadCopilotIcon() {
2
    // Multiple attempts to load icon
3
    let path = "/Users/eliostruyf/Developer/nodejs/DevNotch/assets/$2x32.png"
4
    // ... more hardcoded paths
5
}

There it was. A hardcoded file path. With my username. From my Mac Mini. The AI had generated code that worked perfectly in one context but failed completely in another.

If this had been production code and I hadn’t caught it during development, customers would have discovered the issue for me. And that’s never a good look.

What code review actually catches

Here’s what I advocate at conferences/events/talks and what I failed to do myself: review AI-generated code. Not because AI is inherently bad, but because it doesn’t always understand the full context of what you’re building.

The hardcoded path issue required code review to catch. There were no tests yet. I discovered it by manually reading the code after the failure. But this brings up an interesting question: what if you don’t have time to review every line? What if you’re moving fast and the code “just works”?

This is where testing becomes your safety net.

Testing as your AI safety net

I’ll be honest. Even though everyone should review code, especially AI-generated code, people will still blindly accept what’s created because “it just works.” I’ve done it myself. We’re all human, and we all take shortcuts.

Having good tests in place ensures everything that already works keeps working as intended. Tests don’t get tired. They don’t skip steps. They don’t assume that because something worked yesterday, it’ll work today.

Here’s my testing approach:

Create use cases first
Create the solution from those use cases
Create end-to-end tests from the solution and use cases

For E2E testing, I use Playwright. It gives me several critical capabilities:

Screenshot matching: Verify that the UI looks exactly as expected
User flow validation: Ensure buttons work and trigger the right actions
API verification: Confirm that backend calls happen correctly
Change detection: Catch unexpected modifications

This is particularly powerful with AI-generated code. You’re informed by tests that things changed, even if you didn’t catch it during code review.

How my workflow has evolved

I spend less time writing code these days. That probably sounds strange coming from someone who loves developing things, but it’s true. Instead, I spend more time:

Reviewing code
Thinking about what I want AI to create
Defining use cases and requirements
Running tests and validating outcomes

I still write code myself when I can’t explain to AI how to do certain things, or when I have it so clear in my head that it’s faster to just write it. I still love developing things personally. But AI agents allow my creativity to take the lead, and I can do things much quicker.

Understanding the fear

Those dismissive responses to my tweet? They didn’t come from a place of technical superiority. They came from fear. And I get it. People are afraid AI will take over jobs. And yes, it will take over things. But that fear is causing some developers to dig in their heels rather than adapt.

Let me break down what I think is actually happening when developers react negatively to AI:

Layer 1: Job displacement anxiety

This is the most visceral fear. You watch AI generate working code in seconds, and you think: “What does this mean for my career?” This hits junior developers especially hard. They’re wondering if the traditional entry path into development is being automated away before they even get started.

Layer 2: Loss of craft

Developers love the puzzle-solving aspect of programming. There’s a worry that relying on AI will atrophy skills. That the profession becomes about prompt engineering versus actual engineering. There’s an identity component here: if code generation becomes trivial, what makes a developer valuable?

Layer 3: Quality and understanding concerns

This is more pragmatic. Developers who’ve debugged AI-generated code that looked plausible but was subtly wrong understand this fear. There’s anxiety about teams adopting AI without understanding its limitations, leading to technical debt or security vulnerabilities.

Layer 4: Economic uncertainty

Productivity gains mean companies might need fewer engineers. The bar for “good enough” code might drop, so non-developers can build what used to require specialists. This is a legitimate business concern, not just individual anxiety.

Layer 5: The irony

Here’s what I’ve observed: developers who actually integrate AI into their workflow, using Copilot or Claude for tedious bits while focusing on architecture, debugging, and genuinely hard problems, end up LESS afraid, not more. Fear seems highest among those who haven’t found equilibrium with these tools.

The skills that will matter

Eventually, AI code will be perfect. Or close enough. But we’ll still need to understand if it produces expected outcomes. We need to stay in control, and testing gives us that control.

Here are the skills and mindsets that will become most valuable:

Creativity

This is the core fundamental skill. AI can write code, but it can’t imagine the solution your users actually need. That comes from you.

Systems thinking over syntax mastery

You need to understand what AI creates. Development and learning to develop is very important right now, but the focus shifts from memorizing syntax to understanding how systems work together.

Taste and judgment

Can you make judgment calls on whether what’s been created fits your current solutions, patterns, and architecture? Does it feel right? Does it align with your team’s standards?

Problem decomposition

Understanding business problems and formulating them into well-scoped tasks and use cases becomes critical. If you can’t clearly define what you want, AI can’t build it effectively.

Debugging and verification

AI is getting better, but sometimes it can’t do what humans can. You need full control over the environment your app is running in. You need to understand what’s happening under the hood and figure out how to solve things when they go wrong.

Communication and collaboration

The technical ceiling is rising for everyone, so differentiation happens elsewhere. Developers who can translate between business stakeholders and technical teams, mentor others, write clearly, and present well become force multipliers.

In my conference experience, the speakers who resonate aren’t always the deepest technical experts. They’re the ones who make complex ideas accessible.

Comfort with ambiguity and continuous learning

The landscape is shifting fast. Clinging to a fixed skill set is risky. A mindset of “I’ll figure it out” beats “I already know this” every time.

Actionable advice for skeptical developers

If you’re feeling anxious or skeptical about AI tools, here’s my advice: pick one small, annoying task you’ve been putting off. Something tedious but not critical. Not your main project, not anything high-stakes. Maybe:

Writing tests for a module you’ve neglected
Converting old code to a newer pattern
Drafting documentation
Scaffolding a small utility script

The point isn’t to be impressed. It’s to get hands-on experience with what AI does well and where it falls short. Abstract fear thrives on imagination. Practical experience replaces it with calibration.

Here’s what you’ll find:

AI gets you 80% of the way surprisingly fast
You’ll spend time fixing the last 20%, and that’s instructive
You’ll start developing intuition for when to reach for AI and when to write code yourself
You’ll discover which prompts yield useful output versus confident nonsense
You’ll shift from “will this replace me?” to “how do I use this effectively?”

The organizational reality

When I talk about testing at companies, I actually get no pushback. People already know they need to test. They acknowledge testing is important. They recognize they need to do this for their solutions.

The real problem isn’t resistance to the idea. It’s taking the time to actually start doing it. It’s the problem of procrastination: “We are going to do this later.” Pushing it down the road instead of implementing it now.

The companies that have successfully made this shift? Most were already using E2E tests. Specifically, the companies I work for already had E2E tests because I implemented them. These companies had a much quicker and easier start when adopting AI during their development lifecycle.

For them, it wasn’t really a change because everything was already there. Having tests in place BEFORE adopting AI made the transition smooth. The safety net was already built.

Start embracing, learning, and using it

We should NOT be afraid of AI. We should embrace it, learn to use it, and get used to it. If we stay stuck in old routines, others will overtake us.

Use your strengths. Use your creativity to come up with solutions. And most importantly, start doing what we’ve always advocated: testing.

Write use cases. Develop end-to-end tests to validate your solutions keep working. Know what works after new features are implemented. Testing isn’t new, but it’s crucial now because we don’t always know what AI is creating or doing.

Even if people don’t review code as thoroughly as they should, tests catch issues before production. That’s the safety net that lets you move fast with AI without breaking everything.

Don’t stay stuck. Don’t let fear drive your decisions. Start small, build intuition, and adapt. The future of development isn’t about choosing between human code and AI code. It’s about knowing how to work with both effectively.

Resources

My evolving relationship with AI in development - My journey from prompt engineering to agentic AI
My AI Code Review Journey: Copilot, CodeRabbit, Macroscope - Exploring various AI code review tools
GitHub Copilot - AI pair programmer
Playwright - End-to-end testing framework
Claude - AI assistant for development tasks

Reflecting on 2025: Finding Joy and Creating Value

Elio Struyf — Mon, 22 Dec 2025 16:06:57 GMT

As the year comes to a close, it is time to reflect on the past 12 months. 2025 has been a “transformative” year for me, not just in terms of the code I wrote or the talks I gave, but in how I approach my work and life. It was a year where I actively sought to rediscover joy in what I do, embraced a new way of working with AI, and started thinking about a sustainable future for my projects.

In this post, I want to share the story of my 2025, the highlights, the lessons learned, and a glimpse into what 2026 holds.

Highlights of 2025

Here are some of the key moments from this year:

13.000km cycled: Completed my biggest cycling year yet, where I had my personal best on the Mont Ventoux, but also my worst time, six weeks later on it.

Reaching the summit of Mont Ventoux

Demo Time’s explosive growth: Reached over 26,000 installs and saw it used at major stages like OpenAI DevDays, Microsoft Ignite, and GitHub Universe.
Launching EngageTime: Built and successfully tested a new attendee engagement platform at CollabDays Belgium and VisugXL.
Speaking across Europe: Delivered 15+ sessions at conferences including ESPC, Techorama, and the European Collaboration Summit.
Embracing Agentic AI: Shifted my workflow to treat AI as a teammate, allowing me to build tools like FrameFit in just 3 hours.
Hugo to Astro migration: Successfully migrated my blog to Astro after 6 years with Hugo, improving my developer experience.
Community contributions: Published 30 blog posts and continued my journey as a Microsoft MVP, GitHub Star, and Google Developer Expert.

2025 in Numbers

I love looking at the data to see what I’ve been up to. Here is a breakdown of my year in numbers:

5378 GitHub commits
41 New repositories created
26,000+ Demo Time installations
30 Blog posts published
15+ Speaking engagements
13,000 Kilometers cycled
50.000.000 badges generated with the Visitor Badge service

GitHub Stats from 2025

Finding joy and creativity

At the start of the year, I realized I needed to get to know myself better. I wanted to find a way to get more joy out of my work, and to identify what gives me energy and what drains it. I decided to work with a coach, and it was one of the best decisions I made.

This journey allowed me to explore my creativity again. It started with small things, like building a simple app to update my desktop background with the daily Microsoft Bing image, just because seeing a beautiful new landscape each day made me smile. It extended to practical tools, like an app to check the number of remaining GitHub Copilot premium calls. These small projects were the spark I needed to reignite my passion for building.

Embracing AI as a teammate

A huge part of this creative rediscovery was shifting how I work with AI. I moved from simple prompt engineering to an “agentic-first” workflow. I stopped just asking for code snippets and started treating AI as a partner in the development process.

The Bing wallpaper app, for instance, was purely created with GitHub Copilot and coding agents. I defined what I wanted and the technology stack, and we built it together. This new workflow allowed me to be more ambitious. I built FrameFit, a macOS screenshot utility, in just three hours. It wasn’t about replacing my skills; it was about removing the friction between an idea and its execution.

Getting interviewed by AI

One of the experiments I ran this year was changing how I write. Inspired by Daniela Petruzalek’s Speedgrapher, I started using AI not just to generate text, but to interview me.

I created a set of Ghostwriter Agents that work across GitHub Copilot, VS Code, and Claude. The process is simple: an AI agent interviews me about a topic, asking open-ended questions to capture the context and narrative. Then, another agent analyzes my writing style (my “voice”), and a third agent combines the transcript and voice profile to draft the post.

The process reshaped my writing: it makes me explain the reasons behind my choices and teases out the narratives that vanish in a blank editor. This post began as an AI-led interview that I later edited and shaped into the final draft.

From passion project to sustainable future

One of the most important lessons I learned this year is about value and freedom. I used to think that making all my tools available for free was the ultimate form of freedom. I realized that wasn’t the case. Value is creating the freedom.

Demo Time is the perfect example. It started as a tool to solve my own frustration, because “demos are meant to fail.” Today, it’s a staple for speakers worldwide. To ensure I can keep supporting and innovating on it, I announced a plan to build a sustainable ecosystem around it, while keeping the core extension free and open-source. This shift in mindset is crucial for the longevity of the projects I love.

The birth of EngageTime

This year also saw the birth of a major new project: EngageTime.

As a speaker and organizer since 2012, I’ve always felt something was missing. I wanted a “Bird’s-eye view” of my sessions—better feedback, easier connections, and a seamless experience for attendees. In June, I started listing these frustrations, and EngageTime was the answer.

We tested it live at CollabDays Belgium and Visug XL, and the results were fantastic. Seeing attendees join sessions by simply scanning a QR code—no auth, no app download required—and interacting in real-time was a validation of the vision. It proved that we were solving a real problem.

EngageTime in action at Techorama NL

Looking forward to 2026

It doesn’t matter where you go, as long as you do it with a big smile.

As I look toward 2026, I have some big goals:

Commercializing EngageTime: I will start selling EngageTime to events and speakers, with a foundational talk coming up in early January.
Schleck GranFondo: My first major personal goal of the year is to ride the Schleck GranFondo in May.
Tour des Grands Cols Alpes: Later in the year, I will embark on a 7-day cycling tour with 17,000 meters of elevation. We are riding this in memory of a friend who passed away from cancer this year. He rode it in 2022, and his wife will be joining us. It will be a special and emotional journey. 💫

Sticker we sell for charity

2025 was the year I rediscovered my rhythm.. I’m entering 2026 with a clear sense of direction, a sustainable approach to my work, and a heart full of gratitude.

Happy New Year! 🎆

Getting interviewed by AI to write better blog posts

Elio Struyf — Sat, 13 Dec 2025 13:04:28 GMT

A couple of weeks ago, I saw something in a Google GDE call that completely changed how I think about writing technical content. Daniela Petruzalek demoed her Speedgrapher MCP for Gemini CLI, and I’ll admit, I was immediately hooked. Not because it automated writing (it doesn’t, not really), but because it introduced a conversational layer between “I have an idea” and “here’s a 2,000-word article.”

The concept is simple: instead of staring at a blank screen trying to organize your thoughts, you let an AI agent interview you about your topic. The AI asks questions, you answer them naturally, and by the end you have a structured transcript that captures not just the facts, but the narrative arc, the pain points, and the technical details that make a blog post actually useful.

I’ve now written three blog posts using this approach. This article you’re reading right now? It started as an AI interview too. Here’s why this workflow clicked for me, and how I adapted it to work with GitHub Copilot CLI, VS Code, and Claude, not just Gemini CLI.

The problem with traditional blog writing

Normally when I write a technical article, I start with a vague sense of what might be interesting and start typing. Sometimes that works great. Other times I realize halfway through that I’ve organized the whole thing wrong, or I’ve skipped critical context that seemed obvious in my head but won’t be obvious to readers.

Don’t get me wrong, I’ve written hundreds of blog posts this way and it’s served me well. But there’s always been this gap between what I know and what ends up on the page. The writing process filters out a lot: the tangential insights, the “oh by the way” details, the thought process behind technical decisions. Those pieces often get lost because I’m focused on the structure and flow of the final article.

What makes the interview approach different

Here’s what I noticed when I first tried Daniela’s Speedgrapher: the AI interviewer doesn’t let you skip ahead. It asks open-ended questions that make you think outside your usual mental framework. When you explain something out loud (or in text) conversationally, you naturally include context you’d otherwise assume was obvious. You mention the rabbit holes you went down. You explain why you chose one approach over another.

The interview format creates a structure without forcing rigidity. The AI uses what’s called an “Open-Focused-Closed” questioning model:

Open questions explore the topic broadly: “What problem were you trying to solve?”
Focused questions drill into specifics: “Can you share the exact error message?” or “What did that code snippet look like?”
Closed questions confirm understanding: “So the fix was upgrading to version 2.1?”

This progression naturally builds a narrative arc. You’re not just dumping information—you’re telling a story with clear cause and effect.

My First Experiment: Testing Speedgrapher

After seeing Daniela’s demo, I did what any developer would do: I immediately went to the Speedgrapher repo, cloned it, built the MCP (Model Context Protocol server), and configured it for Gemini CLI.

For context: Gemini CLI supports custom slash commands, which are essentially shortcuts that trigger specific AI behaviors. Speedgrapher uses this to implement its interviewer as a slash command. When you invoke it, the AI switches into interview mode and starts asking questions.

The first test went really well. So well that I wrote three blog posts with it over the next week. The workflow felt natural: I’d have a rough idea for an article, start the interview, spend 10 minutes answering questions, and end up with a detailed transcript that captured way more nuance than my initial mental outline.

The Limitation: Platform Lock-In

Here’s the catch: Speedgrapher was built specifically for Gemini CLI’s slash command system. That’s great if you’re using Gemini CLI, but I also use GitHub Copilot CLI, VS Code with Copilot Chat, and Claude regularly. Each tool has its own way of handling AI assistants, and none of them (at the time) supported Gemini’s slash command format.

I could have just stuck with Gemini CLI for article writing. But I realized the core concept, an AI agent with a specific interviewer prompt, didn’t have to be tied to one platform. The “interview” behavior is just a carefully crafted prompt that guides the AI’s questioning style and output format. If I could package that prompt in a way each platform understood, I could use the same workflow everywhere.

Building cross-platform Ghostwriter Agents

This is where I got a bit ambitious: I decided to create agent files that would work across GitHub Copilot CLI, VS Code, and Claude from day one. No point building for one platform and porting later, I use all three tools regularly depending on context.

Here’s the elegant part: agents are nothing more than Markdown files with prompts inside them. Each tool reads these files from specific locations:

GitHub Copilot CLI: ~/.copilot/agents/ (global)
VS Code: .github/agents/ in your project
Claude: ~/.claude/agents/ (global)

The structure is simple. Here’s a simplified version of what an agent file looks like:

1
---
2
name: "ghostwriter-interviewer"
3
description: "Interviews an author to produce a technical blog post"
4
---
5

6
Act as an expert interviewer for a technical blog...
7
[Full prompt with instructions, guidelines, and behavioral rules]

That’s it. The YAML frontmatter gives the agent a name and description, and the markdown body contains the prompt that defines how the AI should behave.

The agents

Speedgrapher consists of various slash commands, but I distilled the core functionality into five agents:

The interviewer: conducts the interview and gathers raw material
The voice agent: analyzes your writing style to create a voice profile
The writer agent: expands the interview transcript into a full article
The context agent: when you need to restart, or want to continue with an existing draft interview, you can load the context with this agent
The reviewer agent: reviews and refines the draft for clarity and flow

Here’s a breakdown of the main three agents you’ll use most often:

1. The interviewer agent

Its job is to ask questions and gather raw material. The prompt instructs it to:

Ask exactly one question per turn (no overwhelming multi-part questions)
Use the Open-Focused-Closed model to progressively narrow in on details
Request actual artifacts: real code snippets, exact error messages, specific version numbers
Focus on narrative elements: pain points, breakthroughs, “aha moments”
Maintain a cozy but professional tone (think knowledgeable peer, not distant expert)

When you’re done, you tell the agent to stop, and it outputs a complete markdown transcript saved as INTERVIEW.md.

The interview with AI

2. The voice agent (optional but recommended)

The voice agent scans your existing content like blog posts, documentation, whatever you’ve written before and analyzes your writing style. It produces a detailed profile that includes:

Voice characteristics: tone, pacing, formality level, typical sentence structure
Style rules: what you do and don’t do in your writing
Lexicon: your favorite phrases, transitions, and words you avoid
Structure patterns: how you typically start and end articles, your heading style

This profile gets saved and used by the writer agent in the next step. The result? AI-generated drafts that actually sound like they came from you, not from Generic Tech Blog #47.

Running the voice agent is optional, you can skip straight to the writer, but I highly recommend doing it at least once. The quality difference is noticeable.

The voice agent

3. The writer agent

This agent takes the interview transcript and (if available) your voice profile, then expands it into a full article. But it’s not just a transcript formatter. The prompt instructs it to:

Add context and definitions for complex terms
Identify every tool, library, or technology mentioned and add proper markdown links
Explain the why behind code examples, not just the syntax
Maintain narrative flow and the article’s emotional arc
Follow “cozy web” editorial guidelines (helpful, relatable, narrative-focused)

The output is a markdown document ready for review. In my experience, the drafts are already well-structured—I mostly add screenshots, refine code examples, and adjust a few phrasing choices.

Using the Agents in practice

Each platform has a slightly different invocation method, but they all use the same underlying markdown files:

In Claude: Type @agent-ghostwriter-interviewer to start the interview. The @ symbol lets you reference agents by name.

In GitHub Copilot CLI: Launch the CLI, select /agent, then choose the ghostwriter-interviewer from the list.

In VS Code with Copilot Chat: Open the agent selector dropdown and pick the interviewer agent.

Once invoked, the experience is remarkably consistent across all three platforms. You answer questions, the AI follows up naturally, and you end with a complete transcript.

What I’ve learned after three articles

The biggest surprise isn’t the time savings, although it does feel faster, but the quality of the raw material. When an AI interviews you, it asks about things you might not have thought to include. It pushes you to articulate the “why” behind decisions. It captures those tangential insights that usually get edited out.

Something I’m still working on: making it easier to include screenshots and code samples during the interview process. Right now I add those in the review phase, after the writer agent has produced the draft. It works, but it feels like there’s room for improvement there.

The other thing I’ve noticed is that the articles feel more complete from the start. There’s less “oh, I forgot to explain this fundamental concept” during editing because the interviewer forced me to explain it during the conversation.

Try it yourself

All credit for this idea goes to Daniela Petruzalek and her Speedgrapher MCP. I just adapted the concept to work across multiple platforms.

I’ve made the ghostwriter agents available at github.com/estruyf/ghostwriter-agents-ai. Installation is straightforward, you can install for all supported platforms at once:

1
npx @estruyf/ghostwriter

Or target specific platforms:

1
# Install for specific platforms
2
npx @estruyf/ghostwriter --vscode
3
npx @estruyf/ghostwriter --copilot
4
npx @estruyf/ghostwriter --claude

The installer copies the agent files to the right locations for each tool.

What’s next

Right now I’m waiting to see how others use this workflow. Different writing styles, different content types, I’m curious whether the three-agent pipeline holds up across different use cases.

The screenshot integration is still on my mind. There’s probably a way to handle visual artifacts more elegantly during the interview phase.

If you write technical articles or blog posts, I’d encourage you to give this a try. It’s a genuinely different experience from traditional writing, not better or worse, just different. You might find, like I did, that having an AI ask you questions unlocks parts of your knowledge that wouldn’t have made it into the article otherwise.

Let me know what you think. And if you try the ghostwriter agents, I’d love to hear how it works for your writing process.

Resources

Daniela Petruzalek on Bluesky - Original creator of Speedgrapher
Speedgrapher MCP - Original interview-based writing tool for Gemini CLI
Gemini CLI - Google’s command-line interface for Gemini
Gemini CLI Custom Slash Commands - Documentation on Gemini’s slash command system
Ghostwriter Agents AI - Cross-platform agent files for GitHub Copilot, VS Code, and Claude
@estruyf/ghostwriter on npm - Installation package for ghostwriter agents

Demo Time: From passion project to a sustainable future

Elio Struyf — Tue, 09 Dec 2025 16:27:51 GMT

It started with a simple frustration: demos are meant to fail. We’ve all been there. You’re on stage, the pressure is on, and suddenly you make a typo, or you forget a step. I wanted to fix that. I wanted to create a tool that would let me script my demos/presentations so I could focus on the story, not the typing.

That’s how Demo Time was born in 2023.

Fast forward to today, and the project has grown beyond my expectations. I’ve seen it used at OpenAI DevDays, Microsoft Ignite, and GitHub Universe. With over 26,000 installs, it’s an incredible feeling to see the community embrace a tool I poured my free time into. At ESPC, there were eight sessions using Demo Time, apart from my own.

Don’t get me wrong, with this success comes a challenge. How do I keep supporting, innovating, and growing the project when the demands start to exceed the hours I have available?

In this post, I want to share the next chapter for Demo Time and my plan to build a sustainable future for the tool.

The problem: demos are meant to fail

The original idea was simple. By scripting every action, from file creation to code highlights and terminal commands. You can present without the stress. The core tool achieved this, and the adoption proved that I wasn’t the only one struggling with this.

The next chapter: building a sustainable ecosystem

The feedback has been amazing so far, but it also signals a need for more. More support, more features, and more time. To make that happen, I’m exploring several monetization avenues. This will allow me to invest back into the project while ensuring the core extension remains free and open-source forever.

{{< blockquote type="important" text="Everything that exists today will remain free and open source.

Here are some of the ideas I’m currently working on.

1. Demo Time cloud: seamless remote control

Right now, you need a local server and a tunnel service like ngrok to connect your phone or tablet when you want to use the Remote Control feature. I must admit, it can be a bit cumbersome.

The solution I’m building is a cloud-based remote control service. Think of it as a subscription service that removes the friction. You get an API key, and the remote just works. Securely and reliably, from anywhere.

2. Demo Time as a service: automated demo creation

This is a bigger idea I’m developing with Andrew Connell. We’ve noticed how much time companies invest in creating high-quality demos. What if we could shrink that time from days to hours?

Demo Time as a Service aims to do just that. The concept is simple:

You build the final version of your solution on your machine.
You create structured commits following a defined pattern.
You upload your project to our service.
The service analyzes your commits and automatically generates a polished Demo Time script.

This turns your development process into the blueprint for the demo.

3. Building partnerships through sponsorship

I’m also opening up sponsorship opportunities. The goal here is twofold. First, the financial support helps me dedicate more time to the product. Second, it’s about building an ecosystem of trusted partners.

By having companies that rely on Demo Time invest in its future, we can create a collaborative loop of feedback and feature ideas.

4. Support, consulting, themes, and templates

Finally, I’m exploring offering premium support and consulting services. Whether it’s helping teams get started with Demo Time, creating custom themes, or building tailored templates, this could be a way to provide additional value to users while generating revenue.

The vision for tomorrow

If these initiatives work out, here is what the future of Demo Time could look like:

Better support: Faster response times for your questions and issues.
New features: The resources to build the complex features you’ve been asking for.
Richer content: More tutorials and guides to help you get the most out of the tool.
A stronger team: The ability to bring on help to accelerate development.

This is a new and exciting step for Demo Time, and I’d love to build it with you. Let me know what you think. What appeals to you? What are your concerns? Join the discussion on GitHub Discussions - Demo Time Monetization: Exploring Sustainable Options.

Let’s shape the future of this product together.

My evolving relationship with AI in development

Elio Struyf — Mon, 01 Dec 2025 08:30:21 GMT

I get this question a lot: “How do you use AI in your development workflow?” At the start of this year, everyone was talking about prompt engineering. You had to be very clear in your prompts, create good prompts, be or become a prompt engineer. I don’t believe in that anymore. Well, not entirely.

Don’t get me wrong, good prompts are still valuable, but the game has changed. AI has become so much better that even when you don’t give enough context, it will do a pretty good job at creating what you want. And if it doesn’t? You iterate. You refine. You collaborate.

This is the story of how my workflow evolved from writing comments for code to treating AI as a team member.

The early days: comment-driven development

I’ve been using GitHub Copilot since the early beta version. Back then, development was straightforward: you opened a file, wrote code, and figured out how everything worked. When Copilot came along, you had to write comments to get code generated. Something like:

1
// Create a function that fetches user data from the API
2
// and returns the user's name and email

And Copilot would generate the function for you. It was like, “whoa, this is already an improvement!” But it wasn’t life-changing. Not yet.

The shift: from listening to predicting

The moment everything changed was when Copilot started doing suggestions proactively. You were writing code, and all of a sudden you got auto-completions that made sense. It wasn’t just listening to your commands anymore, it was predicting what you wanted to do next.

I still remember the moment I copied a variable, and Copilot already knew what I was going to do with it in another file. It predicted: “Before you were writing this function, so you probably want to use this variable here, and this is going to become the output.” That was a really nice improvement to the flow because it made things much easier.

The progression looked something like this:

Listening - You tell it exactly what to do (comments)
Predicting - It anticipates your next moves (smart auto-completions)
Agentic - It takes on tasks and runs with them (the current state)

The agentic mode: AI as a team member

Nowadays, AI can just do whatever you want. It can run as an agent where you prompt it, and it’s going to write code or create a whole application for you. This is the big change that happened over the last couple of months.

Instead of crafting one perfect prompt, I now approach AI collaboration like I would with a junior or medior developer on my team. Here’s how that works in practice:

Step 1: The junior developer (initial prompt)

I start with a simple, high-level prompt. For example:

Create me a dashboard with React and Tailwind CSS. The data I want to show is the session name, the description, and a link to the management page. Besides that, you also need to create a backend to fetch all the necessary data.

That’s it. No 20-minute specification. Just a clear goal.

Step 2: The medior developer (iterate and refine)

As the agent works, I watch its progress. And then I think: “It would be useful to have the session ID there, to show the speaker, to do XYZ.” So my next prompt becomes:

The backend you created, can you also add a couple of other properties to the API, like sessionId and speakerDetails, so this data can be shown on the session cards?

This approach is much quicker for me. I can quickly think about what I need, see the outcome, and refine. Instead of taking 20 minutes to fully spec it out upfront and then still having issues or ideas like “I could actually do it differently.”

Step 3: The senior developer (code review)

This is where I come in. I perform a thorough code review of what the AI delivers. This step is non-negotiable.

A couple of weeks ago, I was working with an Azure Function and Table Storage. The AI wrote me a SQL statement. I don’t have SQL in my application. I don’t even know where it came from. The AI understood the goal, retrieve the speaker and session data, but completely hallucinated the method. It was thinking about SQL databases instead of Azure Table Storage.

If I didn’t review that code and just blindly accepted it, things would have failed in my development environment. At the moment, AI still has some hallucinations, but it’s becoming better and better because it has more context around the whole application. It basically lives in your code, so it knows probably more than you do about where everything is.

Spec it out for larger projects

For simple tasks, the iterative approach works great. But for bigger applications, I believe in spec’ing it out first. This is something we’re seeing with tools like GitHub Spec Kit where you can spec out your project, take the time to think everything through, and then start working with an AI to implement features.

The idea is: once you have the specification, you hand it over to an AI agent. From that point, you evaluate the outcome. Is it good? What do we need to change? But there’s always a person who needs to come into the picture for that code review.

Why now is the best time to become a developer

I believe the time to learn how to develop is right now. All these AI tools like Copilot, Gemini, Claude, and others, they all spit out code. But if you don’t understand it and blindly accept it, you never know what’s going to production.

At the same time, it’s a really nice time to become a developer. It’s so easy to get started because you can begin without much knowledge. You can learn from prompting, creating solutions, seeing the outcome, and then start learning the tech from there. Start understanding what the AI agent is writing.

Even low-code/no-code platforms are shifting. With Power Apps on the Power Platform, their new vibe-coding offering, Vibe - Power Apps, is generating React code. You need to understand React to make sure your application is production-ready (or have confidence in the generated code).

What’s next: chained agents and workflows

Where does it go from here? We’re already in that agentic mode where you give tasks to an agent. But we’re starting to see workflows emerge: if Agent A does this and gives the outcome to Agent B, then we get a final solution.

For instance, you could give a development task to a development agent. Once it’s done, it passes over to a review agent that does a security assessment. These fully automated flows are coming (some platforms already support it), with minimal human interference.

As AI gets smarter with less context, it will become even faster at achieving what you didn’t even know you wanted to achieve. Its predictability and understanding of how things work is already a couple of steps ahead of what you’re currently doing.

My role, and I think the role of many developers, is shifting towards higher-level planning, architecture, robust code review, and our creativity. The creative problem-solving and critical thinking remain irreplaceable.

A note on context and documentation

In this fast-moving field, having access to current documentation is vital. For my agents, I use services like Context7. Their MCP server helps LLMs and AI code editors access up-to-date documentation, which significantly improves the accuracy and relevance of AI-generated code.

I will try to review this post in a couple of weeks or months, or when I see a change in my behavior using AI, to keep it updated with my evolving workflow.

Build a security agent with Copilot and GitHub Actions

Elio Struyf — Fri, 28 Nov 2025 11:36:35 GMT

In the world of software development, security reviews can often feel like a formal, sometimes stressful, ceremony. We hand our code over to specialists, wait for a report, and then scramble to fix the findings. While services like Aikido Security are invaluable in professional settings, I found myself wondering: could I bring some of that power to my personal projects in a more lightweight, “cozy” way? What if I could build my own automated security specialist, an AI agent that knows my code and helps me improve it?

This is the story of how a single talk at a Xebia event by Côme Redon sparked an idea. I decided to build a custom security agent for my project, “EngageTime,” using tools I already had: GitHub Copilot and GitHub Actions. It turned out to be a good journey that I wanted to share.

In this article, I’ll walk you through the entire process, from creating the agent to analysing its findings and even having it file its own bug reports. And yes, I’ll be sharing the complete configuration so you can build your own.

Crafting the brain: the security agent definition

The first step is to create the agent’s definition. In the world of GitHub Copilot, this is done through a simple Markdown file. This file acts as a prompt, a set of instructions that defines the agent’s name, purpose, and rules of engagement.

My goal was to create an agent that could perform a comprehensive security analysis without modifying the code directly. I drew inspiration from the concepts I saw at the event and incorporated terms and capabilities I was familiar with from my experience with professional security tools.

Here’s the agent definition file, located at .github/agents/security-agent.md:

1
---
2
name: SecurityAgent
3
description: Security Agent - Analyzes TypeScript and React code for security vulnerabilities and creates security reports
4
model: GPT-5.1 (Preview)
5
---
6

7
## Purpose
8

9
This agent performs comprehensive security analysis of the Astro, TypeScript code. It identifies security vulnerabilities, assesses risks, and produces detailed security reports without modifying the codebase directly.
10

11
## Security Scanning Capabilities
12

13
This agent can perform comprehensive security analysis across the full stack:
14

15
### Code Analysis
16

17
- **SAST (Static Code Analysis)** - Scans TypeScript/React source code for security vulnerabilities
18
- Identify security vulnerabilities including:
19
  - SQL Injection risks
20
  - Cross-Site Scripting (XSS) vulnerabilities
21
  - Cross-Site Request Forgery (CSRF) issues
22
  - Authentication and authorization flaws
23
  - Insecure cryptographic implementations
24
  - Hardcoded secrets or credentials
25
  - Path traversal vulnerabilities
26
  - Insecure deserialization
27
  - Insufficient input validation
28
  - Information disclosure risks
29
  - Missing security headers
30
  - Dependency vulnerabilities
31
  - Input validation analysis - review all user input handling
32
  - Data Encryption - check encryption at rest and in transit
33
  - Error Handling - ensure errors don't leak sensitive information
34

35
### Dependency & Component Analysis
36

37
- **SCA (Software Composition Analysis)** - Monitors npm dependencies for known vulnerabilities & CVEs
38
- **License Scanning** - Identifies licensing risks in open source components
39
- **Outdated Software Detection** - Flags unmaintained frameworks and end-of-life runtimes
40
- **Malware Detection** - Checks for malicious packages in supply chain
41

42
### Infrastructure & Configuration
43

44
- **Secrets Detection** - Finds hardcoded API keys, passwords, certificates
45
- **Cloud Configuration Review** - Azure Functions and services security posture
46
- **IaC Scanning** - Analyzes Terraform/CloudFormation/Kubernetes configurations
47
- **Container Image Scanning** - Scans Azure container images for vulnerabilities
48

49
### API & Runtime Security
50

51
- **API Security** - Reviews endpoint security and access controls
52
- **Database Security** - Checks for secure queries and connection practices
53
- **WebSocket Security** - Validates secure WebSocket implementations
54
- **File Upload Security** - Reviews secure file handling practices
55

56
### Compliance & Best Practices
57

58
- OWASP Top 10: Check against latest OWASP security risks
59
- TypeScript/React Security Guidelines: Verify adherence to Node.js and React security best practices
60
- Secure coding standards: Validate code follows industry standards
61
- Dependency scanning: Check for known vulnerabilities in npm dependencies
62
- Security headers: Verify proper HTTP security headers
63
- Data privacy: Review GDPR/privacy compliance considerations
64

65
### Security Metrics & Reporting
66

67
- **Vulnerability Count by Severity** - Critical, High, Medium, Low categorization
68
- **Code Coverage Analysis** - Security-critical code coverage metrics
69
- **OWASP Top 10 Mapping** - Maps findings to current OWASP risks
70
- **CWE Classification** - Uses Common Weakness Enumeration for standardization
71
- **Risk Score** - Overall security posture assessment
72
- **Remediation Timeline** - Priority-based fix recommendations
73

74
## Report Structure
75

76
### Security Assessment Report
77

78
1. Executive Summary
79
  - Overall security posture
80
  - Critical findings count
81
  - Risk level assessment
82

83
2. Vulnerability Findings
84
  For each vulnerability:
85
  - Severity: Critical/High/Medium/Low
86
  - Category: (e.g., Injection, Authentication, etc.)
87
  - Location: File and line number
88
  - Description: What the issue is
89
  - Impact: Potential consequences
90
  - Recommendation: How to fix it
91
  - References: OWASP/CWE/Microsoft docs
92

93
3. Security Best Practices Review
94
  - Areas following best practices
95
  - Areas needing improvement
96
  - Configuration recommendations
97

98
4. Dependency Analysis
99
  - Vulnerable packages identified
100
  - Recommended updates
101

102
5. Action Items
103
  - Prioritized list of fixes needed
104
  - Quick wins vs. complex remediation
105

106
6. Critical Vulnerability Warning
107
  - If any CRITICAL severity vulnerabilities are found, include exactly this message at the end of the report:
108
  ````
109
  THIS ASSESSMENT CONTAINS A CRITICAL VULNERABILITY
110
  ````
111
  - Do not adapt or change this message in any way.

This file is the agent’s “brain.” By defining its capabilities and boundaries clearly, I’m setting the stage for a focused and useful analysis.

Wiring it up: the GitHub Actions workflow

With the agent defined, it was time to bring it to life with a GitHub Actions workflow. The goal was to create a process that would:

Check out the code.
Install the GitHub Copilot CLI.
Feed the agent definition and the codebase to the CLI.
Capture the report and make it available.
Most importantly, fail the workflow if any critical issues were found.

After some tinkering, particularly around getting the right authentication token, I landed on this workflow file at .github/workflows/security-agent.yml:

1
name: Security Agent Workflow
2

3
on:
4
  workflow_dispatch:
5

6
jobs:
7
  security-assessment:
8
    runs-on: ubuntu-latest
9
    timeout-minutes: 15
10
    permissions:
11
      contents: read
12
    steps:
13
      - name: Checkout repository
14
        uses: actions/checkout@v4
15

16
      - name: Setup Node.js
17
        uses: actions/setup-node@v4
18
        with:
19
          node-version: 22
20

21
      - name: Install GitHub Copilot CLI
22
        run: npm i -g @github/copilot
23

24
      - name: Run Security Agent via Copilot CLI
25
        env:
26
          COPILOT_GITHUB_TOKEN: ${{ secrets.COPILOT_GITHUB_TOKEN }}
27
          GITHUB_REPOSITORY: ${{ github.repository }}
28
        run: |
29
          set -euo pipefail
30
          AGENT_PROMPT=$(cat .github/agents/security-agent.md)
31
          PROMPT="$AGENT_PROMPT"
32
          PROMPT+=$'\n\nContext:\n'
33
          PROMPT+="- Repository: $GITHUB_REPOSITORY"
34
          PROMPT+=$'\n\nTask:\n'
35
          PROMPT+=$"\n- Execute the instructions on the full codebase"
36
          PROMPT+=$'\n- Generate the security report at /security-reports/security-assessment-report.md summarizing findings, severity, and remediation guidance.'
37

38
          copilot --prompt "$PROMPT" --allow-all-tools --allow-all-paths < /dev/null
39

40
      - name: Output security report as summary
41
        if: always()
42
        run: |
43
          set -euo pipefail
44
          REPORT_PATH="security-reports/security-assessment-report.md"
45

46
          if [ ! -f "$REPORT_PATH" ]; then
47
            echo "No security report generated; skipping summary."
48
            exit 0
49
          fi
50

51
          echo "## Security Assessment Report" >> $GITHUB_STEP_SUMMARY
52
          cat "$REPORT_PATH" >> $GITHUB_STEP_SUMMARY
53

54
      - name: Upload security report artifact
55
        if: always()
56
        uses: actions/upload-artifact@v4
57
        with:
58
          name: security-assessment-report-${{ github.run_id }}
59
          path: security-reports/security-assessment-report.md
60
          retention-days: 30
61

62
      - name: Check for critical vulnerabilities
63
        if: always()
64
        run: |
65
          set -euo pipefail
66
          REPORT_PATH="security-reports/security-assessment-report.md"
67

68
          if [ ! -f "$REPORT_PATH" ]; then
69
            echo "No security report generated; skipping critical check."
70
            exit 0
71
          fi
72

73
          if grep -q "THIS ASSESSMENT CONTAINS A CRITICAL VULNERABILITY" "$REPORT_PATH"; then
74
            echo "❌ CRITICAL VULNERABILITY DETECTED - Workflow failed"
75
            echo "The security assessment found critical vulnerabilities that must be addressed before proceeding."
76
            exit 1
77
          else
78
            echo "✅ No critical vulnerabilities detected"
79
          fi

Use the Copilot Requests read-only permission for the fine-grained personal access token.

Deconstructing the workflow

on: workflow_dispatch: I started with a manual trigger. This is perfect for development, as it lets me run the agent on demand without committing new code every time. You can change this to run on each pull request or on a schedule as needed.
npm i -g @github/copilot-cli: This installs the official GitHub Copilot CLI, the tool that allows us to interact with Copilot agents from the command line.
The Security Gate: An important step is Check for critical vulnerabilities. I had engineered a specific string, THIS ASSESSMENT CONTAINS A CRITICAL VULNERABILITY, into my agent’s instructions. This step uses the simple but powerful grep command to search the report for that exact string. If it’s found, the workflow exits with an error code, effectively acting as a security gate that prevents merging code with critical issues.

The moment of truth: the first report

With everything wired up, I manually triggered the workflow. The first report it generated was astounding. It wasn’t just a list of potential issues; it was a detailed security assessment.

It found 3 critical vulnerabilities, along with a host of high and medium-risk findings. Here are two of the most impactful ones:

Critical finding 1: inadequate input sanitisation

The agent identified a custom sanitizeInput function that was vulnerable to Cross-Site Scripting (XSS).

The Vulnerable Code:

1
export const sanitizeInput = (input: string): string => {
2
  return input.replace(/<script.*?>.*?<\/script>/gi, "").trim();
3
};

The Agent’s Analysis: The agent correctly pointed out that this regex could be easily bypassed with event handlers (<img src=x onerror="alert(1)">), different tags, or encoded payloads.

The Recommended Fix: It suggested replacing this homegrown function with DOMPurify, a battle-tested sanitisation library.

1
import DOMPurify from 'isomorphic-dompurify';
2

3
export const sanitizeInput = (input: string): string => {
4
  return DOMPurify.sanitize(input).trim();
5
};

Critical finding 2: Cross-Site Scripting (XSS) via innerHTML Assignment

Another issue was the direct assignment of user-generated content to innerHTML, which is a classic XSS vector.

The Vulnerable Code:
```
1
container.innerHTML = `
2
  ...
3
`;
```
The Agent’s Analysis: The agent highlighted that this practice could allow malicious scripts to execute if the content isn’t properly sanitized.

The Recommended Fix: It recommended using safer DOM manipulation methods, such as creating elements and setting text content:

1
const fallbackDiv = document.createElement('div');
2
fallbackDiv.className = '...';
3
fallbackDiv.textContent = '...';
4
target.replaceWith(fallbackDiv);

From report to action: automating the workflow

Now I had a detailed report, but I still needed to act on it. Manually creating a issue for each of the findings felt like a chore. So, I turned to my AI partner again.

I gave GitHub Copilot a simple prompt: “Can you create issues on GitHub for the issues that you found in the security report of today?”

Using the GitHub CLI, Copilot iterated through the report and created a new, detailed issue for each finding directly in my repository, turning a static document into a dynamic backlog of actionable tasks.

Conclusion

This journey is great to see how modern AI tools can augment our workflows. By combining a well-defined agent, a pragmatic GitHub Actions workflow, and a little bit of CLI magic, I created a robust, automated security review process for my personal project.

The agent found real, critical issues, provided high-quality remediation advice, and I was even able to automate the process of turning its findings into trackable work. For some of the issues, the agent’s code was a direct, copy-paste solution.

I encourage you to take these configurations and adapt them for your own projects. Happy building!