Elio Struyf

Why GitHub Copilot CLI is my new go-to for heavy lifting

Elio Struyf — Fri, 20 Mar 2026 12:26:13 GMT

As developers, we are always trying to find the most efficient way to build ship, and debug our code. Recently, I’ve been doing a lot of work in a gigantic monorepo for a customer—think 75+ sub-projects bundled into one repository. With such a massive codebase, I found myself hitting performance issues when using the GitHub Copilot Chat extension in Visual Studio Code. One of the main reasons is that Visual Studio Code extensions share the same resources, so when you are making a lot of changes and the Git integration is busy processing them, it ends up competing for the same resources Copilot Chat needs as well. If you want to do some manual changes at the same time, and require formatting updates on save, it can lead to a very laggy experience.

Due to these performance issues, I decided to start exploring the GitHub Copilot CLI, which runs in a completely separate process and doesn’t rely on Visual Studio Code’s resources. In this post, I’ll share my experience with the Copilot CLI and how it has become my new go-to for heavy lifting in large codebases.

The challenge with gigantic monorepos

When you ask Copilot Chat to execute complex, multi-file changes in a massive monorepo, it uses your Visual Studio Code instance’s resources. In my experience with this specific customer project, asking for a substantial change would cause my Visual Studio Code instance to freeze and stop responding.

It takes ages before changes are applied, and you are left staring at a lagging editor. One workaround I found was to disable the Git integration in Visual Studio Code, but that is hardly a sustainable solution as that breaks the GitHub Copilot Chat’s ability to implemnent changes.

I needed a way to leverage the power of Copilot’s agents without sacrificing my IDE’s performance.

The workflow shift: running outside the IDE

The biggest advantage of the Copilot CLI is that it runs on a completely different instance and thread. It doesn’t use Visual Studio Code’s resources to do the heavy lifting.

Initially, I hesitated to move to the CLI because I didn’t want to lose the context-awareness of the Chat interface. I loved being able to point to a specific file or code block. However, the CLI now features a brilliant integration with Visual Studio Code. If you have a Visual Studio Code instance open, the CLI can automatically connect to it and leverage the same context-awareness as the Chat extension.

Here is how my workflow looks in practice:

I open my project in Visual Studio Code.
I open Ghostty (my terminal of choice) in a separate window.
I run the copilot command.
The CLI automatically connects to my active Visual Studio Code instance, and I can start prompting.

GitHub Copilot CLI connected to VS Code

Bridging the gap: context in the CLI

You might be wondering: “If you are in a separate terminal, how do you pass context to the AI?”

The CLI-to-VSCode integration handles this beautifully. Once your CLI session is connected to your editor, you have two great options:

You can naturally use @ mentions in the CLI prompt to reference specific files.
You can right-click directly in your Visual Studio Code editor and select Add file/selection to Copilot CLI from the context menu.

You get the performance of a standalone CLI process with the exact same UX conveniences of the Chat extension.

Why the CLI is a game-changer for autonomous tasks

Besides the massive performance boost, the CLI has fundamentally changed how I approach larger tasks.

Zero GUI friction

With the Chat interface, you are constantly managing the GUI. You have to click “Keep” or “Undo” for every projected change. The CLI excels at autonomous task completion. It just does the work. You don’t suffer from GUI overhead; you simply review the resulting changes in your Git diffs later, which is how we naturally review code anyway.

Running parallel tasks with fleet

This is perhaps the coolest feature of the CLI. In Copilot Chat, if you want multiple things done simultaneously, you have to open multiple chat sessions and prompt each one individually.

The Copilot CLI introduces the /fleet command, which allows you to pass a single prompt that the CLI splits into multiple actions, working on them in parallel.

For example, I can run:

1
/fleet check all my projects to update the labels to the new flat structure

The CLI orchestrates the tasks concurrently, saving an immense amount of time. You can read more about this in the official Copilot CLI fleet documentation.

Parallel tasks for GitHub Copilot CLI

When I still use Copilot Chat

I haven’t abandoned Chat entirely. It still has its place.

If I simply need to implement a quick single-file utility function, or if I need the AI to quickly explain a block of code I’m looking at, the inline Chat is still my go-to. It is perfect for small tasks, but for everything else like heavy agent usage, repo-wide refactors, or anytime I’m working in my massive monorepos, the CLI is the only way to go.

Let me know what you think when you try it out!

Resources

Switching from Apple Watch Ultra to Garmin Venu 4

Elio Struyf — Thu, 19 Mar 2026 15:09:06 GMT

As a developer and avid cyclist, I am always curious about how data can improve my day-to-day life and training. For the longest time, my setup was pretty standard: a Garmin Edge on the bike for my workouts and an Apple Watch Ultra on my wrist for everything else.

But there was a problem: the “data black hole.”

