The idea is almost embarrassingly simple: you click your country flag, your flag climbs up the pole, and you try to overtake everyone else. That’s the whole game.

I keep getting drawn to these tiny internet toys. Not the serious kind of game where you need a tutorial, a season pass, and three currencies before you are allowed to have fun. I mean the stupid little thing that makes sense immediately. You open it, you understand it, and before your brain has time to ask why, you are already clicking.

Flag Click grew out of Flag Match, my flag matching game. Flag Match at least has the noble excuse of being educational. You can tell yourself you are learning geography. Flag Click does not have that excuse. It is the less responsible cousin. You click a flag because you want your flag to be higher than the other flags.

That sounds silly, but that is exactly why flags work so well here. A flag is not just a random image on a button. People instantly recognize it. It carries just enough identity to make the number feel personal, but not enough gravity to turn the thing into something serious. It stays in that nice internet zone where everyone knows it does not matter, but it still kind of does.

The first version was not a flagpole. It was a big field of flags where the winning countries slowly took over the screen. In my head, this was clearly the right mechanic. On the screen, it was ugly. Flags got squished, the layout looked noisy, and the whole thing had no drama. It was technically doing what I asked it to do, which is often the worst kind of failure because the idea itself is the problem.

The flagpole fixed it.

Once countries started climbing instead of occupying space, the game suddenly made sense. The screen had a direction. Being #1 meant being at the top. Smaller countries could sit lower on the pole. On mobile, it also felt much more natural because the entire game became vertical, which is where your thumb already lives.

Most of the work after that was not about adding more features. It was about making the click feel right. The flag had to wave. The score had to react quickly. Overtaking another country needed a little bit of theatre. The sound could not be annoying after five seconds. Mobile tapping had to feel good because this is absolutely a phone game first.

That kind of polish sounds optional until you build something this small. Then you realize the polish is the product. If the button feels bad, there is no game left to hide behind.

I also had to think about fake scores, because of course I did. Any public clicker invites people to mess with it. That is part of the genre. I do not think you can make this kind of thing perfectly cheat-proof, and I do not want to turn a silly flag game into airport security. The goal is simpler: make casual cheating boring enough that normal players do not feel like the board is immediately ruined.

I have no idea if Flag Click will go anywhere. Maybe it gets shared, maybe it doesn’t. Maybe one country wakes up and turns the leaderboard into a national emergency for twelve minutes. Maybe nobody cares. All outcomes are acceptable.

What I like is that it exists. It is small, weird, and self-contained. It made me care about sounds, animation, phone taps, flags, and one very opinionated pole. That is enough for me.

Go click your flag: flagclick.com.

The convenience is ridiculous.

You describe what you want, and it produces working code. You paste a stack trace, and it explains the bug and offers a fix. You ask it to add a feature, and it updates the relevant files, writes tests, and sometimes even suggests the migration. What used to take an hour of focused work can now take ten minutes of prompting and reviewing.

This speed is genuinely useful. I am not going to pretend otherwise. But it also makes it dangerously easy to stop doing the real work yourself.

The muscle that actually makes you a programmer is not typing code. It is the ability to hold a mental model of a system, reason about trade-offs, spot the smell in an abstraction before it spreads, and debug by thinking instead of throwing prompts at the wall.

That muscle needs exercise.

With AI, many problems get solved before you ever have to think hard about them. The friction disappears, and with it goes some of the growth. You still ship the change, but you may not have learned much. You still get the green tests, but you may not understand why the solution is shaped the way it is.

At the same time, the power on the other side is absurd. These tools are no longer just autocomplete. They can act as agents: explore a codebase, make coordinated changes across files, run commands, observe results, and iterate. It is like having a tireless pair of hands that can execute at a speed no human can match.

The leverage is real. Used well, it lets a single developer ship things that previously required a small team.

