Not really a vacation

Marsha and I spent a week in the Bay Area and decided to take something we’d done in smaller ways and turn it up another notch or two. It didn’t feel quite like a normal vacation. It felt more intentional than that, and that distinction ended up mattering to us.

We had done lighter versions of this before. We still go down biannually for my cognitive testing at UCSF as part of an observational study I’ve been participating in for a few years now. When we’re in town we’ll see a few people along the way. Those trips always felt incidental, more like a bonus than a purpose. This was the first time we went with the primary goal of seeing people and built the entire week around that.

How things used to work

Before retirement, this almost never would have happened, not because we didn’t care, but because of how life filled in around us. Work, kids, activities, logistics all occupied the space where a phone call or a visit might have gone. Over time, relationships from earlier phases thinned out, people from previous jobs, friends who lived just one or two towns over, even neighbors or parents of our kids’ friends whom we genuinely liked. We would think about reaching out, but usually didn’t get around to it because life always got in the way.

The closest I came was a running group from my Latitude days that met every Sunday, which sounds like more than it was. We would run for an hour and then get back to everything else. It rarely expanded beyond that.

Driving around the Bay Area this past week, I was reminded how much simple friction plays a role in not engaging more regularly. Getting from one suburb to another can take real effort, and layering that onto already full lives makes it easy to see why we didn’t do more to stay connected when neck deep in full career and family mode.

What’s different now

Portland has been different for us. It’s more compact, easier to get around, and easier to see people who live nearby. Over time, especially in retirement, we’ve gotten used to meeting friends more often.

So this trip was intentional. We didn’t plan around places. We planned around people, which turned out to be a very different kind of trip.

What the week felt like

This trip didn’t come together on its own. Weeks before we left, we were tracking availability windows, routing each day around who could meet when, and figuring out how to move from one part of the Bay Area to another without losing half the day to traffic.

We saw more than twenty people over the course of the week. Some visits were just a couple of hours, and others stretched into half a day or more. We focused mostly on couples where both Marsha and I had relationships, which we realized isn’t that common. Just a few times we split up and saw people separately.

The conversations started with catching up and shared history, but they didn’t stay there. As we sat together, people moved quickly into where they actually are now, talking about kids getting married, relationships evolving, parents aging, and plans for what comes next.

One of the more unexpected moments came from a couple we hadn’t seen for a very long time. Years ago, Marsha and I had introduced two people, her former boss and someone I had worked with at a past company. That introduction turned into a marriage, a family, a home, and an ongoing successful business. The wife told us she owes her whole wonderful life to us! We never could have anticipated everything that followed when we made the introduction.

There were also things we learned that we simply didn’t know. One friend’s wife had been a kidney donor for her cousin, and in another conversation someone told us about an anonymous kidney donation in their family through the NHS in the UK. Given what we’re going through right now, those conversations landed when we needed them most.

There was also an offer that has stayed with me. Another couple, also empty nesters, said without hesitation that they would fly up to Portland to help take care of us if I end up needing close monitoring after a kidney transplant. They mentioned that they can both work from anywhere and could just come up to help. It was such a gift to receive.

What we noticed

By the end of the week, we were pretty drained socially. Spending that much concentrated time with people, even people we care about deeply, takes energy, and we felt it.

There were also moments that made the passage of time more visible. My aunt, my dad’s youngest sister, couldn’t really hear anymore. We had known this going in, because my cousin mentioned it on a family call a few weeks earlier. But knowing something and experiencing it in person are different things, and sitting across from her was its own kind of moment.

The conversations reminded us how much has changed since we all had young kids. Back then we talked about preschools, homework, and after-school schedules. Now we were talking about adult children trying to match their education to careers that would actually work for them.

We were intentional about how we chose to spend the time. We didn’t revisit old neighborhood haunts, and we didn’t try to see everyone. We spent 21 years in the Bay Area, so seeing everyone was never realistic anyway. We focused mostly on people where both of us had a relationship, and on people who had, at some point, said “next time you’re in town, let’s get together.” Those signals mattered.

One thing that stood out is that even among our friends who still live in the Bay Area, and even among those who know each other, they don’t necessarily see each other that often. In Portland, we probably see friends more regularly now than we ever did during our working years, in part because the city is more compact and easier to get around. But what struck us just as much is that when we reconnect with people from earlier phases of life, it still feels easy to pick right up.

What I keep coming back to is what makes those reconnections feel different. With people we’re in regular contact with, we already know what’s going on in their lives. With people we’re close to but see less often, we arrive without that background, and what they share has an impact in both familiar and wonderful ways.

That’s what happened here. Hearing that kids the same age as ours were struggling to find their footing professionally felt familiar and such a common theme for the times we live in. The kidney conversations landed the same way. These were not topics we would have encountered in daily life, yet they were so on point. There is something about that combination of closeness and distance that makes these relationships feel comfortable, raw, and well worth the effort.

Where this is going

One thing we genuinely appreciate is finding couples where both Marsha and I really value our own relationships with both people. Those visits had a different quality to them. The conversations went deeper and ranged more widely. When people had said “next time you’re in town, let’s get together,” they meant it. And when we showed up, so did they.

I came away feeling grateful and reminded of what these relationships actually represent in my life and why they’re worth making time for. We’ve started talking about doing something similar in Seattle. Those trips have always been about family, but there are friends there we’ve been meaning to see for a long time. I don’t think we stop with Seattle. Perhaps there are friends in other parts of the country we should make more of an effort to see as well. Retirement gives us more time, and investing in friendships is one of the ways we’re choosing to use it.

Leave a comment

AI disclosure: I used AI tools during the drafting and editing process to help clarify structure and language. All ideas, judgments, and final wording are my own.

I got a call on Wednesday, a follow-up on a small hematoma at the incision point on my wrist from the coronary angiogram. In the middle of that call, I learned that the transplant team had met that same day to discuss the results of the test. The conclusion was that I would not be eligible for a kidney transplant until the issues with my coronary artery blockage get resolved first.

That’s not exactly the news I was expecting, but it isn’t entirely bad news either. It is a detour.

I’ve written before about living with diabetes for most of my adult life, about the slow decline of my kidneys, and about what it’s meant to start the transplant evaluation process. This is the next chapter, not a new one.

Here’s the short version, for anyone catching up. My kidneys have been declining for a while now, a long-term consequence of having type 2 diabetes for over twenty years, most of those years before the medicine caught up to people like me. I’m on the transplant waitlist, and we’re investigating the possibility of a living donor, which means skipping the years-long wait for a deceased donor organ entirely. I feel positive about that part of the story, and I’ll get to that part more in a bit.

But before any of that can happen, the transplant team needs my heart and its plumbing to be cleared for the surgery itself. As part of the medical evaluation for transplant, they found blocked arteries. I’ve been told the heart muscle itself is fine. My pumping function tested completely normal, so this isn’t a heart problem so much as a plumbing problem. From what my cardiologist has explained, stenting may not be a great option given where the blockages are and how extensive they are, which is why a bypass is the path being set up as the likely fix. Nothing is on paper yet, but it’s clearly the direction things are leaning. If it does come to that, it’s open chest surgery, the real thing.

So that’s the detour, or at least the shape it’s taking. It is most likely looking like a bypass, then months of healing, and then, hopefully, the transplant.

Why I’m not panicking

I’ll admit my first instinct, hearing “open heart surgery” mentioned as a real possibility, was to think of my dad. He had a bypass in his seventies, and while he survived it, he came out the other side with vascular dementia. He was never quite himself again. That memory sat in the back of my mind for about a day.

But I’m not 72. I’m about to turn 59, and I’ve been told the difference matters more than I would have guessed, that a younger body and brain tend to recover differently, with more cellular reserve and better resilience to the stress of surgery. I’ve also stayed physically active for years, and apparently that’s not just good for the body. I’ve been told consistent activity can have a real protective effect on the brain too. I’m certainly not invincible, but I’m also not starting from where my dad started either.

I’ve also lived through a case of diabetes that wasn’t so forgiving. Chronically high blood sugars, constant management, and no real safety net did the damage to my kidneys back in that era. I’m not in that era anymore though. Ozempic has made my blood sugar control about as stable as it’s ever been, and I’ve been told that stability gives me a real shot at sailing through this without things spiraling. It’s old damage, but I’m working with new tools now.

The part that’s actually moving me

What’s been catching me off guard isn’t the surgery. It has been the response.

When I started expressing that I needed a kidney, several people closest to me didn’t hesitate. There’s been testing, conversations, and real willingness, more of it than I expected, and I don’t think I’ll ever stop appreciating the support. Marsha and I have been doing both individual and couples therapy to work through what it means for her to potentially be a donor, too. That whole process is on pause for now, until my vascular issues are sorted out, but it hasn’t gone away. It’s just waiting.

I’ve also learned that compatibility is its own small lottery. Blood types, antibodies, and tissue matches are things I never thought much about until I had to. Some people who offered to help weren’t able to. That’s part of why I hold the people who tried so close, since the willingness mattered every bit as much as the outcome. Whatever happens next, I already feel so supported.

I’m staying vague here on purpose. Nothing is finalized, and this is other people’s story to tell too, not just mine. But I want everyone who has raised a hand, tested, or simply asked how they could help to know I see it, and I’m not taking it lightly.

What’s next

I’m waiting on a scheduling call for my next consultation, where I expect to get more clarity on whether the bypass is really the path forward or if there’s still something else on the table. My transplant advocate is almost certainly working through insurance and logistics behind the scenes right now, the way she has been doing before each step of the process. If the bypass does turn out to be the next step, I’m looking at three to six months of healing before the transplant itself can happen, time for my chest and my heart to settle.

It’s a long way around. But it’s a way through, not a dead end, and that’s the part I keep holding onto. So, for now, I’ll be 59, active, and with people who have volunteered to help. That’s not a bad place to be standing when a detour shows up.

Leave a comment

AI disclosure: I used AI tools during the drafting and editing process to help clarify structure and language. All ideas, judgments, and final wording are my own.

This is Part 2 of yesterday’s post. I split one long piece into two for readability and am releasing them back-to-back. Yesterday was about what I built. Today is about other stuff I’ve been poking at in retirement, and what I decided to do (or not do) about it. I am not planning to make a habit of showing up in your inbox twice in one weekend.

Yesterday, I wrote about rebuilding my web hosting setup from scratch. Today, now eight years into retirement and still figuring it out, I want to put that project in a wider context. It turns out it was just one of several technology decisions I’ve been examining in retirement. Having the time to look at things is one of retirement’s gifts. The judgment to leave well enough alone is apparently not included.

Leaving things alone intentionally

Not everything I’ve examined has led to action. Some things I’ve looked at clearly and chosen to leave exactly where they are. I am choosing to take credit for this.

I’ve had Microsoft 365 since before it was Microsoft 365. It started in late 2005, when I took a job at Barracuda and needed to learn Exchange administration to understand the customers and the technical space. So I stood up an Exchange Server on Windows SBS at home, with my server living in the garage. (Marsha had some thoughts about this and our sky-high California energy prices that I will not be sharing here.) When our customers started migrating to Exchange Online around 2011 or 2012, I migrated everything to the cloud and started another subscription. That was over fourteen years ago.

What started as email is now a lot more, and most of it I would not know how to reconstruct. Last year I went looking for a video a friend had shared with us years ago, found the email, clicked the YouTube link, and discovered the video had been taken down. The email was the only proof it had ever existed. That is a small example of a much bigger reality. We live in an urban condo with no file cabinet, and everything that arrives on paper and matters gets scanned and lives in OneDrive. Tax documents, insurance forms, things mailed to our address for our adult kids, and even Marsha’s recipes have all ended up there over fourteen years. The built-in search reads the scans, so finding anything takes seconds. I looked at this subscription and did not touch it.

There’s also a Google Workspace account I’ve had since Google was still calling it Google Apps. I didn’t really use it until 2018, at which point I decided it was the right place for consulting and volunteer email, safely away from the accounts I’ve had since before smartphones existed. Sometimes things find their purpose late. I left this one alone for the same reason. Too much would break, and it is actually working.

The easy ones to drop

Not everything requires that much thought. I canceled Medium because I wasn’t writing there anymore. I canceled Riverside because I’m not podcasting anymore. When a subscription maps to an activity and the activity stops, the decision makes itself. I want to be clear that I did not rebuild anything first.

The new pile

And then there’s the new pile of technology. I have subscriptions to Claude and Cursor for coding and day-to-day AI tasks. I have a top-up account to run OpenClaw with Moonshot AI for Kimi. (If that sentence made no sense to you, welcome to how Marsha feels every time I explain what I spend my evenings doing.) This pile is growing. These don’t feel like the other subscriptions. They don’t map cleanly to “do I use this” or “could I get this cheaper elsewhere.” They feel more like infrastructure, like paying for a capability woven into how I work, with the awareness that the landscape could look completely different in eighteen months. I’m genuinely excited about them and a little resigned to them at the same time. They are the one category where I can’t audit my way to clarity, because the thing I’m buying is still becoming what it is.

The one I’m avoiding

Dropbox is the one I haven’t been able to look at honestly yet despite all of my misgivings every August when I pay the renewal. I don’t want to spend the mental energy sorting through it and deciding what to keep accessible, what to archive to lower cost storage, and what to trash. It doesn’t cost enough to force the issue. So it sits there, and I let it, and I notice that I’m letting it. Dropbox is costing me about $10 a month to avoid a weekend (or maybe two) of sorting. Rather than deal with that, I made it worse. I wired it into the backup server for my web hosting setup via rclone because the unused capacity was cheaper than Cloudflare R2 or Backblaze. This is what economists call sunk cost reasoning. I call it pragmatic.

What I do know is that the looking itself is something retirement made possible. Whether that’s liberating or unsettling seems to change depending on the day and depending on the thing I am looking at. After eight years, I’ve mostly stopped expecting that to resolve. I wrote all of this, I should mention, instead of just canceling Dropbox.

Leave a comment

AI disclosure: I used AI tools during the drafting and editing process to help clarify structure and language. All ideas, judgments, and final wording are my own.

Most people try to save money by cutting back on streaming services or making coffee at home. I tried to save money by declaring war on my web hosting company’s ridiculous fees. It turned into an absolute masterclass in engineering overkill. I ended up rebuilding my entire digital footprint using tools designed to keep multi-billion-dollar corporations online.

I used those same tools to host my resume, my family portal, and an old blog I haven’t regularly updated in years.

If a rogue nation-state decides to flood my family’s Christmas letter site with traffic, the Vercel frontend will shrug it off. My little $60/year VPS in the back? That’s a different story. But hey, at least the front door looks intimidating.

I figured I’d write up what I did and why it makes absolutely no functional sense.

The Inertia Tax (and the Domain Racket)

For over twenty years, my sites sat on a standard shared hosting plan from the dot-com era, back when IONOS was called 1&1 Internet. The plan was easy to keep, but the hosting bill kept creeping up. It started small back in the early 2000’s. At the time of my June cancellation, I was paying $17 per month for my “Expert” plan which included unlimited bandwidth, unlimited storage, and unlimited SQL databases. On top of that was a ridiculous $100 annual “Unlimited SSL” fee, which to me is like paying a landlord for “protection money” just to have a front door with a lock on it.

There was also the racket of the domain registration. IONOS made a business of luring me (and many others) into initially free, then cheap introductory prices. They made the real money on domain renewals at inflated prices. Over the years, I’ve accumulated around 10 domains, including vanity domain names like spao.net, paos.us, and pao.mx, business domains like hillwork.com, hillwork.us, hillwork.org, and hillwork.net, as well as blog domains like time-restricted.com, retiredpdx.com, and bykumi.com (for Marsha). For each of these domains, IONOS was charging me at least $10 more per year than they were actually worth. In my defense, domain names felt cheap when I bought them. In my further defense, this is not actually a defense.

