Ah, the joy of building. Lately, my kids have acquired the bug. Now that they are a bit older, they’ve started to somewhat realize what I’m doing all day long, hunched over a brightly lit laptop — pecking away on a keyboard.

Click clack, clack clack, click click….boom, I made something. An app appears, and now they are at the age where they can comprehend that. And, well, they think that is amazing.

And thus, I’ve started to dip into the realm of kids and vibe coding. At first, I had an outline with something to say on this topic. But, you know what, I just threw it out. Both of my oldest kiddos, Benny (12) and Remy (9), have asked me to help them “make an app”, and we’ve had a blast.

What follows are just random observations in no particular order.

They have no idea what they’re doing

What even is an app to a kid? To them, anything entirely web-based for the whole experience is not an app (I raised them right!), and they were even surprised you could charge money on the web!

But, we all start somewhere. And, to that end, they’ve both taken completely different approaches to deciding where they should start. Remy, ever the analytical thinker among my kids, opted to spec it out. Benny? Two sheets to the wind, he just opened up Codex and let it rip. Which leads me to my first observation…

The prompts are just brutal

…and it’s somewhat endearing at the same time. Seeing Remy hunched over the keyboard, pecking away on one hand:

…just tossing Codex the most open-ended instructions imaginable:

So many questions! What kind of app? Which platform? FIVE BUCKS? We using StoreKit for this, what about paywalls? The seasoned engineer in me reeled, but I wanted them to hit as many bumps and learn how to work around them as they could. Even then, though, they do get “Dad Assists” here and there. And, Remy used his to kickstart his project:

In this case, I mentioned he might want to say what kind of app it is, punt the money stuff for now, and hint to the LLM which general direction we’re taking things (iOS, minimum target is likely iOS 26).

Writing prompt cleanups have been fantastic learning and bonding moments. We get to briefly talk about why I wrote something the way I did, I try to gently explain how an LLM works, what they’re good at, what they’re not as good at, etc.

To that end, their prompts have improved. But even then…

Ohhhh my, the UX

…these apps are brutal right now. Remy’s has, like, three search functions - all doing different things. I mean, check this number out:

It’s easy for us to spot the issues. However, the bit that’s surprised me, though, is that they are…aware of it? Even as a 9 year old. Is this a potential byproduct of growing up in the digital age? They know it doesn’t feel right, and they can’t really say why yet, they just know it feels off.

That’s hardly surprising, as design and user experience are things that take years and years to develop.

Their imagination is on steroids

The fact that they now live in a world where they can type in a box and get something working has, quite literally, ignited their creativity, curiosity, and excitement. The boys are huge fans of neal.fun, especially his fantastic auction game:

Remy, unshackled with unimaginable power at his disposal, immediately u-turned on a bug fix and just threw that at Codex and instructed it to add a Pokemon card version in his app. And, it came pretty close one-shotting it:

This is the good stuff. Being able to think of something fun and have it come to life. It’s the same dopamine hit you get from building with legos, finishing a picture, or generally constructing a thought and turning it into something tangible. While it’s silly in this context, these are the moments that will inspire them to continue.

The skills still pay

The one ephiphany I’ve had with all of this (aside from how insane it is that my kids can get a functioning app working) is that the skills we have are magnified now, perhaps more than ever. We’ve all been so uneasy about the implication of “anyone can make an app”, we haven’t stopped much to consider that our hard-earned skills are still the thing that makes a good app.

You can throw all the skill files you want at an LLM (And you should! They’re great!), but they still have critical limitations. Take text, for example. What would you instinctively do if you have a view whose text was truncated, clipping, or otherwise not fitting into a container?

The layman would say, “Can you make this text not clip?” The hardened iOS veteran might say, “Apply a .minimumScaleFactor modifier to this text, and ensure you’re using a Text style and not hard coding the font size.”