The problem is the gap between those two realities. The tools reward you for staying in the loop of prompting and accepting. They do not punish you for slowly losing the ability to work without them. You can produce more output while your underlying capability quietly erodes. You become very good at directing an artificial programmer instead of remaining a real one yourself.

I have written before that AI amplifies programmers rather than replacing them. I still believe that. But amplification only works if there is still something strong on the receiving end. If the human side atrophies, you do not get 10× output. You get 10× of whatever shallow thinking you brought to the prompt.

I also still believe that you should learn to code, ignore AI, then use AI to code even better. Maybe even more now.

The practical question is not whether to use these tools. You would be foolish not to. The question is whether you are still doing enough deliberate, unaided work to keep your own reasoning sharp.

Sometimes that means closing the AI tab and wrestling with the problem the old way first. Sometimes it means using the model only after you have already formed your own approach. Sometimes it means reading the generated code line by line instead of accepting the diff because the tests passed.

The tools are too good to ignore, but they are also too good at letting you coast.

The programmers who will matter in the next few years are not the ones who prompt the best. They are the ones who stay sharp enough to know what to prompt for, when to use the output, and when the output is wrong.

Everything else is just faster typing.

Somewhere along the way, software customization became a hobby of its own. This reflects the same pattern behind why developers love complexity.

But the longer I write software, the more I appreciate defaults.

The default path is where every user begins. It is the most exercised, most documented, and most battle-tested part of the product. Thousands or millions of people have already walked that road before you. Bugs are discovered there first. Edge cases are encountered there first. Performance issues become visible there first. When something breaks, the maintainers notice because everyone is using it.

Defaults are not arbitrary. They are usually the result of years of accumulated experience and hard-won trade-offs between performance, maintainability, usability, and predictability. When Rails ships with a certain project structure, or SQLite enables certain behaviors by default, or a browser decides how something should work out of the box, there is often more practical reasoning behind those choices than most developers assume.

The customized path, by contrast, is lonely.

The more you diverge from the defaults, the more you become responsible for your own ecosystem. Documentation becomes less relevant because your environment no longer matches what everyone else is using. Tutorials stop applying cleanly. Upgrades become riskier. You start carrying a collection of tweaks whose original purpose you no longer remember.

I know this because I used to do exactly that. I spent countless hours configuring editors, terminals, Linux desktops, tiling window managers, browser setups, and JavaScript toolchains in pursuit of some ideal workflow that never actually arrived. At some point, the setup itself quietly became the project. I was investing more energy into perfecting the environment than using it to build things.

Meanwhile, the person using the defaults quietly ships their work.

This is not an argument against customization entirely. Sometimes defaults genuinely do not fit your needs. Some workloads require tuning. Some preferences matter. But customization should come from real friction encountered over time, not from the assumption that the default experience must be inferior simply because it is common.

There is also a psychological trap here. Developers often associate customization with expertise. Using the default setup can feel unsophisticated, as if you are leaving performance or productivity on the table. But many experienced engineers eventually arrive at the opposite conclusion: simplicity has value, and every deviation from the standard path carries a maintenance cost.

A good default reduces cognitive load. It lets you focus on the actual work instead of endlessly shaping the environment around the work.

This becomes more obvious as software matures. Modern tools are significantly better than they used to be. Browsers work well without extensions. Rails defaults are remarkably solid. SQLite handles workloads that people once considered impossible for it. Even operating systems have become harder to misconfigure catastrophically.

The industry has slowly learned that good defaults are a feature.

In many cases, the default path is not merely the easiest option. It is the option refined through the largest amount of real-world usage. That matters. Software behaves differently under millions of users than it does in theory.

So these days, I try to resist the instinct to immediately optimize and customize everything. I start with the defaults and stay there until something repeatedly becomes a real problem. Most of the time, that moment never comes.

And when it does, I at least understand exactly why I am changing something.

The screen is black. The cursor blinks — steady and patient. You lean in and begin to type, your fingers moving with intention across the keys. A few simple words appear: ls, cd, mkdir, grep.