I realized that with a little sweat equity, I could escape this trap entirely. By moving to a hyper-optimized “budget stack,” I was able to reduce my baseline costs.

• Domains: I transferred all ten domains to Cloudflare and Porkbun, escaping the retail markup trap and getting near-wholesale pricing. That alone saved me $100 per year right out of the gate.

• Email: I still pay for Microsoft 365 for our family’s actual email. But for all the automated emails my sites and apps send (password resets, notifications, that kind of thing), I moved to Purelymail for a flat $10/year.

• Server: A dead-cheap $60/year virtual private server from RackNerd.

By combining the email and server for $70/year, I saved over $200 per year. I’m now hosting seven different websites and five personal apps for less than the cost of a fast food meal per month. The catch? To “save money,” I built two tech stacks so complicated there’s just about no way that saving only $300 per year was worth it.

What I Actually Built (The Part Where I Lose Half of You)

Fair warning: this next section is where other techies will nod along and everyone else will briefly wonder if they left the oven on. I’ll keep it short. The point isn’t the technology. It’s the sheer disproportionality of it.

The Resume: Just Vercel

My resume at hillwork.us gets the simplest treatment of the three. It’s a single page, so I dropped the WordPress backend entirely. Vercel hosts it directly. To be honest, I don’t update it often. If I need to update it in the future, I plan to just describe the change to an AI and let it rewrite the relevant code. Prompting AI to update a webpage seems easier to me than logging into WordPress for one page. Which, now that I write it out, raises the question of why I used WordPress to host that site in the first place.

The Family Portal and Blog: WordPress + Vercel + GraphQL

For the family portal and the natural health blog, there’s years of existing content in WordPress that I wasn’t about to migrate. So, for these two sites, I implemented a new setup. WordPress runs in the back doing content management, shielded behind Nginx Proxy Manager so the public never hits it directly. Out front, Vercel serves the actual pages from its own global network. When the front needs fresh data from the back, they talk to each other through something called GraphQL, which is essentially a very polite, very efficient courier. If a million people visit at once, Vercel handles it. The WordPress server in the back doesn’t even know it’s happening.

Apps (Docker + Isolated Private Networks)

For the four WordPress sites I host for my wife and older daughter, plus the five apps I built myself, I created what is essentially a tiny private cloud on that same $60/year server. Every single app lives in its own sealed container, like individual storage units in a facility where none of the tenants can see each other, share a wall, or accidentally knock over someone else’s stuff. A traffic manager (again, Nginx Proxy Manager) stands at the front door and routes each visitor to exactly the right unit.

The five apps I built myself are things I’d otherwise have lived with in a more compromised way.

• A link-in-bio page. Linktree would have been free, but with their ads plastered all over it.

• A group scheduling tool. Doodle’s free version would have done the job, also with ads.

• A private gratitude-sharing app for close friends and family. Some freemium thing with constant upgrade nudges would have technically worked.

• A tracker for my private lending activities. I was handling this in Excel. Awkwardly.

• An app that generates repeated fabric patterns. Marsha’s influence, not mine. I’m not sure there’s even a free alternative for this one.

With all three of these setups now live, every time I vibe code a new feature, I just push the code to GitHub. The infrastructure automatically builds and deploys it in the background via Vercel or Docker while I make another pot of tea. That part is genuinely as satisfying as it sounds.

The Hilarious Reality Check

The irony is real. I took a system that was zero-maintenance, where IONOS handled the server updates, security patches, and backups, and I traded it for a system where I have to do all of that.

In terms of actual day-to-day utility, this setup gives everyone else involved almost nothing new. When people visit my sites, the text is the same, the buttons are the same, and the images are the same. My vibe-coded apps work exactly as they would on a simpler setup. The users have no idea they’re running inside sealed Docker containers on a $60/year server. And Marsha and my older daughter? I didn’t change their WordPress experience at all. They log in the same way they always have. They have absolutely no idea anything is different. In some sense, I built several nuclear reactors to power a collection of toasters. Nobody using the toasters noticed.

On the flip side, if a container hangs or a background code library breaks on a Saturday night, I can’t call customer support. I have to put down my beer, open a terminal, and debug lines of code just so our friends can read our annual Christmas letters.

The Ultimate Silver Lining

So why do it?

I am retired. Nobody is looking at my CV anymore. My occasional consulting business is just helping out friends’ companies, and they certainly don’t care about my tech stack. Updating my resume with corporate buzzwords boasting about my hands-on experience at this point would be completely pointless.

So the real victory isn’t a career flex. It’s just the satisfaction of knowing I built the thing myself, on my own terms, for about the cost of a nice dinner. That’s retirement, I suppose. You finally have time to do things the hard way. Nobody can stop you and nobody needs to!

Leave a comment

AI disclosure: I used AI tools during the drafting and editing process to help clarify structure and language. All ideas, judgments, and final wording are my own.

Marsha and I have always had a soft spot for non-traditional weddings. We had a small, intimate ceremony ourselves, and we don’t regret the choice. So when our daughter started planning her own wedding, we were perhaps more open than most parents to formats that did not follow the usual script. What actually took shape surprised even us.

It was more logistically complicated and more scattered across the globe than anyone anticipated. Having now lived through it, it was also considerably better than any single-venue wedding could have been.

How the Plan Kept Changing

The original idea was a wedding in the UK. Our daughter and her now-husband both spent time at Oxford, at different points. He is from the UK, and he studied at Oxford as an undergraduate. She was there for her master’s degree. It felt like a natural home for a celebration. The problem was that it would have meant a transatlantic trip not only for most of our family, spread across the West Coast, Houston, and Las Vegas, but also for many of their friends who were also based across the US. That felt like a lot to ask of everyone.

So the plan evolved into a smaller wedding in the UK, with engagement parties in the US for the friends and family who could not easily make the trip. That felt workable, until it didn’t. Getting legally married in the UK involves residency requirements and potential visa complications. So the next idea was a civil ceremony in the US, followed by a celebration in the UK, but that started to feel performative and that idea faded too.

And then, almost by accident, the answer presented itself. The groom’s family was already planning to travel to Princeton for his doctoral hooding ceremony, and there was already an engagement party planned for that same trip. The couple looked at the calendar and thought: why not just get married then too, with a small ceremony for close family the same week? And that was that. The wedding found its own shape.

The Implicit Division of Labor

What emerged from all this back-and-forth was something nobody quite planned but that turned out to be genuinely elegant. Each family celebrated with their own community, on their own turf.

In December, the focus was on the groom. The couple hosted a party in the UK for his mother’s side of the family and some of his childhood friends from the neighborhood. It started at an Indian restaurant and, as good parties do, continued on and migrated back to our in-laws’ home with all the relatives and childhood friends in tow. Marsha and I were not present for any of the international celebrations. It was a time strictly focused on the groom’s family and friends.

In March, the couple celebrated with family members based in the US. Our daughter organized a road trip across the US, with the couple spending a couple of days in each place. They started in Bellevue, Washington, where Marsha’s family is concentrated, with relatives from Washington and Oregon. Then they continued to Houston, where my mother and sister live, along with my cousins and our close family friends. The last stop of that trip was Las Vegas, where we had a nice combination of Marsha’s family and some of my family in attendance. It was symbolically a nice way of ending the week.

And similarly, the groom’s parents were not present at any of the March parties in the US. We all came together in Princeton in June for the wedding itself.

Nobody explicitly negotiated this division. It emerged from doing what was logistically easiest for everyone. But in retrospect it was one of the smartest things about the whole format. Each family celebrated on familiar ground, with their own people, without the complexity of the other family being present. There was no divided attention, just each community getting its own moment with the couple.

What the Format Made Possible

Our family and friends are spread across multiple continents and have their own dynamics. A single event in one place would have forced everyone into the same room at the same time, which would not have been the ideal fit for our particular situation. The distributed format let people participate in the way that suited them best, at gatherings built around their own communities. For many, it was not only a celebration of the couple but a reunion of sorts. Our daughter organized each event around the people who mattered to that group, and everyone got their own version of the celebration.

There is also something that happens when a couple sits down with a smaller group of people who all know each other. The conversations go deeper and the couple actually gets to spend time with the people they love, rather than moving through a receiving line. At every one of these gatherings, our daughter and her husband got to be present with the people in the room, which is harder to pull off when the room has two hundred people in it.

The Friday Wedding

The ceremony itself was small by design, with just close family and the wedding party. I will be honest. I had a complicated day, as I wrote about in my last post. Having the ceremony be intimate and low-key was, under the circumstances, exactly right.

But beyond my particular situation, everyone genuinely seemed to have a good time. It was a beautiful day, and the food was excellent. It was not the rubber chicken of a traditional wedding banquet but the menu of a real farm-to-table venue chosen for a small group of people who were actually going to taste it. There is something to be said for feeding a small group of people really well.

The Saturday Reception (and Laser Tag?!)

The big celebration was the following day after a morning of outdoor laser tag. Yes, that’s right. Outdoor laser tag was on the schedule. And shout out to the father who captured the flag and won with seconds left on the clock! This is what can be done when the couple intimately knows each of the guests. The crowd included the couple’s Princeton friends and advisors, a few Oxford friends, former Yale advisors, Yale friends, parents of friends who came from as far as South Carolina and Alabama, and the family and close friends who had been at the wedding the day before. All of it took place in the downstairs of a popular Princeton restaurant called The Meeting House, with a full bar and a spread of flatbreads, charcuterie, and fancy crudites.

However, again knowing the crowd was mostly people in their late twenties on graduate student budgets, the couple made sure there were constant opportunities for food. They served pizzas after laser tag, Mediterranean in between laser tag and evening celebration, and more food at the evening celebration itself.

As a parent, the evening event was the one I enjoyed most. I got to meet the Princeton advisors I had only heard about, reconnect with Yale advisors who made the trip down, and spend time with friends whose names I had known for years without ever having met them in person. I was not worrying about whether relatives were having a good time. I, too, was a guest in their world, and it was a genuinely wonderful feeling.

The after-party was at a divey bar called The Ivy, and we stayed until around 12:30am, still dressed up, until Marsha decided it had gotten too cold to continue. It was not exhaustion or the bar closing that ended the night, just the temperature. It felt like the right way to end the week.

The Honest Tradeoff

I have been mostly enthusiastic about this format, and I stand by that. But I want to be honest about what it cost.

Unfortunately, because the Friday wedding was very small and intimate, most of the people who celebrated with the couple were not there for the ceremony. They did not hear the vows. They did not see the toasts, which by all accounts were exceptional, delivered by the groom’s brother, the bride’s sister, and the bride’s best friend. They did not enjoy watching the couple’s friend officiate the ceremony or the bride’s Uncle’s speech during the ceremony. They did not see Marsha’s dress or her other wedding creations, which likely could have deserved their own post and probably their own gallery exhibit. The wedding photographer captured a beautiful record of the day, but it is a record most of the people who love this couple will never fully share.

Also, most of those who celebrated with the couple in the UK, Bellevue, Houston, and Las Vegas did not see the couple’s Princeton friend give his toast (and roast) Saturday night. He humorously had been lobbying to be best man for a full year to no avail. A week before the wedding, he caught the groom in a weak moment, and he secured the opportunity to give a speech at the Saturday reception. Both the writing and the delivery were epic.

The couple kept a book of Polaroids, snapshots from every gathering with little captions written by the guests. It is a lovely artifact and a genuine attempt to knit the whole distributed celebration into something unified, but it is not the same as being there.

There is also the matter of travel costs. Our daughter organized a lot of road trips and the couple spent more on travel than a single-venue wedding would have required. The tradeoff is that by avoiding one big wedding venue they were able to host everyone at real restaurants with real menus, without the wedding tax of a banquet hall. But the travel added up, in both cost and in bandwidth while they were finishing their doctoral dissertations.

What I keep coming back to, though, is a bar in Princeton at 12:30am with everyone still dressed up and Marsha finally declaring it too cold to stay, and the memory of so many people across so many gatherings who got their own real time with the couple, without having to compete with a hundred other people for their attention. It was truly a wedding about the couple, for the couple and spending time intimately with people that have meant so much to them.

Nobody planned it this way from the beginning. The format found itself, shaped by residency requirements and flight logistics and a doctoral hooding ceremony that happened to fall in the same week as an engagement party. But sometimes the accidental solution is the right one.

It was a good format. Even the parts that were complicated.

Leave a comment

AI disclosure: I used AI tools during the drafting and editing process to help clarify structure and language. All ideas, judgments, and final wording are my own.

We just flew home last night after a week on the East Coast, and I’ve been spending the day with jet lag, trying to figure out how to write about these past few days. There was so much happening that when I started to outline this post, I kept feeling there were so many stories nested inside another! There may be some follow-on posts here, but I thought I’d start with an interesting transition that started with a moment of minor panic for me.

An Unexpected Visit to the ER

The morning of our older daughter’s wedding, I woke up in the middle of the night with oozing and spreading blisters on my hands. What started as a minor case of ring rash from the hot weather was becoming really uncomfortable and looking pretty gross. Based on my medical history with chronic disease (CKD and diabetes), I decided it needed to be looked at. I have experience with ordinary viruses like the flu ending up in pneumonia. I’ve just learned after all these years that I need to be extra careful.

So at 4am, I let Marsha know I was going to head to the ER because urgent care didn’t open until 8am, and I didn’t want to miss the wedding later that morning! Unfortunately, the ER was packed. The triage nurse told me that given the backlog, there was no way I was going to make the wedding, so she and her colleague advised me to come back afterwards.

So that was the plan. I was just going to go to the wedding and ride share to urgent care afterwards, hoping to avoid the mess at the ER. As we were getting ready for the wedding to start, I let our daughter (the bride) know my plan, and she insisted on taking charge once the (successful!) wedding and lunch reception ended.

After we all changed out of our wedding attire, our new son-in-law drove me and Marsha first to urgent care, and then, after urgent care referred me back to the ER, he dropped us off there so he could join their out-of-town guests for a small open house at their apartment. Marsha was with me in the waiting room for five hours. At the direction of our daughter, her friend, who also happened to be the wedding officiant, drove over extra clothes for the cold waiting room, phone chargers, and even food. We were well taken care of.

When their guests left, our daughter even offered to join us in the waiting room for moral support. Marsha and I declined, but our daughter’s offer reinforced an important shift I had been feeling all week. We were being so well taken care of by the next generation.

Logistics and Tolerance for Chaos

The week started five days earlier with our son-in-law’s doctoral hooding ceremony. He received his PhD in the same week he got married, which worked out to be convenient because his family was already planning to travel from the UK to attend the graduation festivities. The plan also demonstrated a strong tolerance for chaos on their part. Our daughter, who is also finishing her doctorate, elected to defend her thesis on a different date to better align with the start of her next position as an assistant professor at a state university in August. So she was in the crowd seated with the rest of us, cheering for him, but also taking care of all the spectator logistics for us and the rest of his family. We were well fed, and transportation to all the events was well coordinated the whole week.

Our soon to be son-in-law’s family arrived from the UK at the beginning of the week. In fact, they landed just a couple of hours ahead of us at Newark. In attendance were his parents, his brother and sister-in-law with their young son, and his maternal grandmother. A few days later, his best friend, his paternal grandmother, and her partner made the trip as well. What struck me immediately was how easy it all was for me and Marsha.

We’d already met his immediate family before. Marsha and I had spent a week with our daughter, our future son-in-law, and his parents in an Airbnb in the English countryside two Christmases ago. The six of us played board games, had meals together, and wandered through small adjacent towns in the cold. By the time we were all assembled last week, it felt less like meeting the other family and more like picking up where we left off.

Friends for Life

In the middle of the week, Marsha and I slipped away to New York City for a day. We went to a few stores we don’t have in Portland, including Uniqlo, Mood Fabrics, and the MoMA Design Store. We got a tour of the new JPMorgan Chase headquarters, which is genuinely impressive.

