UX vibes vs Code vibes

An idea I’ve dabbled with

Vibe coding all about focusing on the user experience rather than focusing on the code that makes that experience.

The non scalability issue

People argue about scalability when they see products built with AI-assisted development. They imagine what happens when the userbase grows or the codebase expands i.ez technical debt piling up.

Many products built this way solve specific problems for specific people. A tool that helps a company process their invoices. A system that generates reports for a particular team. An interface that automates one workflow that’s been eating up someone’s time.

When you build something to solve an actual problem you have right now, the constraints are already built in. You know the scope. You know the users. You know what “done” looks like.

The scalability critique applies to products trying to be everything to everyone.

Start with facts, not insights

For a couple of years I’ve had this folder called Braindump. It’s where I write my somewhat on-and-off journal, often when my brain starts getting too clogged up.

One thing I’ve noticed about journaling that makes it way easier: start with facts before insights.

“But of course” you might think. The struggle is that when we start journaling, we think we should only write profound things. We want it to become a book of deep thoughts. But our deep thoughts usually come after we’ve laid out the bare facts.

In other words, it’s way easier to start with what you did, what you were thinking about, what you saw or noticed. Then go deeper if possible.

Declarative and procedural knowledge

A thing I’ve been thinking about lately is the idea of declarative vs procedural knowledge. In other words knowledge that something exists versus knowledge how it is done.

The feeling is that AI tools are removing the need for step-by-step procedures for most things. Knowing that queues and databases exist, that there’s a musical scale called phrygian, what camera body or film stock or shallow depth of field mean. The vocabulary and concepts themselves become more important than memorizing how to execute them.

Because once you know the vocabulary, AI can handle the procedure. You need to know phrygian exists to ask for it. You need to know what shallow depth of field is to request it. But memorizing the scale pattern or calculating the f-stop becomes optional.

The generalist advantage - part three - a new role enters the arena

By the end of 2026 the highest-ROI hire at early-stage startups will be someone who doesn’t fit any existing job title. Not a PM. Not a developer. Not a designer. Someone who can do all three well enough and ship fast enough that traditional role boundaries don’t matter.

Someone with 10-20 years of experience who’s not the best developer and not the best product manager, but they see the whole product. They have the helicopter view that comes from doing this for decades. They know what actually matters versus what’s theater.

A year ago this person was a unicorn hire. They existed but had to choose where to spend their time. AI makes it achievable now. Not because AI replaces experience, but because it amplifies it.

Claude Code can write the checkout flow but it can’t tell you that adding one more step will kill conversion. It doesn’t have the scar tissue from shipping products that failed in interesting ways. Gut feeling still matters and gut feeling comes from experience.

The startups of the future will need fewer people and those people will be generalists. It’s a way to have a longer runway and a way to move faster than your competitors.

This is the time to be a generalist.​​​​​​​​​​​​​​​​

The generalist advantage - part two - the cycle collapsed

The breakthrough isn’t just that you can code faster. It’s that the gap between thinking and shipping collapsed.

The cycle looks like this now: start the morning brainstorming and thinking of ideas, building hypotheses, doing the POC or prototype. After lunch you build and ship. The day after you look at the outcome. Each day can become a sprint.

That used to take weeks and now it takes a day.

Projects that used to be blocked by priorities aren’t anymore because you can build ten different landing pages and ten different A/B tests and ship them all in one day. You can test the hypothesis instead of debating it.

I’ve built Shopify apps in 30 minutes and campaign sites in an hour. These are real products that solve real problems, not just demos to show off the technology.

The constraint wasn’t just coding speed. It was the whole machinery of getting from “what if we tried this” to “here’s what happened when we tried it.”

You can finally execute on product intuition at the speed you think.

The generalist advantage - part one - why you had to choose

For the last 14 years I couldn’t be a generalist anymore.

You’re a developer? Great, please think about the product but don’t go overboard. You’re a product manager? Yes you’re technical but do you really know code? You’re a CPO? Sure, but do you really know the technical parts?

The real blocker was time. You could do both strategy and execution but you didn’t have time to get down in the weeds. This opened up challenges with not being able to discuss the right things. “This is the way we engineer it” became the rule that sometimes blocked progress.

The generalist approach didn’t scale. You had to choose. Strategy or execution. Vision or implementation. The bandwidth wasn’t there to do both well.

I’ve watched developers focus so much on speed optimizations and picking the best frameworks that they lose track of the bigger picture. I’ve seen product managers spend weeks crafting the optimal roadmap with detailed OKRs and PRDs. I’ve watched designers pixel-push design libraries thinking it will make things clearer for developers.

Everyone had to specialize because that’s all the time allowed for.

Sea glass

I tend to think that people’s ideas and opinions are like glass shards in a sea. The longer we live, our sharp edges get softer. We can still be spiky but we also understand that there are other views.

When your AI Sales Agent does know about public holidays

I got an outreach email on December 30th. Then on January 1st, a follow-up arrived: “We haven’t heard back from you yet.”

Well, no. Of course you haven’t heard back. It’s New Year’s Day.

And this isn’t just about public holidays. I’ve experienced this with emails and LinkedIn outreaches on Friday afternoon, then again on Monday morning.

We are using an AI agent sophisticated enough to personalize emails, manage multi-step sequences, and track engagement. But somehow it doesn’t know to check if it’s a public holiday? It doesn’t realize that only a few business hours have passed before firing off that second message?

This isn’t even a hard problem to solve. Every calendar API knows about weekends and major holidays. Your AI can write convincing copy and manage complex workflows. It just needs to be configured to understand that January 1st is probably not the best day to send “just following up since we haven’t heard back.”

We stopped worrying and learned to love the chatbot

Once we believed apps were listening to our conversations. Targeting us with ads. We were outraged.

Now we tell chatbots our worries. Our feelings. Our hopes and secrets.

What changed?

Maybe it’s that sharing benefits me directly. I get something back. Social media ads never gave me anything.

Maybe it’s that I pay for these tools. That makes me feel like my data is more secure. If they were ad-supported, I’d share less. Imagine talking about something personal and then getting an ad for a therapist in Umeå. I’d quit immediately.

I probably overshare. Haven’t found the line yet.

It’s cheaper than a psychologist.