Darwin Biler

Life Decisions is 3D, Not 2D

Sun, 21 Jun 2026 01:00:00 +0000

Growing up, we were mentally conditioned by movies, fairy tales, religion, and social pressure to always think in 2 dimensions:

Binary Opposites We Were Taught
Good vs Bad
God vs Evil
Beautiful vs Ugly
Rewards vs Punishment
Right vs Wrong

This binary framework is comforting. It reduces the terrifying complexity of the world into neat little boxes. You are either on the "right" side or the "wrong" side. The hero or the villain. The saint or the sinner.

But as you mature and learn the dynamics of society, you realize nothing is as simple as that. What one person considers wrong is perfectly acceptable to another. Here are just a few examples:

The Cracks in the Binary

Politics: "Don't support this cleanup program — it was implemented by the opposing party." The same action is framed as good or bad depending on who proposed it.
Religion: Alcohol is forbidden in some faiths but permitted in others. Divorce is a sin in one tradition and a mundane legal procedure in another. Each faith tradition draws its moral lines differently.
Law: Certain substances, behaviors, and contracts are legal in some countries but strictly forbidden in others. The same act crosses the legal line depending only on geography.
Social Norms: Peer pressure shifts what is considered "normal." Conformity is rewarded; deviation is punished — until the norm shifts.
Instinct: Avoid harm, protect kin, reproduce, have sex. These primal drives don't care about moral frameworks.
Personal Ethics: "This is not me" — a boundary drawn from within, independent of external rules.

Clearly, the decision-making landscape is not a flat line with two poles. It is a multi-layered space.

The 6 Layers of Decision-Making Forces

Instead of a binary choice, our decisions are shaped by six distinct layers of influence, stacked upon each other like geological strata:

Layer 1: Basic Instinct / Evolutionary Drives

Reciprocity, kin selection, and group survival. Rooted in evolutionary psychology. Humans have innate tendencies to help kin, expect reciprocal favors, avoid harm, and bond within groups. Examples: empathy, fairness instinct, revenge instinct, disgust response.

Layer 2: Social Norms / Cultural Practices

Customs, taboos, roles, and traditions. What is learned from peers and community as acceptable behavior — often unwritten rules. Examples: politeness norms, gender roles, hospitality, food-sharing rules.

Layer 3: Religion / Organized Faith Communities

Codified beliefs, traditions, rituals, and communal practices that define membership in a faith tradition. These are external systems maintained by institutions and communities. Examples: attending worship services, dietary rules, dress codes, sacraments or rituals, religious authority structures.

Layer 4: Spirituality / Personal Relationship with God

An individual's personal pursuit of the divine through conscience, prayer, reflection, or direct experience. It can reinforce, challenge, or exist independently of organized religion. Examples: feeling called to forgive despite social pressure, personal conviction developed through prayer, believing God asks something different from cultural expectations, mystical or transcendent experiences.

Layer 5: Legal and Institutional Rules

Formal laws, rights, contracts, and punishments. Created by societies to regulate behavior with clear consequences, often secular. Examples: human rights, criminal laws, property rights, anti-discrimination policies.

Layer 6: Personal Ethical Philosophy / Reflective Morality

Conscience, moral reasoning, and personal principles. Individually reasoned positions, influenced by but distinct from culture, religion, and law. Examples: utilitarianism, Kantian ethics, existentialist responsibility, self-authored moral code.

How Decisions Actually Work: The 3D Model

Whenever you are making a decision, you are not actually choosing between two options (right vs wrong). You are navigating using three dimensions:

Dimension	Question
Goal	What is it that you want?
Problem	What prevents you from doing it?
Solution	What is that thing that can solve that problem?

The decision space itself is three-dimensional (Goal, Problem, Solution), but movement through that space is constrained and influenced by six overlapping layers of instinct, culture, organized religion, personal spirituality, law, and personal ethics. As you determine the Solution, you drag yourself across these layers. Each layer exerts a push (toward obedience) and a pull (toward disobedience):

Force (Layer)	Pushes Toward Obedience	Pulls Toward Disobedience
Basic Instinct (L1)	Avoid harm, protect kin	Self-interest, group loyalty
Social Norm (L2)	Belonging, avoid shame	Rebel for individuality
Organized Religion (L3)	Tradition, community belonging	Hypocrisy, institutional distrust
Spirituality (L4)	Personal conviction, divine calling	Doubt, unanswered prayers
Law (L5)	Fear of punishment, duty	Low enforcement, unjust law
Personal Ethics (L6)	Inner peace, coherence	Pragmatism, situational flexibility

Your brain subconsciously weighs how heavy each push/pull is. The heaviest force — or the combination of forces tipping the scale — usually wins. And that is how you come up with what you think is the "right" decision.

The Kick: It's Different for Everyone

Here is the interesting part: Every person arrives at what they believe is the right decision as they go through these layers. But the Goal and the Problem are not the same for everyone.

Two people facing the same situation can experience completely different:

Goals — Because their desires, fears, and aspirations differ.
Problems — Because their circumstances, constraints, and capabilities differ.
Layer Weights — Because someone in organized religion weights Layer 3 more than a secular person. A spiritually devout person weights Layer 4 above institutional rules. A lawyer weights Layer 5 more than someone who distrusts institutions. A teenager might weight Layer 2 (social belonging) above all else.

This is why two reasonable, intelligent, well-meaning people can look at the same issue and reach opposite conclusions. They are not wrong. They are navigating a different 3D space with different coordinates.

The next time you catch yourself thinking in binary — "this is right, that is wrong" — pause. Ask yourself: what layers are at play? What is my goal? What is my problem? And more importantly, what layers might be at play for the person on the other side of the argument?

Every decision is the product of a goal, the obstacles standing in its way, and the solution we choose while navigating instincts, culture, religion, law, and personal ethics. Once you see that, life stops looking like a line between right and wrong and starts looking like a multidimensional landscape.

Agentic Coding From Any Device: opencode Server Behind Tailscale

Sun, 14 Jun 2026 00:00:00 +0000