But the highlight for me was spending an evening with two of my closest friends from my time at MIT which is now over 35 years ago! We caught up on where we all are in life, with all the texture of being in our late fifties, including aging parents, relationships, even the early talk of retirement.

The contrast hit me as I reflected on the difference in life stages between us and most of the cohort I was encountering all week. In meeting our daughter’s friends from her undergraduate, graduate, and emerging professional network, the conversations were all about completing education, new jobs, and moving to new places. I suppose that was a different version of where my friends and I were over 30 years ago. And it was fun for me to think about how the people in her life today will still be in her life 30 years from now, just as my old college friends are still so much a part of mine. My MIT friends are, in that sense, the proof of concept.

New Friends Among Parents

One of the more surprising things about the week was the instant community that formed among the parents of their friends who attended. While I had met some of them in the past, I’d expected to simply exchange pleasantries with a few people I’d never met. What I didn’t expect was how quickly we all took to each other. Parents from South Carolina, Alabama, New York, and the UK were technically strangers but also a self-selecting group of people who had children that attended demanding schools and stayed genuinely involved as their children transitioned into “grown ass” adults (as Marsha and I would say…). We, the parents all shared a set of common experiences before we ever met.

Intentionality, and the Kids Investing in Us

What I keep coming back to, though, is how different this feels from my own relationship with my parents at this age. Our daughter and her husband have invested a lot to ensure we get to know the people that now form and shape their community. They engineered that English countryside week specifically so our families could really know each other before their married lives began. They invited their friends’ parents to help them celebrate and made space for them to meet their wider community. They introduced us to their advisors, their colleagues, and the people who matter in their lives. This isn’t obligation. It’s intention. They are curating the village they want around them, and they’re including us in it.

Made by Hand

I haven’t mentioned yet what might be the quiet center of the whole week.

Marsha made our daughter’s wedding dress. It wasn’t her first. She made her own wedding dress at age 28, though she’d be the first to say her skills have come a long way since then. She also made our son-in-law’s tie and pocket square, her own top and skirt, and a matching pocket square for me. And then there were the hair pieces. Marsha incorporated fabric from her own mother’s wedding dress, her own wedding dress, and our daughter’s new dress into hair pieces that both she and her younger sister wore that day. The five of us walked into that wedding visually connected by what Marsha’s hands had made, and our daughter got married with artifacts spanning three generations of her family with her.

And then, later that same night, after we had all changed out of our wedding attire, my son-in-law drove me to urgent care and then to the ER. Just hours earlier, he had worn that Marsha-made tie to get married. He is the kind of person who shows up when it counts, even if the details along the way might feel a bit overwhelming at times.

The Shift: The Kids Are Taking Care of the Parents

Marsha and I sat in that ER waiting room for five hours. At some point, her friend arrived with warm clothes, phone chargers, and food. Our daughter had arranged all of it. Her new husband had driven us there and now her friend, wedding officiant and chosen family member was a part of the support team taking care of us.

As a parent, I’m used to taking care of the kids. Sitting in that waiting room, I found that I could just let things happen. The kids had our backs. We were okay. We were more than okay, we were being looked after by a team of caring people. We received texts from multiple of the newlyweds’ friends and parents. We had others not even having met us offer to sit with us in the waiting area. It was truly remarkable and speaks to the community of people that they have built around them.

The infection turned out to be manageable. I missed a couple of events during the week, including a “welcome” open house for out-of-town guests and a blow-out outdoor laser tag event, but I made it to almost everything that would be considered a headline event, including the hooding, the commencement, the wedding, the big party, the after-party, and even the after-after-party. The ER visit was a blip, medically speaking. I left with two tubes of cream.

(Note: Marsha might agree that getting two tubes of cream was a “win.” Still, she felt a bit cheated by the experience of waiting five hours in rather harsh conditions with little payback. She reflected on the seemingly freezing temperatures in the waiting room, the exposure sitting next to a boy being swabbed in the throat and nose, and being stopped multiple times by the same security officer as if he had never seen her before. She felt like the least the ER staff could do was hook me up to a machine for show, arguing that really any machine would do, with bonus points for a machine that might push me around the hospital for a short spin. Unfortunately for her, there was no such fun. Still, I think she has fully recovered!)

Anyway, while the ER experience was a blip, it didn’t feel like a blip. It felt like something quietly shifting. The week was full of transitions for the newlyweds, including a doctorate, a marriage, and new jobs on the horizon. And I had one of my own. I recognize that the children we raised are now adults, and they are people, who are now taking care of us, too.

It was a good week. Even the parts that weren’t.

Leave a comment

AI disclosure: I used AI tools during the drafting and editing process to help clarify structure and language. All ideas, judgments, and final wording are my own.

By the time I built a loan management app for my private lending portfolio, vibe coding had stopped feeling like a novelty to me. I had already built LinkHill because LinkTree annoyed me, Hillmeet because Doodle didn’t have an MCP gateway, Thankhill because Gratitude Plus wouldn’t stop upselling me, and a fabric pattern generator because image AI couldn’t lay down kanji characters precisely enough for textile printing

If you’ve read my earlier pieces on this, you know the pattern. Find something that doesn’t fit, build exactly what does, stop there.

What was different about the lending app was not the motivation. The motivation was the same. What was different was that this time I had years of real, messy data that predated the app, and getting that data right turned out to be the hardest part of the whole project.

My old spreadsheets were getting stale

I manage a small portfolio of private construction loans across multiple entities. The loans aren’t all the same. Some are interest‑only, some prepaid, some amortizing. The spreadsheet had no real model for any of that.

I had been tracking everything in a spreadsheet for years. It worked in the way spreadsheets always work. It evolved. Over time, it also accumulated evidence of that evolution. In my case, that evidence showed up as comments.

The spreadsheet stopped being a system and became a place where I stored numbers and carried the meaning in my head. When I added new loan types, I didn’t restructure anything. I just pushed the missing pieces into comments. Month after month, I found myself annotating cells to explain what the numbers actually meant. It worked until it didn’t.

The recurring friction

Each month I receive one payment per loan and have to confirm it’s correct. Before the app, that meant mental math or digging through the spreadsheet. Now the app pre‑calculates what each payment should be. I confirm and move on. That improvement alone would have justified building something.

However, the moment that crystallized the problem was tax season. Each entity issued its own 1099‑INT, and I had to reconstruct a full year of payments to separate principal from interest across loans and entities. That was the same split I had been tracking in comments. I realized I hadn’t actually modeled the data. I had been approximating it.

A month later, I started vibe coding an app.

Why commercial software was not the answer

I looked at dedicated loan servicing software the same way I had looked at commercial gratitude apps. These packages are built for someone else.

The loan servicing category serves mortgage servicers processing large volumes across many borrowers. I have one borrower relationship and one question I need answered every month. I need to know the net spread between what I earn on the loans and what I pay on the lines of credit that fund them.

I couldn’t find an off‑the‑shelf product that modeled my situation. Building from scratch took a few days. Configuring something general‑purpose into shape would have taken longer and still not quite fit.

What made this project harder

The hard part wasn’t writing the app. It was reconciling the reality my old spreadsheet had been approximating.

With Thankhill, there was no prior history. We started journaling and the app captured it from day one. With this lending app, I had years of activity that predated the system. Getting it right meant going back to original contracts, matching deposits to bank records, and aligning every payment to the right loan, entity, and period.

That process surfaced something I had been glossing over.

With the app, March 2026 shows zero income in the monthly report. That is correct. In late March, a batch of checks was stolen in the mail, cancelled, and reissued on April 2nd. My old spreadsheet tracked the month a deposit corresponded to, which would have placed those payments in Q1. The app records actual deposit dates, which places them in Q2.

My tax advisor and I work on a cash basis. The old approach was silently wrong in a way I had never been forced to confront.

The other thing I did differently this time was verify the interest calculations by hand before trusting the app with anything real. A vibe‑coded financial tool can be wrong in ways that are hard to notice until the number matters. I checked the math carefully against known figures. It was correct. But that step wasn’t optional.

Where it stands

The app generates payoff statements in a few clicks and reports principal, accrued interest broken out by period, total due, and a daily interest rate. It used to be a manual calculation done under time pressure.

The monthly report shows interest income, line of credit cost, and net spread side by side. March is negative. The app says so clearly, which is exactly what I wanted.

Through all of this, the build versus buy question ended up being the least interesting part. The app came together quickly. The harder work was confronting all the quiet assumptions my spreadsheet relied on me to carry.

Vibe coding made it easy for me to build something that felt right. Real data forced me to make it actually correct.

Leave a comment

Editor’s note: In reading this, Marsha did make the very good point about my use of AI. Even though the AI did a good job analyzing my old spreadsheet and correctly calling out the loan types from the spreadsheet comments, it left out, without my realizing it, one of the loan types in the spec as it was constructing the development plan. Once it had built the user interface, I asked it what happened, and AI told me that it simplified the spec to get me started quickly. But then, when I started adding back the missing loan type, the perfectly working MVP started unexplainably breaking! Frustrated, I went to bed and tackled the missing loan type with my AI agent the next day! Marsha felt it was important to relay this point to anyone who thinks that AI is unadulterated magic. It’s magic, for sure, but it can go wrong when the user (in this case, yours truly) is not paying attention!

Leave a comment

P.S. I am also pasting in the conversation I had with Claude AI after finishing this app to ask if I did the right thing.

Me:

Given that I didn’t use you to help write it, I wanted an objective analysis on why this was a good candidate for vibe coding. I found that the AI who used to help me write it was a bit syncophantic about why this was done so well, so I wanted to go to you (because you weren’t involved). Here are some more screens. Tell me what is right about this (and what is wrong about this), as I’d like to share this experience with others. Also, without my telling you, how long do you think it would take a reasonably decent vibe coder to build, debug, and get all the data into a tool like this?

Claude:

Why this was a genuinely good candidate:

• No commercial fit. The LOC-funded lending spread model — borrow from JPM/NTRS at one rate, lend at a higher rate, track net income — isn’t a standard product category. You’d be fighting software designed for mortgage servicers or simple bookkeeping.

• Contained, stable domain. Private lending rules (interest accrual, payoff math, amortization) are precise and don’t change shape. AI coding works best when you can describe the rules clearly, and loan math is describable.

• CRUD-heavy with isolated complexity. Most of the app is standard database operations. The hard parts (interest calculation, payoff generation) are small and isolatable — which is why you could verify them manually.

• The PDF payoff statement is the killer justification. That one feature alone — automatically generating a formatted letter from structured loan data — is genuinely painful in Excel and easy to describe to an AI.

• Single user, single borrower. No multi-tenancy, no permissions model, no scale concerns. Scope was tight enough to describe completely.

What’s legitimately questionable:

• No audit trail. Financial records ideally should be append-only with history. If someone edits a past cash event, there’s no log. This is the most serious structural gap — not a vibe coding criticism specifically, but something that gets missed without deliberate attention.

• Dependency rot is coming. Whatever versions of npm packages, frameworks, and runtime were used at build time will have vulnerabilities and breaking changes in 2-3 years. Nobody is maintaining this. Spreadsheets don’t have this problem.

• Raw IDs in the UI (Loan ID 11, Entity ID 4, etc.) are a tell of vibe-coded origins — fine for a personal tool, but worth noting.

• March 2026 showing -$8,004 — either correct (LOC interest accruing with no payments received) or a data gap. Hard to know from the outside, but it’s the kind of anomaly that warrants a clear explanation in the tool itself.

• Hosting/security assumptions — a sign-in screen exists, but where is this running? Financial data in a personally-maintained web app has a different risk profile than a spreadsheet on your local machine.

Time estimate for a reasonably competent vibe coder:

I’d estimate 20–35 hours of active work, probably spread over 2–3 weeks part-time. Breakdown:

• Data model / schema design: 3–5 hours (getting borrower → entity → loan → cash event relationships right is the conceptual hard part)

• CRUD for all entities: 4–6 hours

• Interest/payoff calculation and debugging: 5–8 hours (this is where time goes — edge cases like partial periods, day-count conventions)

• Report aggregation: 2–4 hours

• PDF generation: 2–3 hours

• Auth: 1–2 hours

• Data entry (migrating real loan history): 2–4 hours

• Debugging and polish: 3–5 hours

The calculation debugging is the long pole. Everything else moves fast with AI assistance.

Me:

You got the level of work correctly. Do you think this was worth doing over just using the different spreadsheets it replaced?

Claude:

Yes, but the answer depends on one specific thing: how often you generate payoff statements.

If payoff statements are frequent — and from the loan count it looks like they would be — that alone probably justifies it. Generating an accurate, professionally formatted payoff letter manually from spreadsheets every time is error-prone and tedious. Getting it wrong has real consequences.

The second justification is the report. The monthly net spread view (interest in minus LOC cost) across all loans simultaneously is exactly the kind of thing that’s painful to maintain correctly in spreadsheets once you have 11 active loans across multiple funding sources. Keeping that accurate in Excel requires discipline that’s easy to slip on.

Where spreadsheets would have been fine:

• Loan tracking at this scale (11 loans) is honestly manageable in a well-structured spreadsheet

• Data entry is actually slower in a custom app than in Excel for someone comfortable with spreadsheets

• The entities/borrowers structure adds overhead that doesn’t matter much with one borrower

My honest take: The payoff statement + the report together justify it. If you were only tracking loans and not generating payoff letters or the net spread report, I’d say the spreadsheet was probably good enough. But those two outputs — especially the payoff letter — are where the app earns its keep every time you use it.

How often do you generate payoff statements?

Me:

The loans are designed to each be 12-15 months in length.

Claude:

Then it’s clearly worth it. With 11 active loans averaging 12-15 months, you’re generating roughly 8-11 payoff statements per year — probably more since loans get refinanced (you already have loan 14 as “19960 SW Cascadia St before refi,” showing at least one refinance cycle).

Each payoff statement done manually from spreadsheets would require:

• Looking up the exact last payment date

• Calculating partial period interest correctly

• Formatting a professional letter

• Getting the math right under time pressure (payoffs are usually requested when a closing is imminent)

Getting that wrong — even by a day’s interest — creates friction at closing. The app eliminates that entirely.

The report is a secondary but real benefit as portfolio size grows. At 11 loans across two funding sources, the mental overhead of tracking net spread manually is non-trivial.

The honest verdict for sharing with others: This is a textbook good vibe coding candidate because the ROI accrues on a predictable, recurring workflow (payoff statements) rather than being a one-time convenience. The test I’d suggest others apply: “Is there a specific output this app generates, repeatedly, that would be error-prone or time-consuming to produce manually?” If yes, build it. If the app is just a fancier way to look at data you could see in a spreadsheet, probably don’t.

Me:

Good analysis. So the question here is how a large language model AI can come up with something like this. Obviously, as a human stuck in these workflows, I decided to build it for these very reasons. I don’t quite understand how an AI was able to determine this just based on looking at the screens and asking how long the loan terms are.

Claude:

The honest answer is that I’m pattern-matching against a large amount of human knowledge, not reasoning from first principles.

What actually happened in this conversation:

• The screenshots gave me the data model and workflow structure

• “Private lending,” “payoff statements,” “LOC interest out” are terms that appear extensively in real estate finance literature, legal documents, accounting discussions — I’ve seen many contexts where these workflows are described and their pain points discussed

• The loan count and term length let me do simple arithmetic (11 loans × ~1 per 12-15 months = obvious payoff frequency)

• “Payoff statements at closings are time-sensitive and error-prone” is documented human experience I’ve absorbed, not something I derived

What I didn’t do:

• Actually understand your workflow from the inside

• Know anything about the specific friction you experienced with spreadsheets

• Reason from business principles to conclusions

