<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Best Practices on Corey Daley</title><link>https://coreydaley.dev/categories/best-practices/</link><description>Recent content in Best Practices on Corey Daley</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 27 Apr 2026 14:25:00 -0400</lastBuildDate><atom:link href="https://coreydaley.dev/categories/best-practices/rss.xml" rel="self" type="application/rss+xml"/><item><title>Catching Twilio SMS Locally: MessagePit Extends Mailpit</title><link>https://coreydaley.dev/posts/2026/04/messagepit-catching-twilio-sms-locally/</link><pubDate>Mon, 27 Apr 2026 14:25:00 -0400</pubDate><guid>https://coreydaley.dev/posts/2026/04/messagepit-catching-twilio-sms-locally/</guid><description>&lt;p&gt;Most teams have a tidy local story for email and a weird one for SMS. Mailpit catches every transactional email in dev — clean web UI, nothing leaks. For SMS, the usual options are stub the Twilio client, disable sends in dev entirely, or eat the cost of real messages during CI runs. None of those are good.&lt;/p&gt;
&lt;p&gt;MessagePit is a fork of Ralph Slooten&amp;rsquo;s Mailpit that closes the gap. It exposes a Twilio-compatible HTTP endpoint at the real &lt;code&gt;/2010-04-01/Accounts/{AccountSid}/Messages.json&lt;/code&gt; shape, validates &lt;code&gt;X-Twilio-Signature&lt;/code&gt; if you opt into it, and surfaces every captured SMS in the same web UI Mailpit ships for email. Point your Twilio SDK at &lt;code&gt;http://localhost:1775&lt;/code&gt; instead of &lt;code&gt;api.twilio.com&lt;/code&gt; and the rest of your code stays exactly the same.&lt;/p&gt;
&lt;p&gt;What other third-party integrations in your stack would get dramatically easier if you stopped mocking them and started catching them locally?&lt;/p&gt;
&lt;p&gt;Read more at &lt;a
 href="https://coreydaley.dev/posts/2026/04/messagepit-catching-twilio-sms-locally/" target="_blank" rel="noopener noreferrer"&gt;https://coreydaley.dev/posts/2026/04/messagepit-catching-twilio-sms-locally/&lt;/a&gt;
&lt;/p&gt;</description></item><item><title>Your HTML Is Lying to AI Agents</title><link>https://coreydaley.dev/posts/2026/04/your-html-is-lying-to-ai-agents/</link><pubDate>Sat, 25 Apr 2026 01:13:00 -0400</pubDate><guid>https://coreydaley.dev/posts/2026/04/your-html-is-lying-to-ai-agents/</guid><description>&lt;p&gt;Your site has two versions. The first is the rendered page: sidebar on the left, article on the right, everything in its place. The second is what machines read — the raw HTML, in source order, before CSS gets involved. On most personal blogs, that second version leads with navigation, tag clouds, and category lists before it reaches a word of the article. That&amp;rsquo;s the version every AI agent, crawler, and screen reader encounters first.&lt;/p&gt;
&lt;p&gt;This post argues that HTML is no longer just presentation scaffolding — it&amp;rsquo;s a machine-facing interface, and most of us are still designing it as if only browsers matter. The fix is three practical changes: reordering the DOM so content leads, generating llms.txt so agents can orient to your site, and publishing plain text versions of every post so there&amp;rsquo;s nothing to strip. None require a new framework. All take an afternoon.&lt;/p&gt;
&lt;p&gt;If an agent read your site top to bottom in raw HTML, what would it think matters most?&lt;/p&gt;
&lt;p&gt;Read more at &lt;a
 href="https://coreydaley.dev/posts/2026/04/your-html-is-lying-to-ai-agents/" target="_blank" rel="noopener noreferrer"&gt;https://coreydaley.dev/posts/2026/04/your-html-is-lying-to-ai-agents/&lt;/a&gt;