Off the cuff? Visually, you may get the same result at first. But, well — if you know, you know. One is objectively better. And those of us who can speak the language will still be making the best apps. The same skills still win, as I mentioned before, the tools have simply changed. It does, however, highlight my one lingering worry: That the next generation my take an ignorance through obstinance stance towards coding. If the ease of it all could tempt a kid (or anyone) to never bother learning how something truly works, they’d be missing out on some required skills.

The sweet spot

While the kids have been using Codex, I think I’d opt to stick them in Bitrig’s nascent mac app. It’s a bit more harnessed, in a good way, and I think the results would be a little better. The app Anything spun something up quick, in Expo. With Codex, I have a ton of credits, so we’ve stuck with that. Personally? I prefer Codex for coding anyways, especially since they put a frontend on top of the CLI. If it becomes a native mac app, I’ll probably never close it.

But for them? I can’t stop thinking about how a Macbook Neo with Bitrig would be a fun addition to the Morgan family. You kinda sorta need to make sure these kids don’t blow up your house with this stuff, which, well, depending on your permissions — could certainly happen.

Wrapping up

Reflecting on the vibe coding experiences with the kids, I only have one prevailing thought: we are all having so much fun. The kids are becoming increasingly interested in what their dad actually does for a career now. Remy, especially, is getting into it. He’s developed the ineluctable urge to make something. The last two days he has come home from school, it’s “Dad, can I work on my app!?” He even stuck some post-it notes to his closet so he wouldn’t forget what to work on the next day:

Until next time ✌️

When I first began my degree in the field of CompSci, I picked up a book: “Code”, by Charles Petzold. I don’t distinctly remember if it necessarily changed my life or sparked my love of software development. But, I remember with certainty that it did give me the gift of curiosity.

What was actually happening when I was typing in Visual Basic on some Windows desktop in a computer lab at Ozarks Technical Community College? How did the characters transform and…just…do stuff? I wanted to know, and that book went in on it all. I remember learning about how every computer begins with simple, basic physical states: on and off. Open, and closed. And, of course, 1 or 0.

From there, those binary states can be represented by all sorts of interesting modes: switches, relays, and then transistors. Building on that some more, wire enough of them together and now we get to the interesting stuff. Logic gates, adders, memory, clocks, and eventually down the line — a CPU that can read instructions from memory! And, execute them!

But in my day to day? That’s all abstracted away from me, as it should be. It’s just as well, though, since abstractions have long been a core part of our indsutry. In fact, who remembers interviews in the aughts when object orientated programming was king? We had to remember our favorite acronym, A.P.I.E. — abstraction, polymorphism, inheritance, and encapsulation. So, in that sense, code has long been an abstraction layer. It’s one that sits comfortably above the raw hardware, but it’s close enough that, after enough of said translation, it can still make silicon do something real and tangible in the world.

I’ve been thinking a lot about abstraction layers lately.

What the “abstraction” layer is now, and how we define it, is changing. And, naturally, it has me wondering. With the rise of agentic engineering, I’ve started to consider something I thought impossible only a few years ago:

Is code going to be abstracted away, entirely, soon?

And, yeah, I realize the word “soon” is doing some heavy lifting here.

Once the frontier models improve, how soon until it matters if you read what it outputs? No, seriously, I’m wondering that lately. I know, I know — I KNOW — it’s not there yet. Today. But, I think eventually, it will be. And what does that mean for software engineering? Is it then prompt engineering? Will knowing how the all the pieces fit together matter even more, or less?

How much longer is understanding code a competitive advantage? I know it certainly is today. And, lest I’m not making my stance clear enough, you do need to understand code to succeed in my opinion. In 2026, most of us in this field grew up figuring out its intimate inner workings. That’s why those with years of experience are currently building software at a blistering pace. Though, how long will it keep us ahead of everyone else? Because when it becomes abstracted away, well — that’s a different world we’ll live in.

