Forem: Michelle Duke

Is voice the natural progression of artificial intelligence?

Michelle Duke — Fri, 23 Jan 2026 00:43:14 +0000

As humans, we learn to talk before we learn to read, write, or type. Voice is our most natural form of communication, yet in programming, we have long communicated with rigid computer languages, and even typing queries into our search engines. With AI rapidly reshaping how we build and use tools, voice is emerging as the next evolution for human–machine interaction.

But this shift isn’t just about convenience. It’s about aligning technology with how humans already think, learn, and communicate.

Voice is our first interface

Human language development follows a fairly consistent pattern. Long before we can read or write, we learn to communicate with sound:

4-6 months: babies start babbling
10-12 months: first words appear
2-3 years old: children are forming simple sentences
5-6 years: vocabulary explodes. This is where kids can tell stories, combine ideas, and hold increasingly complex conversations.

Reading and writing come later, often not fully fluent until eight to ten years old.

Everyone develops differently, and there are cultural variations, but the pattern is clear: speech comes first.

Even as adults, voice remains our primary communication method. It’s immediate. It’s expressive. It carries emotion, intent, tone, and context. There’s very little friction compared to typing, reading, or navigating interfaces.

Voice isn’t a feature we grow out of; it’s the interface we default to.

Computers learned the opposite way

Now let’s contrast that with how computers evolved. Early machines didn’t meet humans where we were, instead we adapted to machines:

Late 1800s: punch cards were introduced for data processing, most famously for the US Census. They remained in use for decades. Interaction was physical, slow, and unforgiving.
1960s: command-line interfaces emerged. They were powerful, but only if you knew the exact syntax. One wrong character, and the machine simply refused to cooperate. There was zero tolerance for mistakes.
1970s: introduction of graphical user interfaces (GUI). Desktops, folders, icons, windows, and the mouse made computing more visual and approachable. This was a huge step forward, but interaction was still abstract: clicking representations of objects, not interacting naturally.
1990s: touchscreen mobile devices. With pinch-to-zoom, swipes, and taps, interfaces became more physical and intuitive. Users could interact directly with content instead of through layers of abstraction.

Voice, however, lagged behind.

Early speech recognition systems existed as far back as the 1990s, but they were slow, brittle, and impractical. It wasn’t until mobile computing took off—with assistants like Siri—that voice became usable at scale.

Computers started with structure, precision, and strict rules. Humans started with sound, experimentation, and ambiguity. We built machines backwards compared to how we learned ourselves.

And interestingly, we did the same thing with AI.

Generative AI repeated the pattern

Artificial intelligence as a concept dates back to the 1950s, when Alan Turing posed the question: Can machines really think? Early AI systems were symbolic, rule-based, and highly constrained.

Fast forward through decades of research—first with neural networks in the 1980s and 1990s, and then deep learning in the early 2000s—and we eventually arrive at modern generative AI.

The release of large language models like GPT-3 marked a turning point. For the first time, machines could generate language that felt flexible, contextual, and human-like. Importantly, interaction shifted from strict commands to natural language prompts.

But once again, we started with text.

We typed prompts into boxes. We refined instructions. We engineered prompts the same way we used to engineer command-line inputs, just with more forgiveness.

Voice came later.

It's only been in the last few years that we've seen serious movement toward real-time speech-to-text, text-to-speech, and conversational systems that feel fluid rather than transactional.

That delay wasn’t accidental.

Why voice is hard (and always has been)

Voice feels natural to humans, but it’s one of the hardest interfaces to build well.

Unlike text, speech is messy. People interrupt themselves. They change their mind mid-sentence. They use filler words, sarcasm, emotion, accents, and background noise. Timing matters. Silence matters. Tone matters.

From a technical perspective, voice systems require multiple complex components working together in real time:

Accurate speech recognition across different environments and accents
Low-latency processing so responses don’t feel delayed
Natural-sounding text-to-speech that doesn’t break immersion
Conversation state management so context isn’t lost
Error handling for interruptions, corrections, and ambiguity

And users are far less forgiving with voice than with text. A slow or robotic response breaks trust immediately. A misunderstood request feels personal. When voice fails, it fails loudly.

This is why early voice assistants felt limited and scripted. They were command-driven, not conversational.

What’s changed now is large language models finally give voice systems something they were missing: reasoning, context, and flexibility.

The third generation of conversational AI

We’re now entering what’s often called the third generation of voice AI.

The first generation was assistants like Siri. Yes, Siri was impressive, but narrow. The second generation, defined by systems like Alexa, focused on skills and integrations, but still struggled with real conversation.

The next wave is different.

Modern voice AI systems aim to:

Handle interruptions naturally
Maintain context across topics and time
Resume conversations after breaks
Share information across systems
Understand intent, not just commands and specific words
Sound natural and emotionally appropriate

These systems aren’t just answering questions. They’re helping users achieve their goals.

This is where voice stops being a novelty and starts becoming an interface paradigm.

Why voice is the next frontier

Voice is powerful because it’s hands-free and eyes-free. It’s fast. It’s expressive. It reduces cognitive load. There’s no backspacing, no form fields, no menus to learn.

It’s also inherently more accessible. Voice lowers barriers for users who can’t easily type, read, or navigate traditional interfaces. It works in real-time situations where screens simply aren’t practical. Think a parent holding a child, a person who is injured or limited mobility, or even those trying to multitask.

But more than that, voice changes how we design software.

When users talk to systems the way they talk to each other, the line between human and machine starts to blur. That brings ethical questions. Those conversations definitely matter, but this technological breakthrough also opens up enormous opportunity.

Just look at what's becoming possible with the new Razer AI voice systems:

Michelle Duke

Jan 19