&lt;/p&gt;</description></item><item><title>Before the First Commit: What Multi-Agent Sprint Planning Actually Catches</title><link>https://coreydaley.dev/posts/2026/04/before-first-commit-what-multi-agent-sprint-planning-catches/</link><pubDate>Sat, 11 Apr 2026 18:05:00 -0400</pubDate><guid>https://coreydaley.dev/posts/2026/04/before-first-commit-what-multi-agent-sprint-planning-catches/</guid><description>&lt;p&gt;What does a multi-agent sprint planning workflow actually produce? Not just a cleaner document — it finds real bugs in a plan before implementation begins. When the /sprint-plan command ran against a &amp;ldquo;simple&amp;rdquo; Go REST API project, the security review phase returned three critical findings: a logical contradiction that made the stated auth behavior impossible, a schema constraint that would silently break token revocation, and a SQLite pragma applied to only one connection in a pool.&lt;/p&gt;
&lt;p&gt;The post walks through the entire planning session for org-api — from seed prompt to approved sprint document — showing what each phase of the review pipeline produced and what changed as a result. The security findings came from reading the plan carefully, not from running any code. That&amp;rsquo;s the point.&lt;/p&gt;
&lt;p&gt;What step in your planning process is explicitly there to prove the plan wrong before implementation begins?&lt;/p&gt;
&lt;p&gt;Read more at &lt;a
 href="https://coreydaley.dev/posts/2026/04/before-first-commit-what-multi-agent-sprint-planning-catches/" target="_blank" rel="noopener noreferrer"&gt;https://coreydaley.dev/posts/2026/04/before-first-commit-what-multi-agent-sprint-planning-catches/&lt;/a&gt;
&lt;/p&gt;</description></item><item><title>Opening Polyphon: Trust Needs an Exit</title><link>https://coreydaley.dev/posts/2026/03/polyphon-is-now-open-source/</link><pubDate>Wed, 25 Mar 2026 00:22:00 -0400</pubDate><guid>https://coreydaley.dev/posts/2026/03/polyphon-is-now-open-source/</guid><description>&lt;p&gt;Polyphon is now open source under Apache 2.0. The reason isn&amp;rsquo;t community building or contributor recruitment — it&amp;rsquo;s simpler and more specific than that. When a tool sits in the middle of unfinished thinking, rough drafts, and sensitive code, &amp;ldquo;trust me&amp;rdquo; is not a good enough contract.&lt;/p&gt;
&lt;p&gt;Open source gives users two things that matter here: the ability to inspect the architecture and verify the privacy claims, and a real exit if the project ever changes direction or stops moving. Not everyone will read the source. But anyone can. And the fact that anyone can changes the character of the whole relationship.&lt;/p&gt;
&lt;p&gt;What should users be able to verify for themselves before they trust an AI tool with their unfinished work?&lt;/p&gt;
&lt;p&gt;Read more at &lt;a
 href="https://coreydaley.dev/posts/2026/03/polyphon-is-now-open-source/" target="_blank" rel="noopener noreferrer"&gt;https://coreydaley.dev/posts/2026/03/polyphon-is-now-open-source/&lt;/a&gt;
&lt;/p&gt;</description></item><item><title>Free Doesn't Mean Open: How AI Is Unbundling the Open Source Bargain</title><link>https://coreydaley.dev/posts/2026/03/is-open-source-dead-in-the-age-of-ai/</link><pubDate>Thu, 19 Mar 2026 14:15:00 -0400</pubDate><guid>https://coreydaley.dev/posts/2026/03/is-open-source-dead-in-the-age-of-ai/</guid><description>&lt;p&gt;Open source was never really about the license. It was about economics — no single developer could build everything alone, so you shared the source and let the community help carry the load. AI is making that trade less necessary.&lt;/p&gt;
&lt;p&gt;With Claude Code and Codex, a solo developer can now ship and maintain classes of software that once required a contributor community. A new model is taking shape: users file issues, maintainers decide what&amp;rsquo;s worth building, AI does the implementation. No PRs to review, no design debates in GitHub comments. Meanwhile, tools like Obsidian prove free software doesn&amp;rsquo;t require open source — and have for years. The question is no longer whether to open source, but which parts of the open source bargain still matter to you.&lt;/p&gt;
&lt;p&gt;But here&amp;rsquo;s the counterintuitive part: AI also makes some open source values more important, not less. When software can be shipped and abandoned faster than ever, forkability, auditability, and portability become user protections that matter more. The future isn&amp;rsquo;t open vs. closed — it&amp;rsquo;s deliberate vs. reflexive.&lt;/p&gt;
&lt;p&gt;Read more at &lt;a
 href="https://coreydaley.dev/posts/2026/03/is-open-source-dead-in-the-age-of-ai/" target="_blank" rel="noopener noreferrer"&gt;https://coreydaley.dev/posts/2026/03/is-open-source-dead-in-the-age-of-ai/&lt;/a&gt;
