How I Structure My Thinking in 2026: Learning New Things, Spec Driven Development for Responsible AI
My mode of learning is a mix of reading high-level documentation, thinking of some interesting problem to solve, and just getting my hands dirty. I’ve always been that way. I need to break something before I understand how it works. After this point is where I seek more structured forms of learning like courses, video walkthroughs and certifications.
I started experimenting with spec-driven development in winter 2025, spending weekends learning new things. Getting hands on using my personal Claude Code Max plan when Opus 4.5 dropped made me realize how much our craft may be evolving. It was exciting to feel the builder awaken in me again. GitHub published a great piece on spec-driven development with AI that resonated with where my head was at the time. A lot has changed since then. Markdown has become the de facto way to store context between coding sessions, and things are evolving fast. If you’re reading this months from now, some of what I reference may already look different, but the underlying patterns of how to structure your thinking for AI-assisted work, those I expect to hold up.
How We Learn Is Changing
All of this brought me back to something fundamental: how we learn. Structured plans, reading, video walkthroughs, trial and error. We all gravitate toward different modes. What’s new is this: the key to workflow automation using agentic AI is now using the same formal learning methods. You write your thoughts down, reason about what these AI collaborators actually produce, and guide them. Dan Koe’s piece on strategic thinking resonates here. Your ability to think across dimensions determines the outcome, and learning to think clearly is the actual skill being tested right now.
One workflow that clicked for me was Filip Kowalski’s approach: provide a feature spec, then have Claude interview you about implementation details and tradeoffs before writing a single line of code. The thinking happens first. The code follows. This pattern is now built into the tools themselves. Claude Code has a plan mode that enforces exactly this, restricting the agent to read-only exploration and clarifying questions until you approve a plan. The difference from traditional design documents is that the spec isn’t a gate. It’s a conversation with an agent that actually consumes it and acts on it in real time.
Where I’m Learning This
I found spec-driven development and skills from following practitioners sharing their workflows in real time on X. These often take weeks before they appear as polished blog articles. The learning loop has outpaced the teaching loop. By the time something makes it into a structured course or certification, the next thing has already landed.
I’ve been using a personal Claude Code plan for a while now. Anthropic’s January 2026 Complete Guide to Building Skills for Claude was a turning point in my opinion. I had started building my own skills using examples from their published repos, but that guide helped me refine them into something more structured. In late February, Thariq from the Claude Code team wrote “Seeing like an Agent” about building tools by asking what the model actually needs, not what a human would want. That shaped how I recently built my own harness. You are teaching the agent how you think about quality.
Structuring Thinking Before Structuring Code
The shift for me hasn’t been in the tools alone — it has also been in how I think before I even open them. Early on I noticed something when I was experimenting with side projects: the projects where I wrote down what I was trying to build, the goals, the non-goals, the constraints, those went well. The projects where I just started prompting and iterating turned into a mess I eventually rewrote or abandoned.
I’m realizing spec-driven development isn’t about generating better code. It’s about forcing myself to think clearly about what I actually want. The spec is a thinking tool to plan your work, the code that results from clear input has better outcomes. When I write “Non-Goals: This is not a production-grade platform” for something I was experimenting with, that’s not just a note for Claude. It’s a constraint I’m imposing on myself.
This is also where responsible AI use starts for me. When I give an AI agent unconstrained access to my codebase and just say “build me a feature,” I’m letting the agent decide what good looks like. The spec, the architecture doc, the guardrails: those are how I stay in the loop. I am still the architect. The agent is the builder. But the builder needs blueprints, and if I don’t provide them, it’ll improvise. Sometimes brilliantly, sometimes in ways that are hard to undo.
This applies beyond code too. I recently built a skill for reviewing blog posts before I publish them. I write my posts verbatim from my head, every word typed by me. After writing about The Builder’s Guilt earlier this year, that’s a vow I take seriously. But writing from your head means you’re also editing from your head, and that’s where things can go wrong: conflict of interest with my employer, phrasing that could be taken out of context, disclosures I should have included. Is it contradictory to write everything yourself but then have AI review it? I don’t think so. It’s the difference between having AI write for you and having AI watch your back. A spell checker doesn’t make the writing less yours. Neither does a reviewer that catches the things you’re too close to see.
I write my judgment as well as my taste into a reusable workflow once, and the agent applies it consistently every time. That layering of safety checks into everything I produce, while keeping the writing entirely human, is what feels genuinely new about working with AI.
Putting It Into Practice
Let me walk through what that looks like in practice. I’ve built skills for work and for side projects, but I’ll use the blog post reviewer as a simple, relatable example.
The Skill Definition as Your Spec
A Claude Code skill starts with a YAML frontmatter that describes when to trigger and what it does. Here’s the opening of mine:
---
name: blog-post-reviewer
description: >
Comprehensive blog post review for professionals publishing on
LinkedIn, personal blogs, or Medium. Use this skill whenever a
user asks you to review, vet, critique, or give feedback on a
blog post... Trigger on phrases like "review my blog post",
"check for conflicts of interest", "is this safe to publish",
...
---That description isn’t just documentation. It tells Claude when to activate the skill and what to expect from the conversation. Get the triggers right, and it shows up exactly when you need it.
Below the frontmatter, the skill walks through a five-step review workflow: gather context, check for conflicts of interest, assess public perception, evaluate writing quality, and deliver the findings. Each step has specific checklists. For conflict of interest, every issue gets classified as a hard blocker (must fix before publishing), a recommended change (should fix, but the post survives without it), or an awareness item (nothing wrong in the text, but something to watch for). I wrote these classifications once based on what I’d actually worry about if I were reviewing my own work. Now the agent applies them every time, without the “it’s probably fine” bias I’d have at 11pm on a Sunday.
I also baked in my professional context (employer, role, adjacency areas to watch) and sections for my writing voice, so the feedback is calibrated to how I actually write rather than generic advice.
The Compound Effect
None of these layers is revolutionary on its own. A skill definition is just a trigger. Professional context is a profile. The writing voice stuff is basically a style guide. But put together, they create something that feels different. It’s not that the AI becomes smarter. It’s that I’ve given it the right context to be effective. The agent operates within the context I would if I were reviewing my own work.
Every project teaches me something new about what to encode and what to leave flexible. If you are out there experimenting with these workflows, I’d love to hear how you are approaching it.
Where the Tools Are Converging
This pattern of encoding your thinking into structured files isn’t unique to Claude Code. The major AI coding tools are converging on a similar architectural pattern — instruction files, composable workflows, and extensibility layers — though the maturity and ergonomics differ significantly:
| Feature | Claude Code | Cursor | Codex CLI | Gemini CLI |
|---|---|---|---|---|
| Instructions file | CLAUDE.md | .cursor/rules/*.mdc | AGENTS.md | GEMINI.md |
| Custom workflows | Skills (SKILL.md) | Commands (.cursor/commands/) | Agent Skills (SKILL.md) | Agent Skills (SKILL.md) |
| Bundled distribution | Plugins | Plugins (Feb 2026) | — | Extensions |
| Structured thinking | Plan mode | Plan mode | Plan mode | Plan mode (experimental) |
The instruction file row is the most consistent — every tool has some version of “put a markdown file in your repo and the agent reads it.” Custom workflows vary more: Claude’s skills are the most formalized, Cursor’s commands are lighter-weight, and the Codex/Gemini abstractions are still evolving. Bundled distribution is where the models diverge most. Claude Code’s plugins package skills, agents, hooks, MCP servers, and LSP servers into a single installable unit. Cursor’s plugin marketplace launched in February 2026. Gemini leans on extensions. Codex CLI hasn’t emphasized bundled distribution in the same way yet. The pattern is the same across tools. But the fact that they are heading in the same direction tells you where this is going. If you’re investing time in learning how to structure your thinking for one of these tools, that skill transfers. The real learning is not in picking a tool. It’s in learning how to apply these concepts regardless of the tool.
The purple leaf plum tree in my backyard — cherry plum, if you want to get technical — went from bare branches to full bloom in about two weeks. That’s how this feels right now — a lot of growth happening fast, and I’m just trying to write it down before the next thing lands.
These are my personal thoughts and experiences from side projects and weekend experiments, and they do not reflect the views of my employer.