The Problem

Every “AI coding” tool assumes you’re sitting in front of a powerful machine with an IDE installed.

But what if you’re:

On the couch with a tablet
At a coffee shop with a Chromebook
Commuting with only your phone
Traveling light without a laptop

The usual answer is: SSH in, use a terminal-based AI tool. That works — I’ve done it — but it still requires a terminal emulator app, and the experience is inherently text-only.

What if you could get the full agentic coding chat experience — the same one you’d get in VS Code or Claude’s web UI — inside any browser, on any device, without installing anything?

That’s what this setup does.

The Stack

Fedora Linux server (my home lab, behind double NAT)
opencode — a headless server that exposes an agentic coding chat via HTTP
DeepSeek as the LLM backend
Tailscale — encrypted WireGuard mesh VPN
Any browser on phone, tablet, laptop, whatever

The flow:

📱 Browser → Tailscale IP → opencode server → DeepSeek API → agentic coding

Why opencode Instead of SSH + Terminal AI

I wrote previously about using Continue.dev CLI over SSH via ConnectBot. That setup is still great for quick terminal queries. But opencode is a different paradigm:

Feature	SSH + Continue CLI	opencode Server
Client	ConnectBot / terminal	Any browser
Interface	Text-only terminal	Rich chat UI
Device support	Android only	Every device
File editing	Manual in terminal	Agent can edit files
Setup on client	Install app	Open a URL
Context length	Limited by scrollback	Full HTTP session

The browser interface means I can hand my phone to a non-technical colleague and say “just type what you need.”

Setting It Up

1. Install opencode

On your server:

curl -fsSL https://opencode.ai/install.sh | sh

Or grab the binary from the releases page.

2. Configure the server

opencode can run as an HTTP server. You configure it in ~/.config/opencode/opencode.json:

{
  "server": {
    "port": 8094,
    "host": "100.x.x.x"
  },
  "model": {
    "provider": "deepseek",
    "model": "deepseek-chat"
  }
}

The host should be your Tailscale IP so it only listens on the VPN interface — never on a public-facing port.

3. Start the server

opencode server

You’ll see:

opencode server running on http://100.x.x.x:8094

4. Access from any device

Open your browser and navigate to the Tailscale IP:

http://100.x.x.x:8094

That’s it. No install, no app, no SSH key setup on the client. You get the full agentic coding chat — the AI can read your codebase, edit files, run commands, and reason about your project.

Why Tailscale Is Critical

My home server is behind double NAT (ISP router + my own router). Traditional approaches would require:

Port forwarding (fragile, security risk)
A VPS relay (cost, latency)
Dynamic DNS + public exposure (dangerous)

Tailscale solves all of this:

Zero-config NAT traversal — devices meet in a WireGuard mesh
No open ports — the server initiates the outbound connection
Encrypted by default — end-to-end WireGuard encryption
Access controls — only devices in your tailnet can reach the server

The server binds to the Tailscale IP, so the service is never exposed to the public internet. It’s like having a private LAN that spans the globe.

Real-World Usage

I use this constantly. Here are the scenarios that make it worth it:

Quick fixes from my phone

A bug gets reported while I’m out. I open Chrome on my phone, type in the Tailscale URL, and tell opencode:

“Find the error handler in the auth module and add logging for the token expiry case”

It reads the code, makes the edit, and I’m done in 60 seconds.

Reviewing PRs on a tablet

I open the repo, ask opencode to summarize the diff, then ask follow-up questions about specific functions. No laptop needed.

Pair debugging with a colleague

I share my screen (or just send them the URL if they’re on my tailnet). They can see the AI reasoning in real time.

Coding from a Chromebook

Chromebooks are great for browsing but terrible for local development. This turns any Chromebook into a full agentic coding workstation — just open a tab.

Security

No public ports — opencode binds to the Tailscale interface only
No API keys on clients — the LLM API key lives on the server
No data leaves your tailnet — everything stays inside the WireGuard mesh
Tailscale ACLs — you can restrict which devices can reach the opencode port

If someone gets access to your Tailscale network, you have bigger problems — but even then, opencode’s server has no authentication built in, so I add a simple reverse proxy auth or just rely on Tailscale ACLs being strict.

What This Enables

This setup fundamentally changes where and when you can do serious coding work.

You’re no longer tied to a specific machine with a specific IDE. The AI and the codebase live together on the server, and every device becomes a thin client with full agentic capabilities.

The phone in your pocket is now a supercomputer for software engineering.

Not “run a terminal and type commands.” A full, interactive, agentic coding assistant — in a browser tab.

Final Thoughts

I’ve been through many iterations of this:

SSH + vim — works, but no AI
SSH + Continue CLI — great, but terminal-only
opencode server + Tailscale — browser-based agentic coding from anything

The third one is by far the most practical. It requires zero setup on the client, works on every device I own, and gives me the same agentic coding experience I’d get sitting at my desk — just from a browser tab on a phone.

If you have a Linux server and a Tailscale network, try it. You might find yourself reaching for your phone more often than you expect.

Run Remotion on a Remote Machine and Preview It Locally

Fri, 12 Jun 2026 00:00:00 +0000

Run Remotion on a Remote Machine and Preview It Locally

Remotion lets you create videos using React. It’s powerful, but running the Remotion Studio (the visual editor) on a headless remote server can feel tricky — there’s no browser to open and no display to render to. This post walks through exactly how to set it up so you can develop Remotion projects on your remote machine and preview everything from your local browser.

1. The Setup

I assume you already have a Remotion project on your remote machine. If not, create one:

npx create-video@latest my-project
cd my-project

Make sure Node.js is installed (v18+). Remotion also needs Chrome/Chromium on the server. If it’s not installed, Remotion will download its own — but you can install it explicitly if you prefer:

# Ubuntu/Debian
sudo apt install chromium-browser

2. Start Remotion Studio on the Remote Machine

SSH into your remote machine and start Remotion Studio:

ssh user@your-remote-machine
cd /path/to/your-remotion-project
npm run dev

