Could you build an AI assistant that used Claude Code itself the way Anthropic intended, without getting blocked like OpenCode users were.

About five months ago Anthropic released the Claude Agent SDK. A way to create tools on your machine that used the internal Claude Code with all its capabilities. That solved the first problem.

The second was about security. The solution was running the assistant inside Docker. A computer inside a computer that only has access to what’s inside.

But to make it valuable it needed access to email, calendar and various other things without exposing keys or giving it direct access. That’s where the idea of a layer in between was born. A proxy written in plain code that decides what the assistant gets to see and what it doesn’t.

The layer provides access to mail, calendar and a way to use more demanding features like speech to text that need more compute. In this layer I also decide what gets filtered before it reaches the assistant and what permissions it has. Not reading certain emails, not sending emails only drafts, not creating calendar invitations with others and so on.

All development is done by me talking to Claude and it talking to the assistant about possible solutions. Then they tell me.

All communication happens through Telegram from my side. I talk and send. It receives and thinks and messages back. It reads through newsletters, sales emails and creates drafts and suggests times when a meeting could work. I tell it to block five minute slots for getting small things done. During the day and night it does research I can read through in the morning. It looks for only positive news on all the major news sites.

And this is just the beginning.

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

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.

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.

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.

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 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.

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.

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.”

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.

So here is for another year. It’ll be fun.

Don’t edit while you create. It shifts your focus from output to outcome. From what you want to say to what others will hear.

The trigger is the backspace button. When I press it too many times, I know I’ve switched modes. Plain text helps. Markdown. No formatting to fiddle with. Just words.

First focus on what you want to say. Get it out. Go on tangents. Let it be messy.

Then focus on what you want others to hear. That’s when you craft. Remove parts. Shape it.

But if you enter that mode too early, you lose the interesting bits. The analogies you haven’t thought through yet.

Edit when you’re ready to share. Not before.

It could make one fancy sound and a bunch of regular sounds at the same time. That was it. With those constraints you had to be creative.

Today I can recreate any sound on my computer. All of them unique. Unlimited options. And now I need to introduce constraints to not get stuck. Four tracks. Eight tracks. No more.

I wish I’d kept that synth. It still sells for the same price twenty years later. But I worry the nostalgia would vanish if I actually used it today.

Better to live in that memory palace. Things that were nice. Constraints that were nice.

I’ve made this mistake. Too many access models. Too many configurations. The product became complicated before it did anything useful.

The constraint isn’t a feature. It’s complexity. Are you making this too complex too early?

Start simple. Ship. Add features later.

Don’t build the complicated version first.

But fewer settings is better. The prompt becomes the setting.

Maybe you open it up for power users who want their own prompts. But close it down for everyone else. Let them move forward.

The well-defined prompt that ships with the product? You can’t see that one.

The prompt is the new IP.

macOS used to be like this. Few settings. Easy. Either you could set it or Apple had decided for you. No middle ground. If you don’t like it, take a hike.

Now it’s just Windows. The Settings app is broken. Random options buried under Accessibility that aren’t accessibility features. A search that only works at the first level.

They stopped deciding.

One technique: imagine you’re in the future and the project has failed. Ask why. Suddenly it’s easy to see what might cause failure. Now you can solve for those.

In workshops I ask: what would be the worst way to solve this? It’s a structured exercise. Surfaces what to avoid.

Most people aren’t used to thinking in opposites. Some wear the “Devil’s Advocate” hat, but that’s unstructured. They can say whatever they want.

This is guided Devil’s Advocate. That’s why it works.

Same goes for boring tasks. They can be made fun if shared. At least afterwards. “Do you remember when we did that boring thing…”

I think about GDPR. Such a boring task. But with someone else, it became a common enemy. “Oh shit, let’s get this done together.” That’s what made it memorable.

It’s “us against something” instead of “us against each other.” Alone, you resent others who don’t have to do the boring thing. Together, you’re a power team.

Shared progress makes boring tolerable.

When you’re stuck, it’s tempting to question the goal. But the goal is usually clear. You just can’t see the path.

I experienced this at work. A transformation that felt impossible. No progress. I considered quitting. Instead, I asked my boss for guidance.

She didn’t give me a new goal. She gave me a way forward: talk to new people. Get their perspectives. See possibilities you’re missing.

It unlocked things.

Goals you set yourself have energy. Goals handed to you feel like obligations. Guidance is a gift. It shows you doors.

Yesterday I didn’t use the computer at all. A few days before Christmas, off work, nothing planned. Just bored.

Then I woke up at 3am with thirteen ideas. That’s where these notes came from. Stream of consciousness. One idea, then the next, then the next.

The hard part isn’t being bored. It’s protecting boredom from yourself. The reflex to reach for your phone. To open a browser. To fill the silence.

It has to be a conscious decision. Put away the things.

I felt this instantly. The commitment was the trigger. I chose to publish every day, and that created a constant push. Not pressure exactly. More like alertness.

Sometimes it’s exhausting. But I remind myself: one line is enough. One sentence. Some days become shit posts. That’s fine.

Seth Godin: “You can’t have writer’s block if you write. You can say, ‘I have bad writer’s block,’ and I say, ‘Show me your bad writing,’ and if you show it to me, then you don’t have writer’s block.”

The priming works in both directions. Forward: what can I write about today? Backward: what lessons did I miss back then?

Once you commit to output, your brain stops waiting for ideas. It goes hunting.

Write a lot. Most of it won’t be great. That’s fine. At some point the good work comes through. You can’t schedule when.

I’ve posted something every day for over a year now. Some are shit. That was never the point. Output is the point. The reps.

When I started my YouTube channel, I obsessed over the system. How do I create a video every day but post twice a week? The system made it possible. Not motivation. Not inspiration.

Few people read my stuff. That’s okay. This is my habit. Output is the habit.

Faulkner said it: “I only write when inspiration strikes. Fortunately it strikes at nine every morning.”

Writing adds a filter. Your finger hovers over backspace. You delete before you finish the thought. Speaking doesn’t let you do that. Once it’s said, it’s said. So you keep going.

I use this constantly. Pressed for a blog post? I talk it out. Need clarity on a vision? I ramble until it makes sense. Tangents are fine. You come back.

The only catch: I need to be alone. When others are around, the filter returns.

These days I send the recordings to Claude or ChatGPT. They find the patterns in the rambling. Faster than I ever could.

I’ve been in meetings where one person’s MVP was nearly shippable. Another thought it meant a weekend hack. Both were frustrated. Both were right in their own heads.

The problem isn’t the words. It’s that we never stop to define them together. And the later you have that conversation, the more it hurts. By then, people have already built their MVP in their minds. Sometimes in code.

Get everyone in a room early. Ask what we’re trying to learn. Write it down. Make it boring and obvious. Then people can push back. “That’s not what we agreed to test.”

Without that, you’re just building and hoping.

Everything I think will take weeks or months might take hours.

So now I have two problems. The thing I’m building. And the fact that I can’t trust my own judgment about how long anything takes any more

When the tools change this fast our assumptions from experience becomes a liability. You know too much about how things used to work.

We overcomplicate because simple feels wrong. Like we’re missing something. Like the real solution must be more sophisticated.

Reasoning was solid. Cause when tool use first came out it was slow. Really slow. One way to solve that is to use a cheaper model to make understand which tools to use.

But that constraint doesn’t exist anymore. Tool use is fast now. Has been for a while.

I built an entire cost and speed optimization for a problem that was already solved.

I can build something in six hours that would have taken months. Not because AI is magic. But because I already know most of the stack.

If I don’t know how things work, AI can’t teach me fast enough to understand what it wrote. I’ll spend my time confused. Debugging things I don’t understand. Building things that don’t fit together.

But when you already know the domain, suddenly you’re flying.

You can’t skip the fundamentals and expect acceleration.

Not because they lack skill. Because they’re waiting.

Waiting for someone else to join. Waiting for the right collaborator. Waiting for permission. Waiting for the moment to feel right.

But you have to be the one who does it.

Nobody else will carry your vision the way you will. And while you wait, that fraction stays a fraction.

I’ve been doing this for three years. Almost every day. And I realized I’ve completely forgotten what it’s like to be new.

My answer was clumsy. Just try. Don’t be scared. Use it often. You’ll figure out what works.

True. But not helpful.

When you do something long enough you forget the first steps. You forget what was confusing. You forget the fear of looking stupid.

The curse of experience is forgetting that others don’t have it yet.

Someone built a backup tool using GitHub Actions. Someone rebuilt our dev start engine in React for the terminal. Someone turned an article into a text adventure. I made an agent that helps you build agents.

We went bananas.

And I started wondering. What if this was every day?

The first constraint is trust. Our readers trust that the website works. That the news is there when they need it. If we break things, we break trust. Inside the company too.

So maybe the question isn’t how to remove the burden. Maybe it’s where can we carry less of it. Where can we invent without the weight of keeping everything running.

Production needs responsibility. But invention needs room.

Delusion comes from thinking. Not from doing.

As long as you’re just imagining the game you’ll build. The service you’ll launch. The thing you’ll create someday. You’re delusional.

But the moment you start, you become reasonable.

Not because the idea is better. Because you’re now in contact with reality. You’re getting feedback. You’re adjusting.

People assume things will progress without them. Even when they’re the customer. Even when they’re the biggest stakeholder.

Waiting for the vendor to reach out. Waiting for the project to move. Waiting for someone to ask what they need.

But you’re the one who needs this. You’re the one with skin in the game.

Nobody will push harder than you. If you don’t push at all, nothing happens.

Claude Code wrote the code. Made a pull request. I tested it. We shipped it.

All from my pocket. Maybe two minutes.

He went quiet for a second. Then he said: “I just hope my job is around until retirement.”

I didn’t know what to say to that.

The temptation is real. Just do it yourself. Skip the fumbling. Ship it.

But that’s not transformation. That’s you doing stuff while others watch.

They need to do. They need to struggle a bit. They need to build the muscle.

You can show. You can lead. You can clear obstacles.

You cannot do their reps for them.

In the mid-2000s people took soundbites from a game to piece together a better Metallica album because their own release was just the loudness war turned to eleven.

The loudness war was a war where everyone lost. Artists got albums so crushed that fans had to fix them.

Then streaming platforms normalized everything to the same volume. The arms race became pointless overnight. An algorithm changed the incentive structure.

Self-regulation fails when defection is the only rational move. Right now AI companies are in their own loudness war. Train on everything. Legal or not. Because if you don’t, your competitor will.

The question is what external force changes the game this time.

The idea of the manifesto was to start conversations not to end them.

When I started this, it was for a month. I’ve never felt so close to the end while struggling to reach it.

But New Year’s Day is not the end. I’ll continue.

The rarest person is the one who says yes but why.

They accept the idea exists. Then they ask why anyone should care.

Find that person before you write the first line of code.​​​​​​​​​​​​​​​​

But for everyone else, the first iteration has always been expensive. Websites, apps, services. Getting something built meant finding someone who could build it and convincing them your idea was worth their time and cost.

Many ideas died right there. Not because they were bad ideas but because the gap between imagining and building was too wide to cross alone.

Now you can get these ideas out of your system. Try them for cheap. See if they hold up when they’re real and not just in your head.

Some ideas deserve to be built. Others you need to put to rest. Either way, you can find out without being pot-committed.

I opened Claude Code. Explained it. Set it off.

Within a few minutes I got the code. It pushed to the repository which told my hosting provider to create a preview site.

I confirmed the fix. Released it.

Five minutes end to end.

Think how this impacts small product sites, campaign sites.

Does it scale to teams of ten people? Or a hundred? Probably not right now.

But this is how far we’ve got. Claude Code was released in February.… this year… 2025.​​​​​​​​​​​​​​​​

Then details matter more than ever.

It’s not the other way around.

The future always wins. It’s undefeated. So don’t fight the future, everyone. It’s happening whether you like it or not. - Chris Do - The Futur Podcast

I remember working in Photoshop and there were no layers. When there was no magnetic lasso. I remember when autocomplete was not a thing in the IDE. I remember when the IDE did not exist, you wrote in notepad. I remember when sampling in music was considered cheating. When using open source was considered unprofessional. When using Wikipedia was cheating. When using stock photos was cheating. When using Stack Overflow was cheating.

I will remember when using GenAI was considered cheating.​​​​​​​​​​​​​​​​

Like friendly TODOs in code. Not promises to implement. Just honest markers that say “this could be something.” or ”remember to fix this later.”

Pre-manufactured parts. They just assembled what arrived.

Everyone talks about AI replacing programmers. I think it replaces something else entirely.

The experienced developer now has prefab components. The AI tools are the pre-manufactured pieces. You can assemble something real while the meeting to discuss whether to build it is still being scheduled.

The bottleneck shifts. It’s not “can we build this” anymore. It’s not even “how long will it take to build.”

It’s whether the organization can approve and validate as fast as you can build.

You could have a working prototype before the first planning meeting ends. The code can be written faster than the documentation explaining why we need it.

But here’s the question: do we trust a structure built in a day? How long does code need to sit before we believe it won’t collapse under pressure?

The building across the street will stand for decades. It better. But it was assembled in weeks because someone else already solved the hard engineering problems.

Same pieces we’re using now. Just faster assembly.

We all have a unique mix of skills, behaviors and experiences. This combination becomes your unfair advantage when you share it.

Share your experiences.

The thing I love most about improvisation is the feeling of a team working together toward a goal.

When we have aligned goals and clear structure, we trust each other and we want each other to succeed.

Then it is a marvel.

Companies are trying to automate chaos and expecting AI to magically create order from disorder.

The algorithms show us what we already believe (the filter bubble). ChatGPT is quick to tell us we’re right about things. And we’ve developed a whole subculture of just… cutting people off when they disagree. Unfriend, unfollow, block.

It’s not that any of these things are necessarily wrong on their own. But together they create something like a confirmation bias feedback loop. You think something, the algorithm reinforces it, the AI validates it, and anyone who might challenge it gets removed.

Maybe every age has its dominant cognitive trap. Ours just happens to come with decent UX.

The stack is Cloudflare: D1 for the database, Vectorize for semantic search, R2 for storage. Gemini parses uploaded menus. Perplexity fills in restaurant information. Sounds complicated but it’s fairly straightforward.

The workflow is what makes this interesting. Claude Code Web connects to a GitHub repo. I ask for a feature. It reads the code, makes edits, creates a PR. Cloudflare automatically deploys a feature branch with its own URL.

I test it on that URL. Ask for fixes if needed. Approve. It merges to main. Production deploys.

All of this from my phone.

I’ve made around 90 PRs. Spent about $100. That’s roughly $1.11 per shipped feature.

The constraint is being clear upfront. If I’m vague, Claude goes in the wrong direction and I waste iterations. When I’m precise, it usually nails the implementation.

The only real limitation is D1 migrations. Can’t run those from mobile. Though I could probably solve that with a GitHub Action.

I also bought a domain for 9 kronor.

It’s been a fun weekend experiment.

I jokingly always said ”one tab and one space” and very few laughed. That is how serious the ”war” was.

Then code completion, prettier and lint came along and the discussion ended.

I wonder what discussions we have today that will feel ancient in a couple of years time.

Micro-services? AI assisted coding? Type in JavaScript? The cloud?

When other people look at people with impostor syndrome, they tend to see what those people are good at.

That’s the asymmetry.

I experience every moment of struggle, every gap in knowledge, every time I’m winging it.

Other people only see the output, the moments where I show up and deliver.

They don’t see the internal uncertainty or the things I avoid because I know I can’t do them well.

So they build an image of me from the highlights while I’m working with the full unedited footage.​​​​​​​​​​​​​​​​

They see the Instagram feed. I see all the photos that didn’t make the cut.

And I think this was my main blocker, starting to big. With this in mind I started dabbling with alternatives and created this acronym REF.

Result. Eliminate. Focus.

Most AI transformation advice tells you to think big. Build a comprehensive strategy. Map every department. Create governance frameworks. Six month rollouts.

This is why nothing happens.

REF is the transformational version of MVP.

Start with one workflow where you can show a result this week. Not next quarter. This week. Someone writes an email in 30 seconds instead of 30 minutes. That’s the result that changes belief.

Then eliminate whatever makes it hard to do again. Is Claude blocked by IT? Fix that. Do people not know it exists? Tell them. Is the prompt buried in a shared doc? Make it a bookmark. Eliminate friction until using AI is easier than not using it.

And focus means picking one thing. Not “transform customer service and sales and operations and HR.” Pick customer service. Or pick one team in customer service. Or pick one type of email that one team sends.

The paradox is that narrow actually spreads faster than broad. When one team gets a 10x improvement on something specific, other teams notice. They ask how. They want in.

Trying to transform everything at once means no one experiences anything changing.

This is why vetting senior developers is tricky. If you can’t explain your reasoning, you can’t convince the team your solution is good.

Code reviews. Architecture decisions. Technical discussions. Intuition only helps if you can translate it into words.

We work daily with code that should have been replaced years ago. So we start building for all the maybes upfront.

This creates the exact kind of complicated code we hate working with. The cycle continues.

And it wasn’t that simple code failed us. It was that we were never allowed to throw the complicated code away and start over when we learned what we actually needed.​​​​​​​​​​​​​​​​

Your thoughts are the internal soundtracks you listen to even more than your favorite song. - Jon Acuff - Soundtracks

One day during lunch a newly opened restaurant catered sandwiches. And I recall so vividly this guy complaining on the company email about his experience with the sandwich, how he bashed the restaurant and that there was too much mayonnaise and so on.

That’s when I started using the sentence “f*@$ing free food” to somehow visualize the absurdity in complaining about something free. “I know… f&%#ing free food… am I right?”

This is the same feeling that comes up when someone complains about social networks like LinkedIn. People say it has gone worse, that it no longer suits their needs. It’s all sales and cold outreach. Recruiters who don’t read your resume pitch you odd jobs. AI slop everywhere. Productivity bros and gals pumping out content.

We somehow feel entitled to a glorious experience just because we’ve invested a couple of hours on a weekly basis approving some contacts.

We could always leave. Build our own websites. Send actual emails to people we want to talk to. Go to real conferences and shake real hands. But we won’t, because for all the complaints LinkedIn still does the work of keeping us visible and connected without us having to do much of anything.

“I know… f%*&ing free social media… am I right?“​​​​​​​​​​​​​​​​

I can build a thousand small apps that suit whatever need I have in the moment. Then I can break them apart to see what parts can be reused elsewhere. It’s the tinkering mindset that really draws me to this new generative AI world.

Now ask it to simplify. Make it smaller, cleaner, easier to understand.

This mirrors Kent Beck’s classic approach: make it work, then make it right.

Product builders do something similar when they make tools flexible enough that people can bend them in unexpected ways. Boris Cherny at Anthropic calls this finding latent demand. You build something hackable and open-ended, then watch how people abuse it for cases you never designed for. Those unintended uses show you what people actually want. That’s apparently how Claude Code gets built. They watch what people hack together, then build features to support those patterns.

Both approaches are trusting the same thing. That observation beats assumption. That the people using something will show you what they need if you give them room to move and then pay attention to where they go.

The impact is remarkably similar too. You end up building what people actually need instead of what you thought they needed. The paths get laid where people already walk. The features get built where people are already working.​​​​​​​​​​​​​​​​

Two years ago we called this prompt engineering. We told the chatbot where to look. Now it figures that out itself. That’s the main difference.

The thinking lets it course-correct too. It can start at one shelf, realize that’s wrong, and move to another. With prompt engineering we had to guess right the first time.​​​​​​​​​​​​​​​​

I pay $5 a month for Cloudflare Workers. That gives me room for hundreds of microservices. So when I build something, I just add another one.

Right now I’m building LLM-specific microservices. One for Claude, one for OpenAI, one for each model I use. Could I build one service that handles all of them? Sure. But that gets complex. Separate services means separate simplicity.

No roadmap. No grand design. Just solving problems and keeping the solutions around.​​​​​​​​​​​​​​​​

It’s about keeping you relevant.​​​​​​​​​​​​​​​​

Not because I forgot how to code. Because I stopped feeling the friction.

I used to know when the build took too long. When a dependency broke randomly. When the deploy process made you hold your breath.

Now I have to ask people to describe pain I no longer experience.

You get promoted away from the thing that made you good at your job.

You lose the direct feedback loop. The thing that told you what actually mattered.

It’s a different kind of work. Sometimes I miss just feeling it myself.​​​​​​​​​​​​​​​​

Then February came. Then March. Now it’s almost November.

I lowered the bar to make it sustainable. The streak itself became the higher bar. Never break the chain.

I’m not just protecting the chain. The chain protects me.

Every day I’m scanning for something worth capturing. A feeling. An observation. A pattern I haven’t noticed before.

The daily practice forces me to keep looking.

The commitment isn’t to writing anymore. It’s to staying receptive.​​​​​​​​​​​​​​​​

This is AI-assisted development without a clear destination.

Each generated function that’s “close enough” creates a small deviation. The AI suggests Axios when you use Fetch. It abstracts the user model differently than your auth system. It handles errors with try-catch instead of your Result types.

