Merge pull request #8 from akashtalole/claude/add-claude-documentation-igODC

Add CLAUDE.md, 30-day blog plan, Days 1–5, and GitHub Pages config fixes

Author: akashtalole

_config.yml

@@ -130,7 +130,7 @@ pwa:
 # ---------------------------------------------------------------------------
 # Pagination & URLs
 # ---------------------------------------------------------------------------
-future: true     # Always render posts regardless of build-time vs. post date
+future: false    # Only publish posts whose date is on or before the build date
 paginate: 10
 
 # ---------------------------------------------------------------------------

_posts/2026-04-14-choosing-your-ai-toolchain-claude-code-copilot-or-copilot-studio.md

@@ -0,0 +1,130 @@
+---
+layout: post
+title: "Choosing Your AI Toolchain — Claude Code, Copilot, or Copilot Studio?"
+date: 2026-04-14
+categories: [ai, meta]
+tags: [claude-code, github-copilot, copilot-studio, agentic-ai, sdlc, coding-agents]
+description: "Claude Code, GitHub Copilot, and Microsoft Copilot Studio are not competitors. They solve different problems at different layers. Here's the mental model I use to decide which to reach for — and when to use all three."
+author: akashtalole
+---
+
+Every time I mention using multiple AI tools at work, someone asks the same question: "Which one should I actually use?"
+
+The framing is wrong. These tools aren't alternatives — they're layers. Choosing between them is like asking whether you should use an IDE, a CI pipeline, or a cloud platform. The answer is yes, for different things, at different times.
+
+But the layers aren't obvious until you've spent real time with all three. So let me break down how I actually think about this.
+
+---
+
+## The Three Tools and What They're Actually For
+
+### GitHub Copilot — Your In-Editor Coding Companion
+
+Copilot lives where you write code. It's inline, it's fast, and it's designed to keep you in flow. When you're writing a function and you know what you want but don't want to type all of it — that's Copilot. When you're in a file and want to ask a quick question about the code in front of you without switching context — that's Copilot Chat.
+
+The key characteristic: **it works with what's in your editor right now**. It sees your current file, your open tabs, your recent edits. Its context window is your immediate working surface.
+
+Best for:
+- Autocomplete and inline code generation as you type
+- Quick questions about the code you're looking at
+- Generating test stubs, docstrings, boilerplate
+- Small refactors within a file or a few files
+- Staying in flow without context-switching to a browser
+
+The limitation: it's shallow on depth. Copilot is excellent for the thing you're working on right now. It's not the right tool for "help me understand how this entire service fits together" or "let's redesign this module from scratch."
+
+### Claude Code — Your Deep Technical Collaborator
+
+Claude Code is a different kind of interaction. It's not inline — you have a conversation. You can give it complex multi-part problems, large amounts of context, and ask it to reason across multiple files and concerns at once.
+
+The key characteristic: **it works best when the problem requires sustained reasoning**. Understanding a legacy codebase, planning a refactor, working through a design decision, debugging something with multiple possible causes — these are Claude Code's home territory.
+
+Best for:
+- Exploring and understanding unfamiliar codebases
+- Complex multi-step coding tasks
+- Code review and analysis across multiple files
+- Architecture and design discussions
+- Long-running pair programming sessions where you want to build context over time
+- Enterprise security and compliance contexts where you need auditability
+
+The limitation: it's a deliberate conversation, not a background assistant. You have to context-switch to use it. For quick in-editor completions, it's slower than Copilot.
+
+### Microsoft Copilot Studio — Your Agent Builder
+
+Copilot Studio is different from both. You're not using it to write code — you're using it to build AI-powered products and workflows. It's a platform for creating agents that end users or enterprise systems interact with.
+
+The key characteristic: **it's for building, not using**. When I need an agent that handles customer queries, routes between specialist agents, connects to enterprise data sources, and triggers business workflows — that's a Copilot Studio project. The output is a deployed agent, not code I write.
+
+Best for:
+- Building conversational AI for end users
+- Creating multi-agent orchestration across enterprise systems
+- Connecting AI to line-of-business data (SharePoint, Dataverse, CRMs)
+- Low-code/pro-code hybrid agent development
+- Deploying agents into Microsoft 365 and Teams
+
+The limitation: it's a platform with its own opinions. If your use case doesn't fit Microsoft's ecosystem or you need deep custom logic, you'll hit the edges of what it does easily. It's powerful within its lane, less flexible outside it.
+
+---
+
+## How They Work Together
+
+Here's a real example from my current work to make this concrete.
+
+I'm building a multi-agent solution for enterprise customer support using Copilot Studio. The orchestrator agent routes queries to specialist agents — one for order management, one for account queries, one for escalation.
+
+Here's how all three tools show up in that project:
+
+**Claude Code** — I use it to design the agent architecture. When I'm deciding how to structure the handoff between agents, what context each agent needs, how to handle failure cases — I'm having that conversation in Claude Code. I also use it to understand existing API documentation and write the custom connector code.
+
+**GitHub Copilot** — When I'm writing the actual connector code or the Power Automate flows in VS Code, Copilot is handling the in-editor generation. The boilerplate, the JSON structures, the method signatures — Copilot completes those as I type.
+
+**Copilot Studio** — The agents themselves, the topics, the orchestration, the connections to enterprise data — that all lives in Copilot Studio. It's where the product gets built and deployed.
+
+Three tools, one project, no overlap in what each one does.
+
+---
+
+## The Decision Framework
+
+When I'm about to reach for an AI tool, I ask these questions:
+
+**1. Am I writing code right now in my editor?**
+→ Yes: Copilot
+
+**2. Do I need to reason deeply about a complex problem — design, architecture, understanding, review?**
+→ Yes: Claude Code
+
+**3. Am I building something an end user or enterprise system will interact with?**
+→ Yes: Copilot Studio
+
+**4. Is this a new kind of problem I haven't solved before?**
+→ Start with Claude Code to think it through, then move to Copilot for implementation
+
+**5. Do I need to connect AI to enterprise data and workflows without building everything from scratch?**
+→ Copilot Studio, augmented with Claude Code for the custom logic
+
+The short version: **Copilot for flow, Claude Code for depth, Copilot Studio for products.**
+
+---
+
+## The Mistake I See Most Often
+
+Engineers pick one tool and try to make it do everything.
+
+They use only Copilot and wonder why it can't help with complex architectural decisions. Or they use only Claude Code and find themselves context-switching for every small completion. Or they look at Copilot Studio and try to use it as a code editor.
+
+Each tool is well-designed for its layer. The skill is recognising which layer you're working at — and reaching for the right tool.
+
+That gets easier with practice. After a few weeks of using all three intentionally, the decision becomes automatic. You stop thinking about the tools and start thinking about the problem.
+
+---
+
+## Where This Series Goes From Here
+
+The next four weeks of posts go deep on each tool in turn. Arc 2 starts tomorrow with Claude Code — enterprise setup, real use cases, and what it takes to roll it out responsibly to a team.
+
+If you've only been using one of these tools, I'd encourage you to try the others with deliberate intent this week. Not to evaluate them against each other — to find the layer where each one fits naturally.
+
+---
+
+*Day 5 of the [30-Day AI Engineering series](/posts/30-day-ai-engineering-blog-plan/). Previous: [Agent Skills 101](/posts/agent-skills-101-building-blocks-of-useful-ai-agents/).*

