Note: this is a lightly edited version of an internal work post I wrote in April 2025 before Copilot Coding Agent was released to the public.
I’ve been playing with Copilot Coding Agent a bit lately, and it’s been really interesting for me to realize that my thoughts haven’t really been about AI so much as how strongly the output reminds me of incoming contributors to open source software, and all those non-code maintainer skills coming in handy and what I can work on sharpening again. Similar things apply to earlier-in-profession developers too, and with new hires joining our teams next week, this feels especially good to be thinking about right now.
The thing is, when you combine very eager volunteers with low context, you’ll tend to get additive solutions. And that makes sense! They’re thinking about how to make something work, not “what are all the things that happened leading up to this that caused this that maybe need re-examining” – root causing, if you will. But just because it makes sense and maybe is even expected doesn’t mean that we can’t help steer contributors, human or AI, in better directions through the way we describe the problem space in a well-written issue. Practices of keeping good hygiene between discussing problem definitions (issues) and feedback on solution proposals (PRs) also seem more important than ever – there aren’t always solution proposals to be had for a given problem, and sometimes there are multiple to think through.
So what are some things we can all think about as we grow ourselves and support the journey of others? Here’s what I’m thinking about, and I’d love to hear and talk about yours in the discussion!
Keep issues focused on the problem definition and context – centering them around a specific solution tends to narrow our thinking when it comes to the solution. Of course, sometimes it’s a straightforward bug that’s the problem, so don’t forget nuance either.
Clearly written reproduction steps: one of the things I encourage giving visible code-equivalent credit for in OSS, because it’s hard to describe reproduction steps in a way that is broadly understandable and doesn’t overly rely on screenshots. Oh and hey, if you do use screenshots, remember to include alt text – it’s good for both humans and the machine.
Including references and links for easy access from one place – building context from code archaeology is hard! This doesn’t have to happen when an issue is first written – it can be added later as you dig around and find things.
Ensuring non-durable artifacts or content behind auth like Slack conversations are copied over and/or summarized, especially when decisions are made.
Raising each other up and remembering to include all these skills as a part of how we think about impact and excellence at work and beyond.
Being willing to try to explain again in a different way to steer contributors onto a given path.
The machine is imperfect just as we are, and with AI it’s even clearer how it reflects our own imperfect communication back at us. I’m looking forward to cross-repo support someday with Copilot Coding Agent, because I can see the promise in using the tool to reduce the friction getting started with resolving audit-discovered issues. So while that’s not here just yet, we can still get a start on refining the way those types of issues are written to help get to a reasonable solution faster, whether done by human or Copilot.
I find myself most recently the engineering manager for accessibility at GitHub – an honor and immensely fulfilling to make improvements big and small for all of our users now and in the future. This isn’t an exhaustive post or a tutorial but rather some things I keep thinking about as we both use and work on AI tools.
Accessible interfaces 🤝 LLM context
Working on the accessibility of a product often involves a push-and-pull between prioritizing compliance and focusing on experiences. We need both but can’t always tackle both at the same time. One strong case for the compliance side is that it’s often about structure and semantics, things that are measurable and detectable in a more objective way. If you think about it, assistive technologies are programmatic consumption of rendered pages. What else does programmatic consumption of rendered pages? LLMs! If compliance alone wasn’t enough of a reason to prioritize that work, consider the additional benefit to anything doing programmatic understanding of your product and/or content.
Enabling even more users
With greater programmatic usability comes more ability to use whatever tools suit you to help navigate and use an interface, whether that’s chat or automations or otherwise. How many people have ideas that never come to be realized because they cannot access what they need to bring them to life? On this topic I’ll share a video that brought me to literal tears.
Accessible by default
I’ve heard it said that where we are with AI is the worst it’ll ever be, and I think that’s true. We will continue to learn and apply what we learn to the tools, and for things that really should be table stakes baseline aspects of what it means to be a developer like accessibility (no, your job is not done if it’s not accessible), the machine should be held to that same standard. New developments like MCP servers make me much more optimistic we can get there, but it remains a space to actively push on especially as we focus on agents and the production of larger blocks of code.
I’ve spent the last 8 months telling anybody I talk to about custom WordPress block development that they were way less scary and much easier than I thought they were going to be as somebody with minimal React experience, and that achieving a 1:1 editor experience where you manipulate directly in the content area instead of metaboxes or panels really comes alive when you reuse the same markup and CSS from the front-end and leverage the React components the block editor ships with. Because of that, I think a big game-changer for adoption and shifting thinking would be to find a way to unify templating between the front-end and the editor, essentially swapping the places where you output content with the corresponding editor component.
So what had happened was… I was once again going on and on about this to Mark Jaquith, who blessedly seems to enjoy walls of text from me about programming puzzles, and it turns out he’s been thinking about the same thing as he gets into block development. A weekend later, and:
Weekend exploration, egged on and sparked by @helenhousandi:
“What if building custom blocks for the Block Editor was as easy as supplying attributes and a block of HTML? What if this produced React editing code and PHP rendering code without a build step?” pic.twitter.com/r86Phu88SX
Many years ago (October 2015, to be exact) I wrote a small plugin that allows you to add a note when updating a post, intended as a way to describe what was changed in that revision. For the developer set, it’s kind of like commit messages for your WordPress post/content updates. It was created to fill a need on various WordPress.org sites, such as the handbooks, but it seemed generally useful so I released it as a public plugin. After one more update in August 2016, it just sat there, usable and useful but without any attention. Until this week.
I stream my open source work semi-regularly, and decided that working through how to adapt an old plugin to the block editor (2 years late) would make for a useful exercise. So I did that, for almost 4 hours! But that’s not how long it takes to do this – the base work of this really took about 45 minutes, with the rest of the time spent chatting and chasing a bug related to revisions. So, for this post I’m going to explain the process of achieving the final code, first demonstrating what most people will need, then what I actually did because of some specific UX needs, and then dissect the revision bug and things I tried that didn’t work out.
Masterclasses are not unique to classical music, but they do form a central and critical component of music study. A masterclass is a format in which musicians perform a work for an established artist and the artist then gives them feedback rather like a lesson, except that all of this happens in front of an audience. You might also hear about “studio class” in music school settings, which are similar except that it is not an open audience but instead one made up of your peers who share the same primary professor. For big artists coming to a school or a region, you might have to audition (compete) for a spot to be criticized publicly on your performance. Put that way, it might not sound very appealing, but it is foundational in how to function and succeed as a musician and really in any profession, including as a part of a software team, which is what I do today.
Managing feedback in group settings
The first experience in managing professional feedback is typically how you receive it. Sometimes you might not immediately agree with what you’re being asked to do, and that’s okay. What’s important is to respect the time and effort of the person giving you the feedback and show them that you understand it, even if after synthesizing that information you decide it’s not the direction you want to go. In music, that means acknowledging what you’ve heard by demonstrating the requested change on the spot. This might be a specific request, like “play this section softer”, or something that requires more interpretation, like “don’t lose momentum by getting stuck before the high point of this phrase”. This kind of flexibility is itself a skill, and one that is of high value.
In software, your feedback sessions might not involve direct and immediate action in the same way, but it can be very helpful to show that you understand a concept. For instance, you might say “I hear you, and I need to think about it some more; I’ll start by trying out a different way of structuring this file”. Do be careful not to just repeat back verbatim all the time or come across as explaining back in a condescending way.
As you progress through your career, you will likely find yourself in the position of also giving feedback in a group setting. For many people who are just beginning this part of the journey, this can be quite intimidating because you have not previously had experience in doing this. You also may have had bad experiences in the past with feedback that was not delivered in a constructive way. This is where an early culture of group feedback comes in so handy, notably in the studio class setting: professors are asking your peers to also learn how to process, structure, and deliver feedback in real time. You hear from your professor every week; this is an opportunity for students to deliver a polished performance, receive feedback, and give feedback all at once.
That said, peer groups can also be intimidating. This is not unlike having to give a talk or demo some code in front of your coworkers – it can feel like more pressure than a large room of strangers because these are people whose opinions you are exposed to on a near-daily basis and hopefully care about. Remember that we are all learning all the time, and your peers may also need to work on their delivery! Some strategies you may have encountered are to use “yes, and” instead of “but”, or to begin feedback with related praise.
I highly recommend that teams actively solicit peer feedback at various stages throughout a project and also workshop methods of requesting and giving feedback, something that can be facilitated by an engineering manager. An EM might even want to structure some team meetings much like a studio class, where people present on something they’re working on so that not only do they have a chance to share about something they might not otherwise get to talk about, but the team also has a mechanism built-in for giving and receiving feedback. Soliciting feedback is also a skill in its own right – a culture of regular and expected feedback goes a long way toward building that in all levels of team members.
Arriving prepared
Another major difference between masterclasses and lessons is that you are expected to present a polished product at a masterclass, whereas lessons are to workshop that polish. In a masterclass setting, you and any collaborators enter the stage, bow, and perform to applause before proceeding with the feedback from the masterclass artist. Some professors, especially at the conservatory level, also require performance attire when performing in studio class (though perhaps not black tie).
Working on a software team typically does not involve building something in a vacuum until you’re ready to release it to the world – you hopefully have team checkpoints that are more equivalent to music lessons. But there is a lot to be said for knowing that even though you’re ready to share your work publicly and have met your deadline, there’s still more that can be done, rather like a software beta. And even for something you’ve been performing for a long time, a fresh perspective can change not only how you’re approaching that piece, but how you think about your craft in general. Always be prepared to show your best and recognize that true mastery is in knowing that there’s always another level to reach for.
Cross-discipline knowledge
While masterclasses are typically with an individual artist who specializes in an instrument, many works involve other musicians, such as a string quartet or a piano trio. These are things that are worth bringing to masterclasses too! Related, it’s also valuable to have lessons from people who might normally be considered outside of your discipline – one of the best lessons I’ve ever had was with a jazz professor who spent 2 hours pushing me to express myself more and more.
Not only do your collaborators need to be equally prepared, you need to work together to really achieve artistry. All too often you will see lower-level instrumental masterclasses where the pianist is an afterthought, plunking their way dutifully through concerto reductions, and it shows. Sometimes the masterclass artist will also dutifully ignore them, but more often they have to involve all collaborators in their feedback. No amount of telling a vocalist to evoke the dreamy sparkling of Debussy’s Nuit d’Etoiles is going to work if the pianist is heavy-handed on those rolled chords, or vice versa. (This is also why collaborative pianists have to study lyric diction and multiple languages and can specialize in vocal coaching, but I digress.)
Not only does feedback need to be inclusive of a group while also targeted to each individual, it needs to be clearly contextualized. In music, that means including music history and theory as well – the performance practices of the era, specific notational quirks of the composer, what harmonies are and how do they drive the piece, and limitations of instruments and how they interact together. So when giving feedback to a software team, be sure to continually frame things within broader feature or product goals, and tie the various disciplines together to create that cohesive whole.
In both giving and receiving that style of feedback, you will find that you need to have some amount of understanding of disciplines outside of your own. That doesn’t mean that you need to be an expert; in fact, you will probably be received poorly if you try to instruct somebody on how specifically to accomplish something you don’t normally work on. Instead, much like framing within broader goals, think about how you might inspire somebody to look at something a different way, or contextualize within your own discipline so that they can understand you better as well.
Bonus: watch a masterclass!
Here’s a 45 minute masterclass session with Benjamin Zander, the music director/conductor of the Boston Philharmonic Orchestra and the Boston Philharmonic Youth Orchestra, and Amanda Chi, the cello section lead of the youth orchestra. I promise you don’t need to be a musician to get something out of this – at one point, Maestro Zander acknowledges non-musicians in the audience and gives them a brief explanation of what he means by the direction and pull of harmonies. But even outside of that, you’ll see some real mastery of not only the musical material from both parties, but also how to address both audience and performer, contextualize the feedback, and deliver that feedback in a constructive and suggestive way rather than making it into a personal demand. I also really enjoy what he talks about at the end, differentiating between what you need to do as a performer of this solo piece versus what you need to do as the leader of your group.