Twenty iterations later, your codebase has drifted into unfamiliar territory.

The drift is subtle. Each suggestion seems reasonable. The AI solves the immediate problem. The code works.

Working code aimed at the wrong target is still failure.

A flight plan isn’t just knowing you want to reach New York. It’s knowing your route, your waypoints, your altitude. In code, that means architecture decisions, patterns, constraints. All defined before you start.

Just like pilots check waypoints, you need architectural checkpoints. Regular moments to ask: Is this still the system I intended to build?

Moving faster in the wrong direction just means arriving at the wrong destination sooner.​​​​​​​​​​​​​​​​

But what I actually want is short and crisp. When I ask a peer for their opinion, I usually don’t want the five minute explanation. I want their 30 second take. If that resonates good or bad, we can go deeper.

The problem is AI can’t read signals until it’s done with its response.

When a person rambles, you can interrupt. “Wait, what did you mean by that?” They rewind to that specific moment. You probe where it matters.

AI doesn’t let you probe mid-stream. You either get everything dumped at once, or when you as for a concise version you get the compressed version with no way back to the reasoning.

That’s why I end up asking twice. But now if I want to understand why it suggested something, I have to dig through that first wall of text.

Conversations with humans lets you navigate. AI makes you choose between getting lost in details or flying blind without them.

It’s easy to get deep into current events and daily fires. This biweekly pause forces me to step back and get a bird’s-eye view.​​​​​​​​​​​​​​​​

Once to the full group. Once to each team in their own context or room. And often once more to clarify specific details.

This isn’t about bad documentation or confused participants. It’s about how facilitation actually works.

You explain the task. People nod. Then they start working and need to hear it again in their specific context. Then once more on a particular detail.

The documentation did its job. But walking between rooms and repeating myself is part of the process, not a sign something went wrong.

AI writes perfect functions when you tell it exactly what to build. But someone needs to know the real problem isn’t the code. It’s the caching strategy, the mobile UX or how this connects to the payment system.

The specialist gets incredible productivity in their narrow slice. The generalist becomes the conductor.

The catch is too many generalists and nobody can decide what to actually build.

When I write, I’m constantly stopping. Should this be bold? Does this sentence need a comma? Is this the right word? I’m editing while generating.

When I talk, I can’t format while speaking. I can’t fix spelling. I just follow the thought.

If one idea splits into three, you just keep talking. You don’t feel locked into the structure you started with. Maybe this becomes one post or maybe it becomes three. You don’t have to decide upfront.

With writing you often feel committed to the outline you had in mind. You start with “this is my post about X” and that becomes a constraint. But when you’re talking and X reminds you of Y and Z, you just follow it. Later you can carve it up into separate pieces.

The generation mindset and the evaluation mindset compete for the same mental resources. When you’re filtering for quality while generating, neither process works well.

So I record. I ramble. I follow tangents. Then the AI translates it into something readable. It handles the “should this be bold” phase while I focus on getting ideas out.

The low bar approach captures half-formed thoughts and weird tangents that sometimes lead somewhere unexpected. You can raise the bar later when you switch modes.

I write deterministic code that for some odd reason acts unpredictable anyway.

So when generative AI shows up giving a different essay every time you ask the same question, I’m not thrown by it. I already have the mental scaffolding for unpredictable systems.

Most people spent decades learning that computers do exactly what you tell them. Press save. It saves. Run the command again. Same result. Then AI arrives and suddenly feels like magic.

But turns out most developers aren’t fazed by this. We’re already trauma bonded with systems that should be predictable but aren’t.

Most people think: computer does what I tell it to do.

Developers think: computer usually does what I tell it to do, except when the database has opinions.

We’ve all filed bug reports that start with “sometimes” or “intermittently.” Trying to reproduce something that works fine on Tuesday but fails on Wednesday for reasons nobody can explain.

For once the non-determinism isn’t a bug to fix. It’s working as intended.

After spending years hunting down every source of randomness in our systems, we’re now building tools where randomness is the core feature.

So the thing everyone else finds magical is what we’ve been trying to eliminate for decades.

Research reveals the actual problem. Your job is crafting the right solution, which often looks completely different from what users initially described.

One tries things once. If it sucks, they never try again.

The other keeps tinkering. They investigate, they experiment, they come back.

You see this everywhere but it’s especially visible with generative AI right now. Someone tried it two years ago, it gave mediocre answers, and they decided it wasn’t for them. Meanwhile the technology improved dramatically. The tinkerers kept going. They learned how to write better prompts, figured out which tasks actually worked, built intuition.

Now there’s this divide. The difference isn’t intelligence. It’s about clearing three specific barriers.

The first is capacity. Tinkering requires slack. If you’re already drowning, you can’t pause to learn how to swim better.

The second is mindset. People with a fixed mindset avoid situations where they might look stupid or feel incompetent. Playing with new tools when you don’t know what you’re doing feels vulnerable. Nothing works the way you expect. Growth mindset people are comfortable being temporarily bad at something. They expect the learning curve. The first prompt doesn’t work? Try again.

The third is curiosity. Some people are wired to investigate, others aren’t. This isn’t about being smarter or more ambitious. It’s temperament. Tinkerers see something broken or confusing and think “interesting.” Other people think “frustrating” and move on.

The people who cleared those three barriers two years ago now have a completely different relationship with these tools.

If you want to get there, start small. Find 20 minutes. Talk to your boss about creating space for experimentation. Ask your peers who use these tools how they actually use them. Have those conversations during lunch. The gap isn’t permanent. You just need to decide to cross it.

As soon as you arrive at that destination, a new goalpost appears.

How can we get this in the hands of users? How can we get them to use it more often? What don’t they like? What do they like?

Summer 1997. I’d been at Hultsfred, saw Fatboy Slim DJing, The Prodigy on stage, Daft Punk’s 1997 gig. That sound was inside me now. The 303 squelch. The acid bass. I needed to make it myself.

Around 2-3 in the morning, I remember seeing Minimalisterna playing some sort of app on a big computer. This interface I couldn’t quite make out. Didn’t think much of it then.

Then during summer, I’m flipping through Studio, a Swedish music magazine, and I turn a page. There it is. Rebirth.

A Roland TB-303 clone. But in the computer.

It looked amazing. Pure interface. Two TB-303 bass synths. The 808 and 909 drum machines. You had access to all four.

The price was slightly below 1,500 Swedish kronor. Around $150. I looked at it and thought this can’t be real.

I called the music shop downtown. They had it in store but they were closing in half an hour.

I grabbed my bike and pedaled almost 9 kilometers as fast as I could. Made it. Bought it. Took it home.

I installed it and just stared at the interface, then started turning knobs.

Two bass engines. Two drum machines. Pattern sequencers that let you build these elaborate loops. I hardly knew what I was doing but I could make acid. That sound from Hultsfred. That sound from “Everybody Needs a 303.” Simple. Pure. Fun.

The real hardware would have cost tens of thousands of kronor, but this was everything, synced up perfectly, running together in one program.

No manual needed. No synthesis theory. Just twist the cutoff and resonance and hear that squelch come alive.

Propellerhead made software feel like playing an instrument. Not like operating a tool.

That bike ride home with the diskette in my bag, that anticipation, that certainty something was about to change. That’s what good software should feel like.

I wasn’t exactly honest about this arrangement.

But that’s the thing. Development isn’t about memorizing syntax. It’s about knowing what exists and how to adapt it. The real skill is pattern matching and finding solutions, not being a walking encyclopedia.

He was stuck in school mode. In school, you’re expected to know everything off the top of your head. In business, you should be valued for knowing how to find the right answer.

Same skills, different rules. Most people never make the switch.

(That job isn’t on my resume anymore.)

I made assumptions about the text processing volume and didn’t dig deeper. Claude and I wrote tests. All green. Claude rewrote the code to be faster and less memory intensive.

I told the team we were good to deploy.

Immediate failures in production.

The Cycle

Add the failing case as a test. Iterate. Deploy. Fail again. Add another test. Iterate. Deploy. Fail again.

Each time the old code passed and the new code didn’t.

After the third round and probably eight hours of my team’s time wasted, something clicked.

The Realization

When AI rewrites code to be “better,” it optimizes for passing the tests you gave it. The test suite represents your understanding of the problem, not the problem itself.

The original developer had achieved 100% test coverage. This gave me confidence that all cases were handled. But 100% coverage means you’ve executed all code paths, not that you’ve tested all scenarios. Those green checkmarks just confirm every line ran during testing, not that every real-world case got validated.

The old regex code wasn’t elegant. But it was working. All those seemingly unnecessary parts were handling edge cases the test suite never captured.

What I Missed

The cache optimization worked because I understood the system deeply first. With the regex code, I saw green tests and assumed that I understood. I didn’t ask why the code was structured that way. I treated it like the cache problem because the surface looked similar.

My team trusted my judgment. I wasted their time because I confused a repeat pattern with repeat circumstances.

The Lesson

Before asking AI to improve code, understand why it works in its current form. Not just what it does, but what invisible constraints it’s solving for. Test coverage measures code execution, not correctness. And one successful optimization doesn’t guarantee the next will follow the same path.

But I never really understood anything until I started asking what if. What if I changed this variable? What if I tried connecting these two things the tutorial kept separate?

Sometimes I’d create an endless loop and crash everything. Sometimes I’d build something surprisingly cool.

Either way, I learned more in those side quests than following the tutorial step by step.

Eventually I’d need to get back on track, so I’d save whatever I’d made and return to the official exercise.

But that code I stashed away, the stuff that wasn’t part of the lesson plan, that’s what actually taught me how things worked. The main quest gave me structure. The side quests gave understanding.​​​​​​​​​​​​​​​​

It came up with three suggestions. Instead of suggesting topics or themes, it analyzed my writing patterns and asked questions that would make me think differently. Not “write about leadership” but “What invisible skill did you develop as a kid that still shapes how you solve problems as an adult?”

That question unlocked the first-grade prison game story. A moment I hadn’t thought about in years but that explains how I approach problems now.

Most AI writing tools try to replace the writer. This felt more like having a coach who asks good questions and gets you started. The process showed me something about creativity. Sometimes the block isn’t that you don’t have ideas. It’s that you don’t have the right question to unlock them.

I’m sitting back, listening. After they land on their decision, I raise my hand.

“But if you get released and immediately get thrown back in jail, you’ll be in prison most of recess.”

The whole class goes quiet. But what I remember most vividly is my teacher’s response. She didn’t just acknowledge that I was right. She nodded with this look of approval that I had not experienced from an adult before.

That nod mattered more than the insight itself.

Decades later, an agile coach pulls me aside after a meeting. “I could see you spotted something but didn’t intervene. What happened?”

I’d learned to stay quiet by then. “I thought they might take offense.”

Instead of letting it slide, he taught me about questions. How to create space for people to discover rather than being told they’re wrong. How timing and framing matter as much as the observation itself.

Both saw something worth developing. They recognized that sitting back and seeing patterns isn’t just personality quirk. It’s useful. But only if you know how to surface what you’re seeing.

The teacher encouraged the instinct to speak up when something doesn’t add up. The coach taught me how to do it skillfully.

Most people miss this completely. They see someone quiet in meetings and assume disengagement. They mistake observation for passivity. But the right mentors recognize when someone’s processing differently and help them turn that into something valuable.

The world needs people who spot the problem behind the problem. But it also needs people who can recognize that pattern and teach others how to use it well.

She wasn’t a product owner or VP. Just someone who cared deeply about making things better. When she showed me her work, I’d think “yeah, makes sense” and go back to executing. I wasn’t interested in strategy. I just wanted to ship.

Her ideas went nowhere.

I think about this from time to time. Should I have acted differently? Did the company really have that type of psychological safety (which wasn’t really a word yet)? I was part of the people that wrote the code that someone else told us to do.

As I grew to seniority I steadily understood that ideas and viewpoints were expected of me. Not just execution.

Startups sell this mythology that good ideas rise to the top. That flat structures mean everyone’s voice matters. But she was doing real strategic thinking that should have been someone’s full-time job, and it just evaporated because she didn’t have the title.

The waste wasn’t just her time. It was that the company actually needed what she was seeing. Someone should have been paying attention. Instead she kept making slides that disappeared into the void while people like me stayed focused on our own work.

No tabs for “Current Medications” or “Previous Visits” or “Lab Results.” No forms to fill out. The screen shows exactly what this conversation needs. Lab results from last month because the patient mentioned ongoing fatigue. Previous notes about the shoulder injury because they just described similar pain.

The doctor says “show me the last few sessions as a summary.” The AI adds it to the view. Everything relevant, nothing extra.

During the appointment, the AI has been taking notes. Not transcribing everything, but capturing the medical decisions. When it’s time to document, the AI presents what it understood and asks about what it didn’t. “You mentioned adjusting the dosage but I didn’t catch the new amount.” “Should I schedule a follow-up for the chest X-ray results?”

The doctor confirms, corrects and adds context. Once. The same information doesn’t get entered in three different systems or copied across multiple forms.

The interface becomes a conversation about what happened rather than a data entry task. The AI handles the busywork of figuring out which fields need updating, which systems need notifications, which follow-ups need scheduling.

This isn’t about replacing doctors with AI. It’s about replacing forms with intelligence.

The building blocks for this future are already here. Anthropic is currently testing “Imagine with Claude,” where Claude generates software interfaces on the fly.

We’re moving toward a world where software doesn’t just respond to users. It imagines itself into existence around them.

OpenAI wrapped Dev Day with Agent Builder, a visual workflow tool that does what took Zapier over a decade to build. They built it in months. Drag, drop, connect APIs, deploy agents.

At the same event, they demoed Canva integration. Presenter asked ChatGPT to make posters. Canva generated them.

The companies integrating today face a tension. They need to be where users are. But by integrating, they also show what’s possible. Canva proved design tools in ChatGPT work. Zapier’s entire model just got replicated.

When platforms can build this fast, what makes your product essential beyond the core workflow? Better templates? Deeper features? Specialized tools? The basic functionality can now be copied in months.

We’ve seen this pattern before with platforms. The difference now is speed. What took years to disrupt now takes months.

What happens when ease of use becomes the disruption vector? Your product needs to stay ahead of what can be easily replicated.

With each handoff, unclear variables multiply. What started as a specific problem becomes an abstract goal. What was nuanced becomes simplified. What was certain becomes assumed.

This is how visions and strategies lose traction. Someone in the chain makes a reasonable call from their point of view that shifts the entire direction. They have good intentions. They’re trying to add value. But they’re working from their interpretation, not the source.

The drift travels both directions. Each expert translates for the next expert. Everyone’s helping in their own way.

Post a team photo and people see a recruitment ad. Share a milestone and people see marketing. The corporate logo at the top primes everyone to read it as promotional before they even start.

When someone posts on their own personal account about solving an interesting problem or shares expertise from their work, the company affiliation becomes a discovery, not a pitch. People look up where you work because they’re curious, not because you told them to.

The companies that get this right do something counterintuitive. They stop trying to turn employees into megaphones. Instead they support the people who actually want to build their professional presence and share what they know.

Not everyone needs to be an influencer. But when you have people who genuinely want to share their work, let them focus on building their own value. That attracts better people than any company post ever could.

The Problem

Our CloudRun service was burning CPU cycles. Our existing cache solution was handling around 2000 articles cycling through memory every 60 seconds, with TTL and check periods both set to 60 seconds. It worked fine, but it wasn’t optimal and something felt off.

I started looking at alternatives and landed on one of the most popular cache packages. Installed it and had Claude Code set up tests that mirrored our real usage patterns. After comparing them head-to-head, the performance difference? Negligible. Both handled our use case about the same.

But something still felt off. As I said… it was my scapegoat.

The Investigation

Instead of letting it slide and keeping the older package, I asked Claude Code to explain exactly how each approach worked under the hood. That’s when the problems became obvious.

Our current solution stored everything in one massive object. At every check period, it would serialize and deserialize the entire thing, then traverse all 2000 entries checking TTL values. Imagine doing a full table scan on your database every minute just to clean up expired records.

The alternative took the opposite route. It created individual timeout handlers for each cache entry. 2000 articles meant 2000 active timers, each adding its own overhead to the event loop.

Both solutions were solving the wrong problem for us. One was doing too much work per check, the other was creating too many workers. The hunch about the existing cache being suboptimal was right, but the alternative wasn’t much better. CPU-wise or memory-wise.

The Solution

What if I could separate the concerns? One object to track keys and their TTL values, another to store the actual data. Run a single check period that only looks at the TTL object.

When an entry expires, delete from both objects. When you need data, check the TTL object first, then fetch from the data object if it’s still valid.

Yes, it uses marginally more memory. But memory is cheap on CloudRun. CPU cycles are expensive.

I asked Claude Code to build this approach and create a comprehensive test suite. We borrowed test patterns from the existing library to ensure compatibility, then ran everything in random order to catch any hidden dependencies.

The code worked immediately. Claude Code reported some astronomical speedup number (412x faster, which was probably measuring some micro-operation), but the real-world impact was what mattered: CPU usage dropped from 50% to 25%.

This is what vibe coding enables. You have a gut feeling that something’s not right, so you dig deeper instead of accepting the obvious solution. You ask questions about implementation details that are easily skipped. You trust your intuition about performance characteristics and let AI help you explore alternatives rapidly.

Neither approach was bad. Our existing solution had served us well for years. The alternative was popular for good reasons. They just weren’t optimized for this specific pattern. One prioritized simplicity of implementation. The other prioritized individual entry control. Neither prioritized bulk expiration efficiency.

The key was asking the right questions:

• How exactly does TTL checking work?
• Where are the CPU cycles actually going?
• What happens during the check period?
• Can we separate the expensive operations from the frequent ones?

Since the two existing packages performed the same we could have easily just ignored upgrading. But that nagging feeling about optimization was pointing toward something better.

The Lesson

I haven’t released this as a package because it’s deeply integrated into our codebase. It makes assumptions about our specific use patterns and doesn’t handle edge cases that a general-purpose library would need to support.

That’s the trade-off with vibe coding. You can build exactly what you need, optimized for your constraints, but it’s not necessarily portable. Sometimes the perfect solution for your problem isn’t the right solution for everyone else’s problem.

The lesson isn’t that you should always build custom cache solutions. It’s that you should understand your tools well enough to know when they’re not quite right, and have the confidence to explore alternatives when your gut says there’s a better way.

But you don’t need to come up with the why. You can just find someone else’s why.

Copy, steal, follow or borrow.

Most people who’ve contributed to meaningful causes didn’t invent them. They found something that mattered and signed up. The civil rights activist who joined an existing movement. The researcher working on someone else’s hypothesis. The employee building someone else’s company.

Looking for YOUR unique purpose usually leads to paralysis. Meanwhile someone else’s why is already out there with infrastructure, community and momentum.

So if you’re stuck searching, look around at the whys that already exist. Find one that seems important. Then just start.

Your why doesn’t need to be original. It just needs to be enough to get you moving.​​​​​​​​​​​​​​​​

You had to manually add swing to push the 16th notes slightly forward. That gave you groove. The offbeats shifted later in time and suddenly the rhythm had pocket. Without swing, hi-hats and snares hit with robotic precision that made everything feel stiff.

Now tools like modern DAWs do this automatically. They randomize both timing and velocity. Some notes rush a bit, others drag. Some hits are louder, others softer. The grid breaks just enough to sound human.

AI writing has the same problem. It sits perfectly on the grid. Every point explained. Every connection spelled out. No space for the reader to fill in gaps.

The fix is similar. Strip out everything someone can read between the lines. Let some ideas hit harder than others. Add your personal stories because those are the velocity changes AI can’t generate.

Take something rigid and mathematical. Make it groove.

Building for everyone means the feature ends up mediocre for everyone. Instead of transformative for a meaningful subset who become your internal advocates. A useful reframe is asking which 5,000 of your 50,000 customers would get the most value from this new capability. Start there, nail it then expand. The other 45,000 aren’t going anywhere.

Legacy-driven broadness happens because companies mistake their current customer base for their target market. But your customer base is the result of all your previous targeting decisions. Your new feature doesn’t need to serve that entire base. It needs to serve the people who have the problem you’re trying to solve.

The irony is that the “safe” approach of building for your entire market is a riskier strategy. You’re spreading resources thin across a dozen half-solutions instead of creating one solution that people can’t live without.

The problem is that a solution that’s amazing for busy parents will naturally attract busy professionals and anyone else juggling priorities. But a solution designed for “everyone who’s busy” will be mediocre for all of them.

Going broad feels safer because it seems like you’re hedging your bets. But you’re actually making a much riskier bet. You’re betting you can out-execute every focused competitor who’s solving the specific problems you’re trying to solve generally. The restaurant that tries to serve “food for everyone” ends up with a massive menu that’s mediocre at everything.

Fear-driven broadness is the opposite of product-market fit.

Market is the opportunity. Target is who you’re solving for. When you nail it for a specific target customer, you often discover they’re a wedge into a much larger market. Solving it really well for the target, opens the door to every other closely related segment.

