# Chris Reddington > Hey! I'm Chris Reddington, a seasoned Developer Relations expert and tech enthusiast who loves bringing development teams and end-users closer together. Dive into my portfolio, explore the latest in cloud computing, DevOps, and software development, and get a glimpse of what I'm working on. Whether you want to learn something new or collaborate on exciting projects, let's connect! ## About Chris Reddington is a Developer Relations expert and tech enthusiast focused on cloud computing, DevOps, and software development. He works to bring development teams and end-users closer together. - Website: https://chrisreddington.com/ - About: https://chrisreddington.com/about/ - Github: https://www.github.com/chrisreddington - Bluesky: https://bsky.app/profile/chrisreddington.com - Linkedin: https://linkedin.com/in/chrisreddington - X: https://x.com/reddobowen ## Sections - [Blog](https://chrisreddington.com/blog/): Technical articles on cloud computing, DevOps, AI, and software development - [Talks](https://chrisreddington.com/talk/): Conference talks and presentations - [Videos](https://chrisreddington.com/video/): Video content and tutorials - [Projects](https://chrisreddington.com/project/): Open source and personal projects ## Recent Blog Posts - [The Jury Pattern: a mixture of critics for AI code review](https://chrisreddington.com/blog/mixture-of-critics/): One model reviewing its own plan tends to agree with itself. So I built a cleanup workflow shaped like a jury: separate critics from a deliberate mix of model families weigh the evidence, with a simple forcing function that keeps neighbouring reviewers off the same family. The orchestrator presides as judge, refuting rather than merging, votes promote shared findings, and a post-approval diff check can overrule a verdict that was unanimous and still wrong. - [Agentic memory: what agents should and shouldn't remember](https://chrisreddington.com/blog/agentic-memory-what-agents-should-remember/): Conversation state and retrieved context lead naturally into memory, but only if we're clear about what memory is for. Rules, skills, and instruction files package what you already know. Memory should capture what the work itself teaches the system, and that means reflection, verification, and forgetting matter just as much as recall. - [AGENTS.md and SKILL.md: building a reusable agent toolbox](https://chrisreddington.com/blog/building-your-agent-toolbox/): Context engineering gets more useful when the knowledge it depends on is packaged for reuse. In this post I map the portable core (AGENTS.md and SKILL.md), Copilot-specific concepts like custom instructions, agents and prompt files, and how to decide what knowledge belongs where. - [Context engineering: more context isn't better context](https://chrisreddington.com/blog/context-engineering-more-isnt-better/): Better prompts help, but they're only part of the story. Context engineering is the craft of designing what an AI agent sees, when it sees it, and how that changes across the session. The goal isn't a bigger context window. It's a more effective one. - [The DevRel randomisation trap (and how to stop it)](https://chrisreddington.com/blog/devrel-randomisation-trap/): There's a pattern I've seen play out across dozens of DevRel conversations, confirmed in my MBA dissertation research: teams without a clear golden thread from company strategy to daily activity get 'randomised' by whoever asks most urgently. Here's what the research says about why it happens and how to build your way out of it. - [From tactics to strategy: the DevRel measurement gap](https://chrisreddington.com/blog/devrel-tactics-to-strategy/): Of the 13 DevRel leaders I interviewed for my MBA dissertation, only two could clearly demonstrate a coherent link between tactical activity and organisational strategy. In this post, I talk through how focusing on the developer journey can help bridge that gap. - [The feedback loop: how DevRel bridges community and product](https://chrisreddington.com/blog/devrel-feedback-loop/): DevRel is often framed as the voice of the developer. My research suggests a broader job: gathering representative feedback, reducing friction, and showing developers what changed. - [Why developer communities are not brand communities](https://chrisreddington.com/blog/devrel-communities-not-brand-communities/): Academic research on brand communities can help DevRel, but only up to a point. The bigger lesson is where the model breaks: developer communities run on trust in the technology, not loyalty to the brand. - [Company context: the conditions that shape DevRel strategy](https://chrisreddington.com/blog/devrel-company-context-lifecycle/): Two companies can have similarly capable DevRel teams doing similar work and still get different results. In my research, company type, lifecycle stage, and technology cycles kept shaping what DevRel could realistically do. - [The four pillars of DevRel (and the foundation they rest on)](https://chrisreddington.com/blog/devrel-four-pillars-authentic-foundation/): Education. Success. Marketing. Programs. These four pillars describe what Developer Relations teams do. But the more important question is what makes that work credible, useful, and trusted by developers. - [Developer experience: prerequisite and product of DevRel](https://chrisreddington.com/blog/devrel-developer-experience/): Developer Experience isn't just central to DevRel strategy. It's both what your team depends on before it can succeed, and what it actively shapes through its work. - [Developer Relations is more than marketing. It's co-creation.](https://chrisreddington.com/blog/devrel-value-co-creation-not-marketing/): Developer Relations is sometimes equated to marketing. Incorporating insights from 13 interviews, I explain why DevRel is better understood as value co-creation. - [How does Developer Relations (DevRel) create value? What 13 interviews revealed.](https://chrisreddington.com/blog/devrel-value-creation/): The question of how Developer Relations (DevRel) teams create value has been answered plenty of times (though rarely through systematic research). In 2024 I looked into it properly through 13 interviews with DevRel leaders, culminating in an MBA dissertation at Warwick Business School, unearthing a couple of surprises along the way. This series works through what I found. - [Context windows, Plan agent, and TDD: What I learned building a countdown app with GitHub Copilot](): Learn how I managed context to keep Copilot focused, used the Plan agent to sharpen vague requirements, and required Test Driven Development practices to catch bugs before users. - [Adding Bluesky Comments to My Hugo Site](https://chrisreddington.com/blog/bluesky-comments-integration/): I've been exploring ways to bring social engagement into my blog posts. Taking inspiration from Ashley Willis' implementation, I've integrated Bluesky comments and likes into my Hugo site using the AT Protocol's public API. - [Building smarter interactions with MCP elicitation: From clunky tool calls to seamless user experiences](): Explore how MCP elicitation transforms AI tool interactions by gathering missing information upfront. - [Building your first MCP server: How to extend AI tools with custom capabilities](): Learn Model Context Protocol by building a turn-based game server that shows how to extend GitHub Copilot with custom tools, resources, and prompts. - [Debugging UI with AI: GitHub Copilot agent mode meets MCP servers](): Explore how I use agentic tools like GitHub Copilot agent mode and the Playwright MCP server to accelerate troubleshooting and debugging of UI issues, while revisiting the importance of clear requirements. - [From chaos to clarity: Using GitHub Copilot agents to improve developer workflows](): Explore how you can set Copilot coding agent up for success with custom instruction and Copilot setup steps. - [From idea to PR: A guide to GitHub Copilot’s agentic workflows](): A practical guide to GitHub Copilot’s agentic coding agent, chat modes, and remote MCP server so you turn issues into tested PRs with clear steps (and no hype). ## Optional - [Full content index](https://chrisreddington.com/llms-full.txt): Complete listing of all content with descriptions - [RSS Feed](https://chrisreddington.com/index.xml): Subscribe to updates - [Sitemap](https://chrisreddington.com/sitemap.xml): Full site structure ## AI Usage Policy Content on this site is available for AI agents to read, summarise, and cite with attribution. Please link back to the original URL when referencing content.