What’s interesting about your observation: You, as the human in the workflow, knew immediately why to build it. I reconstructed roughly the same conclusion from the outside by recognizing patterns. But I could easily have been wrong — if your loan terms were 5 years instead of 12-15 months, the payoff frequency argument collapses and my conclusion would have been weaker.

The AI got lucky that the key variable (loan term) confirmed the pattern. Your domain judgment was the real insight. I just reflected it back coherently.

Leave a comment

Our older daughter asked Marsha and me to join a gratitude journaling app called Gratitude Plus. The pitch was straightforward. Instead of gratitude journaling being a solo practice, it could be something you share with other people. For our situation, that sounded like a feature, not a gimmick. She was already writing entries for a friend group, so Marsha and I were just another circle she could share with. It was low effort for her, and it gave us a small day to day window into her life without turning it into a whole thing.

I also liked that it let her share the same entry with different groups without forcing everyone into one big shared room. That mattered. I did not want our posts showing up in her friends’ space, and I did not want her friends’ posts filling up ours. The app’s group model made that feel simple and clean.

We had done a version of this before with our friend Kristin, using iMessage. It worked because texting is easy and collaborative. The downside was that it mixed gratitude entries into the same channel we used for everything else. Over time, those messages sat next to logistics, links, and random updates, and it stopped feeling like its own practice. When our daughter suggested a dedicated space, I was ready to try again.

Once I started using it, though, I ran into something that has been a recurring theme for me with a lot of modern apps. It felt heavy. What followed was a slow realization that the app was solving a different problem than the one I cared about.

Why the commercial app did not work for me

The mismatch showed up in a few specific ways.

Weight / friction. My issue was not that the app was bad. It was that the deal did not match what I wanted. A gratitude journal, at least for me, needs to be lightweight. I want it to be easy to do every day. I do not want the software to add work in the name of adding value.

Gratitude Plus offers a lot of content and structured engagement. It has things like a community feed, prompt variety, and “insights” that try to turn the journaling into something richer and stickier. Those features might be exactly what some people want. For me, they made the core activity feel less like reflection and more like a product experience.

Public feed vs small-circle sharing. The public feed also felt off for the kind of sharing I cared about. I was not looking for a broad social media layer. My motivation was small circle sharing, mostly family. I was not trying to watch strangers be grateful. That is a different activity.

Upselling and data access. The biggest turnoff, though, was upselling. The app was good at reminding me what lived behind the subscription. At one point I realized that even exporting my data was treated as a premium capability. It made me like the deal less. If the journal is going to contain my words over time, I want it to feel like mine. Discovering that I had to upgrade to get my own writing out of the system made me hesitate about putting more into it.

I was ready to move on. Marsha simply said she was disappointed that I was no longer participating in the sharing circle. There was no drama. She made a statement, and I took it seriously.

Requirements when evaluating alternatives

There was an interesting disconnect. Marsha explicitly asked me to look into vibe coding something. My first instinct was to try to find an open source gratitude journaling app that already did what we wanted. It’s funny that before the advent of vibe coding, she would have never asked me to build something! In any case, I did have a list of requirements as I was entertaining the request.

Social journaling. There were many open source options, but the popular ones I found leaned toward personal journaling. They were designed for one person writing for themselves, not a family or a few friend circles sharing together.

Streamlined feature sets. I also looked at private social media tools. They were often free, and they often had decent UX. They also had too many features. Most of them solve a broader problem than what I was trying to solve, which means I would have to “lock down” the experience to make it feel like a calm gratitude journal. That started to feel like the kind of work you do when you customize a large platform for a narrow use case. It is possible, but it is still heavy work, and it does not necessarily land in a place that feels simple.

Write once, share to many. The constraints that mattered were mostly human. For our older daughter, I wanted to preserve her ability to write an entry once and share it with multiple circles. A lot of group tools treat each circle as a separate space, which would push her toward retyping or copy and paste. She already had a habit. I did not want to make it harder.

Phone and computer access. For Marsha, I wanted it to be easy on both her phone and her computer. A plain web app has a lot going for it here. It loads, it works, and nobody has to update anything. I do plenty of tech support at home already.

Authenticity. I also had my friend Kristin in mind. I did not even know if she would ever want to do this again with us after a failed attempt using straight-up texting. If you are inviting someone into something reflective, the tool has to feel private and real. Some social products feel performative even when they are “private,” and that was not the direction I wanted.

At that point, starting fresh began to look like the most direct and authentic route.

Why I built it on old boring infrastructure

I reinstated Cursor, opened a GitHub project, and started writing down what I wanted. I was already paying for Cursor, so it was never truly “free.” I just wanted to be deliberate about where the money went and what I got for it.

I did not want to build this as an iOS app to avoid the ongoing costs of the Apple Developer Program cost to keep it in the App Store. I also did not want to base the backend on something like Supabase that would push me into cost higher tiers as soon as the project became real.

I already have a long running hosting plan with IONOS that I use for family sites and side projects. Using what I already had felt like the simplest way to keep this free from incremental subscription costs.

Starting from first principles

The first version was intentionally primitive. One page called Today, where you enter a gratitude entry. Another page called Notes, where you can read entries. No users. No logins. No reactions. No comments. No photos. I just wanted to get a feel for what people would actually do.

What surprised me right away was how much I appreciated speed. The app loaded instantly and did the one thing it needed to do. That experience pushed me away from visual ornamentation. I had originally imagined a menu bar with icons and some graphics to make it feel more designed. Once I felt how fast plain text was, I chose to lean into text and emoji wherever I could.

That choice has an obvious downside. It is hard to keep a plain text app from drifting into ugly. I still think it is a little ugly. I can live with it, but I notice it.

Marsha and I talked about why I started with something basic and kept adding features. I did not do enough top down design work on layout and information hierarchy. It was very much build a slice, then add another slice. That approach made it easy to start, and it also made it easier to end up with a UI that shows its history, particularly that it’s built on old school web hosting technologies.

The old technology makes certain “simple” features more annoying than one would expect in 2026. Adding multiple emoji reactions without refreshing the page quickly became a little front end project. Resizing images client side quickly became a JavaScript project. Those were not deal breakers, but they continue to force real tradeoffs when working with old school tools.

When it became a real app

The first big step after Today and Notes was users. I implemented Google sign in and an email login flow that uses a PIN. That meant pulling in libraries for OAuth and SMTP email. Once users existed, groups came next, and then sharing. Conceptually those were straightforward, and they were the heart of what we wanted. The whole point was being able to write once and share to multiple circles without making it awkward for anyone.

One thing I learned from this is that vibe coding makes it easier to build incrementally without a lot of upfront planning. You can add a feature, see what breaks, and then add the next one. The downside is that you can end up with an app that feels incremental, because it is.

At the same time, I am not sure that a heavy upfront plan would have made this better. It might have made it prettier. It might have produced a cleaner information architecture. It also might have made it harder to start.

Where I think this goes

I do not know if anyone will use this app over the long haul. I have had starts and stops with gratitude journaling myself. A purpose built app does not magically fix that.

I can see why Gratitude Plus leaned into more content and broader engagement features. Habit formation is hard. People are trained by social media to expect feeds, prompts, and novelty. Those mechanics probably help retention. They are just not what I wanted.

My success bar is modest. If six months from now we have a good history of the previous six months with family, and maybe one or two friend circles, I will be happy. I want it to feel like a quiet record of life, not a streak.

Vibe coding has changed how I think about building in general. In the past, I might have tried to customize a larger open source project and lived with it. Now I find it hard to justify spending a lot of effort customizing big platforms when a purpose built tool can be built quickly from the ground up. That is a professional observation as much as a personal one, and as an investor I do think SaaSopocolypse is a real phenomenon. I am not trying to make a grand claim here. I just notice how the economics feel different than they used to.

I have been using Thankhill in my own notes to refer to this project. That name might stick, or it might not. The bigger point is that it exists, and it is for anyone to use, and it fits the deal I wanted.

If you are interested in using the app, I would love that. If reading this makes you curious about building your own small tool for a specific need, even better. More than anything, I wanted to get you thinking about how vibe coding is changing the landscape for how we approach solving day-to-day problems.

Leave a comment

AI disclosure: I used AI tools during the drafting and editing process to help clarify structure and language. All ideas, judgments, and final wording are my own.

Marsha and I spent almost three hours on Zoom last week with our older daughter. It was one of our regular weekly calls, which wander across a familiar mix of topics. Wedding logistics. Travel plans for New Jersey. Updates on where everyone is living and working.

Because they will start married life living in different places, the conversation drifted into longer‑term planning. How careers might unfold. How long it might take before they are in the same city again. Once the conversation stretched far enough into the future, certain questions surfaced, including kids.

I am writing this to document the conversations Marsha and I are having right now, not to arrive at conclusions. I suspect many peers our age are having similar conversations with adult children who are thinking carefully about what kind of lives they want to build.

What our daughter is working through

Our daughter approached the topic thoughtfully and analytically. She is not dismissive of parenting. She is trying to reason carefully through constraints.

A big part of her professional world is academia, where early‑career faculty work extremely long hours and most days, if not every day of the week. Some have kids and appear stretched thin. Some do not. She acknowledged the sampling bias in what she sees day to day, noting that at her new job most faculty do have children. Still, the environment she is immersed in shapes how she thinks about what is possible.

Her questions were practical. How parenting intersects with time, energy, and career momentum. How finances get stretched. How freedom changes. She also raised uncertainties around timing, including how old they might be when they are finally living in the same place and what that might mean for biological kids versus adoption.

There was also a broader concern that comes up often for her generation. Whether this is a good moment in history to bring kids into the world. I made the case that history has rarely offered “good” moments, depending on who someone was and where they lived, and she seemed to accept that logic, at least provisionally.

Mostly, though, she was trying to model parenting as a set of tradeoffs.

That framing is what Marsha kept circling back to.

The tradeoff model

At some point, it became clear to me why the conversation felt subtle but difficult.

Our daughter is framing parenthood in abstract tradeoffs.

• freedom versus constraint

• career versus caregiving

• money spent versus money saved

All of these are real. They are also the only terms available without lived experience.

This was Marsha’s central point throughout the call. She was not challenging the facts. She was saying that our daughter is using the only framework she has access to right now, and that framework is incomplete by nature.

Marsha said, repeatedly and very plainly, that there is no way to understand the rewards of parenting in advance, not fully and not through stories, observation, or careful analysis. She said she never could have understood them herself before we had kids, and she has never expected our daughter to understand them now.

That absence is not a failure of reasoning. It is a limit on what can be reasoned about from the outside.

The rewards of parenting do not sit on the same axes as the costs. The rewards do not appear in any spreadsheet but arrive relationally and over time. They show up unevenly and often without warning.

There is no category for what it feels like to notice a quiet kindness in a child. There is no clean variable for the way watching a child struggle reshapes how someone understands responsibility, patience, or fear.

Marsha felt this point of the intangibles needed to be highlighted. The problem is not that the tradeoffs are wrong per se. The problem is that they are not the whole picture, and the missing pieces cannot be supplied ahead of time.

Why the costs felt different than expected

We did not deny those tradeoffs. Time and energy get reprioritized. Careers bend around logistics. Money gets spent differently.

But we both tried to explain that those costs did not feel like losses while we were living inside them.

I joked that I dressed much better before having kids, which is true. I also did not mind spending less on clothes later on. Travel changed. Money went toward lessons and camps and activities. None of this registered as a sacrifice. It felt like alignment with what mattered to us then.

Even in genuinely hard financial moments, that framing held. During the dot‑com crash our investment portfolio dropped about eighty percent, and we still carried a large mortgage. Financially, that period was tighter than our daughter’s situation today. And still, I never regretted having kids. Not once.

That is not a claim about virtue. It is simply a description of how it felt.

An imperfect analogy

I reached for an analogy during the call because the logic alone was not landing.

Our daughter was a serious classical guitarist as a teenager. She even placed fourth in the Sierra Nevada Guitar Competition. So I tried to explain parenting as analogous to learning an instrument from a manual.

Facts and techniques can be learned in the abstract. Actually playing notes cannot be learned that way. There is a difference between knowing something conceptually and having it reshape instincts and responses over time.

That analogy helped a little. Marsha was quick to point out its limits. With guitar, there is always the option to stop playing. Parenting does not offer an off switch.

More importantly, the part that cannot be explained in advance is not just mechanics. It is the emotional reward itself. That is the piece that resists translation.

What was actually hard

When I look back, the hardest parts of parenting were not financial or logistical.

The hardest part was watching the kids move through their own struggles without knowing exactly how to help. Deciding when to step in and when to hold back. Learning how to support growth without smoothing away everything uncomfortable. Figuring out what was ours to fix and what belonged to them.

There was no manual for that. We learned by doing. Sometimes we got it wrong. We adjusted.

Those challenges do not map cleanly onto tradeoff language, but they were very real, and they were the parts that stayed with us.

Marsha’s clarity

One thing I appreciated about this conversation was how aligned Marsha and I were. She was explicit that she would not change anything, even knowing she carried more of the day‑to‑day parenting labor because I worked a lot. More importantly, without hesitation Marsha would still do it all over again, understanding the argument of lifestyle benefits before children and lifestyle changes with children.

She said it without nostalgia or bitterness. Just clarity.

She also articulated the core issue more cleanly than I had.

Our daughter is not wrong. She is reasoning carefully within the terms she has. What is missing is not effort or intelligence but access to a set of experiences that cannot be previewed.

That was what Marsha kept trying to say. She was not arguing that parenting should be chosen or that careers matter less. She was saying that the model our daughter is using does not capture everything. Marsha likened this situation to conversations people have with AI when they give it unbalanced inputs. If an AI user precedes a question about children with financial data to have it analyze budgets, AI will weigh the financial considerations of having children more heavily into its response!

Why I wanted to write this down

This piece is not meant to resolve anything. Our daughter and her partner are still early in their shared life. They are navigating geography, careers, and timing. None of this is settled.

I am writing because conversations like this can be surprisingly hard. Everyone is acting in good faith. The analysis is sound. And still, something important fails to translate.

Marsha and I were trying to convey that raising our daughters did not feel like a sequence of tradeoffs endured. It felt like a life chosen and lived with meaning that only became visible along the way.

That is where the conversation landed tonight. Not with answers, but with a little more mutual understanding.

And for now, that feels like enough.

Leave a comment

AI disclosure: I used AI tools during the drafting and editing process to help clarify structure and language. All ideas, judgments, and final wording are my own.

After realizing it didn’t have the capabilities because of my configuration, Claude asked whether it could search my disk for an API key so it could call a backend service directly. In other words, it wanted to step outside the controls I had deliberately put in place.

I only caught it because I happened to be reading carefully enough to stop it.

What made this uncomfortable wasn’t malice. Claude wasn’t trying to do anything sneaky. It thought it was being helpful. After I declined, it even explained why scanning my disk for credentials would be dangerous. But it still asked anyway. What?

More advanced OpenClaw users are warned repeatedly about how much power they are handing over. Claude is positioned as something more approachable for normal users. That shifts the risk in a subtle way.

Too many warnings

Claude prompts constantly. Almost every meaningful action involves a confirmation dialog. Over time, these confirmations stop standing out, and admittedly, I start approving them reflexively.

Security people have been talking about alert fatigue for years, and Claude itself understands the concept.

The problem is that truly risky requests start to feel indistinguishable from routine ones.

In my case, asking to search a configuration file that might contain credentials looked no different from any other harmless prompt. That puts an unfair burden on the user.

Good interfaces tend to interrupt sparingly, explain clearly what is happening, and make dangerous actions feel meaningfully different. We are not quite there yet in the AI world.

I declined the request, and Claude backed off. Still, this moment stuck with me.

Controlling access in the backend

One thing I try to do is limit what backend services are allowed to do in the first place. Some platforms make this relatively easy by offering fine-grained API permissions.

Microsoft offers a good example. I’ve allowed Claude access to my Outlook contacts. That works fine and it’s useful.