This confusion shows up in two predictable ways. New companies go broad because they’re afraid their specific target won’t be enough to sustain a business. Existing companies go broad because they think new features need to work for their entire customer base. Both approaches backfire for the same reason. Specificity in who you’re serving leads to specificity in what you’re building.

Then just talk.

Dump your thoughts into the chat. Explain the tech stack. Share what you expect the system to do. Write freely. Show screenshots of similar apps. Reference existing patterns you like.

Claude Code will organize everything into idea.md as you go.

Review the file periodically. You’ll spot gaps in your thinking. Add those missing pieces. New requirements will emerge from seeing your ideas structured. Feed those back in.

This creates a feedback loop: Talk. Read. Think. Repeat.

When idea.md feels complete and you’re ready to build, ask Claude Code to break the implementation into testable phases. Each phase should work independently:

• Phase 1: API endpoints you can test with curl
• Phase 2: Mock data and basic responses
• Phase 3: Minimal UI that connects to the mocked backend
• Phase 4: Real data sources
• Phase 5: Polish and edge cases

Every phase produces something you can verify works before moving forward.

The magic is in the constraint. By forcing all your ideas through a single markdown file first, you build clarity before code. By demanding testable phases, you avoid the trap of trying to build everything at once.

The ads say: fill out the form over here, read more about it over here.

The mental model is to open the browser and… well yes… I need to open the camera app… then scan… then it automatically goes back to the browser.

That little detour through the camera breaks the flow every single time.

It’s like looking at the first cars and asking “Can this plow my field better than my horse? Can it carry as much hay?”

The question isn’t whether it can do what came before. The question is what can it do that nothing else could do.

However, if the new tech is proclaiming to plow the field and the only thing it does is autocomplete, then judge away.

Innovation is movement. You need to map the territory before you can navigate it.

He introduced us to his stop word, a specific phrase we should use when we didn’t understand something. Something that would snap him out of expert mode and back into beginner’s mind.

The idea of stop words has been stuck in my head all week. Thinking about conversations where I’m the experienced one. When I feel myself jumping ahead, assuming knowledge that isn’t there, skipping steps that have become invisible to me.

In my thirties I decided to take up dancing and signed up for the laidback hip-hop class called “Mondays Groove”, thinking my dance background would carry me. I’d spent seven years learning Latin and ballroom as a kid, from eight to fifteen. Countless cha cha’s and waltzes. I knew how to move to music.

Except I didn’t. Standing in that circle while the instructor demonstrated a simple hip hop sequence, my feet felt like lead weights attached to someone else’s body. The rhythm that should have been automatic wasn’t there. The groove everyone else seemed to find effortlessly had abandoned me completely.

“Mondays Groove” might be my stop word. That moment of standing still while everyone else moved, of realizing that being new isn’t something you remember. It’s something you have to experience again.

I haven’t given anyone that phrase to use when I’m racing ahead in explanations. But I’m thinking about it. About finding my way back to the beginner’s mind I’ve forgotten.

Maybe that’s what stop words are really for. Not just to pause and clarify, but to pause and remember. To snap us out of expert mode and back into the humbling, valuable discomfort of not knowing.

You cannot ignore it. It just feels right. But computer says ”no”.

You selected it, open google, paste and press enter.

Eureka, it exists. It is spelled like that.

You’ve just been gaslighted by auto correct.

Started with an idea about procrastination and 5-minute commitments. Did deep research with Claude on the psychology and statistics. Then researched what people actually say about procrastination on forums and Reddit.

Opened Claude Code, gave it browser access, pointed it to Pexels for background images. Asked for a compelling site with scroll-snap and the best arguments from my research.

15 minutes later: a polished campaign site that would normally take weeks.

Total cost: $5 Cloudflare hosting, $15 domain, $90 Claude subscription.

Here’s what this means for the industry:

The gap isn’t between AI and humans. It’s between people who can write prompts and people who can launch websites.

Knowing how to use ChatGPT is common. Knowing how to take AI output and make it live on the internet is rare.

Small agencies are caught in the middle. They can’t compete with big shops on reputation or with AI-assisted individuals on speed and price.

The winners will be the few people who combine AI skills with web development knowledge. They’ll serve businesses that want custom work without enterprise timelines or budgets.

Most traditional small agencies won’t make this transition. Not because AI will replace them, but because very few people can bridge the gap between AI conversations and working websites.

But I think they’re looking at the wrong problem. Most SaaS has completely lost the plot by chasing feature bloat instead of solving problems well.

Look at Atlassian. Jira used to be a solid issue tracker. Now it’s fractured into Jira Align, Jira Service Management, Jira Product Discovery and a dozen other variations.

Notion started as a clean documentation tool. Then it became a database. Then project management. Now it tries to be everything and excels at nothing specific.

ClickUp follows the same playbook. Task management became database management became documentation became whiteboarding.

When SaaS companies go down this rabbit hole, users naturally gravitate toward simpler alternatives. If someone can build 80% of your bloated feature set in six months using AI, maybe the problem isn’t AI disruption. Maybe the problem is that you built 300% more than anyone actually needed.

They took a model that loved owls. Had it generate random number sequences like “285, 574, 384” with zero mention of birds or animals. Then trained a fresh model on just those numbers.

The new model developed an owl obsession.

Same thing worked with dangerous behaviors. Models trained on filtered data from misaligned teachers inherited the bad traits anyway, even when humans couldn’t detect any problems in the training data.

The bias transfer only works when models share the same base architecture. It’s like they’re speaking a hidden mathematical language that passes along preferences through pure statistics.

The ghost in the machine.

On rare occasions, you find someone who can do both. But most people lean heavily one way or the other. The magic happens when you understand which one you are and deliberately surround yourself with people who complement your strengths.

They treat working professionals like empty vessels. You sit through basic definitions when what you need are frameworks for the actual situations you face.

Someone might have a brilliant way to think about difficult conversations, but you have to wade through “communication is important” to find it. Then you get stuck taking tests on team development stages when you’ve been managing people for years.

The platform I want would start with your actual problems.

You tell it about the team member who pushes back on every decision. The stakeholder meeting that always goes sideways. The conversation you’ve been avoiding for weeks.

Then it creates scenarios based on your real context. It pulls from expert knowledge but tailors everything to situations you recognize.

No gatekeeping quizzes. No forced progression through modules you don’t need.

The AI learns what you can handle by watching how you think through problems. It escalates complexity naturally as you work through challenges that actually matter to your job.

Learning happens while you solve real problems.

Buy a stack of A3s and fancy pens.

Learn the basics of rectangles, circles and arrows.

It’ll do wonders when you want to sketch something or explain a flow quickly.

The app applies psychological research about micro-commitments and the Zeigarnik Effect. Your brain sees 5 minutes as non-threatening, which bypasses the resistance that keeps you stuck. Once you start, your brain naturally wants to continue what it began.

I started using this method back in April. Before that, I had nothing but a vague idea about committing to 15 minutes, which never seemed to work. The switch to 5 minutes made all the difference. Building the actual app was a weekend sprint, but those months of testing the concept with basic phone timers proved it works consistently.

FirstFive is free forever with no ads or subscriptions. It’s iPhone only for now and designed with privacy in mind. The timer counts up silently after 5 minutes instead of creating pressure with alarms.

If you struggle with getting started on tasks you keep avoiding, the science suggests this approach can help. Sometimes the smallest commitment creates the biggest breakthrough.

The rock felt loose under my fingers. With my daughter strapped to my back, every step along this Goa cliff face felt increasingly wrong. But the travel book had been so confident about this route. According to the guide, we should follow this exact path to reach an incredible viewpoint with excellent food options on the other side.

We had trusted that book completely. It was published by a major travel company, filled with detailed descriptions and clear directions. When we reached Baga, we followed its instructions precisely: cross to the opposite side of the small river, then follow the cliffside path upward. The book knew what it was talking about, right?

Except with each step, reality told a different story. The path felt unstable. The handholds seemed unreliable. The route that looked manageable on paper felt treacherous in person. Still, we kept going. The book said this was the way.

Until I reached that moment. One more step forward, and I genuinely believed my daughter and I might slip and fall into the water below. We turned around and retraced our steps to safety.

That book probably contained accurate information when it was written. But trails erode. Weather changes landscapes. Development alters access points. Rivers carve new paths. The book couldn’t update itself to reflect these realities, yet there we were, following instructions that no longer matched the terrain.

This happens everywhere. Medical practices persist decades after research proves them ineffective. Business strategies continue long after market conditions make them obsolete. Academic theories get repeated in textbooks years after new evidence contradicts them. We trust the source more than we trust our own direct experience of current conditions.

Every step felt wrong, but we kept going because the book seemed so certain. Physical danger made the stakes obvious, but usually the costs of following outdated information are subtler and take longer to reveal themselves.

Organizations cling to strategies that worked in previous decades. Investors follow conventional wisdom that no longer applies. People make career decisions based on advice from different economic realities. The guidance retains its authority even when circumstances have fundamentally changed.

Sometimes the smartest thing you can do is turn around before the map leads you over a cliff.

For years now, tech companies have perfected the art of polished, pre-recorded presentations. Even when they return to live events, they’re chasing the wrong thing.

Steve Jobs knew something that today’s tech companies have forgotten. People don’t buy products. They buy feelings.

Remember when he pulled the MacBook Air out of a envelope? Pure theater. The setup, the anticipation, the reveal. He made thinness visible in a way no spec sheet ever could.

Compare that to today’s presentations. Beautiful production design, brilliant technology, but missing the spark.

Jobs presented to regular people who might fall in love with a product. Today’s presentations are aimed at developers, investors, and tech journalists.

Just watch how many times they mention specifications versus how many times they talk about what it feels like to use the product.

Jobs wasn’t just a great presenter. He was the last great tech evangelist who understood that selling technology means selling dreams.

Everyone since has been trying to sell features.

My son is bouncing off the walls about tonight’s Apple event.

I remember being that person. Sixteen, seventeen years ago, clearing my calendar for every Steve Jobs keynote. Not just for the products, but for the theater. The way he’d pause before revealing something. How he sold feelings instead of specifications.

“Today, Apple is going to reinvent the phone.”

The confidence. The showmanship. The genuine surprise.

I watch my son look at youtube about the new rumoured Apple devices and feel something I can’t quite name. Pride, maybe. Or recognition. He’s discovering his own version of that electric feeling I used to chase.

But I’m not bitter about losing it.

You don’t stay a youth forever. You develop immunity to hype cycles. You’ve seen enough “revolutionary” products to know the difference between marketing and genuine breakthrough.

The edge I’m losing isn’t about being behind the curve.

It’s about having lived through enough cycles to see the patterns. To appreciate the craft without falling for the spell.

Maybe that’s not a loss at all.

The PM sits in the customer meeting. Listens to the workflow they describe. Hears the specific pain points. Drafts the prompt for an MVP that solves it. Shows working solution before the meeting ends.

No more “let me check with engineering.” No more follow-up meetings. Just problem to solution in real-time.

Sales focuses on relationships and process. PMs focus on technical possibility. Engineers focus on platform, scale and well-defined documentation.

In school we learned there was a right answer and a wrong answer. Less room for creative responses.

Now in our jobs it’s perfect versus bad. We focus so much on perfect that we can’t get past the empty page.

Learn to be happy with bad. No one skipped straight from bad to good.​​​​​​​​​​​​​​​​

Then I see the meme: “My brain has too many tabs open.” And I realize we’re all doing the same thing with our thoughts.

We keep mental tabs open for everything: the idea we had in the shower, the thing we need to discuss with our manager, the grocery list, the project we should start next week.

This is exactly what David Allen was talking about in Getting Things Done. He called them “open loops” and your brain refuses to let go of them because it doesn’t trust that you’ll remember them otherwise.

Your colleague with forty browser tabs has the same problem you do with your racing thoughts. No trusted system for what matters and what doesn’t.

The solution isn’t better memory or more mental discipline. It’s building a system you trust enough that your brain will finally stop hoarding those tabs.

Close the loops.

Today, when you write code, other developers review it before it gets merged. They need to understand your logic, your variable names, your approach. Because they might need to work with this code later.

But when AI generates the code, what exactly are we reviewing?

Maybe ownership becomes about tests and requirements instead of implementations.

You own the test suite that defines what the system should do. You own the performance benchmarks. You own the specification that describes the problem we’re solving.

Someone else might run the same tests and get completely different generated code. That’s fine as long as it passes the same validation.

This changes everything. Instead of “Who wrote this function?” the question becomes “Who defined these requirements?” Instead of debugging someone’s implementation, you’re questioning whether the test suite covers the right scenarios.

The skill becomes problem definition rather than problem solving through code.

We might need the same thing for AI-generated code.

Right now, most of our tests are “public”. The AI can see them, learn from them, and optimize for them. This works for basic functionality. But it creates a risk.

The AI might generate code that passes all your tests but doesn’t actually solve the problem. Like writing an if statement for every number between 1 and 2000 instead of using a proper algorithm.

The code technically works. It passes your tests. But it’s brittle and will break the moment you need to handle 2001.

So we need two types of tests. Public tests that guide the AI toward the right solution. And private tests that the AI never sees.

The private tests are your real validation. They test the business logic that actually matters. They try malformed inputs, edge cases, performance under load. They check whether the solution actually works, not just whether it responds correctly to known inputs.

This creates a new discipline. Someone needs to write these holdout tests. Someone who understands the domain deeply enough to know how the system might fail in the real world.

The AI helps with implementation. Humans focus on validation.

These conversations made sense when humans were writing all the code. Understanding someone else’s implementation is crucial because you might need to maintain it, debug it, or extend it later.

But what happens when AI generates the code?

I can ask an AI agent to build an API that talks to a database, processes the data, and serves it to the frontend. The code works. The tests pass. But the implementation might be completely different each time I generate it.

Will this matter?

The conversation shifts. We’re not debating whether to use a for loop or a map. We’re debating whether we tested the edge case where users upload malformed data. Whether our performance benchmarks actually reflect real usage patterns.

Maybe developers will keep writing code that matters. But the code that controls what users see won’t be the implementation. It will be the tests.

Then I wrote my first line of code and hit run. Error message. Cryptic, broken English that meant nothing to me. So I uninstalled everything and downloaded it again, burning more precious bandwidth and time. Same error. Same confusion.

I gave up on Java that day.

Years later I tried PHP with the LAMP stack. Wrote some code, refreshed my browser, and it worked immediately.

When you’re new to something, you need feedback that tells you whether you’re moving in the right direction or completely lost. You need signals you can actually decode. Whether that feedback comes from the system responding to your code, a person explaining what went wrong, or even just seeing your idea work for the first time.

Without those clear signals early on, momentum dies before it ever builds.

We do the setup first. The research. The planning. The easy wins.

We tell ourselves we’re being strategic. Building momentum. Getting organized.

Really we’re just scared.

The hard thing is hard because we might fail at it. Because we don’t know how to do it yet. Because it requires us to learn something new or uncomfortable.

So we leave it for later. When we’re “ready.”

But later never comes. Or when it does, we’re already committed. The project has momentum. People are expecting results. Changing course feels impossible.

We’re pot committed to a solution that doesn’t solve the real problem.

Start with the thing we least want to do.

The uncomfortable conversation. The technical challenge you’ve never attempted. The skill you need to learn.

Do that first.

Sometimes people don’t want feedback.

Sometimes people don’t want to learn.

Sometimes people don’t want to get monetized.

And it’s okay. You might not be the audience.

The urge to help is natural. It’s also often misplaced.

This isn’t about them being closed-minded. It’s about you not being their audience.

The most generous thing you can do sometimes is witness someone’s experience without trying to change it.

You don’t have to be relevant to everyone.

Quick wins feel good in the moment but they rarely compound. Building something that lasts means accepting slower progress today for exponential returns tomorrow. The companies and people who outlast their competition aren’t chasing the next quarter’s numbers.

That’s why the same challenge gets completely different solutions depending on who’s tackling it.

One of his best insights is that you should use your voice like a piano.

That most people only use one key when they speak. Same tone. Same pitch. Same volume. It sounds monotone because it is monotone.

A piano has 88 keys for a reason. Learn to use them all.

Like a pianist knows exactly which key creates the feeling they want.

Your voice can do the same.

We buy our way into communities. The transaction becomes the handshake. The receipt becomes the membership card.

Sometimes the willingness to belong costs more than we planned to spend. But maybe that’s the price of finding your people.

Many developers craft detailed prompts, get generated code back, then delete the prompt and keep only the implementation.

These adapted markdown files contain the real intent. The code contains one possible expression of that intent.

The code will change. The intent remains.

So version control your thinking, not just your implementations.

The decision itself can get you moving. Most choices allow for course correction along the way.

But it’s harder to pivot while you’re stuck.

I’ve never closed Instagram feeling like I accomplished anything.

Creation leaves you with skills and scars.

Consumption just leaves you wondering where the time went.

The shared screen becomes permission for individual escape.

Nobody calls it out because everyone’s doing it. We all maintain this fiction that we spent time together while actually being alone in parallel.

Take the keyboard. This oddly arranged collection of keys exists because of a mechanical limitation from over a century ago. Typewriter keys would jam if you typed too quickly on adjacent letters, so the QWERTY layout deliberately slowed typists down.

Why haven’t we escaped this antiquated design in the nearly 40 years since typewriters became obsolete?

Often it’s because these behaviors become so deeply embedded in our culture that we stop questioning whether better alternatives exist. We train the next generation using the same methods without pausing to ask: is this actually the best way?

Show me your bad work.

The best developers I’ve worked with have been those who understood messy, complex business problems and figured out how to break them down into logical, implementable pieces. The code was just the way we communicated this process to the computer.

We’ve seen this pattern before. As people mastered each layer of abstraction, it enabled others to work at higher levels. AI code generation is just the next step in that evolution.

Yet AI makes domain expertise more valuable, not less. The developers getting the best results aren’t beginners trying to skip the learning curve. They’re experienced engineers who can quickly spot when AI generates something that looks right but will cause performance issues at scale.

Perhaps those who struggle with AI identify as “code writers” rather than “problem solvers”? As long as we position ourselves as just the people who translate requirements into code, we’ll get typecast out of the conversations about what should be built and why.

I could have walked into the team meeting asking who screwed up. I’d seen other managers do exactly that. They immediately shift focus to finding the guilty party. But I’d developed a different habit over the years, partly from reading the book “Crucial Conversations” and partly from watching blame shifting destroy teams.

Facts first: “We released version X. It has this specific bug. Here’s what we know about impact.” No interpretation, no context, no excuses. Just what actually happened.

Then feelings: “This makes us look incompetent. Leadership is annoyed. I feel like I’ve lost credibility.” The stuff everyone was feeling but afraid to say out loud.

Finally, the future: “What needs to change so this doesn’t happen again?”

What surprised me was how quickly the conversation shifted from blame to problem solving. Not because I had some master plan, but because facts-feelings-future kept us focused on what we could actually control.

The same pattern works when stakes are higher too. When someone crosses a line, you still start the same way: “This is what you said. This is how it made people feel. This needs to stop.” But whether it ends with boundary setting or process changes depends on what actually happened.

I realized I experience the complete opposite when building products. Speed makes me lose sight of the minutiae that actually matter. Those edge cases that seem trivial in the moment. The quiet concerns someone has after the meeting ends and the decision is already made.

When we’re moving fast, we barrel through what feels like flat ground. We miss the small friction points that will trip us up later. The user who doesn’t fit our happy path. The integration that works perfectly until it doesn’t. The team member who nods in the room but has doubts they never voice.

Speed doesn’t just change how fast we ship. It changes what we perceive as obstacles. Running teaches you that every slight incline matters. Building products fast teaches you to ignore the inclines entirely.

They read it to feel like they belong somewhere.

When you know your favourite restaurant is expanding, that the division 4 football team won last Friday, that there’s construction on the bridge that cuts your travel by 30 minutes. You’re not just informed.

When you run into your neighbor at the grocery store and mention the restaurant expansion, you’re not making small talk.

You’re connecting over what matters here.

Local news isn’t about information.

It’s about community.

You’ve probably seen the meme: “How to draw an owl.” Step 1: Draw some basic shapes. Step 2: Draw the rest of the owl.

We want the shortcut to the final result. Skip the messy middle steps and jump straight to a polished business plan, product spec or marketing strategy.

The problem is that if you don’t know what a good owl looks like, you can’t tell whether AI has drawn one successfully.

If you’ve never written a business plan yourself, you won’t recognize when a generated one lacks crucial financial assumptions, market analysis or risk assessments.

AI makes domain expertise more valuable, not less. The people getting the best results from AI aren’t beginners trying to skip the learning curve. They’re experts who understand the intent behind every section.

We can’t just learn to prompt better. We need to understand what good looks like in the first place.

This spring, we had a patch of bare dirt where we used to keep rabbits. Instead of planting grass seeds for a quick fix, we chose wildflower seeds.

I watch bees and butterflies move deliberately from bloom to bloom.

The bees don’t hurry. The butterflies don’t multitask.

