I wanted to see three things; what games an NWSL team has left, how a team has performed compared to another team, and a ranking of how hard a teams remaining fixture are. I find it useful to see how a team has done and I hope you do too!
So I put the two together and fed Claude Code this prompt:
Create an html page that shows the current NWSL standings and is used to show which teams that one team has played against. Needs to have clear indiciation for Home or Away game and the score for games that have been played. Ideally this would all be client side including loading of existing standings and fixtures or at least a way to catch up to current. Create an html page that shows the current NWSL standings and is used to show which teams that one team has played against. Needs to have clear indiciation for Home or Away game and the score for game that have been played. Ideally this would all be client side including loading of existing standings and fixtures or at least a way to catch up. This lines up with goal to make this shareable and open source.
More a stream of thoughts and ideas than a great prompt.
The first version that came back was a working page. A few tweaks and a follow up session for a difficulty rating and it was done. It is on Github Pages and the code on Github.
The speed of getting ideas out of heads and into something people can consume unlocks creativity. Show up with working proof of your ideas.
]]>Friday night, inspired by what others were building, I decided to take Fable for a spin — not yet knowing it had already been banned. Ten minutes with Fable 5 in the Claude desktop app produced a spec for a Cocktail Recipe app targeting Apple Foundation Models. Then I opened Claude Code in Terminal went to kick off the build and couldn’t find Fable. Logged out, logged back in. There it was. (That second login finally makes sense now.)
All that existed at that point was an implementation plan in a folder. I ran:
/goal Implement @IMPLEMENTATION_PLAN.md and follow Apple Human Interface Guidelines for iOS. End when app is tested and builds
Twenty-two minutes later: a working app.
Three thoughts on where we are headed:
One. As one-shot capabilities mature, the supporting files — standards docs, patterns, guidelines, security reqs — become the differentiator. This matters even more in enterprise contexts where consistency across teams is the whole game.
Two. “Tested and built” is not the same as “working.” All unit tests passed. The app compiled. It did not, however, produce a cocktail recipe. Acceptance criteria need to be airtight for one-shot to truly impress.
Three. Two distinct modes are crystallizing for tools like Claude Code and Codex: one-shot — full infrastructure, complete spec, output lands at UAT-ready — and exploratory, for rapidly converging on what you actually want to build. Both will reshape every role in the development process.
Saturday morning I woke up, read about the Fable ban, and now to finish the build the “old-fashioned” way: Opus and Sonnet.
]]>Great broad content covering all aspects of business, people, and technology needed to lead AI Transformation.
]]>I built Jordan — an AI architecture advisor that operates across 100+ repositories to help us do what we do best: understand systems and design integrations at scale. It is built with Claude Code and runs on Anthropic Claude Code.
The problem: 50 applications, 20 teams, knowledge fragmented everywhere. Simple questions like “How does System A actually talk to System B?” consume days.
Jordan deploys five specialized agents:
The insight: each agent compounds knowledge from the others. It’s cumulative intelligence that scales with every design cycle.
What sets this apart: it reads actual code, generates Mermaid diagrams, cites sources for verification, and grabs data via MCP. ✅
I’m after feedback from architects dealing with complex multi-system integrations:
The goal isn’t replacement — it’s augmentation. We’re not obsolete; we’re about to get superpowers. 🦸♂️
]]>I’ve built about 10 projects using with “vibe-coding”—implement an idea, test, iterate, repeat. They are fun but I’ve found over time become hard to work on due to the short-sighted nature of just creating features. This time I tried something different: I used Claude Code’s plan mode to generate an 11-phase implementation plan before writing a single line of code.
The difference was striking. Instead of wandering through possibilities, I reviewed the plan, made adjustments, then executed 3-5 steps per phase systematically. I deviated twice: adding message deletion and rolling back a feature I didn’t like (git commits made this trivial).
The takeaway: structured planning brings significantly more power than exploratory coding, and delivers a better foundation for expansion.
The implementation plan initially failed when calling Apple’s foundation models—it was based on OS version assumptions rather than device capabilities. I had Claude research the Apple developer docs, updated the plan with accurate context, and the next attempt worked immediately. With accurate context Claude came up with a better plan than making a best guess.
The better approach? Use an MCP server connected to live documentation during the planning phase. But the lesson stands: valid, relevant context yields better results. Just like humans, really :).
What can Apple Intelligence Foundation Models actually do? A couple things I found. They handle basic knowledge well (pre-dentist checklists, Japanese diet overviews), manage simple math (speed-distance calculations), and shine at creative tasks (haiku generation).
But I didn’t have a eureka moment about SLM applications beyond the obvious: lower latency, reduced cost, easier training.
If coding agents are the future, architecture needs to evolve. The context fed into planning mode becomes critical—yet most architecture lives in complex diagrams and dense documentation.
Consider: LLMs prefer text. Markdown, YAML, and CSV parse better than PDFs, JSON or diagrams/screenshots. Architecture diagrams might shift toward Mermaid—LLM-readable as text, renderable as visuals. Integration flows across 5, 10, or 15 systems could become flowcharts that LLMs parse easily and use less tokens.
We might see standardized markdown-based architecture documents, well-documented patterns optimized for LLM consumption, or—and this feels inevitable—architecture agents operating at the same caliber as Claude Code.
The tools are changing how we build.
]]>