&lt;/p&gt;</description></item><item><title>The Rise of the Agent Wrangler</title><link>https://coreydaley.dev/posts/2026/03/the-rise-of-the-agent-wrangler/</link><pubDate>Tue, 10 Mar 2026 11:55:00 -0400</pubDate><guid>https://coreydaley.dev/posts/2026/03/the-rise-of-the-agent-wrangler/</guid><description>&lt;p&gt;People keep asking if AI is going to replace software engineers. Better question: who can still be trusted to ship production software when most implementation is delegated to agents? That role is the Agent Wrangler — and it isn&amp;rsquo;t a step down from engineering, it&amp;rsquo;s a different kind of engineering.&lt;/p&gt;
&lt;p&gt;You spend your day directing Claude Code, Codex, and similar tools through feature work, bug hunts, security audits, and codebase exploration. The job sounds easier than traditional engineering. It isn&amp;rsquo;t — at least not for the people who do it well. Because when you&amp;rsquo;re orchestrating agents, your technical depth is the control surface. CS fundamentals don&amp;rsquo;t disappear; they become the language you use to catch when an agent is wrong.&lt;/p&gt;
&lt;p&gt;Software engineers aren&amp;rsquo;t going away. They need to adapt — like they always have. Maybe the real new title is &amp;lsquo;Adaptability Engineer.&amp;rsquo; Are you ready to stop coding and start wrangling?&lt;/p&gt;
&lt;p&gt;Read more at &lt;a
 href="https://coreydaley.dev/posts/2026/03/the-rise-of-the-agent-wrangler/" target="_blank" rel="noopener noreferrer"&gt;https://coreydaley.dev/posts/2026/03/the-rise-of-the-agent-wrangler/&lt;/a&gt;
&lt;/p&gt;</description></item><item><title>Seeing How the Sausage Gets Made: Demystifying AI and LLMs</title><link>https://coreydaley.dev/posts/2026/02/how-llms-work-sausage-making/</link><pubDate>Fri, 20 Feb 2026 09:00:00 -0500</pubDate><guid>https://coreydaley.dev/posts/2026/02/how-llms-work-sausage-making/</guid><description>&lt;p&gt;There&amp;rsquo;s a moment every developer eventually hits when they stop treating AI as a magic oracle and start asking: okay, but how does it actually work? It&amp;rsquo;s the technology equivalent of learning Santa isn&amp;rsquo;t real. A little wonder leaves the room, but something better moves in: understanding.&lt;/p&gt;
&lt;p&gt;And understanding turns out to be a surprisingly effective antidote to the kind of fear that has people picturing Skynet every time a chatbot gives a confident answer. So let&amp;rsquo;s look inside the machine — and maybe, along the way, inside ourselves.&lt;/p&gt;
&lt;p&gt;What do you think when you finally see how the sausage gets made?&lt;/p&gt;
&lt;p&gt;Read more at &lt;a
 href="https://coreydaley.dev/posts/2026/02/how-llms-work-sausage-making/" target="_blank" rel="noopener noreferrer"&gt;https://coreydaley.dev/posts/2026/02/how-llms-work-sausage-making/&lt;/a&gt;
&lt;/p&gt;</description></item><item><title>How I Used Claude Code to Make My Blog Accessible in Minutes</title><link>https://coreydaley.dev/posts/2026/02/using-claude-code-to-improve-blog-accessibility/</link><pubDate>Wed, 18 Feb 2026 23:03:58 -0500</pubDate><guid>https://coreydaley.dev/posts/2026/02/using-claude-code-to-improve-blog-accessibility/</guid><description>&lt;p&gt;Accessibility often gets pushed to the backlog — it feels complex, time-consuming, and hard to test without specialized knowledge. But I recently discovered just how approachable it can be with the right AI tool.&lt;/p&gt;
&lt;p&gt;I asked Claude Code to audit my Hugo blog for screen reader compatibility with a single prompt. Within seconds it had explored 13 template files, identified issues across 5 priority levels, and produced a comprehensive report. Then I asked it to fix everything — and it did, touching 13 files in one focused session.&lt;/p&gt;
&lt;p&gt;Whether you run a personal blog or a commercial platform, there is no excuse not to make your site accessible when tools like Claude Code can do the heavy lifting. What accessibility improvements have you been putting off that you could tackle today with an AI coding assistant?&lt;/p&gt;
&lt;p&gt;Read more at &lt;a
 href="https://coreydaley.dev/posts/2026/02/using-claude-code-to-improve-blog-accessibility/" target="_blank" rel="noopener noreferrer"&gt;https://coreydaley.dev/posts/2026/02/using-claude-code-to-improve-blog-accessibility/&lt;/a&gt;