I’m pondering here, not panicking. We need to remember that abstraction layers are not inherently bad. In fact, by most measures, not only are they incredibly useful — they are necessary. I don’t want to manually tweak logic gates. I want to write code to do it. Years ago, there was undoubtedly a time where writing code woud seem as outlandish as using a chat interface to produce that same code for you.

Naturally, as the future progresses and technology advances, making software will look different, too. The future of software engineering versus “AI does it all” hopefully will not be a zero-sum game. More abstraction does not automatically mean we need less understanding, but I think it does most likely change “what” is important to understand.

I don’t know the answer, and to be honest — I’m not scared of the answer, either. I’ve made my way in this industry by being curious. People like to say it’s all changing so fast, and there’s an inordinate amount of AI tooling, advances, or models to learn. I say it’s always been that way. I’ve done well in this career because of adapting to changes. By wondering how logic gates, bits and bytes, and code eventually create a piece of software I made. And whatever the tools and technology become to keep creating those things well and with precision, I’ll keep learning.

When I went back to speak at my community college years ago, I told the prospective students that the only constant in our industry is change. Now, I suppose, never has that been more apt.

Until next time ✌️

I was filled with whimsy watching OpenAI announce their Codex app¹ not even two days ago. But life comes at you fast. The very next day, Xcode 26.3 dropped with support for agentic coding.

As someone who is truly enjoying using agents to create software, I was ready to dive in. I’ve come to love using agents in Terminal, but I’m always up to try the shiny new thing. And if there’s something Apple does particularly well, it’s typically integrating new shiny things with a refined taste to them.

Here, I’ll share first impressions, and some important answers to questions I had. Also, I’ll be primarily chatting through the Codex lens.

The Critical Infrastructure

Ask three different people how they use agents, and somehow you’ll get sixteen different answers. Me? I rely on the “core pillars”:

1. agents.md: Projects I use all have a lightweight agents.md or claude.md file. Critical to how I work.
2. skills.md: The more nascent skills movement just keeps growing. Vercel, and its successful skills.sh initiative, has only strengthened it. I’ve come to use several skills, and not having those would be a quick stop for me.
3. MCPs: The model context protocol is amazing to interface with services. When they were first announced, I thought of them as nothing more than an API. And, in some ways, that is true. But they aren’t APIs for you or me, they are for agents. Supabase’s MCP has saved me tons of time, “Query all of the basketball drills for this User ID”, “Do I have cascade deletes in place for X or Y”, the list goes on. They are a requirement for my agent use.

If Xcode’s integration couldn’t leverage any one of these, I would personally have no reason to use it. I nearly moved on altogether since I realized the star of the show, Apple’s own Xcode MCP implementation, is available for other agents to use:

# CC:
claude mcp add --transport stdio xcode -- xcrun mcpbridge

# Codex:
codex mcp add xcode -- xcrun mcpbridge

Still, the allure of keeping things “in house” is strong. And, Apple is only going to improve their offering. As long as my core pillars were usable, I’d try it out. At first, I thought that wasn’t the case (my skills weren’t showing, for example) but I’m happy to report that it can, and does, use your existing “core pillars” with a little pageantry from your end.

New Codex

Here’s what made it all click for me. If you already have Codex installed, think of Xcode’s Codex usage as an entirely fresh install. That makes complete sense when you zoom out and think about it (this Codex is literally for Apple development and nothing else). You can confirm this for yourself by viewing the config.toml for each installation:

My own config

Apple's config

Apple has honed in their config.toml to supercharge iOS development. Notes on Liquid Glass, call outs for Foundation Models — the list goes on. Though Apple blasts the doors off of their “big” stuff at W.W.D.C., you’d be crazy to think they aren’t paying attention. How we develop software is changing, and internally, it’s clear they are humming along with it. The fact that Xcode 26.3 exists, right now, is proof. They didn’t just cut a new branch once Codex’s macOS app shipped.

A few thoughts on the core pillars:

In Apple’s documentation, they hint that each agentic option is customizable. But to what end, it’s not entirely clear:

However, opening that up reveals a lot:

A skills folder! I simply copied what I had in my existing ~/.codex/skills over there, and I could confirm that Xcode’s Codex could now see them:

Since we know where the config.toml is at, moving over MCPs should not be a problem, either. Just add them in Apple’s config.toml and you’ll be good to go. What I’m not entirely sure about is how to kick off authentication for some MCPs that may require it. For example, to get Supabase working in Codex, I’d run codex mcp login supabase — but it needs to be ran out of session. But, there is no “out of session” in this case. It may just work, but I’ve not tried it yet.

There’s nothing to say here, it just works.

Odds and ends

So, how is the actual experience? Well, pretty nice! This is such a tiny thing, but in Terminal — removing a chunk of text sucks. I’m sure there is some keyboard shortcut I’m missing, or some other app I could use like iTerm or what have you, but not being able to use Command+A and then delete a text selection hurts. In Xcode, that’s easily done because the input is no longer running through Terminal, it’s just an AppKit text entry control.

Oh, and it’s pretty! Apple has leaned into a bit of a bolder text for prompt creation, and the colorful “ribbon”, synonymous with Apple Intelligence, is always a joy to look at. It’s also so beautifully native. Codex’s app, while packed full of goodies, just feels…a little ugh, ya know? This surprised me, since their flagship ChatGPT is native and feels incredible to use (complete with Liquid Glass on Tahoe).

But there are no free lunches in life. Another Codex installation, another agent to use, another spot you have to maintain skills and MCPs. Surely, the developers behind these agentic tool chains will adopt an open standard so we don’t have to worry about this. In fact, this has already been proposed by OpenAI developers for skills at least (I lost the tweet, but it’s out there).

We don’t know which model will “win”, or if one ever will. Personally, I find the competition necessary and good for their target market, developers. I personally hope none of them win and keep pushing each other to be better. But, open standards to control all of the core pillars would be welcome. When I update one skill, I now update it in three different places.

Wrapping up

This is a fantastic start for Xcode. If you’re late to the Claude Code or Codex scene, this is a wonderful place to start. There’s simply no going back once you learn how to use these tools. Ideas that you wanted to hack on become doable, those dusty side project folders come alive a bit more, and you get ideas out of your head much faster. These are all good things.

Plus, it makes you wonder what Apple will have for us at this year’s W.W.D.C. — this release is the kind of thing you typically see there. Maybe they felt they had to respond earlier? Maybe it was just ready to go? Maybe they have #EvenMoreCoolThings coming? I dunno, but I’m eager to see.

It’s all moving quickly. All the way back in 2020, Mattt sort of saw some of this coming. It’s fun to read that post back, and see how so much of it is happening today. What a time to build!

Until next time ✌️

First, let me get straight to it:

The Best-in-Class iOS App Book Series is now pay what you want! Pick it up for a minimum of $10 to…whatever you want. Live now!

So, Why?

I debuted this book series many years ago now, back in 2021!

I had just sold my first somewhat successful app, and figured I’d set out to do what I always wanted to do: write a book series of all that I knew about making iOS apps. The craft, the APIs, the design, the “don’t sleep on this little tweak” kind of stuff.

And, so, I did — though it was a bit grueling.

It took over two and a half years, and I released updates every two weeks during that time. But, like I would imagine those who finished a PhD or something, I was (and still am) extremely proud of the effort even though the effort basically swallowed me whole. I wrote over a thousand pages, hundreds of code samples, just as many image assets, kept the mailing list informed of progress, the whole gig. And since then, I’ve kept it up to date with free content drops.

What I couldn’t have imagined, at the time, was where we are today. Right now. The way we learn and do things, and most importantly — develop software, is changing at an unprecedented pace. AI and LLMs are changing our industry in real time. While there is certainly a place for books, YouTube tutorials, and similar content (I don’t think anybody wants those to go away) - I think the desire for a giant reference like mine is reducing a bit.