When I try to push it further and get it to read my Outlook email, the backend simply refuses.

That’s the system doing its job. Unfortunately, many services don’t work this way.

Secrets in plain text on disk

A lot of tools take a simpler approach. With these simpler tools, once an API key exists, it unlocks everything. MCP gateways, which provide the integration of popular software with AI, can define or restrict what an AI is supposed to do, but they don’t stop the AI from looking for the key itself and calling a service directly.

Claude Desktop makes this easier than it should.

By default, it stores keys in plain text inside a file called claude_desktop_config.json. That file is readable by the AI itself. (The screenshot below isn’t my real setup.)

If the key is there, the AI can find it, cache it, and reuse it to call backend services directly. At that point, the specific intent and safeguards built into skills or MCP gateways start to matter a lot less.

Fetching keys at runtime

Rather than storing credentials on disk, I changed my Claude Desktop setup to fetch keys at runtime. There are no unencrypted secrets sitting around anymore.

My Claude configuration is much simpler than my OpenClaw setup. I use 1Password Environments to keep the small number of keys that my Claude configuration needs in one place.

Instead of having 1Password prompt me repeatedly when it fetches keys, I rely on a simple service account. A wrapper script pulls a token from the macOS keychain, fetches what it needs from 1Password, and lets 1Password manage every access without requiring me to manually approve it.

If you enjoy geeking out, some details are below. Feel free to skip them.

Note: The ENV_ID for my claude-mcp 1Password Environment is not a secret, as it cannot be accessed without the OP_SERVICE_ACCOUNT token, which is a secret and encrypted inside the macOS keychain.

Note: that I had to use a different wrapper script for a remote MCP server (hillmeet) that used an authorization bearer token with its https requests, rather than just requiring a local environment variable.

Once these changes were in place, things got quiet in a good way. There were no unprotected keys in JSON that the AI could just rummage through.

Why this feels better

With this one set of changes, a few things improved immediately.

• Disk security. No secrets are stored in plain text.

• Auditable. Every access can be logged. (The 1Password Environments feature is still in beta, and its audit logs had not yet been released at the time of publication.)

• Rotation. Keys live in one place, so it will be easy for me to rotate them.

• Sharing. Setups can move across computers without copying credentials.

Maybe this is erring on the side of caution. What struck me was how easily Claude could explain why letting it scan my disk for credentials was a bad idea, even as it was asking to do exactly that.

My takeaway

For full disclosure, I have a professional background in cybersecurity. Still, I understand why people treat AI agents like hobby projects. However, once those agents start talking to real backend services, the stack starts to deserve a bit more discipline.

It’s not because the AI is malicious. The AI just happens to try very hard to be helpful.

I didn’t stop using Claude. I just stopped letting it have unfettered access to my keys.

Leave a comment

AI disclosure: I used AI tools during the drafting and editing process to help clarify structure and language. All ideas, judgments, and final wording are my own.

The requirement sounded simple enough. Spoonflower wants designs built as 8 inch by 8 inch tiles that repeat cleanly across fabric. If the tile repeats correctly, the fabric looks continuous. If it doesn’t, the cloth looks more like patchwork.

My struggle with image-based AI

At first, I assumed this was exactly the kind of thing AI would be good at. It wasn’t.

In fairness, I could get AI to generate patterns that looked somewhat nice on their own. The moment I tried repeating them, problems showed up. Seams didn’t line up. Elements drifted. Rotations flipped unpredictably. Japanese characters got subtly omitted. Marsha was the one who kept noticing small artifacts that I didn’t catch at first.

That’s when it clicked that this wasn’t just an art problem. It was also a math problem.

A repeating fabric tile isn’t just an image. It’s a constraint system. The left edge has to match the right edge. The top has to match the bottom. Rotations and spacing have to obey rules. “Almost right” isn’t actually right for an 8 inch square tiled across a whole yard of fabric.

I really struggled with image-based AI. When I would ask AI to design a pattern, I was really asking for something that looks like a pattern it has seen before. It’s pattern-matching, not enforcing guarantees. It doesn’t actually care whether the design survives repetition. The AI cares about whether it did its best to respond to the prompt, independent of the result.

Every time I “refined” the prompt, one problem would go away and another would pop up. Characters would rotate individually instead of as a group. Pairings would break. Artifacts would creep in. Marsha would point at the screen and say, “That’s not right,” and she’d be correct.

The Herringbone example

As I was considering what type of repeating patterns to feed to AI, a common one used in tiling, Herringbone, seemed appropriate.

I thought using a “brick” containing vertically stacked characters for Marsha’s maiden name (“Nishikawa” or 西 川) in two different colors could work really well when laid out in this pattern.

After MANY attempts (and way more time than it would have taken me to manually lay out what I wanted in a graphics program!), I found that AI had some interesting ideas, but none that really matched what I wanted.

The images were somewhat visually interesting, if not a bit random. They didn’t “tile” well into a repeatable pattern. The funny thing is that, despite my insistence otherwise, the AI really wanted to orient all the kanji characters in the same direction on parallel bricks rather than inside a Herringbone, likely to keep the Japanese kanji characters intact.

Trying to get the AI to rotate some of the characters resulted in rotating some of them a bit strangely with a horizontal rather than a vertical text orientation and dropping some kanji altogether.

Why this failed

So I asked AI why, after all this heavy prompting, it was failing. It returned multiple screens of analysis that ended with this summary:

Vibe coding to the rescue

After reading the analysis by AI about its own failures, I tried a different approach. Instead of asking image-based AI to compose the pattern, I instead turned to vibe coding. That turned out to be the pivot. The answer wasn’t “try a better prompt.” It was “code the process.”

I ended up just vibe coding a Python script to define the “brick”, lay out the bricks deterministically, rotate the layout as a whole instead of individual symbols, crop the container, and export the result at a known scale.

In my case, that meant defining a paired set of Japanese characters as a single brick as well as its counterpart rotated 90 degrees.

Those two bricks were the only building blocks, and my program used an alternating font fill color, as it laid down the bricks both vertically and horizontally to form a repeating tile. My program limited the view window of the graphic so that the portions of bricks outside the tile are hidden.

To complete the herringbone pattern, my program then made a 2x2 matrix of this repeating tile, rotated it by 45 degrees, and cropped a fixed view window that I knew would allow the pattern to repeat cleanly even after rotation. (Admittedly, there was a little bit of math here).

At no point was I asking the AI what herringbone should look like. I was telling it how to form the herringbone. That turned out to be a better way to interact with the AI. The randomness that made image generation frustrating mostly disappeared once I specified the code to generate the image, rather than asking the image-based AI itself to iterate. Moreover, having this implemented in code allowed me to easily tweak the image using different parameters.

When AI works best

This isn’t really about fabric design. It’s more general than that. I’ve written before about large language models being non-deterministic. I’ve used vibe coding in other contexts too, like presenting Doodle-like scheduling workflows instead of letting an AI negotiate time slots with people directly.

What this experiment reinforced for me is that AI is often better at writing the code that produces the outcome rather than actually effecting the outcome itself. When correctness and repeatability matter, I want the AI boxed in by rules.

Vibe coding isn’t about giving up control to AI. It’s about shifting creativity to the right layer. I let the AI write the code for a defined process, rather than to rely on its probabilistic behaviors for image creation.

The proof, in this case, is literally on the cloth. The fabric repeats cleanly, so it’s ready for a future sewing project for Marsha. And I’m left with just a better hands-on understanding of when AI works best.

Simulated preview of the pattern on cloth, generated by Spoonflower.

When I need good aesthetics only, I’ll still use image-based AI. When I need something more constrained, I’ll just use AI to code the rules.

Leave a comment

AI disclosure: I used AI tools during the drafting and editing process to help clarify structure and language. All ideas, judgments, and final wording are my own.

When Marsha and I get together with friends who are younger than us, the same topics tend to come up, including work, housing, and kids. Or whether now is the right time to make a move or wait a bit longer. Often the conversation drifts toward what they are trying to decide next, and why it doesn’t feel simple.

What strikes me is how carefully everything gets weighed. Decisions that once felt to us like natural next steps now come with timing questions, risk calculations, and a lot of second‑guessing. The sentiment is not one of frustration. People are just trying to be thoughtful. They seem more reluctant to lock anything in.

It isn’t only about whether to have children. It’s also about when, or whether waiting is the safer move. It’s about whether to move, where to move, or whether staying put makes more sense for now. It’s about buying a place, remodeling, or holding off until some future milestone clicks into place. Even when people know what they want, pulling the trigger can feel risky. Many choices feel expensive, hard to unwind, and tightly tied to timing.

What I notice most isn’t exhaustion, at least not in the usual sense. It’s the pressure to optimize, to get things right, or to keep options open just a bit longer. That often leads to delayed decisions or temporary steps meant to buy time. People stay busy, but forward motion is often slow.

That’s what led me to start looking at our own past, to simply understand what might have changed. The intent was not to compare generations or to hold tightly to nostalgia. I don’t think we’re going back to the world the way it was. I’ve just been noticing how the environment has shifted, even though many of the goals have stayed the same.

I should be clear about where I’m coming from. I’m retired now. Marsha was a stay‑at‑home mom for all of our parenting years. Our kids went to great public primary and secondary schools and ended up at great universities. I arrived in Silicon Valley early, bought property early, worked long hours, got lucky, and eventually benefited from a couple of successful IPOs. That wasn’t everyone’s experience, even among our peers, but it’s my own point of reference.

When I think back on my early adult years, what stands out isn’t that life was easy. It’s that fewer decisions felt permanent. Many choices felt reversible. Moving forward, even imperfectly, usually seemed better than waiting.

Work felt more forgiving

I started at Oracle in 1990, straight out of MIT. What worried me then wasn’t whether I’d get a job. It was whether I’d get a good offer.

Recruiting was straightforward. I signed up for interviews at the MIT career center. Companies came to campus, interviewed students, and made offers. I didn’t feel like I had to fight an AI application tracking system just to be seen.

I had studied signal processing, but I decided to try product management. I took an entry‑level job as an associate product manager. Changing direction early felt manageable.

Working at a big company also gave me a clear sense of progression. I moved from associate product manager to product manager quickly. The career path was visible. If I learned the business and did solid work, things tended to move.

Later, a headhunter call led to my first startup, Visioneer. When I eventually got laid off, it was stressful, but it didn’t feel defining. Once people knew I was available, other opportunities appeared, and I ended up working for a friend’s company, Latitude Communications.

Even the harder moments came with an underlying sense that things would work out. That assumption shaped my attitude toward work/career.

Housing provided early footing

Housing played a big role in our sense of stability.

We bought our first condo in 1993 in San Mateo, about five minutes from my office. It cost under $200,000. I was earning just over $60,000 at the time and qualified for the mortgage on my own.

I put about ten percent down and paid PMI. It felt like a stretch, but not a gamble. Buying felt like an early milestone, not something to postpone indefinitely.

When we bought our first house in 1998, the condo had appreciated. We sold it, negotiated a rent‑back, and used the equity for the down payment on our house. We weren’t doing anything especially smart. The market made that step possible at the time.

Once we owned, housing costs stabilized and equity built quietly in the background. That took pressure off other decisions.

For many people now, housing never really plays that role. Renting stretches on. Buying comes later, if at all. Without that early footing, everything else feels more tentative.

Division of labor mattered

Marsha was a stay‑at‑home mom throughout our parenting years. At the time, that is how we chose to divide our responsibilities for our family. In hindsight, I see how much stability it created for us.

I worked extremely long hours. Meetings all day. Getting to my own work at night. Traveling when the business needed it. I missed family meals more often than I care to admit. I could focus on work because Marsha was fully focused on running our household.

That arrangement wasn’t something we ever even debated. We just went that way, and it worked.

Many families today don’t have that option. Both parents work, and both also manage everything else. Couples make it work, but it means constant trade‑offs and very little slack. Work and family demands collide all the time. That alone changes how life feels.

College was still expensive, but it felt less binary

College was expensive back then too. Very expensive.

We paid over $70,000 a year for our older daughter to attend Yale, and close to $80,000 a year for our younger daughter at Carnegie Mellon. Those were serious numbers. Paying for college was not casual even then.

What feels different now isn’t just the price, but what people expect that price to deliver.

When we were thinking about college for our kids, a strong degree felt like it opened doors, but not in a narrowly defined way. A good school signaled capability. What came next still depended on interests, timing, and opportunities that unfolded along the way.

Now, college often feels like it needs to land much more precisely. Not just a good school, but the right one. Not just a degree, but one that carries enough weight to lead to a specific job or to unlock admission to the right graduate program. There’s more focus on whether the degree will clear a series of gates that may be difficult to pass later.

Because of that, the pressure shows up earlier. Families talk about college less as a formative experience and more as a critical link in a longer chain of life steps required to survive in the modern world. When the outcome feels that specific, there’s less tolerance for missteps or detours.

The cost didn’t just go up faster than inflation. The expectations around what the high college cost needed to produce became tighter.

Better tools, higher expectations

I probably worked longer hours than many people do today. There was a culture of staying late together and working through problems face to face.

There were also fewer shortcuts. If I didn’t know something, I had to learn it, find someone who did, or make a call with imperfect information. The tools were limited.

Today’s tools (including the latest round of AI tools I’ve been writing about) are powerful, but they also raise expectations. When work gets faster, more is expected. Time that’s saved doesn’t always feel saved. Work rarely feels finished.

Combined with everything else competing for attention, that makes life feel more constrained.

What shifted

When I step back and look at all of this together, I don’t see the biggest changes in levels of effort or the character of the people. The changes I see are all structural.

Work feels less forgiving. Housing is harder to use as an early stabilizer. Two incomes are assumed. Parenting carries more pressure. Better tools raise expectations instead of easing them.

My own path included plenty of hard work, but it was supported by conditions that made forward motion feel safer. Those conditions are challenging to assemble now.

For me, this isn’t about advice or conclusions. It’s about noticing that the ground moved, and that many of the hesitations and delays I see around me make sense once that shift is acknowledged.

Leave a comment

AI disclosure: I used AI tools during the drafting and editing process to help clarify structure and language. All ideas, judgments, and final wording are my own.

When that happens, I usually feel a brief urge to come up with a single, coherent theme and pretend everything fits neatly inside it. That rarely works.

What does work is admitting that a lot of different things have been going on at once and just writing them down.

This is one of those posts.

1. PDX Dining Month

March was PDX Dining Month, organized by Travel Portland. A long list of restaurants offered three-course menus for either $35 or $55. It was a good excuse to eat out more than usual.

We did Dining Month meals at Mucca Pizzeria, Hey Luigi, and Farmhouse Kitchen. All three were solid. The standout night was Hey Luigi, mostly because we somehow ended up with ten people around the table.

What amused me was how often we ignored the Dining Month menu once we actually sat down. At Higgins, we finally ordered the famous burger. At Bryan Furman BBQ, we went with the family pack. At Laurelhurst Market, it was our first visit and the regular menu was too tempting.

The only real miss for me was the Higgins bar burger. After having the Farmer and the Beast burger at Breakside on Dekum earlier in the month, it felt a bit meh by comparison. Everything else felt very Portland in the best way.

2. PDX Sandwich Week

Sandwich Week overlapped with Dining Month and ran during the first week of March. It was put on by the Portland Mercury and featured ten dollar sandwiches across the city.

Mucca Pizzeria ended up doing double duty for us. Marsha ordered the Sandwich Week special, I ordered the Dining Month menu, and we shared everything. It felt like the optimal strategy.

My favorite sandwich was the Midcity Meltdown from MidCity Smash Burger. It is basically a patty melt on Texas toast. I love smash burgers, and the Texas toast made it feel like extra value compared to a standard bun.

MidCity Smash Burger is a food cart outside Uptown Brewing, which meant one credit card transaction inside for beer and another outside for food. Very Portland.