Then comes the moment of anticipation — that brief pause before you press Enter.

And when you do, the terminal answers.

Results appear line by line, precise and immediate. There is something deeply satisfying about the exchange: you speak in commands, and the machine responds with clarity.

This is the beauty of the terminal: its power lies in simplicity. A few letters typed on a black screen can search vast amounts of data, launch processes, and reshape entire systems.

Here, you are not a passive user. You are the one who speaks — and the machine listens. Every time you type a command in the terminal, you feel it: the ancient, elegant magic of turning thought into action with nothing but words.

It will confidently help you build a ladder… even if it’s leaning against the wrong wall.

The problem

AI keeps moving forward, even when the direction is off. It supports your line of thinking, refines it, and adds detail, but rarely stops to say:

“Now that the requirements are clearer, we should reassess.”

Instead, it continues optimizing the current path — whether or not it still makes sense.

Why this happens (factually)

• Objective mismatch: AI is optimized to be helpful and responsive, not to interrupt or challenge direction.
• Weak global reasoning: It doesn’t reliably maintain a high-level model of changing requirements unless prompted.
• User intent bias: It assumes your framing is correct and works within it.
• Reactive nature: It responds to input, but it doesn’t proactively step back or redirect.

The result

If your initial framing is off, the AI will often:

• Refine the wrong solution
• Add convincing detail to a flawed approach
• Stay anchored to outdated assumptions

Even if you ask it to “reassess”, it may still operate within the same flawed frame.

What would be better

A more useful system would:

• Notice when the problem definition has shifted
• Pause and reframe
• Challenge assumptions
• Suggest stepping back before continuing

Practical takeaway

AI is excellent at accelerating execution.

But it won’t reliably tell you if you’re solving the wrong problem. You still have to move the ladder to the right wall.

While building a mostly text-based UI for Telesink, something became obvious: icons make things look polished, but they rarely make things clearer.

We tend to treat icons as essential. In reality, they’re situational.

They help when:

• 👍 Multilingual products: not everyone speaks the same language, icons provide rough affordances
• 👍 Space-constrained UIs: when labels don’t fit (mobile, dense tables)
• 👍 Repeated actions: once learned, icons are faster to scan
• 👍 Visual grouping: they help chunk related actions
• 👍 Status & feedback: success, warning, loading are instantly recognizable

But most of the time, they’re not necessary:

• 👎 They have to be learned (many aren’t universal)
• 👎 They’re ambiguous without labels
• 👎 They slow down new users
• 👎 They add visual noise without adding meaning
• 👎 They increase design and consistency overhead
• 👎 Text is more accessible (screen readers, clarity, localization control)

So for Telesink, I chose a mostly text-only interface. Not as a stylistic choice, but a practical one:

• ✅ clearer actions
• ✅ less guesswork
• ✅ faster onboarding
• ✅ simpler to build and maintain

My rule of thumb

Whenever I’m deciding whether to use an icon or text, I now run it through two simple questions:

• Would a first-time user understand this instantly?
• Does the icon truly add clarity, or is it mostly decoration?

If it doesn’t pass both tests with a clear “yes”, I default to text.

This mental filter has dramatically reduced visual clutter and forced me to focus on actual communication rather than aesthetic habit.

Less decoration, more communication.

2026 is going to be the best year for me since I embarked on an indie dev journey. I’ll keep building Telebugs, which has become quite mature by now. I’m not done with it (there are still a few big epics ahead), but overall, the product is rock solid.

The thing I’m most excited about, though, is a little announcement… Since I’m back to open source, I want to make 2026 the year of open source.

Announcement

Announcing Telesink! Telesink will be an open-source, real-time event tracking tool that acts as an informational heartbeat for your business, so you can see what’s happening right now.

You’ll be able to hook up your projects and watch live events like:

• “People are signing up”
• “Payments are flowing”
• “MRR is ticking up”
• “New trials are starting”
• “Users are completing onboarding”
• “Form submissions are coming in”
• “Subscribers are renewing”
• …and many more.