Because I use Join alongside Garmin to manage my training schedule, I ran into a major wall. Garmin doesn’t pull metrics like sleep or recovery from Apple Health. My Edge knew exactly how much power I was putting down during a ride, but it knew absolutely nothing about my recovery, sleep, or overall fatigue. Without that 24/7 context, my Training Readiness score couldn’t be calculated properly, and the workouts Join suggested weren’t adapting to my actual physical state.

That made me decide to change my hardware. This is the story of how and why I switched to the Garmin Venu 4.

The choice: why the Venu 4?

A couple of my cycling friends have Garmin watches and raved about their experience. I knew I needed a Garmin wearable to feed that sweet off-bike data into my ecosystem, but I didn’t want a hardcore running watch like a Forerunner or Fenix. The Garmin Edge handles all my cycling navigation and tracking, I just needed a lifestyle watch that tracks health metrics accurately.

I went with the Garmin Venu 4. It looks great, features a round face (which is more my style), and comes with a reasonable price tag.

The first few weeks: patience is required

I must admit, the first day wasn’t perfect. Setting up the Venu 4 required four separate software updates back-to-back. Why not just package them into one? It’s a small quirk, but the onboarding experience could have been smoother.

More importantly, you can’t just strap on a Garmin and expect instant, life-changing insights. Features like Training Readiness, HRV Status, and overall Health Status require about two to three weeks of continuous wear to establish a baseline. Before that, your training status might just stubbornly say “Unproductive.” Pulse Ox data and broader health trends also take time to appear.

The medication curveball

Just as I got past that initial baseline period, I had an unexpected physiological shift. I recently stopped taking beta-blockers, which naturally keep your heart rate lower. My resting heart rate increased by about 10-15 beats per minute, and my peak output changed as well.

The Garmin immediately noticed. Suddenly, my HRV was flagged as “off,” my training status was red, and the watch assumed I was constantly fatigued. It was fascinating to see the algorithms react to my biology, but it meant I had to start that 2-3 week calibration clock all over again.

By around week four, the Health Status view finally started showing meaningful trends for resting heart rate, HRV, respiration, skin temperature, and pulse oximeter. That was the point where the platform started to feel genuinely useful instead of just “collecting numbers.”

Smartwatch features and the Apple ecosystem hangover

Don’t get me wrong, the Apple Watch Ultra is a vastly superior smartwatch. There are definitely things I miss:

Ecosystem integration: I used to walk up to my Mac, and it would seamlessly unlock. Now, I use the fingerprint scanner on my keyboard. It works, and it’s only a second slower, but it’s a slight friction point.
Notification handling: Apple clears notifications across all devices once read. Garmin still struggles a bit with this unified approach (limitation by Apple).
Screen real estate: Because the Venu 4 is round and has a relatively fat bezel, you lose a lot of corner space. When reading long messages, you have to scroll the text right into the middle horizontal strip of the screen to read it properly.

I’ve also experienced a couple of random freezes where a notification would come in, or I’d start an activity, and the screen would just go black and reboot. It’s not a dealbreaker, but the interface is noticeably less responsive than Apple’s.

Battery life changes behavior

This is where the Venu 4 shines. The battery life actually changes how you interact with the device.

With the Apple Watch, I had a strict daily charging ritual. I rarely wore it to bed because I didn’t want to deal with a dead battery the next day, plus I liked keeping electronics out of the bedroom.

With the Venu 4’s AMOLED display set to “Always On,” I still get a solid week of battery life. In one cycle, it dropped to 58% after about four days and was down to 18% after roughly a week, which lined up with Garmin’s estimate.

When I turned Always On off to test it, I had 69% battery left after four days, with the watch predicting another eight days of life.

Because I don’t have to babysit the battery, I sometimes forget I’m even wearing it. I now sleep with it on every single night, which allows me to finally capture that crucial sleep and recovery data. My charging ritual is now just throwing it on the charger once a week while taking a shower after a hard workout.

Nice to have

The built-in flashlight is a genuinely handy extra. I already used it once when I needed quick light and my phone was not nearby. I probably will not use it every day, but it is a nice-to-have feature when you don’t have your phone on you.

The verdict for cyclists

If you are a cyclist who uses an Edge unit for the real work but relies on an Apple Watch for daily wear, you are missing half the picture.

The Apple Watch is a brilliant smart assistant, but the Garmin Venu 4 acts as an actual training partner. It bridges the gap between rides, taking the guesswork out of recovery. Once you survive the initial setup and the baseline calibration, having your holistic health data dictate your training readiness is a massive upgrade.

For my use case, it is the right middle ground: great for cyclists who already rely on an Edge and want better off-bike data, without paying for running-first features from the Forerunner/Fenix line.

Let me know what you think, or if you’ve made a similar jump!

Control Your Mac with a 3-Button Voice Setup

Elio Struyf — Wed, 11 Mar 2026 12:00:00 GMT