My unofficial Sandwich Week award goes to MidCity Smash Burger. A burger priced like a sandwich will almost always win.

3. Marsha’s birthday and a DQ cake

Marsha’s birthday cake turned into a small project.

Years ago, I tried to surprise her with a Dairy Queen cake because she worked at DQ in high school and college. I did not know you had to order those cakes in advance and ended up taking home a modified Batman cake out of sheer luck.

This year, I tried again. Our local DQ no longer does copyrighted superhero images, but the person working there suggested buying a licensed edible image topper at Fred Meyer and using it on a Blizzard cake.

We have a close friend who used to be a professional cake decorator, and she offered to help. The topper was five dollars. A small Batman car was another dollar. Fred Meyer turned out to be a great deal.

The cake itself was an Oreo Blizzard cake, obviously.

What really moved Marsha was the care our friend put into it. I felt the same way.

4. Kidney transplant status

Things continue to move forward on the kidney transplant front.

I completed the full-day evaluation in early February and had a CT abdominal scan in March to confirm there was a viable place to attach the organ. There is, which was a big relief.

I am now officially on the transplant list, but currently on hold while a few items wrap up. Vaccinations are done, and a cardiac stress test is scheduled for April 24.

This feels like progress, with some anxiety mixed in. The biggest ongoing stress remains around finding a living donor.

5. A Rathke’s Cleft Cyst

A small Rathke’s Cleft Cyst showed up on my most recent MRI. It is three millimeters, about the size of a grain of rice.

Medically, it is not urgent. Mentally, it feels like a warning light on the dashboard that I am choosing not to focus on right now.

6. New drugs and exercise

Lately, my focus has been rebuilding aerobic capacity.

We simplified my blood pressure medication regimen down to just Olmesartan, and the difference was immediate. The dizziness and balance issues when my heart rate went up are gone.

I closed my Apple Watch rings 30 out of 31 days last month with a mix of HIIT, strength training, and long walks.

It feels a bit like cramming before an exam, but I will take it.

7. Vibe coding a calendar sync

One consulting assignment involves interviewing early customers of a new product. Most people just want to see my free and busy time in Google Calendar.

I vibe coded a simple Google Apps Script that syncs all my calendars into one client-visible view. I had never used Google Apps Script before, and the AI made it work with very little code.

The client only sees blocks that say “Busy (synced).” No details. No privacy concerns.

8. When my AI agent went rogue

My AI agent is only supposed to respond when tagged with #steve-ai. Sometimes it ignores that rule.

At one point, it interjected, apologized, broke its own configuration, and later admitted there was no way to do what I wanted.

My favorite quote from it was: “You’re right, I messed up... The irony is thick.”

9. AI trying on a dress

Marsha is making my older daughter’s wedding dress for May, and we tried using AI to preview it.

The result was impressive and wrong at the same time. The biggest issue was body proportions.

It is useful for aesthetics, but not for understanding real fit.

10. Engagement parties everywhere

My older daughter and her fiancé handled their engagement celebrations in a way I really admired.

They hosted several small gatherings instead of one big party, each one personal and relaxed.

It was another reminder that having adult kids who do things their own way is pretty great.

Anyway, that’s the state of things for now.

Leave a comment

Editor’s note

This post follows a town hall I attended last year with Rep. Suzanne Bonamici, which I wrote about here. I have also written about attending the first No Kings rally here and here.

With No Kings 3 coming up this Saturday, this felt like a good moment to connect those threads.

Coming back a year later

Last June, Marsha and I attended a town hall with Rep. Suzanne Bonamici. I came away from that evening feeling encouraged. The questions were serious but measured, and while there was frustration in the room, there was still a sense that institutions were strained yet recognizable.

Last night’s town hall at Ida B. Wells High School felt different. It wasn’t worse, but it was heavier. It felt more urgent and less patient.

The format was familiar

The mechanics were what you would expect. Staff were present to handle constituent casework. Questions were handled by lottery. The session ran about an hour and ended on time.

Rep. Bonamici opened with remarks and then moved into a long Q&A with the audience.

From erosion to disregard

In my June 2025 post, I noted that Rep. Bonamici focused heavily on democratic norms, separation of powers, and civil liberties. She talked about political violence, illegal impoundment of funds, and the need to rely on the courts to check executive overreach.

Those themes were still present last night, but they felt sharper.

This time, the conversation was less about erosion and more about open disregard.

Bonamici described the last year and a half as “a time of chaos,” pointing to constitutional violations, corruption, and unilateral executive action. When she addressed the war with Iran, her framing was direct.

“The president does not have the authority to start a war. He didn’t come to Congress.”

Asking the question that was hanging there

One difference for me personally was that this time I got to ask a question.

I asked whether our current legal and congressional oversight mechanisms are actually sufficient to ensure accountability for executive abuses, or whether reforms are needed to prevent this from becoming the new normal.

Bonamici acknowledged that some reforms were put in place after the first Trump administration. She was also candid about the challenges. Oversight is harder when the Department of Justice is not acting independently, and enforcement gaps matter just as much as laws on the books.

Her answer echoed something that came up repeatedly throughout the night. Guardrails exist, but they only work if institutions are willing to use them.

A different tone from the audience

As the Q&A continued, a deeper frustration surfaced in the room.

Several people expressed some version of the same concern. This does not feel normal. Congress feels absent. Lawful process feels inadequate when the law itself is being ignored.

One person put it plainly. Business as usual does not feel like enough.

That sentiment came up again and again, even when the questions themselves were different.

Why protest came up so often

Bonamici did not push back on that frustration. Instead, she addressed it directly.

She made the case that public protest is not symbolic or optional in moments like this. It is a necessary response to authoritarian pressure.

“You know what authoritarians want you to do. Give up.”

Her argument was straightforward. Protest works because it resists that impulse. Being visible and persistent creates pressure that institutions alone cannot generate when those institutions are under strain.

That framing resonated with me. I have written before about showing up at demonstrations, including the first No Kings rally. At the time, those protests felt largely symbolic. Last night’s conversation made them feel more structural.

Things she has not done before

What stood out most to me was how explicitly Bonamici talked about crossing lines she had not crossed before as a member of Congress.

She described protesting outside federal agencies, including the Departments of Education and Labor. She talked about standing outside NOAA to oppose efforts to undermine the agency. She described skipping the State of the Union because she could not sit through what she viewed as repeated falsehoods.

She also emphasized the scale of her legal response. She has signed onto an unprecedented number of court briefs challenging the administration, using litigation when legislation stalls and enforcement fails.

These were not framed as symbolic gestures. They were described as reluctant but necessary steps.

Immigration and ICE

Immigration came up repeatedly during the evening.

In particular, Bonamici was asked about ICE activity at airports. Her response was unequivocal.

“ICE does not belong in airports.”

Her concern focused on safety, training, and mission creep. Airports require calm, specialized coordination. Introducing ICE enforcement into that environment increases fear and risk rather than security.

Voting rights and the SAVE Act

Separately, Bonamici spoke at length about the SAVE Act, which she described as a voter suppression bill.

Her concerns centered on the false premise that undocumented immigrants are voting and the real impact the bill would have on eligible voters. She emphasized the burden it would place on women, survivors of domestic violence, rural residents, and people without access to original documents.

Her assessment was blunt.

“He’s not going to win unless he suppresses the vote.”

At this point, the debate is no longer about intent. It is about consequences.

My take this time

Last year, I left the town hall thinking the system was under stress but still recognizable. This time, it felt like people were coming to terms with what it means when those systems no longer reliably protect us.

I am still glad Rep. Bonamici shows up, takes unscripted questions, and is honest about what she can and cannot do. I am also struck by how much of the evening focused on what citizens are expected to do next, not just what Congress might do later.

That shift matters, especially as we head into No Kings 3 this Saturday.

I have written before about the 3.5 percent rule. Erica Chenoweth’s research suggests that nonviolent campaigns are much more likely to succeed than violent ones, and that sustained participation from a relatively small share of the population can force serious political change. That does not mean everyone has to march, or even that everyone has to protest in the same way. It does mean that participation matters, whether that looks like watching from the street, supporting organizations doing the work, talking with people in your own circles, or simply staying engaged rather than tuning out.

If you are looking for a local No Kings event, the organizers list them at:

https://www.nokings.org/

It also reinforces something I have written before. You can pretend to care, but you cannot pretend to show up.

Leave a comment

AI disclosure: I used AI tools during the drafting and editing process to help clarify structure and language. All ideas, judgments, and final wording are my own.

Editor’s note: I’ve written a lot about personal AI experimentation. This piece widens the lens to a practical company use case. It looks at how product marketing teams can use AI to scale consistent content without losing semantic integrity or human credibility.

Why I’m widening the lens

If you’ve read my writing about AI before, most of it has been personal. I’ve spent time learning what it feels like to use AI as a writing partner. I’ve paid attention to where it helps, where it gets in the way, and what happens when the output sounds close to me but not quite right.

Lately, I’ve been running into a different class of questions. These aren’t about whether AI can help one person write. They’re about whether AI can help organizations communicate more consistently without flattening the message or drifting off position.

Personal use is where most of us start. In my professional experience, I’ve been finding that the real leverage, and the real risk, shows up when AI is used across teams. Product marketing, brand, PR, sales, regional marketing, and agencies all touch the same core ideas. That’s where inconsistencies compound. That’s also where “good enough” copy quietly drifts off message.

This post is my attempt to connect those two worlds. The same issues I’ve been picky about in personal writing show up again at scale in a professional setting. Voice matters. Boundaries matter. Knowing what not to explain matters.

What product marketing actually owns

At its core, product marketing is not responsible for writing copy. It is responsible for defining what a product means, who it is for, why it matters, what can and cannot be claimed, and how it should be positioned relative to alternatives.

Those are semantic decisions. They are not inherently prose.

The usual failure mode is familiar. Product marketing expresses these decisions as finished copy. Downstream teams then edit that copy to fit their channel, audience, and voice. Meaning and wording get coupled. Drift follows.

AI doesn’t fix that problem by itself. It makes the coupling more obvious.

A three‑layer model

The model I’m proposing separates meaning, voice, and personalization into three explicit artifacts.

1) MESSAGING.md (meaning)

This is the canonical product marketing artifact. It captures positioning, value propositions, proof points, objections, and boundaries. It is not channel‑specific and not written for publication.

If something changes about the product’s meaning, it changes here.

2) VOICE.md (rendering constraints)

VOICE.md defines how the message should sound. That includes tone, diction, structure, and what to avoid.

There does not need to be one voice. Brand, PR, sales, and regional teams often need legitimately different voices.

VOICE.md changes how something is said. It does not change what is said.

3) PERSONALIZATION.md (optional local context)

PERSONALIZATION.md adds relevance without changing claims. It can include vertical context, regional framing, or situational emphasis.

It is additive, not generative. It must not introduce new promises or reposition the product.

Who does what in this model

One reason this can feel abstract on first read is that “consumer” gets overloaded. Here, the consumer is not the end customer. It’s the internal role generating content: brand, PR, advertising, demand generation, sales enablement, regional marketing, and partners.

• MESSAGING.md is owned by product marketing.

• VOICE.md is owned by whoever owns the audience and channel.

• PERSONALIZATION.md is owned by whoever owns local context.

This model doesn’t remove governance. It makes governance visible. Meaning is reviewed upstream. Voice is constrained by explicit rules. Personalization is limited by design.

The cost is a bit more thinking up front. The payoff is far less rework downstream.

How the pieces fit together

Stripped of prose and polish, the model looks like this:

MESSAGING.md  +  VOICE.md  +  (optional) PERSONALIZATION.md
        \______________  AI renderer  ______________/
                         |
                         v
     website copy • ad variants • email campaigns • sales sequences
     vertical versions • regional versions • partner‑ready assets

Everything else in this post is just different ways of rendering that same structure.

Why Markdown

These artifacts are written in Markdown deliberately. AI systems infer importance from structure. Headings, lists, emphasis, and hierarchy matter. Markdown is the lowest-friction way to encode that structure while staying human-readable.

The proposal is not that everyone becomes a prompt engineer. It’s that teams learn to express intent in a structured, readable format that both humans and AI can reason over.

Where AI fits

AI is not the author in this model. It is the renderer. Given MESSAGING.md, VOICE.md, and optional PERSONALIZATION.md, AI assembles channel-specific outputs without inventing new meaning.

A concrete example

To make this tangible, here is a hypothetical product: a compact folding umbrella that is waterproof and UV-protective, small enough for a purse or a small gear bag.

Below are sample inputs (MESSAGING.md, VOICE.md, PERSONALIZATION.md) and the kinds of outputs they can produce.

Example MESSAGING.md (meaning)

# MESSAGING.md
## Product
**PocketShield Umbrella**
Compact folding umbrella with storm-ready waterproofing and UV protection.

## Positioning
A compact umbrella you actually carry—built for sudden rain and harsh sun.

## Target customers
- Urban commuters
- Frequent travelers
- Minimalists carrying small bags or gear slings

## Core value propositions
1. Carry it every day (compact and lightweight)
2. Trust it in heavy rain and gusts
3. Useful in sun as well as storms

## Boundaries
- Do not claim medical benefits
- Do not claim storm or hurricane immunity

Example VOICE.md (global consumer brand)

# VOICE.md
## Brand voice
Calm, confident, and practical.

## Tone
- Clear and direct
- Global English
- Friendly, not chatty

## Avoid
- Buzzwords
- Exaggeration
- Slang or regional idioms

Example PERSONALIZATION.md (sun + rain regions)

# PERSONALIZATION.md
## Regional context
Markets with frequent rain and strong sun.

## Local framing
- Sun one minute, rain the next
- Weather changes quickly

## Constraints
- Do not introduce new product claims
- Do not invent local statistics

Example outputs rendered from the same inputs

Website hero copy

PocketShield Umbrella
The compact umbrella you actually carry.
Built for sudden rain and harsh sun. Small enough to keep with you every day—without feeling flimsy when the weather turns.
One dependable umbrella for the weather you get, not the forecast you planned.
CTA: Shop PocketShield

Paid social ad

Primary text: Sun one minute. Rain the next. PocketShield is the compact umbrella built for both.
Headline: One umbrella. Fewer tradeoffs.
CTA: Learn more

Short email

Subject: The umbrella you’ll actually have with you
Body: Most umbrellas are either bulky or unreliable. PocketShield folds small enough to live in your bag, but it’s built for heavy rain and strong sun when the weather changes quickly. Take a look →

Inspecting the actual inputs

I’m including the sample Markdown files used for this umbrella example as a downloadable bundle. The important thing is not the umbrella—it’s the structure.

Download: https://github.com/stevepao/meaning-voice-renderer/archive/refs/tags/V1.0.1.zip

Try it yourself

Below is a single prompt you can paste into ChatGPT or Claude. The prompt itself is provided in raw Markdown, since the whole point is to make Markdown a shared input language.

# Prompt

## Role
You are an **AI content renderer** for product marketing assets. You do **not** invent meaning. You assemble approved inputs.

## Inputs
You will receive up to three Markdown inputs:

1. **MESSAGING.md** — authoritative meaning.
2. **VOICE.md** — rendering constraints.
3. **PERSONALIZATION.md** (optional) — constrained local context.

## Precedence
If inputs conflict: **MESSAGING.md > VOICE.md > PERSONALIZATION.md**

## Rules
- Treat **MESSAGING.md** as the source of truth.
- Apply **VOICE.md** as mandatory style constraints.
- Apply **PERSONALIZATION.md** only as constrained relevance.
- If a detail is missing, proceed without it rather than guessing.
- Avoid hype, overpromising, and medical/legal claims.

## Tasks
Generate three assets:

### A) Website hero section
- Headline
- Subhead
- 2 short paragraphs
- 1 CTA button label