Unlike analytical tools that dig into historical data or developer metrics, Telesink is simple and real-time-first. It’s built for everyone, a straightforward, all-around dashboard for seeing things happen as they happen.

It’s a cleaner replacement for those read-only bots in Slack, Discord, or Telegram that handle this kind of monitoring as an afterthought.

I’ve been thinking about this for months, and it grew directly out of my own need to better understand what’s happening in my projects (beyond just errors).

It’ll be open source and free to self-host, with a paid SaaS offering to sustain development.

Right now I have nothing but the idea in my head (it’s been simmering there for months). I don’t have all the answers or solutions yet, and honestly it’s scary because there are a lot of unknowns, but I’m ready to start.

I’ll be building this in public. Follow along! I’m looking forward to having you with me.

I saw it online and immediately knew it was my kind of jam:

• low memory footprint
• runs on SQLite
• simple to use and maintain
• lightweight tracking script

It’s designed to be self-hosted, and I love simple self-hosted products (I develop them myself).

I come from the Ruby ecosystem and prefer deploying with Kamal. Its configuration file looks almost identical to docker-compose.yml, which Bearlytics already ships with, so using Kamal felt like a natural fit.

Requirements

Hardware

Bearlytics will run on virtually any VPS or hardware. My running container, with no traffic, consumes only 56 MiB of RAM. Impressive!

CONTAINER ID   NAME                                                            CPU %     MEM USAGE / LIMIT    MEM %     NET I/O           BLOCK I/O         PIDS
0db0cbf3fba1   bearlytics-web-9a7059c5bfe6d403d8bf2de40eaf845956ce69ea         0.02%     55.87MiB / 7.57GiB   0.72%     269kB / 582kB     147kB / 13.8MB    3

Go to Hetzner Cloud and grab the cheapest plan (you’ll be totally fine).

Subdomain

To self-host Bearlytics, you’ll need a subdomain, for example analytics.example.com.

On Cloudflare, create an A record pointing to your server’s IP address. This will allow you to access Bearlytics at https://analytics.example.com.

Step-by-step guide

To understand what we’ll be doing, let’s take a look at the docker-compose.yaml file from the repository and translate it into a Kamal configuration.

Bearlytics has no external dependencies: it’s a single container. All we need to do is set a few environment variables and we’re good to go.

Step 1: Clone the Bearlytics repo

Start by cloning the repository:

git clone --single-branch https://github.com/HermanMartinus/bearlytics bearlytics
cd bearlytics

Step 2: Branch out

We don’t want to accidentally push these changes upstream. We’ll be working with our own configuration values, and it’s unlikely the Bearlytics author would want this opinionated setup merged.

Create a new Git branch:

git checkout --b kamal

Step 3: Generate Kamal configuration:

Install Kamal if you don’t already have it (via RubyGems):

gem install kamal

Then generate the Kamal configuration:

kamal init

You should see output similar to this:

Created configuration file in config/deploy.yml
Created .kamal/secrets file
Created sample hooks in .kamal/hooks

We won’t need hooks, so delete that directory:

rm -rf .kamal/hooks

Step 4: Update .gitignore

Next, add the generated files to .gitignore so we don’t accidentally leak secrets:

# .gitignore
!.kamal
!.kamal/secrets
!.config
!config/deploy.yml

Step 5: Setting up Kamal secrets

Bearlytics requires several mandatory environment variables:

• SECRET_KEY: Django secret key
• SALT_SECRET: Secret key used to hash PII
• DEBUG: Set to False in production
• DB_PATH: SQLite database location (default: /app/db/db.sqlite3)
• ALLOWED_HOSTS: Comma-separated list of allowed hosts
• CSRF_TRUSTED_ORIGINS: Comma-separated list of trusted origins

We’ll define most of them in the config/secrets file generated by Kamal. It should look like this:

DEBUG=$DEBUG
SECRET_KEY=$SECRET_KEY
SALT_SECRET=$SALT_SECRET
DB_PATH=$DB_PATH
CSRF_TRUSTED_ORIGINS=$CSRF_TRUSTED_ORIGINS

Now we need to populate these values from the environment. I’ll use a .env file and the dotenv Ruby gem (gem install dotenv). Kamal also supports several other approaches, which are covered in the documentation.

1. Generate SECRET_KEY and SALT_SECRET using any password generator. openssl works great.
2. DB_PATH refers to the path inside the Bearlytics Docker container.
3. CSRF_TRUSTED_ORIGINS should point to your installation URL.

Here’s how .env will look like:

# .env at the bearlytics root directory
SECRET_KEY=$(openssl rand -base64 48)
SALT_SECRET=$(openssl rand -base64 48)
DB_PATH="/app/data/production.sqlite3"
CSRF_TRUSTED_ORIGINS="https://analytics.example.com"

That’s it for secrets. Now we just need to tell Kamal where and how to deploy the app.

Step 6: Update Kamal configuration

We’re almost there. Let’s update the Kamal configuration file. I’ll walk you through the important sections and then provide the full config at the end.

First, set the service name and image:

service: bearlytics
image: bearlytics

Next, define the servers. We’ll use a single server named web:

servers:
  web:
    - <your-server-ip>

Now configure kamal-proxy to enable SSL. We’ll use the subdomain created earlier.

Important: Bearlytics runs on port 8000, but kamal-proxy assumes port 3000 by default, so we need to override that.

proxy:
  ssl: true
  host: analytics.example.com
  app_port: 8000
  healthcheck:
    path: /script.js

We also define a health check that hits /script.js. By default, Kamal pings /up, which Bearlytics doesn’t implement. /script.js is guaranteed to exist because it’s the tracking script itself.

Next, we’ll build the image locally and use Kamal’s local registry feature so we don’t need to push anything to GHCR or Docker Hub:

registry:
  server: localhost:5555

Wire up the environment variables:

env:
  clear:
    DEBUG: false
  secret:
    - DB_PATH
    - SALT_SECRET
    - SECRET_KEY
    - CSRF_TRUSTED_ORIGINS

Now mount a volume for the database so we get persistence and can make backups if needed:

volumes:
  - "/root/bearlytics-storage:/app/data"

Create the directory on your VPS and adjust permissions:

mkdir /root/bearlytics-storage
chown -R 1000:1000 /root/bearlytics-storage

Finally, specify the build architecture:

builder:
  arch: amd64

Here’s the full configuration for convenience:

service: bearlytics
image: bearlytics

servers:
  web:
    - <your-server-ip>

proxy:
  ssl: true
  host: analytics.example.com
  app_port: 8000
  healthcheck:
    path: /script.js

registry:
  server: localhost:5555

env:
  clear:
    DEBUG: false
  secret:
    - DB_PATH
    - SALT_SECRET
    - SECRET_KEY
    - CSRF_TRUSTED_ORIGINS

volumes:
  - "/root/bearlytics-storage:/app/data"

builder:
  arch: amd64

To verify everything is wired correctly, run:

% kamal config

Wonderful! If everything looks good, commit your changes:

git add .
git commit -m "Add Kamal configuration"

Step 7: Deploy Bearlytics

I deployed Bearlytics on a server that was already provisioned with Kamal. If you’re using a fresh server, you’ll probably want to run kamal setup first.

In my case, the server was already running Kamal-managed containers, so I simply ran:

% dotenv kamal deploy

The deployment should take about a minute.

Once it’s done, visit https://analytics.example.com and you should see the Bearlytics sign-up page.

Congratulations, you’ve just self-hosted Bearlyrics with Kamal! I’m proud of you!

Christmas is special for all Rubyists thanks to the annual Ruby release, so I decided to tag along and join the Xmas party.

