Darwin Biler

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

Why I Don't Believe in 'Good vs Evil' Narratives

Tue, 16 Dec 2025 00:00:00 +0000

I’ve been thinking a lot about why modern debates — from geopolitics to social issues — feel increasingly hostile and polarized.

West vs Russia.
China vs USA.
Israel vs Palestine.
Men vs women.
Black vs white.
LGBTQ vs straight.

Different topics, same pattern.

Each side is convinced the other is evil.

I don’t think this framing helps us understand anything. In fact, I think it makes things worse.

Right and wrong depend on alignment, not truth

I don’t see “right” and “wrong” as universal properties of actions.
I see them as signals of alignment.

Alignment with:

law
culture
religion
politics
social norms

When something is called wrong, what it usually means is:

“This action does not align with the system I live under.”

For example, humans eat animals and plants.
From our legal and cultural perspective, that’s normal.

From the perspective of animals, we are mass killers.
From the perspective of plants, we are destroyers.

Nothing about the act changes — only the frame of reference does.

Geopolitics isn’t moral — it’s interest-based

This becomes obvious when looking at geopolitics.

Countries don’t act because they are good or evil.
They act to protect:

security
resources
influence
economic stability
strategic advantage

Moral language comes after decisions are made, not before.

People don’t rally behind “strategic depth” or “trade routes”.
They rally behind words like freedom, evil, terror, or existential threat.

These words simplify complex realities into something emotionally actionable.

Comfort has upstream costs

If you live comfortably inside a powerful system, it’s worth being honest about this:

Your lifestyle didn’t appear out of nowhere.

Stability, cheap goods, secure borders, and economic privilege are often maintained by actions that are:

invisible
outsourced
morally uncomfortable

Calling leaders “evil” while enjoying the benefits of the system they protect is an easy position — but not an honest one.

This isn’t about endorsement.
It’s about acknowledging causality.

Polarization is not an accident

Extreme polarization doesn’t happen because people suddenly became stupid or hateful.

It happens because:

complex problems are simplified into identity battles
disagreement is reframed as moral failure
leaders benefit from divided populations

Once an issue becomes “good people vs evil people”, dialogue ends. Only loyalty remains.

That’s how you get extremists on every side — religious, racial, political, or ideological.

Different beliefs. Same mechanics.

My goal isn’t neutrality — it’s clarity

I’m not saying all sides are the same.
I’m not denying harm, injustice, or suffering.

What I’m rejecting is the idea that moral outrage leads to understanding.

In my experience, it does the opposite:

it hides incentives
it masks power dynamics
it turns people into symbols instead of humans

If we want fewer extremists, less hatred, and more stability, we need to talk less about evil and more about interests.

The question I try to ask

Whenever I feel myself being pulled into outrage, I stop and ask:

Who benefits if I believe this narrative?

That question doesn’t make me passive. It makes me harder to manipulate.

And in a world full of incentives to divide, that feels like a small but necessary act.

Vibe Coding From Anywhere: Agentic CLI + Tailscale + ConnectBot

Sun, 14 Dec 2025 00:00:00 +0000

The Problem

Sometimes inspiration (or urgency) hits when you’re not in front of your main machine.

You want to:

Inspect a codebase
Ask questions about existing logic
Make small edits
Think through architecture

…but your project lives on a home server, behind double NAT, and you only have your phone.

Traditional solutions (port forwarding, public SSH exposure) are either fragile or unsafe.

The Stack

This setup works surprisingly well and feels almost unfairly powerful:

Fedora Linux server (home, double NAT)
Continue.dev CLI → agentic AI that understands your codebase
DeepSeek Coder as the LLM backend
Tailscale → zero-config private networking
Android phone
ConnectBot → real Linux shell on mobile

In short:

📱 Phone → ConnectBot → SSH → Fedora server → Continue.dev → AI understands your repo

Why Tailscale Solves Double NAT

Double NAT normally kills inbound connections.

Tailscale flips the model:

Your server makes an outbound encrypted connection
Your phone does the same
Both devices meet inside a private WireGuard mesh

No port forwarding. No public exposure. No hacks.

From SSH’s perspective, it feels like a local network.

Continue.dev on the Server

On my Fedora server, I run Continue.dev CLI, so the AI lives next to the code.

This means:

Full repository context
Fast file access
No syncing or partial clones

My ~/.continue/config.yaml looks like this:

name: "local-deepseek"
version: "1.0.0"

models:
  - name: "DeepSeek Coder"
    provider: "openai"
    model: "deepseek-coder"
    apiBase: "https://api.deepseek.com/v1"
    apiKey: "REDACTED"