_posts/2026-04-15-11-years-in-ai-augmented-how-my-workflow-actually-changed.md

@@ -0,0 +1,100 @@
+---
+layout: post
+title: "11 Years In, AI-Augmented — How My Workflow Actually Changed"
+date: 2026-04-15
+categories: [ai, meta]
+tags: [claude-code, github-copilot, sdlc, ai-in-sdlc, agentic-ai]
+description: "An honest before-and-after. Eleven years of engineering, eighteen months of AI tooling — here's what actually changed in how I plan, code, review, and ship. And what didn't."
+author: akashtalole
+---
+
+I want to close Arc 1 of this series with something personal: an honest account of what actually changed in my day-to-day work when I started using AI tools seriously. Not the marketing version. The real version — including the parts that didn't change as much as I expected.
+
+---
+
+## Before I Had These Tools
+
+Let me paint the picture accurately. Before I integrated AI tools into my workflow, I was already a reasonably efficient senior engineer. I had patterns that worked. I knew how to read a codebase, design a system, debug a hard problem. Eleven years of that builds real muscle memory.
+
+The friction wasn't incompetence — it was the unavoidable tax on certain kinds of work:
+
+- Understanding an unfamiliar codebase took days of reading, running, and dead ends
+- Writing documentation felt like paying a tax with no immediate return
+- The gap between "I have an idea" and "I have running code to validate it" involved a lot of typing I wasn't thinking about
+- Code review caught what reviewers had time to check, not everything that should be checked
+
+These weren't problems I was failing at. They were just the cost of doing the work.
+
+---
+
+## What Changed: The Honest Accounting
+
+### Planning and Exploration — Significantly Faster
+
+This is where I see the biggest delta. Before, when I picked up an unfamiliar piece of work — a new codebase, a new API, a problem domain I hadn't worked in — I'd spend a lot of time just orienting. Reading docs, running code, building a mental map.
+
+Now I use Claude Code as an interactive guide through that orienting phase. I paste in code, ask questions, test hypotheses. The process is still the same — read, run, understand — but the iteration speed is dramatically higher.
+
+What used to take a day often takes a morning. That compounds.
+
+### Writing Code — Incrementally Better, Not Transformatively
+
+This is where people expect the most change and often experience the most disappointment if they're already strong engineers.
+
+Copilot makes the typing faster. It's good at boilerplate, repetitive patterns, filling out function signatures I already know the shape of. For a senior engineer who types fast and knows what they want, the acceleration is real but not enormous.
+
+Where I feel it more is in unfamiliar territory — a language I use occasionally, a library I haven't worked with recently, a framework pattern I need to look up. The cost of those situations dropped significantly. I reach for documentation less and stay in the editor more.
+
+### Code Review — Meaningfully Better
+
+I now run AI pre-review on my own code before submitting PRs and on others' code before starting detailed review. It catches enough low-hanging fruit — inconsistent error handling, obvious edge cases, style issues, missing validations — that human review time is genuinely more focused.
+
+My PRs are tighter before they go up. Other people's PRs take less of my attention on the mechanical stuff so I can focus on the architecture and logic questions that actually need a human.
+
+### Documentation — The Biggest Relative Improvement
+
+I wrote documentation before. Not as much as I should have. The effort-to-reward ratio felt wrong and I'd often defer it.
+
+Now I write significantly more documentation than I did two years ago. Not because I suddenly care more — because the cost is low enough that I actually do it. Docstrings, ADRs, README sections, runbook entries — I draft them in seconds, edit them in minutes. The activation energy is gone.
+
+That's a bigger change than it sounds. Documentation debt is one of the most consistently painful things in software teams and it's almost entirely an incentive problem, not a knowledge problem.
+
+### Debugging — Mixed Results
+
+This is the one that surprised me. I expected AI to be a debugging superpower. It's more nuanced than that.
+
+For certain classes of bugs — logic errors with clear symptoms, type errors, missing null checks — Claude Code is excellent. Paste the error, paste the relevant code, get a likely cause.
+
+For the hard bugs — the ones that involve subtle interactions between distributed systems, race conditions, environment-specific behaviour, business logic that's wrong in a way that's hard to describe — AI is helpful as a thinking partner but rarely diagnoses the root cause directly. You still need to do the detective work.
+
+### Architecture and Design — Mostly Unchanged
+
+My process for designing systems is largely the same as it was before. AI is useful for quickly generating options and poking holes in reasoning, but the hard work of understanding tradeoffs in context — your team, your constraints, your existing system — is still human work.
+
+I use Claude Code to pressure-test ideas and generate alternatives I might not have considered. I don't use it to make the decisions.
+
+---
+
+## What Didn't Change
+
+**Judgment.** Knowing what the right problem is, whether a proposed solution is actually right for the context, what matters and what doesn't — none of that came from AI.
+
+**Understanding the business.** The context that lives in people's heads, in meetings, in three years of history — AI doesn't have it and can't substitute for building it.
+
+**The hard conversations.** Technical leadership, navigating disagreements, deciding what to build and what to cut — still entirely human.
+
+**Debugging the truly hard things.** Concurrency bugs, distributed system failures, environment mysteries — still detective work.
+
+---
+
+## The Honest Summary
+
+The AI tools I use daily have made me faster at a meaningful subset of my work. Not at all of it. The parts that got faster are real, and the compounding effect over months is significant.
+
+But the things that separate a good senior engineer from an average one — judgment, understanding, communication, system thinking — those are unchanged. If anything, they matter more now, because the baseline productivity has risen and the differentiator has shifted further toward the things AI doesn't do.
+
+That's the honest picture after eighteen months. Starting tomorrow, Arc 2 gets specific: Claude Code for enterprise teams.
+
+---
+
+*Day 6 of the [30-Day AI Engineering series](/posts/30-day-ai-engineering-blog-plan/). Previous: [Choosing Your AI Toolchain](/posts/choosing-your-ai-toolchain-claude-code-copilot-or-copilot-studio/).*