Category: Software

Vibe Coding

~ Veselin ~ 6 Comments

I’ve been experimenting with AI-first coding over the last months. Instead of the usual loop of:

  • Understand the problem
  • Make a change
  • Test it
  • Repeat until ready
  • Create a PR

The workflow becomes something more like:

  • Explain part of the change to the AI
  • Test if it works
  • Review the result
  • Feed back corrections
  • Repeat until ready
  • Create a PR

So far, I’ve found it great for making quick changes quickly. But when it comes to harder tasks, it gets difficult. Progress tends to come either by giving the AI very specific instructions, one tiny step at a time—or by iterating endlessly, like a sculptor chipping away at a boulder and ending up with a smaller boulder.

Still, it feels more productive than traditional coding in many cases, and it feels like the future. But there are real trade-offs, especially when the code is complex or the required change is significant.

I don’t have answers yet. For now, here’s a photo of a waterfall.

EDIT:

My colleague Nico also wrote an article about Vibe Coding, check his blog out!

Agent First Name

~ Veselin ~ 4 Comments

I got a promotional mail from Facebook by Agent First Name. I wonder if that’s a bad parenting decision, an engineering joke, or a bug.

I think it was just a glitch in The Matrix.

Agent First Name is not to be confused with his older sibling, Agent Full Name.

Think Wrong, Move Fast and Break Things

~ Veselin ~ 6 Comments

I’m currently reading Careless People by Sarah Wynn-Williams. I’m less than halfway through, but it already feels like this book deserves more than one post. So far, it doesn’t paint Mark Zuckerberg and Sheryl Sandberg as supervillains, and I’m getting a glimpse into Facebook’s early culture.

One of the big ideas from Facebook’s early years was Move Fast and Break Things. This mantra has been both confirmed working and disproved many times – often by engineers like me, who’ve lived through its successes and catastrophic failures. .

Moving Fast and Breaking Things Works

It works because the software industry can be like a gator-infested pool. When a new idea drops like a piece of meat in the pool, everyone jumps on it. The biggest reward goes to the fastest gator that ships first and markets well. There’s often no time to make things well.

Facebook won the social network race in large parts of the world. Twitter and a few others got the leftovers. But this principle applies beyond tech giants – down to much smaller scales. It’s a form of the Pareto principle: 80% of the outcomes stem from 20% of the causes. If you can roughly identify the 20% and validate an idea quickly, you’ve already won even if it doesn’t work. You saved the effort for something that may work.

On an individual level, it also feels like it works. You get a task, you ship something quickly – it shows up in your weekly update, your team’s update, maybe even the leadership sees it. You’re productive, visible, and valuable.

But It Also Doesn’t Work

Once an idea is validated, it gains users, traction, and revenue. A bug that shows up once in 1000 runs might never happen with 10 users/day. Once you have a million users, it happens 1000 times a day. Also, one broken user profile may be easily fixable but a million? Not so much.

Zuckerberg himself cited this kind of thinking when Facebook moved away from the motto around 2014. You can’t keep patching the same issues over and over at scale. Stability becomes a requirement.

From an individual contributor point of view, it looks that profitable ideas attract many layers of heavily invested people – technical, marketing, finance, data, legal, executive, investors. And when something breaks, you’re not just dealing with bugs. You’re affecting dashboards, KPIs, morale, and your own job security. Blame becomes easier to assign. 10 of these people will know how things work and won’t blame you but the eleventh may have a bad day and push the button.

How to make a difference?

In early-stage product development or during moments of intense change, moving fast and breaking things can be the right move. But in mature projects, where uptime matters and stakeholders are many, the priority shifts. It’s more about stability, reliability, and trust.

Ultimately, Mark Zuckerberg hung that motto on Facebook’s wall – and eventually took it down. He may put it back up if he recognizes a need for it. Recognizing the moment is a key part of leadership.

How many days are left to earn from Revolut?

~ Veselin ~ 3 Comments

I keep getting emails that I have 7 days left to earn from referring my friends to use Revolut. Is it really 7?

So, they appear to have a recurring campaign that invites people to their referral program every 21 days, then a reminder email on day 12 that 7 days are left. Then the amount changes (or doesn’t) and I get a new email.

The amounts vary between 50 and 200 BGN (25 to 100 Euro) with the 50 being the default, 80-90 offered when the bot felt happy, and 200 – about once or twice per year. I couldn’t find any seasonality.

These emails go back to 2022 when I probably signed up for Revolut. I’ve not yet tried the service because it wanted too much private data so I don’t know if it’s good or bad. I just admire how they never considered me an inactive user despite not having the app.

This email title only appeared once. Fellow MarTech folks on Revolut probably recognized it as something that doesn’t sit quite right.

The Power of Old GitHub Issues

~ Veselin ~ 1 Comment

I’m starting believe that a rule exists such that if you file an issue on GitHub, the older it is, the more weight it has and the probability it’s taken seriously increases. As it gets older, the issue either gets randomly closed, or becomes like a space-twisting gravity well.

Let’s imagine a task like visiting the dentist. The more I postpone it, the more I’ll want to do it now as it reaches a nerve and hurts. Something like that happens with issues as well. When a bug report (or a request) is submitted, it starts living its own life, and the clock of decay starts ticking.

  • The problem will be noticed by others and they’ll refer to it (due to the Single Cockroach Rule)
  • Embarrassment may start building up. Why is this still hanging?
  • Familiarity happens. People checking the list of open issues will read that one and postpone it many times, turning it to an old friend.

So even mildly unreasonable issues may eventually get done by the gravity of their own age.