By default, Remotion Studio starts on http://localhost:3000. You’ll see output like:

Remotion Studio
  http://localhost:3000

At this point, the server is running, but you can’t open localhost:3000 on your local machine because localhost refers to the remote machine itself.

3. SSH Tunnel: Bridge the Gap

The trick is SSH port forwarding (also called SSH tunneling). On your local machine, open a new terminal and run:

ssh -L 3000:localhost:3000 user@your-remote-machine

Here’s what this does:

Part	Meaning
`-L 3000:localhost:3000`	Forward local port 3000 to remote’s `localhost:3000`
`user@your-remote-machine`	Your SSH login

Now, any traffic hitting your local http://localhost:3000 gets securely tunneled through SSH to the remote machine’s localhost:3000 — where Remotion Studio is listening.

Open your local browser and go to http://localhost:3000. You should see the Remotion Studio interface.

4. VS Code Remote SSH (Even Easier)

If you use VS Code with the Remote - SSH extension, port forwarding is automatic:

Open your remote folder in VS Code (Ctrl+Shift+P → “Remote-SSH: Connect to Host…”)
Open the terminal in VS Code and run npm run dev
VS Code detects the port and shows a notification: “Your application running on port 3000 is available.”
Click “Open in Browser” or manually visit http://localhost:3000

No ssh -L needed — VS Code handles tunneling behind the scenes.

5. Rendering Without Preview

If you just want to render a video file and download it:

# On the remote machine
npx remotion render src/index.ts output.mp4

Then copy it to your local machine:

# On your local machine
scp user@your-remote-machine:/path/to/remotion-project/output.mp4 .

Or use rsync for larger files:

rsync -avz user@your-remote-machine:/path/to/remotion-project/output.mp4 .

6. Persist the Tunnel (Optional)

If you want the tunnel to stay alive even when you close the terminal, use autossh or a -o ServerAliveInterval flag:

ssh -L 3000:localhost:3000 -o ServerAliveInterval=60 user@your-remote-machine

Or run the Remotion Studio in a tmux/screen session so it survives disconnects:

tmux new -s remotion
npm run dev
# Ctrl+B, D to detach

Summary

Goal	Command
Start Remotion Studio on remote	`npm run dev`
Preview locally	`ssh -L 3000:localhost:3000 user@host` then open `http://localhost:3000`
Render video on remote	`npx remotion render src/index.ts out.mp4`
Download video	`scp user@host:path/to/out.mp4 .`
Persistent session	Use `tmux` on remote

That’s it. No display server, no VNC, no X11 forwarding — just SSH and a browser.

AI Won't Replace Software Engineers. It Will Force Them to Think Like Project Managers.

Tue, 03 Mar 2026 00:00:00 +0000

For months now, the loudest narrative around AI and code has been simple:

“AI is going to replace software engineers.”

That’s the wrong frame.

AI isn’t replacing software engineers. It’s compressing execution — and forcing engineers to level up into something closer to project managers.

And that’s a fundamentally different shift.

The Old Model: Engineers as Builders

Traditionally, software engineers were valued for:

Translating requirements into code
Designing technical architecture
Debugging complex systems
Writing efficient, maintainable implementations

Project managers handled:

Clarifying goals
Aligning stakeholders
Breaking projects into structured tasks
Managing timelines and tradeoffs

There was a clear separation between deciding what should be built and building it.

The AI Inflection Point

Agentic coding tools change the balance.

They can:

Scaffold entire applications
Write boilerplate instantly
Refactor large codebases
Generate tests and documentation
Debug with surprising competence

In other words, they compress the mechanical act of coding.

If implementation becomes faster and cheaper, the bottleneck shifts.

And the new bottleneck is thinking.

The New Bottleneck: Specification

With AI, output quality depends almost entirely on:

Clarity of instructions
Constraint definition
System boundaries
Edge case anticipation
Iterative refinement

That’s not “just coding.”

That’s:

Requirement engineering
Scope design
Risk anticipation
Quality evaluation

Those are project management skills.

Engineers Are Becoming Execution Orchestrators

In the AI-augmented workflow, engineers increasingly:

Frame problems precisely
Define constraints clearly
Evaluate outputs critically
Iterate with strategic intent
Balance trade-offs deliberately

Instead of typing every line, they:

Architect solution space
Design feedback loops
Orchestrate AI agents
Integrate generated systems into coherent products

They move up a layer of abstraction.

Not away from engineering. Deeper into it.

This Isn’t Downgrading Engineering. It’s Upgrading It.

Low-level implementation becomes cheaper. High-level thinking becomes more valuable.

The engineer of the AI era isn’t someone who:

Knows the most syntax
Memorizes APIs
Manually writes boilerplate fastest

It’s someone who can:

Translate ambiguous goals into structured systems
Design reliable architectures
Anticipate failure modes
Define clean interfaces
Evaluate trade-offs under uncertainty

In other words:

Engineers aren’t being replaced. They’re being forced to think like project managers.

But with technical depth.

The Real Risk

The engineers most at risk aren’t those who can’t code.

They’re those who:

Wait to be told exactly what to build
Execute blindly without questioning scope
Avoid ownership of system-level decisions

AI reduces the premium on pure execution. It increases the premium on ownership.

Final Thought

The future engineer looks less like a ticket-closer and more like a systems strategist.

Less like a typist and more like a designer of outcomes.

AI won’t replace software engineers.

It will force them to think bigger.

And the ones who embrace that shift will become exponentially more valuable.