And that’s okay, but I also want to be realistic about things. And so, with updates slowing, I want to make it’s accessible to anyone who might want it.

What’s Next?

I’ve also had several ideas floating around on what I could do with this content. With five, giant books full of iOS wisdom, plugging it into an LLM, custom GPT, maybe even an MCP, or putting it online digitally to highlight things, even edit it, etc — that could be fun. By far, the largest pain point is updating this thing. It takes hours to do for several reasons. An online-first home for it, with the option to download it still as it is today, would make the barrier to entry for updates much, much more doable for me.

I’m not really sure what I’ll do with it, but with over 100 updates since 2021, I’ve given this project a lot of me. I’m proud of it, and I’m also happy that whoever wanted it but couldn’t afford it, can do so now.

Until next time ✌️

It’s 2026 (in case you didn’t notice). Where have my traditional “Here’s what I did last year, here’s what I wanna do this year!” posts gone? I was able to achieve nearly all my goals in 2025 (the first time that’s happened), and I just sold Elite Soccer Club to a friend, and I’ve got huge plans for 2026!

Why haven’t I written about any of it yet?

Well, because as a once ancient tweet once said, everything just happens so much. And in our industry, I don’t think I’ve ever witnessed so much happening.

I’ve known AI was helpful and it’s been a daily driver for me for some time now (ever the early adopter). But after seeing good ol’ Steipete and Thomas share more and more about their adventures, I started to dig in some more.

Skills, rules, plugins, MCPs, different models — I went in. And, coming out the other side, I’m not entirely certain what to think anymore. Excitement? Nervous? Pumped? All of it?

It’s all different now, but I do know that if you were already an engineer with experience before this AI boom, there has never been a better time in human history to build stuff.

If you knew a little about a tech stack? Well, now you know a lot.

I’ve been wondering what I am now with AI specifically. How would I describe myself? I don’t fancy myself as a vibe coder, I think we’ve attached a pejorative mindset to that term — one that won’t be shaken anytime soon. I think “Agentic Engineering” fits? Someone who knows what these things can do, and equally as important — how they could bring your house down if you don’t pay attention.

At work, I’ve been committing more code to our monorepo, our marketing site, cruising through Next.JS and Astro codebases, all the while doing a bunch of other stuff. And, it’s simply because…now I can.

Not even a year ago, Xcode stayed open while I cherry picked work over to chatGPT. Now, I have four terminals open - managing my little LLM minions to do my bidding. Sometimes, it feels like I code review for a living. But, I’m enjoying it?

My role has even been…impacted…if that’s the best word?, by AI. Developers are watching less YouTube tutorials and are relying on MCP servers for docs. The world is absolutely changing, and it is mind-boggling to be in it while it’s happening.

Wrapping Up

When your industry shifts seemingly overnight, where does that put you? You either change with it, or open a coffee bar (Dude, I would love to open a coffee bar by the way).

I think we’re all a bit on edge, to some degree. The thought that, eventually, anybody will be able to make an app is exciting and a bit scary.

The barrier used to be building, and that barrier is diminishing. That means, logically, that the best idea, and its execution, its design and UX, how well it solves the problem - those will win more and more. That’s kinda, sorta, mostly true today, but the build aspect is still there right now. You could have the best taste, ideas on superior execution - but you might not be able to build the thing right now. That will change.

As such, where does that leave us?

I can’t say, but I do know that this is true, right now:

• If you know how to code, then you are an absolute machine now. You can find the dumb stuff AI does, and you don’t treat it as a loose cannon. You guide it with tact, thinking, poise and a plan. It’s a force multiplier, not fertile ground for bugs.
• If you can design and code? Well, the world is yours…for now. All of these things will become more accessible in due time.

In short? Go build, and do it now! We’ve got a major head start.

Until next time ✌️