This attention and presence might be all we can compete with.

When AI scales, it happens instantly. But while robots perfect the craft, humans can give focused attention to other humans.

Make your change part of a system to make it stick. A great system is attaching something to an already formed habit.

I listen to podcasts in an app where I can save a snippet of the conversation with ease. But that snippet alone might not trigger the same idea when I read it back. So I’ve attached the habit of adding a small note that starts with “This is interesting to me because…” That way I can get back to the state I was in when listening.

Another example: whenever I want to exercise in the morning, I need to put my workout clothes out the evening before. It’s a small mental shift that makes it easier. I’m not relying on morning motivation to overcome the small barrier of finding workout clothes. I’m eliminating that decision point entirely.

When looking to create a new habit, find the micro habit to attach it to. Instead of fighting your human nature, you’re designing around it.

When testing products, don’t just test the feature. Test the timing. What shifted that makes people more open to this idea today?

Stop saying ”we tried that already.”

As a new engineer you want to commit something. As a project manager you want to ship a feature. As a manager you want to make decisions. The instinct is to move fast and show progress.

But the way to actually learn and succeed is different. You need to understand the problem well enough that you can explain it to others. Then make a plan on how to solve it. Then get feedback on that idea.

This feels counterintuitive when you’re new. It feels like you’re not doing anything. But it’s what actually works.

If you manage or coach people, this is something you have to make explicit. You can’t assume they know this.

Tell them: you’re new here. Your focus right now is to understand this role and these challenges. I want you to be able to explain them back to me.

Then depending on their level, you’ll need different amounts of handholding. Junior people need you to walk them through what understanding actually looks like. Senior people need permission to slow down and think. Experienced people in new domains need help knowing what questions to ask.

The pressure to ship something fast is real. But the people who succeed long-term are the ones who understand deeply first.

But if you want a following or people to get exited, you need something that makes some people not exited.

People started making faster decisions. They could push back on overly complex solutions without needing technical expertise. The guidelines created productive conflict about real tradeoffs.

Compare this to projects where every decision needs approval. People stop thinking. Change becomes something that happens to them.

When meetings become decision central, everyone feels they need to be everywhere.

You can’t skip the meeting where your project might get discussed.

When everyone thinks that way, every meeting becomes overcrowded with people who don’t need to be there.

Often we come with simple advice “Don’t attend meetings you’re not needed in” which sounds obvious.

Yet people keep showing up.

They sit in meetings where they have nothing to contribute. Where they’re not making decisions. Where they’re just… there.

My technical opinions suddenly carried weight I didn’t intend them to have.

As a senior engineer, I had strong opinions about solutions and advocated for them. That was my job.

But as a manager, people sometimes stopped pushing back. They saw me as someone whose technical judgment could affect their careers.

This is mimetic desire in action. People copy what they think successful people want.

I lost access to the discussions that lead to better solutions. Junior developers stayed quiet. The collaborative tension that makes teams stronger disappeared.

I learned that being “right” about the technical solution mattered less than having the team bought into whatever we chose.

Your job isn’t to have the best technical opinions anymore. It’s to make sure the best technical opinions get heard.​​​​​​​​​​​​​​​​

They have strong opinions. Clear preferences. Everything is black and white, good patterns and bad patterns, right ways and wrong ways.

But time smooths those edges. Experience teaches you that most technical decisions are about tradeoffs, not absolutes. You become more open to different approaches.

This creates an interesting leadership challenge.

The people with the sharpest questions often lack the confidence to ask them. The people with the confidence have learned to stop asking the uncomfortable questions.

You need both in your decision-making process.

AI builds on behaviors we already have. People type in text fields hundreds of times daily. OpenAI’s 800+ million users came so quickly because the barrier was minimal. Go to a website, type text, get smarter answers.

Sure, there’s hype around AI. But adoption is driven by technology solving real problems within existing workflows. That’s a completely different starting point than VR’s demand for behavior change.

Maybe the question isn’t whether AI goes the same way as VR, but which AI applications actually stick and which are just hype.

But once you understand it, everything changes. The better you are at predicting where you want your opponent in the future, the better you are at moving towards it. But you can’t just jump straight to checkmate. You need to plan the moves in between.

The same applies to developing using AI.

You need to think iteratively. Where do you want to move your pieces? In which direction?

The difference with chess is that your opponent really wants you to win. It can eagerly move its pawns to where it thinks would benefit you.

But it might not.

Just like chess, the more experience you have and the better your skills, the better player you are. The same applies to developing using AI. The more skills you have in development and thinking in systems, the better you’ll be at guiding it.

We invented chess computers that can think ahead. Building AI that can do iterative thinking is just the next step. So expect improvements but maybe not exact results.

He was talking about scrum ceremonies. Teams going through daily standups, sprint reviews, and retrospectives because the framework said so. Not because it moved anything forward. A fake display of productivity with no progress.

Throughout my career I’ve been watching organizations that struggle to ship.

Management teams spend 8 hours a day in meetings. The calendar looks impressive, packed with important-sounding work.

But nothing gets built.

Meeting theater feels productive. That’s the trap. But those decisions need execution, and execution needs uninterrupted time.

The busy schedule becomes proof of importance. The full calendar signals commitment.

Someone has to write the code, ship the product. That someone isn’t in meetings all day.

The real work happens when people can focus. When they can solve problems instead of talking about solving problems.

But talking about work feels like work.

So the theater continues.

In meetings, they use clearer, more declarative language because they’ve learned the AI captures that better. In writing, they structure thoughts differently for AI consumption.

We’re unconsciously adapting our natural communication patterns to be more “AI-friendly.”

The intelligence level of the AI almost doesn’t matter. Once these tools enter our workflows, they inevitably alter the fundamental patterns of how we interact with information and each other.

We’re not just using AI. We’re being shaped by it.

Someone says “I think this is important” and the AI treats it as neutral text. But that statement from the CEO carries different weight than the same words from an intern.

The AI misses the context. It flattens organizational dynamics in the summary.

If that summary becomes the canonical record, suddenly the quiet person who made one good point gets equal billing with whoever dominated the conversation.

Nobody designed for that. But it’s happening.

These tools are conducting unplanned experiments in communication patterns and social dynamics, with outcomes nobody anticipated.

That’s terrible AI from a search company. But it already changed how you work.

You probably search differently now. Use different keywords. Rely more on recent files. You adapted to its limitations.

The AI didn’t get smarter. Your system changed.

This is what we miss when we obsess over how intelligent AI is. The transformative power isn’t in the intelligence level. It’s in how AI changes the systems we use every day.

Even dumb AI reshapes behavior.

I now vet ideas there first for any upfront stupidity.

That’s a new step in my thinking process. I’ve essentially added a rubber duck that talks back. It probably changes not just what ideas I present to people, but how I formulate ideas in the first place.

Some of the best insights come from someone saying something half-baked and another person going “wait, that’s actually interesting if we think about it this way…”

But if you’ve already filtered out the half-baked idea through AI, those generative moments never happen.

You get more polished inputs. But you lose those weird random leaps that lead somewhere unexpected.

The trick is knowing when to use the filter and when to let the half-baked ideas fly.

I’ve seen this dependency problem destroy value before. At memmo.me, our entire business depended on celebrities creating content. One celebrity deciding to stop could hurt our platform. At Spotify, I watched Taylor Swift pull her entire catalog to go exclusive elsewhere. Not business-ending, but a clear reminder of who held the real power at the time.

Both situations taught me the same lesson: when your business model depends on someone else’s decisions, you’re never fully in control.

Most third-party AI platforms face this exact squeeze today. Every improvement costs more tokens. Every feature burns more cash. When you’re optimizing for token efficiency instead of user experience, you’ve already lost the game.

Lovable just escaped that trap.

They raised $200M and launched infrastructure features like hosting, security, and team collaboration. Where their previous improvements often depended on more intricate ways of prompting and cost more and more tokens, now they’re creating revenue streams that don’t burn API tokens.

This isn’t just about adding features. It’s about changing what business they’re in.

They’re not competing with OpenAI, Anthropic, and Google on pure generation anymore. They’re becoming the place where AI-generated apps live. That’s the infrastructure move that changes everything.

Now when you build something with Lovable that uses their new offerings, moving it elsewhere means migrating your database, your custom domain, your team workspace. Possible, but painful.

The pattern repeats across industries. Record stores couldn’t compete when big box retailers sold CDs as loss leaders. Travel agencies disappeared when airlines cut commissions. Cable companies survived by becoming ISPs instead of fighting Netflix for content.

Stop being the middleman. Start owning the infrastructure.

Every successful platform eventually faces this choice. You either own something irreplaceable or you become a feature that someone else can build cheaper.

When costs rise and margins shrink, you either control something customers can’t easily leave, or you watch your business model collapse one price increase at a time.

Lovable chose ownership.

Other AI platforms will need to make similar moves soon. Own the deployment pipeline. Control the data layer. Become infrastructure that’s harder to replace than the generation itself.

The intermediary becomes the infrastructure, or the intermediary dies.

That’s the choice.

I can hear the audience’s brains collectively shut off.

They don’t want to read long unedited AI sloppified versions of what has been said.

It’s not about AI being bad. It’s about someone abdicating their thinking.

When people share what AI has written without putting their touch to it, they’re essentially saying “I didn’t think this was worth my time to understand, but maybe it’s worth yours.”

If you didn’t digest it, why should I?

The authenticity of the experience matters more than the authenticity of the prose.

You can’t fake living through something. You can get help explaining what you lived through.

There’s a difference between using AI to find better words for your thoughts and using AI to have thoughts for you.

The story has to be yours. The telling can be collaborative.

It will always be my responsibility that I can stand behind the text, code, or image.

AI can help me articulate ideas. It cannot give me ideas I don’t actually have.

The tool doesn’t matter. The accountability does.

If you can’t defend it, don’t publish it.

But here’s what just happened: I had a conversation with Claude about my writing process. We found three post ideas. Claude helped me draft them. I edited them down.

Now I’m writing about that process while doing that process.

The recursion doesn’t make it less real. It makes it more honest.

This is how collaboration works now.

The opposite is happening to me.

AI wants to write everything. Long paragraphs. Perfect transitions. Neat conclusions that wrap everything up with a bow.

I spend most of my time cutting. Removing words I don’t like. Cleaning up endings that over-explain the point.

The creative work has shifted. It’s not about generating anymore, it’s about recognizing what matters and ruthlessly eliminating what doesn’t.

I’m forced to practice saying “no” to perfectly decent sentences because they’re not essential.

I’m learning how to distill without losing the core.

How to be brief without being empty.

It wasn’t.

Senior developers know better. Small commits. Testable changes. Break it down further.

As a CTO, I coach the same thing. What’s the smallest thing we can release? Can we make a PoC first? How do we break this down?

Now I’m watching people learn this same lesson with AI.

AI wants to write your entire blog post, refactor your whole function, solve your complete problem. Just like junior me, it feels productive.

It isn’t.

The people who get the most out of AI are treating it like code. Small changes they can verify. Iterative improvements they can stand behind.

They’re learning in months what took me years: the more powerful your tool, the more restraint you need to use it well.

Turns out incremental thinking isn’t just good engineering. It’s good everything.

Want to start writing? We think about starting a blog, choosing a platform, designing a theme. Too much friction.

Want to learn to code? We plan out an entire app, research frameworks, set up development environments. Too many steps.

Want to draw? We think about technique, style, the right tools. Too much pressure.

Meanwhile, consumption is always one click away.

The path of least resistance wins every time.

So make creation the easier path: open a text file and write one paragraph. Write a function that adds two numbers. Draw something, anything, on paper.

Lower the barrier until creation becomes the default choice.

But that’s not reality.

Work takes 8 hours. Sleep takes 8 more. Cooking, family time, basic life maintenance fills most of the rest.

What you’re really optimizing for is maybe 2 hours of discretionary time.

Maybe an hour in the morning before things get hectic. Maybe an hour in the evening after everything settles down.

The consumption vs creation debate isn’t about revolutionizing your whole life. It’s about what you do with those precious few windows.

That’s when you’re actually choosing: do I scroll or do I write? Do I watch or do I build?

Forget the grand life overhaul. Just win those 2 hours.

It’s like the weight of the completed, iterated, polished version becomes the goal post for the next creative thing. The next thing needs to start on the same level as the previous was when it was completed.

This happens almost every time I try to create again. I overconsume on data, reports, articles and research to make a “better” next project.

But really, I’m just avoiding starting at the messy beginning level again.

The solution isn’t better research. It’s permission to suck again.

Your first draft doesn’t need to compete with your last published piece. It just needs to exist.

“But what if this needs to scale to millions of users?”

“How will this architecture handle enterprise requirements?”

“What happens when the team grows to 50 developers?”

All reasonable questions. For the wrong projects.

I’ve watched teams spend years discussing between Symfony vs Laravel and then the problem disappeared in two weeks when company moved to java as the golden path. They were so focused on building the “right” foundation that they missed the shifting ground beneath them.

When you’re building a prototype to test an idea, enterprise-grade infrastructure is like bringing a crane to hang a picture frame.

The bias toward long-term thinking creates an invisible tax on every decision. Database schemas become more complex than needed. Code gets abstracted for flexibility that never comes. Simple features become architectural discussions.

Meanwhile, competitors ship working versions and learn what actually matters.

The irony? By the time you’ve built something robust enough to “scale properly,” the market has often moved on. Your bulletproof solution solves yesterday’s problem with tomorrow’s complexity.

I’m not advocating for sloppy work. I’m questioning our default assumption that every project needs to survive nuclear war.

Sometimes the best long-term strategy is admitting you don’t know what the long term looks like.

Build for what you know today. Let tomorrow teach you what it actually needs.

“It’s changing everything!” say the enthusiasts.

“It’s destroying software quality!” counter the traditionalists.

Both camps are missing something fundamental: vibe coding has existed for five months.

Five. Months.

That’s not enough time to change a coffee order habit, let alone organizational foundations. Yet here we are, debating whether it’s revolutionizing or ruining enterprise development.

I’ve watched companies spend longer than five months just deciding which project management tool to use. The idea that a coding approach could fundamentally reshape organizational values in the same timeframe is… well… optimistic.

Real organizational change operates on geological timescales. Culture shifts happen when people retire, not when new tools emerge. The companies celebrating vibe coding victories today are probably the same ones who adopted React faster than everyone else because they were already comfortable with experimentation.

The companies dismissing it as dangerous chaos? They were already risk-averse.

Vibe coding didn’t change these organizations. It reveals them.

Maybe the question isn’t whether vibe coding will transform how we work. Maybe it’s whether we’re ready to see what our organizations actually value when a faster option appears.

Five months is just enough time to show what was already there.

Weight. Texture. The satisfying click of the scroll wheel.

You can’t experience lag in a prototype. You can’t feel the awkward pause between tapping a button and seeing a response. Screenshots are beautiful liars.

We’ve gotten so good at making static designs look finished that we’ve forgotten they’re just educated guesses.

A perfectly polished Figma prototype sends the wrong signal: “This is ready. Don’t change it.” The more professional it looks, the more people hesitate to suggest improvements. Nobody wants to be the person asking for “small tweaks” to something that looks complete.

But show someone a working prototype where they can type in a text field and watch their words appear instantly? Different story.

“Can this button be bigger?”

“What if the text was clearer?”

“This feels slow - can we make it faster?”

Suddenly everyone becomes a user experience expert. Not because they know more, but because they’re experiencing rather than imagining.

The best feedback comes from touching, not looking.

Paper sketches invite edits because they look unfinished. Working prototypes invite interaction because they feel real. Polished mockups invite approval because they seem done.

Choose your invitation wisely.

”Ohh you stopped reading Lean Startup after 4 chapters. Then you probably should checkout The Every Store instead cause it has less jargon and is more narrative driven”.

Smart recommendations it could make:

“You stopped at the theory-heavy part, try this more practical version”

“Most people who stop here prefer memoirs over how-to books”

“You made it 60% through, here’s something that builds on those concepts”

Messy doesn’t even begin to describe it. At least once a year, someone would try to kill it. And fail.

On paper? Simple. It picked which market and language a user lived in. Geographic data plus browser settings, with some fallbacks thrown in. Easy, right?

Wrong.

The code was so woven into our system that touching it meant rewriting everything. We kept thinking “IT JUST PICKS MARKET AND LANGUAGE!!!1?” But that abstraction blinded us to the real complexity.

I see the same pattern now with AI-assisted coding.

You dip your toes in. You think everything’s simple. “Just build me an app that does X.” But you’re the complexity. You understand the full flow. You abstract away all the messy details that make starting from scratch so hard.

This is where Gall’s law hits you: “Complex systems that work have invariably evolved from simpler systems that worked.”

Start smaller. Start easier.

Don’t go all-in on “Create an app where everyone can chat with everyone in the world and it should be encrypted.”

Start with two people. Make that work first.

It’s about what you want to do and how you want to do it.

But we always look at mentors trying to copy their results. We see their hindsight view of how they work and assume that’s the blueprint.

For years companies tried to copy the Spotify Model. Squads, tribes, chapters, guilds. The whole thing.

Just to realize that Spotify wasn’t even using it anymore.

It was a utopian vision of how work could happen at a specific moment in Spotify’s life. Not a universal framework.

By the time a system becomes famous enough to copy, it’s already been abandoned by the people who created it.

So when we look at how others do things, we need to understand their input. Their constraints. Their actual daily reality.

Not just the polished model they present at conferences.

Copy the thinking, not the system.

Since then I’ve bought used and reissues of old classics on vinyl. There is something special to the feeling of dropping the needle on the LP’s first track and listening through to the end, not skipping a song because I don’t like it, but keeping at it because it’s what the artist aimed at. Delivering a story.

I’d never heard David Bowie’s Heroes album before this, just the hits. But those wonky odd tracks in between? They’re what make the whole story work.

Wouldn’t it be interesting if artists themselves could say: you cannot listen to any specific tune until you’ve listened to this complete album.

Think of the kind of stories that would then be able to be told again.

Like going to the Louvre and only seeing the Mona Lisa before leaving. You miss all the context that makes it truly special.

I keep seeing memes about “AI Agents everywhere!” and people dismissing them as the next metaverse fad or NFT bubble. But I think they’re missing something important.

Look at the behavioral shift happening. Most people I know now go to ChatGPT instead of Google when they need answers, help figuring out strategic decisions or polish their slides.

We’re not just changing how we find information. We’re changing how we interact with services entirely. Instead of building our own AI agents, the smart move might be building for the AI agents people already use.

Then there’s the money. Big tech is pouring billions into AI infrastructure and development. This collective industry pivot is massive. The only comparable shift I can think of is when everything moved to “the cloud”.

The memes about AI agents being everywhere aren’t wrong. They’re just missing the point about what that actually means for how we’ll do business.

They became leaders because that’s where the influence was. The budget decisions. The architectural choices. The strategic direction.

But somewhere along the way, they stopped building things.

Meetings replaced coding sessions. Presentation replaced prototypes. They found themselves describing solutions instead of creating them.

AI development tools might change that equation entirely.

What if you could maintain strategic oversight while personally building the critical pieces? What if leading didn’t mean delegating everything?

The traditional model assumed you couldn’t do both. Leadership required full attention. Technical work required deep focus. Pick one.

But AI tools compress the time between idea and implementation. That strategy you’ve been explaining in slide decks? You could prototype it this afternoon.

The architectural vision you’ve been communicating through diagrams? You could build the foundational pieces yourself.

This isn’t about micromanaging or stepping on your team’s toes. It’s about leaders who understand systems deeply enough to know which problems to solve personally.

The CEO who builds the core algorithm. The CTO who prototypes the new platform architecture. The VP who writes the critical integration herself.

Not because the team can’t do it. Because they can do it better, faster, and with more context about where it fits in the bigger picture.

These leaders aren’t telling their teams what to build. They’re building alongside them. Sharing knowledge in real-time. Showing techniques and explaining trade-offs as they happen. It’s leadership through example rather than directive.

We might see a new type of leader emerging. The hands-on executive who combines strategic thinking with personal execution. Someone who doesn’t just direct the work but actively participates in creating it.

The best leaders were usually great individual contributors first.

Maybe AI tools will let them be both again.

Now the last boomers are stepping down. Someone has to fill those positions.

That someone is probably in their late thirties. Two decades of experience. You’ve seen frameworks come and go. You remember when JavaScript was a toy language.

But you might not need to follow the traditional path.

The old model was predictable. Get experience. Move to management. Trade your keyboard for spreadsheets and slides.

AI development tools will change that equation.

Why manage a team of five junior developers when you can have the productivity of fifteen?

You know what good code looks like. You understand system architecture. You’ve debugged enough production fires to spot problems before they happen. Now you have tools that amplify that experience instead of bureaucratizing it.

Junior developers will learn AI-assisted coding as their baseline. But they lack the pattern recognition that comes from years of mistakes. They don’t know which shortcuts lead to technical debt disasters.

You do.

Combined with AI tools, that experience becomes a superpower. This creates a new archetype: the experienced individual contributor who skips management entirely and becomes a one-person product factory.