Razer AIKit: Open-Source, Local-First AI Workflows for Developers

#news #ai #opensource

Comments

2 min read

For the first time, we’ve built systems that adapt to humans, instead of forcing humans to adapt to systems.

So what do we build now?

Voice AI feels like a return to something fundamental. After decades of abstraction layers, command syntax, and graphical metaphors, we’re finally interacting with computers in the same way we interact with each other.

AI is going to talk back to us.

The real question for developers isn’t whether voice is coming; instead, the question is: what we’re going to build to make it useful, meaningful, and worth the effort?

Because the interface is finally human. Now the responsibility is ours.

Razer AIKit: Open-Source, Local-First AI Workflows for Developers

Michelle Duke — Mon, 19 Jan 2026 06:06:07 +0000

If you saw Razer's announcements at CES, you might have seen Razer's Project Ava: an AI companion for your desk:

Well, Razer isn’t just building AI companions and game-centric assistants, it’s also putting serious tools into the hands of developers who want to build, train, and fine-tune AI models without being locked into the cloud.

Last year I wrote about the new Razer AI Game Copilot that can help you build games better. Now Razer is taking it one step further.

Michelle Duke

Apr 3 '25

Game developers: use AI to build your game with Razer AI Game Copilot

#news #gamedev

Comments

2 min read

A developer toolkit, not just another SDK.

At its core, Razer AIKit is an open-source AI development platform designed to streamline the entire AI lifecycle. Instead of wrestling with cloud setup, fragmented tooling, and manual GPU configuration, developers can launch and optimise large language models (LLMs) locally — with performance comparable to cloud instances.

Key strengths include:

Automatic GPU discovery and cluster formation: AIKit detects compatible GPUs on a system and orchestrates them as an efficient cluster, removing a lot of the manual plumbing that typically slows down local AI workflows.
Low-latency, local-first model tuning and inference: With everything running on-premise, latency drops and developers get full control over data and performance.
Open-source on GitHub: The entire platform is available for developers to inspect, extend, and improve. This is a big plus for anyone building specialised AI tools or research workflows.

This isn’t tied exclusively to Razer hardware. Razer AIKit runs on any system with a compatible GPU. Saying that, it plays especially well with Razer’s expanding AI ecosystem, including workstations and accelerators.

What does this mean for us developers?

For game developers, software engineers, and AI researchers alike, Razer AIKit fills a gap between heavyweight cloud services and lightweight local experiments. Instead of juggling disparate tools, AIKit offers a single, scalable platform that supports both training and inference. At the same time, code and models are kept close to home, without cloud fees or data egress time.

It’s a logical next step from Razer’s earlier announcements (like the AI Game Copilot you wrote about), signalling that the company wants to support both creators and the tools they use, not just deploy finished AI experiences.

How to customise the way GitHub Copilot responds

Michelle Duke — Thu, 04 Dec 2025 02:34:18 +0000

Have you been prompting GitHub Copilot a lot? Sometimes you might write the same or similar prompts over and over again. It can be super annoying to tell GitHub Copilot how to interpret and react to a prompt every single time we write in the chat. That's where custom instructions come in handy and can really help supercharge your workflow.

Sometimes there are organisation-, company-, or project-specific policies and guidelines that you need to adhere to. For example, you might have set frameworks and tools you use. Your project or community might specify a certain method for naming functions, or guidelines for writing comments. Rather than tell these instructions to Copilot every time, we can save this type of information to make our development even smoother.

There are two main ways we can customise the way GitHub Copilot responds to prompts. These are:

Custom instructions
Prompt files

Custom instructions

These are instructions help to guide GitHub Copilot on the way we want GitHub Copilot to behave. Instructions can be given and used in various ways. At the time of writing, these are the custom instructions available:

Personal custom instructions.
Repository-wide custom instructions: these will be read by the whole repo.
Path-specific custom instructions: these will be read by a specific file only.
Organization custom instructions: used at the Organization level and set by Org Owners with a Copilot Enterprise subscription.
Agent instructions: used by AI Agents.

Personal custom instructions

This is a way to interact with GitHub Copilot on the web, and provide a way for GitHub Copilot to interpret the prompt we are writing in the chat.

Let's try out personal custom instructions:

Open GitHub Copilot on the web.
Enter a prompt to convert numbers into Roman numerals. Something like: Create a JavaScript function that converts numbers into Roman numerals.
See the output.

Now let's add a custom instruction to change how Copilot interprets the prompt:

Access your GitHub Copilot settings by going to your Profile → Personal instructions.
In the pop-up, enter some instructions, such as:

Always do the following when writing functions:
- Add descriptive comments
- Add input validation
- Use returns early to account for error conditions
- Use meaningful variable names
- Include at least one example usage in comments

Re-enter the same prompt and analyse the differences.

Repository-wide custom instructions

Creating instructions at the repository level is useful for telling GitHub Copilot how to act for a certain project. If you are using specific frameworks, coding languages, or comments, it ensures everyone is on the same page and Copilot can always perform the same for everyone.

For repo-specific instructions, we need to create a copilot-instructions.md file in the .github directory. There are two ways we can achieve this:

Writing our own from scratch.
Getting GitHub Copilot to write them for us.

Custom repo instructions should also already be set to on by default:

Let's write our own custom instructions:

In your editor, open your repo.
Create a new copilot-instructions.md in the .github directory.
Write instructions in natural language using markdown, including something like:

# Project Overview

This project [describe your project]

## Folder Structure

[list the folder structure]

## Libraries and Frameworks

[list any libraries it uses]

## Coding Standards

[list your coding standards]

## UI guidelines

[list your UI guidelines standards]

This can seem like a lot of work, so we can get GitHub Copilot to write custom instructions for us instead. There are a couple of ways we can do this:

