<feed xmlns="http://www.w3.org/2005/Atom"> <id>https://zackkoppert.com/</id><title>Zack Koppert</title><subtitle>Personal blog of Zack Koppert - Senior Software Engineering Manager at GitHub's Open Source Programs Office. Writing about InnerSource, open source, DevOps, and developer tooling.</subtitle> <updated>2026-05-04T16:13:39-07:00</updated> <author> <name>Zack Koppert</name> <uri>https://zackkoppert.com/</uri> </author><link rel="self" type="application/atom+xml" href="https://zackkoppert.com/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="https://zackkoppert.com/"/> <generator uri="https://jekyllrb.com/" version="4.4.1">Jekyll</generator> <rights> © 2026 Zack Koppert </rights> <icon>/assets/img/favicons/favicon.ico</icon> <logo>/assets/img/favicons/favicon-96x96.png</logo> <entry><title>Does a Language Server Actually Help AI Coding Assistants? I Ran an A/B Test to Find Out</title><link href="https://zackkoppert.com/posts/does-lsp-help-ai-coding-assistants/" rel="alternate" type="text/html" title="Does a Language Server Actually Help AI Coding Assistants? I Ran an A/B Test to Find Out" /><published>2026-05-04T00:00:00-07:00</published> <updated>2026-05-04T15:04:17-07:00</updated> <id>https://zackkoppert.com/posts/does-lsp-help-ai-coding-assistants/</id> <content type="text/html" src="https://zackkoppert.com/posts/does-lsp-help-ai-coding-assistants/" /> <author> <name>Zack Koppert</name> </author> <category term="Developer Experience" /> <category term="AI Tools" /> <summary>TL;DR: I ran identical coding tasks with and without language servers enabled in GitHub Copilot CLI. In a large Ruby monolith (~118k files), LSP made Copilot 3–4x faster for models that completed the task - and one model couldn’t finish at all without it. In a small Python repo (61 files), it made no difference. If you work in large or complex codebases, LSP is worth the 10-minute setup. If you...</summary> </entry> <entry><title>Your Best PR Is Your Ceiling. Make It Your Floor.</title><link href="https://zackkoppert.com/posts/your-best-pr-is-your-ceiling/" rel="alternate" type="text/html" title="Your Best PR Is Your Ceiling. Make It Your Floor." /><published>2026-04-28T00:00:00-07:00</published> <updated>2026-04-28T23:59:19-07:00</updated> <id>https://zackkoppert.com/posts/your-best-pr-is-your-ceiling/</id> <content type="text/html" src="https://zackkoppert.com/posts/your-best-pr-is-your-ceiling/" /> <author> <name>Zack Koppert</name> </author> <category term="Engineering Practices" /> <category term="Code Review" /> <summary>A teammate asked me to help them level up their PR descriptions. As a part of this exploration, I built a rubric with seven dimensions, four quality tiers, and real examples from open source and internal projects. It made sense in theory. Then I thought: how do we turn best practices into personalized recommendations? So I pulled every PR I’d authored across the GitHub org since 2020 and grade...</summary> </entry> <entry><title>One File, Every Session: Keeping Copilot Instructions Consistent Across CLI and Codespaces</title><link href="https://zackkoppert.com/posts/copilot-instructions-everywhere/" rel="alternate" type="text/html" title="One File, Every Session: Keeping Copilot Instructions Consistent Across CLI and Codespaces" /><published>2026-03-27T00:00:00-07:00</published> <updated>2026-03-27T17:14:00-07:00</updated> <id>https://zackkoppert.com/posts/copilot-instructions-everywhere/</id> <content type="text/html" src="https://zackkoppert.com/posts/copilot-instructions-everywhere/" /> <author> <name>Zack Koppert</name> </author> <category term="Developer Tooling" /> <category term="GitHub Copilot" /> <summary>If you’ve invested time writing a solid copilot-instructions.md for your preferred coding style, PR conventions, and tooling preferences, you probably want those instructions loaded everywhere you work - not just in one repo. Here’s how I set up a single source of truth that automatically loads in every Copilot CLI session and every Codespace, with zero manual steps. Why bother? Every time y...</summary> </entry> <entry><title>Catching Merge Conflicts Before They Catch You</title><link href="https://zackkoppert.com/posts/catching-merge-conflicts/" rel="alternate" type="text/html" title="Catching Merge Conflicts Before They Catch You" /><published>2026-03-13T00:00:00-07:00</published> <updated>2026-03-13T00:00:00-07:00</updated> <id>https://zackkoppert.com/posts/catching-merge-conflicts/</id> <content type="text/html" src="https://zackkoppert.com/posts/catching-merge-conflicts/" /> <author> <name>Zack Koppert</name> </author> <category term="Open Source" /> <category term="Tooling" /> <summary>We were three engineering teams at GitHub, all jumping into the same product space at the same time. Multiple concurrent work streams, tight timelines, and a shared codebase. Everything was moving fast - until the 11th hour, when we discovered that the work we’d each been doing was stepping on each other’s toes. The resulting merge conflicts caused days of rework. Not hours. Days. If you’ve ev...</summary> </entry> <entry><title>Can You Measure InnerSource?</title><link href="https://zackkoppert.com/posts/can-you-measure-innersource/" rel="alternate" type="text/html" title="Can You Measure InnerSource?" /><published>2026-02-17T00:00:00-08:00</published> <updated>2026-02-17T00:00:00-08:00</updated> <id>https://zackkoppert.com/posts/can-you-measure-innersource/</id> <content type="text/html" src="https://zackkoppert.com/posts/can-you-measure-innersource/" /> <author> <name>Zack Koppert</name> </author> <category term="InnerSource" /> <category term="Measurement" /> <summary>February 17, 2026 I’ve been asked this question more times than I can count. It usually comes up right after someone pitches an InnerSource program, gets conditional approval, and then gets told to prove it’s working. I know this because it happened to me. At a previous company, I was able to convey the need for InnerSource by demonstrating how much rework we were doing across departments. Th...</summary> </entry> </feed>