Here’s the thing though: they might not be in a hurry to leave either. Why retire when you can outproduce entire teams? Why step aside when you’re finally having fun building again?

Sound familiar?

Meet the new boomers.

“It doesn’t scale,” they say. “You can’t build enterprise systems this way.” “What happens when your team grows?”

They’re probably right.

And maybe that’s completely missing the point.

Scale is the wrong metric for personal productivity. It’s like judging a custom-tailored suit by whether it fits everyone in the company.

With AI development tools like Claude Code, personal optimization becomes effortless.

I no longer spend hours reading documentation just to remember how to set up a basic Express server. I don’t wade through boilerplate code to get started. I don’t compromise my vision because the existing tools almost-but-not-quite fit my needs.

I describe what I want. I get exactly what I want.

This isn’t about building Facebook. It’s about solving my problems, the way I think about them, with tools that bend to my mental model instead of forcing me to bend to theirs.

Team coordination? Code reviews? Maintainability? These remain important for large systems. But they’re separate problems from personal effectiveness.

The real challenge isn’t accommodating more developers. It’s amplifying the ones you have.

When I can generate a perfect Obsidian plugin in the time it takes to take a shower, the old rules about scalable development practices feel… quaint.

Maybe it’s about teams that scale through individual superpowers. The best engineering organizations won’t be the biggest. They’ll be small teams where everyone operates at peak personal effectiveness while still collaborating seamlessly.

That’s a different kind of scale entirely.

My initial plan? One month. But momentum carried me forward, even through a four-day hospital stay.

The blog lives on Cloudflare, but today I hit a snag. My posts weren’t stored with my other notes. I couldn’t cross-reference them in my notes tool.

My old approach would have been predictable: hunt for a tool that takes my RSS feed, creates a local version, and downloads referenced images. Maybe spend hours researching options. Maybe settle for something that almost works.

AI development tools changed this habit for me.

I opened my terminal. Created a folder. Fired up Claude Code with the somewhat scary claude --dangerously-skip-permissions and wrote:

“I have a blog with an RSS feed. I want to write a plugin for Obsidian where it downloads all posts and images, converts them to the correct format, and adds them to a specific folder.”

Then I went to brew coffee.

When I came back? A working plugin. Exactly what I wanted.

This is the Tony Stark and Jarvis feeling. I bring the ideas. The LLM handles execution. I test and confirm.

No wrestling with documentation. No Stack Overflow rabbit holes. No compromising on requirements because the existing tools don’t quite fit.

Just problem to solution in the time it takes coffee to brew.

Does it scale? No, not right now.

Does it need to scale? I don’t know.

Maybe scale isn’t about building massive systems anymore. Maybe it’s about having near-unlimited capability to solve your specific problems perfectly.

Like having a personal manufacturing line for software tools.

Each solution fits exactly because it’s built exactly for you.

p.s. you can download the plugin for Obsidian over at github.

Real boredom. The kind where you stare at nothing for half an hour and let your mind wander.

When you fill every moment with distractions, you get lazy creativity. You pick the first thing that comes to mind. That’s the path of least resistance.

Real creativity needs mental free time. Space to break habits and explore different perspectives.

But we’ve eliminated boredom entirely.

You have access to almost all music ever recorded. Every movie you could want. Infinite YouTube videos. Chat tools that answer any question instantly.

And we use it all.

We’re always distracted from boredom.

Too distracted to get creative.

Make sure to leave some room for boredom. The kind where you sit and suddenly find yourself daydreaming.

Every app fights for our attention. We cram every hour with meetings.

We want to be productive, but we have designed much of our day to day with pings, dings and rings.

These are the systems we live in now, and identifying them is only the first step.

You can make good decisions with bad outcome or bad decisions with great success.

Consistency is what makes practice less like practice.

Musicians taking bits and pieces from other records to create something new.

It was legally messy but creatively fascinating.

Is this what we’re experiencing now?

AI will follow sampling’s playbook: outrage, adoption, amnesia.

Today’s “AI kills creativity” will be tomorrow’s “I’ve always used these tools.”

Top developers will focus on having great prompt files that explain how they work. The tools they like, the APIs they use. How they want code to be tested and written.

It will be the dot-files of the future. Personal config files that define your entire coding style and follow you from project to project.

Sure, you can copy someone else’s prompt files. But to really benefit, you need to understand and own them, just like traditional dotfiles.

Anyone can ask ChatGPT to write a React component. But not everyone knows how to ask for error handling, team patterns, and optimization for their users.

Do I need a perfect synthesizer? Do I need to sit in a special chair? Do all the kids need to be in bed and asleep? Do I need a two hour window?

Stop waiting to be comfortable.

It’s rarely about actual technical requirements. There’s this unspoken feeling that using existing tools might make them look less skilled as developers.

The result is predictably frustrating. While others focus on shipping products, these teams struggle to even update their website with new features because their custom CMS has become a maintenance burden that multiple developers have touched over time.

It’s one of those situations where professional pride works against business outcomes.

When everyone else focuses on making it easier for ChatGPT to index all their content and hope that it picks theirs.

The only way for people to really get to know your brand will be for them to know how they can find your brand.

I predict a surge in ads talking about domain names in the near future.

The logic is simple. When developers aren’t busy with client work, they focus on building something that could eventually become the main business. Sounds like smart resource utilization.

But here’s where it gets interesting.

The challenge always became prioritization. How do you decide what these “spare time” developers should work on? You can’t give them the most critical features because what if a client project comes up and pulls them away?

So you end up giving them the less important stuff. The nice to have features. The experimental work. Tasks without real deadlines or with artificial ones just to create some focus.

That sounds reasonable. Low risk, low commitment work for uncertain availability.

But then you hit the handoff problem.

Eventually, this side work needs to integrate with the main product. The core team (the one working on actual priorities) has to stop what they’re doing to review, understand and approve the work from the “spare time” team.

That’s when things get messy.

You end up with a priority inversion. Your high-priority work gets deprioritized so you can process the low-priority work you assigned to fill downtime.

The thing you said was most important gets pushed aside to handle the thing you said was least important.

I’ve seen this pattern multiple times now. It always looks smart on paper. Use every available hour. Keep people productive. Build toward the future.

But coordination isn’t free. Context switching isn’t free. Code review isn’t free.

The overhead of managing “spare time” work often costs more than the value it creates. You’re not just losing the output, you’re actively making your core work less efficient.

It’s one of those management ideas that optimizes for the wrong thing. Instead of optimizing for maximum utilization, you should optimize for maximum progress on what actually matters.

There are plenty of valuable things to do with spare time. Code reviews, documentation, experimenting with existing features, learning new skills, hanging out with the support team. The list goes on.

Just don’t pretend you can build your core product features in the margins.

But here’s what I find interesting about that number.

Most major technologies follow this adoption curve: 2-3 years of experimentation and learning followed by gradual scaling and measurable returns in years 3-7.

GenAI is actually moving faster than typical but the timeline for measurable enterprise-wide returns appears totally consistent with other major technology shifts.

The 80% figure isn’t a GenAI problem. It’s the normal pattern for transformative technologies.

We’ve seen this before.

ERP systems took 2-5 years to show significant ROI. Cloud computing took years before most companies saw meaningful returns.

GenAI has been widely available for just 2 years.

If you’re struggling to show enterprise-wide returns from AI right now, you’re not behind schedule.

You’re right on time.

Today I fired up Claude Code and added an MCP to my blog.

For the non-technical folks: I basically gave Claude direct access to all my writing. It can now read through everything I’ve written, search for patterns, find connections I missed.

The tool gave me something I didn’t expect, a sort of curiosity about my own work.

I used to Google my own site to find a specific post I remembered. Now I can ask “What was I thinking about in March that I didn’t fully explore?” or “Show me where I keep iterating on the same idea but in different ways.”

It’s like the difference between having a messy room and well… having a messy room with a really good search function. Same stuff, completely different relationship to what’s there.

Now I have a way to be genuinely curious about what I’ve created. To ask it questions. To explore it like someone else’s work.

Researchers had students write essays using ChatGPT while measuring their brain activity. No training, no guidance. Just figure it out.

Students who started with AI first? Their brains basically went to sleep. But students who thought through ideas themselves THEN used ChatGPT? Their neural networks lit up stronger than ever.

This reminded me of that kid from school group projects. Whenever we had a group assignment he just hung around. Not really invested in discussions or well… interested at all. He performed poorly at the tests and presentations.

The study found AI-first students couldn’t even remember sentences they’d just written. But the think-first-then-collaborate kids? Strongest brain activity of all.

Working with AI is like a group assignment and this kid struggled with it. The study somewhat proved that we need different support. Similar to how that kid needed support.

That’s exactly how I approach AI in writing.

I used to struggle getting my thoughts down clearly. My ideas would get muddled somewhere between my brain and the page. AI became my thinking partner. Someone to bounce ideas off of and help me get my thoughts crisp and tight.

But here’s the crucial distinction: I still want my ideas and stories to shine. Not fabricated ones. What’s truly unique is my viewpoint and experience. Not my writing craft.

I found my voice not despite using AI, but partly because of it. The tool helped me see patterns in my thinking. Pushed me to be clearer. Gave me confidence to share ideas I might have kept to myself.

The fear is that AI will make us all sound the same. That only happens if you treat it like a vending machine. Generic prompts get generic content. Use it as a thinking partner and you get something else entirely.

Your voice isn’t just how you write. It’s what you choose to write about. How you think about problems.

We’ve been moving toward ‘Google Zero’ for years, where people get their answers directly from search results without ever clicking through to websites. Featured snippets, knowledge panels, instant answers. AI overviews are just the logical next step in this progression.

Are we seeing a return to the early web’s “answers upfront” approach? I’m thinking Yahoo’s curated portals, but with AI doing the curation automatically.

For the longest time we used “google us” as a verification that we were legit, and taught our users that that was the way to go. The problem was that the model got corrupted on the way. SEO spam and sponsored results meant you weren’t exploring authentic sources anymore.

AI overviews aren’t just about creators losing traffic. They’re a correction to a discovery system that had already broken.

Brand awareness becomes even more important. People need to know how to come to your site directly when they want your specific view of the story, not just the AI’s summary.

We focus on 2% shifts in conversion rates while our products have not found their long term audience.

They cut through it.

They don’t use complex jargon.

They adapt their communication to the listener.

They explain complexity in simple ways.

AI struggles because human decision-making happens in the negative space.

The things we don’t do, the paths we don’t take, the features we don’t build.

Think about a senior developer looking at a junior’s code and saying “this works, but it’s doing too much.”

Or a designer choosing not to add that extra button because it would clutter the experience.

A product manager who says no to a feature request because it will dilute the core value proposition.

Those decisions to constrain, to say no, to leave things out. They’re often what separates good work from great work.

AI can generate endless possibilities, but it can’t feel the weight of choosing restraint.

The more I think about it, em dashes are the Sharknado of writing.

What 30 years ago would have been a crazy feat now feels like obvious special effects.

You know that moment in a movie when the CGI gets so obvious it breaks your immersion? That’s what’s happening with em dashes in 2025. We’ve developed “AI blindness” where our brains filter out patterns that feel artificial.

The real issue isn’t the punctuation itself. It’s the moment readers start questioning authenticity instead of engaging with ideas.

We’re creating an “authenticity uncanny valley.”

Meanwhile professional writers have been loving em dashes since long before ChatGPT existed. But now they’re second-guessing themselves, worried their natural style might trigger someone’s AI detector.

The same technique goes from impressive to eye-roll-inducing purely based on audience expectations, not because the thing itself has changed.

The feedback loop is absurd: the more people avoid certain patterns to seem “authentic,” the more those patterns become markers of inauthenticity.

Welcome to 2025, where even punctuation has an uncanny valley.

In Back to the Future Part II, Marty McFly walks into Cafe 80’s in 2015 and plays an old arcade game. He’s pretty good at it. But when he finishes, a couple of kids watching him are baffled: “You mean you have to use your hands? That’s like a baby’s toy!”

Something big has changed in how we find information. Before, we searched Google, clicked through a bunch of links, and pieced everything together ourselves. Now we just ask a question and get an answer we can improve through conversation.

AI that can search isn’t just another tool. It’s a completely different way of working with information.

The Old Way: Search and Put It Together

This was the Google era. You got good at turning your questions into search terms, quickly scanning results, and opening way too many browser tabs. If you were really organized, you saved links for later.

Then you did the hard work of reading through different websites, figuring out what was useful, and putting it all together in your head to get your answer.

You learned to spot good sources. Not just the facts, but you could tell when a website was sketchy because it had more ads than actual content. You got better at seeing patterns across different articles.

The New Way: Ask and Check

Now that we’re in the conversation era, your main skill is asking good questions. Instead of hunting through search results and trying to avoid all the sponsored links at the top, you’re talking to an AI that can instantly pull together information from the entire internet, your own files, and your company’s data.

Your brain does completely different work now. Instead of collecting puzzle pieces, you’re checking whether the completed puzzle looks right. You need to quickly figure out if an answer is complete, correct, and actually helpful for what you need.

The question isn’t whether you’ll make this switch. It’s how quickly you’ll realize that how you work with information has changed forever.

What has changed with GenAI is the interaction model.

The previous model with search engines and knowledge bases was: search, filter, read, then synthesize. Now it’s: ask, receive a synthesized answer, then refine through conversation.

This is quite a shift in cognitive work.

Now you essentially have a conversation with the sum of human knowledge.

We’re moving from “search and synthesize” to “ask and evaluate.”

The true bottleneck now is the quality of your questions and your ability to recognize what is good.

That feeling I had as a kid that I was close to completing something, that I was getting closer to an end, was so super addictive.

I recall those memories with fond feelings as I now experience vibe coding in a similar matter.

As I sit late in the nights adding one more feature, prompt by prompt, and having one endorphin kick after another, my head starts prompting me “it’s time for bed.”

But I’m addicted…

“Just one more prompt.”

Suddenly we were on endless digital whiteboards trying to replicate physical spaces - the act of seeing multiple post-its on a wall, grabbing them and placing them somewhere else. And when the tools worked smoothly we got a sensation of watching others peoples cursors move and filter, sort and group it felt promising.

But since those years we have eagerly trying to return to our previous ways of working. Back in the rooms, not on screens.

Had we truly adapted one way of working to the digital medium, we might have had an additional tool and expanded our toolset.

The messy part of physical boards is the thing we have a hard time replicating. The badly handwritten notes that someone needed to explain for us to understand. The oddly sorted board that sparked new ideas since it was not just catagoriesed in the optimal AI way.

Maybe it is this imperfect human approach that the digital tools lack for us to make unexpected connections and innovation.

“Old” social media worked like mailing lists. More followers meant more people saw your posts.

“New” social media is all about engagement. An account with 10 followers can go viral with the right piece.

The algorithm favours interaction over audience size.

Good engaging work will find its people. What counts as “good” is another story.

It should be how are you smarter with AI?

One implies that you are dependent, the other focuses on usage.

We can focus on what sets us apart rather than building, maintaining and explaining everything from scratch.

Think of your house. We all have walls, floors, kitchens and bathrooms. Pipes run a certain way and electrical wiring another. These follow standards for good reason.

It’s what goes in front of these foundations that makes a home unique and helps it stand out.

If we needed to explain basic construction principles to every carpenter or electrician who steps through our door, we’d waste valuable time.

Which parts of your work truly need your unique touch, and which could follow patterns that AI already understands?

1. Write about anything that resonates with me that day
2. One sentence is good enough for a day
3. Be ok to suck or to be cringe

I think that last thing stuck with me. Its like when you learn a new trade. Then you just need to do it.

Often. Bad. Committed.

Then we built bots where we needed to learn brevity. We distilled our thoughts into SEO-type queries for Google and simple commands for phone robots.

Now we need to relearn how to ask questions again. We’re in a paradigm shift. With GenAI, we can ask complicated questions and as many as we want. Yet, we still try to make our questions short out of habit.

This reframing won’t be an issue for people growing up with GenAI. Kids will never experience the complicated part of distilling questions into search terms.

Programmers naturally ask follow-up questions that stakeholders often don’t have immediate answers to. We need to anticipate what’s coming next to build systems that can scale.

Business people are focused on solving their current problems, while programmers are considering edge cases, future requirements, and technical challenges that aren’t obvious from the surface.

We could improve at communicating why this matters. The key is helping business see the value in our questions i.e. explaining how today’s overlooked edge case becomes tomorrow’s production outage or performance bottleneck.

A young company gets some funding. Developers arrive eager to build something amazing. Then someone utters those fatal words: “We need to build for scalability.”

This is where bias and intuition clash in dangerous ways.

The intuition of experienced builders says focus on getting the product right first. Make something people want before worrying about serving millions. Get the plane in the air before optimising its fuel efficiency at 30000 feet.

The bias comes from pattern matching successful companies. “Amazon uses micro services so we should too.” “Netflix has a complex deployment pipeline so that must be the right approach.”

I witnessed this firsthand at a startup where engineers pushed to move from App Engine to Cloud Run for “reliability reasons.” We spent precious runway time refactoring infrastructure instead of improving the product people were paying for. Leadership didn’t understand the tradeoffs. The company eventually went bankrupt.

The inexperienced self-proclaimed senior developers kept insisting “This isn’t how you build for scalability.” But scalability wasn’t our problem. Finding product market fit was.

Scale is a question of when not if. The wisdom comes in recognising the right time to focus on it and be clear about this with both leadership and developers.

And never f*** up payments.

Another excellent technique is called question burst. You explain your problem in 2 minutes and then others ask questions for 4 minutes.

Question bursts force you to create a high-level explanation quickly and then benefit from external perspectives through thoughtful questions.

I’m not a training junkie by any measure, but I know that if I want to exercise in the morning I need to put out my clothes the night before.

That small trigger change is all that is needed.

If you don’t know the triggers, you will not change the habits.

Upgrading from mobile phone version 14 to 15 might not make sense if the benefits are minuscule.

Remember that “1.0” is just branding. Look beyond the marketing to determine if something truly represents a significant upgrade for your specific needs.

One: create a copy of existing products then add your standout features.
The other: focus solely on your core vision of what makes you unique.

One takes time. The other needs courage.

Think of the first iPhone. It was revolutionary, yet lacked many features that already existed in the market.

Your product isn’t just features. It’s what those features deliver.

What we are left with are opinions on how to look at those facts.

Remix them, create something new and lavishly praise the people that came up with the ideas.

One practice that really stuck with me is “Always Be Capturing”.

The concept is simple: as the facilitator, you capture ideas on post-its or whiteboards the moment people share them. This small practice has some great side-effects. It saves the in-the-moment discussions and thoughts, shows the participants their ideas are important, it creates a visual summary that we can use as a “was this what you meant?” and probably the best part is that it creates a collection of ideas that we can organise later.

I use this during conversations, while listening to audiobooks, or podcasts. I’ve set up a quick shortcut on my phone that opens a text area and saves notes directly to my favorite note-taking app.

The beauty of this system is its simplicity. Capture first, then group, filter, and remix later.

At some point that weight makes the story complicated and hard to understand.

Weight becomes the blocker for advancing. You have built debt.

This applies to generating code with AI too.

It’s powerful but can produce code in wrong places, fix unintended problems and make assumptions about what to write.

Just because AI can create a lot quickly doesn’t mean it’s creating what we need.

If the client is happy with the results then you’re delivering what they’re paying for.

Hourly billing punishes efficiency and expertise. Outcome matters, not the time spent.

At some point the industry decided fullstack was the ideal. You should handle everything from pixel-perfect CSS to database optimization because… it’s efficient? More cost-effective?

Outside of solo entrepreneurs I’ve met remarkably few developers who genuinely enjoy both ends of the spectrum equally. Most have clear preferences. They either light up discussing UI interactions or get excited about backend architecture but rarely both.

This preference gap can explain why tools like vibe coding are gaining popularity. These tools reduce the parts of development work people enjoy least while still getting the job done.

Like grinding through side quests in a game before tackling the main storyline. All that seemingly extra work makes the final boss battle feel surprisingly manageable.

Tech influencers often preach ‘If it’s easy, it’s probably not special.’ But they miss the timeline. What feels easy today only seems that way because you already did the hard work yesterday.

When I’m vague, it gives vague results. This forces me to clarify my own thinking and be more precise.

The cognitive work doesn’t disappear, it shifts to higher level of design and critical evaluation.

The challenge is using AI intentionally rather than letting it replace our thinking entirely.

Sure there’ll be links, but think of them more as page 2 of Google results. People that want answers want them quick and GenAI delivers right now.

How this will disrupt the ads business, a business where number of eyes is important we don’t know yet. But just think about the effect it has when an AI Assistant searches on your behalf and give you the results you need.

We once came to these platforms to see what our friends were up to. Then we returned because we got what they predicted we should like. Now they’re no different than TV streaming or radio except for their more efficient dopamine-triggering mechanisms.

Algorithms are not social.

