AI
-
The Broken Promise of Reach
AI is changing things we take for granted:
the relationship between effort and reach.For years, the implicit promise of the internet was straightforward.
Put in the work, create something valuable, and you’d find your audience. Maybe not millions, but someone.
The effort you invested had a reasonable correlation to the impact you could achieve. A thoughtful blog post might get shared.
A well-crafted tutorial could help thousands of developers. The work mattered because it reached people who needed it.
That equation is no longer guaranteed.
Now we’re in a world where AI can generate endless content at near-zero cost.
The supply of words, images, and ideas has become functionally infinite.
So, what happens to the value of any individual piece?
- Your carefully researched article drowns in a database of a thousand AI-generated summaries.
- Your authentic ideas are lost in a sea of algorithmic content designed for engagement.
So, why put in the work if the reward isn’t there?
The dream used to be building something sustainable or something big enough to matter. Enough to support yourself while doing work you care about. And it still can be, that, a dream.
We need to return to the act of finding value in the act itself
Don’t let your self-worth depend on metrics decided by a platform.
Your entire creative output shouldn’t be measured in likes, shares, and subscriber counts. That’s when they win.
We can’t hand over the definition of “success” to the algorithms
The old promise of platforms will provide is broken.
We’re not going back.
Now we need to build something new.
What we build is up to us.
-
First Impressions of OpenAI's Codex App
I’ve been experimenting with OpenAI’s new Codex app for engineering work that launched on February 2nd, and I’m not impressed.
No subagents from what I can tell. It gets stuck on stuff that shouldn’t be blockers. The gpt-5.2-codex model feels slow. I don’t care about the existing skills enough to try to set one up for it.
I did sign up for a free month trial of ChatGPT Plus though, so I’m going to give it a few more attempts before my time runs out. But so far, it doesn’t feel like a force multiplier the way Claude Code or Amp Code does. Even Open Code feels more productive.
Maybe I’ll have better luck with Codex on the CLI? We’ll see.
There’s something about flat-fee billing that feels so much better than watching tokens drain away. Less constrained and more open to trying new things I guess.
I appreciate that they went through the effort of building what looks like a native Swift app instead of yet another VS Code fork.
I think Codex desktop app is aimed at competing with Cursor’s market share, or maybe it’s some attempt at solving whatever direction Claude Desktop is heading.
It doesn’t feel like it’s solving my problems as a developer who already has workflows that I know work.
Back to the CLI pour moi.
-
Why IndiePub Matters More Than Ever
You might have heard the term IndiePub. It’s short for independent publishing—the practice of creating and distributing your work (books, stories, games, articles) without the financial backing or editorial control of a larger corporation.
It’s closely related to the IndieWeb movement in software development, which has been advocating for personal ownership of digital presence for years.
In the last two decades, we’ve watched massive platforms rise to dominance. They promised reach and convenience, and they delivered—for a while. But now we’re seeing the consequences: algorithmic timelines that bury your work, arbitrary policy changes that can wipe out years of audience building, and the degradation of platform quality as engagement-farming content floods every feed.
This platform decay is exactly why anyone publishing content on the internet should own their own distribution.
I’m not saying you have to stop publishing on platforms. But you shouldn’t publish there first.
Publish your work on something you control, your own site, your own domain, and then push it out to the platforms. Your home base stays yours. The platforms get a copy.
The AI Content Flood Changes Everything
Now we’re facing something new, with the rise of AI-generated content, these platforms are becoming saturated with noise. Human authenticity is at a premium.
The irony? Human authentic content is what trained these large language models in the first place.
So there’s a reclaiming happening here. We’re taking our data back.
Our authentic human content belongs on the platforms we control. The AI stuff can continue flowing through the corporate channels.
It’s Never Been Easier
I’m not going to dive deep into the complexities of book publishing or all the decisions writers face when navigating traditional vs. self-publishing. But I will say this: it’s never been easier to find a way to publish your thoughts and ideas online.
There are definitely some better decisions you can make about where and how to publish. If you’re wondering whether you’ve made the best choice for the type of content you want to put out there, I created a guided decision-making tool to help answer those questions: blog-picker.logan.center
IndiePub matters now more than ever because it’s our primary defense against the commoditization of creativity.
When everything becomes content for platforms, when algorithms decide what gets seen, when AI can generate infinite variations of “good enough” content.
Own your words. Own your distribution. The platforms are guests at your table, not the other way around.
-
Why Data Modeling Matters When Building with AI
If you’ve started building software recently, especially if you’re leaning heavily on AI tools to help you code—here’s something that might not be obvious: data modeling matters more now than ever.
AI is remarkably good at getting the local stuff right. Functions work. Logic flows. Tests pass. But when it comes to understanding the global architecture of your application? That’s where things get shaky.
Without a clear data model guiding the process, you’re essentially letting the AI do whatever it thinks is best. And what the AI thinks is best isn’t always what’s best for your codebase six months from now.
The Flag Problem
When you don’t nail down your data structure upfront, AI tools tend to reach for flags to represent state. You end up with columns like
is_draft,is_published,is_deleted, all stored as separate boolean fields.This seems fine at first. But add a few more flags, and suddenly you’ve got rows where
is_draft = trueANDis_published = trueANDis_deleted = true.That’s an impossible state. Your code can’t handle it because it shouldn’t exist.
Instead of multiple flags, use an enum:
status: draft | published | deleted. One field. Clear states. No contradictions.This is just one example of why data modeling early can save you from drowning in technical debt later.
Representation, Storage, and Retrieval
If data modeling is about the shape of your data, data structures determine how efficiently you represent, store, and retrieve it.
This matters because once you’ve got a lot of data, migrating from one structure to another, or switching database engines—becomes genuinely painful.
When you’re designing a system, think about its lifetime.
- How much data will you store monthly? Yearly?
- How often do you need to retrieve it?
- Does recent data need to be prioritized over historical data?
- Will you use caches or queues for intermediate storage?
Where AI Takes Shortcuts
AI agents inherit our bad habits. Lists and arrays are everywhere in their training data, so they default to using them even when a set, hash map, or dictionary would perform dramatically better.
In TypeScript, I see another pattern constantly: when the AI hits type errors, it makes everything optional.
Problem solved, right? Except now your code is riddled with null checks and edge cases that shouldn’t exist.
Then there’s the object-oriented problems. When building software that should use proper OOP patterns, AI often takes shortcuts in how it represents data. Those shortcuts feel fine in the moment but create maintenance nightmares down the road.
The Prop Drilling Epidemic
LLM providers have optimized their agents to be nimble, managing context windows so they can stay productive. That’s a good thing. But that nimbleness means the agents don’t always understand the full structure of your code.
In TypeScript projects, this leads to prop drilling: passing the entire global application object down through nested components.
Everything becomes tightly coupled. When you need to change the structure of an object, it’s like dropping a pebble in a pond. The ripples spread everywhere.
You change one thing, and suddenly you’re fixing a hundred other places that all expected the old structure.
The Takeaway
If you’re building with AI, invest time in data modeling before you start coding. Define your data structures. Think about how your data will grow and how you’ll access it.
The AI can help you build fast. But you still need to provide the architectural vision. That’s not something you can blindly trust the AI to handle, not yet, anyway.
-
2026: The Year We Stop Blaming the Tools
Here’s a hard truth we’re going to have to face in 2026: sometimes the bottleneck isn’t the technology, it’s us.
I’ve been thinking about how we use tools, how we find the merit in their use. We have access to increasingly powerful tools, but their value depends entirely on our understanding of them.
A hammer is useless if you don’t know which end to hold. The same goes for AI assistants, automation frameworks, and the growing ecosystem of agentic systems.
The rapid adoption of tools like OpenClaw’s agentic assistant tells me something important: people and companies are starting to see the real potential in building autonomous systems. Not just as toys or experiments, but as genuine productivity multipliers. That’s a shift from where we were even a year ago.
I think 2026 will be the year we see more widespread adoption of genuinely useful tools. The Gartner hype cycle is really interesting and how it applies or doesn’t to AI adoption, but I won’t cover it here. I’d like to write more about that in future articles.
The companies that build genuinely useful tools will be the ones that survive. They’ll be the ones that understand the value of tools and how to use them effectively. They’ll be the ones that embrace the future of work, where humans and machines work together to achieve more.
It’s not about replacing humans. It’s about humans getting better at wielding the tools we’ve built. That’s always been how technology works. This time is no different.
-
The Rise of Spec-Driven Development: A Guide to Building with AI
Spec-driven development isn’t new. It has its own Wikipedia page and has been around longer than you might realize.
With the explosion of AI coding assistants, this approach has found new life and we now have a growing ecosystem of tools to support it.
The core idea is simple: instead of telling an AI “hey, build me a thing that does the boops and the beeps” then hoping it reads your mind, you front-load the thinking.
It’s kinda obvious, with it being in the name, but in case you are wondering, here is how it works.
The Spec-Driven Workflow
Here’s how it typically works:
-
Specify: Start with requirements. What do you want? How should it behave? What are the constraints?
-
Plan: Map out the technical approach. What’s the architecture? What “stack” will you use?
-
Task: Break the plan into atomic, actionable pieces. Create a dependency tree—this must happen before that. Define the order of operations. This is often done by the tool.
-
Implement: You work with whatever tool to build the software from your task list. The human is (or should be) responsible for deciding when a task is completed.
You are still a part of the process. It’s up to you to make the decisions at the beginning. It’s up to you to define the approach. And it’s up to you to decide you’re done.
So how do you get started?
The Tool Landscape
The problem we have now is there is not a unified standard. The tool makers are busy building the moats to take time to agree.
Standalone Frameworks:
-
Spec-Kit - GitHub’s own toolkit that makes “specifications executable.” It supports multiple AI agents through slash commands and emphasizes intent-driven development.
-
BMAD Method - Positions AI agents as “expert collaborators” rather than autonomous workers. Includes 21+ specialized agents for different roles like product management and architecture.
-
GSD (Get Shit Done) - A lightweight system that solves “context rot” by giving each task a fresh context window. Designed for Claude Code and similar tools.
-
OpenSpec - Adds a spec layer where humans and AI agree on requirements before coding. Each feature gets its own folder with proposals, specs, designs, and task lists.
-
Autospec - A CLI tool that outputs YAML instead of markdown, enabling programmatic validation between stages. Claims up to 80% reduction in API costs through session isolation.
Built Into Your IDE:
The major AI coding tools have adopted this pattern too:
- Kiro - Amazon’s new IDE with native spec support
- Cursor - Has a dedicated plan mode
- Claude Code - Plan mode for safe code analysis
- VSCode Copilot - Chat planning features
- OpenCode - Multiple modes including planning
- JetBrains Junie - JetBrains’ AI assistant
- Google Antigravity - Implementation planning docs
- Gemini Conductor - Orchestration for Gemini CLI
Memory Tools
- Beads - Use it to manage your tasks. Works very well with your Agents in Claude Code.
Why This Matters
When first getting started building with AI, you might dive right in and be like “go build thing”. You keep then just iterating on a task until it falls apart once you try to do anything substantial.
You end up playing a game of whack-a-mole, where you fix one thing and you break another. This probably sounds familiar to a lot of you from the olden times of 2 years ago when us puny humans did all the work. The point being, even the robots make mistakes.
Another thing that you come to realize is it’s not a mind reader. It’s a prediction engine. So be predictable.
What did we learn? With spec-driven development, you’re in charge. You are the architect. You decide. The AI just handles the details, the execution, but the AI needs structure, and so these are the method(s) to how we provide it.
-
-
Tessl - Agent Enablement Platform
Tessl helps teams build AI-native software by giving coding agents structured, versioned context. Ship AI-powered systems that hold up in real codebases.
-
AMP Code: First Impressions of a Claude Code Competitor
I tried AMP Code last weekend and came away genuinely impressed. I didn’t think there was anything at Claude Code’s level currently available.
That said, AMP is in a somewhat unfortunate position. Similar to Cursor, they have to pay the Anthropic tax, and you really want your primary model to be Opus 4.5 for the best results.
So while I was able to get some things done, once you start paying per token… you feel constrained. I’m speaking from a personal budget perspective here, but I blew through ten dollars of credits on their free tier pretty easily.
I could see how with billing enabled and all the sub-agents they make super easy to use, you could burn through a hundred-dollar Claude Code Max plan budget in a week, or even a day, depending on your usage.
What I Really Like
There’s a lot to appreciate about what AMP is doing.
Team collaboration is a standout feature. It’s incredibly easy to share a discussion with other people on your team. Being able to collaborate with your team on something using agents is extremely powerful.
Their TUI is exceptional. I mean, it’s so much better than Claude Code’s terminal interface. They probably have the best TUI on the market right now. It’s definitely better than Open Code.
Sub-agents work out of the box. All the complicated sub-agent stuff I’ve set up manually for my Claude Code projects? It just comes ready to go with AMP. They’ve made really smart decisions about which agents handle which tasks and which models to use. You don’t have to configure any of it, it’s all done for you.
The Bottom Line
I think for enterprise use cases, AMP Code is going to make a lot of sense for a lot of companies.
For individual developers on a personal budget, the cost model is something to think carefully about.
-
Here’s a helpful idea on how to use Claude CoWork to update your photos EXIF data so they have descriptions.
-
Design engineering for Claude Code. Craft, memory, and enforcement for consistent UI. - Dammyjay93/interface-design