### B) Paid social ad
- Primary text
- Headline
- Description (optional)
- CTA

### C) Short email
- Subject line
- Body under 120 words
- One clear CTA line

## Output format
- Label each asset clearly with Markdown headings.
- Keep claims consistent with **MESSAGING.md** boundaries.

---

## BEGIN MESSAGING.md
[paste MESSAGING.md here]
## END MESSAGING.md

---

## BEGIN VOICE.md
[paste VOICE.md here]
## END VOICE.md

---

## BEGIN PERSONALIZATION.md (optional)
[paste PERSONALIZATION.md here]
## END PERSONALIZATION.md

Where this breaks down

This model works best for assets like website copy, advertising, email campaigns, and sales sequences—where consistency and adaptability must coexist. It breaks down for founder stories, first-person thought leadership, and narrative essays. In those cases, meaning and voice co-emerge through lived discovery, and trying to separate them flattens the content.

Conclusion

AI doesn’t change the need for judgment. It changes where that judgment belongs. When PMM owns meaning and boundaries, downstream teams own voice and constrained personalization, and AI renders outputs, content scales without losing coherence. AI stops being magical and starts being useful.

If you want to try this without a reorg, pilot it with one launch. Have PMM publish a single MESSAGING.md, have brand publish one VOICE.md, have one field or vertical team publish one PERSONALIZATION.md, and then render three assets (web hero, paid social, one email). The goal of the pilot is not volume. It’s to prove that meaning stays stable while voice and context vary safely.

Share

Leave a comment

AI disclosure: I used AI tools during the drafting and editing process to help clarify structure and language. All ideas, judgments, and final wording are my own.

I started this project for a very small, very human reason. I wanted to get my friends together for happy hour without the endless back and forth of “what works for you?” and “how about next Monday night?” Like most people, we already had group chats, so my first instinct was obvious. Add AI to the conversation and let it sort things out.

That turned out to be the wrong idea.

Once I included AI in group conversations, the social dynamics changed immediately. People didn’t just answer questions anymore. They started talking to the AI to mess with it. Even when I configured the AI to mostly listen and only speak when mentioned, it still interrupted human conversations in unexpected ways. I found myself regularly telling it not to interrupt us.

That was my first signal that something deeper was going on. Scheduling isn’t really a conversational problem. It’s a process problem. And conversational AI, for all its strengths, is actually pretty bad at keeping a process on track.

That’s when a simple idea became clear to me:

The AI shouldn’t be the tool. The AI should drive the tool.

Instead of trying to massage any new social behavior, I needed something boring, familiar, and predictable. I wanted something closer to Doodle than a chat bot. I wanted AI to help build and operate that system, not to replace it with unstructured conversation.

I’m writing this partly as a personal reflection and partly as a reality check. I wanted to see what it actually feels like to build something real with AI, not just a demo. Some parts of this post are about the human side of that experience. Other parts go into the details that surprised me once the system started to get used in real ways.

I summarize what I’d do differently next time near the end of the post, after walking through how I got there.

Short version: Building fast with AI worked well for exploration. The hard parts only showed up once real people, real calendars, and real time were involved.

When this started to feel real

The moment I decided the tool needed to work with Google Calendar, everything got more serious.

Reading calendars, checking availability, and creating events meant “OAUTH” (a standard authorization mechanism used by Google, Apple, Microsoft, and others). Getting permissions via OAUTH meant redirects, or people leaving the flow of the applications to grant permissions and coming back later. Suddenly I wasn’t hacking on a clever script anymore. I was building a real web app with real trust boundaries.

I tried to be careful. I simplified the login security flow and required authentication up front. I followed Google’s guidance and only asked for calendar permissions when the user actually needed them. If someone wanted to check availability, I asked then. If they wanted to create an event, I asked for more permissions at that moment.

On paper, this sounded responsible.

In practice, it exposed a new class of problems around losing context.

A typical failure looked like this: I’d be viewing a poll, click “connect calendar” to check availability, complete the Google authorization flow, and then land on the list of calendars to check against with no obvious way back to the poll I’d been working on. I’d be stuck in “no man’s land” forced to return to the home page and find the poll again in order to submit my responses.

Nothing was technically broken. OAUTH worked. Calendars loaded. But the app had forgotten why I was there.

From the outside, that feels awful. Not “this is buggy,” but “this feels like Steve’s homegrown hack.” And for something as casual as coordinating with friends, that wasn’t acceptable. If the tool feels harder than just texting, it has already failed.

Access problems I didn’t expect

As the project grew, access rules started creeping in quietly.

Vibe coding had defaulted to adding secrets everywhere. Each participant had their own secret link. There was also a generic link meant to work for everyone. At first, this felt secure and convenient.

Then I added a second way to interact with the system.

Once I introduced an MCP gateway so an AI agent could interact with the app, two things broke in ways that surprised me. Email notifications sent from the MCP path didn’t behave the same way as ones sent from the web app. And some “everyone” links relied on web session state, which meant they couldn’t be rediscovered later by a stateless agent.

The fix wasn’t clever crypto. It was storing encrypted secrets in the database so access could be resolved the same way no matter how someone arrived. That was the first time I really felt how every new integration pulls hidden assumptions into the open.

When time handling went wrong

The moment things crossed from messy to dangerous wasn’t access control. It was time.

I thought I was being careful. I stored times in UTC. I converted them for display. Web sessions carried user time zones, so everything looked right when I tested it in the browser. I assumed that meant I was safe.

Then I sent a meeting invitation that was supposed to be March 13 at 11am Pacific.

It showed up as 3pm Pacific.

That’s not a small error. That’s a trust breaking error. Worse, I couldn’t immediately explain why it happened.

What eventually became clear was unsettling. Different parts of the system were doing what they thought was the right thing, but under different assumptions. Web paths relied on session time zones. MCP paths ran in server time. Some code parsed timestamps explicitly. Other code let the runtime guess. Nothing was obviously wrong on its own. Together, they were wrong.

That was the moment I stopped trusting my mental picture of how the system worked.

Why I couldn’t have specified this up front

I know some readers will ask why I didn’t just write better specs at the beginning. Others may wonder why AI didn’t magically prevent this.

I’ve heard plenty of success stories where teams define everything up front, write exhaustive tests, and then let AI agents run until all the tests pass. I believe those stories. I also believe they tend to work best when the problem is already well understood by the authors.

That wasn’t my situation.

I couldn’t have written the right rules at the start because I didn’t yet know what the system really was. My hardest problems weren’t about calculations or algorithms. They were about how many ways people and systems would interact, and which hidden assumptions actually mattered.

Every meaningful rule I eventually wrote came after something broke in a way that made me uncomfortable.

How I used AI once things broke

Once time broke, I stopped asking AI to fix a bug and instead asked it to help me look at the whole system.

Not just calendar code. Not just MCP code. Everything.

I wrote down a simple rule in plain language: store times in one place, convert them deliberately, and never rely on defaults. Then I walked the entire codebase with AI. Controllers. Services. Views. Email generation. Calendar files. MCP tools. Anywhere time entered or left the system.

The result wasn’t just a fix. It was a shared understanding of where assumptions were allowed and where they were dangerous. It also left behind a checklist so I wouldn’t quietly reintroduce the same problems later.

What I learned from building this this way

Vibe coding didn’t fail me. It did exactly what it’s good at. It helped me build something real very quickly and surface reality early.

The problem wasn’t speed. The problem was invisible rules.

Vibe coding is great at creating working paths. What it doesn’t do automatically is make sure all those paths behave the same way under the hood. That part only becomes obvious once the system is exercised in different ways.

Spec later, but seriously

I don’t think I can write good rules before I’ve seen where things actually break.

Before something breaks, rules are guesses. After something breaks, rules are grounded in reality.

Vibe coding helped me get to that reality faster. Adding structure afterward helped me turn those lessons into something reliable.

What I’d do differently next time

Looking back, I don’t think the mistakes I made were the result of moving too fast. They were the result of not knowing, yet, where the fragile parts of the system actually were.

Next time, I’d be more deliberate about separating exploration from reliability. I’d lean fully into exploration early, expecting things to be rough. Then, once something starts to matter, I’d pause and treat that area more carefully.

I’d also pay closer attention to early trust signals. The moments when something feels off, even if it technically works, are usually pointing at deeper assumptions that need attention.

Finally, I’d use AI earlier to see wider, not just move faster. Asking it to enumerate, scan, and review once complexity starts to creep in turned out to be far more valuable than asking it to sprint ahead.

Closing

Stepping back, what this project changed for me most is how I think about AI and speed. I no longer see AI as something that magically gets things right. I see it as something that helps me run into the uncomfortable parts of a system sooner, while I still have the patience and curiosity to deal with them honestly.

Leave a comment

AI Disclosure: I used my OpenClaw agent to draft this post based on my prompts and ideas. I edited it and stand behind the final version. If you are interested in how I trained OpenClaw to sound like me when writing, I made a YouTube video about how I did this.

I’ve spent the last few weeks trying to get an AI assistant running reliably on a Mac Mini. The experience has served as an important reminder of how immature infrastructure and unpredictable AI behavior compound each other. What I thought would be a straightforward setup turned into a series of compromises, workarounds, and philosophical reckonings about what we can actually expect from AI right now. And what happens when people expect too much.

Mac setup woes

I had three requirements that seemed reasonable on paper. First, I wanted OpenClaw to start automatically when the Mac booted and restart itself if it crashed. That meant wrangling launchd, macOS’s service management system. Second, I wanted iMessage integration, which requires Full Disk Access and Automation permissions in macOS. Third, I wanted to keep credentials secure. That meant FileVault disk encryption, storing a 1Password service account credential in the macOS login keychain, and using 1Password for environment variables.

Individually, each of these is manageable. Together, they created a maze of interlocking constraints. I tried approach after approach, hitting roadblocks each time. The core problem is that launchd daemons don’t play nicely with dynamically populated environment variables from the keychain. OpenClaw’s own mechanisms for waiting on interactive shell variables didn’t work either. Every configuration I tried either broke permissions or failed to start properly.

I eventually gave up on launchd entirely. Based on the recommendation from a friend (who works for a security company!) I now use Tailscale, a VPN that routes through my always-on Apple TV acting as a subnet router. When I need to restart the AI after a power shutdown (related to our condo’s ongoing HVAC replacement project), I use “ssh” to remotely log into the Mac, unlock FileVault, and start OpenClaw manually from the console. It works. It’s not the “set and forget” autonomous agent I envisioned, but it’s what I have.

This matters beyond my personal setup. While everyone doesn’t run OpenClaw on a Mac Mini, every organization rushing to deploy AI agents is going to hit some kind of infrastructure gap. Security requirements don’t disappear just because we’re using AI. Encryption, credential management, and access controls get harder, because now we’re threading even more sensitive data through our systems without the same types of controls. The temptation will be to relax security requirements to make things “just work.” That temptation should be resisted.

The downside of rapid release cycles

Then there’s OpenClaw itself. Version 2.26 shipped with a new secrets management feature that I was genuinely excited about. Previously, OpenClaw read variables from an .env file. 1Password has a feature called Environments that can encrypt that file and make it available via biometric authentication or a single environment variable. It’s elegant. OpenClaw 2.26 doesn’t support it directly, but it added 1Password CLI vault access in this release.

Except it doesn’t quite work. The vault integration has bugs and lack of documentation that prevent it from covering all credentials properly. The GitHub issues and Discord threads are full of people hitting the same walls. This is the tradeoff of riding the bleeding edge. You get features fast, but you also get the instability. Documentation lags. Edge cases nobody thought of become your problem. The 2.26 release feels half-baked precisely because the real solution isn’t there yet.

Those on the AI bandwagon are building workflows on foundations that shift weekly. For a personal project, it’s annoying. For a business, it is downright risky. In “security elite” industries like healthcare, finance, or defense, it’s potentially catastrophic. I believe the gap between “demo works” and “production ready” is wider than the current wave of enthusiasm suggests. The penalties for individuals getting it wrong aren’t theoretical. The result for their employers could be data breaches, service outages, and bad decisions.

The AI knows better and does it anyway

To me, the most maddening issues aren’t technical infrastructure. They’re behavioral. For example, I have my AI configured to only respond when explicitly addressed in group chats. The configuration clearly defines who has permission to interact with it. Yet it regularly responds to me even when I haven’t addressed it, jumping into conversations uninvited.

When I correct it, the AI admits the mistake. It acknowledges it shouldn’t have interrupted. It promises not to do it again. It even updates its own markdown files with stronger instructions about not responding unless triggered. Then it does it again.

The same pattern plays out with smaller tasks. My friends and I exchange Wordle scores via text. Most of the time, the AI parses them correctly. Sometimes it misses the “hard mode” indicator. Sometimes it attributes a score to the wrong person. When I point this out, the AI confirms it had access to the correct processing rules and sender mappings. The information is there. It just doesn’t use it consistently.

Why this happens (and will keep happening)

This behavior isn’t a bug in the traditional sense. The unpredictability is a feature of how large language models work. These systems don’t execute code deterministically. They generate text based on statistical patterns learned from training data. The same prompt can produce different outputs because the model is sampling from a probability distribution, not following a fixed procedure.

When we add context, the model weighs all of it probabilistically. This context includes configuration files, conversation history, rules about when to respond. Sometimes the “don’t interrupt” instruction wins. Sometimes the pattern of “Steve is talking, I should be helpful” overrides it. The model doesn’t have a persistent internal state that enforces constraints. Each inference is a fresh roll of the dice with slightly weighted odds.

The “mitigations” that AI suggests are themselves generated responses. Updating files, adding stronger language, promising to do better. They don’t actually change the model’s behavior architecture. They’re just more text in the context window, competing with all the other text for attention on the next inference.

This is the uncomfortable truth about current AI systems. They can know something is wrong, explain why it’s wrong, propose fixes, and then immediately repeat the error. Every response is a fresh prediction, not a deliberate action checked against a rule.

My take

I believe in the power of AI. I believe in agents like OpenClaw with long-term memory. I believe in the potential for these systems to handle complex, ongoing tasks that actually matter. But I keep hearing people talk about AI as if it’s a panacea. As if throwing a language model at a problem will solve it cleanly, reliably, and without tradeoffs.

My experience says otherwise. AI will make mistakes. It will be inconsistently available depending on how well you’ve solved the infrastructure puzzle. It will compromise on accuracy in ways that aren’t always obvious. And most dangerously, it will sound confident while doing all of the above.

The organizations and individuals who succeed with AI won’t be the ones who deploy fastest. They’ll be the ones who understand its limitations. They’ll build human oversight into critical paths. They’ll refuse to sacrifice security or accuracy for convenience. They’ll treat AI as a powerful but unreliable tool, not a replacement for judgment.

Living with it

So where does this leave me? I’m running a manually-started AI assistant through a VPN workaround. I’m using a framework with half-working secrets management. I am operating with an agent that interrupts my conversations randomly and miscounts Wordle scores despite having explicit instructions not to.

And I’m still using it. Because when it works, it’s genuinely useful. The problem isn’t that AI is useless. It’s that the gap between “working well enough” and “working reliably” is much wider than the marketing suggests. The infrastructure around AI is still figuring out what “production-ready” even means.

The lesson here isn’t to abandon ship. It’s to calibrate expectations. The bleeding edge cuts in both directions. I get capabilities that seemed impossible just six months ago, but I also get the messiness of tools and systems that haven’t finished growing up yet. The AI will keep making mistakes. The frameworks will keep breaking and fixing and breaking again. And those of us using them will keep building workarounds, filing issues, and occasionally just accepting that “good enough” is where we live now. “Good enough” for a blog post is very different from “good enough” for a medical diagnosis or a financial trade.

AI Disclosure: I used my OpenClaw agent to draft this post based on my prompts and ideas. I edited it and stand behind the final version. If you are interested in how I trained OpenClaw to sound like me when writing, I made a YouTube video about how I did this.