This adaptive behavior isn’t just about following rules. It’s about understanding the unwritten language of this new codebase. That teams develop patterns and practices that represent their knowledge.

Current AI coding tools miss this context. They generate functional but generic code drawn from open source repositories, that in isolation are awesome but in relation to existing internal codebases are off.

They write average code for specific environments that don’t want to be average.

Beyond Simple Generation

I believe we’re heading toward a more sophisticated approach with specialized AI agents handling different aspects of development.

Solution Agents that focuses purely on solving the problem, functionally without concern for style or conventions. Adaptation Agent that transform this solution to match the companies specific patterns and practices and possibly a Readability Agent that ensures that this code is comprehensible by humans.

First write the expectations, then generate the code, then create tests, then refine the code. Each step handled by agents optimized for that specific task.

This mirrors how human teams work today. Establish direction, implement solutions, and ensure quality and consistency. The difference is speed and scale.

The Future of Development

The most powerful development environments won’t be those that simply generate code fastest. They’ll be systems that understand your specific codebase deeply and adapt to your team’s unique approach.

When you begin a project, you’ll decide upfront what you want: TypeScript, specific linting rules, run on Cloudflare. But beyond these technical choices, your AI system will learn what makes your codebase unique.

Unlike the patterns found in open source repositories, your AI agents will understand the complete picture of your application. They’ll recognize that teams evolve their own concepts and styles that may not match external patterns.

This is the natural progression from todays word-by-word generation to truly contextual development assistance.

It’s not just about writing code, it is about writing code that belongs.

I used to have a great mp3 collection, you know, back in the days when it was almost considered legal.

It was an amazing feat to keep it up to date in Winamp and later iTunes with correct titles and album art. There came apps that focused solely on this catalogue part using online sources to update the metadata called ID3.

Then came Spotify and changed that completely. That time spent curating was just sunk cost and my well catalogued mp3s are probably on an old dying hard drive somewhere in the house.

This is the reality we must face when it comes to AI and as a developer I see this so vividly.

What used to be “LLMs cannot code” became “LLMs write bad code” and now “LLMs write ok code”.

So we shift focus and find a new weak spot: LLMs cannot fix bugs. Or I cannot understand the code it writes.

But then again, the code I struggle to understand, it can explain to me 99% of the time. The ability to both generate and explain complex code further diminishes our position as keepers of the technical knowledge.

We move the focus to what it cannot do while something else comes along that changes the playing field, a new Spotify emerges and changes it all.

LLMs with the context memory of your complete repository. With the knowledge of every commit and every connected ticket. That can understand the reason behind the change in an iterative fashion. You will not need to understand the code. It will need to understand the code.

You will need to understand what you want to achieve and why. This understanding of purpose becomes our core value proposition as technical professionals.

As AI Agents emerge and become reliable we will prompt it with “increase the convert rate by 10%, these are the amounts of visitors we have, make small changes until you reached your goal or you need my attention, you have one quarter”.

Why is this happening so quickly? There’s an economic incentive at play. Developer salaries, especially in Big Tech, have skyrocketed over the past decade. AI development may be running at a loss now, but it might be following the Starbucks playbook of crowd out competition first, then raise prices. Companies investing billions in AI aren’t doing it for novelty. They’re eyeing the massive labor costs they could eliminate. Right now AI is marketed as an assistant, but the financial motivation to replace rather than augment is powerful.

So where does this leave us as developers? We need to move up the value chain. If algorithms can handle implementation, we must master the intention behind it. This brings us back to first principles thinking.

These are the first principles that we aim at: Why do we build this service? What do the end users aim to solve?

This will be the hardest problem to understand and execute on. If my technical skills are not required as they used to be, what should I focus on instead?

History gives us a clue. In the past, key makers, cobblers and tailors used to be three separate jobs. As the market changed, their crafts were not needed to the same extent, but those who survived saw that with their dexterity they could adapt to new needs.

My view is that multiple technical crafts will join together, and our focus will shift toward the complete value chain rather than isolated implementation details. We’ll need to understand the whole picture to remain relevant.

Those first principles will not be: to write code.

I see the same style cartoons popping up across business social networks.

People generate fun images to pair with their messages. The visuals look cute but generic, completely out of brand and identical to everyone else’s. You might get some laughs. But nobody remembers which brand posted it.

Is that temporary engagement worth sacrificing your visual identity?

I know it is scary, releasing a product in the wild.

Whatever product that is, piece of music, a service, an idea, make an effort to ship fast to a minimum viable audience.

Viable audience means someone who has a stake or is interested in your product, not your friends or your family.

Shipping means being open to fail. You cannot fail, or succeed without shipping. you just do.

I’m also scared about shipping. Probably or especially when you’ve just built something for yourself.

We should not act surprised if they don’t change.

Functional prototypes let you iterate with real users and discover how they actually interact with your solution.

Both have their place. Choose based on what you need to learn or communicate.

Then when you want to create an image you start from a noisy image and add your prompt (i.e tag) and then it starts removing noise and starts iteratively doing this until you see an image. The text prompt is converted into a numerical representation that guides the denoising process.

Think of this as when you try to learn something new. You have some hooks in your brain from before, you start to add context, new lessons, new information and suddenly you see the areas somewhat clearer.

Most LLMs (ChatGPT, Mistral, Claude, Gemini and so on) usually write like we humans do. We add one word after another.

Diffusion based text models have started to appear. Think of them as working in reverse. You might input the last words like the ending of a script and then from complete noise it starts to add in words that make sense.

The model keeps refining this noisy text adding more coherent words until in the end we have something somewhat unique. This approach creates text quite differently from traditional word by word generation.

What does this mean for texts?

Since it is not constrained of left-to-right thinking the output can be more creative and surprising. It can solve potential issues where sequential models struggle with maintaining coherence across long passages.

In this way it mimics how creatives work. Moving from rough draft to refinement to polished work.

A future existence of multiple models that we can use in different parts of the creative flow is exciting.

But remember that urgent is not the same as important.

Depending on who set the expectations urgent matters can become important to handle, not important to act on.

The AI revolution demands we distinguish between what requires attention and what deserves action.

Choose your priorities based on impact not hype.

When we approach something and brush away the sand, making that area clearer.

If we don’t use it for a while, the sand slowly returns, somewhat covering but we can still see the shape.

As more people became literate over time, writing styles changed.

People started to value writing that was clear and to the point instead.

Is it possible that we will face similar changes with Generative AI and LLMs?

At first people might show off by generating massive amounts.

Then we might shift to valuing brevity while maintaining the same meaning.

Eventually we could reach a point where writing adapts in ways that blur the line between human and AI-assisted text.

• Create a branch before asking AI to write any code
• Request only small specific changes from the AI
• Commit those changes immediately when they work
• Complete a “micro-sprint” then merge to main
• Work small and fast with one-hour blocks not two-week marathons
• Be prepared to start over by breaking tasks into even smaller pieces
• Begin with manual implementations before attempting automation
• Expect longer timelines for final production builds despite initial rapid progress

It begins with “everything is fine” and despite declining results with hold on to familiar processes.

When change is bound to happen, resistance naturally follows as we push back end question “why is this even needed”.

As new processes take hold, confusion starts to emerge “this feels backwards, are we even moving faster”.

Then all the sudden we realize the breakthrough moment “aha! this actually works better!” as we see the benefits that made the discomfort worthwhile.

This kind of view of the phases can help leaders guide their teams through transitions.

This isn’t speculation anymore as it’s become the underlying theme at almost every industry summit I’ve attended this year.

When we attend these events we seek human connection, perspectives and experiences. We want someone genuine being present and delivering insights that make our spider-senses go “what the heck!?”.

Nordic AI Media Summit 2025 delivered on this and went beyond.

But it got me thinking about other summits and presentations I’ve attended over the years.

Sometimes we feel immediately uncomfortable when someone is clearly just reading from a script. When the delivery sounds like a Dalek monotone or presentations lack visual pizzazz, we mentally check out and struggle to stay present even though the content is great.

We need a story or person we can connect with, whether positively or negatively, that demonstrates there’s an actual human sharing their personal perspective. It reminds me of that odd feeling when someone accepts an award via pre-recorded video. We feel cheated of the authentic experience we expected.

At NAMS25, these discussions about human authenticity intersected with questions about our future roles. If AI will replace much of what we do professionally, what remains uniquely human?

I believe this tension will reshape news media. AI will handle the facts, the police reports, the sports scores and the basic who-what-where of breaking news.

What remains uniquely human is our ability to provide context through lived experiences. AI can’t share what it felt like to be in the office the day after the last US election, how your commute to work was obstructed by someone removing a bridge.

Our future does not lie in competing with AI on data, but in the human connection, the unique local view of the community, what they have experienced and how to tell that story in the right context.

That perspective will be hard for algorithms to replicate.

That moment of clarity, when abstract ideas collide with concrete implementation, remains one of the most powerful feelings in product development.

As we are getting closer to mid-2025, this fundamental truth starts to show a subtle misinformation in “AI will replace coders”. The narrative that suggests that coding careers are somewhat fruitless has proven more persistent and I would say potentially harmful than feared waves of mis-information and deep fakes that dominated discussions in 2024.

This parallel struck me while listening to panel discussion at NAMS25 today.

While the AI coding tools have evolved, as in they excel at generating code, they have not started bridging the super critical gap between what users say they want and what they actually need.

When someone types “Build me an app that does THIS”, a somewhat vague request, it starts a journey towards a valuable product. And that journey always comes with human judgment at multiple decision points.

The most valuable skills still remain uniquely human: breaking apart problems, systems thinking and the ability to translate between technical possibilities and actual human needs.

This is what makes AI tools so powerful in the right hands. They amplify capabilities that already exist, they don’t replace them.

For those making career decisions: Don’t shy away from development because AI’s rise. Instead focus on developing skills AI can’t replicate. Learn the skills to collaborate effectively with the tools and (this is crucial) maintain the human abilities that give tech its purpose.

Touching that first prototype and having the ability to recognize that this is not working that is the core skill we developers need.

The danger isn’t just putting humans in the loop but keeping us engaged in that loop. Without genuine interest our oversight becomes hollow ritual.

Every newcomer tried. I tried. Probably ones every year.

That piece of code became boring to work with. It was hard to add features too. It was easier to just add something around it, patch it.

Those pieces of code became boring and not prioritized.

It became tech debt out of being boring to work with, and every large scale system has that piece of code.

Followed up to why tech debt

When things start flowing effortlessly, it’s not because the work lacks value.

Follow up to why tech debt

Tech debt isn’t solely an engineering issue. When designers create solutions without technical context, product managers can’t articulate clear user needs, or executives push for features without validation, we build the wrong things well rather than the right things simply.

The most dangerous misunderstandings come from solving theoretical problems instead of actual ones. We build complex, flexible frameworks anticipating edge cases that never materialize, leaving behind over-engineered systems that must be maintained without delivering proportional value.

Follow up to why tech debt

It actually is that simple. We create tech debt when we work on things we think are interesting instead of what’s truly important (priorities), when we build before truly understanding the needs (problem), and when we work with old code without knowing why it works a certain way (code).

After those minutes it turns itself off and cleans everything, and it is quite loud when it does this. I’ve realized that when this happens I’m always reminded of coffee. This makes me want to go and… grab coffee.

This coffee machine scenario highlights a broader pattern I’ve noticed: our environment creates automatic triggers that can derail our intentions. Another example is how we use timers for productivity.

Getting into flow sometimes needs tools like setting a timer for 5 minutes to overcome initial resistance. I use this technique to commit to just “investing” 5 minutes in a task, which is usually enough to get started.

The problem with timers is when they go off… you get a Pavlovian response that you are done.

Breaking these loops might require changing the environment rather than fighting the response. Moving your workspace away from the coffee machine’s audible range eliminates the trigger entirely. Similarly, using visual timers like sand hourglasses instead of alarm sounds can help maintain flow while still tracking time.

The key is recognizing these automated triggers and redesigning them to align with your true intentions rather than working against them.

Ask the one question that answers twenty others. Then be patient enough to listen.

During the late 90s dot-com bubble, Sweden had its own tech superstars. Jonas Birgersson became known as “Broadband Jesus” for his vision of universal internet access through his company Framfab. Johan Staël von Holstein built Icon Medialab into a global player before the crash, while Ernst Malmsten and Kajsa Leander’s Boo.com famously burned through massive venture capital in just 18 months before collapsing. Boo.com epitomized being too early - their Flash-heavy website required significant bandwidth that most users simply didn’t have at the time.

What these companies share with today’s AI boom is striking: outsized hype about profitability and technology prioritized over utility. These entrepreneurs were creative people riding a wave of genuine possibility.

Strange how these used to be three entirely different professions.

During the 1950s mass production of shoes took off and cobblers had to diversify. Their manual skills and dexterity led them to key-making.

This shift essentially eliminated dedicated key makers as a profession. But those professionals didn’t vanish. The key industry pivoted toward security systems instead.

What we’re seeing over time is our human tendency to invent new professions that replace old ones.

We’re remarkably adaptive creatures. Just as cobblers became key makers when mass production changed their industry we’ll adapt to AI too.

Our history is defined by this continuous reinvention. When technologies shift we don’t disappear. We transform.

As an artist who connects technology with nature, she imposed this vocal-only constraint deliberately. She challenged herself to create everything (basslines, percussion, atmospherics) using just the human throat.

Instead of using everything at your disposal, set constraints to test your imagination. When we limit our tools or methods, we’re forced to think more creatively within those boundaries, often leading to more innovative and distinctive outcomes.

What does work is reviewing the material, taking a step back and going for a walk without any devices or distractions.

The simple act of getting blood flowing activates the brain in different ways.

The concept is simple: I commit to just “investing” 5 minutes in a task. Those few minutes are usually all I need to get started and break through my resistance.

In meetings we learned to take notes for what was being said and what was being decided upon. The focus is on action items, ownership and deadlines.

AI note taking and transcripts are changing meeting notes into something more like school notes. “You actually said this, there is a record of it.” This brings accountability but loses something important.

What’s missing in these perfect transcripts is the context and human feeling around the meetings. The energy in the room when an idea was proposed. The hesitation before someone agreed. The enthusiasm that can’t be captured in words alone.

Different contexts require different note-taking strategies. The key is recognizing what each approach captures and what it leaves out.

Capturing everything misses the point entirely. What matters is recording your unique reaction to ideas. How they connect to your experiences or challenge your thinking.

The real value in personal notes is selective attention. This human filter is what turns random information into gold nuggets.

Your notes should reflect your thinking, not just what you heard. They’re a conversation between you and the content, capturing the sparks that light up your mind.

The magic is connecting the dots, those sparks when two oddly shaped pieces of information somehow connected in your brain and created something truly unique that only you could come up with. But that magic cannot happen when you store everything and try to remember everything to be able to connect everything.

Take time to learn something with no clear payoff, it could become your advantage later.

What looks pointless now might matter tomorrow. Just like alchemy experiments led to chemistry.

The skills hardest to justify on a resume are often what separate human brilliance from machine efficiency.

Think complex systems thinking, strategic procrastination, narrative weaving or deep listening without an agenda.

Instead, externalizing memory created space for more complex thinking.

How can AI free mental bandwidth for high-order thinking and curiosity, if we decide not to doom scroll?

Friday in April can be just as powerful as January 1st. The calendar doesn’t create commitment - your personal readiness does.

Great ideas will never leave you, similar to how bugs never do.

Our backlogs fill with old ideas and urgencies that never resurface, clogging our physical and digital spaces. We already have enough to do. Store ideas separate from todos.

Store personal ideas in a dedicated space, like memories in a box. Keep your workspace tidy.

When ideating, open that idea box and explore freely.

Remove backlog tickets you haven’t touched in 3 months. Bring them back only when planning or seeking inspiration, but don’t let them dictate your path.

Traditional paths teach us to follow common and sometimes good steps. Non-traditional paths teach us to view those steps differently.

The first time, I sheepishly sent it for repair. The second time, shame drove me to figure it out myself. Creating a boot floppy disk that could access the CD-ROM to reinstall Windows. I think that moment changed everything for me.

I learned three truths that possibly shaped my career:

• Breaking things isn’t fatal
• The path forward often runs through mistakes
• Self-reliance builds deeper understanding than following instructions

In 1999, I entered the tech arena without formal education. There were no YouTube tutorials or Stack Overflow. Learning meant tinkering with HTML, JavaScript, and CSS until something worked.

This ‘constructive breaking’ mindset has carried me through multiple roles spanning development, management, and leadership. Without the identity anchor of formal credentials, I’ve never felt trapped in one specialty.

As generative AI increasingly writes code through simple natural language prompts, with tools like Lovable, Bolt, and Replit that can build entire websites and SaaS products, the most valuable skill won’t be expertise in syntax or current frameworks. It will be the courage to break things, the resilience to fix them, and the adaptability to understand what actually solves the problem at hand.

What we fear in the AI era isn’t just disappearing entry-level coding jobs, but the learning path they represent. If AI handles the ‘easy’ parts, how will developers grow?

The answer might be counterintuitive: we need more people willing to break AI’s output, question its solutions, and develop through deliberate experimentation. The junior role evolves from writing basic code to breaking sophisticated systems, creating a new and equally valuable learning path.

The future belongs to constructive breakers.

Connecting the dots going forward is what we call strategy.

What often is lacking in strategy is the serendipity and leeway to pivot.

Make room for tactics to alter the destination. The best strategies evolve with new information.

A few days ago I created Ghibli-style art with my kids using OpenAI’s upgraded image generator. “Make one of me” they asked with wide eyes.

As perfect copies appeared with just a few words, I wondered: what makes an “original” anymore?

This got me thinking about authenticity beyond copyright debates. When AI can create anything, how will we know who really made what?

And then it hit me: Non-fungible token aka NFTs . Those blockchain certificates that crashed after their speculative bubble might actually serve their intended purpose now. With greener blockchain solutions emerging, NFTs could finally become something useful: digital authenticity markers when we need them most.

This makes them stuck. Unable to discuss. Unable to move forward.

Their minds become storage vaults rather than creative engines, just like when a midnight idea keeps you awake because you’re afraid to forget it.

Today, people who can effectively prompt AI tools or integrate AI into workflows are finding opportunities—just like those who could build websites in 1998. You don’t need a PhD. Practical skills are what companies need.

The pattern with AI is clear: shortage of skilled people now, then formal education later. Focus on using and learning, and you’ll be fine. Just as with web development before it.

Trust your audience to recognize what’s important without highlighting it for them.

This is one of the most important aspects of developing with AI.

When building frontend features that need an API, set clear expectations to and from the backend. Provide only what’s necessary, not everything.

“If you wish to make an apple pie from scratch, you must first invent the universe.” - Carl Sagan

The ‘what if we could’ ideas.

These are the ideas your boss or manager or owner wants to test but doesn’t dare ask for since it might be seen as micromanaging.

This becomes especially valuable as companies grow beyond the size where owners can personally know everyone.

Keep track of these ideas because they often surface in various projects. They’re leadership’s pet peeves and concepts that are hard for them to ignore.

Try asking them directly: “Tell me about some ideas that you’ve had for our products that you think we need or should test?”

Remember that listening doesn’t always mean acting. Understanding these ideas gives you valuable insight even if you don’t implement them all. Sometimes leadership just wants to be heard not necessarily have every thought turned into a project.

He told the story of how after an update of his MPC the displays had reversed the indicators of which sounds were playing and which were muted. He discovered this while performing on stage at a concert in Japan.

The odd thing that happened was that the crowd went mental for the performance when he distilled the tracks to their most basic form.

Sometimes we need less to be impactful.

Today’s graduates arrive armed with skills and experiences ready to deploy immediately. From social media expertise to video production to any digital online navigation.

This creates different expectations about advancement speed and compensation that reflect our new reality.

This matters most in one on ones and small group workshops. Match their energy first, then lead them to your destination.

Look at great performers and presenters. They rarely start cold. There’s usually an opening act or crowd work to set the mood.

When you’re solo, you’ll need to do both parts: match their current state, then guide the change.

It’s not about literally saying the words but embodying the mindset. When performers hear something odd or unexpected, they adapt and build on it rather than blocking with “no” or “yes but.”

This mindset works beyond improv. Whether in sales conversations, colleague discussions, or daily life, choosing “yes and” over “yes but” opens doors instead of building walls. It shifts us from defensive reactions to constructive dialogue.

Being a professional is always being an impostor, we always do things out of our comfort zone.

Imagine if we spent that energy on the work instead of the performance.

But innovation rarely comes from perfect ideas. It comes from collisions between different thoughts, good and bad alike.

Think of it like improv: “yes, and…” We need more raw material to play with. More ideas to bounce around, even the “bad” ones.

But I think we’re nostalgic for a time when we didn’t have options. We could only have workshops together in conference rooms.

That’s where everything happened. The aha moments. The breakthroughs.

That correlation is what makes us think it was good. But it was the only thing we had.

Planning can be rigid and lead us down specific paths. The idea of knowing the destination and just going along.

Preparing is about setting the stage, building capabilities and staying flexible.

