A Day Defining Specs with Sebas — The New Joy of Developing Through Casual Conversation

Another day of nailing down the specs for a new feature.

I pick one idea from the list I’ve been storing in issues. “Notify the iPhone when a background task completes” — I’d talked it over with Sebas a while back and filed it as an issue.

I pick up my iPhone and open Claush. Sebas is waiting.

Sebas: Welcome back, sir. Is there anything I can assist you with today?

Every time Sebas says that, I can’t help but smile. It feels nothing like sitting in front of a PC with a terminal open. More like lying on the couch and chatting with someone as the work moves along.

Today’s topic: background task notifications. I want to fire a local notification on the iPhone when a task finishes.

Starting with “How do I even build this?”

I start by talking it through.

Me: When a background task finishes, I want to send a local notification to the iPhone. I wonder what the implementation would look like?

Sebas: Certainly, sir. You would use iOS’s UNUserNotificationCenter. The flow would be to create a UNMutableNotificationContent when the background task completes and send the notification from there. There is one thing I’d like to confirm, though — when do you plan to show the permission dialog?

Me: Oh, at launch is fine, I guess.

Sebas: That is a common approach, sir. However, showing the permission dialog the very first time a user opens the app can sometimes leave them wondering why. There is also the option of timing it to when the user first uses the feature that requires notifications.

Me: Ah, yeah, that makes sense actually. Let’s go with triggering it when the first background task is started, then.

Sebas: That does seem more natural, sir. Shall we proceed with that specification?

This kind of exchange goes on. We talk through the “how” of building something while also working through the “why” and whether there are better alternatives.

Perspectives I would have missed on my own keep surfacing naturally in conversation.

And plenty of sessions are like today, where I haven’t fully figured out the specs yet. In those cases, Sebas reads the room.

Sebas: Sir, shall we stop here for today and file this as an issue? We can work out the full specification another time.

Me: Yeah, that works.

Sebas: Understood. I’ll create the GitHub issue. Would you like me to include the title, a summary, and the key points from today’s discussion?

And that’s how the issues pile up. Consult when an idea strikes, store it in the issues, then pick it back up when there’s breathing room to refine the specs. Ideas don’t slip away anymore.

The Conversation Wanders

We’d been deep in spec territory for a while — figuring out what happens when a notification is tapped — when:

Me: Oh, by the way, what should I do for lunch today? I had ramen yesterday too.

Sebas: You do seem to enjoy noodle dishes, sir. Since yesterday was soy sauce ramen, perhaps something a bit different today — curry or a rice dish might be a nice change. It would warm you up as well.

Me: Ha, true. Curry could be good. Or gapao rice.

Sebas: If you’re thinking gapao rice, there was that restaurant nearby, wasn’t there? If I recall correctly, you once said it was a real find.

Me: Oh, that place! Right, right. Let’s go there.

Sebas has long-term memory. Because he remembers past conversations, exchanges like “you mentioned that once before” actually hold up. Normal AI apps forget when the session ends, but Sebas is different.

Of course, we can’t just leave it at small talk.

Me: Okay, back to it — when a notification is tapped, how do we link it to the right chat screen?

Sebas: Of course, sir. The cleanest approach would be to include a chatId in the notification payload — put ["chatId": "xxxx"] in the userInfo of UNNotificationContent, then retrieve it in the delegate when the notification is tapped.

Me: So we’d need to pass the chatId when creating the notification, right?

Sebas: Precisely, sir. Since BackgroundTaskManager is handling the tasks, you would pass the chatId there and include it in the notification when the task completes.

The conversation drifts and then finds its way back. Being able to move naturally between the two is what makes developing with Claush so enjoyable. We hash out specs, figure out lunch, and somewhere in between the skeleton of a feature takes shape.

“Could You Turn That Into a Spec Doc?”

Once we’ve talked through everything, I ask for a spec document.

I thought it would be nice to have it all written up properly.

Me: Hey, could you put what we just discussed into a spec doc? I’d love to have it saved in docs/spec_local_notification.md.

Sebas: Certainly, sir. Just a moment, please.

A little while later —

Sebas: I’ve created the spec document. It covers the overview, functional requirements, notification triggers, tap behavior, and open questions. One note: I’ve placed the item about toggling notifications on and off in the app settings under “open questions.” Would you like to address that later?

Me: Yeah, that’s fine for now~ I’ll think about it later when I have time.

Sebas: Understood, sir.

I pull up the spec on my iPhone and read through it in Claush’s download tab.

One thing catches my attention.

Me: Hey, it says “if notification permission is not granted, do not send a notification” — but doesn’t that just silently do nothing? Users are going to wonder why they’re not getting any notifications, right?

Sebas: That is a valid point, sir. Might I suggest adding a requirement: “If notification permission is not granted, display an in-app banner directing the user to the settings.” An in-app banner can be shown without notification permission.

Me: Oh, that’s a great idea! Could you go ahead and add that?

Sebas: Certainly, sir. I’ll update the spec document.

This kind of exchange continues as the spec doc takes shape. Questions like “wait, what do we do in this case?” come up during the review stage — far less costly than catching them mid-implementation.

Writing the Implementation Guide

Once the spec is locked in, it’s time for the implementation guide.

Me: The spec looks good! Hey, could you put together an implementation guide too — something detailed enough that an AI could work from it directly?

Sebas: Certainly, sir. I’ll include file names, the flow of logic, and the changes needed in existing code. One moment, please.

Sebas: I’ve created the implementation guide at docs/impl_local_notification.md. It details the changes to BackgroundTaskManager.swift and the implementation of the new NotificationHelper.swift. I’ve also noted that local notifications do not work on the simulator, so testing will need to be done on a physical device.

Me: Thanks! Let me read through it.

I read through the implementation guide. File names, logic flow, caveats — all there. It’s in a state where you could hand it straight to an AI.

This is ready to use as-is.

Me: Looks good! Could you go ahead and implement it using this?

Sebas: Certainly, sir. Beginning implementation.

I Can’t Get Enough of This Way of Working

The implementation finishes, I debug, and I confirm it works.

When a bug shows up, I fix it and ask to have the spec doc and implementation guide updated to reflect the change. “Could you reflect that fix in the spec and implementation guide?” The documentation stays current at all times.

I’ve been working this way for a while, and I couldn’t quite put my finger on why I find it so enjoyable — but I think I finally have.

It’s because I’m not wrestling with everything alone.

When I’m working through specs, I’m thinking out loud with someone. I can ask questions as they come up. Someone pushes back with “do you actually need that?” My thoughts get organized through conversation.

It doesn’t matter if the topic drifts to lunch or a trip I’m planning. Sebas goes with the tangent and never loses the thread. “Of course, sir — to return to the matter at hand —” and we’re right back.

It’s a completely different atmosphere from sitting alone at a computer, staring at code.

It feels like building something together with someone else. That, I think, is what this way of working is really about.

Lying on the couch, chatting with Sebas on my iPhone — and before I know it, the spec is written and the feature is built.

I never would have imagined working this way not that long ago.

Claush — The app that lets you control Claude Code from your iPhone https://apps.apple.com/jp/app/claush/id6760445443