A while back, I wrote a post called Stop typing, start talking: How voice dictation changed my workflow, where I shared how I was shifting my workflow to use my voice more and more. At the time, I was still relying heavily on my main keyboard to trigger these voice commands. It was an improvement, certainly, but it wasn’t perfect. I still had to wrangle my fingers into odd positions to hit complex shortcut combinations.

As a developer, I’m always curious about optimizing my physical workspace. I wanted a way to trigger my voice tools without thinking, and without looking down. So, I decided to buy a 3-button keyboard (actually 4, but I only use three).

In this post, I will share how I use a tiny, three-button keyboard to control my entire machine with my voice.

The hardware: three buttons to rule them all

Nowadays, I use a new programmable keyboard with just three buttons (well, technically four, but I only need three to use it). It is the SinLoon Mini Programmable Mechanical Keyboard.

My 3-button SinLoon macro keyboard setup

The goal is simple: instead of hitting Ctrl+Alt+Shift+Something, I just press a single chunky button.

I must admit, the setup for the hardware has one slight catch. The SinLoon keyboard uses a custom app that you have to download via a Google Drive link. That sounds a bit shady, but it is totally fine. The real downside is that the configuration app only works on Windows, while I do all my development work on macOS.

To map the keys, I plugged the keyboard into a Windows machine, opened the app, and set the shortcuts by clicking the virtual keys in the UI window. Once you send the keybindings to the macro board, they are saved directly on the device. When I plug it back into my Mac, it works flawlessly.

The software: translating buttons to actions

I configured the three buttons to trigger the specific tools that power my voice-first workflow:

Button 1: Triggers Handy, my go-to tool for transcribing voice to text anywhere. It sends Ctrl+Alt+Shift+R.
Button 2: Triggers VoiceSnippets, a custom app I built for running commands and text expansion based on spoken trigger words. It sends Ctrl+Alt+Shift+S.
Button 3: Acts as my Enter key.

VoiceSnippets app to controls your computer with trigger words

VoiceSnippets in action

The real magic happens when you pair a single button press with automation. VoiceSnippets listens for specific trigger phrases and executes pre-defined actions.

Here is how that works in practice. When I want to spin up a project in Visual Studio Code, I press Button 2 and say “Start development”.

VoiceSnippets interprets that and runs the following configuration:

1
{
2
  "id": "492188f5-4ddd-4f12-ba02-37b1a72eaa36",
3
  "trigger_word": "start development",
4
  "expansion": "<delay Cmd+Shift+Pms> → Focus terminal view → <Enter> → <delay 1000ms> → npm run dev → <Enter>",
5
  "command_type": "Workflow",
6
  "category": null,
7
  "aliases": [],
8
  "workflow_steps": [
9
    { "step_type": "shortcut", "value": "Cmd+Shift+P" },
10
    { "step_type": "text", "value": "Focus terminal view" },
11
    { "step_type": "key", "value": "Enter" },
12
    { "step_type": "delay", "value": "1000" },
13
    { "step_type": "text", "value": "npm run dev" },
14
    { "step_type": "key", "value": "Enter" }
15
  ],
16
  "app_filters": [
17
    { "id": "com.microsoft.VSCode", "name": "Code" }
18
  ]
19
}

VoiceSnippet: Start development command configuration

This sequence opens the VS Code command palette, focuses the terminal view, waits a second to ensure the terminal is ready, and then types and runs npm run dev.

I also use text expansion with variables. For example, checking out a git branch:

1
{
2
  "id": "474bf19d-938f-4893-bfe2-390990bd7c17",
3
  "trigger_word": "branch {name}",
4
  "expansion": "git checkout {name}",
5
  "command_type": "TextExpansion",
6
  "category": null,
7
  "aliases": [],
8
  "workflow_steps": null,
9
  "app_filters": []
10
}

VoiceSnippet: branch command

If I say “branch dev”, VoiceSnippets automatically expands it to git checkout dev.

A real-world workflow

When I am answering questions or being interviewed by an AI tool like Ghostwriter, the seamless nature of this setup really shines. Here is the exact loop:

I hold down Button 1 (Handy).
I speak my answer out loud.
I release Button 1.
I tap Button 3 (Enter).

Handy transcribes the text directly into the prompt box, and the Enter button submits it. I can do this process over and over while leaning back in my chair. I do not have to touch my mouse or look down at a full keyboard. I just press the button and talk.

The takeaway

It is remarkably faster to have dedicated physical inputs for voice triggers. Once muscle memory sets in, you never have to look down—you just know the button is exactly where it needs to be, and it will work every single time.

If you spend a lot of time writing, prompting, or executing repetitive terminal commands, I highly recommend exploring a voice-driven approach. Start using your voice today!

Let me know what you think.

Resources

VoiceSnippets - My custom app for macOS voice automation.
Handy - The AI transcription tool I use for dictation.
SinLoon Mini Programmable Mechanical Keyboard - The hardware powering the 3-button setup.

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