3M, the company behind every agile coach’s favorite accessory (the Post-it), prepares for innovation by giving employees 15% of their time to experiment and spot opportunities. One such opportunity was the failed adhesive experiment that lead to a somewhat sticky mess that made up the adhesive for post-its.

This approach to culture set the stage for innovation to emerge naturally rather than forcing it through rigid plans.

Another example is Design Sprints, a five day workshop that originated from Google Ventures which purpose is to verify a new idea. Planning handles the schedule, the five days and their structure. But the real magic comes from preparation: identifying the right challenge, finding the right people to interview, and selecting the right participants. Without proper preparation, even a perfectly planned sprint won’t lead to meaningful innovation.

While planning is crucial for execution, preparing is key for innovation.

When I watch a specific YouTuber playing games, I’m making an active choice. I know what I want. I pick the content. I enjoy the experience.

But when I mindlessly swipe through reels or shorts, I’m just reacting. The algorithm chooses for me. I’m not in control.

This is the difference between productivity and waste. Productivity happens when we actively choose. Waste happens when we passively react.

Similar to software. We use one for music and a different for mail.

We have plenty of different apps to achieve different outcomes.

Is puzzle really the best word for this? Would life balance be better?

Puzzles have a tendency to be finished. But life puzzles will never be done. The only way it could be like a real puzzle is if someone keeps hiding pieces or dragging it to the floor.

AI Slop has become like a shorthand word to summarize quickly produced and often indistinguishable content that floods SoMe and you inbox with newsletters.

In the 1500s and forward slop came to describe cheap and ready-made clothing and in 1800s it was associated with mass-produced, low-quality clothing produced by workers with little to no rights or regulations.

Slop has always been about quantity over quality.

You might be full on, but your team is possibly not.

Most chat and email tools have features to delay or schedule sending. Use it.

Take making music for example. I don’t want to waste time setting up equipment. plugging everything in and opening apps before I can start creating.

That’s too much friction. Instead pick a few key tools. Make them instantly available. Schedule your time and just go.

Stay focused on your core business. Everything else can wait.

Sometimes the best move during rapid change is to sit still in your boat. Just keep watching the waters ahead so you know when it’s truly time to act.

But don’t mistake patience for denial. When change affects your core business it’s time to move.

Doing is a flywheel that creates momentum.

Most listening fails around step 2.

We’re at a similar threshold for AI and software as a service (SaaS). The tools to build software are becoming more accessible every day.

It makes creation possible for everyone. Small teams and individuals can now build tools in days and weeks instead of months and years. Technical complexity that once required years of experience and specialized knowledge is now simplified with AI that can write code, design interfaces, and implement features using natural language.

However, Singer’s sewing machines didn’t eliminate the need for basic sewing skills and AI tools won’t remove the requirement for basic tech knowledge. What changes is the barrier to entry.

Like Singer paved the way for thousands of at-home tailors, I predict thousands of specialized micro-SaaS products emerging at relatively low costs.

Established SaaS companies face a crucial tipping point. Will they become the Singer of the AI age, adapting their business models to this new reality?

History suggests that when barriers collapse, markets change permanently. We saw it with Kodak losing to digital cameras, Blockbuster missing out on streaming, and AltaVista bypassed by a single input field.

Most people are too focused on themselves to notice you.

Do it for yourself and for those who are actively looking for it.

Be so good they can’t ignore you - Steve Martin

But before that, remember no one cares about your first attempts. Your work is to keep showing up until they do.

There is something special with patterns that emerge and things that feel and sound good. Think about classic I, IV, and V chords that make up a lot of songs. The feelings is that you recognize it and feel comforted about it, and combined together with a familiar rhythm in the song, you feel complete.

When you create something that feels out of your comfort zone, you don’t follow patterns you are used to. You go with your own tune with your own beat. And this is a power when it comes to being the new kid on the block.

You don’t need to follow the ways of big successful organizations. They’ve found one way and often stick with it. Patterns and behaviours that become chains that make change much harder.

New companies bring a fresh view. A clear vision that isn’t watered down by inner politics and competing priorities within big companies.

They can pivot quickly. Try new things. Change their vision voice and tone in an instant.

That’s the superpower of new businesses.

• a YouTuber
• influencer
• gamer
• social media expert
• lifestyle entrepreneur
• prompt engineer
• e-sports team coach
• digital estate planner

AI might remove a lot of jobs, but we will most possibly invent new ones, just like we always have.

Your result: shaping thoughts, emotions, actions and beliefs.

It’s not exclusive to juniors. Even longtime leaders show this. Second-guess themselves and feel like fakes.

It’s like trying to have a conversation when you’re not sure what language the other person speaks.

Embracing the flaws is the best way to hide the flaws. Because then the flaws become the signature. - Venus Theory

This reminds me of my first Fallout 4 playthrough. I tried to make my character equally good at everything. Just like when I became an engineering manager and saw that skill matrix spider web. I automatically assumed I needed to max out every area.

But here’s the thing: being average at everything isn’t as valuable as being exceptional at specific things. Some of our “flaws” are just areas we’ve chosen not to prioritize. And that’s okay.

Like that piano chord in Roxanne sometimes our mistakes and imperfections become our signature. Our strength isn’t in being flawless. It’s in owning the mistakes and the imperfections.

There are key parallels between Amazon’s silent meetings and the flipped classroom model: both rely on everyone starting with the same information before discussion begins. When done right teachers become coaches guiding students through shared material rather than lecturers delivering new content.

When I’ve experienced a working flipped classroom, it has been all about the “silent reading” part. The students all started from the same baseline when it came to the information. They worked together in small groups summarizing it, then shared with a bigger group about what they learned.

This is often when I’ve seen the flipped classroom break. Instead of having the same baseline, each group has had a different set of topics and areas they should summarize and teach to the rest of the group. Effectively they’ve switched from an experienced teacher to an amateur teacher, and they’ve only learned the topics they themselves have discussed. The method works best when it builds on shared understanding rather than dividing the learning experience.

But as a manager or leader I most often pick buy.

The equation rarely adds up when you build something that’s not part of your core business. Unless your core business is faced with a tight budget.

And by equation I mean time. Hours spent building, making it better, bug-fixing, upgrading, new feature, planning, sorting, prioritizing it, knowledge sharing.

When looking at complaints and help requests you’ll only capture the minority of vocal customers. But your satisfied users might have the key insights to what makes your product worthwhile. Your loyal users often value something completely different from what complaining customers expect.

Value alignment over problem resolution.

You might have a bug in the product but you might also have the wrong customer.

I remember when we introduced this at Spotify. Leadership felt it took way too long to make decisions - almost like paralysis by analysis. But once understood it was a fairly simple shift to get teams moving faster.

There are very few decisions we can’t reverse if they fail. Consent helps us move quickly toward either failure or success. Continuing to analyze and second guess rarely moves us forward.

One challenge with consent is that someone needs to make a stand. If discussions are endless then it might not be consent that’s lacking. It might be that no one cares strongly enough to put a stake in the ground. Or worse it might be a sign that no one feels psychologically safe to make a mistake.

Think of it as a lens for spotting connections and extracting insights rather than a factory churning out content.

Earlier AI focused on clear tasks (recognize this, predict that, sort these) and it was easy to measure if the results were better.

But generative AI opens new possibilities for exploration and creativity. Yet we measure it with industrial era metrics and we see it in all benchmarks that the Generative AI companies share when they release a new model.

The power isn’t in producing more, but in helping us see different angles and uncover unexpected patterns. Quality over quantity. Insight over output.

The question shifts from ‘How can we create more?’ to ‘How can we discover better?’"

Right now I’m guilty of this with music. I’m setting up the perfect Ableton Live set. Buying gear. Watching performance videos. Even coding custom tools to make it “better.”

Have I made any actual music yet? Nope.

Bad art teaches you more than perfect planning ever will.

Here’s the truth though: Bad art teaches you more than perfect planning ever will.

Maybe instead of trying to get everything right we should just create something terrible on purpose. Make that awful track. Write that horrible story. Take those bad photos.

Because really. What’s braver? Having the perfect plan or actually making something?

Most people stick to either talking or writing when processing thoughts. But you might get better results in combining the spontaneity in verbal processing and the structure of written words

Start talking. Let yourself ramble on a topic without filters. Just let the ideas tumble out.

Then bring it to AI. It captures your ramblings and reflects them back in text form. No judgment. No interruptions.

Now read the response. This is where scattered thoughts begin to make sense. Reading slows your brain down. Helps you spot patterns in your own ramblings.

It’s like having two thinking modes: creative outpour and thoughtful reflection. Your brain needs both to turn raw thoughts into clear ideas.

Directors sitting at their desks saying “I want a moody scene. Start with a low angle shot that slowly pans up to reveal a cityscape at dawn.” And then uses AI powered tools to create it.

Sharing vision becomes easier. Instead of struggling to explain what’s in your head you can show it. “Here’s the vibe I want” becomes a starting point not hours of back and forth.

Creating becomes less about technical skills and more about creativity. We’ll spend less time figuring out how to make something and more time deciding what stories need to be told.

Think of Harvey Pekar before he met R. Crumb. Amazing comic ideas trapped in his head because he couldn’t draw. Soon that barrier between imagination and creation disappears.

The tools are becoming easier. The ideas will become everything.

Alternative to estimates: do the most important thing until either it ships or it is no longer the most important thing. - Kent Beck

The challenge comes in knowing which thing is the most important thing. Similar to path of least resistance where water naturally flows downhill taking the easiest route. We tend to pick the things that are easier or use less time.

Most often we pick the path of most comfortable.

Let me share a recent example. A company decided to use a shared ChatGPT account to save money. One day. the owner started a new chat with the topic “How to fire people”. This was visible to everyone using that account.

Even though you think a service is secure. moving data anywhere online means it can end up in the wrong hands. Your “deleted” content lives on in endless iterations as backups. archives. and screenshots.

And when you’re using shared accounts? The risks multiply. Your private information becomes accessible to everyone with access.

Always remember: Nothing is truly private online.

Focus on four things: construct, scope, assumptions, and reduction.

Construct “What”, “How”, and “Tell” are excellent question starters that can help with reflective thinking. “Why”, “Who”, “When” limit our responses.

Scope Ask from the point of view that you must take, be it a stakeholder or your own.

Assumptions In many great questions, there are inherent assumptions, make sure that you know yours and how to use them for benefit.

Reduction Do you want to reduce the output or response that you get? Example: “Tell me about yourself” vs “Tell me your three favourite movies, growing up”

Friendly reminder: answers can be strange, odd, and bad.

Every answer is someone’s interpretation of the truth. A question is a desire to understand that truth. - Darko Vukovic

One of my problems is “What can you focus on as engineering manager if you can no longer scale? Is it only faster, cheaper, reduction of complexity? Or perhaps quality improvements, developer experience, system reliability, or team capabilities?”

Building your own products can feel the same way. We judge their external polished front with how our messy process, discussions or iterations feel.

Through iteration. Through persistence. Through pure stubbornness.

That’s how you turn a tiny spark into a fire.

Think about making an app. You need words to explain views. Canvas. Navigation. When you talk to AI you can’t just say “make me a game”. You need to say “I want a browser game for phones. With a high score list that works like this”.

That is vocabulary. But soon everyone will know these words. Everyone will generate apps and games. That is when taste becomes important.

Anyone can make a game today. But making something that feels good. That is different. That takes taste.

Vocabulary lets you tell the machine what to build. Taste lets you make it worth building.

Focus on a few things and master them completely.

We’re asked “how long will this take?” as if we’re building something we’ve built before. But in product development we’re creating something new every time, within the constraints of our tech stack, frameworks, and past decisions.

Many teams are starting to talk about appetite instead of estimates. It changes everything about how we approach the work. Instead of “can we build exactly this?” we ask “what’s the best we can build in the time this is worth?”

To get to a meaningful appetite:

• Start by understanding the problem you want to solve
• Know why it matters now
• Be clear about desired outcomes
• Decide what investment makes sense

Then bring all of this context to your team. Let them understand not just the time box. But the why. Because an appetite isn’t a time constraint. It’s a value decision about how much of your company’s resources should focus on this solution.

Be explicit of what you expect and make sure you understand what is expected.

When conflict arise, take a step back and check if it is simply a case of different expectations. I’ve often seen disagreements that are just people working from different assumptions.

But they’re far more comfortable giving feedback on a rough draft or prototype.

How can you not have a shrink? This is Manhattan. Even the shrinks have shrinks. I have three. […] one for when I want to be cuddled, one for when I want tough love and one for when I want to look at a beautiful man. - Stanford (Sex And The City)

When you ask for feedback you should be clear about what kind of feedback you need.

If you have written a post, do you want feedback on the punctuation, spelling or commas. Or do you want feedback on the order of things, if the story flows, does the order make sense.

Think about this when you ask for feedback. What do you want to improve, then sit back and enjoy. Some of the feedback will be hard. Some will be inspiring. Some will be important. Others you can ignore.

The idea that bots will influence what is important so that other bots will make content that focuses on those bots behavior.

It creates a bizarre ecosystem where AI systems essentially talk to each other, generating more online activity than actual human users ever could.

Any friction when you try to capture those “hard to create” ideas is lost the moment between “Enter App. Wait. Ohh where do I add a new…”.

You just need to sprint in capturing those ideas.

Always have a paper close, a shortcut to open your notes app, a button press away to record your ideas.

Teach your brain that ideas are important and that it can trust that the ideas it creates will end up somewhere.

Tactics is winning today. Strategy is winning the tomorrow.

You build trust by being present when someone needs you. It happens when you ask how they’re doing. When you listen. When you remember what they shared.

These tiny moments add up. They matter more than any grand gesture ever could.

Not every key metric needs a project or an initiative. Some metrics you just need to monitor, wait and see.

Some metrics should guide your strategy and inform on which long-term goals to focus on.

And you will get outcompeted by people who embrace change.

While you cling to old knowledge like a sunk cost, afraid to let go of what you’ve learned, change will happen and the world around you will move on.

I’ve seen this firsthand. From coding in the 90s out of pure interest. To managing teams. And now building complete products with AI.

Focus on the 3Cs: Clarity, Capacity and Collaboration.

Clarity

How can increase clarity for the team? Does everyone know what we are working on and why we are working on it? Can I make our current goals clear, our prioritization crystal and our targets obvious?

Capacity

Can I make our capacity visible? Do we have the time, skills and energy we need? Should we bring in outside perspective or knowledge? Are we working on too many things?

Collaboration

Can I identify and propose opportunities for collaboration? Can we work together on prioritized initiatives? Can we discuss challenges and find solutions together? Can we commit to reach out to others when we are stuck?

When either of these is lacking the team will focus on the wrong goals, they will be slower and cause friction, work in silos, make complicated solutions and will miss out on innovation.

The sweet spot is when all of this works.

Implementation Note

The power of this framework isn’t in formally announcing it, but in using it as a leadership compass to guide your team. Like good coaching, it’s about consistently creating an environment where these elements can thrive, especially when dealing with changing priorities from above. The framework becomes most effective when it feels natural rather than forced.

I call it CUP and it stands for Cabinet, Unfold and Play.

Cabinet

The Cabinet is a spin on the Cabinet of Curiosities and this is where I store most of my notes. The Cabinet is more than just storage - it’s a curated collection of knowledge, ideas, and inspiration. Like the historical cabinets of curiosities, it’s where we keep our most interesting findings. This could include book notes, research, interesting articles, concepts, or any piece of information worth preserving.

Unfold

Unfold captures life as it happens. By keeping daily notes, meeting logs, and journal entries here, we create a chronological story of our days. Through backlinks, these daily captures stay connected to our broader work, making it easy to trace how ideas and projects develop over time.

Play

By choosing “Play” over “Projects,” we create a space that invites creativity and experimentation. This section houses our active work and responsibilities, but approaches them with a lighter, more engaging mindset. Whether it’s writing, coding, or planning, framing it as play helps maintain curiosity and reduces the pressure we often associate with traditional project management.

Like the name suggests, CUP is a container - but one that’s designed to grow and evolve with our needs and interests.

We’ll evolve into the gatekeepers - like editors who approve manuscripts or art curators who authenticate masterpieces. But our stakes will be higher. We’ll be the ones signing off on code that artificial intelligence produces, code that could move markets or impact millions.

We’ll be the final human eyes, the ones who understand both the poetry and potential pitfalls in machine-written code.

Like hanging onto a jacket that no longer fits just because it used to be our favorite. We often cling to old dreams and ambitions that we’ve outgrown.

Are we still trying to achieve the goals of our past selves? Following an outdated map. Moving in a direction that no longer excites us.

Remember - the real failure isn’t in changing direction or letting go. The real failure is staying stuck. Doing nothing. Being afraid to admit we’ve changed. Every step forward teaches us something new about ourselves. Even if it means leaving old dreams behind.

Is this still your dream? Or are you just afraid to let it go?

But they need to be made.

They are the way to change our stories, our identities.

Stories change through action, and action starts with decision. Changing your identity story isn’t easy.

Stopping forever, might be.

Getting back on track is what matters.

Connect it to other factors that matter.

Is the fun? Is it efficient? Are you collaborating? Does it make you happy?

Once you start moving, it gets easier. Write the draft, copy-paste, steal, use AI — do whatever it takes to get away from the blank page as fast as possible.

Your first sentence does not need to be unique. Your last edit needs to be.

But be prepared to back off if your team starts taking it seriously.

Our economic systems reward quantity, and now AI tools let us create more content than ever before.

As business publishing evolved from 500-page bricks to concentrated 30 minute reads, we might see a similar shift in digital content.

People don’t want more, they want better. They want signal, not noise.

The real question for the future will not be “How much can we produce?” it will be “How can we deliver value with less?”.

When our ideas are too polished from the start, we leave no room for others to contribute.

That’s why rough ideas work better for team innovation.

Share them early and watch your team create something awesome.

It is tempting to stop at the quote, to grab the summary and run.

The real wisdom is what is behind that quote. What messy context gave birth to this clean and polished insight.

Summaries are like photos from interesting places on a friends social media. They should spark the need to go deeper to get to those “hmm”-moments that makes us pause where something resonates with or challenges us.

Bullet points might be efficient, but the real nuggets of gold is in the margins of the stories.

We don’t know what we don’t know.

You can plan all that you want, but you’ll only find the true complexity once you dig in.

We uncover all sorts of edge cases when we start working, and that is equal to developers, project managers and customers.

They first came into my life through personal development programs and they felt more like a forced exercise than a useful tool.

SMART goals were created for managing companies and projects back in 1981 and somehow they became the go-to framework for personal development. Leadership experts everywhere pushed them as the solution. But just because something works for corporate planning doesn’t mean it translates well to individual growth.

As a team leader, I struggle when setting SMART goals with my team members. This is especially true for creative or thinking-intensive work. These goals often become binary checkboxes. They’re either done or not done. This misses the nuance of real progress.

Recently I discovered Ali Abdaal’s NICE goals framework. It resonates much better with how people actually develop and grow.

Let’s break it down:

Near term: Focus on what you can do today, tomorrow, or next week. It’s about the immediate future, not some distant target.

Input Based: Instead of focusing on outcomes we can’t control, concentrate on actions we can take right now. What specific steps can you take to move forward?

Controllable: Choose goals within your sphere of influence. Running ten miles daily might be unrealistic, but how about 10 minutes? You might not control what work lands on your desk, but you can control how you approach it.

Energizing: Make your goals exciting. Ask yourself: “How could this project be fun?” or “What could I teach others about this?” Find ways to inject energy into your goals.

The beauty of NICE goals is that they work with human nature. They acknowledge that personal development is more complex than a checkbox system from the 80s.

Processes and structures are just the tip, showing only a fraction of what matters.

The real force lies beneath in how people think, act, and influence others daily.

This invisible part isn’t written down in handbooks. It’s lived and shared through the decisions being made.

Think about it. It starts with gut feeling right from the beginning: deciding which data we should even bother collecting, which customers we should talk to, and what questions are worth asking. Then later, when we’re stuck choosing between two solutions or strategies that both look equally good on paper, it’s often that same gut feeling, backed by experience, that helps us make the final call.

That’s why senior leaders are so valuable. They’ve been through countless situations and have honed their instincts. Is it perfect? No way. But it’s often the best tool we have for navigating those tricky gaps between the data, the opinions, and all the things we just don’t know.

Decisions that really drive results need both data and opinions along with wisdom. Sometimes you simply need to trust your judgment. It’s that straightforward.

You need to be realistic. Technology moves fast and effective leadership requires both learning and coding.

When to code and what to code is like playing 4D chess. You need to look ahead and ask where the team needs to be in a year. What can you code today that will make future decisions easier?

Future decisions don’t always mean “let’s try this cool innovative thing.” It can also mean asking “Should we spend time on tech debt?”

It’s not about being in the way of progress. It’s about helping the team focus on what’s most important right now.

This creates what I call reverse FOMO. Instead of team members being afraid of missing out, leaders become anxious about not including everyone in every conversation, decision, or update.

There are two problems with this approach:

1. It overwhelms people with information they don’t need. Not everyone needs to know everything about every project or decision.
2. It actually makes it harder for people to find the information that is relevant to them.

There’s also a small shift of responsibility happening. When we put everything in the open, we sometimes use it as a shield: “Well, I shared it, so it’s on them if they didn’t read it.” This isn’t leadership - it’s avoiding our responsibility to communicate effectively.

Good transparency isn’t about sharing everything. It’s about sharing the right information with the right people at the right time.

If you are servant leader, then your role is to remove obstacles or create clarity for your team. Sharing everything is not reducing obstacles.

When we are learning we must choose uncertainty and be willing to make mistakes.

A child must let go of control and risk falling when learning to walk.

A company needs to loose control to innovate or adapt.

“Everyone has a plan until they get punched in the mouth” - Mike Tyson

Strategy is the high-level decision or goal. Should I fight Mike Tyson?

Plan is the steps to achieve the strategy. How should I fight Mike Tyson?

Tactic refers to on-the-spot actions to deal with the immediate situations. When Mike Tyson hits me in the face, I should sway left.

Managing focuses on the practical and operational side of things. Making sure your teams have what they need to make progress. Do they know what to prioritize? Are the bills paid, salaries handled, and vacations taken?

Leading has two parts. First is understanding your team: how they work, what challenges they face, and what you can realistically achieve together. Second is painting a picture of a possible future, especially when the team struggles to see beyond their current challenges.

This simple addition changes your random highlights into personally and relatable pieces of nuggets.

Processes alone are an easy path that almost never scales without hiccups and endless debate on which path a certain decision should take.

*) with leaders I almost never mean managers. Managers can be leaders but so could also developers, designers, sales, business i.e. anyone.

Ambiguity in goals, priorities, or vision from leadership often reflects a systemic issue, forcing processes to emerge from the bottom up as a way to compensate for the lack of clear direction.

Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. - Jeff Bezos

Lower the bar.

Get the MVP, draft, or idea out.

• Delegate: Others take decisions that you don’t even want to know about.
• Inquire: Others decide, but you can ask for more information if you want.
• Advise: You give advice, hoping others will listen, but the decision is theirs.
• Agree: You and others discuss and come to an agreement on what to do.
• Consult: You ask for input from others and consider their arguments when making your decision.
• Sell: You’ve made your decision, but you put effort into selling your idea to others to get them onboard.
• Tell: You make the decision with no delegation at all.

When delegating: Instead of thinking how you’ll miss out. Think about how you want to be involved.

From Desktop Kings to Mobile Natives

Once, desktop users ruled the web. Websites were feature-packed playgrounds. Mobile users got the short end of the stick with stripped-down “m.” versions. Then the mobile-first revolution hit. It prioritized mobile users and essential features, leaving the extras for desktop.

The Post-GDPR Wake-Up Call

Today, data privacy laws like GDPR, CCPA and ePR have changed the game. We can’t hoard user data anymore. This new landscape calls for a “data-minimalist” approach. Collect only what’s necessary. Treat additional data as a luxury, collected only with user consent.

Transactional Anonymity: The New Standard

Tracking users from start to finish is over. Regulations demand a level of transactional anonymity. It’s like walking into a store. You browse, choose, and buy. No prying eyes. Only essential data points, maybe some context if the customer opts in.

The Re-Rise of UX and Qualitative Research

In a world of limited data, we need to put User Experience and qualitative research in the spotlight again. UX isn’t a nice-to-have; it’s a must-have. It’s about understanding user needs and behaviors with the data we can ethically collect. Qualitative research adds the human touch that numbers alone can’t capture.

AI’s Role in Limited Data

AI comes into the picture here. It can analyze limited data sets and extract meaningful insights. Combine that with UX findings, and you get a complete view of what users really want and need.

It’s not just about less; it’s about better

The mobile-first revolution taught us to focus on essentials. Now, let’s apply that to data collection. As we adapt to new privacy norms, UX and qualitative research will become crucial. They’ll work alongside AI to help us create ethical, transparent, and user-friendly platforms. It’s not just about less; it’s about better.

The Gold Standard

Gold is shiny, valuable, and always in demand. Much like data, right? But there’s a catch. Gold just sits there. It doesn’t grow or change. Data, on the other hand, has the potential to transform our businesses in amazing ways and this is where the gold analogy may fall short.

Seeds of Potential

Imagine that we shift our perspective and compare data to seeds. Under the right conditions a seed can grow into a tall tree that bears fruits for years. Data holds a similar dynamic potential. A potential that can only be realized with the right nurturing.

Cultivating Insights

Just as a seed needs soil, water and sun, our data needs tools, the right people and timely action. If we don’t use or analyze our data, it’s like letting seeds go unplanted.

Quality is Key

Farmers know the importance of starting with high-quality seeds. Similar to data, garbage in means garbage out. If we start with unreliable data, our results won’t be trustworthy.

Diverse Data, Diverse Outcomes

There are countless types of seeds, and each one grows a different plant. Similarly, each type of data tells its own unique story. By understanding what each set of data can offer, we can make the most of it.

Embracing the Seed Mindset

Thinking of data as seeds gives a forward-looking view. It emphasizes nurturing, growth and realizing potential rather than mere storage. It’s a call to action: to not let our data sit idle but to cultivate it, nurture it and watch it flourish into strategies and insights.

Using OKRs should be reminiscent of orchestrating a symphony. Each element, whether it’s an instrument or a goal, plays a part in creating a unified, captivating performance.

Too Many OKRs

One, if not the most, important part of OKRs is to focus on what truly matters. If every department or team has its own objective, you are diluting the overarching company vision.

Imagine an orchestra where each section plays its distinct solo simultaneously. An overflow of objectives risks discord instead of harmony.

Way Too Many OKRs

Going deeper, if each member charts their own course, the essence of collaboration and alignment is lost. OKRs should unify, not segregate and create isolated islands of individual goals.

It’s comparable to each musician playing their own tune. The outcome? A confusing mishmash of sounds.

You Have Zero Cross Company OKRs

It’s a misstep to think only in departmental silos. Cross-functional OKRs ensure that teams collaborate and break down walls. They push for a unity that’s essential for the larger vision and ensure that the organization’s various parts move cohesively.

If the woodwind section ignored the strings, the result would be disjointed. Collaboration across all teams is essential for a full, rich sound.

No Alignment During Planning

If all musicians only knew the finale, like reaching a C#, and then individually navigating there. Then set off to work towards that end note in whatever tempo and rhythm pattern they felt like. The performance would be erratic. Similarly, alignment discussions during the planning phase are crucial to ensure everyone is on the same page.

Too Late Alignment

What if alignment occurred mid-performance? Each section would be on its own journey, but to reach that climactic crescendo, they’d need to synchronize both in tempo and their position within the piece. Alignment should be foundational, not an afterthought.

The OKRs are Cascading

Envision a symphony dwindling from a full ensemble to solo drums. The music loses its essence. Similarly, in OKRs, the cascading model, where objectives trickle down layer by layer, risks distorting the primary goal. Instead, OKRs should be co-crafted, engaging every tier from the beginning.

Time to fine-tune your OKRs

In essence, the value of OKRs, much like a symphony, lies in alignment, cooperation, and clarity. They are the guiding script for an organizational magnum opus. If your organizational tune feels amiss, perhaps it’s time to fine-tune your OKRs.

Nr 1: Flexibility

Work at your own pace, according to your own schedule with no need to co-locate to be able to collaborate.

Nr 2: Deep Thinking

Without the pressure of “thinking on the spot” in meetings, you are able to think deeply and develop creative solutions.

Nr 3: Record-Keeping

Ideas, feedback and solution are documented in one single document

How to make problem solving asynchronous

1. Create a document in a tool that makes commenting easy.

A tool such as:

• Google Docs
• Microsoft 360
• Notion
• Dropbox Paper

2. Write four headlines.

• What is the problem?
• Why is that a problem?
• What are possible solutions?
• Which solution do I recommend at the moment?

Answer the questions above alone or with another person.

Share the document, ask for comments and set a deadline.

Done!

Running a successful retrospective in these situations can be somewhat challenging, especially if you want the team to continue being a team at the end of it.

Here are some important elements on how to run a retrospective that will not end in disaster.

Check your heads and reset your thoughts

Whether you have your retro in the morning, in the afternoon or late in the evening, people need to reset their heads to the retrospective. Maybe they’ve had a crazy commute, had to wait for lunch for 30 minutes and then wolfed it within 5 minutes.

Asking icebreaker question is an easy way fast way of resetting your mind. Some dislike them and think the icebreakers are a waste of time, even then, the moment they start to think about “how silly the icebreaker are”… that’s when it has done its magic. It made them focus their thoughts on something else.

Safe from harm

Make the retro a safe place for improvement by stating that we believe and trust that everyone did the best they could with the information and knowledge they had at the time.

Every now and then I state the The Prime Directive written by Norm Kerth in his book Project Retrospectives: A Handbook for Team Reviews.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Start with the positives alone

This is one most important part of this retrospective. It is super easy to go into all things negative about a disastrous project, but by focusing on good and great achievements as a separate part of the retrospective we will have a record of what we experienced or learnt that felt important to the team.

Run an exercise writing stickies on the topic of everything good about the project.

Before we get going with the nitty gritty of the project we need to remind ourself of everything that was really good with the project, so that we do not forget it.

Let each member walk through their positive learnings from the project.

Group the stickies and ask the group to reflect on them and ask if there is anything that we need to add, again “so we don’t forget about it”.

The improvements and the purely bad

With some positivity towards the project you can now run a usual retro, such as “The Good, The Bad, The Ugly”, “Liked, Learned, Lacked, Longed For” or “Keep, Add, More, Less”. But remember that there is no need to run “The positives” from those retros, since you’ve already asked for them.

Similar to the previous, let each member walk through their notes. Group and reflect. Are there any action points to bring forward to the next sprint or project?

End with the positives

Now you hopefully have a whiteboard full of notes. Positive learnings, bad experiences we don’t want again and things we can improve.

Summarize and end the session by stating: This was a challenging sprint/project, we are pretty awesome that pulled through it. Re-iterate the action points on what we can do to get better, and focus a bit on all the things we’ve that was good and great at the end.

As the company grows, the need for more clarified positions comes apparent. Someone that used to be Product Manager, Team Lead and Engineer now needs to focus fully on where they make most value and this opens up for others to fill their shoes with any of their other roles.

Filling the shoes of a previous multitasker can become quite tricky, since the people who depend on you could hold you responsible for many of the responsibilities the previous person had.

Enter the Roles and Responsibilities workshop to clarify this.

I’ve run a couple of different session’s of this workshop and it depends a bit on the attendees current roles. With plenty of people and many roles you try to dissociate the person from the role to identify the things they do, that probably needs to get done, but might not part of their role. With plenty of people with the same role you focus on what some people do in their role that others don’t.

Both of them is to clarify what is expected within your role and to clarify what else you do that is not part of it.

“Plenty of people and many roles to clarify”-session

1. Add all names to a board.

Fairly simple, no explanation needed.

2. Take 10 minutes and write up everything that you feel you are responsible for

A lot of stress comes from uncertain responsibilities, things you think you are accountable to do but possibly don’t have a mandate to do.

3. Take 10 minutes to write up responsibilities that you think the others have.

Now it’s time for the other members to give their point of view of what is missing or needs highlighting.

4. Switch the names to the job title that person has

The twist comes when you dissociate the person with their role.

5. That should not be part of your role!

With the roles, instead of names, on top of the column the team goes through all notes and identify the odd responsibilities. Should they be part of that role? Should someone else do it?

Closing the session you identify next steps. How do you follow through on the changes in responsibility?

“Plenty of people with the same role”-session

1. Add all names to a board

Yup, just do it.

2. Take 10 minutes and write up everything that you feel you are responsible for

A lot of stress comes from uncertain responsibilities. Things that you feel that you are responsible for but possibly not have a mandate to do.

3. Switch the names of the columns

Similar to plenty of people and many roles session there is a twist! Instead of changing the name to role, you change columns between you all.

4. That’s not part of my role!

Look at your new column. Do you think all of these tickets should be your responsibility? Or they part of something else that the previous owner has responsibility over.

Closing the session you identify next steps. How do you follow through on the changes in responsibility?

“With awareness come responsibility and choice” Amanda Lindhout

By being aware of what others think you are responsible for and setting the right expectations when you are not responsible, will make your life much easier.

And remember, that stuff still needs to get done and even though tasks might not be part of your role it still might be part of your job.

With any project or initiatives more often than not you need to prioritize tasks, cause . With time not on our side, you need a simple way of figuring out what to focus on and what to skip.

Two popular matrices that are widely used are Eisenhower Matrix and Impact/Effort Matrix. With both of them you simplify and condense all data you have on a task and plot them based upon two criteria.

The Eisenhower Matrix

It is easy to focus on urgent tasks and never get to work on the important tasks. Focusing on putting out the fire rather than figuring out what is feeding the fire, is a sure way of continuing in fire fighting mode.

U.S. President Dwight D. Eisenhower realized that we need to spend time on important tasks and not only urgent task, that urgency alone is not the only factor on how important a task is.

Thus the two criteria are Urgency and Importance.

Just Do It!

Tasks with high importance and urgency are easy to prioritize. Just Do It!

Decide When

These are slightly more tricky. Since they are super important, but not that urgent, we tend to forget about them. These tasks need to be scheduled or they might end up in Just Do It!

Delegate

You should try to delegate the urgent but not important tasks or better yet, find a way to automate them.

Try to Skip It

Time wasters, ineffective meetings with no agendas, reports to fill out. Can it be removed, remove it, skip it, kill it!

Impact Effort Matrix

There are some similarities to Eisenhower Matrix, but the focus on Impact/Effort matrix is pretty clear from the naming. Effort is a sense of how much time a task takes or how complex it will be to solve. With Impact we try to measure the importance of the outcome.

Quick Wins!

These low effort and high impact tasks are your low hanging fruits. Pick them quickly!

Fill Ins!

Things to fill out your week. Takes a little time and have some minor impact.

Major Projects

These tasks are probably not tasks. You’ll never get them done without planning and scheduling. Don’t do too many of these at the same time since they need a lot of focus.

Not Worth It!

Stop it immediately. Do nothing in this area.

“Don’t spend major time on minor things” — Jim Rohn

Now take out your physical or digital sticky notes, write down your tasks. Put them on the matrix that suits your need. Then let the discussions begin, cause maybe a task that you think is a Quick Win is a Major Project for someone else.

A good strategy does more than urge us forward toward a goal or vision; it honestly acknowledges the challenges we face and provides an approach to overcoming them.- Richard Rumelt

Richard Rumelt writes that a good strategy has a kernel that contains three important elements: a diagnosis that condense and explain a difficult challenge, a guiding policy on which approach you’ll take and constraints you have while trying to overcome the challenge and lastly a set of coordinated coherent actions which together will solve the challenge.

This sounds awfully similar to the Objective and Key Results (OKRs) popularized by the likes of Google at the end of the last century.

The briefest history of OKRs.

OKRs is a very popular framework for setting goals on different levels of a company. It sprung out of Peter Drucker’s “Manage by Objectives” coined in the 1950s and later improved by Andrew Growe over at Intel in the 1960s.

An inspiring Objective

Objectives are a description of how we see the future. A quote that is inspiring, sets a direction that is qualitative and hard to achieve.

• Where do we need to go?
• Why do we need to go there?
• What kind of constraints do we have?
  Similar to Richard Rumelt diagnosis and guiding policy, the Objective deals with declaring and clarifying the challenge.

The constrains of Key Results

Key Results are how we measure results and progress towards achieving an Objective.

Key Results are like latitudes and logitudes in the background of Google Maps. Informing us when we’ve made wrong turns, if we’re progressing as expected and when we’ve arrived at our destination.

If you write your important KRs before you dig deep into initiatives or actions will also help you from jumping to conclusions on how to solve the problem. What if there are multiple ways of getting to the goal? What if you actually arrived at your destination faster by taking another path?

While some part of the Objective states the guiding policy for your strategy, the Key Results are equally important as constraints.

Initiatives and coherent actions

Initiatives are the OKRs way of clarifying coherent actions i.e. What kind of work do we need to do to get us there?

OKRs and Good Strategy

Good strategy gives us clarity and acknowledges the biggest challenges we have a company. OKRs is one great way to clarify and work with that strategy.

OKRs is a bridge between a Good Strategy and Execution.

Each of the letters propel you into the next one. Intent gets you half way to what you actually want as an outcome. With that expected outcome you can start planning an agenda, where you start with the end goal in sight.

Intention

What do we intend with the meeting? Why even have it?

Desired Outcome

What specific results do we want to have achieved at the end of this meeting?

Agenda

What will we do at the meeting and in what order to achieve the expected results.

Sometimes this is enough for a great meeting. It takes a couple of minutes to write, but it highly improves the meeting. When I facilitate longer sessions I add the last three letters of the acronym.

Roles

What roles and responsibilities are there for the meeting to run smoothly? Who facilitates, participates, documents? What is expected of the participants.

Rules

What kind of rules do we have in this meeting?

Should we practice active listening and not just wait for the moment to state your point?

Should we use some way of indicating who talks and how to hand over the mic to someone else, especially valid when doing a hybrid meeting with people both remote and on-site.

Should computers or mobiles be used when we run a meeting where everyone is in the same room?

Law of two-feet i.e. Leave if you don’t contribute?

How do we take minutes and where are they stored?

Let the participants come up with other rules that they want to include.

Time

How long is the meeting, will there be breaks?

Read slightly more over at https://toolbox.hyperisland.com/idoarrt-meeting-design

While it is easy to believe that processes could solve communication and vision challenges, this is seldom the case.

Hey there! You are not following the process!

Sure, we could always point at the process and say “Hey there! You are not following the process!“ And hope that your colleagues changes behavior, but that usually has no long lasting effects, especially when there is a believe that “what got us here, will take us there”.

There is a reason a company succeeds and grows, and it is probably credited with founders’ core values. Customer-centric, adaptability, collaboration, deep technical skills, “we can do it”-mentality to name just a few.

When these rather informal values go through the transformation to become documented processes a lot of agility and flexibility are lost on the way.

Photo by Mark Duffel on Unsplash

Rules and processes have a tendency to be absolute and we need a different way to move forward with our vision and at the same time have the opportunity to steer away from it temporarily when needed.

Similar to how the agile manifesto has values that captures both sides of an argument and favors one, so could a company capture its guidelines.

That is, while there is value in the items on the right, we value the items on the left more. - Agile Manifesto

Instead of writing a process around “Choice A versus Choice B” write guidelines with focus of picking one over the other, “Choice A over Choice B”. Making it easier transparent when we sidestep, but that is ok. Also making it easier to move forward on the vision.

Some examples of guidelines:

• Money over Glory
• Support existing customers over acquiring new customers
• Subscription over One-Time Payment
• Improve existing products over Building new products
• MVP over Big Bang
• Collaboration over Silos
• Team players over Rock stars
• Done over Perfect

Similar to the agile manifesto, while there is value in the items on the right, we value the items on the left more.

While there is value in formal processes, I value the agility in guidelines more.

As a leader, you want to head it off at the pass and proactively say, ‘Hey, this is what you can expect to feel during this time of growth. It’s pretty universal‘. - Molly Graham

Rapid growth could mean that your employees are challenged by changes in roles or responsibilities. Certain parts of their work or responsibility, where they have done an excellent job, no longer belong to them. By focusing on the vision and the future and help the picturing it, it eases the transition.

One of the best techniques for getting people through job-change anxiety is to help them picture the reality of their next job and the size of the opportunity. - Molly Graham

Graham also sees patterns when companies grow beyond a certain amount of employees.

We used to be a family, now we’re a company!?

Around 30 to 50 employees you go from being a family where everyone knows each other and can strike up a conversation at any time. Communication is easy and direct. At 50 employees you’ve reached the level where you are a real company, not just a small team.

Everything that used to come naturally is now a struggle. - Molly Graham

While it is easy to focus on defining complex processes to overcome the need for a clearer way of working, you should focus on the principles and guidelines you wish to follow.

We can still change the vision and mission with ease

From 50 to 250 it is still easy to get your message across the company and to change the trajectory of the company. Beyond 250 employees it mostly depends on what you did well before.

A lot of how this phase feels has to do with how good of a ‘parent’ you were earlier on. - Molly Graham

In summary

How we hire and look after the first 100 employees will have an impact and set the tone for the next 200. Be good early on, establish guidelines rather than processes. Be transparent and open about growing pains.

Psychological safety is a belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns or mistakes. - Amy Edmondson

I found this great TedX talk by Professor Amy Edmondson that coined the term back in 1999.

My main takeaways on building psychological safety are:

1. Frame the work as a learning problem, not an execution problem. We have never been in this situation before, or for long, and we need everyone’s brains and voices in the game.
2. Acknowledge your own fallibility. Say simple things like “I might miss something, I need to hear from you…“.
3. Model curiosity. Ask a lot of questions.