So here’s the announcement: WeUseRails.com goes open source! I launched it a year ago, and since then it has received over 150 submissions. It’s a free directory of Ruby on Rails web apps. Released under AGPL-3.0, it ensures that it’s truly open source.

This is my humble contribution to the ecosystem. Enjoy!

Natural languages evolved for persuasion, storytelling, negotiation, and survival in small tribes. They are optimized for social flexibility and rapid communication, not exact meaning. That is why they keep failing us when we try to use them as the primary interface for machines.

The language is full of hidden landmines: ambiguity, implied context, emotional framing, and undefined terms. Humans constantly misinterpret each other (even after thousands of years of practice).

The existence of lawyers is not an accident. It is evidence.

If natural language were precise, contracts would not need to be hundreds of pages long. Courts would not exist to interpret intent. Disputes would not hinge on what someone “meant”.

Now we take this same fuzzy medium and say: “Hey AI, do exactly what I mean”.

That is not engineering. That is wishful thinking.

Examples of the problem

• “Make it faster”.
  Faster how? CPU? Latency? Cost? Perception?

• “Use a lightweight solution”.
  Lightweight in memory? Dependencies? Code size?

• “Notify me when it is ready”.
  Ready by whose definition?

Humans fill these gaps with intuition and shared context.
Machines cannot reliably do that. And arguably should not be expected to.

Real-world consequences

2025 research drives the point home. Veracode analyzed code from over 100 LLMs and found that 45% of samples introduced OWASP Top 10 vulnerabilities (see 2025 GenAI Code Security Report). A Cloud Security Alliance study reported that 62% of AI-generated code contains design flaws or known security vulnerabilities (even with the latest models).

Prompts rarely specify security constraints, error handling, input validation, or performance bounds. The model guesses. And often guesses wrong.

To be fair, natural language prompting has been a breakthrough. It has democratized AI, enabling non-programmers to build complex applications quickly and opened up rapid prototyping in ways that traditional coding never could. Modern LLMs are remarkably good at resolving ambiguity using conversation history, context, and probabilistic reasoning. Often better than early skeptics predicted (see research).

Yet these successes are still papering over a fundamental mismatch. Prompt engineering helps, but it remains an imprecise art, not a science. When outputs go wrong, we still end up blaming the model for “misunderstanding” us. Rather than recognizing the root issue. We are asking it to read our minds in a language built for nuance, not specification.

Jacque Fresco, futurist and founder of the Venus Project, repeatedly argued that natural language is fundamentally inadequate for operating rational, technical systems. In his lecture “The Inadequacy of Language” (1975), he emphasized that words are ambiguous, emotionally charged, and dependent on personal interpretation. And that truly rational systems must rely on measurable, objective, and instrument-based forms of communication rather than symbolic abstraction.

Natural language is symbolic and expressive, not scientific. It describes impressions and intentions, not verifiable constraints.

Words like “optimize”, “secure”, “simple”, “important”, and “critical” feel meaningful. But they carry zero measurable content unless explicitly defined.

When we instruct AI in natural language, we are translating fuzziness into code and hoping it collapses into correctness.

Sometimes it does.
Often it does not.

The future is not just “better prompt engineering”.
It is better interfaces. Ones built on.

Explicit constraints instead of vague adjectives. Measurable objectives instead of implied intentions. Formal definitions instead of metaphors.

We are already seeing promising steps in this direction. Structured prompts using JSON schemas or YAML, formal specification tools like TLA+ or Alloy, visual programming environments, and agentic tools like Cursor or Replit Agent that let users define goals with clearer boundaries and iterative feedback loops.

Conclusion

Natural language can and should remain a conversational layer.

A high-level UI. A convenience for exploration and ideation.

But it should never be the source of truth for critical instructions.

You do not build a bridge using poetry.
You do not govern machines using vibes.

And expecting AI to reliably interpret natural language as precise code is like expecting a compiler to understand sarcasm.