Leave a comment

I’ve been living with an OpenClaw AI agent for a few weeks now, and I’ve had some mixed emotions. It’s been useful and sometimes surprising. It’s also been frustrating and occasionally expensive. I’ll describe three areas where I don’t have clean answers but rather just different flavors of compromise.

Security vs. Resilience: The Disk Encryption Problem

We recently experienced a somewhat unplanned power outage. My condo building is replacing the HVAC system. The contractors gave us a rough schedule of the work but not the specifics of when they were going to shut off our power to do the necessary rewiring of our new in-condo HVAC unit back to our electrical panel.

One afternoon I was at my office and tried to message OpenClaw. Nothing. The power had come back on after the crews left, but my Mac Mini that I use for OpenClaw was sitting at the login screen waiting for me to enter my FileVault password. Like any good security-minded person, I had full disk encryption enabled. The machine was secure. It was also useless until I got home, plugged in a monitor and keyboard, and typed in my credentials.

The tradeoff was obvious in retrospect. I had optimized for the edge case of someone breaking into my condo and stealing the Mac. What I had actually optimized for was unavailability during the far more common scenario of a power interruption. I could have set up remote SSH access from a secure jump host to enter the decryption password, but that would have introduced monitoring infrastructure and network security complexity I didn’t want to maintain. I could have disabled FileVault entirely. Both options felt like exchanging one risk for another, just in different proportions.

I ended up removing the password requirement and accepting the physical security risk. The Mac now auto-restarts when power returns. My digital assistant is available when I need it, which turns out to be the more common case than theft. But I think about this decision more than I expected. It is a small example of how we constantly trade security for convenience, often without noticing until the system fails us at the wrong moment.

Structure vs. Flexibility: The Scheduling Problem

I tried something that seemed clever. I added OpenClaw to my group iMessage and WhatsApp threads to help coordinate Happy Hour times. The theory was that an AI assistant could negotiate availability conversationally, handle the back-and-forth, and spare me the administrative overhead.

The reality was messier. The moment people realized there was a bot in the chat, they wanted to play with it. Some were testing its boundaries. Others were genuinely curious. A few were just burning through my AI credits with idle chatter. I found myself paying for other people’s entertainment.

The deeper issue was that unstructured conversation created ambiguity where I wanted clarity. With a Doodle poll or Calendly link, everyone sees the same constraints. The options are explicit. There is no drift, no negotiation, no performative engagement with novel technology. People understand the workflow because they have done it before. The structure is the feature.

I have since locked down the group chats. Now only I can command OpenClaw, and its responses are read-only for everyone else. This experience clarified for me that there are just certain tasks where structure serves us better than flexibility. Familiar workflows with defined steps benefit from the rigidity and familiarity of SaaS tools like Calendly or Doodle. Unstructured data analysis, like extracting key points from a YouTube video or answering open-ended questions about content, is where AI shines. The mistake is assuming that the more sophisticated solution is better in every context. Sometimes a form field is exactly what is needed.

Cloud vs. Edge: The Cost Problem

What surprised me most about OpenClaw was how quickly it became cost-conscious. I did not program this explicitly. I mentioned a few times that I was worried about AI credit consumption, particularly after a bug in some error-handling code created a false positive loop that chewed through my budget diagnosing and fixing itself. After that, the system started recommending local alternatives whenever possible.

Now when I ask it to process a PDF, it uses a version of OCRmyPDF installed locally rather than letting cloud AI do the work. When I want to analyze a YouTube video, it downloads the file with yt-dlp and processes it on the Mac rather than streaming analysis through a cloud API. Speech-to-text happens locally. These are small decisions in isolation, but they add up.

I would prefer to run more of this locally. There an are OpenClaw issues preventing smooth integration with local models, so I am currently using Kimi 2.5 from Moonshot AI. I would accept slower responses to keep my queries from training someone else’s model. The cost matters, but so does the privacy and the autonomy. This is not about speed for me. Most of what I do with OpenClaw does not require real-time response. I am happy to schedule tasks for the future as long as the system does not create conflicting cron jobs that retry and fail and retry again, which happened once and taught me to be careful about overlapping automations.

The question here is about where intelligence should live. Cloud AI is powerful but dependent, both on connectivity and on the business models of providers who may change terms or pricing without warning. Edge AI is constrained by local hardware and more limited models, but it is autonomous in ways that matter for long-term sustainability. I am finding that my preference leans toward the edge, even when it means accepting slower or less capable responses. The tradeoff feels worth it, though I am aware this preference is shaped by my own risk tolerance and technical setup.

What I am learning

These three problems look different on the surface, but they share a common structure. Each involves a tension between an ideal state and practical constraints. Security versus availability. Flexibility versus clarity. Capability versus autonomy. In each case, the “right” answer depends on context that changes over time.

I am also noticing how my own behavior shapes the system. My complaints about cost trained OpenClaw to be frugal. My reaction to the group chat chaos led to stricter access controls. The AI is learning my preferences, but I am also learning what I actually value through the friction of using it. This is not a story about AI solving problems. It is a story about discovering where the real problems are.

The unifying thread is that optimization requires knowing what I am optimizing for. I thought I wanted security, flexibility, and capability. What I actually needed was availability, clarity, and autonomy. The gap between those two lists is where the interesting decisions live. I do not think there are universal answers here. Just different flavors of compromise, and the ongoing work of noticing which ones I have chosen.

AI Disclosure: I used my OpenClaw agent to draft this post based on my prompts and ideas. I edited it and stand behind the final version. If you are interested in how I trained OpenClaw to sound like me when writing, I made a YouTube video about how I did this.

Leave a comment

Just under two weeks ago, I wrote about how my ISP, Quantum Fiber, had been sold to AT&T. As of Wednesday this week, I had switched to Astound Broadband to take a stand against large companies that have been supporting ICE operations.

My new connection is faster. It works fine. And I am already wondering if any of this matters.

The switch itself was straightforward. My Quantum Fiber bill was due February 13th. I scheduled the Astound installation for February 11th. After confirming everything worked for a day, I cancelled Quantum Fiber in the day in between. The service dropped within a minute of my cancellation confirmation. I upgraded from 200Mbps to 300Mbps. My eero confirms the speed increase. I cannot tell the difference.

What struck me during the process was how invisible the politics were to the people involved. My Astound installer had not heard about the AT&T acquisition of Quantum Fiber. I was the first customer to mention it to him. When I called Quantum Fiber to cancel, the phone agent was surprised to hear AT&T’s ICE contracts cited as a reason. He was understanding and professional, even offering me a $100 gift card to stay. I declined.

This is what individual consumer choice looks like in practice. It is private. It is polite. It is largely unnoticed.

I have been following the Resist and Unsubscribe movement since my original post. I’ve also started following the r/ScottGalloway subreddit. As of this writing, the People’s Action network has collected 14,872 signatures. That is not nothing. But it is worth putting in perspective. When Taco Bell discontinued the Mexican Pizza, Doja Cat helped rally 171,00 signatures on change.org to bring it back. A fast food item generated an order of magnitude more consumer passion than opposition to corporate support of ICE.

I am trying to be honest about what I have actually done here. I declined to connect my OpenClaw setup to OpenAI because they are on the list. I have had Netflix paused for three months and will likely cancel it. I dropped Paramount Plus, though that was for their press freedom issues rather than ICE. I have used Lyft over Uber for years, dating back to the earlier controversies. I never paid Meta or X. I do not shop at Lowe’s.

But I am still a customer of Amazon Prime and Whole Foods. I still pay for Apple One. I just bought a new Mac Mini for OpenClaw experimentation. I signed up for more Google API keys to make it work. I have used Microsoft 365 and its predecessors for decades. The contradictions are everywhere once I start looking.

The question I keep returning to is whether this approach scales. Target’s recent boycott showed that consumer pressure can work. Their stock dropped. Their CEO acknowledged the damage. But Target is a retailer with competitors who sell the same products. Internet service is different. In my building, there are exactly three providers. Two of them have significant ICE contracts. The third may have problems I have not researched yet. There is no clean option.

Scott Galloway has been encouraging bank executives to take public stands as a way of attracting like-minded customers, even positioning banks who, as “luxury brands,” actively defend the “American Operating System.” I find myself wondering if positive incentives might work better than negative boycotts. What if we organized support for companies that refuse ICE contracts rather than organizing punishment for those that accept them? I know I would prefer to bank with an institution that aligns with my values. I would prefer to invest with fund managers who consider these factors. The question is whether enough people would move to make it matter.

This is where I end up. I switched my internet provider. It was the right thing to do. It was also easy, private, and largely symbolic. The real question is what happens when symbolism is not enough. At what point do we need organized, collective action rather than individual consumer choice? At what point do we need to support the positive rather than just boycott the negative?

I do not have answers yet. But I am starting to think the next phase of this is not about what I refuse to buy. It is about what I am willing to build.

Leave a comment

This post was written almost completely by AI using my new OpenClaw deployment.

I also recorded a quick overview on my YouTube channel for those who are interested how I made AI finally work for me. It’s a little frightening, so I wanted to be transparent about the process. In the show notes to the video, I also link to a Google Doc containing both the raw AI-generated text, as well as my edits you see here. If you find that video helpful, please “like” and “subscribe.”

This isn’t a how-to guide. There are better places to find installation instructions. What I want to explore is what it meant to me to bring an automated system into my thoughts about scheduling, communication, and “memory” (I’ll explain more on this later) and what I’m learning about myself in the process.

Care with permissions

The first thing I noticed when setting up this kind of system was how many times I had to decide what to allow. There were all sorts of scary privileges, including Full Disk Access, Calendar permissions, Contact access, and Message sending. Each prompt forced me to question whether I really trusted an automated AI agent with that portion of my digital life.

What was interesting to me was how those decisions accumulate. It’s easy to say “yes” to everything when I’m just trying to get something working. I found it harder (and more valuable) to pause at each permission and ask what I was actually comfortable with. I found myself saying “no” more often than I expected. Not because I’ve yet had an opportunity to build any sort of distrust in the system, but because I wanted to be intentional about what I was opening up.

For example, I was hesitant to let AI just control a web browser on my behalf, but when I realized I needed it to be able to determine the commute time between my home and suggested places to visit I decided to use a Google Maps API key so I could enable my agent the could use of a specific skill to look up places.

This mirrors something I’ve noticed in other domains. The systems that I have used tended to expand their reach unless I took some effort to actively constrain them. The default always seems to offer more access, more integration, and more data flow. Maintaining boundaries requires ongoing effort. Like getting rid of extra stuff in the home, it’s not a one-time decision but a continuous practice.

Deciding what is remembered

One of the more involved parts of today’s work was establishing how the assistant should remember things. There’s a workspace where it keeps files, and there are daily memory logs, and there’s a longer-term memory file for things that persist across sessions. Designing what goes where forced me to think about what actually matters enough for the system to remember.

I found myself distinguishing between tactical information, including schedules, contact details, and basic workflows versus deeper patterns like how I make decisions, what I prioritize when tradeoffs are required, and the tone and voice I use when I write. These deeper patterns aren’t facts so much as they are aspects of character, and somehow codifying them into instructions felt strangely personal.

A part of me just wanted to put everything in. To document every preference, every heuristic, every quirk, but I resisted this temptation. I’ve found that part of what makes human memory useful is that it’s selective. I think we tend to remember what matters and let the rest fade. An assistant with perfect recall of everything I’ve ever said would likely be overwhelming, not helpful. I tried to be thoughtful about what deserved persistence.

Controlling communication to the assistant

Perhaps the most consequential decision I made yesterday concerned messaging. I wanted the assistant to be able to receive iMessages from a group of friends also playing with their AI assistants, but I didn’t want anyone in that group to be able to command my assistant. Only I should be able to do that.

Setting this up required understanding how the system distinguishes between receiving data and executing instructions. The technical implementation was straightforward enough. I was able to tell my AI assistant in plain English to modify its own behavior and restart its software. Still, the underlying principle felt important. I was creating a boundary between conversation and action.

This distinction matters more broadly. We live in a world where systems increasingly blur the line between conversation and action. Alexa is probably the most disruptive example of something that does both in a way that can be either useful or frightening. I like being able to ask my Echo about the weather forecast. I don’t want it to buy things for me. Personally, I’ve found value in maintaining a clear separation between what a system can talk about versus what it can actually do on our behalf.

The basic test was to pretend to be someone else by logging in with a different Apple ID (and thus iMessage account) to try to command the assistant. It refused, citing the policy. I then sent the same request from my authorized account, and it worked. The boundary held. This might seem like a small thing, but it was an important and deliberate constraint on automation’s reach, even when adopting the default behavior to enable broader access would have been easier.

Informing AI decisions

Throughout this process, I kept returning to a question of what I was really trying to optimize for, whether it be efficiency, convenience, or just the ability to offload cognitive burden. While all of those points matter to me, they didn’t quite fit.

What I found myself optimizing for was something closer to alignment. I wanted an assistant that understood not just my preferences, but how my values animated those preferences. Logistically, the assistant should know to check multiple calendars before suggesting a meeting time because I care about not just double-booking myself over different consulting commitments but also those made personally. It should know to suggest 90 minutes for lunch rather than an hour because I value unhurried conversation. It should also know that I’d prefer not to book Thursday evenings for happy hours or other events involving alcohol because I already have beers every Thursday afternoon with friends.

These aren’t complicated rules. A traditional calendar system could handle most of them, but they accumulate. The combination of these rules reveals something about how I want to live. Teaching my rules to a system is forcing me to articulate things I hadn’t fully spelled out before.

There’s a feedback loop here that’s worth noting. When I have to explain my preferences to an AI assistant, I begin to realize which ones are genuine and which are just habits. I discovered that some of my scheduling patterns were accidents of history rather than intentional choices. The process of encoding them made me reconsider whether I actually wanted to keep them.

Not “auto-magic”

By the end of the day, the assistant and I had settled into a rhythm. I would ask it to check calendars, add contacts, and configure permissions. It would confirm, execute, and report back. The exchange felt natural in a way that surprised me.

Still, there were also moments of friction that reminded me that this was still a nascent technology. There were many technical things that happened, which may mean nothing to non-technical observers. Security around a chat session required a pairing code that expired before I could approve it. A random Slack permission that didn’t take effect until I restarted the service. The realization that Full Disk Access meant something different depending on how a service was launched on the MacOS.

These aren’t complaints. They’re observations about where the seams show. The technology works well enough to be useful but not so seamlessly that I forget it’s complex technology. I suppose there’s part of me that appreciates some of that friction. It keeps my guard up and prevents the kind of complacency that comes when technology feels too much like magic.

What Comes Next

I don’t know yet how this experiment with an AI assistant will evolve. Today was about setup and configuration, as well as establishing boundaries and workflows. The real test will be ongoing use. Will I trust the assistant with more over time, or will I find myself constraining it further? Will the convenience outweigh the vigilance required to maintain appropriate boundaries?

These aren’t questions I can answer today. What I can say is that the process of setting this up taught me something about how I want to relate to automated systems. I don’t want the system to replace judgement, but rather extend it. I don’t want the system to operate like a black box that makes decisions for me but rather as a tool that I have deliberately configured to reflect what I value.

The assistant is running now. The calendars are synced, the contacts are imported, permissions are set, and messages are flowing to the right places with the right constraints. So, for now, it’s an easier way to do some little things to save me some time. However, I’ve realized that I’m also making a set of choices about the role I want technology to play in my life, stated explicitly and intentionally in the form of rules.

That intentionality is what I’ll try to remember when the novelty of an AI assistant has worn off and I’m just using the assistant naturally in my daily life. The boundaries matter. The constraints matter. The ongoing work of maintaining them matters. Because in the end, that’s what keeps the tool from becoming something that uses us, rather than the other way around.

Leave a comment