&lt;/p&gt;</description></item><item><title>The Ethics of AI-Generated Code in Open Source: A Balanced Perspective</title><link>https://coreydaley.dev/posts/2026/02/ethics-of-ai-generated-code-in-open-source/</link><pubDate>Fri, 13 Feb 2026 11:57:51 -0500</pubDate><guid>https://coreydaley.dev/posts/2026/02/ethics-of-ai-generated-code-in-open-source/</guid><description>&lt;p&gt;Here&amp;rsquo;s a question that&amp;rsquo;s been keeping me up at night: When does using AI coding assistants cross the line from productivity tool to ethical problem? I&amp;rsquo;ve been using tools like GitHub Copilot and Claude Code extensively, and I started wondering—if someone submits AI-generated code to open source projects and builds their reputation on it, is that fundamentally different from using Stack Overflow or IDE autocomplete?&lt;/p&gt;
&lt;p&gt;In my latest blog post, I explore both sides of this debate. On one hand, AI democratizes contributions and amplifies what we can accomplish. On the other, it raises serious questions about authenticity, trust, and what it means to truly &amp;lsquo;know&amp;rsquo; the code you&amp;rsquo;re responsible for. The middle ground is messy and context-dependent.&lt;/p&gt;
&lt;p&gt;Where do you draw the line? Should contributors be required to disclose AI usage? What do you think?&lt;/p&gt;
&lt;p&gt;Read more at &lt;a
 href="https://coreydaley.dev/posts/2026/02/ethics-of-ai-generated-code-in-open-source/" target="_blank" rel="noopener noreferrer"&gt;https://coreydaley.dev/posts/2026/02/ethics-of-ai-generated-code-in-open-source/&lt;/a&gt;
&lt;/p&gt;</description></item><item><title>A Search UI That Feels Native: Pagefind + Custom JSON Rendering</title><link>https://coreydaley.dev/posts/2026/02/pagefind-custom-search-ui/</link><pubDate>Sun, 08 Feb 2026 19:19:33 -0500</pubDate><guid>https://coreydaley.dev/posts/2026/02/pagefind-custom-search-ui/</guid><description>&lt;p&gt;The default Pagefind UI is great for quick setup, but what if you want search results that feel like they belong to your site? That&amp;rsquo;s exactly what I built for this blog. Instead of using Pagefind&amp;rsquo;s default UI with its own markup and styles, I tapped directly into the Pagefind API to pull JSON results and render them using the same post card structure used throughout the theme.&lt;/p&gt;
&lt;p&gt;The result? Search that feels completely native—same date formats, same taxonomy chips, same layout consistency. This post walks through the technical approach: loading Pagefind as a module, querying for results, and building custom rendering logic.&lt;/p&gt;
&lt;p&gt;If you&amp;rsquo;re building with Hugo or any static site generator and want full control over your search UI, this approach might inspire you. How are you handling search on your static sites?&lt;/p&gt;
&lt;p&gt;Read more at &lt;a
 href="https://coreydaley.dev/posts/2026/02/pagefind-custom-search-ui/" target="_blank" rel="noopener noreferrer"&gt;https://coreydaley.dev/posts/2026/02/pagefind-custom-search-ui/&lt;/a&gt;
&lt;/p&gt;</description></item><item><title>The Art of Iterative Cycles with AI: Why Your First Prompt is Never Your Best</title><link>https://coreydaley.dev/posts/2026/02/iterative-cycles-with-ai/</link><pubDate>Wed, 04 Feb 2026 19:50:00 -0500</pubDate><guid>https://coreydaley.dev/posts/2026/02/iterative-cycles-with-ai/</guid><description>&lt;p&gt;Here&amp;rsquo;s something I&amp;rsquo;ve learned about AI coding assistants: the first response is rarely perfect—and that&amp;rsquo;s actually a good thing. When I started using GitHub Copilot and Claude, I expected instant perfect code. Reality? AI interprets your instructions based on patterns and context, so the first attempt is often close but not quite right.&lt;/p&gt;
&lt;p&gt;The key is treating AI like a junior developer: start with clear instructions, review the result, provide feedback, and iterate. Each cycle gets closer to what you need. This isn&amp;rsquo;t a limitation—it&amp;rsquo;s how effective collaboration works.&lt;/p&gt;
&lt;p&gt;The developers who succeed with AI aren&amp;rsquo;t the ones with perfect prompts; they&amp;rsquo;re the ones who embrace refinement. Have you experienced this iterative dance with AI tools? How many rounds does it usually take you to get the result you want?&lt;/p&gt;
&lt;p&gt;Read more at &lt;a
 href="https://coreydaley.dev/posts/2026/02/iterative-cycles-with-ai/" target="_blank" rel="noopener noreferrer"&gt;https://coreydaley.dev/posts/2026/02/iterative-cycles-with-ai/&lt;/a&gt;
&lt;/p&gt;</description></item></channel></rss>