Go to the GitHub Copilot Agents page.
Select your repo from the dropdown.
Enter the following:

Your task is [describe the task] by adding a .github/copilot-instructions.md file in the repository.

<Goals>
[outline the goals you want GitHub Copilot to achieve]
</Goals>

<Limitations>
[add limitations such as length or task-specific]

<WhatToAdd>
Add the following high-level details about the codebase to reduce the amount of searching the agent has to do to understand the codebase each time:
<HighLevelDetails>
- A summary of what the repository does.
- High-level repository information, such as the size of the repo, the type of the project, the languages, frameworks, or target runtimes in use.
</HighLevelDetails>

Add information about how to build and validate changes so the agent does not need to search and find it each time.
<BuildInstructions>
[put in some build instructions]
</BuildInstructions>

List key facts about the layout and architecture of the codebase to help the agent find where to make changes with minimal searching.
<ProjectLayout>
[add in what the project does and how it works]
</ProjectLayout>
</WhatToAdd>

<StepsToFollow>
[what should GitHub Copilot do, maybe perform search of what's available, scripts etc., then think]
</StepsToFollow>

Click the arrow or press enter.
Analyse the output and adjust if needed.

We can also have VS Code do it all for us:

Open the repo you'd like custom instructions for.
In the chat menu, click the "Settings icon".
Click "Generate instructions".
In the chat window, view the steps GitHub Copilot took.
Review the .copilot-instructions.md file.

Path-specific custom instructions

These are similar to repo instructions, but can be created for specific files. This is useful if we only want Copilot to apply logic to a certain file in the repo. Path-specific instructions are currently only supported by VS Code and JetBrains IDEs.

Create path-specific instructions by:

In your editor, open the repo where you want to make a file-specific instruction.
Create a new folder called instructions under the .github directory.
Create a new file called NAME.instructions.md. NAME should indicate the purpose of the instructions. You can create as many of these instructions as you like.
Open the file and on the first line write: applyTo: "app/models/**/*.rb" to indicate which files you want the instructions to apply to. You can specify multiple files by using a comma: applyTo: "**/*.ts,**/*.tsx". You can also apply the instructions to all files using applyTo: "**". This is useful if you're creating multiple instructions and you want some high level instructions to apply to everything and other sub-instructions to apply to specific files.
Add instructions again using natural language in markdown.

Organization custom instructions

Instructions can also be set at the organization level and are useful for enforcing your company's, team's, or community's policies and guidelines. Org custom instructions are currently in public preview, and can only be set by Org Owners with a Copilot Enterprise subscription.

You can read more about it in the GitHub announcement blog post.

Agent instructions

A lot of people are now using AI Agents, and you can write instructions for them too. These instructions are used by AI Agents to dictate how they perform. The AGENTS.md file can sit anywhere in your repository, and is written with natural language in markdown. It's an open format for guiding coding agents. You can also use a CLAUDE.md or GEMINI.md file that will sit in the root of your repo.

Check out the Open AI example of how instructions should be written for coding Agents.

Prompt files

Now that you have a handle on all the custom instructions, let's look at prompt files. These differ as they are reusable prompts for specific tasks that we can call via the chat window. For example, instead of using @workspace in Copilot chat to look at the entire workspace, you can call a custom file you've already created. This is useful for setting up lots of types of prompting files, think explaining code, writing tests, and documentation.

Prompt files are currently in public preview and only available in VS Code and JetBrains IDEs. Let's look at each of these and what they do.

We can create prompt files by doing the following:

In your editor, open the repository where you want to create a prompt file.
Create a new folder called prompts under the .github directory.
Create a new file in this new folder and name the file explain-code.prompt.md
Enter the information you want your prompt to output or perform. As an example, you can use this prompt that helps with writing clear and well-documented code:

---
mode: 'agent'
description: 'Generate a clear code explanation with examples'
---

Explain the following code in a clear, beginner-friendly way:

Code to explain: ${input:code:Paste your code here}
Target audience: ${input:audience:Who is this explanation for? (e.g., beginners, intermediate developers, etc.)}

Please provide:

* A brief overview of what the code does
* A step-by-step breakdown of the main parts
* Explanation of any key concepts or terminology
* A simple example showing how it works
* Common use cases or when you might use this approach

Use clear, simple language and avoid unnecessary jargon.

Go to the GitHub Copilot chat window and switch to "Agent" mode.
Type /explain-code and review the output.
You should also notice that your new prompt file is being used as the reference.

When working with any type of custom prompting, we can always check to see if the instructions we've written above were used by checking which references were used in the chatbox.

Prompt engineering and customising your prompts

Custom instructions and prompt files aren’t just nice-to-haves, they’re powerful ways to shape how GitHub Copilot works for you. Pair these with strong prompting skills and an ethical approach to AI, and you’ll level up your entire development workflow. If you want a refresher, check out the articles on prompt engineering and responsible AI. They’re quick reads that reinforce the principles behind everything we’ve covered here.

Michelle Duke

Oct 20 '25

Responsible use of AI for developers: Ethics and prompting with purpose

#ai #devops #productivity #machinelearning

Comments 2

2 min read

Celebrating All Hallow's Eve

Michelle Duke — Wed, 05 Nov 2025 03:23:27 +0000

This is a submission for Frontend Challenge - Halloween Edition, CSS Art.

Inspiration

For my submission, I went for something a little different than the jack-o-lanterns 🎃 and spooky things 👻 we often think about during Halloween. I wanted to create something that captures the essence of what Halloween really means, not just costumes and candy, but remembrance.

Thus, I created a beautiful webpage featuring a flickering candle on a lovely wooden table. It's a simple, peaceful symbol of what Halloween, AKA All Hallows' Eve, really means: the night we remember all those who came before us, and who have now journeyed onward. A candle is such a simple object, yet it carries deep symbolism: light in the darkness 🕯️, warmth 🔥, and memory. Translating that into a webpage allowed me to combine some artistic creativity with CSS and web animation.

Demo

My website is built mostly with CSS, with just a tiny sprinkle of JavaScript to enhance the flicker. You can see the project live with my use of GitHub Pages:

This project was primarily CSS-driven, which aligns perfectly with the CSS Art challenge guidelines. Some of the techniques I explored included:

Gradients and layering: Creating the soft glow of the candle flame required multiple layers and subtle gradients to mimic light diffusion.
Animations and keyframes: The flicker effect is achieved by animating opacity, transform, and shadow offsets to make the flame feel alive.
Minimal JavaScript: Just enough to add a slight randomness to the flicker, with the star of the show being still pure CSS ⭐.

This is probably my favourite piece of CSS:

/* Flame with inner core and outer glow */
.flame {
    position: absolute;
    top: -200px; 
    left: 50%;
    transform: translateX(-50%);
    width: 24px;  
    height: 300px; 
    background: radial-gradient(circle at 50% 30%, #fff6c8 0%, #ffd35b 18%, rgba(255,153,34,0.95) 42%, rgba(255,100,20,0.6) 70%, transparent 71%);
    border-radius: 50% 50% 40% 40%;
    filter: blur(0.6px);
    z-index: 4;
    mix-blend-mode: screen;
    transform-origin: bottom center;
    animation: flame-flicker 1.2s infinite;
}

The website is also responsive, meaning if you change the dimensions, the candle will adjust accordingly:

Journey

I'm one of those visual learners, I love seeing things actually work. This is one of the reasons I love CSS so much: you change something and something visibly changes. Even after years of working with CSS, this project reminded me how powerful CSS can be for creating fun, realistic effects. I experimented with colours and layering, and the result feels very much alive. It's not perfect and doesn't replace my physical candle, but working with this CSS shows the power of effects.

This project also reinforced a concept that something small (such as a candle, or a small change in the CSS), can be more impactful than overloading a scene with too many details.

CSS artwork

CSS Art isn’t always about flashy visuals. It can be about storytelling through code. By combining design sensibilities with CSS techniques, you can create something that resonates emotionally while still impressing technically.

If you want to explore it yourself, check out the code in my GitHub repo and the live demo powered by GitHub Pages. For anyone entering the CSS Art challenge, remember: let your creativity guide your styles, but keep the CSS at the heart of the project:

mishmanners / candle-webpage

Celebrating All Hallow's Eve

This project creates a beautiful webpage featuring a flickering candle on a lovely wooden table. The candle symbolises remembrance, showing why we celebrate Halloween, AKA All Hallow's Eve.

This is a submission for the DEV Frontend Challenge.

Setup Instructions

Clone the Repository:

git clone <repository-url>
cd candle-webpage

Open the Project: Open the src/index.html file in your web browser to view the webpage.
Modify Styles: You can customise the appearance of the candle and text by editing the src/css/styles.css file.
Flickering Effect: The flickering effect of the candlelight is controlled by the src/js/main.js file. You can adjust the animation parameters as needed.

View on GitHub

Happy Halloween, and happy coding 🕯️🎃.

Code, community, and copilot. AI is changing the way we contribute

Michelle Duke — Mon, 03 Nov 2025 00:55:29 +0000

This is a submission for the 2025 Hacktoberfest Writing Challenge: Contribution Chronicles

Hacktoberfest is always one of my favourite times of year. It's a month filled with learning, sharing, and connecting through open source. Every year, I try to dive into a few new projects, meet new communities, and stretch my technical skills. This year, my main contribution highlights were to Appwrite, ToolJet, and for the first time, Home Assistant's Core, and I learned tonnes along the way.

Learning through contributions

One of the things I love most about open source is how it forces you to learn by doing. Each project has its own way of working, its own tech stack, and its own community culture. Appwrite, for instance, has such a rich and well-documented environment that made it a great place to dive deep into backend systems and authentication flows. ToolJet, on the other hand, gave me the chance to explore where no-code meets open source. Contributing in this way helps others build faster, and that was both challenging and rewarding.

And then there was Core, my first contributions to the project. Jumping into a new codebase can feel like walking into a library where every book is written in a slightly different language. But that’s the beauty of open source: you learn to navigate new structures, styles, and expectations, while discovering just how welcoming maintainers can be when you ask questions or offer suggestions.

I also love how we are rewarded for our contributions through Holopin. It's a fun way to showcase your involvement in technology, collect badges, and curate your board:

You can even add your board to your GitHub profile:

AI is changing the way we contribute

This Hacktoberfest, I noticed something a little different. It's not just how I contributed, but how I learned. AI tools like GitHub Copilot, Copilot for Pull Requests, and CodeRabbit are becoming a natural part of the contribution process. They’re helping contributors (like me!) catch small issues early, suggest cleaner code, and even guide commit messages.

GitHub Copilot is also helping review the code with useful summaries and updates on PRs:

What’s even more powerful is how these tools support maintainers. Code review can be a time-consuming process, especially during Hacktoberfest when contributions flood in. But with AI-assisted code reviews and automation checks, maintainers can focus on the things that make sense: architecture, logic, human decisions, instead of being bogged down in syntax or formatting issues. As an example, I contributed to EbookFoundation and their GitHub Actions bot picked up if any resources were placed in the incorrect order:

We're now working in a hybrid world where human creativity meets AI assistance, and the result is faster learning and more maintainable projects.

Growing together

Hacktoberfest has always been about growth, both individual and collective. This year, I learned how to learn better and work with automation tools. I learned how to communicate more clearly in PRs, how to write more descriptive commit messages (thanks, Copilot!), and how to think about maintainability from a maintainer’s perspective.

I also saw first-hand how open source communities are embracing AI not as a replacement, but as an enhancement. It's a way to empower more contributors to get involved, and to help maintainers manage their growing projects without burnout. As an example, having AI pre-review code and run checks can be helpful for picking up early bugs, and ensuring guidelines are adhered to:

Looking ahead

Contributing to open source has never been easier, more accessible, or more exciting. Whether you’re tackling your first “good first issue” or merging your 100th PR, there’s always something new to learn. This Hacktoberfest reminded me that contribution isn’t just about code; it’s about collaboration, curiosity, and continuous improvement.

If you’ve never contributed before, jump in! Start small, ask questions, and don’t be afraid to let tools like GitHub Copilot lend a hand. Because in open source, every contribution counts, and every experience is a chance to grow.

Responsible use of AI for developers: Ethics and prompting with purpose

Michelle Duke — Mon, 20 Oct 2025 07:59:14 +0000

As developers, we’re shaping how AI fits into our workflows. This carries a lot of responsibility. When working with tools like GitHub Copilot, Cursor, or AI models, it’s important to think beyond what the AI can do, and focus on how we should use it.

There are three key areas to keep in mind: code quality, copyright and licensing, and collaboration.

💻 Code Quality

Even when AI-generated code looks great at first glance, it’s still your responsibility to make sure it’s solid. Think of AI as your pair programmer, not your replacement.

Check, check, check your work. Review every line before merging, you’re the final gatekeeper. Regardless of whether GitHub Copilot or other is the author of your PR, you are still responsible for shipping the code. If you're not sure, ask a senior member of your team, a colleague, or a manager. Don't just accept that the AI is providing.

Test your code. Does it run as expected? Are edge cases handled?

Keep your code maintainable. Make sure it’s written in your team’s style, easy to read, and simple to debug.

AI can speed things up, but good engineering practices still apply.

⚖️ Copyright and Licensing

AI models like GitHub Copilot were trained on public code. This means ownership and attribution can get tricky. Stay ethical and compliant by being mindful of where code comes from.

Provide context. The more project-specific context you give, the more likely your AI will generate original, relevant code.

Double-check the source. Before using generated code in a closed-source or commercial project, make sure it doesn’t infringe on others’ work.

Respect open source licenses. Check repo licenses and follow their terms.

Document responsibly. Comment when and how AI-generated code was used as this helps with transparency.

🤝 Collaboration and Transparency

Your AI might be an amazing coding buddy, but your best collaborators are still your human teammates. Building trust and clarity around AI use helps everyone work smarter.

Be open about AI use. Let teammates know when you’ve used AI assistance in your work. Ensure you're using AI within your organisation's policies and practices. Remember, tools like GitHub Copilot have business tiers to ensure you're effectively working within your teams' security and compliance.

Review with care. Treat AI-generated code the same way you’d review a teammate’s PR, that is, thoughtfully and critically. Check what model your AI is using. How has that model been trained? What kind of bias might be in the training data?

Encourage inclusivity. Diverse perspectives make for better code and fairer AI outputs. Try prompting your AI to consider different approaches or viewpoints.

Keep learning together. Share insights, report odd outputs, and help shape how your team or community uses AI responsibly.

Remember to be responsible

Responsible AI use isn’t about limiting creativity. Rather, it’s about enhancing it. By combining human judgment with AI’s capabilities, we can write cleaner, fairer, and more innovative code, together.

GitHub Copilot - Methods, modes, and Models: Which one is the best?

Michelle Duke — Wed, 23 Apr 2025 01:27:09 +0000

When someone asks "what's the best [insert type of tool]", the answer usually is "it depends". What's the best car? What's the best computer? What's the best AI? It all depends on what you're trying to do. What you're better off asking is "what's the best [insert type of tool] for [insert activity]". Now your questions become "What's the best car for long distance driving?", "What's the best computer for FPS gaming?" "What's the best AI for coding?" Now we're getting somewhere.

"What's the best AI?" is a trick question, because it depends on the type of activity you are doing. Same with models, agents, and modes. Let's look at GitHub Copilot and how you can use it to achieve what you want, and what the different modes and models are designed for.

GitHub Copilot Methods

When GitHub Copilot was first launched, code completion was all it could really do. It can suggest lines of code, or whole functions. Now, GitHub Copilot has evolved to do so much more. It can still suggest lines of code or functions. You can still use the chat feature in the side bar, or you can press "CTRL + I" to bring up the inline chat and have GitHub Copilot help with a certain section of your code. These are the three main ways you can interact with GitHub Copilot:

GitHub Copilot Code Completion
GitHub Copilot Chat
GitHub Copilot In-Line Chat

GitHub Copilot Modes

Within GitHub Copilot Chat, we now have various ways in which we can chat and interact with GitHub Copilot: Ask, Edit, and Agent.

By clicking the arrow next to the GitHub Copilot “mode,” you can bring up these three options. You'll want to choose the option that suits the outcome you are wanting. For example:

Ask: Question GitHub Copilot on technical topics
Edit: Have GitHub Copilot create new code, or edit existing code
Agent: Let GitHub Copilot automatically edit your existing code using multiple requests to pick which files it should edit, run commands, understand errors and iterate on those errors

The mode you pick will depend on what you want to accomplish. If you're starting a new project for the first time, you won't be able to use "Agent" mode because there's no code to edit. Think about what you're trying to do and which mode is the best for you. Switching between modes can help you have the best outcome.

GitHub Copilot Models

Like many AIs, GitHub Copilot runs on various different models. These models have been trained differently and therefore are better at doing certain things. It's like asking different people for their answer to a question; everyone has been taught slightly different and have different experiences and backgrounds, and thus the answers you receive from different people might be slightly different.

In a similar way, different Large Language Models (LLMs) can help with different tasks. For example, GPT-4o is a multimodal model and can support both text and images. Thus, by using GPT-4o you can have GitHub Copilot convert a hand drawn wireframe into a functional website.

Claude 3.7 Sonnet, for example, is an advanced model that requires structured reasoning, but can deliver on deeper tasks. It's good at bug fixes and advanced optimisation. Gemini 2.0 Flash on the other hand is good at generating small reusable pieces of code due to its high-speed, multimodal model that's been optimised for real-time inputs and agentic reasoning, making it a good fit for Agent Mode. There are tonnes of models to choose from and you can read more about them in the GitHub Docs and understand which one you might want to use for a specific task.

You can choose your model, right alongside the GitHub Copilot mode:

Remember, if you are having trouble getting what you want from GitHub Copilot, switching to a different mode can really help.

How have you been using GitHub Copilot? What's your top tip for getting the best out of GitHub Copilot?

GitHub Issues or GitHub Discussions? What's the difference, and when should you use each one?

Michelle Duke — Thu, 17 Apr 2025 00:27:51 +0000

Tabs or spaces, Python or JavaScript, Windows or Mac, Issues or Discussions? Everything depends on the situation. Today, we're going to look at GitHub Discussions and GitHub Issues to explain the differences and when you should use each.

Launch of GitHub Issues and Discussions

GitHub Issues was launched in 2009 as a way for software teams to collaborate. Developers and users now had a way to submit bugs, request features, and report other issues related to the project. Issues were designed to be a place to talk about a bug, feature, or update, before working on it, and closing out the issue. We know users don't always use a product exactly as intended, and developers were finding themselves having lengthy Discussions around whether they should work on an idea or issue in the first place.

This is where GitHub Discussions comes into play. Launched in 2020, Discussions are a way for developers and the community to have discussions—conversations around features, bugs, and suggestions—outside the codebase. Discussions aren't closed the way issues are, and thus they can serve as a place for maintaining FAQs, documentation, and hosted threaded conversations.

When should you use a Discussion or an Issue?

In short, Issues should be a way to track tasks and defined pieces of work. Discussions on the other hand are great for hosting questions, ideas, and a way to collaborate before making a decision. They are also great for community building, hosting conversations around FAQs, show and tells, and more.

If you ever create and Issue that you think should be a Discussion, and vice versa, you can quickly convert an Issue to a Discussion or a Discussion to an Issue. This is also helpful-as an example-if someone has opened a Discussion and a decision has been made, you can convert it to an Issue to complete the work. You can also convert an Issue to Discussion if someone has opened an Issue for a feature request, and it turns into a Discussion about whether the feature should be built, rather than being a task to implement the feature.

When it comes down to it, it depends on the situation whether you use GitHub Issues or Discussions. Both these products are great ways to collaborate and build projects, and I hope I've given you plenty of information to make a decision on when you should open a GitHub Issue, and when you should create a GitHub Discussion.

Best community tech Discord servers to join

Michelle Duke — Mon, 07 Apr 2025 05:32:15 +0000

Joining a Discord server can be a lot of fun. Engaging in the tech community is super valuable, and Discord has become a place for many tech groups from all over the world to gather.

You can find likeminded people, get answers to your questions, and connect with other developers who build awesome products. Many Discord servers encourage their community members to post questions and issues regarding their product or service, so you can get help directly from either the community or those building the service.

It can feel a little overwhelming when getting started as a user, so I've put together my top ten cool servers you can join.

Microsoft

Needing no introduction, the Microsoft Discord is a place for community members to come together and geek out about Microsoft. The moderators are community members, just like you, and you can receive all kinds of support from technical, to builds support, programming chats, and even advice on design.

You won't be disappointed joining this community.

.NET

If you want to find all the Microsoft employees, it looks like they hang out in this server. The Discord is for contributors to the .NET platform and ecosystem. There are a bunch of no-go topics, so make sure you read the rules before you post in here. There are channels for specific operating systems, frameworks, libraries, languages, and even GitHub repos. If you're contributing to .NET, you'll find everything you need here.

Discord

It's so meta, but there's a Discord server for Discord. This one is specifically for developers. If you're building an open source community, and running a Discord channel, you'll want to check out this community. There are lots of resources around the Discord API, news, product announcements, and plenty of help available.

Gamedev.js

For the game developers amongst you, join Gamedev.js. This server is all about game development, promoting game jams, jobs, encouraging people to showcase their games, and plenty of channels to ask questions about your game. This server is also specifically set up for French, Spanish, Portuguese, and Brazilian speakers.

Next.js

Set up super well for new members, you'll be greeted with a lovely welcome screen that walks you through the rules, asks questions about your interest in Next.js and even set up a custom colour for your username. They'll post about events, hackathons, and more, so get involved.

Tina.io

The open source content management system (CMS) Tina, does all their support through Discord. Open a GitHub Discussion that's linked to Discord, or chat with other members of the community to troubleshoot your bugs.

Appwrite

One of the top open source communities, Appwrite has participated in big open source events every year. Their Discord hosts events, office hours, and encourages people to showcase their Appwrite projects. Chat to maintainers, giggle at memes, and get the support you need.

Devtron

I came across Devtron one Hacktoberfest, and I thought it'd be fun to check out. It's a Kubernetes Platform and you can engage with the community on Discord. Check out their upcoming hackathons, get help with your community contributions—yes Devtron is open source—and provide feedback to shape the future.

Adafruit

I love a good piece of hardware, yet it comes with its own set of challenges. Luckily, Adafruit have a server where you can get lots of help from the community. Get help with specifics of circuit boards, 3D printing, firmware, design, and more. Chat with others, and showcase your builds. There are tonnes of channels in this server so take a little bit of time to browse through and find the right one for you.

Major League Hacking

Another huge hackathon community is Major League Hacking. Their server showcases all their major hacks, and if you're a hackathon organiser, you can get loads of tips and tricks on running your hackathon.

Don't forget the community guidelines

Similar to our top tips for being a good community member, don't forget to read the rules, roles, and announcements for each Discord server before joining.

Michelle Duke for GitHub

May 17 '22

Top tips for being a good online community member

#opensource #tutorial #beginners #devops

Comments 1

4 min read

Game developers: use AI to build your game with Razer AI Game Copilot

Michelle Duke — Thu, 03 Apr 2025 05:44:46 +0000

I recently wrote an article on Razer's announcement of WYVRN, which includes the release of their AI Game Copilot. What does this mean for game developers?

Develop games with automatic support

Building games is hard enough, without having to worry about building support for third-party components and hardware such as RGB lights and THX® Spatial Audio. If developers build games with this kind of support, games will be more immersive for players. But this can be a mammoth task, involving SDKs, more dev hours, and more testing.

The new Razer AI Game Copilot can now help you build your games for integration with Razer Sensa HD, Razer Chroma lighting effects, and THX® Spatial Audio+. This means you can streamline your development process, and build products that will automatically be capable of connecting with Razer Chroma lights and have immersive sound as an example.

Automatic testing and hardware optimisation

Razer AI Game Copilot doesn't just make coding faster and easier, but it can help with testing and performance. The tool can help you with quality assurance (QA) testing. By partnering with Side, Razer builds on Side's 30 years of experience in QA testing. The partnership is all about working with Razer on tools and technology to improve game developer QA.

The CEO of Side, Deborah Kirkham, said the partnership brings together the best technology and makes it available for game developers:

"As a company, Side’s mission is to infuse technology with human ingenuity to create unforgettable game experiences. Working hand-in-hand with Razer, this partnership allows us to combine decades of market-leading experience in our respective areas to revolutionize the way games are tested.”

The Razer AI QA Copilot can plug into existing testing workflows, boosting bug detection efficiency, allowing you as the developer to focus on building the product rather than finding and fixing bugs. This Copilot can also help with crashes and performance issues, suggesting code and fixes to improve the overall playability of your game. Furthermore, this will help you cut costs and release your game to the public faster.

How can you use Razer AI Game Copilot as a developer?

As a game developer, you already get access to Razer AI Game Copilot via Razer WYVRN's SDK. You can download this directly from the website, or—even better—use Razer WYVRN’s SDK directly from Unreal Engine 5.5 which is already available. This means if you're an Unreal Engine developer, you can enable WYVRN technologies directly from your Unreal Editor.

Would you use Razer AI Game Copilot?

Are you already using AI tools? Would you use Razer AI Game Copilot to help develop your game? Drop your answers in the comments.

And if you're a gamer, Razer AI Game Copilot for gamers is coming soon!

Compiling 2025: Goals, strategies, and milestones

Michelle Duke — Fri, 17 Jan 2025 05:41:03 +0000

This is a submission for the 2025 New Year Writing challenge: Compiling 2025.

Reflecting on your year is an important step before moving forward into the new year. Check out my 2024 reflection before diving in here and reading about my goals, and goal-setting.

Debugging 2024: Lessons learned, wins, and achievements

Michelle Duke ・ Jan 17

#devchallenge #newyearchallenge #career #speaking

New Year's Eve 2024

On New Year's Eve, as my husband and I sat on the beach, sipping champagne and waiting for the fireworks ✨, we asked each other about our goals for this year. Goal-setting is one of those activities I've done for as long as I can remember. When my husband asked me this, I thought about it for a bit—at this point in time, I hadn't really sat down to set my goals for 2025. But this question prompted me to start gathering my thoughts and thinking about what it was I wanted to achieve this year.

Structuring and setting goals

I believe goal setting is something we should do for all aspects of our life. Every year, when I write my goals, I look at various parts of my existence, and write goals for each of those sections. Here is the list I use when thinking about "aspects of life":

Career
Physical/sport
Financial
Family/friends/community
Spiritual/mindfulness
Hobbies
Wellness and health
Exploration/travel

Each of these aspects represents a different part of our lives and I have goals for each of these. For example, a career goal might be "learn Python enough to build an AI chatbot", or "take on a leadership position within my company, even if it's something outside my direct team". Physical or sports goals might be "go to the gym at least three times a week", "run 10km in 45mins". You can see how breaking goals into categories can help us succeed.

It also forces us to think outside the usual goals and categories we often think about when we talk about "goals". For example, if I ask someone what their goals are for this year, I might get something like "lose 10kg", or "get a promotion". You rarely hear someone talk about things like "set aside time for myself for meaningful reflection". Try and have at least one goal in each of the classes.

🏆 How to achieve goals

Next, how do you actually achieve goals? Some goals might be 'easier' to achieve than others, in the sense that they have a set path to winning. For example "run 10km in 45mins", can be broken down:

Run 5km without stopping
Run 7km without stopping
Run 10km without stopping
Run 10km in under 60mins
Run 10km in under 50mins
Run 10km in under 40mins
Run 10km in under 45mins ➡️ GOAL

What I've done here, is written a list of "mini" goals on the pathway to achieving the main goal. This is a good technique to practice when goal setting ➡️ breaking down large goals into smaller goals. When you reach these milestones, you should celebrate 🥳. You don't have to celebrate in a massive way, but small wins should mean small celebrations, big wins should equal big celebrations.

We often don't take enough time out for ourselves to celebrate the small wins along the way. But if we can do this, it will give us consistent motivation to achieve our large goals, and ensure we don't get burned out along the way to achieving the big targets.

Another way to set goals is to put time limits or dates on your goals. For example "read more books" could be a good goal for this year, but it's much harder to achieve because you haven't really defined it. You might get to the end of this year and go "did I really read more books?". Maybe you read a book, which is one more than what you did last year. Is this a win? It might be. Be specific about the type of goals you want to set. Instead, it might be "read one book a week", or "read a chapter of a book each night". Break goals into smaller, manageable, and trackable tasks. This will ensure you feel good about reaching each of those wins each day or each week, and you don't feel burned out from 'not achieving' anything.

You might also like to consider a way to record track your goals. It might be a diary, GitHub Project board, or similar.

What are my goals for 2025

I've talked a lot about goals, so what are mine for this year? Well, last year I did a lot of speaking engagements, so this year, my target is to reach ten keynote presentations. It's a stretch but it's a good, measurable goal to have. I would like to be on Twitch more, and so I'm aiming for a least 2-3 streams a week, as long as I'm in Melbourne (I'm not counting trying to do live streams whilst travelling).

I have a goal set for every category above, but I won't reveal them all to you here. Just remember, look at what you want to achieve, why, and then how. Think about how you might celebrate those goals along the way. For example, you might have a financial goal to save a certain amount of money by a certain amount of time, and if you hit your target, then you might treat yourself.

Debugging 2024: Lessons learned, wins, and achievements

Michelle Duke — Fri, 17 Jan 2025 05:33:05 +0000

This is a submission for the 2025 New Year Writing challenge: Retro’ing and Debugging 2024.

I'm one of those people who love looking back on a year. Reflecting on what I've done, what I've learned, and what I want to achieve in the following year. This year—like many others—I jumped on Twitch to recap my year, review the stats, and talk about what I want to do moving forward.

Here are the stats, things I learned, and goals I have for 2025. The main reason I like sharing these things is to inspire and motivate others. I hope you find it interesting ❤️.

2024 Stats and Achievements

I look at the main things I completed during the year. For me, as a developer advocate and influencer, a lot of what I do is content creation. I check out the number of conferences I spoke at, videos I created, blog posts written, and even GitHub contributions. After adding them all up, you can see the stats yourself:

// Detect dark theme var iframe = document.getElementById('tweet-1876885288552644899-751'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1876885288552644899&theme=dark" }

Finally, I looked at a couple of big things I achieved. I was really excited to win one of DEV's first DEV challenges, and it motivated and encouraged me to submit to more in future, including this one.

Congrats to our first Computer Science Challenge Winners!

dev.to staff for The DEV Team ・ Jun 25 '24

#devchallenge #cschallenge #computerscience #beginners

I also won some awards that I'm really proud of, and was selected in the "top 3% of most active speakers on Sessionize". Something I think that's really important when it comes to stats and achievements is thanking people 🙏. Most of the things I've achieved in the past year wouldn't have been possible without others: conference organisers who selected my sessions, colleagues who put me forward for opportunities, and those who chose to publish my articles. In one of my LinkedIn posts I tagged and thanked multiple people and organisations who helped me achieve these numbers last year.

Things I learned

Retrospectives wouldn't be useful if we didn't learn anything from them. I picked up some really cool technical skills last year.

Test writing and test driven development

One of my colleagues took time out to teach me all about writing tests for code. I learned about test driven development (TDD), the testing hierarchy, and the importance of writing tests, as well as types of testing. I documented these learnings in a blog post:

How to test websites: Using SIRV and Playwright for test driven development (TDD)

Michelle Duke ・ Aug 7 '24

#javascript #webdev #programming #tutorial

One of the reasons I love writing blog posts, is not only to share my knowledge and learnings with others, but to have good documentation that I can refer back to when I need it. There have been at least three occasions since writing the article where I've been building websites and writing tests, and I've referred back to this article. Thus, I encourage you, if you learn something new, write about.

Online Learning

I've known about LinkedIn Learning for a while, having featured it under my GitHub repo of free learning resources for several years, however I feel as though the platform is now well-developed, featuring many different types of learning—from technical to management, project engineering, emotional intelligence, resilience, and more.

As such, I've completed over 60 LinkedIn Learning courses, most in the past few months. It's a great way to upskill and discover new areas of learning. There's also Microsoft Learn where I completed several courses. I'd encourage you to add learning—both formal and informal—to your goals for 2025.

Learning to say no

This is one of the hardest things, especially for someone like me who really likes to help people. Learning to say no—and actually doing it this year—taught me a lot. I gained a lot more time that I could use for more impactful things, and other people valued and respected my time more. Whilst I've always known these things, and have been to so many different talks on the subject, it's really hard to actually do. But once you do, there's something liberating about putting it into practice.

I believe it was during Christina's talk at NDC London last year that I finally thought "Right! I'm going to do this".

Not only is she a brilliant speaker, but she also pointed out one of the things I struggled with when saying "no": how not to feel bad about it. I'd recommend giving her talk a watch.

Goals for 2025

I think it's really good to reflect on what we've done and learned and look forward. Well, from this post, it's clear I did a lot, and learned a lot from 2024, so how do I top that? On New Year's Eve, as my husband and I sat on the beach, sipping champagne and waiting for the fireworks, we asked each other about our goals for this year.

So if you want to hear about how I structure yearly goals, and learn a bit about my 2025 goals, check out my next blog post:

Compiling 2025: Goals, strategies, and milestones

Michelle Duke ・ Jan 17

#devchallenge #newyearchallenge #career