defaultModel: "DeepSeek Coder"
allowAnonymousTelemetry: false

Once authenticated, I can ask questions like:

“Why is this function structured this way?”
“What breaks if I change this interface?”
“Refactor this for clarity”

All over SSH.

ConnectBot: Real Linux on Android

ConnectBot turns your phone into a legit Linux terminal.

just enter your SSH credentials after installing the app.

Once connected:

Run cn (Continue.dev CLI)
Navigate the repo
Read, reason, and edit code

This isn’t remote desktop cosplay — it’s actual development.

Why This Feels Different

Most “AI coding” setups are:

Browser-based
Detached from the real repo
Context-limited

This one is:

Terminal-native
Repo-aware
Private
Always-on

You’re not asking an AI to guess your project.

You’re asking it while standing inside the project.

When This Is Useful

Reviewing PRs while commuting
Debugging production logic away from your desk
Capturing architectural thoughts before they fade
Teaching yourself your own codebase

It’s not about replacing real development time.

It’s about keeping momentum alive.

Security Notes

SSH is only reachable via Tailscale
No public ports exposed
Keys stay on your devices
AI API key lives only on the server

This is far safer than exposing SSH to the internet.

Final Thoughts

Agentic CLI + Tailscale + ConnectBot turns your phone into:

A secure, private, AI-augmented terminal to your home server

Not flashy.

Just extremely effective.

If you already think in terminals, this feels like cheating — in the best way possible.

Why Confidence Is the Key Is Terrible Advice

Fri, 12 Dec 2025 00:00:00 +0000

People love repeating the phrase confidence is the key as if it is some universal truth.
But this advice—while catchy—often creates more problems than it solves. In fact, it encourages a culture where overconfidence is mistaken for competence, and where the loudest voice in the room gets more attention than the most capable one.

This isn’t just an opinion. It matches what many people observe in real life:
the most successful people are often humble, cautious, and quietly competent.

So why does society get it so backwards?

Confidence vs. Competence-Based Confidence

There are two kinds of confidence, but most people only talk about one.

1. Performative Confidence

This is the type that’s rewarded in interviews, meetings, and social media:

loud
assertive
certain even when unsure
full of opinions

This is the kind of “confidence” that leads straight into the Dunning–Kruger effect—people who don’t know much, but assume they know enough.

2. Competence-Based Confidence

This one looks completely different:

calm
humble
aware of limits
willing to say “I don’t know”
precise instead of loud

People with this kind of confidence don’t act confident, but they are trusted because they consistently deliver.

Real Experts Doubt Themselves More

It seems counterintuitive, but it’s true:
The more skilled someone becomes, the more aware they are of what they don’t know.

That’s why top performers tend to:

double-check their assumptions
ask questions
defer to someone with deeper expertise
avoid pretending they “know everything”

This is called intellectual humility, and it’s a sign of maturity—not insecurity.

Meanwhile, the people who “never doubt themselves” are often the ones who stop learning.

How Confidence Culture Creates the Wrong Leaders

Modern culture rewards the wrong traits:

Being loud instead of being right
Being assertive instead of being thoughtful
Acting certain instead of checking facts

This results in:

poor leadership
shallow decision-making
workplaces dominated by people who look confident but lack depth

Meanwhile, the quiet experts—who carry teams, solve failures, and prevent disasters—often go unnoticed because they don’t broadcast their expertise.

It’s a mismatch between visibility and value.

Humility Is Not Shyness — It’s Mastery

You’ll notice something if you talk to people who are truly world-class at what they do:

They don’t brag
They share credit
They second-guess high-stakes decisions
They treat knowledge as something you never fully “finish”

They don’t need to prove anything. Their work speaks for them.

This humility is not a lack of confidence.
It’s a sign that they understand the complexity of their field.

So If Confidence Isn’t the Key, What Is?

A better formula looks like this:

Competence → Humility → Quiet Confidence

Competence gives you real ability.
Humility keeps you learning and prevents blind spots.
Quiet confidence lets you act decisively after doing the work.

This is the opposite of the “fake it till you make it” mentality.

Final Thoughts

Telling people that “confidence is the key” might sound uplifting, but it oversimplifies reality and encourages the wrong behaviors.

A more honest message is this:

Competence matters more than confidence.
Humility protects you from stupidity.
Quiet confidence beats loud confidence every time.

Instead of teaching people to act certain, we should encourage them to become skilled, stay humble, and let confidence grow naturally from real ability.