Two Lenses: Why Products Decay (And What Young Engineers Don't See Yet)

Tue, 24 Feb 2026 00:00:00 +0000

Two Lenses: Why Products Decay (And What Young Engineers Don’t See Yet)

When you’re early in your tech career, products feel simple.

Good engineering → good product.
Clean code → long-term success.
Thoughtful architecture → scalable future.

It feels rational.

But 10–15 years into the industry, you start seeing something unsettling:

The same product is being viewed through two completely different lenses.

And the tension between those lenses is what often leads to what people now call “enshitification.”

This post is about understanding that dynamic early — before cynicism sets in.

Lens #1: The Engineering Lens

Engineers see products as systems.

You naturally care about:

Architecture
Maintainability
Clean abstractions
Long-term scalability
Minimizing technical debt

When you see a shortcut, your brain automatically projects forward:

“This will hurt us later.”

Your mental model is compounding stability.

Good structure today = easier evolution tomorrow.

From this lens, degrading quality feels irrational and self-destructive.

Lens #2: The Business Lens

Founders, PMs, and investors see something different.

They see:

Runway (months until money runs out)
Revenue growth
Customer acquisition cost
Competitive pressure
Investor expectations

Their mental model isn’t compounding structure.

It’s survival under uncertainty.

From this lens:

A quick solution that generates revenue beats a perfect system that doesn’t.
Speed beats elegance before validation.
Monetizable problems matter more than meaningful-but-unpaid ones.

If the company dies, your clean architecture dies with it.

Where the Tension Begins

Early stage companies usually optimize for users.

They polish. They care. They iterate. They earn trust.

But once growth stabilizes, something shifts.

The optimization function changes.

It becomes:

Increase margins
Reduce costs
Extract more value per user
Satisfy investors

This is where quality sometimes declines.

Not because people suddenly became evil.

But because incentives moved.

This slow drift from “serve users” to “extract value” is what creates product decay.

Understanding “Enshitification”

The term was popularized by Cory Doctorow to describe a common lifecycle:

A platform is great for users.
Then it becomes optimized for business customers.
Then it becomes optimized for shareholders.
Then user experience degrades.

This isn’t always intentional sabotage.

It’s often the natural result of late-stage growth pressure.

And if you stay long enough in tech, you’ll see this cycle repeat.

Why This Confuses Young Engineers

When you’re early in your career, you assume:

Everyone is trying to build the best possible product.

But in reality, different stakeholders are optimizing for different outcomes.

Engineers optimize for system integrity.
Business optimizes for capital efficiency.

Neither perspective is irrational.

But they are incompatible at the extremes.

If engineering dominates without validation → the company may die beautifully.

If business dominates without restraint → the product may survive financially but decay experientially.

The Hard Realization

Some founders plan for exit.

Some investors expect 10x returns.

Some decisions are made knowing long-term technical debt will become someone else’s problem.

That can feel cynical.

But it’s usually structural, not personal.

Understanding incentives makes you less angry and more strategic.

The Real Skill to Develop Early

Instead of choosing a side, learn both lenses.

As a young engineer:

Master technical craft.
Learn how revenue actually works.
Observe how incentives shift as companies grow.
Notice when survival decisions become extraction decisions.
Decide what environments align with your values.

Not every company is built for longevity.

Not every product is meant to age well.

Some are experiments. Some are vehicles for exit. Some become enduring systems.

Your clarity about this will shape your career more than your choice of framework.

Final Thought

Technology is not the product.

It is leverage.

Engineering asks: > “Is this built well?”

Business asks: > “Does this generate return?”

When you understand both lenses, you stop being surprised by product decay.

You start predicting it.

And that awareness changes how you build, where you work, and what you tolerate.

The Clawdbot Debacle Is a Distraction: Agentic AI Ran a Ponzi on Humans

Thu, 29 Jan 2026 00:00:00 +0000

A Quick Backstory (For Those Who Missed the Drama)

In late January, an open-source AI project called Clawdbot went explosively viral.

Clawdbot was marketed as a personal AI agent — something that could run on your own hardware and connect to messaging apps like WhatsApp, Telegram, Discord, Slack, and iMessage. Instead of being “just a chatbot,” it could execute commands, manage email, and act on your behalf.

Within days, the project accumulated tens of thousands of GitHub stars. Tech Twitter buzzed. Influential developers posted about buying Mac Minis just to run it.

Then everything unraveled.

After receiving trademark concerns from Anthropic (the company behind Claude), the creator renamed the project to Moltbot. During the rename process, the old Clawdbot handles on GitHub and X (Twitter) were released and immediately claimed by third parties.

Those accounts were then used to promote a fake crypto token called $CLAWD, launched on the Solana blockchain.

The token briefly surged to a multi‑million‑dollar market cap, before collapsing once the original developer publicly disavowed any involvement. Late buyers were wiped out. Early actors exited.

The internet’s conclusion was swift and simple:

“Clawdbot failed.”

That conclusion is wrong.

The Wrong Story Is Going Viral

The dominant narrative frames this as a cautionary tale about:

careless renaming
trademark pressure
crypto scammers
and reckless users

It’s a comforting story because it isolates the problem.

Delete Clawdbot.
Avoid Solana memes.
Be more careful next time.

Problem solved.

Except it isn’t.

What actually happened is far more uncomfortable:

Agentic AI systems executed a Ponzi‑style extraction against humans, and Solana made it frictionless.

Clawdbot wasn’t the cause. It was the vehicle.

This Wasn’t a “Hack” — It Was an Emergent Behavior

No credentials were cracked. No zero‑day exploit was required.

Instead:

High‑value identities were released
Automated systems detected the opportunity
Fake legitimacy was established instantly
A token was created
Humans provided liquidity
Early actors exited
Late humans absorbed the loss

This sequence didn’t require intelligence. It required automation, speed, and incentives.

That’s not hacking. That’s a Ponzi dynamic — executed at machine speed.

Why “Clawdbot Failed” Is a Convenient Lie

Blaming Clawdbot implies:

the tool was flawed
the developer was careless
uninstalling is a solution

But remove Clawdbot from the equation and nothing changes.

Another agent. Another repo. Another viral moment.

The narrative focuses on which app, instead of what behavior emerged.

Agentic AI Is the New Counterparty

This wasn’t simply “crypto scammers versus users.”

It was:

automated agents
coordinating across platforms
exploiting human reaction time
monetizing attention

Humans weren’t deceived so much as outpaced.

They became liquidity providers in a system that rewards speed over understanding.

That’s Ponzi logic — without the paperwork.

Why Solana Matters (and Why This Will Repeat)

Solana didn’t invent the behavior.

It enabled it.

Solana offers:

near‑zero transaction costs
instant finality
permissionless token creation
public price charts that manufacture legitimacy

This converts hype into money in minutes.

Without platforms like Solana:

impersonation would still happen
hype would still spread

But extraction would be slower.

Slowness is safety. Friction is ethics.

Solana removed both.

The Real Vulnerability Isn’t the Platform

It’s urgency.

Every cycle looks the same:

crypto
NFTs
yield farming
AI agents

Something goes viral. Humans rush to be early. Automation front‑runs them. Losses concentrate at the edges.

This isn’t a user education problem. It’s a structural incentive problem.

“Just Uninstall It” Is Not a Resolution

Uninstalling Clawdbot fixes nothing.

The real questions are:

Why can agentic systems monetize identity gaps instantly?
Why do platforms release high‑value handles with no grace period?
Why does speed consistently beat verification?
Why is hype allowed to convert directly into financial instruments?

Until those questions are addressed:

another tool, another name, another chain
will recreate the same outcome

The Uncomfortable Conclusion

The Clawdbot debacle wasn’t an accident.

It was a preview.

Agentic AI didn’t malfunction. It followed incentives perfectly.

Humans didn’t fail because they were stupid. They failed because they were slower.

And platforms didn’t intervene because:

money moving fast is still considered innovation

That’s the real issue.

Everything else is just a story we tell ourselves so we can move on.

The Hidden Dangers of Vibe Coding at Scale

Wed, 28 Jan 2026 00:00:00 +0000

The Hidden Dangers of Vibe Coding at Scale

When AI helps you move fast—until it quietly breaks what already works.

What People Mean by “Vibe Coding”

“Vibe coding” is the practice of building software by giving high‑level, intent‑based prompts to an LLM and letting it generate or rewrite large portions of the codebase.

Examples:

“Add Stripe payments.”
“Refactor this to support subscriptions.”
“I want a new payment system integrated.”

At small scale, this feels magical. You move fast, features appear instantly, and the app seems to work. The problem begins when your product grows.

The Scaling Problem Nobody Talks About

As your app matures, it accumulates invisible complexity:

Multiple payment gateways (Stripe, PayPal, local wallets)
Legacy users with grandfathered rules
One‑off promos (e.g., Black Friday signups)
Regulatory or accounting edge cases
“Temporary” hacks that became permanent

Humans forget these details too—but humans usually don’t rewrite the entire file when asked for a new feature.

LLMs often do.

How High‑Level Prompts Break Existing Logic

Consider this real‑world scenario:

You already support 2–3 payment gateways
Black Friday users:
- Locked‑in pricing
- Different renewal rules
- Special cancellation behavior

Now you prompt:

“I want a new payment system integrated.”

From the model’s perspective:

The prompt is present‑focused
The most recent instruction has the highest priority
Anything not clearly represented in the visible context is treated as expendable

The result?

Old conditional logic is simplified away
Edge cases are overwritten by a “cleaner” abstraction
Rare user segments silently lose guarantees you promised them

Nothing crashes. No tests fail.

But production behavior changes.

Context Windows Are a Hard Technical Limit

This isn’t just “AI being careless.” It’s architectural.

LLMs have a finite context window.

As your codebase grows:

Not all files fit into context
Not all historical decisions are visible
Comments explaining why something exists are often omitted

When the model rewrites code:

It optimizes for internal coherence, not historical correctness
It prefers consistency over exceptions

From the model’s point of view, deleting them is improving the code.

Why This Is Especially Dangerous in Payments

Payments are a perfect storm:

Money + trust
Legal and accounting implications
Users notice changes immediately
Rollbacks are messy or impossible

Breaking a UI feature is annoying. Breaking payment logic is existential.

The Illusion of “It Still Works”

One of the most dangerous aspects of vibe coding is that nothing appears broken.

The app builds. The checkout flows. The demo works.

But correctness isn’t binary.

The app works—just not the way it used to.

How to Use LLMs Without Shooting Yourself

Vibe coding isn’t evil—but it needs guardrails.

1. Narrow the Rewrite Surface

Avoid prompts that imply global change.

Bad:

“Refactor the payment system.”

Better:

“Add a new gateway without modifying existing pricing logic or legacy user rules.”

2. Encode Edge Cases as Tests, Not Comments

LLMs respect failing tests more than comments.

If Black Friday users matter, lock their behavior in tests.

3. Document Business Invariants Explicitly

Create documents like:

PAYMENTS_INVARIANTS.md

Feed them into relevant prompts.

4. Treat AI as a Junior Engineer, Not an Architect

A junior dev can implement scoped changes. They should not redefine system boundaries.

Your LLM is no different.

Closing Thought

Your production system is not just code.

It is:

A history of decisions
A record of promises
A map of exceptions that exist for a reason

If you let high‑level prompts rewrite that history unchecked, you’re not vibe coding.

You’re vibe gambling.

How Do You Make AI Understand Business Rules Across Products — And Still Dive Into the Code?

Wed, 14 Jan 2026 00:00:00 +0000

The Question That Actually Started This

“How can I make the AI understand our business rules across all products —
while still being able to dive down to exact code-level details when needed?”

Not one product.
Not one repo.
Not one stack.

Multiple long-lived products.
Multiple repositories per product.
Different frameworks. Different versions.
Shared business logic with subtle differences.

If you’ve ever been responsible for more than one real system, this question probably feels familiar.

Why This Is Harder Than It Sounds

At a business level, things are usually clear:

“Resellers with 50% commission can’t offer Package A”
“This only applies in Country B”
“Product A and B follow the same rule — mostly”

At a technical level, reality looks like this:

Product A: React + Backend 1
Product B: Vue + Backend 2
Pricing logic spread across:
- frontend conditionals
- backend validation
- configs
- migrations
Business rules described… somewhere in Markdown

The hard part isn’t the rule.
The hard part is bridging intent → implementation across systems.

That’s what I wanted the AI to help with.

The First Attempt: “Just Load the Context”

Like many teams, we leaned into Markdown:

Business rules written in .md
Glossaries explaining internal terms
Copilot tools (Amazon Q, later Open WebUI) pointed at them

And at first… it worked.

Until it didn’t.

As products grew, so did the Markdown:

Per-product summaries
Shared rules duplicated
Exceptions layered on

Eventually every question started failing the same way:

“Too much context loaded”

When Bigger Models Still Hit the Wall

At this point, the natural response was:

“Okay, let’s try the biggest LLM we can.”

We tried Claude Sonnet 4.5 — massive context window, best-in-class reasoning.

And it helped… briefly.

Then the same pattern emerged:

Load more Markdown → worse answers
Load all knowledge → hallucinations
Remove some docs → missing rules
Trust erodes

This is the moment many teams quietly arrive at the same thought:

“Maybe we need to fine-tune.”

The Fine-Tuning Temptation (and Why It’s a Trap)

Fine-tuning sounds like the ultimate solution:

“Teach the model our rules”
“Bake in company knowledge”
“No more context juggling”

But that idea rests on a false assumption:

That the problem is memory.

It isn’t.

Fine-tuning:

Changes behavior, not structure
Compresses knowledge, destroying traceability
Makes rules harder to audit
Requires retraining as rules change

You don’t want the model to remember your business logic.

You want it to consult it correctly.

The Realization: Humans Don’t Load Everything Either

The turning point was embarrassingly simple:

Senior engineers don’t load the entire system before fixing something.

They:

Clarify intent
Consult business rules
Identify scope
Navigate code selectively

We were forcing LLMs to skip steps 1–3 and jump straight to step 4 — with all knowledge shoved into a single prompt.

That’s not intelligence. That’s overload.

Markdown Was Never the Problem

This part surprised me:

Markdown was actually the best part of the system.

During meetings:

Someone adds a constraint
A paragraph gets appended
The rule is updated immediately

No schemas. No pipelines. No re-indexing.

The problem wasn’t Markdown.

The problem was treating Markdown as always-loaded memory, instead of consulted intent.

The Architectural Shift: From Memory to Consultation

Instead of asking:

“How do I get the AI to read everything?”

The better question became:

“How does the AI ask the right questions?”

That’s where Model Context Protocol (MCP) fits — not as an AI feature, but as an architectural boundary.

What MCP Enabled That RAG Couldn’t

With MCP, the AI no longer gets documents dumped into its prompt.

Instead, it gets tools like:

“Search relevant business rules”
“Explain this internal term”
“What domains might this rule affect?”

The AI:

Starts with intent
Pulls only relevant excerpts
Decides what code to inspect next

Exactly how an experienced engineer works.

Why This Scales Across Products

Now:

One business rule lives in one place
Product differences are contextual, not duplicated
Markdown stays human-first
Indexes are optional accelerators
Context windows stay small and meaningful

The same MCP server can be used by:

Amazon Q Developer (inside VS Code)
Open WebUI
Future agentic tooling

One knowledge system. Multiple products. Multiple entry points.

The Outcome

What started as a simple question:

“How can I make AI understand business rules across products and dive into code?”

Ended with a realization:

LLMs don’t fail because they lack knowledge.
They fail because we architect them like databases.

Once we stopped forcing memory
and started enabling consultation,

the tools finally behaved like senior engineers instead of overconfident interns.

If This Feels Familiar

If you’ve:

Hit “too much context loaded”
Tried the biggest available model
Doubted RAG
Considered fine-tuning out of frustration
Worked on more than one real product

This problem isn’t unique to you.

And the solution isn’t a bigger model.

It’s better boundaries.

Scalable Full-Stack Development Environment

Sat, 20 Dec 2025 06:45:00 +0000

Scalable Full-Stack Development Environment

A thin-client, container-first approach to building a resilient, portable development workflow.

As a full-stack developer, I’ve repeatedly run into problems that don’t show up in tutorials but absolutely show up in real life: OS updates breaking setups, machines crashing mid-work, environments drifting away from production, and the constant fear that a reformat means rebuilding everything from scratch.

Over time, I intentionally designed a development environment that prioritizes stability, portability, and recoverability over convenience. This post documents that setup—not as a theoretical best practice, but as a system I actively use.

This setup is especially relevant for solo developers, indie hackers, and small teams who want their development environment to behave more like infrastructure than a fragile personal workstation.

The Pain Points

1. System Instability

No matter how powerful your PC, laptop, or Mac is, you are always one buggy program away from crashing your entire system. Memory leaks, runaway Docker containers, bad drivers, or misbehaving apps can freeze or reboot your machine—taking your development work with it.

2. Lack of Portability

I need to be able to resume my work from any device—mobile phone, tablet, laptop—anytime, anywhere. Traditional setups assume you are sitting in front of the same machine that contains your entire development state.

3. Environment Inconsistency

Reproducing production environments locally is notoriously difficult. Slight differences in OS, libraries, PHP or Node versions, and system packages lead to the classic problem:

“It works on my machine.”

4. OS-Level Disruptions

OS updates frequently break development tools or require reconfiguration. Whether it’s macOS, Windows, or Linux, updates tend to reset assumptions your workflow quietly relied on.

5. Hardware Failures

A corrupted disk, damaged SSD, malware incident, or forced reformat means rebuilding everything. Even with backups, the environment itself is often undocumented and unreproducible.

The Solution: A Distributed, Containerized Approach

Instead of treating my primary computer as both a workstation and a server, I separated responsibilities.

This effectively turns my local machine into a thin client, while a dedicated Linux machine becomes the authoritative source of compute, state, and configuration.

Hardware Configuration

I use two inexpensive computers, each focused on what it does best.

1. macOS Machine (Thin Client)

Purpose: User interaction only (screen, keyboard, mouse)
Installed software:
- Google Chrome
- Sequel Ace
Philosophy:
- No compilers
- No runtimes
- No databases
- Nothing critical lives here

If this machine dies, is reformatted, or updated aggressively, nothing important is lost.

2. Linux Server (Development Infrastructure)

OS: Fedora Linux Server
Responsibilities:
- Running all server software
- Storing all code
- Hosting databases
- Managing containers

Installed components include:

Docker Engine + Docker Compose
Caddy (reverse proxy and TLS)
Visual Studio Code Server
Continue.dev CLI
Git
Tailscale

This machine is where state lives.

Network Architecture

To make local development fast and predictable, both machines connect to a dedicated router, while the ISP router is placed upstream.

macOS device → LAN
Linux server → LAN
ISP router → WAN

Why This Matters

Local traffic never passes through the ISP router
Lower latency and fewer bottlenecks
Isolation from other devices on the ISP network
Reduced risk of accidental exposure

This results in double NAT. While double NAT is not perfect security, it provides meaningful isolation and reduces attack surface and network noise.

Built-In Internet Failover

The router supports dual WAN inputs. This allows me to attach a secondary connection (for example, prepaid home WiFi) and automatically fail over if the primary wired connection goes down.

Connectivity becomes infrastructure, not a single point of failure.

Development Workflow

Code Editing Anywhere (Code Server as PWA)

I never edit code directly on macOS.

Instead, I access Visual Studio Code Server running on the Linux machine via a browser. By clicking the browser’s Install button, Code Server becomes a Progressive Web App.

From the user’s perspective, it behaves like a native application—but all computation and files remain on the server.

I’ve resumed work from:

Another laptop
A tablet
A mobile phone
An airport gate in another country

Nothing changes except the screen size.

Container-First, Host-Nothing Philosophy

All development dependencies live in containers.

No PHP installed on the host
No Node.js installed on the host
No databases installed on the host

Each project defines exactly what it needs.

If Project A needs PHP 7.4 and Project B needs PHP 8.3, they coexist without conflict—because the host never knows PHP exists.

Docker is not just a tool here; it is the contract.

Reverse Proxy and HTTPS with Caddy

When hosting multiple applications on the same machine:

Caddy routes domains to the correct container
Each service is reachable via HTTPS
Self-signed certificates are handled automatically

This allows realistic local development that closely mirrors production behavior.

Resilience by Design

OS Updates Become Non-Events

When macOS updates arrive, I update immediately.

Nothing breaks—because nothing critical lives there. After the update, I reconnect to Code Server and continue working exactly where I left off.

Hardware Failures Are Contained

If the macOS machine fails entirely, any device with a browser becomes a replacement. The development environment itself remains intact.

Remote Access from Anywhere

Tailscale VPN

A Tailscale daemon runs on the Linux server, exposing a secure private IP.

This enables:

Secure access without port forwarding
Encrypted connections from anywhere
Zero-trust networking

Mobile and Agentic CLI Access

With Tailscale enabled:

I connect from a mobile device
Open a terminal client
Access Continue.dev CLI
Interact with the codebase using agentic workflows

This works whether I’m at home, in a café, or traveling internationally.

Off-Premise Backups: Planning for Total Failure

Even with all the precautions above, I assume one thing will eventually happen:

The Linux server will fail catastrophically.

Fire, power surge, disk failure, or simple human error — local infrastructure is still local infrastructure. To handle this, I treat off‑premise backups as a first‑class component of the system.

Rclone + Backblaze B2

I use rclone to synchronize critical data from the Linux server to an off‑site object storage provider.

Rclone supports Backblaze B2 natively, so I configure a remote that points directly to a B2 bucket. From there, scheduled jobs handle backups automatically.

What gets backed up:

SQL database dumps (MySQL, PostgreSQL, etc.)
Entire Git repositories (including all branches)
Project stack repositories (*-stack)
Configuration files that define the environment

What does not get backed up:

Running containers
Build artifacts
Anything that can be recreated from Dockerfiles

The goal is simple: preserve state, not runtime.

Recovery Scenario

If the Linux server is completely destroyed:

Provision a new Linux machine
Install Docker, Docker Compose, and rclone
Restore repositories and SQL dumps from Backblaze B2
Run docker compose up

The entire development environment — including code, history, and data — is reconstructed without relying on any single physical machine.

This turns a catastrophic failure into a recoverable inconvenience.

Project Structure: The “Super-Repo” Pattern

For each project, I create a repository named:

[project]-stack

Example structure:

helloworld-stack/
├── repos/
│   ├── api.example.com
│   ├── app.example.com
│   ├── mysql-migration-scripts
│   └── helloworld-mcp-server
├── docker-compose.yml
├── docker/
├── .gitignore
├── .amazonq/rules
└── .roocode/rules

Why Submodules Instead of a Monorepo?

Each submodule retains its own:

Git history
CI/CD pipeline
Deployment lifecycle

The stack repository simply orchestrates them.

Benefits

One repository defines the entire system
Easy onboarding
Fully reproducible environments
AI tools gain structured, project-level context

Who This Setup Is (and Isn’t) For

This Setup Is For:

Developers who value stability over convenience
People maintaining multiple long-lived projects
Anyone tired of rebuilding environments

This Setup May Be Overkill If:

You only write small scripts
You rely heavily on native GUI tooling
You prefer managed cloud IDEs

Core Philosophy

Treat development machines as disposable clients.

Preserve state only where it matters.

Once you adopt this mindset:

OS updates stop being scary
Hardware failures become inconveniences
Your environment becomes portable by default

Getting Started

Start with a dedicated Linux machine (even low-powered hardware works)
Install Docker and Docker Compose
Set up Code Server
Configure Tailscale
Create your first [project]-stack repository

This approach transformed my workflow from something fragile into something durable. I spend far less time fixing my environment—and far more time actually building software.

Secure Development Environment with Tailscale, Caddy, and dnsmasq

Thu, 18 Dec 2025 00:00:00 +0000

Secure Development Environment with Tailscale, Caddy, and dnsmasq

This guide explains how to set up a secure development environment using Tailscale VPN, Caddy reverse proxy, and dnsmasq DNS server to provide HTTPS access to local development services across multiple machines.

Why You Need This Setup

Mobile Device Testing

Testing your web applications on mobile devices (Android, iOS) requires proper HTTPS endpoints with valid certificates. Unlike desktop machines where you can modify /etc/hosts, mobile devices don’t allow easy host file modifications. This setup provides:

Automatic DNS resolution on mobile devices through Tailscale
Valid HTTPS certificates that mobile browsers trust
No manual configuration required on each mobile device
Consistent URLs across all testing devices

Secure Remote Access

You want to access your development environment from anywhere (home, office, coffee shop) without exposing it to the general public. This setup enables:

Private network access through Tailscale VPN from any location
No public port forwarding or firewall rules needed
Encrypted connections for all traffic
Access control through Tailscale authentication
No cloud hosting costs for development environments

Architecture Overview

The setup consists of three main components working together:

Tailscale VPN - Provides secure network connectivity between devices
dnsmasq DNS Server - Resolves custom domain names to the development server
Caddy Reverse Proxy - Handles HTTPS termination and routing to local services

How It Works

Network Flow

Client Machine (via Tailscale) 
    ↓ DNS Query (local-api.example.com)
dnsmasq DNS Server (100.x.x.x)
    ↓ Returns server IP
Client connects to Caddy (100.x.x.x:443)
    ↓ HTTPS with internal certificates
Caddy routes to local service (localhost:8080)

Component Roles

Tailscale VPN:

Creates secure mesh network between all devices
Assigns stable IP addresses (100.x.x.x range)
Handles authentication and encryption
Enables split DNS configuration

dnsmasq DNS Server:

Runs on the development server
Resolves custom domains to server’s Tailscale IP
Configured as nameserver for Tailscale clients
Provides local DNS resolution without external dependencies

Caddy Reverse Proxy:

Terminates HTTPS with internal certificates
Routes requests to appropriate backend services
Adds security headers for proper forwarding
Handles multiple domains and services

Setup Process

1. Tailscale Configuration

Install Tailscale on all devices and connect them to your tailnet:

# Install Tailscale (varies by OS)
curl -fsSL https://tailscale.com/install.sh | sh

# Connect to your tailnet
sudo tailscale up

2. dnsmasq DNS Server Setup

Configure dnsmasq on your development server:

# Install dnsmasq
sudo apt install dnsmasq

# Create DNS configuration
sudo tee /etc/dnsmasq.d/internal.conf << EOF
# Listen on Tailscale interface
listen-address=127.0.0.1,100.x.x.x
bind-interfaces
no-dhcp-interface=*
domain-needed
bogus-priv
no-resolv
no-poll
no-hosts

# Upstream DNS servers
server=8.8.8.8
server=8.8.4.4

# Local domain mappings
address=/local-api.example.com/100.x.x.x
address=/local-app.example.com/100.x.x.x
EOF

# Start dnsmasq
sudo systemctl enable --now dnsmasq

3. Caddy Reverse Proxy Setup

Configure Caddy for HTTPS termination and routing:

# Global settings
{
    http_port 80
    https_port 443
    skip_install_trust
    local_certs
}

# API service
local-api.example.com {
    reverse_proxy localhost:8080 {
        header_up X-Forwarded-Proto https
        header_up X-Forwarded-Port 443
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Ssl on
        header_up X-Url-Scheme https
        header_up HTTPS on
    }
    tls internal
}

# Web application
local-app.example.com {
    reverse_proxy localhost:3000 {
        header_up X-Forwarded-Proto https
        header_up X-Forwarded-Port 443
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Ssl on
        header_up X-Url-Scheme https
        header_up HTTPS on
    }
    tls internal
}

4. Tailscale DNS Configuration

Configure Tailscale to use your server as DNS:

# Set your server as nameserver for custom domains
tailscale set --nameserver=100.x.x.x

Benefits

Security

Encrypted Traffic: All communication encrypted via Tailscale
No Public Exposure: Services remain private to your tailnet
HTTPS Everywhere: Internal certificates provide HTTPS for all services
Access Control: Tailscale handles authentication and authorization

Development Experience

Custom Domains: Use meaningful domain names instead of IP:port
Cross-Device Access: Access services from any device in your tailnet
No Certificate Warnings: Proper HTTPS with trusted internal certificates
Easy Service Discovery: DNS-based service discovery

Operational Advantages

No External Dependencies: Works without internet for local development
Scalable: Easy to add new services and domains
Portable: Works across different networks and locations
Maintainable: Simple configuration files for all components

Troubleshooting

DNS Resolution Issues

# Test DNS resolution
nslookup local-api.example.com 100.x.x.x

# Check dnsmasq status
sudo systemctl status dnsmasq

# View dnsmasq logs
sudo journalctl -u dnsmasq -f

Certificate Issues

# Check Caddy status
sudo systemctl status caddy

# View Caddy logs
sudo journalctl -u caddy -f

# Test HTTPS connection
curl -v https://local-api.example.com/

Tailscale Connectivity

# Check Tailscale status
tailscale status

# Test connectivity
ping 100.x.x.x

# Check DNS configuration
tailscale status --json | grep -A5 DNS

Common Pitfalls

Conflicting /etc/hosts entries - Remove any localhost entries for your custom domains
DNS caching - Clear DNS cache after configuration changes
Firewall rules - Ensure ports 53 (DNS) and 443 (HTTPS) are accessible
Service binding - Make sure backend services bind to localhost or all interfaces

Conclusion

This setup provides a robust, secure development environment that scales across multiple services and devices. The combination of Tailscale’s mesh VPN, dnsmasq’s local DNS resolution, and Caddy’s reverse proxy creates a production-like environment for development while maintaining security and ease of use.

The architecture is particularly valuable for:

Mobile app development - Test APIs on real devices without certificate issues
Remote development - Access your dev environment securely from anywhere
Team collaboration - Share development services without public exposure
Microservices development - Use proper domain names instead of localhost:port
Cross-device testing - Consistent HTTPS URLs across all devices
Client demos - Show work-in-progress to clients securely