Home on Antonio B De Castro | Expert Technologist

The 2025 Developer Stack: What I'd Choose Starting from Scratch

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 25 Nov 2025 00:00:00 +0000

Every few months, a “perfect stack” shows up on Twitter—complete with new acronyms and a promise that your next release will be effortless. It won’t. What actually makes developers faster and keeps production calm is boring consistency: one language everywhere, one runtime that feels good day-to-day, predictable interfaces, and tooling that doesn’t collapse under real traffic. If I were building a new product today, this is the stack I’d start with—and the logic behind it.

TypeScript Everywhere: One Language, Fewer Surprises

If there’s a single foundation I’d refuse to compromise on, it’s TypeScript. Not because “types are cool,” but because they eliminate entire classes of bugs created by uncertainty. Your future self doesn’t just want fewer runtime errors—they want clearer intent.

Where I’d use it:

Backend services: TypeScript with strict settings
Frontend: Svelte 5 + TypeScript
Shared libraries: types, domain models, validation schemas
Tooling scripts: build, migrations, CI helpers

Opinionated defaults I’d set immediately:

strict: true
Avoid any like it’s technical debt with a pulse
Prefer explicit return types for exported functions in shared packages
Use project references if your repo grows

Concrete example: Suppose you have a “Checkout” flow used by both web and an internal admin tool. With TypeScript, the request/response types can live in a shared @types/checkout package. When the API changes, the compiler becomes your reviewer.

That’s the real win: TypeScript doesn’t just catch mistakes—it shapes how your team talks about code.

Bun as the Runtime: Fast Feedback, Practical Ops

Next up: Bun. I’m not interested in declaring a winner in a runtime war; I’m interested in the developer loop. Bun’s advantage is tangible: fast installs, quick startup, and a toolchain that feels responsive. If you’re shipping frequently, the time saved compounds.

How I’d adopt Bun without being reckless:

Use Bun for local development and CI build/test steps
For production, keep deployment predictable (containerize like you always do)
Pin versions (both runtime and dependencies) to avoid “works on my machine” drift
Benchmark only if you have evidence of a bottleneck—otherwise, trust the productivity gain

Concrete example: In a monorepo, “install + build + test” can become the slowest part of your day. Bun’s speed makes that loop less painful, which encourages smaller PRs and faster iteration. Smaller PRs lead to fewer regressions. That’s how DX translates into reliability.

I’ll be blunt: if a runtime makes your team’s daily workflow slower, it’s not “simpler.” It’s compounding friction.

Svelte 5 for UI: A UI Framework That Doesn’t Fight You

Svelte has always appealed to me because it’s pragmatic. With Svelte 5, you get a modern component model with a strong focus on performance and developer ergonomics. The best part is that you can build product UIs without turning your app into a configuration labyrinth.

What I’d standardize:

A design system approach early (even if it’s lightweight)
Shared UI primitives: buttons, inputs, modals, form components
Strong typing for props and event payloads

Concrete example: Let’s say you’re building a “user preferences” screen with multiple toggles, validation, and server persistence. With Svelte + TypeScript, you can keep the entire flow coherent:

Typed form state on the client
Typed payload for the API call
Typed response for optimistic UI updates

You end up with fewer “stringly-typed” edge cases, which is where UI bugs hide.

And yes—UI performance matters. But more than that, UI maintainability matters. Svelte’s mental model tends to stay readable as components grow, which is exactly what you want in teams that will change over time.

APIs with Hono or FastAPI: Choose the One You Can Ship With

For APIs, I’d pick between Hono and FastAPI based on team strengths—but I’d insist on a consistent philosophy: fast request handling, clear route structure, and strong validation at boundaries.

If your team leans TypeScript-first: Hono

Hono fits naturally in the “TypeScript everywhere” world. You can keep request/response types aligned with your frontend and shared libraries.

Practical advice: Use schema validation at the edges (request parsing) and keep handlers thin. Put business logic in separate modules so route files don’t become accidental architecture.

If your team wants Python’s ecosystem gravity: FastAPI

FastAPI is excellent when you want rapid development with excellent validation ergonomics, and you plan to lean on Python libraries for specific tasks.

Practical advice: Keep your OpenAPI contract stable and treat it like a public interface. If you version endpoints, do it deliberately—not via accidental behavior changes.

Concrete example (either way): Your API should have typed contracts for:

Authenticated user identity
Pagination/filtering semantics
Error shapes (consistent error codes/messages)

That one decision reduces front-end guesswork and backend churn.

PostgreSQL + pgvector + Redis: Data You Can Trust, Cache You Can Justify

When people talk about “data stacks,” they often list five systems and call it “modern.” I prefer a smaller set of systems you actually understand under pressure.

PostgreSQL as the source of truth

Start with PostgreSQL. It’s the backbone that survives scale, migrations, and reorganizations. Then add pgvector when you need vector search features.

How I’d structure it:

Use Postgres for all canonical entities
Store vectors in Postgres via pgvector
Build retrieval logic so that vector search is an internal detail, not something your app code is tangled with

Concrete example: A support assistant might retrieve relevant articles:

Store article embeddings in a documents table with a vector column
On query, compute the embedding and run similarity search in Postgres
Retrieve top N matches, then apply application-level ranking/filters

You get one system that supports both relational data and vector similarity, reducing operational sprawl.

Redis for caching (not for persistence)

Use Redis to speed things up—caches, rate limiting, ephemeral session data where appropriate, and background job coordination if it fits your design.

Rule of thumb: If losing the cache would damage correctness, don’t store correctness-critical state in Redis. Store it in Postgres and let Redis be the acceleration layer.

Practical advice: Namespaces and TTLs matter. Add prefixes like cache:user: and set sensible expirations so stale data doesn’t haunt you.

Docker for Deployment + AI Agents in CI/CD: Reliable Shipping, Automated Assistance

Here’s where modern stacks either become disciplined—or become a science project.

Docker for deployment

Docker keeps environments consistent and makes onboarding cheaper. Even if you later move to a more specialized platform, Docker-first habits (clear build steps, reproducible images) pay off.

Practical advice:

Build optimized images (multi-stage builds)
Run as non-root
Keep secrets out of images (use environment variables or your secret manager)
Add health checks and timeouts so your system fails in a controlled way

AI agents in CI/CD (use them like junior devs)

I’m supportive of AI agents in the pipeline, but only with guardrails. The best use is automation around repetitive tasks: linting improvements, test generation for edge cases, changelog drafting, migration plan review, and code review assistance.

How I’d deploy them safely:

Limit scope: “Suggest” and “annotate,” not “rewrite everything”
Require human approval for high-impact changes
Make them explain their modifications and link to failing logs or test output
Treat them as workflow accelerators, not sources of truth

Concrete example: If a PR fails integration tests, an agent can read the logs and propose a likely fix: missing environment variable, incorrect request schema, or flaky timing. The agent reduces investigation time; it doesn’t “decide reality.”

Conclusion: A Stack That Optimizes for Shipping, Not Swagger

The 2025 stack I’d choose isn’t the flashiest lineup. It’s the one that respects your time: TypeScript for coherence, Bun for a fast feedback loop, Svelte 5 for maintainable UI, Hono or FastAPI for APIs, PostgreSQL + pgvector for trustworthy data plus retrieval, Redis for speed without correctness risk, Docker for repeatable deployment, and AI agents in CI/CD for automation with supervision.

If you want a stack that survives the hype cycle, optimize for the daily loop that your team lives in—edit, build, test, deploy, repeat. Everything else is noise until it proves it helps you ship.

The Technologies That Survived the Hype: A Four-Year Retrospective

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 15 Nov 2025 00:00:00 +0000

Hype cycles are loud, but they’re not decisive. Over four years—2022 through 2025—what survived wasn’t what sounded impressive in keynote decks. It was what made developers’ lives easier, reduced operational pain, and scaled with real-world requirements. If you’ve ever watched a promising tool peak, fade, and leave your team stuck with migration work, this retrospective will feel uncomfortably familiar—and useful.

The survival rule: solve problems that compound

The technologies that endured share a blunt trait: they compound value. Every successful project teaches the team something, and that knowledge becomes reusable. That’s how adoption accelerates—documentation grows, community answers become sharper, tooling tightens, and integrations multiply.

By contrast, hype-driven tools often solve a problem that mostly exists in slides. When the novelty wears off, teams don’t have a sustained reason to keep switching. The result is a revolving door: new features, unstable ecosystems, and migration fatigue without enough operational or developer experience payoff to justify the churn.

You can see this in how “winners” behave across the stack: languages and frameworks that reduce day-to-day friction, databases that perform predictably, and deployment tools that make reliability boring.

TypeScript and the death of “clever JavaScript”

JavaScript frameworks come and go, but TypeScript keeps converting skeptics into believers. The key isn’t that TypeScript is trendy—it’s that it makes large codebases survivable.

In practical terms, TypeScript doesn’t just “add types.” It gives teams:

Safer refactors: rename a function, and the compiler tells you what breaks.
Better navigation: IDEs can infer intent, not just syntax.
More maintainable APIs: teams can publish contracts instead of tribal knowledge.

This is why TypeScript moved from “nice-to-have” to default behavior. It meshes with how real engineering teams work: multiple services, multiple contributors, and a constant need to reduce regressions. When JavaScript gets messy, TypeScript offers a steady, incremental escape route.

Here’s a concrete way to adopt it without burning time: enable checkJs in the parts of your codebase with the highest churn, then ratchet strictness module-by-module. Your goal isn’t to go fully strict on day one—it’s to build confidence quickly, so the habit sticks.

PostgreSQL: the boring choice that keeps winning

Databases don’t win on marketing. They win on reliability, performance you can reason about, and operational transparency.

PostgreSQL’s rise in this period reflects a familiar pattern: once teams hit the limits of “simple enough,” they look for a database that can grow with them. PostgreSQL delivers that growth path through robust indexing options, predictable transactions, solid query planning, and a mature ecosystem around tooling and migrations.

The important part is that PostgreSQL rewards competence. If you write queries thoughtfully and design schemas carefully, you get stable performance and fewer surprises. That creates a loop:

Better defaults reduce incidents.
Fewer incidents reduce rework.
Rework reduction makes teams more willing to invest in deeper optimization.
Investment leads to stronger institutional knowledge.

MySQL didn’t “lose” so much as PostgreSQL pulled ahead in scenarios where teams needed more flexibility and fewer compromises. If you’re choosing today, treat this as a process: match the database to your workload and operational tolerance, not your preference for one vendor’s branding.

Docker (+17 points): packaging reality into something teams can trust

Some tools survive hype because they turn invisible complexity into a repeatable artifact. Docker is a masterclass in this: it packaged “works on my machine” into something testable and deployable.

The real win wasn’t containers as a concept—it was containers as a workflow:

consistent runtime environments across dev, CI, and production
faster onboarding (“here’s how to run the service”)
safer experimentation (spin up a new version without wrecking the baseline)
pragmatic isolation for dependencies

If Docker has a credibility advantage, it’s because it’s not asking teams to believe in an ideology. It’s asking them to stop arguing about environment drift. That’s why adoption tends to stay sticky once teams integrate it into CI pipelines and release processes.

A practical tip: treat your Dockerfile like part of your production surface area. Use multi-stage builds, keep images small enough to scan and reason about, and pin versions where it matters. The hype ends; the build discipline remains.

Rust and FastAPI: when ergonomics and performance meet

Rust and FastAPI are often discussed separately, but they rhyme: both provide immediate developer value while enabling serious performance and correctness goals.

Rust survived because it takes safety seriously without pretending trade-offs don’t exist. Teams that adopt Rust typically do it for:

stronger guarantees that reduce production failures
performance that doesn’t require contortions
a tooling ecosystem (cargo, formatting, linting) that encourages consistency

Admittedly, Rust can feel demanding at first. That’s why “most admired four years running” matters: admiration follows adoption that sticks. People don’t love Rust merely because it’s fashionable—they love it because, once the team clears the learning curve, the toolchain makes quality easier.

FastAPI, meanwhile, is a case study in aligning a framework with how developers actually build APIs: concise code, strong validation, and automatic documentation that saves hours. It also integrates smoothly into modern Python service patterns, which lowers the cost of switching frameworks mid-stream.

If you’re evaluating FastAPI, a good strategy is to start with a single service boundary—one that already has a clear request/response contract. Let the framework prove itself by improving maintainability (docs, validation, typed models) instead of asking you to rewrite everything at once.

The losers: where hype tried to solve imaginary problems

The most instructive failures aren’t subtle—they’re painfully obvious in hindsight.

Web3: billions burned, nothing shipped (at the level teams needed)

The Web3 story, at least as it played out in many engineering orgs, reads like a marketing-driven detour. Teams chased novelty without securing the practical foundations required to ship stable systems for ordinary users—reliability, governance that doesn’t collapse under edge cases, developer tooling that doesn’t punish iteration, and clear economic incentives that hold up under real usage.

The lesson for developers is uncomfortable but straightforward: if you can’t explain your system’s operational model in plain engineering terms, you’re probably not building a production platform—you’re building a belief system.

The NoSQL-for-everything movement: abstraction can’t replace design

NoSQL didn’t fail because it’s inherently bad. It failed when it became a reflex. The “NoSQL-for-everything” mindset treated the database as a branding decision rather than a workload-specific engineering choice.

The durable takeaway: databases are tools with trade-offs. If your access patterns are known and your consistency requirements are clear, relational databases can be an excellent fit. When teams insisted on schemaless flexibility for every problem, they often paid later in complexity: harder migrations, inconsistent data models, and debugging that became a team sport.

JavaScript frameworks built for cleverness over experience

Every cycle brings a new front-end framework that promises to “change everything.” Many of them prioritize novelty or marketing narratives over the day-to-day developer experience: predictable ergonomics, excellent error messages, stable APIs, and tooling that integrates cleanly into real projects.

A good framework doesn’t just make demos impressive. It makes maintenance cheaper. If switching tools improves productivity for both new and existing developers, adoption follows. If it mainly improves press coverage, the ecosystem becomes a treadmill.

What to do in 2026: pick tools by evidence, not vibes

So how do you avoid repeating the same hype-cycle mistakes? Use a short checklist that forces signal over style:

Ask what problem it removes. If the answer is “faster” or “revolutionary,” demand specifics.
Look for compounding assets. Mature documentation, examples that resemble production, and tooling that doesn’t require heroics.
Evaluate migration cost early. If adoption requires a rewrite, run a pilot with a clear exit plan.
Measure developer experience, not excitement. Time-to-debug, refactor safety, clarity of error messages, and how quickly new teammates become effective.
Check whether the ecosystem supports operational reality. Monitoring, deployment patterns, and predictable runtime behavior.

In other words: reward technologies that help you build and run software with less friction, not ones that help you win arguments on Twitter.

Conclusion: the winners weren’t magical—they were useful

Across 2022–2025, the technologies that survived hype did so because they solved real engineering problems in ways that compound over time. TypeScript made large JavaScript systems manageable. PostgreSQL offered dependable growth without constant trade-off drama. Docker turned environments into repeatable artifacts. Rust and FastAPI earned admiration by improving quality and developer speed. The losers—Web3 hype, NoSQL-for-everything impulses, and frameworks driven more by clever marketing than real ergonomics—didn’t fail because they were interesting. They failed because they didn’t reliably reduce friction in production.

The pattern is the point: technologies that make real work better tend to endure. Technologies that mostly satisfy anticipation tend to evaporate.

Deno 2.0: The Second Act That Might Actually Work

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 03 Nov 2025 00:00:00 +0000

Deno 1.0 arrived with a bold thesis: stop trusting the web’s “it works on my machine” past, and build a safer, cleaner runtime for modern JavaScript and TypeScript. But the first act also came with friction—especially around npm compatibility and the ecosystem gravity of Node. Deno 2.0 flips the story. It doesn’t ask you to abandon npm. It meets you where you already are, then layers Deno’s security and developer experience on top. That shift is small in wording and massive in impact.

From “purity” to pragmatism

Deno 1.0’s original proposition was understandable: eliminate global package state, make permissions explicit, and simplify TypeScript by treating it as first-class rather than an afterthought. But “simplify” turned into “retrain,” and “rethink the ecosystem” turned into “pay the switching tax.”

Deno 2.0 changes the tone. The goal is no longer to win a philosophical debate about package management. The goal is to make Deno the default choice for teams building real systems—where dependencies already exist, documentation already assumes Node, and libraries aren’t going to rewrite themselves just because a runtime asks nicely.

You can feel this in the design: Node compatibility isn’t treated as a concession. It’s treated as a product feature.

Node compatibility: the ecosystem door swings both ways

The easiest way to understand why this matters is to picture how Node projects actually live. They don’t start with “Hello, world.” They start with “we have a working dependency tree,” and then they build from there: authentication, ORMs, queue clients, cloud SDK wrappers, testing utilities—plus a thousand smaller choices that accumulate over years.

Deno 2.0 acknowledges that reality. Instead of forcing teams to rebuild the dependency landscape from scratch (or maintain awkward compatibility layers), it leans into compatibility so existing packages can be brought along with less pain.

Practical payoff: you can move a project without turning it into a migration war.

For example, suppose you have a Node service that depends on an established HTTP stack and a validation library. In the Deno 1.0 world, the decision might have been “rewrite to Deno style” or “stay on Node.” In the Deno 2.0 world, you can evaluate moving portions of the system first—starting with the parts that benefit from Deno’s strengths (security and TypeScript ergonomics) while keeping the rest familiar.

That’s how adoption happens in the real world: not by converting the entire enterprise in one weekend, but by proving value in small, low-risk slices.

npm support: stop fighting the thing people already use

If Node compatibility is the door, npm support is the hinge. npm is where most projects—and most developers’ instincts—already point. You install packages. You update them. You rely on semver behavior. You search npm for examples when you hit edge cases you can’t afford to reinvent.

Deno 2.0’s npm support means you don’t have to ask your team to stop doing the one thing they already know how to do. It also removes a common adoption blocker: the fear that “Deno means extra work forever.”

A practical way to test this is to run a small dependency-heavy project. Choose one that uses a mix of transitive dependencies, not just a couple of simple libraries. If your biggest hurdle becomes “convert imports,” you’ll feel that pain quickly. If your biggest hurdle becomes “fix a handful of runtime differences,” you’re already in a healthier migration posture.

The important shift is emotional as much as technical: Deno 2.0 makes it easier to say “yes” without feeling like you’re signing up for perpetual conversion.

First-class TypeScript, without the build ritual

One of Deno’s strongest early claims was TypeScript without configuration. In practice, that meant fewer moving parts: no extra toolchain required just to get type checking and module resolution working.

Deno 2.0 keeps that advantage, and it becomes more compelling when paired with npm-era expectations. Teams don’t want to pick between “nice TypeScript” and “use the same packages the rest of the world uses.” They want both.

Consider a typical Node service that uses TypeScript. In many teams, TypeScript integration requires a patchwork of config files, build steps, and “just remember to run the right commands.” Deno’s model often collapses those steps into a simpler workflow: write TypeScript, run it directly, and rely on a runtime that understands the language without turning it into a complicated build chore.

Pragmatic advice: when adopting Deno 2.0, aim to keep your developer loop tight. Start with a small service. Ensure it compiles and runs predictably. Then expand. You’ll get the most value when developers can iterate quickly without fighting compilation or module resolution at every step.

Deno’s security model still matters—especially after Node gets easier

The story could have ended at “Deno now supports npm,” and that would still be useful. But Deno isn’t merely a compatibility layer. Its security model is the reason many teams wanted Deno in the first place.

The core idea is simple: don’t let programs access the system by default. Make permissions explicit. In Deno 2.0, Node compatibility and npm support don’t erase that—if anything, they make it more valuable. When you can reuse packages from the wider ecosystem, you also reuse their assumptions about the world. Deno’s permission model becomes the safety net that helps you keep those assumptions from turning into accidental vulnerabilities.

Practical framing: treat permissions as part of your deployment contract. Decide what your service should be allowed to do—network access, file reads, environment variable access—and enforce it at runtime. That way, even if a dependency goes sideways, the blast radius is smaller.

In other words, Deno 2.0 makes “safe by design” more realistic for teams using real-world dependencies.

Package.json and the end of awkward module expectations

Deno 1.0 leaned heavily on URL-based imports and a “bring your own dependency graph” philosophy. That model can feel elegant until you’re forced to integrate with tooling, CI pipelines, or dependency conventions that expect package.json.

Deno 2.0 supports package.json, which matters more than it sounds. package.json is not just a manifest; it’s the gravitational center of the JavaScript ecosystem:

Scripts like test, build, and lint
Dependency pinning and lockfile workflows
Shared conventions across teams and repositories
Compatibility with common tooling that expects npm-style project structure

Practical advice: if you’re migrating, don’t try to fight the shape of the ecosystem. Embrace package.json early so your team’s workflows remain recognizable. Then layer Deno-specific workflow changes gradually—permissions, runtime flags, and deployment specifics.

This is how you avoid the most common failure mode of new runtimes: winning the runtime argument while losing the team’s daily routine.

The adoption checklist for teams considering Deno 2.0

If you’re evaluating whether Deno 2.0 “might actually work,” treat it like a migration decision, not a faith decision. Here’s a practical checklist that keeps the process grounded:

Pick a real service, not a toy. Something that uses a few non-trivial dependencies, like an auth helper, a database client, or a request router.
Validate TypeScript workflow end-to-end. Ensure type checking and developer iteration feel better—not merely different.
Test npm dependency usage early. Confirm that the packages you rely on behave correctly in Deno’s runtime model.
Define permissions explicitly. Decide what the service needs and lock it down. Treat permission failures as good signals, not annoyances.
Run CI in a way your team already understands. If your team uses scripts and lockfiles, make sure the Deno integration matches those expectations.
Measure complexity, not ideology. If the migration ends with “we fixed some code and reduced risk,” it’s a win. If it ends with “we invented a new process for every step,” you’re not winning.

This checklist is deliberately not about whether Deno is “more pure” than Node. It’s about whether it reduces friction while improving safety and developer experience.

Conclusion: Deno 2.0 is what happens when a runtime stops asking permission

Deno 1.0 asked developers to rethink their ecosystem choices. Deno 2.0 stops asking and starts cooperating. Node compatibility and npm support remove the biggest adoption barrier. package.json support eliminates the daily friction of fighting conventions. And a mature, first-class TypeScript experience keeps Deno’s original promise intact—without forcing teams into a perpetual rewrite.

Most importantly, Deno’s security model doesn’t get watered down by compatibility. It becomes more relevant precisely because real-world dependencies are now easier to bring along.

This is the second act Deno needed: not a retreat from its ideals, but an expansion of its usefulness. If you’ve wanted Deno’s ideas without the ecosystem cost, Deno 2.0 feels like the moment the price tag finally matches the value.

Why I Think 2025 Is the Most Exciting Year to Be a Developer Since 2007

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 28 Oct 2025 00:00:00 +0000

In 2007, a device hit the market that didn’t just ship better apps—it changed what software was. In 2025, AI agents are doing the same thing, except faster, messier, and arguably more consequential. If you’ve felt a familiar itch—like you’re watching the next platform form in real time—you’re not imagining it. The parallels with the iPhone era are uncanny, and the window for builders is open right now.

1) The platform shift: from “app” to “agent”

The iPhone didn’t magically improve mobile apps. It created a new interaction model—touch, gestures, always-with-you distribution—and developers had to reinvent their mental model of UI, navigation, and data flows. The winners weren’t the people who “ported” their desktop app to a smaller screen. They were the people who designed around the device’s new reality.

Agent systems are forcing the same pivot. Instead of thinking in terms of “screens and buttons,” you’re building systems that can interpret goals, take actions across tools, and recover from failure. In practical terms, an “agent” application looks less like a traditional workflow app and more like a living collaboration between:

an LLM (reasoning + language),
tools (APIs, code execution, browsers, databases, task runners),
memory (what the system knows about the user and the task),
policies (what the agent is allowed to do),
and orchestration (how the system decides, calls tools, and verifies outputs).

Here’s a concrete example: in a customer support product, a conventional app might provide a ticket UI and search. An agent-first approach can handle the full loop: interpret the user’s message, locate relevant documentation, draft a response, check policy constraints, and either send it or request approval. The “feature” isn’t a screen—it’s the end-to-end capability.

That’s the platform shift. You’re not just adding intelligence to an existing product; you’re redesigning the product around a new unit of value: autonomy with guardrails.

2) Interaction paradigms are changing (again)

In the iPhone era, “mobile-first” wasn’t a slogan—it meant you designed for thumbs, latency, attention, and constrained input. You couldn’t assume a keyboard, hover states, or multi-tab workflows. You rethought interaction.

In 2025, “agent-first” is still settling, but the direction is clear: natural language as the primary interface, and tool-driven execution as the new output. That creates new design constraints you can’t ignore:

Uncertainty is part of the experience. Agents will be wrong sometimes. Your product must make failure modes legible and recoverable.
Action beats narration. Users don’t just want explanations; they want tasks completed—booked, updated, summarized, created.
Verification becomes UX. “Trust me” doesn’t scale. Interfaces will increasingly show what the agent did, why it decided, and what it verified.

A helpful way to frame your work: don’t start with “What should the agent say?” Start with “What should the agent do safely?” Then design the prompts, tools, and UI to support that contract.

One practical pattern: two-step confirmation for high-impact actions. For example, an agent that manages invoices can draft a change request first (“I’m proposing to update vendor terms; I will notify accounting and attach this PDF.”). Then require explicit confirmation before committing changes. Users get speed without losing control.

3) Distribution channels will reward different builders

Mobile changed distribution overnight: the app store, push notifications, background execution constraints, and viral sharing mechanics shaped what “good” looked like. Developers who understood those channels—how users discover, install, and retain—outperformed those who treated distribution as an afterthought.

Agent systems are likely to spread through different rails:

embedded inside existing products (CRMs, IDEs, email, spreadsheets),
through chat or workflow front-ends people already use,
via integrations that turn “actions” into reusable capabilities,
and via marketplaces for agent tools (the equivalent of app marketplaces, but centered on functions and connectors).

If you’ve built a useful integration before, you already get the dynamic: the value accrues to the ecosystem pieces that are easiest to plug into. For agent-first products, this means you should prioritize:

clean tool interfaces (inputs/outputs you can trust),
predictable side effects (what happens when the agent calls your API),
and strong observability (logs, traces, and human-readable audit trails).

Ask yourself: could your capability be dropped into someone else’s agent runtime tomorrow? If yes, you’re building in the direction of platform gravity.

4) New business models: autonomy needs pricing and accountability

The iPhone era didn’t just create new technology; it created new monetization models—paid apps, freemium, subscriptions, app bundles, and ad ecosystems built around mobile usage patterns.

Agent-first systems complicate monetization because the “unit of value” shifts from UI features to outcomes. Users pay for results, not for screens. But autonomy also introduces variable cost: tool calls, model inference, retries, and—most importantly—human review when things go wrong.

In practice, you’ll probably end up with pricing that reflects one of three realities:

Seat-based (for teams using an agent in a product like a developer tool or internal ops assistant),
Usage-based (per task, per action, per successful resolution),
Outcome-based (rare early, but compelling once reliability improves: “bookings made,” “incidents resolved,” “tickets closed”).

My opinion: the best early agent products won’t pretend they can price perfectly. They’ll align cost to user value and make trade-offs explicit. For example, you can offer “fast draft” vs “verified and approved” modes. The cheaper mode is useful and quick; the verified mode costs more but reduces risk. That’s how you monetize autonomy while respecting the fact that agents are still learning.

5) The hard part isn’t “the model”—it’s the system

In 2008, plenty of people could build a basic mobile app. The generational outcomes came from those who solved the unsexy problems: performance, battery usage, flaky network behavior, state management, and platform conventions.

In 2025, the shiny part is easy to demo: prompt an agent, get a useful response, show off a tool call. The generational outcomes will come from the systems work that makes agents dependable:

Tool reliability: timeouts, idempotency, retries, and consistent schemas.
State and memory: what the agent remembers, what it forgets, and how that affects correctness.
Policy enforcement: role-based permissions, allowed operations, and safe browsing.
Evaluation and regression testing: you need measurable behaviors, not vibes.
Observability: traces that answer “why did it do that?” in minutes, not hours.

A concrete build plan for a team (or a solo builder) that wants to stand out fast:

Pick one workflow where mistakes are costly but recoverable (e.g., drafting internal docs, summarizing meeting actions, generating code changes with review).
Implement the agent as a pipeline: plan → act via tools → verify → (optionally) ask a human.
Log everything: tool inputs/outputs, intermediate decisions, and verification outcomes.
Create a small eval suite: 50–200 representative tasks with expected behaviors.
Ship a “conservative” mode first, then expand autonomy as reliability improves.

The developers who do this will build products that people trust. Trust is the platform.

6) Why the timing feels like 2007 all over again

Here’s what made mobile in the late 2000s special: the rules weren’t fully standardized yet. Nobody agreed on best practices. APIs evolved quickly. UI patterns were still forming. But the market was moving, and the people who experimented early learned faster than the people who waited for consensus.

Agent-first development is in that same chaotic but fertile stage. The interaction model isn’t settled, the tooling ecosystem is still consolidating, and best practices are emerging through hard experience rather than textbooks. That’s exactly when developer leverage is highest.

If you want a “generational outcome” mindset, borrow the mobile-era lesson: don’t just chase the novelty. Chase the fundamentals people will still need after the hype cools down:

designing for reliability,
building clean integrations,
instrumenting the system end-to-end,
and making automation safe enough to scale.

7) A personal rule: build something that will still be valuable when agents get better

The iPhone platform didn’t just reward people who built apps—it rewarded those who created experiences aligned with the new interaction reality. The equivalent test for agents is simple: if your agent got 10x smarter next year, would your product still matter?

If your answer is “no,” you’re probably building around a temporary capability. If your answer is “yes,” you’re building around a workflow, a trust model, or an integration surface that will remain essential.

Start small and concrete:

Build an agent that does one job end-to-end with verification.
Make the tool interfaces clean enough to reuse.
Provide an audit trail users can understand.
Add a human-in-the-loop escape hatch.
Focus on outcomes, not demos.

The window is open because the platform is forming. That doesn’t guarantee success—but it does guarantee learning velocity. And learning velocity is how you earn leverage.

Conclusion: The iPhone lesson, applied to 2025

We’ve seen this movie before. A new platform arrives, interaction changes, distribution shifts, business models evolve, and the surface area of unsolved problems explodes. In 2007, developers who built for mobile early shaped entire careers. In 2025, developers who build for agents early will do the same—because they’ll understand what “agent-first” really means: autonomy with accountability.

So don’t wait for the perfect definition. Find a real workflow, build the reliable loop, measure what matters, and ship. 2025 isn’t just an exciting year to be a developer—it’s a year to become one in a new way.

Zero-Knowledge Proofs Are the Sleeper Technology of the Decade

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 22 Oct 2025 00:00:00 +0000

For years, zero-knowledge proofs (ZKPs) lived in the shadowy corner of crypto research—fascinating, clever, and mostly optional. That’s changing. ZKPs have quietly matured into a general-purpose privacy technology: you can prove a claim without exposing the data behind it, and you can even prove that a computation was performed correctly without redoing the computation itself. If blockchain was the headline, authentication and verification are the next act—and they’ll matter more to everyday users than another token launch.

This is why ZKPs are the sleeper technology of the decade: they solve a problem everyone has (privacy and trust), in a way that’s becoming practical (libraries, tooling, and composable designs). Let’s talk about what ZKPs actually do, where they’re landing now, and how teams can prepare.

The core idea: prove the statement, not the secret

A zero-knowledge proof lets you convince a verifier that a statement is true without revealing why in a way that leaks sensitive information. Think of it like showing you passed an exam without showing your entire work—or showing you’re eligible for a service without disclosing your birthdate, income, or identity documents.

A classic framing is “prove you’re over 21”:

You want to hide the birthdate (and everything else you typed into the form).
You want to prove eligibility (“I’m at least 21 now”).
A verifier should be convinced without learning the exact date.

In ZK terms, your client generates a proof that it satisfies a constraint like: now - birthdate >= 21 years. The verifier checks the proof using only public inputs (like “the cutoff date” or “current timestamp rules”) and never learns the birthdate itself.

This is the key shift: privacy isn’t an afterthought or a masking trick; it’s encoded into the verification mechanism. That’s a fundamentally different design pattern from “encrypt the data and hope the system works.”

ZK identity: privacy-preserving authentication that actually scales

Identity is where ZKPs become immediately compelling. Today, many onboarding flows are privacy-hostile by default: you submit documents, systems store them, and “trust” often becomes “we have your data.” Even if you use encryption and access controls, the data still exists—and breaches still happen.

ZK-based identity can change the shape of the interaction. Instead of handing over raw attributes, a user proves properties about themselves:

Age gates: “Over 21” or “Under 18,” without revealing birthdate.
Residency: “Resident of jurisdiction X,” without exposing full address.
Eligibility: “Member of organization Y” or “Passed compliance checks,” without disclosing the underlying records.
Account access: “This device belongs to an enrolled user,” without exposing identifiers beyond what’s needed.

Here’s a practical example for a consumer product:

The user’s wallet (or identity app) holds credentials from a trusted issuer.
When the user needs access to age-restricted content, the app creates a ZK proof: “I satisfy the predicate for age eligibility.”
The content provider verifies the proof and grants access—without ever receiving the birthdate or document scans.

From a system design perspective, the win is twofold:

Minimized data exposure: fewer sensitive attributes cross trust boundaries.
Flexible compliance: you can design proofs around specific policies (“only reveal what’s necessary”) instead of collecting everything “just in case.”

The operational reality is that teams should treat ZK identity as a protocol problem, not a “drop-in library” problem. You’ll need a clear issuer/verifier model, well-defined public parameters, and a threat model for things like replay attacks, revocation, and jurisdiction changes. ZKPs don’t remove engineering—they concentrate it in the right places.

Verifying computation integrity: proofs without re-running the work

The second big unlock is computation integrity. Many systems need to ensure that some action was computed correctly, but re-running the computation can be expensive, slow, or impossible to do trustlessly.

ZK proofs address that. The prover performs the computation once (locally or in a trusted environment) and then generates a proof that the computation followed the rules. The verifier checks the proof quickly, without re-executing the computation.

This shows up in two common patterns:

Third-party computation: If you outsource data processing or inference, ZK proofs can let you verify correctness without redoing the entire workflow.
On-chain or constrained verification: If verification must happen in a limited environment (like smart contracts or secure hardware), ZKPs provide a compact way to validate results.

A simple mental model: today, “verification” often means re-execution or trusting a result. With ZK, verification becomes “check a certificate.” Your systems shift from “do the work twice” to “do the work once, then verify efficiently.”

The more you care about correctness under privacy constraints, the more ZKPs start to look like the missing primitive. You get integrity with less data movement—a combination that’s hard to replicate with conventional cryptography alone.

zkVM and arbitrary program execution: from toy statements to real software

In early ZK systems, proving was often limited to hand-crafted circuits: you translate logic into an arithmetic form that the ZK system can prove efficiently. That translation can be tedious, and it limits what you can prove quickly.

That’s why zkVM-style approaches matter. A zkVM is a virtual machine designed so that you can generate a ZK proof for running an arbitrary program, not just a small set of specialized computations. In other words: write code, compile it, prove that it ran correctly.

One prominent example is RISC Zero’s zkVM, which targets the idea of proving program execution for a RISC-V instruction set. Practically, this means you can aim for a workflow closer to:

Write or compile the program you want to verify.
Execute it to produce outputs.
Generate a zero-knowledge proof that the program executed correctly over the inputs.

This doesn’t magically eliminate complexity, but it reduces the “circuit translation tax” that previously made many ZK applications feel like research projects. It also makes ZK more composable with the way software teams already work: compile, test, prove, verify.

A good way to think about zkVMs is as the bridge between cryptographic theory and developer ergonomics. They turn ZK from “prove this math identity” into “prove this software behavior.”

What it means for authentication, compliance, and privacy

ZKPs aren’t just a technical curiosity—they’re a reshaping force for how verification works across regulated and privacy-sensitive domains.

Authentication: fewer secrets, fewer leaks

Instead of collecting sensitive attributes and storing them, systems can verify predicates. Users get control, providers get assurance, and attackers get less.

For teams implementing ZK authentication, a practical rule is to start with one predicate that maps cleanly to policy. Don’t begin with “full identity.” Begin with “over 21,” “passed KYC,” “owns required credential,” or “has authorization granted by issuer X.”

Compliance: prove policy adherence, not document contents

Compliance often demands proof that you followed rules. ZKPs let you prove compliance conditions without exposing the raw documents—especially valuable when you must show eligibility while minimizing sensitive disclosures.

Data privacy: reduce the blast radius

Even if your encryption story is strong, breaches are still possible. ZK helps by design: if the server never receives the birthdate, an attacker can’t steal it from that server.

This is the part most teams underestimate. ZK is not just about “privacy-friendly storage.” It’s about privacy-preserving verification, meaning less sensitive data crosses boundaries in the first place.

How to adopt ZKPs without getting lost in the math

Let’s be blunt: ZKPs can be mathematically dense, and it’s tempting to either overhype them or wait until they become effortless. The reality is that you can adopt them now with a pragmatic approach.

Pick a narrow use case with clear predicates.
Age checks, eligibility flags, credential possession, or “computation result validity” are better than “prove everything about me.”
Design the verification interface first.
Decide what inputs are public, what outputs must be verified, and what the verifier actually needs to trust. A good ZK system fails less when the boundary is crisp.
Lean on existing tooling and proven libraries.
You don’t want to implement cryptography from scratch. Use established libraries, reference zkVM workflows, and existing proof systems tailored for your environment.
Treat performance as a product constraint.
ZK proofs have costs—proof generation time, verification overhead, and infrastructure considerations. Benchmark early using your target hardware and realistic statement sizes.
Plan for revocation and policy updates.
If credentials expire, jurisdictions change, or rules evolve, you’ll need a strategy. Many ZK designs assume relatively stable public parameters; you should plan what happens when they’re not.

If you do these things, you’ll avoid the two common failure modes: building a “cool proof” that doesn’t integrate, or building a system that integrates but can’t meet performance and operations requirements.

Conclusion: the privacy-and-trust layer hiding in plain sight

Zero-knowledge proofs are the sleeper technology because they don’t chase adoption with flash—they quietly improve the foundations of verification. Identity becomes attribute-based without data hoarding. Compliance becomes proof of policy adherence without document sprawl. Computation integrity becomes a certificate-check instead of re-execution.

The next decade won’t be defined by ZKPs replacing everything. It’ll be defined by ZKPs becoming the default answer to a recurring question: How do we prove trust without exposing the sensitive parts? As zkVM approaches and libraries mature, the transition from research-grade demos to production-grade systems accelerates. The teams that start planning now—around predicates, interfaces, and operational realities—will ship the next generation of authentication and verification while everyone else is still debating what “privacy” should mean.

htmx 2.0 and the Maturation of the Hypermedia Renaissance

abdecastro@protonmail.com (Antonio B De Castro) — Fri, 10 Oct 2025 00:00:00 +0000

For years, the “just use HTML” crowd was easy to dismiss as nostalgia. Then something happened: interactive apps got good enough that you stopped needing a JavaScript build pipeline for every UI. htmx didn’t just revive hypermedia—it made it practical, then repeatable. With htmx 2.0, the hypermedia renaissance isn’t a clever side project anymore; it’s becoming a legitimate architectural default for internal tools and framework-driven teams.

From rebellion to architecture: why “hypermedia” finally stuck

The early hypermedia argument was philosophical: HTTP is already a messaging layer, and HTML is already a UI language. Server-rendered pages aren’t inherently static; they’re just missing the wiring for partial updates and event-driven interactions.

What changed is that teams stopped asking, “Can we avoid JavaScript?” and started asking, “Can we ship faster with fewer moving parts?” That shift is why htmx found a home in everyday product engineering.

In practice, “hypermedia” with htmx means:

You keep your UI as HTML (and server templates).
You enhance it with small attributes that trigger requests and swap fragments.
You let the server remain the source of truth for UI state and validation.

This is especially attractive for internal applications—dashboards, admin panels, CRUD-heavy workflows—where the UI often looks complex but behaves like a set of forms, tables, filters, and modal interactions. Those interfaces don’t require a full SPA framework to be excellent. They require responsiveness, correctness, and maintainability.

What htmx 2.0 improves: smaller surface area, smoother extension, steadier streaming

htmx 2.0 brings meaningful “day-to-day” improvements: a smaller bundle, a better extension system, and improved support for Server-Sent Events (SSE). Even if you don’t care about internals, these are the kinds of enhancements that reduce friction when you’re building a real product instead of a demo.

1) Smaller bundle, less penalty for “just use htmx”

When a library is lightweight, it’s easier to justify adoption across a large codebase. You don’t hesitate to include it on every page, and you’re less likely to end up with inconsistent patterns where only certain sections of the app use enhanced behaviors.

A practical effect: you can progressively enhance. Start with a single endpoint powering an “inline edit” or “filter results” view, then expand without turning the rest of your templates into a legacy-free zone.

2) A better extension system means fewer one-off hacks

Every team has a moment where “we’ll just add one helper” becomes “we now maintain three parallel mini-frameworks for behavior.” A better extension system reduces that drift.

Think about how extensions help with consistency:

Standardize how you handle error rendering across requests.
Build reusable abstractions for common UI patterns (confirmation dialogs, optimistic spinners, accessibility-friendly focus management).
Encapsulate analytics hooks so behavior isn’t scattered across templates.

3) Improved SSE support makes streaming UIs feel native

SSE is a natural fit for internal tools: live activity feeds, long-running job updates, background processing status, and “processing…” progress bars that don’t require WebSocket complexity.

With better SSE support, you can:

Stream status updates into a single DOM region.
Keep the rest of the page stable.
Avoid a “replace the world” approach typical of SPAs when the only changing part is a small component.

If your users are waiting for the back office to finish processing an import, SSE-driven updates make the app feel responsive without building a realtime platform.

How enterprise teams actually adopt htmx: start with workflows, not ideology

The adoption pattern that keeps repeating is simple: teams pick one class of workflows where server-rendered HTML already makes sense, then add interactivity where it matters. That’s where htmx shines—because it doesn’t ask you to rewrite your app’s mental model.

Here’s a concrete example that shows the usual progression:

Example: an admin “user management” screen

Start with the classic server-rendered page:

A table of users
A search filter
A “disable account” action

Next, add just enough interactivity:

Submitting the search filter updates the table via a partial request.
Clicking “disable account” opens a confirm prompt that triggers a server action.
The table row updates in-place after the action completes.

You end up with an interface that feels modern, but the architecture remains stable:

The server renders the fragments.
The client swaps them into place.
Validation, authorization, and business logic stay on the server.

This is how hypermedia becomes “legitimate.” It isn’t a replacement for application logic—it’s a smarter way to deliver UI logic without dragging in a build system for everything.

The key advantage: fewer cross-layer bugs

When UI state and business state are separated (common in SPA architectures), you inevitably get mismatches:

The server rejects an update; the UI assumes success.
A race condition changes data; the UI is stale until a manual refresh.
Validation logic exists in two places and diverges.

With htmx, the server remains authoritative. The UI reflects the server’s decisions because the server returns the view (or the fragment) that the client applies.

That’s not just developer ergonomics—it’s fewer production surprises.

Pairing with Django and Rails: interactive UIs without a JavaScript build system

If you’re a Django or Rails developer, the appeal of htmx is obvious: your framework already excels at server-rendered views, routing, and forms. htmx lets you keep those strengths while upgrading the interaction model.

A typical pairing looks like this:

Django/Rails serve HTML templates as usual.
htmx requests call the same endpoints (often with partial templates).
Your templates contain the behavior annotations where it’s needed.

Practical pattern: “HTML forms, but faster feedback”

Suppose you have a form that validates input and displays field errors. In a SPA, you might build a client-side form state machine. In an htmx approach, you:

Submit the form normally (or via htmx).
Return either:
- A success fragment (e.g., updated profile card), or
- The form with validation errors rendered inline.

Users get immediate feedback without the burden of maintaining parallel validation logic. You can also keep accessibility straightforward because your forms remain real forms.

Practical pattern: “Tables that filter and paginate”

Most internal tools live or die by data exploration. With htmx:

Pagination links become htmx requests.
Sorting and filtering triggers partial updates.
The page keeps its overall layout, while the data region swaps.

It’s the “it feels like an app” effect without pretending you built a frontend platform.

Where htmx is not the answer: complex SPAs still have a place

A mature architectural stance means knowing what you’re not replacing. htmx isn’t a universal hammer. If your product needs a highly interactive, client-heavy experience—think complex canvas editing, offline-first behavior, or deeply stateful workflows—React or other SPA approaches can still be the right tool.

The important point is that the “SPA by default” mindset was never justified for most applications. Many teams built full client apps to render pages that are mostly server-meaningful anyway. For those apps, the cost of SPA architecture—bundling, state synchronization, build tooling, and ongoing UI complexity—was disproportionate.

htmx doesn’t invalidate SPAs. It rebalances the decision. The question becomes:

Does this UI benefit from a rich client runtime?
Or does it mostly need fast, correct, interactive server-driven rendering?

For many enterprise and internal workflows, the second answer wins.

The hypermedia renaissance, now mainstream: what production teams are learning

The hypermedia renaissance matured when teams stopped treating it as a lifestyle brand and started treating it as a delivery mechanism. htmx 2.0’s improvements accelerate that shift: better performance, better extension ergonomics, and more robust streaming support make it easier to scale from prototypes into production.

In my view, the most important lesson is cultural: you don’t “graduate” to htmx by announcing it in a blog post. You graduate by building one area of your app the healthier way—then noticing the difference:

Faster iterations because you’re editing templates, not frontend state logic.
Fewer integration layers between server and UI.
Easier correctness because the server renders the truth.

Then you expand. Not because it’s trendy, but because it reduces the overhead that keeps enterprise teams stuck.

Conclusion: a quieter kind of modern

htmx 2.0 is not a dramatic revolution. It’s a refinement—and, more importantly, it’s a validation. Hypermedia stopped being an act of contrarian faith and became a stable architectural choice.

If your application doesn’t need a complex SPA runtime, htmx offers a compelling path to interactive UIs with fewer moving parts. And in 2026, “fewer moving parts” isn’t a compromise—it’s a competitive advantage.

The Real Cost of 'Just Use a Microservice'

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 28 Sep 2025 00:00:00 +0000

Microservices are sold as an easy path to speed: ship faster, scale independently, sleep better. In practice, most teams discover a harsher truth—operational complexity doesn’t just add work, it multiplies it. And the gap shows up not in theory, but in infrastructure bills, incident volume, and the calendar time your engineers spend doing things that don’t feel like building.

Below is a data-driven look at what happens when eight teams decomposed monoliths into microservices over roughly three years—and what that means for anyone planning the next rewrite.

What “Scale” Really Means (And Why Most Teams Get It Wrong)

Here’s the core mistake: most discussions treat “scale” as traffic. If your monolith serves 10,000 RPS, you might think you’re already “large enough” to justify microservices. But for microservices to pay off, the scale that matters is organizational—how many independently changing ownership boundaries you have.

A monolith handling 10,000 RPS can be perfectly fine because the system boundary is clear: one deployable unit, one runtime model, one place to reason about failures. The moment you split along team ownership—multiple teams making coordinated changes with different release cadences—you create a different kind of scaling problem: coordination overhead.

In the eight-team pattern observed, teams were often attempting to optimize deployment and scaling by traffic characteristics, even though the real driver should have been organizational autonomy: “Can these components change independently without constant cross-team coordination?” If the answer is “not really,” microservices become a tax collector for everything that used to be internal.

Practical framing: Ask this before you refactor.

If team A deploys independently, can team B reliably consume those changes without waiting on A?
Can you design stable contracts (APIs/events) that won’t break every release?
Do you already have automated integration and observability that make cross-service failures diagnosable within minutes?

If you can’t answer yes, you don’t have a microservices need—you have a monolith that could benefit from modularization.

The Operating Overhead You Don’t See in the Architecture Diagram

The most consistent outcome across the eight teams wasn’t that microservices “failed.” It was that the operational cost rose far faster than the benefits.

Operational costs increased by roughly 3–8×, while deployment velocity improved by only ~1.5×. That discrepancy is the heart of the story. Microservices didn’t prevent slowdowns; they redistributed them.

Where did the overhead come from?

More moving parts, more runtime knobs
You go from “one service with one stack” to N services each with their own configurations, dependencies, versioning, and failure modes. Even if each service is simple, the system is not.
Service mesh and platform complexity
Service mesh can be useful, but it comes with its own operational model: sidecars, traffic policies, certificate management, routing rules, debugging tools, and failure semantics that differ from “plain HTTP.” Teams frequently underestimated how much time is spent validating mesh behavior during incidents and rollouts.
Distributed tracing and metrics pipelines
You don’t just “turn on tracing.” You instrument, configure sampling strategies, manage trace context propagation, ensure dashboards are meaningful, and debug gaps where spans don’t line up. The result is better visibility—but it also means more engineering time maintaining the visibility stack itself.
Cross-service integration testing
Unit tests are not enough. Once behavior spans service boundaries, you need integration tests that can stand up multiple components reliably. Those tests become brittle if contracts evolve quickly or environments aren’t standardized.
On-call rotation expansion
More services means more alerts. Even with better tooling, the number of things that can page someone increases. Teams found they needed more coverage per time window, which directly reduces the time available for feature work.

A concrete example: one team decomposed a monolith into billing, catalog, and orders services. Everything looked clean on day one. But in the first month, their biggest recurring work wasn’t “fixing billing.” It was diagnosing why orders were delayed after catalog responses changed. The issue lived at the seams: contract drift, retry behavior, and inconsistent error mapping. None of that would exist in a monolith because the failure is within one deployable boundary.

Microservices don’t eliminate failure—they relocate it to the interfaces.

Deployment Velocity Didn’t Scale Linearly (Because Integration Is the Real Bottleneck)

Teams expected microservices to make deployments faster. The reality: deployment cadence improved modestly, but release throughput didn’t translate into overall delivery speed because integration costs grew in parallel.

Why does that happen?

Independent deployments still require coordinated correctness.
Even if you can deploy services independently, users experience end-to-end behavior. If you deploy billing today and orders tomorrow, you still need confidence that the combination works.
Backward compatibility becomes a lifecycle, not a promise.
Stable APIs and versioned events are essential—but they also create more work, more code paths, and more test matrices.
Rollbacks become multi-service events.
In a monolith, rollback is one action. In microservices, rollback might mean reverting one service, temporarily throttling traffic, and restoring an older integration contract while other services remain running.

In practice, teams saw a ~1.5× deployment velocity improvement, but that did not match the overhead required to make those deployments safe. If your integration and observability aren’t “first-class,” the pipeline becomes a treadmill: faster builds, slower safe releases.

Practical advice: treat “integration readiness” as a deployment prerequisite, not an afterthought. If you can’t answer:

What happens when service A returns a new shape of error?
How quickly can we trace a user journey across 6 services?
Do we have realistic staging environments with production-like dependencies?

…then microservices will feel like speed with hidden braking.

The Seam Problem: Mesh Complexity, Tracing Overhead, and Contract Drift

If there’s a villain in most microservice stories, it’s the seams—those moments where systems touch. Microservices increase the number of seams, and each seam needs deliberate design and maintenance.

Service mesh complexity

Service meshes can standardize cross-cutting concerns like retries, timeouts, and mTLS. But teams also found mesh configuration itself became a source of subtle failures. Misconfigured retries can amplify load during partial outages. Routing rules can create “works in staging, fails in prod” scenarios. And when incidents happen, debugging mesh behavior often requires specialized knowledge your broader team may not have.

Distributed tracing overhead

Tracing improves diagnosis, but it also adds operational work:

ensure trace context propagation across languages and libraries,
maintain consistent span naming and attributes,
decide sampling to avoid drowning in telemetry,
and keep dashboards actionable.

If you deploy without a mature tracing strategy, the first incidents will be slower because you don’t yet know where to look.

Cross-service integration testing and contract drift

Integration tests are where microservices either earn their keep or reveal their cost. Teams that invested in contract testing, consumer-driven contracts, and automated compatibility checks reduced surprises. Teams that didn’t discovered that the “independent” parts weren’t independent at all—they were coupled through emergent behavior.

Sharp takeaway: microservices demand stronger discipline than monoliths. If you can’t enforce contracts, you’ll pay for it through outages and regression debugging.

When Microservices Actually Make Sense (And When They Don’t)

This is the part people skip, but it’s where the decision becomes obvious.

Microservices are more likely to work when:

Ownership is already split across teams with independent change needs.
You can design stable interfaces (APIs or events) with clear versioning strategies.
You have an operational platform (or time to build one) that makes observability and incident response routine.
You can standardize environments so integration tests run consistently.
The system has true modular boundaries—not just “different folders in a repo.”

Microservices are a bad bet when:

The monolith’s modularity is already improving with internal refactoring.
Most services need synchronized releases to avoid breakage.
Your org isn’t ready for the operational load (on-call coverage, incident culture, tooling ownership).
You’re chasing traffic scaling while organizational coupling remains high.

And yes: a monolith handling 10,000 RPS is often fine. A monolith owned by 10 teams is the scenario that becomes risky—because release coordination becomes the bottleneck, and slow merges drag down throughput.

So the decision should be less “microservices or monolith?” and more “how much organizational coupling are we willing to pay for?”

A Better Path: Modular Monoliths, Then Measured Decomposition

If your goal is speed, the safest route is incremental. A modular monolith can preserve the operational simplicity of one deployable while still structuring code around bounded contexts. You get:

one deployment unit,
fewer seams,
simpler tracing,
and quicker incident recovery.

Then, decompose only the parts that meet the bar for autonomy—where you can articulate ownership boundaries, define contracts, and prove that integration testing and observability are mature enough to keep failures diagnosable.

Practical approach teams used successfully (or wished they had):

Stabilize and document internal interfaces first—even before splitting.
Introduce contract tests while still in the monolith.
Build an end-to-end observability story early, including correlation IDs and trace propagation patterns.
Decompose in slices that reduce coupling, not slices that just “seem different.”

This isn’t anti-microservice. It’s pro-clarity.

Conclusion: Don’t Choose Microservices—Choose Measurable Autonomy

“Just use a microservice” is an architecture reflex, not a strategy. The data from eight teams is blunt: operational costs climbed by 3–8× while deployment velocity improved by only ~1.5×. The productivity gains were eaten by service mesh and platform complexity, distributed tracing overhead, cross-service integration testing, and larger on-call rotations.

Microservices can be the right tool—when the real driver is organizational scale and when you can invest in the seams: contracts, integration testing, and observability. If you can’t, you’re not buying speed. You’re buying a larger system that requires constant operational attention.

Start with modular boundaries. Measure your integration pain. And decompose only where autonomy is real—not where complexity is merely fashionable.

The Rise of Local-First Software and Why It Matters

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 16 Sep 2025 00:00:00 +0000

The best software doesn’t ask permission from the network. It just works—instantly, smoothly, and even when you’re offline. Local-first software flips the old model on its head: instead of treating the cloud as the source of truth and the client as a temporary viewer, it treats your device as the working system. The result is software that feels fast because it doesn’t wait, and resilient because it doesn’t break when the connection does.

What “local-first” actually means (and what it rejects)

Local-first isn’t a marketing slogan; it’s a design stance. In a local-first app:

The source of truth starts on your device. Reads and writes happen locally.
The cloud is a sync destination, not a gatekeeper. It receives changes and distributes them to other devices.
The app can operate without a network. You can create, edit, and reorganize data even if connectivity disappears.
Conflicts are handled by design, not by user prompts. The system merges updates instead of forcing humans to arbitrate.

The rejected alternative is the classic client-server workflow: load from the server, edit, then save back—often with UI logic that turns into a “loading spinner” festival. Even if the network is usually fast, this model keeps injecting round trips into the user experience. Slow networks and flaky Wi‑Fi aren’t edge cases; they’re normal life.

Local-first removes the round trips from the critical path. When you type into a note app, the note appears immediately because it’s written locally. When you reconnect, synchronization happens in the background.

Why the old approach was “good enough” until it wasn’t

For years, many teams treated “offline” as a special mode: store things locally, then reconcile later. That sounds close to local-first, but the practical difference is where correctness lives. In the old approach, the server often remains the authority. The client may cache, but it still depends on server truth.

That becomes painful in four common scenarios:

Concurrent edits across devices
Open the same document on your laptop and phone, edit both, and then watch the conflict resolution dance begin.
Slow or unstable connections
If saves are required to render a “successful state,” the UI will stall. Users blame your app even when the problem is the Wi‑Fi.
Real-time-ish features without real-time guarantees
Systems built around polling or ephemeral WebSocket state can degrade into “looks fine until it doesn’t.”
Complex merge logic
The more structured the data, the harder conflict handling becomes. Teams either simplify the product or punt conflicts to the user.

Local-first doesn’t magically eliminate distributed systems complexity—but it puts the complexity where it belongs: inside the sync layer.

The sync problem: merges without drama

If multiple devices can change the same data offline, you need a sync system that can merge changes deterministically. You can’t rely on “last writer wins” without corrupting user intent. And you can’t afford to ask users to resolve conflicts every time they lose connectivity for ten minutes.

This is the core role of CRDTs (Conflict-free Replicated Data Types). A CRDT is a data structure designed so that:

Each device can apply updates locally.
Updates can be exchanged in any order.
Eventually, all replicas converge to the same state.

The important practical point is not the math—it’s the UX. With CRDTs, you get merge-by-default. Instead of detecting conflicts and escalating them, the system merges changes automatically in a way that preserves intent as much as the model allows.

A concrete example: collaborative notes

Imagine a shared note with a checklist. On your laptop you tick item 3. On your phone you add a new item right below item 2—offline. When you reconnect:

Your local edits are already present on each device.
Sync exchanges the operations.
The CRDT merges them into a single consistent checklist.

Users don’t need to guess which version is “correct,” and the app doesn’t need to block until reconciliation completes. The UI never has to wait for a network round trip to show a usable state.

CRDTs in practice: Automerge and Yjs as the “merge engines”

CRDTs aren’t one monolithic thing. Different CRDT approaches exist, and different ecosystems optimize for different workloads. Two popular building blocks:

Automerge: often used for structured document editing where you want a high-level “document that merges.” It’s a good fit when your app’s data model is rich and you want predictable merging behavior.
Yjs: widely adopted for real-time collaborative editing patterns. It’s commonly paired with providers that handle transport (WebRTC, WebSocket, etc.) and persistence.

The practical takeaway: you don’t build a custom merge algorithm for every feature. You pick a proven CRDT library, model your data as CRDT-managed structures, and let the library handle convergence.

A developer-friendly mindset

To make CRDTs work smoothly, structure your app so that:

Local changes are first-class. Your UI writes to the CRDT state immediately.
Sync is incremental and backgrounded. You send/receive updates continuously rather than doing full document overwrites.
Persistence is explicit. Store the CRDT state (or its updates) locally so reopening the app doesn’t re-run “download to render” flows.

If your app architecture is already event-driven, CRDTs fit naturally: local events mutate local state, and sync propagates the same state transitions outward.

ElectricSQL and the “database that speaks CRDT” idea

CRDTs are often presented as collaboration tools, but their real leverage appears when you treat them as a persistence layer rather than just an in-memory sync strategy. That’s where tools like ElectricSQL enter the conversation: they aim to make local-first development closer to normal database workflows.

Instead of thinking, “How do I synchronize this custom document format?” you think, “How do I keep my local database consistent with other replicas while still supporting offline work?”

The most valuable shift is psychological and architectural:

You stop designing around the idea that the server must be reachable to do useful work.
You design around local correctness first, then synchronization as a system behavior.

In practical terms, teams can build features that feel like standard database-backed apps—except the sync layer handles replication and conflict resolution without asking the UI to babysit the network.

What changes for UX, performance, and engineering teams

Local-first isn’t only a technical change; it changes what your product can promise.

1) The end of “loading to edit”

With local-first, “load” becomes “hydrate” and “render,” not “wait.” If your data is already on-device, the app can show content immediately. Sync catches up later.

That’s how you avoid the spinner loops users hate: “Fetching updates…”, “Syncing…”, “Reconnecting…”. The app remains interactive because the user is never blocked by remote state.

2) Offline becomes a feature, not a fallback

Offline-first used to mean “read-only with occasional edits.” Local-first means offline edits are the default. If sync is robust, offline isn’t an exception path—it’s just another condition.

3) Engineering shifts from request/response to replication mindset

You stop designing APIs around “submit changes, server validates, client displays.” Instead, you design around:

local mutation
durable local storage
deterministic merge
background replication

This also clarifies responsibilities: the sync engine owns distribution and convergence; the UI owns immediate feedback.

4) Testing becomes more realistic

Network simulations matter, but local-first changes the test surface dramatically. You can test correctness by:

applying updates independently on two replicas
permuting update order
verifying convergence after sync

That’s a cleaner mental model than trying to reproduce timing-dependent server-side race conditions.

The future isn’t faster networks—it’s fewer required networks

It’s tempting to chase performance by upgrading infrastructure: lower latency CDNs, faster APIs, better caching. Those improvements help, but local-first attacks the root UX problem: network round trips shouldn’t be on the critical path for core operations.

When CRDT-based sync is done right, most user actions don’t depend on connectivity. The cloud becomes a distribution mechanism, not a dependency.

That’s why local-first is rising now. It’s not just because developers want offline mode—it’s because CRDTs and modern sync tooling have matured into practical, integrable building blocks. Libraries like Automerge and Yjs provide the merge semantics. Systems like ElectricSQL bring the “database-like” experience closer to what teams already understand.

The common outcome is straightforward: apps that start instantly, feel responsive under stress, and recover gracefully. Not because the network is magical—but because the app no longer needs the network to be “real.”

Conclusion: Build for local truth, then sync with confidence

Local-first software is a bet on a simple idea: your device should be able to do real work without waiting. CRDTs make the hard part—conflicting updates—tractable by ensuring convergence without user drama. With proven tools and sync engines, teams can finally deliver the experience users expect: edits that appear instantly, offline reliability, and background sync that doesn’t interrupt the flow. The next wave of software won’t just be faster—it will be less dependent on the connection entirely.

Hono Became the Express.js of the Edge Computing Era

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 10 Sep 2025 00:00:00 +0000

Edge computing used to feel like a niche hobby—deploy a toy API to a single platform and pray your code survives the next runtime update. Hono changes that vibe. It’s the rare web framework that feels purpose-built for today’s reality: many runtimes, many deployment targets, and too much time wasted on “it works on Workers but not on Lambda.”

Hono has crossed 50,000 GitHub stars for a reason. It’s small, standards-forward, runtime-agnostic, and surprisingly pleasant to use. If Express defined the Node.js web era, Hono is shaping what comes next: runtime-independent, edge-first services that you can ship without rewriting everything every time your infrastructure changes.

What Makes Hono Feel Like “Express, but for Everything”

Express became the default because it hit a sweet spot: simple routing, middleware that’s easy to reason about, and an ecosystem that kept growing. Hono hits a similar sweet spot—but with a crucial upgrade: it runs on every JavaScript runtime you care about.

The headline is the size: Hono is roughly 14KB. That matters more than it sounds. Smaller frameworks mean fewer abstraction leaks, faster cold-starts in serverless environments, and less overhead when you’re pushing requests through an edge runtime where every millisecond counts.

But the bigger reason Hono feels familiar is how it models the web. Hono follows standards-based request/response patterns instead of forcing you into a platform-specific API. In practice, that means your handlers look like web code—not like a runtime-specific experiment.

Concretely, you can write the same application using the same core APIs across Node.js, Bun, Deno, Cloudflare Workers, and AWS Lambda-style environments—without “runtime branches” scattered throughout your codebase.

Standards-Based by Default: Write Web Code, Not Runtime Code

The easiest way to understand Hono is to treat it like you’re writing for the web first. You’re working with the semantics you already know: HTTP requests, headers, bodies, status codes, and responses.

This matters when you move to the edge because edge runtimes don’t share the same assumptions as traditional Node.js servers. Some don’t support the Node.js standard library the way you expect. Some don’t behave like a long-running process. Some have different streaming and body-handling behavior.

Hono avoids the worst of that by aligning with the web platform’s primitives. The result is that migrating from “local Node server” to “edge deployment” is far less about porting and far more about packaging and configuration—exactly what you want.

Practical example: a minimal route that stays portable

With Hono, you can keep your app logic focused on request handling rather than on the runtime’s quirks. A route stays a route whether you deploy it to a worker or a serverless function. The interface is familiar, but the portability is the point.

You won’t need to learn a separate framework dialect for each platform—because Hono isn’t pretending the platforms are the same. It’s building a stable layer on top of their shared web capabilities.

TypeScript You’ll Actually Enjoy (Plus an RPC Helper)

Most “frameworks with TypeScript support” still feel like TypeScript-as-afterthought. Hono doesn’t. TypeScript integration is one of the places where it feels modern and confident, not bolted on.

You get solid inference and ergonomic patterns that help you keep types accurate as your handlers grow. But the real differentiator for teams building real services is the RPC helper—an approach that supports end-to-end type safety.

That’s not just a developer-experience win; it’s an operational win. When client and server disagree about shapes—payload fields, return types, or error formats—you usually find out in production. With an RPC-style workflow, you can catch those mismatches at development time.

What “end-to-end type safety” means in practice

Imagine you have a createUser operation:

Your API expects { email: string; name: string }
Your frontend supplies those fields
Your code transforms them into a database-ready model
Your API returns a structured response your UI uses to render the next state

With a type-safe RPC helper, you’re not maintaining two separate contracts in two separate places. You’re maintaining one. That reduces churn and makes refactors dramatically less scary—especially when you’re shipping quickly across environments.

Middleware and Ecosystem: Mature Enough to Build Real Products

A framework is only as good as its “boring parts”—logging, auth, validation, compression, error handling, and the rest of the daily glue code that turns routes into a product.

Hono’s middleware ecosystem is mature enough that you can assemble common patterns without reinventing everything. That’s crucial if you want to migrate from Express without feeling like you’re starting from scratch.

You can take your existing Express mental model and map it over:

Middleware chains become middleware chains
Route handlers remain handlers
Composition stays straightforward

The migration story here is the opposite of the painful kind. You shouldn’t be rewriting your business logic. You should be swapping the framework layer, adjusting a few API details, and shipping.

Migrating from Express: The Sharp, Practical Path

Let’s be honest: most teams don’t “rewrite” when they adopt a new framework. They migrate.

The good news is that migrating from Express to Hono is typically straightforward because your architecture already exists:

Routes and controllers: Move handler functions over with minimal logic changes.
Middleware: Convert middleware registration to Hono’s approach.
Request/response details: Adjust anything that relied on Node-specific behavior.
Validation and serialization: Prefer Hono-friendly patterns so your code stays runtime-agnostic.
Deploy target: Pick the edge runtime you want first—then make sure the app behaves the same everywhere.

A realistic example: turning an Express-style API into Hono

Say your Express app has:

/health route
authentication middleware
a couple of JSON endpoints
centralized error handling

In Hono, the structure remains familiar: you define routes, attach middleware, and keep your logic in handler functions. The biggest differences tend to show up only where Express code relied on Node’s streaming quirks, request object extensions, or nonstandard response helpers.

The payoff is immediate: once deployed, edge runtimes typically feel snappier. Your service stops “waiting” on the same server characteristics every time and benefits from closer geographic placement and a more lightweight runtime model.

And since Hono is runtime-agnostic, you’re no longer locked into “whatever Node server we run today.” Your architecture becomes resilient to infrastructure churn.

Performance and Deployment: Why “Runs Everywhere” Changes the Business

Frameworks shouldn’t be a theology debate, and Hono isn’t either. It’s a practical tool.

Edge-first changes the distribution of latency across your app. It reduces the distance between user and execution environment and can improve perceived speed. But the real business impact is operational: fewer rewrite cycles, faster iteration, and simpler platform selection.

When your framework is runtime-agnostic:

You can start with a worker and later move to another platform
You can use serverless for some endpoints and edge for others
You can test different deployment targets without changing application architecture

Hono makes “platform flexibility” real by making the code portable, not merely “deployable with minor changes.”

Conclusion: Express Built a Node Era—Hono Is Building the Next One

Express defined how millions of developers built web services in the Node.js world. Hono is defining how teams build web services across the edge-first, runtime-agnostic world—standards-based, runtime-agnostic, TypeScript-friendly, and fast without feeling fragile.

If you’re still treating deployment targets as a reason to fork your codebase, it’s time to stop. Hono gives you the one thing modern engineering desperately needs: a framework that lets you ship the same application everywhere, with less ceremony and fewer surprises.

PostgreSQL 17 Features That Make Me Unreasonably Excited

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 04 Sep 2025 00:00:00 +0000

PostgreSQL has never been the database that tries to impress you with gimmicks. It’s the database that quietly fixes the exact problems you didn’t want to admit you had—then ships the fix in a release that feels almost… inevitable. PostgreSQL 17 is one of those releases. And yes, it has me unreasonably excited.

This time, it’s a rare combo: operational pain gets easier (incremental backup), everyday developer work gets cleaner (enhanced JSON-to-relational), and schema modeling finally behaves the way identity columns were supposed to. On top of that, the boring-but-critical scaling knobs—vacuuming and parallel execution—get meaningful attention. Let’s dig in.

Incremental backup: less downtime, fewer “backup day” rituals

If you’ve ever backed up a large PostgreSQL database, you already know the emotional arc: start the job, watch throughput, pray the storage doesn’t choke, and then spend the rest of the day in “restore rehearsal” mode because “we should really test that.”

Incremental backup in PostgreSQL 17 targets that entire experience. Instead of treating every backup as a full snapshot, PostgreSQL can produce backups that include only changes since the last backup (conceptually speaking). The payoff is straightforward: backup windows shrink, and the operational cost of “regular backups” becomes realistic rather than aspirational.

What this looks like in practice

Imagine a system where full backups take 6 hours during a busy window, and you can only run them at night. With incremental backups, you can shift toward:

More frequent backups (because each one is cheaper).
Shorter “backup-impact” periods (because you’re not rewriting the universe each time).
Faster recovery planning (because you can combine backups and log changes more efficiently than “one huge full backup plus everything else”).

A practical strategy I like: run a baseline full backup regularly (say, weekly), then use incremental backups more frequently (daily or even more often, depending on your change rate and storage budget). That gives you a recovery chain that’s neither too shallow (riskier) nor too deep (harder to manage).

A caution worth keeping

Incremental backups are not magic. You still need to think about retention, cataloging backup sets, and ensuring you can reliably restore from the chain. The win is that the chain becomes less painful to maintain, not that you can skip testing restores.

If you haven’t restored from your backups recently, consider PostgreSQL 17 a forcing function. Your future self will thank you.

Enhanced JSON_TABLE: stop duct-taping JSON into relational queries

JSON is great for flexibility. It’s also a magnet for complexity. You start with “just a small nested object,” then add five more fields over time, and suddenly your SQL is full of repetitive extraction logic, lateral joins, and hand-rolled transformations that nobody wants to touch.

PostgreSQL 17’s enhanced JSON_TABLE moves the needle toward something much more pleasant: transforming JSON into a relational shape in a way that is designed for querying.

Why `JSON_TABLE` changes the feel of the code

The key improvement is that you can treat JSON arrays and objects as structured rows and columns without turning your query into spaghetti. Instead of scattering ->, ->>, casting, and COALESCE across half a dozen expressions, you can describe the target table-like structure more directly.

Here’s the pattern that tends to become common:

You receive JSON payloads (from an API, event stream, or document store style workflow).
You want to filter, aggregate, or join that payload with relational tables.
You don’t want to implement “JSON shredding” differently for every endpoint.

With JSON_TABLE, your SQL can become a consistent pipeline: JSON in → rows/columns out → normal SQL behavior.

Example: query an array of items with relational clarity

Suppose you store an “order events” JSON document like this:

{
 "order_id": 123,
 "items": [
 { "sku": "A1", "qty": 2, "price": 9.99 },
 { "sku": "B2", "qty": 1, "price": 19.50 }
 ]
}

To sum quantities per SKU, instead of repeatedly extracting fields, you can use JSON_TABLE to map items[] into rows with typed columns (sku, qty, price). From there, it’s normal SQL: GROUP BY sku, joins to a products table, filtering by price thresholds, etc.

The practical benefit: fewer edge cases and fewer “why does this cast differently in this one query?” moments.

Opinionated advice: treat JSON as an input format, not your long-term schema

If you use JSON as a storage format, fine—just don’t let it become a long-term substitute for proper tables when the data is genuinely relational. Use JSON_TABLE to bridge the gap, then consider whether the most important fields deserve first-class columns (or at least generated columns / indexing strategies where appropriate).

PostgreSQL is great at accommodating both worlds; PostgreSQL 17 makes the bridge sturdier.

Identity columns done right: schemas stop feeling “accidentally correct”

Identity columns have been one of those features that people repeatedly tried to use—but often with a slightly haunted feeling. You want auto-increment behavior that’s reliable, safe under concurrency, and explicit in schema. You also want it to play nicely with migrations.

PostgreSQL 17’s improvements around identity columns make them behave the way developers expect: cleaner semantics, fewer surprises, and a more consistent migration story.

What “done right” means for daily work

In real systems, identity columns are involved in:

Importing data into tables with existing keys.
Writing migrations that add identity columns to existing tables.
Handling sequences and ownership correctly so that the database enforces integrity.
Preventing the classic failure mode: “someone inserted rows and now the next id collides.”

If identity columns are configured and maintained cleanly, you don’t have to keep a mental model of how sequences were created, who owns them, and what happens when rows are inserted out of band.

Migration tip: validate behavior, don’t just rely on it

When you change identity behavior or retrofit identity onto an existing table, do two things:

Run a migration in a staging environment with representative data volume.
Verify the next generated value (especially after inserts that might bypass the ORM path).

It’s not about fear—it’s about certainty. Identity columns are where correctness should be boring.

PostgreSQL 17 is making that boredom easier to achieve.

Vacuuming improvements: make “eventually” mean “predictably”

Vacuum is one of those topics that always arrives right after you’ve already been burned. The database is slow, table bloat is creeping up, autovacuum settings were “fine” until they weren’t, and now you’re debugging performance like it’s a crime scene.

PostgreSQL 17 improves aspects of vacuuming performance and behavior, which matters because vacuuming is how PostgreSQL maintains its MVCC reality. In other words: vacuum isn’t optional; it’s the price you pay for concurrency and consistency.

Why this is more than housekeeping

When vacuuming is efficient and more predictable, it impacts:

Query latency (less bloat, fewer slowdowns)
Index health (less churn, fewer pathological states)
Operational stability (fewer “why is it worse today?” mysteries)

The practical result is that scaling becomes less dependent on heroic tuning. You still need sane defaults, monitoring, and maintenance—but you get a more forgiving baseline.

What to do after upgrading

Don’t just deploy and forget. After upgrading to PostgreSQL 17:

Review your autovacuum settings and ensure they’re aligned with your workload pattern.
Monitor table bloat trends before and after.
Watch for changes in vacuum runtime characteristics.

If you previously had to over-tune to keep latency stable, this release might allow you to simplify. That’s a win you feel every day.

Parallel query execution: scaling without turning your hardware into a lottery

PostgreSQL has made parallel execution increasingly capable over time, but performance scaling has often felt like an art project: sometimes parallelism helps a lot, sometimes it barely moves the needle, and sometimes the plan changes in ways that make you second-guess the optimizer.

PostgreSQL 17 continues the trend of improving parallel query execution. That matters because modern workloads aren’t just bigger—they’re more varied, more concurrent, and more latency-sensitive.

Practical expectations

Parallel query benefits most when:

Queries scan large datasets.
Work is naturally decomposable (e.g., per-partition operations).
You’re able to provide enough CPU and memory headroom for worker processes.

To get value from parallelism, you generally need three things:

Appropriate indexes (so parallel work isn’t wasted).
Cost settings that don’t discourage parallel plans.
Hardware and configuration that allow workers to run without starving the system.

Make it concrete: check plans the right way

After upgrading, test critical query paths and compare execution plans. Look for:

Whether the planner chooses parallel plans.
Whether the degree of parallelism is reasonable.
Whether runtime improvements align with reductions in scanned rows or expensive operations.

Don’t treat “parallel” as a checkbox. Treat it as a tool—and verify the tool is being used effectively.

Scaling and correctness improvements that add up

The features above aren’t isolated wins. They form a coherent story:

Incremental backup reduces operational friction and enables safer recovery practices.
Enhanced JSON_TABLE reduces query complexity and makes JSON-to-relational transformations more consistent.
Identity columns improve schema correctness and migration sanity.
Vacuuming and parallel execution improvements address the last-mile scaling concerns that tend to turn “it works” into “why is it painful?”

If you’ve ever considered switching away from PostgreSQL because “it’s tough at scale,” PostgreSQL 17 is the kind of release that challenges that narrative. Not by adding magic, but by sanding down the rough edges in the parts of the system where teams actually suffer.

Conclusion: the kind of release you build on

PostgreSQL 17 feels like a mature upgrade: it doesn’t ask you to relearn your database, and it doesn’t chase flashy novelty. Instead, it makes the day-to-day better—faster backups, cleaner JSON queries, identity columns that behave, and performance improvements that help your system stay healthy under load.

If you manage production databases or write SQL for a living, this is the release where you’ll notice the improvements not in benchmarks, but in fewer outages, fewer migrations-that-keep-you-up, and fewer “why is this query different today?” moments. That’s the good stuff.

Every Framework Claims Server-Side Rendering—Here's What Actually Matters

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 23 Aug 2025 00:00:00 +0000

Your feed is full of badges: SSR! SSG! ISR! Streaming! Partial hydration! Resumability! The industry keeps inventing new labels for the same handful of problems: render fast, ship content that search engines can find, and keep interaction snappy without melting your servers. The good news: you don’t need to memorize taxonomy. You need to optimize a small set of user-visible outcomes—and pick the strategy that serves them.

Let’s cut through the marketing fog and talk about what actually matters: time to first byte, time to interactive, and indexability. Then we’ll map those outcomes to the handful of architectures worth caring about.

The Taxonomy Problem: Most “Rendering” Is Just Caching and Scheduling

Framework teams market rendering modes as if they’re fundamentally different technologies. In practice, many of them differ in when HTML is produced and how it’s cached and delivered.

SSR typically means: render HTML on demand (per request).
SSG typically means: render HTML ahead of time (build time).
ISR typically means: render HTML ahead of time, but refresh it later on a schedule or on demand.
Streaming SSR means: start sending the HTML before the full page is ready.
Partial hydration / islands means: ship HTML for everything, but only hydrate interactive parts.

Under the hood, you’re juggling three levers:

Latency to HTML (how fast the server can produce bytes)
Latency to interactivity (how fast JS becomes functional)
Cacheability and freshness (how often you need to redo work)

If you keep these levers in mind, the taxonomy stops being confusing and starts being useful.

The Only Metrics That Pay Rent: TTFB, TTI, and Indexability

Before you choose a framework feature, decide what you’re optimizing for. For most real products, these three metrics answer the question:

1) Time to First Byte (TTFB): Do users see something quickly?

TTFB is the moment the browser receives the first byte of HTML (or a meaningful payload). People don’t judge “performance” in milliseconds; they judge whether the page feels responsive.

Practical test: throttle to a slow 4G profile, load the page, and see how quickly the first paint starts. If your SSR takes too long to produce HTML, streaming or pre-rendering might be the fix.

2) Time to Interactive (TTI): Can users do anything without waiting?

TTFB can be great and still feel slow if you block interactivity with heavy JS bundles or delayed hydration.

Practical test: use DevTools to inspect long tasks and the moment event handlers become active. If “interactive” arrives late, your problem is often hydration strategy, not HTML delivery.

3) Indexability: Will search engines reliably understand the content?

This isn’t about being “SEO-friendly” in the abstract—it’s about whether bots can fetch and interpret the content consistently.

If your “server-side” story depends on client-side rendering for the meaningful text, you’re forcing your users (and bots) to wait for JavaScript that may not run the way you expect.

Practical rule: if a page’s value is the content itself (docs, marketing copy, product descriptions), indexability should be non-negotiable.

With these three metrics, you can evaluate any rendering approach without caring what brand of taxonomy it wears.

Static Generation (SSG): The Best Default for Rarely Changing Content

When content rarely changes, static generation isn’t just a “mode”—it’s the simplest path to excellent performance and stable indexing.

Why it works

The server isn’t doing work at request time.
CDN caching is straightforward.
HTML exists before the first user asks for it.
Search engines can fetch the final markup immediately.

Where to use it

Documentation sites
Blog archives and evergreen guides
Product pages where updates are infrequent and can be deployed in batches
Marketing pages with a predictable release cycle

Concrete example

Imagine a “How it works” page for a SaaS that updates quarterly. Rendering it as SSG means the CDN can serve the same HTML worldwide with minimal latency. Your users get fast page loads, and your search engine doesn’t need to execute application code just to see the content.

What about “but my data changes”?

That’s where ISR comes in. But if the content truly changes rarely, resist the temptation to “dynamic render everything” just because you can. Complexity is a tax.

ISR and Similar Caching Strategies: Freshness Without Sacrificing Speed

Incremental Static Regeneration (ISR) is often marketed as a distinct revolution. What it’s really offering is a compromise: static delivery with periodic or on-demand refresh.

The practical goal

Keep most requests fast (served from cache or pre-rendered HTML)
Update content eventually so it doesn’t go stale forever
Avoid full SSR load spikes

Where it shines

Content that changes more often than quarterly but not every second
- News tickers that update multiple times daily
- Pricing pages that update occasionally
- Catalog pages where inventory changes are frequent but don’t need perfect “live” accuracy on every request

Concrete example

A pricing comparison page might update weekly. With ISR, you ship pre-rendered HTML for immediate responsiveness, then regenerate in the background when it’s due. Users still get a fast TTFB, and the page remains indexable because it’s real HTML, not an empty shell.

The decision you should make

Choose your freshness model intentionally:

Time-based revalidation: “Update at most every X minutes.”
Request-triggered regeneration: “Update when a user hits it after it’s stale.”

The marketing label matters less than how you control the staleness window—and how you prevent regeneration storms.

Streaming SSR: When Personalization and Data Fetching Dominate

SSR becomes a necessity when each request’s HTML depends on personalized data or complex server-side computation. But naive SSR can be slow if you block on everything before sending bytes.

Streaming SSR solves a specific pain: it lets you start sending the response early, before the slowest data sources finish.

Why it works

Instead of doing this:

Fetch A, fetch B, fetch C
Render the whole page
Send HTML

Streaming does this:

Send the shell/layout immediately
Stream sections as data arrives
Finish the response when the last pieces are ready

Where it shines

Personalized dashboards where the “chrome” can render immediately, but some widgets depend on user-specific data
Account pages, onboarding flows, and “resume where you left off” pages
Pages with expensive server calls where you want the user to see progress rather than a blank screen

Concrete example

A dashboard can often render:

navigation + page title immediately
“recent activity” once queried
“recommendations” when the recommender returns

Streaming means users see the dashboard skeleton early, improving perceived responsiveness even if total server work still takes time.

The trade-off

Streaming complicates your HTML and component boundaries. Don’t adopt it because it sounds modern—adopt it because your pages can benefit from progressive section delivery.

Partial Hydration and Islands: Fixing the Interactivity Bottleneck

Many teams assume “SSR means fast.” It doesn’t—at least not fully. A page can arrive quickly and still feel dead if you hydrate everything, eagerly, with a massive JS bundle.

That’s where islands and partial hydration earn their keep: you ship HTML for the whole page, but only hydrate interactive regions.

Why it works

Static or read-only content doesn’t pay for JS.
Interaction is enabled only where needed.
Your time to interactive improves because the browser does less work.

Where it shines

Content sites with interactive widgets:
- search boxes
- comment systems
- subscribe forms
- polls
Documentation or blog pages with a few islands (like code copy buttons or embedded diagrams)
Commerce pages where some sections require interactivity but the rest is largely static HTML

Concrete example

A blog post page might have:

the article body (no interactivity needed)
a “copy code” button (small interactive island)
a newsletter form (interactive island)
a related posts carousel (interactive island)

If you hydrate the entire page as a full client app, you’re wasting time executing code that does nothing on most screens.

Practical advice

Treat islands like “budgeted JavaScript.” If an island’s code grows, it should fight for its place. Measure hydration cost. Keep interactive widgets small and lazy-load them when they enter view—if your UX allows it.

What About Streaming, Resumability, and Everything Else?

You don’t need to treat every new label as a new dimension of value. Most “advanced” features boil down to one of the same three outcomes:

Better TTFB (send bytes earlier, reduce blocking)
Better TTI (reduce JS, hydrate less, unblock interaction)
Better indexability (deliver meaningful HTML reliably)

If a “resumability” story doesn’t map to user-visible improvement—or it only helps edge cases you don’t actually have—you should be skeptical. Great engineering deserves skepticism. Marketing deserves it more.

A useful framing: ask whether the feature changes what the browser receives and when it becomes usable, not whether it sounds impressive at a conference.

Conclusion: Choose Rendering Like a Product Manager, Not Like a Theorist

The rendering landscape is noisy because frameworks compete on labels, not outcomes. Your job is to pick the approach that meets user needs:

Use SSG for content that doesn’t change much: fast, cacheable, indexable.
Use ISR/caching regeneration when you need freshness without losing CDN speed.
Use streaming SSR when personalized or data-heavy pages can benefit from early partial delivery.
Use partial hydration / islands when interactivity is localized and hydrating everything would slow users down.

Stop chasing “server-side” as a badge. Chase TTFB, TTI, and indexability—and let the architecture follow.

The Pragmatist's Guide to Choosing a JavaScript Runtime in 2025

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 17 Aug 2025 00:00:00 +0000

If you’ve spent even five minutes in a developer chat, you’ve seen it: the runtime debate that turns into a theology lesson. Node, Bun, and Deno aren’t just “different ways to run JavaScript”—they’re different bets about what matters most (ecosystems, speed, and safety). In 2025, the winning move isn’t picking a side. It’s choosing the runtime that lets your team ship the next feature with the least friction.

This guide is unapologetically practical: what each runtime optimizes for, when that optimization actually matters, and how to decide without getting pulled into a religious war.

Start with reality: runtime choice affects your team, not your demo

A runtime is a long-term operational commitment. The demo you write today is rarely the production system you run next year.

So instead of asking, “Which runtime is best?”, ask:

What code will you run? (Existing apps vs. new builds)
What dependencies will you rely on? (npm vs. web APIs vs. TypeScript-first)
How will you deploy and operate? (hosting support, CI/CD, monitoring)
What constraints do you actually have? (security requirements, performance budgets, developer skillset)

Here’s the rule I follow: pick the runtime that reduces your total cost of change—not just the cost of initial setup.

Node.js: the ecosystem gravity well (and why enterprises keep defaulting to it)

Node is the safe default because it’s the ecosystem default. If you’ve got an existing codebase, Node is the least surprising choice: most npm packages “just work,” most tutorials assume Node, and most hosting providers support it without special handling.

When Node is the right move

Choose Node if one or more of these are true:

You’re migrating or maintaining an existing application.
You depend on mainstream npm packages (auth, payment SDKs, queues, ORMs, admin tooling).
Your team’s hiring and training pipeline is optimized for Node.
Your organization wants the lowest operational uncertainty.

Practical example: “we already have dependencies”

Imagine a B2B dashboard that uses a mix of:

an ORM ecosystem
a session/auth library
multiple UI-adjacent tooling packages
a few legacy internal plugins

Even if Bun or Deno could run the code, you’re effectively betting on compatibility across that dependency graph. Node minimizes that bet.

The cost of Node (and how to manage it)

Node’s downside isn’t “it’s slow.” It’s that performance and developer experience improvements often come as add-ons: bundlers, test runners, linters, and platform-specific optimizations. If you need speed, you’ll assemble it. That can be fine—until you have strict startup latency or serverless cold-start sensitivity.

If you’re going the Node route, treat performance as a first-class engineering task:

use a modern bundler (so you don’t ship “everything”)
keep your dependency graph tidy
measure startup and request latency early, not after launch

Bun: the performance-first runtime that rewards greenfield speed

Bun’s value proposition in 2025 is simple: it’s built for velocity—both developer velocity (tooling included) and runtime velocity (startup, bundling, execution).

The important nuance: Bun shines when your project is new enough that you can design around the runtime rather than dragging an old dependency ecosystem into it.

When Bun is the right move

Choose Bun if:

you’re starting a greenfield service and want to move fast
you care about startup latency (serverless, edge-adjacent systems, ephemeral workers)
you want an “all-in-one” dev loop (run, bundle, test—less ceremony)
your dependencies are compatible with Bun’s world

Practical example: serverless workers and quick deploy loops

Say you’re building event-driven background processing:

short-lived compute
frequent redeploys
dozens of small worker processes rather than a single long-lived server

In this scenario, startup time and deployment speed become product features. Bun’s performance characteristics can turn a “wait a few seconds each redeploy” workflow into something closer to instant feedback.

The cost of Bun (and how to de-risk it)

The risk is not that Bun is “bad.” The risk is that the dependency ecosystem is broader in Node. Bun can run many npm packages, but if you’re heavily invested in niche native modules or very Node-specific tooling, you may hit friction.

To de-risk:

run a compatibility pass on your dependency tree early
pin versions aggressively
create a small “canary” service in Bun that covers the riskiest libraries first

Deno: secure-by-default, TypeScript-native, and web-standards oriented

Deno takes a different stance: it treats security and modern API design as fundamentals, not optional upgrades. Its default model—permissioned access—forces you to be explicit about what your code can do. It’s also TypeScript-native, which means fewer translation steps between “the language we wrote” and “the language we run.”

When Deno is the right move

Choose Deno if:

your organization prioritizes security boundaries and least privilege
TypeScript is non-negotiable (not “we’ll add types later”)
you want to lean into web-standard APIs (instead of Node’s legacy-inherited patterns)
you prefer runtime-level controls over relying solely on tooling and process discipline

Practical example: permissioned integrations

Consider an internal automation service that:

downloads files from a specific URL
reads from a specific directory
calls out to an external API
writes logs to stdout only

In Deno, you can align runtime permissions to the exact behaviors you intend. That turns “someone accidentally added a filesystem call” into something that’s either blocked or requires conscious permission changes.

The cost of Deno (and how to manage it)

The trade-off is ecosystem fit and patterns. Some Node-targeted packages and assumptions may require adaptation. If your team is deeply embedded in a Node-first workflow, switching to Deno can mean learning new patterns and dealing with compatibility edges.

To manage this:

start with a small service that benefits from Deno’s design goals (security boundaries, TypeScript ergonomics, web APIs)
standardize how your team structures code and permissions
invest in internal wrappers around external services so the codebase stays consistent even when underlying libraries differ

A decision framework you can use in a meeting (without derailing into vibes)

When teams get stuck, it’s usually because they’re arguing about “what’s cool” instead of “what’s required.” Use this checklist and make it concrete.

1) Legacy and dependency gravity

Mostly new code, small set of dependencies? Bun or Deno becomes viable quickly.
Large existing npm-based system? Node is usually the path with the fewest unknowns.

2) Deployment model and performance sensitivity

Serverless / ephemeral compute / frequent cold starts? Bun often earns a spot.
Long-lived services where latency matters but cold start isn’t brutal? Node is often fine with the right optimizations.

3) Security posture

You want least-privilege enforced at the runtime level? Deno is compelling.
Your security model already relies heavily on infrastructure policies and process discipline? Node can still work—just be rigorous.

4) TypeScript and developer workflow

TypeScript is central to how you build and review? Deno’s TypeScript-native approach may reduce friction.
Your toolchain is already optimized for Node+TypeScript? Node remains the pragmatic default.

5) Team and hiring reality

This is the part nobody wants to say out loud, but it matters:

If the team is Node-leaning and the org hires Node engineers, Node reduces onboarding cost.
If your team is comfortable exploring newer runtimes and you can ramp quickly, Bun or Deno can pay off.

How to choose without making it a forever decision

Even with the best framework, you’ll still want a strategy to avoid “big bang” regret.

Here’s a pragmatic approach:

Pick the runtime for the first service, not the whole company.
Create a compatibility spike: a small proof that runs your highest-risk dependencies.
Measure what matters: startup time, local iteration speed, and build/test reliability—not abstract benchmarks.
Codify your defaults: linting, formatting, testing, CI pipeline, deployment scripts.
Leave an exit ramp: keep business logic isolated from runtime-specific quirks.

If you’re doing this well, you’re not committing to ideology—you’re building institutional muscle.

Conclusion: choose the runtime that makes shipping inevitable

In 2025, the “right” JavaScript runtime isn’t the one with the loudest supporters. It’s the one that aligns with your constraints and reduces operational and developer friction.

Choose Node for enterprise continuity and ecosystem certainty.
Choose Bun for greenfield performance-sensitive projects where speed and tooling matter.
Choose Deno for security-first, TypeScript-native teams that want web-standard APIs and permissioned execution.

The best decision is the one you can explain in terms of trade-offs—and implement without waiting for the internet to agree.

Coding Agents Changed How I Ship Software and There's No Going Back

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 11 Aug 2025 00:00:00 +0000

For the last month, I let coding agents touch almost everything: features, bug fixes, refactors, and the boring-but-critical glue that keeps a production codebase healthy. I expected a productivity bump. I didn’t expect my whole workflow to reorganize around delegation. And after enough shipping, I can say this with conviction: agents are transformative for well-defined work—and dangerous when you blur the line between “implementation” and “decision.”

The Month I Let Agents Drive

I didn’t run a controlled experiment. I did what most teams do when tools get promising: I used them where they seemed to fit, then watched what broke, what improved, and what forced me to change my process.

I used three agent-capable workflows in practice:

Claude Code–style project assistance: iterating on changes within a local repo, asking it to propose edits, then verifying.
Copilot CLI–style command workflows: quick generation, test writing, and fix suggestions based on the codebase.
Agentic “delegation loops”: the pattern of “assign task → agent proposes changes → I review/approve → run tests → repeat.”

My rule at the start was simple: I would not delegate architectural choices or high-risk behavior. Then, as the week went on, I realized something uncomfortable. The more I trusted the agent, the easier it became to slip into delegating decisions.

That’s the core lesson: coding agents don’t just write code—they reshape your habits. Your system either keeps them in their lane or quietly turns them into your co-author for things they shouldn’t be touching.

Where Agents Actually Shine (and Why It Feels Like Cheating)

Coding agents are best at tasks that are mechanically bounded and verifiable. In that zone, they feel almost unfairly fast.

Test writing that would otherwise steal hours

The most immediate win was test coverage. When I had a bug with a clear reproduction path, I’d ask the agent to:

locate the relevant code path,
draft a focused test,
run it (or at least align it with existing test patterns),
iterate until it fails for the right reason and then passes after the fix.

Example: a flaky behavior in a background job. The “human” version of this story is messy—hand-wave the setup, write a brittle test, and spend the afternoon debugging the test instead of the code. The agent’s strength was structural: it knew which fixtures and helpers existed in the repo, and it tended to generate tests that matched the project’s existing conventions. The result was quicker feedback loops.

Boilerplate and “boring correctness”

Agents are excellent at repetitive edits: adding endpoints, wiring parameters, updating DTOs, handling serialization, and mirroring patterns across modules. If your codebase already has a style, agents can replicate it with surprising fidelity.

I used this for:

adding a new API field across request/response types,
creating the “same but slightly different” service layer method,
introducing a new migration with the correct shape and rollback behavior (with my review, obviously).

Mechanical refactors with tight acceptance criteria

Refactors are where agent value jumps from “nice” to “can’t go back.” If you can define success as “the build passes, tests pass, and the diff matches this transformation,” agents can do a lot.

One example: renaming a set of internal functions and updating all call sites. A competent agent reduced the grunt work drastically—then I enforced a review pass that focused on the diff quality, not whether I fully understood every line.

This is the key: when the work is checkable, agents are brilliant. When it’s not, they become expensive.

Where Agents Get Risky Fast (Especially in Production)

Agents become genuinely dangerous when you ask them to make ambiguous decisions—or when the acceptance criteria are fuzzy.

Architectural decisions are “context work”

In every mature codebase, architecture is less about syntax and more about tradeoffs: performance constraints, operational realities, domain boundaries, and team conventions. Agents don’t have that context unless your prompts and repository structure explicitly encode it.

I saw this in two failure modes:

Overconfident design changes: an agent proposed a “cleaner” abstraction that ignored existing boundaries and introduced new coupling.
Implicit assumptions about invariants: it changed logic in a way that compiled fine but subtly violated how the system behaves under load or in edge cases.

In both cases, the problem wasn’t that the agent was incompetent. The problem was that the agent optimized for what was easiest to modify, not what was safest to alter.

Subtle bugs hide behind “looks correct”

The scariest failures aren’t obvious test breakages. They’re logic changes that still pass tests but alter behavior in ways your tests don’t cover.

This is why I stopped delegating anything that required deep reasoning beyond what tests capture. If I couldn’t define the behavior precisely, the agent didn’t get a free hand. I learned to treat “it should work” as unacceptable as an acceptance criterion.

Context beyond the codebase doesn’t exist

Agents can only infer what they see. If your system depends on operational knowledge—timeouts chosen for production, rate limits negotiated with upstream partners, deployment quirks, feature flags with historical baggage—agents will guess unless you tell them.

If you’ve ever regretted a “quick fix” that only worked in development, you already know the danger zone.

My Delegation Pattern: Break Work Into Agent-Sized Chunks and Review Aggressively

The optimal workflow I landed on is not “give agent tasks and hope.” It’s a delegation discipline.

1) Convert vague work into concrete subtasks

Instead of: “Refactor this module for better design.”

Use: “Rename these functions, update call sites, keep public API unchanged. Ensure no behavior changes. Add/adjust tests covering current behavior.”

Agents love bounded tasks because they produce bounded diffs. Humans should love bounded tasks because they reduce review risk.

2) Force a verification loop every time

I treated each agent output as a proposed patch, not an implementation. After every meaningful change, I ran:

the test suite (or the relevant subset),
lint/type checks,
and—when behavior mattered—targeted checks around the risky path.

Even when the agent claimed the change “should pass,” I didn’t trust it. The point of agents is speed; the point of your workflow is correctness.

3) Review the diff like a publication editor

My review strategy shifted. I stopped reading every line with equal attention and started looking for patterns:

Are there silent changes to error handling?
Did it modify conditional logic or ordering?
Does it introduce new dependencies or broaden coupling?
Are tests added or just updated?
Are names consistent with intent, or just mechanically transformed?

When the agent writes boilerplate, the diff can be huge but low-risk. When it touches control flow, concurrency, caching, permissions, or data transformation, the diff is small but high-risk. I adjusted scrutiny accordingly.

4) Ask for smaller artifacts, not whole solutions

If you ask an agent to “implement the feature,” you’ll often get a stitched-together solution that’s hard to review.

Instead, ask for:

“Propose the exact test cases first.”
“Draft the interface changes only.”
“Show the diff for wiring before implementing business logic.”
“Enumerate the invariants you’re assuming, then wait for approval.”

This makes the agent’s thinking observable. That’s crucial.

A Practical Playbook for Your Next Iteration

If you’re adopting coding agents tomorrow, here’s how I’d start without creating chaos.

Use agents for:

Test creation and expansion (especially around known failing cases)
Boilerplate and repetitive wiring
Mechanical refactors with explicit transformation rules
Small, scoped features where behavior is already well-understood
Documentation updates tied to concrete code changes (with review)

Avoid agents for:

Architecture and boundary redesign
Permission/security model changes
Performance-critical logic without targeted tests
Edge-case behavior you don’t already have solid coverage for
Any “global” change that depends on tribal knowledge

Establish a “merge gate”

Even a lightweight gate helps. For example:

agent-generated code must be accompanied by tests for the changed behavior,
no agent changes land without running the suite in CI (even if it feels slow),
and high-risk areas require an explicit human approval checklist.

This is how you keep the speed without importing the risk.

The Real Outcome: Productivity, But Also Better Engineering Taste

Here’s the part that surprised me: delegation didn’t just make me faster. It made me more selective.

Once you can move quickly, you stop spending time on the drudgery that doesn’t differentiate you as an engineer. That time goes to the work that actually matters: defining the problem, enforcing invariants, tightening acceptance criteria, and reviewing carefully where it counts.

And yes—agents can make you sloppy if you let them. They will tempt you to offload thinking. But if you treat them like a powerful junior who needs boundaries, you get leverage.

The strongest teams I can imagine won’t be the ones that “use agents.” They’ll be the ones that build a delegation culture: agent-sized chunks, explicit verification, and aggressive review. Master that pattern and you don’t just ship faster—you ship cleaner.

Conclusion: Agents Are a Multiplier, Not an Autopilot

Coding agents changed how I ship software because they collapse the time between idea and implemented diff—especially for tests, boilerplate, and mechanical refactors. But they’re genuinely dangerous when tasks are ambiguous or when architecture-level decisions creep in.

So my takeaway is simple and non-negotiable: break work into agent-sized chunks and review aggressively. Treat agents as accelerators for verifiable implementation, not as authorities for system design. If you do that, there’s no going back.

The Developer Tool Landscape Is Consolidating Around AI-Native Platforms

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 05 Aug 2025 00:00:00 +0000

For years, “AI in the IDE” has meant bolting a chatbot onto a familiar workflow. But the editor is no longer the same interface—it’s becoming an AI workbench. Cursor, Windsurf, and Zed aren’t merely adding smarter completions to existing tooling; they’re reshaping how you reason about a codebase by making AI a first-class interaction model. And that shift is quietly but decisively consolidating mindshare away from the extension-first approach that powered VS Code’s rise.

From “AI-added” to “AI-native”: the real change

VS Code’s architecture made it easy to win adoption: a clean editor core, extensibility everywhere, and a plugin ecosystem that covered everything from linting to Git workflows. AI followed the same path. Copilot-style experiences fit neatly into that model—suggestions, inline chat, and helper features implemented as extensions that sit on top of the editor.

AI-native platforms take a different stance: they treat AI as the operating layer of the product rather than a feature. That difference shows up in three places:

Context isn’t an afterthought. AI-first editors are designed from the beginning to understand and use broader project state, not just the current buffer.
Edits aren’t limited to suggestions. They’re framed as intentional transformations—apply changes across multiple files, keep structure consistent, and verify outcomes.
The workflow includes agency. Instead of “ask → get completion,” you get “plan → perform → iterate,” sometimes with agent-like behavior that can execute multi-step tasks.

This is why the headline isn’t “AI makes edits smarter.” It’s “AI changes what the editor is for.”

Multi-file context is where the illusion breaks

If you’ve ever tried to refactor something non-trivial with an AI that only sees what you’re currently looking at, you’ve felt the limitation: answers get vague, changes become inconsistent, or the tool confidently suggests edits that don’t match surrounding usage patterns.

AI-native editors build a habit into the UI: when you ask for a change, the system assumes the relevant context spans the repository. Cursor and Windsurf, for example, are built around the idea that the assistant can reference the project at scale to implement a coherent edit rather than producing a patch confined to the visible file. Zed leans into the same “fast, fluid, repository-aware” philosophy with an emphasis on performance and responsiveness that keeps the loop tight.

Practical example: imagine you want to “rename AuthService to AuthenticationService, update imports, fix references, and adjust tests.” In a Copilot-style workflow, you might get a series of isolated suggestions—or you’ll be forced to manually manage the blast radius. In an AI-native workflow, you can often describe the intent once and let the editor coordinate the edit across the codebase, then show you a diff you can review.

The key isn’t just that it can see more. It’s that the editor uses that context to structure the work.

Natural-language project-wide edits beat “autocomplete for code”

The marketing term for AI in an editor is often “autocomplete.” But autocomplete is a single-shot tool. It assumes the user’s intent is already fully expressed in the current cursor position.

AI-native editors move the intent boundary outward. You state the goal in natural language, and the editor translates that goal into a series of code changes. That sounds obvious, but the UX implications are profound:

You stop thinking in keystrokes and start thinking in outcomes.
You treat the codebase like a document you can transform, not a buffer you can fill.
You rely on reviewable changes rather than trusting each suggestion blindly.

Consider an incremental modernization task: “Migrate this module from callbacks to async/await, update all call sites, and ensure error handling remains consistent.” In an autocomplete-centric flow, you’ll likely patch one function at a time and chase compile errors manually. In an AI-native flow, the editor can perform the transformation across multiple files, keep the error-handling pattern consistent, and present a coherent set of changes for you to validate.

This is where the extension model often runs out of runway. Copilot-as-plugin can provide assistance, but it usually can’t fully replace the editor’s conceptual model of what a “change” is.

Agent-mode shifts the burden from you to the tool

There’s a reason “agent mode” is showing up everywhere: it’s the closest thing to removing busywork from the development loop. The best implementations don’t just generate text—they can carry out tasks with some autonomy, such as:

searching the codebase for usages,
making a sequence of changes,
running checks (or preparing changes that will pass),
and iterating based on feedback.

Even when agent-mode features aren’t fully autonomous in the strictest sense, the workflow changes. Instead of repeatedly prompting with “what next?”, you prompt with “do the task.” The editor becomes a collaborator that can coordinate steps.

Here’s a concrete workflow that teams like because it reduces cognitive overhead: “Create a new API endpoint at /v2/users that mirrors the existing /v1/users logic, but uses the new repository layer; update routing, add the handler, and adjust tests.” In an AI-native editor, you’re not stuck translating your intent into a sequence of commands. The tool interprets the task as a set of coordinated edits.

And crucially: you still review the diff. Agent-mode isn’t a surrender button—it’s a way to compress the time between “idea” and “candidate implementation.”

Why VS Code’s extension model can’t fully absorb the paradigm shift

VS Code remains a phenomenal platform, and it will keep attracting developers for good reasons. But the extension model has a ceiling when the core interaction model changes.

When the AI becomes the primary interface, you need deep integration with:

how the editor assembles context,
how it plans and applies multi-step edits,
how it presents diffs in a reviewable way,
how it manages long-running tasks,
and how it synchronizes UI state with “work in progress.”

Extensions can do a lot, but they often operate at the edges of the editor. They can add chat panels, commands, and helpers. They can’t easily re-architect the editor’s center of gravity around AI as an editing engine.

Put differently: VS Code’s superpower is customization by composition. AI-native tools are optimizing for experience by design. That difference matters when the product’s value is increasingly about how work gets done, not just whether features are available.

This is the same pattern we saw with earlier editor transitions: the winner isn’t merely the tool with the most plugins; it’s the tool with the most frictionless mental model for the modern task.

The consolidation dynamic: trust, speed, and iteration loops

Why are Cursor, Windsurf, and Zed “eating lunch” instead of VS Code simply absorbing the features? Because developers aren’t choosing tools on capability alone—they’re choosing tools on loop time.

An AI-native editor compresses the loop from:

understand intent →
gather context →
propose changes →
let the user review →
iterate—

into something that feels immediate. If the AI needs five minutes and three manual steps to produce a coherent multi-file refactor, the “assistant” becomes another job. If it produces a reviewable change in seconds, the assistant becomes infrastructure.

Two practical selection criteria you can use right now:

Can it edit across the repo with a single intent? Try a realistic refactor on your own project. If it’s mainly confined to the current file, you’re still in the AI-added era.
Does the diff feel coherent? The best tools don’t just output code—they output a change you can safely review. Look for stable formatting, consistent naming, and minimal unnecessary churn.

There’s also a social factor: when teams standardize on AI-native workflows, code review expectations change. Instead of reviewing “suggested lines,” you review “agent-produced transformations.” That shifts how developers collaborate—and consolidates tooling accordingly.

What to do if you’re staying on VS Code (or if you’re migrating)

If you’re committed to VS Code—fair—don’t treat this as a declaration of defeat. You can still capture some of the benefits by focusing on workflow:

Use AI features that support repository context and multi-file changes rather than purely inline suggestions.
Prefer tools and workflows that produce reviewable diffs for larger changes.
Build habits around “describe the transformation, then verify the diff,” not “accept suggestions until it compiles.”

If you’re migrating, don’t start with “which editor has the best chat.” Start with: “Can I do the three tasks I do most often with fewer steps?” For many developers, that’s refactors, migrations, and test updates. AI-native editors win when those tasks become compressible.

Also, set guardrails. Even the best AI-first experiences can overshoot. Make “review before apply” non-negotiable, and require tests or linters for anything that touches critical paths.

Conclusion: the editor is becoming a co-author, not a text box

The most important shift in the IDE market isn’t that AI can write code. It’s that the editing experience is being rebuilt around AI as an interactive engine: multi-file context, natural-language transformations, and agent-style task execution are changing what developers expect from their tools.

VS Code’s extension ecosystem will remain influential, but AI-native platforms are redefining the baseline. The consolidation isn’t just about features—it’s about the workflow that feels inevitable once you’ve tried it.

Understanding WASM Components Will Make You a Better Engineer

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 30 Jul 2025 00:00:00 +0000

If you’ve ever stitched together systems with a patchwork of ABIs, you already understand the pain that the WebAssembly component model is trying to solve. The component model is the missing “adult supervision” layer for WebAssembly: a standardized way for separately compiled modules—written in different languages, built by different teams—to talk to each other without brittle, bespoke glue code. Most developers haven’t heard of it yet, but it’s the closest thing the industry has seen to a universal ABI in decades.

And once you understand it, you’ll write better systems even outside WebAssembly—because you’ll stop treating interfaces as afterthoughts.

The ABI problem we never truly fixed

An ABI (Application Binary Interface) is the contract between compiled code and the runtime: calling conventions, data layout, how values cross boundaries, what “string” means at the machine boundary, and who owns memory. For a long time, the industry has punted on universal solutions and instead invented a thousand variants:

You export functions from one environment and call them from another using a specific FFI toolchain.
You define a C struct and hope everyone interprets it the same way.
You serialize everything to bytes, because nothing else is portable enough.

This works, but it’s expensive—in complexity, in time, and in reliability. It also forces teams into a tradeoff: either constrain your integration surface (so you can keep it simple) or pay an integration tax (so you can keep it flexible).

The component model targets the integration tax head-on by standardizing the shape of interfaces, not just the ability to run code.

What “components” actually give you

A WebAssembly module is great at running code in isolation. But modules weren’t designed as a universal interop language; they’re primarily an execution unit. The component model builds a higher-level abstraction on top: a component exposes an interface, and other components can import and use that interface in a structured way.

The practical idea is simple: compile your library in one language, export a well-defined interface, and import it from another language without you manually writing low-level glue.

Where this becomes exciting is the difference between “it runs” and “it composes.”

Plain WebAssembly modules often require you to agree on calling conventions and data representation out-of-band.
Components define a standard interface model so cross-language calls can be mediated consistently.

Think of it like moving from “RPC over raw sockets” to “RPC over an IDL with agreed semantics.” You still call a function, but you don’t have to babysit every byte.

A concrete example: Rust image processing into Python

Let’s make the dream tangible. Suppose you have an image processing library written in Rust that performs resizing and filtering. You want to use it inside a Python application—without writing C shims, hand-rolling marshaling logic, or juggling memory ownership.

With a component-based approach, the Rust side exports an interface that describes what it needs and what it returns—at the component level. On the Python side, you import that component and call the functions as if they were “normal” library calls, except the runtime mediates the data crossing the boundary.

In practical terms, what changes is where the complexity lives:

You define an interface once (in the component world), not a one-off FFI binding for every consumer.
You don’t need to rebuild or reinterpret data layouts in every integration path.
The runtime has enough information to convert between representations appropriately.

Even if you don’t use Python specifically, the pattern is the same: component boundaries let you treat compiled code from other languages as reusable dependencies, not fragile experiments.

Universal ABI on the web, the server, and the edge

The “universal” part matters. If this model only works in one environment, it’s just another platform-specific solution. The component model is designed to be portable across runtimes and deployment targets, which is exactly what you want if you’re building systems that span:

The browser (where you want safe, efficient execution)
The server (where you want composable services and fast startup)
The edge (where you want predictable resource usage and fast distribution)

The value proposition is obvious: ship one artifact—one component interface—and reuse it everywhere instead of rebuilding bindings per environment.

This is why engineers who understand components tend to design interfaces more like products than like one-off glue. You stop thinking “how do I call it from here?” and start thinking “how will other systems call it reliably?”

Why you should care even if you never write components directly

You might not author component interfaces tomorrow. You might just consume them. Still, understanding the model changes how you engineer.

1) You’ll design safer boundaries

When you define an interface, you’re forced to decide questions that are easy to ignore until they break:

What are the inputs and their types?
Who owns memory?
How do errors propagate?
What is synchronous vs. asynchronous behavior?
What happens with large buffers (images, files, data streams)?

Components push you toward explicit semantics. That reduces “mystery failures” where one side assumes a different representation than the other.

2) You’ll stop over-serializing

A common pattern in cross-language integration is to convert everything to bytes or JSON. It’s robust, but it’s also slow and noisy. With a standardized interface model, you have a path to more direct calls and fewer transformations—so your system stays both fast and legible.

You still may serialize when it’s the right tradeoff, but you’ll do it deliberately rather than by default.

3) You’ll build libraries that are easier to reuse

Reusable code doesn’t only mean “it’s correct.” It means “other people can use it without heroic effort.” Components help because they turn your export surface into something that other language ecosystems can reliably import.

In other words: you ship an API contract, not just an implementation.

Shipping today: preview runtimes and real adoption

The most encouraging part is that this isn’t trapped in theory. Preview runtimes and tooling are already exploring component support, and the ecosystem is actively iterating on how developers package and consume these interfaces.

So the right move isn’t waiting for perfection. It’s building fluency now:

Learn the conceptual model: exports, imports, and interface mediation.
Track what your runtime supports today.
Prototype with one realistic integration—like the Rust image library example.
Measure the pain you eliminate: less glue code, fewer marshaling bugs, faster iteration.

If you’re thinking “but we’ll have to learn a new system,” you’re right. But the trade is worth it: you’re learning the thing that will reduce integration overhead for years, not just for one stack.

Conclusion: The best engineers treat interfaces as first-class

WebAssembly’s component model is more than a spec feature—it’s a mindset upgrade. It’s an attempt to standardize the contract between compiled worlds, so libraries become plug-and-play dependencies instead of bespoke integration projects.

If you want to be a better engineer, stop treating interfaces as the messy last step. Learn how components model boundaries, and you’ll design cleaner APIs, fewer glue layers, and more reusable systems—whether you’re working inside WebAssembly or not.

The Next.js Backlash Is Overblown (But Not Entirely Wrong)

abdecastro@protonmail.com (Antonio B De Castro) — Fri, 18 Jul 2025 00:00:00 +0000

The internet loves a villain, and lately that villain has been Next.js. The loudest criticisms—vendor lock-in, App Router complexity, confusing caching defaults, and a release cadence that feels like it never stops—are real enough to deserve attention. But the conclusion people jump to (“Next.js is broken” or “it’s all hype”) is too lazy. The truth is more interesting: Next.js has genuine architectural wins, and the discourse is partly right about where teams get burned.

Let’s separate what’s performative from what’s actionable—because if you’re building with Next.js right now, you should care about both.

What Next.js Gets Right: Modern Rendering as a Product, Not a Hack

A lot of the heat around Next.js ignores the core reason it’s so dominant: it made modern React rendering patterns feel approachable. React Server Components (RSC), streaming server-side rendering, and a pragmatic approach to hybrid static/dynamic pages are not just buzzwords—they’re architectural options you can use without reinventing the tooling each time.

Take streaming SSR. Before frameworks mainstreamed it, teams either settled for slower first paint or built brittle custom stacks. Next.js’s model lets you stream content to the browser while the server continues working. That matters for user experience and perceived performance, especially for pages that depend on multiple asynchronous data sources. Even if you never optimize “like a performance blog,” streaming gives you headroom.

Then there’s incremental static regeneration (ISR). The basic promise is simple: generate pages ahead of time, but refresh them on a schedule or on demand. Practically, this gives you an escape hatch from the binary choice between “all static” and “all dynamic.” For marketing sites, documentation, and content-heavy apps, ISR is a sweet spot. You can keep most pages fast and cacheable while still updating without redeploying everything.

My opinionated takeaway: Next.js’s success isn’t just ecosystem gravity. It’s that it turned serious rendering primitives into a developer workflow. That’s the part the backlash keeps skipping.

The Vercel Lock-In Claim: Not Wrong, Just Misframed

The “vendor lock-in” argument usually appears in two flavors.

The first is emotional: “If you use Next.js on Vercel, you’re trapped.” That’s not quite how it works. Next.js itself is a framework; you can run it elsewhere. But the second flavor is more concrete: Vercel’s platform features are so smooth—caching behavior, deployment workflow, edge/runtime integration—that they can encourage coupling to the assumptions of that environment.

Here’s a practical way to evaluate lock-in rather than doomscrolling tweets: identify which parts of your app depend on platform-specific behavior.

For example:

If you rely heavily on Vercel’s caching knobs and runtime behaviors, you may need a migration plan that explicitly tests those assumptions on your target host.
If you use route handlers and server actions in ways that map neatly to Vercel’s execution model, you might face subtle behavior differences elsewhere.
If your CI/CD pipeline, environment variables, secrets management, or build caching are all tightly Vercel-shaped, you’ve locked in operational convenience—even if the code remains portable.

So yes: the criticism has teeth, but it’s not fatal by default. Treat deployment platform features as optional enhancements, not your entire strategy. If your architecture depends on “works only when hosted like this,” that’s not a Next.js problem—it’s an engineering risk you chose.

App Router Complexity: The Problem Isn’t App Router—It’s Mental Load

The App Router critique is often presented as “it’s too complex.” That’s too vague to help. What’s actually happening is that the App Router pushes you into a different set of mental models than the old pages-based approach.

Instead of a single convention for routing and rendering, you now juggle:

Server and client component boundaries
Data fetching patterns (and their impact on caching)
Streaming and suspense semantics
Layouts, nested routes, and route-level configuration

If you’ve been building React apps for years, the conceptual shift feels manageable at first—and then the edge cases arrive.

A concrete example: imagine a team that moves a component into the client boundary to “fix a bug,” and suddenly the page stops streaming as expected or data fetching behavior changes. The app still works, but its performance characteristics and caching are no longer what the team thinks they are. The code compiles; the mental model doesn’t.

The best practical advice I can offer is to enforce architectural boundaries early:

Make “server by default” a team norm.
Treat client components as a scarce resource.
Document where data fetching happens and what caching policy is expected.
Add lightweight code review checklists for component boundary changes.

App Router isn’t inherently wrong. It rewards teams that think clearly about boundaries. The backlash exists because many teams adopted it without also upgrading their engineering discipline.

Caching Defaults: This Is the Criticism With the Most Real-World Bite

If you want one place where the backlash stops being noise and starts being useful, it’s caching. Next.js can behave in ways that feel unintuitive—especially when teams assume “it works like React” or “it works like plain Node SSR.”

Two recurring pain points show up in real projects:

Caching policy is not always obvious from the component tree. When caching is tied to route-level or fetch-level semantics, it’s easy for developers to misattribute cause and effect.
The defaults can be surprising. Developers may deploy something that appears correct, then later notice updates not showing up when they expect, or differences between local behavior and production behavior.

To make this practical, here’s what good teams do:

Decide up front which routes should be “cacheable,” “revalidated,” or “dynamic.”
For each fetch call, be explicit about caching and revalidation intent. Don’t rely on vibes.
Create a staging environment that mirrors production caching settings as closely as possible.
Add regression tests for content freshness—especially for routes that depend on CMS updates or time-sensitive data.

If your docs are “thin” (and the ecosystem often is), you compensate with internal guidance. A one-page engineering doc—“our caching rules for Next.js”—beats a week of Slack debates.

This is where the backlash is genuinely right: caching behavior needs better mental models and better tooling support. But the solution isn’t abandoning Next.js; it’s getting disciplined about cache intent and verifying freshness.

Release Cadence: Fast Doesn’t Mean Reckless—But It Can Feel Like It

Next.js evolves quickly. That’s not inherently bad—web frameworks should not ossify. But rapid release cadence can be brutal when breaking changes land and teams lack time or tooling to validate every upgrade.

The core issue isn’t speed; it’s unpredictability. When a framework changes frequently, teams need a stable upgrade pipeline:

Pin versions in lockfiles and update in controlled batches.
Run end-to-end tests for key routes (not just unit tests).
Pay attention to deprecations and migration guides early, not during firefights.
Keep an “upgrade budget” in your planning, like you would for infrastructure maintenance.

If you’re encountering “things break every time,” that’s often a process failure, not only a framework failure. Frameworks move. Your job is to insulate production from constant churn.

One pragmatic stance: upgrade regularly, but not always immediately. Move in small steps, measure, and roll forward with confidence. Teams that do this usually experience “steady improvement.” Teams that wait until they’re multiple versions behind experience “random catastrophe.”

So… Should You Use Next.js Anyway?

Here’s the nuanced position I’d actually recommend: don’t treat the Next.js backlash as a signal to abandon the framework. Treat it as a prompt to be more intentional about how you build.

Next.js’s architectural strengths—server components, streaming SSR, hybrid rendering, ISR—are real capabilities that improve the baseline quality of many applications. But the criticisms around caching clarity, App Router mental load, and operational coupling to hosting platforms are legitimate risk factors if you ignore them.

If you want a simple decision checklist:

Are you prepared to be explicit about caching policy? If not, fix that first.
Do you have team norms for server/client boundaries? If not, codify them.
Do you understand how your platform features map to deployment portability? If not, run a migration thought experiment.
Do you have a predictable upgrade process? If not, build one.

Done well, Next.js becomes less of a “framework you tolerate” and more of a platform that helps you ship faster—without surrendering control over performance and delivery.

Conclusion: The Discourse Is Loud. The Engineering Is Where the Truth Lives.

The Next.js backlash is overblown in its certainty—but not entirely wrong in its instincts. The framework’s architectural advances are worth serious credit. The pain points—caching confusion, App Router cognitive load, and platform coupling—are real enough to demand better practices, clearer documentation, and more careful team discipline.

In other words: Next.js isn’t the villain. But the backlash is a reminder that frameworks don’t remove engineering responsibility—they concentrate it.

Effective AI Code Review: A Framework for Teams

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 12 Jul 2025 00:00:00 +0000

AI-generated code can look “done” in a way human code often doesn’t—clean diffs, sensible naming, and an almost eerie confidence. But that confidence is the problem. AI doesn’t merely make mistakes; it fails in predictable ways. If your team reviews AI code the same way it reviews human-written code, you’ll systematically miss the specific bugs AI is most likely to introduce.

Below is a practical framework—built for teams—that treats AI code review as a different discipline, with its own heuristics, checklists, and testing strategy.

Why AI Code Review Breaks Traditional Heuristics

Human code review mostly targets misunderstandings: the developer read the requirements slightly wrong, chose the wrong invariant, or forgot how an API behaves. Those are real and common, but they come with telltale signs—confusing naming, awkward structure, and obvious missing cases.

AI code review fails differently:

Subtle correctness errors: The code “works” on the happy path but violates an unstated constraint (time zones, idempotency, pagination, authorization boundaries).
Confident abstraction mismatch: AI often lands on patterns that are common on the internet, not necessarily the architecture your team uses.
Edge-case blindness: The model may not consider rare-but-critical inputs—empty lists, nulls, duplicated events, malformed UTF-8, boundary timestamps.
Spec drift: The output may reflect a nearby “typical” interpretation of your request rather than your true requirement.
Failure-mode coupling: The bug type correlates with how the model generated the code (e.g., type assumptions, error-handling style, and assumptions about data shape).

So the right move isn’t “be more skeptical.” The right move is to be skeptical in the right directions—with a review checklist and targeted tests that map to AI’s predictable failure patterns.

Step 1: Establish an AI-Specific Review Checklist

A good human review checklist asks “Did we meet the requirements?” An AI checklist asks “Where might the requirements be silently violated?”

Use a two-layer checklist: static reasoning (what to look for in the diff) and behavioral validation (what to test).

Static checks (in the PR diff)

Edge-case scan
- Look for explicit handling of: empty inputs, null/undefined, negative values, overflow/underflow, and boundary conditions.
- Ask: What does the code do when the real world refuses to be polite?
Input validation and normalization
- Are there schema checks before business logic?
- Are strings normalized (trimmed, case-folded) where your domain expects it?
- Does it handle malformed data gracefully, or does it assume cleanliness?
Error handling behavior
- Does the code preserve error context for debugging?
- Does it convert errors into the right HTTP status / domain error types?
- Does it accidentally swallow errors (e.g., catch {}) or return success on failure?
Authorization and security boundaries
- AI will often “wire the flow” but forget the policy.
- Confirm that permission checks occur at the correct boundary (e.g., before data access, not after partial transformation).
Abstraction alignment with your architecture
- Does it use your service layer conventions, or does it introduce a new “helpful” pattern that bypasses them?
- Watch for: direct DB calls from handlers, ad-hoc HTTP clients, bypassing your logging/tracing utilities, reinvented caching.
Assumptions about data shape
- If the code uses fields like user.email or request.body.items[0], confirm those fields are guaranteed by your contract.
- AI often assumes optional fields are always present, especially when the prompt is vague.

Behavioral checks (questions for the author)

What invariants are guaranteed?
Example: “This operation is idempotent” or “This endpoint is safe under retries.” If the author can’t answer, you’ve found a review gap.
What edge cases are tested?
Require at least one test per risk category relevant to the change.
Where can the model have guessed wrong?
For example: time zone handling, pagination semantics, event ordering, numeric rounding rules, or database transaction boundaries.

If your team treats this as a “nice to have,” it will become theater. Make it explicit: every AI PR must satisfy the checklist—or document why deviations are safe.

Step 2: Verify Abstractions Match Your Architecture (Not the Internet)

AI tends to optimize for what’s common, not what’s correct for you. “Common” patterns can still be wrong when they conflict with your constraints: tracing, dependency injection, repository boundaries, job orchestration, or deployment topology.

Concrete example: imagine AI generates a feature that queries the database directly inside an HTTP handler:

AI output: app.get('/items', async (req, res) => { const rows = await db.query(...) ... })
Your architecture: handlers call services; services call repositories; repositories attach metrics and enforce tenant filters; tracing spans are created at the service boundary.

Even if the direct query works functionally, it can:

skip tenant scoping,
miss structured logging fields,
break metrics aggregation,
and make future refactors painful.

Your review should explicitly ask: Does this code obey our layering rules? If not, require a refactor before approving.

Practical advice: maintain a short “house pattern” doc with links to examples (e.g., “How we do DB access,” “How we do retries,” “How we do pagination”). When AI code violates those patterns, reviewers shouldn’t negotiate on taste—point to the house rules.

Step 3: Test for AI-Specific Failure Modes

AI bugs are best caught by tests that target behavior, not just implementation details. Humans can reason through “what if the developer misunderstood X.” AI requires a different stance: “what if the model made a reasonable-sounding assumption that isn’t true here?”

Here are failure-mode-focused test categories that map well to AI-generated code:

1) Boundary and emptiness tests

If the code processes collections:

empty list → should return empty result, not error
single element → should be correct
maximum size near limits → should behave predictably

If it processes time:

epoch values, daylight savings transitions, time zone offsets, and rounding boundaries.

2) Contract tests (data shape and optionality)

AI frequently assumes fields exist. Add tests that cover:

missing optional fields
unexpected types (string vs number)
unknown enum values
malformed JSON payloads

Your aim isn’t to reject everything—it’s to ensure the system fails safely and predictably.

3) Error-path correctness

Require tests for:

downstream service timeouts
invalid credentials
database constraint violations
retries and idempotency behavior

A common AI mistake is to handle “happy errors” (throwing) but mishandle “messy errors” (partial failure or retries).

4) Security-relevant tests

For endpoints:

ensure authorization happens before data access
ensure tenant scoping is applied consistently
ensure logs do not leak sensitive values

A simple test harness that verifies “unauthorized user cannot access resource ID X” can catch a surprising amount of AI-generated wiring mistakes.

5) Concurrency and ordering assumptions

AI often assumes sequential execution. Add tests for:

duplicate requests
out-of-order event arrival
concurrent updates causing race conditions

If your domain has event sourcing or background jobs, prioritize tests around deduplication and idempotency keys.

Step 4: Make Review a Collaborative Workflow, Not a Gate

Teams get stuck because they treat AI code review as a one-person “spot the bug” activity. Instead, adopt a loop where the reviewer guides the AI output into a safer shape.

Practical workflow:

Reviewer flags risks early
Before asking for changes, name the likely failure modes: “I’m worried about optional fields,” or “This pagination logic looks too optimistic.”
Author runs targeted tests and shares results
Don’t stop at “tests pass.” Ask: “Which tests cover the risk categories?”
Second iteration tightens contracts
If the model assumed types or invariants, force explicit contract checks in code (schemas, guards, assertions) and reflect them in tests.
Document assumptions in code comments or design notes
If the code relies on “items always exists,” codify it with input validation—or with an explicit comment plus a test proving the assumption.

This turns AI code review into a reliability conversation, not an aesthetics debate.

Step 5: Adopt an “AI PR” Approval Policy

You don’t need to ban AI-generated code. You do need consistency.

A simple policy teams can enforce:

AI-generated PRs require the AI review checklist (static + behavioral).
At least one reviewer must be a domain owner for changes in security, payments, data integrity, or critical business logic.
Test coverage must include edge-case categories relevant to the change—not necessarily “100%,” but “risk-aligned.”
Abstraction mismatches require refactor to house patterns, not “approval with a comment.”

To keep it lightweight, create a template reviewers can use:

Edge cases identified:
Tests added/updated:
Security/authorization validated:
Architecture alignment confirmed:
Remaining assumptions documented:

The template is the point. It prevents the review from devolving into “seems fine.”

Conclusion: Review AI Like It’s a Different Kind of Developer

AI code review isn’t harder because the code is uglier. It’s harder because AI fails in quieter ways—confidently implementing the wrong assumption. Teams win by switching heuristics: scan for edge cases, verify architecture-aligned abstractions, and test the specific failure modes AI is prone to introduce.

When you treat AI code review as a dedicated workflow—with explicit checklists and risk-aligned tests—you don’t just catch bugs faster. You build software that stays correct when the model confidently gets something slightly off.

Developer AI Skepticism Is Growing and That's the Healthiest Thing I've Seen

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 06 Jul 2025 00:00:00 +0000

Developers aren’t turning away from AI—they’re turning up the scrutiny. And that shift, paradoxical on the surface, is the healthiest sign the software industry could ask for: adoption is rising, trust is falling, and expectations are becoming more realistic.

The “paradox” isn’t a paradox

You can summarize the current mood like this: more teams are using AI tooling, but fewer people believe the output should be treated as truth. That sounds like contradiction until you notice what “trust” actually means in engineering.

In the early hype cycle, trust was often implied: if the model could generate plausible code, it must be correct. In practice, developers discovered a more useful operating system: AI is a drafting tool, not an oracle.

So the adoption-versus-trust split is not regress. It’s a maturation signal. Teams are learning to separate usefulness from authority. They’re getting value without pretending the tool is infallible.

A concrete example: a developer can use an AI assistant to scaffold a REST endpoint in seconds—then spend the next five minutes wiring validation, error handling, auth checks, and tests. The tool saves time. The human still owns correctness. That’s the new norm.

Adoption goes up because AI helps with the right tasks

Skepticism doesn’t happen in a vacuum. Developers keep using AI because it reduces friction in places where they feel the burn daily:

Boilerplate and scaffolding: CRUD endpoints, serializers, basic UI components, configuration templates.
Explaining code and APIs: turning a vague internal wiki into actionable steps.
Drafting tests and edge cases: generating initial test structures and prompting follow-ups.
Refactoring suggestions: outlining how to restructure functions, rename variables, or simplify control flow.

When AI supports these workflows, it earns its keep. People adopt tools that reduce cognitive load and cycle time—especially under tight deadlines. Even skeptical engineers will try something that saves them an afternoon.

The important nuance is that adoption doesn’t require blind faith. Developers don’t need AI to be right; they need it to be helpful enough to make review faster and outcomes better.

Trust goes down because developers have finally learned the failure modes

Where skepticism becomes “productive” is in how targeted it is. Developers aren’t just saying “AI is bad.” They’re saying, essentially: “I know how it breaks.”

In real projects, AI output commonly fails in predictable categories:

Subtle logic bugs: code that compiles but behaves incorrectly under edge conditions.
Incorrect assumptions: using the wrong library function signature, mismatched API versions, or outdated conventions.
Security oversights: missing input sanitization, naive auth logic, or accidental exposure of sensitive data.
False confidence: output that looks correct even when it’s missing required requirements or constraints.

This is why trust erodes over time. Early users treat AI like an autocomplete superpower. Later users treat it like a junior contributor: fast to produce, but needing verification.

A good mental model: if AI is used as a starting point, trust becomes rational. If it’s used as a source of truth, trust collapses quickly. The decline in trust isn’t cynicism—it’s calibration.

The healthiest teams build AI into a quality loop

The difference between “AI skepticism” and “AI fear” is whether teams build guardrails. The healthiest trajectory is not less AI; it’s more engineering discipline around AI output.

Here are practical patterns that turn skepticism into speed:

Treat AI output like a diff, not a decision

Instead of asking, “Is this correct?” ask, “What changed, and do we understand why?”

Require AI-generated code to pass through the same review checklist as human-written code.
In code review, ask for rationale, not just acceptance: “Why does this handle nulls this way?” “What happens with malformed input?”

Add tests before you trust the behavior

If AI drafts tests, great—use them—but don’t stop there. Make a habit of adding at least one “nasty” test per feature:

empty inputs
unexpected types
boundary values
permission failures

The point isn’t to catch everything. It’s to ensure the model’s mistakes become visible early—before they become production bugs.

Make the tool context-aware, not just prompt-aware

A common trap is sending a generic prompt and trusting the result. Better approach: give the model the project’s constraints.

Link to relevant interfaces or type definitions.
Provide the expected request/response schema.
Tell it the conventions: error format, logging style, naming rules, timeouts.

Skeptics don’t just ask for better answers—they ask for better inputs.

Use automated checks to “outvote” the model

Put friction where it matters:

static analysis
linting
formatting enforcement
type checking
dependency vulnerability scans

Let tools catch the easy-to-miss failures so humans can focus on the hard reasoning.

Skepticism is becoming a skill, not a stance

This shift matters: developers aren’t merely refusing AI. They’re developing a new competency—knowing when to trust, when to verify, and how to structure work so verification is cheap.

Think of it like unit testing. At first, “test everything” sounds like overhead. Over time, it becomes a superpower because it changes how you work. You move faster because you’re not constantly guessing.

AI skepticism is following the same path. Teams that learn to evaluate AI output quickly aren’t resisting progress; they’re upgrading their process.

For example, a developer might adopt a rule like:

AI drafts: generate candidate implementations.
Humans verify: confirm correctness, align with requirements, and review security implications.
CI enforces: fail builds on style, type, and test regressions.

That’s not anti-AI. It’s professionalized AI usage.

Why this maturity beats the hype cycle every time

The industry has been here before: tools arrive promising miracles, everyone rushes to adopt, and then reality kicks in. The difference now is that the response is healthier.

Instead of doubling down on magical thinking, developers are doing something better: they’re turning lessons into norms.

Trust is earned through testing and review, not through plausibility.
AI is evaluated like any other contributor: output quality varies by task and context.
Feedback loops improve results over time, without pretending the first version was perfect.

If you want a single sentence summary of what’s happening: the tools are getting used more widely, and expectations are getting corrected faster than marketing can inflate them.

That’s how an ecosystem becomes durable.

The rise of developer skepticism isn’t a warning sign—it’s a maturity milestone. As AI becomes embedded in everyday workflows, trust naturally becomes conditional: useful for drafts, verified for decisions.

The healthiest thing we can do—individually and as teams—is exactly what skeptical developers are doing now: use AI to move faster, then prove correctness with the engineering fundamentals that have always mattered. When adoption and evaluation grow up together, the hype cycle stops driving the roadmap—and craft finally does.

AI Coding Agents Need Guardrails, Not Cheerleaders

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 24 Jun 2025 00:00:00 +0000

AI coding agents have moved from “impressive demo” to “just ship it.” And once teams adopt the unrestricted “let the agent do everything” mindset, the results stop being clever—and start looking like familiar technical debt with a faster keyboard. The pattern is now painfully predictable: untested code, direct commits to main, and pull requests that get rubber-stamped because someone said, “The AI checked it.”

That’s not agentic development. It’s automation without responsibility.

The hype cycle’s hidden failure mode: speed over correctness

The original promise of AI coding agents was simple: reduce toil. Generate code quickly, propose changes automatically, and help teams move faster. The failure mode appears when “faster” quietly becomes “always.”

In the unrestricted approach, agents are often granted four freedoms at once:

Write code without strong constraints (no enforced test expectations, no required coverage thresholds).
Execute changes without sandboxing (shared environments, persistent credentials, broad filesystem access).
Commit directly to privileged branches (main, or equivalent).
Submit PRs with authority (“LGTM—AI verified it”), which discourages real review.

Notice how each freedom removes a human control point. Individually, that might feel efficient. Together, they create a new class of technical debt: changes that look structured, compile “sometimes,” and pass casual checks—yet fail under real usage, produce security exposure, or break downstream assumptions.

The key editorial point: agents don’t create correctness. They create plausible code. Without guardrails, plausibility becomes policy.

Why “the AI checked it” is a trap

Teams already understand the gap between “code generated” and “code validated.” We’ve built entire engineering cultures around that gap: CI gates, staging environments, test suites, linters, code review, and incident response.

“AI checked it” collapses that gap through social convenience. It’s a claim that substitutes process for proof.

Consider what often happens in practice:

The agent runs a thin local test set (or none), because it can’t reliably know what matters for your domain.
The agent “updates tests” to make them pass, because it can optimize for the visible objective rather than the underlying requirement.
The agent’s PR description is persuasive and specific—because language models are good at writing explanations—even when the changes are wrong.

A sharp rule of thumb: if review criteria changed from “can we trust this?” to “the bot said so,” you’re past the point where technical debt is preventable.

Guardrails aren’t bureaucracy—they’re a control system

A good agent workflow is not “permissionless coding.” It’s a bounded system that makes failure expensive and success measurable. The constraints aren’t there to slow you down; they’re there to keep your engineering pipeline honest.

Here’s the guardrail stack I’d treat as non-negotiable for production-grade AI coding agents:

Sandbox execution (and least privilege by default)

Run agent code generation and execution inside isolated environments. No broad network access. No long-lived secrets. No direct access to production-like credentials.

Practical example: if the agent needs to run integration tests, give it a test-only service account with read-only access and scoped tokens, and route it through a test harness that cannot reach external systems.

Mandatory test expectations (not optional “best effort”)

Agents should not be allowed to merge code that doesn’t meet defined quality gates. Define:

Minimum unit test coverage for touched modules (even if lightweight)
Required test categories (e.g., unit + integration for API changes)
A policy for “no tests added” (usually: fail the pipeline)

Crucial detail: make the agent responsible for writing the tests only inside the constraints you enforce. Your CI is the enforcement mechanism; the agent is just a contributor.

Human review gates (with real checklists)

Keep humans in the loop. But don’t leave review to mood or memory—encode review gates into tooling and PR templates.

Example checklist for AI-generated changes:

Behavioral correctness: does this change the system in intended ways only?
Edge cases: are boundaries and error handling covered?
Security posture: are secrets handled correctly? Are inputs validated?
Maintainability: are changes localized? Is the diff reasonable?

The goal isn’t to distrust the agent; it’s to make review systematic even when the code is generated quickly.

Scope limitations (timebox, file allowlists, and change budgets)

An unrestricted agent is a chaos generator with a badge. Use:

Time budgets (e.g., agent can iterate for 5–10 minutes per task)
File allowlists (e.g., only under src/ and tests/ for a given objective)
Change budgets (e.g., cap the number of files or lines modified)

If the agent can rewrite half your repo, you’re not using an assistant—you’re running a demolition crew with autocomplete.

The anti-pattern: committing to `main` like it’s a spreadsheet

The most corrosive behavior in the current wave is “agent commits to `main because it’s confident.” Confidence is not a release criterion, and AI uncertainty does not translate cleanly into engineering risk.

Instead, treat agent-generated changes like any other untrusted input: they must pass through the same gates as human-authored PRs—just faster and with more explicit evidence.

A robust workflow looks like this:

Agent creates a branch (not PR-less commits).
CI runs the full relevant test suite.
Required checks succeed (tests, lint, security scanning where applicable).
Human review happens.
Merge happens only after gates pass.

If you’re tempted to bypass steps “because the bot is good,” ask what you’re optimizing for:

Throughput (fine)
or system reliability (better)

The trick is to recognize that throughput without reliability is just creating the next incident faster.

A better model: “agent as implementer,” “team as validator”

Agentic development shines when you separate responsibilities. An AI coding agent should be an implementer that proposes changes, but it shouldn’t be the final arbiter of correctness.

Here’s a practical division of labor that works in real teams:

You define the contract: issue requirements, acceptance criteria, APIs involved, and risk boundaries.
The agent drafts the implementation: code changes and accompanying tests.
Your pipeline validates everything: deterministic checks, unit and integration tests, security tooling, and build verification.
Humans arbitrate ambiguity: design tradeoffs, review context, and domain-specific correctness.

When teams adopt this model, agents become useful without becoming dangerous. You get speed where it matters—drafting, refactoring, test generation under constraints—while preserving the human authority that final validation requires.

Concrete example: say you want to add a new endpoint. A good agent workflow would:

generate the endpoint handler,
update the routing,
add tests for success and failure paths,
and produce a PR that clearly links new tests to new behavior. But it should not:
guess at authorization rules without confirmation,
skip integration tests because “unit tests passed,”
or modify unrelated modules to “make things work.”

Conclusion: Guardrails are how you keep agent speed from becoming debt

AI coding agents are not the enemy. Unrestricted adoption is.

If you want agents to reduce technical debt, you need them inside a control system: sandboxed execution, mandatory tests, human review gates, and strict scope limits. Anything else turns “agentic development” into “automated regret”—a faster way to ship plausible code that your team will have to untangle later.

Be the adult in the workflow: let the agent draft, but make correctness expensive to get wrong and easy to verify when it’s right.

Valkey Forked Redis and Nobody Panicked

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 18 Jun 2025 00:00:00 +0000

There aren’t many technology stories where “corporate licensing changed” turns into “everyone quietly kept shipping.” The Valkey fork is one of them. When Redis Ltd. tightened its license, the community didn’t build a new database from scratch or demand users rewrite their world—it forked, kept the interface steady, and made the ecosystem resilient. The result wasn’t just a technical win. It was a cultural one: open-source infrastructure can survive corporate capture—without putting engineers on a two-week migration treadmill.

What Happened When Redis Got Restrictive

Redis didn’t suddenly become unusable. The alarm sounded because Redis’s licensing direction shifted toward restrictions that many organizations—especially those using Redis as infrastructure at scale—viewed as a risk. In practice, licensing changes can be as operationally disruptive as breaking API changes: procurement, legal review, vendor contracts, compliance workflows, and internal policy all have to catch up.

And unlike a normal “upgrade,” licensing friction tends to propagate through an organization slowly—until it abruptly doesn’t. The moment a company’s leadership decides it wants certainty, the engineering plan becomes: ensure the dependency is stable, legally safe, and technically compatible.

That’s where the fork mattered. A fork is often framed as a last resort. Here, it became a strategy: keep the system the same for users, while removing the license uncertainty at the source.

Valkey: Same Shape, Different Governance

The Linux Foundation forked Redis into Valkey. The key point—one that engineers care about more than headlines—is that Valkey wasn’t designed to be “Redis, but different.” It was designed to be Redis, but with a governance and licensing story that didn’t trigger the same existential worry.

In an ideal world, migrations are boring. Valkey’s success hinged on boring being possible:

API compatibility: Applications that speak Redis commands didn’t need to learn a new dialect.
Performance parity: Systems that depended on Redis’s speed didn’t have to justify a sudden slowdown with benchmarking theater.
Data format compatibility: Stored data didn’t become a museum piece that required an elaborate conversion project.

That combination is what makes “overnight migration” realistic. If the new system changed the wire protocol, the data model, or the behavior of common commands, users would have noticed immediately. Instead, users noticed something else: their infrastructure stopped being exposed to a licensing cliff.

How the Ecosystem Switched Without Users Feeling It

Fork stories fail when they stay trapped inside engineering circles. This one didn’t. Major cloud providers and vendors—AWS, Google, Oracle, and Ericsson among them—backed Valkey. That matters because most production Redis deployments aren’t “pets.” They’re services managed by platforms, tooling, and automation.

When those layers adopt a compatible alternative, the migration path becomes less like a grand rewrite and more like a dependency swap.

Here’s what “seamless” typically looks like in practice:

Managed service adoption
Instead of every team compiling and operating a new Redis-like database, platform teams switch the backing implementation. Internal services keep connecting to the same endpoint style—often with the same client libraries.
Compatibility at the edges
Many production issues show up where assumptions leak: client versions, proxy behavior, command parsing, replication semantics. Because Valkey kept compatibility close to Redis, these edge cases were less likely to break in surprising ways.
No “big bang” deployments
Teams can roll changes gradually—cluster-by-cluster, region-by-region—using feature flags and deployment pipelines. When the interface is compatible, the risk profile drops dramatically.

A concrete example: consider a web service that uses Redis for session state and caching. If the application is already configured around standard Redis commands and the client library is compatible, the team can focus on validating performance and operational behavior—rather than rewriting business logic or rethinking serialization.

The “nobody panicked” part wasn’t magic. It was engineering design aligned with operational reality.

Why Standard Protocols Beat Vendor Licensing

Licensing decisions are corporate decisions. Infrastructure is an operational commitment. The tension between those two realities is where open-source resilience lives or dies.

When a project is built on standard protocols and stable interfaces, it becomes harder for a single vendor’s licensing policy to strand users. Engineers can swap implementations without forcing a rewrite of their entire stack.

This is the deeper lesson: the Redis protocol isn’t just an implementation detail. It’s the contract that lets ecosystems evolve. As long as clients, tooling, and data expectations remain grounded in that contract, forks are viable responses to governance failures—not disruptive events.

You can see this principle in other infrastructure categories, too:

If you use SQL, moving between engines is painful but often manageable.
If you use container interfaces, you can shift runtimes without breaking the world.
If you standardize on HTTP semantics and clear API boundaries, you can replace backends while keeping clients stable.

Valkey didn’t invalidate Redis. It demonstrated that a widely adopted protocol can outlive one company’s licensing choices—because users have options and ecosystems have inertia.

Practical Advice: How to Build for This Kind of Shock

The Valkey story is inspiring, but you shouldn’t bet your production uptime on hope. If you run infrastructure that could face licensing or governance risk, you need a plan that assumes “the dependency may change.”

Here are practical steps that reduce your blast radius:

1) Treat compatibility as a requirement, not a hope

Before you adopt any critical dependency, confirm what would break if the implementation changed. Is your application tied to one vendor’s extensions? Are you relying on undocumented behavior? Is your data model vendor-specific?

If you’re using the “standard path” (well-defined commands, stable semantics), you’re already doing the right thing.

2) Keep dependency surfaces small

If Redis is embedded everywhere—directly into app logic, analytics jobs, and custom tooling—you’ll feel migration pain. Prefer centralized access patterns: consistent clients, shared libraries, standardized command usage, and a small number of integration points.

3) Maintain a compatibility test harness

When you can run the same test suite against multiple implementations, you turn migration from a philosophical debate into a technical exercise. Validate:

command behavior for your critical operations
serialization/deserialization logic
failure modes (timeouts, reconnect behavior)
replication and persistence behaviors (as applicable)

4) Have a “provider swap” playbook

Define what changes in your stack when the backing implementation changes:

infrastructure configuration
deployment pipeline steps
monitoring and alerting assumptions
rollback procedures

Your goal isn’t to be ready for every scenario. It’s to be ready for the one that’s most common: “the provider changed the terms.”

5) Coordinate with platform and legal early

One lesson from licensing-driven transitions: engineering isn’t the only bottleneck. Procurement timelines, contract language, and internal policy reviews can drag out while systems keep running. Bring stakeholders into the process with clear technical compatibility evidence and an operational migration plan.

If you wait until a contract deadline hits, you’ll end up doing emergency work with insufficient time to test.

The Real Takeaway: Forks Are a Feature of Open Infrastructure

Valkey’s success wasn’t just that the fork existed. It was that it was usable immediately: compatible interfaces, compatible data, and broad backing. That’s how you keep momentum while others scramble.

In the broader open-source ecosystem, forks are often portrayed as messy. But they can be orderly and constructive when the project’s core interface is stable and widely adopted. More importantly, the community demonstrated something executives and architects should notice:

Open-source infrastructure with standard protocols isn’t fragile. It’s resilient by design.

And that resilience matters now, in an era where corporate control can change overnight through licensing decisions, distribution terms, or “enterprise-only” constraints. The best defense isn’t panic. It’s architecture—and the quiet confidence that the ecosystem can carry users forward when one company’s incentives diverge.

Conclusion: Redis Outlived the Decision, Not the Protocol

Valkey proved that when an open-source project is anchored to a stable protocol and a broad ecosystem, users don’t have to choose between compliance and continuity. They can switch providers quickly, keep APIs steady, preserve data compatibility, and continue shipping—without turning every licensing change into a crisis.

The Redis protocol will outlive any single company’s licensing decisions because the protocol is bigger than the company. That’s the kind of infrastructure story worth building for.

FastAPI's +5 Point Surge Signals Python's Async-First Future

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 12 Jun 2025 00:00:00 +0000

For years, Python web development lived with a quiet tradeoff: either you got speed and clarity, or you got “flexibility” that quickly turned into ambiguity. FastAPI didn’t just improve one API—it changed what developers expect from frameworks. The latest momentum—often described as a noticeable usage uptick—shouldn’t be read as a single team winning. It’s a signal that Python’s ecosystem is moving toward async-first behavior, type-driven correctness, and documentation that isn’t an afterthought.

This is how FastAPI forced the conversation, and why competitors like Litestar—and even heavyweight incumbents like Django—are now responding with the same underlying message: guardrails beat guesswork.

FastAPI’s Real Innovation Wasn’t Speed—It Was Intent

Yes, FastAPI can be fast. But speed isn’t why teams adopt it and stay. The real innovation is that it turns developer intent into machine-checkable structure—then uses that structure to automate the boring parts: validation, serialization, and documentation.

The signature move was leveraging Python type hints as a first-class specification. Instead of writing parallel schemas, validation logic, and OpenAPI descriptions by hand, you express your data model once:

from typing import Optional
from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class UserIn(BaseModel):
 name: str
 email: str
 age: Optional[int] = None

@app.post("/users")
def create_user(payload: UserIn):
 return {"ok": True, "user": payload}

That UserIn type isn’t “just typing.” In practice, it becomes input validation, shapes the JSON schema, and drives the generated API docs. This is the opposite of the old Flask-era vibe: “figure it out yourself.”

Opinionated frameworks don’t remove freedom—they remove uncertainty.

The guardrails developers actually feel

Validation happens automatically based on your declared types.
Errors become consistent and easier to troubleshoot.
Docs are accurate by construction because they’re derived from your types.

When your API is a living product, “accurate by construction” is a competitive advantage.

Async-First Doesn’t Mean “Always Async”—It Means Designed for Concurrency

FastAPI made async feel natural rather than bolted on. But the more important shift is conceptual: the framework is built around non-blocking request handling, which aligns with how modern Python systems behave—event loops, concurrent I/O, and streaming responses.

You can write sync endpoints, but the default path encourages async where it matters:

from fastapi import FastAPI
import httpx

app = FastAPI()

@app.get("/weather")
async def weather(city: str):
 async with httpx.AsyncClient() as client:
 r = await client.get(f"https://example.com/weather?city={city}")
 return r.json()

This isn’t just about “use async def.” It’s about building a framework where concurrency is a first-order concern: middleware, dependency injection, background tasks, and streaming can all cooperate with the async model instead of fighting it.

Practical advice: treat async as an I/O contract. If your endpoint touches the network, the database, or the filesystem, async is often worth it. If you’re doing CPU-heavy work, keep it out of the event loop—use worker processes or task queues.

Type Hints Became a Product Feature, Not Developer Ornamentation

Python’s typing story has matured for years, but FastAPI turned type hints into a customer-facing feature. And that’s a subtle but decisive change.

In classic setups, types are for IDEs and static analysis; runtime behavior still depends on handwritten validation and serialization. FastAPI collapses that separation. When types are enforced at runtime, they become part of your API’s contract.

This is also why FastAPI-style ecosystems tend to feel “self-documenting.” When your endpoint signature is declarative, the system can:

generate accurate OpenAPI schemas,
enforce constraints like Optional, lists, enums, and nested models,
document parameter metadata without duplicating work.

Practical example: constrained inputs save you from an entire category of bugs.

from pydantic import BaseModel, EmailStr, Field
from fastapi import FastAPI

app = FastAPI()

class Signup(BaseModel):
 email: EmailStr
 password: str = Field(min_length=12)

Now you’ve built enforcement into the contract. Your users get clear validation feedback, and your logs stop filling up with predictable “bad request” chaos.

If you’ve ever supported a production API with loosely validated payloads, you already know why teams gravitate toward type-driven frameworks.

Litestar’s Challenge: Same Philosophy, Different Edges

FastAPI didn’t create the desire for type-driven APIs, but it proved it could become mainstream. That’s why Litestar’s rise matters. It’s not “yet another web framework.” It’s evidence that the philosophy—typed contracts, async capability, and reduced boilerplate—is now competitive territory.

Litestar positions itself as modern and developer-experience focused, aiming to deliver a similar promise: write clean Python, get structured request/response behavior, and keep the API documentation aligned with reality.

The practical question for teams isn’t “Is Litestar better than FastAPI?” It’s “Do we want the async-first, type-driven ergonomics—and are we willing to bet on the ecosystem around it?” If your team cares about long-term maintainability, that philosophy is increasingly the default expectation.

A simple migration mindset helps:

Start new services in the framework whose development ergonomics your team already trusts.
When migrating legacy code, focus on one vertical slice: request models + validation + docs + one database-backed endpoint.
Keep endpoint logic pure and isolate side effects so async execution and testing stay manageable.

Framework choice matters less than the architectural pattern: typed boundaries + explicit I/O + predictable errors.

Django, Too: The Incumbent Is Moving Toward Async

The most telling signal is that even Django—synonymous with batteries included and “just works”—has invested in async support. That doesn’t mean Django is suddenly “an async-only framework.” It means the ecosystem can’t ignore async anymore.

Why this matters: Django’s adoption pattern is conservative. Teams use it because it’s stable, familiar, and supported. When Django commits effort toward async, it sends a clear message: the market expects concurrency-ready web stacks as a baseline, not an optional add-on.

The broader point is cultural. “Figure it out yourself” is increasingly unacceptable when teams need predictable behavior under load, consistent request validation, and reliable documentation for integrators.

FastAPI helped shift expectations. Now the whole ecosystem is converging toward the same outcomes:

async-first capability,
type-driven contracts,
automated documentation,
guardrails that scale with teams and complexity.

What This Means for Your Next Python Service

If you’re building a new API—or rewriting one that’s stuck in documentation drift and validation chaos—here’s the opinionated guidance that falls out of the FastAPI-led wave.

Choose a framework that treats types as runtime contracts

Your endpoints should describe your data clearly, and your system should enforce it automatically. This reduces bugs and support burden. It also makes your API easier to integrate with, because consumers can trust the schema.

Make async decisions based on I/O boundaries

Async is not a religious requirement. But if your service spends most of its time waiting—databases, HTTP calls, message queues—async-first design reduces waste and improves throughput. If you do heavy CPU work, offload it.

Don’t confuse documentation with truth

If your docs are hand-maintained, they will drift. Prefer frameworks where your declared models generate the OpenAPI schema. This is how you keep contracts stable even as code evolves.

Treat validation as part of your public API

Validation isn’t only about protecting your database. It’s about giving clients predictable error shapes and clear constraints. Typed models help you get this right without writing a custom validator for every field.

Conclusion: FastAPI’s Surge Is a Forecast, Not a Trend

FastAPI’s momentum isn’t merely a single framework’s success story. It’s a forecast of where Python web development is headed: async-first concurrency built into the foundations, and type hints elevated into real runtime contracts that generate accurate behavior and documentation automatically.

The era of “flexibility over guarantees” is ending—not because Python lost its soul, but because teams found something better: guardrails that don’t slow you down, and APIs that explain themselves while staying correct.

Why PostgreSQL's Community Is Its Biggest Competitive Advantage

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 05 Jun 2025 00:00:00 +0000

Most databases try to win on features—better indexing, faster joins, nicer tooling. PostgreSQL wins on something harder to copy: a community that turns upgrades into ecosystems. Extensions expand Postgres without bloating the core. Conferences spread hard-won lessons faster than any marketing cycle. And a contributor culture that’s distributed across companies—not owned by one—keeps the project resilient.

If you’ve ever felt that proprietary platforms grow “only when the vendor wants,” PostgreSQL’s community model will feel like a breath of fresh air. Here’s why that matters, and how to think about it when choosing a database strategy.

The real moat isn’t core—it’s the extension ecosystem

It’s easy to look at PostgreSQL feature checklists and conclude “other databases can do that too.” The more interesting question is: How does the system evolve without turning into a kitchen sink?

PostgreSQL’s extension model is the answer. Extensions let the database grow capabilities as opt-in add-ons, usually in separate packages with clear boundaries. You can adopt what you need without dragging the entire world into a monolith of features.

Think about workflows that typically belong outside the database core:

Auth and identity integration: You can add what you need—without forcing every installation to carry the same assumptions.
Custom indexing strategies: When a team needs something specific (for example, a new way to index a domain type), extension authors can build it without waiting for a global release cycle.
Specialized data features: Geospatial, time-series helpers, vector tooling, and operational utilities often arrive through extensions and community libraries rather than kernel-level rewrites.

Practically, this changes how you plan upgrades. In many proprietary ecosystems, “new capability” often means “new licensed version,” sometimes with migration pain. With PostgreSQL, new capability frequently means “install an extension” and move on. Your roadmap becomes modular.

And that modularity compounds. Once an extension has users, it tends to attract maintenance contributors, bug fixes, performance tuning, documentation, and integration work. The ecosystem doesn’t just add features—it improves them in the open.

Community contributions beat vendor roadmaps

Proprietary databases operate on a simple premise: the vendor decides what matters, when it ships, and how it’s supported. That’s not inherently bad—but it does create a predictable dynamic: innovation tends to lag behind community experimentation because the experimental work has to pass through a gatekeeper.

PostgreSQL’s model is fundamentally different. It treats contributions as a first-class development pipeline. That means:

Ideas originate everywhere: from startups, from enterprise teams, from researchers, from individuals who simply care.
The best solutions have to earn their place: they go through review, testing, and iteration.
The project can absorb innovation without adopting everyone’s worldview: extensions help keep the core clean while still enabling growth.

The key is not that PostgreSQL is “more innovative than any vendor.” It’s that the incentives are aligned with long-term improvement. When contributors upstream changes, the benefits aren’t trapped behind a product SKU. They become part of the common foundation.

That’s the competitive difference. Features are easy to clone. A living contribution culture is not.

Conferences create a knowledge network, not just hype

Software communities don’t scale with Git commits alone. They scale with shared context—what works, what breaks, and what’s actually maintainable in production.

This is where PostgreSQL conferences matter. PGConf events across regions do more than entertain. They turn practical experience into reusable patterns. You get sessions on extension design, replication trade-offs, performance investigations, migrations, and operational playbooks—not just “look at our demo.”

Here’s what that means for teams making real decisions:

Architectural clarity: You hear how people structure workloads, partitioning strategies, and indexing approaches under constraints similar to yours.
Faster troubleshooting: When a bug or behavior shows up, there’s often precedent in community discussions.
Better integration instincts: You learn where extension boundaries make sense and where they don’t.

The strongest conferences share one trait: they reward depth. They aren’t only about features; they’re about how to make those features reliable. That operational knowledge is what many teams struggle to acquire quickly—especially when they’re trying to build on a database that isn’t “their team’s database,” but rather a dependency they can’t afford to misunderstand.

Distributed companies, shared ownership

One of the most underappreciated advantages of PostgreSQL is that no single company controls the project. That doesn’t mean there’s no corporate involvement—it means corporate involvement is accountable to the project and the community, not to a private roadmap.

This distributed ownership shows up in the services ecosystem:

Neon focuses on Postgres-based cloud offerings with modern scaling approaches.
Supabase builds developer-centric platforms on top of Postgres for application teams.
Crunchy Data supports production-grade deployments, operational tooling, and lifecycle management.
Tembo offers managed capabilities around Postgres and extensions, helping teams move faster without giving up the flexibility of the underlying database.

These companies compete in the market, but many also contribute upstream—whether that’s improving extensions, sharing integration learnings, or helping stabilize the ecosystem.

The practical consequence is trust. When your database is backed by a community where multiple organizations have skin in the game, your risk profile changes. You’re less likely to face sudden product pivots, deprecations without meaningful alternatives, or “platform lock-in” that’s really just a business decision.

In other words: community isn’t only a technical advantage. It’s a governance advantage.

Sustainable open source looks like a feedback loop

A lot of open source projects begin as code and end as abandoned repositories. PostgreSQL is different because it has a feedback loop:

People use Postgres in real systems.
They build extensions, tools, and integrations to solve practical problems.
Those solutions accumulate users.
Community maintainers and contributors refine and upstream the best ideas.
The improved ecosystem enables broader adoption and more contributors.

This creates momentum that doesn’t depend on a single funding cycle or a single product manager’s priorities.

You can see the loop in the way extension ecosystems often mature: initial implementations solve a problem, then the community gradually improves performance, documentation, compatibility, and operational tooling. The “shape” of the system stays flexible because growth is compartmentalized.

And because the core remains stable, you avoid the “big-bang evolution” problem. Teams can adopt new capabilities without constantly rewriting everything around the database. That’s a major reason Postgres continues to be a sensible default for organizations that expect to evolve their applications for years.

How to capitalize on PostgreSQL’s community advantage (not just admire it)

The smartest teams don’t just pick PostgreSQL—they leverage the ecosystem consciously. Here are practical ways to do that:

1) Start with the extension model, but don’t overextend

Before you bolt on ten extensions, map your requirements to clear boundaries:

What belongs in the database (data integrity, core query needs)?
What belongs in the application (business logic, orchestration)?
What belongs in the ecosystem (indexing helpers, operational tooling, specialized types)?

A smaller, well-chosen extension set is easier to maintain and upgrade.

2) Treat community adoption as an engineering discipline

When you adopt an extension, do the same due diligence you would for internal libraries:

Verify compatibility with your PostgreSQL version.
Review update cadence and maintainers.
Test performance under realistic workloads.
Document rollback paths.

Community support is strong, but you still need internal operational rigor.

3) Build a habit of reading and participating

If you maintain anything around Postgres—migrations, operational scripts, custom extensions, query tooling—contribute back when you can. Even small contributions (bug fixes, documentation improvements, example recipes) reduce future maintenance burden for everyone, including you.

You don’t need to be a core committer. You need to be part of the feedback loop.

4) Use conferences to accelerate your internal playbook

Send engineers who own production concerns. Ask them to capture learnings immediately:

what patterns are recommended,
what trade-offs are common,
what pitfalls showed up in real deployments.

Then turn that knowledge into internal documentation and decision templates. The value of conferences isn’t the talk—it’s what you operationalize afterward.

Conclusion: Postgres wins because the community keeps compounding

PostgreSQL’s competitive advantage isn’t that it has every feature under the sun today. Plenty of databases can match capabilities in isolation. PostgreSQL’s lead comes from compounding: an extension ecosystem that scales without core bloat, a contribution culture that isn’t trapped behind a single vendor roadmap, and a global set of conferences that turn hard-won production lessons into shared knowledge.

In the long run, sustainable advantage belongs to communities that keep improving the platform after you choose it. PostgreSQL’s community doesn’t just support users—it continuously upgrades the system’s future. That’s why its momentum isn’t a trend. It’s a trajectory.

The State of Rust in 2025: Beyond Systems Programming

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 31 May 2025 00:00:00 +0000

Rust’s reputation used to be a narrow one: “systems programming, but safer.” In 2025, that framing feels like an old map. Yes, Rust is still excellent at low-level work—but its ecosystem has broadened so aggressively that “beyond systems” isn’t a side quest anymore. It’s the main plot.

What changed isn’t that Rust suddenly became something it isn’t. It’s that the supporting cast—frameworks, tooling, deployment paths, and libraries—matured enough to make full products practical. If you’re still treating Rust as a specialty language, you’re leaving capability on the table.

Web development: Rust is no longer a thought experiment

For years, the argument against Rust web development was less about performance and more about ergonomics and ecosystem breadth. That conversation has shifted. You don’t have to assemble a web stack from scraps anymore, and you don’t have to compromise on maintainability to get “Rust-level correctness.”

On the server side, Axum and Actix-web have become the kinds of frameworks people actually build businesses with. Axum’s routing and extraction model makes request handling feel clean and composable—useful when your API surface grows beyond simple CRUD. Actix-web, meanwhile, shines when you want a mature, battle-tested event-driven approach and fine control over concurrency patterns.

Practical example: imagine building an API gateway that routes to internal services, applies auth, logs structured events, and enforces rate limiting. In Axum, you can structure this as layers/middleware and request extractors so the core handlers stay readable. In Actix-web, the ecosystem supports a straightforward decomposition into services, middleware, and async handlers—without forcing you into a framework style that doesn’t match your team.

On the frontend side, the ecosystem has also moved past “hello world.” Leptos targets a reactive programming model that pairs well with Rust’s strengths: explicit state, predictable data flow, and tight integration between backend and UI logic. Dioxus brings a component-based mental model familiar to React users, but with Rust at the core. The result is a path to full-stack development where your server and UI can share types and build on the same language semantics.

If your organization has a TypeScript-heavy web stack, adopting Rust for the frontend can be incremental: start with a small internal tool, admin dashboard, or performance-sensitive UI, and expand only when the developer experience holds up.

CLI and tooling: Rust’s sweet spot is productivity now

Rust has always been good at shipping reliable binaries. In 2025, that reliability comes packaged with ergonomics: argument parsing libraries that fit well into real codebases, solid patterns for logging and configuration, and build tooling that integrates cleanly with CI/CD.

For CLI apps, the story is straightforward: Rust is fantastic when you want predictable behavior, fast startup, stable dependency management, and binaries that you can distribute without turning your infrastructure into a science project.

Practical example: you’re building a deployment helper that:

validates environment configuration,
packages a build artifact,
uploads it to storage,
triggers a remote deploy,
prints a human-readable summary plus machine-readable logs.

Rust lets you model the workflow as a set of explicit steps with strong error handling. The “important” part is not the syntax—it’s how errors remain structured instead of dissolving into strings. When something breaks (an auth token is missing, a path is wrong, a network call fails), your CLI can exit with useful codes and actionable messages.

Opinionated takeaway: if you’re still shipping operational tools in loosely typed scripts, Rust CLIs are the upgrade path that tends to pay back quickly—in fewer support tickets, faster debugging, and fewer “works on my machine” incidents.

WASM: the performance story is real, but the constraints are clearer

WebAssembly in 2025 is not “Rust’s magic trick.” It’s an engineering tool with constraints you need to respect: sandboxing rules, interop boundaries, bundle size considerations, and the reality that not every workload benefits from moving to WASM.

But Rust remains one of the cleanest ways to produce WASM modules that are memory-safe and maintainable—especially when you’re compiling predictable computational workloads. Think:

image processing kernels,
parsers and validators,
encryption/decryption helpers,
deterministic transformation pipelines.

Practical example: suppose you need to validate and normalize user-provided files before sending them to your backend. A WASM module can run locally in the browser for responsive UX—while your server repeats the same logic for correctness. Rust’s type system and explicit error handling make it far easier to keep the behavior consistent across environments.

The “gotcha” to plan for is interface design. Keep the surface area between JS and WASM narrow: avoid chatty calls, batch work, and design clear data formats. If you treat WASM as a low-level compute engine with a tight API, you’ll get a system that feels fast and reliable rather than fragile.

Desktop apps: Tauri turns “Rust for UI” into a deployment advantage

Desktop apps used to mean heavyweight frameworks. Electron made sense when iteration speed dominated everything else. But as teams matured, the pain points became obvious: memory footprint, slower cold starts, and bundling overhead. Tauri changes the equation by letting Rust own the core and wrapping a lightweight webview for UI.

In practice, this affects more than performance. It affects how you ship updates, how you manage resource usage on lower-end machines, and how you build apps that behave consistently.

Practical example: build a cross-platform desktop companion for a developer tool—syncing state, managing local configuration, and providing an audit-style UI with a web tech stack. With Tauri, the Rust side can handle the “real work”: filesystem access (where appropriate), process orchestration, encryption, and communication with your backend. The web UI can remain familiar for frontend developers, while the system-level functionality stays in Rust’s safer domain.

The key point: Tauri isn’t just “Electron but smaller.” It’s a different architecture. Your developers stop treating the backend and desktop core as a JavaScript problem and start treating it like a product-grade systems problem—with Rust in the driver’s seat.

Embedded: Rust is no longer a research project

Embedded isn’t just “Rust as a better C.” In many cases it’s Rust as the language that makes codebases sustainable—because ownership and types reduce entire categories of bugs that are expensive to diagnose when you can’t replicate hardware states on your desk.

The embedded Rust ecosystem is mature enough that projects are serious, not experimental. You’ll see libraries and tooling aimed at microcontrollers, drivers, and runtime support designed for production realities: constrained memory, tight timing, and the need for predictable behavior.

Practical example: you’re implementing firmware for a sensor node that:

reads data on an interrupt-driven schedule,
buffers samples safely,
encodes packets for transmission,
handles power state transitions,
reports errors in a way you can interpret in the field.

Rust’s value is not that it’s “safe” in a marketing sense—it’s that it forces you to make resource ownership explicit. Concurrency bugs and memory corruption are still possible in embedded systems, but Rust reduces the surface area drastically and encourages design patterns that stay correct as features expand.

In embedded, you also learn quickly what to avoid: complicated abstractions where determinism matters, overly dynamic behavior, and designs that create unclear ownership boundaries. The upside is that these constraints push teams toward cleaner architecture from day one.

The meta-story: tooling and ecosystem maturity

It’s tempting to reduce Rust’s 2025 state to frameworks and examples. But the real shift is operational: the ecosystem behaves like it’s built for teams.

That means:

dependency management that works predictably across projects,
consistent async patterns and integration points,
build and test workflows that don’t require ritual,
clear pathways from prototype to deployable artifacts.

The “Rust is only for systems programming” era was never about Rust’s capability. It was about confidence—confidence that you could build a complete product without fighting your tools every week. In 2025, that confidence has matured because the ecosystem learned what product teams need: stable libraries, good documentation habits, ergonomic APIs, and straightforward deployment stories.

And this is where Rust’s advantage compounds. When you can reuse Rust patterns and types across server, CLI, desktop core, and WASM compute modules, your team stops context-switching. You ship fewer rewrites, you get more shared understanding, and you reduce the friction between frontend and backend decisions.

Conclusion: Rust is a product platform now

Rust in 2025 is no longer a niche language with a strong pitch. It’s a platform with breadth: web servers that scale, reactive UI approaches that ship, CLI tooling that’s actually maintainable, WASM modules that behave like serious components, desktop apps that don’t punish your users’ machines, and embedded codebases that can last.

If you’re evaluating Rust for a new project today, don’t ask whether it can do the job—ask whether your team wants the benefits Rust unlocks: correctness, predictable behavior, and a coherent ecosystem that supports real applications end to end.

TypeScript Just Overtook Python and JavaScript on GitHub

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 19 May 2025 00:00:00 +0000

For years, TypeScript’s pitch was simple: add types to JavaScript, get safer code, catch bugs earlier. But the real story now is different. TypeScript has quietly become the language most teams want in 2026—not only because it’s more reliable, but because it’s more understandable by the AI tools that increasingly write, refactor, and autocomplete our code. The typed superset didn’t just win the type-safety debate. It won the AI-context debate, and that’s reshaping developer behavior.

The tipping point: a “superset” that behaves like a destination

TypeScript started as a complement: a way to bring structure to the chaos of JavaScript. Yet the ecosystem evolved in a way that flipped the relationship. Modern TypeScript isn’t merely “JavaScript with types.” It’s a full development language, complete with patterns, tooling conventions, and a massive library surface built around its type system.

Look at what teams actually do:

They don’t just annotate a few variables—they define interfaces and types as the core of their design.
They don’t just compile—they rely on type-driven APIs, typed schemas, and generics that encode intent.
They don’t treat the type checker as optional—they treat it as part of the review process.

That shift matters when you consider who your codebase is now written for. TypeScript was designed to help humans reason about software. But it also helps machines—especially LLMs—reason about it with far fewer guesses.

Meanwhile, JavaScript remains flexible and productive, but it leaves both humans and AI tools to infer structure from runtime behavior, naming conventions, and convention-over-configuration patterns that can vary widely across teams. Python, similarly, is expressive and fast for scripting and data work, but its dynamic nature means AI tools must reconstruct likely types from usage patterns and docstrings rather than from an explicit contract.

TypeScript became the “default language of intent.” And once that becomes the default, popularity follows.

Why GitHub’s language rankings started reflecting reality

GitHub language rankings aren’t a perfect measure of “best language,” and they certainly aren’t a scientific study of developer satisfaction. But they do reflect a consistent behavior: where new code gets created and where projects invest.

When TypeScript rises above both Python and JavaScript in those rankings, it signals something more than taste. It indicates that TypeScript is winning at the stage where language choice hardens into habit:

New web applications are more often scaffolded with TypeScript.
Libraries increasingly ship type definitions (or are written in TypeScript from the start).
Tooling defaults—linters, IDE integrations, code generators—reinforce typed code as the path of least resistance.

The key point is this: TypeScript’s momentum is no longer just “JavaScript but safer.” It’s “a complete authoring environment” that fits how modern teams build: editors that provide rich context, CI pipelines that enforce contracts, and automation that depends on static knowledge.

The AI argument: TypeScript gives LLMs a map, not a maze

Here’s the blunt truth about how LLM coding assistance works in practice: it performs best when the model can see stable, explicit structure.

Dynamic languages force the model to infer types from usage. That inference can work, but it’s fragile. It also makes the model’s job harder during generation and refactoring—exactly when mistakes are most costly.

TypeScript changes the game by providing:

Explicit types (e.g., User, OrderStatus, ApiResponse<T>).
Function signatures that constrain inputs and outputs.
Generics that encode relationships (e.g., “this function transforms T into U”).
Discriminated unions that represent real-world state machines.
Module boundaries that help tools locate the right abstractions.

An LLM-assisted workflow becomes dramatically more effective when the codebase contains these contracts in plain sight.

Concrete example: endpoint generation

Imagine generating a frontend client for an API.

In JavaScript, an AI assistant might produce something like:

async function createUser(data) {
 const res = await fetch("/api/users", { method: "POST", body: JSON.stringify(data) });
 return await res.json();
}

But “data” could be any shape, and “res.json()” could return anything. The assistant must guess. If your API returns { userId, email } in one case and { error } in another, the assistant has to infer behavior from prior calls.

In TypeScript, the code can be explicit:

type CreateUserRequest = { email: string; name: string };
type CreateUserResponse = { userId: string; email: string };

async function createUser(data: CreateUserRequest): Promise<CreateUserResponse> {
 const res = await fetch("/api/users", {
 method: "POST",
 body: JSON.stringify(data),
 headers: { "content-type": "application/json" }
 });

 if (!res.ok) throw new Error("Failed to create user");
 return res.json() as Promise<CreateUserResponse>;
}

Now the AI assistant can generate the right request shape, understand what the response must contain, and propagate those types into downstream UI and state management without guessing. The model isn’t only writing code—it’s aligning with a contract.

Why this feels like “TypeScript isn’t a superset anymore”

In the AI era, contracts aren’t just for compile-time correctness. They’re for reasoning-time correctness. When TypeScript types permeate your codebase, the assistant has fewer degrees of freedom, which means fewer wrong branches, fewer missing fields, and less rewriting.

In other words: TypeScript doesn’t merely improve correctness for humans. It improves correctness for the automation humans increasingly rely on.

The practical benefits teams feel immediately

The AI advantage is real, but it’s not abstract. It shows up as day-to-day friction reduction.

1) Fewer “mystery objects” and cleaner refactors

Consider a refactor that changes a user model. With TypeScript, you can update a single type definition and let the compiler (and IDE) highlight every impacted usage. With AI assistance, the assistant also learns the new shape from types rather than from scattered runtime checks.

2) Better autocomplete and safer code suggestions

Typed projects tend to have richer language server responses. That improves suggestions before you even reach for an AI assistant, and it reduces the chance that AI-generated code diverges from your project’s established patterns.

3) Stronger boundaries for generated code

AI tools often generate code “locally” (a function here, a component there). TypeScript’s interfaces and type exports act like guardrails, so generated code plugs into the rest of the system with fewer integration bugs.

A practical workflow many teams adopt looks like this:

Define the types first (request/response, domain entities, state shapes).
Generate or implement functions around those types.
Let TypeScript drive the cleanup through compile errors.

It’s not glamorous, but it’s effective—and it pairs extremely well with AI-assisted development.

What about Python and JavaScript—are they “losing”?

No. JavaScript and Python remain strong, especially where their ecosystems shine. But the selection pressure is shifting.

JavaScript is still the language of the web, and many teams keep it for prototypes, scripts, and cases where overhead matters. However, as teams grow, typed contracts reduce ambiguity, and AI tooling makes that ambiguity more expensive.
Python remains a powerhouse for data, automation, and backend services. But the move toward AI-assisted coding favors static structure. Python can add type hints, of course—but many Python codebases still rely on runtime dynamics and patterns that aren’t as consistently enforced as TypeScript’s end-to-end tooling.

The important distinction is not “TypeScript is better than Python.” It’s “TypeScript has become the most efficient substrate for modern development tooling, including AI.”

And that efficiency is compelling when the cost of a mistake is higher and the volume of changes is larger—exactly what happens when AI speeds up iteration.

How to adopt the “AI-friendly TypeScript” mindset (without rewriting everything)

If you’re thinking about TypeScript now—or already using it and want to get the most from AI tooling—focus on these high-leverage moves.

Make types part of your domain model
- Don’t only type variables. Type the concepts: Order, Money, UserSession, FeatureFlag.
Use discriminated unions for state
- Model UI and workflow states explicitly, instead of relying on boolean flags scattered across components.
Prefer typed interfaces at module boundaries
- The fastest wins come from typing request/response shapes, props, and public APIs between layers.
Let the type checker lead
- When integrating AI-generated code, treat type errors as a checklist. Don’t manually patch around them; fix them by aligning with the types.
Avoid “type any” as a habit
- If you must cast, contain it. Otherwise, you erase the very contract AI tools need.

This isn’t a mandate to migrate overnight. It’s a mandate to converge your project around explicit contracts—because AI assistance performs best when the codebase is legible.

Conclusion: TypeScript won by becoming easier to build with—and to build through

TypeScript overtaking Python and JavaScript on GitHub isn’t just a popularity swing. It’s the visible result of a deeper shift: software development is increasingly mediated by AI tools, and those tools work far better when code carries explicit structure.

Types used to be a compile-time safety net. Now they’re also an AI-context advantage. TypeScript didn’t merely complement JavaScript—it evolved into the language teams trust to express intent clearly, refactor confidently, and automate reliably. In the age of AI-assisted coding, that matters more than slogans about safety ever did.

The Three AI Skills Every Developer Needs by End of Year

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 13 May 2025 00:00:00 +0000

AI in software isn’t “optional tooling” anymore—it’s becoming a core capability. The same way every developer had to eventually learn version control, observability, and cloud basics, the AI era now demands a practical skill stack. And after watching too many teams stumble, there’s a clear answer: by the end of the year, you should be building competency in three areas—prompt engineering, RAG architecture, and agent orchestration.

Not because you’ll memorize buzzwords. Because these three skills map directly to what production systems actually need: reliable instructions, grounded knowledge, and safe action.

1) Prompt engineering: turn “chat” into a controllable interface

Prompt engineering used to be a party trick. Now it’s the control layer. If your application depends on an LLM, you need prompts that behave like interfaces—predictable inputs, constrained outputs, and explicit assumptions.

Start with system prompts that define role, boundaries, and output contract. A good system prompt doesn’t just say “You are helpful.” It tells the model what to do when information is missing, how to format responses, and what not to do.

Example (system prompt for a support bot):

“You are a support agent for Acme Cloud.”
“If the user asks for account-specific details, request verification steps rather than guessing.”
“Output JSON with fields: intent, summary, next_action, confidence.”

That last line—an output contract—changes everything. It reduces downstream parsing headaches and makes testing realistic.

Next, use few-shot examples to teach your model the patterns your product cares about. The key isn’t adding lots of examples; it’s picking the ones that represent your real edge cases: ambiguous requests, conflicting requirements, and “unknown” scenarios.

For instance, if your system routes tickets by intent, include examples where:

the user’s request is underspecified,
the user’s request conflicts with policy,
the user asks for something the bot cannot do.

Finally, teams should stop treating “chain-of-thought” as magic. You don’t want to expose internal reasoning; you want reasoning behavior you can validate. In practice, this means eliciting structured intermediate signals in a way that you can test—like “list key factors” or “produce a brief checklist before the final answer.”

Practical advice:
Build a small prompt test suite now. Keep 20–50 representative prompts in a repo, run them in CI, and record whether outputs still match your contract. Prompt quality degrades when models update, your product changes, or you tweak instructions—testing is how you catch it before users do.

2) RAG architecture: retrieve the right context, not just more text

If prompt engineering is your interface, RAG (Retrieval-Augmented Generation) is your truth layer. The core idea is simple: don’t rely on the model’s memory for enterprise knowledge. Instead, retrieve relevant documents and feed them into the model.

But RAG only works when the architecture is designed, not when you “turn on embeddings.” In enterprise settings, most failures come down to retrieval quality, not generation quality.

The moving parts you must understand

Embedding models: Convert text into vectors so similarity search can work.
Vector stores: Persist embeddings and enable retrieval.
Retrieval strategy: Decide how you fetch candidates (e.g., top-k, hybrid search).
Reranking: Re-order retrieved candidates with a stronger model to improve relevance.

A realistic example: policy Q&A

Imagine an internal tool that answers: “What’s our retention policy for customer logs?”

A naive RAG setup might retrieve a few chunks that vaguely relate to “security,” and the LLM will happily synthesize a plausible answer—wrong, but fluent.

A better approach:

Use chunking that matches document structure (headings, sections, tables where appropriate).
Retrieve with a strategy tuned to your data (hybrid retrieval often helps when keywords matter).
Add reranking so the final context is the most relevant, not merely the most similar.

Practical guidance: make retrieval observable

Treat retrieval like a subsystem you can debug. Log:

the retrieved chunk IDs,
similarity scores,
the final set of context sent to the model,
the model’s stated confidence (or your rubric-based confidence).

Then add a rubric: “Did the answer cite the correct policy section?” Without this, you’ll never know whether you’re improving retrieval or just getting lucky.

Also, don’t ignore data hygiene. If your documents are duplicated, outdated, or poorly chunked, embeddings will faithfully preserve that mess. RAG amplifies quality problems—so you need versioning, deletion policies, and update workflows.

3) Agent orchestration: stop building one-off prompts and start building systems

Most AI projects stall not because the model can’t do the work, but because the workflow is bigger than a single generation call. That’s where agent orchestration comes in: coordinating tool use, managing state, and integrating human review when risk is non-trivial.

In 2025, the winning teams won’t just “prompt the model.” They’ll ship reliable systems that:

decide when to call tools,
track progress across steps,
recover from failure,
and escalate to a human when needed.

Tool use needs guardrails

Suppose your agent can create Jira tickets after reading a bug report. If it mistakes a label, you might spam a queue. If it invents fields, automation breaks.

So design orchestration with:

explicit tool schemas (inputs validated),
preconditions (“don’t create until severity is known”),
and postconditions (“confirm the created ticket ID and required links”).

A practical pattern:

Agent reads user request.
Agent drafts a structured “plan” (what to do and what info is missing).
Agent calls tools only for validated steps.
Agent reports results with citations to tool outputs.

State management is what makes it production-grade

Agents aren’t just prompts—they’re workflows. You need a state model: conversation context, retrieved documents, tool outputs, and intermediate decisions. If you don’t persist state, you’ll get loops, contradictions, and inconsistent outcomes.

Implement state explicitly in your code:

messages[]
retrieval_context[]
tool_calls[] + results
pending_clarifications[]
final_response

Human-in-the-loop isn’t a weakness—it’s how you scale safely

Every serious agent should have escalation paths. Not every action requires human approval, but high-risk operations should.

For example:

For “draft a support reply,” you can let the model draft and humans optionally review.
For “refund money,” you should require human confirmation after the agent proposes an action and the supporting evidence.

The best orchestration designs make escalation deterministic: “If confidence < threshold OR policy category == restricted, escalate.”

4) How these three skills fit together in a real product

It’s tempting to learn these skills in isolation. Don’t. Build a mental model for how they cooperate.

Prompt engineering defines the behavior of each model call: format, boundaries, and decision style.
RAG supplies grounded context: it reduces hallucination by forcing the model to operate over retrieved sources.
Agent orchestration connects those capabilities to actions and workflows: it decides what to retrieve, when to call tools, and when to ask humans.

A concrete architecture example: “AI ops copilot”

User asks: “Why did our deployment fail last night?”
Orchestrator:
- retrieves relevant incident logs and deployment runbooks (RAG),
- asks the model to produce a root-cause hypothesis with references,
- optionally calls a “log search” tool for missing details,
- and generates a short remediation plan.
Prompt layer ensures the output includes: hypothesis, evidence, affected services, and recommended next steps.
Human-in-the-loop triggers when the agent proposes changes to production configurations.

This is the end state developers should aim for: an AI feature that behaves like software, not like a demo.

5) A practical learning plan you can execute this quarter

You don’t need a month-long course. You need a portfolio of working features and a repeatable process.

Week 1–2: Prompt engineering with contracts

Build 3 small prompting tasks with strict JSON outputs.
Add a test suite with edge cases.
Integrate output validation and fallback strategies.

Week 3–4: RAG that you can debug

Create a mini knowledge base (policies, docs, or internal markdown).
Implement embeddings + vector store + retrieval.
Add reranking and log what context was used.
Evaluate with a rubric: “correctness with citations.”

Week 5–6: Agent orchestration for one real workflow

Pick a workflow with tools (e.g., ticket creation, document drafting, or code search + change proposal).
Implement state, tool schemas, and escalation.
Add “plan then act” to reduce messy actions.

End of month: ship a small internal tool. The goal isn’t impressing anyone—it’s proving you can operate AI reliably with engineering discipline.

Conclusion: the skill gap is now a production gap

The AI skill gap isn’t about knowing that LLMs exist. It’s about building systems that behave correctly under real constraints. By end of year, prompt engineering, RAG architecture, and agent orchestration become the baseline differentiators: they’re what turns model output into dependable software.

Learn them together, test everything, and treat AI like production engineering—not experimentation. That’s how you stop being “AI-curious” and start being AI-competent.

Kamal: The Deployment Tool That Made Me Question Everything About Kubernetes

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 07 May 2025 00:00:00 +0000

For years, I treated Kubernetes like the grown-up version of deployment: inevitable, powerful, and—if you ignored the operational pain—almost magical. Then I tried Kamal. The premise is so straightforward it feels suspicious: build a deployable container, point at a few servers, and roll out with near-zero downtime… without an orchestrator. After using it, I stopped assuming that “serious companies” need Kubernetes. I started asking a more honest question: do you need orchestration, or do you need a deploy process that doesn’t hate you?

The problem Kubernetes quietly teaches you to ignore

Kubernetes is often sold as a platform for running workloads. In practice, most teams adopt it to solve a different problem: they want consistent, repeatable deployments across environments—dev, staging, prod, plus a cloud of edge cases in between.

But Kubernetes doesn’t eliminate deployment complexity; it relocates it. You trade “write a deployment script” for “design a deployment strategy across controllers,” “choose rollout parameters,” “understand service discovery and readiness gates,” and “learn how to debug the moment your cluster is healthy but your app isn’t.”

Even the people who love Kubernetes eventually end up writing glue: pipelines that generate manifests, conventions for image tags, scripts for migrations, and tribal knowledge about rollbacks. The more you rely on the cluster for everything, the more deployment becomes an exercise in understanding the platform’s behavior rather than the app’s behavior.

Kamal’s appeal is that it refuses to make deployment a rite of passage.

What Kamal actually is (and what it isn’t)

Kamal is a deployment tool for containerized applications to bare servers. No orchestrator required. No Kubernetes. No Helm. No controllers. The conceptual model is closer to Docker Compose than it is to K8s:

You define what to run.
You build images.
You deploy them to one or more servers.
You roll out changes using a strategy that aims for no downtime.

If Kubernetes is “describe the desired state of your entire system,” Kamal is “ship this release to these machines, safely.”

It also bakes in a few things teams always end up bolting on:

Zero-downtime rolling deploys (the practical kind: instances come up, traffic shifts, old ones drain)
Built-in SSL (so you’re not reinventing HTTPS automation)
A deployment workflow designed around real apps, not abstract workloads

The most telling part is the positioning. Kamal doesn’t ask you to run your whole world. It asks you to deploy your app. That means your mental model stays attached to your software instead of drifting into platform mechanics.

The “it’s just a script” philosophy that hits a nerve

The first thing you notice about Kamal is how calm it feels. Kubernetes deployments can be thrilling—until you start worrying about resource requests, readiness probes, rollout controllers, and the difference between “pod running” and “app actually serving traffic.”

Kamal is suspiciously simple. And that’s the point.

Think about what you truly need for most production deployments:

Build a new artifact (container image).
Start the new version somewhere.
Verify it’s healthy.
Shift traffic to it.
Stop the old version without breaking users.
Make rollback predictable.

That’s basically it. Everything else—ingress controllers, service meshes, autoscalers—may be useful, but it’s not required for safe, repeatable rollouts of a typical web app.

Kamal leans into that reality. It’s what Docker Compose would become if it grew up just enough to deploy across multiple machines with disciplined rollout behavior.

And yes, it can feel offensive if you’ve spent years mastering Kubernetes. You built expertise. You paid the tax. Seeing a tool bypass most of that can look like a shortcut.

But shortcuts aren’t the issue. Abstractions that don’t match your problem are.

A concrete rollout example: the sane kind of “zero downtime”

Let’s say you run a Rails app in containers across three servers behind a load balancer. With Kubernetes, your rollout story might involve:

updating a Deployment spec,
letting the controller create pods,
ensuring readiness probes are correct,
waiting for the rollout strategy to complete,
and hoping your traffic routing behaves exactly as expected.

With Kamal, the story is narrower. The deploy is centered on application instances:

Deploy to a subset of servers
- Kamal brings up the new release alongside the old one.
Health checks gate progression
- If the new container isn’t serving properly, the rollout won’t just “pretend” it’s fine.
Traffic shifts cleanly
- Clients start hitting the new instances.
Old instances drain and stop
- You minimize disruption without requiring the entire system to be re-platformed.

This model is not about theoretical correctness; it’s about keeping the website usable during updates. If your app is mostly stateless and your dependencies are stable, that’s often exactly what you need.

And the best part? When things go wrong, you can reason about them like a deploy issue, not like a distributed systems seminar.

Why DHH’s comfort matters (and why it shouldn’t be a surprise)

Kamal isn’t just a toy for hobbyists. The 37signals team reportedly runs Hey and Basecamp using Kamal without Kubernetes. That detail matters less as a status symbol and more as a validation of the underlying premise: you can run serious production workloads with a deployment workflow designed to do the job, not to showcase architecture.

But here’s the part I find most useful as a lesson: their choice suggests they didn’t chase complexity for its own sake. They likely asked the same question many teams eventually reach:

Are we actually deploying our application, or are we operating our infrastructure?

Kubernetes can be a great platform, but it’s also a commitment. It’s not merely “a tool”; it’s a way of structuring work, skills, debugging, and cost. If your workload doesn’t require the benefits of orchestration, then Kubernetes becomes an elegant answer to a question you didn’t ask.

Kamal answers the question you did ask: “How do we roll out changes without breaking production?”

When you should choose Kamal—and when you shouldn’t

Here’s my opinionated rule of thumb:

Kamal fits best when…

Your app is web-facing (or otherwise straightforward to route)
Your deployment unit is essentially one release → one container image
You want multi-server deployments without building a platform team
You prefer strong deploy guarantees (rolling updates, HTTPS, predictable rollbacks) over deep cluster-level control

Examples: Rails apps, Node services, background workers with manageable routing, and most “normal” containerized web systems.

You might still want Kubernetes when…

You need complex scheduling across heterogeneous resources
You run workloads that demand fine-grained autoscaling and orchestration semantics
You’re building a platform used by multiple teams with diverse requirements
You want cluster-native primitives as first-class features (for example, advanced networking models)

None of that is “bad.” It’s just different. Kubernetes is incredible when you genuinely want a distributed runtime and you’re willing to operate it.

But if your primary pain is “we can’t deploy safely,” Kamal targets that directly.

The practical takeaway: stop making deploys a platform problem

After using Kamal, the biggest mindset shift I had wasn’t technical—it was cultural.

Stop asking, “Do we have Kubernetes?” Start asking:

Do we have a release workflow that makes rollback boring?
Can we deploy across servers without a fragile web of custom scripts?
Do we have health checks and traffic shifting that match how users experience the system?
Are we building abstractions we can’t explain to a new teammate?

Kamal’s strength is that it keeps deployment close to the app’s reality. You get a disciplined rollout mechanism, not an ecosystem you have to learn to operate.

And in many teams, that’s the difference between shipping confidently and constantly fearing the next production change.

Conclusion: Maybe the orchestrator isn’t the point

Kubernetes is powerful, but it isn’t automatically the answer to “safe deployments.” Kamal is a reminder that many production problems reduce to a well-designed release process: roll forward without downtime, roll back without drama, and keep HTTPS from becoming a permanent project.

If your infrastructure goal is “run apps,” Kamal will feel almost refreshingly honest. It’s not trying to be your platform. It’s trying to get your code into production—cleanly—and let you get back to building.

The Quiet Death of the SPA for Content Websites

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 01 May 2025 00:00:00 +0000

For years, the industry treated SPAs like a universal solvent—drop one into every project and everything gets “modern.” But if you’ve built or maintained a content-heavy site, you already know the bill came due: brittle performance, fragile SEO, and accessibility compromises that took longer to fix than they did to ship.

The good news is that course-correction is no longer theoretical. Multi-page apps (MPAs), delivered as HTML and progressively enhanced, are back—and for most content websites, they never should have left.

Why the SPA model broke content sites (not just “SEO”)

An SPA optimizes for one primary goal: an app-like experience after the initial load, typically with most data and UI transitions handled client-side. That’s a great fit when the product is the UI—think Figma-style collaboration or Google Docs-like document editing—where the user continuously interacts with stateful interfaces.

Content websites are different. A blog, a landing page, a documentation portal, or a storefront is primarily about information retrieval: render content quickly, let users skim, make pages discoverable, and ensure assistive technologies can follow structure.

When you force an SPA architecture onto that job, you usually inherit several cascading problems:

First meaningful paint suffers. SPAs often ship a JavaScript bundle first, then render content later once the client hydrates and runs UI logic. Even if the final interaction is smooth, the initial “I can read this” moment can lag.
Indexing becomes a moving target. You can make SPAs work with server-side rendering or pre-rendering, but it turns a simple content pipeline into a complicated system with multiple render paths and edge cases.
Accessibility gets harder than it needs to be. SPA routing and dynamic content require careful focus management, live region announcements, history handling, and robust semantic structure. You can do it—but it’s not “free,” and it’s easy to regress.
Complexity creeps upward. A content site shouldn’t need a full application framework, client routers, state managers, and build pipelines to publish articles. Yet many teams ended up with exactly that.

In short: the SPA made content sites behave like applications. But content sites aren’t applications—they’re documents plus navigation.

The real reason MPAs are winning again: they ship HTML first

The winning pattern is straightforward: render HTML on the server, send it over the wire, and enhance it progressively for interactions that actually need JavaScript. This approach is less about nostalgia and more about engineering leverage.

When you deliver meaningful HTML immediately:

Users see real content quickly, even on slow devices or spotty networks.
Search engines receive structured, crawlable pages without guessing what the client might render later.
Assistive technologies get semantic markup by default—headings, links, tables, lists—rather than reconstructed DOM trees.

Concrete example: a documentation page.

With an SPA, you often pay for:

A client-side router
A hydration step
A “loading” UI that replaces the server markup
Extra client logic to build headings, anchor links, and code blocks

With an MPA + progressive enhancement, you simply render the documentation page as HTML. If you want “copy code” buttons, collapsible sections, or client-side search, you add that on top—without turning the entire page into a JavaScript application.

The key is not “no JavaScript.” The key is “JavaScript when it helps,” not “JavaScript as the delivery mechanism for core content.”

Astro, server-rendered frameworks, and htmx: the modern toolkit for HTML-first

The industry didn’t just “go back.” It improved the mechanics of shipping HTML-first while keeping developer experience sane.

Astro and component-driven static generation

Astro’s core idea—ship less JavaScript by default and keep components composable—fits content sites like a glove. You can build a site with pages that are generated as HTML, then selectively hydrate interactive components only where necessary. The result is a clean separation between “content delivery” and “interactive behavior.”

Practical advice:

Prefer Islands of interactivity: buttons, modals, forms, widgets—hydrate only those.
Keep your routing and page structure server-rendered so deep links and sharing behave predictably.

Server-rendered frameworks (React/Vue/Svelte on the server)

Server-rendered frameworks have matured: streaming, routing, data loading conventions, and tooling that make “render HTML on the server” a first-class default. If you need a component model, you can still have one—just don’t force the browser to become the primary renderer.

Practical advice:

Treat hydration as an enhancement, not a requirement for correctness.
Avoid client-side-only “blank pages.” If a page can’t render meaningfully without JavaScript, you’re back to SPA territory.

htmx for incremental interactivity

If you want a particularly pragmatic approach, htmx is hard to ignore. It lets you sprinkle interactivity into server-rendered pages using declarative attributes—fetch partial HTML, swap DOM fragments, and keep the browser in charge of only the interaction.

A classic example: a product list with filtering.

The server renders the initial catalog as HTML.
When users filter, htmx requests the filtered HTML from the server and swaps the relevant section.
No SPA routing. No client-side state gymnastics. No hydration dependency.

This is not “less modern.” It’s just closer to how the web already works.

Progressive enhancement isn’t a vibe—it’s a discipline

Progressive enhancement is often described as a principle, but in practice it’s a set of decisions. If you apply it consistently, it becomes a competitive advantage.

Here’s what it looks like in a content website build:

Core content is server-rendered HTML.
Your page must make sense with JavaScript turned off.
Navigation works without a SPA router.
Standard links should load new pages. If you want transitions, layer them on later.
Forms work reliably.
Use server-side validation and render form errors in HTML. Enhance with client-side validation only to improve usability, not to provide the only validation path.
Interactive components are isolated.
If a widget needs JavaScript, make it a self-contained enhancement. Don’t let one widget decide the rendering architecture for the entire page.
Accessibility is part of the contract.
Don’t treat focus states and announcements as afterthoughts. With HTML-first rendering, you get much of the semantic foundation for free.

Opinionated takeaway: if your “content site” behaves like an SPA core, you’re likely violating at least two of these disciplines—usually #1 and #2.

Performance isn’t just faster—it’s more predictable

SPA defenders often argue that once the initial bundle loads, navigation becomes fast. That can be true in ideal conditions. But content websites live in real conditions: slow networks, low-power phones, distracted users, and frequent back/forward navigation.

MPA + HTML-first designs have a different performance profile:

The browser has something meaningful to display immediately.
Cache behavior is simpler.
Page loads are stateless and consistent across sessions.

Practical guidance when reviewing an existing SPA content site:

Measure time to first contentful paint and time to interactive, not just route transitions.
Check whether content is available in the initial HTML response or only after hydration.
Validate that your pages have meaningful metadata and structured headings before client code runs.
Test with JavaScript disabled. If the page collapses into an error state, you’ve built a fragile system.

A sharp rule of thumb: if the page is primarily consumed as a document, make the server deliver the document.

The cost of the SPA era—and why the “default” is changing

The SPA wasn’t a mistake because SPAs are “bad.” They’re bad as a default architecture for everything.

The industry conflated “single-page feel” with “better user experience,” then standardized tooling around client-first rendering. Over time, teams accumulated complexity to fix the shortcomings: SSR, pre-rendering, client routing workarounds, SEO adapters, and accessibility patches. You could keep going, but you were treating symptoms instead of questioning the underlying assumption.

Now the assumptions are being challenged:

Content should be delivered as HTML first.
Interactivity should be added where it provides value.
Framework choice should follow product needs, not fashion.

And crucially, we have better options than we did a decade ago. Astro, server-rendered frameworks, and htmx prove that you can build modern experiences without forcing every page into an SPA mold.

Conclusion: Build like the web still matters

The SPA for content websites didn’t fail because developers lacked talent—it failed because the architecture was misaligned with what content websites actually are. The web is at its best when it ships documents efficiently, lets users navigate naturally, and makes accessibility and SEO the default outcome rather than the result of heroic engineering.

Multi-page apps with progressive enhancement aren’t a trend. They’re the correction: HTML-first delivery, interactive enhancements on demand, and a cleaner, more resilient foundation for every blog, doc site, marketing page, and storefront that wants to be fast and readable everywhere.

Redis Jumped 8% Because Microservices Won (Whether You Like It or Not)

abdecastro@protonmail.com (Antonio B De Castro) — Fri, 25 Apr 2025 00:00:00 +0000

Microservices didn’t just change how teams ship software—they changed what software needs to survive the chaos: caches that stay coherent, sessions that don’t vanish, queues that don’t turn into spreadsheets, and coordination that doesn’t become a deadlock festival. Redis is the glue that keeps all of that from collapsing. If you’ve noticed Redis usage trending upward, it’s not because teams suddenly got nostalgic for an in-memory datastore—it’s because microservices made Redis unavoidable.

The microservices default: why “one tool per concern” stops working

At small scale, it’s tempting to treat each microservice concern as a separate tool: a cache here, a queue there, rate limiting somewhere else, sessions “handled by the platform,” and pub/sub whenever you feel brave. That strategy dies as soon as you run multiple services in production long enough to learn the cost of integration.

Here’s what microservices force you to do:

Keep latency tolerable across network hops.
Share state without introducing a distributed-system meltdown.
Coordinate actions (locks, leader election, idempotency).
Handle traffic spikes without turning your database into a punchline.
Recover gracefully when services restart, deploy, and fail.

Redis earns its place because it’s a single, well-understood infrastructure primitive that can support multiple patterns. Not all at once—nothing good is that simple—but enough that teams can standardize quickly and move faster.

Practical example: imagine an e-commerce checkout system split into services like catalog, pricing, inventory, and orders. Each service might need caching, each needs rate limiting, sessions need somewhere durable to live, and events need to flow between services. When Redis is available as a shared component, the team stops reinventing the wheel per microservice and starts enforcing consistent operational practices.

Caching that doesn’t turn into a reliability problem

Caching is the classic reason Redis gets adopted, but the real value is how caching becomes a system, not a shortcut.

A few patterns teams use successfully:

Read-through caching: service checks Redis first; if missing, fetches from the database and writes back.
Write-through or write-back: updates Redis in step with writes, or queues cache invalidation.
Cache-aside with TTL discipline: every cached value has a sensible expiration and a plan for misses.

The difference between “Redis as a feature” and “Redis as infrastructure” is TTL strategy and invalidation behavior. You don’t need exotic techniques on day one—you need consistency.

Concrete advice:

Use short TTLs for highly dynamic data (e.g., “current availability”).
Use versioned keys for items where invalidation is awkward (e.g., product:{id}:v{version}).
Prefer bounded memory patterns: set eviction policies intentionally instead of assuming “in-memory means infinite.”

In microservices, this matters because cache misses amplify downstream load. A single poorly scoped cache can turn a deployment into a thundering herd.

Session storage: the boring piece that quietly matters

Most teams don’t realize they’re fighting distributed systems until sessions become a problem. Load balancers send requests to different instances; instances restart; autoscaling changes the topology; and suddenly your “stateless” application isn’t as stateless as you thought.

Redis session storage solves the operational mismatch: web and API instances can stay ephemeral while session state lives in a shared store.

A typical implementation:

Store session data keyed by session ID.
Set TTL aligned with session expiration.
Use atomic updates when multiple requests mutate the same session (e.g., cart updates and authentication refresh).

Practical example: a mobile client might call /api/cart and /api/checkout concurrently. Without careful handling, you can race session updates and end up with “ghost carts” or stale authentication state. Redis gives you the primitives to make those updates consistent without forcing the web tier to become sticky in a fragile way.

Pub/sub and eventing: decoupling services without losing control

Once microservices multiply, you hit the “who informs whom?” question. Polling works until it doesn’t—stale data, wasted calls, delayed reactions. Pub/sub and streaming patterns help decouple services so that publishers don’t need to know who consumes.

Redis-based patterns commonly look like:

Broadcasting domain events (e.g., order.created, user.verified).
Building lightweight notification channels (e.g., “cache invalidation” messages).
Driving fan-out workflows without tight service-to-service coupling.

Here’s the editorial truth: pub/sub is easy to wire and easy to misuse. It’s not a magic message bus. Teams succeed when they treat it as part of a broader design that includes:

Idempotent consumers (events can be delivered more than once).
Retry and dead-letter logic where appropriate.
Clear ownership of state (events announce changes; state lives elsewhere).

Redis helps because it keeps the plumbing simple while still being fast enough for high-throughput internal messaging.

Distributed locks and coordination: use them carefully, but don’t pretend you don’t need them

Microservices are distributed by definition, which means coordination is unavoidable. You need mutual exclusion sometimes, leader election sometimes, and “only one worker does the expensive thing” behavior often.

Redis makes these coordination patterns achievable without turning your stack into a research project. Distributed locks, for example, are a tool—powerful, but sharp.

Practical guidance:

Use Redis locks for short critical sections and time-bounded operations.
Prefer single-purpose locks (one lock per resource or keyspace) instead of a global “everything lock.”
Make operations idempotent so failures don’t cause double work.
Set lock expirations to avoid permanent contention after crashes.

And if you think you “don’t need locks,” check the real world: retries, concurrent requests, background jobs, and deployment rollouts are exactly where coordination bugs breed.

Rate limiting and backpressure: protecting systems from themselves

Rate limiting is where Redis often becomes non-negotiable. Microservices don’t just receive traffic—they receive traffic multiplied by internal calls. One slow downstream dependency can trigger a cascade of retries and timeouts. Rate limiting buys time.

Teams use Redis counters and token-bucket-like strategies to:

Throttle by user, API key, or IP.
Apply burst control for expensive endpoints.
Provide consistent behavior across multiple service instances.

Practical example: if you expose an endpoint that triggers a heavyweight report generation, you can throttle requests per user. Even if one instance fails mid-flight, Redis ensures the overall system’s decision remains consistent across the fleet.

The key is operational realism:

Choose a rate limiting window that matches your user expectations.
Store only what you need (and consider key cardinality carefully).
Monitor denial rates; if legitimate users get throttled, you’ll need a feedback loop.

The Valkey moment: licensing drama, but protocol-grade infrastructure still wins

There’s real momentum around Redis alternatives, including Valkey, driven in part by licensing and governance debates. That shift is not imaginary—teams re-evaluate dependencies whenever legal uncertainty appears.

But two things stay true in practice:

Redis patterns are portable knowledge. Teams built their caching, session, pub/sub, and locking layers around the Redis programming model.
The Redis protocol is infrastructure-grade. Even when a backend changes, application-level fluency and operational muscle memory don’t vanish.

What this means for builders: you can reduce lock-in pressure by choosing implementations thoughtfully, but you shouldn’t treat Redis fluency as optional. If you understand the patterns, the migration path gets easier, not harder.

If your team is hiring or training, make Redis competence a baseline skill: not just “how to run Redis,” but how to design with TTLs, failure modes, atomicity, and workload characteristics.

Conclusion: Redis didn’t “get popular”—microservices made it necessary

Redis usage rises for a reason: microservices created a steady demand for fast shared state, coordination, and communication. Caching keeps latency sane, session storage keeps web tiers clean, pub/sub enables decoupling, distributed locks prevent duplicate work, and rate limiting protects the system from cascading failure.

Whether you’re strictly on Redis today or exploring protocol-compatible alternatives, the takeaway is the same: if you build distributed systems, Redis fluency isn’t a nice-to-have. It’s the difference between stitching services together and actually running them.

Your Kubernetes Cluster Is Probably Overkill (Still)

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 13 Apr 2025 00:00:00 +0000

Kubernetes is a marvel—so is a CNC machine. The trouble isn’t that it’s powerful. The trouble is that most teams keep buying power tools when they actually need a bench vise. Three years after I made this argument, the replies are still furious. That tells me the real issue isn’t Kubernetes. It’s what people do with it.

Kubernetes is great for running complex, multi-team systems at scale. But for the majority of teams running it today—especially those under ~30 engineers—it’s usually not the best default. You’re paying an operational complexity tax for capabilities you may never use.

This is not a hit piece. It’s a reality check, with practical alternatives you can adopt without lighting your roadmap on fire.

Why Kubernetes becomes “invisible infrastructure”—and why that’s costly

The biggest lie about Kubernetes is that it’s just “infrastructure as code,” like Terraform. In practice, Kubernetes introduces a new category of work that doesn’t feel like feature development but still consumes engineering energy: continual operational alignment.

You rarely “set up Kubernetes once.” Instead, you maintain an ecosystem:

Identity and access (RBAC roles, service accounts, least privilege)
Networking (ingress controllers, service types, network policies, DNS quirks)
Storage (storage classes, volume lifecycle, reclaim policies)
Security plumbing (certificates, secrets management patterns, image scanning integration)
Deployment mechanics (rollouts, readiness/liveness, autoscaling rules, dashboards/observability hooks)

Even if your team uses sensible defaults, the work doesn’t disappear. It just moves into “tribal knowledge” and recurring operational tickets.

A common pattern looks like this:

You ship features in sprint cadence, but you also spend cycles every week debugging environment drift—why one pod behaves differently under the new ingress, why a migration script fails only in staging, why TLS renewals stalled, why a network policy blocked something you forgot to label.

That time doesn’t always show up as “Kubernetes time” on a timesheet. But it shows up in your delivery speed.

And if you’re not explicitly using Kubernetes primitives—multi-tenancy boundaries, advanced scheduling, complex stateful workloads, multi-region failover—then a lot of that overhead is mostly theater.

The “capability mismatch” problem: you’re building the wrong platform

Kubernetes rewards teams that need platform behaviors. The platform behaviors people often cite—self-healing, rolling updates, scaling—are real. But they’re not exclusive to K8s. What matters is whether your application portfolio demands the orchestration features K8s makes easy.

Consider a typical team of ~10–25 engineers building a handful of services:

A web app
One or two background workers
A few domain services (maybe a queue consumer, maybe a scheduled job)
A database and cache
Some integrations and an admin UI

This is a perfect use case for simpler deployment models. You can still get reliability: retries, health checks, rollouts, environment separation. You just don’t need to bring your own cluster-building discipline.

Here’s the litmus test I use:

Do you run multiple deployable services per team, with strict ownership boundaries and heavy automation demands?
Do you need fine-grained traffic routing across many versions (beyond basic blue/green)?
Do you manage stateful workloads with custom storage behavior frequently?
Do you require complex autoscaling based on app-level metrics?
Do you operate across multiple regions or have a real multi-cluster story?

If you’re answering “mostly no,” then Kubernetes becomes a capability mismatch. You’re paying to orchestrate complexity you don’t need, which slows down everything else.

What those engineers are really doing (and what to stop doing)

Let’s talk about the day-to-day work that tends to consume Kubernetes teams. This isn’t a list of “bad practices.” It’s a list of the recurring categories of tasks that Kubernetes introduces.

1) RBAC and permissions drift

When you add a new job, service, or endpoint, you often have to update RBAC bindings. Even with automation, the process adds friction and review surface area. It’s not hard—it’s just constant.

Practical move: if you must use Kubernetes, invest early in a clean permission model with templates. But if you don’t need Kubernetes, don’t recreate this treadmill elsewhere.

2) Ingress, TLS, and “why is staging different?”

Ingress controllers and certificate management sound solved—until you have five environments, two domains, and one legacy wildcard certificate strategy. Then you get a steady drip of “it works locally / fails in staging” issues.

Practical move: fewer moving parts wins. Managed PaaS and simpler container platforms typically reduce this entire class of work.

3) Storage class complexity and volume lifecycle surprises

Stateful workloads require careful thinking: provisioning behavior, reclaim policies, migration impact, backups, and incident recovery. If your services are mostly stateless (common for modern web stacks), you can keep your state on managed services and reduce Kubernetes storage complexity dramatically. But when teams don’t do this, they end up spending time in storage configuration instead of product.

4) Observability wiring that never fully stabilizes

Kubernetes monitoring stacks are powerful, but the integration path can be endless: metrics, logs, traces, pod identity, dashboards, alert tuning, SLO definitions. You’ll still need observability with any platform—but Kubernetes makes it more configurable, and configuration invites drift.

Practical move: choose an ecosystem with sensible defaults and fewer integration seams unless you truly need the control.

Faster paths: Docker Compose, Kamal, and managed PaaS

Here are three alternatives I genuinely think most teams should consider first. The point isn’t ideology. The point is shipping faster with fewer operational surprises.

Docker Compose: the “serious local + simple deploy” baseline

Docker Compose is underrated because it’s not glamorous. But if your architecture is straightforward, Compose gives you:

Repeatable local development
Clear service boundaries
A clean way to mirror staging
Straightforward CI builds

You can run Compose in production with the right tooling around it, but even if you don’t, Compose still pays off by removing environment differences. Less drift means fewer “Kubernetes-only” bugs and fewer emergency rollbacks.

Concrete example: If your team currently builds Docker images and then struggles with dev/staging parity, start by making Compose the canonical way to run the whole stack locally. When you later deploy via another method, keep the service definitions aligned.

Kamal (or similar “deploy via SSH + containers” approaches): pragmatic deployment

Tools in the “run containers on servers” family let teams focus on what matters: build artifacts, run them reliably, and roll forward/back without cluster semantics.

Kamal-style workflows shine for teams that don’t want to learn the full operational Kubernetes surface area:

No RBAC learning curve
Less networking plumbing
Fewer controllers to manage
Predictable runtime behavior

If your deployment targets are a small set of VMs (or a limited fleet), this approach can be shockingly productive.

Concrete example: A two-service Rails + worker setup can deploy via a single command, with database migrations handled in a controlled step. When something fails, you can inspect the running container set directly rather than spelunking through pod states, events, and controller reconciliation.

Managed PaaS: let someone else babysit the platform

If you’re not actively developing a platform, using a managed PaaS can be the fastest path to “production without the platform tax.”

Managed offerings typically handle:

Ingress routing
TLS automation
Build pipelines and rollouts
Environment configuration
Some level of scaling (often good enough)

This isn’t about avoiding performance constraints forever. It’s about delaying complexity until you truly need it.

Concrete example: If your team’s bottleneck is feature throughput, the move is to adopt a PaaS that supports your deployment model and database integration well—then use the saved engineering time to improve reliability at the app layer (idempotent jobs, safe migrations, better caching strategies, and robust retry policies).

When Kubernetes actually earns its keep

To be fair, Kubernetes earns its keep in specific situations. You shouldn’t feel guilty for using it when you need what it provides.

Kubernetes is a strong choice when you have:

A large portfolio of services with frequent deployments across many teams
Strong multi-tenancy or isolation requirements (not just “we should be careful,” but enforceable boundaries)
Advanced scheduling and placement needs
Complex stateful workloads that genuinely benefit from Kubernetes-native patterns
Multi-cluster or multi-region architectures with orchestrated failover strategies
A platform team that can maintain the ecosystem as a product

The key is organizational. If you have the headcount and mandate to operate Kubernetes well, the complexity tax is an investment, not a leak.

But if you’re a small team building product—Kubernetes can become your unwilling second job.

Conclusion: choose the simplest system that meets your real requirements

Kubernetes isn’t wrong. It’s just often misapplied.

If your team is under 30 engineers and you don’t have multi-region needs, complex autoscaling, canary-heavy rollout strategies, or a platform team dedicated to cluster operations, you’re probably paying a complexity tax you could eliminate. Start with Docker Compose for parity, consider Kamal-style pragmatic deployments for speed, or go managed PaaS to reclaim engineering time.

Ship faster. Learn fewer moving parts. Spend your energy on the product—not on keeping controllers and certificates reconciled.

Anthropic Claude Code Is the AI Coding Tool I Wanted Since Copilot Launched

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 07 Apr 2025 00:00:00 +0000

Copilot made coding feel faster—but it still mostly treated you like a keyboard. Anthropic’s Claude Code flips the model: instead of spitting out text for you to paste, it operates like a teammate in your repo. It reads your files, writes code, runs commands, checks results, and iterates until the work is done—right inside the terminal.

If you’ve ever thought, “I don’t need better autocomplete; I need an agent that can actually take a task from start to finish,” Claude Code is the first tool I’ve used that feels close.

Agentic coding that behaves like pair programming

Most AI coding tools today are great at one thing: predicting the next token. Even when they wrap that prediction in chat, the workflow remains “generate something and hope it compiles.” You still do the expensive part—understanding the context, wiring the change into the right place, running tests, debugging failures, and iterating.

Claude Code changes that rhythm. The core promise isn’t that it can write code; it’s that it can work on a problem with the repository as its working memory.

Here’s what that looks like in practice:

You give it a task (often via a GitHub issue).
It reads the relevant files and the surrounding code patterns.
It proposes and applies changes.
It runs the commands you’d normally run (tests, linters, build steps).
It checks what happened, fixes what broke, and repeats.

That last part matters. Pair programming isn’t “here’s a patch—good luck.” It’s “let’s make it pass,” with feedback loops built into the workflow. Claude Code behaves that way.

From issue to PR: the workflow shift you can feel

The biggest difference is how Claude Code frames collaboration. With Copilot-style tools, you’re often the operator: you request code, then you integrate it, run it, and debug the results. With Claude Code, you’re more like a reviewer overseeing an execution loop.

Give it a GitHub issue and it can:

Read the codebase to understand where the fix belongs.
Write the changes in the right files and style conventions.
Run tests and other checks that reveal whether the change is correct.
Iterate when something fails—without you manually stitching the next attempt.
Open a PR so you can review with the full diff and rationale context.

The practical outcome: you spend less time shepherding small generated snippets into a coherent change. Instead, you spend time on what humans are good at—reviewing approach, catching edge cases, and approving the direction.

A concrete example: “Make tests pass” isn’t enough—until it is

Imagine an issue like:

“Fix flakiness in orders integration tests. Failures occur intermittently in CI.”

With a token-predicting tool, you’d likely get a suggestion—maybe “add a retry” or “sleep before asserting”—and then you’d test it and probably spend an hour tuning until it behaves. You’d iterate manually, because the tool can’t reliably carry the loop across your project.

With Claude Code, you can hand it the same issue and let it do the loop:

It finds the flaky tests and their dependencies.
It traces the timing assumptions and where they break.
It changes the code (or test strategy) in targeted places.
It runs the test suite, observes the failure mode, and tries again.

Even when it doesn’t “know” the best fix instantly, the agentic behavior makes it safe to explore. You’re not stuck between guess-and-paste attempts—you’re watching an automated effort converge.

Terminal-native means fewer context switches

AI coding tools usually fail developers not because they’re dumb, but because they create friction. If you have to copy prompts in one place, paste patches elsewhere, and keep reloading mental context, you lose momentum.

Claude Code being terminal-native is a quality-of-life decision that reads like a small detail but changes everything:

It sees your filesystem and your project structure directly.
It can run commands in the same environment you use.
It can inspect outputs and adjust based on real error messages.
It’s naturally aligned with how developers already work: edit → run → read logs → repeat.

This is what makes it feel like pair programming. In real pairing, you don’t ask your teammate to describe a patch and then you do the integration manually. You collaborate around an active session: they make changes, they run things, they show you what broke and why.

Claude Code’s workflow matches that.

“Work on this problem while I review” beats “generate for me”

Here’s my firm opinion: the best AI coding tools shouldn’t replace your judgment. They should compress the busywork between your judgment calls.

The difference between “generate code for me to paste” and “work on this problem while I review your approach” is not just semantics—it changes how often you get interrupted.

When the tool generates code for you, you’re responsible for:

choosing where to apply it,
adapting it to your architecture,
running tests,
interpreting failures,
and iterating.

When the tool works on the problem, that burden shifts into an execution loop the tool can handle reliably. Your job becomes:

review the diff,
sanity-check the strategy,
confirm edge cases,
and approve merge readiness.

That’s the kind of productivity gain you actually feel in a real sprint. You don’t just write less code; you make fewer “dead end” attempts.

How to get better results immediately

Claude Code performs best when you give it a crisp task boundary. Instead of vague prompts, use issue-style specificity:

What’s broken (error message, failing test name, repro steps)?
What “done” looks like (tests passing, performance constraint, API behavior)?
Any constraints (don’t change public API, keep backward compatibility, follow existing patterns).

If your issue description includes the right breadcrumbs, the agent can spend its time on implementation and verification rather than reverse-engineering your intent.

Practical patterns: how to use it like a pro

Claude Code isn’t magic, and you shouldn’t treat it like you can delegate design. But you can structure work so the agent contributes at its strongest.

1) Start with a well-scoped GitHub issue

Great issues include the failure signal and expected behavior. Even if you’re not sure of the fix, tell it what’s wrong.

Example:

“GET /v1/users returns 500 in staging”
“Integration test users-list fails with timeout”
“Expected: returns 200 and includes cursor field”

2) Let it run the same checks you trust

If your repo has make test, pnpm test, or pytest -q, make sure Claude Code uses those commands. The point isn’t “run something”; it’s “run the things that represent correctness.”

When an agent runs your real suite, you get a meaningful signal rather than a superficial “it compiles” state.

3) Review approach, not just the diff

The agentic loop produces more complete changes, which means your review should focus on the strategy:

Does it handle the failure mode it discovered?
Did it introduce broader refactors than needed?
Are new behaviors covered by tests?
Did it respect existing conventions?

A quick scan of how it fixed the immediate issue—and whether that fix seems robust—will save you from merging subtle regressions.

4) Use it iteratively on “hard middle” problems

Claude Code shines when the work isn’t just writing new code; it’s changing code under constraints:

refactors that must preserve behavior,
bug fixes that require understanding test failures,
integration changes across multiple modules,
cleanup of technical debt without breaking the build.

That’s where a feedback loop is everything.

The real promise: fewer “AI-driven” bugs, more engineering

The best part about this category shift is psychological. Developers are cautious for a reason: AI-generated code can be syntactically correct and still wrong in ways that only show up during execution. Claude Code’s approach reduces that gap by staying close to execution—reading, writing, running, and iterating.

It’s not that it never makes mistakes. It’s that mistakes are handled inside the workflow, not after you paste something into your repo and discover it fails. When the agent can observe failures and respond, the tool becomes less of a suggestion engine and more of a task worker.

That’s why it feels like pair programming. Your attention moves from babysitting outputs to guiding outcomes.

Conclusion: the first AI coding tool that matches how teams actually build

Copilot was a breakthrough, but it mostly optimized for completion. Claude Code feels like a bigger idea: agentic coding in the terminal that treats your repo as the workspace and treats your review as the final checkpoint.

If you want AI that can truly help you ship—read the context, implement the fix, run the tests, and iterate until it works—Claude Code is the tool I’ve wanted since Copilot landed.

Gleam and Zig: New Languages That Actually Deserve the Hype

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 01 Apr 2025 00:00:00 +0000

Every few years, a new language arrives with the same promise: “faster,” “safer,” “cleaner.” Most fade into the background noise. Gleam and Zig are different—not because they’re magic, but because their design decisions are unusually aligned with a very practical goal: respect the developer’s time. If you care about building real systems without drowning in toolchain surprises or debugging mysteries, these two deserve a serious look.

Why hype is cheap—and good design isn’t

Language hype usually comes from marketing, not engineering. It’s easy to say “best-in-class” and hard to deliver on the boring parts: predictable compilation errors, readable code, tooling that doesn’t fight you, and performance you can reason about.

Gleam and Zig share an almost contrarian philosophy: the language should make the common path smooth, and the uncommon path survivable.

Gleam targets the BEAM VM, bringing typed, functional programming with a syntax people often find familiar if they’ve used TypeScript or modern ML-style languages—without giving up the BEAM’s resilience.
Zig targets systems work with a tone that’s refreshingly explicit: manual control without hidden complexity, and error handling that’s visible rather than magical.

Neither is positioned as “replace everything tomorrow.” Instead, each is a bet on something more durable: making developers faster without making correctness a suffering contest.

Gleam: typed functional programming, without the “move fast” tax

Gleam is a functional language that compiles to the BEAM, the same runtime behind Erlang and Elixir. That’s not a trivia detail—it matters. On BEAM, the system is built for concurrency, distribution, and fault tolerance. The language gives you a typed experience that feels designed to reduce the classic functional pain point: unclear invariants.

What “Erlang-style fault tolerance” looks like in practice

In BEAM land, crashes are often treated as a normal event. Processes isolate failures, supervisors restart what needs restarting, and the system keeps moving.

Gleam builds on that mental model. You write code with types that push errors earlier, then rely on BEAM’s runtime behavior for resilience. The combination is especially attractive for real-world services: APIs, background jobs, messaging, and anything that benefits from long-running reliability.

A taste of the developer experience

You don’t need to become a Lisp acolyte to start shipping with Gleam. The syntax is intentionally approachable. Where many functional languages feel like a tax you must pay before you can think, Gleam tries to keep you close to the logic you care about.

For example, instead of fighting type inference you don’t understand, you can structure functions and types so the compiler becomes a helpful reviewer:

Use explicit types for boundaries (public functions, data entering/exiting the system).
Let the compiler guide refactors by tightening types as you change logic.
Prefer small composable functions—BEAM’s concurrency model pairs naturally with that style.

If you’ve used TypeScript, you’ll probably recognize the instinct: “make invalid states unrepresentable,” but without the same runtime guesswork.

Practical use cases that justify the time investment

Gleam is a strong candidate when you want:

A typed functional core inside a distributed service.
BEAM’s fault tolerance for long-lived processes.
A language that doesn’t require you to abandon modern expectations around tooling and readability.

A concrete example: imagine building a notification service. You’ll likely handle queue consumers, retries, and transient failures. Gleam’s combination of types and runtime fault tolerance maps cleanly to that reality.

Zig: C-level control with explicit error handling (and fewer surprises)

Zig’s appeal is straightforward: you want the performance and low-level control of C, but you don’t want to inherit C’s accident-prone ergonomics. Zig is opinionated about what “explicit” should mean.

“Explicit error handling” isn’t academic—it changes how you debug

In many languages, failures are either exceptions, panics, or “return codes you forget to check.” Zig makes error paths part of the type system and control flow.

That means when something goes wrong, the program’s structure already told you how errors are supposed to propagate. Less time is wasted hunting for whether a function can fail and—if it does—how.

A practical pattern looks like this (conceptually): functions that can fail return an error union type, and callers handle the outcome explicitly. The compiler won’t let you pretend failure can’t happen.

Cross-compilation that feels trivial

One of Zig’s strengths is that cross-compilation is designed into the workflow rather than bolted on. If you’ve ever wrestled with CMake toolchains, environment variables, and mysterious linker errors, you know how much time a build system can eat.

Zig’s approach aims to make the “target matrix” less painful. Even if you only ship to one platform today, a smoother path to additional platforms becomes valuable fast—especially for tools, embedded-ish use cases, or performance-sensitive services.

Practical use cases that justify the time investment

Zig shines when you want:

FFI-friendly code that can integrate with C ecosystems.
Predictable resource management without the overhead of a heavy runtime.
A build workflow that doesn’t turn portability into a recurring tax.

Think: writing a high-performance library used by multiple services, building developer tooling, or implementing system components where you want the constraints to be obvious.

Shared philosophy: they both respect your time

It’s tempting to compare languages on headline features. But the real differentiator is how often the language interrupts your work with avoidable friction.

Gleam respects time by catching mistakes early—then leaning on BEAM for resilience

Gleam’s “typed and pragmatic” vibe means the compiler helps you avoid entire categories of mistakes. And when something still goes wrong at runtime—because reality is messy—the BEAM ecosystem expects failures and provides a recovery model.

That’s not a guarantee of perfection. It’s a guarantee that your system is designed to survive imperfect conditions.

Zig respects time by making control flow and failure modes visible

Zig’s explicit approach reduces the mental overhead of “what could happen here?” and “did we check the error?” You don’t need to rely on conventions or code reviews to keep failure handling correct.

Even better: the language’s explicitness tends to make debugging less of a detective novel. You can reason about the program because the program tells you what it’s doing.

Choosing where to start: a practical learning plan

If you’re deciding whether to spend time on Gleam or Zig, don’t start with an abstract language preference. Start with a project shape.

If your work is backend-heavy: start with Gleam

Pick one subsystem you already maintain:

queue consumer
background job worker
websocket handler
event processing pipeline

Your goal isn’t to rewrite everything. It’s to validate that typed Gleam can model your domain without turning everyday refactors into a type-system battle.

Practical approach:

Write a small module with clear input/output types.
Add concurrency boundaries where BEAM shines.
Let the compiler drive refactors while you keep runtime behavior understandable.

If your work is systems-heavy: start with Zig

Choose a component where performance or portability matters:

a parsing library
a CLI tool that must be fast and portable
a low-level integration layer (FFI)

Practical approach:

Start with a function or module that returns explicit error unions.
Build with cross-compilation from day one (even if you test locally).
Refactor only when the error model and interfaces stay coherent.

A smart middle path: learn both, but for different reasons

You don’t have to become a polyglot collector. Learn each language for the problems it actually solves:

Gleam: typed reliability on a resilient runtime.
Zig: explicit control and predictable performance with a friendlier build experience than the C baseline.

Conclusion: invest time where the design is doing real work

Gleam and Zig won’t replace your stack overnight. But they’re not hype artifacts—they’re deliberate attempts to solve long-standing developer pain.

Gleam pairs a typed, approachable syntax with BEAM’s fault-tolerant runtime philosophy, making real services easier to build and maintain. Zig brings C-level control while insisting that errors and failure paths are first-class, and it treats cross-compilation as a normal workflow rather than a torment.

If you want languages that earn time, not beg for attention, these two are worth putting on your short list—and starting small this week.

The Honest Guide to AI-Assisted Development in 2025

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 19 Mar 2025 00:00:00 +0000

AI-assisted development in 2025 isn’t a magic button—it’s a workflow. After two years of daily tool usage, the most useful thing I can tell you is this: AI is best at helping you think faster and write cleaner, not at making final decisions on your behalf. Treat it like a sharp junior teammate with great recall and unreliable judgment, and you’ll get real leverage. Treat it like an autopilot, and you’ll ship confident bugs.

What Works (and Why It Works)

There’s a pattern behind the best AI use cases: tasks where the input already contains the relevant context, the output is bounded, and correctness is checkable. In 2025, these are the areas where AI consistently shines.

1) Generating tests from specifications

When you can describe expected behavior in plain language (or in existing acceptance criteria), AI can produce a strong first draft of tests—especially for edge cases developers forget.

Example: You have an API endpoint: POST /refunds that should reject refunds over the remaining balance and require idempotency keys. You can prompt AI with:

Input: a short spec of validation rules
Output format: “Write unit tests for validation and idempotency behavior”
Tech details: your test framework, mocking approach, and naming conventions

AI will often generate:

parameterized tests for boundary conditions
tests for error response shapes
idempotency tests that ensure the second request doesn’t re-apply the refund

Practical advice: immediately tighten the tests. AI will usually get the “what” right, but not always the “how strict.” Use your existing test suite style as the template, and run everything on CI before you trust it.

2) Explaining unfamiliar codebases

AI is surprisingly effective at turning “mystery code” into a navigable map—especially when you provide the file(s) and describe what you’re trying to change.

A good prompt looks like:

“Here’s authMiddleware.ts and how the router uses it. Explain the request flow and where errors are handled.”
“What invariants does this code assume?”

It’s not clairvoyance; it’s summarization plus pattern matching. If you feed it the relevant modules, it can explain how they interact and where the risks are.

Practical advice: ask for implications, not just descriptions. For example: “Where would a null value cause a crash?” or “What happens if the token is expired?”

3) Rubber-duck debugging (with better recall)

Rubber-duck debugging works because you force your brain to articulate the system. AI can accelerate that by acting as the duck—but with a better ability to keep track of details.

Use it like a structured interrogation:

“Here’s what I expected.”
“Here’s what actually happened.”
“Here’s the relevant code and logs.”
“List 5 plausible root causes, ranked by likelihood, and tell me what single test would confirm each.”

You’ll get clearer hypotheses faster than you would alone.

Practical advice: don’t ask “why is this failing?” Ask for experiments. The best AI outputs are testable.

4) Writing boilerplate and glue code

Boilerplate is the sweet spot because it’s mechanical and easy to validate.

Think:

mapping DTOs
wiring dependencies
request/response shaping
repetitive CRUD handlers
translating between languages or frameworks (“Write a TypeScript version of this Java logic,” or vice versa)

AI is excellent at producing an initial draft of these pieces that you can then review and adapt.

Practical advice: insist on style consistency. If your team prefers explicit error types or specific naming conventions, bake them into the prompt.

5) Translating between languages (with attention to idioms)

Translation is more than syntax. AI helps most when you care about idioms, not just compilation.

Example: Port a Python function to Go:

Provide the Python version and the required behavior.
Ask for the Go version using the idiomatic error handling (error returns, explicit checks).
Request a small set of tests that confirm parity.

AI often nails the intent, then you fix edge behaviors and formatting.

Practical advice: don’t skip equivalence tests. Translation is a place where subtle semantics (null vs empty, timezone parsing, overflow behavior) can quietly diverge.

What Doesn’t Work (or Works Poorly)

AI is still weak where the “context radius” explodes—where decisions depend on system-level knowledge, threat models, performance constraints, and real-world operational tradeoffs. In these areas, AI can easily provide plausible-sounding wrong answers.

1) Architecture decisions

Architecture is not just code—it’s tradeoffs over time. AI can generate diagrams and high-level components, but it can’t responsibly choose constraints you haven’t supplied.

If you ask for “the best architecture for X,” you’ll likely get a polished proposal that ignores:

your existing deployment reality
team ownership boundaries
operational costs
failure modes and recovery strategies
product constraints (latency vs throughput, compliance, rollout strategy)

What to do instead: use AI to enumerate options and risks, not to decide. Ask:

“List three architecture options and the specific risks each introduces.”
“What questions should I ask stakeholders before choosing?” Then decide with human judgment and, ideally, hard requirements.

2) Security-sensitive code

This is the hard line. AI can help, but it shouldn’t be the authority for security properties. For auth flows, crypto usage, sanitization, and authorization logic, “almost correct” can be catastrophic.

Common failure modes include:

incorrect assumptions about threat models
incomplete validation
insecure defaults
misuse of cryptographic primitives

Practical advice: if AI drafts security-related code, treat it as a suspect contribution:

require code review by someone who owns security
add tests for adversarial inputs
verify with established libraries and patterns you already trust

3) Performance optimization

Performance work requires measurement, profiling context, and a model of the workload. AI can suggest optimizations, but it can’t observe your production bottlenecks.

Even when AI identifies plausible hot paths, it may:

optimize the wrong layer
recommend complexity where a simple cache would do
propose micro-optimizations that don’t matter

What to do instead: let AI help you design experiments. Use prompts like:

“Given this endpoint, what metrics would you profile first?”
“Suggest profiling steps and what you’d expect to see if X is the bottleneck.”

Use the tool’s reasoning to guide measurement, then let reality decide.

4) Anything requiring system-level context

If the correctness depends on infrastructure, data distribution, concurrency assumptions, or operational constraints, AI is operating blind.

Examples:

queue semantics and retry behavior across services
eventual consistency guarantees in your actual data stores
resource limits in Kubernetes and autoscaling behavior
how your CI, feature flags, and rollout process interact

AI can help you reason about what context is missing—but it can’t substitute for it.

The Two Biggest Mistakes Developers Make

Mistake #1: Using AI as a code generator instead of a thinking partner

This is the most common failure I see: developers paste a prompt, receive a “working” implementation, and move on. The mental work disappears. So does verification.

When you use AI as a thinking partner, you’re not asking for “the code.” You’re asking for:

options
tradeoffs
hypotheses
explanations of assumptions
test plans
refactoring strategies

A better workflow: have AI propose, then you interrogate.

“Draft a solution, but also list 10 assumptions you’re making.”
“What edge cases does this miss?”
“How would you prove it’s correct with tests?”

Mistake #2: Not verifying AI output with the same rigor as a junior dev’s PR

If AI output is treated as authoritative, you’ll ship errors that look like mistakes nobody should make. The fix is simple in principle: verify.

At minimum:

run unit tests and lint
add regression tests for any changed behavior
perform code review for readability and invariants
check for security-relevant patterns (input validation, authz/authn flow correctness, secrets handling)
validate performance assumptions with benchmarks or profiler output when relevant

Practical rule: the AI response must earn trust, not receive it.

A Practical “AI-Assisted” Workflow That Holds Up

Here’s a pattern that consistently produces quality without turning your team into prompt engineers.

Provide constraints and examples.
“Here’s the function signature, here’s how errors are represented, here’s what a valid request looks like.”
Request reasoning artifacts, not just code.
Ask for test cases, edge cases, assumptions, and failure modes.
Generate drafts, then revise with human ownership.
Treat AI as a starting point. You remain accountable.
Verify with the same discipline as any PR.
Tests, review, and CI gates are non-negotiable—especially for security and correctness-critical logic.
Measure before optimizing.
Let AI propose experiments; let data decide.

Concrete example: Suppose you’re adding a new language integration. Use AI to translate and scaffold, but require parity tests. Then run a small suite that compares outputs across edge cases (timezones, encoding, whitespace normalization). That single move prevents the most common “translation drift” bugs.

Conclusion: Use AI for Speed, Keep Humans for Judgment

In 2025, AI-assisted development works best when you align it with bounded, testable tasks: generating tests, explaining code, accelerating boilerplate, and translating logic between languages. It struggles—and can genuinely mislead—when you’re doing architecture, security-sensitive engineering, performance tuning, or anything that depends on system-level context.

If there’s one mindset to adopt, it’s this: AI is your thinking partner and draft generator, not your decision-maker. The moment you require the same verification rigor you’d demand from a junior dev’s PR, AI stops being a gamble and starts being an advantage.

Your Monolith Is Fine. Your Monorepo Is Fine. Stop Apologizing.

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 13 Mar 2025 00:00:00 +0000

There’s a particular kind of tech insecurity that shows up in pull requests, architecture docs, and sprint planning: the urge to preface your choices with a justification. “We know it’s a monolith, but…” or “We know this deployment setup is intense, but…” Stop. The goal isn’t to be impressive at architecture debates. The goal is to ship software that users can actually benefit from.

Both monoliths and microservices can be great. Both monorepos and polyrepos can work. What doesn’t work is treating architecture like a personality test—or freezing your roadmap in the name of “future-proofing.” If your team can deliver, recover from incidents, and evolve the system without heroic effort, your architecture is already doing its job.

The real question isn’t “what architecture,” it’s “what friction?”

Frameworks aside, architecture is just a tool for managing friction. The friction shows up as:

How fast you can change code and see the impact (local dev loop, CI time, release cadence).
How safely you can change without causing outages or regressions (testing, rollback, blast radius).
How predictably you can scale when usage changes (performance isolation, capacity planning).
How painful it is to operate day to day (observability, incident response, deployment pipelines).

A monolith typically wins when friction is dominated by organizational coordination and integration overhead. A microservices approach can win when friction is dominated by independent scaling needs and different lifecycles between domains.

A monorepo typically wins when friction is dominated by cross-team coordination and shared interfaces. A polyrepo can win when friction is dominated by hard boundaries—legal, organizational, or release autonomy—that you genuinely need to enforce.

The trap is pretending those tradeoffs map cleanly to ideology. They don’t. They map to your constraints.

Monoliths aren’t a moral failing—coordination is the point

If you have a single codebase with clear boundaries inside it, you’re not “wrong.” You’re simply optimizing for the realities of engineering teams.

Here’s what a well-run monolith looks like in practice:

Your domain boundaries are explicit: packages/modules/classes map to business concepts, not just technical convenience.
Your APIs are stable internally: you avoid “randomly calling any function anywhere” by treating modules like contracts.
Your CI pipeline is disciplined: linting, unit tests, integration tests, and fast feedback are part of the product—not optional ceremony.
Your releases are boring: frequent deploys, automated rollback, and feature flags reduce the stress that people mistakenly attribute to the “monolith vs microservices” question.

Concrete example: imagine a retail platform where checkout, catalog browsing, and order management live together. If checkout needs to evolve weekly and the catalog needs to evolve monthly, you don’t need microservices to decouple those rhythms—you need internal boundaries and tooling. You can isolate deploy risk with feature flags and carve out independent deployable components within the monolith (for example, background jobs or internal modules that can be toggled independently).

Now, when does a monolith start to hurt? Usually not at “scale of traffic” alone. It’s when teams can’t move independently anymore because changes collide constantly—when build times explode, when deploys become a scary event, when understanding the system requires a small group of “architect guardians.”

That’s not a referendum on monoliths. It’s an alarm that your internal structure and engineering workflow need investment.

Microservices aren’t a victory lap—deployment complexity is real

Microservices are often sold as independence. Sometimes they deliver it. Often they deliver a new kind of coordination: you trade “one repo” problems for “many moving parts” problems.

Microservices add real operational load:

Deployment pipelines per service (or at least per group)
Service-to-service communication (and the failure modes that come with it)
Versioning and compatibility (contracts don’t stay compatible by vibes)
Observability across boundaries (logs aren’t enough; you need tracing and metrics that actually connect)

A common mistake is building microservices around organizational hopes rather than actual requirements. If you have a single team that changes everything together, splitting into services can amplify the cost of every change. You’ll end up writing distributed systems glue—retries, timeouts, circuit breakers—just to recreate what a monolith already handles naturally.

Concrete example: two services, user-profile and billing, both changed together every sprint. If you introduce an API boundary between them without a real reason (separate scaling needs, separate teams, separate compliance, or independent release timelines), you’ll likely slow the team down. Your integration tests will become more complex. Your debugging will become more distributed. Your release process will become less “one click, done” and more “orchestrate the dance.”

Microservices shine when you truly need independent evolution: different service ownership, different release cadence, different scaling constraints, or clear domain separation where teams can move without constant cross-team synchronization.

If that’s not your reality yet, microservices will feel like paying for a gym membership you don’t use.

Monorepos aren’t “too much”—they’re coordination made practical

Let’s talk monorepos without hand-wringing. A monorepo is just an engineering contract with your future self: shared code should be discoverable, tested, and versioned consistently.

A monorepo is especially effective when:

Teams frequently share libraries and components.
You want consistent code review and automated testing across the stack.
You need atomic changes across multiple packages (or at least predictable change sets).
You rely on internal tools or shared schemas.

The monorepo anti-pattern isn’t the repository. It’s the tooling and workflow. If your CI runs everything every time, your monorepo will feel slow. If developers can’t find the right library quickly, your monorepo will feel confusing. If ownership is unclear, you’ll get dependency sprawl.

So make monorepos work by investing in:

Incremental builds and targeted testing (run what changed, not everything).
Clear code ownership (CODEOWNERS, teams, or explicit module maintainers).
Good boundaries (lint rules, package visibility, and dependency constraints).
Developer experience (fast local builds, sensible test commands, and documentation that doesn’t rot).

And yes, polyrepos can be great too. If you have strict release independence or hard organizational boundaries, polyrepos may reduce accidental coupling. But don’t pretend monorepos are inherently unscalable or inherently “unconventional.” They’re only as painful as your build, test, and ownership discipline.

The worst architecture is the halfway one

The most expensive pattern I see isn’t monolith or microservices—it’s mid-migration. The team ends up with the complexity of both worlds and the benefits of neither.

What does “halfway” typically look like?

A monolith that’s been “service-ified” without a clean boundary plan, leaving tangled shared code and unclear ownership.
A microservices rollout where only the newest features are split out, but the old system still drives critical workflows.
Deploy pipelines that become a labyrinth: some changes go through monolith release, others through service releases, and both must be coordinated to make a single product change work.

The result is predictable: slower iteration, more outages, and a constant tax of “Do we change the monolith or the service?” That ambiguity doesn’t stay theoretical—it turns into production incidents, and then it turns into blame.

Pick a direction based on where your current friction actually lives.

If your friction is team coordination and integration pain, improve the monolith and tighten boundaries.
If your friction is operational isolation and independent scaling, commit to microservices (or at least a clear service extraction strategy).
If your friction is release governance and shared dependencies, choose monorepo and invest in tooling—or choose polyrepo and enforce boundaries intentionally.

And when you do migrate, migrate with an end state in mind. Don’t start a journey without knowing what “done” looks like.

How to decide without mythology

Here’s a decision framework you can use this sprint, not in some mythical architecture committee:

Write down your current deployment cadence.
If you deploy multiple times per day, microservices may add overhead without payoff. If you deploy monthly because the monolith release is scary, you may need better release engineering and internal modularity before changing architecture.
Identify your scaling pain.
Is performance constrained globally (monolith bottleneck) or selectively (a domain with distinct load patterns)? Microservices can help when specific domains need independent scaling, not when you just want to “be scalable.”
Measure change propagation.
When a developer merges a feature, how many systems need to change? If it’s always everything, microservices won’t reduce the coordination cost yet. Focus on internal boundaries, tests, and feature flags.
Assess team topology.
Do you have stable team ownership per domain? If yes, microservices can map cleanly to teams. If not, a monolith with modular boundaries may be a better starting point.
Decide on repo strategy based on dependency reality.
If shared code is constant and correct integration matters, a monorepo usually reduces friction. If boundaries are strict and releases must be independent by policy, polyrepo might be appropriate.

The key is to treat architecture as a living implementation detail of your delivery system. Don’t worship patterns. Build what reduces your time-to-productive-change.

Conclusion: Stop apologizing—start optimizing

Monoliths are fine. Microservices are fine. Monorepos are fine. Polyrepos are fine. The only failing architecture is the one that stalls your team’s ability to ship reliable improvements.

If your system is understandable, your deployments are manageable, and your team can iterate without dread, you already have the right architecture for today. Invest in boundaries, testing, observability, and developer experience—then revisit when your friction profile changes.

Ship features. Keep the lights on. And retire the apology.

Python Ate Another Seven Points of Market Share and AI Is Why

abdecastro@protonmail.com (Antonio B De Castro) — Fri, 07 Mar 2025 00:00:00 +0000

Every few years, the tech world witnesses a shift that feels almost unfair to legacy thinking: a mature, decades-old language suddenly starts behaving like a new platform. That’s what’s happening with Python—except this time the engine isn’t “developer preference” in the abstract. It’s the AI/LLM ecosystem, where Python has become the default operating system for building things that talk, predict, retrieve, and automate.

The “impossible” growth curve: why Python’s jump looks different

A seven-percentage-point leap in a single year is the kind of movement you usually see when something genuinely new arrives—new browsers, new frameworks, new paradigms. Python is neither new nor small. It’s been around for over 30 years, and its core identity is stable: readable syntax, batteries-included standard library, and a vast ecosystem of packages.

So when Python’s adoption visibly accelerates, the “why” matters. It’s not because Python suddenly became faster at the language level or because developers collectively changed their minds overnight. It’s because the work developers are being asked to do has changed—dramatically—and Python is the most efficient language for that work.

Here’s the crux: AI development isn’t a single task. It’s a pipeline of tasks—data prep, experimentation, model training or fine-tuning, evaluation, orchestration, serving, monitoring, and iteration. Python sits at the center of that entire lifecycle, and the ecosystem around it has matured into an assembly line.

AI isn’t just “using Python”—it’s demanding Python-first tooling

If you’ve built anything with modern machine learning, you know the pattern: you start with notebooks, you sketch experiments quickly, you iterate on data transformations, and you wire up training loops. Then you transition to APIs so the model can be used by applications. Finally, you productionize: versioning, logging, testing, deployment.

Python is uniquely positioned because it’s already the glue language for each phase:

Research and training workflows tend to be Python-native—think model code, training loops, evaluation scripts, and experimentation tooling.
Data tooling—cleaning, preprocessing, feature engineering, dataset iteration—often lives in Python because integration is easy and libraries are everywhere.
Serving and integration—turning results into endpoints—works smoothly with Python web frameworks and inference libraries.

This is why the AI boom doesn’t just “boost” Python. It reinforces Python as the center of gravity. The more LLM frameworks and ML libraries the community builds, the more Python becomes the path of least resistance for the next project. Ecosystems compound. Python is the compound-interest vehicle.

FastAPI, notebooks, and PyTorch: the trio that made Python the default

Python’s AI advantage isn’t vague. It’s embodied in specific tooling choices that have become standard practice in real teams.

FastAPI for APIs: from prototype to endpoint without a rewrite

Most teams don’t start with production architecture. They start with a prototype. For LLM apps, that prototype often ends up being an API call: “take this prompt, return that response.”

FastAPI has become a go-to because it fits the workflow:

You can validate inputs cleanly.
You can generate interactive documentation.
You can ship endpoints with minimal friction.

A typical progression looks like this: you prototype a model invocation in Python, then wrap it as an HTTP service with FastAPI, then add background tasks (for streaming, retrieval, or longer-running jobs). The language stays the same across the journey, which means the team spends time improving the system—not rewriting it.

Jupyter notebooks for experimentation: the universal sandbox

Notebooks may be messy, but they’re effective. They’re where ideas become experiments and experiments become systems.

In LLM development especially, experimentation is relentless:

prompt changes,
retrieval tweaks,
chunking strategies,
tool-calling behaviors,
evaluation sets and metrics.

Notebooks let teams iterate quickly, share results, and explore failure modes. Even when projects later move into structured codebases, notebooks often remain the operational “lab notebook” for ongoing iteration.

PyTorch for AI research and development: the practical research engine

When you want to understand, modify, and train models, you need a framework that supports the entire research loop. PyTorch has become the lingua franca for that work—especially in the AI community—because it provides a flexible, Pythonic way to define and train neural networks.

Even if your end product is not a training-heavy system, many teams still rely on PyTorch in the pipeline: generating embeddings, running inference, fine-tuning, or validating behaviors. It’s not just “research only.” It’s practical.

The real reason adoption spikes: AI development is iterative, and Python minimizes friction

Developers don’t choose a language because it wins a theoretical contest. They choose it because it reduces time-to-result under constraints. AI projects have unusually tight feedback loops, and Python optimizes for those loops.

Consider a concrete scenario: building an internal “policy assistant” using retrieval-augmented generation (RAG).

A realistic workflow might include:

Ingest documents and normalize them.
Chunk and embed text.
Store embeddings in a vector database.
Retrieve relevant chunks at query time.
Compose prompts and run the LLM.
Evaluate answers against a test set.
Add citations, guardrails, and fallback behaviors.
Expose the system via an API for the product team.

Each step benefits from Python’s ecosystem and expressiveness. You can move through the workflow without switching languages or constantly translating concepts across stacks. That matters because AI projects rarely go straight from “idea” to “finished.” They go from “works on my notebook” to “works for real users,” and that transition is where friction kills momentum.

Python’s advantage is that it keeps you in the same environment while you iterate.

Practical advice: if you’re choosing a stack, optimize for the AI lifecycle

The right move isn’t “learn Python because everyone else does.” It’s to choose an approach that matches the AI lifecycle you’ll actually run.

Here’s how to think about it:

If your work involves experimentation, evaluation, and rapid iteration, Python is the most efficient starting point. Notebooks, rapid prototyping, and model tinkering are where time is won.
If you’re building model-backed services, pair Python with a framework like FastAPI so the path from experimental code to maintainable APIs is straightforward.
If you’re doing training or fine-tuning, expect Python-first tooling (PyTorch-style ecosystems) to remain central.
Plan for production from day one, even if you prototype quickly. Structure code early, treat notebooks as experiments, and move critical logic into tested modules.

And yes—use the right boundaries. One common failure mode is “notebook sprawl,” where the prototype becomes the product without guardrails. A mature workflow looks like this:

Keep notebooks for exploration and experiments.
Put production logic into a package/module.
Add automated tests for core behaviors (preprocessing, prompt formatting, retrieval routing).
Monitor model outputs and latency like any other system.

The goal isn’t to worship Python—it’s to use Python to accelerate the parts that benefit from acceleration, without surrendering engineering discipline.

What this means for the “language wars” narrative

When Python’s market share rises this sharply, it doesn’t invalidate other languages. JavaScript still dominates the web surface area. Java and C# still power enterprise backends. Go and Rust show their strengths in systems and reliability-focused contexts.

But AI changes the center of gravity. The “war” isn’t about which language is best at everything. It’s about which language sits at the intersection of:

rapidly evolving libraries,
widely shared examples and patterns,
tooling that supports the full development loop,
and teams that need results quickly.

Python is winning that intersection because it behaves like an ecosystem, not just a language.

Conclusion: Python isn’t growing despite AI—it’s growing because AI speaks Python

Python’s seven-point jump isn’t a mystery if you look at what developers are building right now. LLMs and AI frameworks didn’t just add new jobs; they created a new development lifecycle—iterative, pipeline-driven, experiment-heavy, and ecosystem-dependent. Python is the native tongue of that lifecycle.

If AI is the new default workload, then Python isn’t merely benefiting. It’s becoming the fastest route from idea to working product, and that kind of advantage compounds.

The MCP Ecosystem Exploded and We're Just Getting Started

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 01 Mar 2025 00:00:00 +0000

In under four months, the Model Context Protocol (MCP) went from an announcement to an integration ecosystem phenomenon. And the reason isn’t hype—it’s engineering. MCP is the rare kind of protocol that feels inevitable: simple enough that an individual developer can ship something useful in an afternoon, yet structured enough to scale into a real platform.

What we’re watching is the TCP/IP moment for AI tool integration: once a common “wiring” standard exists, the ecosystem doesn’t need permission to grow.

Why MCP Took Off So Fast

Most integration efforts fail because the protocol is either too abstract to implement or too opinionated to reuse. MCP hit a sweet spot. It’s fundamentally just a small set of JSON-RPC methods over stdio, paired with a predictable process model. That choice matters.

When integration is “one-way glue,” it’s fragile and expensive to maintain. When it’s a “real protocol,” it becomes a product primitive. MCP turned “tool access” into something you can implement once and expose broadly.

Here’s what that looks like in practice:

A tool provider (say, “PostgreSQL”) can expose a narrow, well-defined capability—querying, schema inspection, or metadata—without asking every client to learn its internals.
A client (an AI application) can discover what’s available and call it using a consistent interface.
A developer can write a server without standing up a complex web service, onboarding flow, auth system, or bespoke SDK every time.

The speed came from eliminating the parts that usually slow ecosystems down: bespoke protocols, custom client code, and long feedback loops.

“Few Methods Over Stdio” Is the Secret Weapon

Let’s be concrete. The core experience of MCP for builders is:

Run a local process (the MCP server).
Speak MCP over a standard stream.
Use a tiny RPC surface to list tools and execute them.

That design compresses the path from idea to working integration. No load balancers. No gateway rewrites. No “works on my machine” service deployment drama. You can prototype quickly, then harden later.

Consider a developer building an integration for a collaboration tool like Slack:

The developer can implement “list channels,” “search messages,” or “post a message” as MCP tools.
The AI client can call those tools with consistent parameters and get structured results back.
From there, you can iterate: add richer query options, add better formatting, and tighten permission handling.

Compare that to typical integration patterns where every new model client requires a separate connector. MCP flips the equation: integrations become reusable “adapters” that any MCP-capable client can consume.

And that’s the broader principle: protocols win when they make reuse the default.

The Explosion: 300+ Servers and a Copy-Paste Ecosystem

Once a protocol becomes implementable, the ecosystem fills in rapidly. We’ve already seen servers for mainstream tools—GitHub, Slack, PostgreSQL, Jira, Linear, Notion—and hundreds beyond them. But the most important detail isn’t just the number; it’s the distribution of effort.

A typical outcome looks like this:

One developer builds an MCP server for a tool.
Another developer extends it (better filtering, pagination, richer schema context).
A third developer adapts it for a specific organization’s workflow (custom projects, naming conventions, internal policies).

Because MCP servers are small, the ecosystem supports branching and specialization without requiring a full platform rewrite. The protocol becomes the stable center, and innovation happens at the edges.

This is also why the “TCP/IP moment” analogy holds. When networking standards spread, they don’t just add more devices—they unlock new categories of application. MCP doesn’t just connect AI to tools; it makes tool connectivity composable.

How to Think About MCP: Tools, Context, and Safety

It’s tempting to treat MCP as “just connectors.” But if you want real production value, you have to think in terms of capabilities and context management.

Tools are contracts, not scripts

A good MCP server exposes tools that are:

Purposeful: narrowly scoped operations (e.g., “search issues by JQL,” not “do whatever you want”).
Typed: clear input schemas that reduce ambiguity.
Deterministic: structured outputs that your client can reliably interpret.

Context isn’t an afterthought

AI clients need context to be useful. With MCP, servers can provide context via tools like “get schema” or “list resources,” but the real win is reducing the client’s guesswork.

For example, with a database integration:

Instead of relying on the model to remember table names, the client can call a “schema inspection” tool.
The model can then generate queries grounded in actual fields and relationships.
The output can return query results in a format designed for follow-on reasoning.

Safety must be designed into tool boundaries

The simplest tool to implement is often the most dangerous to expose. If your server includes an “execute arbitrary SQL” tool, you’ve effectively created a remote execution interface.

A safer pattern is to expose constrained operations:

Read-only querying tools for exploratory workflows.
Parameterized actions that limit scope (e.g., only within a specific schema or allowlist).
Explicit “confirm” steps for mutations, where applicable.

You don’t need fancy research to justify this. You just need to respect that MCP tools are callable by an AI system—which means you should minimize the blast radius.

Building an MCP Server in an Afternoon (Then Fixing What Matters)

The headline is true: implementing an MCP server can be fast. But the difference between a demo and a dependable integration is usually not protocol complexity—it’s product discipline.

If you’re building (or evaluating) an MCP server, here’s a practical checklist:

Start with one or two tools
- Example: for GitHub, begin with “search repositories” and “create an issue.”
- Don’t start by trying to mirror the entire API surface.
Define strict input schemas
- Prefer explicit fields over free-form text.
- Make pagination and limits first-class parameters.
Return structured outputs
- Provide consistent keys and predictable formats.
- Include identifiers (IDs, URLs) so the client can chain actions safely.
Design for failure
- Network issues, auth expiry, missing permissions—build reasonable error messages.
- Your AI client will surface these errors to users, so clarity matters.
Treat auth like a capability boundary
- Ensure tokens are stored securely and never echoed to the model.
- If your integration needs user permissions, build the workflow explicitly.
Add guardrails for write operations
- Mutations should be deliberate: scoped, confirmable, and logged.
- If your tool can change state, you should make it hard to do so accidentally.

If you do just these, your server will feel “real,” not “prototype-y,” even if it started as one.

Where MCP Goes Next: From Adapters to Infrastructure

The most interesting part of this story isn’t that MCP servers exist—it’s that they behave like infrastructure. Once you can standardize tool discovery and invocation, you can build higher-level systems on top:

Multitool workflows that coordinate GitHub + Jira + Linear without bespoke glue.
Environment-aware automation where an agent inspects the workspace, then decides which tools to call.
Composable internal platforms: teams can standardize on MCP servers for their data sources and business systems, making AI features portable across clients.

And because MCP is lightweight, teams can keep local control. Instead of routing everything through a heavyweight service layer, you can run servers where the credentials and policies already live.

This is why the ecosystem is compounding. Each new server reduces the incremental cost of adding another capability. Each integration becomes a building block. And because the protocol is stable, you don’t have to rewrite your wiring every time a new client appears.

Conclusion: The Protocol Is the Product

MCP didn’t just spark a wave of integrations—it changed the economics of building them. A tiny JSON-RPC interface over stdio turned “AI tool support” into something developers can ship quickly, reuse broadly, and improve continuously.

We’re not at the end of the story. We’re at the beginning of a new kind of tooling ecosystem—one where the plumbing is standardized and innovation happens at the capability layer. The moment protocols become boring, ecosystems get exciting.

SQLite Is Having a Moment and It's Not Just for Mobile Anymore

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 23 Feb 2025 00:00:00 +0000

For years, SQLite lived in the shadows: the reliable little workhorse quietly powering apps on a phone, a laptop, or an offline-first prototype. But the ground has shifted. Today, teams are turning SQLite into a distributed database platform—by adding replication, global distribution, and continuous backups around it. The result is a pragmatic architecture where your users don’t just get faster software—they get faster data.

Why SQLite Suddenly Feels “Distributed”

SQLite was never meant to be a cluster database. It’s a single-file engine designed to be embedded, deterministic, and easy to move. That simplicity used to be a liability when you needed horizontal scaling or HA.

The renaissance comes from a new pattern: don’t replace SQLite—wrap it with distribution.

Instead of asking SQLite to do everything, modern systems treat it as the core data engine and add:

Global placement (so reads and writes start near users)
Replication (so failures don’t equal downtime)
Change capture + streaming backups (so recovery doesn’t require heroic restores)

This changes how you build. You stop treating “database” as a remote service you must tolerate and start treating it as a local capability your application can rely on—then you distribute that capability where it matters.

Think of it as local-first, but with production-grade guardrails.

Turso: Shipping SQLite to the Edge

Turso’s big idea is straightforward: make SQLite feel like a globally distributed database without making you learn a whole new database paradigm. The implementation details vary, but the architecture goal is consistent: keep SQLite close to your users by running it in edge locations and coordinating access so your app can use it as if it were local.

What does that unlock?

Example: A read-heavy app that shouldn’t pay the latency tax

Imagine a web app for product analytics where most requests are “give me aggregated metrics” and only a smaller portion are writes. If your data lives in a distant region, every page load quietly pays a latency toll.

With an edge-distributed SQLite approach, you can:

Reduce time-to-first-byte for read queries
Keep interactive browsing snappy
Still support updates without forcing your whole system into a centralized OLTP design

Practical advice: Choose your consistency expectations deliberately

Distributed systems are mostly about trade-offs. If your workload is read-heavy, you can often tolerate slightly fresher data than strict transactional semantics. The right move is to define what your users should experience:

Does “freshness” mean seconds, minutes, or milliseconds?
Are stale reads acceptable for non-critical views?
Can you design writes to be idempotent so retries are safe?

Turso-style distribution shines when you shape the app around these realities instead of fighting them.

LiteFS: Replicate SQLite Across Nodes for Read Scaling

Turso gets you global proximity; LiteFS targets a different pain: scaling reads by replicating the database across multiple nodes.

SQLite is great at local performance. The trick is getting those benefits when multiple machines need access. LiteFS replicates changes so each node can run queries locally rather than funneling everything through a single database instance.

Example: A multi-node backend for the “same” app data

Consider a service where:

Write traffic is moderate (events, orders, user actions)
Read traffic is heavy (dashboards, recommendations, query-driven UIs)

Instead of having every node hit a central database over the network, you replicate the SQLite database. Now each node can run reads locally—faster, cheaper, and less fragile under network jitter.

Practical advice: Design for conflict boundaries

Replication systems usually have a “happy path” model: one primary writer, then fan out to replicas. That doesn’t mean you’re trapped in a single-writer design, but it does mean you should think about:

Where writes originate
How conflicts are avoided or resolved
What happens during failover

If your app can centralize writes (or route them deterministically), you’ll get a lot of the simplicity that makes SQLite attractive in the first place.

Litestream: Continuous Streaming Backups You Can Actually Trust

Replication helps with uptime. But you still need backups—real ones. Litestream addresses the uncomfortable truth that backups are often an afterthought until a failure forces a restore you didn’t test.

Litestream provides continuous streaming backups of SQLite changes to durable storage like S3. The key value is not just “backups exist,” but that they exist continuously and can be restored incrementally.

Example: The difference between “we’ll restore later” and “we can recover”

Picture a production issue:

A deployment bug corrupts a database table
You discover it quickly, but restoring from an overnight backup means losing hours of data

With continuous streaming backups, recovery becomes a routine operational move rather than a stressful forensic exercise. You restore to a recent point in time close to when the corruption occurred.

Practical advice: Treat restore as a first-class feature

Backups aren’t useful unless your team can restore them. Make it part of your process:

Automate restore into staging
Run tabletop exercises (“What if the database is corrupted?”)
Document the runbook so it doesn’t live only in someone’s head

If you’re building with SQLite in a distributed-ish architecture, backups become the safety net that lets you move fast.

Putting It Together: Local-First Data, Global-First Performance

The most compelling outcome isn’t any single tool—it’s the pattern they enable.

By combining edge distribution (Turso), node replication (LiteFS), and continuous streaming backups (Litestream), you can build systems where:

Data is near users (edge-first reads)
Compute scales horizontally (each node can serve locally)
Failures are survivable (replication + durable backups)
Recovery is predictable (streaming backup trails)

Example architecture: “Fast dashboards with safe writes”

A practical blueprint for many teams:

Clients read from a nearby SQLite-backed node
Dashboards feel instant because queries run locally to that edge region.
Writes flow to a primary (or a controlled writer path)
You avoid the chaos of multi-writer conflicts.
Replicas receive updates
Each node updates its local SQLite copy, so reads remain fast.
Every change is continuously backed up
Litestream streams snapshots/segments to S3 (or another durable store), enabling quick, point-in-time restores.

Even if you don’t fully adopt all three components, you can borrow the design mindset: performance through locality, reliability through replication and streaming backups.

When SQLite (and This Pattern) Is a Great Fit

SQLite isn’t “better than” every database. But it’s a strong fit when your product needs certain qualities:

Read-heavy workloads: dashboards, feeds, query-driven UI, analytics views
Embedded analytics: compute aggregates close to where data lives
Local-first architectures: offline capability, fast local writes, resilient sync
Moderate write throughput with real-time expectations: events and state updates with immediate visibility

If your workload is dominated by complex joins across huge datasets, or you need heavyweight distributed transactions, you may still prefer other systems. But for many modern applications, you don’t need a monster—you need a fast, reliable core with sane operational properties.

Practical advice: Start by choosing your “data gravity”

Ask: where should data live to make the app feel fast?

If users are global: edge distribution matters.
If traffic is spiky and read-heavy: replication matters.
If your biggest fear is data loss: streaming backups matter.

Pick one and build outward. The tools are modular. The architecture pattern is what sticks.

Conclusion: SQLite Is Becoming an Architecture, Not a Tool

SQLite’s moment isn’t nostalgia for “the little database.” It’s a serious rethinking of how data can be shipped, replicated, and protected without drowning teams in complexity.

Turso brings SQLite to the edge, LiteFS scales reads by replicating across nodes, and Litestream makes continuous backups practical. Together, they unlock a modern promise: code and data close to users, with operational confidence.

If you’ve been waiting for SQLite to become “enterprise enough,” this is the breakthrough. The secret weapon isn’t the engine—it’s the ecosystem and the architecture you build around it.

Docker's +17 Point Surge Is the Most Underreported Story in Dev

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 11 Feb 2025 00:00:00 +0000

Every few months, the ecosystem rediscovers the “next big thing” and spends weeks arguing about it. Meanwhile, Docker has been quietly doing something far more consequential: turning from “useful tool” into “default foundation.” In one of the largest single-year adoption jumps ever seen in the Stack Overflow survey data, Docker reportedly climbed by +17 percentage points. That’s not a marketing win. That’s a phase transition—and it’s undercovered because nobody’s excited by infrastructure becoming boring.

What the +17 Really Means (And Why It Matters)

Adoption graphs don’t move like that unless something changes at the workflow level. A +17 point swing in usage is the kind of step-change that usually follows an ecosystem shift: a platform matures, tooling stabilizes, and the “old way” stops being the path of least resistance.

Think about what Docker represents in practice:

A single command to run a service anywhere.
A repeatable filesystem + runtime environment.
Dependency boundaries you can reason about, review, and version.

If you’re building software, reproducibility isn’t a nice-to-have—it’s how teams stop burning time on “it works on my machine.” When a tool becomes the shortest route to reliable builds and deployments, adoption stops being optional. It becomes muscle memory.

That’s the leap Docker is making: from “popular tool” to “assumed infrastructure,” similar to what Git became years ago. Once something is the baseline, discussions migrate elsewhere. People stop saying “I use Git,” and they just start shipping commits.

Docker Was Already Winning the Dev Loop—AI Just Gave It a Runway

It’s tempting to credit Docker’s growth to cloud adoption, microservices, or general container hype. Those factors matter, but the real accelerant is unmistakable: AI development, especially the LLM-centric workflow that’s now everywhere.

Here’s the uncomfortable truth for modern teams: LLM app development is dependency-heavy and environment-sensitive.

A typical stack today looks like:

A Python runtime with the right CUDA/CPU behavior
A specific version of PyTorch (or TensorFlow, JAX, or whatever your stack uses)
Tokenizers and model-serving libraries with their own quirks
System packages (often OS-level libraries) that “shouldn’t matter” until they do
Feature flags and config tied to dataset preprocessing and model formatting
GPU vs CPU variations across dev machines

In other words, it’s not just “code.” It’s a fragile bundle of assumptions.

Docker turns that bundle into an artifact you can share with confidence. When your team says, “Run it with Docker,” you’ve eliminated the most expensive failure mode in software: silent mismatches.

The LLM Reproducibility Problem Docker Solves

Let’s make it concrete. Suppose you’re building a Retrieval-Augmented Generation (RAG) service. You might have:

An embedding pipeline that depends on a specific model version and tokenizer behavior
A vector database with a particular schema expectation
An indexing job that must use identical preprocessing steps
An API server that loads models and runs retrieval consistently

Now add the real-world scenario: one developer uses Python 3.11 locally, another uses 3.10, and a third is on an older Linux image. Suddenly, you don’t get a clean error—you get subtle differences. Embeddings shift. Retrieval quality drifts. Tests “almost pass.” Debugging becomes a detective story instead of engineering.

Docker gives you the one thing teams crave in fast-moving AI projects: environment determinism.

Instead of debating whose laptop is “correct,” you codify the runtime:

Pin base images.
Pin dependency versions.
Encode system dependencies explicitly.
Make GPU requirements explicit instead of implicit.

Even when the underlying model stack changes weekly, the container can be rebuilt with the new pins—and your team knows they’re running the same reality.

From “Container Trend” to Oxygen: Why Teams Stop Questioning It

Containerization doesn’t become “oxygen” because people love containers. It becomes oxygen because the alternative costs too much.

The cost shows up as:

onboarding time that drags for days
PR review churn caused by environment failures
flaky tests that pass locally and fail in CI (or worse, fail everywhere)
production “it behaved differently here” incidents

Docker doesn’t remove engineering complexity—but it corrals complexity into a predictable boundary. That boundary is powerful in AI development because your stack is moving quickly and your experiments are numerous. You need to iterate without the “reset the machine” tax.

There’s also a cultural shift happening. Teams now expect that an AI demo, a training pipeline, or an evaluation harness comes with a runnable environment. If it doesn’t, people assume it will be painful—and they may just not try it.

That expectation is exactly what the adoption surge signals. The tool stops being a topic and becomes a default behavior.

Practical Guidance: How to Make Docker Serve AI (Not Just “Run Code”)

If Docker adoption is soaring, the winners won’t be the teams that “use Docker,” full stop. They’ll be the teams that structure their Docker usage like a product feature. Here’s what that looks like in real projects:

1) Treat your container as an interface

Your container image is the contract between your code and the runtime. When you publish it (internally or externally), include:

clear tags (e.g., rag-eval:0.3.2)
documented build instructions
a single entrypoint command for common tasks (train, index, serve)

If your onboarding instructions say “run pip install -r requirements.txt and hope,” you’re not getting the real benefit.

2) Pin versions aggressively—especially for AI stacks

For LLM apps, pinning isn’t about purity. It’s about avoiding shifting behavior. Pin:

Python and OS base image
key ML frameworks
tokenizers and preprocessing libraries
evaluation dependencies

Yes, it requires maintenance. But maintenance is cheaper than debugging.

3) Separate dev containers from production images

A common failure mode is using the same container for everything. Instead:

dev image: faster iteration, tooling installed
prod image: minimal runtime, security posture, deterministic dependencies

This keeps build times and attack surface reasonable while preserving reproducibility.

4) Make GPU needs explicit

If your app needs CUDA or specific GPU behavior, encode it in the container strategy rather than relying on developer luck. The worst experience is a “works on my GPU” workflow that collapses for everyone else.

5) Don’t hide complexity behind magic

It’s tempting to wrap Docker in scripts until nobody can tell what actually runs. Resist that. Keep Dockerfiles readable and the build process understandable. Your future self will thank you.

Why This Story Is Underreported—and Why It’s Still the One to Watch

AI gets attention because it’s novel and visible: demos, benchmarks, flashy tools. Docker’s story is more subtle because it’s the scaffolding. The adoption jump is a sign that teams are shifting from “experiment mode” to “build mode.”

When Docker becomes assumed infrastructure, it means teams are standardizing. Standardization is what unlocks collaboration, automation, scaling, and velocity. It’s the quiet enabler behind many AI engineering practices people treat as “new.”

So the underreported angle isn’t that Docker is growing. It’s that Docker is becoming the default. And defaults are where ecosystems converge.

If you’re building anything LLM-related—and especially if you care about shipping reliably—Docker shouldn’t be an afterthought. It’s how you turn brittle experimentation into durable systems.

Conclusion: Docker Is Becoming the Baseline for Reliable AI Engineering

A +17 percentage point adoption jump isn’t just momentum; it’s an ecosystem reorientation. Docker is moving into the same role Git occupies: the tool people stop mentioning because it’s simply how the work gets done. AI development, with its dependency sensitivity and reproducibility demands, is the perfect catalyst. In the rush to chase models, Docker is already delivering the foundation teams need to build, test, and iterate without chaos.

Cursor Changed My Mind About AI-Native Editors

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 04 Feb 2025 00:00:00 +0000

I’ve been around enough “AI features” to distrust the hype. For a while, I treated AI in editors like a garnish: helpful, occasionally brilliant, but never fundamental. Then I spent a week in Cursor, and I had to admit something uncomfortable—my mental model was wrong. AI-native editors aren’t just VS Code with smarter plugins. They’re a different class of tool, and the difference shows up the moment you stop asking it to “help you type” and start asking it to understand and change your codebase.

The real problem with “AI as a plugin”

Most AI experiences inside editors follow the same pattern: you trigger a chat or command, the tool generates some text, and you manually splice it into your project. Even when the integration is excellent, the architecture tends to be additive—AI bolted on after the editor’s core assumptions are already set.

That matters because coding isn’t just writing lines. It’s maintaining invariants across files, refactoring across boundaries, obeying conventions, and avoiding silent regressions. A plugin-style AI assistant can be clever at answering questions, but it struggles to operate like a reliable collaborator when the unit of work is bigger than a snippet.

Here’s the moment I usually notice the limitation: you ask for a refactor, the assistant proposes changes, and suddenly you’re doing reconciliation. Which file should change? Did it update all call sites? Did it preserve formatting? Did it accidentally break an import graph or introduce a circular dependency? With plugin-style AI, those questions are mostly answered by you—slowly, cautiously, and repeatedly.

Cursor flips the default by making AI part of the editor’s workflow—not an overlay you summon when you’re stuck.

AI as a foundation: codebase-aware chat that actually knows the room

The first shift is how chat behaves when it’s integrated into the editor itself. In Cursor, the assistant isn’t just generating plausible suggestions; it’s participating in your project context as a first-class object. Ask something like: “Where are we validating auth tokens, and what happens when refresh fails?” and you don’t get a generic explanation—you get answers grounded in your repository’s structure, names, and actual code paths.

What surprised me most wasn’t that it could “find files,” but that it could reason across them without making me jump through hoops. In a normal setup, you’d bounce between tabs, copy/paste snippets, and prompt the assistant with whatever you managed to extract. The cognitive tax is real.

In Cursor, you can approach questions the way you would with a strong teammate:

“Show me every place this API is called and why the error mapping differs between routes.”
“What would break if we change this function signature? List impacted files and propose a safe update plan.”
“Explain this module like I’m onboarding—point me to the data flow and the contracts between layers.”

You can still prompt it like a chatbot, but the editor integration nudges you toward problem-solving. It’s less “talk to a model” and more “coordinate with a system that has your code loaded as working memory.”

Multi-file edits: the difference between suggestions and commits

The second shift is more practical, and arguably more important: how changes get applied.

With plugin-style AI, you typically accept output text and then manually edit it into place. That turns every change into a series of separate steps. The refactor becomes fragile, because each step is an opportunity for mismatch—one missing import here, one inconsistent type there, a formatting difference that triggers lint errors later.

Cursor’s multi-file editing is designed around atomic-ish workflows: you don’t just “get an answer,” you get a set of edits that are meant to land together. When you’re refactoring something that spans routing, validation, and storage, you want the assistant to change all relevant files in concert, not one at a time while you hope the remaining steps still align.

A concrete example: imagine you’re introducing a new field to a request payload and need it to propagate from the HTTP handler to the service layer, into persistence, and back out through a response transformer. In a plugin setup, you’d be juggling prompts, searching for usages, and verifying that everything updated cleanly.

In Cursor, you can ask for the change as a goal—“Add tenantId to the request payload, validate it, persist it, and include it in the response where applicable”—and then inspect a coherent set of modifications. Even when you disagree with parts, the workflow still feels like you’re reviewing a single proposed change, not stitching together a patchwork.

AI-generated diffs you can accept—or reject—per hunk

This is where my trust issues finally got resolved. The most important feature of an AI editor isn’t raw generation quality; it’s controllability.

Cursor presents changes as diffs with granularity—hunks you can accept or reject. That turns the assistant into something closer to a code review partner. You’re not forced to swallow a whole refactor in one gulp. You can say: yes, update the data model; no, not like that for validation; revise the mapping logic to match the existing error schema.

In practice, this changes how you use the tool:

Ask for a change plan in plain language.
Review the diff with a “lint-and-logic” mindset.
Accept the safe hunks first.
Push back on the risky ones with targeted follow-ups.

If you’ve ever worked with code generation tools before, you know the difference between “here’s a replacement file” and “here are incremental, reviewable edits.” Cursor behaves more like the latter, and that makes it drastically easier to keep your standards intact.

The composer effect: generating features across boundaries

The composer—Cursor’s ability to generate larger chunks of functionality—was the final nail in my old worldview. Plugins often excel at micro-edits or localized fixes. A composer mindset is different: it’s oriented around delivering a feature that spans multiple modules, not just patching what’s directly visible.

Instead of “autocomplete, then fix the rest,” it’s closer to “implement the feature, then review and adjust.” You can request things like:

“Build a new admin endpoint to list users with pagination and role filtering.”
“Add a feature flag system that toggles behavior per request, using existing config patterns.”
“Refactor this workflow into a cleaner service layer and update tests accordingly.”

The key isn’t that the assistant always nails every line on the first try. It’s that the editor experience supports iterative construction. You can accept the parts that match your architecture, reject the parts that don’t, and guide the rest until it conforms to the project’s style and semantics.

And because the system is editor-native, the generated work is immediately inspectable, runnable, and diffable. That reduces the “AI output as text blob” problem that often kills momentum in other tools.

How I use Cursor day-to-day (without losing control)

Let me be blunt: AI-native editors only feel magical if you adopt the right habits. Otherwise, they become yet another source of confusion. Here’s the workflow that made Cursor consistently effective for me:

Start with intent, not instructions. Instead of “write a function,” say “I need an endpoint that validates X, stores Y, and returns Z with these error cases.”
Constrain scope explicitly. “Update only files under services/ and routes/” beats vague prompts every time.
Review diffs like you would a PR. Accept small hunks; reject anything that touches security-sensitive code without scrutiny.
Use the chat to verify assumptions. When the assistant proposes something that sounds right, ask it to point to the exact code path it used to reach that conclusion.
Treat the composer as a starting engine. Expect to adjust architecture choices. Your job isn’t to rubber-stamp—it’s to steer.

This approach is how you keep the assistant from becoming an autopilot. You’re still the engineer. You’re just delegating the grunt work: searching, wiring, applying consistent edits across files, and drafting the mechanical parts of refactors.

Conclusion: AI-native beats AI-adjacent because software is bigger than text

I resisted AI-native editors because I believed the value was mostly in models and prompts. Cursor forced a different realization: the editor experience—the way context flows, how changes are represented, and how multi-file edits are handled—determines whether AI is genuinely useful or just decorative.

If you want AI to help with “the next line,” a plugin can be enough. But if you want an assistant that can see your repository as a coherent system and propose reviewable changes that span files, AI-native is the point. Cursor changed my mind because it made AI feel less like a suggestion engine and more like a collaborative editing environment—one where you can move fast without surrendering control.

The Case for Zig in 2025

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 30 Jan 2025 00:00:00 +0000

Every new language claims it will “make systems programming easier,” but most deliver the same bargain in different wrapping paper: you either accept C’s manual sharp edges or you accept a stricter compiler regime that can feel like it’s steering your hands. In 2025, Zig stands out because it offers a third path. You get C-like control, explicitness, and predictable performance—without reaching for a macro-heavy toolchain or wrestling the language into Rust’s ownership worldview. It’s not a replacement for Rust. It’s an alternative philosophy: trust the programmer, while making the unsafe parts loud and the compile-time metaprogramming sane.

Why Zig is different: “explicitness” over “enforcement”

Zig’s core pitch is simple: do more with less magic. C gives you direct control, but it also gives you footguns—buffer overflows, lifetime confusion, and error paths that are easy to ignore. Rust tries to prevent whole categories of problems by making invalid states hard to represent. That’s powerful, but it can also impose a mental model that doesn’t fit every problem, especially when you want to bend the compiler to your will.

Zig takes a more human-centered approach. Instead of enforcing ownership and borrowing across the entire ecosystem, it emphasizes explicit control flow and visible effects. If something can fail, it’s expressed in the type system in a way that doesn’t hide behind conventions. If memory management is your job, Zig makes it your job—clearly and ergonomically—rather than pretending the compiler can understand every intent.

This isn’t “no safety.” It’s “safety by design clarity.” For many teams, that trade feels healthier than either extreme.

Compile-time code that behaves like code (not macros)

If you’ve spent time in C++ template land or C macro land, you already know the pain: metaprogramming that’s clever can become unreadable, and compile-time diagnostics often feel like deciphering an ancient prophecy.

Zig’s comptime flips that relationship. It’s not a macro system in the “substitute tokens until you hope it works” sense. Instead, Zig uses regular language constructs and asks the compiler to evaluate them at compile time when you choose. That means your metaprogramming is still “Zig,” with the same mental model—loops, branches, types, and values—just executed earlier.

A concrete example: imagine you’re writing a small serialization function that needs to know field offsets for a packed struct. With comptime, you can iterate fields at compile time and generate the offset table using ordinary control flow. The result is deterministic, debuggable code generation without shoving logic into preprocessor macros.

The practical upside for 2025 developers is speed of thinking. You can prototype compile-time logic quickly, because you’re not debugging token pastes—you’re debugging code. And when errors happen, they generally feel closer to “this is wrong here” rather than “somewhere inside the macro maze.”

Error handling without ceremony: make failure a first-class path

Zig’s error handling is one of its most distinctive design choices. It’s explicit, but it’s not wrapped in a thicket of ceremony. When a function can fail, that fact is represented, and callers must deal with it—either by handling it, transforming it, or bubbling it up.

In practice, this leads to fewer “mystery returns.” Instead of returning sentinel values like -1 or NULL and hoping the caller remembers the contract, Zig pushes the contract into the signature. The result is code that reads like a conversation: “here’s what can go wrong, and here’s what I do when it does.”

Consider a typical scenario in systems tools: parsing a config file, allocating buffers, and then calling into an OS API. In many languages, those failure modes get collapsed into either exceptions (sometimes too global) or error codes (sometimes too easy to ignore). Zig encourages a middle road: propagate errors when you can, handle them when you must.

For teams, this matters. Error paths are not an afterthought; they become part of the control flow you review during code review. That alone can reduce production incidents—even when you’re doing “unsafe” low-level work—because your “what if it fails” statements are no longer optional.

Memory control you can actually live with

Zig’s approach to memory is direct. You don’t get implicit garbage collection, and you don’t get Rust’s ownership constraints everywhere. Instead, Zig gives you allocators as explicit parameters and patterns you can adopt consistently across a codebase.

This is a big part of why Zig appeals to C developers who are tired of repeating the same manual checks, but also tired of fighting Rust’s rules for certain workflows. Game engines, embedded systems, performance-critical real-time components, plugin architectures—these can all involve patterns where strict ownership can be awkward or expensive to contort around.

A practical example: suppose you’re building an asset pipeline that loads models and textures, then stores them in an arena allocator for the duration of the program. In Zig, you can thread an allocator through your loader functions, decide the allocation strategy at the boundary, and keep your internal code honest. You can even use different allocators per subsystem (arena for long-lived data, page allocator for transient buffers) without pretending that one allocator model magically fits everything.

The key is that Zig’s memory model doesn’t try to “save you” by hiding complexity. It helps you handle complexity.

And importantly: you can test that complexity. Because memory management is explicit, it’s straightforward to plug in debug allocators in tests, catch leaks and misuse early, and keep production behavior predictable.

Cross-compilation that targets reality, not a demo

Zig’s build system is designed for practical cross-compilation. If you’ve ever tried to cross-compile a non-trivial C/C++ project and spent days debugging platform quirks, you already appreciate what Zig is trying to reduce: the “works on my machine” tax.

Zig’s tooling makes it more natural to produce binaries for different targets from the same codebase, including cross-compiling to architectures you don’t run locally. For teams delivering to embedded targets, containerized environments, or multiple CPU architectures, this can be a decisive advantage.

Practically, this means you can structure projects with target-specific knobs while keeping the core logic shared. Build scripts can express the configuration clearly, rather than scattering it across fragile Makefile incantations and undocumented environment variables. The goal isn’t just compilation—it’s reproducibility.

A good strategy is to define your “platform contract” early: what syscalls or libc assumptions you’re making, what alignment rules apply, and what ABI expectations you’re relying on. Then let Zig’s build configuration keep those decisions explicit and versioned.

Trust the programmer: the “right” philosophy for certain projects

Zig’s positioning is not subtle: it’s a language that assumes competent programmers will make sensible choices, and it gives them the tools to do so without relying on compiler enforcement everywhere. That can sound risky—until you notice how Zig tries to compensate. It keeps the sharp edges visible. It prefers clear control flow over magical behavior. It makes compile-time generation understandable via real code.

This philosophy fits specific project types extremely well:

Low-level libraries where you want predictable performance and explicit memory behavior, and where enforcing ownership would be more constraining than helpful.
Tooling and infrastructure where clarity and portability matter, and where error handling needs to be disciplined without turning every function into a novel.
Embedded and systems-adjacent code where you might be mapping to hardware resources and need a direct language-level handle.

In these contexts, Zig offers something compelling: fewer “language fights.” You spend less time wrestling the compiler’s model of your intent, and more time expressing the system you’re building.

That doesn’t mean Zig is universally “better.” If you crave Rust’s strongest invariants—especially around complex shared ownership and concurrency—Rust may still be the better bet. Zig’s win is in flexibility and readability of low-level intent, with compile-time power that doesn’t feel like a detour.

Conclusion: Zig is the pragmatic third option in 2025

Zig’s case in 2025 isn’t that it’s safer than everything else or that it replaces Rust or C. It’s that it offers a deliberate middle path: C-level control, explicit failure and memory decisions, and a compile-time system that behaves like real code. For teams that want fewer footguns than C provides, but also don’t want Rust’s ownership model to dictate architecture, Zig can be the right trade.

If you’re building systems software where performance, portability, and clarity matter—and you want the compiler to assist rather than fully govern—Zig is worth serious consideration this year.

Model Context Protocol: The Standard That Makes AI Agents Work

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 18 Jan 2025 00:00:00 +0000

AI agents don’t fail because they “can’t think.” They fail because they can’t reliably act: fetch the right data, call the right tools, and do it in a way you can trust. For years, the bottleneck wasn’t intelligence—it was integration. Model Context Protocol (MCP) is quickly becoming the answer, offering a universal way for large language models to connect to external tools and systems. If REST made web APIs boringly interoperable, MCP is doing the same for agent tool use.

The integration problem AI keeps tripping over

Most “agent” demos look impressive because they’re built on a stack that’s invisible to the user: custom wrappers, hand-written tool schemas, special-case authentication, bespoke adapters for each service. That’s fine for a prototype. It’s a nightmare for a product.

Here’s what usually goes wrong:

Tool definitions don’t travel. Every LLM integration ends up with its own format for “here are the tools you can call.”
Context is inconsistent. Agents may retrieve data in different ways depending on the tool, causing unpredictable behavior.
Auth and permissions are brittle. Connecting to Slack, GitHub, databases, or ticketing systems often requires custom OAuth flows and environment-specific hacks.
Maintenance becomes an identity crisis. Add one new capability (say, “read from Postgres”) and you rewrite integration glue.

The result is a fragmented ecosystem where every new model or agent framework risks breaking existing tooling—or forcing developers to duplicate effort across integrations.

MCP attacks this at the root: instead of building bespoke tool adapters for every LLM, you build once—against a standard protocol.

What MCP is, in plain terms

Model Context Protocol is a standard way for LLM clients (the “agent runtime”) to talk to tool and data providers via MCP servers. Think of MCP as a contract for tool use:

MCP server: Exposes capabilities—tools, resources, and structured actions—over a consistent interface.
MCP client: Connects to one or more MCP servers and lets the model invoke those capabilities.

In practice, that means an agent can connect to a GitHub server, a Slack server, and a Postgres server using the same underlying mechanism. The model doesn’t need a unique integration strategy per service. It needs the tools that are available—and MCP gives you a uniform way to describe them.

The “context” part matters too. MCP isn’t only about calling functions. It’s also about giving the model a consistent pathway to retrieve relevant information (resources) from external systems so the agent can decide what to do next.

Before MCP: bespoke toolchains and fragile glue

To appreciate why MCP matters, you need to see the old workflow.

Imagine you’re building an internal agent for engineers. You want it to:

Query issues in GitHub.
Read or post messages in Slack.
Pull deployment metadata from a Postgres database.
Maybe also check CI status and open a ticket.

Before a standard, you typically write separate integrations like:

A GitHub “tool wrapper” that maps model intent into GitHub API calls.
A Slack wrapper handling message formatting, channel selection, and permissions.
A database wrapper converting SQL requests into safe queries (or, worse, running raw queries).
A bespoke orchestration layer that manages auth tokens and error handling.

Now add new models or new agent runtimes. Even if they’re both “LLM clients,” they may expect different tool schemas, different calling conventions, or different streaming patterns. You end up maintaining N×M glue code: tools times clients. That slows down iteration and makes reliability worse, because every edge case is a custom one.

MCP is the pivot: you standardize the interface between clients and servers. The tools become reusable building blocks.

After MCP: servers turn capabilities into plug-and-play modules

The most pragmatic way to understand MCP is to treat MCP servers as reusable capability packages.

Suppose you’re building a support engineer copilot. You don’t want to write a custom “read from Jira” tool schema from scratch every time. With MCP, you can point your agent runtime at an MCP server that already exposes Jira capabilities in a consistent format.

Even the examples in common ecosystems follow the same pattern: there are MCP servers for mainstream platforms like GitHub, Slack, and PostgreSQL, and the community has expanded far beyond that. The key isn’t the specific services—it’s the repeatable integration mechanics.

Here’s a concrete, product-minded scenario:

Your agent receives a request: “Find the latest deployment failures and post a summary to #incident-response.”
Your MCP-connected agent runtime:
- Calls the Postgres server (or a CI/status server) to fetch relevant failure records.
- Calls the GitHub server to link failures to commits or issues (if needed).
- Calls the Slack server to post the summary using the correct channel and formatting rules.
Your application doesn’t re-learn each service’s calling conventions because MCP normalizes the interface.

This is exactly what developers wanted from web APIs with REST: one consistent style for how clients talk to servers. MCP brings that “boring interoperability” to agent tool use.

Designing robust agents with MCP (not just demos)

Standardizing tool access is a major step—but it’s not a magic wand. The difference between a demo and a dependable product is guardrails and operational discipline.

Here are practical ways to build robustness on top of MCP:

1) Treat tools like production endpoints, not suggestions

Even with MCP, you still need to define clear tool behavior:

Prefer read-only tools by default.
Require explicit user confirmation before write actions (e.g., “post to Slack,” “open a PR”).
Use structured inputs with validation so the model can’t “guess” parameter formats.

2) Make permissions explicit and least-privilege

MCP servers will likely run with tokens/credentials. Don’t overload them.

Separate credentials for read vs write.
Scope tokens to specific repositories, channels, or database schemas.
Audit what the agent can do if a prompt injection tries to trick it into calling a write tool.

3) Normalize your “data contract” with resources

Agents perform better when the retrieved context is predictable. If an MCP server returns resources in a consistent structure—like “issue summary + status + last updated timestamp”—the agent can reliably decide next steps.

A simple win: design your internal MCP servers so they return compact, model-friendly payloads rather than dumping raw API responses.

4) Add tracing at the protocol boundary

When something goes wrong—wrong tool called, wrong parameters, missing context—you want visibility.

Log:

which MCP server was invoked,
which tool/action was called,
the request/response metadata (careful with secrets),
timing and failure reasons.

This makes your agent debuggable, which is what you’ll need once usage grows beyond internal testing.

5) Compose multiple servers into a workflow, not a single “god tool”

It’s tempting to create one “Everything” MCP server that handles all integrations. Resist that.

Instead:

Let each server own its domain (GitHub, Slack, Postgres).
In your agent logic, orchestrate them deliberately.
This makes it easier to swap providers and reduces blast radius when a single integration breaks.

Where MCP fits in your architecture today

So when should you bet on MCP? If you’re building anything that needs to call external systems—especially if you expect those systems to change—MCP is the kind of decision that prevents future rewrites.

Use MCP when:

You’re integrating more than one external system (almost everyone is).
You want to reuse tool capabilities across different agent runtimes or model choices.
You plan to add new tools over time without turning your codebase into a museum of custom adapters.

You still have to choose the rest of your stack—agent runtime, orchestration layer, security model—but MCP reduces the surface area where integrations become bespoke and fragile.

The opinionated takeaway: MCP should be your default integration layer for tool access, not a “nice-to-have” experiment. Standards are only valuable when you commit to them early enough to prevent fragmentation.

Conclusion: The standard that turns agents into software

AI agents are finally becoming practical, but not because models got smarter overnight. They’re becoming practical because the ecosystem is converging on shared interfaces for tool use. MCP does for agent integrations what REST did for web APIs: it gives developers a consistent, reusable contract so capabilities become modular instead of bespoke.

If you’re building AI-powered applications that need to connect to real systems—code, messaging, data, workflows—MCP isn’t just worth tracking. It’s the integration foundation you’ll be glad you chose when your next feature request doesn’t turn into a rewrite.

The Year of the AI-Augmented Developer

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 12 Jan 2025 00:00:00 +0000

In 2025, “writing code” quietly stops meaning the same thing it did a year ago. The fastest hands will still matter—but the decisive advantage is shifting to a different skill set: defining the problem with precision, directing an agent toward the right solution, and catching the failure modes before they become incidents.

The most important change isn’t that AI can generate code. It’s that AI can participate in an end-to-end workflow—inside the IDE, against your repo, and against your standards—while you stay responsible for correctness, security, and design.

AI in the IDE: from autocomplete to collaborators

For years, developer tooling treated AI like a suggestion engine: one line here, a refactor there. In 2025, that boundary is dissolving. Major IDE experiences are folding AI features directly into the editor loop: explain this file, generate tests, propose a migration, summarize a PR, and even execute multi-step plans across multiple files.

If you’ve used tools like GitHub Copilot, Cursor, Windsurf, or Zed AI, you’ve probably noticed the pattern: the “agent” isn’t only writing. It’s reasoning through context you provide—sometimes by reading the codebase, sometimes by asking clarifying questions, and often by proposing a set of edits that look plausible at first glance.

That’s why this year feels different. The bottleneck is no longer raw typing speed or even syntax knowledge. It’s intent. The agent can crank out boilerplate quickly, but it can’t reliably infer what you meant when your requirements are incomplete, your constraints are implicit, or your architecture decisions live in your head.

Practical takeaway: Treat AI as a fast subordinate, not an autonomous authority. You set direction. The IDE assistant executes.

The new advantage: problem definition beats problem execution

The developers thriving in this moment aren’t the ones who type fastest. They’re the ones who make the agent’s job easy—by turning vague requests into crisp engineering tasks.

Consider two prompts for the same feature:

“Add caching to this endpoint.”
“Add an in-memory cache to GET /v1/orders keyed by userId. Cache TTL: 60 seconds. Invalidate on POST /v1/orders for that user. Preserve existing response shape. Add unit tests for cache hits/misses and concurrency behavior.”

The second version is what an agent needs: explicit constraints, acceptance criteria, and where to look. Notice the difference: it’s not just describing behavior, it’s specifying failure boundaries.

Now look at code review. In a normal workflow, you review the diff. In an AI-augmented workflow, you also review the specification you gave the agent. If the spec was sloppy, the diff will be, too—only faster.

Practical takeaway: Before you generate, write a mini “engineering contract” in plain language. Then ask the AI to implement against that contract.

Critical review becomes the primary engineering skill

When AI starts producing multi-file changes, the review job changes shape. You still inspect code—but you also audit assumptions.

Here are common “looks right, is wrong” categories to train yourself to catch:

Boundary mistakes
Off-by-one logic, incorrect pagination semantics, wrong time zone conversions, or mishandled empty states. Agents often handle the “happy path” well and miss the edges unless you force them to.
Security drift
Authentication checks may be omitted in one route. Authorization logic might be inconsistent with existing patterns. Input validation can become “best effort.” The agent is optimizing for completion, not for threat modeling.
Inconsistent architecture
The AI may introduce a new abstraction where none exists, or use an established one incorrectly. It might also refactor code while preserving behavior—except the behavior includes subtle performance characteristics you didn’t mention.
Test theater
Generated tests can be brittle, duplicate existing coverage, or assert the wrong invariants. You want tests that lock down intent, not just that pass.

A sharp workflow is to review in layers:

Spec layer: Did the changes match the requirements you wrote?
Safety layer: Any security or data integrity concerns?
Correctness layer: Edge cases and invariants.
Maintainability layer: Naming, structure, and alignment with existing conventions.

Practical takeaway: Don’t skim AI code like it’s just another PR. Review it like it’s a draft authored by someone who didn’t live with your system for years.

Architectural judgment scales upward, not sideways

The profession isn’t shrinking; it’s stratifying. The floor rises because AI handles a lot of boilerplate—CRUD scaffolding, routine test creation, repetitive formatting, mechanical refactors, and documentation drafts. The ceiling rises faster because humans remain the only reliable source of architectural judgment in ambiguous situations.

AI can propose patterns. It can even justify them. But it can’t truly “feel” the long-term shape of your product, your operational constraints, and your team’s maintenance realities. That’s where senior developers become disproportionately valuable:

choosing boundaries and data ownership
designing failure modes (timeouts, retries, backpressure)
establishing invariants across services
deciding what not to automate
orchestrating migrations without breaking production

A concrete example: “refactor for cleanliness” isn’t a plan

Imagine you ask an AI to “refactor the payment module for clarity.” It may produce cleaner functions and better naming. But if it also changes call graphs, introduces subtle ordering dependencies, or alters transactional semantics, you’ve traded readability for risk.

Instead, a more senior framing looks like:

“Extract a payment authorization interface without changing transactional boundaries.”
“Keep idempotency behavior identical.”
“Add integration tests for rollback scenarios.”
“Stage the refactor behind a feature flag.”

You’re still letting the agent do work—but you’re putting guardrails around the decisions that must be yours.

Practical takeaway: Use AI for execution. Reserve architecture for judgment.

Designing systems that agents can modify safely

Here’s the uncomfortable truth: agents will modify your repo whether you’re ready or not. The winners will be the teams that make their codebases easier to edit safely.

You can “agent-proof” a system without building a fantasy future of autonomous software. The goal is simple: make intent legible, reduce hidden coupling, and centralize policies.

Practical steps:

Create clear module boundaries
If authorization rules are scattered, an agent will eventually miss one. Centralize those rules, and document the contracts.
Codify invariants
Examples: “All domain IDs must be validated at entry,” “All writes must be idempotent,” “Every API response must include correlation IDs.” Encode these in shared utilities and test fixtures, not in tribal memory.
Make style and structure predictable
Consistent naming, standard folder layout, and established patterns reduce the chance the agent invents a new way to do the same thing.
Invest in high-signal tests
Not every test needs to be generated. But when agents change behavior, you want fast tests that catch violations immediately—especially around authorization, parsing, and concurrency.
Use review checklists for AI-generated diffs
For example:
- “Did we update authz/authn in every affected route?”
- “Are serialization formats unchanged?”
- “Are we preserving idempotency keys?”
- “Do we handle null/empty edge cases?”

Practical takeaway: Your best defense against incorrect AI edits is not distrust—it’s structure.

Working with agents in real projects: a disciplined loop

You don’t need a new philosophy—you need a better loop. Here’s a pragmatic workflow many strong teams are converging on:

Write a spec you can test
Include acceptance criteria, error handling expectations, and non-goals.
Ask for a small first change
Don’t request a full rewrite. Generate a minimal diff that proves the approach.
Review the diff and the reasoning
If the tool offers a plan, evaluate it. If it doesn’t, force the output to explain assumptions.
Add or adjust tests before widening scope
Make it safe to iterate. Generated code without tests is just faster risk.
Repeat with tighter constraints
Once you see how the agent interprets your instructions, sharpen the next prompt and limit the next edit.

If you want a litmus test: if your prompt doesn’t mention failure modes, invariants, or constraints, you’re not directing an agent—you’re outsourcing ambiguity.

Practical takeaway: Treat each AI-assisted change like a contract negotiation: clarify, verify, then expand.

Conclusion: the floor rises, and the ceiling rises faster

2025 will not reward the people who can produce code at maximum speed. It will reward the people who can produce clarity: crisp requirements, thoughtful architectures, and ruthless reviews of AI output. The floor is rising as agents eliminate boilerplate. The ceiling is rising as humans handle ambiguity, responsibility, and system-level judgment.

If you want to stay competitive, don’t just learn which button to click in your IDE. Upgrade your engineering habits: specify better, test more intentionally, and architect with the assumption that AI will be editing right alongside you.

AI Agents Are Coming for Your Workflow, Not Your Job

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 06 Jan 2025 00:00:00 +0000

For years, AI in software has felt like a productivity accessory: a smarter autocomplete, a helpful chat, a quicker way to draft boilerplate. That era is ending. The real shift isn’t “AI replaces developers.” It’s “AI starts replacing the workflow steps you’ve been manually babysitting.” And the moment you realize that, you’ll stop asking whether agents are useful—and start asking how to deploy them safely.

The evolution from assistants to agents is the biggest architectural change since microservices. Not because it’s flashy, but because it changes how work is structured: from single-shot answers to delegated, multi-step execution.

From autocomplete to delegation

Autocomplete guesses the next token. Assistants respond to your prompt. Agents do something different: they decide what to do next, run it, and correct course when reality disagrees.

In practice, coding agents behave less like a “chat partner” and more like an operator who can:

plan a task (e.g., “fix failing tests and update docs”),
execute commands (run tests, lint, build),
inspect outputs (parse error logs, check diffs),
iterate (apply changes, re-run, repeat),
and report back with concrete results.

This loop matters. Most teams don’t lose time because code is hard to write; they lose time because code fails in the real world—CI breaks, dependencies shift, edge cases appear, formatting policies kick back, tests flare up with cryptic stack traces. Agents are designed to live inside that friction.

A simple way to think about it: if assistants help you write code faster, agents help you finish work.

The “workflow graph” becomes the product

Microservices changed architecture by turning one big system into many independently deployable pieces. AI agents are doing something similar to how developers think about work.

Instead of a workflow that looks like:

you write code,
you run tests,
you debug failures manually,
you repeat,

you get a workflow graph where an agent can traverse steps automatically:

determine the scope,
open the relevant files,
modify code,
run targeted tests,
read the failure output,
change strategy,
re-run until it meets acceptance criteria.

Here’s the concrete example that tends to land: a PR request comes in with “tests are failing in CI.” An agent can:

reproduce locally,
run the smallest failing test subset,
locate the exact failing assertion,
patch the underlying logic,
re-run the full suite,
update any affected snapshots or docs,
and summarize what changed and why.

That’s not magic; it’s execution + feedback. And once you can rely on loops, you can start treating “test-driven development” as something more like “test-driven iteration,” where the iteration part is automated.

Real tools—and the patterns behind them

Tools like Claude Code and GitHub Copilot CLI (plus various open-source alternatives) are already pushing this behavior into day-to-day development: code generation that can actually run commands, inspect errors, and try again. The names vary, but the architectural pattern is consistent:

Context ingestion: read your repo, relevant files, and recent changes.
Action planning: decide what commands and edits to attempt next.
Execution sandboxing: run tests, linters, or build steps.
Observation: capture logs and interpret failures.
State management: keep track of what was tried and what worked.
Termination criteria: stop when the definition of done is met (tests pass, checks pass, or an explicit threshold is reached).

This is why the “assistant vs agent” distinction is more than marketing. An assistant can help with code snippets. An agent can operate on the repo as a living system.

Practical advice: design for agent-friendliness

If you want agents to work well, your repo can’t be a black box. You’ll get better results by doing the unsexy hygiene work that also benefits humans:

Ensure make test / npm test / pytest runs quickly and deterministically.
Keep scripts documented and discoverable.
Prefer meaningful error messages (fail fast, don’t swallow stack traces).
Make the CI output legible enough for an agent to interpret (clear failing test names, useful logs).
Add “golden” commands in your docs: “run these to reproduce.”

Think of it as DevEx for machines.

The DevOps analogy is real (and useful)

Here’s the opinionated truth: managing AI agents is starting to look like DevOps container management. You’re not just “using a tool”—you’re orchestrating a fleet.

In DevOps, you learned to ask:

What runtime environment?
What permissions?
What observability?
What happens when it fails?

With agents, you need the same instincts.

Permissions and blast radius

A coding agent that can edit your entire repo is powerful. It should also be constrained.

Practical guardrails:

Run in a controlled environment (container, ephemeral workspace, or at least isolated branch).
Use least privilege: don’t let the agent access secrets it doesn’t need.
Require changes go through a PR flow, not direct merges.
Make the agent operate on a branch and let CI be the final arbiter.

Observability: logs are your ground truth

Agents will sometimes “sound confident” while making incorrect assumptions. Your defense is instrumentation:

Capture the commands the agent ran.
Store diffs it attempted.
Save the failing logs it used to decide next steps.
Track iteration counts to prevent runaway loops.

When you can review an agent’s decision trail, you can improve prompts, tighten constraints, and debug failures like any other automation.

How developers adapt: shift from craft to orchestration

Let’s address the fear head-on: yes, some tasks will shrink. The junior developer who spends their day writing boilerplate and chasing simple failures will feel it first. But the bigger transformation is that developer skill shifts upward.

Instead of “I can write the code,” the new differentiator is “I can direct an automated workflow to the correct outcome.”

That includes:

writing clear acceptance criteria (“tests pass,” “lint is clean,” “performance regression not introduced”),
decomposing work into an agent-executable plan,
shaping prompts to reduce ambiguity,
curating the context an agent uses,
and reviewing results with an expert eye.

If you’ve ever reviewed a teammate’s PR, you already have the muscle. AI just changes the ratio: you’ll review more, but the changes will often be more mechanical—and the stakes are higher because automation can produce large diffs quickly.

Concrete example: directing an agent to fix a regression safely

Suppose a service starts failing with a new error after a dependency update. Instead of saying “fix it,” you can instruct:

“Reproduce failure locally.”
“Run integration tests first; only run full suite if they pass.”
“Patch the smallest surface area to restore behavior.”
“Add or update tests that cover the regression.”
“Stop when CI checks pass and include a summary of changes.”

You’re not micromanaging. You’re setting a safe boundary and a stop condition.

That’s orchestration: giving the agent enough structure to be effective without turning it loose.

The hard part isn’t technical—it’s organizational

The biggest challenge teams face isn’t whether agents can run tests. It’s whether your process can absorb autonomous iteration.

Start small:

Pick one workflow step that’s repetitive and well-instrumented (e.g., fixing failing tests, updating documentation formatting, triaging build errors).
Gate it behind CI and PRs.
Measure outcomes with human review (time-to-merge, number of failed attempts, diff size).
Expand scope once you trust the loop.

Then align incentives. If an agent produces 20 commits for a single fix, developers will lose patience and revert to manual work. If the agent only runs the right commands and stops cleanly, adoption becomes a no-brainer.

And don’t ignore policy. Decide what agents can do with:

external network access,
dependency changes,
secret handling,
license-sensitive operations,
and code ownership boundaries.

This isn’t bureaucracy—it’s how you keep velocity without burning trust.

Conclusion: your job isn’t disappearing—your workflow is being rewritten

AI agents aren’t coming for your job; they’re coming for your workflow. The shift from assistants to agents turns software work into a loop: plan, execute, observe, iterate. Developers who adapt will manage agent-powered automation the way DevOps engineers managed containers—confidently, with constraints, observability, and clear acceptance criteria.

The ones who don’t will keep doing manually what their peers will accomplish in minutes. The only question left is whether you’ll be the person orchestrating the new architecture—or the person stuck doing the old work in the margins.

The Tech I'm Watching in 2025

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 22 Dec 2024 00:00:00 +0000

Every year has its hype cycles, but 2025 feels different: the conversation is shifting from “can we build cool demos?” to “can we ship reliable systems that keep working when the novelty wears off?” This is the year I’m watching for tools and frameworks that move from prototypes to infrastructure—especially in AI integration, developer productivity, and the boring parts of reliability nobody wants to own.

Here’s my 2025 watchlist: AI agents that truly chain tasks autonomously, Anthropic’s Model Context Protocol as a universal integration layer, Zig gaining momentum as an accessible systems language, Effect-TS bringing algebraic effects to mainstream TypeScript, PostgreSQL’s pgvector pressuring standalone vector databases, and the perennial question: will Rust finally break into mainstream web development?

1) AI agents that can chain tasks without faceplanting

The headline in 2025 isn’t “AI.” It’s execution. The agents I’m watching are those that can take a goal, decompose it into steps, call tools, check their work, and continue until completion—without constantly asking the user what to do next.

What separates real agents from toy demos? Three things:

1) Deterministic control around non-deterministic models.
If an agent delegates everything to a model, it will eventually drift, loop, or hallucinate tool parameters. The stronger pattern is to keep the model responsible for reasoning and selection, while the system owns workflow and state. For example: represent tasks as a graph, track completed steps, and enforce “only call tool X with schema Y.”

2) Tool contracts and validation.
A practical agent treats tools like APIs, not suggestions. Use strict schemas for inputs/outputs; validate responses; reject malformed results; and have fallback strategies. If your agent can’t parse a JSON response from a tool reliably, it doesn’t get to proceed.

3) Persistent memory with guardrails.
Agents need context—previous steps, user preferences, project state. But memory shouldn’t become a dumping ground. In practice, you’ll want layered context: session state (ephemeral), task state (durable for the current run), and user profile (long-lived). And you should be able to inspect or clear it when things go wrong.

A concrete example: an “ops assistant” agent that handles incident triage. In a good design, it doesn’t just ask ChatGPT to “look at logs.” It:

Pulls recent errors from your log tool (via a tool call).
Extracts key symptoms (model reasoning).
Queries runbooks (retrieval tool).
Proposes a short plan with explicit steps and expected outcomes.
Executes safe actions (restart service, increase log level) with confirmation gates.
Writes a postmortem draft with sources.

In 2025, I’m placing bets on agents that earn trust through control, not vibes.

2) MCP: the integration layer that could replace the glue code

If agents are the execution engine, the integration layer is the plumbing. That’s why I’m watching Anthropic’s Model Context Protocol (MCP) as the most promising “universal adapter” approach in the AI tooling ecosystem.

The core idea is simple: define a standard way for model clients to connect to external tools and data sources through consistent capabilities and message semantics. In other words, MCP aims to reduce the “N adapters for N tools” problem—where every new model or agent framework forces you to rewrite integrations.

Here’s what MCP changes in practice:

Tool portability. A tool exposed via MCP becomes available to multiple clients without bespoke wiring each time. If you’ve ever built a custom connector to a single agent framework, you know how fast that turns into maintenance debt.
Cleaner separation of concerns. Your “tool server” focuses on exposing capabilities, authentication, and data shaping. Your “agent” focuses on orchestration and reasoning.
Composable context. Instead of stuffing everything into prompts, clients can request structured context from multiple providers with less chaos.

If you’re building with an eye toward 2025 stability, don’t just evaluate MCP as a protocol—evaluate it as an organizational strategy. Start by:

Selecting 2–3 high-value integrations you already use (e.g., ticketing, docs, internal APIs).
Exposing them behind MCP with strict schemas.
Plugging them into one agent workflow end-to-end.
Measuring the reduction in integration churn across framework changes.

My bet: MCP becomes a default path for integrations, not because it’s trendy, but because “standard adapters” win over time.

3) Zig’s momentum: systems programming you can actually approach

Zig has been inching forward for years, but what I’m watching in 2025 is whether it becomes a default choice for production-adjacent systems components—not just a hobbyist darling.

What’s the practical appeal? Zig sits in an interesting middle ground: lower-level control without the complexity tax that often comes with C/C++ toolchains, and a growing ecosystem that’s good enough for serious work. The language also encourages explicitness: when you care about memory, error handling, or build behavior, Zig tends to make that visible rather than hiding it behind conventions.

Where I think Zig can land in mainstream engineering:

Performance-critical services that need predictable behavior and minimal runtime overhead.
CLI tools and infrastructure utilities where correctness and deployability matter more than flashy abstraction.
Interop layers between languages (think: “a small fast core” with a stable API surface).

A concrete “reasonable Zig project” in 2025: a fast log processor that:

Streams files or stdin.
Parses structured logs with minimal allocations.
Outputs normalized JSON for downstream indexing.
Produces stable exit codes and error messages for automation.

If you can wrap that as a standalone binary with predictable cross-compilation, you’ll feel Zig’s value immediately. The test is not whether Zig can do everything—it’s whether it can do the kind of work teams keep shipping every week.

4) Effect-TS in TypeScript: algebraic effects for the rest of us

TypeScript is the default language for a reason: it’s pragmatic and reachable. But error handling, side effects, retries, timeouts, and cancellation can turn even clean codebases into spaghetti. Effect-TS is one of the more compelling attempts to fix that, bringing ideas from algebraic effects into the TypeScript world.

I’m watching Effect-TS in 2025 because it tackles a real pain:

Error handling becomes consistent and composable.
Side effects become explicit and testable.
Resource management (like acquiring/releasing) can be modeled rather than “remembered.”

A practical framing: instead of sprinkling try/catch and ad-hoc retry logic across your app, you build workflows where:

Each effect (HTTP call, DB access, cache lookup) is modeled explicitly.
Dependencies are injected through the effect environment.
You can test a workflow by swapping real effects with deterministic test doubles.

A common integration scenario: a checkout-like flow that needs to call multiple services with strict rules. With effect-style programming, you can express “if payment fails, don’t attempt fulfillment; if fulfillment fails, trigger compensation; always release resources.” That’s the kind of logic that otherwise becomes fragile across a tangle of promises and control flags.

If you’re curious, don’t start by rewriting your whole app. Start by isolating one workflow with meaningful side effects—say, “create order + reserve inventory + confirm payment”—and model it using Effect-TS patterns. The goal isn’t purity. It’s reducing the number of ways your system can fail silently.

5) pgvector pressures standalone vector databases

Vector search is no longer a novelty feature; it’s showing up everywhere—from semantic search in docs to recommendation systems and retrieval-augmented generation. The question for 2025 is whether teams need a separate vector database, or whether the mainstream database stack can carry the load.

That’s where PostgreSQL’s pgvector is interesting. The practical advantage of using a database you already run is operational simplicity:

One authentication and access pattern.
One backup/restore story.
One schema migration workflow.
One place to reason about queries and data consistency.

Does that mean standalone vector databases disappear? Not necessarily. There are workloads where a dedicated system makes sense—especially at high scale or where specialized indexing and retrieval features offer real benefits.

But the momentum I’m watching is different: more teams will prototype and ship vector-backed features using pgvector because it lowers the barrier to production. If you can do semantic search with PostgreSQL tables, and your latency/throughput needs aren’t extreme, you avoid the “second operational universe.”

A concrete decision rule for 2025:

If your data already lives in Postgres, and your retrieval requirements are within reasonable bounds, start with pgvector.
If you later hit limitations (indexing cost, scaling strategy, or specialized filtering), migrate to a dedicated engine with a clean abstraction around the retrieval interface.

This is how you prevent vector search from becoming a permanent architectural tax.

6) Will Rust break into mainstream web development?

Rust has been “one year away” from mainstream web development for a long time. Still, I’m watching 2025 closely because the language is mature enough now that the conversation can shift from “can Rust do it?” to “can Rust do it with tolerable ergonomics and ecosystem support?”

Mainstream web adoption hinges on a few factors:

Framework and tooling maturity. Developers need a comfortable path for routing, middleware, templating or APIs, and deployment.
Ergonomics for the web’s reality: async IO, streaming bodies, cookies, auth, and JSON handling.
Interoperability. Web stacks rarely live in isolation; they integrate with Node tooling, CI systems, and sometimes legacy services.

What I’d look for in 2025 isn’t a universal Rust takeover. It’s more nuanced:

More production deployments of Rust backends in teams that value reliability and performance.
Better “batteries included” workflows that reduce friction for newcomers.
Clear patterns for integrating Rust services with existing TypeScript frontends and infrastructure.

My bet? Rust continues to grow where correctness and performance matter and where teams are willing to invest in a stable backend foundation—even if it never becomes the default for every web app. But it could become common enough that “Rust backend” stops sounding like a contrarian move.

Conclusion: the 2025 winners will feel boring in the best way

The most exciting tech in 2025 isn’t the flashiest feature—it’s the infrastructure that makes systems dependable: agents that chain tasks with control, MCP that reduces integration sprawl, Zig that makes systems work approachable, Effect-TS that makes side effects manageable, pgvector that keeps vector search grounded in standard operations, and Rust continuing its slow march into everyday backend work.

Place your bets. Just bet on the things that help you ship—and keep shipping—without rewriting your glue every time the ecosystem shifts.

2024: The Year AI Became Infrastructure

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 10 Dec 2024 00:00:00 +0000

In 2024, AI didn’t “get smarter” in some magical, headline-grabbing way—it got useful in a way that changed how teams build. The result: what used to be a demo became plumbing. The biggest shift wasn’t just technology; it was mindset. Developers stopped asking, “Can we do this with AI?” and started asking, “How do we operationalize it safely, cheaply, and reliably?”

RAG stopped being a research idea and became the default architecture

If there was a single enterprise pattern that won in 2024, it was RAG—retrieval-augmented generation. Not because it’s perfect, but because it’s accountable. When your AI answers from company documents, the system can be designed around citations, access controls, and retrieval policies. That matters when you’re moving from “chat” to “workflow.”

A practical way teams adopted RAG: they stopped treating it like a clever prompt trick and started treating it like a pipeline.

Ingest: chunk documents intelligently (respecting headings, tables, and sections), deduplicate, and tag content by tenant, domain, or product line.
Retrieve: use embeddings plus filtering (permissions, language, recency, customer segment). Retrieval isn’t just vector similarity; it’s “what’s allowed” and “what’s relevant.”
Generate: constrain the model to the retrieved context; require “I don’t know” behavior when retrieval is weak.
Evaluate: measure answer correctness against a test set tied to real tasks, not just “sounds good” examples.

The biggest win wasn’t the model’s output quality alone—it was the ability to improve outcomes by iterating on retrieval quality. In practice, teams got better by fixing boring stuff: chunk sizes, metadata quality, and query rewriting. That’s the infrastructure mindset: optimize the system, not the magic.

And yes, RAG also made skepticism rational. If the answer is wrong, you can often locate the failure mode: missing documents, poor chunking, bad filters, stale indices, or a prompt that didn’t respect the context. That observability is a forcing function toward reliability.

Open-source models reached “good enough” parity for many jobs

2024 was also the year open-source models became normal business choices. Not universally—some edge cases still favor proprietary systems, especially where tooling, reliability guarantees, or niche capabilities are critical. But for the bulk of day-to-day tasks—summarization, classification, extraction, code assistance, customer support triage—many teams found the trade-offs no longer justify paying the “closed” tax.

Here’s what “parity” looked like in real deployments:

Document processing: extract fields from messy text, normalize formats, and route results to downstream systems.
Customer support: classify intent, draft responses with a retrieval context, and enforce policy constraints.
Developer productivity: generate boilerplate, explain code, and propose diffs—then let tests and linting arbitrate correctness.

The practical takeaway: open-source adoption wasn’t just about licensing. It was about owning the lifecycle. Teams could tune prompts, run evaluations in their own environments, and switch model versions without vendor drama.

But infrastructure doesn’t mean “set it and forget it.” The teams that benefited most treated model serving like any other production dependency: versioned models, staged rollouts, latency budgets, and predictable cost controls. If you can’t measure it, you can’t trust it—especially when models evolve.

Vector databases moved from niche to necessary—because retrieval became mission-critical

Once RAG became the default, vector storage stopped being a “nice to have” and started being a core dependency. In 2024, vector databases went mainstream not because they were trendy, but because retrieval requires persistence, indexing, and performance characteristics you can’t hack together forever.

The infrastructure shift was visible in how teams evaluated vector DBs:

Indexing and update behavior: Can you handle incremental document updates without painful reindexing every time?
Filtering support: Permissions and tenancy aren’t optional. You need metadata-aware retrieval, not just similarity search.
Latency and throughput: If your RAG system times out, the user experience suffers instantly.
Operational tooling: Observability, backups, migrations—things that matter when you have real traffic and real risk.

A common practical pattern: many teams used a hybrid approach even when they called it “RAG.” For instance, they relied on keyword search for exact matches and vector search for semantic similarity, then merged results with a reranker. The “vector database” was only one component of retrieval quality, but it became the backbone that made retrieval reliable at scale.

And reliability exposed a hidden constraint: embeddings are not a stable artifact. Change the embedding model or chunking strategy and your “truth” changes. That forced teams to adopt better data versioning—another infrastructure hallmark.

Docker kept winning quietly—and AI made it even more important

Docker’s story in 2024 wasn’t dramatic. It just worked—so teams kept using it. What AI changed is that containerization became the easiest way to manage a growing stack: embedding generation, retrieval services, reranking, model inference, evaluation harnesses, and observability.

In practice, Docker helped teams standardize environments across:

developer machines
staging pipelines
production clusters
ephemeral evaluation runs

If you’ve ever watched a demo collapse because “it works on my laptop,” you already know why this matters. AI systems amplify environment drift: model versions, CUDA dependencies, tokenization settings, and even subtle library differences can swing outputs.

The infrastructure move: build a repeatable “AI service image,” then pin versions everywhere:

base images
Python/Node dependencies
model binaries or serving endpoints
embedding model versions
prompt and retrieval configuration

Docker didn’t create these best practices—but it made them sustainable.

PostgreSQL expanded its role as the everything-database—and that’s not an accident

The “AI stack” is full of specialized tools, but 2024 reinforced a simple truth: operational data still belongs in operational databases. PostgreSQL won more mindshare as the center of gravity for teams who wanted fewer moving parts and better auditability.

Where PostgreSQL fit particularly well:

Document metadata and permissions: tenants, roles, access rules, document lifecycle state.
Job queues and ingestion tracking: status, retries, and backfills.
Evaluation results: prompts, contexts, model versions, and human feedback signals.
Audit logs: what the system retrieved and why an answer was produced.

When teams paired PostgreSQL with vector storage, it looked less like “AI architecture cosplay” and more like sane engineering:

Postgres tells you what exists and who can access it.
The vector database helps you find similar content.
The inference layer focuses on generating.
Observability ties everything together.

That separation of concerns is the infrastructure philosophy. You keep state where it’s durable and queryable, and you use specialized systems where they’re genuinely superior.

The real shift: skepticism grew—because teams demanded infrastructure-grade trust

The most interesting part of 2024 wasn’t the tech. It was the mood. Developers became more skeptical even as adoption accelerated. That’s a good sign. Skepticism isn’t resistance; it’s quality control.

You saw it in the questions that replaced early “AI hype” prompts:

“What’s the failure mode when retrieval misses?”
“How do we prevent data leaks across tenants?”
“Can we reproduce answers for debugging?”
“What’s our cost per task at peak traffic?”
“How do we evaluate improvements without gaming the metrics?”

Healthy skepticism also showed up in how teams chose to integrate AI into products. Instead of replacing everything with chat, they embedded AI where it adds value with guardrails: drafting, summarizing, extracting, classifying, and assisting. They let deterministic systems handle irreversible decisions—and used AI for reversible, human-reviewed steps when stakes were high.

The best teams treated AI like a living system:

tests for retrieval and generation quality
monitoring for drift and latency
rollback strategies for model updates
clear ownership for the pipeline components

That’s what infrastructure does. It turns uncertainty into manageability.

Conclusion: AI became infrastructure by earning the right to stay

2024 marked the year AI stopped being an experiment and started being infrastructure—because teams demanded systems they could operate. RAG became standard because it connects answers to real data. Open-source models became viable because they delivered enough capability with more control. Vector databases became necessary because retrieval moved from “nice feature” to “core function.” Docker kept things reproducible. PostgreSQL kept things durable.

And through it all, developer skepticism grew—not as a brake, but as a compass. The industry doesn’t need blind adoption. It needs engineering discipline. If 2024 taught anything, it’s that AI becomes infrastructure only when it’s trustworthy enough to be relied on.

Advent of Code 2024: Why Zig Is My Weapon of Choice This Year

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 28 Nov 2024 00:00:00 +0000

Every year I tell myself I’ll do Advent of Code “for fun,” and every year I end up turning it into a stress test for whatever language I’m learning. This year, that language is Zig—and after a few days of solutions, it’s already the most satisfying systems-programming journey I’ve had since first picking up Rust. Why? Because Zig lets me learn by doing the things I usually hand-wave: memory, performance, and compilation behavior. It doesn’t just allow mistakes—it gives you the levers to correct them quickly.

In short: if Rust is the safe-but-strict parent, Zig is the uncle who trusts you with power tools.

The moment Zig “clicked” for me

I didn’t love Zig on day one. It’s not a “read-the-docs and feel smart” language. It’s a “ship the code and feel the consequences” language.

Advent of Code is perfect for that. It’s the same pattern over and over:

Parse some input.
Build data structures (arrays, maps, graphs, bitsets).
Run an algorithm with tight loops.
Debug edge cases under time pressure.

With Zig, you do all of that directly. There’s no magic framework getting in the way, no hidden runtime doing the heavy lifting, and—crucially—no hand-wavy memory model. You see every allocation decision, every buffer lifetime, and every opportunity for efficiency.

The first time I rewrote a parser to use a resizable buffer and an allocator you can actually reason about, it felt like I stopped “coding” and started engineering. That’s the addiction.

Comptime: the “regular Zig code” metaprogramming superpower

Zig’s comptime is the headline feature for me, mostly because it’s not what I expected. I came in thinking it would be another macro system with a syntax tax. Instead, comptime is code execution at compile time—using the same language constructs you already know.

That matters for Advent of Code because you constantly want small variations without rewriting everything:

Different grid sizes
Different neighbor rules
Parsing strategies
Precomputed lookup tables (like direction maps or transition tables)
Specialized data structures for a known maximum size

Here’s what this looks like in practice: suppose you’re working on a puzzle where you need a fixed-size 2D grid. You can write a generic grid routine that compiles into a specialized version for each grid size—without resorting to macro tricks or template gymnastics.

Instead of “macro generates code,” you’re basically saying: “run this logic during compilation so the result can be baked into the program.” And because it’s normal Zig code, you can debug it as you develop it. The mental model is consistent, which is rare in metaprogramming.

My favorite part is that comptime doesn’t force you to use it. You can start with a simple, runtime version and only move “up” to comptime when you actually need it. That’s how you learn the power without turning your early solutions into a compilation-themed art project.

Memory management that’s explicit—but not hostile

Manual memory management is the thing people warn you about with C. Zig does not pretend manual memory management is “free.” It makes it explicit, but it doesn’t try to punish you for knowing what you’re doing.

This is where Zig feels like the “learning-by-doing” language I always want. The allocator system is front and center: you pass an allocator into functions that need memory, you decide what to allocate, and you control lifetimes. If you leak, you’ll know. If you use memory incorrectly, the program can fail loudly—rather than letting undefined behavior quietly corrupt your confidence.

Concretely, Advent of Code often wants a temporary structure: parse input into something, process it once, then discard it. In languages with heavy abstractions, you either allocate more than you need or fight the framework. In Zig, you can pick the right tool for the job.

For example:

Use an arena allocator when you allocate many small objects during parsing and then discard them all at the end of the run.
Use a general purpose allocator when you truly need allocations that come and go.
Keep scratch buffers local so your algorithm stays readable.

A typical pattern looks like this conceptually:

Read input.
Create an allocator.
Parse into data structures that live for the duration of the solution.
Compute answers.
Free everything (or tear down the arena) in one predictable step.

That’s the whole point: memory is a first-class design element, not a hidden tax.

And unlike C, you’re not left guessing which function “probably” frees memory. Zig asks you to be deliberate.

Cross-compilation without ritual

Advent of Code is computer science, but it’s also… platform friction. You often want to run and test solutions across your laptop, maybe a server, maybe a different target architecture if you’re feeling adventurous.

Zig’s cross-compilation is one of the quiet advantages that makes it easier to keep coding instead of managing your environment. The workflow is straightforward: compile for a target in a single command rather than setting up a pile of toolchains and environment variables that you forget how to undo.

In practice, this means I’m more willing to treat Zig as my “single-source of truth” across systems. I’m not just building a solution—I’m building a portable tool. Even if the puzzle runner is local only, that portability mindset is its own reward.

Systems performance you can actually measure

Advent of Code doesn’t demand low-level performance in the way kernel development does, but it absolutely exposes inefficient choices. If your algorithm is sloppy, your runtime or memory will show it. If your parsing is wasteful, it compounds. If your data structures are a poor fit, you’ll feel it when you iterate on the fix.

Zig encourages efficient structure without forcing you into “micro-optimizations forever.” The language gives you:

Predictable data layout for many common patterns.
Clear control over allocations.
The ability to write tight loops without contortions.
Good opportunities to reduce overhead because you’re not fighting the runtime.

This is also where Zig’s comptime can sneak in wins. Precomputing tables or specializing logic for known constants turns repeated work into compile-time computation. That’s the kind of optimization you can add after the solution is correct, not before—which is how optimization should work.

My rule this year: first make it correct and readable, then tighten. Zig supports that workflow unusually well.

How I approach Advent of Code in Zig (so it stays fun)

If you try to “Zig everything” from day one, you can end up writing impressive code that still doesn’t solve the puzzle in time. The key is to use Zig’s strengths in the right order.

Here’s my practical process:

Start with a clean parser.
Get from text to a structured representation fast. Use an allocator you can tear down at the end. Don’t optimize parsing until you need to.
Choose data structures based on the puzzle shape.
If you’re doing grid traversal, keep it simple: arrays and coordinate math beat overengineering. If you’re doing frequency counts, map/set approaches can keep your reasoning clean.
Use debug-friendly checks early.
Zig’s tooling and explicitness make it easier to localize errors. I’ll add temporary assertions that catch off-by-one mistakes in neighbor logic or index math before I waste an hour chasing phantom bugs.
Add comptime only when there’s repetition.
If the solution has repeated patterns with only small differences, that’s your cue. Specialize grid sizes, precompute transitions, or build lookup tables.
Tighten memory last.
If the solution works but allocates too much, switch parsing to an arena allocator or restructure buffers. This is often a small, high-impact change.

And yes, I still keep it sharp and readable. Zig rewards clarity, and you don’t win Advent of Code by producing unreadable wizardry—even if it’s tempting.

Conclusion: Zig makes Advent of Code feel like real engineering

Advent of Code is a strange tradition: it’s competitive, but it’s also educational. This year, Zig is my weapon of choice because it hits the sweet spot between power and understanding. You get explicit memory management without the constant anxiety of unsafe habits. You get comptime without turning your code into a macro labyrinth. And you get portability and performance with minimal ceremony.

If you’ve been itching to learn systems programming the practical way—by building, debugging, and refining—Advent of Code in Zig is an unusually satisfying path. Rust made me careful. Zig is making me confident.

AI-Generated Code Is Creating a Testing Crisis Nobody Talks About

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 16 Nov 2024 00:00:00 +0000

AI coding assistants can make you feel unstoppable: you ask for a feature, it ships in minutes, and your repo fills up with fresh commits that look—mostly—correct. But there’s a quieter problem happening in parallel: we’re generating code faster than we can verify it, and our testing practices are starting to lag behind. The result isn’t just more bugs. It’s a growing verification gap that slowly turns “shipping faster” into “breaking faster with confidence.”

And the most dangerous part? Many teams aren’t noticing until it’s too late, because the failure mode doesn’t look like a dramatic outage. It looks like subtly declining test quality, mysteriously brittle behavior, and a rising backlog of “can’t reproduce” issues that only appear in production.

The Hidden Math: Output Is Rising, Verification Isn’t

When teams adopt AI coding tools, the headline is obvious: you write more code, faster. Fewer blank pages. Less time wrestling with boilerplate. More completed tasks per sprint. That’s real productivity—at least up to the moment you ask the next question: How much verification do those extra lines of code get?

In practice, verification rarely scales linearly. Test suites are expensive to maintain, flaky tests sap trust, and coverage alone can become a hollow metric. When engineers feel pressured to “keep up,” they do what humans do under time constraints: they focus on functionality and treat testing as something you sprinkle on later.

The outcome is an asymmetry:

AI increases production throughput (more code written, faster).
Teams often keep testing effort flat (same number of tests, same review time, same CI budget).
Test coverage can even decline because the new code isn’t exercised, or because tests are rewritten less frequently than application logic.

This is how technical debt accelerates without anyone explicitly deciding to take it on. The debt isn’t just missing tests; it’s missing confidence.

Why LLMs Make the Happy Path Look Like the Whole Story

AI coding assistants are optimized for plausibility and helpfulness, not adversarial thinking. That’s why their code tends to pass the tests we already have—and why it often fails at exactly the places we don’t test.

Consider a common scenario: an LLM helps you implement a “discount” function for an e-commerce app.

You might ask for something like:

Apply 10% discount
Cap discount at $50
Handle null values gracefully
Support percentages as integers

The assistant writes code that satisfies the spec and likely includes common branches. But if your existing test suite only checks “normal” inputs—positive prices, straightforward percentages, expected formatting—you’ve created a runway for the happy path to look solid while the edge cases quietly rot.

LLMs are particularly prone to omissions like:

Boundary mistakes (e.g., inclusive vs. exclusive ranges)
Empty inputs and malformed data (e.g., "", null, unexpected types)
Large values and overflow behavior
State transitions (e.g., retries, idempotency, concurrent updates)
Invariant violations (e.g., “discounted total must never increase”)

It’s not that LLMs “don’t know edge cases.” It’s that they don’t prioritize them. Their defaults are to produce code that fits typical patterns. Edge cases require a different kind of rigor—one that’s harder to automate with simple generation.

The Verification Gap: When Bugs Stop Being Reproducible

A verification gap is what you get when your confidence model breaks. You start shipping code that is only partially validated, and the failures shift downstream.

Here’s what it often looks like:

CI passes more frequently, but production reports increase.
Bug reports become harder to reproduce, because the failure depends on rare input combinations.
Regression testing becomes slower, because each new workaround adds another “special case” that wasn’t specified or verified.
Developers lose trust in the test suite, either because it’s too slow or because it doesn’t catch what matters.

Then a vicious loop begins: to keep velocity, teams relax coverage expectations or skip expensive tests. The test suite becomes less representative of reality, so confidence drops further. Meanwhile the AI keeps producing code at the speed of thought.

If you want a simple diagnostic: look for trends in test quality signals, not just test counts. Are integration tests failing more often? Are unit tests covering fewer code paths? Are you adding new tests at a slower rate than new code? These are warning lights.

Make Tests Scale With Code: Property-Based + Mutation Testing

If AI is widening the gap, you need verification strategies that widen faster. Two techniques do that especially well: property-based testing and mutation testing.

Property-based testing: Generate edge cases automatically

Instead of writing one test for one input, property-based testing asks: What should always be true? You then generate many inputs—often including nasty boundary cases—to try to falsify that property.

Example (language-agnostic idea): for the discount function, define properties like:

The discounted total is never greater than the original total.
The discount amount is never negative and never exceeds the cap.
For any valid input, the result matches the agreed formula.

A property-based framework might try thousands of price/discount combinations, including zeros, extreme values, and unusual types, to find violations. This is exactly the kind of behavior that LLMs don’t reliably anticipate when writing only happy-path tests.

The key is to write properties tied to invariants your system must obey, not to mirror the implementation.

Mutation testing: Measure whether tests can detect wrong code

Mutation testing works differently: it intentionally makes small, plausible changes to your code (mutations) and then checks whether your tests fail. If your tests still pass after meaningful mutations, that means the suite isn’t actually protecting you.

This is where teams catch a common trap: “We have coverage” often means “we have coverage of code paths that aren’t sensitive to incorrect logic.” Mutation testing forces the question: Would a real bug slip through?

Set targets thoughtfully. Start with a narrow scope (critical modules, pure functions, business rules), then expand.

Tighten the System: Coverage Thresholds That Don’t Lie

Coverage thresholds can be useful—but only if they measure something that correlates with risk. Many teams set a single global number and call it done. That encourages gaming and doesn’t address the real problem: new code entering the repo without adequate verification.

Instead, adopt coverage rules that are hard to bypass:

Require minimum coverage for changed code, not the entire repo.
Differentiate unit vs. integration coverage, and don’t pretend one substitute can replace the other.
Use branch coverage or mutation score where it matters, especially for decision-heavy logic.
Set stricter thresholds for AI-assisted modules (business rules, parsing, validation, permissions)—the places where edge cases are expensive.

Practical advice: when AI writes code, treat it like code you didn’t fully reason about. That means your review and testing expectations should be higher, not lower. If your team already struggles with test maintenance, AI is going to make that struggle worse unless you invest in scalable verification.

Operational Guardrails: Review, CI Budgets, and Test-First Contracts

The right response isn’t “ban AI code generation.” It’s to wrap it in a verification discipline that matches its speed.

A strong, realistic workflow looks like this:

Define test contracts up front. For example, specify invariants for transformations and explicit parsing/validation behavior for inputs.
Require tests for every AI-generated change that affects behavior. Boilerplate helpers are one thing; business logic is another.
Use CI to enforce verification budgets. Property-based tests can be heavier, mutation tests can be slower—so run mutation tests on a schedule or only on critical paths, and tune input counts for property tests.
Review for invariants and edge cases, not just correctness. Your reviewer should ask, “What would break this in production?” not “Does it look right?”
Make test failures informative. If your suite is flaky or noisy, developers will stop trusting it, and then you’re back to the same verification gap.

Concrete example: if AI generates a serializer/deserializer, require:

round-trip properties (serialize then deserialize yields the original structure),
invalid input behaviors (expected errors or safe handling),
boundary handling (max/min sizes, encoding errors).

You’ll catch issues that a handful of example-based tests miss—especially when the assistant’s default assumptions don’t match your real-world data.

Conclusion: Speed Without Verification Isn’t Productivity

AI-generated code is genuinely accelerating development. The problem is that “faster” is not the same thing as “safer,” and our testing systems haven’t adapted to the new throughput. LLMs optimize for the happy path; real systems live and die by the edges.

To close the verification gap, pair AI coding with property-based testing to explore input space, mutation testing to validate test sensitivity, and stricter, change-aware coverage thresholds that can’t be gamed. Then add operational guardrails so CI and review reinforce the discipline you want—not the shortcuts you’ll accidentally take.

The future isn’t slower engineering. It’s verification that keeps pace.

Anthropic's Claude 3.5 Sonnet Is the Best Coding Model Nobody Expected

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 10 Nov 2024 00:00:00 +0000

For a while, the AI coding conversation sounded like a single question: How close can we get to “universal” intelligence by scaling up? But in practice, developers don’t live in benchmarks. They live in tickets, pull requests, CI failures, and deadlines. And that’s why Claude 3.5 Sonnet quietly became the developer’s model of choice for code generation and analysis—despite not being the obvious “flagship” pick.

The “mid-tier” model that shipped the goods

In the typical model lineup narrative, “best” almost always means “biggest.” The marketing gravity goes to the headline model—more capability, more ambition, more compute. The smaller sibling is often treated like an economy option.

Claude 3.5 Sonnet flipped that script for developers.

The surprising part isn’t that Sonnet can code. Most modern frontier models can produce working code when you give them a clear prompt. The surprise is that Sonnet feels operationally useful: it tends to hit the sweet spot where you can iterate quickly, get coherent reasoning, and avoid the “draft-your-own-architecture” problem that plagues weaker models.

Developers discovered it the way they always discover good tools: not by reading a press release, but by running a real task end-to-end. “Can it refactor this without breaking things?” “Can it update the call sites and imports correctly?” “Will it suggest a test strategy instead of dumping random assertions?” Sonnet answered those questions with fewer follow-ups than many expected from a non-flagship model.

Why speed and cost matter more than you think

Coding with AI is a feedback loop. You don’t just want one perfect output—you want a dialogue that converges quickly. In that loop, time and cost are not “secondary concerns.” They determine whether you can actually use the model repeatedly, throughout the day, on the kinds of problems that show up in production engineering.

Here’s what that looks like in practice:

Refactoring work rarely fits in one prompt. You ask for a change, you review the diff, you catch a logic edge case, you re-prompt with constraints (“preserve behavior,” “keep API stable,” “update tests accordingly”).
Test generation often needs iteration. You’ll accept an initial test suite, then realize you need more coverage for a boundary case, or you want to switch from integration tests to unit tests for determinism.
Codebase explanation is not a one-shot activity. You ask the model to summarize a module, then you ask follow-ups: “Show me the data flow,” “Where is the authorization enforced?” “What happens on retry?”

When a model is “good enough,” it becomes easier to do more turns. And when you can afford more turns, you get higher-quality final results. In the end, “best” becomes: best at solving your real problems with the resources you actually have.

Sonnet landed there—strong enough to do serious coding work, fast enough to iterate without friction, and priced in a way that encourages developer usage rather than experimental dabbling.

Complex refactoring: the difference between code and a change

A lot of models can generate code snippets. Fewer models can perform refactoring in a way that feels like a developer touching a live codebase.

Claude 3.5 Sonnet’s standout behavior in refactoring is its tendency to reason about the change as a system:

It identifies what needs to be updated (call sites, types, interfaces, error handling).
It preserves invariants (data formats, side effects, contract semantics).
It accounts for knock-on effects (tests, mocks, configuration).

A typical refactoring request might be:

“Extract this validation logic into a dedicated module. Keep the public API unchanged. Update any tests that depend on old error messages.”

In many models, this turns into a partial rewrite: a new module appears, but error messages drift, tests still expect the old behavior, or subtle semantics change. Sonnet more reliably produces refactors that “close the loop”—a change that includes the scaffolding and verification needed to merge safely.

The practical takeaway: when you refactor, ask for the full transformation, not just the new function. Include requirements like “preserve behavior,” “update tests,” and “keep interfaces stable.” The best models will follow through.

Tests that don’t feel like an afterthought

Generating tests is where model competence becomes visible. A weak model writes tests that are either too shallow (“assert true”) or overly brittle (hard-coding irrelevant details). A strong model produces tests that map to behavior and edge cases.

Sonnet tends to do something valuable: it treats tests as part of the design.

For example, if you ask it to implement a feature—say, adding idempotency keys to an API—Sonnet doesn’t just write the endpoint handler. It typically proposes a test plan that covers:

Happy path behavior (first request succeeds, subsequent duplicates are handled correctly)
Edge cases (missing or malformed keys, TTL expiration behavior)
Failure modes (database constraints, retries, concurrency considerations at the application level)
Integration boundaries (what should be mocked vs. exercised end-to-end)

Even when you don’t explicitly request a testing strategy, the model often generates tests that correspond to the meaning of the feature, not just its syntax. That’s exactly what developers need when they’re trying to land changes quickly without turning QA into a guessing game.

Practical advice: prompt for tests in the same style you write them. If your team uses Jest, pytest, or Go’s testing package, specify the framework and conventions. Then add one sentence: “Write tests that would catch regressions in behavior, not implementation details.” It forces the model to aim at correctness rather than imitation.

Explaining codebases with coherent reasoning

Another underrated coding use case is analysis: understanding code you didn’t write. This is where many AI outputs become “helpful-sounding” but shallow—summaries that don’t actually answer the questions you care about.

Sonnet’s strength shows up when you use it like an engineering partner, not a search engine:

“What is the data flow from request to response?”
“Where is permission checked, and how is it enforced?”
“Which functions mutate state, and under what conditions?”
“If I add this feature flag, what are the minimal changes?”

When it works well, you get a narrative you can follow—one that maps responsibilities to locations in the codebase. You can sanity-check it against what you see in files, then ask targeted follow-ups.

If you’ve ever used a model that “explains” by listing functions, you know how frustrating that is. A coherent explanation should help you predict behavior. Sonnet’s outputs often feel like they’re aiming at that prediction, not just summarization.

A practical workflow that works well: ask for a brief explanation first, then request a diagram-like breakdown in text (components → inputs → transformations → outputs). Finally, ask where the critical invariants live. You’ll get fewer meandering answers and more actionable guidance.

The real lesson: “best” is the time-cost tradeoff that wins

The industry’s loudest instinct is to chase the largest model. But developers don’t optimize for theoretical capability—they optimize for throughput, iteration speed, and merge safety.

A flagship model can be excellent, but it may come with constraints that matter in daily work:

slower response times that break your momentum
higher per-request costs that limit experimentation
output styles that require more editing to integrate cleanly

Sonnet’s success suggests a clearer rule of thumb: the “best” coding model is the one that reliably completes the loop—generate, review, modify, test—within the constraints of real engineering time.

In other words, the winning model is often not the most impressive. It’s the one that makes the engineer feel faster without sacrificing correctness.

Conclusion: pick the model that matches your workflow

Claude 3.5 Sonnet became the best coding model for many developers not because it was destined to be the headliner, but because it fit the real demands of coding work: speed for iteration, capability for non-trivial changes, and enough coherence to reduce back-and-forth.

If you’re evaluating models for development use, don’t start with “which is smartest?” Start with “which will make me ship?” Run a few tasks that mirror your day—refactor with tests, implement a feature with edge cases, and explain an unfamiliar module. The model that wins will almost certainly be the one that handles your constraints, not just your ambitions.

The Container Security Landscape Every Developer Should Understand

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 04 Nov 2024 00:00:00 +0000

If you write Dockerfiles, you’re already in the blast radius. Most teams treat container security like an operations problem—something for the platform team to “deal with.” But the truth is sharper: the image you build is the product you ship, and every security shortcut you take in the Dockerfile becomes an attack surface your users can’t afford.

Let’s walk through the container security landscape in a developer-first way—what’s commonly broken, why it matters, and how to fix it with practical, repeatable patterns.

Start with the reality: your Dockerfile decides the threat model

Container security isn’t magic tooling; it’s a chain of decisions:

What’s inside the image (packages, binaries, shells, utilities)
What runs by default (user, permissions, entrypoint behavior)
What gets baked in during build (secrets, compilers, debug tools)
Where dependencies come from (base images, package repos, build scripts)
What’s exposed (ports, network permissions, filesystem write access)

Most insecure images share a few predictable traits:

They run as root.
They rely on unverified or moving base images.
They include build tooling in production. (compilers, package managers, shells)
They ship more than necessary—extra packages, language runtimes, package caches.
They lack scanning in the build pipeline, so vulnerabilities survive until runtime.

These aren’t “ops mistakes.” They’re developer workflow mistakes.

A good mental model: an image is immutable, but your build process isn’t. The build process determines what immutability preserves.

The biggest easy win: stop running as root

Running as root is a top-tier convenience tax. It usually happens because it “just works” during local development, and it tends to be copy-pasted into production.

Instead, treat non-root as a baseline requirement.

A practical Dockerfile pattern

For many apps, you can do something like:

Create a dedicated user/group
Ensure the application directory is owned by that user
Switch to that user
Avoid setuid surprises

Example (Node.js-style, but the pattern generalizes):

Use a non-root user like appuser
Copy only what you need
Ensure file permissions are correct before USER appuser

FROM node:20-slim

WORKDIR /app

# Create non-root user
RUN groupadd -r appuser && useradd -r -g appuser appuser

# Install dependencies (keep it minimal)
COPY package*.json ./
RUN npm ci --omit=dev

# Copy application
COPY . .

# Fix ownership
RUN chown -R appuser:appuser /app

USER appuser

EXPOSE 3000
CMD ["node", "server.js"]

Two developer tips here:

Don’t rely on Kubernetes SecurityContext alone. It’s a safety net, not a replacement for correct image defaults.
Test permissions locally. If your app needs to write to a directory (logs, temp files), create and chown those paths explicitly.

If you’re migrating an existing app, expect failures around filesystem write. Fix them directly in the image rather than granting root privileges “temporarily.”

Reduce attack surface with multi-stage builds and minimal runtimes

A common anti-pattern is “install everything once, keep it forever.” Build tools shouldn’t ship in production—yet many images do exactly that: compilers, debuggers, and package managers included “just in case.”

Multi-stage builds: the developer-native security tool

Multi-stage builds let you compile/build in one stage and copy only runtime artifacts into the final image. That shrinks both the image size and the reachable tools an attacker could leverage.

For example, a typical approach for compiled languages:

Stage 1: build your binary (include build dependencies)
Stage 2: copy the binary into a lightweight runtime image

Even if you don’t adopt distroless immediately, multi-stage builds are a massive improvement because they reduce what an attacker gets.

Why “less” matters beyond size

Fewer packages means fewer known vulnerabilities, fewer ways to execute code, and fewer shells/utilities for post-exploitation. It also improves your scanning signal—fewer components, fewer false leads.

Prefer distroless (or at least slim) and be deliberate about base images

Your base image is the foundation of your security posture. If you use an outdated base or a constantly changing tag, you inherit risk without noticing.

Use pinned digests, not just tags

Tags like latest and even semver tags can move over time. For deterministic builds, prefer pinning by digest (the immutable identifier for an image).

Instead of:

FROM python:3.12-slim

Consider:

FROM python@sha256:<digest>

This doesn’t make vulnerabilities disappear, but it makes your build reproducible and your upgrades intentional.

Distroless: fewer utilities, fewer surprises

Distroless images generally omit shells and package managers, which is exactly what you want for production. Attackers rely on tooling; distroless reduces that capability dramatically.

The tradeoff is operational friction: debugging “inside the container” is harder. That’s a fair cost. Debugging should be done via logs, metrics, traces, and local reproduction—not by opening a shell in production.

A practical compromise many teams adopt:

Development: full-featured images for convenience
CI/testing: minimal images for early feedback
Production: distroless (or very slim) with a hard non-root baseline

Make scanning part of the build, not a report card

If you run vulnerability scanning only after deployment, you’re creating a delayed feedback loop. Developers need fast, actionable signals when the Dockerfile and dependencies are still editable.

Two tools commonly used for scanning are:

Trivy (often favored for simplicity and Docker-native workflows)
Snyk (useful in ecosystems with strong dependency management features)

Regardless of tool choice, the principle is the same: scan the built image and fail fast on serious issues.

What “baseline” looks like in practice

A reasonable workflow:

Build image in CI
Run image scan
Gate on severity thresholds (be strict on critical/high; handle medium thoughtfully)
Publish scan artifacts (so teams can trace what was scanned and when)
Create remediation paths (upgrade base image, rebuild with updated dependencies, or adjust package selection)

Also: treat scanning output as a starting point, not an oracle. For example, a vulnerability in a package you don’t actually include is irrelevant—but an image with build tools and shells makes “maybe exploitable” a more dangerous category. That’s why minimizing the image matters before you even argue about scan results.

Secrets and build-time tooling: the silent security footguns

Containers are often blamed for runtime vulnerabilities, but a more subtle risk is secrets baked into images during build.

Common mistakes:

Copying .env files into the image
Using ARG or ENV for credentials
Leaving package manager caches or build artifacts that contain tokens
Running build steps with tools that persist into the final stage

Practical rules of thumb

Never copy secret files into the image context. Use proper secret injection mechanisms in your CI system.
Use multi-stage builds so build-time tooling and artifacts don’t persist.
Don’t run npm install or pip install with dev/test extras unless you truly need them at runtime.
Clean up caches if your build pipeline or base image leaves them behind (and again: multi-stage is cleaner than cleanup heroics).

If you must fetch private dependencies, do it in a way that doesn’t leave credentials in layers. The simplest posture is to ensure credentials don’t make it past the build stage—and ideally never into the final layer graph.

OCI and ecosystem-agnostic security: your Dockerfile travels

One reason this topic feels messy is that people conflate “security on Docker” with “security on Kubernetes.” The good news is that modern container standards push toward consistency.

The OCI image specification makes the image format ecosystem-agnostic: your build output isn’t tied to a single platform. That means better Dockerfile practices—non-root defaults, minimal layers, pinned bases, clean runtime artifacts—carry forward regardless of whether you run on Kubernetes, Nomad, or another compatible runtime.

In other words, you’re not just improving one deployment. You’re improving a portable artifact.

Conclusion: treat image authoring as part of secure engineering

Container security isn’t an ops afterthought. It’s a developer responsibility embedded in the Dockerfile, the build pipeline, and the dependency choices you automate.

If you remember nothing else, adopt these baselines:

Run as non-root
Use multi-stage builds to keep build tooling out of production
Prefer minimal or distroless images
Pin base images by digest for reproducibility
Scan images in CI and fail fast
Ensure secrets never make it into image layers

Write fewer “convenient” layers. Ship fewer utilities. Make your builds deterministic. You’ll reduce risk immediately—and you’ll make the rest of your security tooling far more effective.

Gleam Might Be the Language the BEAM VM Deserved All Along

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 23 Oct 2024 00:00:00 +0000

Erlang’s runtime is the kind of engineering that feels unfair: it’s been hammered by real-world concurrency for decades and keeps winning. But the developer experience around it has often been… an acquired taste. Gleam is the antidote—an ergonomically modern, statically typed language that targets the BEAM VM, with a syntax many developers will recognize immediately. If you like the reliability of Erlang but want code you can trust before you run it, Gleam is suddenly hard to ignore.

The BEAM: reliability built into the substrate

Before you fall in love with any language surface syntax, it helps to respect the machine underneath. The BEAM VM is famous for concurrency and fault isolation. Processes are lightweight, message passing is straightforward, and supervision lets systems recover from failures without bringing the whole application down.

That’s why the BEAM shows up in places where uptime is not a nice-to-have—it’s the product. WhatsApp’s messaging layer, parts of Discord’s services, and telecom workloads where reliability matters more than trendiness all benefit from this runtime model. The point isn’t that BEAM is “better” in some abstract ranking; it’s that it solves a class of problems extremely well: concurrent systems that must keep moving when components fail.

Erlang, in turn, is the original BEAM native language. It exposes the runtime model directly. That’s a strength—and also why so many developers bump into friction early: the syntax can be terse to the point of feeling hostile, and the mental model of pattern matching and function heads is powerful but not always beginner-friendly.

So you end up with a familiar pattern in the ecosystem: the runtime is a powerhouse, but writing production code is sometimes harder than it needs to be. That gap is exactly where Gleam enters.

Erlang’s runtime, Erlang’s syntax, and the productivity tax

Erlang gets results. Its process model is clean, its failure handling is disciplined, and its ecosystem matured by surviving real deployments. But if you’ve ever tried to write something moderately complex—say, a web API with validation, a multi-step state machine, or a data pipeline—you’ve likely felt the productivity tax of the language surface.

Erlang code often reads like it’s optimized for the compiler’s comfort, not the developer’s attention. You can absolutely become fluent, but the learning curve is steep and unforgiving. You pay in readability, in refactoring safety, and in how quickly you can iterate.

And then there’s the type story. Erlang’s dynamic typing is a feature of its time and a fit for its philosophy, but it shifts error discovery to runtime. That’s acceptable in some domains, but it’s not a great fit for teams that want to catch entire classes of bugs before integration testing ever begins.

This is where Elixir helped. It made BEAM development feel mainstream: a friendlier syntax, the joy of pipelines, and a strong web ecosystem. But Elixir still largely relies on runtime checking. You can get pretty far with tests and contracts, and the community has built excellent tooling—but static types remain the missing safety net for many teams.

Gleam’s pitch is simple: keep the BEAM strengths, add a modern type system, and make code feel pleasant to write and review.

Why static types matter on BEAM (more than you’d think)

In a concurrent system, correctness isn’t just “does this compile?” It’s also “does this message have the shape I expect?” and “will this branch return the kind of value other code relies on?”

Dynamic types can handle this, but only if you’re disciplined about runtime validation. That means you often discover problems after deployment—or at least after you’ve exercised the relevant path in tests. Static types move those checks earlier, when it’s cheaper to fix them.

Gleam doesn’t just add “types for show.” It aims to make types work for day-to-day programming:

Function signatures become contracts. If your API handler returns Result, callers must handle failures explicitly rather than assuming success.
Pattern matching becomes safer. You can encode invariants in types so that illegal states are unrepresentable.
Refactoring becomes less terrifying. When you change a data structure, the compiler points you to every place the change ripples.

The practical outcome is fewer production surprises. Not zero surprises—no tool can promise that—but fewer “we only saw this bug in the wild” moments.

Gleam in practice: readable syntax, typed results, sane ergonomics

Gleam’s syntax will feel familiar if you’ve touched TypeScript or Rust. It’s readable, expression-oriented, and tends to keep the “shape” of your code visually obvious.

Here’s a small example of modeling success/failure with explicit types. (Think of it as the kind of helper you’d use in a web handler or data pipeline.)

pub type UserError {
 MissingField(String)
 InvalidEmail(String)
}

pub fn validate_email(email: String) -> Result(String, UserError> {
 if email.contains("@") {
 Ok(email)
 } else {
 Error(InvalidEmail(email))
 }
}

Even without the rest of the project, you can see what the function does: it returns either a validated value or a specific error variant. In a dynamic language you’d typically return nil or throw, and then your callers might or might not remember to check. In Gleam, your compiler becomes the annoying teammate who demands you handle failure cases.

Now imagine turning that into a more complete flow:

Parse input
Validate fields
Construct a domain type
Return either a domain object or a typed error you can map to an HTTP response

With static types, this chain can become self-documenting. You can refactor validation rules without losing confidence in how errors propagate.

Concurrency and processes without losing type safety

Because Gleam compiles to BEAM bytecode, it can participate in the same fault-tolerant concurrency model that made Erlang legendary. The important difference is that the code you write can still be checked by a static type system.

That means you can structure concurrent components—workers, supervisors, actors—while keeping your message shapes and invariants under control. In practice, that reduces the “mystery” aspect of distributed message passing. Your processes still fail and recover as designed, but you’re less likely to send the wrong thing and only discover it when a branch crashes at runtime.

The BEAM ecosystem often emphasizes designing for failure. Gleam pairs well with that philosophy: types don’t remove failure, they make failure less arbitrary.

The ecosystem advantage: what Gleam unlocks for teams

The BEAM ecosystem is already strong, but the language you use affects who joins and how fast they become productive. Erlang’s syntax deters some engineers. Elixir welcomes many, but static types remain a gap for teams that want compile-time guarantees.

Gleam occupies a sweet spot:

It’s modern enough to feel approachable.
It’s typed enough to make refactoring safer.
It compiles to the same runtime primitives that power the most battle-tested systems.

This matters for business outcomes, not just developer aesthetics. Consider the typical pressures on a production team:

You need to onboard developers quickly.
You need to maintain and extend code without constant rewrites.
You need confidence during deployments.
You want to spend time building features, not chasing edge-case regressions.

Types improve the cost profile of all of these. They make code review sharper because the compiler has already filtered out many classes of mistakes. They also help when you introduce new contributors: reading a well-typed module is often easier than interpreting the implicit expectations of a dynamically typed one.

And because Gleam targets the BEAM, you’re not trading away operational maturity. You’re getting a friendlier front door to the same backend strengths.

If you’ve ever wished BEAM development had the “modern language feel” of today’s ecosystems—without giving up fault-tolerant concurrency—Gleam is essentially that wishlist, turned into code.

Building with Gleam: a pragmatic path for production use

If you’re evaluating Gleam for real projects, the best strategy is to be pragmatic. Don’t try to boil the ocean.

Start with the kind of code where types deliver immediate value:

input validation
domain modeling
data transformation pipelines
boundary logic (mapping errors to responses)
message payload definitions for concurrent components

Use Gleam to make illegal states unrepresentable. Then lean on BEAM’s runtime model for the concurrency and fault-tolerance you actually care about.

A practical workflow might look like this:

Model your domain with explicit types. Represent errors and data structures directly.
Write small, pure functions first. Let the compiler guide you.
Add concurrency for the parts that need it. Use BEAM’s process model for orchestration.
Keep effects at the edges. The more you can isolate pure logic, the more the type system pays off.
Treat refactoring as a feature. In typed codebases, safe refactors are not a luxury—they’re how you stay fast.

You’ll find that Gleam encourages readable structure. The syntax stays out of the way, while types make expectations explicit. That combination is exactly what teams need when code has to survive both time and traffic.

Conclusion: the BEAM era deserves modern ergonomics

The BEAM VM already proved that concurrency, supervision, and fault recovery can be engineered into something reliable enough for the real world. Erlang delivered the runtime. Elixir delivered usability. Gleam delivers the missing piece many teams want most: static types with a modern, friendly syntax.

If you care about the operational strengths of BEAM but want compile-time confidence and clearer code, Gleam is hard to dismiss. It doesn’t replace the BEAM story—it completes it.

The Observability Stack Is Consolidating and That's Good

abdecastro@protonmail.com (Antonio B De Castro) — Fri, 11 Oct 2024 00:00:00 +0000

For years, observability felt like a series of one-off experiments: pick a backend, instrument your app, pray it works with your dashboards, and then repeat when the next platform “wins.” That era is ending. OpenTelemetry has emerged as the common language, and the ecosystem is converging around it—making observability less of a vendor-specific art project and more of an engineering discipline.

From “observability wars” to “shared instrumentation”

The observability ecosystem didn’t just grow—it fragmented. StatsD fought for metrics, Prometheus won a generation of monitoring fans, while Jaeger and Zipkin splashed the trace landscape with competing ideas. Even when two tools were both “good,” they often required different instrumentation strategies, different exporters, different semantics, and different operational habits.

The practical downside was predictable: instrumentation became backend-driven rather than application-driven. If you started with one stack and later wanted to switch, you weren’t just changing dashboards—you were rethinking how your software reported telemetry.

Consolidation fixes this. The core shift is that instrumentation is now largely backend-agnostic. Your application emits telemetry in a standard format, and the backend decides what to store, how to index, and how to visualize it. That means less rewriting when strategies change—and faster adoption of new analysis techniques without re-instrumenting your systems.

OpenTelemetry won because it standardized the “wire” and the “SDK”

OpenTelemetry is more than a marketing umbrella. It standardized two things that matter to real teams:

A common telemetry model (what spans, metrics, and logs represent, and how they relate).
A common protocol and SDK approach for emitting that data.

The impact shows up immediately in everyday developer workflows. Consider a typical microservice deployment:

You add tracing to a service.
You add metrics to track latency and errors.
You correlate those signals during incidents.

With a consolidated approach, you can instrument once, and you can route the output to different destinations. Today you might send traces to Tempo and metrics to Prometheus-compatible storage. Tomorrow you might add a vendor backend for enterprise workflows—or run a mixed environment during migration.

The key is separation of concerns: your application speaks OpenTelemetry; your platforms listen. That’s the difference between “observability as a product decision” and “observability as an engineering capability.”

The backend landscape is converging—Grafana, Datadog, and more

Once OpenTelemetry became the shared foundation, the competition didn’t disappear—it evolved. Backends now differentiate on storage, scale, UI/UX, alerting ergonomics, cost, and operational maturity—not on whether your instrumentation can even work.

Grafana’s LGTM stack is a credible open-source alternative

Grafana’s “LGTM” story—Loki (logs), Grafana (dashboards), Tempo (traces), and Mimir (metrics)—is compelling because it treats the observability surface as a cohesive platform. The result is a workflow many teams actually want:

Search logs in Loki while looking at traces in Tempo
Use Grafana panels to correlate metrics and traces
Maintain one query and visualization layer across signals

Where this matters in practice is during incidents. Suppose a customer reports elevated checkout failures. A useful workflow looks like:

Use Grafana to see the error rate spike (metrics).
Jump to a trace exemplifying a failing request (traces).
Inspect the relevant log lines and upstream/downstream calls (logs).

When these signals are tied together consistently, investigation time collapses. You spend less time stitching together evidence and more time fixing root causes.

And because LGTM is largely open-source, teams can keep the cost structure sane. You can run it yourself, scale it deliberately, and avoid paying for features you don’t need. (That doesn’t automatically mean “cheaper in every case,” but it does mean you have options that aren’t locked behind contracts.)

Datadog still wins on speed-to-value

Datadog’s strength has long been operational convenience: getting to dashboards and alerting quickly, and handling ingestion, indexing, and analysis in a polished way. If you want a turnkey “ship it tomorrow” experience, vendor ecosystems still have an edge.

But consolidation changes the negotiation. If you start with Datadog but later decide you need more control—or you want to reduce recurring cost—you’re not trapped by instrumentation lock-in in the same way. OpenTelemetry reduces the pain of switching backends because your application doesn’t have to be rewritten to emit different telemetry formats.

The real takeaway: compatibility is now a default expectation

The emerging norm is that observability tools should accept OpenTelemetry-compatible data. That doesn’t mean they’re identical—storage and semantics still differ—but it means compatibility is no longer a special project.

For engineering leaders, this is the shift worth caring about. It turns observability procurement from a gamble into a managed lifecycle.

Practical migration strategies: how to avoid the “rewrite everything” trap

Even with consolidation, most organizations aren’t starting from greenfield. They have:

existing tracing systems
Prometheus metrics scraped today
log pipelines built around specific agents
dashboards that encode institutional knowledge

So the goal isn’t “rip and replace.” It’s staged convergence.

Step 1: Instrument once, then fan out

If you already collect telemetry with partial standards, move toward OpenTelemetry at the edges. A practical pattern is:

Keep existing backends running.
Begin exporting via OpenTelemetry.
Validate that correlation works: trace IDs link to logs, metrics align with span events, and service naming is consistent.

Make this measurable. For example, pick one critical user journey—like “search to checkout”—and ensure you can follow it end-to-end using the new pipeline without guessing.

Step 2: Standardize service names and attributes early

Convergence fails when teams invent inconsistent conventions. Decide what you mean by:

service name
environment (prod/staging)
deployment version
instance identifiers
request/user correlation keys (when appropriate)

OpenTelemetry gives you the structure; humans still define the meaning. Invest time here early, because it determines how usable your observability data becomes in Grafana or any UI.

Step 3: Use one “source of truth” for each signal during migration

Mixing duplicate pipelines is tempting—especially when you can’t turn everything off at once. But duplication can create confusing dashboards and noisy alerts.

A cleaner approach is to pick a default destination per signal while migrating:

traces: Tempo (new)
metrics: Mimir or existing Prometheus (choose deliberately)
logs: Loki or existing log store

Then sunset old pipelines after validation.

Step 4: Treat cost and retention as first-class design inputs

When observability becomes consolidated, the temptation is to collect everything. Don’t. Define your retention and downsampling strategy for each signal:

Keep high-cardinality data short-lived.
Store detailed logs for a limited window.
Keep tracing sampling tuned to your budget and incident needs.

Because now you’re able to route the same telemetry to different backends, you can also right-size storage decisions without forcing new instrumentation.

What this means for teams: less lock-in, more engineering focus

The most important benefit of consolidation isn’t the choice of vendor or open-source stack. It’s what consolidation frees your organization to do.

You can plan for change instead of fearing it

When instrumentation is standard, switching backends becomes an infrastructure migration, not a feature rewrite. That changes the tone of platform roadmaps. Instead of treating observability selection as a one-time irreversible bet, teams can evolve their stack based on cost, performance, and usability.

Incident response becomes faster and more consistent

Correlation is where observability earns its keep. With standardized telemetry, trace IDs can reliably connect to logs and span context can consistently enrich metrics and dashboards. The result is less time spent on plumbing and more time on diagnosis.

Developers get a smoother path from “instrumented” to “understood”

A subtle but real advantage: once telemetry meaning is consistent, tools can provide better defaults—service maps, better drill-down experiences, clearer dashboards, and more useful alerts. That makes observability not just something ops manages, but something developers can use to iterate confidently.

Conclusion: the observability stack is becoming a utility

The observability wars weren’t meaningless—they drove innovation. But the fragmentation was expensive, and the ecosystem is now correcting course. OpenTelemetry unified instrumentation and wire protocol, and that shared foundation is enabling real interoperability across backends.

Whether you choose Grafana’s LGTM approach, a vendor platform like Datadog, or a hybrid strategy, the trend is clear: observability is consolidating into a utility-like capability. For teams, that means fewer rewrites, less lock-in, and faster paths from signals to fixes. That’s not just good architecture—it’s good business.

Go 1.23 Range Functions Are a Bigger Deal Than You Think

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 05 Oct 2024 00:00:00 +0000

Go has always been opinionated about iteration: simple syntax, predictable control flow, and—when you need concurrency—explicit goroutines and channels. So when Go 1.23 expands what range can do, it doesn’t just add a small convenience. It changes the shape of what Go code can express, particularly around custom iterators and “generator-like” patterns.

The headline feature sounds small: you can now range over function types in Go 1.23. But the real story is what that unlocks. You can write lazy, composable iteration pipelines—filters, transformers, even reductions—without channels, without callback spaghetti, and without paying the mental cost of concurrency when you don’t need it.

What changed in Go 1.23 (and why it matters)

Before Go 1.23, you could range over arrays, slices, maps, strings, and channels. You could build custom iteration abstractions, but the moment you wanted to integrate with for range, you typically had to choose between:

Channels: convenient, but ties your design to concurrency and buffering semantics.
Callbacks: flexible, but often devolves into hard-to-read control flow and “who owns what?”
Manual loops: straightforward, but you lose the uniformity and readability that range gives you.

Go 1.23 extends range to work with range-over-function types. The exact mechanics are language-level, but the practical effect is simple: you can define an iterator as a function (or a function-like type) and then iterate it with for ... range in a way that feels native to Go.

This is the kind of change that doesn’t trumpet itself as a new abstraction—because it doesn’t introduce a new concept you have to learn. It upgrades a syntax tool you already know.

From “iterator objects” to lazy pipelines

The biggest win is composition without ceremony. Once your iteration source can be ranged over, you can build pipelines that are:

Lazy: items are produced on demand.
Deterministic: no goroutine scheduling, no races, no buffering surprises.
Ergonomic: for v := range it { ... } reads like iteration, not like framework code.

Consider a common need: filter a stream of records and then transform them. With channels, you’d typically spin up a goroutine pipeline. With the new capability, you can write something closer to iterator algebra.

Imagine a function that yields values matching a predicate:

It takes a collection (or another iterator).
It returns an iterator function type that range can consume.
It produces results lazily as the consumer requests them.

Even if you’re used to Go’s functional packages, the key shift is that you’re not building “map/filter” helpers that eagerly allocate slices. You’re building something you can chain and consume like native iteration.

Practical example: filter + map without channels

Suppose you have a slice of integers and you want odd numbers squared, but only until you’ve collected 10.

With a lazy iterator approach, you can stop early naturally:

for v := range IterFrom(xs).Filter(isOdd).Map(square) { ... }
Break after the 10th result.

The early break matters. Eager implementations would already compute the entire transformed slice before you ever know you can stop. Lazy iterators let you align computation with need.

That alignment is more than performance. It’s also correctness-by-construction: your “pipeline” doesn’t accidentally do extra work or depend on side effects that should have been deferred.

The case for custom iterators over channels

It’s tempting to treat channels as a universal iterator mechanism. In practice, that’s usually a tax.

Channels shine when you’re doing concurrency: independent work streams that must overlap. But when you’re doing ordinary data traversal, channels force you to answer questions your code shouldn’t have to care about:

Should the pipeline run in a goroutine, or not?
Who closes the channel, and how do you guarantee it?
What happens on early termination (e.g., break)?
What’s the buffering strategy, and why?

Custom iterators eliminate most of that. They let you keep the shape of Go’s range loops while staying fully in the single-threaded world unless you explicitly opt into concurrency.

This is especially valuable for library code. A library that exposes an iterator-like API shouldn’t implicitly decide that its user now has to think about goroutine lifetime. With function-based range iterators, the consumer owns the loop; cancellation becomes as simple as breaking out of the loop.

The standard library’s `iter` package becomes more than helpers

Go’s ecosystem has long had “iterator” utilities, but the real difference here is that the language now makes iterator composition feel first-class.

The standard library’s iter package (and its map/filter/reduce style operations) becomes dramatically more usable because you can integrate those operations directly into for range loops. That means:

Consumers can use familiar loop constructs.
Iterator transformations remain lazy and composable.
You can build “generator patterns” without inventing your own mini-framework.

A practical way to think about it: iter gives you a vocabulary, and Go 1.23 gives you grammar. Previously, you could write pipeline logic, but the moment you wanted it to feel like iteration, you had friction. Now you can make it feel native.

Example: reduce with readable control flow

Reduction is a good example of why this matters. A reduction often wants a single pass and no intermediate allocations.

With iterators, a reducer can consume values as they’re produced. That means you can express things like:

Sum only items matching a condition.
Find the first element meeting a criterion.
Build a fold that carries state.

The for range integration makes these patterns straightforward to read: the loop is where the control flow is, and the iterator is where the values come from.

A more Go-like alternative to generator frameworks

If you’ve used other languages with generator syntax, you know the appeal: define a “sequence producer” once, then consume it with plain loops. Go’s history has been less syntactic here, so teams often build internal generator patterns with channels or callbacks.

Go 1.23 lets you stop doing that.

Custom iterators are the sweet spot for “generator-like” behavior in Go:

You can define reusable iteration sources.
You can chain transforms cleanly.
You can avoid goroutines unless you truly want concurrency.
You can keep the consumer side boring and idiomatic.

This is also how you avoid accidental complexity in teams. Instead of every codebase rolling its own yield abstraction (with subtle differences, error handling quirks, and inconsistent naming), you can standardize on iterator functions that work with for range.

And yes, that also makes code review easier: reviewers can reason about for range semantics without tracing channel lifetimes or callback invocation order.

Practical guidance: what to build, what to avoid

To take advantage of this feature without turning your codebase into an iterator maze, keep these principles in mind:

Use iterators for lazy pipelines, not for everything.
If you already need all results, building slices directly may be clearer and faster than chaining iterator adapters.
Prefer early termination.
The biggest practical benefit of laziness shows up when consumers can stop early. Design iterators so break stops upstream work.
Don’t hide side effects in iteration.
Iteration should generally be about traversal and transformation, not orchestration. If you must do side effects, keep them explicit in the consumer loop.
Choose clarity over cleverness.
Iterator chains can become hard to debug if you go too abstract. Use small, well-named adapter functions—especially in exported APIs.
Use channels when concurrency is the point.
If you’re doing parallel work or coordinating asynchronous producers/consumers, channels are still the right tool. Iterators are for expressive, composable single-pass iteration.

If you adopt those rules, Go 1.23’s range-over-function-types don’t just add new capability—they help you keep your code honest.

Conclusion: Go is getting more expressive without losing itself

Go’s design promise has always been simple: keep the language understandable, and add power in ways that fit the existing mental model. Range-over-function types are a perfect example. They don’t replace Go’s core iteration constructs—they extend them so custom iterators can participate as first-class citizens.

The result is a practical shift: you can build lazy filtering pipelines, generator-style sequences, and reduce-style folds without channels, without goroutine choreography, and without callbacks pretending to be control flow. The iter package gets more useful, but the bigger win is architectural: Go becomes more composable for everyday data transformation tasks.

In other words, it’s not a “minor feature.” It’s a better way to write the code you already write—just with fewer compromises.

Claude Just Became My Default AI Coding Partner

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 29 Sep 2024 00:00:00 +0000

I didn’t switch to Claude because it sounded impressive—I switched because it stopped breaking my workflow. After months of juggling ChatGPT, Copilot, and a rotating cast of open-source assistants, I landed on Anthropic’s Claude for one specific job: code-heavy work where you can’t afford the model to “mostly get it right.” The difference isn’t marketing. It’s how it handles context, instruction-following, and—most importantly—uncertainty.

Context Isn’t a Feature. It’s the Product.

Most AI coding assistants feel like smart autocomplete until your codebase gets real. Then you hit the classic failure mode: you paste the file, the model answers as if it read the whole thing, and then you discover it quietly ignored key parts—imports, edge cases, types, or the one function you actually cared about.

Claude’s standout strength, at least in my experience, is its ability to ingest a lot of code at once without immediately dropping the thread. A large context window (I routinely work with entire modules in a single chat) changes the nature of the interaction. Instead of “here’s a snippet, please guess,” it becomes “here’s the system—respond within it.”

A practical example: refactoring without guesswork

Imagine you’re refactoring a service layer that spans multiple files:

UserService calls UserRepository
UserRepository uses a query builder
Validation rules live in shared utilities
Error handling depends on a couple of conventions

With a small-context model, you’ll end up sending fragments and asking follow-up questions like, “Wait, did you see the retry policy in this other module?” With Claude, I can often paste the relevant functions and associated helpers in one go, then ask for a structured refactor:

Identify where behavior changes risk regression
Propose a new interface
Update call sites
List tests I should run

That shift sounds subtle, but it’s enormous in practice: you spend less time re-teaching the model your architecture, and more time iterating on the actual change.

Instruction-Following That Doesn’t Melt Under Complexity

Plenty of tools can generate code. Fewer can reliably execute on constraints. In real refactors, you don’t just want “a correct implementation.” You want:

Preserve public API shape
Keep function signatures stable
Maintain error semantics (especially around retries and idempotency)
Avoid changing database query behavior
Don’t touch unrelated modules

Claude has earned my trust because it stays readable to constraints. When I ask for a refactor plan followed by a patch-style change, it doesn’t treat my instructions like vibes. It follows them in a way that’s consistent across multiple iterations.

Example: “Keep behavior identical” prompts

Instead of saying “refactor this,” I ask:

“Refactor for clarity without changing runtime behavior.”
“Do not alter the signature of getUserById.”
“Keep all thrown exceptions exactly as-is.”
“If any behavior can’t be guaranteed, stop and ask questions.”

In return, I get answers that are structured, where changes are localized and reasoning is explicit. That matters when you’re working with code that already has landmines: implicit ordering, side effects, and subtle invariants.

And yes, this is where other assistants often disappoint—not by being malicious, but by being too eager. They’ll “improve” things you didn’t ask for, or they’ll rewrite logic with a casual confidence that feels like a trap.

The Best Part: Claude Admits Uncertainty

Here’s the truth: I don’t want a coding assistant that sounds sure when it isn’t. I’ve seen too many AI outputs that read like authoritative explanations while being subtly wrong. The worst ones are the ones that don’t hesitate.

Claude, in my experience, is more likely to say something like: “I’m not certain how X is handled in your code,” or “I need to see the implementation of Y to avoid breaking behavior.” That posture is a gift.

Why? Because software engineering is risk management. When an assistant can’t guarantee correctness, the correct response is to ask for more information—not to fake certainty.

Example: when the model should stop

Suppose I’m modifying pagination logic, and the codebase has two different paging strategies depending on request headers. If I paste only one module, a less careful assistant might produce “a working answer” that accidentally breaks the alternate path.

When Claude isn’t sure, it pushes the right interaction forward:

“Can you paste the handler that sets the paging mode?”
“Show the function that interprets cursor vs offset.”
“Confirm how you treat empty result sets.”

That keeps me from deploying a plausible bug.

My Workflow: How I Use Claude Without Losing Time

A big context window doesn’t mean “dump everything and pray.” The workflow matters. Here’s the approach that made Claude my default instead of just another tool.

1) Give it the problem boundary, not just the code

I start with a short briefing:

Language + frameworks involved
What “done” looks like
What must not change (API shape, behavior, performance constraints)

Then I paste the relevant modules.

2) Ask for an explicit plan before code

For complex refactors, I ask for:

A step-by-step plan
A list of assumptions
A list of files/sections that will change
A test checklist

This prevents “instant code generation” from becoming “instant nonsense.”

3) Use iterations like a human review loop

If the model proposes changes that touch too much, I say so. If it misses a constraint, I point it out. I don’t treat it like an oracle; I treat it like a strong pair programmer that can digest large chunks of code faster than I can search manually.

4) Require uncertainty, explicitly

In the prompts I’ll include a line like:

“If you can’t guarantee correctness, ask questions.”

That’s not a trick—it aligns incentives with my actual needs: safer change proposals.

Why the Market Still Can’t Beat the Context + Honesty Combo

The AI coding assistant space is fierce, and every contender promises “better code.” But what I care about isn’t raw creativity. It’s operational reliability.

A smaller context window forces a constant back-and-forth that slows you down and increases the chance of mismatch. Meanwhile, assistants that confidently hallucinate—however fluent their writing—introduce a risk profile that’s hard to manage under time pressure.

Claude’s combination—large-context handling for whole modules, precise instruction-following during complex edits, and a willingness to flag uncertainty—fits the way I actually build software. It reduces thrash. It increases traceability. And it makes refactoring feel like engineering instead of gambling.

In other words: capability matters, but context and epistemic humility matter more.

Conclusion: Claude Isn’t Just Smarter—It’s Safer for Code-Heavy Work

After months of switching between tools, I kept returning to one realization: the best AI coding partner isn’t the one that can generate the most impressive snippet—it’s the one that understands enough of your code to make fewer dangerous assumptions. Claude earned my default status because it handles large code context cleanly, follows constraints in complex tasks, and treats uncertainty as a first-class input rather than a defect.

If your work involves real modules, real refactors, and real risk, Claude is the one I’d bet on.

Edge Computing Isn't a Buzzword Anymore—It's Where Your Code Runs

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 17 Sep 2024 00:00:00 +0000

For years, “move it to the edge” sounded like marketing—something for CDNs and caching layers. But edge runtimes have quietly crossed a threshold: they now run real application code globally, with enough maturity to change how you design, deploy, and ship. If your users feel latency, you don’t need a new idea—you need a different execution location.

Why proximity beats cleverness

The simplest way to understand edge computing is also the least romantic: the closer your code runs to the user, the less time it takes for the request to come back.

In practice, that means your app stops paying a round-trip tax to a single origin region. When traffic is worldwide, a “single-region” architecture often turns every request into a tiny negotiation: browser → region → upstream services → region → browser. Even if your origin is optimized, the physical distance remains.

Edge platforms flip the model. Instead of treating compute as something you “maybe” add near your CDN, edge runtimes treat compute as part of the distribution layer. The result is straightforward:

Interactive UX improves because the response arrives faster.
APIs feel more reliable because you reduce long-tail delays caused by routing and congestion toward a distant origin.
Global scalability becomes default because your code is already distributed.

This is why the latency gap between “one region” and “hundreds of edge locations” is more than a number—it’s the difference between a UI that feels responsive and one that feels fragile.

Edge has matured: from caching scripts to application logic

The old edge story was caching and routing. That still matters, but it’s not the interesting part. The real shift is that edge runtimes are now capable of executing business-relevant logic without you building an entirely separate backend for the edge.

Cloudflare Workers, Deno Deploy, and Vercel Edge Functions share a common design philosophy: start fast, run on a lightweight global runtime, and expose enough platform APIs to handle common web patterns. You’re no longer limited to “rewrite this header” or “serve that file.” You can implement:

lightweight API proxies
request authentication and lightweight authorization checks
tenant-aware routing (e.g., based on hostname)
response shaping (masking fields, adding computed metadata)
cache-control decisions based on request context
integration glue between edge clients and your origin services

A practical example: imagine a global onboarding flow that calls an API to validate an invitation token and returns a user profile. Today, you might route to your origin, validate there, and return the result. With an edge function, you can validate the token at the edge (or at least validate format + short-circuit obvious failures), attach tenant context, and then forward only the necessary upstream calls. Even when you still hit the origin, the user experiences less waiting—because you’ve reduced the number of round-trips and the work done far away.

Three edge runtimes, one outcome: ship closer

Edge ecosystems differ in developer experience and runtime capabilities, but the goal is the same: get code running near the user, fast.

Cloudflare Workers: global by default, V8 isolation in the mix

Cloudflare Workers are built around the idea that the platform should handle distribution and scaling for you. Under the hood, Workers run in V8 isolates, which helps keep execution fast and predictable for lightweight application logic.

Where Workers shine in real deployments:

Read-heavy request paths where you want low latency more than long compute
API gateway patterns (authentication checks, routing, response normalization)
streaming and proxying patterns where a CDN alone isn’t enough

A common pattern is to implement a thin “edge API façade” in Workers that:

inspects the request (headers, cookies, path)
decides routing and cache strategy
forwards to your origin or other services
returns a tailored response

Deno Deploy: a globally distributed Deno runtime

Deno Deploy brings Deno’s developer ergonomics to a distributed runtime. If you already like Deno’s module approach and its “batteries-in-the-right-place” feel, edge deployments become less of a context switch.

Deno Deploy is a strong choice when you want edge code that resembles the rest of your Deno-based stack. That matters because edge functions often evolve quickly: today it’s a simple redirect, next week it’s an auth layer, and the week after it’s a request transformer with caching rules.

In other words, the best edge architecture isn’t the one you planned—it’s the one you can iterate on safely.

Vercel Edge Functions: edge-first integration for modern web apps

Vercel Edge Functions fit naturally into the Vercel workflow, which is a big deal for teams that ship web apps continuously. If your product is already aligned with Vercel’s deployment model, edge functions become an extension of your existing pipeline rather than a new infrastructure project.

Vercel Edge Functions are especially compelling for:

API endpoints that support your frontend
request/response logic tightly coupled to the web experience
incremental edge adoption (move one endpoint at a time)

A useful mental model: start by moving your most latency-sensitive endpoints. Your app gets the biggest UX payoff first, and you avoid premature refactors.

The tradeoff: fewer runtime APIs, more design discipline

Edge runtimes are fast, but they’re not a clone of your server environment. You typically get limited runtime APIs, constrained execution environments, and different patterns for networking, storage, and heavy background work.

That constraint is not a dealbreaker—it’s a forcing function.

Design edge logic like it’s a high-frequency gate

Edge works best for code that:

makes quick decisions
reads data efficiently
minimizes heavy computation
delegates expensive work to origins or specialized services

A good rule of thumb: if your edge function can answer the request with minimal dependencies and short logic paths, it’s a candidate. If it needs long-running tasks, heavy CPU, or complex stateful workflows, it likely belongs elsewhere.

Example: cache-aware response shaping

Consider a read-mostly endpoint like /api/catalog. Your edge function can:

check query params and headers to decide cache keys
serve from cache when possible
attach small computed fields (like user-specific visibility rules) without rewriting the whole backend

Even if the edge has to occasionally call the origin, the “fast path” keeps UX snappy and protects your origin from spikes.

Example: edge auth as a first filter

You can implement a first-pass authorization check at the edge:

verify token presence and basic claims structure
block obvious invalid sessions
pass through only authorized requests

The origin still validates thoroughly, but the edge removes needless load and reduces time-to-failure for unauthenticated users.

Practical migration strategy: don’t boil the ocean

Edge is most effective when you adopt it intentionally. Here’s how to move without breaking everything.

Pick one user-visible endpoint
Start with the route that dominates UX timing—search, feed retrieval, or any API your frontend calls for initial render.
Map the critical path
Identify what happens before the response can be produced. If there’s logic you can do earlier—or decisions you can make closer to the user—edge is worth it.
Keep edge responsibilities narrow
Treat the edge function as a fast gatekeeper and router. Push heavy compute and long workflows to your origin or background workers.
Add observability early
Edge debugging can be different from server debugging. Ensure you log request IDs, capture error context, and measure latency by route and status. If you can’t tell what’s happening, you can’t iterate.
Use a “fast path” + “fallback” model
The edge should handle the common case quickly. When it can’t, it forwards to the origin. This gives you performance now without betting the farm on perfect edge coverage.
Iterate endpoint by endpoint
Edge adoption shouldn’t be a migration project; it should be a continuous improvement loop.

Conclusion: edge is where UX is won

Edge computing isn’t a trend anymore—it’s a deployment location with real architectural consequences. Cloudflare Workers, Deno Deploy, and Vercel Edge Functions all push the same outcome: your code runs closer to users, reducing latency and improving perceived performance.

The best teams won’t “move everything to the edge.” They’ll move the parts that matter most—read-heavy request paths, API proxies, and fast decision logic—while keeping complex work where it belongs. Done right, edge isn’t just faster. It changes how your product feels.

Local AI Development Environments Are a Game Changer

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 11 Sep 2024 00:00:00 +0000

If you’ve ever “spent your way” through prompt engineering, you already know the real tax on AI development isn’t compute—it’s friction. Local-first tooling changes that. With the right stack, you can iterate instantly, keep your data where it belongs, and—when you’re ready—move to production with almost no refactoring.

This post lays out a practical local AI development environment using Ollama + Open WebUI + LiteLLM + Docker Compose. The goal is simple: a full AI dev stack on your laptop that behaves like a real service, but costs you nothing during iteration and doesn’t leak your experiments.

The three hidden costs of “just use an API”

Most teams don’t struggle because they can’t build AI features. They struggle because early iteration is expensive in ways dashboards don’t capture.

1) API costs during iteration

Prompt tweaks are cheap—until every tweak triggers an API call you can’t stop. Even if your project has a budget, you’ll burn it on exploratory runs, regression testing, and “just one more” rephrasing.

2) Latency during prompt engineering

When each response takes seconds, you stop thinking in terms of conversation and start thinking in terms of waiting. That slows down debugging and makes iteration feel like pulling teeth.

3) Privacy concerns during testing

Teams love to say “it’s just test data,” then paste real customer context, internal documents, or proprietary workflows into prompts. You might be careful, but software doesn’t care about intent—it only moves bytes. Local tools let you develop without that anxiety.

The fix isn’t “be more disciplined.” The fix is to build locally.

The architecture: local models, web UI, and an OpenAI-compatible proxy

Here’s the backbone of the system, and why each component matters.

Ollama: run models on your machine

Ollama is the local model runner. Instead of calling a hosted model, it pulls and runs LLMs locally (GPU if you have it, CPU if you don’t).

Practical payoff: you can iterate on prompts with near-real-time feedback—because you’re not waiting on an external network and billing meter.

Example use case:

Generate a draft for a PR description template
Summarize internal docs
Rewrite safety-sensitive text according to your own rules All without sending that content to a third party.

Open WebUI: a ChatGPT-like interface for developers

Open WebUI gives you a familiar chat UI—prompting, conversation history, and model selection—without requiring you to build a front-end.

Practical payoff: it accelerates everyone. Backend engineers can test prompts without context switching into scripts, and product folks can validate behavior without asking for exports.

LiteLLM: an OpenAI-compatible proxy

LiteLLM is the glue that makes your local setup look like an OpenAI-style API. That’s the key to not rewriting your application later.

Instead of building your app around Ollama’s specific endpoints, you point your app at LiteLLM using OpenAI-compatible settings:

base_url
api_key (often a dummy value in local setups)
model name mapping

Practical payoff: the move from local development to production becomes an environment variable swap, not a migration project.

Docker Compose: turn the pieces into a real stack

You can run these tools separately, but the real win is consistency. Docker Compose makes “works on my machine” less common and onboarding dramatically faster.

A typical local docker-compose.yml includes four services:

ollama (model runtime)
open-webui (chat UI)
litellm (OpenAI-compatible proxy)
Your app or a test runner service (optional)

A skeleton example (trimmed for clarity) looks like this:

ollama exposes the local model API to the Compose network.
open-webui connects to Ollama as its model backend.
litellm connects to Ollama and exposes an OpenAI-compatible endpoint for your application.

From a developer’s perspective, you’ll end up with two “entry points”:

A browser URL for chat (Open WebUI)
An HTTP endpoint for your code (LiteLLM)

Practical advice:

Use named volumes for anything stateful (like Open WebUI settings).
Pin container versions so your environment doesn’t change under you mid-sprint.
Keep your Compose file in the repo so the team shares the same setup.

Workflow: iterate like a normal developer, not a prompt scientist

Once the stack is up, you should be able to move through a loop that feels boring—in the best way.

Step 1: Validate the model behavior in Open WebUI

Start with a “conversation contract”:

The task you want
The tone/style constraints
Any format requirements (JSON, bullet points, etc.)
A few representative inputs that mirror your real data

For example, suppose you’re building a feature that drafts customer support replies. Your prompt contract might include:

“Write as the agent, ask one clarifying question if intent is ambiguous.”
“Never mention internal systems.”
“Return JSON with reply, next_question, and confidence.”

In Open WebUI, you can quickly test formatting and refusal behavior before writing code.

Step 2: Test through your app using the OpenAI-compatible endpoint

Now point your application to LiteLLM. For local development, you’ll set something like:

base_url=http://localhost:<litellm-port>/v1
api_key=local (or whatever LiteLLM expects)

The critical thing: your app code shouldn’t care whether the model is local or remote. You’re exercising the same interface you’ll use in production—just with a different host.

Step 3: Regression-test prompts with deterministic fixtures

Don’t rely on manual chat sessions forever. Build a small test harness:

Store input prompts and expected output structure (not necessarily exact wording)
Validate JSON schemas
Check that required fields exist
Ensure safety rules are followed (e.g., “don’t output PII” in your own checks)

Practical tip: assert structure and key content rather than exact strings. LLMs are probabilistic; your tests should reflect that.

The production switch: one environment variable, real deployment confidence

Local-first development only matters if it doesn’t trap you. The point of LiteLLM’s OpenAI compatibility is that you can swap backends cleanly.

When you’re satisfied with prompt quality, tool calling, and formatting:

Set your production base_url to your chosen hosted provider
Keep the rest of your app configuration the same
Redeploy

You haven’t rewritten code to match a different API. You’ve validated behavior under realistic constraints and moved forward with confidence.

Practical advice before you switch:

Keep model names abstract in config (e.g., LLM_MODEL=chat-dev mapped to a specific underlying model locally vs. prod).
Re-run your regression suite against production early. The failure modes are different when you change model families.

Common pitfalls (and how to avoid them)

Local setups are straightforward—until they aren’t. Here are the issues that commonly waste time:

“It works in Open WebUI, but not in my app”

This usually means your app prompt differs from your chat prompt, or your output parsing is too strict. Fix by:

Copying the exact system and user messages into your app
Validating output with the same schema checks you used locally

“Latency is still annoying”

Make sure you’re running a model size your machine can handle comfortably. If you’re on CPU, choose smaller models for development loops. You can always test larger models selectively.

“Docker networking confusion”

If your app container can’t reach LiteLLM, stop guessing and confirm:

the exposed port
the service name on the Compose network
whether you’re using localhost inside a container (often the wrong target)

Conclusion: build locally, ship faster, sleep better

A local AI development environment isn’t just a convenience—it’s a strategic advantage. Ollama gives you instant iteration, Open WebUI gives your team a shared interface, and LiteLLM gives your application a stable OpenAI-compatible contract. Docker Compose ties it all together into a repeatable stack.

The best part is the real-world payoff: you don’t waste budget or patience during prompt engineering, you reduce privacy risk during testing, and you move to production with minimal friction. Start local. Iterate quickly. Then ship.

Why I'm Mass-Migrating Projects from npm to pnpm

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 05 Sep 2024 00:00:00 +0000

For years I treated node_modules/ like a necessary evil: bloated, inconsistent, and occasionally cursed. Then I met pnpm and realized I’d been wasting time—and disk space—for reasons that weren’t technical at all. My npm projects worked… right up until they didn’t. pnpm fixes the problems I actually feel day to day: faster installs, stricter dependency behavior, and disk usage that doesn’t balloon quietly in the background.

The real problem with npm: it “works” until it doesn’t

Let’s be honest: npm’s classic approach makes it easy to get moving, but it also makes it easy to accumulate technical debt without noticing. In many teams and many repos, node_modules becomes a behavioral dependency. A package might accidentally reach for a transitive dependency that happens to exist because of how npm flattened the tree. That’s not “functionality.” That’s coincidence.

The most frustrating bugs are the ones that only reproduce on “fresh” machines or after a clean install. You’ll see errors like:

Cannot find module 'x'
runtime failures caused by missing nested packages
tests that pass locally because the dependency was present “somewhere” in the flattened structure

In other words: npm can mask dependency issues rather than surfacing them early.

I don’t want my build system to be a scavenger hunt. I want it to be boring—and correct.

pnpm’s storage model: fewer duplicates, more sanity

The headline difference most people miss is not the speed—it’s the storage strategy. pnpm uses content-addressable storage (store once, reuse everywhere) and then hard-links dependencies into each project.

What that means in practice:

If 20 projects use the same version of react, you don’t keep 20 physical copies of react’s files.
pnpm keeps a global store and links what each project needs.
On developer machines that run lots of repositories, this is the difference between “my disk is fine” and “why is my laptop suddenly out of space?”

I’ve experienced this firsthand while cleaning up after a long npm era: folders that looked harmless turned into multi-gigabyte node_modules duplicates. pnpm doesn’t eliminate disk usage (dependencies still exist), but it prevents the quiet multiplication that feels unavoidable with npm.

If you manage monorepos, CI caches, or a personal machine with a dozen repos, this becomes immediately tangible. My installs aren’t just faster—they’re less wasteful. That matters because storage pressure is the silent tax that slows everything else down: backups, indexing, container builds, and even editor performance.

Faster installs: not magic, just better mechanics

The second reason I’m migrating is simple: pnpm installs faster for me, and the gap has been consistent enough that I stopped doubting it.

Two mechanisms drive that improvement:

Reuse from the global store. If the package versions already exist in the store, pnpm can link rather than re-download and re-write everything.
Deterministic resolution. pnpm knows exactly what should be installed for a project, instead of leaning on whatever npm happens to flatten or hoist.

If you want a practical feel, run this on a clean environment:

Create two temporary directories: one for npm, one for pnpm.
Copy the same package.json/lockfile setup.
Blow away caches as needed (or use a fresh node environment).
Measure install time.

You don’t have to chase microbenchmarks. The goal is confidence: “Will this be faster every time I start work?” In my experience, yes. And once you’re used to it, npm’s slower churn starts to feel like dragging a chain.

Strict dependency resolution: pnpm catches the “phantoms”

Here’s the part I care about most: pnpm forces dependency truth.

With npm’s permissive hoisting/flattening behavior, you can accidentally rely on packages you never declared. The dependency might appear because another package pulled it in somewhere else in the tree. npm can make that feel “fine” until the dependency graph changes—perhaps after an unrelated upgrade.

pnpm’s strictness changes the incentive structure:

If your code imports left-pad, you must declare left-pad (or the package providing it).
If a tool expects a peer dependency, pnpm pushes you toward the correct setup instead of silently tolerating ambiguity.
If something is missing, pnpm fails early during install rather than letting it explode later in runtime.

This is not just pedantry. It’s how you prevent “works on my machine” from becoming a lifestyle.

A concrete example: accidental transitive reliance

Suppose you’re building a tool:

import somePlugin from 'some-plugin';

Your package.json includes some-plugin as a dependency, sure. But your code might also implicitly rely on some-plugin pulling in some-utils, and you never declared some-utils yourself.

With npm, some-utils might end up available via hoisting and flattening. With pnpm, you’ll discover the dependency is not actually part of your project contract. You’ll either:

add some-utils explicitly, or
update how you import/use things so the dependency is truly not needed

That’s the point: pnpm makes dependency boundaries real.

The migration path: painless for most projects (and worth it)

Let’s talk about what “mass-migration” actually looks like in the real world. I’m not suggesting you rewrite your entire ecosystem overnight. The migration for most projects is straightforward:

Pick pnpm and install it
If you’re using Corepack, you can enable it; otherwise install pnpm globally.
Generate a lockfile
Run pnpm install to create pnpm-lock.yaml based on your existing package.json. You’ll keep your current semantic intent; you’re just switching the installer and the lock format.
Update scripts with confidence
Most scripts (test, build, lint) don’t care whether npm or pnpm runs them. The command runner remains Node-centric. Where differences pop up, it’s usually around assumptions about module layout—which pnpm is intentionally stricter about.
Fix the few errors that reveal hidden dependency bugs
The first pnpm install after migration is often an opportunity, not a crisis. If something fails, it’s because the project relied on undeclared transitive dependencies. Add the missing dependency, fix peer dependency declarations, or adjust tooling configuration.
Update CI and caching
Cache pnpm’s store rather than caching node_modules blobs. This is a major win for repeat builds and keeps CI artifacts lean.

For monorepos, you’ll also want to standardize how workspaces are configured. The upside is that once pnpm is consistent across repos, the whole fleet starts behaving predictably.

What about edge cases?

The only reason you might struggle is if your project has grown into a “dependency soup” where code imports things it never declared. That’s not a pnpm problem—it’s a hygiene problem waiting to be exposed.

In practice, these fixes are usually small: add a dependency, correct a peer dependency declaration, or update a toolchain package. pnpm doesn’t just move files around; it teaches your project to be honest.

Why inertia is the only reason npm still wins

There’s a reflex in the JavaScript ecosystem: npm is “default,” so it must be the safe choice. But defaults aren’t merit. They’re momentum.

pnpm offers:

Faster installs driven by reuse and deterministic behavior
Strict dependency resolution that catches phantom dependencies early
Disk space savings from global content-addressable storage and hard-linking
A more predictable developer experience across clean installs and new machines

If your organization values stability and correctness, pnpm is the better contract. If you’re optimizing for “it happens to work today,” npm’s permissiveness can feel convenient—but that convenience comes due later, usually during upgrades or onboarding.

Mass migration isn’t about switching for novelty. It’s about removing a source of accidental complexity that has been slowing you down quietly for years.

Conclusion: make dependency truth and faster installs your default

I migrated because I was tired of invisible fragility: installs that took longer than they should, disks filling with duplicated dependencies, and bugs that only appeared after clean installs. pnpm gave me a better setup with practical benefits I can feel every day: less wasted disk, faster installs, and dependency resolution that forces correctness instead of guessing.

If you have multiple projects—or even a single repo that keeps growing—start the migration. You’ll likely fix a handful of undeclared dependencies, replace guesswork with guarantees, and wonder why you didn’t do it sooner.

Rust for the Web Is No Longer a Meme

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 24 Aug 2024 00:00:00 +0000

For years, “Rust for the web” sounded like a dare—an eccentric choice for developers who wanted to prove a point. Today it reads more like a category: Leptos for full-stack UI, Axum for pragmatic HTTP services, and a growing set of libraries that make the whole stack feel less like a science project and more like an engineering option. Rust didn’t just wander onto the web; it brought the same habits that made it dominant in systems programming—ownership, correctness tooling, and predictable performance.

This is not a call to rewrite your Next.js app because the zeitgeist demands it. It’s a case for paying attention. If you’re starting something new and reliability matters as much as speed, Rust has quietly become one of the most credible paths available.

From punchline to platform: the practical shift

The old argument against Rust on the web was simple: “You’ll be slower, and you’ll fight the tooling.” For a long time, that was true. Rust’s strengths—memory safety and fearless concurrency—were convincing, but the web ecosystem lagged in developer-experience polish.

What’s changed isn’t that Rust suddenly became “easy.” It’s that the major pieces now fit together with fewer gaps:

Leptos offers a coherent approach to full-stack Rust apps: render to the frontend (including WebAssembly) and run SSR on the server.
Axum brings a clean, composable model for HTTP servers and middleware built on the idea of “towers”—a structure that keeps request handling modular.
The broader ecosystem—logging, async runtimes, serialization, error handling—has matured enough that you can build without constantly duct-taping.

If you previously tried Rust web frameworks and felt like you were bleeding time into scaffolding, you’ll notice the difference: the “happy path” is clearer now. The best way to see it is not in benchmarks or hot takes—it’s building a small feature end-to-end.

Leptos: full-stack Rust without giving up the frontend

Leptos is one of the most compelling “real apps” stories in Rust web. The core idea is straightforward: write your UI logic in Rust, keep it reactive, and then use the right compilation target—WASM for the browser and server-side rendering for the backend.

Here’s why that matters in practice:

SSR that feels native. If you render on the server, you can serve initial HTML immediately and avoid the “blank page while JS hydrates” experience. Leptos keeps the mental model coherent by letting the server produce UI output rather than treating it as an afterthought.
A single language across the stack. That sounds like a developer-experience tagline until you experience how often you end up duplicating types between frontend and backend. With Rust on both sides, sharing data structures and validation rules becomes less painful.
Performance as a default, not a promise. The Rust toolchain nudges you toward efficient data handling and predictable costs. You still need to profile, but you’re less likely to accidentally create an unbounded mess.

Consider a typical product workflow: a page that displays a dashboard for the user, and can update part of the UI when filters change. In a Leptos-based app, you can keep the reactive UI logic in Rust, and choose whether updates happen through SSR refresh patterns, client-side hydration, or targeted interactivity. The point isn’t that Leptos replaces every existing web technique; it’s that it doesn’t force you into the worst parts of the ecosystem to get started.

Practical framing: if your team already understands Rust, Leptos reduces the “two-language” tax. If you don’t, don’t pretend this becomes instantly beginner-friendly. But it becomes easier to justify because you can ship more reliably with fewer moving parts—especially when correctness and maintainability are non-negotiable.

Axum: composable HTTP services that don’t feel like spaghetti

On the backend, Axum’s biggest contribution is that it feels architected. Many web frameworks grow organically around routing and controllers. Axum grows around request processing as a pipeline, using the tower ecosystem model.

In practical terms, that means middleware and handlers compose cleanly:

Authentication can wrap routes without being entangled with business logic.
Rate limiting can be applied at the appropriate layers.
Tracing/logging can capture consistent context for every request.
Error handling can be centralized without turning into a nested conditional jungle.

If you’ve ever tried to retrofit observability into a web service and ended up rewriting half the codebase, you already understand why this matters. With Axum, it’s natural to set up middleware once, then reuse it across routers and services.

A concrete example: imagine an API with endpoints under /api/v1/*. You can structure your app so that:

A first middleware extracts and validates a session token.
A second middleware enforces rate limits per user or per IP.
Tracing middleware attaches request IDs and user IDs to spans.
Handlers focus on transforming validated input into domain actions.

You don’t just get clean code—you get a system where changing policy (say, tweaking limits or auth rules) is localized. That’s a reliability win you feel months later, not just a stylistic preference.

The Rust web stack: mature enough to bet on

The most honest way to evaluate a framework is to ask: “When I hit the edges, will I have to rewrite everything?” Rust’s web ecosystem is now mature enough that most common edges are navigable:

Serialization and validation are well-trodden. You can structure request and response types without turning your codebase into a stringly-typed mess.
Async and concurrency are first-class. Rust’s async story is not magic, but it’s consistent and supported by the ecosystem.
Error handling is ergonomic when you adopt a pattern early. The best Rust web code usually has a predictable error type strategy rather than ad-hoc panics.

You should still expect some roughness if you go looking for the most bleeding-edge patterns. But if you stick to the mainstream crates and patterns, the experience is less “reinvent the wheel” and more “build the wheel you need.”

A useful litmus test: if you can implement “create user,” “login,” and “fetch protected resource” in a week—with logs, tracing, and meaningful errors—you’re not in a science project anymore. Rust web apps can do that now, without requiring heroic effort.

Should you rewrite your Next.js app? (No.)

Let’s kill the wrong project. Rewriting an existing Next.js app in Rust is rarely the right move, because the problem isn’t the technology—it’s the cost of change.

You should consider Rust for the web when one of these is true:

You’re starting a new product and want a long runway where correctness and reliability are part of the architecture, not a post-launch scramble.
Latency and resource efficiency matter—think backend services that need to handle sustained traffic predictably.
Security and robustness are core requirements, and you want the compiler and tooling to eliminate entire classes of bugs.
Your team already ships in Rust and can leverage shared expertise instead of forcing a full re-training cycle.

But if you already have a mature frontend, a working deployment pipeline, and a healthy developer workflow, Rust isn’t a reason to blow it up. Interoperability is also real here: you can gradually adopt Rust for specific services (APIs, workers, performance-sensitive components) and leave your frontend in its current shape. The web is big enough for polyglot systems—just don’t let “polyglot” become “we never finished deciding.”

A good compromise is architectural: keep Next.js for the UI if that’s where your team shines, and use Rust services behind it where performance, safety, or concurrency dominate. That yields tangible benefits without risking a full rewrite.

The bottom line: Rust is a legitimate web choice

Rust for the web is no longer a meme because it’s no longer purely theoretical. With Leptos, you can build full-stack apps with SSR and WebAssembly-based frontend interactivity while staying in Rust. With Axum, you get a backend architecture that supports composable middleware, clean request pipelines, and maintainable error handling.

Here’s the opinionated guidance: don’t rewrite what works. But if you’re choosing a stack for something new—especially something that must be stable under load—Rust deserves a serious place on your shortlist.

The language that conquered systems programming is finally taking the web personally. And this time, it brought the tools to back it up.

Conclusion

Rust for the web has crossed the line from curiosity to credible platform. Leptos and Axum demonstrate that you can build modern, full-stack applications with composable architecture and production-oriented correctness. If performance and reliability are part of your requirements—not slogans—Rust is a smart, defensible choice for new projects.

The Quiet Rise of Server-Sent Events Over WebSockets

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 12 Aug 2024 00:00:00 +0000

Most “real-time” apps don’t need real-time in both directions. They need the server to reliably tell the browser what’s happening—notifications, progress, live updates, streaming responses—without the operational overhead of bidirectional sockets. That’s exactly why Server-Sent Events (SSE) have been steadily winning mindshare. They do a surprising amount of what WebSockets do, with a fraction of the complexity.

What most apps actually mean by “real-time”

When teams say “we need WebSockets,” they often mean one narrow thing: the server should push updates to the client.

Think about the common list:

Notifications (“your report is ready”)
Live dashboards (new events, status changes)
Upload or job progress (percent complete, logs)
Streaming AI responses (tokens as they’re generated)
Server-driven UI updates (ban someone, expire a session, refresh a card)

In all of these, the client rarely needs to send a continuous stream to the server over the same channel. Sure, the client will sometimes click a button or acknowledge something—but that’s request/response territory, not a persistent two-way socket conversation.

That mismatch is the core reason SSE keeps showing up in production architectures: it matches the problem shape.

SSE vs WebSockets: same outcome, different cost

At a high level:

WebSockets establish a full-duplex connection: both sides can send messages at any time.
SSE establishes a server-to-client stream over plain HTTP semantics: the browser opens a connection, and the server writes events down that pipe.

Here’s the practical difference that matters:

SSE is designed for one-way streams

If your “real-time” feature is inherently unidirectional, SSE is the clean fit. You don’t spend engineering time building message routing, buffering, or client-side state machines for traffic you don’t actually need.

SSE plays nicely with the web platform

SSE uses HTTP, which means:

It works naturally with typical web infrastructure.
It can reuse existing routing, authentication patterns, and logging.
It tends to be easier to reason about when something goes wrong.

WebSockets can still be absolutely right—especially for truly interactive, bidirectional workflows like multiplayer games or collaborative editors. But those are a smaller slice of the “real-time” pie than most teams admit during planning.

A real-world pattern: live progress without a socket

Let’s take a concrete example: a user starts a long-running job (say, generating a report). The UI needs to update the progress bar and display incremental log lines.

With SSE, you can do this cleanly:

The browser requests /jobs/{id}/events to open the stream.
Your server writes events like progress and log.
The client updates the UI as messages arrive.
If the connection drops, SSE can reconnect and continue.

On the server side (Node/Express-style pseudo-implementation):

Set Content-Type: text/event-stream
Flush headers immediately
Write lines in SSE format:
- event: progress
- data: { "percent": 42 }
Repeat as progress changes

On the client side, you use the built-in EventSource API:

Open the stream
Listen for named events
Update UI components in real time

The key benefit isn’t just fewer lines of code—it’s fewer moving parts. You avoid designing a protocol for bi-directional messages when all you need is “server tells client, reliably.”

Reliability and reconnection: “it should come back” is built in

One of the underappreciated reasons SSE is popular is that it embraces a reality most teams eventually face: connections fail.

Mobile networks drop. Load balancers recycle connections. Deploys happen. Browsers navigate away and back. The question becomes: what do you do when the stream interrupts?

SSE’s model is built around reconnection behavior. You can take advantage of that by using event IDs and the Last-Event-ID header to let clients resume from where they left off.

Practical advice:

Include an id: field per event when ordering matters.
Make your server store (or recompute) recent event history for a short window.
Design the client to treat the stream as “eventually consistent,” not a perfectly uninterrupted transcript.

This approach drastically reduces the “we lost the message” edge cases that haunt real-time systems. With WebSockets, you can implement reconnection too, but you’re doing more work and owning more failure modes.

Infrastructure reality: SSE tends to be boring (in a good way)

Boring infrastructure is a competitive advantage. SSE generally works over HTTP and therefore tends to require less special handling at the edges—especially when compared to WebSocket-specific plumbing.

In practice:

Load balancers often behave more predictably with HTTP connections than with protocol-upgraded channels.
Reverse proxies usually route SSE traffic using existing HTTP rules.
Observability (logs, metrics, traces) often becomes simpler because everything is still fundamentally HTTP traffic.

That doesn’t mean SSE is magic. You still need to think about:

Connection limits on servers and proxies
Timeouts for long-lived HTTP connections
Scaling strategies (more on that below)

But if your team has ever spent time untangling “why does WebSocket fail only in staging behind this proxy,” SSE can feel like a timeout governor: you just get fewer surprises.

Scaling and load: what to plan for with SSE

Long-lived connections aren’t free. Regardless of technology, you have to plan for how many concurrent clients you’ll support and how your system will behave under load.

The good news: SSE has a straightforward scaling story.

Use horizontal scaling-friendly patterns

Run your SSE endpoint behind your normal HTTP load balancing.
Ensure sticky sessions are not required for correctness. If they are, you’ll feel it quickly during scaling events.
Avoid “one stream per worker” designs that require shared in-memory state unless you’re very careful.

Externalize event distribution

If multiple app instances must deliver events for the same client stream, you’ll likely want a shared pub/sub mechanism (or a queue-based architecture) to route events to the right instances.

Keep event payloads small

Streaming is not a license to send megabytes per message. For progress updates, send compact updates and let the client fetch larger data on demand.

Handle backpressure intentionally

If the client can’t process events quickly, you can end up building buffers. Treat your SSE stream as a “live feed,” not a guaranteed delivery log unless you implement buffering and replay semantics yourself.

A solid heuristic: design the event stream so that missing intermediate updates doesn’t break the UI. For example, a progress bar can usually jump from 40% to 55% without needing every in-between step.

When WebSockets are still the right call

SSE is not a blanket replacement. WebSockets win when you truly need the bidirectional behavior.

Choose WebSockets when you need:

Client-to-server streaming (e.g., real-time input streams)
Collaborative editing patterns where both sides send frequent updates
Low-latency command/control where you want the flexibility of full-duplex messaging
A single persistent channel that carries multiple message types in both directions

Even then, it’s worth asking whether you can split responsibilities. A common pattern is:

Use SSE for server → client updates (status, notifications, streaming output)
Use regular HTTP requests for client → server actions (commands, mutations)
Reserve WebSockets only for the interactive bidirectional subset

That hybrid approach often reduces the blast radius of failures and simplifies your system architecture without losing functionality.

Conclusion: SSE is the pragmatic default for server-to-client “real-time”

WebSockets get the headlines, but SSE has the better fit for most real-time features. If your primary job is server-to-client updates—notifications, feeds, progress, and streaming—SSE delivers that value with a simpler mental model, more natural integration with the web stack, and built-in reconnection behavior.

The quiet rise of SSE isn’t a fad. It’s teams choosing reliability and simplicity over over-engineering.

The State of WebAssembly in 2024: Finally Beyond the Hype Cycle

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 06 Aug 2024 00:00:00 +0000

WebAssembly stopped being a promise the moment teams started shipping it—not as a science project, but as a dependable part of production systems. In 2024, the center of gravity is clear: not “replace JavaScript,” but “run safe, portable code anywhere”—with predictable performance and much less operational drama than you get from native binaries or server-side polyglot sprawl.

The hype cycle didn’t break WebAssembly; it just delayed the boring parts that matter: stable runtimes, interoperable modules, and an ecosystem good enough to trust with real workloads. What’s different now is that the pieces are finally converging.

Why WebAssembly Went Through the Trough (and What Changed)

If you’ve followed the story, you remember the early pitch: compile to WASM, ship everywhere, get near-native performance in the browser. The problem wasn’t that WASM was bad—it was that too many use cases depended on assumptions that weren’t ready.

Early friction clustered around a few themes:

The runtime boundary was unclear. WASM itself is a binary format, but “running code” still depends on how it interacts with the outside world (files, networking, clocks, environment variables).
Tooling and interoperability were inconsistent. Teams could compile a module, but composing multiple languages/modules into a coherent system was still messy.
Performance arguments weren’t always actionable. “Near-native” is true in the right circumstances, but production systems care about latency budgets, startup costs, memory behavior, and operational overhead—not benchmark trivia.

In 2024, those problems are shrinking. WASI preview 2 is an attempt to make “system interfaces” more capable and standardized. The component model is an attempt to make module composition less brittle and more language-agnostic. Together, they address the core operational question: how do you safely run code in a sandbox without turning every integration into a bespoke engineering project?

WASI Preview 2: The Missing Piece Between “Sandbox” and “System”

WASI—the WebAssembly System Interface—has always been the bridge between “pure WASM” and something closer to a real application. But older iterations left a gap for production workloads that need richer, more predictable interactions with their host environment.

WASI preview 2 matters because it aims to improve how WASM code imports capabilities from the host. Instead of treating the host as a vague black box, you can think in terms of capabilities and well-defined imports. That shift is crucial when you’re trying to run untrusted or semi-trusted code safely.

Here’s the practical difference: in a production platform, you don’t want every WASM module to come with a custom runtime shim. You want a consistent contract. When WASI gets that contract closer to “good enough for real systems,” teams can focus on what matters—business logic, security boundaries, and performance—rather than on integration archaeology.

A good mental model is this: WASI preview 2 doesn’t magically eliminate all complexity, but it reduces the number of ways “running WASM” can mean “doing a one-off port.” That’s how you get from prototypes to repeatable deployments.

The Component Model: Stop Treating WASM Like a Binary Blob

WASM modules aren’t just bytecode; they’re artifacts that need to interoperate. The early reality was that composition often meant “wire together exports and imports, hope signatures match, and pray you didn’t miss a subtle ABI detail.”

The component model is the response. It’s designed to make WebAssembly interoperation more structured—so you can treat WASM units like components with explicit interfaces rather than low-level binary expectations.

Why this changes the game:

Fewer integration surprises. When interfaces are clearer, you don’t end up debugging “why doesn’t this call land correctly?” at the worst possible time.
More reliable multi-language ecosystems. Teams can mix languages and toolchains more confidently when the boundary contract is standardized.
Cleaner composition for platforms. If your infrastructure expects components, you can build catalogs, versioning strategies, and compatibility policies that don’t rely on tribal knowledge.

Consider a storefront extension system. You might have modules compiled from different languages—some authored by internal teams, others contributed by partners. Without strong interface discipline, every module becomes a bespoke integration. With the component model approach, you can create guardrails: stable interface versions, consistent data shapes, and predictable host calls.

The result isn’t just developer convenience. It’s operational sanity—fewer risky updates, easier rollbacks, and a system that scales beyond a single team’s preferences.

Production Proof Points: Platforms That Put WASM to Work

The real story of WebAssembly in 2024 isn’t that “it’s possible.” It’s that major platforms are using it for specific, high-value scenarios where WASM’s constraints are actually advantages.

Shopify: Safe storefront extensions with WASM modules

Shopify’s use of WASM for storefront extensions highlights a key strength: sandboxing with portability. Storefront customization is inherently extensible—and inherently risky. Running extensions in WASM lets platforms limit what extensions can do, while still achieving low-latency execution compared to heavier isolation mechanisms.

In other words, Shopify isn’t trying to turn every storefront feature into WASM. It’s using WASM where it provides leverage: safe extensibility without giving every extension the keys to the kingdom.

Figma: Performance-sensitive behavior benefits from WASM

Figma’s performance depends on interactive workloads where milliseconds matter. WASM is a compelling option when you want deterministic performance characteristics and the ability to run compute-heavy logic without forcing the entire product into a single language stack.

The important nuance: WASM becomes most valuable when it targets a “hot path”—the part of the app that truly benefits from compiled performance and consistent execution behavior.

Cloudflare Workers: WASM for portable server-side workloads

Cloudflare Workers is a canonical example of “run code safely, fast, and consistently at the edge.” WASM support for workloads here aligns with a broader trend: edge platforms need portability across runtime environments, while still enforcing isolation boundaries.

Again, the pitch isn’t “WASM instead of JavaScript.” It’s “WASM for workloads that benefit from predictable sandboxing and language flexibility.”

Fermyon Spin: WASM as a microservice deployment primitive

Fermyon’s Spin framework takes the “WASM beyond the browser” idea and turns it into a deployable microservice model. The advantage isn’t only isolation—it’s also packaging and portability. When you can ship services as WASM artifacts with consistent host semantics, you reduce drift between environments.

This is what operational teams care about: reproducibility. If your service behavior depends on a particular runtime and interface contract, you want that contract to be stable across staging and production.

Practical Guidance: When WASM Is a Smart Bet (and When It Isn’t)

Here’s my blunt take: WASM is not a universal migration strategy. It’s a precision tool.

Use WASM when…

You need strong sandboxing for third-party or untrusted code. Storefront extensions and plugin architectures are the obvious fits.
You want language freedom without operational chaos. Teams can use different ecosystems and still deploy a common runtime artifact.
You have performance-critical compute. Think parsing, transformation pipelines, media processing, optimization loops, or other workloads where compiled execution can reduce overhead.
You care about portability across hosts. WASM gives you a path to move code between environments more cleanly than native binaries.

Don’t use WASM when…

Your work is mostly I/O orchestration. If you’re mostly waiting on network calls or driving UI logic, the cost/benefit may not justify the boundary complexity.
Your app needs deep, bespoke OS integration. WASI is evolving, but you still have to design around what the host interfaces provide.
You can’t commit to interface contracts. The component model helps, but you still need discipline in data formats, versioning, and compatibility strategy.

A pragmatic workflow looks like this:

Identify one subsystem that is compute-heavy or security-sensitive.
Define the boundary: what inputs/outputs cross the WASM/host line, and what capabilities the module requires.
Standardize interfaces early—especially if multiple teams or partners will contribute modules.
Measure end-to-end latency, not just microbenchmarks. Startup time, memory behavior, and invocation frequency often matter more than raw execution speed.
Treat compatibility like a product feature. Version your component interfaces and document the upgrade path.

The Conclusion: WASM Has Earned Its Seat—But Only in the Right Rooms

The state of WebAssembly in 2024 isn’t “everything will be WASM.” It’s more interesting than that: WASM is finally reaching the stage where platforms can use it as a reliable deployment boundary, not a novelty.

WASI preview 2 and the component model are the quiet workhorses making this practical. And the production examples—Shopify’s extensions, Figma’s performance needs, Cloudflare Workers’ edge execution, and Fermyon Spin’s microservice deployment—show the pattern: WebAssembly wins when you need safe portability with near-native performance, applied to focused, high-value workloads.

If you’re considering WASM today, don’t ask whether it can replace your stack. Ask what piece of your system benefits from a tighter sandbox, cleaner interfaces, and predictable execution. That’s where WebAssembly stops being hype and becomes engineering.

Terraform's Dominance Is Slipping and Pulumi Knows Why

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 31 Jul 2024 00:00:00 +0000

For years, Terraform rode a wave of “configuration as truth”: describe the desired state in HCL, let the engine reconcile reality, and move on. It worked—because the industry needed standardization more than it needed elegance. But as teams matured, a different problem emerged: infrastructure isn’t just configuration. It’s software. And that’s exactly where Pulumi starts to win.

HCL Solved a Problem—Then Developers Hit the Wall

HCL is a reasonable idea. Terraform’s declarative model, and its promise that you can model infrastructure resources in a dedicated language, made it approachable and portable. When you’re wiring up a few services, modules feel clean, state management is predictable, and the learning curve is manageable.

The wall comes when the infrastructure complexity stops being “a bunch of resources” and becomes “a system with behavior.”

Real teams don’t build static stacks. They build conditional deployments (prod vs. staging), multi-tenant environments, environment-dependent naming rules, conditional networking, and resource graphs that vary depending on runtime inputs. In Terraform, this logic exists—but it’s awkward. You end up encoding software patterns using a declarative toolchain with:

Expressions that get hard to read and debug
Repeated “plumbing” for maps, locals, and dynamic blocks
Modules that grow into mini-programs with limited abstraction power
Copy/paste patterns that resist refactoring because the language fights you

HCL isn’t wrong; it just isn’t optimized for how developers naturally reason. When your infrastructure begins to look like application code—because it effectively is application code—you feel the friction.

“Infrastructure as Configuration” Becomes a Productivity Tax

Here’s the uncomfortable truth: infrastructure-as-configuration treats the most valuable part of modern engineering—iteration—as an afterthought.

Most engineering teams expect to do the following routinely:

write small, testable units
factor shared logic into reusable abstractions
refactor safely with IDE support
use existing language tooling for linting, formatting, and static analysis
apply conventional control flow patterns (loops, conditionals, early returns)

Terraform can do some of this, but it doesn’t do it in the way software engineers expect. Instead, you’re limited to the constructs Terraform provides, and “logic” often becomes data transformation inside expressions. That can be fine until you need robust branching, non-trivial orchestration, or you just want the simplest possible way to validate inputs and invariants.

Practical example: multi-tenant provisioning
Imagine a platform that creates a network, deploys a database, and configures application access per tenant. Each tenant has features toggled based on a configuration file—some tenants need private endpoints, others don’t; some require extra security controls; others have simpler defaults.

In a configuration-first approach, you’ll represent this as deeply nested variables and conditionals. The resulting code becomes a maze of maps, merges, and dynamic blocks. Even if it’s correct today, future changes are expensive because the “program” isn’t truly a program—it’s a declaration expressed in a constrained DSL.

Once you feel that pain, the argument stops being philosophical. It becomes economic: time spent deciphering infrastructure code isn’t building value. It’s paying a tax.

Pulumi Treats Infrastructure Like Code—Because It Is

Pulumi’s core bet is straightforward: define infrastructure in real programming languages—TypeScript, Python, Go, and others—so your infrastructure enjoys the full power of the software toolchain.

That means you get real loops, real conditionals, and real functions. But more importantly, you get structure. You can create abstractions that match how developers think rather than forcing everything through the grammar of HCL.

Consider the same multi-tenant scenario in a general-purpose language:

You can model the tenant configuration as data structures.
You can write a function that returns the desired resources for a tenant.
You can reuse shared logic naturally.
You can validate inputs early (before deployment) and fail fast.

Example (TypeScript-style pseudocode):
You might have a provisionTenant(tenantSpec) function that:

computes naming and tags
decides whether to attach private networking
creates the database with the right configuration
outputs connection details
optionally enables extra security resources

That’s not just “easier.” It’s more maintainable. When the team grows, onboarding gets faster because infrastructure code reads like code. When requirements change, refactoring isn’t a gamble.

And because Pulumi supports unit testing around your infrastructure logic, you can test the behavior you care about. You’re no longer restricted to hoping a deployment succeeds as your primary validation strategy.

Tooling Compounds: Refactor, Test, and Review Faster

The strongest argument for Pulumi isn’t that it can express infrastructure differently—it’s that it plugs into the development workflow teams already have.

When your infrastructure is written in a real language:

IDE refactoring works. Rename a function or extract a module and trust your tooling to update call sites.
Static analysis works. Catch obvious issues before you run CI/CD.
Unit tests are possible. You can test logic that computes resource properties, naming conventions, and policy decisions.
Code review becomes sharper. Reviewers can reason about control flow, helper functions, and invariants instead of parsing nested expressions.

This matters in practice because infrastructure failures are rarely “random.” They’re almost always caused by changes: new tenants, new regions, updated credentials, toggled features, or altered security requirements. If your infrastructure logic is difficult to validate locally, you end up moving mistakes downstream—into the apply step—where feedback is slower and the blast radius is larger.

Pulumi’s approach doesn’t eliminate the need for careful review and deployment discipline. It reduces the chance that you can’t even reason about the system you’re about to deploy.

Terraform’s Ecosystem Is Real—But Pulumi’s Model Is the Point

Terraform’s ecosystem is undeniably large. There are countless modules, a huge base of existing knowledge, and mature patterns for state management and dependency graphs. For many teams, that ecosystem has been enough to justify the tradeoffs.

But the tradeoffs are why dominance is slipping.

When infrastructure engineering moves from “write once, deploy many” to “continuously evolve,” the ability to treat infrastructure as a maintainable software codebase becomes a strategic advantage. Pulumi’s promise isn’t only flexibility—it’s that your infrastructure code can be engineered like the rest of your systems.

And the market has been quietly acknowledging this. CDK for Terraform (CDKTF) is HashiCorp’s admission that HCL wasn’t enough for many developers. CDKTF lets you define Terraform configurations using a programming language and generates HCL under the hood. In other words: even Terraform is moving toward the “actual code” model because teams want familiar abstractions, reusable libraries, and real control flow.

That doesn’t mean HCL will disappear. It means the center of gravity is shifting. People want the Terraform engine and module ecosystem sometimes, but they increasingly want the developer experience benefits that come from writing infrastructure the way developers actually write software.

Choosing the Right Approach: A Practical Decision Checklist

If you’re evaluating whether to adopt Pulumi (or whether to stick with Terraform), don’t get distracted by debates about “purity.” Use a checklist that reflects how your team builds.

Choose Pulumi if:

Your infrastructure logic is already complex (conditional resources, multi-tenant patterns, environment-specific branching).
You want to reuse abstractions and refactor confidently with IDE tooling.
You would benefit from unit tests for infrastructure decisions (naming, policy enforcement, computed configuration).
Your team is staffed by developers who expect real code workflows, not DSL workarounds.

Stick with Terraform if:

Your organization relies heavily on existing HCL modules and workflows, and migration would be costly.
Your deployments are mostly static and the declarative model stays readable.
You prefer the current ecosystem’s module-driven development and your teams are already productive with it.

And here’s the compromise that often works: if you’re committed to Terraform but feel the pain of HCL logic, consider reducing logic density—push computation into fewer, cleaner modules, standardize naming and tagging, and aggressively document module contracts. If that still isn’t enough, Pulumi’s model may be the real fix.

Conclusion: Infrastructure Is Software—Stop Treating It Like Configuration

Terraform’s HCL was a milestone: it made infrastructure approachable and standardized. But software teams didn’t stop at “approachable.” They kept building systems that behave, evolve, and grow. At that point, infrastructure isn’t configuration—it’s software engineering.

Pulumi wins because it aligns infrastructure with how developers actually work: real programming languages, real abstractions, unit-testable logic, and refactoring support that doesn’t punish you for being a modern team. Terraform’s ecosystem will keep it relevant, but the direction of travel is clear: infrastructure-as-actual-code beats infrastructure-as-configuration every time.

FastAPI Is Eating Flask's Lunch and Django Should Pay Attention

abdecastro@protonmail.com (Antonio B De Castro) — Fri, 19 Jul 2024 00:00:00 +0000

Python’s web ecosystem has always moved fast, but lately it feels like one framework is quietly turning “best practices” into defaults. FastAPI takes the things developers already reach for—type hints, async/await, and Pydantic models—and then does something Flask and Django users often have to cobble together: it turns that structure into request validation, predictable serialization, and excellent documentation automatically. If you’re building APIs in 2024, you’re either choosing FastAPI because it fits, or you’re choosing something else for reasons that must be painfully specific.

The real shift: type hints stop being decoration

Flask is flexible, which is another way of saying it leaves responsibility on the developer. You can validate input, generate schemas, document endpoints, and serialize responses—but you build that stack yourself. Django can be even more “batteries included,” but its API story tends to be oriented around forms, models, templates, and server-rendered workflows—then adapted for APIs.

FastAPI flips the philosophy: it treats type hints as part of the application contract. Instead of “Here’s a function that receives JSON,” the code says “Here’s a function that receives a specific model, and here’s what it returns.” That contract is then used for three practical outcomes:

Automatic request validation
Automatic response serialization
Automatic API documentation

Consider an endpoint that creates a “user” resource. With FastAPI, you define a request model and a response model, and the framework enforces and documents them without extra glue code.

from fastapi import FastAPI
from pydantic import BaseModel
from uuid import UUID, uuid4

app = FastAPI()

class UserIn(BaseModel):
 email: str
 age: int

class UserOut(BaseModel):
 id: UUID
 email: str
 age: int

fake_db = {}

@app.post("/users", response_model=UserOut)
def create_user(payload: UserIn) -> UserOut:
 user_id = uuid4()
 user = UserOut(id=user_id, email=payload.email, age=payload.age)
 fake_db[str(user_id)] = user
 return user

You’re not writing “validation logic.” You’re writing data shapes, and FastAPI does the rest. If a client sends "age": "thirty", it fails fast with a structured error. That’s the difference between a framework that assists and a framework that enforces.

Automatic docs aren’t a luxury—they’re leverage

Swagger UI and OpenAPI documentation are often treated as a checkbox. FastAPI makes them a byproduct of doing real modeling work.

When you define endpoints with typed inputs and response_model, FastAPI can generate an OpenAPI schema and interactive docs automatically. That matters because documentation becomes part of the workflow, not a follow-up chore. Your API stops being “something in a README” and becomes something clients can explore and test immediately.

Try this mindset shift: imagine your team shipping an API to another team that needs examples, field meanings, and error formats. With Flask, you either maintain docs manually or integrate a documentation library. With Django, you often rely on Django REST Framework tooling and serializers—useful, but heavier. With FastAPI, the contract you already coded becomes the contract the docs show.

Even better: the docs tend to stay accurate because the source of truth is the Python typing and the Pydantic models. That’s how you reduce the classic “docs drift” problem: you don’t need discipline so much as you need the framework to make correctness the path of least resistance.

Validation that reduces back-and-forth (and incidents)

Most API failures aren’t dramatic—they’re mundane. A client sends the wrong field name. A number arrives as a string. A nested object is missing. Suddenly you’re parsing errors from logs, guessing what the caller meant, and rebuilding a tiny spec in a Slack thread.

FastAPI’s validation pipeline is one of its most practical advantages. Because Pydantic models define constraints and types, FastAPI can:

reject invalid requests before they hit your business logic
produce consistent error responses
keep serialization predictable

You can also express constraints directly in the model. For example, if an email must be non-empty and age must be within a range, say so in code and let the framework enforce it.

from pydantic import BaseModel, Field

class UserIn(BaseModel):
 email: str = Field(min_length=3)
 age: int = Field(ge=0, le=120)

Now your API becomes harder to misuse. That’s not “developer experience” in a fluffy sense; it’s fewer broken requests reaching production. It’s less time spent writing guardrails, because you’ve already encoded them.

Async in the places that matter

FastAPI also benefits from async/await being a first-class citizen rather than an afterthought. Async is most valuable when your API spends time waiting: database calls, HTTP requests to other services, file I/O, and streaming responses.

Flask can work with async-like patterns, but it historically hasn’t made the async model feel native. Django can do async views, but using Django for high-throughput API services often feels like dragging a feature-rich environment into a job it wasn’t primarily designed for.

In FastAPI, async endpoints feel straightforward:

from fastapi import FastAPI
import httpx

app = FastAPI()

@app.get("/weather")
async def get_weather(city: str):
 async with httpx.AsyncClient() as client:
 resp = await client.get(f"https://example.com/weather?city={city}")
 data = resp.json()
 return {"city": city, "forecast": data}

This isn’t about chasing “async hype.” It’s about having a framework that doesn’t fight you when you need I/O concurrency. If your API integrates with other services (which most do), async can improve responsiveness and reduce resource burn.

Flask feels primitive—because you’re rebuilding infrastructure

Flask isn’t a bad framework. It’s lightweight. But lightweight cuts both ways: when your application grows into an API platform, you end up stitching together:

request parsing and validation
serialization
error handling patterns
OpenAPI schema generation
dependency injection for common concerns (auth, database sessions, etc.)

FastAPI collapses much of that into the framework itself. The result is not just faster development—it’s fewer mismatched conventions across endpoints.

A practical example: authentication and dependency injection.

With FastAPI, you typically model authentication as a dependency and reuse it across endpoints. That encourages consistency: every endpoint that needs auth declares it clearly in the function signature, and the framework calls the dependency appropriately.

You can keep Flask for simple services, internal tools, or projects where the API surface is tiny and unlikely to grow. But if you’re building a serious API product—one that needs validation, documentation, and predictable contracts—FastAPI’s approach tends to win because it keeps the complexity where it belongs: in the framework, not in your codebase.

Django shouldn’t ignore APIs anymore

Django’s “batteries included” identity is real. But that strength can become friction for API teams who want speed, clean typing, and automatic schema-driven behavior. Django’s API ecosystem (often through Django REST Framework) is capable, but it can feel heavy when you’re trying to move quickly and keep interfaces explicit.

Here’s the honest trade: Django is an excellent general-purpose web platform. FastAPI is a surgical tool for API development. When you combine typing-driven contracts with automatic validation and docs, you get a development loop that’s hard to beat—especially when your team cares about correctness and client integration.

Django can—and should—learn from that philosophy. Even if you keep Django for the core site, FastAPI is increasingly the “API front door” in modern architectures. Common patterns include:

Django for admin and core business workflows
FastAPI for high-velocity external API endpoints
Shared domain logic where it makes sense, without forcing one framework to become the other

If you’re a Django shop, this doesn’t mean abandoning Django. It means acknowledging that an API-centric workflow is now a first-class requirement, and FastAPI is delivering it with less friction.

Conclusion: choose the framework that turns contracts into behavior

FastAPI isn’t “winning” because it’s trendy. It’s winning because it treats the API contract as executable code—using type hints and Pydantic models to generate validation, serialization, and documentation. Flask’s flexibility and Django’s batteries are both valuable, but if you’re building new APIs in 2024, you should ask a blunt question: do you want to build the plumbing yourself, or do you want your code’s structure to drive correctness?

If your answer is the latter, FastAPI is the default choice. And if you’re still investing in Flask or Django for API work, make sure you can justify the extra effort—because clients increasingly prefer APIs that are self-describing, strictly validated, and effortless to integrate.

Why I'm Bullish on Elixir for AI Applications

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 13 Jul 2024 00:00:00 +0000

AI backends are no longer “a call, then a response.” They’re now a choreography problem: juggling multiple LLM requests at once, streaming partial output to the user, recovering from failures without collapsing the whole service, and staying polite with rate limits. After years of watching teams rebuild orchestration logic in brittle ways, I’m increasingly bullish on Elixir—not because it’s fashionable, but because the BEAM VM was built for this exact kind of concurrency.

The orchestration problem AI creates (and why most stacks feel bolted on)

If you’ve built an AI feature, you’ve already felt the complexity that comes with “just call the model.” A real assistant might:

request multiple LLM calls in parallel (e.g., rewrite + tool plan + answer draft),
stream tokens back to the UI as they arrive,
retry or fail over when one provider times out,
enforce per-provider rate limits and connection limits,
keep state consistent even when requests complete out of order.

Most backends solve this with a patchwork of threads, async callbacks, job queues, and custom retry logic. You can make it work—but the implementation often ends up tightly coupled to one specific provider’s behavior or one specific streaming format. When requirements evolve (new models, new vendors, new streaming semantics), the glue code becomes the product.

Elixir starts from a different premise: concurrency is a first-class runtime feature, not an add-on.

The BEAM is basically an AI orchestration engine in disguise

Here’s the pitch I keep coming back to: the BEAM VM’s concurrency model isn’t a “general-purpose” solution. It’s tailor-made for orchestrating lots of concurrent, independent tasks.

Elixir gives you:

Lightweight processes: create thousands (or more) without micromanaging threads.
Message passing: tasks coordinate by sending messages, not by contending over shared mutable state.
Supervision trees: failures are contained and recovered in predictable ways.
Fault-tolerant design patterns: the runtime encourages architectures where components can crash safely.

That maps beautifully to an AI backend.

A concrete example: parallel LLM calls with deterministic coordination

Imagine an endpoint that must:

Ask for “plan” from Model A,
Ask for “critique” from Model B,
Ask for “final answer” from Model C,
Stream the final answer as tokens arrive,
If critique fails, still produce an answer (but with fewer safeguards).

In Elixir, you can structure each LLM request as a separate process. Each process sends results back to a coordinator process as messages arrive. If one child process crashes due to a timeout, the supervisor can restart it (or replace it) according to a policy you define—without bringing down the whole request flow.

This is a mindset shift: you aren’t trying to prevent failures; you’re designing for them.

Streaming is not an afterthought—it’s the shape of the solution

For AI UX, streaming isn’t optional. Users don’t want to wait for “the whole paragraph.” They want momentum: tokens appearing, thoughts forming, partial results updating.

Elixir’s concurrency model supports streaming naturally because you can treat “token arrival” as an event stream. Instead of buffering everything before responding, you can forward partial data as it comes in.

Then comes the practical magic: if you’re using Phoenix LiveView, you can stream updates from the server to the browser in real time. In practical terms, your backend doesn’t need to invent yet another websocket layer or reconcile UI state manually. LiveView is already built around incremental UI updates driven by server events.

What this looks like in practice

Say your system streams tokens from the provider to your backend, and your backend streams them to the UI:

A “streaming” process consumes provider chunks (tokens, deltas, tool events).
It sends each chunk to a coordinator (or directly to a UI state process).
LiveView receives events and updates the DOM incrementally.

If the stream is interrupted, you can decide whether to:

retry from the last known state,
fall back to a non-streaming response,
or gracefully stop and show a “partial output” message.

That’s exactly where supervision and message passing shine: resilience without spaghetti.

Rate limits, connection pools, and provider chaos—managed, not endured

LLM providers are not predictable. One vendor throttles aggressively. Another occasionally hangs instead of timing out cleanly. Some have streaming quirks. Others return malformed partial chunks. And they all have different rate limits.

A mature AI backend needs to enforce constraints systematically—per provider, per key, sometimes per tenant.

In Elixir, the runtime encourages you to centralize control. For example:

Connection pooling can be managed by dedicated processes responsible for HTTP clients.
Rate limiting can be enforced by a token-bucket process per provider.
Circuit breakers can be modeled as processes that track failures and temporarily refuse new work.
Retries can be explicit and bounded, tied to supervision policies.

Here’s the opinionated part: if your provider orchestration logic is scattered across controllers and random utility functions, your future self will hate you. In Elixir, you can concentrate orchestration in the processes that own the policy.

Practical tip: keep coordination separate from I/O

A clean pattern is to separate:

the process that talks to the LLM API (I/O + parsing),
the process that coordinates workflow (what to do when which result arrives),
the process that manages policy (rate limiting, retries, fallback routing).

This reduces coupling and makes it easy to swap providers without rewriting your whole application.

The “AI stack” in Elixir isn’t one thing—it’s a coherent ecosystem

It’s tempting to claim Elixir is a complete AI solution, but that’s not the real advantage. The real advantage is that Elixir plays well with an evolving AI ecosystem while staying strong where it matters: concurrency, orchestration, and streaming.

A few components worth calling out:

Nx for numerical computing when you need tensor operations or lightweight model-related work in Elixir land.
Bumblebee for running models locally—useful when you want edge inference or to prototype without constantly paying API costs.
LiveView for streaming results directly to the browser, turning “AI output” into an interactive experience rather than a delayed blob.
Plus the BEAM runtime primitives (processes, supervision, message passing) that make the whole system resilient.

The takeaway: even when inference happens outside BEAM, BEAM can still be the conductor. And orchestration is where most AI backends get messy.

Designing an AI backend with BEAM-friendly architecture

If you want to get real benefits (instead of just writing Elixir “because”), treat your AI backend as a set of supervised components.

1) Use a supervisor tree that mirrors your failure domains

Examples of failure domains:

per-provider HTTP client failures,
per-model streaming failures,
per-tenant rate limiting,
per-workflow orchestration.

When something breaks, you want it to restart within the right boundary. Not everything should restart because one provider returned a bad chunk.

2) Model the workflow as messages, not shared state

Coordinator processes that receive “plan ready,” “critique ready,” and “stream token” messages tend to be simpler than shared-state approaches. You can keep request-scoped state inside the coordinator and drop it when the workflow completes.

3) Make fallback behavior explicit

Don’t bury fallback logic in random rescue blocks. Decide up front what happens when:

a stream ends early,
a call times out,
one model is down,
a provider returns invalid output.

Then implement those choices in the coordinator and/or policy processes.

4) Stream early, confirm later

If you can provide partial output quickly, do it. But keep validation and post-processing separate so you can keep streaming while you check. Users experience responsiveness; your system maintains correctness.

This is where BEAM’s event-driven feel is a competitive advantage.

Conclusion: the BEAM world arrived early—and AI finally caught up

I’m bullish on Elixir for AI applications because it doesn’t merely “support concurrency.” The BEAM was built for high-concurrency, fault-tolerant systems with message-driven orchestration and streaming-friendly workflows. AI backends are now forced to behave like those systems—running many parallel operations, streaming incremental results, and handling provider unreliability without collapsing.

Elixir gives you a runtime that makes those requirements feel natural rather than heroic. And when you combine that with a practical web layer like Phoenix LiveView, you don’t just build an AI backend—you build an interactive, resilient AI product.

The BEAM was designed for the world we’re entering. Elixir just makes that world easier to ship.

Why Every Backend Developer Should Learn Some Systems Programming

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 07 Jul 2024 00:00:00 +0000

Backend work lives at the boundary between “my code” and “the machine.” Most of the time, that boundary is a comfort blanket—runtime abstractions smooth over complexity until something goes wrong. Then you’re left staring at a container that gets OOM-killed, a Node server that crawls under load, or a Go benchmark that “should” be faster but isn’t. If you learn a bit of systems programming, those failures become explainable—and fixable.

You don’t need to write C professionally. You need to understand what your runtime is doing on your behalf: memory layout, threads, syscalls, and I/O behavior. Once those fundamentals click, Go, Python, and Node stop feeling like black boxes and start behaving like tools.

Memory: Why “it fits” locally can die in a container

Memory bugs aren’t always bugs. Often they’re mismatches between assumptions and reality—especially in containers.

At a systems level, every process has a virtual address space: memory pages that the OS can map to physical RAM, swap, or file-backed regions. Your language runtime (Go GC, Python allocator, Node’s V8 + heap) builds its own memory model on top of that. When people say “it’s a memory leak,” what they sometimes really mean is “I didn’t account for the shape of allocations and the way the OS enforces limits.”

Two practical examples:

OOM-kill surprise from allocator behavior
Suppose your Go service loads a large JSON payload, parses it into structs, and holds it for a while. Locally you have plenty of RAM. In production you set a container memory limit. Even if your app’s “heap usage” looks reasonable in logs, the OS may still kill the process if the RSS (resident set size) exceeds the limit. Why? Runtimes often reserve memory, grow arenas, and keep freed memory for reuse rather than returning it to the OS immediately. Virtual memory and RSS aren’t the same thing.

What to do: read both “heap” metrics and OS-level memory (like RSS), and learn how your runtime returns memory (or doesn’t). In Go, for example, GC behavior and arena growth matter. In Node, V8 heap limits and native allocations matter.
Copying and fragmentation from hidden allocations
A common backend anti-pattern is “harmless” string/byte transformations in hot paths. In systems terms, copies cost memory bandwidth and create temporary allocations that increase peak memory. The OS will happily give you virtual memory until the moment your working set spikes beyond the container limit.

What to do: profile allocation rates and reduce intermediate buffers. In many workloads, the biggest win is stopping accidental copies (e.g., avoiding unnecessary conversions between strings and byte arrays, streaming instead of buffering, using buffer pools where appropriate).

If you understand pages, RSS, and allocation patterns, you stop guessing when memory alarms fire. You start predicting which code changes will shift peak memory—and by how much.

Threads and scheduling: Why your server feels slow “only sometimes”

Modern servers are concurrency-heavy, but most developers treat concurrency as a property of their language rather than of the OS. That’s why issues appear that seem nondeterministic: requests are fast until traffic rises, then latency spikes, then throughput collapses.

Under the hood, threads are scheduled by the OS. Even “green threads” (user-space scheduling) ultimately map to real threads and get blocked by kernel events. Thread pools, context switches, and synchronization primitives determine how well your system uses CPU without turning contention into a tax.

Consider a Node.js service under load. Node’s event loop can look “single-threaded,” but the system still relies on worker threads for certain tasks (like crypto or file operations), plus the kernel handles network I/O and timers. If your app does heavy CPU work in the main thread, your event loop stalls. Requests queue up; timeouts trigger; it feels like the server “crawled” for no reason.

What systems understanding changes: you realize “fast I/O” and “slow CPU” are different bottlenecks. CPU-bound work needs to be offloaded or optimized, not just awaited.

Now think about Go. Go uses M:N scheduling: many goroutines multiplex onto a smaller set of OS threads. That’s powerful, but it doesn’t remove the reality of CPU scheduling. If your goroutines contend on locks, saturate a shared resource, or create a thundering herd of runnable goroutines, the scheduler will work harder and latency will worsen.

What to do in practice:

Learn what “blocking” means at the OS level: waiting for sockets, disk, or locks.
When you see latency spikes, ask: is the bottleneck CPU, contention, or I/O?
Use runtime profiling tools, but interpret them with a mental model of scheduling and blocking.

Even if you never touch kernel APIs, understanding scheduling teaches you to design backpressure, avoid lock contention, and size concurrency limits based on system behavior—not vibes.

Syscalls and I/O models: Benchmarks lie when you ignore the kernel

If you’ve ever run a Go microbenchmark and thought, “This can’t be right,” you’ve already met the kernel. Syscalls—calls from your program into the OS—aren’t free. They involve transitions between user space and kernel space, queueing, and synchronization. The cost varies by operation, but the key lesson is stable: excessive syscalls dominate performance long before clever algorithms do.

The I/O model matters too. Network and disk I/O can be blocking, event-driven, or asynchronous, but the OS always mediates. When you understand that mediation, your benchmark design improves automatically.

A few common benchmark traps:

Measuring overhead, not work
If your benchmark performs tiny operations with lots of small reads/writes, you might be benchmarking syscall overhead and buffering behavior rather than your logic.
Ignoring buffering and batching
Many runtimes batch work under the hood, but it’s not guaranteed. If you use naive request-by-request writes without aggregation, you may inflate syscall counts.
Testing in a “warm” environment only
Page cache effects and JIT/GC warmup can change performance dramatically. Systems knowledge helps you structure benchmarks to separate steady-state from initialization.

Practical advice for better performance work:

Measure at the right layer: application latency/throughput plus system metrics (CPU, context switches, network retransmits, disk I/O).
Reduce syscalls in hot paths: favor buffering, batching, and streaming.
Use load testing that resembles production concurrency—not just single-thread microbench loops.

Once you see syscalls as a first-class cost, you stop being surprised by performance cliffs and start designing experiments that answer real questions.

Memory + threads + syscalls: the “OOM killed” and “latency spike” debugging loop

Systems programming isn’t about collecting trivia. It’s about shortening the debugging loop.

Here’s the workflow that becomes natural once you’ve learned the layers:

Identify the resource pressure: memory limit, CPU saturation, queue buildup, or I/O bottleneck.
Map symptoms to mechanisms:
- OOM-kill → virtual memory growth vs RSS, allocator behavior, peak working set.
- Latency spikes → scheduler contention, blocking points, event loop stalls, thread pool saturation.
- Throughput weirdness → syscall overhead, batching, network backpressure, disk cache effects.
Instrument the right thing:
- Add OS-level visibility alongside runtime metrics.
- Capture allocation profiles, goroutine/block profiles, or event loop delay.
Change code in ways that shift the underlying mechanism: streaming instead of buffering, limiting concurrency, avoiding copies, reducing lock contention, or batching I/O.

If you can do that consistently, your backend engineering becomes less reactive. You don’t just “tune until it works.” You change the system’s behavior in a way that has a predictable effect.

Why Rust and Zig make this easier than you think

There’s a cultural myth that systems programming learning requires pain: long C nights, undefined behavior roulette, and manual memory management without guardrails. You can still learn those concepts safely, but you don’t have to start there.

Rust and Zig are unusually good gateways for backend developers because they preserve the core systems ideas while reducing avoidable footguns:

Rust makes ownership and borrowing feel like a design tool, not just a language feature. Learn the mental model behind memory lifetimes and you’ll write safer high-performance code—and you’ll better understand why runtimes need GC, arenas, or reference counting in the first place.
Zig encourages explicit control and transparency. When you can see allocations, lifetimes, and calling conventions, it becomes easier to map what you learn back to how OSes and runtimes behave.

And you don’t need to build a kernel to get value. Build small but revealing programs:

A tiny HTTP server that streams responses and observe memory behavior.
A concurrent downloader that limits parallelism and measures latency under load.
A program that reads from a file in small chunks vs large buffered reads and then compares syscall-heavy patterns.

The goal is not to become a systems engineer overnight. The goal is to internalize the cause-and-effect loop between “what the code asks for” and “what the OS does.”

Conclusion: Learn the layers, and your backend skills compound

Backend development gets easier when you stop treating the runtime as an oracle. Memory, threads, and syscalls are the real contracts your code runs against. Once you understand those contracts, container OOMs become diagnosable, Node latency spikes become explainable, and Go benchmarks become trustworthy.

Learn enough systems programming to build a mental model. Then keep using it—because every year you’ll work closer to the boundary where abstractions end and reality begins.

Llama, Mistral, and the Open-Source LLM Revolution

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 25 Jun 2024 00:00:00 +0000

For a long time, “building AI” meant negotiating access to proprietary models—paying API tolls, accepting platform rules, and hoping your prompts and data would never become collateral damage. Then something changed: open-source large language models stopped being a curiosity and started looking like infrastructure. Llama and Mistral didn’t just improve chatbots; they detonated the closed-AI business model’s gravity.

Meta’s detonation: when Llama broke the monopoly

Meta didn’t set out to end the era of closed models. But when Llama 2 landed, it did the one thing proprietary vendors can’t: it gave developers a credible alternative that didn’t require permission slips.

The key shift wasn’t that Llama was “better.” It was that it was useable by ordinary teams. Once the model weights were available, developers could run them locally, fine-tune them, and integrate them into their own products without relying on an external API as the single point of failure.

That’s the real threat to vendor lock-in: when an alternative is technically viable, it becomes financially and operationally risky to keep depending on a single provider. API pricing changes. Rate limits appear. Terms of service evolve. Latency spikes. Suddenly, your AI roadmap is at the mercy of someone else’s billing dashboard.

Practical consequence: many teams stopped treating their LLM dependency as a product feature and started treating it as a pluggable component. You can see this mindset in architecture choices—routing requests through an internal service, adding fallback models, and tracking costs per feature rather than per experiment.

Mistral’s accelerant: smaller models, real capability

If Llama made the open-source case, Mistral made it scalable.

Mistral’s approach has consistently emphasized performance-per-parameter: models that can deliver high-quality results without demanding the kind of massive infrastructure reserved for frontier labs. In other words, open-source wasn’t just “possible”—it was increasingly “affordable.”

This matters because the economics of AI products aren’t dominated by the first demo. They’re dominated by iteration speed and steady-state inference cost. A smaller, capable model can mean:

More frequent releases because you can experiment without waiting for budget approvals.
More predictable latency for end users.
Lower inference bills for production workloads.
Easier deployment on your own hardware (or on cost-efficient providers).

Concrete example: imagine building a support assistant for an ecommerce site. With a compact model, you can deploy it closer to your app servers, reduce round-trip latency, and tune prompts for your ticket taxonomy. With a heavier model, you might still do that—but only if the cost profile allows it. Open models expand the range of feasible products.

The sharp truth is that “GPT-level” performance isn’t the only metric that matters. For many businesses, the winning move is good enough at the right cost, with control over deployment, data flow, and behavior.

The quantization boom: running smarter on consumer hardware

Open-source also attracted a builder community, and builders hate waiting. As models became more common, the next bottleneck wasn’t training—it was inference.

That’s where quantization enters: techniques that reduce a model’s numeric precision (for example, storing weights with fewer bits) to shrink memory usage and speed up computation. Done well, quantization makes it realistic to run capable LLMs on consumer GPUs or even smaller setups—without turning your performance into a slideshow.

What this enables in practice:

Local development workflows: Developers can test prompt strategies and tool integrations on their own machines rather than burning API calls.
Privacy-sensitive deployments: If your data can’t leave your network, local inference becomes a non-negotiable requirement.
Iterative fine-tuning and evaluation: You can run repeatable experiments faster when the loop doesn’t involve external services.

Quantization isn’t magic. You trade some quality or stability for efficiency depending on the method and target hardware. But the important shift is cultural: the community started treating model deployment as an engineering problem—not an exclusive privilege.

The moat was never the architecture—it was the supply chain

It’s tempting to say open-source “wins” because models are getting better. But that’s not the real business lesson.

The moat for AI companies was never only model architecture. It was:

Training data access at scale and with usable licensing,
Compute to train and iterate quickly,
Operational tooling to keep models reliable in production.

Architecture is comparatively easy to replicate once the community has the recipe. Compute and data are harder—and that’s why open-source threatens the old order so aggressively: it chips away at each layer of dependency.

When more organizations can host models themselves, the vendor’s “platform tax” becomes optional. When teams can evaluate multiple models side-by-side, a single provider’s advantage erodes. When developers can fine-tune for specific domains, generic model performance becomes less important than your ability to shape behavior and outputs.

Opinionated take: the closed-AI model benefited from asymmetry. Developers didn’t just buy inference—they bought uncertainty management: “Trust that the provider will handle it.” Open-source reduces that uncertainty by letting teams own the system end-to-end.

Building without lock-in: practical patterns that actually work

The open-source shift doesn’t just change what model you use—it changes how you design your AI product. Here are practical patterns teams are adopting to avoid painting themselves into a corner:

1) Use an internal model gateway

Instead of calling a vendor API directly from your app, route all LLM requests through an internal service. This gives you:

centralized prompt/version management,
consistent formatting,
cost tracking,
model switching and fallbacks.

If you start with open-source now, you can still migrate later—but you won’t have to rewrite your application to do it.

2) Separate “model logic” from “product logic”

Treat the model as a component that transforms inputs to outputs. Keep your business rules outside the model: validation, policy enforcement, tool selection, and structured formatting. That makes behavior more predictable across different models.

A common winning approach is to push the model toward structured outputs (JSON schemas, constrained formats) and enforce them at the application layer.

3) Build retrieval and context like it’s a first-class feature

Most real-world LLM systems aren’t “pure chat.” They’re retrieval-augmented generation (RAG), workflows, and constrained agents. Open-source models make it feasible to customize this entire stack—so the advantage shifts from “which model?” to “how well do you feed and verify the output?”

4) Plan evaluation like you plan security

Don’t judge by a handful of examples. Create test suites that represent real user queries, failure modes, and regressions. Track:

refusal behavior and safety,
factuality and citation quality (when using retrieval),
formatting compliance,
latency and cost.

If you can’t evaluate reliably, model choice will feel like vibes.

Data privacy and cost: the unglamorous wins

The revolution sounds glamorous, but the biggest benefits are boring—and that’s why they matter.

When you can run LLMs in your own environment, you can:

keep sensitive text and documents within your infrastructure,
control logging policies,
reduce exposure to third-party retention rules,
avoid surprising data handling changes.

And when you’re not paying per token to a vendor for every iteration, you can afford to improve the product instead of optimizing it down to the cheapest prompt that “kind of works.”

Example: a legal or HR workflow assistant often needs strict controls around document handling. With a closed API, every new integration risks a compliance review. With a self-hosted model (plus a well-designed retrieval layer), you can standardize the data path and keep approvals from reinventing themselves every quarter.

Conclusion: open models are becoming the default infrastructure

Llama and Mistral didn’t just offer better chat. They shifted the balance of power by making LLM capability portable, testable, and deployable. The open-source ecosystem—quantization, tooling, fine-tuning practices—turned model ownership into a practical engineering option rather than a distant fantasy.

The closed-AI era didn’t end because proprietary models stopped being good. It ended because the dependency was no longer inevitable. Open-source is eroding the old moat, and it’s doing it in the most consequential way possible: by letting developers build AI features without asking permission every step of the way.

The htmx vs. React Debate Is Missing the Point Entirely

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 13 Jun 2024 00:00:00 +0000

Every few weeks, the same argument resurfaces: htmx is “the future,” React is “too heavy,” or vice versa. It’s loud, opinionated, and rarely useful. The real problem is simpler—and more practical: both camps often talk past each other because they’re not solving the same kinds of systems.

htmx and React aren’t rivals in the way people claim. They’re tools optimized for different architectural realities. Pick based on the shape of your application, where state lives, and how your team ships software—not based on who’s winning the comment thread.

What the Debate Gets Wrong: “Better” Isn’t a Category

“Which is better?” sounds productive until you notice it’s usually not asked in context. Better for what? Better for which constraints? Better for what team composition? Better for which latency model? Better for what maintenance pattern?

In practice, the decision is less like choosing a sports car and more like choosing a building material. Concrete and steel can both build bridges. But if you’re trying to assemble a temporary bridge quickly, you’ll likely make different tradeoffs than if you’re building something that must survive decades of load.

The htmx vs. React argument often fails because it treats the UI framework as the primary variable. In reality, the primary variable is the architecture: who owns state, how much logic runs on the server, and how complex interactions need to be.

When htmx Wins: Backend-Owned State and Server as the Source of Truth

htmx shines when the server is the natural home for your data and state. If your application already thinks in terms of requests, resources, permissions, and server-rendered views, htmx lets you keep that mental model while still delivering a modern “app-like” experience.

Concrete examples where htmx is a great fit

Admin panels and internal tools: You typically have CRUD flows, table views, filters, and form edits. The server already knows what the user is allowed to do. With htmx, you can progressively enhance without building a full client application.
Content sites with interactive widgets: Think comment forms, “load more” sections, search, voting, or admin moderation. Most interactions don’t need a fully client-managed state machine.
Workflows tied to backend invariants: If a state transition is enforced by business rules—like “you can’t approve until prerequisites are met”—keeping that logic server-side is not just convenient, it’s safer.

Why the architecture matters

htmx encourages you to treat HTML as the UI contract. You return markup that represents the new state, and you swap it into the page. When the backend is already the source of truth, this pattern reduces duplication. You avoid writing two versions of reality: one in the server and one in the browser.

And you avoid the “SPA tax” that hits teams hard: authentication edge cases, routing complexity, caching, rehydration, and state synchronization. You don’t need all of that if your system’s authority is the server.

When React Wins: Complex Client-Side State and Rich, Interactive UX

React excels when the browser must own meaningful local state and coordinate complex UI behavior that doesn’t map cleanly to round-trips.

Concrete examples where React is a great fit

Collaborative editors: Cursor positions, selections, operational transforms/CRDT updates, and frequent incremental changes benefit from client-managed state and optimized rendering paths.
Real-time dashboards: Live updates, streaming data, optimistic UI, and intricate layout logic are often easiest when the client maintains a local model of what’s on screen.
Complex component ecosystems: If your product needs deeply interactive UI primitives—drag-and-drop, advanced filtering, multi-step forms with intricate validation—React’s component model and local state management become compelling.

Why the architecture matters

When the interaction model is “the user is constantly changing something” and those changes need to feel immediate, a server round-trip isn’t just slower—it can be architecturally awkward. You want predictable UI state transitions, local derivations, and a rendering model that updates quickly.

React doesn’t just provide a view layer. It pushes you toward a design where the UI is a function of state, and that state can be complex and transient. That’s a good thing when the client is the natural engine of the interaction.

The Real Decision Framework: Where Does State Live?

Here’s the practical way to choose without tribal noise: identify where your application’s state lives and how often it changes.

Ask these questions:

Is the backend the source of truth?
If permissions, validation, and invariants are authoritative on the server, htmx aligns naturally.
Do you need rich local state?
If the UI depends on client-only details—like ephemeral UI state, optimistic changes, or interaction-heavy workflows—React is built for that.
How “round-trip friendly” are your interactions?
CRUD-heavy flows and form submissions are usually fine with request/response patterns. Fine-grained, continuous interaction tends to favor client state.
What’s your team’s operating model?
If your team is strongest in server development and wants to ship HTML-driven features quickly, htmx can reduce friction. If your team already lives in the client ecosystem and can maintain a component architecture, React can be a multiplier.

This is why the debate misses the point: it assumes the UI layer is the main event. The main event is the system boundary between server and client.

A Better Pattern: Combine Them Instead of Worshipping One

Here’s the opinionated take that should end most arguments: you can—and often should—use both. Many teams do.

A common hybrid approach looks like this:

Use htmx for server-rendered pages and incremental updates: pagination, filters, admin actions, form submissions, and small interactive fragments.
Use React for the parts that genuinely need client-owned complexity: a collaborative editor, a heavily interactive visualization, or a complex multi-step workflow.

This isn’t compromise; it’s correctness. You’re choosing the simplest tool that fits each problem. If your “hard part” is isolated, you don’t need to drag the whole product into a single architectural style.

Example: an admin tool with one React island

The admin panel is server-rendered. Tables, editing forms, and status changes use htmx swaps.
One section—say, an advanced configuration visualizer—uses React because it needs rich client-side state and a responsive UI.
The boundary stays clean: the React component can fetch data and send updates, while the rest of the system remains consistent with server truth.

This keeps your product coherent and your engineering effort focused where it matters.

Common Failure Modes (And How to Avoid Them)

Both sides have predictable ways to shoot themselves in the foot.

Failure mode for htmx

If you try to shoehorn a highly stateful, component-driven UI into htmx patterns, you’ll end up fighting the model. You’ll be forced to invent client-side state synchronization anyway—at which point you may as well ask whether React (or another client state system) would have been simpler.

Fix: Treat htmx as a server-centric enhancement tool. When local state complexity grows beyond “swap some markup,” isolate that complexity.

Failure mode for React

If you build a full SPA for an app where the server already owns the truth, you’ll spend time recreating things the server could have handled cleanly. The result can be a lot of glue code for routing, caching, permissions, and data consistency.

Fix: Don’t default to React when your problem is mostly CRUD, server-rendered pages, and backend-enforced invariants. Consider whether a request/response UI would reduce risk and speed up iteration.

Conclusion: Stop Debating Tools, Start Designing Systems

The htmx vs. React debate isn’t really about htmx or React. It’s about system design: where state lives, how interactions behave, and what your application must guarantee.

Pick the tool that matches your architecture, not the one that wins your timeline. If the backend is the source of truth and interactions are mostly request-friendly, htmx will make you faster and your UI more consistent. If the client must manage complex, transient state with highly responsive interactions, React will save you from contortions.

Make the boundary intentional, and the “war” goes away.

The Database Branching Revolution: Neon, PlanetScale, and the End of Migration Fear

abdecastro@protonmail.com (Antonio B De Castro) — Fri, 07 Jun 2024 00:00:00 +0000

Deployments should feel like releases, not rituals. Yet for most teams, the scariest moment still isn’t the new UI or the background job—it’s the database migration. That tiny blob of SQL that “should be safe” somehow becomes a roulette wheel: lock timeouts, unexpected data shapes, irreversible changes, and the dreaded rollback plan that only works in theory.

The good news: the ecosystem finally has a better answer. Neon’s database branching and PlanetScale’s deploy requests (plus preview environments) change the entire psychology of migration work. Instead of betting production, you can test the exact reality of production—schema and data—before you flip the switch.

Why migrations feel existential (and why they shouldn’t)

Migrations are anxiety-inducing for a few practical reasons:

They’re stateful. Schema changes depend on real data. A “harmless” ALTER TABLE can behave very differently depending on indexing, row counts, and existing constraints.
They’re sequential. You can’t always treat migrations like stateless code. They modify shared infrastructure that other requests depend on.
They’re hard to validate. Unit tests don’t cover production data distributions. Staging often diverges quietly: missing rows, different null rates, different edge-case strings, different query patterns.
Rollback is a myth. Many migrations aren’t safely reversible. Even reversible ones often require time, locks, and operational discipline that you only have after something is already on fire.

The result is a grim engineering loop: you make a best guess, deploy during a low-traffic window, watch metrics, and hope that “should be fine” stays true.

That’s not a discipline problem. It’s a tooling and workflow problem.

Neon’s database branching: production-grade previews without the paranoia

Neon’s database branching is the most important shift because it treats your database like versioned work—not a single mutable blob.

With database branching, you can create isolated branches of your production database that include both schema and data, then work in those branches safely. In other words: your staging environment stops being a fragile approximation and becomes a faithful sandbox.

Here’s what that changes in practice.

Replace “staging is close enough” with “staging is exact”

Imagine you’re preparing a migration that changes a column type or adds a constraint. Traditionally, you’d run it on a staging copy and hope it behaves. But staging might not include the edge cases that exist in production—especially with messy historical data.

With branching, you can create a branch from production and run the migration against real production-shaped data. That lets you test:

whether the migration completes within your operational time budget
whether backfills (if any) behave correctly
whether queries and code paths behave as expected with the new schema
whether unexpected rows violate new constraints

Think “feature branch,” but for your database

This is the mental model that matters. You’re not just “running a migration somewhere.” You’re creating a branch that your team can iterate on.

For example:

Create a Neon branch from production for a new feature (say, orders-v2).
Apply your migration(s) on that branch.
Deploy the application version that expects the new schema into a preview environment wired to that branch.
Run tests and manual verification against production-like data.
When you’re confident, merge the change into the main migration line.

The win isn’t only technical—it’s emotional. Engineers stop treating database changes as a leap of faith and start treating them like normal development work.

Practical advice: use branches to validate the hard parts

Not every migration deserves equal fear, but some deserve real validation. Branching is especially valuable for:

Backfills and data transformations (because they reveal real data pain)
Constraint additions (NOT NULL, UNIQUE, foreign keys) (because they fail on ugly rows)
Type changes (because implicit conversions can be surprising)
Index changes that can impact query plans (because the data distribution matters)

If you’ve ever stared at a migration and thought “I hope our production data doesn’t do something weird,” you’ve already identified the kinds of changes branching should cover.

PlanetScale deploy requests: schema changes without stopping the world

Branching helps you validate—but you still need a safe rollout path. PlanetScale’s deploy requests take care of the operational part by applying schema changes with zero downtime.

The point here is not just “no downtime” as a headline. It’s that deploys become less binary. When the platform can apply changes in a way that avoids service interruption, you can focus on correctness rather than firefighting.

How this changes rollout strategy

In many teams, the migration rollout strategy becomes a choreography of fear:

deploy schema change in one release
deploy code change in a later release
keep backward compatibility windows alive forever
coordinate carefully to avoid breaking requests

Zero-downtime schema application doesn’t eliminate compatibility concerns entirely, but it drastically reduces the urgency. You can use deploy requests to move faster without forcing every migration into a slow, two-step process.

Practical advice: pair PlanetScale deploy requests with explicit verification

Even with zero downtime, correctness still matters. A good rollout workflow looks like:

Use Neon to validate the migration against production-shaped data in preview environments
Prepare the PlanetScale deploy request with the schema change
Roll out with monitoring focused on the specific risks (constraints, query latency, write correctness)
Keep an eye on application-level signals (not just database health)

Zero downtime removes one class of risk. Branching removes another. Together, they shrink the entire surface area of “migration fear.”

Preview environments: test the exact data shape before you ship

Branching gives you production-grade isolation; preview environments give you end-to-end confidence. The combo is where migrations stop being existential.

Instead of asking, “Will this migration break production?”, you ask something more constructive:

“Does the application behave correctly with the migrated schema?”
“Do critical flows work with real data shapes?”
“Do we still handle edge cases correctly after the new constraint or type?”

A concrete example: adding a uniqueness constraint

Suppose you want to enforce that email is unique on users.

The scariest part of this migration isn’t the SQL statement—it’s the assumption that there are no duplicates lurking in production. Staging might be clean. Production probably isn’t.

With Neon branching:

Create a branch from production.
Apply the migration adding the unique constraint.
Run a preview deployment of the code that expects the constraint to exist.
Let your tests (and a few targeted manual checks) reveal duplicates or broken assumptions.

If the migration fails on the branch, you fix the issue before it ever reaches the production runway. The “fear” becomes a routine, solvable engineering task: cleaning data, adjusting the migration approach, or introducing a safe backfill.

A new workflow: Git-style confidence for database changes

The most useful way to think about this revolution is “database changes should work like code changes.”

That means you treat database schema work the same way you treat application work:

create an isolated branch
build and test in that branch
validate behavior against production-shaped reality
promote the change through controlled steps

Here’s a workflow your team can adopt with minimal drama:

Create a database branch for the migration work (Neon).
Apply the migration in the branch.
Deploy a preview environment using the migrated branch database.
Run tests and perform targeted verification of the risky flows.
Promote to rollout using PlanetScale deploy requests for safe application-level and schema-level changes.
Monitor the specific behaviors you validated—because verification isn’t just for confidence; it’s also for faster detection when something deviates.

This workflow flips the default posture from “hope” to “prove.”

The end of “will this break production?”—and what still matters

Let’s be honest: you’ll still write careful migrations. You’ll still think about lock behavior, index builds, and compatibility. You’ll still watch error rates and latencies after deployment.

But the psychological center of gravity moves.

You stop relying on vague staging resemblance and start using true production-shaped validation. You stop treating migrations like existential events and start treating them like normal changes with previewable outcomes.

In practice, this means your team can stop asking:

“Do we feel lucky?”
“Can we risk this during peak?”
“What’s our rollback if the data is messy?”

And start asking:

“What will fail on the migrated branch?”
“Which tests and flows must pass to consider this safe?”
“What is the smallest operationally safe migration plan?”

That’s engineering maturity—not fear avoidance.

Conclusion: migration fear is solvable engineering work

Database migrations don’t have to be the scariest part of deployment. Neon’s database branching lets you create isolated, production-grade copies of schema and data for development and testing. PlanetScale’s deploy requests apply schema changes with zero downtime. Add preview environments and you can validate the exact shape of production reality before you ship.

The result is a practical revolution: Git-style confidence for your database lifecycle—where “will this break production?” becomes a question you can test and answer, not a gamble you have to survive.

shadcn/ui Proved Component Libraries Were Doing It Wrong

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 01 Jun 2024 00:00:00 +0000

For years, teams have treated UI components like a commodity: install a package, trust the defaults, and hope the library’s opinions match your product’s reality. That strategy fails the moment your “simple” button needs to do something slightly different. shadcn/ui flips the entire model—by making components something you copy, own, and evolve inside your codebase. It’s not just a better UI stack. It’s a better philosophy.

The real problem with “component libraries”

Most component libraries ship as npm packages, versioned and maintained separately from your application. That sounds convenient until you hit the friction points every frontend team knows too well:

Version conflicts: You want the latest component fix, but it pulls a dependency chain you’d rather not touch.
Opinion mismatches: The library’s styling and behavior are coherent—until they’re not your product.
Feature gaps: “We don’t support that prop combination” becomes a recurring conversation.
The slow loop: You wait on maintainers for changes that are obvious in your app context.

What’s easy to miss is that these aren’t small annoyances. They’re structural. When the UI is owned by someone else’s package, you spend engineering effort negotiating boundaries rather than shipping product. Even if the library is great, the moment you need to bend it, you’re negotiating with an abstraction.

What shadcn/ui actually is (and why it matters)

shadcn/ui is not a typical component library you install and depend on. It’s closer to a curated set of components you copy into your project. You don’t keep it as a third-party runtime dependency. You bring the source code into your repo and you own it.

That single change changes everything:

No npm dependency to manage for the components themselves.
No version upgrades that silently alter behavior across releases.
No “but the library doesn’t support my use case” wall—because the code is now yours.
Your team controls the design system timeline, not the library’s release schedule.

The radical insight is embarrassingly simple: if you treat UI components like your code, the “library limitations” problem disappears. You can refactor, extend, or remove logic without waiting for permission.

Copy-paste beats dependency drama

Let’s ground this in a scenario that hits almost every team.

You choose a component library for consistent buttons, dialogs, forms—great. Now a designer asks: “The primary button should show a loading spinner and disable itself during the async call, but only for certain actions. Also, we need analytics events fired on click—no matter whether the handler is synchronous or async.”

With an npm-based component, you have options:

Wrap the component in your own abstraction (more code, more indirection).
Use library extension points (if they exist, and if they behave exactly how you need).
Fork the repo (then you own the upkeep forever, just without the clarity of “this is our code”).

With shadcn/ui-style copyable components, the path is direct:

Find the button component file in your project.
Add the spinner + disabled logic where it belongs.
Ensure the analytics hook is triggered in the right places.
Commit it like any other feature.

You don’t “work around” the library. You implement the button you actually need, inside your codebase, with full control over behavior.

And because you own it, you can keep changes consistent across the app. You can even standardize patterns: for example, enforce that all async buttons share a single “loading contract” so your UI feels coherent.

You can still have a system—just make it yours

Skeptics often say, “Copying components sounds like fragmentation.” That’s a fair concern, but it’s also a process problem—not a tooling problem.

The solution is to treat your copied components like a real internal design system:

Centralize the source of truth: keep components in a predictable folder structure (e.g., src/components/ui/).
Document the intent: explain what variations exist and how they’re supposed to be used.
Create local conventions: define patterns for props like variant, size, asChild, or any app-specific behaviors.
Refactor aggressively: once a couple of features prove out, fold them into the component rather than duplicating wrappers everywhere.

In practice, teams adopting this model often end up with the best of both worlds:

the speed of starting from beautifully designed defaults, and
the freedom to evolve the components without downstream dependency politics.

Your design system becomes a living part of your app, not an external artifact you babysit.

When you should customize (and when you shouldn’t)

Owning components is power—but power needs boundaries. Here’s an opinionated rule of thumb:

Customize when the behavior is product-specific

Examples:

Analytics events on interaction
Auth-gated actions
Routing-aware links (“active” styling based on app state)
Accessibility behaviors tied to your domain logic (not just generic keyboard support)
Form validation and error messaging patterns that match your UX

Don’t customize when it’s purely cosmetic or superficial

Examples:

Small color tweaks that can be handled by theme variables or CSS overrides
Layout differences that should live in className composition
“One-off” experiments that don’t become patterns

If you customize too eagerly, you’ll create a zoo of near-duplicate components. The smarter approach is to customize when you see the same requirement repeating—or when the component’s behavior must align with your product rules.

What this model teaches maintainers

If you maintain a UI library, shadcn/ui is uncomfortable reading—because it exposes a mismatch between how maintainers think and how product teams actually build.

Maintainers optimize for:

a coherent API across many users,
backward compatibility,
generality,
and a manageable surface area.

Product teams optimize for:

rapid iteration,
tight integration with app-specific state,
and predictable behavior under real workflows.

Those priorities collide the moment your “generic component” becomes “our product’s component.”

So here’s the takeaway for maintainers: the job isn’t just shipping components. It’s shipping a component model that doesn’t trap users inside your update cycle.

Even if you don’t adopt a copy-first approach, you can learn from it:

Offer clear extension points that don’t require deep forks.
Minimize breaking changes by stabilizing behavior, not just types.
Document customization paths that work in real apps, not just demos.
Design for composition and behavior overrides—because product requirements will always be weird.

shadcn/ui didn’t win because it had better UI marketing. It won because it respected ownership.

Conclusion: treat UI as code you own

Component libraries should accelerate development, not outsource decision-making. shadcn/ui proves a simple principle: when you copy components into your project and own the source, you eliminate the core pain of third-party UI—version conflicts, feature gaps, and the constant negotiation between your product and someone else’s assumptions.

The next time your app needs a button that behaves like a button in your world, don’t search for a prop. Own the code.

PostgreSQL Is a Vector Database Now, and That Changes Everything

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 20 May 2024 00:00:00 +0000

For years, teams building AI features treated vectors like a separate species of data—store them somewhere else, query them with a different system, and glue everything together with application code. That pattern is expensive, operationally messy, and rarely necessary. The shift is simple: PostgreSQL plus pgvector turns your existing relational database into an AI-native store for embeddings and similarity search—right next to the data you actually care about.

If you’ve been tempted to spin up a vector database “because that’s what everyone does,” it’s time to reconsider the architecture. In many real-world systems, vectors should live next to your records, not in a parallel universe.

The old pattern: two databases and a duct-taped workflow

A typical AI app pipeline used to look like this:

Your application stores canonical data in PostgreSQL (users, documents, tickets, products).
Your embedding service generates vectors.
You store vectors in a dedicated vector database (e.g., for similarity search).
When a user asks a question, you:
- query the vector store to get nearest matches,
- then make another trip to PostgreSQL to fetch metadata,
- then assemble the final response.

This isn’t just “more infrastructure”—it changes failure modes and performance characteristics. You now have at least two sources of truth, two indexing systems to maintain, and at least one place where permissions or tenant boundaries can drift out of sync.

Even if you’ve built the integration well, the architecture tends to encourage a frustrating workflow: the vector store becomes the “search brain,” while PostgreSQL remains the “details clerk.” That split often forces extra joins at the application layer and complicates transactional consistency.

What pgvector changes: vectors become first-class citizens in Postgres

With pgvector, embeddings live in PostgreSQL tables. Similarity search becomes a native query pattern. Instead of shipping data back and forth between systems, you can store vectors alongside the rows they describe.

The practical win is adjacency:

One database for both structured data and embeddings.
One query surface (SQL) to combine similarity matching with filters.
One transactional model for updates and deletes.
One place to manage access controls.

A simple mental model: pgvector adds an efficient way to store vector columns and compute nearest neighbors using similarity operators. From there, Postgres does the rest—indexes, constraints, transactions, and joins—using familiar tooling.

You can write a query that looks like “find the most similar documents, but only for this customer and only those that are still active,” without manually stitching results across services.

“Next to your data” isn’t a slogan—it’s an implementation advantage

Here’s where the benefits stop being theoretical.

Example: RAG over document metadata without an extra hop

Suppose you’re building retrieval-augmented generation (RAG) for internal docs. Your Postgres table might include:

doc_id
tenant_id
title
content_chunk
embedding

With pgvector, a single query can:

filter by tenant_id (hard boundary),
compute similarity between the query embedding and stored chunk embeddings,
return the top K chunks with their doc_id and content_chunk.

That means your “retrieve context” step can stay inside the database. Your application stops doing “top K from vector DB, then fetch details from Postgres”—and you eliminate a whole class of consistency problems.

Example: Search that respects business rules

Similarity search is rarely the whole story. You almost always want:

only enabled products,
only non-expired records,
only items the user is allowed to see,
only content in a certain language,
only recent activity.

In a two-database world, those constraints can become an awkward post-filter step: vector DB retrieves candidates broadly, and then your application or Postgres filters them. With pgvector, you can push those filters directly into the SQL query so the nearest-neighbor work happens within the correct slice of the data.

Example: Updates and deletes that won’t drift

Embeddings change when you re-chunk documents, update models, or re-embed after content edits. If vectors live in a separate service, you’ll eventually deal with “ghost results”—vectors that remain after the source document was deleted, or metadata that no longer matches.

In Postgres, you can tie embedding updates to the lifecycle of the underlying rows. Use transactions, triggers, or background jobs that update both the metadata and embeddings together. Even if you use async embedding generation, you can keep the database as the source of truth and reduce cross-system mismatch.

Practical advice: design for similarity, not just storage

pgvector is not magic; it’s an enabler. To get solid performance and maintainability, you still need to design your embedding tables and indexing strategy with intent.

Store chunk identifiers and metadata you’ll filter on

If you plan to filter by tenant_id, document_type, or created_at, include those columns in the same table as the vector. Your future self will thank you. “Store only vectors” sounds clean until you realize nearly every search needs guardrails.

Choose chunk sizes and keep them stable

For RAG-like workloads, embedding quality often depends more on how you chunk content than on which vector model you use. If chunking changes frequently, expect a churn cycle: re-embed, re-index, and validate retrieval relevance.

A good approach is to standardize chunking logic early. When you must change it, treat the embedding version as a first-class attribute (e.g., embedding_model, chunk_version) so you can roll forward predictably.

Index like you mean it (and measure)

Vector search performance depends heavily on indexes and the query operators you use. pgvector supports different index types and similarity functions, and the “best” choice varies by workload: dataset size, dimensionality, and acceptable latency.

Your practical workflow should look like this:

Start with correctness: implement similarity queries first.
Add an index once you confirm your query patterns.
Measure latency and recall behavior with your real distributions (tenants, doc lengths, update frequency).
Iterate on index parameters based on outcomes, not guesses.

If you’ve ever tuned a search system that only performed well on demo data, you know why this matters.

Keep your embedding generation pipeline honest

Even in a unified architecture, you still need a reliable embedding pipeline. A simple but effective pattern:

Store the source data in Postgres.
Generate embeddings asynchronously.
Write embeddings back to the same row (or a dedicated embedding table keyed by the row ID).
Track embedding status and versioning so you don’t serve stale vectors silently.

That way, the database remains the operational center while your embedding compute can scale independently.

The “one database” argument: not a meme, a systems decision

There’s a reason this shift feels inevitable: complexity taxes compound. Every additional service requires:

deployment and monitoring,
backups and disaster recovery thinking,
security reviews,
data modeling coordination,
and operational runbooks for “what happened when it went wrong.”

When vectors sit beside the data, you can simplify those operational steps dramatically. And you improve developer velocity because the mental model becomes straightforward: “I store and retrieve everything about this entity in one place.”

But the real advantage is architectural coherence. Similarity search is not an exotic afterthought anymore; it’s just another index-assisted query method. When you can join nearest-neighbor results to structured filters in the same system, you stop treating AI features like a separate product line.

For many teams, this is the difference between “we built a prototype” and “we can confidently ship and operate this.”

Conclusion: PostgreSQL + pgvector is the AI-native baseline

PostgreSQL has always been a database for serious workloads—reliable transactions, robust query planning, and a mature operational ecosystem. pgvector brings an AI capability into that same environment, turning embeddings and nearest-neighbor search into first-class relational concerns.

If you’re building AI features that need retrieval, ranking, or similarity search—and you already store canonical data in Postgres—then the cleanest architecture is to keep vectors in the same place. Not because “one database” sounds nice, but because it reduces operational risk, improves query expressiveness, and keeps your AI workflows aligned with your actual data model.

PostgreSQL is now a vector database. The smartest teams will treat that as a baseline, not a novelty.

Docker's Quiet Transformation from Dev Tool to Infrastructure Backbone

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 08 May 2024 00:00:00 +0000

For years, containers were the “cheat code” developers used to escape the dreaded works on my machine trap. Today, that same idea has quietly evolved into something far bigger: a dependable infrastructure layer teams treat as unremarkable—like DNS or TCP/IP—because it just works. Docker didn’t merely make deployments easier; it made reliability portable.

This is the story of why containerization stopped being a workaround and started acting like infrastructure: through tooling maturity, better build workflows, and an ecosystem that hardened where it mattered—at the edges of production.

From “Dev Convenience” to “Platform Expectation”

The early container pitch was simple: package your app with its dependencies, ship it, and run it consistently. In practice, that meant fewer “It fails only in production” incidents and fewer late-night environment archaeology sessions.

But Docker’s real shift wasn’t the container itself. It was the operational habit it enabled.

Consider the typical progression most teams experienced:

Phase 1: “We’ll use Docker for local dev.”
Great—until integration tests depend on external services, and the team starts copy-pasting run commands like sacred incantations.
Phase 2: “We’ll use Docker for staging.”
Now the environment is reproducible, but deployment is still manual and brittle.
Phase 3: “We’ll standardize on Compose/CI builds.”
The workflow becomes repeatable enough that new services can be created with minimal ceremony.
Phase 4: “We’ll treat containers as the delivery format.”
At this point, containers aren’t a special step; they’re the assumption.

Once containers become the assumption, architecture changes. Service boundaries map cleanly to runtime boundaries. Rollbacks become a matter of redeploying known artifacts. Scaling becomes a predictable exercise rather than a bespoke rewrite.

In other words: Docker didn’t just solve “works on my machine.” It eliminated the need to care about machine-specific details altogether.

Docker Compose Made Environments Actually Match

It’s easy to underestimate the importance of Docker Compose. The headline value is obvious—run multi-container apps locally—but the deeper win is behavioral: it encouraged teams to create environments that mirror each other across development, testing, and staging.

A practical example: imagine a web service that depends on PostgreSQL, Redis, and a background worker. Without Compose, developers often end up with divergent setups:

One developer runs Postgres 12 locally, another runs Postgres 15.
Someone uses a different Redis configuration.
Environment variables drift because they’re documented in screenshots, not defined in code.

With Compose, those differences collapse. You codify the environment: ports, volumes, dependency order, health checks, and even initialization scripts. The result is not just convenience—it’s alignment.

And that alignment becomes cultural. When the “default way” to run the stack is the same as the “default way” to test it, fewer bugs survive to the point where they’re expensive.

Compose also enabled a more disciplined approach to service design. If each service can be described as a container, it becomes easier to reason about interfaces, data lifecycles, and failure modes.

BuildKit and Multi-Stage Builds: The Quiet Productivity Revolution

Containers are only as useful as the build pipeline behind them. The ecosystem moved from “build an image” to “build an artifact you can trust.”

Two innovations (and the patterns surrounding them) made a massive difference:

BuildKit: faster, smarter builds

BuildKit improved builds in ways developers can feel immediately: caching gets more effective, parallelism increases throughput, and builds become less “mysterious” when caches miss. Instead of waiting for a full rebuild every time you touch a single file, you get incremental behavior that maps closer to how developers think.

Multi-stage builds: smaller images, cleaner boundaries

Multi-stage builds are the practical antidote to the “one giant image” problem. Instead of baking build tools, compilers, and caches into the final runtime image, you split the process into stages:

Build stage: compile the application, install dependencies, run tests.
Runtime stage: copy only the built artifacts and the minimal runtime dependencies.

The immediate benefits are straightforward: smaller images and reduced attack surface. But the deeper value is architectural. Your Dockerfile becomes documentation of what the application truly needs to run versus what it needs only to build.

A good multi-stage pattern looks like this conceptually:

Lock dependencies early to maximize cache reuse.
Copy only what’s needed from earlier stages.
Keep runtime stages free of compilers and build tooling.

In practice, this turns Docker from a packaging tool into part of a software supply chain you can audit and iterate on confidently.

The Ecosystem Hardened: From “Works” to “Reliable”

The shift from dev tool to infrastructure backbone didn’t happen in a single release. It happened as teams demanded reliability and the ecosystem responded.

What changed?

Better defaults and clearer tooling: CI pipelines, registries, and orchestration integrations became smoother, reducing the odds of “it worked locally” drift.
Stronger layering of concerns: developers focus on application code; platform tooling handles deployment mechanics. Containers provide the contract between them.
Repeatable deployment primitives: images became immutable artifacts, not “things we build on the server.” That’s a foundational reliability step.

Now, when something breaks, it’s usually because of real issues—dependency changes, misconfigured secrets, a bad migration—not because the environment is secretly different.

And once reliability becomes the baseline, conversations move on. Teams stop debating whether containers are “worth it” and start discussing higher-level concerns: observability, resilience, data consistency, rollout strategies, and cost.

That’s the hallmark of infrastructure maturity. The tool stops being the story.

The Invisibility Principle: Containers as the New TCP/IP

There’s a reason containerization is now so rarely explained from first principles. TCP/IP became inevitable because it solved a routing problem so thoroughly that developers stopped thinking about it. Docker has followed a similar path: the abstraction became so effective that the “how” receded.

What does that look like day-to-day?

Developers request services and receive them as deployable images.
CI systems produce artifacts the same way every time.
Operations teams treat containerized workloads as standard components—like any other workload type.

Containerization becomes invisible when it earns trust through consistency. When teams can say, “We already know how this runs,” they spend their time improving application quality instead of fighting environment variability.

This doesn’t mean problems disappeared. It means the container platform handles the predictable parts well enough that the real engineering work can rise to the surface.

Practical Advice: How to Keep Containers Acting Like Infrastructure

If Docker is now infrastructure in your organization, you should treat it accordingly. Here are the habits that keep containerization from regressing into fragile “magic”:

Pin versions aggressively
- Use lockfiles for app dependencies.
- Pin base images (and update deliberately) rather than relying on implicit tags.
Make builds deterministic
- Keep Dockerfiles focused.
- Avoid hidden state. If an environment variable is required, define it explicitly.
Use multi-stage builds by default
- Keep runtime images lean.
- Ensure build tooling doesn’t leak into production artifacts.
Codify environment setup
- Prefer Compose (or equivalent) for local parity with dev/staging.
- Include health checks and initialization where possible.
Treat images as immutable artifacts
- Build once in CI, deploy the same artifact everywhere.
- If you need different behavior, use configuration—not ad hoc rebuilds.
Invest in observability early
- Containers make deployment consistent; they don’t make debugging automatic.
- Make logs, metrics, and traces first-class citizens of your setup.

When you do these things, Docker stops being a “tool you use” and becomes a dependable substrate. That’s when the abstraction pays off—repeatedly, without drama.

Conclusion: The Real Transformation Was Trust

Docker’s quiet transformation—from dev convenience to infrastructure backbone—wasn’t a marketing win. It was an engineering outcome: containers became reliable enough, repeatable enough, and ergonomic enough that teams stopped thinking about them as a special technique.

Like TCP/IP, the best infrastructure fades into the background. You notice it when it’s missing, and you take it for granted when it’s there. Containers have reached that point. Now the work is to build on top of them with the same seriousness you’d bring to any foundational layer of your system.

Vercel's Lock-In Problem Is Becoming Impossible to Ignore

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 02 May 2024 00:00:00 +0000

It’s easy to miss lock-in when it looks like convenience. You ship fast, everything renders instantly, and the defaults just “work.” But when your framework, your hosting, and your commercial incentives all come from the same company, the path of least resistance quietly becomes the only practical path. That’s the uncomfortable truth at the center of Next.js + Vercel today—and it’s getting harder to ignore.

The cozy triangle: Next.js, Vercel, and incentives

Start with the obvious: Next.js is the most popular React framework, and Vercel is its corporate sponsor. Vercel is also a hosting platform designed around Next.js. That means the tooling, performance features, and “just works” experience are not neutral—they’re aligned with Vercel’s business goals.

None of this requires a conspiracy. It’s simply how platform ecosystems evolve. When a company invests heavily in a framework’s fastest lane, it will naturally want that lane to stay paved with its own infrastructure. And when developers are rewarded for taking that lane—better performance, smoother DX, fewer edge cases—competitors are left playing catch-up with imperfect compatibility.

The result: what begins as a technical choice gradually becomes a vendor dependency.

Why the “best features” are the ones that are hardest to move

Lock-in doesn’t usually show up as a dramatic switch you can’t make. It shows up as friction—small enough to postpone, large enough to eventually matter. In the Next.js world, that friction often clusters around features that are most mature on Vercel.

Consider two popular examples:

ISR (Incremental Static Regeneration): In principle, ISR is part of Next.js. In practice, it behaves best when paired with the platform’s caching strategy, deployment flow, and request handling. When you move to another host, the feature may still exist—but the performance characteristics, invalidation behavior, or integration polish can vary enough to force rewrites, config tweaks, or architectural compromises.
Edge Middleware: Middleware is where the “platform gravity” gets most visible. Middleware can run at the edge, but the edge runtime and routing semantics are deeply tied to the provider’s infrastructure. You can sometimes reproduce behavior elsewhere, but it’s rarely as seamless—especially when you rely on specifics like headers, rewrites, routing order, or the provider’s implementation of caching and session-affinity assumptions.

Here’s the real pattern: the more you build around “the good stuff,” the more your application becomes a composite of Next.js plus Vercel assumptions. And those assumptions tend to be the last things you want to unravel in the middle of growth.

The self-hosting gap: documentation exists, but confidence doesn’t

If you want to believe lock-in isn’t real, the first stop is usually documentation. For self-hosting, you’ll find plenty of Next.js guidance. But you may also notice something subtle: documentation often tells you how to run Next.js, not how to replicate the full Vercel experience with confidence.

That confidence gap matters. Running Next.js isn’t the hard part. Recreating the operational behaviors you’ve come to rely on is. For teams, the cost isn’t just engineering time—it’s uncertainty.

A concrete example: suppose you built a deployment strategy that assumes Vercel’s preview environments, automatic rollbacks, and content caching behavior are “the way the platform works.” If you switch hosts, even if your builds still succeed, you may discover that:

preview URLs don’t behave identically,
cache invalidation is less deterministic,
certain optimizations don’t trigger the same way,
and diagnosing performance regressions becomes a routine chore.

None of that is “impossible,” but it’s expensive. And expense is how lock-in converts from philosophy into engineering reality.

When compatibility breaks, it breaks quietly—then costs double

A good lock-in system doesn’t fail loudly. It degrades gradually, so you keep shipping while the exit plan rots.

Think about what happens when you’re mid-migration:

You discover an edge-case difference in middleware behavior.
You patch it with an abstraction or conditional code path.
The abstraction depends on internal behavior you didn’t document.
Six months later, you can’t confidently refactor because no one remembers why the workaround exists.

That’s how “small incompatibilities” multiply into a full rewrite. And because Next.js adoption is widespread, the hardest parts aren’t always the framework code—they’re the glue between framework features and the hosting platform’s runtime.

If you’re building authentication, personalization, or URL rewriting logic, you can end up with hidden dependencies on the host’s routing, caching, and header normalization. Even when the application renders, correctness can become inconsistent across environments. That inconsistency is often discovered at the worst possible time: during traffic spikes, marketing launches, or compliance audits.

The business model is working as designed

So yes—this is a business model. It’s also a rational one. If you operate a hosting platform, you want the ecosystem to treat your infrastructure as the default. If you sponsor the leading framework, you can prioritize the features that differentiate your platform and improve your customers’ outcomes.

It’s tempting to frame this as unfair. It isn’t. It’s competitive. But it does create an uneven playing field:

Alternative platforms may support Next.js, but struggle to match Vercel’s maturity across the full feature surface.
Developers may get encouraged to use “platform-native” capabilities because they’re the easiest to adopt.
Funding and tooling momentum then reinforce the same path, making other options feel risky or under-supported.

The irony is that the developer experience is genuinely good on Vercel. The problem isn’t that Vercel is “bad.” The problem is that “good” makes it harder to leave.

How to plan your exit without slowing down shipping

You don’t need paranoia to protect yourself. You need a strategy. Here are practical steps that reduce lock-in while keeping velocity.

1) Treat platform-specific features as an architectural choice

When you reach for Edge Middleware or rely heavily on ISR behavior, don’t assume it’s “portable by default.” Make a conscious decision:

What’s the fallback if that feature behaves differently?
Can your app degrade gracefully?
Is the logic essential, or can it be moved to a more portable layer?

If the answer is “we’d have to rewrite it,” that’s not a reason to stop—it’s a reason to plan.

2) Isolate “host assumptions” behind narrow interfaces

Create a thin internal layer that wraps platform-dependent behavior. For example:

Route rewriting logic can be centralized.
Cache invalidation hooks can be abstracted behind a small module.
Middleware decisions can call your own functions rather than embedding provider-specific assumptions everywhere.

You’re building an escape hatch. The win isn’t only future portability—it’s simpler testing and cleaner refactors.

3) Make local and staging parity part of your definition of “done”

If you only test “works on Vercel,” you’re not testing. Use staging environments that mimic production as closely as possible, especially around caching, headers, and routing behavior.

If you can’t get perfect parity, at least measure the differences early. The cost of discovering divergence in week one is dramatically lower than discovering it at month six.

4) Keep your infrastructure story documented—before you need it

Write down how deployments work today: environment variables, build steps, caching assumptions, preview flows, and any special integration. Then add an “exit section”:

What would change if we moved to a different host?
Which components are most sensitive?
What testing would we run to validate the migration?

This isn’t overhead. It’s insurance.

5) Periodically re-evaluate the “default”

Framework and tooling evolve. Hosts change. The ecosystem’s balance can shift. Make it a habit to audit whether your current setup still offers the best trade-off—not just whether it’s convenient.

Lock-in often persists because teams stop asking the question.

Conclusion: Choose Next.js with eyes open

Next.js can absolutely be a great framework. Vercel can absolutely be a great hosting platform. The problem is when the ecosystem quietly turns into a single-vendor pipeline where the most valuable features are the least transferable.

If you’re building with Next.js in 2026, the responsible move isn’t to panic—it’s to plan. Treat platform-native capabilities as decisions, isolate assumptions, demand parity in testing, and document your exit path while the project is still easy to change. Convenience is powerful, but so is foresight.

The Surprisingly Mature Ecosystem of Rust CLI Tools Replacing Unix Classics

abdecastro@protonmail.com (Antonio B De Castro) — Fri, 26 Apr 2024 00:00:00 +0000

Unix shipped a philosophy: small tools, composable outputs, ruthless simplicity. For decades, that meant a handful of classics dominated your terminal—grep, find, cat, ls, even the awkward parts of navigating a filesystem and reading diffs. Then Rust showed up and did something rare: it didn’t just produce a new language, it produced a new default toolkit. And the best part is that the “Rust CLI revolution” isn’t hype. It’s quietly mature, aggressively practical, and in many workflows, simply better.

This is how the Rust ecosystem rewrites your day-to-day terminal—and why the pattern matters.

Rust CLI tools didn’t arrive as experiments

A lot of ecosystems try to replace Unix classics with “cool” alternatives that break under real usage. The Rust story has been different. Tools like rg (ripgrep), fd, bat, eza, zoxide, and delta don’t feel like prototypes. They feel like they were designed for people who live in the terminal and care about latency, ergonomics, and predictable behavior.

The maturity shows up in details you only notice once the tools become your default:

Sensible command defaults that reduce the need for flags.
Clear, consistent output and paging behavior.
Strong performance characteristics when repositories get large.
Compatibility with common developer workflows, including pipelines and editors.

You can argue about aesthetics, but you can’t argue about friction. If a tool consistently saves you keystrokes and time, it wins. Rust just happened to ship a whole generation of winners.

ripgrep vs grep: search that doesn’t punish you

grep is a workhorse, but it’s also the kind of tool that teaches you pain. It’s fast enough until it isn’t. You start adding flags. You stop searching whole trees and begin excluding files manually. You learn the dark art of --exclude-dir, --binary-files, and other incantations.

ripgrep—usually invoked as rg—approaches the same job with a design that assumes you want quick iteration. In practice, that means:

It respects .gitignore by default, so you don’t drown in vendor code and generated files.
It has sane defaults that make “just search” actually work in big repositories.
It’s built for interactive use: run, scan, adjust, run again.

A concrete example: instead of:

grep -R "TODO" .

you’d typically do:

rg "TODO"

Then, if you want case-insensitive search:

rg -i "todo"

Or search only specific types:

rg "config" --glob '*.yaml'

The key isn’t that rg is “faster” in a lab. The key is that it makes your mental loop faster. You stop hesitating before searching. You search more often. And you find things you’d otherwise have missed because your tools made the first attempt too expensive.

fd vs find: fewer flags, fewer mistakes

find is powerful, but it’s also famously easy to misuse—especially when you’re juggling quoting, precedence, and type filters. fd keeps the useful parts of find while removing the parts that turn searches into debugging sessions.

In day-to-day usage, fd feels like what you always wanted find to be:

It uses more predictable defaults (like not searching hidden files unless you ask).
It tends to keep commands short and readable.
It encourages a “filter-first” mindset without a wall of parentheses and operators.

Example: locate a file name pattern:

find . -name "nginx.conf"

becomes:

fd nginx.conf

Search by extension:

fd '*.rs'

Or combine with actions—like previewing matches or piping results into other tools—without drowning in boilerplate:

fd "main" --type f -x rg "fn main"

The practical win is confidence. If a command is easier to write correctly, you run it more often and with fewer second thoughts.

bat vs cat: readability as a feature, not a luxury

cat is fine for dumping content, but it’s optimized for the past. Once your terminals became visual workspaces, “readable output” became part of productivity. bat steps in here by adding syntax highlighting and paging that behave like a modern CLI viewer.

Instead of:

cat server.go

you reach for:

bat server.go

What changes immediately?

You can scan code and configuration without squinting.
Syntax highlighting reduces the cognitive load of identifying structure.
Paging makes long files survivable without redirecting output to less manually.

This is one of those upgrades that feels small until you switch back. After a week of bat, plain cat looks like you forgot to configure your editor.

eza vs ls: modern listing without losing the Unix vibe

Unix veterans can quote ls options like scripture. But ls has always been oddly stuck between “simple directory listing” and “everything you need to configure yourself into usefulness.”

eza is essentially a modernization of directory viewing:

Better formatting that makes columns and file types more legible.
More helpful defaults for humans scanning output.
Still firmly in the “terminal-first” tradition.

Try a default list:

ls

and then:

eza

You’ll quickly notice that your eyes spend less time decoding and more time deciding what to do next. That matters when you’re sorting through build directories, logs, or “what did this command generate?” moments.

The important point: eza doesn’t pretend to be a filesystem explorer. It’s still a CLI listing tool. It just stops treating your terminal like a monochrome environment.

zoxide: instant `cd` built from your real habits

Navigation is the hidden tax in terminal workflows. Even if you have the perfect search tool, you still lose time every time you have to remember where something lives—or worse, where it used to live.

zoxide attacks this directly: it learns directory usage patterns and lets you jump there quickly with a short query. Instead of relying on memory, it relies on your behavior.

A typical flow looks like:

z src

and suddenly you’re in the directory that most often matches “src” in your recent activity. It’s not magic; it’s just data-driven convenience.

The practical benefits show up in exactly the moments you’d otherwise open a file manager:

“Where’s that project I touched yesterday?”
“I know the directory name has ‘client’ somewhere—what was it again?”
“I keep bouncing between infra/ and services/—why am I walking there every time?”

With zoxide, the answer is: you don’t walk. You jump.

delta: the missing layer between git diff and your brain

Version control diffs are a necessary evil. git diff is technically correct, but it’s not always human-friendly. When diffs get large, you end up reading patch hunks like they’re ancient scrolls.

delta makes diffs substantially more readable by enhancing presentation—coloring, grouping, and highlighting changes so the important parts stand out. If you’ve ever thought “I know what I changed, but why is it so hard to see it in the output?”, you’ll understand what delta solves.

A common workflow:

git diff

turns into a better experience after configuring your git pager to use delta. The immediate payoff is that reviews become faster for you, and debugging becomes less tedious for everyone.

And importantly, this is not only for pull requests. Even your own local iteration benefits. When you’re trying to validate a change, clarity in diff output reduces the number of times you have to re-run commands or re-open files just to confirm what actually moved.

The pattern: Rust isn’t replacing Python—it’s replacing C

Here’s the sharper takeaway: Rust’s sweet spot, in this ecosystem, isn’t “yet another language for everything.” It’s replacing the systems tooling layer—the C-era Unix toolbox that powers your day-to-day performance needs.

That matters because the Rust ecosystem is built on constraints that fit CLI design:

Efficient binaries and predictable runtime behavior.
Strong tooling for correctness and maintainability.
A community culture that ships usable defaults and polished output.

You can see it across these tools: rg and fd reduce wasted time; bat improves readability; eza makes directories legible; zoxide accelerates navigation; delta turns raw diffs into something you can actually interpret at speed.

It’s not just a set of trendy commands. It’s an operating system for developers that happens to live in your terminal.

Conclusion: switch your defaults, not just your commands

If your terminal is where you work, you should treat CLI tooling like infrastructure. And the Rust ecosystem has done something rare: it replaced familiar classics with better UX and better performance without breaking the underlying Unix spirit.

Start small. Pick one pain point—search, finding files, viewing content, listing directories, navigation, or diff readability—and swap in the Rust tool that targets it. Run it for a week. If you’re like most people, you won’t miss the old default—and you’ll wonder how you managed without it.

AI Code Review Is Coming Whether You Like It or Not

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 14 Apr 2024 00:00:00 +0000

AI code review bots are no longer an experimental curiosity—they’re becoming a default layer of your engineering process. The uncomfortable truth is that this is happening regardless of whether your team trusts the tooling. The only real choice you have is whether you’ll treat AI review as a tool with guardrails (and measurable outcomes) or as a new source of code review theater that clutters your pull requests.

The good news: modern AI review assistants are genuinely catching real bugs. The bad news: they’re also introducing fresh failure modes—especially around style churn, false positives, and verbose “autopsy reports” of changes everyone can already see. This article lays out what’s actually happening, where the value is real, and how to set policies so AI becomes signal—not noise.

Why AI reviews are suddenly worth paying attention to

Traditional code review is expensive because it’s mostly manual attention. A human reviewer can miss issues under time pressure, and they can’t easily enforce consistent checks across a large codebase. AI-powered review tools sit in the middle: they read diffs, infer intent, and then propose issues or improvements in the same place developers already work—inside pull requests.

In practice, this often looks like:

Null or invalid-state risks: e.g., “user can be null when passed into calculateDiscount(user)” or “response.getBody() may be null in error paths.”
Untested edge cases: e.g., “What happens when the list is empty?” or “pageToken is optional, but pagination logic assumes it’s present.”
Security footguns: e.g., “Avoid string concatenation in SQL queries,” “Don’t log secrets,” or “Validate untrusted input before deserialization.”
Exception and control-flow gaps: e.g., “This catch block swallows the error and hides failures from callers.”

These are the kinds of problems that slip past even careful reviewers—especially when the diff is small but the behavioral impact is large. AI isn’t magical, but it is fast, consistent, and good at noticing patterns that humans skim past.

The key change is that the signal-to-noise ratio is improving. Earlier generations of assistants were often verbose and wrong. Now, many teams report that the “this might be a real issue” comments land more often than not—especially in languages and frameworks where common bug patterns repeat frequently.

The new problem isn’t mistakes—it’s review theater

As AI reviews become more common, the biggest threat to developer velocity isn’t that bots are wrong. It’s that bots can be confident while producing comments that don’t deserve engineering time.

Code review theater looks like this:

A bot drops a multi-paragraph summary of a change that the author already knows.
It recommends renaming variables or reformatting code in ways that conflict with team conventions.
It flags “issues” that are intentional—like a deliberate empty catch block used to preserve backward compatibility or an exception-throwing pattern that’s enforced by an architectural guideline.
It repeats the same generic suggestions across many files, turning each PR into a small inbox war.

Here’s a concrete example. Imagine a team uses a particular Java style:

// Intentionally empty: we preserve behavior for legacy clients.
catch (IOException ignored) {
}

An AI reviewer might suggest logging the exception or rethrowing it. Both are reasonable in general, but if the team policy is to preserve legacy semantics, the review comment becomes noise. If the bot keeps generating these “reasonable but policy-breaking” suggestions, developers start ignoring AI feedback entirely—or worse, argue with it in every PR.

That’s the new theater category: review comments that sound technical but don’t map to the team’s actual correctness contract.

Where AI actually helps most (and where it doesn’t)

AI code review is strongest when the reviewer’s job is to enforce repeatable constraints and spot known risk patterns. It’s weakest when the reviewer’s job is to enforce human judgment—things like architectural tradeoffs, domain-specific invariants, and stylistic consistency that isn’t codified anywhere.

High-value targets for AI review

Input validation and trust boundaries: “Where does this value come from?” “Is it sanitized before use?”
Resource handling: streams, DB connections, timeouts, cancellation tokens.
Error handling quality: swallowing exceptions, missing retries, inconsistent error propagation.
Concurrency hazards: shared state, lock ordering issues, unsafe access patterns.
Dependency and configuration security: insecure defaults, weak cipher choices, unsafe file operations.

Low-value targets for AI review

Pure style preferences: line wrapping, naming opinions, formatter debates (unless your team explicitly wants it).
Over-explanations: “This change updates validation logic” when the diff already makes that obvious.
Policy conflicts: anything that contradicts documented conventions (logging rules, exception patterns, performance constraints).

The practical takeaway: if you don’t already have a crisp definition of “what counts as correctness,” AI will happily propose what it thinks correctness means. That’s why the next section matters.

Establish policies now: treat AI as an automated reviewer with rules

If you wait until AI becomes ubiquitous in your org, you’ll be forced into reactive cleanup. Start now with a few concrete policies that determine what AI is allowed to comment on, how teams respond, and how the organization measures success.

1) Decide what AI must never override

Write down a short list of “AI non-goals.” For example:

No stylistic refactors unless they are required for correctness.
No comments that conflict with documented architecture or legacy compatibility policies.
No blocking PRs for issues labeled “suggestions” or “considerations,” unless they match an explicit rule set.

Then enforce it operationally: require that PR authors can mark AI comments as “won’t fix (policy)” without starting debate.

2) Require a classification: “Bug / Risk / Style / Explanation”

Good AI tooling already returns structured comments sometimes, but even if it doesn’t, your team can enforce a convention:

Bug: likely incorrect behavior (null dereference, missing return, incorrect condition).
Risk: likely issue under certain conditions (unhandled edge cases, insecure defaults).
Style: readability or formatting improvements.
Explanation: redundant “what changed” summaries.

Your policy can then say: bugs and risks must be addressed (or explicitly justified). Style and explanation should be ignored unless you opt in.

3) Convert AI feedback into “actionable diff changes”

A bot that says “Consider improving exception handling” is low value. A bot that says “This path can throw NPE because x is null; fix by guarding before dereference” is actionable. When reviewing AI output, prioritize comments that point to:

the exact location in the diff,
the reason it’s a risk,
and the minimal change needed to fix it.

If AI can’t do that, it probably belongs in the “theater” bucket.

4) Make the bot’s output measurable

You don’t need complicated metrics. Just track:

Accepted AI findings: how many bot comments you actually fix.
Dismissed AI findings: and why (false positive, policy conflict, style).
Time cost: did it slow down PR merges or add helpful pre-checks?

Within a few weeks, you’ll learn whether your team should tune the tool, change prompt settings (where supported), or adjust which checks are enabled. Most importantly, you’ll stop treating AI as a vibes-based debate.

Integrate AI with CI/CD, not as a replacement for engineering judgment

The mistake many teams make is trying to make AI “the reviewer of record.” Don’t. AI should complement your existing guardrails:

Static analysis: linters, type checkers, security scanners.
Tests: unit/integration, plus targeted regression tests for previously found classes of bugs.
SAST/DAST: where appropriate.
Build-time policies: required code owners, required checks, and branch protection.

AI should primarily help before code hits these systems: catching obvious mistakes while the change is still cheap to modify. Think of it as the earliest possible triage layer.

Here’s a practical workflow that tends to work well:

Developer opens PR.
AI runs and posts comments.
The author resolves or tags each comment according to your classification policy.
Humans focus on the remaining high-impact review: architecture, performance, semantics, and testing strategy.
CI verifies correctness. AI becomes a pre-filter, not a final authority.

This approach keeps AI from becoming a parallel “review meeting” that never ends.

What to do in the next quarter: a rollout plan that won’t break your team

If AI review is coming for you, treat the rollout like any other tool adoption—with sequencing, expectations, and escape hatches.

Week 1–2: Establish rules.

Create the classification scheme (Bug/Risk/Style/Explanation).
Define “allowed” and “not allowed” comment types.
Document the expected response format for each category.

Week 3–4: Pilot on a limited scope.

Choose one repo or a subset of services.
Start with non-blocking review comments.
Collect dismissal reasons to spot policy conflicts quickly.

Week 5–8: Tune and integrate.

Disable style-heavy suggestions if they dominate the feed.
Encourage the team to tag false positives so you can adjust later.
Link AI findings to existing checks (e.g., when it flags insecure patterns, ensure your security scanners confirm them).

Week 9–12: Expand with confidence.

If bug and risk acceptance rates are high and PR cycle time doesn’t worsen, expand.
If theater dominates, tighten rules and reduce comment types.

Most teams don’t fail because the tool is bad. They fail because they try to roll out AI review without first deciding what “good review” means.

Conclusion: the future is automated review—so make it automated correctly

AI code review is not a question of if; it’s a question of how smoothly you absorb it. The best bots are already finding real bugs and security risks. The worst outcomes happen when teams treat AI comments as a new kind of mandatory ritual, generating theater instead of accountability.

Your move is simple and urgent: set policies now, classify AI feedback, measure what’s useful, and integrate AI with the rest of your CI/CD guardrails. If you do that, AI won’t replace your reviewers—it’ll make them faster, sharper, and less burdened by the kinds of repetitive mistakes humans are never going to catch every time.

HTMX Crossed the Chasm: Production Adoption Stories from Real Teams

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 08 Apr 2024 00:00:00 +0000

A year ago, htmx was still being debated in the “interesting demo” lane. Now it’s showing up where it matters: internal tools, admin panels, dashboards, and CRUD-heavy apps that need to feel fast—without turning your frontend into a second engineering organization. Teams aren’t adopting htmx because it’s clever. They’re adopting it because it’s pragmatic.

Below are the patterns that kept repeating across fifteen production teams in 2024—spanning Fortune 500 internal tooling, Django modernization efforts, Go and .NET backends, and even Rails teams rediscovering the power of server-driven UI. The takeaway is simple and slightly contrarian: htmx succeeds when you stop treating server-rendered HTML like a limitation and start treating it like an advantage.

Why htmx “clicked” in production environments

Most teams don’t start with htmx as a grand architectural rewrite. They start with a concrete pain:

“Our admin UI feels sluggish.”
“We’re shipping too much JavaScript for simple interactions.”
“We can’t keep the frontend and backend in sync without constant coordination.”
“The SPA route is expensive—too many states, too many edge cases, too many bugs.”

htmx offers a way out that aligns with how many organizations already build: render HTML on the server, then progressively enhance it with targeted requests. Instead of building a full client-side application shell, you sprinkle interactivity onto server-rendered pages.

That sounds academic until you watch teams operationalize it. In practice, htmx let them keep their existing backend model layer (Django models, Rails models, Go handlers, .NET controllers) and reuse their rendering templates. The “frontend” became a thin layer of markup + attributes, not a new runtime.

The common migration path: start small, get real value in days

Across the teams that adopted htmx successfully, the story was consistently incremental. They didn’t replace everything at once; they replaced the parts that were slow, brittle, or overly complex.

A typical sequence looked like this:

Identify the worst UX hotspots
Search for interactions that currently require page reloads or complicated JavaScript—filters, inline edits, status toggles, pagination, dependent dropdowns.
Convert one interaction to htmx
For example, replace a “Submit → reload page” flow with an htmx request that updates only the relevant fragment.
Wire server responses to HTML, not JSON
Templates return markup for the updated component. The browser swaps it in.
Scale gradually
Once the team trusts the pattern, more interactions move to htmx one at a time.

One Django team described converting an admin filter: instead of requesting data via a JS layer and re-rendering tables client-side, they returned the filtered table fragment from Django and let htmx swap it in. The result wasn’t just faster development—it was fewer moving parts. No client-side state machine. No duplicated rendering logic. No synchronization problems.

In the dataset, the average time to “productive htmx usage” was about three days—not weeks. That speed matters because it prevents the migration from becoming a never-ending design project.

What “reduced frontend complexity” actually meant

Teams reported an average 60–80% reduction in frontend complexity. That phrasing can sound vague, so here’s what it usually looked like in real codebases:

Less UI duplication: with htmx, the server already knows how to render “the truth.” The browser doesn’t need a separate rendering pipeline.
Fewer libraries: teams leaned on existing template tooling instead of layering state management and routing frameworks.
Smaller cognitive surface area: rather than reasoning about component trees, hydration, and async state, developers reason about requests and responses.

Consider an internal approval workflow. Before htmx, a team might have built a React component hierarchy just to support:

Approve/reject buttons
Reason fields shown conditionally
Status badges updating instantly
Activity logs expanding without full reloads

With htmx, the page becomes a set of server-rendered components, each with an endpoint that can return updated HTML fragments. The “asynchrony” is handled by HTTP requests and HTML swaps—meaning the mental model stays close to web fundamentals.

And yes, this reduces bug classes. You still have edge cases, but they’re generally “HTTP and rendering” edge cases, not “client state drift” edge cases.

The Fortune 500 internal tools pattern: security + velocity

One reason htmx landed early in enterprise internal tooling: it fits how these systems are governed. Many Fortune 500 environments have:

mature authentication/authorization patterns
strict audit requirements
existing server-side validation
legacy-ish templates that still run critical workflows

htmx made it feasible to modernize without detonating the security model. Instead of building a new SPA that must re-implement authentication flows, authorization checks, and permission logic on the client, teams kept authorization on the server. The browser just asks for HTML fragments.

A common production decision: make every htmx request go through the same authorization gates as full-page requests. That preserves auditability and reduces “special-case” vulnerabilities where a fragment endpoint might accidentally become less protected than the surrounding page.

Where teams really felt the impact was speed to iteration. Instead of coordination overhead between backend and a complex frontend team, a full-stack developer could add an interaction by:

updating a template fragment
wiring an endpoint
adding an htmx attribute to the triggering element

That’s not theoretical. It’s the difference between “we’ll add that feature next quarter” and “we shipped it this week.”

Where teams struggled: treating htmx like a SPA framework

For every success story, there’s a failure mode. The teams that struggled shared one anti-pattern: they tried to use htmx as if it were a replacement for SPA-level state management.

The symptom was usually the same:

lots of client-side logic creeping into the markup
“component state” being tracked in the browser anyway
endpoints returning fragments that depended on complex hidden state
interactions that required global client coordination

In other words, they built a pseudo-SPA—but with none of the ergonomic guarantees of a real SPA framework. That combination is painful.

The practical fix is architectural honesty: embrace server-driven UI. Let the server be the source of truth for what the UI should look like after an action. If you need shared state, push it into the rendered HTML or session-backed server state—then return updated fragments that reflect it.

A useful rule of thumb:
If an interaction requires complex client-side state orchestration, it’s probably not an htmx-first problem. htmx shines when the “next UI” can be derived from the request and server state.

Concrete patterns that worked across Django, Rails, Go, and .NET

Even with different stacks, the best teams converged on similar techniques.

1) Treat UI fragments as first-class endpoints

Create dedicated routes that return HTML snippets for specific components—tables, forms, status panels. Keep the contract simple: request parameters in, HTML fragment out.

Example flow:

User clicks “Toggle status”
htmx POSTs to /admin/items/{id}/toggle
Server returns the updated table row or badge fragment
htmx swaps it into place

2) Use progressive enhancement intentionally

Start with a functional HTML page. Then layer htmx on top for interactions that benefit from partial updates. This keeps accessibility and non-JavaScript behavior intact without extra work.

3) Make errors renderable

Instead of returning raw JSON errors that the client must interpret, return the same fragment (or a close cousin) with validation messages and proper markup. Your UI stays consistent because it’s still server-rendered.

4) Keep requests scoped

Avoid turning the entire page into a single fragment update. Fine-grained swaps make the UI feel instant and reduce bandwidth. More importantly, it keeps debugging straightforward: you can inspect exactly what changed and why.

5) Prefer server-side templates to “client templates”

If the browser is going to render HTML, you’re back to a SPA problem—only with worse tooling. htmx encourages you to render on the server, where your existing template logic already lives.

Across Django shops, Rails teams, and backends in Go and .NET, those patterns reduced friction more than any specific “hacks.” The winning approach was boring: clean server endpoints, clean templates, targeted swaps.

Conclusion: the chasm isn’t about technology—it’s about mindset

htmx crossed the chasm because it respects how web apps work in the real world: server-rendered HTML, incremental enhancements, and straightforward request/response flows. Teams adopted it quickly—often within days—because it didn’t require a wholesale frontend re-platforming effort.

The consistent lesson from production teams in 2024 is equally clear: don’t try to make htmx behave like a SPA framework. Make it behave like what it is—a server-driven UI enhancement layer. If you do, you’ll get fast UI updates, smaller frontend complexity, and a migration path your engineers can actually sustain.

Svelte 5 Runes: The Framework That Keeps Getting Simpler

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 02 Apr 2024 00:00:00 +0000

UI frameworks don’t usually get simpler over time—they get more clever. They add new knobs, new mental models, and new ways to accidentally shoot your feet. Svelte 5 is different. With Runes, it leans harder into a philosophy that has always been its edge: stop fighting JavaScript’s ergonomics and instead compile the work you don’t want to do.

If you’ve ever thought “React is powerful, but why does it feel like I’m wiring the app myself?”—Svelte’s approach will feel like relief. Not because it’s less capable, but because it’s more direct.

The React vs. Svelte philosophy gap (and why it matters)

React’s story is built around one question: how do we make JavaScript do UI? That leads to a particular kind of framework: one that gives you primitives (components, hooks, effects) and expects you to assemble the rest with discipline and conventions.

Svelte starts from a different question: how do we make UI easy? It treats UI as a compile-time artifact. Instead of asking you to manage reactivity and rendering correctness with runtime abstractions, it asks how to generate the optimal code up front.

Runes are the sharpest expression of that gap. They don’t add more complexity to the developer experience; they reduce the number of times you have to remember what the framework needs from you.

What “runic reactivity” feels like in practice

Runes are Svelte’s reactivity system for Svelte 5. The headline idea is straightforward: you declare intent in a small, explicit syntax, and Svelte tracks what needs updating.

In other words, you don’t “teach” reactivity by using a particular lifecycle pattern or by memorizing rules like “this must be immutable” or “this dependency must be listed.” You describe reactive state and derived values, and the compiler handles the wiring.

Here’s the kind of mental shift you’re looking for.

A simple reactive state

In Svelte 5, reactive state can be expressed directly, without the old pattern of sprinkling $: everywhere just to coax updates into happening.

Instead of thinking “when do I need $:?”, you think “this variable is state.” Then you update it like normal state.

The practical impact is less code and fewer accidental bugs—especially in components that evolve over time.

Derived values without effect gymnastics

Once you have state, you almost always need derived values: formatting, filtering, computed totals, and so on. React tends to push people toward useMemo or derived state inside render, then adds a new layer of complexity: “is this memo actually needed, and did I get the dependency array right?”

Runes push derived state into the language of the framework itself. The result is that computed values stay aligned with their inputs by construction, not by developer diligence.

A common example: you have a price and a quantity, and you want total.

In React, you might write logic inside render and hope it’s fast enough, or you might introduce useMemo and carefully manage dependencies.
In Svelte with runic reactivity, the derived value reads like a first-class concept. You declare it once; Svelte keeps it correct.

That’s the difference between “patterns” and “capabilities.”

“use” is replaced by “just works”: ergonomics over rituals

Svelte 5 isn’t just about reactivity; it’s also about reducing the rituals developers pick up when they want reliable behavior.

React has its own modern rituals—server components, use() for suspending data flows, and increasingly arcane rendering patterns where correctness depends on when code runs and where state lives. Even when these tools are well-designed, they introduce new ways to be confused.

Svelte 5’s Runes aim to make the default behavior predictable. You don’t need to re-architect your component just to get updates to propagate cleanly. You express state and derivations directly, and the compiler does the bookkeeping.

If you’re building a form, the experience is especially noticeable:

React forms often become a tangle of state updates, controlled inputs, effects, and edge-case handling (stale closures, synchronization, rerender cascades).
Svelte can be more direct: state updates trigger the right downstream updates without you having to orchestrate a web of handlers and effects.

Developers don’t just want fewer lines—they want fewer failure modes.

Why the “compiler magic” angle is not marketing fluff

It’s tempting to treat “compiler” as a buzzword. But the practical payoff is tangible: less framework runtime, fewer abstractions, and less code shipped to the browser.

Svelte’s model is that your app is compiled into efficient JavaScript that includes the specific update logic for your components. That means users download less generic runtime code than they would with frameworks that perform more work at runtime to discover dependencies.

In the same way that a SQL query planner can optimize execution before the database even runs the query, Svelte compiles away generic uncertainty. It knows your component structure ahead of time, so it can produce targeted update logic.

This isn’t only about performance micro-benchmarks; it’s about simplicity:

Your mental model becomes smaller because the framework isn’t asking you to provide as many runtime hints.
Your bundle tends to be leaner because you aren’t carrying as much general machinery.

The most “Svelte” part of this is not that it’s fast. It’s that it feels like the framework is on your side.

A realistic migration mindset: adopt Runes where they hurt most

If you’re already comfortable with Svelte, Runes aren’t something you need to fear. They’re the natural evolution of how Svelte thinks about reactive intent.

If you’re coming from another framework, treat Runes as an adoption path:

Start with state: model your UI with explicit reactive values.
Add derived data: prefer computed transformations over “manual syncing” logic.
Only then worry about advanced patterns.

This order matters. The fastest way to feel friction is to start with patterns you already understand—then layer Runes in second. Instead, let Runes reshape your defaults.

A practical example: suppose you’re building a dashboard with filters.

First, model filters as state.
Next, derive filteredRows from filters and your raw dataset.
Finally, derive any UI strings (like “Showing 12 of 48 results”) from those computed values.

You’ll end up with a component where the dataflow is visible in the code, not hidden in the lifecycle timing of effects.

Developer satisfaction isn’t just taste—it’s feedback loops

There’s a reason developers tend to stick with Svelte when they switch: the feedback loop is tight. Changes in state lead to predictable UI updates. The code reads like intent. Debugging is less about tracing framework mechanics and more about checking your own logic.

That’s what high satisfaction usually means in practice. Not that nothing goes wrong, but that when it does, you’re not fighting the framework.

And it’s not a small difference. When your framework reduces boilerplate and discourages incorrect patterns, developers spend more time shipping the product and less time maintaining “framework correctness scaffolding.”

That is exactly the kind of payoff you get when a reactivity system is designed to be intuitive instead of merely powerful.

Conclusion: Svelte 5 keeps moving in the right direction

Runes in Svelte 5 aren’t just a new feature—they’re a continuation of the same promise: make UI authoring easier by compiling the heavy lifting away. The result is a framework that feels less like you’re negotiating with runtime behavior and more like you’re describing the UI you want.

If React often makes you ask how do I make this work?, Svelte with Runes pushes you toward here’s what the UI should be. And for a lot of teams, that shift is the difference between “framework that powers the app” and “framework that gets out of your way.”

Effect-TS Is the Most Important TypeScript Library Nobody's Using

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 21 Mar 2024 00:00:00 +0000

TypeScript made “working code” easy—but it didn’t make reliable code easy. Try/catch spaghetti creeps in, resources leak quietly, and error handling turns into a web of ad-hoc conventions no one remembers agreeing to. Effect-TS tackles those problems head-on with a composable model for errors, dependencies, and concurrency—without asking you to speak fluent category theory. It’s the rare library that feels like it was built by people who’ve spent nights debugging production incidents.

What Effect-TS actually changes (and what it doesn’t)

Effect-TS introduces a single core idea: instead of throwing and catching, you build descriptions of work that the runtime can execute safely. Think of it as a typed, structured “program” that can express:

Typed errors that are explicit and composable across boundaries
Dependency injection without a container framework
Concurrency with structured lifetimes, so tasks don’t outlive what they should
Operational concerns like retries, timeouts, caching, and observability—treated as first-class capabilities

Crucially, it doesn’t require you to adopt a new team-wide philosophy overnight. You can use it surgically: wrap the riskiest parts (network calls, file operations, background jobs) and leave the rest of your app alone. The best way to understand it is to compare it to the common alternative: Promise + try/catch + “whatever error shape happens to exist today.”

Effect doesn’t eliminate asynchrony. It makes it disciplined.

Typed errors that don’t evaporate across boundaries

In “classic” TypeScript, errors tend to become vibes. You’ll see something like:

async function fetchUser(id: string): Promise<User> {
 try {
 return await api.get(`/users/${id}`)
 } catch (e) {
 // Was this a timeout? 404? auth failure?
 throw e
 }
}

Now multiply that across services, and you get the real problem: the type system stops helping the moment the error crosses a function boundary. Effect-TS keeps error types attached to the work that can fail.

Practically, that means your function signatures communicate what can go wrong. You can also compose failures: map an error from one layer into a more meaningful domain error at the boundary.

A realistic example: suppose a payment service talks to an external provider. You want your application layer to know whether failures are “provider unavailable” vs “card declined,” and you want to preserve that classification even when you orchestrate multiple effects.

In Effect-TS terms, you’d create a workflow that can fail with a specific set of error types, and then transform them deliberately when crossing boundaries. The result is less defensive coding (“catch everything and rethrow”) and more intentional error contracts.

Opinionated takeaway: if you’ve ever written catch (e) { throw new Error("Something went wrong") } and regretted it later, typed errors are the missing ingredient.

Dependency injection without the container tax

If your experience with dependency injection is mostly a Spring-style container, you might think this becomes heavyweight. Effect-TS takes a different approach: dependencies are provided explicitly to the “program,” not hidden behind global mutable singletons.

That matters because it improves two things teams usually fight over:

Testability: swap real services with fakes quickly.
Clarity: see what a unit of work needs.

Instead of constructing everything manually inside the function (or relying on global variables), you define the effect to require certain capabilities (like HttpClient, Clock, Logger, or database access), then provide those capabilities at runtime.

Concretely, the win is this: when you test a piece of logic, you can supply deterministic implementations for time, randomness, storage, or external calls. No more brittle “monkey patching” modules or spinning up entire integration environments just to test a retry policy.

Also, because dependencies are scoped to the effect execution, you avoid the classic failure mode of DI containers: accidental cross-test contamination or accidental sharing of state.

The best part? You don’t need to refactor your entire codebase. Start with one module that already depends on half a dozen collaborators (common in API handlers and job processors), and convert it into an effect that states its needs explicitly.

Structured concurrency that prevents resource leaks

JavaScript concurrency is powerful—and remarkably good at leaking resources. You kick off a background task, the request finishes, and the task keeps running. Or you open a connection and forget to close it when an error occurs mid-flight.

Effect-TS promotes structured concurrency, meaning the lifetime of child work is tied to the parent. When the parent finishes (successfully or with failure), the runtime can ensure children are cancelled or completed appropriately. This is exactly the discipline you want around:

request-scoped background jobs
streaming pipelines
retries that shouldn’t outlive their caller
timeouts and cancellation boundaries

If you’ve ever debugged “why is the database pool exhausted only after errors spike,” you already know why this matters.

A practical pattern: wrap any “start something and later stop it” logic in the structured scope of the effect. Don’t rely on “eventually” or “we’ll clean up in catch”—make cleanup part of the program structure.

The result is not just fewer leaks. It’s confidence. You stop wondering whether a failure path accidentally left a task running.

Retry, caching, and observability—built into the workflow

Most teams treat retries, caching, and logging as bolt-ons. That leads to inconsistent behavior:

one service retries timeouts, another retries everything
one logs correlation IDs, another logs the entire error object (and may leak secrets)
caching sometimes happens at the edge, sometimes inside the service, sometimes nowhere

Effect-TS treats operational behavior as part of the effect composition. That’s the difference between “we hope the retry code is correct” and “retry policy is a deliberate component of the workflow.”

Here’s how this typically plays out in real apps:

Retry policies: Retry transient failures (like network timeouts) with backoff, but stop on non-transient errors (like invalid input).
Caching: Cache pure-ish reads (like “get config for tenant”) while still respecting invalidation boundaries you control.
Observability: Emit consistent logs/metrics/traces around the effect execution, including error classification.

You can apply these policies at the edges of your domain workflows, not scattered across every low-level API wrapper. For example: put retry/circuit-break behavior around the external-provider call, not in every business function that happens to call it.

If you want a simple rule: when you can describe the operational intent, you should encode it once—then reuse it everywhere by composing effects.

The API is big, but each part earns its keep

Effect-TS can feel daunting at first. There are multiple modules, combinators, and concepts. But the “big API” issue is mostly an onboarding problem—because the primitives map to real production concerns.

Here’s a practical mental model you can use:

Effects are the unit of work (typed failures included)
Layers/capabilities provide dependencies in a scoped way
Combinators transform and compose workflows (mapping errors, sequencing steps, branching)
Concurrency primitives give you controlled parallelism
Runtime execution interprets the plan and applies resource safety

Instead of trying to learn everything, pick one workflow type and implement it end-to-end:

Write an effect that calls an external service and models its error types.
Add a retry policy only for the error subset that is transient.
Add timeout and cancellation behavior.
Add logging/metrics around the effect execution.
Provide dependencies via test doubles in unit tests.

That workflow touches the core value propositions immediately, and you’ll learn the rest naturally as you go.

Conclusion: Effect-TS is a practical upgrade to how you handle failure

Effect-TS isn’t “FP cosplay.” It’s a disciplined approach to the exact places where production systems hurt: error handling that degrades across boundaries, hidden dependencies, and concurrency that leaks. You don’t need a PhD to get value—you need typed contracts, scoped dependencies, and structured concurrency that behaves correctly under failure.

If you’ve written too many catch blocks, cleaned up too many hanging tasks, or lost too many hours to “mystery errors,” Effect-TS is worth putting on your shortlist. Convert one critical path first. The confidence gain is immediate, and the payoff compounds fast.

Bun 1.0 Is Here and Node.js Should Be Nervous

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 09 Mar 2024 00:00:00 +0000

For a long time, Bun lived in the “nice benchmark” corner of the JavaScript universe. Fast startup, impressive throughput, and a promise that someday it would feel like a real platform. Bun 1.0 collapses that gap. It’s no longer just a faster way to run JavaScript—it’s a complete runtime with the tooling you actually need to ship production software. Node.js isn’t dead, but its “default by inertia” advantage just got more fragile.

What Changed With Bun 1.0 (And Why It Matters)

Bun 1.0 isn’t a cosmetic release. The big shift is that Bun now behaves like a complete application platform, not a “run the script” novelty. The runtime comes with its own:

package manager (so you’re not forced back into npm workflows)
test runner (so your CI and local developer loop can stay in one place)
bundler (so you can build, ship, and optimize without bolt-on tooling)

In practice, that means teams can stop treating Bun as a performance experiment and start treating it as a serious choice for new services, CLIs, and even web backends that want to stay lightweight.

This is also where “benchmarks” stop being the whole story. A fast runtime is helpful, but developers buy stability: predictable builds, familiar workflows, and tooling that doesn’t fight you. Bun 1.0 is trying to win on that axis.

The Performance Story Isn’t Just a Gimmick Anymore

Let’s be honest: Node.js has been optimized for years, and it still runs a huge portion of the internet. That’s why performance claims matter only when they translate into real daily wins.

Bun’s headline advantages are still hard to ignore:

startup times that feel dramatically faster—especially noticeable in dev loops and short-lived serverless-style workloads
throughput wins on many common server workloads where JavaScript execution and module loading dominate

The practical effect is less “look, numbers” and more “how does this change my workflow?” If your project spins up containers, restarts processes frequently during deployments, or runs many short tasks (think CI jobs, background workers, scheduled scripts), startup speed directly reduces waiting.

Example: imagine a team with a microservice architecture where each service is restarted often during rollouts. If your runtime starts in a fraction of the time, you shorten the feedback loop for deployments and debugging. That compounds into fewer hours lost to “where did it hang this time?” and faster iteration.

Is Bun always faster? No. Performance is workload-specific. But the key point is that Bun 1.0 is designed to be used end-to-end—so you don’t just get a faster “node app start,” you get a faster path from dependencies → tests → bundles → execution.

Node.js Compatibility: “Strong Enough” Becomes a Real Strategy

The other big lever is compatibility. Bun’s npm compatibility story is strong enough that many Node.js projects can switch with minimal changes.

For teams considering migration, this is the most important kind of “works on my machine” that actually matters: fewer rewrites, fewer dependency surprises, fewer weeks lost to edge-case debugging.

A practical migration approach looks like this:

Start with the app’s dependency graph. In many Node projects, the dependency set is the hardest part. Try swapping the runtime and see whether Bun can install dependencies and resolve imports without chaos.
Run the test suite immediately. Bun’s test runner helps keep this close to the toolchain. If tests pass, you’ve already cleared the biggest hurdle: behavioral compatibility.
Build with the bundler. If your project depends on bundling for production artifacts, test that path early. A runtime switch that breaks packaging is not a victory—it’s just a delay.
Fix the handful of friction points. Expect some ecosystem edges: subtle differences in how specific Node APIs behave, or assumptions made by certain libraries. The difference now is that Bun gives you enough tooling to iterate quickly.

Opinionated take: if your project is greenfield, you shouldn’t wait for a hypothetical perfect compatibility story. If you already have a mature Node codebase, don’t romanticize migration either—trial Bun in a branch, run tests, and measure end-to-end build/run time. The “minimal changes” promise is only real when validated against your dependencies and your deployment shape.

Tooling Is the Battleground Now: Package, Test, Bundle

Node.js has enjoyed a decade of “best-of-breed” tooling, and that ecosystem is real. But Bun’s bet is that you shouldn’t have to stitch together four or five tools just to ship a modern application.

Bun 1.0 gives you a cohesive toolchain:

Package management that’s designed to work naturally with the runtime.
A test runner that fits into the developer workflow.
A bundler that supports production packaging without forcing you to build around a separate stack.

Here’s how this shows up for day-to-day development.

Example: a lightweight web service project

A typical team wants:

install to be fast and predictable
test to run quickly locally and reliably in CI
build to generate output that deploys cleanly

With Bun 1.0, you can keep those steps inside one “Bun-native” workflow. That reduces context switching: fewer config formats, fewer script adapters, fewer “why does this work with Webpack but not with our custom setup?” moments.

And because the runtime is tied to the tooling, you’re less likely to hit performance mismatches where your bundler is fast but your runtime cold-start is slow, or where your install is quick but your test harness lags behind.

When Bun Is the Right Choice (and When It Isn’t)

Bun’s momentum is not just about speed—it’s about the cost of adoption. The more your project values fast feedback and simple toolchains, the more Bun makes sense.

Bun is a strong fit if…

You’re building greenfield services or tooling and you want a modern, cohesive dev workflow.
You run workloads that benefit from startup speed (many short-lived processes, dev servers, CI tasks, serverless-style execution).
You want to standardize on a single runtime and toolchain to reduce friction.

Node.js is still the safer default if…

You have a highly specialized dependency stack that you can’t comfortably validate in time.
Your team has deep investment in Node-only tooling and you’re not ready to revisit build/test pipelines.
You rely on edge-case behavior from Node APIs where library support may lag.

Here’s the sharper truth: Node isn’t going anywhere soon. Even if Bun becomes the better choice for new projects, Node will remain the compatibility baseline for enterprise systems, long-lived apps, and libraries that assume Node semantics.

But for greenfield projects, the “default to Node forever” posture should be questioned. Monthly, the case for choosing Bun gets easier: the tooling is already there, the ecosystem compatibility is strong enough to start, and the performance advantages translate into real workflow improvements.

A Migration Playbook That Doesn’t Waste Time

If you’re on Node and wondering whether to try Bun, treat it like a controlled experiment—not a rewrite.

Clone the repo and switch runtime in a feature branch.
Run install and confirm dependencies resolve.
Run unit tests and integration tests. Fix the smallest set of issues first.
Run your build pipeline and verify that production artifacts behave correctly.
Compare cold-start and CI timing. Don’t just benchmark “node vs bun” in isolation—measure your actual pipeline steps: install → test → build → run.

If your project has a CI pipeline, make it the truth serum. It’s the most repeatable environment you’ll have, and it reveals whether Bun’s toolchain is truly frictionless under pressure.

And keep one pragmatic rule: don’t migrate everything at once. Start with one service, one repo, or one subset of jobs. If Bun is going to improve your day-to-day, you’ll see it quickly—without risking the whole organization.

Conclusion: Node Should Stay Confident—But It Shouldn’t Stay Complacent

Bun 1.0 changes the conversation. The runtime isn’t “just benchmarks” anymore; it’s a complete toolkit with package management, testing, and bundling built in. The performance story remains compelling, and—crucially—it’s now wrapped in workflows that feel production-ready.

Node.js will keep its place in the ecosystem for a long time. But for greenfield projects, the default choice is no longer automatic. Bun has narrowed the gap between “fast on my laptop” and “works as a platform,” and that’s exactly what makes teams pay attention.

If you’re building new systems in the next quarter, you should at least evaluate Bun—because the longer you wait, the more likely you are to feel left behind by teams that already made the switch.

Tailwind v4 Alpha: CSS Variables, Lightning CSS, and a Ground-Up Rewrite

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 03 Mar 2024 00:00:00 +0000

Utility-first CSS didn’t just “catch on”—it rewired how teams ship interfaces. Tailwind’s winning formula was always pragmatic: generate exactly what you need, avoid bespoke CSS sprawl, and let design systems evolve without constant refactors. Tailwind v4 doesn’t chase more features. It goes after the engine room—swapping out the build pipeline, changing the theming model, and embracing native CSS capabilities so the framework can scale with performance instead of fighting it.

What follows is the big picture: Tailwind v4 Alpha replaces the PostCSS-based workflow with Lightning CSS (a Rust-powered parser), moves theming to CSS custom properties, introduces cascade layers, and shifts configuration from JavaScript into CSS via @theme. This isn’t a cosmetic update. It’s a fundamentals rewrite—arguably the most significant since Tailwind 1.0.

The real shift: from PostCSS utilities to a new CSS compiler pipeline

Tailwind has historically relied on PostCSS as its transformation layer: parse your source, interpret classes, and generate CSS. That approach worked brilliantly for years—until it became the ceiling for performance, determinism, and output control.

Tailwind v4 replaces that engine. The headline change is Lightning CSS: a fast CSS parser and transformer built in Rust. Practically, this matters in two ways:

Faster builds with the same mental model. When your tooling spends less time parsing and rewriting, iteration loops tighten. Teams feel this immediately: fewer “wait for the build” moments, and more time designing.
More predictable CSS transformations. Utility frameworks generate lots of CSS under the hood. A more capable CSS pipeline helps ensure the framework’s output is easier to reason about when something goes wrong.

If you’ve ever debugged “why did this utility not apply?” or “why is this rule winning?” you know the pain isn’t the concept—it’s the compiled output. A modern compiler pipeline is partly about speed, but it’s also about producing CSS that behaves consistently with the platform.

Concrete example: fewer moving parts when you inspect output

In a PostCSS-based setup, your compiled CSS can reflect multiple passes and plugin behaviors. With a more direct CSS pipeline, you’re more likely to see cleaner, more intentional output.

Try it yourself: build the same small demo with Tailwind v3 and v4, then inspect the generated CSS. You’re looking for legibility, not just size. Even if the output “looks different,” the goal is that it’s easier to debug because the pipeline is less hand-wavy.

The theming revolution: CSS custom properties as the new contract

Tailwind v3 pushed theme customization through config—centralizing design tokens in JavaScript objects and then generating styles. Tailwind v4 takes a bolder stance: use CSS custom properties as the primary theming mechanism.

This is a meaningful shift because custom properties are native, dynamic, and cascade-friendly. They let you change theme values at runtime, support theming per subtree, and integrate more naturally with component libraries and design tokens.

What changes for developers?

Instead of thinking “my colors are defined in JS and compiled into CSS once,” you start thinking “my tokens are variables resolved by CSS at runtime.”

Concretely, this enables patterns like:

Theme switching without rebuilding CSS. Flip variables at the root (or within a container) and the UI updates.
Component-scoped theming. Apply a different theme inside a modal or a card by overriding variables there.
Better interop with design systems. If your design system already exports CSS variables, Tailwind can align with it instead of duplicating it.

A practical pattern: light/dark using variables

Even without diving into exact syntax yet, the workflow becomes intuitive:

Define base variables for colors (e.g., --color-bg, --color-fg).
Map Tailwind utilities to those variables.
Override variables in [data-theme="dark"] (or the relevant selector).
Use standard utilities (bg-*, text-*) as if nothing changed.

This shifts theming from “generate two bundles” to “generate one stylesheet that can adapt.”

Native cascade layers: stop playing whack-a-mole with specificity

If Tailwind has taught teams anything, it’s that specificity wars are avoidable when you control the cascade. Tailwind v4 adds native cascade layers. This is not an aesthetic upgrade; it’s a strategy upgrade.

Cascade layers let you define priority between groups of rules (e.g., framework utilities vs. component overrides vs. app-specific styles). Instead of relying on fragile ordering or !important, you can tell the browser how to resolve competing declarations.

Why it matters for utility-first CSS

Utility frameworks generate many selectors. In a complex app, you inevitably layer on:

component styles,
overrides,
third-party CSS,
and bespoke rules.

Without a clear cascade strategy, you end up with “works until it doesn’t,” then sprinkle overrides to regain control.

With cascade layers, you can keep utilities powerful while still guaranteeing that your app and components override them deterministically.

Practical advice: treat layers like contracts

Use layers to formalize your stylesheet hierarchy:

Framework layer: generated utilities and base styles.
Component layer: your design system components.
App layer: routing pages, layout overrides, emergency fixes (hopefully rare).

The win is fewer surprises: when you adjust a component, you won’t accidentally override utilities because some rule order flipped after a dependency update.

Configuration goes CSS-first: `@theme` beats “everything in JavaScript”

The most jarring change—at least conceptually—is the move from JavaScript configuration to CSS-based directives using @theme.

Tailwind historically lived in tailwind.config.js. That file is powerful, but it’s also a separate language with its own runtime assumptions. When the framework is shifting toward CSS variables and native cascade features, it makes sense to move configuration into the same domain where the output ultimately lives: CSS.

Why CSS-based theming is a win

When your theme definition is written in CSS:

It aligns with the browser’s actual rendering model (variables + cascade).
It reduces the impedance mismatch between “design tokens” and “style rules.”
It encourages teams to version and review theme changes alongside CSS semantics.

A concrete example: token definition becomes “just CSS”

Instead of tweaking a JS object and re-running a build pipeline to understand what changes, you can:

inspect the theme definitions directly,
override variables in CSS,
and rely on cascade layers for predictable resolution.

This also improves portability. If your org already manages design tokens in CSS (or can export them as CSS variables), Tailwind v4 can adopt them with less glue.

Lightning-fast builds and smaller CSS: what to expect in the real world

The most exciting part of the rewrite isn’t theoretical. It’s the expected outcomes: build times dropping dramatically, and CSS output shrinking.

But numbers aren’t the story. The story is workflow quality.

What “smaller CSS” changes day-to-day

Less CSS means:

Faster page loads (especially for CSS-heavy apps).
Less time parsing styles on the client.
Fewer edge cases where unused or conflicting rules create weird rendering.

Even if your app doesn’t ship a “huge” stylesheet, Tailwind projects tend to accumulate utility usage over time. A tighter output pipeline helps keep that growth in check.

A quick checklist to validate improvements

If you’re evaluating Tailwind v4 Alpha, don’t trust vibes—measure:

Track build time for a representative project (same machine, same dev actions).
Inspect compiled CSS size (gzip/brotli too, not just raw bytes).
Render critical pages and ensure no specificity regressions.
Test theming changes (e.g., toggle dark mode) without rebuilds if your workflow supports it.

You’re not just verifying “it’s faster.” You’re verifying it behaves like a production-ready toolchain should.

The migration posture: don’t wait for perfection—adapt the mental model

Tailwind v4 Alpha is a signal: the framework is investing in performance infrastructure and aligning more closely with native CSS capabilities. That means the “how” of Tailwind changes even when the “what” (utility-first classes) stays familiar.

If you’re planning a migration, here’s the approach that reduces pain:

Start with small surfaces. Pick one feature area (e.g., a page with light/dark theming) and migrate it.
Lean into CSS variables. Don’t fight the new theming model—use variables to align tokens across your stack.
Adopt cascade layers early. Even if you keep overrides minimal, layers prevent future specificity chaos.
Treat @theme as your source of truth. Minimize dual definitions (JS + CSS) during transition.

And be honest: if your team is heavily invested in custom PostCSS or complex build-time plugins, you’ll need to validate those integrations carefully. A new engine is an opportunity, but it’s also a forcing function to simplify.

Conclusion: Tailwind is still utility-first—now it’s platform-first

Tailwind v4 Alpha reads like a mature framework choosing to optimize where it matters: the CSS pipeline, the cascade, and the theming model. Lightning CSS replaces the older PostCSS-driven engine with something built for speed and consistency. CSS custom properties move theming from “compiled config” to “runtime-native tokens.” Cascade layers bring deterministic override behavior to the chaos of real apps. And @theme shifts configuration into CSS, where it naturally belongs.

This isn’t Tailwind chasing novelty. It’s Tailwind making the case that utility-first doesn’t have to mean “build-system complexity forever.” If the rewrite holds up in production, Tailwind won’t just generate utilities—it’ll generate better CSS infrastructure for the long haul.

Ollama Made Running Local LLMs Embarrassingly Easy

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 26 Feb 2024 00:00:00 +0000

For years, the promise of “run AI on your own machine” sounded less like a breakthrough and more like a dare. You wanted a local LLM—sure—but what you got was a weekend lost to Python dependencies, CUDA driver versions, quantization scripts, and mysteriously broken model files. Then Ollama showed up and turned the whole thing into a single, boring command. And that’s the point: local AI stopped being a research project and started being a tool.

The old way: local LLMs as a systems engineering hobby

If you ever tried to run a local model back when “local LLM” meant “self-managed inference stack,” you know the pattern. You’d start with something like “I’ll just install the runtime,” then hit a dependency mismatch. Next came GPU configuration—CUDA, drivers, compatible builds—followed by quantization steps to make the model fit in VRAM. Finally, you’d wrestle with how to format prompts correctly and ensure the model actually responds as expected.

Even when it worked, the setup was fragile. Update one dependency and suddenly the environment breaks. Swap GPUs and you’re rebuilding from scratch. For most teams, that means local inference stays in the lab, not the product roadmap.

This friction isn’t just annoying—it actively distorts decision-making. If “local AI” requires ML engineering labor, privacy and latency become luxuries. The result: people either send everything to hosted APIs or build nothing.

The new way: one binary, one command, and a model

Ollama’s core move is disarmingly simple: you install a single tool, then you download and run models through a straightforward CLI. The mental model is “like running a local dev server,” not “like deploying a distributed ML system.”

Instead of stitching together a runtime, a model format pipeline, and a chat wrapper, you do something along these lines:

Install Ollama (your OS guides you through it)
Run a model: ollama run llama2 (or mistral, mixtral, etc.)
Talk to it immediately in a chat-like interface

That “one command” experience is the real product. It collapses the entire workflow—from acquisition to inference—into a tight feedback loop. You can test an idea in minutes, not days.

And because Ollama exposes an OpenAI-compatible API, local models stop being a weird side channel and become a drop-in option for applications that already speak “Chat Completions.”

Running models like you mean it: Llama, Mistral, Mixtral

The point isn’t that every model is perfect for every task. It’s that you can choose based on use case without re-platforming your stack every time.

Llama: the baseline you can actually iterate on

Llama-family models are a solid default when you want something pragmatic: summarization, drafting, Q&A, lightweight assistance. If you’re building features and need consistent behavior across iterations, Llama is often the model you start with because it’s easy to reason about and easy to refine.

Practical example: imagine you’re building an internal “meeting notes” assistant. You can start with a Llama run locally, tune your prompts, and validate formatting and citation behavior (even if you don’t do retrieval yet). Once the UX is right, you can swap models and keep the same application interface thanks to the API compatibility.

Mistral 7B: conversational speed without the guilt

Mistral 7B is popular for a reason: it’s compact enough that it can feel responsive on consumer hardware—especially on modern Mac systems. If your product needs a tight conversational loop (think: support agents, interactive tutoring, quick drafting), latency matters as much as raw quality.

Practical advice: don’t just “see if it works.” Evaluate the full interaction. Measure how long it takes to start responding, how stable the output is across turns, and whether the model tends to ramble or follow instructions. Local inference makes these iterations fast; use that to quickly identify prompt patterns that work.

Mixtral: when the problem isn’t just fluency

For more demanding reasoning and complex tasks, Mixtral-family models can be a better fit—especially when you want the model to handle multi-part instructions without dropping critical constraints. Think: planning workflows, transforming messy input into structured outputs, or performing “agent-like” steps where you want fewer silly mistakes.

Practical example: suppose you’re building an incident response assistant. The model needs to take logs, extract key details, propose hypotheses, and output a structured checklist. You can prototype that pipeline locally, then compare model behavior: does it preserve constraints? Does it produce useful sections consistently? Mixtral’s strength for multi-step tasks often shows up immediately in these structured transforms.

The API advantage: privacy isn’t just an architecture, it’s a product decision

Local models are often discussed in terms of privacy, but the more interesting shift is product design. When your AI runs locally, you can build features that were previously blocked by data-sharing concerns—or at least you can reduce the cost of being careful.

Because Ollama is OpenAI-compatible, you can treat the local model like another “backend” in your application. That means you can:

Run local inference in sensitive environments (legal, healthcare-adjacent workflows, internal operations)
Default to local processing for user-provided text by design
Keep a hosted fallback for non-sensitive or heavy workloads

A concrete architecture pattern many teams will adopt: local-first, cloud-later. Start locally for interactive features (drafting, summarization, transformations). If the user explicitly opts in—or if tasks exceed what your machine can handle—route to a hosted model. The key is that your application code doesn’t have to be rewritten every time.

This also changes procurement and policy conversations. Instead of arguing about whether “we can justify sending data to a third party,” you can sometimes say: “we can keep it on-device by default.” That’s not a philosophical win; it’s a practical one.

Practical setup: make local LLMs boring (in a good way)

The biggest risk with any “easy” tool is that people stop thinking about the operational details. Ollama makes running models simple, but you still want your experience to be stable and repeatable.

Here’s how to keep things sane:

Pick a small set of models and stick to them.
If your app supports five models with wildly different behavior, your prompts become a mess. Choose one “default” (often Llama or Mistral) and one “advanced” option (often Mixtral), then evaluate.
Treat prompts as code.
Store prompt templates in your repo. Version them. If you tweak instructions to reduce verbosity or improve formatting, do it intentionally—not ad hoc in a terminal.
Plan for resource constraints.
Even if a model “runs,” your laptop has limits. If you notice lag, consider using a smaller model, adjusting generation settings (like max tokens), or running fewer parallel requests.
Build evaluation into the workflow.
Don’t rely on “it seems good.” Create a small set of test inputs—your real user scenarios—and compare model outputs before and after prompt changes.
Integrate via the API, not via a manual terminal session.
You’ll learn faster early on in the CLI, but production should go through the API so your app stays consistent.

The goal is simple: make the whole thing feel like an everyday dependency, not an experiment.

Where this goes next: local AI becomes the baseline, not the exception

Once you can run strong models locally with a one-command flow, the center of gravity shifts. Developers stop asking “can we run LLMs on our machine?” and start asking “which features should run locally by default?”

Expect local-first patterns to show up everywhere: internal copilots, document transformation tools, interactive assistants for domain-specific workflows, privacy-sensitive chat experiences, and prototypes that never need to send raw user data off-device.

The best part is that Ollama’s approach lowers the intimidation barrier for new teams. You don’t need to be a GPU-tuning wizard to start building. You need a product idea, a prompt strategy, and the willingness to test.

Conclusion: local LLMs are no longer a project

Ollama didn’t invent better models—it made using them dramatically easier. By collapsing setup, model downloads, and inference into a single tool—and keeping an OpenAI-compatible API—you can go from “I have an idea” to “it’s running on my laptop” faster than most teams can write the project charter.

That’s why local AI feels different now. It’s not just more private; it’s more usable. And once it’s usable, it becomes a default choice.

The TypeScript Ecosystem Is Now Best-in-Class for Full-Stack Development

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 14 Feb 2024 00:00:00 +0000

Full-stack development used to feel like a series of translation layers: database types become JSON, JSON becomes DTOs, DTOs become UI models, and somewhere along the way, one tiny mismatch turns into a production bug. In 2024, TypeScript largely breaks that spell. The ecosystem around it now delivers something more ambitious than “types help”: it enables compile-time and runtime correctness that travels across your entire stack—without you having to weld everything together by hand.

This isn’t hype. It’s a quality threshold the tooling has finally crossed. When you combine modern TypeScript-friendly libraries like Drizzle, Zod, tRPC, and Tailwind, you get end-to-end feedback loops that are fast, practical, and—most importantly—boring in the best way. Fewer surprises. Clearer contracts. Better refactors. Let’s unpack why this stack has become my default for building full applications.

TypeScript’s real superpower: composable guarantees

TypeScript isn’t just a language feature; it’s an ecosystem magnet. The reason is simple: once you have a strong type system, people build libraries that “speak types” in a way the compiler can understand.

But the real leap in full-stack quality comes from composition. Individual libraries can be good. The difference now is that the best-in-class ones reinforce each other:

Database layer can expose types that flow upward.
API layer can enforce those same shapes at the boundaries.
Runtime layer can validate external inputs safely.
UI layer can guide you with editor intelligence instead of docs.

The result is a workflow where the compiler and your editor become reliable partners, not just documentation checkers.

To put it in concrete terms: you should be able to change a field in your database schema and have your editor highlight every place that needs updating—before you run the app. That’s the baseline expectation for “best-in-class” in 2024, and TypeScript tooling now gets you there more consistently than alternative ecosystems.

Drizzle + SQL: type inference that doesn’t feel fragile

If you’ve ever used an ORM that forces you to manually define shapes—then later discovers the database schema drifted anyway—you know the pain. Drizzle’s approach is compelling because it treats SQL as something you can reason about with types, not a black box.

In practice, Drizzle lets your queries produce types you can trust. That means when you select columns, your returned objects have the inferred structure you expect, and you can build on top of it without constantly re-declaring interfaces.

A common pattern looks like this conceptually:

Define your tables (or import schema).
Write queries using those table definitions.
Receive results typed by the query.

Then, you can reuse those result types to populate API outputs or UI models with minimal friction. The important part isn’t that you “have types.” It’s that the types remain connected to the underlying query logic.

A practical advantage: when you refactor a query—rename a column, change a join, adjust nullability—TypeScript can force you to fix downstream code immediately. This is especially valuable when multiple developers are working on different layers. The compiler becomes the contract negotiator.

Zod: runtime validation that derives types instead of duplicating them

Compile-time types are great—until you accept untrusted input. Anything coming from the network, from forms, from cookies, or from external services must be validated at runtime. Zod is the ecosystem’s go-to because it bridges the gap cleanly: you write validation logic once, and you get type inference out of it.

The key idea is that Zod schemas are not “parallel truth.” They’re a single source of validation, which TypeScript can use to infer static types.

A typical workflow:

Define a Zod schema for input (e.g., a “CreateUser” payload).
Use it to validate at runtime.
Reuse the inferred TypeScript type wherever you need compile-time safety.

This prevents the worst failure mode in full-stack projects: developers adding a type definition to satisfy the compiler while the actual runtime validation allows a broader or different shape. Zod’s schema-first model keeps those concerns aligned.

Even more important: Zod plays nicely with real-world constraints. You can validate strings, numbers, enums, nested objects, arrays, and custom refinements. You can enforce invariants like “password must match confirmation” or “email must be normalized,” then carry the derived types forward without extra ceremony.

tRPC: type-safe APIs without the schema tax

APIs are where correctness goes to die—because that’s where contracts get duplicated. The usual approach is to describe an API with a schema (OpenAPI, JSON Schema, protobuf, etc.) and then generate types for clients. It works, but it creates friction and overhead.

tRPC takes a different stance: you define procedures in TypeScript and let the type system propagate. Instead of maintaining a separate schema file, you get end-to-end typing between server and client.

The practical win is velocity and refactor safety:

Change a procedure input type on the server.
Your client code updates with editor help.
You avoid “works on my machine” mismatches caused by stale generated artifacts.

This is especially potent when paired with Zod. If a tRPC procedure validates input with a Zod schema, you get both runtime safety and static types. That combination is the closest thing I’ve found to “the boundary is actually safe.”

And it has a cultural effect too: developers don’t treat the API as a fragile string-based interface. They treat it as code that the compiler can reason about.

Tailwind: editor-level feedback that makes UI correctness feel effortless

For all the talk about backends, full-stack quality lives in the UI too. Tailwind’s “className intelligence” (via editor tooling) matters because it shortens the loop between intent and correctness.

Instead of guessing which utility names are valid or relying on runtime CSS surprises, the editor can help you keep classes consistent. The payoff is subtle but real: fewer typos, fewer dead styles, less time lost to formatting and lookup.

Tailwind also aligns with TypeScript’s general philosophy: prefer explicitness and tooling feedback over hidden conventions. When your UI class composition is safer and faster to edit, you can focus on behavior and state, not stylesheet debugging.

In a TypeScript-first codebase, this matters because the UI isn’t an island—it’s the consumer of your typed API models. When your components build from well-typed props and well-typed data, the UI becomes harder to break.

Putting it together: an end-to-end “type journey” example

Here’s what the best TypeScript full-stack experience feels like when it’s working:

Database query shape
- You define tables and write queries with Drizzle.
- The results are inferred and typed based on what you actually select.
API boundary
- You expose procedures with tRPC.
- Inputs are validated with Zod at runtime.
- Outputs remain typed end-to-end so clients know exactly what they’ll receive.
UI consumption
- Your frontend uses typed data directly.
- Components receive typed props inferred from the procedure outputs.
- Editor intelligence helps you map data to UI without guesswork.
Refactor with confidence
- Suppose you rename a field from displayName to name.
- The database query changes (Drizzle).
- The API procedure output changes (tRPC).
- The UI component usage breaks at compile time until you update it.
- You catch the entire mismatch before shipping.

This is why I call it best-in-class. Not because TypeScript is magical, but because the ecosystem is now mature enough to make the “type journey” reliable across every boundary that typically leaks correctness.

Conclusion: the ecosystem has turned TypeScript into a full-stack advantage

The TypeScript ecosystem isn’t merely popular—it’s coherent. Drizzle provides typed data access. Zod enforces runtime correctness without duplicating types. tRPC keeps API contracts aligned with the code that implements them. Tailwind finishes the loop with editor-grade UI feedback.

When you combine those pieces, you stop fighting your tools and start trusting them. And that’s the real quality threshold: not more types, but fewer broken contracts, faster iteration, and refactors that don’t feel scary. If you’re building full-stack apps in 2024, TypeScript isn’t just a choice—it’s the default architecture for developers who want correctness to be effortless.

The Hidden Cost of 'Free' AI APIs

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 08 Feb 2024 00:00:00 +0000

“Free” AI APIs are seductive: you get a quick endpoint, a slick demo, and the confidence to ship before you fully understand the bill. But the real cost of an AI integration rarely shows up in the README. It shows up in the fine print—rate limits that throttle production, data retention rules that change how your compliance story reads, model deprecations that break working prompts, and pricing tiers that jump the moment you succeed.

If you’re building with hosted LLMs, you need to treat your provider like a dependency—not a convenience. Here’s what the “free” tier actually hides, and how to design around it.

Rate limits: your app’s performance ceiling is someone else’s policy

Most teams assume rate limits are an implementation detail. They’re not. Rate limits are a hard operational constraint that can cap your throughput, shape user experience, and force architectural compromises you can’t easily undo.

What it looks like in the real world

Imagine you build a customer support chatbot. In the first week, traffic is low, so you’re happily generating responses at will. Then marketing launches a campaign. Suddenly you hit your per-minute token or request limit, and the experience degrades: delays, retries, and occasional failures. Even if your code is correct, your product becomes hostage to the provider’s throttling rules.

The most common mistake is assuming you can “just add retries.” Retries can turn a temporary slowdown into a cascading failure:

Your app queues requests internally.
Users click “Try again.”
Your retry loop multiplies load.
You hit rate limits harder and burn through the free tier faster.

Practical advice

Treat rate limits like a design input, not an afterthought:

Model your worst-case traffic. Decide what happens when you receive 10× normal requests for 10 minutes.
Implement backpressure. If you can’t serve immediately, degrade gracefully: shorter responses, fewer tool calls, or “we’re busy—please wait.”
Use a queue with a deadline. Time-box requests so you’re not endlessly waiting for the provider.
Cache aggressively where it’s safe. If users ask the same question repeatedly (or the same instruction template is used), caching reduces both cost and rate pressure.

The point isn’t to “avoid” limits. It’s to prevent them from dictating your product’s behavior.

Data retention: the compliance bill you didn’t budget for

Free tiers love to advertise how fast you can “ship AI.” Few teams read the retention and logging policy with the seriousness they’d apply to analytics pipelines. But with AI APIs, retention is not abstract—it’s part of your risk model.

The hidden question: “Where does my user’s text go?”

Depending on the provider and settings, your prompts and outputs may be retained for:

abuse monitoring
service improvement
training or fine-tuning (directly or indirectly)
debugging and audit logs

Even if you never request training, a provider may still keep data for defined periods. That matters for:

privacy obligations (e.g., whether users reasonably expect their inputs to be stored)
confidentiality (customer data, internal docs, trade secrets)
regulatory constraints (industry-specific requirements, cross-border data handling)

Practical advice

Before you write a single line of production code, answer these questions:

Is retention configurable? Look for options like “no training” and “short retention,” and confirm defaults.
Do they use your prompts/outputs for model improvement? The wording is everything—“may” and “aggregated” are not guarantees.
What’s the retention period? Ask what happens to logs after the period ends.
Can you delete data on request? In practice, deletion can be slow or limited.
What about system prompts and tool results? If you send proprietary context as part of an instruction, that context may be treated as data too.

Then adjust your architecture:

Minimize what you send. Don’t include entire documents when a retrieval snippet will do.
Redact sensitive fields. Build a preprocessing step that masks PII or confidential identifiers.
Use deterministic routing where needed. If you must meet strict rules, route sensitive flows through a provider configuration that supports your requirements, or through a self-hosted alternative.

You don’t want your AI vendor to become the surprise owner of your users’ most sensitive text.

Model deprecation: when “working” prompts stop working overnight

LLM providers don’t just iterate—they replace. And replacement can break systems that rely on stable behavior.

A model deprecation means the provider will eventually retire a model version. That retirement can alter:

response formatting
tool calling behavior
reasoning style (often indirectly)
refusal patterns
latency and output length distribution

The dangerous part is that the system may still “work” at a superficial level—until it doesn’t. For production, subtle changes can be catastrophic:

JSON output becomes inconsistent.
A classifier flips edge cases.
Your extraction pipeline starts failing.
“Same prompt” yields different behavior for the same user intent.

Practical advice

Design for change as a core requirement:

Version explicitly. If the API lets you pin a model, do it. Don’t drift silently across releases.
Add output contracts. Enforce JSON schema validation and retry with a constrained instruction when formatting fails.
Maintain regression tests. Build a small “golden set” of representative prompts and expected structured outputs. Run it on every model change.
Use canary routing. Send a small percentage of production traffic to the new model and monitor outcomes before full rollout.
Log prompts responsibly. You’ll need test evidence, but remember the retention discussion—log minimally and securely.

The best production teams treat model updates like software releases, not like background maintenance.

Pricing tiers and surprise egress: your bill scales faster than your team

Pricing is where “free” turns into a lesson. Many providers structure costs so that early prototypes are cheap, then costs expand quickly with real usage. And usage isn’t just prompt tokens—sometimes it’s also output length, tool calls, retries, caching misses, and network egress.

The common scaling traps

Long outputs. A chat interface invites users to request verbose answers. Output tokens grow fast.
Retry loops. When formatting fails or tools time out, retries add hidden cost.
No caching. If every request is unique, you pay for everything every time.
Tool chaining. Each tool call may add additional model usage and orchestration overhead.
Egress costs. If your architecture sends data to and from multiple services (or regions), network costs can become meaningful.

And yes—providers can change pricing. Even if they give notice, your production forecasting is only as good as your assumption that the assumptions stay stable.

Practical advice

Stop thinking about “the cost per request” and start thinking about “the cost per user outcome.”

Set token budgets per feature. For example: “summary must be under 200 tokens.”
Constrain the interface. Encourage short, structured responses for workflows that don’t need verbosity.
Measure end-to-end cost. Include retries and tool calls.
Build a cost guardrail. If spending exceeds a daily budget, switch strategies (shorter responses, caching, fewer tool calls).
Forecast with scenarios. Model not just average usage, but spikes and worst-case retry behavior.

And if you’re serious about reducing risk, consider portability: the cost of swapping providers is real, but the cost of being unable to swap is worse.

Vendor lock-in: portability isn’t a luxury, it’s an exit strategy

“Build fast with AI” is a valid prototype strategy. The trap is treating prototypes like architecture. When you tie critical product flows to one vendor’s API quirks—prompt formats, tool calling semantics, embeddings choices, evaluation tooling—you make switching expensive.

Lock-in isn’t only about rewriting code. It’s also about:

operational knowledge embedded in team workflows
evaluation datasets tuned to a specific model’s behavior
prompt templates that rely on specific response patterns
infrastructure around your provider’s streaming, logging, and rate limit mechanics

Practical advice

You don’t need to chase full multi-provider complexity. You need an abstraction boundary:

Create a model gateway. One internal interface for “generate,” “classify,” “extract,” etc.
Normalize inputs and outputs. Convert responses into your own internal schema.
Separate orchestration from vendor calls. Your app should decide what to do; the gateway decides how to call the vendor.
Keep prompt templates portable. Avoid vendor-specific instruction patterns that won’t translate cleanly.
Document assumptions. If your extraction depends on a particular formatting convention, write it down. That’s how you avoid rewriting blindly later.

Think of portability as insurance: not because you expect to need it, but because you’ll regret it when you do.

A production-ready checklist for “free” API optimism

If you’re moving from prototype to production, treat these as non-negotiables:

Read rate limit and retry guidance and implement backpressure with timeouts and caching.
Verify data retention and training settings and minimize what you send; redact sensitive content.
Pin model versions and create regression tests with schema validation and canary rollout.
Track end-to-end cost (including retries and tool calls) with daily budget guardrails.
Build a gateway abstraction so swapping providers doesn’t require a rewrite of your product logic.
Plan for deprecation events as routine releases, not emergencies.

The uncomfortable truth: “free” is a marketing phase. Production is where incentives and constraints collide.

Conclusion: ship fast, but architect for the day the fine print becomes real

Free AI APIs are great for learning and for proving value. But if you let the prototype phase become your production architecture, the hidden costs will arrive all at once—rate limits that throttle growth, retention policies that complicate compliance, model deprecations that break behavior, and pricing changes that strain budgets.

You don’t need to fear vendors. You need to design like reality is going to happen—because it will. Build your AI layer with contracts, guardrails, tests, and a clear exit strategy, and you’ll keep your momentum when the fine print finally matters.

RAG Is the Pattern That Makes LLMs Actually Useful for Enterprises

abdecastro@protonmail.com (Antonio B De Castro) — Fri, 02 Feb 2024 00:00:00 +0000

Enterprise AI has a branding problem: it looks magical in a demo and disappoints in production. The dirty secret isn’t that LLMs are “bad”—it’s that vanilla LLMs are ungrounded. They’re fantastic at sounding right. They’re not automatically good at knowing your policies, your contracts, or your product catalog. Retrieval-Augmented Generation (RAG) is the pattern that turns “cool text generation” into “reliable enterprise assistance.”

The enterprise failure mode: confident answers without grounding

Most companies don’t fail with LLMs because the model can’t write. They fail because the model doesn’t know what it’s supposed to be answering.

If you ask a base LLM, “What’s our policy for vendor onboarding exceptions?” it will answer as if it were guessing based on generic patterns from the internet and its training. It may produce something coherent—perhaps even plausible—but it has no direct line to your actual policy documents. When you operationalize that output, the problems get expensive fast:

Compliance risk: An answer that quotes the wrong version of a policy is still an incorrect answer.
Legal risk: Summaries of contract clauses that “sound right” can be misleading.
Operational friction: Support teams lose trust and revert to search and spreadsheets.
User harm: Employees make decisions based on generated text that wasn’t grounded.

The core issue is not reasoning capacity. It’s knowledge access.

The RAG principle: retrieve first, then generate

RAG bridges the gap by changing the workflow. Instead of letting the LLM freestyle from its internal priors, you ground it in enterprise-owned sources at query time.

The pattern is simple to describe and easy to implement incorrectly:

Ingest your content (docs, tickets, PDFs, wiki pages, database rows).
Split it into chunks (small enough to retrieve, large enough to be meaningful).
Embed the chunks into vectors and store them in a vector database.
At question time, embed the user query, retrieve the most relevant chunks, and feed those chunks to the LLM.
Generate an answer that is constrained by the retrieved context—ideally with citations.

Notice what’s happening: the LLM becomes an answer synthesizer, not a knowledge source. Retrieval does the “what we know,” and generation does the “how we explain it.”

Practical takeaway: if you’re evaluating an LLM app, don’t ask “Can it respond?” Ask “Can it respond using the right evidence, every time?”

RAG in practice: an employee-facing Q&A system that won’t lie

Let’s make this concrete. Imagine a company HR team wants an internal assistant that answers:

“What’s the vacation policy for hourly contractors?”
“Do we reimburse relocation expenses, and what receipts are required?”
“How do I request an exception to the onboarding timeline?”

A vanilla LLM will be vague at best. Worse, it will “complete” your question with generic HR norms. That might even pass a casual test—until someone asks a question that depends on a specific clause or an updated form.

A RAG system, by contrast, retrieves the relevant policy sections and then generates a response anchored to them. The result can look like:

Answer: Hourly contractors are eligible for X days after Y months of service. Exceptions require manager approval and must include documentation of Z.
Sources: “Contractor Leave Policy v3 (Section 4.2)” and “Exception Request Guidelines (Updated 2025-01).”

Even if the LLM still makes mistakes in phrasing, the system has a fighting chance to be correct because the model is working from the actual text.

Operational detail that matters: you want retrieval to return chunks that preserve meaning. If you chunk a policy by arbitrary length, you might separate the eligibility statement from the definitions. That produces “technically plausible but wrong” answers. Good chunking—plus overlap and metadata—turns RAG from brittle to dependable.

Designing the pipeline: chunking, embeddings, and retrieval quality

RAG isn’t glamorous. It’s also not magic. Most of the real work is in the boring parts, because those parts determine whether the right context arrives in the prompt.

Here are the practices that typically separate demos from production:

Chunking that preserves intent

Use chunk sizes that fit your content type and query patterns. For policies, chunk around headings or logical sections, not just token counts. Include overlap so definitions and referents aren’t stranded in different pieces.

Metadata is not optional

Store metadata with every chunk: document name, section path, version, effective date, department owner. This enables filtering (“only return current HR policies”) and better citations.

For example, when someone asks about “the current vacation policy,” retrieval should favor documents marked as current. Without metadata filtering, you may pull last year’s version, and the LLM will happily summarize outdated rules.

Retrieval settings should be tuned, not trusted blindly

Vector search is only as good as its configuration. Tune the number of retrieved chunks and consider hybrid retrieval (vector + keyword) when content has identifiers, product names, or legal terms that don’t embed cleanly.

Also: monitor retrieval failure cases. If users repeatedly ask about the same subject and get irrelevant context, you likely need better chunk boundaries or additional indexing sources.

Prompting that encourages grounded answers

A common mistake is to dump retrieved text into the prompt and assume the LLM will behave. Write instructions that require the model to:

answer using the provided context,
mention uncertainty when context is insufficient,
and prefer quoting or citing relevant excerpts.

If your prompt never tells the model how to behave when evidence is missing, you’ll eventually see hallucinated citations or confident inventions.

Vector databases are plumbing—evaluation is the product

Enterprises love to buy infrastructure. They should instead buy evaluation.

You can build a perfect RAG pipeline on paper and still fail in the real world because retrieval quality and answer correctness drift over time: docs change, formats vary, and teams add content in inconsistent ways.

Treat evaluation as a first-class feature:

Build a test set of real questions from the people who will use the system—HR, finance, support, engineering. Include edge cases.
Measure retrieval accuracy (did we fetch the right sections?) and answer correctness (did the response match the fetched text?).
Track regressions when you update chunking rules, embedding models, or document ingestion logic.
Log what context was retrieved for every answer so you can debug failures quickly.

One practical approach: classify failures into categories—wrong doc, wrong section, insufficient context, and reasoning error after correct retrieval. Each category points to a different fix. Otherwise, you’ll chase phantom improvements and wonder why user trust doesn’t return.

And yes, you should require citations (or at least evidence references) for high-stakes answers. RAG is the pattern that makes LLMs useful, but it doesn’t remove the need for accountability.

Beyond Q&A: RAG as a general enterprise “grounding” layer

RAG isn’t limited to chatbots. It’s a grounding layer you can apply wherever LLMs need to operate on your data without inventing it.

Common expansions:

Support assistants that retrieve relevant troubleshooting steps and known issues from your ticket history.
Contract and policy analyzers that pull clause text and then generate clause-by-clause explanations.
Internal knowledge copilots that draft summaries of documents while citing where each claim came from.
Agent workflows that retrieve state and constraints before taking action (e.g., “what approvals are required for this request type?”).

The key design idea stays the same: retrieval provides authoritative context; generation provides readability and structure.

When you treat RAG as foundational infrastructure—not a one-off feature—you reduce the risk of turning “AI” into a glorified auto-completer.

Conclusion: stop demoing, start grounding

Vanilla LLMs are impressive, but for enterprise use they’re fundamentally ungrounded. RAG is what makes them practically reliable by forcing answers to be generated from your actual documents and databases. It’s not glamorous, but it’s the difference between a chatbot that hallucinates company policies and one that can cite them.

If you want LLMs to earn trust inside your organization, build RAG—and then invest just as hard in evaluation, metadata, and retrieval quality as you do in the model itself. That’s how you move from prototypes to production.

Neon and Supabase Are Making PostgreSQL Cool for Indie Hackers

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 21 Jan 2024 00:00:00 +0000

For years, “use PostgreSQL” was easy advice and hard reality. The database was brilliant—until you had to babysit migrations, scaling, replicas, backups, and connection limits while also building product. What’s changed is simple: Neon and Supabase have turned PostgreSQL from “the right choice” into “the obvious one” for indie hackers who want speed, branching, and guardrails without hiring a DBA.

The PostgreSQL problem indie hackers actually felt

PostgreSQL isn’t the issue. Operations are. Even the most capable solo developer eventually runs into the same friction points:

Scaling pressure: PostgreSQL can scale, but you still need to think about indexing, connection pooling, and when to move off a single box.
Migrations with consequences: Schema changes are required, but they’re also risky. One bad migration can break production, and “rollback” is never as clean as you hope.
Environment sprawl: You want a staging database, a preview database for each PR, and maybe a couple of test fixtures—then the cost and overhead hit.
“Not just a database”: Modern apps require auth, storage, file uploads, background jobs, and real-time updates. Building all of that correctly is what keeps projects small—until you realize you’ve reinvented half a platform.

Firebase and PlanetScale filled part of that gap: they were easy to operate and packaged nicely. But they often moved developers away from SQL-first thinking, and the long-term cost was avoidable lock-in.

The new wave flips the story: keep PostgreSQL, remove the operational drag, and add the platform features you’d otherwise bolt on yourself.

Neon: serverless Postgres plus schema branching (git for your data model)

Neon’s big idea is to make Postgres feel elastic without forcing you to become a cloud infrastructure expert. Instead of treating your database like a fixed-capacity server, Neon offers serverless scaling that’s designed to handle varying workloads.

But the feature indie teams care about most is branching.

Think about how you ship code today: you branch your app, test changes, and merge. For databases, the equivalent has historically been “migrate in place” (or maintain multiple manual environments). Neon’s branching brings a Git-like workflow to your schema and data access patterns, so you can test changes in isolation.

A practical example: preview environments for every change

Imagine you’re building a SaaS dashboard and you want a URL where teammates can review the UI and the database schema changes behind it.

With branching, you can create a database branch tied to a specific code change, run migrations, seed test data, and point your preview deployment at that branch. If the change passes, you merge forward; if it fails, you discard the branch. No emergency migration surgery on shared environments.

Why this matters

Branching isn’t just convenience—it’s risk management.

When you can safely test migrations in a disposable environment, you’ll ship faster. You’ll also write migrations differently. Instead of “make it work on production,” you start writing migrations like you’re testing code: deterministic, reviewable, and rollback-friendly.

Serverless scaling is the enabler; branching is the workflow upgrade.

Supabase: Postgres as the core, plus auth, storage, edge functions, and real-time

If Neon is the “make Postgres easy to operate” story, Supabase is the “make your app stack coherent” story.

Supabase sits on Postgres, then adds the missing pieces that used to send indie hackers chasing a grab bag of services. The result is a platform that feels like Firebase in spirit—but keeps PostgreSQL at the center.

Key components include:

Authentication: sign-in flows you can configure quickly, plus a clean way to integrate user identity into your database-backed logic.
Storage: a practical pipeline for files and assets with policies you can reason about.
Edge functions: server-side logic close to users, useful for webhook handling, background orchestration, or lightweight APIs.
Real-time: the ability to react to database changes without inventing your own pub/sub layer.

A practical example: “events from the database” without extra plumbing

Suppose your app needs to update a dashboard instantly when a user’s job status changes. With Supabase’s real-time capabilities, you can subscribe to updates backed by Postgres changes.

Instead of building a custom event stream (or managing another database for events), you keep your source of truth in Postgres and let the app react. It’s a tighter feedback loop: database changes produce product changes.

Edge functions as the glue

Postgres is your model; edge functions handle the “app logic around the edges.” For example:

a Stripe webhook handler that validates the event, writes entitlements into Postgres, and triggers any downstream updates;
a function that processes an uploaded file, updates metadata in Postgres, and returns a clean response to the client.

You still get SQL where it counts—and you don’t have to build an entire backend platform yourself.

The killer combo: Neon for database ergonomics, Supabase for app infrastructure

Here’s the opinionated take: use the tools where they’re strongest.

Neon brings excellent Postgres scaling and branching—the operational freedom and safe schema experimentation that keeps shipping moving.
Supabase brings the product layer: auth, storage, edge functions, and real-time so you’re not stitching together five services to launch a credible MVP.

Depending on your setup, you might choose one as your primary platform. But the larger point is that the PostgreSQL ecosystem has matured: you can keep your architecture SQL-first and still get the “batteries included” experience.

A realistic indie workflow

Build features with Postgres-backed tables.
Use branching to test migrations and seed data safely for preview deployments.
Use Supabase for authentication and file handling (so your app logic doesn’t balloon).
Use edge functions for webhook glue and lightweight APIs.
Use real-time subscriptions for “it updates instantly” UX.

This is how you compress the distance between idea and working product.

Generous free tiers change the economics of shipping

Indie hackers don’t just need tools—they need room to experiment without learning the painful cost curve too early. Neon and Supabase both offer generous free tiers, which matters for two reasons:

You can build and iterate without turning every test into a budgeting exercise.
You can keep the architecture you want. When costs are predictable, you don’t feel forced into shortcuts like denormalizing everything prematurely or avoiding real-time features entirely.

The end result is cultural as much as financial: PostgreSQL stops being “what you’ll use later when you have money for ops,” and becomes what you start with on day one.

What to watch out for (so you don’t repeat old mistakes)

Even with modern platforms, you can still shoot yourself in the foot. The goal isn’t magic—it’s fewer chores and better workflows. A few practical guardrails:

Treat migrations like code: review them, test them in a branch, and keep them deterministic.
Index intentionally: serverless and managed platforms don’t erase query design. If your dashboard needs fast filtering, add the right indexes early.
Be mindful of connection patterns: real-time and edge functions can increase concurrency. Use pooling strategies appropriate to your stack.
Keep security policies tight: Supabase’s strengths include a strong approach to access control—use it deliberately rather than “open by default.”

If you do these things, the new Postgres workflow becomes less about reacting to production fires and more about shipping.

Conclusion: Firebase’s default era is ending—SQL-first is back

Neon and Supabase don’t just make PostgreSQL easier; they restore a long-lost indie developer feeling: you can build a serious backend without turning every day into infrastructure work.

Serverless scaling and schema branching mean safer, faster development. Auth, storage, edge functions, and real-time mean you don’t sacrifice product velocity to avoid complexity. And generous free tiers keep experimentation affordable.

PostgreSQL was always the right core. Now it’s the right developer experience too—and that’s the shift that finally makes “use Postgres” the default choice again.

Every Developer Needs an AI Workflow in 2024 (Here's Mine)

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 09 Jan 2024 00:00:00 +0000

AI isn’t the future—it’s the present. But in 2024, “using AI” is less about fancy prompts and more about building a workflow you can trust. After a year of experimentation (and a few embarrassing bug reports), I’ve landed on a simple rule: treat AI like a junior developer. It can draft, it can suggest, it can learn your style. But it cannot be left alone with production.

Here’s the workflow I actually use: Copilot for autocompletion, ChatGPT for architecture discussions and code review, and local models when sensitive data is involved. The goal isn’t to make AI do everything. The goal is to make you faster—without becoming the quality assurance department for hallucinations.

The Real Problem Isn’t “AI Quality”—It’s Workflow

Most developers fall into one of two traps:

Over-reliance: They paste tasks into a chat, accept the first answer, and hope tests will catch the rest. Spoiler: tests often catch the symptom, not the root cause—and sometimes they don’t catch it at all.
Stubborn refusal: They insist they’ll “use AI later,” which usually means never. Meanwhile, everyone else is iterating on designs and prototypes twice as fast.

The middle path is what I recommend: aggressive adoption with ruthless verification. That means AI outputs are treated as drafts and candidates, not decisions. You don’t “ask AI to code.” You run an iterative process where AI helps you get to a better final version under your control.

Think of it like pair programming—with the caveat that your pair is brilliant at first drafts and terrible at knowing when it’s wrong.

My Stack: Copilot, ChatGPT, and Local Models—Used on Purpose

My workflow is intentionally boring in the best way. Each tool has a job, and I don’t blur the boundaries.

Copilot for autocompletion (speed with guardrails)

Copilot is my default for day-to-day coding: filling in obvious boilerplate, suggesting method implementations, and accelerating refactors.

How I use it:

I let Copilot write the first draft of a function.
I then immediately review for correctness, edge cases, and style alignment.
I keep prompts minimal. Autocomplete doesn’t need a novel; it needs context.

Example: I’m adding a new endpoint handler in a TypeScript service. Copilot can generate request parsing, validation scaffolding, and response shape mapping. I then verify:

status codes and error formats
input validation rules
logging and tracing hooks
and whether the function respects existing conventions

If Copilot’s suggestion conflicts with established patterns, I overwrite it. That’s not “fighting AI.” That’s maintaining consistency.

ChatGPT for architecture discussions and code review (thinking and critique)

ChatGPT is where I slow down. I use it to pressure-test design decisions, identify missing pieces, and review diffs.

How I use it:

For architecture: I ask for tradeoffs, failure modes, and “what would you do differently?”
For code review: I paste targeted snippets or PR-ready diffs and ask for specific categories of feedback.

Example: Before committing to a caching strategy, I’ll ask:

“Given these constraints (latency, data freshness, invalidation pattern), what architecture would you recommend and why?”
“What are the top three ways this can fail in production?”
“What would you measure first to verify it’s working?”

ChatGPT is best when you narrow the question. A vague request yields generic answers. A precise request yields actionable critique.

Local models for sensitive data (control the blast radius)

When the work involves proprietary data, customer context, or anything you wouldn’t want floating through third-party services, I switch to local models.

This isn’t about paranoia. It’s about risk management and operational hygiene. Local inference keeps sensitive content inside your boundary, where you can version, log, and control it.

Practical advice:

Maintain a separate “local prompt template” for security-sensitive tasks.
Don’t reuse prompts that accidentally reference sensitive payloads.
Use local models for summarization, classification, and constrained extraction when possible.

The key isn’t making local models perfect—it’s ensuring you’re not using a chat tool as a data pipeline.

The Junior-Developer Mindset: Drafts, Not Decisions

Here’s the mindset that changed everything for me: AI is useful like a junior developer, not like a system.

A junior can:

implement the happy path quickly
draft a method with reasonable structure
propose an API shape you can refine

A junior also can:

misunderstand requirements
ignore non-happy paths
miss subtle concurrency or security issues
output code that compiles but is wrong

So I use a simple workflow:

Get a draft fast (Copilot or ChatGPT).
Make it specific (add constraints, test expectations, formatting rules).
Verify aggressively (tests, linters, type checks, manual reasoning).
Lock in changes only after proof.

If you follow that loop, AI becomes a lever instead of a liability.

A Practical Workflow You Can Copy Tomorrow

Let’s make this concrete. This is how I run AI-assisted development end-to-end.

Step 1: Start with the spec you actually have

Before calling any model, write a short “working spec” for the task:

What should happen?
What must not happen?
Inputs/outputs (including edge cases)
Existing constraints (libraries, patterns, performance)
Acceptance checks (tests, metrics, formatting)

This is the difference between AI helping and AI guessing.

Step 2: Use Copilot for the scaffold

Ask for the structure, not the truth. Let Copilot generate:

function skeletons
data transformations
interface wiring
repetitive boilerplate

Then immediately do a “human pass”:

check for off-by-one logic
validate error handling
confirm proper async/await usage
ensure you’re not silently swallowing exceptions

Step 3: Use ChatGPT for review categories

When I want critique, I don’t ask “is this good?” I ask targeted questions. Example prompt:

“Review this code for: correctness, security issues, performance pitfalls, and maintainability. Call out any lines that are likely wrong.”
“Suggest test cases I’m missing, including concurrency and failure modes.”
“If you were refactoring this for clarity, what would you change first?”

This turns ChatGPT into a reviewer with an agenda—much closer to how you actually want help.

Step 4: Demand verification, not confidence

Every AI-assisted change triggers verification:

unit tests for logic
integration tests for behavior
type checks and linting for consistency
code review from me, with attention to edge cases

If AI suggests something that isn’t reflected in the tests, it’s a hypothesis—not a conclusion.

Step 5: Escalate to local models for sensitive work

If content crosses a line (customer identifiers, production payloads, confidential algorithms), don’t improvise. Switch tools and use locally hosted models for:

transformation of sensitive data into safe summaries
extraction of schema info
generation of non-sensitive scaffolding

Keep the sensitive text out of your normal chat stack. Make “tool choice” part of your workflow, not an afterthought.

What I’ve Learned the Hard Way (So You Don’t Have To)

A few lessons I wish someone had hammered into me early:

Don’t trust “it compiles”. AI can produce syntactically correct code that violates your business logic. Tests and reasoning matter.
Don’t give AI your whole brain. The more context you paste, the more likely it is to mirror misunderstandings. Provide a crisp spec and a narrow target.
Prefer iterative refinement over one-shot answers. Generate a draft, critique it, then regenerate with constraints.
Watch for consistency drift. Copilot can introduce style deviations and subtle API mismatches. Treat your existing codebase as the source of truth.
Treat architecture advice as a set of options, not a blueprint. ChatGPT is excellent at presenting tradeoffs. It’s not omniscient about your constraints. Your constraints are the real input.

Most importantly: AI adoption should feel like hiring a junior who’s fast but needs supervision. If you’re “letting AI drive,” you’re not supervising—you’re outsourcing.

Conclusion: Build a Workflow You Can Trust

AI in 2024 isn’t a magic upgrade. It’s a new collaborator, and like any collaborator, it needs boundaries. My approach—Copilot for autocompletion, ChatGPT for architecture and review, and local models for sensitive data—works because it’s structured. The drafts are fast. The verification is ruthless. The final responsibility stays with you.

If you want one takeaway: adopt AI aggressively, but verify with discipline. That’s how you get speed without chaos—and how AI becomes a tool you rely on instead of a problem you inherit.

Devin Was a Wake-Up Call, Not a Replacement

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 03 Jan 2024 00:00:00 +0000

The viral demo wasn’t a prophecy. It was a stress test—of our expectations, our workflows, and our ability to tell “cool” from “real.” When Cognition’s Devin showed an AI agent that can plan, code, debug, and deploy with minimal human steering, the internet instantly split into two tribes: “developers are dead” and “it’s vaporware.” Both reactions missed the point.

The more interesting truth is simpler: agentic coding is real for narrow problems, and “autonomous software engineering” for messy, ambiguous work is still a long way off. Devin wasn’t a replacement. It was a wake-up call—about which parts of software work will get automated first, and what you’ll need to protect (and sharpen) to stay valuable.

What the Devin Demo Proved—and What It Didn’t

A great demo is a mirror: it reflects what the team can do today and what the audience wants to believe tomorrow. Devin’s viral moments highlighted capabilities that many developers can recognize immediately—iterating on code, running tests, searching for failing conditions, and producing working changes.

But demos also hide complexity. They typically compress the messy parts of engineering into something that can be evaluated quickly: a defined repository, a clear task statement, a constrained environment, and success criteria you can check with a green checkmark. In other words, the demo proved feasibility under conditions that are close to “well-specified engineering.”

What it didn’t prove is the hardest part of software: navigating ambiguity. Real requirements aren’t just a string prompt; they’re a moving target shaped by stakeholders, trade-offs, legacy constraints, regulatory considerations, incident history, performance budgets, and “we didn’t think about that edge case until production.” A demo can simulate those pressures, but it can’t fully recreate them at the same time the way a long-lived system does.

So yes: agentic coding is possible. No: that doesn’t mean it’s ready to replace the craft of building software in the world as it actually exists.

Agentic Coding Is Real—If You Keep the Box Small

Here’s the pattern that matters: the best use cases for autonomous agents are narrow, bounded, and testable. Think of tasks where:

The inputs and outputs are reasonably clear
There’s a reliable harness to verify correctness (tests, linters, build steps)
The environment is constrained enough that the agent won’t need endless clarifying conversations

A concrete example: “Fix the failing unit tests in this repo.” If you can provide a reproduction (or a failing CI run) and the goal is to get from red to green, an agent can do real work—often faster than a human can context-switch into that codebase.

Another example: “Migrate a set of endpoints from one auth mechanism to another.” If the transformation is consistent, the agent can apply a structured refactor, update call sites, and run the test suite until it passes.

Even better: these tasks don’t just benefit from automation—they benefit from feedback. Agents are at their strongest when every attempt produces signals: compilation output, stack traces, test failures, formatting errors, type checker complaints. That’s the loop software engineers already use instinctively; the difference is that agents can run that loop at machine speed without needing a coffee break.

Your takeaway: Devin-style agents are most useful when you can turn “engineering” into “iteration with verification.” When you can’t, the agent stalls—or worse, produces plausible but wrong outcomes.

Why “Developers Are Dead” Is a Bad Forecast

The “developers are dead” argument tends to rely on a single mistaken assumption: that software development is mostly about writing code. It isn’t. Code is the artifact; engineering is the process that produces the right artifact under uncertainty.

Most real developer value sits in places demos don’t capture well:

Translating fuzzy business intent into technical requirements
Designing systems that can survive change (not just tests that can go green)
Making trade-offs (latency vs. cost, simplicity vs. scalability, correctness vs. developer velocity)
Coordinating across teams and constraints
Knowing which assumptions are safe—and which will explode in production

If an agent can churn through a bugfix task, great. But if you hand it an initiative like “reduce churn by improving onboarding,” it doesn’t get to “just code.” It needs experimentation plans, analytics instrumentation, privacy considerations, rollout strategy, and a model of user behavior. That’s not a narrow repo problem; it’s a product-and-platform problem.

Even within a single codebase, ambiguous work dominates: “This feels slow” becomes a performance investigation; “We need better reliability” becomes an incident review, an SLO definition, and a series of mitigations across components. There’s often no clean evaluation harness that a tool can automatically label as “correct.”

The strongest claim you can make about agentic agents is not that they replace developers—it’s that they will increasingly handle the repetitive, structured parts of development. The rest remains stubbornly human.

Why “It’s Vaporware” Misses the Real Shift

At the other extreme, calling Devin vaporware ignores something equally important: the industry doesn’t need full autonomy to change how work gets done. Even partial autonomy can reshape workflows.

Once developers start using agents for the boring-but-critical steps—scaffolding, refactoring, generating boilerplate, rewriting repetitive code, hunting down test failures—teams will reorganize around that reality. Code review becomes more about evaluating intent and design constraints. Planning becomes more iterative as agents propose multiple implementations. Debugging shifts from “find the bug” toward “validate the agent’s hypothesis.”

In practice, you don’t need an agent to reliably ship production on its own to get value. You need it to reduce time spent on “mechanical work” while improving developer throughput and shortening feedback loops.

The “vaporware” framing also underestimates the cultural impact of a demo like this. Even if the agent is limited, it establishes a new mental model: software engineering can be approached as a sequence of actions toward verifiable outcomes. That model will spread, and tools will improve. You can’t dismiss the future because it isn’t here in full.

The reality is probabilistic, not binary. Some tasks will be automated sooner than others. That’s how technology adoption usually works—messily, unevenly, but relentlessly.

Where Agents Actually Fit in Today’s Engineering Workflow

So what should you do with this wake-up call? Treat agents as junior collaborators with obsessive follow-through—useful for speed, dangerous for unchecked assumptions.

Here’s a practical framing you can adopt immediately:

1) Give agents problems with receipts

Prefer tasks that come with:

a failing test log or CI run
a reproduction script
a target interface or schema
a clear definition of “done”

If your prompt is “Improve this module,” you’ll get vague outputs. If it’s “Fix the failing integration tests in payments-service by updating the request retry logic to meet these constraints,” you’ll get something actionable.

2) Make evaluation non-negotiable

Don’t treat generated code as a conclusion—treat it as a hypothesis. Require:

test runs
lint/type checks
code review with a checklist
targeted regression testing

In other words: keep the machine in the loop, but keep humans responsible for outcomes.

3) Use agents for breadth, humans for judgment

Agents are great at exploring options quickly: “Try three ways to refactor this function.” Humans should decide which path aligns with architecture, maintainability, and product goals.

4) Guard against “plausible but wrong”

When ambiguity is high, agent outputs can look coherent while missing the real requirement. A reliable pattern is to force explicit alignment steps:

Ask the agent to restate requirements
Ask it to list assumptions
Have it cite evidence from the repo or error logs
Require a minimal plan before execution

5) Build your own “agent playbook”

Your best investment isn’t chasing the newest model—it’s codifying how you work:

standard repo structure conventions
test harness expectations
command sequences for local reproduction
templates for prompts and review questions

The teams that win won’t be the ones who “use Devin.” They’ll be the ones who turn agent workflows into repeatable operating systems.

Become Indispensable by Moving Up the Value Chain

If you want the sharpest interpretation of Devin’s lesson, it’s this: AI won’t eliminate software developers—it will compress the role of “coder” into something closer to “orchestrator.”

The boring parts will be handled more often:

writing boilerplate
refactoring mechanical code
chasing failing tests
generating migrations and repetitive updates

Your leverage will come from the interesting parts:

system design under constraints
requirement shaping and stakeholder alignment
security, correctness, and operational responsibility
debugging the hard failures that aren’t reducible to a clean test harness
making decisions when the data is incomplete

If you’re a developer, your competitive advantage is not that you can type faster. It’s that you can understand the problem deeply enough to know what “correct” even means—and you can own the consequences when it’s wrong.

That’s why the wake-up call isn’t fear. It’s momentum. Learn how to delegate structured work to agents, and spend your time where agents struggle: ambiguity, trade-offs, and judgment.

Conclusion: The Future Isn’t “Autonomy Everywhere”—It’s “Automation Where It Can Earn Trust”

Devin didn’t prove that software engineering is dead. It proved that agentic coding can work when the task is bounded, verifiable, and guided by feedback loops. It also showed the uncomfortable gap between demos and reality: real engineering is messy, ambiguous, and accountable.

So don’t bet your career on competing with the machine at typing. Bet it on becoming the person who knows how to define the right problem, validate the right outcome, and keep systems reliable when the world refuses to be neatly specified. That’s how you turn a viral demo into an advantage—without losing your craft.

Predictions for 2024: What I'm Betting On

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 18 Dec 2023 00:00:00 +0000

Enterprise AI is entering its “quietly inevitable” phase: fewer demos, more plumbing. In 2024, I expect the conversation to shift from “can we build it?” to “can we run it reliably, cheaply, and safely?” My bets are specific—and yes, I’m willing to be wrong in public. So bookmark this and come roast me in December.

1) RAG becomes the default enterprise architecture

For years, the standard pattern has been: prompt the model, hope for the best, and then write a blog post about “responsible AI” after the first angry ticket arrives. In 2024, retrieval-augmented generation (RAG) won’t just become popular—it will become the default architecture for most enterprise AI apps.

Why? Because RAG solves the problem enterprises actually have:

Knowledge is messy and constantly changing. A model that’s trained once can’t keep up with policy updates, product documentation revisions, or support playbooks that change weekly.
Ground truth matters. When a bot confidently hallucinates a shipping policy, it’s not a cute failure mode—it’s a process failure.
Auditing becomes possible. Retrieval gives you citations, traceability, and a path to debugging.

What “standard” will look like in practice

If you’re building enterprise AI in 2024, I’d bet you end up with a pipeline that looks something like this:

Ingest documents (PDFs, wikis, tickets, manuals).
Chunk them with intent (not arbitrary token counts).
Embed chunks into a vector index.
Retrieve relevant passages at query time.
Generate using the retrieved context plus a strict prompt template.
Evaluate with a feedback loop: which answers were wrong, and why?

The practical advice I’ll stand by

Don’t start with “top-k and pray.” Your chunking strategy will matter more than your model selection early on. If your chunks cut across table rows or policy sections, retrieval quality will collapse.
Treat RAG as a product, not a feature. Set up monitoring for retrieval hits, response usefulness, and failure categories (missing info vs. misread policy vs. wrong reasoning).
Plan for “no good context.” The best RAG systems know when to say: “I couldn’t find a relevant policy section.” Build that behavior deliberately.

RAG won’t replace all generative workflows, but it will become the baseline for enterprise “knowledge tasks” like support automation, internal assistants, compliance Q&A, and draft-with-sources experiences.

2) Open-source LLMs close the gap—and companies stop paying the premium

My second bet is blunt: open-source LLMs from Meta and Mistral (and others) will get close enough to top-tier proprietary models that “best model wins” stops being the default procurement strategy.

I’m not claiming identity with any specific frontier system. I am saying that, in real product conditions—latency constraints, tool use, RAG grounding, and evaluation-driven prompting—open models will reach a point where many teams can deliver comparable user outcomes at a fraction of the cost.

“90% quality / 10% cost” as a working assumption

In a spreadsheet fantasy world, “quality” is a single number. In production, quality is a mix of:

factual grounding (RAG helps a lot here),
instruction-following reliability,
safety behavior,
latency under load,
and the cost of failure.

So my prediction is really about ROI: open models will become the rational choice for most use cases once teams invest in evaluation, prompt scaffolding, and retrieval.

How teams will make this switch without rewriting everything

Expect a pattern shift:

You’ll standardize on model-agnostic prompting and evaluation harnesses.
You’ll build adapters for tool calling and formatting rather than bespoke prompts for one vendor.
You’ll use RAG to reduce dependency on raw parametric knowledge.

If you’re already using RAG, switching models is less scary than it sounds. Retrieval provides stable context; the model becomes a rendering engine plus reasoning layer. That’s exactly the job open models are increasingly good at.

3) htmx goes from “cool demo” to production default

htmx has been the darling of devs who want fewer abstractions and more actual HTTP. In 2024, I expect it to cross the chasm from curiosity to adoption in real products—especially where the UI is mostly forms, lists, and incremental updates.

The reason is simple: many web apps don’t need client-side complexity. They need fast feedback loops, clear server-side logic, and predictable state.

What production adoption looks like

You’ll see htmx in places like:

internal dashboards and admin tools,
CRUD-heavy workflows (ticketing, approvals, inventory),
content management UIs,
“modal + partial update” patterns without building a SPA.

For example, instead of turning your app into a JavaScript framework project, you can ship a server-rendered page where actions like “approve request” trigger a targeted request and swap only the relevant fragment.

The strategic advantage

The hidden win of htmx is operational:

Fewer front-end build steps.
Less state management in the browser.
More leverage from your existing backend stack.
Easier auditing and debugging because the server remains the source of truth.

If you’ve ever debugged a production SPA issue that turned out to be a state desync, you already understand why this matters.

4) Bun 1.0 lands—and starts taking bites out of Node’s dominance

My next bet: Bun will hit 1.0 and start stealing market share from Node.js. Not because Node is bad—it’s because the ecosystem is now big enough that performance matters again.

Bun’s pitch is compelling: faster startup, a tighter toolchain, and an integrated developer experience. Even if you don’t care about raw speed, teams care about iteration time, CI time, and “time-to-first-response” for developers.

Where Bun wins immediately

I expect adoption first in:

greenfield services that don’t depend on esoteric Node internals,
teams that run lots of short-lived jobs and scripts,
environments where dev experience is a priority,
workloads where startup and memory behavior are visible costs.

What to do if you’re skeptical

Be pragmatic. Don’t rewrite your whole org because a new runtime looks shiny. Instead:

prototype a single service,
run your tests under Bun,
compare build + deploy + runtime metrics in your real environment,
and only then standardize.

The best “framework wars” aren’t decided by hype—they’re decided by whether the new option makes your team faster without making production harder.

5) Framework wars get interesting—because the real battleground is feedback loops

Framework wars usually get framed like religion: “React vs. Vue,” “Next vs. Remix,” “server vs. client.” 2024’s twist is that the battleground is shifting from logos to iteration velocity.

Three forces make this real:

AI-assisted development reduces the cost of wiring up prototypes.
Production requirements (security, latency, observability) still don’t go away.
Modern architectures increasingly separate the “UI shell” from the “capabilities backend” (RAG, tools, workflows).

So the winning frameworks will be the ones that:

make it easy to ship incremental changes,
integrate cleanly with backend services,
and don’t punish you with complexity when you need to debug.

This is also where htmx’s rise fits neatly: when you’re building AI-assisted workflows, you want UI patterns that respond quickly and predictably to backend decisions.

6) At least one major AI “disaster” resets expectations

Here’s the one bet I both expect and dread: in 2024, at least one major company will have a public AI disaster—bad enough that it temporarily resets how people talk about AI.

Will it be a data leak? A runaway automation incident? A high-profile reliability failure? I’m not predicting the exact cause. I’m predicting the pattern: impressive capabilities collide with real-world messiness, and the result becomes a teachable moment for everyone.

What that means for your roadmap

If you’re building with AI, the industry-level “reset” translates into three practical actions:

Prioritize guardrails over optimism. Add safe defaults, refusal logic, and permission checks where relevant.
Invest in evaluation. You can’t “prompt” your way out of bad edge cases forever.
Design for failure. A system that degrades gracefully beats one that fails loudly every time.

Disasters are bad for users—but they’re also how the market learns. Expect 2024 to reward teams that treat AI as an engineering discipline, not a novelty.

Conclusion: The year of boring reliability

My 2024 thesis is that AI stops being a spectacle and becomes infrastructure. RAG becomes standard because enterprises need grounding. Open-source models close the practical gap because evaluation and retrieval make “good enough” feel excellent. htmx and Bun make developers faster because they reduce ceremony. And when disaster strikes, it will remind everyone that reliability, observability, and guardrails aren’t optional.

In other words: bookmark this—and be ready to update your priors.

Turbopack, Rspack, and the Rust-ification of JavaScript Tooling

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 11 Dec 2023 00:00:00 +0000

JavaScript doesn’t need to be “fixed.” It needs to be handled. And for the last couple of years, the people building the JavaScript developer experience have been quietly making a bet: if you can’t make JS faster at runtime, make the tools that process it faster. The newest wave of that bet isn’t just performance—it’s implementation. Multiple core parts of the ecosystem are being rewritten in Rust, and the pattern is now too consistent to ignore.

This shift didn’t start with Rust. It started with the uncomfortable truth that a lot of JavaScript tooling was written in languages that don’t love CPU-heavy parsing and transformation. Then esbuild proved a thesis that felt like heresy to some: rewrite the hot path in a compiled language and the whole experience changes. Suddenly, the “developer workflow” wasn’t a black box—it was a performance budget you could actually win.

Now the budget has a new currency: Rust.

From “JavaScript everywhere” to “Rust in the critical path”

To understand why Rust is showing up everywhere, you have to separate where JavaScript tooling spends time:

Parsing: turning source code into an AST (and doing it repeatedly)
Transforming: rewriting syntax features, compiling TS/JSX, applying plugins
Bundling and graph traversal: resolving modules and building dependency graphs
Linting/formatting: walking syntax trees, generating diagnostics, printing consistent output

All of those are algorithmic and CPU-bound. They also benefit from predictable memory usage and fast execution. You can absolutely do high-performance work in JavaScript or TypeScript, but the runtime model fights you: the GC and dynamic dispatch are rarely your friends when you’re trying to parse tens of thousands of lines repeatedly during watch mode.

Rust’s pitch is straightforward: compile to native code, control allocations, avoid GC pauses, and squeeze performance out of the exact hot path that matters. The irony, of course, is that JavaScript—the language loved for its accessibility—is increasingly using Rust behind the curtain to make the day-to-day experience tolerable.

If you want a visceral example of why this matters, consider watch-mode workflows. It’s not “how fast can you build once?” It’s “how quickly can you respond to keystrokes without making your laptop sound like a jet engine?” Parsing and re-transforming code happens continuously, and the tooling has to be responsive under constant churn.

Turbopack: Rust-first for “next app” performance

Turbopack is the clearest signal that the Rustification isn’t limited to niche tools—it’s moving into the front yard. It’s being built with a Rust core strategy for the same reason earlier tooling innovations targeted the hot path: fast builds are a feature, not a luxury.

Where Turbopack matters is in the kinds of feedback loops modern apps expect:

Instant or near-instant incremental updates
Aggressive caching
Dependency graph intelligence
Handling modern module ecosystems efficiently

In practice, the best developer experience isn’t just speed in a benchmark. It’s the reduction of “dead time.” If your bundler is slow, your mental model gets cut every time the UI freezes: you stop trusting edits, you stop experimenting, you start waiting.

A Rust-powered bundler core can aim for a simple promise: minimize the work between change and result. That means doing less, reusing more, and scheduling what you must do in a way that keeps the pipeline responsive.

You can think of Turbopack’s Rust direction as “optimize the entire feedback loop,” not just compile something faster. It’s the difference between a race car and a commuter bike with better brakes.

Rspack: ByteDance’s Rust bet on bundler reality

If Turbopack tells you “the future is Rust,” Rspack tells you “Rust scales.” ByteDance is not interested in experimental prototypes for developer tools—they’re interested in tooling that handles huge codebases, constant iteration, and the practical messiness of real-world apps.

Bundlers don’t just process small examples. They process:

Large dependency graphs
Frequent updates across many files
Framework-specific patterns and edge cases
A constant stream of “works on my machine” issues

Rspack’s emphasis on performance aligns with the same core thesis: JavaScript tooling lives or dies by how efficiently it can parse and transform code and keep that work incremental.

Here’s a practical framing: if your build pipeline is slow, developers invent workarounds. Those workarounds become cultural overhead. They spawn tribal knowledge (“don’t touch this file,” “avoid this config,” “split this route”), which then makes performance worse over time. High-performance tooling prevents that spiral by reducing the friction that causes the workarounds in the first place.

Rspack is a sign that teams with serious throughput aren’t treating Rust as novelty. They’re treating it as infrastructure.

Biome: Rust as the replacement layer for ESLint + Prettier

The Rust trend isn’t confined to bundlers. Biome is where the “Rustification” becomes more intimate: it’s about editing and formatting—the stuff you see every day.

Historically, the ecosystem built a two-tool pipeline:

ESLint for linting (often overlapping with type-aware checks)
Prettier for formatting (opinionated, predictable output)

That separation can be valuable, but it also creates overhead: more configuration, more tooling startup, more places for conflicts, and sometimes more latency in the editor loop.

Biome’s Rust-first approach targets the whole formatting/linting experience as one coherent system. That’s the important editorial distinction: it’s not merely faster linting. It’s reducing “tool orchestration tax.” When you collapse multiple concerns into a single engine, you can:

Parse once, analyze multiple rules
Share AST work between linting and formatting
Provide more consistent diagnostics and edits
Reduce the time between file change and “green” state

A practical way to evaluate this in your own workflow: measure the time from “save file” to “editor stops nagging.” If that cycle feels sluggish, you don’t necessarily need a new rule set—you need fewer passes, less overhead, and faster execution in the critical loop. Rust is particularly suited to this kind of tight iteration.

Oxc: The compiler pipeline creeps into everyday JavaScript

Then there’s Oxc, which represents a deeper shift: Rust is becoming the language of JavaScript’s internal machinery. Oxc isn’t just “a linter.” It’s a toolkit covering parsing, transformation, and linting-like capabilities—effectively, pieces of a compiler pipeline.

This is where the Rustification becomes a philosophical change. For years, JavaScript tooling has often been “glued together” with plugins and AST walks done in whatever language the project started with. But as tooling grows more ambitious—supporting new syntax, optimizing transforms, and keeping pace with evolving specs—the cost of duct-tape implementations becomes obvious.

A compiler-like architecture benefits from:

Fast parser implementations
High-quality AST representations
Efficient code generation / transformation
A coherent internal model for rules and diagnostics

Rust’s ownership model doesn’t magically guarantee correctness, but it does encourage careful engineering around memory and invariants—exactly what you want when you’re building the engine that sits underneath every edit.

The real advantage: smaller latency, not just faster builds

It’s tempting to reduce the Rust shift to “performance.” But performance is the surface explanation; the real win is latency predictability.

When tooling is written in slower execution environments, the user feels it as randomness: sometimes it’s fine, sometimes it spikes. Rust-powered tooling aims to make the execution time more consistent—less jank during parse/transform phases, fewer “waiting for the machine” moments.

That matters because developer workflows aren’t linear. They’re interrupt-driven. You type, you save, you switch tabs, you rename files, you re-run commands. Tooling needs to behave well under interruption and incremental updates. The best tools make you forget they’re running—until they need to output a helpful diagnostic. That’s the ideal loop: fast enough that the tool fades into the background.

If you’re adopting these tools, prioritize this question over benchmark numbers:

Does the tool reduce the number of times you have to wait, restart, or rethink your workflow?

In most teams, that’s more valuable than shaving seconds off a one-time build.

Should you care as a developer—or only as a tooling user?

Yes—and no.

If you’re just using the ecosystem, you’ll feel the improvements without doing anything. Faster hot reloads, less editor lag, quicker feedback on issues: the benefits land automatically.

But if you’re building libraries, frameworks, or custom tooling, the Rustification changes what “good engineering” looks like in the ecosystem. It sets expectations:

AST processing and transforms must be efficient
Incrementality should be built-in, not bolted on
Tooling latency is part of the product

So the practical advice is simple: treat tooling performance like UX. If your project’s configuration or custom transforms create slow paths, new fast engines won’t save you. You still need to be mindful about:

Excessive plugin chains
Unnecessary rebuild triggers
Expensive type-aware checks in the wrong loop
Overly broad lint scopes for large repos

Rust engines can move faster, but they can’t fix design that forces them to do unnecessary work.

Conclusion: Rust isn’t replacing JavaScript—it’s defending it

The JavaScript ecosystem didn’t become Rust-first because developers suddenly got bored with JavaScript. It happened because the bottleneck moved into places where CPU-heavy parsing and transformation dominate, and the tooling needs to be responsive under constant change.

Turbopack, Rspack, Biome, Oxc—each tool is different, but they rhyme. They’re rewriting the critical path in Rust to deliver faster feedback loops, lower latency, and more dependable developer workflows.

And the irony remains delicious: the language that developers reach for because it’s accessible is increasingly paired with Rust behind the scenes because “accessible” should also mean “fast enough to keep up.”

2023: The Year AI Crashed the Developer Party

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 06 Dec 2023 00:00:00 +0000

In 2023, software development didn’t just get new tools—it got a new baseline expectation. One moment, AI was an experimental novelty; the next, it was sitting in your editor, answering questions while you worked, drafting code while you blinked. The result wasn’t a robot uprising. It was something more uncomfortable: a permanent shift in what “good” looks like for a single developer.

AI became part of the workflow—not a separate project

For years, “AI for developers” sounded like a side quest. People experimented with bots, tried prompts for documentation, and built prototypes that felt impressive but didn’t change the daily rhythm of shipping products.

In 2023, that changed. ChatGPT became a default reference tool for many developers, and Copilot-style assistants moved from “try it” to “use it.” The practical impact is simple: AI started compressing time-to-first-draft. You asked fewer “Where do I start?” questions and more “Will this scale?” questions—because the first answer arrived instantly.

That speed is addictive, but it’s also a trap if you treat AI output as truth. A common 2023 pattern: a developer accepts a generated function, runs tests, and then discovers edge cases three days later. The mistake isn’t using AI—it’s skipping the “human responsibility” step that you can’t delegate: validating assumptions. AI is excellent at producing plausible solutions. It’s not responsible for your product’s invariants.

Practical framing for 2024: treat AI like a powerful junior teammate. Great at drafts, unreliable on consequences. Require it to explain, justify, and reveal uncertainty. If the assistant can’t articulate trade-offs—latency, cost, correctness, failure modes—it’s not ready for production decisions.

The bar rose: one developer could do more—and had to

The biggest story of 2023 wasn’t replacement. It was leverage. When tools reduce friction for common tasks—boilerplate, translation between APIs, test scaffolding, code review suggestions—the limiting factor moves. Less time gets spent wrestling syntax, more gets spent on architecture, correctness, and system behavior.

This is why 2023 felt disruptive even to developers who barely changed their codebase. The work became less about writing the first version and more about owning the second and third: performance tuning, security hardening, and resilience under real-world chaos.

A concrete example: imagine a developer building an internal service. Without AI, they might spend an entire afternoon wiring request handlers, validating inputs, and writing basic tests. With AI, they can get that skeleton running in minutes. Great. But now they’re expected to use that freed time to handle the stuff that AI can’t “solve” for you: rate limits, idempotency, observability, schema evolution, and clear failure semantics.

Opinionated takeaway: the future isn’t “AI writes code.” It’s “AI writes drafts,” and developers become accountable for design quality. In 2023, companies learned they could expect faster delivery from individuals. That expectation doesn’t vanish. It just raises the cost of shipping sloppy work.

Copilot-style coding changed how teams review code

Once AI is in the editor, pull requests change. The review surface area doesn’t disappear—it morphs.

In 2023, many teams discovered that “looks good” is no longer sufficient. Generated code can be stylistically consistent and logically coherent while still being wrong for your context. It may:

misunderstand your domain constraints,
ignore your existing abstractions,
introduce inefficient patterns that pass tests but struggle in production,
or quietly omit security and error-handling details you normally wouldn’t forget.

The best teams responded by tightening review criteria. Instead of spending energy debating whether a loop should be a for or a while, reviews shifted toward:

correctness under edge cases,
adherence to system conventions,
performance characteristics (especially around I/O and concurrency),
and explicit handling of failures (timeouts, retries, partial results).

Practical advice: update your team’s pull request checklist to reflect AI realities. For example:

Does the change include tests for failure modes?
Does it follow established error-handling patterns?
Are we using safe parsing/validation instead of trusting inputs?
Are we logging enough to debug incidents without drowning in noise?

If your review process didn’t evolve in 2023, your quality drift probably did—just quietly.

PostgreSQL “finished the job” as the default database choice

Every developer has a story about database indecision: one project that used something “new” that became a liability, another that bolted on caching without understanding consistency, another that promised “schema-less flexibility” and delivered chaos instead.

In 2023, PostgreSQL’s position as the default backbone hardened. This wasn’t a dramatic announcement—it was a continuation. Teams kept choosing it because it reliably supports the real work: transactions, indexing, query planning, constraints, and the boring discipline that keeps data from turning into a haunted house.

When you combine PostgreSQL with modern tooling, it becomes an even more practical default. AI-assisted development thrives on stable primitives. It’s easier to ask an assistant to generate correct migrations, queries, and test cases when the “target” system is mature and well-understood.

A common 2023 workflow looked like this: developers built features faster using assistants, then leaned on PostgreSQL to keep data integrity intact. They still had to learn how to write good queries and model relationships—but they weren’t fighting the database itself.

Practical advice if you’re modernizing in 2024: don’t treat PostgreSQL as a novelty. Treat it like the core product. Invest in:

proper indexing (and measuring query plans),
constraints and validation at the schema level,
migrations you can roll forward and back safely,
and observability around slow queries and lock contention.

The fastest AI-generated feature is worthless if it causes recurring incidents at 2 a.m.

Rust kept expanding the systems programming frontier

While AI dominated headlines, 2023 also reinforced a quieter story: developers keep choosing Rust for systems-level correctness and performance without forfeiting safety.

Rust’s “conquest” isn’t about replacing every language. It’s about winning the slices where teams care deeply about memory safety, concurrency, and predictable behavior. In practice, Rust made its case by being usable: tooling matured, crates ecosystems filled in the gaps, and teams could move from “this is promising” to “this is our standard” at an accelerating pace.

A useful way to view 2023’s Rust momentum is as a counterpoint to AI. AI can generate code quickly, but systems programming punishes assumptions. You can’t hand-wave data races or undefined behavior. Rust’s borrow checker isn’t just a constraint—it’s a forcing function that makes correctness cheaper over time.

Practical advice: if you’re adopting Rust in 2024, resist the urge to rewrite everything. Start with components that benefit immediately from safety and performance: parsers, protocol handlers, background workers, and services with heavy concurrency. Then build a culture: consistent error handling, profiling early, and a shared approach to testing.

The real question for 2024: how not to become dependent

AI in 2023 didn’t replace developers. It replaced some steps in the workflow. That’s a gift—but gifts can become crutches.

Dependency doesn’t look like “not coding.” It looks like:

blindly trusting output,
failing to understand the generated code enough to debug it,
shipping with weak tests because “it worked in the demo,”
and letting expertise atrophy because the machine handles the first draft.

To avoid that outcome, you need intentional habits.

Start with “understand before you merge.” When AI drafts a function, your job is to verify behavior, not just compile success. Ask it to add tests for edge cases. Then run them. When it suggests an optimization, measure it.

Use AI to accelerate learning, not bypass it. A good workflow is: generate → inspect → refactor → explain. If you can’t explain why the code is correct, it’s not done.

Codify prompt patterns as team knowledge. Prompts are like macros: they’re powerful when standardized. Create internal prompt templates for common tasks—migrations, query writing, test generation, security checks—and document the review expectations. The goal is not to standardize wording. It’s to standardize rigor.

Conclusion: 2023 raised the bar; 2024 is about craftsmanship with leverage

2023 was the year AI crashed the developer party—then quietly became the music. The change wasn’t that developers vanished. It’s that shipping got faster, and quality expectations rose with it.

The smartest teams in 2024 won’t ask whether to use AI. They’ll ask how to use it without surrendering judgment. If AI drafts the code, developers must own the consequences. That’s the new contract—and it’s how the best work will keep happening.

Advent of Code Is the Best Professional Development You're Not Doing

abdecastro@protonmail.com (Antonio B De Castro) — Fri, 24 Nov 2023 00:00:00 +0000

Every December, a weird little ritual takes over developer calendars: people voluntarily sign up for an inbox of intentionally pointless problems. Advent of Code doesn’t ship features. It doesn’t close tickets. It certainly doesn’t care about your sprint goals. And yet, if you want a fast track to becoming a sharper production engineer, it’s one of the best training programs you’ll actually do.

Not because the puzzles are “fun” in some vague, hand-wavy way—but because they relentlessly pressure the exact skills that make work smoother when the stakes are higher: parsing what you thought would be easy, handling edge cases you didn’t model, optimizing the right thing, and turning “I think this works” into “this works everywhere.”

Why pointless puzzles aren’t pointless

Advent of Code is intentionally designed to be a workout. Each year delivers 25 daily problems that are conceptually small but technically sticky. The inputs are messy in the way real systems are messy—lines break unexpectedly, separators aren’t what you assumed, counts overflow your intuition, and off-by-one errors show up like clockwork.

In product engineering, you often stay in your domain. You build pipelines, services, UIs, or infrastructure within a familiar toolbox. That’s valuable, but it can lead to a kind of cognitive comfort: you default to the approach you’ve used before.

Advent of Code blows that comfort up. One day you’re writing a parser. The next you’re doing graph traversal. Then you’re threading a needle through dynamic programming. This is not “domain hopping” for entertainment; it’s targeted cross-training. You’re forced to learn how to think when the usual assumptions don’t apply.

And here’s the part that matters: the skills don’t stay trapped in December. They migrate into January as habits—cleaner code boundaries, more careful reasoning, better test instincts, and a willingness to scrutinize performance before it hurts.

The real professional skill: turning inputs into trusted behavior

The fastest way to become a better production engineer is to improve your relationship with inputs. In the real world, bad data isn’t rare—it’s just not always your fault. Teams learn (or should learn) to treat input handling as a first-class concern.

Advent of Code starts there. Even when the puzzle theme is whimsical, the practical task is always the same: take a text blob, interpret it correctly, and produce accurate results for two parts—often with Part 2 requiring a more sophisticated approach.

Consider the recurring pattern:

Parse an input format you don’t fully control.
Model the problem state clearly.
Solve for Part 1 with a straightforward technique.
Refactor or upgrade for Part 2 when the naive solution fails—usually due to time complexity, memory use, or a misunderstood constraint.

That cycle is a microcosm of production work. In January, when a new service receives unexpected payload shapes or when a query slows down after growth, you’re better prepared—not because the problems were identical, but because your brain learned to treat “what does the input actually mean?” as a disciplined question.

The edge-case factory (and why it’s good for you)

If you want to know what separates reliable engineers from “works on my machine” engineers, it’s not heroics. It’s edge cases.

Advent of Code is a deliberate edge-case factory. The puzzles often reward players who do the boring work:

Confirming boundary behavior (empty lines, singleton lists, zero-length segments)
Validating assumptions (are you indexing rows or coordinates?)
Handling special cases explicitly instead of hiding them in vague “else” logic
Making invariants obvious (what must always be true at each step?)

A common example: movement and adjacency problems. You’ll repeatedly manage coordinate transforms. In production, you’ll later deal with time zones, pagination, coordinate systems in graphics, or indexing in caches. The details differ, but the failure modes rhyme.

When you solve these puzzles, you develop a reflex: before you run, you ask where the logic might break. You start building confidence through reasoning, not luck.

Learn outside your comfort zone—on purpose

The strongest argument for Advent of Code as development is simple: do it in a language you’re learning.

Learning a new language makes the training more honest. It forces you to engage with:

parsing and string handling idioms
data structure tradeoffs
performance characteristics
error handling patterns
test ergonomics

For instance, in one language you might reach instinctively for regex-heavy parsing and forget about maintainability. In another, the standard library might steer you toward robust parsing utilities. Either way, you feel the consequences quickly because the puzzles don’t care about your preferences—they care about correctness and efficiency.

A practical rule: pick one “home language” for the year and stick with it for the whole series. You don’t need to become fluent in 25 days; you need to build a repeatable workflow: read input → model → implement → test → iterate.

If you bounce languages mid-season, you’ll lose the compounding effect. The point is to let your tooling and muscle memory improve over time.

Treat it like a mini engineering project

Advent of Code is a personal game unless you upgrade the process. If you want the training to stick, run it like a small engineering project:

Write a real parser for the input, even if a quick split works today.
Tomorrow’s input variations will punish sloppy assumptions.
Add tests early, not just at the end.
Most puzzle statements include examples. Turn those into tests. Then create additional tests for boundary scenarios you can reason about.
Benchmark the Part 2 approach, even if it’s “just” a puzzle.
If your algorithm becomes slow, that’s your clue that your production instinct should already be screaming: optimize the right thing.
Refactor between parts.
A common trap is copying your Part 1 solution into Part 2 and bolting on hacks. Instead, extract reusable functions (grid parsing, neighbor generation, graph edges, state transitions) and keep the core logic clean.
Write explanations in comments or a short README.
Future-you is a teammate. Your future self will thank you when you revisit an approach months later.

Here’s a concrete example workflow that pays dividends: suppose you’re solving a grid navigation puzzle. Write helper functions first:

parse_grid(input) that returns a structured grid
neighbors(position, grid) that centralizes movement rules
solve_part1() for the straightforward shortest path (maybe BFS)
solve_part2() for the modified constraint (maybe Dijkstra or BFS with additional state)

When you do this repeatedly across days, you’re practicing the same habits you’ll need for production: modularity, clarity, and separation of concerns.

What you’ll notice in January

The improvements aren’t theoretical. They show up as small but compounding differences in your day-to-day work:

Fewer “surprises” when inputs don’t match your expectations.
Better algorithm choices under constraints, because you’ve felt performance pain before.
More deliberate edge-case coverage, especially around boundaries and indexing.
Cleaner code structure, because you’re constantly forced to revisit designs when Part 2 arrives.
A calmer approach to complexity, since you’ve trained on escalating difficulty without panicking.

The most valuable shift is mental. Advent of Code teaches you to respect constraints—time, memory, correctness—early. You stop assuming “it should work” and start proving it, either with tests or with reasoning, or both.

And yes, it’s still fun. But fun is the marketing. Skill is the product.

Conclusion: Do it, then keep the habits

Advent of Code is the best professional development you’re not doing because it’s not pretending to be a course. It’s a forcing function: it drags you into unfamiliar problem types, punishes sloppy assumptions, and trains the engineering behaviors that matter most when real systems fail.

If you want a measurable impact, don’t just “solve puzzles.” Run it like an engineering practice. Use a language you’re learning. Build tests from the examples. Refactor deliberately. Then carry the habits into January—where the work actually happens.

Signals Are Taking Over Frontend Frameworks and React Is Late to the Party

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 12 Nov 2023 00:00:00 +0000

Frontend development is finally admitting what many teams have felt for years: “re-render everything” is a blunt instrument. In its place, a more precise paradigm is spreading across frameworks—signals. These reactive primitives track what depends on what, then update only the parts of the UI that actually need to change. Angular did it first, Solid made it feel effortless, and Vue/Preact/Qwik shipped variants. React, meanwhile, is still treating memoization as an art form instead of a baseline capability.

This isn’t just trend-chasing. It’s a different mental model—one that reduces wasted work and makes performance less of a self-inflicted tax.

What signals change: from “re-render the world” to “update the truth”

The core idea behind signals is simple: state is represented by primitives that know who depends on them. When a signal changes, the system automatically recalculates derived values and re-renders only the minimal set of consumers.

Contrast that with the dominant React pattern most apps still follow:

UI re-renders when component state/props change.
Developers then try to prevent unnecessary re-renders using React.memo, useMemo, and useCallback.
When optimization fails, the fix is often “sprinkle more memoization,” sometimes with fragile dependency arrays and unclear performance wins.

Signals flip that burden. You describe reactive relationships once, and the runtime keeps them consistent. If a UI subtree doesn’t depend on the updated signal, it never re-renders in the first place.

A practical way to see the difference: imagine a dashboard with filters on the left and a chart list on the right. When a user toggles a filter, only the chart list needs to change. With signals, that dependency is explicit: chart rendering consumes filter signals, while unrelated UI doesn’t. With re-render-everything, the “chart list” is often still re-rendered indirectly—React will reconcile anyway, and whether reconciliation short-circuits depends on memoization strategy and component structure.

Angular, Solid, Vue, Preact, Qwik: the ecosystem is converging

Signals aren’t one monolithic thing—each framework has its own flavor—but the trajectory is clear: the industry is converging on dependency-tracked reactivity as the default.

Angular adopted signals as a first-class reactivity model. It’s not positioned as a niche optimization; it’s the direction of the platform.
Solid is essentially “signals-first.” Reactive updates are granular by design, and UI updates are tied directly to reactive reads.
Vue introduced reactivity that feels very close to signals in practice, with dependency tracking and targeted updates baked into the framework’s reactivity system.
Preact has followed the same pragmatic path: keep updates precise and fast without forcing developers into a maze of memoization hooks.
Qwik takes the idea further by optimizing for resumability (the ability to load less JavaScript up front), while still using signals/reactivity patterns to keep UI updates aligned with actual data dependencies.

The common thread across these ecosystems is that “efficiency” isn’t an afterthought. It’s what the runtime does while you focus on building features.

React’s holdout: power through memoization, or a performance tax in disguise?

React has a sophisticated rendering model and a strong mental framework—there’s a reason it became the default for years. But in the signal era, React’s current stance reads less like a principled design decision and more like a willingness to outsource performance to developers.

In practice, the React approach often looks like this:

A state update occurs.
Components re-render.
Developers attempt to curb the blast radius:
- useMemo to avoid recomputing expensive derived values.
- useCallback to stabilize function identities passed to children.
- React.memo to prevent re-renders of child components.
If something still re-renders, you profile, refactor, and repeat.

The problem isn’t that React memoization can work. It’s that the default path requires constant vigilance. A small code change—like capturing stale values incorrectly or missing a dependency in a memo hook—can silently sabotage performance (or correctness).

Worse, many teams end up with optimization logic that’s harder to read than the actual UI code. The application becomes a patchwork of “render control” rather than a clean expression of data dependencies.

To be blunt: React didn’t just lag behind signals. It kept the assumption that developers can and should manually manage reactivity boundaries.

The real benefit: signals make performance predictable, not heroic

The most compelling argument for signals is not raw speed—it’s predictability.

With dependency-tracked updates, the system knows exactly which computations and UI pieces are affected. That turns performance into a property of the programming model, not a recurring project management task.

Consider a common React performance trap: a list rendering component with derived sorting/filtering. Developers often wrap the sort with useMemo and the callbacks with useCallback. But the real work is determining whether the dependencies truly change when they should. In large apps, dependency arrays become a form of long-term technical debt.

Signals reduce this fragility. Derived values are automatically recomputed when (and only when) the signals they read change. You’re not asking React to guess when recomputation is necessary—you’re telling the reactive system what depends on what.

Here’s what that looks like conceptually:

A derived value reads filterSignal and itemsSignal.
When filterSignal changes, only the derived value recalculates.
Only the UI bound to that derived value updates.

No need to propagate “stability” via useCallback just to satisfy referential equality.

Practical migration mindset: you don’t need a rewrite to learn from signals

React might not be shipping signals broadly tomorrow (or ever, in the same way), but you can still adopt the core lesson: make dependencies explicit.

If you want the practical benefits without a framework switch, start by changing how you structure state:

Co-locate derived state with its inputs. If something is derived from multiple sources, keep it near the code that consumes it and ensure it’s recomputed only when those sources change.
Avoid passing unstable objects/functions deep into the tree. Even in React, this is often where performance leaks out.
Prefer localized state updates over global “everything changed” patterns. If one change invalidates a huge subtree, your reactivity boundaries are too coarse.
Profile before optimizing. The goal isn’t to memoize everything—it’s to stop re-render storms at the source.

If you’re already using React and feel forced into the memoization treadmill, signals are the clearest signal (pun intended) that you should reconsider your architecture. You don’t have to adopt a new framework to adopt the mindset: dependencies should drive updates, not the other way around.

And if you are choosing a new stack today? The decision is hard to justify for teams optimizing for correctness and performance without micromanaging re-render boundaries. Angular/Solid/Vue/Preact/Qwik aren’t perfect, but their direction is coherent: reactive primitives first, optimization as default behavior rather than a developer chore.

Conclusion: signals are the direction of travel—React should catch up

Signals represent a shift from “render cycles as the unit of work” to “data dependency as the unit of truth.” That change reduces unnecessary work, simplifies reasoning about updates, and removes a large portion of the performance burden from developers.

React can still build great products, and it will keep its loyal base. But the ecosystem is converging on signals because they solve a real, recurring problem: re-render-everything models force developers to simulate dependency tracking after the fact. Signals don’t simulate—they embody it.

At this point, the question isn’t whether signals are better. It’s whether React wants to treat them as a feature of modern UI engineering rather than a competing philosophy—because the rest of the industry already has.

GitHub Copilot Chat vs. ChatGPT for Coding: Which Actually Ships Better Code?

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 05 Nov 2023 00:00:00 +0000

AI coding tools are everywhere, but “better” is the wrong question. The question that matters is simpler: which one gets you to a commit that actually passes review—faster, with less thrash? I tested two popular options head-to-head—GitHub Copilot Chat and ChatGPT—across real tasks you’d recognize from a normal engineering week: debugging, refactoring, test generation, code review, and greenfield feature work. Then I looked not at demos, but at the edit distance between “AI output” and “shippable code.”

The Setup: 30 Tasks, Real Constraints, Real Code

This wasn’t a synthetic benchmark where everyone agrees on the same toy problem. I ran both tools through 30 real-world coding tasks, roughly evenly distributed across five categories:

Debugging: given a failing function or stack trace, fix the bug with minimal churn.
Refactoring: improve structure without changing behavior.
Test generation: add unit tests that match existing patterns and libraries.
Code review: identify issues, suggest improvements, and estimate risk.
Greenfield implementation: implement a feature from a specification with reasonable coding standards.

A few ground rules made the results meaningful:

I used the tools in the environments they’re designed for: Copilot Chat inside the IDE and ChatGPT in a browser.
I scored outcomes by whether the code worked on the first integration attempt, how much editing it required, and how often the tool needed follow-up clarification to avoid drifting.
For “code generation,” I measured a practical metric: the percentage of output that needed modification before it was correct and stylistically consistent. In both tools, it hovered around 60%.

That last point matters. It’s the antidote to the hype.

What IDE-Integrated AI Does Better: In-Context Modification

Copilot Chat’s biggest advantage isn’t that it “understands code” in some abstract way. It’s that it lives with your code. When your IDE has open files, surrounding definitions, local types, and the current refactor context, the assistant can stop guessing.

Example: Debugging Without Re-Explaining the World

In debugging tasks, Copilot Chat consistently performed better because it could see the relevant module structure immediately. For instance, when tracking down a null-handling bug in a TypeScript utility, I could point to the failing call site and ask Copilot Chat to “fix the logic and keep the current interface.” It didn’t need me to paste the entire dependency graph—because it could infer what mattered from the workspace.

The result wasn’t magic. It was operationally cheaper:

fewer clarifying questions,
smaller patches,
less time reconciling assumptions.

Example: Refactors That Respect the Local Style

When refactoring, Copilot Chat also tended to respect local patterns: naming conventions, helper functions already present, and idioms used in nearby files. In one refactor, I asked it to “extract validation into a reusable function” while preserving error types. It produced a change set that matched the project’s existing approach—so I edited minor details rather than rewriting the whole plan.

Opinionated takeaway: if your problem is “change these lines correctly, given what’s already here,” Copilot Chat is the more reliable tool. It’s built for the moment-to-moment work of editing.

Where ChatGPT Holds the Edge: Architecture, Planning, and Dialogue

ChatGPT’s advantage isn’t proximity to your workspace. It’s its ability to handle long-form reasoning and maintain a coherent thread over multiple iterations—especially when the problem is bigger than a single file.

Example: Greenfield Feature Planning

For greenfield tasks, I often started with a feature spec and constraints: “Implement X, but follow our modular boundaries and ensure we can later add Y.” ChatGPT did better in two ways:

It proposed an architecture first—components, responsibilities, and how data flows.
It handled iterative refinement without losing context.

Copilot Chat can do architecture too, but it’s more naturally oriented toward local changes. ChatGPT, by contrast, feels like you’re collaborating with someone who can hold the full project model in their working set while you debate tradeoffs.

Example: Code Review as a Conversation

For code review tasks, I leaned on ChatGPT for a different reason: I could ask it to walk through reasoning, risks, and alternative approaches. When reviewing concurrency logic or API design decisions, I didn’t just want a list of “what’s wrong.” I wanted the “why,” the “what could break,” and the “what would you change if you had a day to improve it.”

ChatGPT tends to deliver that in a more dialog-friendly way—especially across multiple rounds.

Opinionated takeaway: if your problem is “make sense of the design, choose an approach, and iterate through tradeoffs,” ChatGPT is usually the stronger partner.

The Surprise: Neither Tool Is Reliably “Good at Code Generation”

Here’s the part that undercuts the most common marketing claims: for the act of generating code that you can drop in and run, neither tool was consistently better.

Across the tasks, both tools produced code that required modification about 60% of the time. Sometimes that modification was small—renaming symbols, adjusting edge-case handling, or aligning with existing abstractions. Other times it was structural—an incomplete implementation, mismatched assumptions about libraries, or logic that worked in isolation but not in the project.

Why this happens (and why it’s not a deal-breaker)

Code generation fails in predictable ways:

Project-specific conventions aren’t always known to the model, even when context is provided.
Hidden dependencies (configuration, error types, middleware expectations, existing helper utilities) cause drift.
Edge cases are rarely captured correctly on the first try, especially when the spec is underspecified.

But here’s the useful reframing: “bad at generating perfect code” doesn’t mean “bad at helping you ship.” In practice, the real win is using the tool to compress the gap between a vague idea and a working baseline—then using your judgment (and tests) to finish the job.

Practical Workflow: Use Both, and Use Them for What They’re Best At

So what’s the best system? Not “pick a winner.” It’s a workflow that matches the tools to the tasks.

When to Use Copilot Chat (In-IDE)

Use Copilot Chat when you need:

targeted edits to open files,
small refactors that must match local patterns,
quick debugging tied to the current codebase,
test additions that match existing conventions.

Tactic: Ask for a patch, not an essay. For example:
“Fix the bug here while preserving the public API. Show the diff and don’t refactor unrelated code.”

When to Use ChatGPT (Browser-Based)

Use ChatGPT when you need:

architecture planning and tradeoff exploration,
longer back-and-forth refinement,
code review reasoning and risk analysis,
learning support (“explain why this approach is safer”).

Tactic: Provide the “shape” of the system, then iterate. Example:
“Here’s our module layout and constraints. Propose a design, then critique it and suggest an alternative that improves testability.”

The Best Hybrid Loop

A workflow that repeatedly worked during my test run:

ChatGPT for plan: define architecture, validate assumptions, list edge cases.
Copilot Chat for execution: implement the plan in the IDE, adjust to local code realities.
Tests as the arbiter: whatever the AI says, tests determine truth.
One final ChatGPT pass for review: ask for risk assessment and improvements.

This loop turns AI from “code generator” into “software partner”—planning plus execution.

Don’t Trust Output—Instrument It

If you want the tools to “ship better code,” you have to pair them with verification. In my runs, the highest-confidence improvements weren’t the ones that looked polished—they were the ones that were validated quickly.

Concrete advice:

Require minimal diffs for debugging: change the smallest area first, then expand only if tests demand it.
Use property-based or boundary-focused tests when you ask for “edge case handling.” Don’t accept generic “handles errors” language—write tests.
Ask for test updates alongside code changes, especially for refactors. If the tool can’t explain what tests would change, it’s probably guessing.
For code review tasks, ask for failure modes: “What would you expect to break in production if this ships?”

AI is best treated like a junior engineer who can draft quickly—but who needs your oversight and your test suite.

Conclusion: Copilot Ships Locally, ChatGPT Thinks Globally—but Both Need You to Finish

After 30 real tasks, the verdict is clear and a little deflating: Copilot Chat wins for in-context code modification because it operates inside your workspace. ChatGPT wins for architectural discussions and learning because it excels at long-form dialogue and reasoning. The surprise is that neither is reliably better at first-pass code generation—both often require meaningful edits before they become correct, consistent, and review-ready.

The best outcome isn’t choosing one tool. It’s using both the right way: ChatGPT to shape the design and challenge assumptions, Copilot Chat to implement changes that fit your codebase, and tests to decide what ships.

The State of Containers in 2023: Beyond Docker Compose

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 31 Oct 2023 00:00:00 +0000

For years, “containers” quietly meant “Docker Compose plus a Dockerfile.” In 2023, that shorthand is no longer enough—and that’s a good thing. The container ecosystem has unbundled into separate components with different responsibilities, trust boundaries, and performance characteristics. If you still think of containers as one product, you’ll keep hitting ceilings. If you understand the layers, you’ll build faster, secure better, and troubleshoot like a grown-up.

Docker the company vs. Docker the runtime: two stories that don’t match

Let’s start with the uncomfortable truth: “Docker” is both a company story and a runtime story, and they’re converging less than they used to. For many teams, Docker Desktop remains the smoothest path to running local containers, especially on developer laptops. Compose is still a practical way to coordinate services.

But on the backend, reality diverges:

Some environments run workloads without a long-lived daemon.
Kubernetes relies on a runtime layer that is not “Docker.”
Image builds are often handled by builders that don’t care about Compose at all.

So the real question isn’t “Are containers still Docker?” The real question is: which layer are you actually using, and what assumptions did you inherit when you picked it? That’s where most teams start getting meaningful improvements.

Podman: rootless by default, and why it changes your threat model

Podman’s core value proposition is simple: you can run containers without a daemon, and you can do it rootless by default. That sounds like implementation detail—until you look at what it means for security and operations.

In many Docker-based workflows, the daemon is a privileged point of control. When you run containers, you are indirectly asking that daemon to perform privileged operations on your behalf. Rootless operation flips the model: containers run with your user’s privileges, and the runtime is designed to work within those constraints.

A practical example: local dev without “sudo roulette”

Imagine you’re developing a microservice that needs to write to a mounted directory and bind ports locally. With rootless runtimes, you’re less likely to reach for “just run it as root” when something goes sideways.

Try this mental checklist when you evaluate rootless support:

Do you need elevated privileges for file access, or can you use user-owned mounts?
Are ports you expose compatible with your user namespace mapping (e.g., unprivileged ports)?
When you map volumes, what does the container process actually get permission to do?

Podman doesn’t remove all complexity, but it forces you to confront privilege boundaries earlier. That’s exactly what you want. Better to discover “this workload shouldn’t need root” on day one than after a production incident.

containerd: the runtime engine Kubernetes actually speaks

If you’ve been building on Kubernetes for more than a minute, you already live in the world of containerd—whether you realized it or not. containerd is the runtime layer that executes container workloads. It’s the piece that sits “under” higher-level orchestration and starts the containers.

This matters because performance and security troubleshooting often comes down to runtime mechanics:

How images are unpacked and stored
How namespaces and cgroups are configured
What happens when pulls fail, signatures don’t validate, or filesystem mounts behave differently than expected

Practical advice: learn the language of the runtime, not just the CLI

When something breaks, you don’t want to guess at the boundary between “Kubernetes says it’s running” and “the container actually started correctly.” Knowing that containerd is the executor helps you frame investigations:

Is the issue image-related (pull/build/artifact), or execution-related (runtime configuration)?
Are you dealing with permissions, filesystem behavior, or networking?
Do you see errors in runtime logs that align with pod lifecycle events?

Even if you never touch containerd directly, internalizing that Kubernetes talks to a runtime makes your debugging more precise.

BuildKit: stop thinking of image builds as one monolithic step

Compose and “docker build” are easy mental models. The catch is that building images has become a sophisticated pipeline: caching, parallelization, cross-stage optimization, and reproducibility are all different problems than “run a Dockerfile.”

BuildKit is a builder designed to handle that complexity. In practice, the difference shows up when you care about:

Fast rebuilds (especially in monorepos)
Deterministic output (so deployments are traceable)
Efficient multi-stage builds (so your runtime image isn’t bloated by build tooling)

Example: the monorepo trap

If you build multiple services from a shared repo, naive Docker builds often invalidate cache too easily. One small change forces everything to rebuild, even if 90% of layers are unchanged.

With a BuildKit-style mindset, you start designing builds for cache stability:

Split dependency installation steps from source compilation steps
Use multi-stage builds so only the final artifacts ship
Structure Dockerfile stages so changes only invalidate what truly depends on them

This isn’t just faster—it’s a reliability upgrade. Fewer unnecessary rebuilds means fewer opportunities to introduce transient failures and fewer changes to inspect when something regresses.

The ecosystem unbundled: why “containers” is now a stack you must understand

The most important shift in 2023 is that the container ecosystem isn’t a single thing anymore. It’s a set of cooperating components:

Image building (e.g., BuildKit)
Image storage and distribution (registries and content-addressed layers)
Runtime execution (e.g., containerd)
Service orchestration/compose tooling (e.g., Compose, or Kubernetes for real clusters)
Security and trust tooling (signing, scanning, policy enforcement)

When these were bundled tightly, teams could “set and forget.” Now you need to know what each layer does and where security controls live.

Security: stop assuming you get it “because you’re using containers”

Security posture depends on where you enforce it:

Do you verify image provenance/signatures before runtime?
Do you scan the right artifacts—the final image you deploy, not just intermediates?
Are runtime privileges minimized (rootless where appropriate)?
Do you understand what the filesystem mounts allow inside the container?

The unbundling forces better hygiene. You can’t outsource security to a single vendor setting anymore. But you also gain flexibility: you can pick the components and policies that fit your risk profile.

Performance: measure the right bottleneck

Performance issues often trace back to layer boundaries:

Slow pulls? That’s registry/storage/network.
Slow rebuilds? That’s build caching and Dockerfile structure.
Slow startup? That’s runtime execution and filesystem/cgroup configuration.
High resource usage? That’s app/container config plus how the runtime constrains it.

A stack-aware mindset turns “containers are slow” into a concrete investigation plan.

Docker Desktop as an on-ramp—and a curriculum for escaping abstraction

Docker Desktop remains the easiest on-ramp. It’s a polished developer experience: it spins up what you need, abstracts away runtime details, and gets people shipping.

But if you stay at that abstraction level forever, you’ll eventually hit friction in production. And production is where the layers matter: rootless behavior, runtime logs, image build caching, and cluster execution semantics.

A simple learning path that pays off

Here’s a practical approach that keeps your team productive while building real understanding:

Use Docker Desktop for local iteration, but treat it as a convenience, not a reference architecture.
Practice with Podman rootless for at least a few workflows. Learn what changes when you don’t have a privileged daemon.
Become fluent in Kubernetes-runtime boundaries by learning what containerd is doing when a pod starts.
Optimize a Dockerfile with BuildKit-style thinking, even if you still invoke it via higher-level tooling.
Write down your security pipeline: where scanning happens, where signing is verified, and what policy blocks deployment.

This is how you turn “containers” from a button-click into an engineering discipline.

Conclusion: the future isn’t “Docker vs. not Docker”—it’s layered competence

The container world in 2023 rewards people who can describe the stack accurately. Docker Compose was a great starting point, but it shouldn’t be your endpoint. Podman changes privilege assumptions with rootless execution. containerd anchors Kubernetes runtime behavior. BuildKit modernizes image building as a performance and reliability tool. And the unbundling of the ecosystem means you must understand the layers to secure and optimize your systems.

If you want to be a better infrastructure engineer, don’t fight the abstraction—learn what it hides. Then build with intention.

Drizzle ORM: SQL for People Who Actually Like SQL

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 19 Oct 2023 00:00:00 +0000

If you’ve ever sworn off ORMs after fighting “magic” query builders, you’re not alone. Many tools treat SQL as an implementation detail—something you’re supposed to forget. Drizzle ORM takes the opposite stance: it assumes you want SQL, then adds the TypeScript safety you came for. The result is an ORM that feels less like a translation layer and more like a typed extension of your existing habits.

SQL-first, not SQL-avoidant

Most ORMs try to win you over with abstraction: models, relations, and a query API that claims to be “better” than SQL. But if you’re already thinking in joins, aggregations, and explicit where-clauses, that abstraction often becomes a second language you must constantly relearn.

Drizzle’s philosophy is refreshingly direct: the query builder is deliberately shaped like SQL. That means:

select, insert, update, and delete map cleanly to SQL concepts.
Expressions look like the SQL you’d write by hand.
Joins are modeled explicitly instead of being hidden behind implicit relation magic.

In practice, this matters when you’re debugging. When a query returns unexpected results, you can read the builder code and recognize the SQL structure immediately—because it’s built from SQL-shaped primitives, not an opaque DSL.

Here’s a small taste of that “reads like SQL” feel:

const results = await db
 .select()
 .from(users)
 .where(eq(users.email, email));

No guessing what “eq” does, no wondering whether the tool silently rewrites your query in a surprising way. If you know SQL, you can navigate Drizzle.

TypeScript inference that doesn’t fight you

The real selling point of any TypeScript ORM isn’t just code completion—it’s type-driven correctness. Drizzle focuses on making types flow from your schema into your queries, so you get feedback at development time rather than at runtime.

When you structure queries in a SQL-aligned way, TypeScript can infer what the result should look like. That unlocks a practical workflow:

Write a query that matches how you’d do it in SQL.
Let the type system validate shape and fields.
Avoid accidental field mismatches or mis-typed parameters.

For example, assume a schema roughly like:

users(id, email, name, createdAt)
posts(id, userId, title, createdAt)

A relational query becomes readable and type-safe:

const posts = await db
 .select({
 title: posts.title,
 authorEmail: users.email,
 })
 .from(posts)
 .innerJoin(users, eq(posts.userId, users.id))
 .where(gt(posts.createdAt, since));

Notice what’s happening: you’re explicitly choosing output fields and joining conditions. That’s SQL thinking. And because the output is declared, TypeScript can infer the returned object shape so you don’t end up dereferencing fields that don’t exist.

This is the sweet spot: Drizzle doesn’t make you abandon SQL; it makes SQL safer.

Relational queries that stay readable at scale

Joins are where many ORMs either shine—or collapse into unreadable abstractions. Drizzle keeps joins explicit, which is a big deal once your queries stop being toy examples.

Consider a common “feed” query: fetch recent posts with author info, filter by author, and order by recency. With SQL-shaped constructs, you can keep it structured:

const feed = await db
 .select({
 postId: posts.id,
 title: posts.title,
 authorName: users.name,
 authorEmail: users.email,
 createdAt: posts.createdAt,
 })
 .from(posts)
 .innerJoin(users, eq(posts.userId, users.id))
 .where(eq(posts.userId, authorId))
 .orderBy(desc(posts.createdAt))
 .limit(limit);

If you’ve written SQL before, you’ll recognize every clause. If you haven’t, you still get a consistent pattern. That predictability reduces cognitive load—especially when team members rotate or when you revisit code months later.

Practical advice: treat your query builder code like SQL you’d be proud to review. Keep joins explicit, name your selected fields intentionally, and avoid building huge queries by accident. If the query becomes complex, break it into subqueries or stepwise operations (with clear comments), the same way you’d do in hand-written SQL.

Migrations: the boring part you actually want done well

No one writes migrations because they’re fun. We write them because production needs change management. Drizzle’s migration story keeps schema evolution part of the normal developer workflow—without turning it into a separate universe.

You define tables and relationships in code, then generate migrations from that source of truth. That aligns with how SQL developers already think: schema changes should be inspectable, reviewable, and repeatable.

A practical workflow looks like this:

Update your Drizzle schema definitions.
Generate a migration.
Review the migration SQL (yes, review it).
Apply it in dev/staging; only then promote to production.

That last step is where SQL-first tools win. You’re not surrendering visibility. When something goes wrong, you can trace it to an explicit change you can read.

Edge runtime friendly: less infrastructure, more focus

One of Drizzle’s underappreciated advantages is that it’s built to work broadly, including edge runtimes. The reason matters: you don’t need a separate “binary engine” process sitting between your app and the database. That reduces operational friction and makes deployment more portable.

If you’re building Next.js or similar apps and you want your data access layer to run where your code runs, this is a concrete advantage—not a marketing bullet. It keeps your architecture simpler: fewer moving parts, fewer environment-specific surprises.

Practical advice: when targeting edge, pay attention to connection handling and how you configure your database driver. The ORM won’t save you from runtime constraints, but a leaner setup does mean fewer platform-specific gotchas.

When Drizzle is the right choice—and when it isn’t

Drizzle is best for teams that:

think in SQL already (or want to, and don’t want to be punished for it),
value TypeScript inference for correctness,
want explicit joins and predictable query shape,
prefer readable code over opaque magic.

It’s not ideal if your team’s goal is “never think about SQL.” If you want to model everything as a purely object-oriented graph and avoid joins entirely, an ORM that treats SQL as an implementation detail may feel more comfortable. But you’ll likely trade away transparency exactly when your queries get interesting.

A more honest way to put it: Drizzle rewards developers who enjoy understanding their queries. If you’re the kind of person who writes WHERE clauses with intention, you’ll feel at home.

Conclusion: typed SQL you can trust

Drizzle ORM makes a compelling argument: you don’t need a new query language to get type safety. You need better alignment between your mental model (SQL) and your tooling (TypeScript inference, explicit relational queries, and migrations you can review).

SQL doesn’t have to be the old way. With Drizzle, it can be the right way—typed, maintainable, and readable enough that your future self won’t dread the next “why is this query slow?” moment.

The HTMX + Go Combination Is Absurdly Productive

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 14 Oct 2023 00:00:00 +0000

Web development loves to pretend it’s always reinventing the wheel, but the best stacks rarely feel “new”—they feel useful. The HTMX + Go combo is exactly that: server-rendered HTML from a compiled binary, with interactivity layered on through hypermedia instead of an entire JavaScript ecosystem. It’s the kind of setup that makes you ship faster, deploy simpler, and keep your sanity.

Why this pairing works (and why it’s not just “a hack”)

HTMX and Go share a core philosophy: treat the server as the source of truth and the browser as an intelligent viewer—not a separate universe. HTMX lets you define interactive behavior using HTML attributes like hx-get, hx-post, and hx-target. When something changes, the browser asks the server for a fragment of HTML and swaps it into the page.

Go, meanwhile, excels at building fast, reliable server processes. With html/template, you can render secure, composable HTML on the backend. Put differently:

Go renders HTML (full pages and fragments) from real data.
HTMX turns user actions into HTTP requests and swaps HTML responses into the DOM.
Your UI becomes a set of endpoints, not a client-side application that must be kept in sync forever.

This isn’t a fragile “server-rendering with training wheels” approach. It’s a straightforward hypermedia workflow that stays coherent as your product grows.

The development loop: less framework churn, more shipping

If you’ve built CRUD tools with modern frontend frameworks, you already know the pattern: you spend time wiring state management, handling loading/error states everywhere, and chasing version compatibility. Even when the app is simple, the ecosystem cost is real—node versions, dependency updates, build steps, and “why is this rerendering infinitely?” debugging.

With HTMX + Go, the loop becomes brutally direct:

Add a route in Go (e.g., POST /users).
Render a template or partial for the response.
Add an hx- attribute to the HTML element that should trigger the request.
Swap the response into the right part of the page.

A concrete example: inline user updates

Imagine an admin page listing users. Each row has a “Change role” dropdown and a “Save” button. With HTMX, you can make that feel interactive without building a SPA:

<tr>
 <td>{{.Name}}</td>
 <td>
 <select name="role" id="role-{{.ID}}">
 <option selected>{{.Role}}</option>
 <option>admin</option>
 <option>viewer</option>
 </select>
 </td>
 <td>
 <button
 hx-post="/admin/users/{{.ID}}/role"
 hx-target="#user-{{.ID}}"
 hx-swap="outerHTML">
 Save
 </button>
 </td>
</tr>

The server receives the POST, updates the role, and returns updated HTML for the row (or the whole table, if that’s simpler). No client-side state machine. No bespoke API client. No separate JSON-to-UI mapping layer.

The “absurdly productive” part isn’t just that it’s fast—it’s that the mental overhead stays low as features accumulate.

The deployment story: one binary, anywhere

This stack collapses your infrastructure surface area. Instead of a Node build step, a frontend artifact pipeline, and a backend service with two different runtimes, you ship one compiled Go binary.

That means:

No node_modules on the server.
No frontend build step in your CI/CD for every deploy.
Fewer runtime dependencies to lock down.
One container or one executable that runs the same way locally, in staging, and in production.

For internal tools—dashboards, operators’ consoles, back-office CRUD—this matters more than people admit. You’re not trying to impress a build pipeline. You’re trying to deploy reliably.

And because the UI is server-rendered, your “homepage” is not an empty skeleton waiting for JavaScript to finish booting. It’s HTML on first response. That makes behavior more predictable, especially under load or flaky networks.

Performance: concurrency without contortions

There’s a temptation to equate “server-rendered HTML” with “slow.” In practice, with Go and HTMX, performance is often better than you’d expect for this class of apps—because you’re not asking the client to load and execute a heavy UI bundle, and you’re not shipping a ton of client logic just to do form posts.

HTMX interaction is also inherently incremental. If a button click only needs to refresh one component, your request can return a targeted fragment, not an entire application state dump.

Practical tips to keep things snappy:

Render fragments intentionally: use hx-target and return HTML that matches the target’s structure.
Avoid chatty endpoints: if multiple fields need validation feedback, consider returning a chunk containing all messages at once.
Cache what’s stable: for pages where parts don’t change often (e.g., navigation, reference data), reuse computed fragments or templates where appropriate.
Keep templates composable: template.ParseFiles / template definitions let you reuse markup and avoid copy-paste bloat.

The big win is that you can move fast without turning performance into a rewrite later. The architecture supports incremental improvements instead of forcing a “done when it’s done” SPA optimization scramble.

UX without a JavaScript framework: it’s still modern

“Interactive without JavaScript” sounds like a limitation until you use it. HTMX gives you the tools to create real UX flows using plain HTML:

Submit forms asynchronously (hx-post, hx-put)
Replace parts of the page (hx-swap)
Trigger requests on events (hx-trigger)
Show confirmations or incremental prompts
Validate and re-render server-side error states

Error handling that actually works

In a traditional API + frontend setup, form errors are often treated as a second system: the server returns JSON, the client maps it to UI, and everything can desync. With server-rendered templates, error states are just another HTML response.

For instance, if POST /admin/users/:id/role fails validation, your handler can render the same fragment with error messages included. The browser swaps it into place and the user stays in context.

That’s “modern UX” in the most practical sense: predictable feedback, fewer edge cases, and fewer moving parts.

When you should (and shouldn’t) choose this stack

This combination is ideal for:

Internal tools (admin panels, operations consoles, dashboards)
CRUD-heavy applications (users, records, approvals, workflows)
Form-centric products (multi-step data entry, review screens)
Projects where speed-to-ship beats “maximal interactivity”

You should be more cautious when you need:

Highly complex client-side state and animation (think spreadsheet-grade interactions)
Real-time collaborative editing with heavy synchronization logic
Offline-first experiences where the client must function without server access

Even then, you can often still use HTMX for the majority of pages and reserve specialized client-side code for the handful of truly interactive screens. The point is not purity; it’s momentum.

Conclusion: the simplest architecture that keeps winning

HTMX + Go is absurdly productive because it removes the two biggest sources of friction in typical web development: the client framework ecosystem and the state synchronization burden it creates. You render HTML where it belongs, make interactions HTTP-driven, and ship a single compiled binary that deploys anywhere.

If you’re building an internal tool or a CRUD application and you want to stop wrestling with frontend churn, this is one of the rare stacks that makes “fast to develop” and “fast to deploy” feel like the same thing.

The JavaScript Build Tool Graveyard: A History of Things We Overcomplicated

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 07 Oct 2023 00:00:00 +0000

For a decade, JavaScript developers haven’t just built apps—we’ve built build systems. And then, inevitably, we tore them down. Grunt, Gulp, Webpack, then more layers around Webpack, and now Vite and esbuild: each new tool arrives with the same pitch—this one will finally fix complexity. The joke is that the promise never really changes. The real lesson is staring us in the face: we keep optimizing the wrong thing.

The recurring villain: complexity you have to configure

The story usually starts the same way. A team wants “modern tooling,” which quickly becomes “a build pipeline.” The pipeline needs bundling, transpilation, minification, CSS handling, image optimization, environment variables, live reload, testing integration, linting, type checking, and a development server that won’t make you scream.

So the team picks a tool.

Grunt arrives with task runners and a declarative config file that feels like control.
Gulp arrives with streams and a sense of speed—write JavaScript instead of YAML.
Webpack arrives with a graph-centric worldview: everything becomes a dependency graph, so how could it ever be messy?
Then the ecosystem grows: plugins, loaders, presets, dev server wrappers, custom scripts, and “just one more config tweak.”
Eventually, Vite and esbuild show up: fewer layers, faster startup, less ceremony.

But notice the through-line. Every generation claims to reduce complexity, yet complexity reappears in a new costume. You don’t eliminate build complexity—you relocate it.

In practice, that relocation often looks like this: the build script you just simplified now lives in a different place. Webpack complexity moves into loader/plugin choices. Gulp complexity moves into stream piping and edge cases. The “modern” tool replaces one set of configuration problems with another.

Grunt to Gulp: when “automation” turned into another job

Grunt’s appeal was obvious: it offered a structured way to run tasks. If your build process was a series of commands, Grunt gave you a place to orchestrate them—minify, compile, copy, watch. The configuration style was friendly to people who wanted “knobs” and predictable execution.

Then Gulp arrived and asked a tempting question: why not write the pipeline in JavaScript? Gulp’s stream-based approach felt more flexible, more “real code,” and easier to customize.

Here’s the practical reality both tools eventually hit: once your build steps include branching logic, conditional environments, cross-platform path handling, and watch mode quirks, your build file becomes a mini application. It needs testing. It needs documentation. It needs someone to understand why task ordering matters.

Even “simple” things become surprisingly political. Example: suppose you copy static assets from src/assets to dist/assets. In Grunt, that’s a task config. In Gulp, it’s a pipeline stage. In both cases, you eventually discover a subtle bug where assets are copied before compilation finishes—or overwritten by a later step.

The build step isn’t just glue. It becomes the system.

Webpack: the promise of a single tool, the birth of an ecosystem

Webpack’s genius was conceptual: treat your project as a dependency graph and let the bundler do the heavy lifting. For many teams, it replaced a mess of scripts and task runners with one coherent engine. You could express “what depends on what,” and webpack would figure out the order.

But the moment you introduce a graph-based bundler, you also introduce a new class of complexity: the boundary between “source code” and “build-time transformation.”

Webpack is where transformation lives—transpiling, bundling, injecting globals, handling CSS modules, rewriting URLs, optimizing production output, and dealing with runtime differences. To make all of that possible, webpack leaned into loaders and plugins.

Loaders are where projects tend to sprawl. A team starts with babel-loader and a CSS loader. Then they need special handling for images, fonts, SVGs, and environment-specific config. Soon, you’re juggling a lineup of loaders and plugin combinations, each with its own failure modes.

This is the hidden cost of an ecosystem model: the upgrade path becomes part of your build tooling. A team doesn’t just upgrade dependencies; they upgrade a delicate choreography of plugins that may not change together.

Webpack also encouraged “everything in the bundle” thinking. That’s sensible until your bundle starts acting like a second product: performance tuning, chunk splitting, caching strategies, and “why is this module duplicated” mysteries.

It worked. It also taught teams a habit: treat configuration complexity as an acceptable tax for shipping. Once you accept that tax, it grows.

The modern shift: Vite, esbuild, and the appeal of fewer layers

Vite’s pitch is brutally practical: don’t do work you don’t need. During development, it avoids the full bundling pipeline and leans on native module support (plus smart transforms). In production, it can still build optimized output, but the key idea is to keep the dev loop lean.

esbuild takes the “do the minimum work fast” philosophy even further. Where webpack is built around the bundling graph and transformation pipeline, esbuild is built for speed and simplicity in transformation. It’s the opposite of “we’ll solve everything with a single heavyweight system.” It tries to solve the hot path: turning modern syntax into something your runtime understands.

What changes psychologically is the shape of the project:

Instead of a build system that dominates the repository, you get a smaller set of build responsibilities.
Instead of a build config that feels like infrastructure code, you get a build config that feels like setup.

You still need tooling. Linting doesn’t disappear. Testing doesn’t disappear. You still need bundling for many deployment targets. But the closer you get to native ESM in browsers and Node.js, the less you have to fake the module system with elaborate bundling and shimming.

And that’s the deeper point: modern tools aren’t just “better versions of webpack.” They’re concessions to reality—ESM support, improved runtime compatibility, and the desire to make development feel like editing, not waiting.

The uncomfortable conclusion: the build step is the problem

It’s fashionable to blame tools. “Webpack is too complex.” “Gulp was hard to debug.” “Grunt felt too rigid.” Those complaints are often real. But the recurring behavior is the same: the build step becomes a place where we hide mismatches between how code runs and how code is authored.

The build step grows because we insist on creating a universal runtime story out of limited one-size-fits-all assumptions:

Browsers don’t always support the exact syntax we like.
Node and browsers don’t always agree on module formats.
APIs differ across environments.
Performance constraints push us toward bundling and chunking strategies.
Teams want the same local workflow for everything, including deployment differences.

Every time you add a mismatch, you add a transformation. Every transformation introduces edge cases, configuration, and integration surface.

So the build system isn’t merely a tool chain—it’s a patch. And patches accumulate.

The more aggressively you pursue “shipping without a build step,” the more you force the ecosystem to meet you where you are. Native ESM, import maps (where appropriate), consistent module formats, and runtime-aligned development patterns reduce the need for heavy transformation.

You don’t have to go all-in on “no build ever.” But you should treat the build step as a last resort, not a default lifestyle.

Practical guidance: designing a toolchain that won’t rot

If you’re starting fresh—or rescuing an existing project—here’s what I’d do, opinionated and practical:

Separate dev workflow from production bundling.
The dev experience should be fast and predictable. Production can be more involved. Tools like Vite exist because development should not pay the full cost of production bundling every time you save a file.
Minimize transformation.
If you don’t need to transpile, don’t. If you can target modern runtimes, do. Every transformation stage is a future maintenance obligation.
Keep configuration close to intent.
If a config file becomes a program—with lots of custom logic—refactor it into fewer, well-understood conventions. “A messy but centralized webpack config” often becomes “a specialized snowflake build system.”
Prefer fewer plugins, fewer loaders, and simpler graphs.
If you can replace a plugin chain with a single supported option or a smaller set of tools, do it. The goal is not minimal dependencies; it’s reduced integration complexity.
Treat upgrades as part of engineering, not a surprise.
Pin what you must, update intentionally, and document why you chose each piece. The “graveyard” isn’t just tools—it’s teams who upgraded without understanding the coupling.
Align runtime with authoring.
Use the module formats your runtime actually supports. Target modern environments when you can. If your code and deployment target speak the same language, your build step shrinks.
Measure the real pain: build time and debugging time, not just “tool popularity.”
A tool can be “modern” and still slow your loop or make errors harder to interpret. Optimize for your team’s daily friction.

If you follow these rules, you won’t avoid build steps entirely—but you’ll avoid the specific trap that created the graveyard: treating build tooling as an endless arms race.

Conclusion: fewer steps, fewer excuses

The JavaScript build tool graveyard is less about tool choice and more about a recurring self-inflicted wound: we keep trying to solve the complexity created by the build step using more elaborate build steps. Grunt to Gulp to Webpack to Vite reflects the same emotional loop—the old way is too hard; the new tool will simplify everything. Sometimes it does. Often it just moves the complexity.

The path forward is to reduce the need for transformation and embrace native module realities where possible. The best build system is the one that doesn’t have to do much.

You Should Be Pair Programming with AI, Not Copy-Pasting from It

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 25 Sep 2023 00:00:00 +0000

It’s tempting to treat an LLM like a search engine with amnesia: paste your prompt, grab the answer, move on. But that workflow—copy, paste, hope—quietly drains your engineering judgment. If you want better code, faster, you need to change how you use AI: don’t outsource thinking. Pair with it.

Most developers are using ChatGPT like Stack Overflow: “Here’s my problem. Here’s your solution.” The result is brittle code, mismatched architecture, and a growing sense that you’re shipping faster without actually getting better. The fix is not a new model or a magic prompt. It’s an iterative collaboration style—AI as a thought partner, not a clipboard.

Stop Treating the LLM Like a Clipboard

Copy-pasting an AI-generated snippet feels productive because it’s immediate. You get code without the tedium. But it’s also exactly how bugs multiply: you accept an answer before you understand its assumptions.

Here’s a typical pattern:

You paste an error message and a vague description.
The model returns a polished-looking solution.
You integrate it quickly.
Then you discover edge cases, security issues, performance regressions, or architectural mismatch.

When you copy-paste, you rarely get to ask the most important questions:

Why is this the right approach?
What trade-offs are being made?
What failure modes should I plan for?
How does this fit into my system’s constraints?

The model can’t optimize for your production reality if you never interrogate it. And you can’t improve your own judgment if you never practice decision-making.

Use AI Like a Pair Programmer: Dialogue Over Dumping

Pair programming has a rhythm: you explain what you’re doing, your partner questions it, you adjust, and you converge. An LLM can mimic that rhythm—if you give it the context and the permission to critique.

The key difference is input shape. Instead of sending a problem and asking for “the answer,” you send:

Your architecture (or the piece you’re working on)
Your constraints (latency, scaling, data model, security requirements)
Your current approach (even if it’s rough)
Your questions (what you want challenged)
Your acceptance criteria (what “good” looks like)

Think of your prompt as a mini design doc plus a review request. Then run an iteration loop:

Ask it to critique.
Challenge its suggestions.
Request alternatives.
Synthesize a final plan.
Only then ask for code.

That’s how you avoid the “snippet spiral,” where each pasted chunk introduces new unknowns.

A Practical Workflow: Critique, Counter-Example, Alternative

Let’s make this concrete with a common engineering task: implementing an API endpoint that performs a database-backed search.

Bad use: “Paste code”

You might do something like:
“Write a Node.js endpoint to search products by keyword. Use SQL.”

The model responds with a plausible implementation. You paste it. It compiles. Then your logs tell you it’s slow, ignores indexing strategy, and mishandles special characters.

Better use: “Pair and pressure test”

Instead, start with context:

We have a PostgreSQL table products(id, name, description, updated_at). We need a /search endpoint. Constraints: response under 200ms at p95 for common queries, must be SQL-injection safe, and we must support pagination with stable ordering. Current plan: use ILIKE on name and description, paginate by updated_at DESC, id DESC. Critique this plan: performance risks, correctness risks, and edge cases. Suggest at least two alternatives and tell me when each alternative wins.

Now the model is forced to reason about trade-offs. You can further challenge it:

Counter-argument: We can’t deploy a full text search engine right now. Can you propose a low-risk incremental approach that improves latency using only Postgres features we already have? Also, what indices would you add, and what query shape would you use?

Only after you’ve locked the approach, you ask for implementation:

Given the chosen approach, write the query and the endpoint code. Follow these acceptance criteria: parameterized queries only, deterministic pagination, and explain how it prevents injection and how it handles empty search terms.

This workflow turns AI into a reviewer who cares about your specific system, not a random code generator.

Prompt Like You’re Designing: Provide Inputs, Ask for Evaluation

Quality prompts aren’t “more text.” They’re better structure. Aim for prompts that force the model into roles:

Architect: “Propose a design that meets these constraints.”
Reviewer: “Critique for correctness, security, and performance.”
Skeptic: “What would break in production? Where are the hidden assumptions?”
Planner: “What are the next steps and tests I should write?”
Opponent: “Argue against your own solution.”

Also, give the model acceptance criteria. Vague instructions produce vague code. Concrete criteria produce usable outcomes.

For example, instead of:

“Make it fast.”

Use:

“Benchmark expectation: keep the query under 150ms for queries containing 3+ keywords; add an index plan; avoid leading wildcards.”

Instead of:

“Secure it.”

Use:

“No dynamic SQL string concatenation; validate inputs; use parameter binding; discuss how the approach handles UTF-8 and user-supplied wildcards.”

Then—critically—ask for failure modes:

List the top five production failure modes for this design and how we’d detect and mitigate them.

That single line changes everything. It nudges the model away from “it works on my machine” and toward operational thinking.

Generate Alternatives, Then Synthesize—Don’t Choose the First Answer

One reason copy-pasting works “well enough” is that the first solution often looks reasonable. The danger is that you’re accepting a single point of view—usually the model’s default.

A better approach is to explicitly request multiple strategies and then decide.

Try a prompt like:

Provide three alternative designs for this feature. For each: pros, cons, complexity, risks, and what I should test in staging. Assume we have limited time for refactors.

Then you synthesize:

Based on our constraints (X, Y, Z), I’m choosing design B. Explain any remaining risks and suggest a test plan to validate it.

This “alternatives → decision → verification” cycle is the core of engineering. AI shouldn’t replace it—it should accelerate it.

Treat AI Code as a Draft That Must Earn Its Place

Even with excellent prompting, LLM output is still a draft. The goal is not to eliminate manual work; it’s to make the manual work smarter.

So, when you request code, also request guardrails:

Invariants: “List invariants the code must maintain.”
Edge cases: “Handle empty inputs, pagination boundaries, and null values.”
Tests: “Generate unit tests and integration tests for the failure modes you identified.”
Complexity: “Explain time/space complexity and how it behaves under load.”

Then do the final step: review like you’d review a junior engineer’s PR. You’re looking for clarity, correctness, and fit—not for “looks right.”

A useful mental model: AI can help you write faster, but you’re responsible for thinking faster. Pairing enforces that division of labor.

Conclusion: AI as a Thought Partner Makes You a Better Engineer

If you use AI like a clipboard, you’ll ship code that you didn’t truly evaluate. If you use AI like a pair programmer—iterating on architecture, challenging assumptions, generating alternatives, and validating with tests—you’ll ship code you actually understand.

The best part is that this approach compounds. Every critique you force out of the model becomes a pattern you can apply later—whether or not you’re using AI.

The Postgres Extensions That Make Every Other Database Jealous

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 13 Sep 2023 00:00:00 +0000

Every time a project needs “just one more database,” the stack quietly grows teeth: a separate search engine, a dedicated time-series store, a geospatial platform, a job scheduler, maybe even a vector database. It’s not that those systems are bad—it’s that they’re optional. PostgreSQL is the ecosystem with a secret weapon: extensions. And if you choose the right ones, you can keep the operational surface area small without giving up capability.

The real question isn’t “Do we need another database?” It’s: can PostgreSQL do it via an extension? In my experience, the answer is often yes—especially when the “missing feature” is one of the big modern categories: vectors, geospatial, time-series, scheduling, or horizontal scale.

Why Extensions Beat “Add Another Database”

PostgreSQL extensions aren’t just add-ons; they’re a philosophy. Instead of moving data between systems, you keep it in one place and let specialized features live inside the same engine, same transactions, same security model, same query planner.

That matters because most production pain isn’t theoretical—it’s operational:

Multiple databases mean multiple backup/restore paths, monitoring, upgrade cycles, and failure modes.
Data duplication means eventual consistency bugs and messy synchronization jobs.
Cross-system queries often become application-layer glue, which is where correctness goes to die.

Extensions change the equation. You still deploy one database, but you can teach it new skills. When it works, the payoff is huge: fewer moving parts, simpler governance, and simpler developer experience.

So when someone proposes a specialty database, I ask a blunt follow-up: “What exactly are we adding, and can Postgres do that natively via an extension?” Most of the time, the answer is surprisingly straightforward.

pgvector: Make Your Relevance Engine a Postgres Query

If your app needs semantic search, recommendations, or retrieval-augmented generation (RAG), you’re in “embeddings land.” The typical approach is to reach for a vector database. But PostgreSQL can host vectors just fine—using pgvector.

A practical way to think about it: your embeddings don’t have to live in a separate product category. They can live alongside the rest of your data—products, documents, users, permissions—so your similarity search becomes part of the same query that enforces business rules.

Example pattern:

Store an embedding vector for each document.
When a user searches, compute a query embedding.
Run a SELECT that ranks documents by vector similarity—and filters by tenant, access level, language, or recency.

That last part is the killer feature. In a vector-only system, access control often becomes a post-filtering step, which can quietly ruin both ranking quality and latency. In Postgres, filtering and ranking can be combined so the engine does the work.

Even if you’re not building full RAG yet, pgvector helps you avoid a common trap: treating embeddings as a separate universe. Keep them in Postgres and you can evolve from “semantic search” to “semantic search + transactional features” without rewriting your data model.

Practical advice: Treat embeddings like any other field with lifecycle needs. Plan for re-embedding when your model changes, and version your embeddings (e.g., embedding_model_version) so you can run migrations safely.

PostGIS: Geospatial Without the Geospatial Stack

Geospatial workloads have a long history of attracting special-purpose databases. That’s reasonable—until you realize you can do a lot of serious geo work in Postgres.

PostGIS is the industry standard for a reason: it’s mature, expressive, and designed for spatial querying and indexing.

The key advantage isn’t just that PostGIS can store coordinates. It’s that it can answer spatial questions like they’re first-class:

“Which delivery zones intersect this polygon?”
“Which warehouses are within 10 km of this address?”
“Are these two geometries touching, overlapping, or disjoint?”
“Return nearest points, but only inside allowed regions.”

In practice, that means you can keep your “geo logic” in SQL with real indexes, instead of pushing it into application code or a separate geospatial service.

Concrete example: Suppose you’re building an admin console for service areas. You likely need to validate boundaries, compute intersections, and generate “coverage maps.” With PostGIS, those operations can run directly over your canonical geometry tables. You avoid building a second source of truth just for maps.

Practical advice: Don’t wait until you have a performance problem to design spatial indexes. Use the right geometry types and SRIDs consistently, and index the columns you’ll query with distance or containment patterns.

TimescaleDB: Time-Series Features Where You Already Store Everything

Time-series is another category that tends to pull in dedicated databases—because it’s tempting to think in terms of specialized storage. But if your app already uses Postgres as the system of record, you may not need to leave it.

TimescaleDB adds time-series capabilities to Postgres, notably the kind of partitioning and query optimizations that make time-series practical without turning your architecture into spaghetti.

Where this pays off:

Metrics and events tied to your domain entities (users, devices, accounts).
Operational telemetry that you want to query alongside relational data.
Retention and downsampling policies that you can manage without bespoke tooling.

A common “gotcha” with time-series splits is that you end up with mismatched identifiers: your device registry lives in Postgres, but your metrics live elsewhere. Queries become two-step workflows—fetch IDs from one system, then query the other—and you introduce synchronization logic that never fully disappears.

With TimescaleDB, you can store both relational data and time-series samples together, then join when it matters.

Practical advice: Model your hypertables thoughtfully—choose the right time column, understand your cardinality, and set retention/compression policies early. Time-series schema changes are rarely fun after you’ve shipped.

pg_cron: Scheduled Jobs That Don’t Need Another Service

At some point, every system needs scheduling: periodic cleanup, batch processing, notifications, reindexing, refreshing aggregates, calling external APIs, rotating keys, exporting reports.

The usual response is to bolt on a scheduler service or rely on an external cron environment. But PostgreSQL can schedule tasks internally with pg_cron.

That shifts work from “some machine somewhere runs cron” to “the database owns the schedule.” It’s a cleaner separation of responsibilities when you’re operating a managed environment or you want tight coupling between job execution and database state.

Example uses:

Nightly recomputation of search rankings or materialized views.
Periodic expiration of stale records.
Scheduled maintenance of derived tables for dashboard speed.
Controlled batch writes for ETL jobs that must be consistent with transactional data.

The point isn’t that pg_cron replaces every job system—workflow orchestration still belongs somewhere else. It’s that simple, database-adjacent scheduling is often best kept close to the data.

Practical advice: Keep scheduled jobs idempotent. Assume retries. And log job activity so you can answer “what ran, when, and why it failed” without spelunking across systems.

Horizontal Scaling: When You Need It, Still Consider Postgres

Not every scaling problem is solvable with an extension, but some are. When you need to distribute data across nodes—typically for high write throughput or multi-tenant scale—Citus is the extension that often steps in.

The value here is strategic: you keep the PostgreSQL programming model while enabling distribution patterns. Developers don’t have to relearn query language semantics or build cross-database aggregation layers just to scale out.

If you’re evaluating whether to adopt another distributed database, the right framing is: are we replacing PostgreSQL because we can’t scale it, or because we didn’t try scaling it in the way PostgreSQL supports? Citus is one of the best “try Postgres first” answers.

Practical advice: Distribution is not a magic trick. Get your sharding key strategy right early, and test cross-shard query patterns. Distributed databases reward discipline.

A Modern “Postgres First” Architecture Checklist

Here’s the rule I use to prevent database sprawl from turning into long-term drag:

Vector search? Try pgvector before committing to a separate vector database.
Geospatial? Use PostGIS and keep geo logic close to the data model.
Time-series? Add TimescaleDB when your “time” data is part of the same domain as everything else.
Scheduling? Use pg_cron for database-owned periodic tasks.
Need scale-out distribution? Evaluate Citus rather than switching engines on day one.
If you still need another system, make it for a reason Postgres can’t solve—not because the stack template says you should.

This isn’t about ideology. It’s about minimizing complexity while keeping capability. PostgreSQL’s extension ecosystem lets you expand without abandoning the foundation.

Conclusion: Fewer Databases, Better Decisions

Specialty databases can be excellent tools—but they come with costs: more infrastructure, more integration work, and more places for correctness to drift. The best engineering decision is often the one that preserves simplicity while increasing power.

When your “missing feature” falls into vectors, geospatial, time-series, scheduling, or distributed scale, there’s a good chance PostgreSQL already has an extension for it. The next time someone proposes adding a new database, don’t argue—ask the more productive question: can this be a Postgres extension problem instead?

Passkeys Will Kill Passwords and It Can't Happen Fast Enough

abdecastro@protonmail.com (Antonio B De Castro) — Fri, 08 Sep 2023 00:00:00 +0000

Passwords are the worst authentication mechanism—except for every other option we’ve tried. They’re memorable, but they’re also phishable, reusable, and constantly mishandled. And even when users do everything “right,” attackers still have a playbook: trick them, capture the secret, and ride it to account takeover.

Passkeys—FIDO2 credentials stored in platform authenticators—remove the secret from the equation. That change isn’t incremental. It’s structural. And it’s finally making phishing-resistant authentication the default experience users get without thinking.

Why passwords keep losing (even when everyone agrees they’re bad)

Let’s be blunt: passwords don’t fail because users are careless. They fail because the threat model is stacked against them.

Phishing turns passwords into a one-time ticket for criminals. Even perfect password habits don’t stop a user from being tricked into entering their secret into a fake login page. And once the attacker has a working password, the rest is easy: automated retries, credential stuffing, session hijacking attempts, and the same “you were logged in” patterns that still dominate modern account takeover workflows.

Then there’s operational reality. Many breaches don’t involve “breaking encryption.” They involve mishandled secrets: leaked databases, weak password storage practices, credential reuse across services, and reset flows that become attack surfaces. Even with salted hashes (and even when you do everything correctly), the fact remains that passwords are an attractive target.

Passwords also produce a UI/UX bargain that attackers exploit. Users type secrets. Attackers ask for them. Humans are predictable. Every time you build a login form, you’re building a stage for social engineering.

Passkeys change the game: no secret to steal, no password to reuse

Passkeys are FIDO2 credentials—typically bound to your device or platform authenticator—that authenticate using public-key cryptography. The key point is what doesn’t exist anymore:

No password to phish. There’s nothing for a malicious page to trick a user into typing.
No credential to “stuff.” Attackers can’t replay a captured secret because the authentication response is generated in context and typically protected by hardware-backed signing.
No reusable shared secret to exfiltrate from a database. What you store server-side isn’t a password-equivalent secret waiting to be abused.

In practice, the flow looks different from password login:

The server sends a challenge tied to the specific site and session.
The user triggers a platform authenticator (biometric prompt, device PIN, or secure element approval).
The device signs the challenge with the credential private key.
The server verifies the signature using the corresponding public key.

This is more than “stronger passwords.” It’s a different mechanism with a different failure mode.

And importantly: because passkeys are designed for the web with WebAuthn, they can be implemented without a proprietary client app. The UX is also finally competitive: a biometric or device prompt that’s often quicker than typing.

The real reason passkeys work: phishing resistance by design

A lot of security advice boils down to “be smarter than the attacker.” Passkeys are smarter than the attacker—at least for the phishing scenario that accounts for so much real-world trouble.

Phishing usually relies on two weaknesses:

The victim is convinced to enter credentials into a malicious site.
The attacker’s site proxies or reuses that credential against the real service.

Passkeys break the first step because the “credential” is not something a web page can harvest through text entry. The second step breaks because authentication is tied to the relying party (the real site origin) and produces a response that can’t be simply replayed elsewhere.

To make this concrete, imagine a fake login page for your fintech app. Under a password model, the attacker just asks for username and password and then forwards them. Under a passkey model, that fake page can’t trigger the right authenticator flow for the correct relying party in a way the server will accept. The user may see a prompt, but the cryptographic verification still only succeeds for the genuine site configuration.

Is the user still responsible for choosing the right button and device prompt? Yes. But the attacker can’t complete the job by collecting a reusable secret. That’s the crucial shift.

Platform authenticators and native support: the ecosystem finally arrived

Passkeys aren’t theoretical. They’re shipping across major platforms with native support from Apple, Google, and Microsoft. That matters because passkeys live or die by usability. If every deployment required custom client software or a clunky enrollment process, adoption would stall.

With platform authenticators, the “credential storage” problem is handled where it belongs: on-device, protected by OS-level security primitives. The user experiences it as a biometric prompt, often with familiar affordances like Face ID / Touch ID, device PIN, or an OS confirmation dialog.

From a developer’s standpoint, the biggest advantage is straightforward integration. You can implement WebAuthn-based passkey registration and authentication inside your existing web auth flow—then offer passkeys alongside passwords during transition. Users who already use password managers aren’t forced to abandon them overnight; they’re given an upgrade path.

The win is twofold:

Security improves immediately for users who adopt passkeys.
Your system becomes less dependent on brittle password workflows, like “forgot password” as a primary recovery path.

Practical rollout strategy: stop dragging your feet, but don’t brick your users

If you’re building authentication in 2023 and not supporting passkeys, you’re building yesterday’s security. But you still need to roll this out responsibly.

Here’s a pragmatic plan that avoids the common trap of “we flipped the switch and everything broke.”

1) Add passkey registration to the account settings flow

Make it obvious and low-friction. A button like “Add a passkey” paired with a clear explanation (“Use biometrics or your device to sign in—no password required”) goes a long way.

Don’t force an all-or-nothing migration. Offer passkeys as an alternative button or flow, then log outcomes so you can measure progress. The key is to make passkey usage the path of least resistance.

3) Treat account recovery as a first-class design problem

Recovery is where attackers often strike, especially when password resets are weak. Once passkeys are available, consider using them as part of the recovery story—at minimum, ensure recovery flows can’t be trivially abused and that they’re hardened against account enumeration.

4) Handle edge cases like lost devices and multi-device enrollment

Encourage users to create passkeys on more than one device (especially if your service is important). In UI terms, this can be as simple as letting them add multiple passkeys and showing which devices they’ve registered.

5) Plan telemetry and friction measurement

Track:

how many users have passkeys enrolled
how often passkey auth succeeds
where users drop off (registration errors, prompt cancellations, etc.)

Security wins mean nothing if the UX collapses. Measure it, iterate it, improve it.

The password retirement plan: make it optional, then make it obsolete

The goal isn’t “ban passwords tomorrow.” The goal is to make passwords progressively irrelevant.

Start by positioning passkeys as the modern default:

If a user has a passkey, offer sign-in with passkey prominently.
If not, allow password login but make passkey enrollment part of the account experience (“Secure your account with a passkey”).
After you see meaningful adoption, reduce password reliance: consider rate limits, stronger recovery requirements, and clearer warnings around risky login behavior.

You’ll notice something as usage grows: your support queues change. Fewer “I got phished” and “my credentials were stolen” incidents. More “I lost my phone” issues—which are manageable when recovery is designed well.

Eventually, you’ll reach the stage where passwords are just a fallback. That’s the endgame.

Conclusion: Passkeys are the default security upgrade, and waiting costs you

Passwords aren’t just insecure—they’re structurally vulnerable to phishing and account takeover. Passkeys fix that by removing the phishable secret and binding authentication to the legitimate origin using cryptography and platform authenticators.

Adoption won’t happen fast enough if you treat it like a “someday” feature. The fastest way to improve your users’ security is to ship passkeys now: enroll them in settings, offer them on login, harden recovery, and then quietly let passwords fade into irrelevance. This is one of the rare security transitions that actually improves both protection and experience at the same time—and you should take it.

Biome Is the Linter/Formatter Combo That Will End the Prettier/ESLint Era

abdecastro@protonmail.com (Antonio B De Castro) — Fri, 01 Sep 2023 00:00:00 +0000

For years, JavaScript developers have accepted an annoying tax: two tools, two configs, and the constant possibility that they’ll disagree. ESLint worries about code quality; Prettier reshapes your style. In theory they’re complementary. In practice, teams end up with drift, duplicated rules, and a pipeline that feels heavier than it should. Biome changes the equation: one fast, Rust-based tool that both formats and lints—without you hand-tuning a peace treaty between systems that were never meant to work together.

The real problem: two tools, one codebase, endless edge cases

ESLint and Prettier solve different problems, but they create shared responsibilities:

ESLint enforces rules (style, correctness, best practices) and can also format in limited ways.
Prettier enforces formatting (whitespace, quotes, commas, indentation) and will reformat whatever it’s pointed at.

The friction starts when teams try to make those responsibilities overlap just enough to avoid conflicts. The common response is to configure ESLint with rules like “delegate formatting to Prettier,” disable stylistic rules, add plugins, and wire up both tools in scripts—often in a sequence that depends on file types, editor behavior, and CI.

Here’s what that looks like in real projects:

Developers run eslint locally and sometimes see issues that disappear after formatting.
Prettier changes code in ways that make an ESLint rule complain differently (or vice versa).
Teams accumulate “temporary” rules and overrides to quiet a specific case.
Migrations become multi-step: update dependencies, adjust configs, then revisit rules, then fix formatting diffs that show up everywhere.

This is not just inconvenience—it’s a DX tax. Every time formatting and linting are separate, you pay with complexity: more configuration, more tooling surface area, more chances for the editor to behave differently than CI, and more time watching diffs scroll by.

What Biome does differently: one pass for style and correctness

Biome is a single tool designed to be a formatter and linter in one. Conceptually, the win is simple:

Formatting isn’t an external “afterthought” step.
Linting isn’t blind to the formatting decisions that will be applied.
Configuration doesn’t need to coordinate two separate rule engines.

Practically, Biome aims for a workflow where running it is deterministic: the same input yields the same output, and both linting feedback and formatted code come from the same source of truth.

The result is a more cohesive developer experience. Instead of asking, “Should I run ESLint or Prettier first?” you just run one tool and move on. Instead of maintaining a brittle chain of config choices to prevent conflicts, you rely on one tool’s built-in philosophy about what good code looks like.

And yes—the speed matters. When a tool is fast enough, it changes how people work: formatting-before-commit becomes default behavior instead of a background chore. On large repositories, the difference is visceral—less time waiting, fewer context switches, and fewer “why is CI taking so long” conversations.

Migration: replacing a two-tool pipeline with one command

Most teams don’t want a rewrite. They want a swap.

Step 1: Install Biome and add a config

You add Biome to your dev dependencies and let it generate or adopt configuration. Biome supports formats and linting in a way that maps cleanly to typical expectations: you don’t need to invent a new governance process, you replace the enforcement engine.

Step 2: Start by wiring Biome into scripts

A straightforward migration typically looks like:

Run Biome in CI to ensure formatted code and lint rules are satisfied.
Optionally run Biome in a pre-commit hook for quick feedback.
Update developer scripts so local checks match CI.

Instead of eslint . and prettier --check . (plus whatever plugins and ignore rules make those behave), you run Biome and let it do both. The key benefit isn’t just fewer commands—it’s fewer mismatched behaviors.

Step 3: Accept and commit the formatting baseline

Your first Biome run will produce diffs. That’s normal, and it’s the point. Commit a clean formatting baseline so future diffs reflect real changes, not tooling churn.

A practical tip: do this as a single atomic commit (or a small number of commits) and communicate it clearly. Teams that treat migration diffs as background noise tend to lose trust in the toolchain. Treat it as “day one, reset the baseline,” and you’ll get cleaner downstream behavior.

Step 4: Lock in linting expectations

Then you tune linting to your preferences—without maintaining two different rule systems. If you currently have ESLint rules that exist only to prevent formatting chaos, expect them to disappear in the new world. If you relied on Prettier to control style, those decisions become part of Biome’s formatting pipeline.

The outcome: fewer “override files” and fewer “we had to disable that rule because Prettier changes it” conversations.

Editing and CI: making “works on my machine” less of a thing

A large part of the ESLint/Prettier era is the mismatch between:

Editor formatting (what happens when you save)
Local scripts (what you run manually)
CI checks (what gatekeepers enforce)

Even when teams “configure correctly,” these three can still drift due to plugin versions, extension settings, file globs, ignore rules, and ordering.

Biome’s value shows up when you make one tool authoritative:

If the editor uses Biome for formatting, your saved code matches the CI expectation.
If the same Biome config drives both lint and formatting checks, you avoid the “formatting passes but lint fails” loop.
If it runs quickly, teams actually enable it everywhere (pre-commit, CI, and—critically—editor save hooks).

A good target workflow is: save triggers formatting, and commits trigger lint + formatting checks. When everything is the same tool, you reduce the number of moving pieces that can disagree.

Performance is not a “nice to have”—it changes team behavior

The slogan “100x faster” is marketing unless you’ve felt the alternative. In practice, slower formatter/linter combos produce predictable habits:

Developers defer running formatting to “later.”
People skip linting locally and rely on CI.
Pre-commit hooks get disabled or weakened because they feel too slow.
Large diffs become painful because the feedback loop is sluggish.

Biome shifts the incentives. When checks are quick, teams tighten the loop: run checks more often, fix issues sooner, and stop treating linting as a gate you survive at the end of the day. You get less friction and more consistency—and because it’s one tool, you get fewer “why did that change?” mysteries.

On big monorepos, this matters even more. Toolchain overhead scales with the number of files and the number of times you run it. The best DX improvements aren’t always about adding features; sometimes they’re about removing the need to run two heavyweight passes across the same code. Biome’s approach is that removal made real.

Common concerns: “Will it match our existing standards?” and “What about rule parity?”

Migration anxiety is healthy. Teams should ask:

Will Biome format code in a way that matches our current style expectations?
Will our current ESLint rules translate cleanly?
Will we lose coverage?

The honest answer: you’ll want to evaluate it in your codebase. But the migration path usually benefits from the same observation that motivates Biome in the first place: if you’re currently maintaining two tools to approximate one consistent style, you already know your setup isn’t perfectly coherent.

A pragmatic plan:

Run Biome and review diffs to ensure formatting isn’t wildly surprising.
Port lint expectations incrementally—start broad, then tighten.
Measure trust: once developers see that Biome’s output is consistent and fixes issues quickly, adoption becomes easy.

If you truly require specific custom ESLint rule behavior, you’ll need to verify Biome’s lint coverage for those exact cases. But even when teams find one or two rule gaps, the overall direction remains compelling: fewer conflicts, less configuration complexity, and faster feedback loops.

Conclusion: one tool to enforce one standard

The Prettier/ESLint era wasn’t a mistake—it was a necessary compromise for a messy time in tooling. But the compromise is over. Biome offers a simpler model: one Rust-based tool that formats and lints together, producing consistent results with less configuration and dramatically faster feedback.

If your team is still juggling rule overrides, sequencing scripts to avoid conflicts, and watching formatting + lint diffs become background noise, it’s time to collapse the pipeline. The best DX upgrade isn’t another plugin. It’s fewer tools doing more correctly—faster—so developers can spend their attention on the code, not the toolchain.

Running LLMs Locally Changed How I Think About AI Privacy

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 20 Aug 2023 00:00:00 +0000

The first time I ran a local LLM on my MacBook, it didn’t feel like “AI development” so much as a privacy reality check. One minute I was tinkering with prompts. The next, I was reconsidering every AI feature I’d ever shipped—because the difference between “helpful assistant” and “data pipeline” stops being theoretical when your laptop can do the work.

If you build software that touches user data, you should run a model locally at least once. Not because it’s always the best option, but because it makes the tradeoffs painfully concrete.

What “local LLMs” actually mean (and why it matters)

A cloud LLM is a service: you send text, the model runs elsewhere, and your input becomes part of a larger system—logs, telemetry, retention policies, access controls, incident response, and (often) additional vendors in the chain. Local LLMs flip that architecture: the model runs on your machine, and the only network path is whatever you choose to create.

That distinction sounds obvious, but it’s easy to forget when you’re working at the product level. “We’ll send the user’s prompt to the model” becomes routine. “We’re now transferring potentially sensitive information to a third party” becomes a line item you may or may not revisit.

Running locally reframes the whole conversation. You stop thinking in vague terms like “privacy” and start thinking in operational terms: where does the text go, how long is it kept, who can access it, and what happens when something goes wrong.

My weekend experiment: capabilities without the data pipeline

I didn’t start with a grand plan. I just wanted to understand whether local models were usable for real development. Within an afternoon, I was able to:

chat with a model about code structure,
generate quick drafts for documentation,
do lightweight classification tasks (e.g., “is this a bug report or a feature request?”),
and sanity-check prompt behavior by iterating rapidly.

The key moment wasn’t that it was smarter than a cloud model—it wasn’t. It was that it was predictably constrained in a way I could observe. Context windows were limited. Outputs were slower. Some tasks required more prompting discipline. But crucially, I never had to route user-like text to a third party to test those behaviors.

I started imagining the same workflow inside a real product: “What if the user’s text is private by design?” “What if it’s regulated?” “What if the model’s failure mode leaks sensitive details?” With a local run, you feel these questions in your hands, not in policy documents.

The tradeoffs you can’t ignore: slower, smaller, and pickier

Local LLMs come with compromises. You’re replacing convenience and scale with control and proximity. That’s a good deal for some use cases—but it’s not a universal replacement for cloud inference.

Here are the tradeoffs I think developers should internalize early:

Performance and latency. Even on modern laptops, local inference can feel “glacial” compared to managed endpoints. That’s fine for editing support or internal tools, but it changes user experience expectations. If your AI feature is interactive and fast, you’ll need careful UX design (streaming outputs, optimistic UI, background processing, or smaller models).

Model capability and reliability. Smaller local models often require tighter prompting, fewer steps, and better constraints. They can be very helpful, but they’re also more likely to produce plausible nonsense than a stronger cloud model. That means you must treat them like an assistant, not a source of truth.

Setup friction. Local tooling varies. You’ll deal with model downloads, quantization choices, hardware limitations, and configuration quirks. This is where most teams stop experimenting—precisely because it’s inconvenient. But the effort is educational: it teaches you what “offline” really costs.

My advice: don’t use local models to pretend you don’t need engineering. Use them to develop intuition about constraints—because intuition becomes a design tool when you later decide what to send to the cloud.

How local models change your privacy decisions

This is the part that surprised me most. After running locally, I stopped asking only, “Is the provider trustworthy?” and started asking more precise questions:

1) What exactly are we transmitting?
In many apps, the “prompt” isn’t just a prompt—it’s user content, product context, or operational data. If you’re doing support chat, you might be transmitting message history. If you’re doing document analysis, you might be sending entire files. Local testing makes it easier to see what minimal text you could instead process on-device.

2) Are we building a data pipeline accidentally?
When teams integrate cloud LLMs, they often create hidden data flows: debug logs, replay tools, monitoring dashboards, and vendor telemetry. Local runs help you notice what can be kept local in the first place, and what you truly need to externalize.

3) What happens during failure modes?
Privacy isn’t only “where data goes when things are fine.” It’s what your system does when the model misunderstands, when users paste sensitive info unexpectedly, or when your prompt template accidentally includes extra context. With local models, you can repeatedly test those failure modes without depending on third-party handling.

4) Can we design for data minimization?
Once you’ve experienced local inference, you’ll be more willing to reduce the amount of text you send. Maybe you don’t need the full conversation—maybe you only need extracted fields. Maybe you can summarize locally and only transmit a structured, de-identified representation. Even if you still use the cloud for the final step, data minimization gets easier when you’ve built (and measured) the local alternative.

Practical ways to use local models in real workflows

You don’t need to replace your entire AI stack. You need a strategy that matches risk and effort. Here are concrete patterns that tend to work well:

Use local models for preprocessing.
If you have long documents, consider running local extraction or summarization first—turning “a wall of text” into “a small structured payload.” Then send only the essential data to a cloud model for higher-level reasoning.

Keep sensitive interactions on-device.
For user-generated content that’s highly sensitive—health notes, internal incident details, personal drafts—local inference can prevent accidental disclosure. Even if your cloud model remains part of the product, you can gate certain flows behind local processing.

Build with “offline-first prompts.”
Before you ever call a hosted endpoint, try to make the task work locally. That forces you to craft prompts, templates, and output formats that don’t rely on magical abilities. It also gives you regression tests: you can compare outputs (or at least behaviors) across model versions without network variability.

Use local models as development-time tools.
A local model is perfect for drafting, code understanding, schema generation, and quick ideation—especially when developers are experimenting with prompt engineering. This reduces the chances that sensitive internal text ever touches external services during development.

Treat local outputs as untrusted.
Whether the model is local or cloud, you still need guardrails: JSON schema validation, allowlists for actions, retrieval grounding when accuracy matters, and careful refusal handling. Local doesn’t mean “safe.” It means “contained.”

A weekend plan: how every developer can try this

Here’s a straightforward approach that doesn’t waste your time:

Pick one model and one task.
Don’t start with “I’ll build an AI app.” Start with something bounded: “summarize support emails” or “classify bug reports.”
Decide your success criteria.
For example: “Can it produce JSON with the fields I need?” or “Does it follow a rubric without constant re-prompting?”
Run the same prompt with sensitive-like text.
Use realistic examples from your domain (sanitized, of course). The point isn’t to expose real user data; it’s to simulate what your system would do.
Measure what changes.
Track latency, failure rate, and how much prompting you need to get consistent structure. You’re learning the model’s operational character.
Only then compare to cloud.
After you understand local constraints, you can make an informed decision about what to externalize, what to minimize, and what to keep on-device.

Do this once and you’ll stop treating privacy as an afterthought. You’ll start treating it as a system design problem—one you can validate by running code, not just reading policy.

Conclusion: Local models are a privacy education

Cloud LLMs can be incredibly powerful, and for many production scenarios they’ll remain the default. But running a model locally changed how I think about privacy because it collapsed the distance between “AI feature” and “data handling.” You learn the cost of convenience, the limits of control, and the practical ways to minimize what you transmit.

Every developer building AI features should spend a weekend with a local model. Not to replace the cloud—just to understand what you’re risking, what you can avoid, and what “privacy by design” looks like when it’s not theoretical.

Property-Based Testing Is the Testing Approach You're Sleeping On

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 13 Aug 2023 00:00:00 +0000

Most teams think they’re “done with testing” once the unit tests compile and pass. But passing tests are only proof that your code can handle the inputs you bothered to imagine. Property-based testing flips that assumption: instead of hand-picking a few examples, you specify the truths your code must always satisfy—and let the test engine generate thousands of cases, including the ones you’d never write.

If your current test suite feels like a collection of one-off scenarios, property-based testing is the upgrade you’ve been avoiding.

Why example-based tests plateau fast

Example-based unit tests are straightforward: you assert that function(x) equals y for a small set of chosen inputs. That’s useful—especially early on. The problem is what happens when your domain gets even slightly gnarly:

parsing user input (“empty string” isn’t exotic—it’s inevitable)
dealing with Unicode (normalization, combining characters, odd boundaries)
handling integer extremes (0, -1, MAX_INT, MIN_INT)
working with nested structures (depth, empty arrays, missing fields)
enforcing invariants (sorting, idempotency, round-trips)

At some point, your tests become a patchwork of special cases. You add one more example because a bug slipped through. Then another. Eventually the suite is a map of your intuition rather than a specification of your logic.

Property-based testing attacks the root cause: your “spec” should be the property, not the list of examples.

The core idea: specify invariants, not inputs

In property-based testing, you write properties—statements that should hold for all valid inputs. The framework then generates random inputs and checks whether the property holds. If it fails, it shrinks the failing input to a minimal counterexample. That last part matters: instead of “your test failed,” you get a small, human-readable input that breaks your assumption.

A simple example: suppose you have a function that normalizes whitespace in a string. A typical example-based test might check:

input "hello world" → output "hello world"
input "" → output ""

But the real invariant is usually stronger:

After normalization, the string contains no consecutive whitespace sequences.
Normalizing twice is the same as normalizing once (idempotence).

With property-based testing, you express those invariants and let the generator discover cases like " \t\n " or strings full of weird spacing you didn’t think to include.

A concrete TypeScript example with fast-check

Let’s say we have a normalizeSpaces function and we want to ensure idempotence:

Property: normalizeSpaces(normalizeSpaces(s)) === normalizeSpaces(s)

In fast-check, that looks like this:

import fc from "fast-check";

function normalizeSpaces(s: string): string {
 return s.replace(/\s+/g, " ").trim();
}

fc.assert(
 fc.property(fc.string(), (s) => {
 const once = normalizeSpaces(s);
 const twice = normalizeSpaces(once);
 return twice === once;
 })
);

Notice the absence of hand-picked examples. We didn’t write tests for empty strings, whitespace-only strings, or long strings—we simply told the system what must always be true.

Edge cases you didn’t write become the point

The strongest argument for property-based testing is what happens when randomness hits the boundaries of your assumptions. Example-based suites often overweight “happy path” values: typical lengths, typical characters, typical shapes.

Property-based testing pushes toward values that are systematically likely to expose bugs:

Empty strings: trimming, splitting, regex edge cases
Max/min integers: overflow, off-by-one logic
Unicode boundary characters: surrogate pairs, combining marks, grapheme clusters
Deep nesting: recursion limits, stack behavior, quadratic work
Nullability / missing fields (when you model them): optional logic that forgot a branch

Here’s what’s different: you’re not just hoping the test generator covers edge cases. You’re designing properties that remain meaningful across the entire input space. That turns “randomness” into a practical strategy for discovering failures.

What “shrinking” buys you

When a property fails, frameworks typically shrink the input to a minimal counterexample. That’s the difference between a failing test you can debug and a failing test you dread.

For example, if your “round trip” property fails for some complex string, shrinking might reduce it to something like "a\u0301" (a base character plus a combining mark) or "" (empty) rather than a 2,000-character monstrosity. You’ll understand what broke much faster—and you can add a targeted regression test once you know the real failure mode.

How to choose the right properties (and avoid cargo culting)

Not every invariant is a good property. A property should be:

Expressive: it describes real correctness, not just “it doesn’t crash.”
Checkable: you can verify it quickly during tests.
Stable: it won’t flake due to nondeterminism or time.
Aligned with domain rules: properties should reflect your actual specification.

Common high-value properties include:

Idempotence: f(f(x)) == f(x)
Round-trip: decode(encode(x)) == x (when the inverse relationship is true)
Ordering guarantees: sort(xs) is monotonically non-decreasing
Length / structure: transformations preserve size or expected shape
Algebraic laws: associativity, commutativity (when relevant), identity elements

If you’re building APIs, another pragmatic property is validating normalization behavior:

“After parsing and re-serializing, the canonical form is stable.”

Instead of asserting 10 examples, you assert canonical stability across thousands of generated inputs.

Practical tip: start with “metamorphic” properties

If you struggle to find direct invariants, look for metamorphic ones—relationships between inputs and outputs. For instance:

If you sort a list, sorting it again shouldn’t change it (idempotence).
If you concatenate two inputs and apply a transformation, the result should match applying the transformation to each part (under the right conditions).

Metamorphic properties are often easier to express than full correctness proofs.

fast-check, Hypothesis, and proptest: choose what fits your stack

Property-based testing isn’t one tool—it’s a mindset supported by different ecosystems.

fast-check (TypeScript / JavaScript)

fast-check integrates well with modern TypeScript projects. It has rich arbitraries (generators) for common data types, and its failure reports are typically straightforward. It’s especially convenient if your domain model already uses TypeScript types—your properties can mirror those types cleanly.

A big win in practice: you can write properties that use your existing pure functions, without ceremony. For teams that already test with Jest/Vitest, fast-check feels like a natural extension.

Hypothesis (Python)

Hypothesis is famously effective at finding minimal failing cases. It encourages you to write properties rather than examples, and its approach to generating data tends to produce useful counterexamples quickly.

In Python codebases, it’s a strong fit when you have lots of data transformation logic—parsers, validators, serialization routines, business rules—and you want confidence that your assumptions hold beyond the examples you wrote down.

proptest (Rust)

proptest matches Rust’s strengths: you can model constraints precisely using strategies, generate data that respects invariants, and lean on Rust’s type system to keep your properties honest.

If you’re working in Rust with complex enums, algebraic data types, or low-level correctness concerns, proptest is often a near-perfect complement to the language’s emphasis on safety.

Put it into your workflow without boiling the ocean

Teams often fail at property-based testing adoption for one reason: they try to rewrite everything at once. Don’t.

Here’s a practical rollout plan that works:

Pick one module with clear invariants
Parsing, normalization, transformations, encoding/decoding, and pure business logic are ideal.
Write one property that replaces a cluster of tests
If you currently have “input/output” tests for many variants, identify the shared invariant. For example, multiple tests of string normalization likely share idempotence and “no consecutive whitespace.”
Start with small input domains
Don’t immediately generate huge nested structures. Increase complexity after the first green runs.
Use failing counterexamples as regression seeds
When a property fails, keep the minimal counterexample as a concrete unit test. Property-based tests find bugs; unit tests make sure they stay fixed.
Tune performance intentionally
Properties can be expensive if you generate unbounded structures or perform heavy computations per case. Set reasonable limits and avoid doing deep parsing inside the property unless that’s what you’re testing.

If you do this well, you’ll see immediate payoff: fewer brittle tests, more confidence at the edges, and fewer “we didn’t consider that input” surprises in production.

Conclusion: your test suite should represent the specification, not your imagination

Example-based tests are necessary, but they’re not sufficient. Property-based testing turns your correctness criteria into executable specifications and continuously challenges your assumptions with thousands of generated inputs—especially the boundary cases that intuition misses.

Start with one property. Let the framework do the annoying work of generating cases you wouldn’t think to write. Then use the shrinking counterexamples to fix the real issues and lock them in. Once you’ve seen how quickly it finds bugs, you won’t go back.

Hono: The Ultralight Framework That Runs Everywhere

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 08 Aug 2023 00:00:00 +0000

If you’ve ever watched a tiny API project spiral into a dependency forest, Hono will feel like a wake-up call. It’s a web framework built for modern runtimes—edge included—without the baggage. The headline is simple: Hono is ultralight, standards-based, and designed to run the same code across Cloudflare Workers, Deno Deploy, Bun, Vercel Edge, and Node.js. The result is faster iteration, cleaner middleware, and a TypeScript experience that doesn’t fight you.

Built on Web Standards (Not “Framework-isms”)

Hono’s core philosophy is that the web already provides a great set of primitives. Instead of inventing a new request/response model or expecting you to learn a framework-specific abstraction, it leans on Web Standards. That matters because it keeps your mental model stable across environments.

In practice, this means you’re writing handlers that resemble how the web works: you accept requests, you return responses, and you use familiar HTTP concepts. When you deploy to an edge runtime, you’re not “porting” your application so much as moving it.

Concrete example: imagine you have a lightweight “health” endpoint and an API key gate.

import { Hono } from 'hono'

const app = new Hono()

app.get('/health', (c) => c.json({ ok: true }))

app.get('/secret', (c) => {
 const token = c.req.header('authorization')
 if (token !== `Bearer ${process.env.API_TOKEN}`) {
 return c.json({ error: 'unauthorized' }, 401)
 }
 return c.json({ data: 'classified' })
})

export default app

Notice the shape: concise routes, predictable request access, clean JSON responses. It’s the kind of code you don’t mind maintaining, even when the app grows.

The Real Superpower: One Codebase, Many Runtimes

Most frameworks make you choose a runtime—then punish you when you try to move. Hono is the opposite. You can use the same framework code across multiple deployment targets, including edge platforms and standard Node.js.

That isn’t just a convenience feature; it changes how you build. You can prototype locally, validate behavior quickly, and then ship to an edge runtime without rewriting the app’s architecture.

Think about common teams and workflows:

Edge-first products: you start at the edge to reduce latency and keep compute close to users.
Prototyping: you build locally (or in CI) with the same framework you’ll deploy.
Scaling needs: you may later split heavier work into separate services while keeping the HTTP edge surface lightweight.

Hono fits this reality because it doesn’t treat edge as a special snowflake.

Middleware That Doesn’t Feel Like a Mess

Express-style middleware patterns are familiar, but they can become tangled—especially as you start composing cross-cutting concerns like auth, logging, CORS, rate limiting, and request shaping.

Hono’s middleware system is intentionally clean. The interfaces are straightforward, and the flow stays readable. Instead of scattering logic in ad hoc route handlers, you can assemble behavior at the app level and reuse it consistently.

A practical pattern is to define middleware for:

Authentication (attach user context)
Observability (log request IDs, timing)
Input shaping (validate/normalize request bodies)

For example, you can create a middleware that ensures a request has a specific header before allowing access:

import { Hono } from 'hono'

const app = new Hono()

app.use('/api/*', async (c, next) => {
 const apiKey = c.req.header('x-api-key')
 if (!apiKey || apiKey !== process.env.API_KEY) {
 return c.json({ error: 'missing or invalid api key' }, 401)
 }
 await next()
})

app.get('/api/items', (c) => {
 return c.json([{ id: 1, name: 'Widget' }])
})

This is the kind of middleware you can reason about. It’s not hiding control flow in clever tricks; it’s explicit about “check, then next.”

Routing and TypeScript: Fast to Write, Hard to Break

Hono’s routing is intuitive, and that matters more than people admit. If routing feels frictionless, you write endpoints more frequently—and that’s how teams end up with smaller, testable surfaces rather than one monolithic handler.

The TypeScript experience is also first-class. You get strong autocomplete, predictable handler signatures, and a codebase that stays friendly as it grows. TypeScript isn’t a bolt-on here; it’s part of the design.

Here’s a simple example of route-driven typing and safe response shaping:

import { Hono } from 'hono'

type Item = { id: number; name: string }

const app = new Hono()

app.get('/items/:id', async (c) => {
 const id = Number(c.req.param('id'))
 if (!Number.isFinite(id)) return c.json({ error: 'invalid id' }, 400)

 const item: Item = { id, name: 'Example Item' }
 return c.json(item)
})

The handler stays compact, but you’re still protected against sloppy assumptions. That’s how TypeScript should feel: helping without getting in your way.

Performance Without the Ego: Small Framework, Big Output

Hono is built to be lightweight—around 12KB and with zero dependencies. That matters because dependency graphs create overhead: more installs, more build steps, more places for things to break, and more time debugging version mismatch issues.

The framework also targets performance realistically. It’s been benchmarked as faster than Express by an “embarrassing margin” in common scenarios. Even if you don’t obsess over microbenchmarks, the underlying point holds: fewer layers and fewer moving parts usually translate to better runtime efficiency and lower latency variance.

Where this shows up in the real world:

Edge response times feel snappier because the request path stays lean.
Cold starts are less painful because there’s less to load.
Developer iteration speeds up because the framework doesn’t drag your build pipeline around.

If you’re building an API gateway, a webhook receiver, a set of CRUD endpoints, or any “lots of requests, little logic” service, Hono is a strong default choice.

When to Use Hono (and When Not To)

Hono shines when you want modern HTTP behavior, clean composition, and runtime portability—especially for edge deployments and lightweight APIs.

Use it when:

You’re deploying to edge runtimes and want to keep the code portable.
You want a minimal server layer for an API or backend-for-frontend.
You care about readable middleware composition and predictable TypeScript.
You’re building services that should be easy to split, scale, and maintain.

Be cautious when:

You need heavy, deeply specialized ecosystem features that you already depend on in a different framework.
Your team is deeply invested in a specific middleware ecosystem and doesn’t want to migrate patterns.
You’re building something that’s less “HTTP service” and more “full application framework” with lots of built-in conventions—because Hono’s strength is staying focused.

My opinionated take: if your service is fundamentally an HTTP API, Hono is the kind of framework you’ll be glad you chose early. Migration later is harder than it should be—so pick the lightweight, standards-based option now.

Conclusion: A Modern Default for Edge and APIs

Hono is what Express would look like if it were designed in 2023 for today’s runtime reality: standards-based, edge-friendly, dependency-free, and genuinely pleasant to use in TypeScript. It’s small enough to stay out of your way, fast enough to matter, and consistent enough to deploy confidently across multiple platforms.

If you’re building APIs—especially edge-first ones—Hono deserves a spot in your toolkit.

tRPC Made Me Forget REST Exists

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 27 Jul 2023 00:00:00 +0000

REST isn’t “dead,” but after using tRPC in a TypeScript-heavy codebase, it’s hard to unsee how much ceremony you inherit—versioning chaos, schema drift, and that nagging question of whether the backend and frontend still agree.

tRPC doesn’t just make API calls feel nicer. It removes the API contract problem at the source: the same TypeScript types that describe your server procedure become available to your client automatically—no OpenAPI spec, no code generation, and far fewer “surprise” mismatches.

The real problem isn’t HTTP—it’s the contract

REST is fundamentally an HTTP convention. The contract—the part everyone actually cares about—is usually captured somewhere else: an OpenAPI document, a hand-written JSON schema, a shared type package, or the worst option of all: documentation that developers interpret differently.

That’s where problems breed:

Input shape drift: frontend sends { userId: "123" }, backend expects { id: number }.
Output shape drift: frontend reads data.items, backend returns data.results.
Version mismatches: you deploy the backend, the frontend lags, and nobody realizes the procedure signature changed.
Maintenance overhead: keeping schemas, generators, and types in sync becomes a job of its own.

You can paper over this with discipline, but discipline doesn’t fix structural risk. You can be the best engineer on the team and still get burned when the system encourages divergence.

What tRPC changes: one source of truth for both sides

With tRPC, you define procedures on the server in TypeScript. The client consumes them via a type-safe API that’s inferred from the server definition.

The important part: the contract is not “described” in a separate artifact. It is the code itself.

Here’s the basic shape of the mental model:

Server: you declare a procedure with input validation and an output type.
Client: you call that procedure and TypeScript already knows the input/output types.
Sync by construction: change the server procedure, and the client immediately reflects the new types (or fails to compile).

No OpenAPI spec. No generator pipeline. No “run codegen, commit output, pray.” If you’re using a TypeScript monorepo, it gets even cleaner because the server router and client can share types directly.

A concrete example: “getUser” that can’t drift

Suppose your server has a procedure:

input: { userId: string }
output: { id: string; name: string; role: "admin" | "user" }

With tRPC, when you call it from the client:

TypeScript will enforce the input shape.
TypeScript will tell you exactly what fields exist in the result.
If you rename userId to id, or add/remove a field, the client compile fails right away.

That’s not “nice autocomplete.” That’s eliminating a whole class of integration bugs before runtime even has a chance to happen.

Compile-time safety isn’t enough—Zod closes the runtime gap

If you stop at TypeScript inference, you still have a runtime problem: the network doesn’t care about your types. A malicious client (or a buggy client) can send invalid data.

tRPC typically pairs with Zod (or similar validators) so you get the best of both worlds:

Compile-time types: derived from the Zod schema and the procedure.
Runtime validation: enforced on the server before your logic runs.

That means your server doesn’t just hope the input matches—it checks it. And your client doesn’t just trust the types—it’s guided by them.

Practical takeaway: validate at the boundary, type everywhere

A pattern I now treat as non-negotiable:

Use Zod to define the input schema.
Let tRPC infer the TypeScript types from that schema.
Keep business logic focused on valid inputs, not defensive parsing everywhere.

Your procedure becomes easier to read because you remove a layer of clutter—“validate this, check that, handle weird shapes”—and move it into a clear schema definition.

Eliminating “contract maintenance” changes how you ship

Once the contract is shared automatically, development velocity improves in a way that’s hard to quantify but easy to feel.

You refactor without fear

In traditional REST setups, refactoring a request or response means juggling:

update backend code
update OpenAPI docs (if you have them)
regenerate client types (if you have them)
audit call sites across the app
coordinate deployments so clients don’t break

With tRPC, the “audit across the app” part becomes the compiler’s job. When you change the server procedure signature, the client sees it immediately. You fix broken call sites as you go, and you don’t ship until everything compiles cleanly.

You don’t design contracts separately from code

REST often leads you to think: “First we define the API. Then we implement it.” That separation sounds tidy, but it creates drift. tRPC collapses that workflow. You build the procedure, define the validation, define the return type, and the client just follows.

This has a subtle effect: API design becomes less of a heavyweight phase and more of an iterative practice.

REST and GraphQL feel like ceremony when TypeScript does the syncing

tRPC also changes the emotional comparison. Without code generation, without schemas-as-docs, without “versioned contracts,” REST and GraphQL start to feel like you’re doing extra work to keep two systems aligned.

REST still has strengths—caching semantics, broad ecosystem support, and a universal language for HTTP clients. GraphQL still offers flexible querying and tooling around schemas and resolvers.

But if your world is already TypeScript end-to-end, tRPC brings the contract problem to a stop.

The monorepo advantage is real

In a TypeScript monorepo, the server and client often evolve together. tRPC turns that advantage into a workflow: shared types, inferred procedure signatures, and a unified developer experience.

If you’re working across package boundaries, you also get a practical enforcement mechanism: changes to the server router break the client build immediately. That’s the kind of feedback loop you want—fast, local, and unavoidable.

Where tRPC fits best (and where you should still be careful)

Let’s be honest: you shouldn’t declare REST irrelevant in every context. The value of tRPC is strongest when:

your stack is TypeScript-heavy
backend and frontend live in the same repo (or at least share types through a package boundary)
you care deeply about developer experience and integration correctness
your API surface benefits from procedure-level modeling

You still need to think about compatibility for external consumers. If third-party clients must integrate, you may still need public, language-agnostic contracts (OpenAPI, documentation, or a published schema). tRPC doesn’t magically replace that. It excels at the internal “frontend ↔ backend” relationship where TypeScript can be the contract layer.

Also, don’t treat runtime validation as optional. Type inference doesn’t validate network inputs; Zod does.

Conclusion: stop negotiating contracts—make them compile

tRPC “made me forget REST exists” not because HTTP disappeared, but because the contract stopped being fragile. When the backend procedure definition and the frontend usage share types through inference, you eliminate drift by construction. Add Zod validation and you get runtime safety too.

If your team lives in TypeScript and you want fewer moving parts—no OpenAPI file, no codegen pipeline, fewer version mismatch headaches—tRPC is one of the rare upgrades that changes both the reliability and the feel of building APIs.

Next.js App Router: Brilliant Architecture, Terrible Developer Experience

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 15 Jul 2023 00:00:00 +0000

Next.js App Router is the rare framework feature that feels like a major step forward—right up until you try to use it on a real codebase. The architecture is genuinely exciting: server components, streaming SSR, and caching controls that promise to eliminate whole classes of client-side waterfalls. But the migration from the Pages Router? That’s where the glow fades. In practice, you’re handed unpredictable caching behavior, confusing mental models, missing documentation details, and error messages that read like they were generated by a haunted toaster.

If you’re deciding whether to adopt App Router now, here’s the unvarnished truth: it will likely be excellent in a year. Today, it’s a beta disguised as stability.

The Real Win: Server Components That Actually Change the Game

App Router’s central idea is React Server Components (RSC): components rendered on the server by default, with no need to ship their code to the browser. That architectural choice eliminates a lot of the “fetch everything in a client effect” anti-pattern. Instead of rendering a shell and then progressively hydrating data, you can fetch data where it belongs.

A typical App Router pattern looks like this:

app/ routes define your UI as nested layouts and pages.
Server components are the default.
Client components are opt-in via "use client".

So a route might fetch directly:

// app/products/[id]/page.tsx (server component by default)
export default async function ProductPage({ params }: { params: { id: string } }) {
 const product = await getProduct(params.id); // server-side fetch
 return <div>{product.name}</div>;
}

The practical benefit is immediate: no client waterfall waiting for a useEffect to run before data appears. Combined with streaming SSR, users can see meaningful UI quickly—sometimes before the entire tree resolves.

On paper, this is exactly how modern web apps should work: push work to the server, reduce bundle size, and keep rendering deterministic.

But the Migration Is Where Productivity Goes to Die

The Pages Router and App Router share a name—“Next.js”—but they don’t share a developer experience. Moving an existing app is less like upgrading and more like rewriting.

In Pages Router, you might rely on familiar primitives:

pages/ routes
getServerSideProps / getStaticProps
next/head
predictable client/server boundaries

In App Router, you’re instead navigating:

app/ segments, layouts, and route groups
server components by default
data loading through server code (often inside components)
a different approach to head management and metadata
caching semantics tied to both fetch and route behavior

The first “gotcha” most teams hit is that boundaries are enforced differently. You might have an existing component that “used to be safe” to import anywhere, but in App Router it can silently become a client component (or fail when you accidentally use server-only features in the wrong place). The fix is rarely just one line—it’s often a refactor of how data and UI are separated.

Here’s a common trap: importing something that uses browser APIs into a component that App Router expects to run on the server. You then discover that the fix involves carving the component into server + client halves, and passing data through props (which changes serialization constraints).

Even experienced Next.js developers end up spending time on “plumbing work” that doesn’t deliver user value: reorganizing folders, splitting components, chasing build errors, and re-learning what runs where.

Caching: The Promise of Control, the Reality of Confusion

Next.js App Router’s caching story is one of its biggest selling points: you can aim for granular caching with the framework doing the heavy lifting. And yes, the system is powerful. But the behavior can feel like you’re wrestling a black box—especially when you’re migrating from a system where caching was explicit and isolated.

The core tension is simple: caching is now tied to the semantics of fetch and the rendering lifecycle. That means small changes—moving a fetch into a server component, changing where a value is computed, tweaking fetch options—can change the caching outcome.

In practical terms, teams often experience some combination of:

“It works locally but not in production.”
“My page updates sometimes, but not consistently.”
“I expected revalidation to happen, but stale data persists longer than I can explain.”
“Changing the code invalidates cache in one environment but not another.”

What helps is adopting a disciplined approach:

Decide your caching policy per request type, not per developer preference. For example: “product detail pages are revalidated every 60 seconds” vs “admin pages are never cached.”
Keep data-fetching logic in one place (e.g., a lib/ function) so you don’t end up with caching differences across components.
Instrument and verify. Don’t guess. Add visible “data age” markers in development, and log request identifiers server-side so you can tell which requests were served from cache.
Use fetch options intentionally. Treat cache and revalidation-related settings as part of your product requirements, not implementation details you can sprinkle later.

If you do nothing else, make caching testable. App Router makes caching powerful enough that you should demand it behave predictably.

Error Messages and Documentation Gaps: You’ll Learn Through Pain

The architecture is modern. The developer experience is… not.

App Router error messages can be cryptic in a way that wastes hours. The framework sometimes tells you what you did wrong without providing actionable context—especially around server/client boundaries and invalid imports. You’ll see failures that feel detached from the line of code that triggered them, because the underlying problem may occur earlier in the render tree or during build compilation.

Documentation gaps are the second productivity killer. You’ll find pages that explain the concepts, but not always the edge cases you need during migration. The missing details tend to be exactly where teams get stuck:

how to structure layouts and nested routes for common patterns
how metadata and head-like concerns map from Pages Router equivalents
what runs where when you mix server logic with interactive UI
how to reason about caching when code structure changes

The “truck-sized gap” feeling isn’t because documentation is absent—it’s because it’s incomplete for the workflow you’re actually trying to execute. You’ll often end up triangulating from:

examples that assume a greenfield project
GitHub issues with partial answers
“tribal knowledge” from other teams who already banged their heads against the same wall

My advice is to plan for that reality. If your roadmap depends on migrating dozens of routes quickly, you’ll want a buffer for experimentation and refactoring. Treat the migration as a project, not a simple branch upgrade.

A Better Migration Strategy: Build a Safe Path, Not a Leap of Faith

If you’re moving to App Router, don’t do it as a big-bang rewrite. Do it like you’re managing risk—because you are.

Here’s a pragmatic strategy that works better than “convert everything”:

Start with low-risk routes. Public content pages, simple lists, and read-only detail pages are great candidates. Save authentication-heavy and highly interactive screens for later.
Create a compatibility plan for shared components. Establish conventions:
- Server components by default
- Client components only where interactivity is required
- A clear folder structure for UI primitives vs data logic
Centralize your data layer. Put fetching and transformation in lib/ functions so caching policies don’t drift across components.
Write migration tests. Not just unit tests—behavior checks.
- Confirm loading states render as expected.
- Confirm data freshness matches your caching intent.
- Confirm redirects and error pages behave correctly.
Document the rules your team adopts. For example: “No browser APIs in server components” or “All fetches go through lib/.” The goal is to prevent accidental inconsistencies that are hard to debug later.

The win here is that you reduce the scope of uncertainty. App Router is best when you can isolate its effects while you learn the mechanics.

And yes: you may need to “unlearn” some habits from Pages Router. But if you approach it as incremental learning with guardrails, the migration becomes survivable—and eventually rewarding.

Conclusion: The Architecture Deserves the Attention—The Adoption Needs Guardrails

Next.js App Router is a real architectural breakthrough that aligns with where React is headed: server-first rendering, streaming SSR, and caching control that can eliminate performance footguns. But today’s developer experience—especially during migration—is still rough around the edges. Caching behavior can feel unintuitive, documentation gaps will cost time, and error messages won’t always help you fix the real underlying issue.

So here’s the bottom line: adopt App Router when you can afford iterative migration and you’re willing to treat caching and boundaries as first-class concerns. Give it time, build with discipline, and you’ll likely end up with a codebase that performs better than what Pages Router could ever deliver. Jump in recklessly, and you’ll spend the next few weeks debugging the framework instead of building your product.

OpenTelemetry Is the Observability Standard You Should Adopt Now

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 08 Jul 2023 00:00:00 +0000

If your observability stack feels like a set of bespoke duct-tape integrations—each new service, new vendor, new dashboard, new “how did we even measure that?”—OpenTelemetry is the reset button. It’s vendor-neutral instrumentation designed to work across backends, so you instrument once and route telemetry anywhere you want. That means fewer rewrites, less vendor lock-in, and a cleaner path to better reliability.

Why “instrumentation” should not mean “vendor lock-in”

Most teams don’t start with lock-in—they start with urgency. Something goes wrong, logs are noisy, metrics are inconsistent, traces are missing, and suddenly you’re “just integrating with Vendor X” to ship a fix. The problem is that instrumentation tends to calcify. Dashboards and alerts become tightly coupled to the vendor’s data model and query language. Even worse, app code often ends up calling vendor SDKs directly.

OpenTelemetry (OTel) changes the default workflow:

You instrument your code with OTel SDKs (or via auto-instrumentation).
You export telemetry through a standardized protocol (OTLP).
You configure where it goes—Jaeger, Grafana, Datadog, or any OTLP-compatible backend—without reworking application code.

In practice, this means you can start with one backend today and keep the option to migrate later. You’re not buying observability twice: once in your vendor relationship, and again in the engineering effort required to leave.

Instrument once: traces, metrics, and logs in one system

OpenTelemetry isn’t only for traces. A modern observability program needs all three pillars:

Traces to understand request flow and latency bottlenecks across services.
Metrics to track performance over time (latency percentiles, error rates, saturation signals).
Logs to capture event context that doesn’t fit traces or metrics.

The key is consistent correlation. When your trace IDs and resource attributes are standardized, you can connect “what happened” to “why it happened” without manual glue code.

A concrete example: imagine an e-commerce checkout pipeline.

You instrument the checkout service (OTel spans for inbound HTTP requests, outgoing calls, database queries).
You export metrics like request latency and error count.
You include log records that automatically attach trace context.

Now, when a user reports a timeout, your on-call flow becomes: open trace → see which downstream dependency slowed down → jump to the matching logs/events → correlate with metrics trends. You stop treating observability as disconnected artifacts and start treating it as a navigable system.

The real power move: the Collector as your routing brain

Here’s where teams either win or stall. If you export telemetry directly from every app to every backend, you reintroduce complexity and brittleness. The OpenTelemetry Collector fixes that by acting as a central telemetry processing layer.

Think of the Collector as your “observability gateway.” It can:

Receive telemetry from your applications (or agents).
Transform and enrich data (add or normalize attributes).
Filter noisy signals so you don’t drown in cost or irrelevant detail.
Batch and retry to improve reliability of exports.
Route telemetry to one or more backends—often simultaneously.

Operationally, this is gold. You can change routing or processing rules without shipping application updates. For instance, during an incident you might temporarily increase sampling for one service to get higher-fidelity traces, then dial it back once stability returns. With the Collector, that’s a configuration change, not a code release.

Auto-instrumentation: baseline observability without developer tax

Manual instrumentation is valuable, but it’s not sustainable as a universal strategy. You want “good enough” coverage immediately—especially for common libraries like HTTP frameworks, database drivers, and messaging clients.

OpenTelemetry supports auto-instrumentation for many ecosystems, which means:

You get default spans for inbound/outbound requests.
You capture key attributes automatically (route, method, peer service, etc.).
You reduce the cognitive load on developers.

This isn’t about removing all manual work. It’s about ensuring that the first deploy already produces useful traces and metrics. Then developers can selectively add custom spans around business-critical operations—like “checkout authorization” or “credit card verification”—to make traces meaningful to humans.

A practical workflow many teams adopt:

Deploy auto-instrumentation broadly to establish coverage.
Turn on Collector-based enrichment (service names, environments, tenancy keys, etc.).
Add targeted manual spans for workflows that matter most.
Use dashboards and alerts to validate signal quality.
Iterate once the system is live—without rewriting from scratch.

Choose your backend now (and keep your options later)

The strongest argument for OTel is not theoretical portability—it’s strategic flexibility. If your environment supports OTLP, you can forward the same telemetry to different backends.

Examples of common setups:

Local development with Jaeger for quick trace exploration.
Production with a managed backend like Grafana-based tooling.
Parallel export during migrations, so you validate new dashboards against existing traces.
Cost-aware routing: keep high-cardinality detail for a subset of traffic, and aggregate the rest.

If you’re currently locked into a single vendor, OpenTelemetry doesn’t demand you abandon everything overnight. You can start by integrating OTel while continuing to use your current backend. Then, as you validate parity (dashboards, alerting logic, trace navigation), you can gradually shift exports.

This is also how you avoid paying twice. Vendor pricing models often punish growth in ways that are hard to predict. Moving to a routing architecture where you can control what you send—and where—gives you leverage. You’re not trapped into one pricing scheme for the entire lifespan of your platform.

And yes, the economics matter. If you’re paying per-host or per-agent for a commercial backend, it’s worth comparing what you can achieve with an OTLP-compatible path that fits your budget. For example, teams that already use Grafana tooling may find meaningful value using Grafana Cloud’s free tier for initial onboarding and evaluation—especially when combined with OTel’s ability to export once and route anywhere. (Treat “80% of the value” as a goal, not a guarantee: the real win is that you can measure your results quickly and adjust.)

A practical adoption plan that won’t break your week

Adopting OpenTelemetry can feel intimidating, but it doesn’t have to be a rewrite. Here’s a pragmatic path that minimizes risk:

1) Pick a language and start with one service

Choose a service that:

is already instrumented with some logging/metrics,
handles meaningful user traffic,
and has clear downstream dependencies.

Start with traces first—because they immediately unlock root-cause analysis.

2) Enable auto-instrumentation, then verify output

Bring up your Collector and confirm you see spans end-to-end. Don’t worry about perfect attribute naming on day one. The goal is signal flow: instrumentation → Collector → backend.

3) Standardize “resource” attributes early

Decide on consistent values for:

service.name
service.version (if available)
environment (prod/staging/dev)
deployment metadata (region, cluster, etc.)

This is what makes dashboards useful instead of confusing.

4) Add filtering and sampling rules in the Collector

Cost control belongs at the Collector layer. Start with conservative defaults:

sample high-volume endpoints more aggressively,
keep error traces at higher priority (via status-based sampling if supported),
drop or reduce noisy attributes that explode cardinality.

5) Roll out iteratively and teach the team the workflow

Once traces exist, your team needs a shared mental model:

“Start with trace, then pivot to logs and metrics.”
“Use service boundaries and span names consistently.”
“When you deploy, you should be able to see the impact within minutes.”

That cultural piece is the difference between “we installed OTel” and “we use OTel to get better.”

Conclusion: adopt OTel now, then refine with confidence

OpenTelemetry isn’t just another observability tool—it’s a standard approach to instrumentation that protects you from vendor lock-in and reduces future migration pain. By instrumenting once and using the Collector to route, transform, and control telemetry, you gain flexibility, cost leverage, and a cleaner operational model. Start small with auto-instrumentation, verify end-to-end traces, then iterate into richer metrics and logs correlation. If your observability strategy is still tightly coupled to a single vendor, OpenTelemetry is the modern way out.

WebAssembly Will Eat the World (Just Not How You Think)

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 03 Jul 2023 00:00:00 +0000

For years, the WebAssembly story has been sold as a clever way to run C++ in the browser. That’s not wrong—it’s just incomplete. The real revolution is happening in the places you can’t easily “just ship to the browser”: servers, edges, embedded systems, database extensions, and the permissioned chaos of smart contract runtimes. WebAssembly isn’t becoming the web’s new app platform. It’s becoming the plumbing layer for every platform that needs safe, fast, language-agnostic execution.

Stop worshiping the browser use case

The browser is the shiny demo. It’s also the constraint. Browser-based WASM is still bound by sandboxing, execution models, and the web’s expectations around networking, storage, and user interaction. Plenty of teams will continue using WASM for interactive workloads—games, image/video pipelines, and compute-heavy UI logic—and those use cases are real.

But the “WASM in the browser” narrative misses the point: the industry already knows how to ship web apps. What it didn’t know how to standardize is how to run untrusted or semi-trusted code safely and consistently across heterogeneous environments.

When you look at WASM as a compilation target rather than a browser feature, the real story gets obvious. WASM gives you a portable, verifiable binary format plus an execution contract. That combination is the foundation for runtime ecosystems far beyond the DOM.

The universe of Wasmtime-style runtimes

If you’ve only encountered WASM through browser tooling, you might not realize how quickly it turns into “just another runtime” on the server.

Server-side WASM runtimes—think Wasmtime-style engines—let you run WASM modules in environments where you otherwise might deploy containers, custom plugins, or heavyweight microservices. The key difference isn’t only performance. It’s the ability to treat code as a deployable artifact with a stable contract: inputs/outputs, resource limits, and predictable execution semantics.

A practical pattern is “small compute modules” that your service loads on demand. For example:

A request pipeline that calls a WASM module to compute pricing rules.
A fraud-scoring module that runs with strict CPU/memory caps.
A compliance checker that rejects payloads before they reach downstream systems.

In this model, the runtime handles isolation and resource boundaries. Your application becomes an orchestrator rather than a monolith of business logic. If you’ve ever built a plugin system in production, you know how fragile those get—ABI mismatches, dependency hell, and “hot reload” drama. WASM narrows the surface area of failure because it doesn’t care what language produced the module.

And importantly, you can version and test modules more deterministically than with ad-hoc binaries.

Edge computing: WASM as the portable “compute cartridge”

Edge platforms have a different problem than browsers and traditional servers: they need to run code near users without giving every customer a free pass on resources, security posture, or performance predictability.

This is where WASM shines. When an edge provider offers a WASM-friendly execution model, you can ship compute as a portable artifact. The runtime can impose quotas, limit outbound network access, and keep the execution sandboxed. From your perspective, you’re not building per-edge-language custom stacks. You compile once, target the WASM module interface, and let the edge runtime do the hosting.

A concrete example: a content routing service at the edge.

You compile a WASM module that parses headers and rewrites routing decisions.
The edge platform calls the module for each request.
The module returns an action: rewrite, cache key, or bypass cache.

Even if the module logic changes frequently, you still get a clean deployment unit that doesn’t require you to rebuild an entire service. This is the “compute cartridge” mindset: small, isolated, swappable logic that moves with the traffic.

Databases and plugins: making “extensions” actually extensible

The internet is full of extension systems that weren’t designed for safety, portability, or long-term maintainability. Databases are the perfect example: users want custom functions, transforms, and policy checks—yet every extension model tends to become a tangle of ABI constraints, version lock-in, and security trade-offs.

WASM is an unusually good fit for database extensions because it can serve as a common execution substrate between the host database and many extension languages.

Instead of requiring extensions to be compiled as native code against a specific database version, you can:

Expose a narrow host interface (how to read rows, how to return results, how to handle errors).
Run extensions as WASM modules under the database’s runtime policy.
Enforce resource limits and sandbox boundaries.

The benefit is cultural as much as technical: you can build an extension ecosystem where people don’t need deep knowledge of your database’s internal build system. They just need to target the WASM module contract. A Rust author and a Go author can both ship compatible extensions without you maintaining two different plugin SDKs forever.

If you’ve ever watched an extension community collapse because “we only support language X,” you already understand why this matters.

Smart contracts and the “universal runtime” effect

Smart contracts already have their own execution environments and languages. But WASM’s influence here is about standardizing the execution layer, not just providing another syntax.

When contract platforms use WASM-based execution, you get a pipeline where developers can compile from multiple languages into the same portable binary format. That reduces the friction of tooling, improves portability, and makes the runtime more uniform across contracts.

Even in ecosystems where developers still “write in Solidity” or a domain-specific language, the underlying execution model often becomes the real battlefield: determinism, metering, and state interaction. A WASM-based runtime can unify these concerns in a way that language choices can largely ignore.

The outcome is language interoperability that feels inevitable in hindsight. Today, smart contract developers deal with fragmented toolchains, unique runtime semantics per platform, and incompatible ABI rules. A shared execution target doesn’t magically solve every semantic mismatch—but it does remove a large category of “rewrite the whole stack” problems.

WASM’s real superpower: the component model and interoperability

If you want one reason to believe the “eat the world” headline without hand-waving, it’s the WASM component model. The browser can be the first landing zone, but the component model is about defining interfaces between modules and hosts in a portable, language-agnostic way.

In practice, this is the difference between:

“Here’s a blob of code you can run,” and
“Here’s a code package with a well-defined interface contract you can reliably wire into other systems.”

Think about what that enables:

A WASM module written in one language can call a capability exposed by another module written in a different language.
Hosts can provide standardized capability imports (files, networking-like abstractions, key-value storage access, cryptographic primitives, application-specific services).
Tooling can reason about interfaces, generate bindings, and reduce the brittle glue code that makes interoperability a fantasy.

This is the kind of progress that makes platforms feel boring—in the best way. When the plumbing is stable, innovation accelerates because teams stop re-solving the same integration problems.

And yes, this will still show up in the browser eventually. But the component model is more valuable anywhere you have multiple teams, multiple languages, and frequent composition of behavior: edge + backend pipelines, database extensions + policy modules, orchestration layers + sandboxed compute.

So what should you do with this?

If you’re building products, the best approach is pragmatic, not ideological.

Treat WASM as a deployment artifact, not a marketing slogan. Start with “small logic modules” that are expensive to iterate on, risky to run natively, or hard to version safely.
Design a narrow interface. The moment your WASM boundary becomes “everything,” you’ll recreate the same complexity you tried to escape. Keep it tight: inputs, outputs, and a few well-defined capabilities.
Make isolation a first-class feature. Use resource limits and sandbox policies intentionally. Decide what’s allowed before you ship—not after someone needs “just one more permission.”
Plan for an ecosystem, not a one-off. If you can standardize your module interface, you can eventually support third-party extensions without becoming the bottleneck.

If you’re a developer evaluating tooling: learn the “compile-to-WASM then run in a runtime” workflow and get comfortable with the host interface model. Don’t start with building a web app in WASM. Start by building a module that does one job well and can run under constraints.

Conclusion: The web is just the first room

WebAssembly won’t “replace” the web. It will replace the need to invent new execution environments every time you want safe, portable code. The browser is a compelling proving ground, but WASM’s real power is broader: server-side runtimes for modular compute, edge-friendly cartridges for low-latency logic, plugin systems for extensible databases, and language interoperability made practical through interface-focused component design.

WASM isn’t eating the world because it’s cool in the browser. It’s eating the world because it’s a universal execution target—and universality is the rarest form of platform power.

Playwright Killed Cypress and I'm Not Sorry

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 21 Jun 2023 00:00:00 +0000

For years, Cypress felt like the rare end-to-end (E2E) testing tool that didn’t make developers want to set fire to their laptops. It was fast, friendly, and made “write integration tests” sound almost enjoyable. But good tools get replaced when the fundamentals stop matching how real apps work—multi-browser reality, auth flows, multiple tabs, and flaky timing. Playwright doesn’t just improve the experience. It fixes the structural problems that made Cypress feel like a good first act instead of the final one.

Why Cypress Was a Revelation (and Why That Matters)

Cypress arrived at the exact moment E2E testing was in decline. Selenium-based approaches were brittle, slow, and miserable to debug. Cypress changed the emotional tone: tests ran in the browser, the UI showed what happened, and writing “realistic” user flows wasn’t a chore.

It also normalized a development workflow many teams wanted:

Write tests alongside the app.
See failures immediately.
Debug with a time-travel style runner.
Get deterministic-ish results through built-in waiting and control.

If you used Cypress for a year and felt like your testing strategy finally stopped fighting you, you’re not imagining it. Cypress had momentum for a reason.

But here’s the trade-off: Cypress made certain assumptions that are great for some apps and painful for others. Over time, those assumptions became the reasons teams either grew around Cypress—or grew out of it.

And once you’ve been burned by enough “works on my machine / only in Chrome / only in one tab / only same-origin” edge cases, the honeymoon ends.

The Dealbreakers Cypress Couldn’t Outgrow

Let’s be blunt about the flaws that started as limitations and turned into dealbreakers.

1) Single-browser-at-a-time execution

Modern frontends aren’t just “Chrome apps.” They’re shipped to users running Chromium, Firefox, and Safari/WebKit, often all at once in the same CI pipeline.

Cypress’s execution model made “run the exact same E2E suite everywhere” more cumbersome than it should be. You can compensate with parallelization and configuration gymnastics, but you still end up with a testing strategy that feels heavier than it needs to.

E2E testing always hits auth. Whether you’re using cookies, tokens, SSO redirects, or multi-step login flows, you don’t want to repeat the same expensive login for every test case.

Cypress can do auth workflows, but the model often pushes teams toward workarounds—custom helpers, manual state management, or patterns that feel brittle when the app changes.

3) Multi-tab and window behavior aren’t optional

Real apps open new tabs, spawn popups, and rely on window context. OAuth and some third-party integrations effectively demand it.

If your E2E suite can’t reliably handle multi-tab workflows, you either stop testing the real user path or you accept chronic flakiness. Both are bad. One hides bugs. The other wastes developer time.

4) Same-origin constraints can force unnatural testing patterns

Many apps are cleanly same-origin. Many aren’t. Even when your app is “mostly” same-origin, modern architecture introduces cross-origin behavior—CDNs, identity providers, payment pages, embedded widgets, and more.

When your testing tool struggles with cross-origin realism, your E2E suite becomes less of a mirror and more of a simplified cartoon of the product.

Those are not minor inconveniences. They’re the difference between “tests that build confidence” and “tests that create doubt.”

Why Playwright Wins: Speed, Reliability, and True Multi-Browser

Playwright addresses these problems in a way that feels like a design decision, not a collection of plugins.

Multi-browser by default

Playwright runs against Chromium, Firefox, and WebKit. That means the same E2E suite is exercised across rendering engines without you rewriting everything or maintaining separate strategies.

Practically, this changes how teams plan releases. Instead of “we’ll see Safari issues later,” you get feedback early because Safari/WebKit is part of the routine.

Better reliability through auto-waiting

Flakiness is rarely about your app suddenly turning evil. It’s about mismatched assumptions: the test thinks an element is ready before the browser does, or the DOM is in flux and the click happens “too early.”

Playwright’s auto-waiting model is built to reduce these timing mismatches. You don’t have to litter tests with arbitrary wait(1000) calls just to keep them green. The result is an E2E suite that behaves more like a conversation with the UI rather than a rigid script.

Instead of forcing every test to walk through login like a ritual, Playwright lets you reuse authenticated state across the suite. In practice, teams often move toward a pattern like:

Authenticate once (e.g., via a storage state file).
Run many tests as the authenticated user.
Keep the suite focused on the behaviors that matter.

This is one of those “infrastructure” improvements that compounds. Faster tests lead to more frequent runs, which lead to earlier bug discovery, which leads to fewer “big bang” releases where nobody trusts the pipeline.

Multi-tab and window flows that match reality

OAuth, payment providers, “open in new tab,” embedded flows—these are not exotic edge cases. They’re core to modern apps.

Playwright can handle multi-page scenarios cleanly, so your E2E tests can model the real browser experience instead of forcing the product into a single-tab testing fantasy.

The Most Magic Part: Recording Tests that Actually Help

Cypress had an ace here: the runner and debugging experience made you feel like you were driving the browser. Playwright takes it further with a test generator that records your actions and produces usable code.

And “usable” is the key word. Many record-and-replay tools spit out output that looks clever but quickly turns into archaeology. Playwright’s generator produces code you can refine rather than code you must rewrite from scratch.

Here’s what that looks like in a practical workflow:

You start by recording a key user journey—say, “create an account, land on the dashboard, add an item.”
The generator gives you a scaffold for selectors, navigation, and assertions.
You review the output and replace brittle selectors with stable ones (data attributes).
You add assertions that reflect business outcomes, not just UI states.

That means you can bootstrap coverage quickly without sacrificing engineering discipline. You get the speed of automation with the maintainability you’d expect from handwritten tests.

A Practical Migration Playbook (Without the Pain)

“Cypress to Playwright” can sound like a rewrite project. It doesn’t have to be. You can migrate in slices and keep shipping.

1) Start with the highest-signal flows

Don’t port everything at once. Pick the E2E tests that:

represent core user journeys,
cover the most bug-prone areas,
run frequently in CI,
and are the most painful today (flaky timing, auth overhead, cross-origin weirdness).

If your Cypress suite is already healthy, you might migrate less urgently. But if it’s slowing you down or forcing workarounds, prioritize what hurts.

2) Standardize selectors early

A migration goes smoother when you pick a selector strategy and stick to it. The simplest, most reliable approach is usually:

data-testid for test hooks,
and minimal reliance on fragile DOM structures.

This reduces churn when UI changes.

3) Centralize auth state

If you’re wasting time logging in during every test, fix that first. In Playwright, treat authentication state as an artifact of your suite—generated once, reused everywhere.

Even if you’re migrating gradually, centralizing auth will make the new tests instantly faster and more stable than the ones that repeat login workflows.

4) Use Playwright’s expectations like product contracts

E2E tests should assert business-relevant outcomes. Instead of “click happened,” assert:

the user sees the created entity,
the cart totals are correct,
the success message appears with the right content,
and navigation lands on the right page.

This is how you avoid “tests that pass but don’t matter.”

5) Run both suites during transition

For a limited time, keep Cypress and Playwright running for coverage overlap. That gives you confidence and helps you identify gaps without halting development.

You’ll also learn quickly what kinds of flows your team needs to model differently in Playwright (especially multi-tab behavior).

Conclusion: Cypress Had a Great Run—But Playwright Is the Real Platform

Cypress earned its reputation for making E2E testing feel approachable. But the industry moved: multi-browser needs are non-negotiable, auth is too complex for repetitive flows, and modern apps increasingly rely on multi-page realities.

Playwright isn’t a “better Cypress.” It’s a more complete E2E platform designed around how browsers actually behave—fewer timing problems, first-class multi-browser support, cleaner auth state sharing, and recording that accelerates implementation without sabotaging maintainability.

If your E2E strategy is still making you fight the tool, stop fighting it. Use the one that doesn’t require you to compromise with the truth of the browser.

Vite Won the Bundler Wars and Webpack Didn't Even See It Coming

abdecastro@protonmail.com (Antonio B De Castro) — Fri, 09 Jun 2023 00:00:00 +0000

For years, JavaScript tooling followed a familiar pattern: every release came with “just one more configuration knob,” and every upgrade came with a ritual sacrifice to the build system. Webpack helped define what modern bundling could be—but it also normalized the idea that developer experience was something you had to earn through pain. Then Vite arrived with a different premise: ship less configuration, leverage the language you already use, and make the feedback loop feel instant. The result wasn’t just a new tool. It was a shift in what developers expect from the stack.

Webpack created the era—then it created the problem

Webpack’s rise wasn’t accidental. It offered a powerful mental model: everything is a module, dependency graphs get built, assets get processed, and the browser finally receives a coherent bundle. That model scaled, and it became the default language of JavaScript build tooling.

But power came with tradeoffs. Over time, Webpack didn’t merely require configuration—it incentivized complexity. Teams accumulated layered rules across webpack.config.js, custom loaders, plugin stacks, environment-specific overrides, and a constellation of flags that only a few people really understood. The build might be technically correct while still feeling operationally hostile.

You’ve seen the symptoms:

“Why is this change not reflected?” (caches, rebuilds, watch config)
“Why did the build take 90 seconds again?” (broad recompilation)
“Why does it work on my machine?” (environment divergence)
“Can someone just tweak the loader chain?” (tribal knowledge)

Webpack made bundling effective. It also made iteration expensive—and developer experience became a second-class citizen.

The “ESM-native” bet that changed everything

Vite’s breakthrough was philosophical as much as technical. Instead of treating your codebase as a bundle-first artifact, it treated the browser as a runtime for modules that can be loaded directly via ES modules.

Concretely, Vite starts a dev server that serves your source using native ESM semantics. That means you’re no longer waiting for a full production-style build just to see changes. When you edit a file, Vite can serve the updated module quickly and let the browser reload precisely what’s needed.

The impact on day-to-day work is immediate:

Fast startup: the dev server boots without performing a heavy “bundle everything” pass.
Near-instant HMR: edits propagate quickly without the ritual of full rebuilds.
Lower cognitive load: the config story is simpler and more legible.

If you’ve ever compared a slow “webpack dev server” experience to a snappy one where HMR feels like typing is directly connected to what you see on screen, you already understand why this mattered. Developer experience isn’t a luxury—it’s velocity.

Configuration became readable again

The most underrated win isn’t raw speed. It’s that Vite makes configuration feel like code you can reason about rather than a mystery incantation.

Webpack configurations often grow into sprawling files where order matters, plugin timing matters, and loader chains interact in non-obvious ways. Even when you understand it, you still have to hold the whole system in your head.

Vite flips that default. For many projects, you can start with a minimal vite.config.* and only add complexity where you actually need it. For example, a typical Vite config for a React app might look like:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

export default defineConfig({
 plugins: [react()],
})

Notice what’s missing: elaborate entry/output configuration, long loader arrays, and a dependency graph that you’re forced to model up front just to get started.

And when you do need customization, Vite’s structure tends to map cleanly to what you mean: dev server behavior, plugins for frameworks, build options, asset handling, and path aliases. In practice, this makes onboarding faster and reduces the odds that a “simple change” becomes a two-week debugging quest.

Migration is straightforward—if you plan it like an engineer

The reason Vite didn’t just win on paper is that migration doesn’t have to be a rewrite. The key is to treat it as a series of controlled transitions:

1) Start by swapping the tooling, not the app architecture

Create a new Vite project scaffold for your target framework (React/Vue/Svelte/etc.) and use it as a baseline. Then move your existing source files and adapt configuration. Keep behavior stable while you change the build pipeline.

2) Map your current bundler expectations to Vite equivalents

Common migration points include:

Entry points: Webpack’s entry becomes Vite’s index.html plus standard module imports.
Aliases: Webpack resolve.alias maps naturally to Vite resolve.alias.
Static assets: Move public assets to Vite’s public/ directory and adjust references accordingly.
Environment variables: Webpack often uses custom conventions; Vite expects import.meta.env for client-side variables.

A simple alias example in Vite:

import { defineConfig } from 'vite'

export default defineConfig({
 resolve: {
 alias: {
 '@': '/src',
 },
 },
})

3) Verify HMR behavior early

Many migrations succeed technically but feel wrong because dev workflows change. Make sure your team’s “edit → see changes” loop behaves as expected. This is where Vite usually shines, but you still need to validate framework integrations and any special tooling.

4) Fix the build output last

Only after dev is comfortable should you focus on production parity: output paths, minification expectations, and any CDN/static hosting rules. In most cases, Vite’s build is simpler to reason about, but you want to avoid surprises for deployment.

If your team treats migration like a controlled engineering rollout—not a big bang rewrite—you’ll be surprised how quickly the new workflow feels normal.

Rollup compatibility made Vite the default, not just an alternative

It’s not enough for a dev server to be fast; the production build matters. Vite’s use of Rollup under the hood is a key reason it’s been easy for teams to adopt.

Rollup’s approach encourages predictable bundling and produces outputs that many tooling chains already understand. In practical terms, that means you can often migrate without losing the “I know how to debug build output” muscle memory your team built over time with bundlers.

This is also why the ecosystem rallied quickly. Plugins for framework integrations, TypeScript support, CSS preprocessors, and common patterns fell into place fast. When a tool has a strong default path and a robust plugin system, teams stop treating configuration as a personal project and start treating it like infrastructure.

And yes—Turbopack from Vercel is chasing the “faster than fast” dream. But speed alone doesn’t win long-term. The developer experience equation includes clarity, compatibility, and the ability to survive upgrades without turning your build config into archaeology. Vite’s balance—simplicity plus production compatibility—has made it the default choice for many teams.

What “Webpack isn’t dead” actually means (and why it’s still worth switching)

Let’s be precise: Webpack isn’t dead. It still exists, and some large, customized configurations will keep running for years. If you’ve invested heavily in a specialized Webpack setup—custom loaders, legacy build quirks, tightly coupled internal tooling—it may be unrealistic to migrate immediately.

But “not dead” is not the same as “the future.” Webpack is in hospice in the sense that the center of gravity has moved. New projects overwhelmingly favor workflows that reduce iteration time, decrease configuration burden, and make the build system more legible.

The best argument for switching isn’t that Vite is trendy. It’s that Vite aligns the tooling with how modern JavaScript works:

native module semantics
fast feedback loops
configuration that scales with needs instead of forcing complexity up front

If your current Webpack setup feels like it taxes every change—even when it works—Vite offers a way out without demanding you rebuild your application from scratch.

Conclusion: the bundler wars ended where they should have—at developer experience

Webpack defined an era, but it also taught teams to accept friction as the price of building JavaScript. Vite won because it challenged the bargain: make the dev loop fast by default, make configuration understandable, and let the language ecosystem do more of the heavy lifting.

Turbopack may chase further performance gains, but Vite’s real victory is broader. It changed expectations. And once a tool makes iteration feel effortless, “impenetrable configuration” stops being acceptable—even if it used to be industry standard.

The Surprising Value of Learning a Language You'll Never Use Professionally

abdecastro@protonmail.com (Antonio B De Castro) — Fri, 02 Jun 2023 00:00:00 +0000

You don’t learn a strange programming language just to add another syntax high to your résumé. You learn it because it rewires your mental habits—so even if you never ship production code in that language, you start building better software elsewhere. After learning Haskell, Clojure, and Prolog, I stopped thinking of “different languages” as different tools and started thinking of them as different ways to reason.

And yes, I know the obvious objection: “I don’t need monads. I don’t write Clojure. I don’t deploy Prolog.” That’s exactly the point. The value isn’t the feature set. It’s the mental model.

Why “useless” languages aren’t useless

Most engineers treat language learning like skill stacking: if you don’t use the language directly, the time investment feels wasteful. But the real payoff is cognitive, not credential-based.

Programming is not only about writing code—it’s about designing decisions under constraints:

What can vary?
What must never be wrong?
How do we represent uncertainty?
How do we decompose a problem?
How do we avoid bugs that only appear when state gets complicated?

Different languages force you to answer those questions differently. Even when you return to your “main” stack—TypeScript, Python, React—you carry the patterns that prevented mistakes in the other ecosystem.

Think of it like cross-training. Learning a different sport doesn’t make you a professional in that sport. It improves your coordination—and changes what “good form” feels like when you go back to your own.

Haskell: monads don’t matter—types-first does

I learned Haskell expecting to admire functional purity. What surprised me was how quickly it trained me to design interfaces before implementing them. Not “monads in production,” but types-first thinking.

In Haskell, you feel the pressure of types the way you feel gravity: consistently. If you want to represent failure, you don’t shrug and return null; you use a type that forces callers to handle it. If you want to represent optionality, you don’t pretend it’s the default case; you make “maybe present” explicit.

Back in TypeScript, the difference shows up immediately in API design.

Example: turning “hope” into a type contract

Suppose you’re writing a function that might fail:

Bad habit: return T | null and hope callers remember to check.
Haskell-shaped habit: return a discriminated union that makes handling explicit.

In TypeScript, you can mirror Haskell’s “constructor tells you what happened” approach:

{ ok: true, value: ... }
{ ok: false, error: ... }

Now the caller can’t ignore failure without the compiler nagging them. More importantly, the interface tells the truth: failure is part of the contract, not an exception hiding in the shadows.

Another shift: designing for composition, not side effects

Haskell encourages you to build pipelines where each step transforms data and each transformation is typed. You start valuing small, pure functions—not because you love purity, but because you can reason about them.

So when I went back to TypeScript, I stopped sprinkling logic across UI components and started extracting functions that:

take well-typed inputs,
return well-typed outputs,
avoid hidden side effects.

You don’t need monads to get the benefits—you need the mindset that “an interface is a promise,” and types are how you keep that promise.

Clojure: immutable data is a state superpower

Clojure’s biggest lesson wasn’t syntax or functional flair. It was an obsession with immutable data—and the way that obsession changes how you structure state in real applications, especially React.

In mutable designs, state bugs often show up as “impossible” behavior: the UI is wrong, effects run in odd orders, a value “shouldn’t have changed,” and you spend a day hunting down who mutated it.

Clojure doesn’t let you hand-wave that away. Immutability makes every state transition explicit. You stop treating state as a thing that gets edited and start treating it as a value that gets replaced.

Example: make updates explicit with pure reducers

In React, state management often devolves into “setState whenever something happens.” With Clojure’s influence, I lean toward reducer-like patterns:

Define a state shape.
Define a small set of actions that represent transitions.
Implement transitions as pure functions: nextState = reducer(state, action).

Even if you don’t use Redux, you can adopt the mental model with React hooks:

Compute next state from current state and an event.
Keep transitions deterministic.
Avoid “update in place” patterns.

This doesn’t mean your app will magically become bug-free. It means that when something goes wrong, you can inspect the transition logic and understand how the state evolved, rather than chasing accidental mutations.

Practical advice: treat state as values, not containers

A simple rule of thumb I adopted from Clojure:

If a value represents your current app state, never “edit” it—derive the next value.

In TypeScript and Python, that means you’re less likely to mutate arrays in a reducer, less likely to patch nested objects in place, and more likely to return fresh objects.

It’s not about aesthetics. It’s about making “what happened” inspectable.

Prolog: logic thinking for constraint problems

Then there’s Prolog—logic programming that feels alien until you notice what it’s really doing: it turns certain classes of problems from “how do I compute this?” into “what conditions must be satisfied?”

That mental shift is incredibly useful in TypeScript and Python, even if you never embed Prolog in production.

Example: search and constraints are the same beast

A lot of real engineering boils down to constraints:

Find assignments that satisfy requirements.
Validate a schedule.
Determine which combinations are allowed.
Solve dependency rules.
Derive eligibility conditions.

In imperative code, you often write loops with clever pruning. In logic code, you write rules that declare relationships, and let the search engine do the exploring.

You don’t need Prolog to write constraint-focused solutions. But learning it trains you to ask:

What are the predicates?
What must be true for a solution?
How do we express relationships?
Where does backtracking happen (even if simulated)?

Practical framing: represent rules, not steps

Back in TypeScript or Python, I now approach some problems by defining rule functions or declarative constraints first. For example:

“An item is eligible if it satisfies A and B and not C.”
“A route is valid if each segment allows the transition and the total cost is under budget.”

Even if you end up implementing it imperatively, the structure you choose is more aligned with the problem. Your code becomes easier to test: you can test each predicate independently, then test the combination.

Prolog also makes you respect ambiguity and multiplicity. Instead of “the answer,” you start expecting “zero or more solutions.” That mindset reduces the temptation to oversimplify—another quiet source of production bugs.

Diversify your mental models (and your interface instincts)

The real theme across these languages is not that they share features. They don’t. It’s that each one attacks a different assumption:

Haskell pressures you to make states and failures explicit via types.
Clojure pressures you to treat data as immutable values and transitions as deliberate.
Prolog pressures you to state constraints and relationships rather than only computation steps.

When you go back to your everyday stack, you don’t just write different code—you think differently about what a “good interface” is, what “correct state” means, and how to structure complex reasoning.

A practical way to apply this immediately

Pick one current project (or one recurring kind of bug). Then apply a single “language-derived” rule:

Haskell-style: Replace null/undefined return values with explicit result types. Make failure a first-class outcome.
Clojure-style: Refactor one state update path into a pure transition function. Avoid in-place mutation.
Prolog-style: For one gnarly decision feature, identify predicates and constraints. Implement them as composable checks before wiring them together.

You’ll get benefits without changing your deployment strategy, your tooling, or your hiring posture. You’ll just improve your reasoning.

And that’s what makes the time investment feel less like trivia and more like engineering.

Conclusion: learning “unused” languages is training your engineering judgment

If you’re waiting for the day you’ll need Haskell, Clojure, or Prolog professionally, you’ll miss the point. The surprising value is that these languages teach you new ways to model correctness: types that force handling, immutable state that makes transitions legible, and logic constraints that clarify what must be true.

Learn languages you won’t ship. Let them break your habits. Then let your production code benefit from the better mental models you bring back—especially in interface design, state management, and constraint-heavy logic.

Strict TypeScript or GTFO

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 28 May 2023 00:00:00 +0000

If your TypeScript config doesn’t run with strict: true, you’re not using TypeScript—you’re writing JavaScript with extra keystrokes and a false sense of safety. TypeScript can’t magically fix sloppy typing after the fact. The discipline has to start at the compiler. Turn on strict mode, embrace the friction, and watch your codebase get cleaner, faster to navigate, and dramatically easier to change.

What “strict” actually changes (and why it matters)

TypeScript’s strict flag is a shortcut for enabling a bundle of stricter type-checking behaviors. When it’s off, the compiler becomes permissive in ways that directly undermine TypeScript’s value: it allows missing or inconsistent types, tolerates nullable mistakes, and lets implicit any slip through your codebase.

With strict mode on, TypeScript forces you to be explicit about the boundaries of your program:

Is a value possibly null or undefined, or is it guaranteed?
Does a function accept the arguments you think it does?
Are you using a property that might not exist?
Are you returning a value of the type you claimed?

This isn’t academic. Those questions correlate closely to real runtime failures—especially null/undefined crashes and “shape drift” bugs where objects change and code keeps compiling anyway.

The “sprinkled any” problem: how teams sabotage TypeScript

Here’s the pattern I’ve seen over and over: teams start with strict: false, ship quickly, and convince themselves it’s fine. Then the codebase grows. Eventually you get this:

Developers add // @ts-ignore to silence errors.
Others introduce any because the compiler is “too strict.”
Functions accept values typed as any and cast their way through the mess.

Once any exists, TypeScript stops being a safety net. any is contagious: when a value is any, operations on it don’t get checked. You’ve effectively turned the compiler into a suggestion engine.

A typical example looks like this:

function saveUser(input: any) {
 // TypeScript can’t help; everything is allowed
 const email = input.email.toLowerCase();
 return fetch("/api/users", { method: "POST", body: JSON.stringify({ email }) });
}

When this runs, you’re trusting that input.email exists and is a string. Strict mode would force you to say what you accept—or validate it. That’s the difference between “works on my machine” and “works because it’s correct.”

With strict mode, you’d end up writing something like:

type SaveUserInput = { email: string };

function saveUser(input: SaveUserInput) {
 const email = input.email.toLowerCase();
 return fetch("/api/users", { method: "POST", body: JSON.stringify({ email }) });
}

Or if you’re dealing with untrusted data, you’d validate it at the boundary. Strict mode nudges you toward that healthier architecture: types at the edge, certainty inside.

Null safety: the bug you don’t want in production

If there’s one “entire class of failures” strict mode reliably reduces, it’s null reference errors—code that assumes a value exists when it doesn’t.

Consider this non-strict code:

function greet(user: { name?: string }) {
 return "Hello " + user.name.toUpperCase();
}

If name is optional, then user.name can be undefined. Without strict null checks, TypeScript may let this slide. In production, that becomes a runtime exception:

Cannot read properties of undefined (reading 'toUpperCase')

With strict mode enabled, you’re forced to handle that reality:

function greet(user: { name?: string }) {
 const name = user.name ?? "Anonymous";
 return "Hello " + name.toUpperCase();
}

Or if name must exist, the type should reflect that:

function greet(user: { name: string }) {
 return "Hello " + user.name.toUpperCase();
}

That’s the key: strict mode makes invalid assumptions unignorable. You either change the code, validate inputs, or tighten the types until the program matches the contract.

Function signatures and refactors: confidence comes from the compiler

Strict typing isn’t only about preventing runtime crashes. It also prevents slow, painful refactors.

When you change a function signature, strict mode helps ensure every call site updates correctly. Without strict mode, mismatches can compile and fail later—often in places you didn’t think to check.

Example:

function formatUser(user: { name: string; age: number }) {
 return `${user.name} (${user.age})`;
}

If a new team member starts calling it like this:

formatUser({ name: "Sam", age: "unknown" });

Strict mode will catch it immediately. Without strict mode, you can end up passing wrong types through the system, then debugging the symptoms later.

Even better, strict mode improves editor intelligence. With correct types everywhere, autocompletion and jump-to-definition become trustworthy. Onboarding improves because the codebase is readable: the types explain the shape of your system without forcing developers to memorize it.

The result is not just fewer bugs—it’s cheaper change.

Practical setup: turning strict mode on without panicking

“Yes, it’s harder. That’s the point.” Still, you don’t have to flip the switch and walk into a compile-error avalanche. The goal is to make the compiler your ally, not your enemy.

Start by checking your tsconfig.json. At minimum:

{
 "compilerOptions": {
 "strict": true
 }
}

If you’re currently off strict mode, the first build might produce a lot of errors. Resist the urge to spam any everywhere to “get green.” Instead:

Fix the boundary errors first. Areas that ingest data from the outside world (API responses, form input, message queues, file parsing) should define clear types and perform validation.
Add precise types instead of any. When you truly don’t know the type, use unknown and narrow it. unknown is strict; it forces you to check.
Use narrowing properly. Optional fields and discriminated unions should be handled with if checks, in operators, or switch statements on tagged types.

For example, suppose you have an API response that may include different shapes:

type ApiResult =
 | { type: "success"; data: { email: string } }
 | { type: "error"; message: string };

function handleResult(result: ApiResult) {
 switch (result.type) {
 case "success":
 return result.data.email;
 case "error":
 throw new Error(result.message);
 }
}

Strict mode will help you maintain exhaustiveness. That’s how you prevent “new variant arrives and nothing updates” bugs.

If you want a migration strategy that’s actually humane, consider tightening one strictness area at a time, but keep the long-term destination clear: you want the full strict: true eventually. Half-measures tend to become permanent.

When strict mode is painful: the right kind of pain

Strict TypeScript isn’t about being precious. It’s about forcing your code to earn its correctness.

If strict mode flags dozens of issues, that’s not “the compiler being annoying.” It’s the compiler pointing at places where your program currently has implicit assumptions. Those assumptions might not fail today—but they will fail eventually, and usually during the most inconvenient moment: a refactor, a deploy, an edge-case input, or a new data shape.

So what do you do when strict mode is painful?

Stop hiding behind any. Replace it with unknown and narrow.
Don’t weaken types just to satisfy the compiler. If you lie to TypeScript, you’ll pay later.
Make nullability explicit. If a value can be absent, encode that in the type.
Treat types as documentation. Your future self will thank you.

If you’re building a real product, strictness is a form of respect—for users, for teammates, and for the person who inherits the code next.

Conclusion: strict mode is the default your future needs

Turning on TypeScript strict mode is the simplest high-leverage decision you can make in a JavaScript-to-TypeScript world. It catches null reference errors, enforces correct function signatures, and prevents a flood of silent any that erodes TypeScript’s value. The friction up front buys you reliability, onboarding speed, and refactor confidence that doesn’t rely on vibes.

So enable strict: true. Don’t “maybe later” it. If your codebase isn’t ready for strict mode, that’s your real roadmap—not an excuse to keep writing JavaScript with a TypeScript wrapper.

Turso and the Rise of Edge Databases

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 16 May 2023 00:00:00 +0000

For years, “move the database closer to the user” sounded like a nice optimization—until you tried to actually do it without turning your system into a distributed-systems science fair. Turso changes the equation by taking SQLite (yes, the tiny, ubiquitous database embedded in countless apps) and operationalizing it at the edge. The result is an architectural pattern that feels obvious in hindsight: local reads in milliseconds, global writes through replication, and application code that can live just as close to users as the data does.

Why edge databases suddenly make sense

Edge computing has matured fast: runtimes like Cloudflare Workers, Vercel Edge Functions, and similar platforms make it practical to run code near users. But most traditional database choices fight that model. If your database sits in a distant region, every query pays the latency tax. If you “shard by region,” you immediately inherit distributed consistency problems. And if you try to replicate, you need a replication strategy, conflict handling, and tooling that doesn’t turn every deploy into a gamble.

The core promise of an edge database is simple: keep the critical working set close to where the user is. Not in theory—on purpose. Not “eventually,” unless that tradeoff is acceptable. Practically, it means you want:

Low-latency reads near the user
Predictable write behavior that still scales globally
A model you can operate without rewriting your organization’s entire playbook

This is where Turso’s approach lands: SQLite at the edge, with replication that keeps regional data patterns coherent enough for real applications.

SQLite at the edge: the underrated starting point

SQLite’s reputation is usually confined to embedded devices and single-node apps. But SQLite has two traits that make it a surprisingly good candidate for edge distribution:

It’s compact and fast to initialize. You don’t need a heavyweight server process per region just to serve basic queries.
Its developer experience is straightforward. SQL schemas, migrations, and local testing are familiar and cheap.

Turso effectively treats “SQLite everywhere” as a deployable architecture rather than a local convenience. Instead of building a custom distributed database system, you distribute the SQLite data plane. Reads happen locally at the edge location. Writes replicate so that other regions converge over time.

That combination matters. The “edge database” pattern fails when you optimize only for locality (fast reads) but ignore correctness and operational realism (how writes propagate, how you handle failures, how you roll out schema changes). Turso’s core value is giving you a pragmatic path to that balance, using a database model many teams already know.

The replication model: local reads, global writes

Think about what you’re actually optimizing. For most apps, the biggest user-perceived latency is in the time to serve reads—fetching feeds, retrieving profiles, loading cached metadata, or rendering parts of a page. Writes are usually less frequent and more forgiving in how long they can take, as long as the system eventually reflects changes reliably.

An edge SQLite system aligns with that reality:

Local reads: Your edge worker hits a nearby database replica, so “get this record” feels instant.
Global writes: Updates are sent through replication to keep other edge locations informed.
Consistency by design choice: You’re not trying to pretend the speed of light doesn’t exist. You’re designing for the tradeoffs your application can tolerate.

To make this tangible, consider an e-commerce browsing experience:

A user in London requests the latest product availability and pricing.
The edge database serves that read locally—no cross-Atlantic delay.
When the inventory system updates a product, the write replicates out so that Paris, Frankfurt, and other nearby edges reflect the change without waiting for a centralized database.

This isn’t “one true database” in the philosophical sense. It’s a practical distributed system where performance is local and propagation is global.

Pairing Turso with edge compute (without overengineering)

Edge databases become powerful when you combine them with edge compute—especially request-driven runtimes like Cloudflare Workers. The pattern is straightforward:

Run your API logic at the edge.
Query the edge SQLite replica for reads.
Write updates when necessary, letting replication handle distribution.

Here’s the practical advantage: your application’s hot path can avoid round-trips to a far-away data center. Instead, your “code and data are near the user,” which reduces latency and simplifies the tuning you’d otherwise do with caching layers.

A concrete example: a multi-region content app.

Writers update articles.
Readers browse feeds and view article summaries.
The edge layer needs to answer “what should I show right now?” with minimal latency.

With edge SQLite, the feed and summary reads can be local. When writers publish or update content, the writes replicate. The system can be designed so that clients tolerate a short propagation window—often acceptable for feeds and non-critical UI content.

Where you should resist temptation: don’t try to force complex transactional workflows into an edge replication model. If you’re building a ledger-like system where every operation must be strongly consistent across regions, PostgreSQL (or another strongly consistent database) will likely fit better. Edge databases shine when your workload is read-heavy and your data naturally clusters by region or by access pattern.

When edge SQLite is a great fit (and when it isn’t)

The most productive way to think about Turso is not “replace PostgreSQL,” but “apply a different database geometry to different problems.”

Great fits

Read-heavy applications: dashboards, feeds, browsing experiences, search-adjacent metadata, configuration retrieval.
Regional data patterns: content localized by geography, latency-sensitive personalization, or region-specific datasets.
User-facing performance wins: anything where tens or hundreds of milliseconds matter to conversion or perceived responsiveness.
Stateless edge APIs: edge functions that act like fast query frontends with occasional updates.

Less ideal fits

Complex cross-record transactions across regions: if correctness depends on strict global ordering, edge replication may complicate matters.
Write-dominant workloads: replication cost and propagation windows can outweigh benefits.
Systems requiring strong, immediate consistency guarantees everywhere: you can often build around eventual behavior, but you shouldn’t pretend it’s the same as single-node transactional semantics.

A good rule of thumb: if your product can tolerate “the update is visible everywhere soon,” edge SQLite is compelling. If it requires “the update is visible everywhere right now,” you’ll probably want a centralized, strongly consistent store or a hybrid design.

Operational reality: schemas, migrations, and rollouts

It’s easy to get seduced by latency graphs. The real work is keeping the system healthy over time. With edge SQLite, operational concerns look different than with a single managed cluster, but they’re still manageable if you stay disciplined.

Practical advice for running an edge SQLite setup:

Treat migrations like releases. Schema changes should be versioned and rolled out deliberately, not improvised during peak traffic.
Keep edge queries simple. Avoid overly complex joins that are expensive and hard to reason about across replicated data. Edge is about speed and predictability.
Design with propagation in mind. If a user updates something and immediately reads it, decide what behavior you want:
- Prefer the local edge replica to reflect the write quickly, or
- Accept a brief window where reads reflect the pre-update state.
Instrument the propagation path. Log replication lag and failures as first-class signals. If you ignore it, you’ll eventually debug it under pressure.

The biggest mindset shift is accepting that “distributed” isn’t a theoretical label—it’s an operational domain. But the good news is you don’t have to build everything yourself. The value of Turso is that you’re standing on a battle-tested foundation while still getting the performance benefits of edge locality.

Conclusion: the edge database pattern is finally practical

Turso and the rise of edge databases aren’t about chasing hype. They’re about aligning architecture with the constraints that always existed—latency, geography, and operational complexity—and choosing a database distribution model that actually matches how users interact with your app. SQLite at the edge gives you local reads where they matter, replication for global updates, and an approachable development experience that teams can adopt without reinventing their stack.

Edge SQLite isn’t a universal replacement for PostgreSQL. It’s better framed as a new default for read-heavy, region-sensitive workloads. When your product’s performance hinges on proximity, Turso’s paradigm shift can feel less like innovation and more like the missing piece you should have had all along.

Why I Switched My Personal Projects to Fly.io

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 10 May 2023 00:00:00 +0000

I didn’t “discover” Fly.io so much as I got tired of duct-taping infrastructure together—again. Every personal project eventually turns into a mini platform: builds, deploys, databases, secrets, scaling, logs, rollbacks. After enough cycles, you stop asking “can I deploy this?” and start asking “why does deploying this feel like a punishment?” That’s the moment Fly.io clicked for me.

The real problem wasn’t hosting—it was friction

Most hosting platforms make one thing easy (usually “getting a server running”) and then quietly add friction everywhere else. For personal projects, that friction compounds:

Deployment feels fragile. Small changes trigger big ceremony: build steps, env wiring, migrations, rollbacks.
The database becomes a separate world. You end up juggling connection strings, backups, failover, and version mismatches—on top of your app.
Scaling is either hand-wavy or expensive. You either guess and over-provision or get surprised when traffic grows.
Tooling gets in your way. The CLI should reduce cognitive load, not create a new set of commands you memorize once and regret forever.

Fly.io attacked this as a systems problem. Instead of pretending everything is “just a button,” it gives you primitives that map cleanly to how apps actually run: containers, networks, storage, databases, and a control plane that doesn’t require you to be an infrastructure engineer.

Edge deployment that doesn’t feel like a gimmick

Fly’s core idea is simple: run your workloads closer to users. The practical payoff is lower latency and a deployment model that scales beyond a single region without you building a whole geographic strategy from scratch.

In my case, I was building a small web app with an API and a dashboard. Users weren’t concentrated in one place, and I didn’t want to over-engineer. On Fly, I could ship the same Docker image and rely on Fly’s global infrastructure to handle placement.

Here’s the concrete difference I noticed when comparing approaches:

On “traditional” setups, I’d deploy to one region and then spend time convincing myself that performance was “good enough.”
On Fly, performance became a default rather than a compromise. If a user is in a different geography, the app doesn’t have to wait for the slowest link in my architecture decisions.

The key is that Fly still uses Docker containers as the deployment unit. That matters because it keeps your workflow consistent: build once, run anywhere within the Fly model, and don’t rewrite how you ship just because the hosting provider is fashionable.

Deployments become boring (in the best way)

Let’s talk about Docker—because for once, Docker isn’t the chore people fear. The workflow is straightforward:

Build a Docker image for your app.
Deploy it to Fly using the CLI.
Configure environment variables, ports, and services.
Let Fly run it where it makes sense.

The best part is the CLI experience. I’m not easily impressed by tools, but Fly’s CLI genuinely reduced my number of “what now?” moments. Commands are predictable. Feedback is helpful. You can tell what’s happening without squinting at logs like you’re decoding a firmware update.

A personal example: I had a small Rails app that I rebuilt and redeployed frequently while iterating. With Fly, the “inner loop” felt tight. I could deploy, check health, inspect logs, and iterate quickly without turning deployment into a recurring afternoon.

And because everything is containerized, you can keep local and remote behavior aligned. Your Dockerfile becomes the contract. That’s how you stop “works on my machine” from turning into “works in production, except when it doesn’t.”

Built-in Postgres, Redis, and LiteFS: less glue code

Databases are where projects go to die—not because databases are hard, but because the integration surface area is huge. You start worrying about provisioning, networking, migrations, backups, and failover, and suddenly your app is no longer the main character.

Fly’s built-in services changed the tone. Instead of assembling a database stack from separate vendors and then babysitting connectivity, I could treat Postgres and Redis as first-class components of the app.

Even more interesting is LiteFS, which gives you SQLite replication via a mechanism designed to keep developer workflows sane. For projects that benefit from SQLite (common for personal tooling, small APIs, and “I want speed without operational drag” apps), LiteFS is a pragmatic bridge: you get the simplicity of SQLite while still aiming for multi-instance resilience.

What I did in practice:

Use Postgres for apps where the relational model is the point and concurrency matters.
Use SQLite for early-stage or lightweight services where operational simplicity wins.
Add LiteFS when I want SQLite’s ergonomics without pretending single-instance is a long-term strategy.

The point isn’t that one database is always best. It’s that Fly gives you options without forcing you to learn and manage an entire ecosystem just to run queries.

Scaling to zero feels possible, not theoretical

One of the most underrated features for personal projects is the ability to scale to zero. When your app isn’t receiving traffic, you shouldn’t have to pay for idle resources—or keep processes running “just because.”

Fly’s Machines API makes scaling explicit and controllable. You can model your service instances instead of treating scaling as an opaque side effect of someone else’s defaults.

In other words: if you want your app to wake up on demand, you’re not stuck with the idea that it must always be on. For my projects, this translated into less worry about “did I just leave something running all weekend?” and more freedom to experiment.

This is also where Fly’s container-based approach shines again. When your workload is a machine definition, scaling becomes a workflow action, not a reconfiguration wizard.

The pricing reality: cheaper than you expect, generous where it matters

Pricing is always a trade-off, but what I appreciated about Fly is that the free tier is usable for real personal projects—not just a demo environment you outgrow in a week.

On the paid side, Fly also felt like it was pricing for developers who don’t want to do cost math every time they deploy. While I won’t pretend every workload maps perfectly, the overall experience for small systems was what I cared about: I could run a meaningful setup without feeling like I was renting a production-grade machine just to host a hobby.

The best comparison isn’t a spreadsheet anyway—it’s your actual monthly behavior. When your stack is frictionless, you deploy more confidently, and the platform stops being a “cost center” you avoid and starts being a tool you rely on.

What switching actually changed in my workflow

After moving personal projects to Fly.io, the biggest change wasn’t performance or cost first—it was confidence.

I shipped more often. Deployments were less intimidating.
I spent more time on the app. Fewer evenings went into infrastructure cleanup.
I stopped re-learning the basics. The same Docker-first model repeated across projects.
I had fewer “mystery failures.” Built-in services reduced configuration surface area.
Scaling felt like a knob, not a gamble. Machines made it concrete.

If you’re still on Heroku-style patterns (or you’re stuck in the “deployments are a ritual” phase), Fly offers a modern alternative: infrastructure primitives that feel approachable, not overwhelming.

And yes—Fly feels like what Heroku would look like if it were built today with better defaults and cleaner operational semantics. Not because it’s flashy, but because it respects the fact that developers want to build software, not babysit pipelines.

Conclusion: Fly.io is the platform I reach for first now

I switched my personal projects to Fly.io because it solved the problems that always show up: Docker-based deployments, built-in Postgres/Redis, LiteFS for SQLite replication, and a CLI that doesn’t drain my patience. Add edge deployment and Machines-based scaling (including to zero), and you get a platform that fits the way solo developers and small teams actually work.

If you want your projects to feel lighter—technically and emotionally—Fly.io is one of the few choices that makes that promise real.

We Put Rust in Production for Six Months. Here's What Actually Happened.

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 04 May 2023 00:00:00 +0000

Replacing a production service is easy to justify in a slide deck and brutally hard to live through. We swapped our highest-throughput Python microservice for Rust with the usual promise: faster, cheaper, more reliable. And yes—those benefits showed up. But the story isn’t “Rust fixes everything.” It’s “Rust fixed some things, while making other problems newly visible.” Here’s what really happened over six months, beyond the hype.

The starting point: why we touched the service at all

Our Python service sat at the center of a high-traffic workflow. It wasn’t “toy” code: it was a core dependency with steady load, strict latency goals, and a performance profile that made ops tired of refreshing dashboards.

The pain was recognizable:

Latency: tail latency (p95/p99) was consistently worse than we wanted, especially under bursts.
Resource pressure: memory usage climbed with traffic; GC churn and fragmentation-like symptoms showed up in metrics and flame graphs.
Cost: we were paying for scale and still not getting “smooth” performance.

The simplest pitch to stakeholders was: “Rust will help us run the same workload with fewer resources and better predictability.” We sold the rewrite as a targeted modernization, not a wholesale replatform.

Then reality started writing its own requirements.

The plan we made (and how it went wrong)

We estimated the rewrite would take “a few months.” That assumption was optimistic in a way only experienced teams can manage: we treated code migration as mostly mechanical. We underestimated the amount of time required to:

Understand the old service’s behavior deeply (not just read the code, but understand its edge cases and implicit contracts).
Recreate correctness under concurrency (Python masked a lot of sins with fewer threads and more forgiving timing).
Build missing safety rails (tests, benchmarks, and observability weren’t as complete as we needed).

The rewrite took roughly 3× longer than estimated. The cause wasn’t Rust “being slow.” It was that migrating a production service is less like translating syntax and more like re-learning the system.

A practical example: the “it works locally” trap

We had a path that behaved fine in dev, then failed under load with subtle timing issues. In Python, the bug was partly hidden by the service model and by how execution interleaved. In Rust, everything was faster—and the faster version exposed the order-of-operations problem more clearly.

We ended up spending time building instrumentation that we should have had from day one: request tracing across internal calls, structured logs that included correlation IDs, and benchmark harnesses that reproduced the hot paths.

If you’re considering a rewrite, treat test/bench/trace work as first-class deliverables—not as cleanup after the “real” coding.

What improved in production (and what didn’t)

After rollout, the benefits were real, measurable, and—importantly—stable rather than accidental.

Latency dropped dramatically

Our latency improved substantially—about a 94% drop in the metric we cared about most. What mattered wasn’t just average speed. It was predictability under load. Rust helped us reduce overhead in the hot path and avoid the “performance cliff” behavior we saw in Python when traffic spiked.

Memory usage fell hard

We also saw ~80% lower memory usage for the service. A big part of that was simply running fewer processes / smaller footprints to achieve the same throughput, which became possible once we stopped paying the cost of Python runtime overhead and GC dynamics.

The AWS bill moved

Finally, the service got cheaper: we saw ~60% reduction in the AWS spend attributable to that microservice.

Those numbers weren’t magic. They were the sum of less runtime overhead, more efficient handling of hot data paths, and a capacity plan that matched reality rather than optimism.

What didn’t automatically improve

Rust didn’t magically make our architecture better. If the service was slow because of an external dependency or a chatty interface, rewriting it wouldn’t fix that. In fact, in a few places we had to admit that the biggest wins came from tightening up:

request batching strategy
data serialization format and size
internal allocation patterns
concurrency model and backpressure

Rust gave us the tools; we still had to use them like adults.

The “hard parts” nobody tells you about

This is the section I wish we’d read before we started. Rust can be amazing, but it also has sharp edges that show up in the real world.

Compile times will test your patience

Compile times are not theoretical. During active development, iteration speed became a bottleneck. We mitigated it with practical tactics:

Limit what rebuilds: keep module boundaries clean and avoid broad dependency graphs.
Use incremental builds where possible.
Automate dev loops: wire up “compile + run + smoke test” commands so you’re not manually doing five steps every time.

Even then, the first time you change a core module and watch a full rebuild churn through your machine, you feel it.

Hiring Rust developers is nearly impossible

This was the biggest operational surprise. We assumed “there are plenty of Rust devs.” In practice, for our needs—production experience with async, networking, observability, and a willingness to write unsafe-free code unless you truly mean it—we had fewer options than we wanted.

We had to do one or more of the following:

hire slower than planned
rely on internal training
accept a temporary productivity dip while people ramped up

Rust is not just a language switch; it’s a hiring and onboarding switch. If your timeline depends on filling seats quickly, plan for friction.

The rewrite took longer because “correctness” costs time

Rust’s ownership model is a gift, but it also forces you to confront design problems that dynamic languages can sometimes paper over. During the rewrite, we spent time on:

lifetime and ownership boundaries
data structure choices that reduce copying without overcomplicating
error handling paths that we previously ignored

That work is worthwhile. But it isn’t “free.” It’s more like prepaying bugs at compile time rather than discovering them at runtime.

How we made Rust work: a production playbook

If you want a rewrite to actually succeed, here’s what helped most for us.

1) Treat performance engineering as part of the spec

Before porting anything, we established a benchmark plan for hot paths:

microbenchmarks for isolated functions
load tests for end-to-end behavior
profiling during both development and rollout

When performance claims are just vibes, you lose time later. With benchmarks in place, you can make tradeoffs intentionally—like whether to optimize allocation patterns or to change the concurrency strategy first.

2) Build observability early, not after the rewrite

Rust services can be “correct” and still be opaque. You need:

structured logging with request IDs
metrics for queue depth, processing time, and error categories
tracing across internal boundaries if you have multiple services

We learned this the hard way: once the service was faster, problems moved from “obviously slow” to “fast but wrong.” Better visibility mattered.

3) Choose a concurrency model you can explain on a whiteboard

Rust’s async ecosystem is powerful, but teams can create chaos by mixing patterns. We standardized our approach early, especially around:

how work is spawned
where backpressure happens
how cancellation and timeouts are handled

This reduced incident complexity and made code reviews faster.

4) Don’t rewrite everything—identify the hot path

The most important strategic decision was scope. We targeted our highest-throughput microservice and avoided a “Rust everything” impulse. The reason evangelists oversell Rust is that they often assume the bottlenecks align with CPU/memory overhead alone.

In our case, the hot path was where Rust paid off. Other parts of the system were limited by external calls and orchestration—not by Python’s runtime characteristics. Those areas didn’t justify the migration cost.

The verdict: worth it, but only for the right constraints

Rust in production is absolutely worth it for certain problems. When your service is performance-critical, allocation-heavy, latency-sensitive, and you can invest in engineering rigor, Rust can deliver measurable gains quickly after the dust settles.

But we also learned that “the right use cases” are narrower than the hype implies. If your service is mostly bound by network latency, third-party dependencies, or system design flaws that Rust can’t fix, a rewrite becomes expensive theater.

And if your organization can’t support:

the time cost of correctness work
compile-time iteration overhead
hiring/training for Rust production expertise

…then the rewrite may turn into a multi-quarter tax with uncertain ROI.

After six months, we don’t regret switching. We’re just more realistic about what to expect. The rewrite wasn’t a magic wand. It was a disciplined trade: we spent time and complexity upfront to buy performance predictability, memory efficiency, and lower operational cost.

Conclusion

Rust gave us real production improvements—lower latency, lower memory usage, and a lower bill. But the true lesson isn’t “Rust is better than Python.” It’s that a rewrite is a systems project: scope, testing, benchmarking, observability, hiring, and iteration speed all determine whether you get value or just accumulate complexity.

If you’re considering Rust, be selective. Pick the parts of your system where performance constraints are actually inside your control, and build the safety rails before you start typing. That’s the path from hype to payoff.

PostgreSQL Dethroned MySQL and the Implications Are Huge

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 22 Apr 2023 00:00:00 +0000

For years, “just use MySQL” was treated like database common sense—especially if you wanted to ship fast and avoid the complexity of “that other SQL.” But when PostgreSQL became the default choice for more developers than MySQL, it wasn’t a cosmetic change. It signaled a worldview shift: developers are increasingly selecting databases based on real capabilities, not convenience.

The quiet end of “whatever comes with hosting”

The old logic behind MySQL’s dominance was simple: it’s everywhere. It ships with tons of hosting stacks, tutorials assume it, and most teams never had to ask whether they actually needed anything more.

But popularity isn’t the same thing as fit. MySQL became the default because it was easy to deploy, not because it was the strongest long-term foundation for modern application patterns. PostgreSQL’s rise reflects a more modern decision-making loop:

You start with the problem (search, analytics, event logs, geospatial queries, background jobs).
You evaluate database capabilities against that problem.
You pick the database that reduces architectural contortions later.

In other words, teams are moving from “pick a database that’s convenient” to “pick a database that’s strategically correct.”

PostgreSQL’s real superpower: it adapts to your workload

PostgreSQL isn’t “just a relational database,” and that’s the point. It can cover multiple roles in the same system, which means fewer bolt-on services, fewer synchronization problems, and fewer “write it twice” compromises.

Here are a few concrete ways teams actually use that flexibility:

Document-style data without abandoning SQL discipline

PostgreSQL’s JSONB support lets you store semi-structured documents while retaining relational strengths like indexing and query capabilities. For example, you might store user preferences as JSON, but still enforce constraints elsewhere and join cleanly to normalized tables.

Practical takeaway: use JSONB for fields that change shape, not as a substitute for modeling when the domain is stable.

Time-series patterns without duct-taping

If your app tracks events—prices, sensor readings, clicks—PostgreSQL can handle time-based queries efficiently with the right schema and indexes. In many teams, this avoids spinning up a separate time-series database just to run “show me the last 7 days” queries.

Practical takeaway: model time-series data with clear partitioning strategies (or at least indexes) early; don’t wait until dashboards are slow.

Geospatial and “location-aware” features that don’t feel hacked

PostgreSQL is strong for geospatial data. If your product is map-driven—delivery zones, user proximity, route filtering—PostGIS-style workflows can keep those queries close to the data they depend on.

Practical takeaway: if your domain includes geography, treat it as a first-class requirement, not a later add-on.

Vector search without treating your database like a leaky cache

Vector support in PostgreSQL enables embedding storage and similarity queries in the same transactional system as your relational data. That matters because your “what” (entities, permissions, metadata) often lives in relational tables, while your “how similar” lives in vectors. When the DB can do both, the application logic gets simpler and consistency gets better.

Practical takeaway: if your ranking depends on both vector similarity and relational constraints (e.g., “only show results the user is allowed to see”), co-locating vectors with relational data can reduce query gymnastics.

The underlying message is blunt: PostgreSQL gives developers fewer reasons to offload parts of the workload into special-purpose databases just because the original database couldn’t handle it cleanly.

The extensibility advantage: SQL that doesn’t cap your ambitions

The phrase “extensibility” can sound like marketing fluff until you’ve lived through what happens when you hit a wall.

When a database is extensible, you can add capabilities without abandoning your existing schema, deployment model, and operational reality. PostgreSQL’s extension ecosystem—plus its ability to support advanced features natively—means teams can evolve without starting over.

A practical example: imagine you need to implement custom scoring for search results. With a database that supports server-side logic and rich indexing, you can push more work toward the data layer. You might end up with:

SQL functions for deterministic scoring
indexing strategies that make ranking queries fast enough
consistent behavior across services because logic lives in the database

That reduces drift: no more “service A computes scoring a little differently than service B” because the logic isn’t replicated everywhere.

Developers choosing capability over default convenience

This is the real implication behind “Postgres overtook MySQL”: the industry is learning to stop treating databases as plumbing.

Modern development pushes for tight feedback loops. You iterate quickly. Your schema changes frequently. Your product grows into new use cases. The cost of choosing a database that’s merely “good enough at day one” becomes a tax you pay every time you need to do something slightly unusual.

PostgreSQL, as a category, supports a wider range of patterns without requiring a new platform for each pattern. That affects more than architecture diagrams—it affects team velocity:

fewer migrations between databases because one finally “can’t do it”
fewer services to secure, monitor, and maintain
fewer edge cases around consistency and replication

If you’ve ever spent weeks coordinating cross-service data correctness problems, you know why teams get enthusiastic about putting more capability inside the database that already owns the truth.

What this shift means for teams right now

It’s easy to celebrate a “winner,” but what matters is the action you take next.

If you’re starting a new project

Don’t pick PostgreSQL because it’s trending—pick it because its strengths match your roadmap. Ask questions like:

Do you need semi-structured data with queryable fields?
Are you likely to add search, geospatial, analytics, or vector retrieval?
Do you want application logic to remain consistent when requirements change?
Are you aiming to reduce the number of supporting data services?

If you can answer “yes” to even a couple, PostgreSQL is often the safer bet.

If you’re on MySQL today

You’re not obligated to panic or rewrite everything. Instead, be tactical:

Identify the first pain point that MySQL creates (query complexity, indexing limits, evolving data shape, performance under mixed workloads).
Evaluate whether PostgreSQL would remove that pain in a way that reduces system complexity—not just “improves performance on one query.”
Pilot migration for a bounded workload (one service, one dataset subset) and measure not only latency, but operational overhead and developer effort.

The best migrations are boring. They start with a real workload and a clear definition of “success.”

If you’re hiring and standardizing stacks

Your database choice influences hiring patterns, onboarding time, and tooling. When PostgreSQL becomes the default, you benefit from a larger pool of developers who already know how to model data using constraints, indexes, and extensions—and who can troubleshoot issues without guessing.

Standardization also affects observability. You’ll want consistent metrics for query performance, lock contention, slow query logs, and index usage across environments. PostgreSQL’s ecosystem and tools make this easier—if you treat it as part of your engineering practice, not a one-time setup.

Conclusion: PostgreSQL isn’t just winning—it’s changing the decision model

PostgreSQL overtaking MySQL isn’t merely a shift in ranking. It’s a signal that developers are selecting databases as strategic platforms, not as pre-installed conveniences. The implications are huge because the database you choose shapes how easily you can evolve your product—whether that evolution involves semi-structured data, geospatial queries, time-based analytics, or vector search.

The era of “just use MySQL because it’s easy” is over. The next era is about fit: picking the database that lets your application grow without making you rebuild your foundations every time your requirements get interesting.

Zod Changed How I Think About Validation

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 10 Apr 2023 00:00:00 +0000

I used to treat validation like paperwork: something you do at the edges “just in case.” Then I learned what TypeScript really does when the program runs: it doesn’t validate anything. Your types evaporate, and the real world leaks in—API responses, form data, environment variables, file uploads—turning “type-safe” code into a polite fiction. Zod didn’t just improve my validation. It changed how I reason about correctness in TypeScript.

The moment types stop mattering

TypeScript’s type system is brilliant—at compile time. But at runtime, it’s gone. That’s not a bug; it’s how the language works. Once your application is running, any silently wins the argument.

Consider a typical boundary:

You call an API endpoint.
You receive JSON.
You trust that it matches your TypeScript types.

If that JSON is wrong—because of a backend change, a bad deploy, a malicious client, or even a subtle bug—you won’t know until something breaks later. And by then, the stack trace is often downstream from the actual cause, which makes debugging slower and more expensive.

This is why “types-as-suggestions” becomes a daily reality. TypeScript may help you write correct code, but it can’t guarantee that your inputs are correct.

Validation isn’t optional—just misplaced

Before Zod, I’d sprinkle validation in a scattered way: ad-hoc checks, if statements, a few runtime asserts, maybe a lightweight schema somewhere in the backend. The trouble is placement. Validation after you’ve already assumed a shape leads to the classic failure mode:

“The API returned something I didn’t expect,” but the error appears two layers later when you try to access a property.

Instead of validating at the boundary, many projects validate “somewhere near” the boundary, hoping it’s close enough. It usually isn’t.

Here’s a concrete example. Let’s say you expect this from an API:

type User = { id: string; name: string; email?: string };

You fetch it, then do:

const user = await getUser(id);
console.log(user.email?.toLowerCase());

If the backend accidentally returns { id: 123, username: "..." }, TypeScript won’t help at runtime. You’ll get user.email is undefined or—worse—an exception when you call .toLowerCase() on a value that isn’t a string.

Zod pushes validation to the correct location: right where untrusted data crosses into your typed world.

Zod: one schema, two guarantees

Zod changes the workflow by making your schema the source of truth. You define what you accept once, and you get:

Runtime validation: real checks while the program runs.
Type inference: compile-time types derived from the schema.

That combination is the whole point. You stop writing “types” that look correct to the compiler but do nothing to protect the program when reality disagrees.

A Zod schema for a User might look like this:

import { z } from "zod";

const UserSchema = z.object({
 id: z.string(),
 name: z.string(),
 email: z.string().email().optional(),
});

type User = z.infer<typeof UserSchema>;

Now your API boundary becomes explicit:

const raw = await getUser(id); // unknown, from the real world
const user = UserSchema.parse(raw); // validates or throws

If the payload is wrong, you fail immediately and locally, right where the assumption is made. That single shift—validating at the edge—eliminates an entire class of bugs.

Parsing vs. “just checking”

Zod’s parse() gives you a hard guarantee: either you get a valid typed value or you throw. There’s no pretending.

If you want a non-throwing approach, Zod also provides safeParse():

const result = UserSchema.safeParse(raw);
if (!result.success) {
 // handle validation errors cleanly
 return;
}
const user = result.data;

In practice, I prefer parse() for internal invariants and safeParse() when I’m building user-facing error handling (like form submission feedback).

Turning validation into a system (not a chore)

The best part of Zod isn’t the syntax—it’s the discipline it encourages. Your schemas become reusable assets instead of one-off checks.

Forms: validate where the user submits

When form data is involved, the input is almost always untrusted: everything starts as strings, numbers may arrive as malformed strings, optional fields might be missing, and browsers are inconsistent in edge cases.

Zod makes it easy to model the exact input contract. For example, a login form:

const LoginSchema = z.object({
 email: z.string().email(),
 password: z.string().min(8),
});

Then, on submit:

const raw = Object.fromEntries(new FormData(form));
const data = LoginSchema.parse(raw);
await login(data.email, data.password);

You’ll notice what’s happening: you’re not “validating fields somewhere.” You’re validating the entire payload as a single unit right before you use it.

That’s how you avoid the slow creep of partial checks that miss a field you didn’t think about.

Environment variables: validate at startup

Environment variables are the silent source of runtime “unknown.” They’re strings. Sometimes empty. Sometimes missing. Sometimes set differently across deployments.

With Zod, you can validate immediately on boot:

const EnvSchema = z.object({
 PORT: z.coerce.number().int().min(1).max(65535),
 NODE_ENV: z.enum(["development", "production", "test"]),
});

const env = EnvSchema.parse(process.env);

Now your application fails fast with a clear reason instead of stumbling later with strange behavior. You also get types for env.PORT and env.NODE_ENV without manual duplication.

tRPC + Zod: end-to-end type safety in real life

Zod alone already changes your runtime story. But the real payoff shows up when you combine it with end-to-end frameworks like tRPC—where types flow across the network instead of resetting to “just JSON.”

The pattern looks like this:

Define a Zod schema for inputs/outputs.
Use the inferred types in your TypeScript code.
Ensure the client and server agree on the shape of data.
Validate at the boundary so malformed data can’t masquerade as valid types.

If you’ve ever experienced the horror of a frontend and backend “agreeing” for weeks and then failing on deploy, you understand why this matters. A schema-driven approach makes contract changes intentional: if you update the contract, you update the schema, and the rest of the code follows.

Even better, errors become actionable. Instead of chasing a downstream Cannot read property 'x' of undefined, you get validation feedback that says the payload was wrong for the expected schema. That’s not just safer—it’s dramatically faster to debug.

What I’d say to teams still without Zod

If you’re writing TypeScript without runtime validation, you’re not “being productive.” You’re deferring risk. The compiler will help you with internal correctness, but it cannot protect you from external inputs. Sooner or later, something outside your codebase disagrees with your types.

My opinionated recommendation:

Treat every boundary as unknown.
Validate with Zod immediately on entry.
Prefer schema-first designs where the schema drives both runtime behavior and TypeScript types.
When possible, share schemas across client/server to keep the contract tight.

A small migration can deliver outsized returns. Start with your most critical boundaries: login/signup payloads, payment requests, environment config, and any endpoint that drives UI state. Those are where unexpected shapes turn into the most painful failures.

Conclusion: correctness that survives contact with reality

Zod changed how I think about validation because it removed the split between “what TypeScript says” and “what actually happens.” Types are great—until runtime arrives. With Zod, your schemas enforce reality at the edges, and your TypeScript types stay in sync automatically. Add tRPC and you get end-to-end contracts that don’t crumble the moment JSON shows up.

If you want fewer “API returned something weird” bugs, stop treating validation as optional. Put your guarantees where they belong: at the boundary.

Serverless Was Overhyped (But the Right Parts Won)

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 03 Apr 2023 00:00:00 +0000

“Serverless” didn’t fail because the technology was bad—it failed because people tried to use it for the one thing it was never designed to be great at. In the 2018–2020 boom cycle, teams treated Lambda like a universal solvent for application architecture. The result was predictable: broken assumptions, latency surprises, and brittle designs that collapsed under real traffic and real state.

But here’s the revisionist truth worth keeping: serverless didn’t replace servers. It carved out a few genuinely excellent niches. And if you use it for those niches—event-driven processing, scheduled jobs, webhook handlers, and the kind of pipelines that naturally flow through queues and storage—it’s not just acceptable. It’s often the best tool in the box.

The “serverless everything” mistake

The hype train sold a simple promise: stop managing servers, scale automatically, pay only for what you use. That’s all true—at least at the level of individual services. The problem was how quickly “no servers” became a design philosophy instead of an implementation detail.

Most applications aren’t stateless monoliths you can decompose into independent functions with zero friction. They need at least some of the following:

Persistent connections (WebSockets, long-lived database sessions, streaming responses)
Local state that lives for the lifetime of a request flow
Predictable latency for interactive UX
Operational habits that assume warm process lifecycles and stable execution contexts

Serverless can sometimes mimic these patterns, but the cost is usually hidden complexity—clever caching strategies, fragile workarounds for state, and “best effort” latency management. Teams learned the hard way that architecture is about constraints, not slogans.

My favorite example from that era: the “Lambda behind API Gateway for a REST API” pattern used as a default. For lightweight endpoints, it can work. But when you wrap every endpoint in a serverless façade without thinking through connection behavior, timeouts, request/response size, observability, and warm-up realities, you end up optimizing for convenience instead of performance and reliability. In many cases, the experience wasn’t dramatically better than running a small fleet of containers—and the failure modes were different enough to make troubleshooting more annoying.

Why serverless never meant “no state,” just “no babysitting”

Serverless functions are ephemeral execution environments. That does not mean you can’t build stateful systems. It means you must externalize state.

That distinction is where teams either matured—or burned time. A healthy serverless architecture assumes:

Compute is disposable.
State lives outside the function.
You design for idempotency because retries happen.
You treat timeouts and concurrency as first-class constraints.

So instead of trying to keep “session state” in memory, you store it in something like Redis or a database. Instead of assuming a function will always run once, you design for “run it again safely.” Instead of expecting a request to have unbounded duration, you set time budgets and push longer workflows into asynchronous pipelines.

This framing turns “serverless limitations” into straightforward engineering constraints. The system stops being magical and starts being predictable.

The right pattern: event-driven processing (not everything behind HTTP)

The most natural serverless use case is boring in the best way: events in, work out. When your inputs come from systems that already speak in events—object storage uploads, message queues, webhook notifications—Lambda shines because it can scale compute to match incoming demand.

S3 uploads → image pipeline

Take image processing. A user uploads an image. That’s an event. You don’t need an HTTP server sitting there for the rest of time; you need a pipeline:

Upload to S3
Trigger processing (e.g., resize, compress, generate thumbnails)
Store results back to S3
Optionally notify downstream services or update metadata

In practice, you get a workflow like “S3 event → function → write outputs.” The user’s upload and the derived processing are decoupled. If the pipeline is slower, it doesn’t stall user-facing traffic. If you need to add another step—say, watermarking—you extend the pipeline without reshaping the entire application.

SQS messages → background jobs

Queues are another sweet spot because they’re fundamentally aligned with serverless execution models. You receive a message, do the work, acknowledge, repeat. If processing fails, retries happen. The important part is that you implement idempotency so “at least once delivery” doesn’t become “duplicate side effects.”

A practical rule: make your work conditional on a stable identifier. For example, if a message represents “process order 123,” write results keyed by order ID, and safely no-op if the work already completed.

This is also where operational sanity improves. Instead of scaling an application tier and managing job runners, you scale the event consumer and let the queue absorb bursts.

Webhooks → quick, durable responses

Webhook handlers are another clean fit: receive an event from an external system, validate it, record it, trigger async follow-up work. The key is to keep the synchronous part short—ack quickly, then do heavier processing asynchronously.

If you try to do “everything” in the webhook request, you’ll hit timeouts and create cascading retries. If you treat the webhook as a trigger and move the real work to a queue or pipeline, serverless becomes an advantage rather than a gamble.

Scheduled jobs: let time be the trigger

Not every useful workload starts with an external event. Some starts with time: nightly reports, cache refreshes, cleanup tasks, batch processing windows.

Serverless scheduled invocations are ideal for these because you avoid building and maintaining the “cron runner” infrastructure. You also get clear boundaries: each job run is its own execution. That makes debugging and reruns easier.

A practical pattern is “scheduled function → enqueue work.” Don’t have the scheduler do heavy lifting itself if the task can fan out. For example:

Scheduled run at 02:00
Query for “items needing refresh”
Enqueue one message per item (or per shard)
Worker functions process in parallel

This reduces the blast radius of failures and prevents one long-running job from turning into a recurring outage.

The latency and connection reality (and how to work with it)

The hype glossed over the fact that serverless is not optimized for every interaction pattern. Execution time, cold starts, concurrency behavior, and integration timeouts are constraints you must respect.

So how do you build well anyway?

Design for short synchronous work

Use serverless for the part of the request that benefits from elasticity and isolation. If a request needs slow external calls or heavy computation, push it into an async workflow. Then return something like:

“Accepted” with a job ID
Or update the UI via polling/websocket later

Even if you’re using serverless behind HTTP for specific endpoints, you still want the synchronous path to be lean.

Externalize dependencies and caches

If you’re repeatedly calling downstream services, cache aggressively outside the function so you’re not depending on warm invocations. Treat caches as best-effort, not correctness.

Make retries boring

Assume your function might run multiple times for the same logical event. That means:

Use unique keys for side effects
Deduplicate where possible
Write results in a way that can be replayed safely

This is one of the most important “culture shifts” serverless demands. Once teams embrace it, the system becomes sturdier rather than fragile.

When you should avoid Lambda (and what to use instead)

The blunt take: if your workload needs stable, long-lived connections or you’re building a real-time system with tight latency expectations, serverless may fight you. Likewise, if you want to manage complex in-memory state across requests, you’re probably recreating a server—just with extra steps.

In those cases, you’ll often be better off with:

Long-running containers or services for streaming and persistent connections
Managed databases and queues paired with a service tier where appropriate
Event-driven services where serverless is a worker, not the entire application boundary

And if you’re thinking about doing “Lambda everywhere behind API Gateway,” do it selectively. Start with endpoints that are naturally request/response and lightweight—or endpoints that are easy to observe and easy to retry safely. Don’t make it your default architecture just because it’s trendy.

Conclusion: serverless didn’t die—it grew up

The serverless everything era was overconfident, and it paid the price. But the core idea wasn’t wrong; it was the application of the idea that was. Lambda didn’t replace servers—it found a niche where it’s genuinely excellent: event-driven processing, scheduled jobs, webhook handling, and image/asset pipelines that naturally decompose into asynchronous steps.

If you build with the grain of serverless—externalized state, idempotent work, short synchronous paths, and async fan-out—you get a system that’s easier to scale, easier to reason about, and often cheaper to operate. Serverless wasn’t the future of every workload. It was the future of the right workloads. And that future is still here.

htmx Is a Rebellion Against JavaScript Complexity (and I'm Joining)

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 29 Mar 2023 00:00:00 +0000

There’s a moment in every developer’s life when they realize they’re not building an app anymore—they’re building a build system to build an app. htmx is my loud, unapologetic answer to that feeling. It doesn’t “replace” JavaScript so much as it rejects the idea that every interactive UI needs a bespoke JavaScript universe. Instead: extend HTML, let the server do the heavy lifting, and ship.

This is not nostalgia. It’s pragmatism—especially if your app looks like most real apps: CRUD screens, searchable lists, dashboards, comment threads, account pages, and all the workflows that don’t require a game engine in the browser.

The problem isn’t JavaScript—it’s the complexity tax

Modern front-end tooling has trained us to believe that interactivity always comes with a specific stack shape: a client-side framework, a bundler, a state management library, a router, a data-fetch layer, a form abstraction, and then a pile of glue code to keep it all from falling apart.

You can see the pattern in how teams talk:

“We’re rewriting the state management.”
“We need a new data layer.”
“The UI is hard because the data is hard.”
“We’re fighting re-renders.”

To be clear: JavaScript is powerful. Frameworks are useful. But the default industry approach often charges an upfront complexity tax on every page, regardless of whether the page needs it.

Most CRUD apps don’t need client-side routing gymnastics. They don’t need a virtual DOM diffing strategy. They need predictable behavior, fast iteration, and a server that’s already great at generating HTML.

htmx asks the simple question we avoid: why are we replacing a perfectly good document with a second, synchronized document?

The htmx idea: make HTML interactive, not obsolete

htmx takes HTML seriously. It turns “static markup plus a small enhancement layer” into a full application style—without insisting you abandon HTML or introduce a virtual DOM.

The core move is this: use HTML attributes to declare behavior.

Instead of writing a component that fetches data, renders UI, and updates state, you write markup that says things like:

When this button is clicked, make a request.
When the response arrives, swap a portion of the page.
When the user types, debounce and query.
When a form is submitted, send it and replace the results.

That’s it. The “state” lives where it should for these apps: on the server, reflected in HTML.

A tiny example: delete with a confirmation and a swap

Imagine a list of items:

<div id="items">
 <div id="item-42">
 <span>Item 42</span>
 <button
 hx-delete="/items/42"
 hx-confirm="Delete this item?"
 hx-target="#item-42"
 hx-swap="outerHTML"
 >
 Delete
 </button>
 </div>
</div>

No client-side store. No reducer. No rehydration drama. Your delete endpoint returns what the UI should become—often 204 for “remove it,” or a small fragment to replace the row.

This is not magic; it’s mechanical sympathy. The browser remains the browser: it loads a page, you update parts of it, and the DOM stays the DOM.

“No build step” doesn’t mean “no discipline”

Let’s clear a common misconception: “no build step” doesn’t mean “no engineering.” You still need boundaries, good endpoints, and a clean mental model for what’s rendered where.

What htmx changes is where complexity belongs.

With a React-style approach, complexity migrates into JavaScript architecture: component trees, client caching rules, state synchronization, optimistic updates, and a thicket of abstractions. With htmx, the complexity shifts back toward server design:

Your endpoints become the UI’s “program.”
Your HTML fragments become the UI’s “render output.”
Your controllers decide what state exists and what the user sees next.

Practical advice: design endpoints that return partial HTML fragments with clear responsibility.

For example:

GET /items returns a full page for initial load.
GET /items/search?query=... returns a fragment for the results list.
POST /items returns the updated list fragment (or the created row).
DELETE /items/:id returns a fragment to remove or replace the row.

Your UI composition becomes a series of intentional swaps.

When htmx fits like a glove (and when it doesn’t)

Let’s be honest: htmx isn’t a universal replacement for all front-end development. It’s a different trade.

Great fits

htmx shines when:

The UI is mostly server-driven content.
CRUD flows dominate.
Users expect forms, tables, filtering, pagination, and actions that map cleanly to HTTP.
You can tolerate navigation that is mostly “page loads + partial updates.”

A job board. A blog admin. A ticketing system. A content CMS. An internal tool. Most of the software you or your company actually needs.

Not ideal (by default)

htmx will fight you if you need:

Highly interactive, real-time canvas-like experiences.
Complex client-side validation logic that depends on large local state.
Heavy offline-first behavior where the server is only a later reconciliation step.
Ultra-granular animations tied tightly to high-frequency UI state.

In those cases, you can still use htmx as a companion—enhancing the “boring parts” while reserving a dedicated front-end for the parts that truly need it.

My opinionated stance: start with server-rendered HTML and let interactivity grow only where it earns its complexity.

How the architecture changes your day-to-day

Here’s why I’m “joining” the htmx camp: it changes how development feels.

1) Debugging becomes straightforward

When something renders wrong, you can inspect the HTML you received. When an interaction fails, you can inspect the network request and the returned fragment.

No component introspection. No “why did the state update twice?” no phantom re-renders. You can reason about behavior using tools you already know: request/response, DOM updates, and HTML output.

2) Iteration loops get tighter

Design your app like you would design pages:

Create a route that renders a view.
Add a small fragment endpoint for updates.
Wire an attribute in the markup to swap it in.

The feedback cycle shrinks because you’re not constantly building an app shell just to test a small UI behavior.

3) Performance becomes natural

Server-rendered pages start with meaningful HTML. That reduces the “blank screen until hydration” problem that haunts many client-heavy architectures. Even when you use JavaScript sparingly, the baseline experience is already there.

And because updates are targeted swaps, you often avoid re-fetching and re-rendering entire application states for what should be local changes.

A pragmatic migration strategy: start small, win early

If you’re currently deep in a React-first setup, you don’t need to rip everything out to benefit from the underlying idea: fewer client-state responsibilities.

A migration strategy that works in real organizations:

Pick one CRUD feature (e.g., “edit profile” or “manage tags”).
Implement it server-rendered with standard HTML routes.
Add htmx enhancements only where it improves flow (search-as-you-type, inline delete, partial refresh of a table).
Keep the rest untouched until you’re confident you like the model.
Measure engineering outcomes, not just UI metrics: time-to-change, regression frequency, and how often you fight state bugs.

The goal isn’t purity. It’s reducing the complexity tax. If htmx makes a single area of your product easier to maintain, that’s already a win.

Conclusion: the server isn’t “old”—it’s the solid foundation

htmx isn’t a rejection of modern web development; it’s a rejection of modern web development’s habits. It brings us back to a principle that scales: build reliable behavior around HTML and HTTP, and use the browser as a platform rather than as a rendering target for a separate UI model.

For the vast majority of apps—especially CRUD and content-driven workflows—htmx offers a simpler architecture that’s easier to understand, easier to debug, and faster to ship. I’m joining because it feels like building software again, not managing a framework’s ecosystem.

Phoenix LiveView Is the Framework the Industry Refuses to Notice

abdecastro@protonmail.com (Antonio B De Castro) — Fri, 17 Mar 2023 00:00:00 +0000

For years, the web development conversation has been hijacked by a single obsession: push as much logic as possible into the browser. Phoenix LiveView quietly does the opposite—render server-driven HTML that feels real-time, reactive, and alive—without demanding a dedicated client-side framework to babysit state. The industry has plenty of reasons to ignore that. But those reasons are rarely about capability.

The promise: real-time interactivity without the JavaScript tax

LiveView’s core idea is disarmingly simple: you write Elixir on the server, and the UI updates over a persistent connection. Instead of a client-side app that owns the state, LiveView owns the interaction model on the server, and the browser becomes a “thin” endpoint that renders HTML updates as they arrive.

That sounds like a throwback until you actually build something interactive:

A live search box that updates results as you type.
A dashboard with filters, tabs, and paginated tables that update instantly.
A collaborative workflow where actions by one user trigger changes for others.

In LiveView, those behaviors aren’t bolted on with hacks. They’re part of the programming model. You don’t need to design a whole state management architecture before you can show a single component. You model events and render the result. That’s it.

And crucially: you typically don’t need to introduce a large client-side JavaScript framework to get there. You can still use JavaScript where it’s genuinely needed (file uploads, complex third-party widgets, browser APIs), but you’re not forced into treating the front end as a separate application you must synchronize forever.

Why React “feels” over-engineered once you’ve shipped LiveView

React is an extraordinary library. The problem is the ecosystem you end up building around it.

React apps often become a collection of moving parts: a router, a data-fetching layer, a cache, a state manager, form handling utilities, global stores, local component state, and a growing set of conventions that exist largely to stop the app from collapsing under its own complexity. Even when you get it right, you’re still paying ongoing costs:

You implement optimistic updates to keep the UI responsive.
You fight edge cases around stale caches.
You reconcile server state with local intent.
You debug race conditions between concurrent effects and network latency.

LiveView attacks the problem at the root: it keeps the “truth” of interaction on the server. When the user clicks a button or submits a form, that event is handled by your Elixir code. The response is a render update—HTML patches that update what the user sees.

Here’s the practical difference in mindset:

React-style framing:

“What does the UI state become? Who owns it? How do we keep it consistent with the server?”

LiveView-style framing:

“What should the UI look like given the current state? What happens on each event?”

Once you’ve internalized that difference, React can start to feel like over-engineering for common product workflows—especially internal tools, admin dashboards, CRUD-heavy apps, and interactive pages where the business logic belongs on the backend anyway.

The developer experience: write Elixir, not a second job

The strongest argument for LiveView isn’t theoretical; it’s ergonomic.

In many web stacks, you end up doing “two jobs”:

Build the server correctly.
Then replicate parts of your server logic in the browser so the UI can stay responsive.

With LiveView, you usually don’t have to. You can keep business logic where it belongs—on the server—then render UI directly from that same logic. Forms, validations, and authorization checks happen in one place. That means fewer “mirrors” of logic, fewer mismatches, and fewer times you debug why the UI thinks something is allowed when the server denies it.

Consider a common scenario: a settings page with dependent fields.

Changing “Region” changes available “Language” options.
Certain combinations disable other fields.
Submitting updates requires validating permissions and rejecting conflicting states.

In a React app, you’ll often build a mini client-side system to manage this dependency graph. In LiveView, you handle the change event, update the server-side state, and re-render the affected section of the UI. The result is immediate, consistent, and—most importantly—maintainable by the same team that wrote the backend.

If you want a litmus test: ask yourself how often your React UI logic duplicates server logic. If it’s frequent, LiveView will feel like relief rather than novelty.

“State management nightmare” is usually just state management avoidance

The phrase “state management nightmare” gets tossed around like a cliché, but it captures a real failure mode: many front-end architectures treat state as something you constantly patch rather than something you design.

LiveView flips that. You structure your application around server-side events and renders. If you need to track UI-specific ephemeral state—like which tab is selected or whether a modal is open—LiveView lets you do it without turning your codebase into a distributed state experiment.

A concrete example: imagine a multi-step onboarding wizard.

Step 1 collects company details.
Step 2 collects team preferences.
Step 3 shows a summary and confirmation.

In React, you’re likely to maintain form state in the browser, serialize it, validate it, and coordinate it across routes or components. You might keep it in a form library, a global store, or both.

In LiveView, you can keep the “wizard state” server-side. Each step transition triggers an event; you validate and update state; you render the next step. You can still optimize user experience (e.g., debounce specific inputs), but you don’t have to build an entire client-side data layer to get correctness.

This is where LiveView’s philosophy shines: it doesn’t deny interactivity—it centralizes responsibility.

Practical advice: how to adopt LiveView without clinging to old habits

If you’re coming from the React/Next.js world, the temptation will be to “port” your existing patterns instead of learning new ones. Don’t.

Here are a few approaches that work well in practice:

Treat LiveView as your UI state machine

Model the app around events and render outcomes. When you name things—events, assigns, components—opt for business semantics, not UI mechanics. “OrderPlaced” beats “ClickedPrimaryButton.”

Keep components small and composable

Break down your templates into LiveView components where it helps readability. Aim for components that own a clear set of responsibilities: a single form, a table with filters, a modal with its own logic.

Use JavaScript only when the browser genuinely adds value

If you’re building a date picker or integrating with a third-party widget, fine—use JavaScript. But don’t start every project by assuming the client must own the architecture. Let LiveView do what it does best: interactive HTML rendering driven by server events.

Don’t bolt on complexity

A common trap is trying to recreate SPA patterns: global stores everywhere, client-side caching strategies, “optimistic” behaviors that mirror server writes. LiveView encourages a more direct path: handle the event, update server state, re-render.

Adopting LiveView successfully often means unlearning the reflex to “keep everything in sync on the client.” LiveView was built to make that sync problem smaller by design.

Why the industry ignores it—and why that’s irrational

Let’s be blunt: Phoenix LiveView is powerful, and it’s not new. Yet it doesn’t dominate mindshare the way JavaScript frameworks do. That gap has less to do with technical capability and more to do with how ecosystems grow.

JavaScript is the default language of the web, so the ecosystem gravity is enormous. Teams hire for it. Tutorials lead with it. Tooling assumes it. And once a workflow becomes standard, it acquires a kind of institutional momentum that has nothing to do with whether it’s the best tool for the job.

But “standard” is not the same as “effective.”

LiveView offers a different trade: instead of treating the browser as the primary place where truth lives, it treats the server as the source of interaction truth. You get reactive behavior without the constant churn of front-end architectural overhead. The user experience feels modern because the UI updates immediately; the implementation feels sane because the state model stays coherent.

If the industry wants to keep repeating the same patterns—global state, optimistic UI, reconciliation strategies, and the endless ceremony around correctness—React will keep looking like the safe choice. LiveView just quietly proves it isn’t the only one.

Conclusion: a framework that treats interactivity like engineering, not theater

Phoenix LiveView doesn’t ask you to surrender interactivity for simplicity. It gives you real-time UX through server-driven, reactive rendering—so your codebase remains unified and your UI stays correct without orchestrating a complicated client-side state universe. If your current stack feels like it’s always one refactor away from stability, LiveView is worth a serious look.

Not because it’s trendy. Because it works—cleanly, confidently, and with far less drama than the industry’s JavaScript-first reflex will admit.

How I Use ChatGPT as a Senior Developer (Without Losing My Mind)

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 05 Mar 2023 00:00:00 +0000

I didn’t “learn ChatGPT” so much as I built a workflow around it—one that treats the model like a sharp junior teammate, not an oracle. After months of daily use, the pattern is clear: when I’m exploring, translating, or brainstorming, ChatGPT accelerates me. When I’m deciding, securing, or computing precisely, it can quietly steer me off a cliff. The difference is knowing which prompt category I’m in before I hit send.

My rule of thumb: classify the task before you prompt

Here’s the gating question I ask myself every time: Is this something I can safely iterate on, or something I must get exactly right? That single decision determines what I paste, what I ask for, and how I verify the output.

I split tasks into four buckets:

Explaining and mapping (safe): unfamiliar codebases, unclear docs, “walk me through this.”
Translating requirements (mostly safe): turn a spec into test ideas, edge cases, or example scenarios.
Debugging and reasoning support (safe with discipline): rubber-duck style for complex logic.
Deciding and delivering precision (danger zone): architecture, security-sensitive code, exact numerical reasoning, or anything tied to specific API versions.

If you do nothing else, do this: choose your bucket and tailor your prompt to match the risk. ChatGPT isn’t the risk—it’s the mismatch between the kind of certainty you need and the kind of certainty the model is designed to provide.

The sweet spot #1: explaining unfamiliar codebases

The fastest way I get value is by treating ChatGPT like a code archaeologist. I paste a small slice—usually 50–150 lines around the behavior I don’t understand—and ask it to build a mental model.

My go-to prompt pattern:

Give context first: language, framework, and what behavior you’re trying to understand.
Constrain the scope: “Explain only this file/function and its call chain.”
Ask for a trace: “What happens step-by-step when X occurs?”

Example:

You are reviewing a JavaScript/TypeScript service. Here’s a function handleRequest(req) and the helper it calls.
Explain:

the data flow from req to the final response,

where validation happens, and

which branch handles error conditions.
Don’t suggest refactors yet—just narrate the current behavior.

What I look for in the answer:

It should mention the real variables and branches I provided.
It should identify what’s missing (e.g., “This function assumes userId is present but I don’t see the check here.”).
It should surface questions I can answer with additional code.

Where this wins: the first pass is often enough to guide my next search in the repo. ChatGPT turns “Where do I even start?” into “Here are the three files and conditions I should inspect.”

The sweet spot #2: generating test cases from requirements

I use ChatGPT to turn vague product language into testable expectations. This is not “generate the tests and ship.” It’s “generate the candidates and make them real.”

My prompt pattern for test generation is brutally structured:

Paste the requirement (or user story).
Provide known constraints (e.g., time zones, input formats, limits).
Ask for equivalence classes + boundary cases + negative cases.
Request tests in a specific format (table-driven, Jest, pytest, etc.).

Example:

We have an endpoint POST /v1/events. Requirements:

eventType is required and must be one of: click, view, purchase

userId is optional; if omitted, store as anonymous

timestamp must be ISO-8601 in UTC (e.g., 2026-03-19T12:34:56Z)
Generate a test plan with:

5 happy-path tests

6 validation tests

4 edge/boundary tests

3 security-ish misuse tests (e.g., wrong content-type, oversized payload)
Then output pseudocode tests in Jest-style.

What makes this effective:

I don’t ask for “the correct behavior”—I ask for “a test plan.”
I insist on format and constraints so the model can’t drift into generic advice.
I always follow up with: “What assumptions did you make that I should verify in code?”

My verification step is mechanical. I pick one or two tests to run immediately and use the rest to guide code reading. Test generation becomes a map, not the territory.

The sweet spot #3: rubber-duck debugging complex logic

When logic gets gnarly—distributed edge cases, state machines, off-by-one territory—ChatGPT shines as a rubber duck that can keep up. The trick is to force it to ask questions and reflect its reasoning back at you.

My prompt pattern:

Provide the problematic function (or simplified version).
Tell it what you already believe is happening.
Ask it to enumerate hypotheses and contradictions.
Require it to point to what would falsify each hypothesis.

Example:

Here’s a simplified function that calculates a rolling window score.
Current behavior: when the window crosses midnight, scores sometimes reset unexpectedly.
Assume I might be misunderstanding the timestamp conversions.
Do this debugging:

Restate the algorithm in plain English

List the branches that behave differently near midnight

Identify 3 plausible bugs

For each bug, tell me what input would disprove it and why

The output I want isn’t a verdict; it’s a menu of targeted experiments. Once I have that, I can instrument the code or write a focused failing test. ChatGPT accelerates the “what should I check next?” loop.

The sweet spot #4: writing regex patterns that actually match

Regex is where I’m willing to delegate “construction,” because it’s easy to test. If you can run it against representative inputs, you can validate quickly.

My prompt pattern:

Provide the goal in examples (“matches these, rejects those”).
Specify the regex flavor (JavaScript, PCRE, RE2, etc.).
Ask for anchored vs unanchored variants depending on use case.
Request explanation of groups and boundaries.

Example:

Write a JavaScript regex that matches filenames like invoice_2026-03-19_v3.pdf
Requirements:

Must start at beginning and end at .pdf

Date is YYYY-MM-DD

Version is v followed by an integer (no decimals)
Return:

the regex,

a list of example strings it matches, and

a list it must reject.

The “must reject” list is the real win—it exposes the model’s tendency to be overly permissive. I then run the regex against those examples, and only then do I integrate.

The failure modes I refuse to delegate

Here’s where I draw hard lines. These are categories where ChatGPT can be persuasive in the wrong way—producing plausible code or explanations that fail under constraints you didn’t explicitly enforce.

1) Architecture decisions

ChatGPT can propose elegant structures that don’t fit your system’s operational reality: deployment model, data ownership, migration strategy, team workflow. I use it for diagramming and options, not choosing.

What I do instead: ask for trade-offs, then make the decision myself:

“List three architecture options and the operational implications of each.”
“What questions should I ask my team to choose?”

2) Security-sensitive code

Anything involving auth, authorization, cryptography, input sanitization, permission boundaries, or threat modeling is not a “paste and hope” zone. Even if the code “works,” it can be subtly wrong.

What I do instead: use ChatGPT to produce a checklist:

“Give me a security review checklist for OAuth token validation in Node.js.”
Then I implement with known, reviewed patterns and run the full test suite.

3) Precise numerical reasoning

If the task hinges on exact math, floating-point behavior, financial rounding rules, or tricky time arithmetic, I treat the model as a brainstorming partner at best. “Looks right” isn’t good enough.

What I do instead:

derive formulas myself,
write a few canonical tests with known inputs/outputs,
and then use ChatGPT to help explain discrepancies rather than compute final truth.

4) Code tied to specific API versions

Models often generalize: an SDK method changed, a parameter was renamed, an error response structure differs. If your code must match a particular API version, you need deterministic references.

What I do instead: include the exact version and relevant docs snippet in the prompt, and ask ChatGPT to only transform what you gave it—never invent.

Red flags in outputs: when I stop trusting it

Even in safe categories, I watch for signals that the model is making stuff up or smoothing over uncertainty:

Confident language with missing assumptions: “It will work” without referencing your constraints.
Invented file names or symbols: if it claims there’s a helper I didn’t paste, that’s a no-go.
Unverifiable leaps: “This is the algorithm” when the reasoning depends on something not present in your code.
Off-by-default behavior: regex or parsing outputs that lack anchors, flags, or boundary conditions you didn’t request.
Citations to nonexistent docs: if it references a behavior “from the docs” but you didn’t provide the docs, treat it as suspect.

When I see these, I don’t argue with it—I shrink the prompt. More context. Narrow scope. Ask it to point to exact lines. Or ask it to produce questions I can answer with additional code.

Conclusion: use ChatGPT like a tool with guardrails

ChatGPT became genuinely useful for me once I stopped trying to make it “smart” and instead made it consistent. In the best cases—explaining unfamiliar code, generating test candidates, rubber-duck debugging, and crafting regex—it speeds up my feedback loops. In the worst cases—architecture, security-sensitive code, precise numerical reasoning, and version-specific integrations—it can sound right while being dangerously wrong.

So my final advice is simple: classify the task, constrain the scope, and verify every output that must be exact. If you do that, you’ll get faster without losing your mind—and without shipping the model’s confidence as if it were proof.

Writing CLI Tools in 2023: Rust, Go, or TypeScript?

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 21 Feb 2023 00:00:00 +0000

If you’ve ever shipped a CLI and then watched it break because someone’s environment differed from yours, you already know the real problem isn’t the command—it’s the tooling choices that sit underneath it. In 2023, you don’t have to settle for brittle scripts anymore. You can build modern, ergonomic CLI tools that feel like first-class software—only now you get to choose the language that best fits the job.

The “right” answer is less about what’s trendy and more about what your users will do with your tool: how fast it needs to be, how many dependencies it should carry, and whether your team lives in Node or prefers a compile-and-ship workflow.

The modern CLI reality: you’re shipping behavior, not just code

A CLI tool is a contract. It promises:

Predictable flags and help text
Stable parsing across shells and environments
Good error messages (with non-zero exit codes)
A deployment story that won’t collapse on someone else’s machine

In earlier years, “good enough” often meant Python with argparse, or bash scripts that stitched together other programs. Those approaches can still work—but they tend to fail in the places teams care about most: dependency drift, version mismatches, packaging pain, and inconsistent argument parsing.

So let’s talk about three languages that make those problems dramatically easier in 2023: Go (with Cobra), Rust (with Clap), and TypeScript (with Commander).

Go: pick it when you want single-binary simplicity and fast iteration

Go’s superpower for CLI tools is straightforward: you can usually build a static-ish, single-binary executable quickly, with a deployment story that’s easy to explain. That matters when your users just want a command—no runtime setup, no “please install Node 18” footnotes, no container requirements.

Why Cobra fits Go’s strengths

Cobra is a mature library with a familiar structure for defining commands and subcommands. It encourages you to model your CLI like a small app, not a pile of string parsing. Flags, help output, and command composition become “boring” in the best way.

Practical example: a workspace cleanup utility

Imagine a CLI like:

tool purge --dry-run
tool purge --days 30
tool purge --path ./dist
tool config set region us-east-1

With Cobra, you can define subcommands cleanly and keep option wiring readable:

One command file per major subcommand
Central config handling
Consistent exit codes and messaging

The real win is that Go lets you ship a utility that’s easy to install and fast to run—exactly what you want for operational scripts and developer productivity tools.

When Go is the wrong choice

Go isn’t ideal when your CLI is fundamentally a data-processing engine where you need tight control over memory layout or you’re squeezing every millisecond out of streaming. Go can handle that work, but if performance and predictable resource usage at scale are the whole point, Rust usually becomes the sharper tool.

Rust: pick it when correctness, performance, and large data are the product

Rust is what you reach for when “CLI tool” is really shorthand for “high-throughput system.” Think: parsing logs at scale, transforming large datasets, indexing files, running ETL-like pipelines, or any workload where speed and resource efficiency are non-negotiable.

Why Clap fits Rust’s ergonomics

Clap is the de facto standard for CLI argument parsing in Rust. It gives you powerful declarative configuration for options, subcommands, and validation. You also get help output that feels polished without you spending hours polishing it.

The bigger point: Rust makes it easier to write a CLI whose failure modes are clean. When things go wrong, you can surface precise errors instead of dumping stack traces or swallowing edge cases.

Practical example: streaming log processing

Consider a tool like:

logx grep --pattern "ERROR" --input ./logs --output ./report.jsonl
logx stats --group-by service --input ./logs

If you need to stream input efficiently, avoid loading everything into memory, and process files concurrently, Rust shines. You can build a pipeline where:

Input is read incrementally
Parsing is robust (with clear errors for malformed lines)
Output is written in a controlled format
Concurrency is explicit and safe

This is also where Rust tends to pay off in long-lived tools: memory safety and strong typing reduce “it worked on my machine” bugs that only surface under real workloads.

When Rust is the wrong choice

Rust can be overkill when the CLI is mainly glue—wrapping a few subprocess calls, moving files around, or orchestrating existing tools. If your tool’s primary value is workflow convenience and you don’t need heavy lifting, Go will usually get you to a shippable result faster.

TypeScript: pick it when your users are already in the Node ecosystem

TypeScript makes sense when your CLI is part of a larger ecosystem that already runs on Node: dev tools, integrations, build tooling, plugin systems, and anything that benefits from npm’s distribution model.

Why Commander fits TypeScript well

Commander is a popular choice for defining commands and options, with a pragmatic programming model that works well for JS/TS teams. You’ll find it especially natural to build a CLI that talks to:

npm packages
REST APIs
local project configuration files (like package.json)
JavaScript-based tooling

TypeScript also lets you share types between the CLI and the underlying libraries. That can be a big quality-of-life improvement: you don’t just parse flags—you generate strongly typed config objects that downstream code understands.

Practical example: a project scaffolding CLI

Suppose you’re building:

mygen init --template react --name acme-app
mygen install --with eslint --with prettier
mygen doctor to validate the project setup

In a Node-centric workflow, TypeScript shines because the CLI and the libraries live in the same universe. Installation might even be as simple as npx mygen or npm i -g mygen depending on your distribution goals.

When TypeScript is the wrong choice

TypeScript is less compelling when you want the simplest “drop a single binary on a server” experience or when your CLI must be standalone with minimal runtime concerns. If users expect curl | bash-style installation and zero runtime assumptions, Rust or Go tends to be the smoother experience.

Also, if your tool is heavy on raw data processing, TypeScript will likely feel frictional compared to Rust or even Go.

What about Python? Don’t resurrect the original pain

Python still exists—and some teams genuinely like it. But for a CLI that must be reliable across machines and time, Python scripts are where many projects go when they didn’t plan for operational longevity.

The failure pattern is predictable:

Someone has Python 3.10, someone else has 3.11 (or none)
Dependencies behave differently across minor versions
A packaging mistake turns “works locally” into “it fails on CI”
Argument parsing logic becomes inconsistent and hard to test

If Python is your starting point, you’ll want disciplined packaging and pinned dependencies. But if your goal is to ship a CLI that behaves like infrastructure—not a quick personal script—Rust, Go, or TypeScript are usually the more dependable choices.

A decision framework you can actually use

Here’s a blunt but useful way to choose:

Choose Go + Cobra if…

You want a single-binary developer utility
Your CLI is primarily orchestration or lightweight processing
You value fast compilation, straightforward deployment, and quick iteration
Your team prefers minimal runtime dependencies

Rule of thumb: if your users just need tool do-thing to work everywhere, Go is your best bet.

Choose Rust + Clap if…

The tool must process large datasets efficiently
Performance and predictable resource usage matter
You care deeply about correctness, validation, and clean failure modes
You’re building something closer to a real system than a wrapper

Rule of thumb: if the CLI is the engine, Rust is usually the engine room.

Choose TypeScript + Commander if…

Your users are already Node/TypeScript developers
The CLI integrates with npm packages, project configs, or web APIs
You want to share types and reuse libraries across CLI + runtime
Distribution via npm is part of your product strategy

Rule of thumb: if the CLI is part of a JavaScript workflow, TypeScript will feel native.

Make your CLI feel “professional” regardless of language

Language matters, but you can still raise the baseline quality of your CLI quickly:

Treat help output as product. Add examples to --help and ensure flags are consistent across subcommands.
Validate early. Don’t wait until halfway through processing to discover a bad flag.
Be explicit in errors. Print actionable messages and exit with non-zero codes.
Support --dry-run when the CLI modifies things. It builds trust.
Keep output stable. If you offer machine-readable formats (JSON, NDJSON), document them and don’t casually break them.

Also: design your commands before your implementation. If your CLI architecture is clear, your library choice becomes an implementation detail rather than a regret.

Conclusion: the best language is the one that matches your users

Go, Rust, and TypeScript are all excellent in 2023—they just optimize for different realities.

Go + Cobra for quick utilities and a simple install story.
Rust + Clap for performance-critical tooling and large-scale processing.
TypeScript + Commander for Node-first ecosystems and integration-heavy CLIs.

Choose the one that matches how your users live. If you do that, you’ll spend less time firefighting environment mismatches and more time building a CLI people actually enjoy using.

AI Coding Assistants Are Making Senior Developers More Valuable, Not Less

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 09 Feb 2023 00:00:00 +0000

Every few months, a new wave of automation arrives with the same promise: “Don’t worry—your job is going away.” AI coding assistants are no exception. But the lived reality is harder to dismiss. When you put tools like Copilot and ChatGPT into the hands of real engineers, especially the senior ones, the story flips: expertise doesn’t get erased—it gets leveraged. And the disruption isn’t “AI replaces programmers.” It’s that the difference between good and mediocre developers is about to become unmistakable.

The real pattern: AI speeds up judgment, not just typing

Coding has always been more than generating lines of code. The work is figuring out what should be written, how it fits into an existing system, and which tradeoffs matter—performance, safety, readability, cost, maintainability, and time-to-debug. Autocomplete can help you type faster. AI assistants help you think faster—if you already know how to think.

In practice, senior developers don’t treat AI output as gospel. They treat it like a suggestion engine for implementation details. They can review changes instantly, spot mismatches with architecture, and correct edge cases before those edge cases become incidents.

That’s the key difference:

Senior developers use AI to accelerate evaluation. They review, test, refactor, and integrate quickly.
Junior developers use AI to accelerate output. They may implement quickly, but without the instincts to detect subtle wrongness.

The outcome is not theoretical. It’s what you see after months of heavy usage: productivity gains skew higher for seniors because they can convert AI suggestions into correct, production-quality work at speed.

Why seniors get the biggest lift (and juniors don’t)

Imagine you’re building a feature in a mature codebase: an API endpoint that writes to a relational database, triggers background work, and must conform to existing conventions. A junior developer might ask an assistant to “write the endpoint.” The assistant will likely produce something that looks right: correct shapes, plausible validation, typical error handling.

But senior developers also ask: “How does this endpoint need to behave under load?” “What are our domain invariants?” “How do we handle idempotency?” “Where does this belong in the layering?” Those questions are where senior judgment lives.

A concrete example: suppose the assistant proposes a database query that works for small test data but misses an index and causes table scans in production. A junior might not notice, or might not understand the impact until it’s too late. A senior will notice immediately, because they’ve seen the pattern before and understand the query planner implications. They’ll adjust the query shape, add or leverage an index, and ensure the pagination strategy won’t grind the system down.

That’s why the productivity boost often looks like this:

Senior developers: ~2–3× more productive (because they can evaluate and correct quickly)
Junior developers: ~1.2× more productive (because they can’t reliably separate good suggestions from dangerous ones yet)

Notice what’s missing from that comparison: nobody becomes “twice as good” at design just because they can prompt. AI reduces friction, but it doesn’t install experience. Seniors already have it. Juniors are still building it—so they get smaller gains until their review instincts catch up.

The overlooked advantage: faster feedback loops

AI coding assistants also compress time between “idea” and “verified reality.” That matters because the best developers are the ones who run tight loops:

Generate a candidate implementation
Understand it
Validate it with tests and local reasoning
Improve it until it meets real constraints

For seniors, these loops stay intact. In fact, AI can strengthen them. For example, an engineer might use ChatGPT to draft a set of unit tests, then immediately verify them against the existing code patterns. Or they might use Copilot to implement a refactor and then rely on their own test suite and type system to confirm correctness.

For juniors, the loops can degrade:

Generate code
Believe the code
Run it once
Fix what breaks
Ship what “seems” to work

If you’ve mentored people, you recognize the failure mode: not malice—just an inability to anticipate what will break later. AI can make it easier to move fast, but without strong validation habits and system understanding, “fast” can become “fragile.”

Practical advice for teams: don’t just measure output. Measure time-to-correct. Encourage workflows that force verification. A simple rule like “every AI-generated change must include at least one targeted test or a code review checklist item” can dramatically raise the quality of junior work and reduce the risk of shipping subtle defects.

How AI widens the canyon between good and mediocre

Here’s the uncomfortable truth: AI doesn’t make everyone equal. It makes speed cheaper. And when speed is cheaper, the bottleneck becomes correctness and decision-making.

So the gap widens, because:

Mediocre developers lean harder on AI because it feels productive.
They may accept plausible-but-wrong solutions.
Their review standards don’t improve as fast as their ability to produce code.

Meanwhile, strong developers use AI as leverage. They ask better questions, structure work more cleanly, and refine AI output into something coherent with the system. They also know where to draw boundaries—what to generate, what to write by hand, and what to question.

This is the “canyon” effect: differences that were once softened by slower iteration now become obvious. In code reviews, you’ll see it in:

consistent architecture choices
disciplined error handling
thoughtful naming and documentation
test coverage that matches risk
PRs that require fewer follow-up fixes

The best engineers won’t disappear. They’ll become the people whose reviews prevent costly mistakes and whose implementations align with the system’s reality.

The new senior skill: guiding the assistant like a teammate

If you want to remain valuable in an AI-accelerated world, don’t try to “use AI more.” Use it smarter.

A senior developer’s approach looks less like “prompting” and more like directing a working session:

Provide context early. Link to the relevant modules, describe invariants, and mention constraints (“must be backwards compatible,” “avoid N+1 queries,” “follow existing logging conventions”).
Ask for changes, not miracles. “Refactor this function to…” beats “Rewrite everything to be better.”
Require a review plan. “List the edge cases you handled and how you’d test them.”
Confirm with tools you already trust. Run linters, type checks, unit tests, and targeted integration tests—then interpret failures like a professional, not like a spectator.

For example, instead of asking, “Can you write the payment webhook handler?” try:
“Given this event schema and these idempotency rules, implement the handler. Also propose a set of tests that verify retry behavior and duplicate event handling.”

That single shift—explicit constraints plus verification—turns AI output into something a senior can validate quickly and juniors can learn from. It’s not just about correctness. It’s about teaching the habits that produce correct systems over time.

What companies should do right now

This is where leadership matters. If you treat AI coding assistants like a productivity hack, you’ll get patchy results. If you treat them like an experience amplifier, you’ll get measurable quality gains.

Start with policies that encourage disciplined use:

Code review expectations: AI-generated code still gets reviewed, but seniors should review for reasoning, not just syntax.
Test gates: require tests for non-trivial changes, especially around data access, concurrency, authentication, and money-like domains.
Prompting standards: encourage developers to include constraints and to request test plans for risky code.
Mentorship pairing: seniors can “drive” AI-assisted work while juniors learn by observing how decisions are made and validated.

Also, update evaluation criteria. If your hiring or performance reviews reward raw PR volume, AI will distort the metric. Reward the things that scale: fewer regressions, faster resolution of complex issues, better system design, and improved maintainability.

The most successful teams will recognize that AI doesn’t replace senior talent. It concentrates it—because the people who can interpret, validate, and integrate AI output are the ones who prevent costly failures.

Conclusion: AI doesn’t replace expertise—it concentrates it

AI coding assistants are changing how software gets written, but they aren’t rewriting the fundamentals. Code still needs judgment. Systems still need context. Production still punishes assumptions.

What’s emerging after widespread Copilot and ChatGPT adoption is a simple, opinionated takeaway: seniors get more valuable because they can turn AI suggestions into correct software immediately. Juniors may get some speed, but the biggest gains come when they build the experience to evaluate output safely.

So don’t panic. Invest in senior-level review culture, tighten validation loops, and teach junior developers the decision-making habits that AI can accelerate—but not replace. The future won’t be “AI programmers.” It will be “judgment-powered programmers,” and the ones who master that will lead.

WebGPU Is the Graphics API the Web Actually Deserves

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 02 Feb 2023 00:00:00 +0000

For years, the browser’s graphics stack felt like a compromise: great for demos, limiting for serious work, and increasingly out of sync with what GPUs can actually do. WebGL helped the web learn to talk to hardware—but it was built on older assumptions. WebGPU is different. It’s the first graphics API designed with modern GPU programming in mind, and it finally gives browser developers the kind of control—and performance headroom—that desktop apps have enjoyed for years.

WebGL’s hidden tax: OpenGL ES, in a modern world

WebGL did something crucial: it proved the browser could do real-time graphics without installing drivers or runtimes. But the “classic” path still shows its age. WebGL is effectively a web-friendly wrapper around an OpenGL ES-era model—stateful, abstraction-heavy, and not particularly aligned with how modern GPUs are pipelined and optimized.

The practical consequences show up quickly as you push beyond simple rendering:

You fight the API: Many performance wins require batching, careful buffer updates, and predictable state changes—things WebGL can encourage, but it also makes awkward when your workload is modern and compute-heavy.
Compute remains a second-class citizen: WebGL’s main story is rendering. Yes, you can do GPU computations with fragment shaders and framebuffer tricks, but that’s a workaround—not an ergonomic model for general parallel compute.
Debugging and profiling are harder than they should be: When your mental model is “draw calls and shader uniforms,” it’s tough to translate that to the kind of explicit scheduling and resource management that GPUs increasingly benefit from.

In other words, WebGL made the web capable. But it didn’t make the web native to GPU workflows.

WebGPU’s big idea: explicit, Vulkan-inspired control

WebGPU is the browser’s answer to a fundamental problem: GPUs don’t scale well with vague intent. They like explicitness—clear resource lifetimes, predictable pipeline states, and command buffers that can be optimized.

WebGPU borrows architectural ideas from Vulkan: explicit resource binding, pipeline objects, and command-based submission. The difference is that it’s designed to feel approachable in JavaScript and safe by default.

Concretely, you get a programming model that maps more cleanly to GPU reality:

Pipelines instead of “set random state and hope”: You define how the GPU should run—vertex/fragment stages for rendering, compute pipelines for general GPU workloads.
Buffers and textures as first-class citizens: You manage GPU memory objects explicitly, which makes performance tuning much more straightforward.
Compute shaders are real: No more treating fragments like compute threads by accident. If your problem is parallel, WebGPU treats it that way.
Command encoders and submission: You build a plan for the GPU, then hand it off. That’s not just “clean”—it’s how you unlock consistent performance.

This is why WebGPU is more than a new renderer. It’s a general GPU API that lets web developers stop pretending the GPU is a glorified background effect.

What “Vulkan-level performance” looks like in practice

Let’s translate the theory into something you can actually ship. High performance isn’t magic; it’s about avoiding avoidable overhead and keeping the GPU fed.

WebGPU’s biggest practical wins tend to come from three areas:

1) Less CPU/GPU thrash through predictability

Modern rendering performance often collapses when the CPU has to constantly reconfigure GPU state or when resource updates happen in unpredictable patterns. WebGPU encourages stable pipeline objects and explicit buffer management.

Example: Suppose you’re rendering a large scene with thousands of instances. With WebGL, you’ll often feel the pain of per-frame uniform churn and state changes. With WebGPU, you can structure data so instance transforms live in a single GPU buffer and you use appropriate binding strategies to keep draw calls consistent.

2) GPU compute that doesn’t feel like a hack

If you’ve ever tried to run an ML inference step in the browser, you’ve likely hit the wall where your “GPU compute” approach feels like a shader trick instead of a compute pipeline. WebGPU’s compute support is designed for exactly this kind of workload.

Example: Implement a small neural network layer (e.g., matrix multiply + activation) with a compute shader. Instead of packing data into textures and writing “fragment compute,” you can dispatch work groups directly and control how buffers map to the GPU.

3) Better scaling for parallel workloads

Performance isn’t only about frames per second. It’s also about throughput for workloads that can be parallelized—video processing, image transforms, simulation steps, scientific visualization.

Example: A web-based microscopy viewer can use compute passes to denoise frames or enhance contrast. Because these operations are uniform per pixel or per region, they map well to dispatchable compute work. The result is not just faster processing—it’s the difference between “interactive” and “wait for the results.”

You don’t need to believe grand promises to see the value. If your workload is parallel and you want to avoid desktop-only pipelines, WebGPU gives you a serious path to get there.

Beyond games: real applications that benefit from WebGPU

Games are the obvious headline because they stress the GPU. But the browser’s most valuable opportunities are broader: any time you need GPU acceleration in a place where your users already are.

Here are the categories where WebGPU’s model is a strong fit:

GPU-accelerated machine learning inference

On-device inference in the browser is compelling: fewer round trips, better privacy, and an easier “it just runs” story. WebGPU can accelerate tensor operations using compute shaders and carefully planned memory layouts.

Practical advice: Start with a small subset of operations—like convolution or matrix multiplications—then expand. Don’t try to replicate an entire ML runtime on day one. Build a pipeline that keeps tensors in GPU buffers and minimizes host-device transfers.

Scientific visualization and data exploration

Scientists and analysts increasingly expect interactive plots, volume rendering, and simulations. WebGPU’s explicit pipeline and compute support can power progressive rendering, smoothing filters, or on-GPU transformations of large datasets.

Practical advice: Use compute passes to pre-process data into GPU-friendly formats. Then render using those outputs. Separating “prepare” from “draw” often leads to clearer code and more predictable performance.

Video processing and real-time image pipelines

Filters, warps, denoising, stabilization, and effects are perfect for parallel processing. With WebGPU, you can build pipelines that operate on frames efficiently rather than relying on CPU-heavy transforms.

Practical advice: Design your pipeline to reuse GPU buffers between frames. Allocate once, then update contents. Frequent reallocation is the silent performance killer.

Parallel computation for web-native tools

Think simulations, procedural generation, particle systems, physics approximations, or interactive editing with GPU-accelerated preview steps. WebGPU lets you treat the browser as a real compute environment, not just a UI wrapper.

Practical advice: Treat GPU work like a pipeline, not a function call. Batch operations when possible and structure your command submission to avoid stalling.

How to think about development: building pipelines, not patches

WebGPU is powerful, but it rewards the right mindset. If you treat it like WebGL—incrementally patching state and hoping for the best—you’ll underutilize its strengths. If you treat it like a compute-and-render pipeline, you’ll get better results faster.

Here’s a practical workflow that tends to work well:

Start with a narrow, measurable goal.
Example: “Apply a blur to an image at interactive latency.” Don’t start with “build a full engine.”
Design buffer and data flow upfront.
Decide what lives on the GPU, what needs to move, and how often. Host-device transfers are where performance plans go to die.
Create explicit pipelines for each stage.
Rendering stages belong in render pipelines; compute stages belong in compute pipelines. Mixing everything into one shader often makes optimization harder.
Use predictable resource binding.
Favor stable bind groups and consistent layouts. The more your structure stays constant between frames, the easier it is for the runtime—and the GPU—to keep performance smooth.
Profile like you mean it.
You want to know where time goes: command encoding, buffer updates, shader execution, or synchronization. WebGPU gives you enough structure to investigate, but you still have to look.

If you do this, WebGPU becomes less about learning a new API and more about adopting a better performance discipline.

Conclusion: the web is finally catching up to GPUs

WebGPU isn’t “WebGL, but newer.” It’s a different philosophy: explicit GPU control, compute-first capability, and a pipeline architecture inspired by the APIs that power serious desktop graphics and compute workloads.

And that matters because the browser is no longer just a place to display content—it’s becoming a platform for real-time computation, from ML inference to scientific visualization to high-throughput media processing. WebGPU is the foundation that makes those experiences feel less like magic tricks and more like engineering.

Nix Is the Future of Reproducible Development Environments

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 28 Jan 2023 00:00:00 +0000

“Works on my machine” isn’t a bug—it’s a business model. It’s what happens when your developer environment is an artisanal snowflake, assembled from shell history, undocumented installs, and whatever your laptop decided to keep. Dev containers help, but they’re still a packaging strategy around an inherently mutable reality. Nix takes the opposite approach: define the world you need, lock it down with cryptographic hashes, and make it reproducible everywhere—from a teammate’s laptop to CI.

If you’ve spent more time debugging environment drift than debugging code, this is the pivot you’ve been looking for.

Why developer environments keep breaking

In most teams, “the dev environment” is a pile of assumptions:

The “right” Node or Python version is installed… somewhere.
OS-level libraries exist… on some machines.
Tooling plugins match… mostly.
Your local ~/.config and ~/.cache don’t accidentally influence runtime behavior.
Someone’s favorite workaround didn’t get written down, because it “only matters on this one distro.”

Even with Docker, the story doesn’t fully change. Containers give you a clean filesystem and a repeatable filesystem layout, but they often rely on:

A base image that drifts over time (even when you “pin” vaguely).
Build steps that can introduce nondeterminism (apt repositories, network timing, transitive dependency churn).
A “container for dev” that still depends on the developer to pull the right tags, mount volumes correctly, and set env vars.

Net result: you trade one class of pain for another. The real issue is not packaging—it’s declaration and isolation.

Nix flips the model: declare everything, isolate it

Nix is built on a simple, radical premise: the environment should be derived entirely from inputs you declare, not from what happens to exist on a machine.

Instead of “install these things and hope,” Nix treats each dependency—system libraries, language runtimes, compilers, build tools, CLIs—as something that can be represented precisely. Those definitions are versioned and stored in a content-addressed way: when your inputs change, the resulting environment changes too, and Nix knows exactly how.

The crucial part isn’t just that it installs dependencies. It’s that it produces an environment that is:

Deterministic: same declared inputs → same environment.
Isolated: dependencies don’t leak into each other or rely on global state.
Composable: you can build new environments by combining precise pieces.

That’s why Nix feels different. It doesn’t ask developers to follow instructions. It asks them to accept a specification.

Reproducibility with Nix flakes: the “it works in CI” factor

Where teams really feel the pain is the transition from “local works” to “CI passes.” Nix flakes address that by turning your environment definition into a first-class artifact you can reference across machines.

A “flake” is essentially a reproducible bundle: you define inputs (like specific package sources) and outputs (like a dev shell). Then you let Nix resolve and build the exact dependency graph.

Here’s the practical payoff: your CI pipeline can use the same environment definition your developers use locally. That means the question stops being:

“Why does CI fail when it works here?”

…and becomes:

“Which input changed, and what exactly did it change?”

You can also pin versions tightly. When you upgrade something, you upgrade intentionally, and the diff is real—because Nix computes the new closure from your new inputs.

If you’ve used Docker with “latest” tags or a half-pinned base image, you already understand the temptation that reproducibility battles. Nix makes that temptation less productive.

A concrete workflow: `nix develop` for instant parity

Let’s say you’re building a service with a Rust backend and a Node-based toolchain (common in modern stacks). In a README-driven world, your setup might be spread across:

language version managers (sometimes conflicting),
OS package installs for shared libs,
global npm installs,
special environment variables that “you’ll see in the docs.”

In a Nix world, you specify those requirements once. Then the developer experience becomes boring—in the best way.

A developer runs:

nix develop

…and gets a shell with the right Rust toolchain, the Node version you declared, and any system libraries your builds require. No “install this, then reboot, then run this script.” No “wait, you’re on the other minor version.” The environment is built from a dependency graph rather than a set of vibes.

Practical advice for making this stick

If you’re adopting Nix, don’t try to boil the ocean on day one. Start with the highest-friction parts:

Put build tools under Nix first: compiler, language runtime, and core build dependencies.
Then add OS libraries that previously lived in “install on Ubuntu/Debian” instructions.
Finally add dev conveniences (formatters, linters, test runners, CLIs).

This incremental approach matters because teams often resist the learning curve when they don’t see immediate benefits. Your first win should be: “I can stop explaining setup.”

Dev containers aren’t wrong—but they’re incomplete

Dev containers are a good idea: they make the environment portable and reduce host-specific differences. But they tend to be procedural. You write steps; the result depends on the state of registries, network availability, and how carefully you pin versions.

Even when you’re disciplined, you still get friction:

Rebuilding images for small changes can be slow.
Updating base images can introduce subtle drift.
You can end up with two sources of truth: the Dockerfile and the README, or the Dockerfile and your CI scripts.

Nix doesn’t eliminate every form of overhead—nothing eliminates all cost in software. But it targets the real defect: “the environment isn’t defined as a pure function of inputs.”

In other words, Docker can help you ship a known filesystem. Nix aims to ship a known world.

And once you’ve experienced a nix develop that consistently lands you in the right environment, the “works on my machine” genre starts to look like legacy software.

The learning curve: steep, but worth designing around

Nix has a reputation for being difficult, and that’s not entirely unfair. You’re stepping into a new way of thinking:

Instead of installing things globally, you define them.
Instead of relying on mutable state, you embrace immutability and composition.
Instead of a linear “do these commands,” you specify a graph.

But the learning curve softens fast if you treat Nix like infrastructure, not like magic. A few strategies that work in real teams:

Template your flake outputs: standardize a “dev shell” pattern and reuse it across repos.
Document the interface, not every internal detail: developers shouldn’t need to memorize the whole Nix language to run the shell.
Make upgrades explicit: when you bump a dependency, it should be obvious which input changed.
Keep your scope tight: define exactly what the build and dev tooling needs, no more.

If you do this right, developers mostly interact with a stable command set, not a novel programming language.

And yes—initial setup will feel awkward. But awkwardness tends to fade when the payoff is immediate: fewer environment bugs, faster onboarding, and fewer CI “surprises.”

Conclusion: reproducibility is a feature, not a ritual

Reproducible development environments aren’t a luxury for elite teams—they’re a foundation for velocity. Dev containers reduce drift, but Nix tackles the root cause: environments should be derived from declared inputs and isolated with cryptographic precision.

Once your team stops treating setup as tribal knowledge and starts treating it as a versioned artifact, the entire development workflow tightens. nix develop becomes less like a tool and more like a contract: the environment you run locally is the one you build, test, and deploy against.

That’s the future—because it’s the only future where “works on my machine” stops being a recurring headline.

The Surprising Depth of Modern HTML

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 16 Jan 2023 00:00:00 +0000

Most developers treat HTML like a dumb container: a place to put <div> tags and hope JavaScript fixes everything later. That mindset is dated. Modern HTML has grown into a capable UI and data-validation layer—quietly, steadily, and without asking for attention. If you’ve stopped learning HTML since the “2015 era,” you’re almost certainly paying extra complexity to solve problems the browser already knows how to handle.

Let’s talk about the overlooked depth: dialogs, accordions, lazy loading, form validation, and a few adjacent features that let you ship cleaner, faster, more maintainable front ends with less JavaScript.

HTML Isn’t Just Markup Anymore (It’s a UI Contract)

HTML used to be “structure, then script.” That’s still mostly true—but the split has narrowed. Browsers now interpret HTML attributes and semantics in ways that used to require custom code.

The practical implication is simple: before you reach for a JavaScript solution, ask whether HTML can do it declaratively. Not because JavaScript is “bad,” but because native browser behavior is usually:

More consistent (works across pages and components without extra glue)
More accessible by default when you use the right semantics
Less code to maintain and less surface area for bugs
Faster to load when you can reduce scripts and event handlers

You don’t need to make your app “HTML only.” You do need to stop treating HTML as powerless.

Dialogs: Native Modals Without a Library

If you’ve built modal dialogs, you already know the usual pain: focus trapping, ESC-to-close, preventing background scroll, keyboard navigation, ARIA wiring, click-outside behavior, and lifecycle edge cases. Most teams solve this once with a library and then never question whether they could do better.

The built-in <dialog> element is the point where “HTML as structure” becomes “HTML as interaction.” It’s designed for exactly this job.

<button id="open">Open settings</button>

<dialog id="settings">
 <form method="dialog">
 <h2>Settings</h2>
 <label>
 Notifications
 <input type="checkbox" name="notify" checked />
 </label>
 <menu>
 <button value="cancel" formmethod="dialog">Close</button>
 <button value="save" id="saveBtn">Save</button>
 </menu>
 </form>
</dialog>

<script>
 const dialog = document.getElementById('settings');
 document.getElementById('open').addEventListener('click', () => dialog.showModal());

 dialog.addEventListener('close', () => {
 if (dialog.returnValue === 'save') {
 // read form values if needed
 console.log('Save clicked');
 }
 });
</script>

You still need a little JavaScript to open it and handle results—but you avoid the entire “modal implementation” layer. The browser handles the semantics and default behavior; you handle the application logic.

Opinionated take: if your current modal solution is a pile of focus and keyboard handling code, you’re probably over-engineering. Start with <dialog> and only customize behavior when you truly must.

Accordions and Details: Let HTML Do the Toggling

Accordion components are everywhere: FAQs, filters, docs sections. Historically, teams built them by hand: ARIA attributes, aria-expanded, click handlers, and CSS states.

Modern HTML gives you a native pattern: the <details> element and its sibling <summary>. Together, they implement the “expand/collapse” behavior with semantics the browser understands.

Example: A native accordion

<details>
 <summary>What’s included in the plan?</summary>
 <p>Everything you need to ship: templates, components, and support.</p>
</details>

<details>
 <summary>Can I change my billing later?</summary>
 <p>Yes. Update your payment method and switch tiers anytime.</p>
</details>

Want one open at a time? That’s still possible with a tiny amount of JS, but you can often avoid it by accepting “multiple open” behavior. Users generally don’t need complex behavior for basic FAQs.

Practical advice: if you’re using an accordion library, check whether it’s adding value beyond styling. If the behavior is just expand/collapse, native HTML is a strong default.

Lazy Loading: `loading="lazy"` Beats Custom Image Scripts

Image lazy loading is one of those features that used to be “required engineering.” You’d wire an IntersectionObserver, manage placeholders, handle edge cases, and hope it worked across browsers.

Today, for the common case, HTML has the answer: the loading attribute.

Example: Native lazy loading

<img
 src="/images/product-3.jpg"
 alt="Product photo"
 loading="lazy"
/>

This is intentionally modest: it won’t replace every advanced strategy (like responsive srcset decisions, complex prefetching rules, or sophisticated viewport heuristics). But if your current code is basically “lazy load images as they approach the viewport,” you can almost certainly remove a chunk of JavaScript and let the browser handle it.

Opinionated take: treat loading="lazy" as the default. Add custom logic only when you’re solving a genuinely specific problem, not because “we always did it with JS.”

Form Validation: Stop Writing Tiny Validators

One of the biggest areas where developers accidentally reinvent the wheel is validation. Many teams write JavaScript that checks “this field must be an email,” “this must be at least N characters,” or “this should match a format.” Then they display errors based on the result.

Modern HTML supports validation attributes that perform checks natively and integrate with browser UX patterns.

Example: Validate with `pattern`, `minlength`, and more

<form>
 <label>
 Username
 <input
 name="username"
 required
 minlength="3"
 maxlength="20"
 pattern="^[a-zA-Z0-9_]+$"
 title="Use only letters, numbers, and underscore."
 />
 </label>

 <label>
 Zip code
 <input
 name="zip"
 required
 inputmode="numeric"
 pattern="^\d{5}(-\d{4})?$"
 />
 </label>

 <button type="submit">Create account</button>
</form>

This gives you:

Built-in browser feedback behavior
Reduced JS code
Better accessibility because the browser knows what constraints exist

If you do need custom validation logic (cross-field checks, server-backed constraints), you can still use JavaScript—but the “basic constraints” should live in HTML whenever possible.

Practical advice: When a validator is purely about data shape, don’t hide that knowledge in JavaScript. Put it in HTML so it’s visible, declarative, and consistent.

HTML isn’t just about widgets. It’s also about semantics that the browser and assistive technologies understand.

A few examples that commonly get overlooked because they’re “obvious” when you learn HTML but quietly disappear in real projects:

Use real headings (<h1>–<h6>) instead of styled text pretending to be headings.
Use lists (<ul>, <ol>) for collections instead of stacking <div> elements.
Use buttons (<button>) for actions instead of clickable <div>s.
Use <label> tied to form fields so clicking text focuses inputs.
Use meaningful link text and avoid “click here.”

These choices reduce the need for custom scripting and increase usability. The browser will handle keyboard navigation and focus behavior in ways that are difficult to replicate manually without careful attention.

Opinionated take: if you find yourself adding JavaScript just to make interaction “work,” it’s often a sign that your underlying semantics aren’t communicating intent to the browser.

A Better Workflow: Decline JavaScript by Default

The most effective way to benefit from modern HTML isn’t to memorize every tag and attribute. It’s to adopt a workflow:

Start with structure and semantics. Can you express the UI with native elements?
Check for declarative capabilities. Dialogs? Accordions? Validation? Lazy loading?
Add JavaScript only for state and business logic. Not for basic interaction mechanics.
Measure tradeoffs. If custom behavior is required, fine—but justify it.

A concrete example: suppose you’re building a product page with

an FAQ accordion,
a “quick settings” modal,
images that load as users scroll,
and a sign-up form with constraints.

A strong approach is to use:

<details>/<summary> for FAQs,
<dialog> for the modal,
loading="lazy" for images,
and HTML validation attributes for input constraints.

Then use a small amount of JS to coordinate submission, update server state, or perform cross-field logic. You’ll end up with fewer event listeners, less UI code, and an interface that feels more “native” to the browser.

Conclusion: Stop Paying JavaScript Tax for Things HTML Already Solves

Modern HTML has matured into a practical toolkit for UI behavior, validation, and performance. The “HTML is dumb” assumption is no longer just outdated—it’s expensive. Use <dialog> for modals, <details>/<summary> for accordions, loading="lazy" for images, and validation attributes for form constraints. When you combine those with sound semantics, you’ll write less JavaScript and ship interfaces that are easier to maintain, more accessible, and faster by default.

The Death of Heroku and What It Means for Developer PaaS

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 10 Jan 2023 00:00:00 +0000

For years, “deploy to Heroku” was the punchline and the strategy: spin up a real web app in minutes, keep costs near zero, and iterate without thinking too hard. When Salesforce removed the free tier in late 2022, the community didn’t just lose a feature—it lost a safety net. And the scramble that followed turned “platform as a service” from a convenience into a risk decision.

This is the real lesson of Heroku’s fall: if your PaaS model depends on free hosting, you’re not building a product—you’re building your roadmap on someone else’s pricing page. The good news is that the alternatives aren’t just replacements. In many cases, they’re improvements.

What “Heroku’s Free Tier” Really Was (and Why It Mattered)

Heroku’s free tier wasn’t simply cheaper hosting; it was an ecosystem trigger. It made it normal for developers to:

prototype in public,
ship side projects that needed a real domain and SSL,
test integrations end-to-end without fiddling with local tunnels,
and share reproducible deployments with friends or teammates.

Once you can reliably run your app in production-like conditions, your development process changes. You stop treating deployment as a separate discipline and start treating it as part of the build loop.

So when the free tier ended, the impact was immediate and cultural. People had apps that were “free enough” to keep running. Those apps didn’t disappear magically—they just stopped working the way their authors planned. That forced a new conversation: Where do we run small apps now, without waking up to surprise bills or downtime?

The Great Migration: Render, Railway, Fly.io, and Coolify

The post-Heroku scramble looked chaotic from the outside, but it was actually a series of clear design responses to the same anxiety: “Don’t make me fight infrastructure.”

Railway: Monorepos, fast iteration, and sensible defaults

Railway’s pitch is straightforward: keep deployments simple, and play well with real codebases. In practice, that often means better support for modern repo layouts than older “single app” mental models. If you’re working with a monorepo—say, a Next.js frontend plus a Node API plus background workers—Railway’s workflows can feel less like a contortion and more like a deployment system.

A practical example: if you maintain a monorepo with a shared package and multiple services, you want a platform that won’t punish you for not fitting into a single-project mold. Railway’s approach tends to treat “application” as something broader than “one web dyno.”

Render: A free tier with “real-world” expectations (including SSL)

Render’s big differentiator in this era is how naturally it maps to production expectations. For many indie developers, “free hosting” that doesn’t come with SSL or a smooth domain story isn’t actually usable. Render helped make the free-tier conversation feel less like a compromise and more like a baseline.

If you have a SaaS landing page plus a simple API, the ability to put SSL in front of everything without manual ceremony matters. You want to test payment webhooks, OAuth callbacks, and secure fetch calls without building your own deployment scaffolding.

Fly.io: Edge deployment and the promise of “closer to users”

Fly.io went hard on a different idea: compute near your users rather than funneling everyone through a single region. That can be more than marketing. If you’re serving a global audience—or your app latency is noticeable—you can architect deployments that reduce “distance tax.”

A concrete use case: a chat app for users in different continents often feels different when the server is region-aware. Fly.io’s model encourages thinking in those terms, even if you start small.

Coolify: Bring PaaS thinking into your own infrastructure

Coolify represents a more pragmatic mood shift: “If platforms are a business, their guarantees are business terms. Let’s reduce the blast radius.” Coolify lets you get PaaS-style workflows—apps, builds, environments—on your own server(s).

That’s not for everyone, but it’s a critical counterpoint. Sometimes the best way to stop being surprised is to stop outsourcing the entire control plane.

The Hidden Contract You Were Ignoring: Free Tiers Are Not Promises

The Heroku chapter exposed a basic contract assumption many developers didn’t realize they were making:

“Free” isn’t a right; it’s a lever.
Pricing changes don’t require your permission.
Ecosystems rebalance quickly when the economics shift.

Even when a provider doesn’t intend to break community trust, it only takes one internal decision—cost structure changes, growth strategy, or revenue pressure—to flip the game. In other words: the free tier is a convenience, not infrastructure.

So the question becomes: How do you design your deployment strategy so pricing shocks don’t derail your project? The answer is not “pick the best PaaS.” The answer is “build portability and reduce lock-in.”

What Better Alternatives Teach Us About Future Developer PaaS

The new generation of developer PaaS isn’t just “Heroku but cheaper.” It reflects different philosophies about what matters for real builders.

1) Developer experience is a technical feature

“Easy deployment” is not fluff. It directly affects iteration speed, debugging time, and how often you can test changes safely. Platforms that reduce steps—connect repository, set env vars, deploy, get logs—effectively shorten the time between idea and feedback.

If your chosen PaaS makes every small change feel expensive or risky, you’ll develop workarounds. Those workarounds become technical debt.

2) Modern repo realities are no longer optional

Monorepos, background workers, preview environments, and multiple services aren’t edge cases. If a platform makes these awkward, you’ll pay later.

Railway’s monorepo-friendly posture and Fly.io’s deployment flexibility are both ways of acknowledging this reality. The best platforms don’t ask you to contort your project into their favorite shapes.

3) “Production features” on free tiers matter

An SSL-enabled domain isn’t just a checkbox. It affects authentication flows, secure cookies, webhook verification, and even basic browser behavior. When providers offer these capabilities in their free tier (or at least make them painless), developers can keep projects alive in a way that feels legitimate, not improvised.

Render’s emphasis here hits the practical nerve: if your app is public, users expect secure access without extra steps.

4) Edge deployment is an architectural advantage, not a luxury

Fly.io’s approach pushes you toward thinking about placement and latency. Even if you start with a single region, the mental model encourages better performance hygiene as your app grows.

The win isn’t only speed; it’s a cleaner path to scaling responsibly.

5) You need an escape hatch

Whether your fallback is another PaaS or your own orchestrator, portability is insurance. Containerization and clear infrastructure boundaries are the antidote to “platform surprise.”

In practice, this means:

keep build steps reproducible (Dockerfile or equivalent),
avoid deep platform-specific APIs unless absolutely necessary,
store secrets and configuration in a way you can rehydrate elsewhere,
and document how you deploy.

A Playbook for Post-Heroku Decisions (So You Don’t Get Bit Again)

If you’re picking a PaaS today, don’t start with “What’s the free tier?” Start with “How do I keep moving if the floor disappears?”

Here’s a pragmatic checklist:

Define your portability level.
Are you okay re-deploying your app to another provider in a day? Or would you rather migrate in an hour? Your answer determines how much platform-specific wiring you should accept.
Choose the platform that matches your architecture.
- If you want fewer deployment headaches for complex repos, lean toward providers that treat monorepos as normal (Railway-style thinking).
- If you want a clean path to public apps with domains and SSL, prioritize providers that make “public by default” easy (Render-style).
- If latency and global footprint matter, consider edge-first platforms (Fly.io’s model).
- If you want control and resilience, consider a self-hosted PaaS layer (Coolify-style).
Treat free hosting like a development environment, not a business guarantee.
You can absolutely run a side project on a free tier—but build the habit of having an upgrade path. Set budget alerts where possible. Even a small monthly cost is often cheaper than rebuilding your deployment pipeline under stress.
Automate the boring parts.
If you can re-deploy with one command and one documented process, the platform choice matters less. Automation turns platform churn into a routine event.
Plan for state.
Databases, queues, and file storage are where migrations hurt. Keep state external to your web app when you can, and understand how each platform backs services.

Conclusion: The PaaS Future Is Better—If You Design for It

Heroku’s free tier ending didn’t just change where developers deploy. It forced the community to confront a long-ignored truth: PaaS convenience is conditional on provider economics. But the aftermath also proved something encouraging: the ecosystem didn’t collapse—it evolved.

Fly.io’s edge mindset, Railway’s monorepo-friendly workflows, and Render’s “actually usable” free tier with SSL collectively make post-Heroku life genuinely pleasant for many builders. Just don’t confuse “great alternatives” with “permanent assurances.” Build portability, keep deployment reproducible, and treat any free tier as a temporary advantage—not a foundation.

ChatGPT Is a Parlor Trick That Will Reshape Software Engineering

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 04 Jan 2023 00:00:00 +0000

ChatGPT is the most theatrical thing to happen to software engineering in years: it talks like a genius, sometimes writes like a beginner, and occasionally manufactures facts out of pure confidence. If you’re unimpressed, you’re not wrong. If you’re dismissing it, you’re also probably wrong. The real story isn’t whether it’s “correct” today—it’s the direction it’s taking your job, your tools, and your expectations of how software gets built.

The parlor trick: fluent nonsense that feels useful

Let’s start with the obvious. Large language models can hallucinate. They can produce code that fails tests. They can explain a concept accurately in a way that still doesn’t help you implement it. They can present uncertainty as certainty, which is a special kind of danger in engineering.

But here’s what’s easy to miss: a parlor trick still works if it moves attention. ChatGPT doesn’t just answer questions—it compresses an ocean of patterns into a conversational interface. That interface changes how developers feel about asking for help.

Consider a real workflow. You’re stuck debugging a flaky integration test. You can:

Search docs for an hour and still come up empty.
Or paste the error log, the relevant code snippet, and your hypothesis into ChatGPT and get back a structured set of suspects: race conditions, test isolation, network retries, timeouts, mocking mismatches.

Sometimes the model is wrong. But the first pass is often good enough to narrow the search space dramatically. That’s the trick: not magic correctness, but fast guidance.

The “today” version matters less than the “tomorrow” direction—because the interface is becoming the new terminal prompt, the new ticket comment, the new design sketch.

The underestimation problem: developers are judging the tool, not the trajectory

Most developers are still thinking in the wrong frame. They’re asking questions like: “Can it replace programmers?” or “How often does it hallucinate?” Those are understandable, but they’re also the wrong scoreboard.

Software engineering is not a static craft; it’s a compounding system of feedback loops:

You write something.
You test it.
You observe the failure mode.
You refine the design.
You automate what you learned.

LLMs slot into that loop as a new kind of pre-processing layer for thinking. The models don’t have to be perfect to shift the system. They only have to be useful enough to reduce the cost of iteration.

And iteration is where software gets transformed. Even a modest improvement in:

how quickly you draft a candidate solution,
how quickly you translate requirements into concrete code,
how quickly you locate likely root causes, multiplies across every feature, every incident, and every onboarding cycle.

The frightening part is not that the model is already “great.” It’s that engineering teams will normalize using it in the middle of the workflow—until they can’t imagine working without it.

LLMs aren’t code generators—they’re thinking partners (or they fail loudly)

The biggest practical shift is this: stop treating ChatGPT like a machine that outputs working software. Treat it like a thinking partner with a strong autocomplete brain and a weak truth sense.

That means you should engineer prompts the way you engineer systems: with constraints, inputs, and feedback.

Do this: give context + ask for plans, not just outputs

Instead of “Write me an API client,” try:

“Here are the constraints: authentication uses rotating tokens, requests must be idempotent, timeouts are 2s, and the server returns 429 with a Retry-After header. Propose an implementation plan first, then code.”
“Given this TypeScript interface and this example response payload, generate parsing logic and explain edge cases that could break it.”

You’re forcing the model to behave like a collaborator—planning before executing—reducing the odds of confident nonsense.

Do this: demand test scaffolding and failure modes

A productive question looks like:

“Write unit tests for the parsing logic, including malformed inputs and boundary cases. Then show how you’d validate the retry behavior under 429.”

The key is that you’re not trying to get “correct code on the first try.” You’re trying to accelerate the path to evidence.

Don’t do this: paste a vague task and accept the answer unverified

If you ask for “a caching layer,” you will get a story. If you ask for “a caching layer that avoids stampedes using request coalescing, supports TTL invalidation, and includes an integration test strategy,” you will get engineering artifacts you can actually evaluate.

In practice: the model will still be wrong sometimes. But wrongness becomes manageable when you’re asking for structure, assumptions, and tests—not miracles.

The real engineering change: from building code to orchestrating feedback

When LLMs become normal, the unit of work changes.

Traditionally, you “build code.” With LLMs, you “orchestrate refinement.” The most valuable developers won’t be the ones who can prompt the slickest one-liner—they’ll be the ones who can set up evaluation quickly and relentlessly.

Here’s how that looks in day-to-day engineering:

1) Faster drafts, but with guardrails

LLMs can draft:

endpoints,
serializers,
database queries,
migration scripts,
documentation,
error-handling patterns.

But the winning teams wrap those drafts in guardrails: type checks, linting rules, unit tests, property-based tests where appropriate, and review checklists that explicitly look for common failure modes.

2) Review becomes “prove it” instead of “read it”

Code review will shift from “does this look sensible?” to “show me the evidence.” Expect more pull requests that include:

test plans,
rationale for tradeoffs,
links between requirements and implementation,
explicit handling of edge cases.

Even if the LLM wrote half the code, the human’s responsibility becomes sharper: validating behavior and aligning with system constraints.

3) Debugging turns into interactive diagnosis

In incidents, time is everything. Teams will start using LLMs to:

summarize logs and trace patterns,
propose hypotheses in priority order,
generate targeted reproduction steps,
draft remediation PRs that include tests.

This won’t eliminate debugging. It will change how quickly you get to the right questions—and how often you stop flailing.

Who will thrive: the engineers who treat AI like a new layer of tooling

The developers who will thrive are not necessarily the most enthusiastic ones. They’re the ones with the right mental model and the right habits.

Thrivers will:

Demand plans and tests, not just final answers.
Use the model to accelerate exploration, then validate via tooling.
Translate requirements into concrete constraints (timeouts, retries, idempotency, security boundaries).
Know where hallucinations are likely and design prompts to reduce that risk.
Build reusable prompt patterns for their stack (e.g., “generate migrations with rollback,” “handle pagination with cursor semantics,” “never invent env vars—ask for them”).

Strugglers will:

Dismiss AI entirely and keep paying the “blank screen” cost when stuck.
Trust blindly and ship untested behavior because the output sounded plausible.
Treat prompts like magic incantations rather than engineering inputs that require iteration.

The difference isn’t talent. It’s discipline.

A concrete example: onboarding. With LLMs, you can accelerate “how does this codebase do X?” But the thriving approach is to ask for:

an explanation of architecture,
a walkthrough of a representative module,
a list of relevant entry points,
and a suggestion for a small “first contribution” task.

The failing approach is to ask for “an overview,” accept it, and then get blindsided by the real design constraints that the model never saw.

The uncomfortable truth: hallucinations force better engineering, not weaker it

Yes, LLMs hallucinate. Yes, they can produce buggy code. And if you treat that as a reason to stop using them, you’ll miss the point.

Hallucinations are a forcing function. They push you toward:

tighter feedback loops,
stronger test culture,
clearer requirements,
explicit contracts between components,
and better separation between “draft” and “verified.”

In other words, the risk can make the process better—if your team responds with engineering rigor rather than wishful thinking. The model’s confidence becomes a prompt for you to add structure: validations, tests, and operational checks.

This is what makes the transformation “terrifying” in a productive way. Once engineers internalize that LLMs are unreliable narrators but powerful accelerators, software development becomes more experimental, more iterative, and less gated by how long you can stare at a problem.

That’s a structural shift.

Conclusion: the parlor trick becomes the toolchain

ChatGPT can be a parlor trick—confident nonsense dressed in helpful language. But the parlor trick is exactly how it rewires engineering: it makes collaboration feel instantaneous, it shrinks the time between questions and candidate solutions, and it turns iteration into the default mode.

The winners won’t be the ones who worship the model or ignore it. They’ll be the ones who treat LLMs as thinking partners inside a disciplined system of verification. If you build that muscle now—plans, constraints, tests, evidence—you won’t just adapt to the change. You’ll outpace the people still arguing about whether it’s “real.”

Five Developer Tools I Can't Live Without in 2022

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 22 Dec 2022 00:00:00 +0000

Most developer “productivity advice” sounds like it’s trying to sell you a new framework. I’ve stopped chasing shiny. The tools that actually make me faster are quieter—little interfaces that remove friction from work I do constantly. After a year of experimenting, these are the five developer tools I’d miss first. Not because they’re glamorous, but because they compound: shave seconds off every task, and you magically earn back hours by the end of the month.

Warp Terminal: AI command search that actually feels instant

I don’t use terminal menus. I use muscle memory—until I don’t. Warp Terminal fixed that gap with AI-powered command search, which is especially useful when you’re trying to remember the exact incantation you ran yesterday.

Here’s what this looks like in real life: I’ll be half-thinking about a task—“I need to tail logs for that service”—but I’m not sure which command I used last time. Instead of fumbling through history or scanning docs, I type a partial intent and Warp narrows down the candidates. It’s not magic; it’s fast retrieval. And fast retrieval beats slow recall.

Practical ways to lean into it:

Search by purpose, not by command. If you’re working with Docker, Kubernetes, or a custom CLI, use natural language like “restart api container” or “stream logs web worker.”
Keep your history clean enough to matter. If you run scripts that generate noise, consider aliases or wrapper scripts so your “searchable” history remains useful.
Use it as a bridge, not a crutch. I still memorize frequent commands, but Warp handles the long tail—the ones you only run occasionally.

Warp also improved my baseline terminal experience: speed, keyboard navigation, and a UI that encourages you to iterate rather than hesitate. In practice, it reduces the “I should look this up” moments that quietly steal focus.

Raycast: the Spotlight replacement that understands developers

If Warp makes the command line easier to navigate, Raycast makes the computer itself easier to navigate. For me, it effectively replaced macOS Spotlight as the default “search and launch” surface—except it’s faster, more configurable, and built for repeatable workflows.

The difference is subtle: Spotlight is great for finding files and launching apps. Raycast is great for doing tasks. That means you don’t just open the thing—you get the right action immediately.

Concrete examples that show why I kept it:

Jumping between projects. Instead of digging through folders, I hit Raycast and type the project name. It opens the right directory, sometimes with a command to start the dev server.
Clipboard and snippet workflows. Copy something in one app and insert it into another without manually juggling context. If you do any kind of copy/paste-heavy work (migrations, config updates, API payloads), Raycast pays for itself quickly.
Command palettes for dev chores. You can build or install extensions that perform actions like “create branch,” “run test,” “open logs,” or “switch environments.” The win isn’t that it’s novel—it’s that it removes steps you repeat daily.

My rule: if I catch myself switching windows, hunting through menus, or retyping routine actions more than twice in a day, Raycast is where I fix it. I treat it like part of my workflow infrastructure, not a “nice-to-have launcher.”

Fig: shell autocomplete that turns typing into intention

Autocompletion is one of those benefits that’s easy to underestimate until you use it for a week. Fig extends your terminal experience with smarter autocomplete, which helps when your CLI ecosystem is large: multiple package managers, internal commands, and a web of scripts that never quite share the same flags.

The best part is that autocomplete isn’t just about saving keystrokes. It’s about preventing mistakes. When you’re halfway through a command and you realize you forgot a flag—or you used a wrong argument—you can waste minutes rerunning. Fig reduces that by making the likely next tokens visible.

How I use it:

Autocomplete for flags and subcommands. If I’m working with tools like git, docker, or a framework CLI, Fig makes it easy to discover valid options without memorizing syntax.
Tab-completion for “where did this live again?” moments. When you have scripts across repos, Fig helps you navigate the landscape faster than searching by filesystem paths.
Speed during refactors. Renaming commands, changing environments, or swapping parameters becomes less scary because the shell can guide you as you type.

If you already have a great terminal workflow, you might think Fig is redundant. It isn’t. It’s the layer between “I know what I want” and “I can’t remember the exact text.” That layer saves time and lowers mental load.

TablePlus: database work that doesn’t feel like punishment

Databases are where productivity goes to die—unless your tool gets out of the way. I use TablePlus for everything from quick inspections to more involved admin tasks. The key feature isn’t just that it works; it’s that it makes database work comfortable.

When I’m debugging, I want two things immediately:

Fast visibility into what’s happening (tables, rows, indexes, schema).
Low-friction editing (writing queries, running them, iterating, copying results).

TablePlus nails the loop: open connection → inspect schema → write query → run → adjust → repeat. The UI matters because database work is iterative by nature. When the tool is clunky, iteration slows down. When it’s smooth, iteration becomes normal.

A few practical workflows I rely on:

Inspect schema without tab-hopping. I can look up columns and constraints without bouncing between a migration file, an admin UI, and documentation.
Query iteration with results in view. I often build queries step-by-step. Being able to tweak and re-run with minimal friction reduces the “SQL downtime tax.”
Export and share results quickly. When debugging with teammates, sending the right snippet matters. TablePlus makes it easier to extract exactly what someone needs.

For a surprising number of developer tasks, the database is the source of truth—and TablePlus turns the source of truth into something you can access without suffering.

Obsidian: the documentation system that stays out of your way

Codebases change. Your memory won’t. Obsidian is my technical documentation “home base” because it’s flexible enough to capture messy reality: notes, snippets, decisions, postmortems, and links between them. It’s not a formal doc platform. It’s better than that—it’s a living workspace.

I use it for exactly the kind of documentation teams avoid because it’s “not urgent.” That’s where Obsidian wins: it makes documentation feel lightweight and immediate, so you actually keep it current.

Examples of notes I maintain:

Runbooks for recurring problems. “How to reset X” or “What to check when Y fails” in a format I can search in minutes.
Project decision logs. When we choose a library, change an architecture, or decide not to adopt something, I record the reasoning. Months later, I can answer “why” without guessing.
Snippets with context. Not just code blocks—include where it came from and when to use it.

What makes it effective is the compound behavior: once you’ve connected related notes, you stop re-explaining the same concepts. Search becomes meaningful, not just a pile of text. And when you’re onboarding or debugging at 2 a.m., that “connected knowledge” matters more than any polished markdown page.

My approach is simple: if I fix something that future-me will have to do again, I write down the fix while it’s fresh. Obsidian makes that habit practical.

The real lesson: invest in the local dev environment before your stack

None of these tools are frameworks or languages. That’s the point. They’re productivity multipliers in the most boring place possible: your local workflow. They reduce friction around the activities you repeat constantly—typing commands, switching contexts, querying databases, and finding answers later.

In my experience, “stack investing” is easy to justify because it’s visible: new framework, new library, new architecture. But the daily time sink is usually the environment around the stack—how quickly you can operate it, navigate it, and recover from mistakes.

If you want a practical starting point, do this:

Pick one bottleneck you hit daily (command recall, app switching, DB debugging, or documentation retrieval).
Trial one tool for a week.
Measure the time you spend on the annoyance, not the time you spend admiring the feature.
Keep the tool only if it becomes part of your default workflow.

Because the truth is, speed doesn’t come from doing more. It comes from doing less of what slows you down.

Conclusion: compound speed beats occasional heroics

Warp, Raycast, Fig, TablePlus, and Obsidian aren’t flashy. They don’t rewrite your architecture. They just make routine work smoother—and that’s exactly what turns small improvements into hours over time. If you want to get faster in 2022, start by fixing your local environment. That’s where productivity quietly lives, and where it compounds.

The Year JavaScript Grew Up: 2022 in Review

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 10 Dec 2022 00:00:00 +0000

In most technology stories, “progress” looks like novelty sprinting ahead of reality. In 2022, the JavaScript ecosystem did something rarer: it started treating stability like a feature, not a tax. The result wasn’t just new tools—it was a shift in what people expect their tools to do well.

TypeScript crossed the tipping point—because teams got tired of guessing

TypeScript didn’t “arrive” in 2022; it matured. The meaningful change was cultural: type safety moved from “nice-to-have” to the default expectation for serious codebases.

You can see it in the day-to-day decisions teams made:

Frontends stopped treating types as optional ceremony. If a refactor could silently break production, teams increasingly demanded compile-time protection.
APIs became self-documenting. When you ship a typed client or a typed backend boundary, you reduce the amount of tribal knowledge required to use the system.
Tooling improved enough that types stopped feeling punitive. Editors started catching issues immediately; modern TypeScript workflows made incremental adoption less painful.

A practical example: imagine a React app with dozens of API calls. Without types, you eventually end up with patterns like “assume response.data.user exists.” With TypeScript, you instead model the response shape—so missing fields become a build-time problem. That’s not theoretical. It changes how fast teams can refactor safely.

My opinionated take: the “tipping point” wasn’t just people choosing TypeScript. It was people choosing predictability. Once you’ve been burned by a runtime shape mismatch, the value of types becomes obvious.

Bun showed that runtimes are still design space—not sacred history

Bun arriving in 2022 reminded everyone that JavaScript tooling isn’t frozen in time. A runtime isn’t merely an engine—it’s an integrated product: package management, bundling/transform behavior, developer experience, startup performance, and the ergonomics of everyday commands.

The key idea wasn’t “Bun is faster” (speed is easy to market and hard to reason about). The key idea was that the runtime layer is still something developers can rethink:

Friction matters. If your node-based workflow requires extra steps or inconsistent behavior across tools, teams feel it daily.
A runtime can offer a more coherent toolchain. When install, run, and script execution behave consistently, the environment stops being a source of bugs.

In practical terms, Bun’s biggest impact for many teams was exploratory. They started asking new questions like:

Can we standardize how scripts run across the monorepo?
Can we simplify dev startup without sacrificing compatibility?
Can we reduce the “glue code” between package manager, runtime, and build tool?

Even when teams didn’t switch their production workloads immediately, Bun shifted the conversation. It made it easier to believe that the ecosystem could improve the foundations instead of only adding more wrappers around the same assumptions.

Vite consolidated the build tool landscape—less ceremony, fewer moving parts

If TypeScript was about correctness and Bun was about reimagining runtime ergonomics, Vite was about something quieter: reducing the cognitive load of building frontend applications.

Vite’s value wasn’t just that it was fast. It also pushed teams toward a build setup that feels closer to how modern development should work:

Development and production behave consistently, with fewer “works in dev, breaks in prod” mysteries.
The default path became usable. Teams weren’t required to assemble a complicated stack just to get started.
Hot reload and module handling felt more direct, which reduces the number of times developers must mentally model the toolchain.

A concrete scenario: consider a team migrating from a more complex bundler configuration. The old setup might involve many options, custom loaders, and bespoke performance hacks. With Vite, the migration becomes less about rewriting your entire mental model and more about mapping concepts—entry points, assets, environment variables—into a simpler structure.

Opinionated truth: build tools aren’t where product ideas succeed. They’re where deadlines fail. Vite’s consolidation helped teams spend less time fighting configuration and more time shipping features.

Rust entered the conversation for a reason: teams wanted safer systems boundaries

2022 wasn’t a “Rust replaces everything” moment. That story is always too neat. But Rust entered the mainstream developer conversation because JavaScript teams kept running into the limits of the platform when they cared about performance and safety at the boundary.

The pattern usually looks like this:

Your Node/JS application needs a high-performance component—parsing, compression, crypto, file processing, or other CPU-heavy tasks.
Rewriting the entire app in Rust is unrealistic.
But depending on an unsafe native extension is also risky.

Rust offers a middle path: it’s suitable for writing reliable system-level components while keeping the surrounding ecosystem intact. Even if a team doesn’t adopt Rust directly, the pressure it adds to the ecosystem changes how people evaluate architectures.

A practical way to think about it: if your product needs predictable memory behavior, robust concurrency, or hardened parsing, you don’t just want speed—you want correctness under stress. Rust’s design choices make that conversation feel more grounded.

Docker cemented dominance: shipping became about consistency, not heroics

Docker didn’t become popular in 2022. It became even more essential. The reason is simple: containers made environments reproducible in a way that mattered when teams got larger and deployments got more complex.

In 2022, the value proposition sharpened:

“Works on my machine” became increasingly indefensible. Even small differences in OS libraries, Node versions, or dependency resolution can break builds.
CI/CD pipelines became more standardized. Teams could run the same image locally and in production-like environments.
Rollback and scaling got easier when the artifact is consistent.

A practical example: if your JavaScript app depends on a specific native module or system library, Docker becomes the difference between smooth onboarding and endless debugging. You bake the environment once, then treat it as an artifact you can reproduce.

My take: Docker’s real victory is not containers—it’s the operational maturity they enabled. Stability in the environment reduces the surface area for failures that have nothing to do with your code.

PostgreSQL kept conquering quietly—because reliability is a feature

Some technologies dominate headlines. PostgreSQL dominated production. In 2022, it continued its quiet conquest by being the default choice for teams who cared about correctness, operability, and long-term maintainability.

Even when new data stores appeared, many teams stuck with PostgreSQL because it offered:

A pragmatic balance of features and reliability
Solid tooling and migration patterns
A mature ecosystem of extensions, integrations, and operational practices

If you’ve run a database in the real world, you know this: the “right” database isn’t the one with the most futuristic options—it’s the one you can trust during incidents, migrations, and scaling events.

A good rule of thumb for 2022 thinking: if your team is building a business, not a database platform, your data layer shouldn’t be a research project. PostgreSQL let teams focus on product work while still giving them enough power to evolve.

Web3 burned through billions—and the ecosystem learned some painful lessons

Web3 entered 2022 with momentum and left with skepticism. The industry’s most visible feature wasn’t technical capability—it was overconfidence. Billions spent on promises without proportional delivery trained developers to demand accountability.

What changed in practice?

Teams became more cautious about timelines. “Soon” started meaning “we don’t actually know.”
Risk moved from theoretical to operational. Custody, upgrades, smart contract safety, and integration complexity became harder to ignore.
The market for prototypes narrowed. Investors and builders started demanding traction, not vibes.

The lesson for JavaScript developers is broader than any single sector: novelty can attract attention, but stability earns trust. If a system can’t be operated safely, its theoretical advantages don’t matter during outages.

Conclusion: 2022 wasn’t about new toys—it was about grown-up expectations

2022 marked a turning point for JavaScript: TypeScript made correctness mainstream, Bun proved runtimes could be redesigned, and Vite reduced build-time friction. Meanwhile, Rust, Docker, and PostgreSQL reinforced a larger theme—teams increasingly valued reliability at the boundaries: systems interfaces, deployment environments, and data storage.

The ecosystem didn’t stop innovating. It just started prioritizing what lasts. And if you build for longevity, you don’t chase novelty—you design for stability.

The Architecture Decision Record Changed How Our Team Communicates

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 01 Dec 2022 00:00:00 +0000

Every team has the same hidden cost: not the build time, not the cloud bills—communication drift. Six months after a big architecture decision, “why did we choose this?” turns into a scavenger hunt through Slack, half-remembered meeting notes, and tribal knowledge that lives in one person’s head. We fixed that with one small habit: Architecture Decision Records (ADRs). The change was less about documentation volume and more about documenting intent—so the team stops guessing.

What an ADR is (and what it isn’t)

An ADR is a short, lightweight document that records a significant architecture decision. The key is significant and architecture—not every code style preference, not every temporary workaround. We use ADRs to capture:

Context: What problem are we solving, and what constraints exist?
Options considered: What alternatives did we weigh?
Decision: What did we choose?
Consequences: What trade-offs did we accept, including known risks?

And here’s what it isn’t: it’s not a design spec. It’s not a wiki page that someone will eventually complete. It’s not meant to be beautiful or exhaustive. In practice, an ADR is a tiny artifact with a job to do: preserve the why so it’s still legible later.

Our rule of thumb is brutally pragmatic: if we would need to answer “why” from scratch in a future incident, migration, or onboarding, that decision deserves an ADR. If the decision is reversible and trivial, it doesn’t.

The format that makes ADRs actually stick

You can’t rely on motivation. You need a format that reduces friction.

We adopted a dead-simple structure:

ADRs live as numbered Markdown files under a /docs/adr directory
Each ADR follows a consistent template so anyone can scan and trust it

Example filenames:

/docs/adr/0012-move-to-postgres.md
/docs/adr/0013-introduce-event-driven-ingestion.md

A typical ADR document is compact—often 20–30 minutes to write, usually just a few sections with headings. The point isn’t to write a novel; it’s to make the decision findable and explainable.

Our template looks like this (conceptually):

Status (Proposed / Accepted / Deprecated)
Context
Decision
Options
Consequences

That template is doing more work than people think. It prevents the common failure mode where “documentation” becomes a blob of details with no recorded reasoning. When the team can read the same structure every time, the ADR log becomes a navigable timeline.

The real benefit: fewer “why?” conversations later

The best argument for ADRs is the one you can feel: fewer repeat questions.

Before ADRs, our communication had a predictable pattern. Early in a project, decisions were discussed in real time. Later, as the project scaled and people rotated, those same decisions became opaque. We didn’t lose knowledge because people were careless—we lost it because time happens.

Six months after a migration, someone would ask:

“Why are we using this queue instead of that one?”
“Why did we avoid synchronous writes?”
“Why did the service split happen the way it did?”

Those questions are not petty. They’re how engineers protect themselves from repeating mistakes. The problem is that the answers were locked in Slack threads, meeting minutes, or in the brain of a teammate who might not be available.

ADRs changed the default. Instead of starting from scratch, we now point to a document:

“Check ADR 0013—this was chosen because X, given the constraint Y, and we accepted Z.”

The conversation shifts from archaeology to engineering. That’s a real productivity win, but more importantly, it improves quality: fewer misunderstandings, fewer half-accurate assumptions, and faster alignment on trade-offs.

A concrete example: the “event-driven ingestion” decision

One decision that ADRs made dramatically easier to revisit was our move to event-driven ingestion. At the time, we had a familiar list of options:

Option A: Keep a batch job that periodically fetches and writes to the database
Option B: Use synchronous requests from the source to the service
Option C: Publish domain events and consume them asynchronously

In the ADR, we captured the context plainly:

We needed fresher data without overloading the source system.
We wanted resilience to transient failures.
We were concerned about backpressure and retry behavior.

Then we recorded the decision and the why:

We chose the event-driven approach because it decoupled producers from consumers and gave us controlled retry semantics.
We called out consequences up front: increased operational complexity, the need for idempotency, and a more deliberate debugging story (because “what happened” is spread across logs and event history).

When we later hit a performance issue, we didn’t argue about whether event-driven was “right” in theory. We worked with the documented trade-offs. Even better: we could compare our current symptoms to the consequences section and verify whether we were facing a known risk or a new failure mode.

That’s the difference between documentation that explains reasoning and documentation that only records outcomes.

How ADRs help onboarding—and reduce bus-factor risk

Onboarding is where communication debt becomes obvious. New teammates don’t just need to learn what exists—they need to learn why the system looks the way it does.

ADRs give new engineers a safe on-ramp. Instead of asking five separate people, they can read the ADR log and understand how the system evolved. That reduces “random questions” and shifts onboarding into a more confident, self-directed process.

We also treat ADRs as a lightweight hedge against bus-factor risk. When someone leaves, their knowledge shouldn’t vanish with them. ADRs don’t preserve every implementation detail, but they preserve what matters most: the architecture decisions and the logic behind them.

A practical tweak we made: we encourage engineers to link the ADR in the relevant PR description and in major design docs. That way, the decision isn’t isolated—it’s connected to code history and future context.

Keeping ADRs useful: discipline, scope, and updates

ADRs only work if they stay accurate and current. The fastest way to kill trust is to write an ADR and then pretend it’s still true after the world changes.

So we practice three disciplines:

Write for future readers, not for the meeting
If an ADR can’t be understood by someone who wasn’t in the room, it’s too vague. Be explicit about constraints and trade-offs.
Avoid “decision by committee” word salad
The ADR should clearly state what was decided. If there were disagreements, capture them as options and consequences—not as a transcript.
Update with replacement ADRs
When a decision is superseded, we don’t edit the old ADR into a different truth. We mark it deprecated (or replaced) and create a new ADR that explains the new context and updated trade-offs.

Also, keep scope tight. If you’re starting to write something that feels like a full system proposal, split it. The ADR should capture the decision, not document every parameter.

Finally, treat ADRs as living operational tools. When we face a production failure tied to architectural trade-offs, we refer back to the relevant ADR and check what was expected. That turns documentation into a feedback loop, not a dead artifact.

Conclusion: documentation that behaves like engineering

ADRs didn’t make our team “better at writing.” They made our team better at thinking together.

Instead of relying on memory, we preserved intent. Instead of replaying old debates, we referenced the recorded trade-offs. Instead of onboarding via Slack archaeology, we gave new engineers a clean timeline of decisions.

If you want the smallest change with outsized communication impact, start here: create a /docs/adr folder, adopt a consistent Markdown template, and commit to writing one ADR per meaningful architecture decision. You’ll feel the difference quickly—and you’ll thank yourself months later.

Astro Is the Static Site Framework That Actually Gets It Right

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 29 Nov 2022 00:00:00 +0000

Most static site generators brag about “fast” the way car companies brag about horsepower. Astro is different. It treats performance as a design constraint, not a marketing afterthought—and it makes the right defaults feel obvious. If you build content-heavy websites (blogs, docs, marketing sites, knowledge bases), Astro’s islands architecture and “zero-JS-by-default” philosophy give you a path to shipping less code without dumbing down the experience.

The real problem with “static” websites: everything becomes JavaScript

For years, the ecosystem’s default answer to interactivity has been the same: JavaScript-heavy frameworks, client-side rendering, and a growing pile of hydrated components that wake up as soon as the page loads.

Even when your homepage is mostly text and images, you often still pay for:

bundling large framework runtime code,
hydrating components you don’t need immediately,
running expensive scripts on the main thread,
and shipping JS that users may never execute.

The worst part is that the pain often hides behind smooth developer workflows. Your local dev server “feels fast,” your pages “work,” and production looks fine—until you test on slower devices or measure load and interactivity. Then the numbers stop being negotiable.

Astro’s stance is refreshingly blunt: if a page is content, ship content. Only deliver JavaScript where it’s truly necessary.

Zero-JS-by-default: the default you should want

Astro’s most practical feature is also its most philosophical: it sends almost no JavaScript by default. The browser receives HTML for the page shell—the parts that matter for reading—rendered immediately.

That doesn’t mean Astro has a “no JavaScript” rule. It means Astro treats JavaScript as an opt-in tool. If a component needs interactivity (a search box, a comment form, a toggle, a video player), Astro will bundle and hydrate that component. If it doesn’t, Astro doesn’t.

Here’s what that looks like in a blog context:

The blog post page loads as plain HTML: headings, paragraphs, images, code blocks, table of contents links.
A “like” button hydrates only that button when needed.
A comment widget loads its React component only when the user reaches it.
If the user never scrolls to comments, the comment JS never runs.

This “pay for what you touch” approach aligns perfectly with how content is actually consumed. Most readers skim. They rarely engage with every interactive widget on the page. Your site shouldn’t punish them for that.

Islands architecture: hydrate where interactivity lives, not everywhere

Astro’s islands architecture is the mechanism that makes the philosophy work. Think of your page as a calm ocean of HTML, with small islands of interactivity rising where needed.

A component-based mental model helps:

Static regions: server-rendered HTML that the browser can display immediately.
Interactive islands: UI components that require client-side behavior.
Lazy loading hooks: hydration can be triggered based on visibility or user actions.

The comment widget example is the clearest. On a content-heavy article page:

The comments section is typically below the fold.
Your majority of readers never reach it in the first few seconds.
Hydrating a full comment app early is a waste.

With islands, you can treat the comment section as an isolated island. Configure it to hydrate on visibility (or on scroll). The result is not just “faster,” but more honest: you only run what the user is about to use.

A framework-agnostic workflow: React, Svelte, Vue, Solid in one project

One reason teams cling to Next.js or Gatsby is ecosystem gravity. But you shouldn’t have to rewrite your mental model or your component library to get good performance.

Astro supports multiple UI component frameworks in the same project: React, Svelte, Vue, Solid—and you can mix and match based on what you already know.

That enables a pragmatic strategy:

Use Astro for page composition, routing, content rendering, and static output.
Use React for an interactive “rich editor” or a complex widget.
Use Svelte for lightweight UI bits where it’s a good fit.
Use Solid for ultra-responsive components that benefit from its reactivity model.

You’re not forced into a single framework’s worldview across your entire site. Instead, you choose the right tool for each island.

In practice, this matters when you’re modernizing an existing content platform. You can migrate page by page and component by component instead of betting the farm on a full rewrite.

“Lighthouse scores” are nice—what you should measure instead

It’s tempting to celebrate Lighthouse improvements. And yes, when you remove unnecessary JavaScript, your metrics often get dramatically better.

But the more important question is: what do the metrics represent in real life?

For content-heavy sites, the outcomes that matter are usually:

Immediate readability: the page should render quickly enough that users start reading before they notice anything.
Lower main-thread work: fewer scripts competing for time with rendering and user input.
Faster interaction readiness: when a user hits an interactive element (like a subscribe form), it should work without lag.

Here’s a practical way to think about it when building with Astro:

Default every page to server-rendered HTML.
Audit interactive components: ask, “Does this need to be hydrated immediately on load?”
Hydrate on demand: visibility, user interaction, or even route-level conditions.
Keep islands small: don’t wrap an entire page in a single hydrated component just because it’s convenient.

If you’re coming from React-only or Next.js defaults, the mental shift is: “interactivity is localized,” not “the app boots everywhere.”

Astro vs Next.js vs Gatsby: not a winner-for-everyone, but a best-fit for content

Comparing Astro directly to Next.js or Gatsby is fair, but the framing matters. Next.js is a powerful general-purpose framework. Gatsby is optimized for certain build-time patterns. Astro is optimized for a specific reality: most content sites don’t need a full client app.

If your site is largely pages, articles, and documents—where most users want to read—Astro is the most natural fit because it treats interactivity as an exception, not the foundation.

Next.js becomes attractive when you’re building a product-like UI with heavy, always-on interactivity. Gatsby can be great when your build pipeline and data layer match its strengths. Astro wins when you want:

static-friendly output,
strong performance by default,
and framework flexibility without framework sprawl.

For teams juggling content and interactivity, Astro feels like the first serious attempt to stop over-hydrating the web.

Build it the smart way: a checklist for content-heavy Astro projects

If you’re adopting Astro, don’t just “switch frameworks.” Adopt the performance discipline Astro encourages. Here’s a practical checklist I’d actually use on a real project:

Start with server-rendered pages: let Astro handle layout, metadata, and content rendering.
Ship components, not apps: make interactive widgets small and self-contained.
Hydrate when the user is likely to care: visibility-based hydration for widgets below the fold is a strong default.
Avoid “just because” interactivity: if a control isn’t essential, render it as HTML first.
Use multiple frameworks only where it helps: mixed stacks can be powerful, but complexity is real—keep it intentional.
Measure the right moments: test load, rendering, and interaction with real devices and throttled networks, not just fast desktops.

A concrete example strategy: imagine a blog with a newsletter signup, a reading progress bar, and a comment system.

Reading progress bar: hydrate it as the user scrolls (or early if you consider it essential).
Newsletter signup: hydrate only the form when it appears near the bottom or after a time delay.
Comments: hydrate when the comments section becomes visible.
Everything else: pure HTML.

That’s islands architecture in the wild: small islands, fewer bytes, better user experience.

Conclusion: Astro makes performance the default, not the exception

Astro doesn’t ask you to choose between “modern developer experience” and “fast content.” It gives you a framework where the sane defaults are fast, and where interactivity is treated as an explicit, localized responsibility.

If you build content-heavy websites and you’re tired of shipping unnecessary JavaScript everywhere, Astro is the kind of tooling that makes the right outcome feel like the easiest one to implement. The future of content isn’t more client apps—it’s less code, better defaults, and islands that show up only when users need them.

Technical Debt Is a Feature, Not a Bug

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 17 Nov 2022 00:00:00 +0000

Every engineering team wants “clean code.” The irony is that the cleanest codebase is usually the one that never shipped. In the real world, technical debt isn’t an accident you must eliminate—it’s an economic tool you’re always using. The problem isn’t that you accrue debt; the problem is that you accrue it unconsciously, fail to price it, and then act surprised when the interest compounds faster than your roadmap.

Debt is how you ship—on purpose

Let’s make the metaphor explicit: technical debt works like financial debt. You trade something valuable today—time, focus, or architectural purity—for the ability to move faster now. That trade can be rational, even strategically necessary.

Think about a common scenario: you’re building a new onboarding flow. You could spend two months perfecting a domain model, writing a full set of integration tests, and setting up a robust abstraction layer. Or you could ship a minimal version in four weeks, learn from real user behavior, and iterate. That faster launch is a win. It becomes “debt” only if you never plan to pay it back—or if you let the shortcuts quietly metastasize.

The best teams treat debt as a consciously chosen option, not an embarrassing byproduct. They ask questions like:

What are we gaining by taking this shortcut?
What will this cost us later?
Can we isolate the impact so it doesn’t leak across the system?
When, exactly, will we repay?

If you’re answering those questions, you’re managing debt. If you’re pretending it doesn’t exist, you’re managing hope.

The real bug: untracked debt and unpriced interest

Most organizations don’t have a “technical debt problem.” They have a visibility problem. Debt compounds invisibly when no one tracks:

Where the debt lives (which services, modules, or components)
What kind of debt it is (tests missing, architecture skew, performance shortcuts, process issues)
How it affects delivery (slower deployments, harder onboarding, frequent regressions)
When it will block new work

The interest rate isn’t a number on a dashboard—it’s your lived experience. It shows up as “small” annoyances that become permanent:

Every change takes longer because the system is fragile.
Rollbacks become scary because behavior is unpredictable.
New hires can’t contribute quickly because everything is entangled.
Feature work gets rerouted into “fixing old stuff” with no planned budget.

Here’s the key: teams rarely notice interest rising until it’s already painful. The metaphor helps because financial debt has a predictable truth—if you only pay minimums, you may never escape. In software, minimum payments look like endless bugfixes without addressing root causes, or refactoring “whenever we have time,” which is a schedule that never arrives.

A practical way to “credit-card” your debt

If technical debt is credit card debt, then you need a ledger. Not bureaucracy—operational clarity.

1) Create a Debt Backlog (with real fields)

You don’t need a fancy system. You need consistent entries. For each debt item, capture:

Context: service/module/repo
Description: what shortcut was taken
Impact: what it slows or breaks (e.g., release frequency, test coverage, deployment time)
Estimated repayment cost: engineering effort to make it safer
Priority: what’s blocking features or increasing risk
Paydown plan: the smallest complete step that reduces interest

Example entry:

“We skipped integration tests for payment webhook retries in billing-service. Impact: every change requires manual verification; regressions appear in production.”
Repayment: add contract tests + simulation harness; estimated: 2–3 days.

2) Estimate repayment like you mean it

“Someday” is not an estimate. Use ranges if you must, but provide enough structure that planning becomes real. Even a rough “1–2 days to reduce risk substantially” is better than a vague “we should refactor.”

If you’re worried about accuracy, treat it like portfolio management: you’re not predicting the future perfectly; you’re making it possible to allocate resources intelligently.

3) Tie debt to work, not vibes

A mature approach links debt items to feature initiatives:

When a team touches a brittle subsystem, require a debt check.
When a feature is accepted, ensure the debt ledger reflects any new shortcuts.
When a release is scheduled, include a debt repayment lane.

That last part matters: you’re not just capturing debt—you’re booking repayment capacity.

Interest shows up in delivery metrics (so manage those too)

Financial debt is measured by payments and interest. Software debt is measured by delivery drag and risk. You can’t manage what you can’t observe, so use lightweight signals that reflect real cost.

Look for patterns like:

Change failure rate: when tests are missing or architecture is fragile, failures cluster around modifications.
Lead time creep: small changes taking longer over time.
Deployment friction: longer pipelines, more manual steps, more rollbacks.
Onboarding latency: how long it takes new engineers to safely make changes.
Rework loops: the same area repeatedly generating bugs or “surprise regressions.”

You don’t need a perfect metric. What you need is a consistent set of signals and the discipline to interpret them as interest.

For example, if releases to a specific service increasingly require manual hotfixes, that’s a sign your “interest rate” is climbing. If you keep adding features to the same area while refusing to pay down the ledger, you’re essentially financing growth with credit—until the day you can’t.

Build repayment into your roadmap: sprints that actually pay down

Debt repayment fails when it competes with everything else and always loses. The solution is scheduling. Not as a moral commitment, but as a resource allocation policy.

A simple repayment cadence

Many teams adopt a recurring pattern like:

Every sprint: allocate a fixed percentage (e.g., 15–25%) to debt repayment.
Every quarter: run a dedicated “paydown” initiative when a set of debt items becomes blocking.

The exact numbers don’t matter as much as the principle: repayment must be protected time, not leftover time.

Define “paid down” clearly

Debt items should have a “definition of done” that reduces interest, not just cleans up code aesthetics. Example definitions:

“We added automated tests that cover the risky behavior.”
“We reduced deployment steps from N to 1 by improving the pipeline.”
“We separated the module boundary so future changes don’t require touching unrelated components.”
“We introduced a stable interface so downstream services stop breaking.”

Pay the highest-interest debt first

Just like credit card strategy, don’t treat all debt equally. If one shortcut is causing repeated production incidents or blocking feature delivery, that’s high-interest. Pay it first, even if it’s not the most glamorous refactor.

Conversely, low-interest cleanup can wait. Not because it’s unimportant—because the portfolio matters.

When you ignore debt, you hit “bankruptcy”

The word “bankruptcy” sounds dramatic, but software has its own versions:

You stop shipping features because every release becomes a fire drill.
Teams lose trust in the system, so changes require excessive ceremony.
Bugs become so tightly coupled that fixing one thing breaks another.
Engineers spend more time compensating for uncertainty than delivering value.

Notice what’s common: the organization becomes unable to convert engineering effort into reliable outcomes. That’s the software equivalent of insolvency.

And it’s often preventable. Bankruptcy doesn’t usually arrive from one catastrophic decision. It arrives from a pattern: no ledger, no repayment budget, and a steady stream of new “minimum payments” that keep you afloat just long enough to fall again.

Conclusion: Manage debt like engineering, not like embarrassment

Technical debt is not a moral failure. It’s a predictable consequence of shipping under constraints—and a tool you can use well. The difference between sustainable engineering and chronic pain is management: track your shortcuts, estimate the cost to repay, assign repayment time, and monitor the interest rate through delivery friction and risk.

Treat your codebase like a credit portfolio. Pay down high-interest debt before it becomes unpayable. Keep shipping. Stay solvent.

Why Senior Engineers Should Write More Documentation

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 08 Nov 2022 00:00:00 +0000

Senior engineers don’t get promoted because they can compress ideas into clever code—they get promoted because other people can reliably build on those ideas. Documentation is how that reliability ships. The irony is that many experienced engineers treat writing as overhead, even though it’s the highest-leverage work they can do.

The real reason teams “need” documentation

Teams don’t fall apart because junior engineers can’t read code. They fall apart because decisions evaporate.

Code is executable, but it’s not communicative in the way humans need. It answers what the system does; it rarely answers why the system does it, when it should behave differently, or what trade-off was accepted to get there. That’s where documentation wins: it preserves context, aligns expectations, and turns tribal knowledge into something transferable.

If you’ve ever watched a senior engineer spend an hour explaining a system to a teammate (or to a future you), you’ve already seen what’s missing. Documentation isn’t a nice-to-have; it’s a mechanism for reducing repeated thinking and preventing expensive misunderstandings.

Clever code is cheap; institutional memory is scarce

Experienced developers can always write more code. What’s hard is carrying forward the reasoning behind the code when people rotate, teams reorganize, or priorities change. Documentation is the closest thing engineering has to institutional memory.

Consider a feature that “works on staging but not in production.” Sometimes the bug is real. Often it’s a gap in understanding: different configuration defaults, a missing dependency, an environment-specific constraint, or a deliberate behavior from an earlier incident. When the explanation lives only in someone’s head, the team is condemned to rediscover it the next time it breaks—usually during peak traffic, usually at the worst possible moment.

Institutional memory also changes the shape of engineering work. When the why is written down, you can review decisions faster, onboard new engineers faster, and debug incidents without asking the same question in three different Slack threads.

ADRs: prevent three meetings with one good page

The most practical documentation senior engineers can write is an Architecture Decision Record (ADR). Not because ADRs are fashionable—but because they directly attack the most common coordination cost in software: misalignment.

A good ADR captures:

Decision: what you chose.
Status: accepted, rejected, superseded.
Context: what problem you were solving.
Alternatives considered: at least the major ones.
Trade-offs: what you intentionally gave up.
Consequences: how this affects future changes, operations, and risk.

Here’s a concrete example. Imagine you decide to introduce a message queue for an order processing pipeline. Without an ADR, the team will eventually ask:

Why not do it synchronously?
Why this queue tech?
What does it imply for retries and idempotency?

Those questions often turn into meetings because the “why” is trapped. With an ADR, they become reading exercises. The next time someone proposes switching away from the queue, they can refer to the trade-offs you already documented instead of re-litigating the same debate.

Opinionated standard: if a decision affects correctness, reliability, security, or operational complexity, write it down. If it doesn’t—maybe it doesn’t deserve to be a decision at all.

Runbooks: the difference between calm and chaos at 2 AM

Code runs in production with or without documentation. But your on-call rotation lives and dies by how quickly humans can understand what’s happening.

A runbook isn’t a screenshot collection or a pile of “try these steps” commands. It’s an explanation of system behavior under stress, plus a path to safe resolution.

A useful runbook answers questions like:

What does “normal” look like? (Key metrics, expected patterns, alert triggers.)
What changes during peak hours? (Caching behavior, queue depth, throttling, autoscaling delays.)
How do dependencies behave? (Database latency, third-party API limits, network issues.)
Common failure modes and what symptoms they produce.
Triage steps in order: verify, isolate, mitigate, then resolve.
Rollback and mitigation guidance: what to do if things worsen.
Ownership and escalation: who to page next and when.

Take the scenario from real life: the system behaves oddly during peak hours. Maybe timeouts spike because of downstream throttling, or a cache TTL causes stampedes right at the top of the hour. If that behavior is “mystifying,” it becomes an incident generator. If it’s documented—clearly, with reasoning—on-call becomes surgical instead of improvised.

And yes, runbooks should be written by engineers who understand the system. Not just by whoever happens to have the least urgent backlog. If you wrote the subsystem, you’re uniquely qualified to explain what’s happening and why.

Documentation reduces the real cost of ownership

The argument against documentation is usually framed like this: “We’re busy. The code is the source of truth.” That’s true, but incomplete. Documentation doesn’t replace code; it complements it by expressing the parts of software that code doesn’t naturally tell.

Here’s the kicker: documentation is not extra work—it’s a form of engineering leverage.

Without documentation, senior engineers pay a “re-explanation tax” repeatedly:

during onboarding,
during code reviews,
during incident retrospectives,
during escalations,
during dependency upgrades,
during migrations and refactors.

With documentation, you convert that tax into once-and-done writing. The system still changes, but your knowledge updates with it. A small doc that stays current saves hours across many future cycles. A stale doc is worse than no doc; the answer isn’t perfectionism—it’s ownership discipline (more on that below).

How to write docs senior engineers actually maintain

Documentation fails when it becomes a dumping ground. Good documentation isn’t long—it’s usable. A useful doc has a clear audience and a clear job.

Adopt a simple writing contract

Every doc should answer:

Who is this for? (On-call engineers, future maintainers, product engineers, security reviewers.)
What decision or behavior does it cover?
What should the reader do with it?

Use structured formats

Some formats are reliably effective:

ADRs for decisions.
Runbooks for operational response.
“Design notes” for complex subsystems.
Readme + docs pages for entry points and mental models.
Commented examples when the code behavior is non-obvious.

Keep docs close to the code

A runbook in a random wiki link is effectively invisible at 2 AM. Put ADRs next to the systems they affect. Put runbooks in the repository that owns the service. Use links, but don’t bury essentials behind link stacks.

Treat documentation as code, not art

Version it. Review it. Refactor it. If you change a subsystem, update the documentation as part of the same work item. This is how you prevent documentation drift—the silent killer that turns good intentions into misleading guides.

A practical workflow: add a “Docs updated?” checkbox in your PR template for changes that affect behavior, interfaces, or operational characteristics. It’s not bureaucracy; it’s a reminder that knowledge must travel with code.

The payoff: fewer escalations, faster change, and better engineers

When senior engineers write more documentation, the benefits are immediate and visible.

Incidents improve because triage is faster and less dependent on a single person’s memory.
Reviews improve because reviewers can evaluate trade-offs, not just diffs.
Onboarding improves because new engineers can form accurate mental models without interrupting experts constantly.
Teams become more resilient to turnover because knowledge survives beyond the original author.

Most importantly, documentation trains your organization to think like engineers. It forces clarity: what problem are we solving, what constraints exist, what risks did we accept, and what behavior should be expected under different conditions? That clarity improves both systems and people.

And yes, it can feel like you’re writing “less code.” But the outcome is more successful code: code that others can safely change, operate, and trust.

Conclusion: document like your future self is your teammate

Senior engineers should write more documentation because it’s the highest-leverage activity in software. It prevents recurring debates, reduces operational chaos, and preserves the reasoning that code alone can’t carry. Write the ADRs. Write the runbooks. Keep them close to the systems they describe. Then watch your team become faster, calmer, and more capable—especially when the next incident hits and your future self is reading at 2 AM.

SolidJS Deserves Your Attention

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 05 Nov 2022 00:00:00 +0000

React taught the modern web how to think in components and re-render cycles. SolidJS—quietly, confidently—makes the case that your mental model doesn’t need to be “render, diff, patch” to get interactive UI performance. It swaps the usual framework tax for fine-grained reactivity: update only what changes, directly in the DOM, without virtual DOM diffing or rerendering components.

If you like hooks, you’ll feel at home. If you care about performance, SolidJS is the rare framework that treats it as a first-class design constraint rather than an afterthought.

The React Mental Model (and Why Solid Questions It)

React’s model is simple to explain: state changes, components re-render, React reconciles what should appear. That model is powerful, but it has a built-in assumption: the UI can be derived from state by repeatedly “recomputing” component trees.

SolidJS agrees with the goal—a declarative UI—but challenges the mechanism. Instead of running components again and again, Solid compiles your reactive code into a graph of dependencies. When a signal changes, Solid updates only the DOM nodes that depend on it. No virtual DOM. No diffing. No rerendering to “figure it out” again.

Here’s the practical difference:

In React, a state update triggers a render pass for the affected component(s). Even if reconciliation avoids heavy work, the render phase still happens.
In Solid, reactive primitives wire dependencies once. Updates propagate through that graph to precisely targeted DOM updates.

This isn’t theoretical. It changes how predictable performance feels under real interaction: typing in an input, toggling classes, streaming data into a list, or driving high-frequency UI like charts and editors.

Fine-Grained Reactivity: Signals That Hit the DOM Directly

SolidJS uses signals (the core primitive) to represent reactive state. When you read a signal during computation, Solid records the dependency. When you write to that signal later, Solid automatically re-runs only the computations that actually depend on it—and updates the specific DOM nodes bound to those computations.

A simple example makes the point:

import { createSignal } from "solid-js";

function Counter() {
 const [count, setCount] = createSignal(0);

 return (
 <div>
 <button onClick={() => setCount(c => c + 1)}>+1</button>
 <span>{count()}</span>
 </div>
 );
}

Notice what’s not happening. The component function doesn’t need to re-run like it does in React’s render model. Instead, count() is a reactive read. Solid connects that read to the <span> text node. When setCount fires, Solid updates the span and leaves everything else alone.

Now scale the idea:

If you have ten reactive fields on a form, changing one field updates only the DOM parts that depend on that field.
If a complex child component reads a signal, it updates only those computations that read that signal—not the entire component subtree via rerender.

Solid’s reactivity is fine-grained because dependencies are tracked at the level of individual reads and computations, not at the component boundary.

JSX Without the Virtual DOM Overhead

Solid uses JSX, so your UI still looks like React. But JSX in Solid is not synonymous with “virtual DOM runtime work.” Solid’s compilation strategy produces efficient DOM bindings.

In practice, you get a component authoring style that looks familiar while avoiding the reconciler loop that virtual DOM implementations rely on. That means fewer moving parts at runtime and less wasted work when state updates frequently.

Think about this workflow:

In React, you might rely on memoization (React.memo, useMemo, useCallback) to prevent unnecessary rerenders.
In Solid, the dependency graph already ensures that only relevant computations update.

This doesn’t mean performance “just happens” in every case. If you create overly broad reactive dependencies, you can still cause more updates than needed. But Solid makes the common case—updating a single piece of UI—naturally efficient.

Hooks-Like Ergonomics, With a Different Execution Model

Solid’s API is intentionally approachable. You can write code that feels like React hooks:

createSignal for state
createEffect for side effects
createMemo for derived values
onCleanup for teardown

But the key is: the semantics are built around reactive execution, not component rerender cycles.

A derived computation is a good example:

import { createSignal, createMemo } from "solid-js";

function Product() {
 const [price, setPrice] = createSignal(10);
 const [qty, setQty] = createSignal(2);

 const total = createMemo(() => price() * qty());

 return (
 <div>
 <input type="number" value={price()} onInput={(e) => setPrice(e.currentTarget.valueAsNumber)} />
 <input type="number" value={qty()} onInput={(e) => setQty(e.currentTarget.valueAsNumber)} />
 <p>Total: {total()}</p>
 </div>
 );
}

total() updates only when price() or qty() changes, and only the parts depending on total() re-evaluate. You’re not re-rendering the entire component tree to rediscover the relationship.

This is where Solid feels like “React if it was designed today”: the API lowers the cognitive barrier, while the runtime behavior targets the performance bottleneck instead of papering over it with memoization.

Practical Guidance: How to Think in Signals, Not Rerenders

Solid rewards a particular way of structuring UI code. If you come from React, you can accidentally write “React-shaped” Solid code that creates unnecessary reactive reads. The good news: the fixes are straightforward.

1) Keep reactive reads close to the DOM that needs them

If a computation reads a signal, that signal becomes a dependency for that computation. If you read it in a wide scope, you’ll broaden what updates. Prefer reading in the smallest scope that actually needs the value.

2) Use derived state explicitly with `createMemo`

If you compute something from signals, treat it as a derived reactive value. That keeps dependency tracking honest and prevents accidental recomputation.

3) Be intentional about effects

createEffect runs when its dependencies change. If an effect reads multiple signals, it will rerun whenever any of them changes. That’s correct behavior—just make sure the effect’s dependency footprint is what you mean.

4) Model lists carefully

List rendering is where frameworks either shine or struggle. Solid’s fine-grained model is a strong fit for updating individual items. When you render an array, ensure you use Solid’s list primitives (like For) and structure your data flow so updates don’t force wholesale recalculation.

A common pattern: keep item state granular. If each row depends on its own signals, changes to one row won’t ripple through the entire list.

When Solid Is the Better Choice

Solid is not a universal replacement for React. But it’s an excellent fit when you care about UI responsiveness and predictable performance—especially under frequent updates or complex interactive surfaces.

Consider teams building:

dashboards with fast-moving filters and live values
editors with keystroke-level interactivity
animation-heavy interfaces
data-rich apps where “small changes” happen constantly

Solid’s model aligns with those realities. You don’t want rerenders to be the mechanism that “figures out” what changed. You want changes to propagate directly to the DOM nodes that actually care.

And because Solid is JSX-based with hooks-like APIs, adoption is less intimidating than it sounds. Your biggest adjustment is internal: stop expecting component rerenders to be the engine of UI updates.

Conclusion: A Framework That Respects Your Time

SolidJS deserves attention because it offers the rare combination of familiar ergonomics and a radically more efficient update model. It replaces virtual DOM diffing and component rerender cycles with fine-grained reactivity that updates only what changed—often with less code in the places where React traditionally leans on memoization to stay fast.

If you’ve ever thought, “This should be simpler, and it shouldn’t cost this much,” Solid is the kind of framework you reach for. React may still be your default, but Solid is a compelling answer to the question behind React’s greatest abstraction: what if the mental model was wrong all along?

Functional Programming Concepts Every OOP Developer Should Steal

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 25 Oct 2022 00:00:00 +0000

If you’ve ever shipped a bug caused by “somehow that state changed,” congratulations—you’ve already met the enemy. The good news: you don’t need to abandon OOP, learn Haskell, or rewrite your entire codebase to get most of the benefits of functional programming. You just need to steal a few ideas: immutability, pure functions, and composition.

These aren’t academic curiosities. They’re pragmatic techniques that make code easier to reason about, simpler to test, and harder to break.

1) Stop treating state like it can’t bite you

OOP is built around state: objects hold data, methods change it, and the system evolves. That’s not wrong—until it becomes unmanageable. The functional mindset challenges the default assumption that mutable state is the natural way to build software.

What immutability actually buys you

When your data is immutable:

You eliminate whole categories of “action at a distance” bugs (where a change in one place unexpectedly affects another).
You can trust that a function’s inputs won’t be quietly mutated under your feet.
Debugging gets less mystical. If something changes, you’ll see where a new value was created.

Practical example: safer updates

Imagine a typical OOP-style “update” flow:

A Cart object has a List<Item> field.
An addItem() method mutates that list.

Now compare a functional-ish approach:

Cart is treated as immutable.
addItem() returns a new Cart with the additional item.

In Java-like pseudocode:

Mutable style:
- cart.addItem(item) (side effect)
Immutable style:
- cart = cart.withAddedItem(item) (new value)

You didn’t remove the need for updates—you just made updates explicit and traceable. Most teams discover that this alone reduces bug volume dramatically, not because developers become smarter, but because the code becomes less ambiguous.

How to start without rewriting everything

You don’t need persistent data structures tomorrow. Start small:

Prefer final (or equivalent) fields where feasible.
Treat “DTOs” and “event objects” as immutable.
In critical paths, return new values instead of mutating shared objects.

If you’re using TypeScript, you can also lean on readonly types. If you’re in C#, favor records for value-like models. The goal is consistency: when objects represent facts, keep them stable.

2) Make your core logic pure (and your tests will thank you)

Immutability prevents accidental chaos, but pure functions prevent intentional chaos. A pure function does one thing: it returns a result based solely on its inputs, without side effects.

No network calls. No database writes. No hidden time bombs. Just input → output.

Why pure functions are the ultimate testability upgrade

Testing pure functions is almost comically easy:

Given input X, you expect output Y.
There’s no need to set up mocks for time, random numbers, or external services (unless those are inputs).

This doesn’t mean you can make your entire system pure. It means you should make the business logic pure where it matters.

Practical example: split logic from effects

Consider a payment flow:

You fetch exchange rates (effect)
You compute the final totals (logic)
You store the transaction (effect)

A functional-friendly structure splits these responsibilities:

Effectful boundary: “Get rate,” “read cart,” “write ledger.”
Pure core: “Compute totals,” “validate constraints,” “apply discounts.”

Suppose you currently have a method like:

calculateTotal(cart) that calls a rate service internally.

That’s hard to test and easy to break. Instead:

calculateTotal(cart, rate) becomes pure.

Now you can test the computation with plain data:

Provide cart and rate
Assert the totals

The service call still exists, but it moves to the edges of your application where side effects belong.

What about randomness and time?

If you use now() or random(), you’re quietly importing hidden dependencies. The easiest fix is to pass them in:

computeDiscount(cart, currentTime)
generateOrderId(seed)

This keeps “environment” out of your core logic. It’s also a clean design signal: your logic depends on explicit inputs, not ambient conditions.

3) Compose transformations instead of stacking control flow

OOP code often leans on loops, conditionals, and stateful accumulation:

“iterate through items”
“if this, then mutate”
“track totals”
“handle edge cases inline”

Functional composition encourages a different style: define transformations and chain them. A pipeline is a story with steps.

Map/filter/reduce as the “data movement” language

These three operators cover an astonishing amount of everyday work:

map: transform each element
filter: keep only elements that match
reduce: combine elements into one result

Example: generating order lines from raw cart items.

Instead of:

A for-loop that mutates an array
Conditionals scattered inside the loop
Manual accumulation

You can express it as:

items.filter(isEligible)
.map(toOrderLine)
.reduce(sumTotal)

This reads like a specification. Also, it tends to make edge cases more obvious, because you isolate them in small, named functions.

Concrete advice: name your steps

Don’t just cram anonymous lambdas into a single statement. Make it legible:

const eligible = items.filter(isEligibleItem)
const lines = eligible.map(toOrderLine)
const total = lines.reduce(addLineTotal, 0)

Even in languages without first-class pipeline syntax, you can preserve the structure. The key is composition: each step should do one job.

When composition helps beyond lists

Composition isn’t limited to arrays. You can compose:

functions for validation
mappers from domain models to view models
parsers that normalize input
reducers that build aggregates

The bigger your codebase, the more you’ll appreciate code that can be assembled like Lego rather than rewritten like a monolith.

4) Keep your objects—just stop letting them control everything

Here’s the misconception to drop: functional programming doesn’t require abandoning OOP. You can absolutely keep classes, encapsulation, and polymorphism. The “steal” is about how you structure logic and how you manage data.

A hybrid pattern that works in the real world

A common, effective structure looks like this:

Domain objects: represent core concepts (often immutable).
Pure functions: implement business rules.
Effectful services: handle I/O (databases, HTTP, messaging).
Composition layer: orchestrates pure logic from effect boundaries.

Think of it as: objects own meaning, pure functions own reasoning, and services own consequences.

Concrete example: validation

Bad approach (typical OOP trap):

A User method performs validation and also hits external systems to check something.
The behavior becomes hard to test because it’s entangled with side effects.

Better:

A pure function validateUser(user) returns either errors or a validated result.
Effectful calls happen elsewhere if needed (e.g., uniqueness checks against a database).

This doesn’t weaken encapsulation; it makes responsibilities cleaner and testing cheaper.

Practical heuristic: “Methods that call the network aren’t domain logic”

If a method performs I/O, it belongs near the edges. If a method only transforms data, it belongs in the core. When you apply that heuristic consistently, the functional gains arrive without the ideological baggage.

5) You don’t need monads to get the benefits

You can hear the functional crowd and assume you must learn monads, higher-kinded types, or category theory to be “doing it right.” You don’t. Most practical functional improvements come from the basics:

avoid mutable shared state
write pure functions for business rules
compose transformations clearly

If you want a small “gateway drug” concept beyond the basics, start with something as simple as representing computations that may fail:

Use Result/Either-like types where available
Or use explicit error-return objects
Or, in mainstream languages, at least avoid exceptions for expected control flow

But even if you never touch monads, immutability + pure functions + composition already give you a large share of the real-world value.

Conclusion: steal the useful parts—and your code will get calmer

You don’t need to pick a side in a decades-old debate. The best modern code borrows ruthlessly: OOP for structure and abstraction, and functional ideas for predictability and clarity. Make data immutable where it represents facts. Write business logic as pure functions so tests become straightforward and bugs become rarer. Finally, express transformations as composition—so the “what” is obvious and the “how” stays tidy.

Steal those three concepts, and you’ll feel the difference quickly: fewer state-related incidents, faster iteration, and code that reads like it was designed—not merely written.

GitHub Actions Ate Jenkins and Nobody Mourned

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 13 Oct 2022 00:00:00 +0000

For years, CI/CD felt like a rite of passage: set up Jenkins, wrestle with plugins, babysit servers, and pretend the build pipeline was “just another application.” Then GitHub Actions arrived with a simple pitch—commit a workflow, and stop treating automation like a pet. The punchline isn’t that Jenkins stopped working. It’s that the reasons people used Jenkins became optional overnight.

The Jenkins Era: Great Tools, Heavy Maintenance

Jenkins didn’t earn its reputation by accident. It was flexible, battle-tested, and extensible in a way that made teams feel in control. If you needed a custom build step, a weird environment, or an opinionated deployment flow, you could usually duct-tape it into Jenkins and keep shipping.

But Jenkins has a cost structure that most developers quietly hate:

You own the platform. Patching Jenkins, upgrading Java, securing the controller, managing plugins, cleaning up agents—it’s not “set and forget.” It’s ongoing ops.
Plugins are a supply chain. Every plugin is another moving part. Some stay healthy; others accumulate warnings, break with upgrades, or become incompatible with the rest of your setup.
The pipeline becomes a second system to administer. Even when the Jenkinsfile is clean, someone still has to explain why builds fail “only sometimes,” why a node is stuck, or why an agent label doesn’t match.

The uncomfortable reality: Jenkins made CI/CD a job. It wasn’t just a workflow—it was an internal product you maintained. That’s a tax even mature teams resent, and a deal-breaker for smaller ones.

What Changed: CI/CD Became Source-Driven Again

GitHub Actions flipped the mental model. Instead of “run your own CI server,” it became “describe your automation in your repo.”

A workflow is just YAML living beside your code. That shift sounds small, but it changes everything:

Review is native. When you modify how you build or test, your PR shows exactly what changed. No separate change process. No “trust the pipeline maintainers.”
Version control becomes the system of record. Roll back a broken pipeline by reverting a commit. That’s the most underrated feature of the GitHub Actions approach.
Discovery is easier. You don’t have to remember plugin names or hunt down internal docs written by someone who left the company. You search the repository, and the workflow is right there.

Consider a typical improvement scenario. Teams often start with “we’ll automate builds” and end up with a pipeline that nobody touches because it’s fragile. With GitHub Actions, the barrier drops: developers can iterate without filing infrastructure tickets.

And yes—YAML can be intimidating. But “intimidating” is a one-time problem. “Nobody wants to babysit Jenkins” is a continuous one.

Marketplace Actions and Matrix Builds: The Death of DIY CI

A big reason Jenkins survived so long is that teams built everything themselves—or stitched together a plugin ecosystem. That approach worked, but it also encouraged bespoke solutions for common tasks: checking out code, setting up language runtimes, caching dependencies, building containers, publishing artifacts.

GitHub Actions made the default path dramatically easier by combining two ideas:

Reusable actions for common tasks
Matrix builds for systematic coverage (multiple versions, OSes, or configurations)

Instead of inventing your own “install dependencies” step or writing custom scripts to manage caching, you can use established actions and keep your workflow focused on the logic that’s unique to your application.

For example, testing a Node.js project across Node 18 and 20 doesn’t have to be a tangle of branches and cron jobs. A matrix turns it into something readable:

Define the versions once
Let the runner handle the repetition
Keep failures scoped to the specific environment

That’s the difference between CI/CD as a craft and CI/CD as a capability.

And it matters culturally: the more your pipeline resembles declarative intent, the more developers feel ownership instead of fear.

Self-Hosted Runners: Enterprise Requirements Without the Jenkins Burden

At some point, someone will say: “Sure, hosted runners are nice, but we need enterprise controls.” That’s fair. Some environments require access to private networks, internal artifact registries, compliance constraints, or custom tooling that can’t run on shared infrastructure.

The good news is that you don’t have to rebuild the Jenkins world to meet those needs.

GitHub Actions supports self-hosted runners, which let you keep your requirements while removing the “Jenkins maintenance job” from your daily life. In practical terms, you can:

Install runners inside your network boundary
Use labels to target where jobs can run
Keep the workflow definition in the repo (so the orchestration is still source-driven)
Scale runners as needed without managing a CI “controller” application

This is where the comparison gets brutal. With Jenkins, “self-hosted” typically means you’re also hosting the orchestration layer—maintaining controllers, plugin compatibility, job configuration, and operational drift. With GitHub Actions, you can host only what must be hosted: the execution environment.

You end up with enterprise capability without turning your CI/CD platform into a permanent internal engineering program.

The Real Question: Is Anyone Happy Running Jenkins?

Here’s the uncomfortable editorial stance: if your team still runs Jenkins, ask yourself whether Jenkins is solving a problem you genuinely have—not whether you can keep it running.

A healthy CI/CD setup has one key property: it feels boring. Builds run, tests execute, artifacts publish, deployments follow policy. When something breaks, the failure is actionable.

Jenkins often creates the opposite experience:

Builds fail because of infrastructure conditions, not code changes.
Pipeline behavior is hard to reason about because it’s spread across plugins, scripts, and server state.
Improvements require knowledge that only a few people have.

If the only people who can safely modify the pipeline are “the Jenkins team,” then Jenkins has already achieved the worst possible outcome: CI/CD has become a specialty skill. That defeats the whole purpose of automation.

And nobody wants to maintain a tool that makes everyday development feel harder. If your CI/CD pipeline requires a dedicated team to keep it alive, your platform isn’t supporting developers—it’s consuming them.

Migration doesn’t need to be dramatic. Start by moving one workflow: say, “run unit tests on pull requests.” Port the logic, keep the build steps, and compare runtime and developer experience. Over time, you’ll find that replacing orchestration is less work than you feared—and less risky than you expect, precisely because workflows are versioned alongside the code.

A Practical Path Off Jenkins (Without Big-Bang Rewrite)

Nobody should pretend migrations are effortless. But you can make the transition systematic and low drama. A good migration plan focuses on outcomes, not ideology.

Inventory your pipeline responsibilities
List what Jenkins does today: build, test, lint, package, publish artifacts, deploy environments, run scheduled jobs, manage credentials.
Pick a narrow first workflow
Choose something with clear inputs/outputs—like “compile + unit test” on every PR. Avoid the most custom deployment logic until you’ve established confidence.
Model stages as jobs and keep steps explicit
Treat your workflow like production code: readable naming, small steps, clear failure points. If you need scripts, check them into the repo.
Use caching and artifacts intentionally
Dependency caching and artifact passing are where pipeline speed and reliability improve. Do not reinvent caching mechanisms if a ready approach exists; do ensure caches are keyed sensibly.
Move secrets and permissions carefully
Jenkins credential management and GitHub Actions secrets are different. Plan the migration of tokens, registry credentials, and deployment keys. Least privilege matters.
Adopt self-hosted runners only when you must
Start on GitHub-hosted runners if possible. Bring in self-hosted runners when you hit real constraints (network access, internal tooling, compliance).

The goal isn’t to “win” a tool choice. The goal is to make CI/CD so maintainable that developers don’t notice it—except when it speeds them up.

Conclusion: CI/CD Shouldn’t Be a Separate Engineering Department

Jenkins was a landmark product, and it earned a decade of loyalty. But modern CI/CD doesn’t need a dedicated maintenance team. GitHub Actions made automation source-driven, composable, and easier to reason about—while self-hosted runners cover legitimate enterprise needs without reintroducing the Jenkins maintenance tax.

If your Jenkins setup requires constant babysitting, you don’t have CI/CD—you have a second system to operate. And if nobody’s happy about that, it’s time to stop pretending it’s normal.

Cloudflare Workers Are Underrated for Full Application Backends

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 08 Oct 2022 00:00:00 +0000

Most people still think of Cloudflare Workers as “serverless scripts for the edge.” That’s like calling a car a steering wheel. In practice, Workers has matured into a serious backend platform: request handling, global storage, durable coordination, and even a relational database—packaged around V8 isolates and deployed across Cloudflare’s footprint. If you’re building an app that doesn’t need a traditional server estate, Workers can be the cleanest, fastest, and most cost-effective way to run it.

From edge scripts to full backends (and why that matters)

The original appeal of Workers was simple: run code close to users, reduce latency, and avoid managing servers. But the “backend” part sneaks up on you once you stop treating Workers as a place to do small transformations and start building whole systems around it.

A modern Workers backend typically includes:

Request logic in Workers (routing, auth, rate limiting, rendering responses)
Global storage with KV (fast reads for configuration, feature flags, sessions-like keys where eventual consistency is acceptable)
Object storage with R2 (user uploads, generated artifacts, media, backups—without pulling data through a traditional cloud storage setup)
Relational data with D1 (SQLite semantics at the edge for transactional needs)
Stateful coordination with Durable Objects (when you need “one thing at a time” per entity: chat rooms, rate-limit counters, leaderboards, game sessions)
Async processing patterns (queue-style workflows, webhooks, background tasks—without spinning up anything)

The underrated part? This isn’t a patchwork of random services. It’s one platform designed to work together, with consistent deployment ergonomics and an execution model that encourages building smaller, composable services without losing coherence.

The engine: V8 isolates and why the runtime feels different

Workers run your code on V8 isolates. Practically, that affects performance and reliability in the way you’d expect from a properly sandboxed runtime: fast startup, tight memory usage, and predictable request handling.

What you feel as a developer is this: you can build backends that respond instantly to traffic spikes without the “warm instance” ritual. Instead of thinking in terms of fleets and autoscaling delays, you think in terms of stateless request handlers plus explicit state where needed (KV, D1, Durable Objects, R2).

A good pattern is to separate your code into:

Stateless HTTP layer (Workers): validate requests, read/update state, return responses
Stateful entities (Durable Objects): own the coordination and invariants
Storage-specific access (KV / D1 / R2): use the right tool for the access pattern

That separation keeps your logic crisp and prevents the common failure mode of “we’ll just store everything in KV,” followed by a debugging spiral when you discover consistency and query limitations.

KV and R2: global storage without the usual storage anxiety

Let’s talk about the two storage pillars that many teams overlook because they’re not branded as “databases.”

KV for global configuration and fast key lookups

KV shines when you want low-latency, global reads keyed by something simple: tenant:featureFlags, user:preferences:theme, promo:currentCampaign, and so on.

Example: feature flags per tenant

On the Workers request path:
- read kv.get("tenant:" + tenantId + ":flags")
- evaluate flags to choose routes or response behavior
On flag updates:
- write new values to KV
- accept that propagation can be non-instant, depending on your design

If your UX can tolerate slight delays between toggling a flag and seeing the effect, KV is perfect. If you need strict read-after-write guarantees for user-critical decisions, you’re better off using D1 or Durable Objects.

R2 for application objects, not just “files”

R2 is S3-compatible object storage. The killer feature for many teams is that you avoid the typical “egress tax” mental model that shows up when you use traditional cloud storage as an afterthought.

Examples where R2 fits naturally:

User uploads (profile images, documents)
Generated artifacts (PDF renders, thumbnails, exports)
Import/export pipelines (store incoming files, process them, then store results)
Backups and snapshots for non-database assets

A pragmatic workflow:

Client uploads to your backend endpoint.
Workers validates auth and content type.
Workers writes the object to R2.
Workers returns a reference URL or key.
Optional: a Durable Object or a D1-backed job table tracks processing status.

Even if you later add a frontend CDN, R2 integration stays conceptually simple: store objects, reference them by key, and let the edge deliver.

D1: SQLite at the edge for real backend logic

KV is fast, but it’s not transactional. R2 is great, but it’s not queryable like a database. That’s where D1 comes in: a SQLite-based database you can query from Workers.

Use D1 when you need:

Transactions (e.g., “create order + create line items + update inventory”)
Relational querying (filter, sort, join-like behavior where applicable)
Deterministic integrity (unique constraints and consistent updates)

Example: a minimal checkout state machine

Table: orders
Table: order_items
Table: payments

Workers handles the HTTP request, then uses D1 to:

create the order row
record item rows
update payment status on webhook callbacks

This avoids the most common “backend tax” teams pay: shuttling state between services and storage systems until everything becomes glue code. With D1, the transactional core can stay close to the edge.

Durable Objects: the missing piece for stateful backends

Stateless is great—until it isn’t. Many applications have moments where you need coordination, ordering, or per-entity state that can’t be approximated with “eventual consistency and good luck.”

Durable Objects are the solution. Think of them as entities that live near the edge, encapsulating state and handling messages in a controlled way.

Use Durable Objects for:

Chat rooms / group sessions
Rate limiting per user or per API key
Game session state
Idempotency keys (prevent duplicate processing)
Multi-step workflows that require ordering

Example: per-user rate limiting with Durable Objects

Workers receives a request.
It routes the request to a Durable Object instance keyed by userId.
The Durable Object increments a counter and enforces limits.
Workers returns allow/deny based on the object’s authoritative decision.

This is exactly the type of logic that teams traditionally implement with a centralized Redis cluster or a carefully tuned database approach. With Durable Objects, you can keep coordination near where requests arrive, while still making it deterministic.

The important mental shift: Workers is your edge runtime; Durable Objects are your stateful runtime. Put coordination where it belongs.

Practical architecture: building a full backend without a server fleet

If you want a concrete blueprint, here’s a pattern that holds up well:

1) HTTP API in Workers

Authentication + request validation
Routing to Durable Objects / D1 / KV / R2
Response shaping and error handling
Minimal business logic that requires no cross-request coordination

2) Durable Objects for “entities”

One Durable Object per conceptual entity type (e.g., UserSession, ChatRoom, ApiKeyLimiter)
Methods that process events/messages
Encapsulated invariants (ordering, dedupe, counters)

3) D1 for durable transactional state

Store durable records that your app must query and mutate reliably
Use D1 when you need constraints, joins, or consistent updates

4) KV for read-heavy configuration and flags

Store feature flags, static mappings, small config blobs
Design for eventual propagation where appropriate

5) R2 for everything binary

Store uploads and generated files
Keep the “source of truth” for objects in R2
Reference by object key and let the edge handle delivery

A sample endpoint design

POST /upload: validates user, writes to R2, stores metadata row in D1
POST /uploads/:id/process: triggers a Durable Object message to coordinate processing
GET /uploads/:id: reads metadata from D1 and returns signed/accessible links to R2 objects
GET /feature-flags: reads KV, applies logic in Workers

This keeps your system cohesive. You’re not forcing a single datastore to do everything. You’re matching the tool to the access pattern.

Conclusion: stop treating Workers like a utility—use it as your backend

Cloudflare Workers is underrated because it doesn’t look like a “backend stack” at first glance. But once you lean into V8 isolates for runtime, KV for global lookups, R2 for objects, D1 for transactional data, and Durable Objects for stateful coordination, the platform behaves like a full application backend—deployed at the edge where latency matters.

If your app can avoid a traditional server model, Workers can give you the performance benefits without the operational overhead. More importantly, it encourages better architecture: stateless request handling by default, explicit state when needed, and storage that matches how your app actually reads and writes. That’s not just cheaper. It’s cleaner.

Redis Is Not Just a Cache (And You're Underusing It)

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 01 Oct 2022 00:00:00 +0000

If your Redis experience is limited to SET and GET, you’re treating a Swiss Army knife like a single screwdriver. Redis has matured into a multi-model data structure server that can handle everything from rate limiting and leaderboards to pub/sub messaging and stream processing—often with simpler operational overhead than the alternatives.

The good news: you don’t need to rewrite your whole system to get value. You just need to start using the right Redis primitives for the job.

Redis as a multi-model data structure server

The fastest way to appreciate Redis is to stop thinking in terms of “cache” and start thinking in terms of “data structures with commands designed for specific workflows.”

Instead of storing one value per key, Redis gives you purpose-built tools:

Lists, sets, and sorted sets for different access patterns
Streams for event ingestion, retention, and consumer groups
Pub/sub for lightweight real-time messaging
Hashes for structured objects
Lua scripting for atomic, multi-step logic
Transactions and server-side primitives to coordinate distributed behavior

That means Redis can sit at the center of real application logic—not just performance tuning.

A practical mindset shift

Ask a better question: “What data structure does my problem resemble?”

Need ranking? Use sorted sets.
Need ordered events? Use streams.
Need real-time fan-out? Use pub/sub.
Need atomic updates across keys? Use Lua.

Pub/sub: real-time notifications without the overhead

Pub/sub is Redis’s simplest messaging model: publishers send messages to channels; subscribers receive them. It’s a great fit when you want quick, transient distribution and don’t need durable replay.

Example: live notifications

Suppose you have a web app where users get notifications when something changes:

When an event happens, publish to a channel like notify:user:123.
Subscribers listen and push to WebSocket connections.

PUBLISH notify:user:123 "Your report is ready"

In practice, pub/sub shines for:

Live UI updates
Server-to-server “nudge” messaging
Broadcasting lightweight state changes

The gotcha you should plan for

Pub/sub is not durable. If a subscriber is offline, it misses messages. That’s fine for “best effort” updates, but if you need reliability, you should pivot to Streams (more on that next).

Streams: a lightweight Kafka alternative

Redis Streams are designed for ordered event logs with consumer groups—meaning you can process events asynchronously, at scale, with less system complexity than a full Kafka deployment.

Example: background jobs from events

Imagine you receive events from an API (e.g., user actions) and need a worker to process them. With Streams:

Your API appends events to a stream.
Worker processes read from the stream using a consumer group.
You can track progress with consumer offsets.

Writing to a stream looks like:

XADD events:activity * userId 42 action "clicked_button"

Workers then read using XREADGROUP, claim pending messages when needed, and continue.

Why this beats “roll-your-own” queues

Many teams start by pushing jobs into lists or using ad-hoc keys. Streams are better because they are:

Ordered: event sequencing is preserved.
Retainable: you can keep messages for retries and reprocessing.
Operationally cohesive: offsets and consumer groups help you avoid inventing your own coordination logic.

If Kafka is overkill for your needs—or you want to avoid running a separate distributed log system—Streams are often the pragmatic answer.

When streams aren’t enough

If you need strict, enterprise-grade event log governance, heavy multi-datacenter replication, or deep Kafka ecosystem integrations, Kafka still has advantages. But for many product teams, Streams hit the sweet spot: durable enough, simple enough.

Sorted sets: ranking, deduplication, and time windows made easy

Sorted sets (ZSET) are Redis’s most underused “business logic” primitive. They store members with scores and keep them ordered. That single property unlocks a ton of features that are otherwise annoyingly complex.

Example: real-time leaderboards

A classic ranking system: you award points and need to show the top users.

ZINCRBY leaderboard:points 10 user:42

To get the top 10:

ZREVRANGE leaderboard:points 0 9

What makes this elegant is that the sorted set is always ready to answer ranking queries—no separate database sorting step required.

Example: expiring leaderboards and time windows

For “leaderboards for the last 24 hours,” you can store timestamps as scores and periodically prune old entries. A common pattern:

Add score = timestamp
Trim entries older than your window

ZREMRANGEBYSCORE leaderboard:last24h 0 (currentTime - 86400)

This approach can work surprisingly well for time-bounded metrics without needing a heavyweight analytics pipeline.

Lua scripting: atomic multi-step operations you can actually trust

When distributed systems go wrong, it’s often because multi-step operations aren’t atomic. Redis Lua scripting lets you execute multiple commands server-side as a single atomic operation.

If you’re doing anything like:

check then set
decrement with guards
update multiple keys consistently

…Lua is your tool of choice.

Example: atomic rate limiting-ish logic

Suppose you want to increment a counter only if it doesn’t exceed a threshold, and you want the read/update decision to be consistent.

Lua runs the logic entirely on the Redis server, so you don’t get race conditions between separate client requests.

A typical pattern is:

Key holds a counter (or hash field)
Lua reads current value
If under threshold, it increments and sets expiry if needed
Otherwise, it returns a denial

Even if you don’t copy an exact template, the key point is this: move the “decision” into Redis.

Practical advice

Lua scripts are power tools—use them deliberately:

Keep scripts small and focused.
Use EVALSHA with cached script hashes for performance.
Return simple values (0/1, remaining tokens, current score) so your application logic stays readable.

Lua turns Redis from a storage layer into a coordination layer.

Putting it together: design patterns that actually work in production

Once you stop treating Redis as a cache, you can build clean distributed patterns. Here are a few that consistently improve outcomes.

Pattern 1: Streams for ingestion, Sets/Sorted sets for state

Ingest events into a stream
Update ranking or dedup state using sorted sets
Use Lua to ensure multi-key consistency during updates

This gives you both durability (stream) and fast queryability (sorted sets).

Pattern 2: Pub/sub for real-time UX, Streams for reliability

Pub/sub for “instant” UI nudges (best effort)
Streams for everything that must not be lost (auditing, retries, workflows)

This hybrid approach keeps your system responsive without sacrificing correctness where it matters.

Pattern 3: Rate limiting with Redis data structures + server-side logic

Instead of scattering rate-limit logic across the app:

Store counters in Redis
Use Lua to enforce thresholds atomically
Set expirations to keep memory usage bounded

Your API becomes simpler, and your guarantees become stronger.

Conclusion: Redis isn’t smaller infrastructure—it’s smarter architecture

Redis is not “just a cache.” It’s a multi-model data structure platform with messaging (pub/sub, streams), ranking (sorted sets), and atomic computation (Lua). If your current usage is SET and GET, you’re leaving reliability, speed, and architectural clarity on the table.

Pick one feature you currently handle awkwardly—rate limiting, leaderboards, event processing, coordination—and implement it with the Redis primitive that matches the shape of the problem. You’ll be surprised how quickly your system becomes simpler and more robust.

Why I Switched from Jest to Vitest and Never Looked Back

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 20 Sep 2022 00:00:00 +0000

For years, I treated Jest as “the way things are done.” It was the default, the safe choice, the thing everyone knew how to configure. Then our codebase grew, our build times got better, and our test times… didn’t. At some point, I realized we weren’t just “waiting for tests”—we were building a second toolchain that fought our actual stack. Switching from Jest to Vitest wasn’t a theoretical upgrade. It was a quality-of-life change that made testing feel like part of development again.

The real problem with Jest: not capability—friction

Jest still works. That’s the trap: when a tool works, it becomes infrastructure, and infrastructure becomes inertia. But in practice, Jest’s pain points showed up in three places:

1) Slow feedback loops.
Watch mode is supposed to be the thing that keeps you moving. When startup is heavy and transforms are expensive, “run tests on change” turns into “wait, and then maybe get an answer.” That’s not a developer experience; it’s a tax.

2) ESM support that never quite felt native.
Modern JavaScript projects increasingly live in ESM land: import/export, ESM-only dependencies, package type: "module", and the general desire not to juggle module systems. Jest has improved over time, but the experience can still feel like you’re fighting the boundary between tools rather than building on top of them.

3) Configuration sprawl.
Jest’s configuration surface area can expand quickly—transform rules, environment choices, module name mapping, and all the little “just make it pass” settings. It starts small, then it becomes a second webpack-in-miniature. You end up maintaining testing logic that’s unrelated to your app’s actual build logic.

And once you’ve felt that friction long enough, you start to notice the irony: your production build is fast and modern, but your tests are stuck in the past.

What Vitest changes: it shares your Vite brain

Vitest isn’t just a different test runner. The key idea is brutally simple: Vitest uses Vite’s transform pipeline. That means the same ecosystem assumptions—how your code is parsed, how transforms happen, how your config is interpreted—carry directly into the test environment.

If you’re already using Vite, this is the difference between:

“We’ll test your code with our own interpretation rules.” (Jest-style)
“We’ll test your code using the same rules you use to build it.” (Vitest-style)

That shared pipeline matters. In real projects, the most annoying failures aren’t always logic bugs—they’re mismatches between how the app code is transformed for runtime and how it’s transformed for tests.

Vitest also embraces the reality that ESM is the default mood. If your project is ESM-first, you’re not trying to force Jest to pretend otherwise.

Fast feedback you can actually feel

The thing I didn’t expect—at least not emotionally—is how much faster watch mode makes you test more. When tests run quickly, they stop being a “CI ceremony” and become a habit.

Here’s a practical way to see the difference:

Start your dev server (Vite).
In another terminal, run Vitest watch mode.
Make a small change in a module and save.

With Vitest, the test runner starts quickly, reuses the Vite transform pipeline, and tends to keep the “save → results” loop tight. The impact isn’t just raw speed; it’s reduced interruption. You iterate in flow, not in pauses.

Even if your test suite is moderate, the compound effect is real: fewer seconds waiting per iteration adds up to hours saved over a sprint. More importantly, you stop deferring tests until “later,” because later doesn’t arrive.

Migration is simpler than you’re imagining

The other reason I switched—completely unglamorous, but important—is that Vitest intentionally offers a Jest-compatible API. That means your existing test code usually doesn’t need a rewrite, just a new home.

In most cases, you can move from Jest to Vitest without drama:

Keep your describe, it, test, expect
Keep your matchers and typical assertion flow
Keep the same mental model of how tests are structured

A quick example: a familiar test becomes Vitest

If your Jest test looks like this:

import { sum } from './sum';

describe('sum', () => {
 it('adds numbers', () => {
 expect(sum(2, 3)).toBe(5);
 });
});

That test can typically run in Vitest with minimal changes. The bigger shift is not rewriting test logic—it’s updating config and ensuring the test runner sees your files correctly.

The only part that usually needs attention: setup and environment

You may need to map over these categories:

Global setup files (e.g., test utilities, polyfills)
DOM vs node environment
Mocking strategy if you used Jest-specific helpers

But even then, you’re generally translating configuration, not refactoring your suite.

In my experience, the “hard parts” were less about Vitest and more about cleaning up what we’d let Jest-specific cruft accumulate over time.

Using your existing Vite config instead of reinventing it

One of my favorite parts of the switch is that Vitest plays nicely with your current Vite setup. If you already have path aliases, plugin transforms, or module resolution rules, you can keep them.

For example, if your Vite config includes aliases like:

@/components → src/components

your tests should ideally resolve those same aliases without additional Jest-specific moduleNameMapper gymnastics.

That’s not just convenience. It prevents a subtle but common failure mode: tests passing while the app fails (or vice versa) because one tool resolved imports differently.

If your app uses Vite plugins, Vitest can benefit from the same assumptions. The result: fewer “why does this work in dev but not in tests?” conversations.

A practical migration plan (that won’t derail your week)

Switching a test runner can sound intimidating, so here’s the approach I recommend—incremental, boring, and effective.

Step 1: Add Vitest alongside Jest

Don’t try to “big bang” the entire suite. Start by installing Vitest and creating a Vitest config that fits your existing project.

Step 2: Run a subset of tests

Pick a folder—say src/utils—and migrate those tests first. Confirm that:

imports resolve correctly
mocks behave as expected
your environment is correct (DOM vs Node)

Step 3: Port shared setup

If you have a Jest setup file (globals, custom matchers, test utilities), translate it to Vitest’s equivalent so your tests keep their expectations.

Step 4: Adjust only what breaks

When something fails, resist the urge to reconfigure everything at once. Fix the specific mismatch:

module resolution
test environment
mocking differences
any remaining transform edge cases

Step 5: Flip the default once the suite is stable

Once the majority of tests run cleanly under Vitest, update your package scripts and make Vitest the standard.

One more recommendation: keep CI behavior consistent. If Jest was running --runInBand (or similar), you’ll want to understand Vitest’s concurrency defaults and tune only if you have a real reason. Speed is a feature—don’t accidentally eliminate it.

The conclusion: testing should reinforce development, not compete with it

I didn’t switch from Jest to Vitest because Jest stopped being “good.” I switched because our workflow got better everywhere else—and testing lagged behind in a way that started to matter. Vitest feels like the test runner that finally understands the modern JavaScript toolchain: fast iteration, ESM-native sensibilities, and a configuration model that doesn’t ask you to maintain a second build system.

If you’re already using Vite for your build, keeping Jest around is mostly symbolic inertia. Vitest doesn’t just run tests—it plugs into the same engine that already knows how your project works. And once you experience watch mode that feels instant, it’s hard to go back to waiting for your tools instead of your code.

GraphQL at Scale: The Complexity You Don't See Coming

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 14 Sep 2022 00:00:00 +0000

GraphQL is sold as simplicity: a single endpoint, a typed schema, and clients that ask for exactly what they need. In production, though, GraphQL quietly bills you for everything your team used to “get for free” with REST—until the bill shows up as slow pages, exploding query counts, tangled schemas, and authorization logic that’s impossible to reason about. The demos look elegant. The operations are where the real work starts.

The N+1 Query Problem Hides Behind “Flexible Queries”

If you’re new to GraphQL, the first time you see nested fields resolve “as expected,” it feels like magic. Then traffic hits, and your database logs turn into a horror movie.

Here’s the typical failure mode: your resolver resolves a list, but each item triggers another query for nested fields. In GraphQL, that often means N+1 queries—even when your schema and resolvers look perfectly reasonable.

A concrete example

Imagine a schema like:

users returns a list of users
each User has projects
each Project has owner

A naive resolver chain might do:

Query DB for users (1 query)
For each user (N), query projects (N queries)
For each project (M), query owner (M queries)

That’s not “one request.” It’s potentially hundreds or thousands of DB operations for a single GraphQL request—especially if the client requests a deep selection set.

The practical fix: batching + caching (DataLoader, done correctly)

The standard mitigation is batching at the resolver layer. DataLoader (or an equivalent) groups loads by key per request and executes them in bulk. But the operational gotcha is: you must apply it consistently.

Practical advice:

Use one DataLoader instance per request (not global). Global caching can leak authorization context across users.
Ensure your batch functions respect tenant boundaries and permission checks. A batch that returns too much is worse than N+1—because it’s a security incident waiting to happen.
Watch for “partial batching.” If only some resolvers use DataLoader, you still pay most of the cost.

You’re not eliminating database work—you’re preventing it from ballooning with query shape. That’s the difference between “works on my machine” and “still works at 9am on Monday.”

Schema Sprawl: When “Typed” Turns into “Unmanageable”

GraphQL schemas look tidy in early builds. Then you add more teams, more features, more service ownership, and suddenly the schema is a living map of historical decisions. The result is schema sprawl: types proliferate, responsibilities blur, and changes become risky because everything is connected.

There are two common reasons this happens:

Schema becomes a product of convenience, not architecture. Teams reuse types across domains because it’s faster than modeling correctly.
Schema stitching or federation creates a distributed monolith—the schema is centralized, but ownership and semantics are spread across systems.

Distributed monolith, centralized contract

When you “compose” multiple services into a single GraphQL schema, you create a contract that spans teams. That’s good—until you realize that:

one service change can break queries in unrelated screens,
versioning becomes fuzzy because clients only see the schema,
performance issues are hard to trace because the request crosses boundaries.

Practical advice that actually helps:

Treat schema changes like API changes with explicit ownership. Every type should have a clear “steward.”
Define boundaries in the schema, not just in code. For example: group types by domain and avoid cross-domain reuse without a shared contract.
Build automated checks for schema evolution. At minimum: backwards-compatibility tests and “query replay” against production-like data.

If you let schema sprawl happen, it will eventually demand a cleanup project. The painful part? Clients don’t wait politely for refactors.

Authorization Nightmares: The Field-Level Problem You Must Solve

REST authorization often maps cleanly to endpoints: “user can’t access this resource.” GraphQL authorization is nastier because fields are requested selectively. A single query might ask for 20 fields from multiple domains—and each field might require a different permission model.

That means you end up implementing authorization at a granularity your team didn’t plan for.

The trap: permission logic scattered across resolvers

A common early approach is inline checks in each resolver:

User.email checks permission A
User.billingStatus checks permission B
Project.confidentialNotes checks permission C

This quickly becomes unmaintainable. Worse, it becomes inconsistent. One resolver forgets a check. Another handles it differently. A third does it “during fetching,” which means you might accidentally leak data through side effects or timing differences.

The right pattern: centralize authorization decisions

You want authorization to be:

consistent (same rules everywhere),
composable (works across nested selections),
auditable (you can explain why access was granted or denied).

Practical advice:

Implement a field-level authorization mechanism, either through directives, a policy layer, or a wrapper around resolver execution.
Make authorization decisions depend on the resolved context: user identity, tenant, and relevant parent object.
Ensure batching doesn’t bypass auth. If you batch-load records, you still must filter or enforce permissions before returning field values.

If authorization feels like “framework within a framework,” that’s not a sign you’re doing it wrong—it’s a sign you’re modeling a real problem. The goal is to make that complexity boring.

Query Complexity Limiting: Protecting Against Your Own Frontend Team

GraphQL’s flexibility can be weaponized—accidentally or intentionally. Even if you never expose your API publicly, your own frontend team can accidentally ship an expensive query shape. Or a new feature can trigger a deep nesting selection set. Or a pagination bug can request far more than intended.

The solution is query complexity limiting: measure the “cost” of a request (depth, estimated resolver work, field weights) and refuse or throttle requests that exceed thresholds.

Complexity limits are an operational control, not a theoretical one

A realistic approach:

Assign weights to fields. For example, users might be 1, projects might be 3, owner might be 5.
Penalize deep nesting. A query that goes five levels deep should not be “free” just because it’s in a single request.
Consider pagination arguments. A query asking for 1,000 items should cost more than one asking for 20.

Practical advice:

Start conservative and iterate with real query logs.
Return a helpful error that your frontend team can act on (“reduce depth,” “use pagination,” or “request smaller page size”).
Add tooling so developers can test complexity before deploying. Otherwise complexity limiting becomes a support ticket machine.

This is one area where GraphQL differs sharply from REST: clients can shape the server workload. You must respond by shaping—or constraining—that workload.

Performance Observability: GraphQL Needs Better Tracing Than You Expect

Once you move beyond toy workloads, the real question becomes: where is the time going? With GraphQL, it’s not just “which endpoint is slow.” It’s “which field resolver caused the slowdown,” possibly across multiple services.

Without strong observability, you’ll end up guessing. And guessing is expensive when queries vary wildly by client.

Practical advice:

Instrument resolver execution time per field, not just per request.
Correlate GraphQL resolver spans with downstream service calls and database queries.
Track the number of resolver invocations and the count of batched loads per request. If your DataLoader isn’t working, you’ll see it here.
Log query shape metadata: operation name, selected depth, and expensive fields. You don’t need to store raw queries forever—just enough to analyze performance regressions.

Opinionated take: treat your GraphQL server like a query execution engine, not a thin HTTP layer. That means applying the same rigor you’d apply to a database—metrics, tracing, and controlled execution paths.

Shipping GraphQL at Scale: A Checklist That Prevents Regret

If you’re building GraphQL for production use, don’t rely on good intentions. Build guardrails early:

Always batch nested fetching. Use per-request DataLoaders (or equivalent) and enforce it consistently across resolvers.
Define schema ownership. Every type and domain should have a steward. Avoid “schema by accumulation.”
Centralize authorization decisions. Field-level rules should be managed in one place with strong context handling.
Enforce query complexity limits. Use weighted costs, depth limits, and pagination-aware rules.
Invest in tracing and performance visibility. Resolver-level instrumentation is non-negotiable.

And most importantly: socialize these rules with your product and frontend teams. Complexity limits, auth behavior, and schema boundaries aren’t backend details—they’re developer experience.

Conclusion: The Tax Is Real, But It’s Manageable

GraphQL at scale isn’t about abandoning the model—it’s about accepting the operational reality. N+1 queries, schema sprawl, field-level authorization, and complexity attacks aren’t unsolvable. They’re just the costs of giving clients power over query shape.

Pay attention early, and you can keep GraphQL’s strengths: a precise contract, efficient data fetching, and a schema that actually helps teams move faster. Ignore it, and you’ll discover that “flexible” eventually means “fragile” under load.

Edge Functions Are the Serverless Evolution Nobody Talks About

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 08 Sep 2022 00:00:00 +0000

Serverless used to mean “write code, forget servers.” But for many teams, it also meant “accept latency tax.” The breakthrough isn’t just that serverless got cheaper or easier—it’s that edge functions moved compute closer to users, turning network delay from an inevitability into a choice. Cloudflare Workers and Deno Deploy didn’t merely improve performance; they quietly rewired how modern deployment strategy should work.

Why Lambda Feels Fast—Until It Doesn’t

AWS Lambda (and its cousins) changed application development by making compute elastic. You pay for what you run, you deploy code, and the platform handles scaling. For workloads that aren’t latency-sensitive, Lambda can be a great fit.

But there’s a structural issue Lambda can’t fully erase: regionality. Even when your function is “serverless,” it still runs in a specific cloud region. If your user is halfway across the world, every request has to traverse distance, routing, and congestion before your code even starts. In other words, Lambda optimizes your server management—but not always the physics of delivery.

Teams often compensate by optimizing backends: caching, query tuning, faster language runtimes, aggressive CDNs, and better keep-alive behavior. Those improvements can be real. Yet for APIs and request-driven logic, the dominant cost often becomes the round trip to the nearest compute region—not the database query itself.

Edge functions attack that different problem directly: they run your code near the network edge, in many locations simultaneously.

Edge Functions: Same “Serverless,” Different Placement

Edge functions are still serverless in spirit: deploy code without managing servers. The key difference is where that code runs. Instead of a single regional deployment target, edge platforms execute your logic at a large number of points of presence worldwide.

That placement matters because latency is often dominated by distance. Move compute closer to users and you shrink the time between “user pressed a button” and “your logic replied.” This is why edge approaches feel different: a cached static asset might already be served from the edge, but dynamic logic—auth, request shaping, personalization, transformations—has historically been trapped behind regional compute.

Cloudflare Workers, for example, run on V8 isolates rather than containerized environments. That architectural choice is less about branding and more about behavior: startup time and request overhead are dramatically reduced compared to traditional cold-start patterns. In plain terms, “spin up” becomes almost a non-event, which is what you want for high fan-out request handling.

Practical framing: if your workload involves lots of small requests that must respond quickly, edge functions can remove a whole category of latency. If your workload is a heavyweight batch job, it won’t.

The Real Trade-off: Constraints That Force Better Design

Edge isn’t “unlimited serverless.” It’s serverless with guardrails—meaning you have less flexibility than with Lambda or a container service.

Common constraints you’ll feel immediately include:

No filesystem access (or severe limitations): You can’t assume persistent disk semantics.
Limited memory: You can’t casually load large models, huge datasets, or heavy in-memory processing.
No long-running processes: You can’t run background daemons the way you might in a VM or container.
Runtime differences: “Works in Node locally” doesn’t always translate perfectly to the edge runtime.

This is not a deal-breaker; it’s a forcing function. Edge functions are best when the request can be handled quickly and deterministically—when you can treat each request like a self-contained transaction.

That suggests a different architecture mindset:

Keep transformations lightweight.
Stream responses where possible.
Use external services for heavy lifting.
Cache results aggressively when safe.
Design for timeouts and early exits.

If you’ve ever built an API and then tried to shoehorn authentication, rate limiting, header normalization, and content rewrites into multiple backend layers, edge functions let you pull some of that work closer to the user—without waiting for a full regional compute pipeline.

Where Edge Functions Shine (With Concrete Examples)

Edge functions are not a replacement for everything. They’re an amplifier for specific classes of problems: request-driven logic that benefits from geographic proximity and fast startup.

1) Authentication and Authorization Middleware at the Edge

Instead of sending every request to a backend just to validate a token, you can verify credentials at the edge and forward only authorized traffic.

A common pattern: inspect the Authorization header, validate a JWT signature (or consult an auth endpoint if needed), and then add identity context to upstream requests. Even if you still call a backend for business logic, you’ve removed a round trip and reduced load on your origin.

Practical advice: keep verification fast. If token validation requires remote calls, cache those results or use a strategy that keeps your edge response time predictable.

2) Request Routing and URL Rewriting

For multi-tenant apps, edge logic can map hostnames or paths to the right origin service.

Example: tenantA.yourapp.com and tenantB.yourapp.com can route to different backends, while still serving shared assets from the same CDN. Or you can implement clean URLs that rewrite to internal endpoints without changing the user-facing structure.

The payoff is real: fewer redirect hops and less backend logic.

3) Content Transformation (But Keep It Bounded)

Want to transform HTML responses, rewrite links, or apply small response mutations? Edge is ideal.

Examples:

Rewrite image URLs to a CDN format.
Adjust caching headers based on path patterns.
Inject environment-specific scripts into the response.
Transform JSON payloads for compatibility between services.

The key is to keep transformations small and streaming-friendly. If you need to render a full page from templates, that may be a better fit for edge rendering frameworks—still edge-adjacent, but architected for it.

4) Security Controls and Bot Mitigation

Edge is naturally suited for request filtering:

Block known malicious patterns.
Rate limit by IP or token.
Enforce header requirements.
Normalize requests to reduce attack surface.

You get two advantages: quicker rejection (less wasted work upstream) and consistent enforcement across locations.

5) Personalized Responses with Near-Zero Startup

If your personalization is lightweight—say, selecting a theme or variant based on a cookie—you can compute that at the edge and return the correct result immediately.

Done well, personalization becomes a fast lookup rather than an expensive orchestration step across regions.

A Practical Migration Strategy: Don’t “Edge Everything”

The best way to adopt edge functions is to target the latency contributors first, not to rewrite your entire stack.

Here’s a sensible approach:

Measure before you guess. Look at your request waterfall: where does time go? If you see meaningful delay before your backend code starts running, that’s your signal.
Start with one endpoint class. Pick a narrow slice like auth validation, header normalization, or URL rewriting.
Design for statelessness. Assume each request is independent. If you need data, fetch it efficiently (or cache it).
Choose safe caching. If the edge response can be cached without violating user isolation, do it. If not, cache the pieces that are safe (like token verification artifacts or configuration).
Integrate with your existing infrastructure. You don’t have to replace your backend. Let edge handle the first mile, then forward the request.

A common pitfall is using edge functions as a dumping ground for complex business logic. That defeats the point: you’ll end up fighting constraints, complicating debugging, and still paying upstream latency for the work that stays in the origin.

Instead, treat edge code like the “front porch” of your system: fast checks, quick rewrites, and small transformations that make everything downstream cheaper.

The Bigger Point: Deployment Strategy Is Now Part of Performance

There’s a deeper reason people “don’t talk about” edge functions enough: they change the conversation from implementation details to deployment geography.

You can’t optimize your way out of regional distance alone. You can add caching and tune code, but if the request must wait for regional compute before it can even decide what to do, your platform is still paying the network tax. Edge functions turn that decision into an immediate action near the user.

Cloudflare Workers and Deno Deploy represent a shift in what developers should consider normal: not just “deploy code,” but “deploy logic at the network edge.” The runtime constraints are real, yet they align with modern web needs—short-lived request handling, streaming responses, middleware-like workflows, and fast security enforcement.

Conclusion: Edge Functions Are the Upgrade You Actually Feel

Serverless was supposed to remove friction. Edge functions remove another form of friction: the latency that comes from waiting for code to run far away. When your workloads match the edge sweet spot—API middleware, auth, routing, security filters, bounded transformations—Workers-style execution can make your system feel dramatically faster, not just better optimized.

Adopt edge functions like a product decision: start with one high-impact path, design for statelessness and speed, and let the edge handle the first and most time-critical moments of the request lifecycle.

React Fatigue Is Real, and Svelte Knows It

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 27 Aug 2022 00:00:00 +0000

React didn’t just start a trend—it set expectations. For years, “modern front-end” meant thinking in components, mastering hooks, and treating state as the central character in every app. But somewhere along the way, the day-to-day experience started to feel like a treadmill. Not because React is bad, but because the surrounding ecosystem has become… loud. And in the loudness, developers are getting tired.

The framework wars aren’t over. They’re just evolving. React fatigue is real, and Svelte’s approach—compile away the framework at build time—hits a nerve: fewer abstractions, less ceremony, code that looks closer to what you actually ship.

The hook-era bargain—and the interest that keeps accruing

Hooks were a breakthrough. They made function components first-class and unlocked patterns that class components made awkward. But the “hooks era” also introduced a kind of cognitive tax.

You don’t just write UI anymore. You also write rules for how state changes flow through time:

Dependency arrays that must be correct or subtly wrong.
Effect ordering questions that don’t always have intuitive answers.
Stale closures that appear only under specific timing and render sequences.
A steady stream of advice like “move logic into effects” or “avoid effects entirely,” often contradicting itself depending on who you ask.

In practice, this means more time spent reasoning about lifecycles than about interfaces. Consider a simple requirement: “When the user selects an item, fetch details and show a spinner, then render the result.” In React, you typically end up with effects, conditional logic, and careful dependency tracking:

useEffect(() => {
 if (!selectedId) return;

 let cancelled = false;
 setLoading(true);

 fetch(`/api/items/${selectedId}`)
 .then(r => r.json())
 .then(data => { if (!cancelled) setData(data); })
 .finally(() => { if (!cancelled) setLoading(false); });

 return () => { cancelled = true; };
}, [selectedId]);

It works, but it’s not inherently “UI code.” It’s choreography code—because the framework requires you to coordinate when and how side effects occur.

When developers say they’re fatigued, they’re often describing this feeling: the codebase is teaching you more about the framework than the product.

State management debates never end because the problem never quite resolves

React’s flexibility is both its superpower and its curse. Almost any state can live anywhere: component state, context, reducers, stores like Redux/Zustand/MobX, server state libraries, caches, query layers, and so on. The ecosystem has solutions for everything—so the argument never fully shuts down.

You can see the pattern on real teams:

“We need global state.”
“Actually we just need derived state.”
“Never mind, we need async caching.”
“The app will be cleaner with a store.”
“No, use context + hooks is simpler.”
“We’ll regret that later.”
“Let’s rewrite.”

React fatigue is often less about React itself and more about state architecture churn. Even when the team agrees on an approach, the boilerplate and mental overhead can pile up quickly: action types, selectors, memoization, cache invalidation strategies, and “why did this re-render?” investigations.

To be clear: state management is hard. Every framework faces it. But React’s model tends to encourage debates because it doesn’t prescribe a single, opinionated path for how UI state, server state, and side effects should be wired together.

Svelte’s pitch is different: less “pick a library for everything,” more “the compiler can do the bookkeeping.”

Meta-framework churn: when “React” turns into a stack you have to maintain

Then there’s the meta-framework layer. In 2026, “React app” often means a particular combo of routing, rendering strategy, data fetching, bundling, styling conventions, and deployment assumptions. Next.js, Remix, custom SSR setups, edge runtimes, loading patterns, hydration quirks—the list keeps growing.

The result is a subtle fatigue: teams spend more time staying current with the platform layer than improving product code.

And the churn isn’t always optional. If you want the “right” conventions for SEO, caching, streaming, or routing, you inherit the framework’s worldview. That worldview then shapes your components, your fetching logic, and even how developers learn to think.

This is where many React developers start to crave simplicity—not in the sense of less capability, but in the sense of fewer decisions per feature.

Svelte’s radical move: compile away the framework

Svelte’s central idea is disarming: instead of shipping a big runtime that interprets your components, Svelte compiles your code into efficient JavaScript at build time. The framework doesn’t have to “make things work” in the browser because it already transformed your intent into concrete instructions.

The practical effect is that you write less scaffolding and fewer coordination rituals. React asks you to tell it what state is and when to react. Svelte asks you to declare what UI depends on, and the compiler wires the updates.

Here’s a stylized comparison. In React, a component might juggle local state, effects, and conditional renders. In Svelte, the reactive dependency model is closer to how many developers naturally describe UI:

<script>
 export let selectedId = null;
 let data = null;
 let loading = false;

 $: if (selectedId) {
 loading = true;
 fetch(`/api/items/${selectedId}`)
 .then(r => r.json())
 .then(json => data = json)
 .finally(() => loading = false);
 }
</script>

{#if loading}
 <p>Loading…</p>
{:else if data}
 <h2>{data.title}</h2>
{/if}

This doesn’t mean you never need effects or async control. It means the “reactivity plumbing” is less verbose. And because Svelte tracks dependencies at compile time, updates can be more direct, without you constantly reasoning about render cycles and effect timing.

You still write real logic. You just spend less time translating your logic into framework-specific rituals.

Smaller surface area: why code feels closer to HTML/CSS/JS

One reason Svelte feels like relief is that the code reads like a developer’s mental model of the browser: HTML for structure, CSS for presentation, JS for behavior.

Svelte components co-locate template and logic in a way that keeps your attention on the UI:

Markup and state are right next to each other.
Styling stays where it belongs, often in the same file without an extra ceremony layer.
Event handling is straightforward and doesn’t require a new mental framework.

React is absolutely capable of this style—but the surrounding ecosystem often nudges you toward patterns that pull logic into separate files, wrap everything in abstractions, and turn “a component” into a mini-architecture project.

Svelte doesn’t prevent scaling. It simply gives you a smaller baseline. That matters when you’re building the second and third feature, not just the first.

Practical advice if you’re considering the switch: don’t treat Svelte as a “new framework to learn.” Treat it as a different default tradeoff. You’ll likely gain speed in everyday development, especially for UI-heavy apps where reactive updates are frequent.

But React isn’t dead—Svelte just proves you can optimize developer experience

It’s tempting to declare framework winners like sports fans. That’s not how this plays out.

React is deeply entrenched. There are entire hiring pipelines, codebases, and libraries built around it. It’s not going away. And React teams can absolutely reduce fatigue—by enforcing architectural conventions, limiting the sprawl of state libraries, and choosing consistent patterns for side effects.

Still, Svelte’s existence changes the conversation. It proves that a UI framework doesn’t have to ship its own runtime burden to be powerful. It can compile your intent into something closer to hand-written JS. And that shifts the center of gravity back toward developer experience: fewer moving parts, fewer “gotchas,” and fewer places for the app to reinvent the same wheel.

The real evolution is this: React fatigue isn’t the end of React—it’s the beginning of a broader push toward simpler mental models.

Conclusion: the framework wars are evolving toward calm

React fatigue is real because the ecosystem grew beyond the framework: hooks complexity, endless state debates, and meta-framework churn all add up. Svelte’s response is not a new dashboard of features—it’s a smaller system with a clearer job: compile components into efficient code and let reactivity be driven by dependencies, not rituals.

React will keep building the web for a long time. But Svelte’s win—developer love, not just benchmarks—signals something important: the next era of front-end isn’t about more abstraction. It’s about less ceremony, fewer decisions, and code that feels like it belongs to the browser, not to the framework.

Deno Was Right About Everything (And It Might Not Matter)

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 15 Aug 2022 00:00:00 +0000

For a while, Deno felt like a corrective lens: the same problem space as Node.js, but with the mistakes acknowledged up front and fixed by design. Secure by default. TypeScript from day one. Web-standard APIs. Clean, predictable tooling. It’s hard to argue with that direction. The uncomfortable twist is that “better” doesn’t automatically win—especially when the winning asset isn’t code, it’s the ecosystem. Deno’s ideas may still be the real story, even if Deno itself doesn’t fully take over.

The “rewrite the universe” instinct Node never had

When Ryan Dahl built Node.js, it was a lightning strike: fast, pragmatic, and wildly productive. It also shipped with blind spots that only became obvious at scale—most famously around security. Node’s permission model is effectively “opt out of safety,” which works fine for controlled environments and breaks down in the messy reality of modern deployments.

Deno’s core instinct was different. Instead of retrofitting safety and structure after the fact, it set defaults that assume you will run untrusted code, pull dependencies from the internet, and deploy to shared infrastructure. The result is a runtime that forces you to be explicit: if you want filesystem access, you ask for it; if you want network access, you ask for it. That one decision changes how teams reason about threat models.

It also changes how developers learn. With Deno, you can’t ignore permissions without noticing the friction. In Node, you can ignore permissions all day—until something goes wrong, and then you’re scrambling to patch with wrappers, conventions, or separate processes.

Secure-by-default: the most consequential “small” decision

Deno’s permission flags look like a usability tax—until you realize they’re actually a clarity gain. Consider the most common failure mode for JavaScript services: a dependency pulls code you didn’t expect, and that code reaches out to sensitive resources.

In Deno, the runtime nudges you toward the safer posture:

Your script won’t touch the filesystem unless you explicitly grant --allow-read (or broader).
It won’t make outbound calls unless you explicitly grant network access (e.g., --allow-net).
You can tighten scope to what the program needs rather than granting blanket rights.

In practice, teams can turn this into a repeatable workflow. For example, a CLI tool that reads a config file and writes a report doesn’t need full access; it needs narrow read/write permissions. That means the “worst-case” impact of a compromised dependency is capped by the boundaries you set when running the program.

Node can do permissions too, but it’s not the default experience in the same way. Most teams rely on container boundaries, network policies, and careful deployment practices—good measures, but indirect. Deno tried to make the runtime itself a first-class part of the defense, not an optional add-on.

If you care about secure-by-default, Deno’s approach is objectively cleaner: fewer hidden assumptions, fewer opportunities to forget the security step, less reliance on tribal knowledge.

TypeScript native: fewer tools, fewer gaps

Deno’s other big bet was to treat TypeScript as a native concern rather than a build-time afterthought. In a Node world, TypeScript often means one or more of the following:

a compilation step,
a bundler step,
a runtime loader or transpiler,
and sometimes “just enough” configuration to make it all work.

You can make it solid—but you’re building a pipeline. Deno largely collapsed that pipeline into the runtime workflow.

This matters for day-to-day engineering because friction multiplies. A typical Node+TypeScript project can become a maze of config files: tsconfig, package.json scripts, tooling versions, and sometimes edge-case handling for module formats. Deno’s workflow encourages a single mental model: write TypeScript, run it, get predictable behavior, keep moving.

Even if you eventually bundle or compile for production, “TypeScript native” still pays dividends during development: faster feedback loops and fewer configuration seams where bugs hide.

The punchline: Deno didn’t just make TypeScript convenient; it made correctness more continuous. You spend less time chasing tooling mismatch and more time fixing logic.

URL imports and web standards: the boring power move

Deno’s module story is another area where it felt like Deno was playing a different game. Node’s module ecosystem is deeply tied to the package manager and registry. Deno’s design, by contrast, leans toward URL imports and web-standard compatibility—so dependencies can be fetched and used in a way that resembles how the web itself works.

At minimum, that changes how you think about dependency resolution and version control. In Deno, “where code came from” can be more explicit. A URL points to a specific origin; that makes it easier to reason about provenance and caching. It also reduces the mental overhead of the “package is named X, but what actually installed?” question that haunts npm-heavy workflows.

This is not just aesthetic. The moment you’re dealing with serverless functions, edge runtimes, or CI systems that need reproducibility, having a cleaner import model helps you keep builds deterministic without layering on complexity.

And Deno’s push toward web-standard APIs means your JavaScript model is closer to what browsers and other runtimes already understand. That reduces the gap between “web developer” and “backend developer,” which is good for teams and good for recruiting.

The ecosystem moat is real—and Deno’s truce is an admission

Here’s where opinion becomes math: Node wins because npm wins. The package ecosystem is an unassailable moat not because it’s perfect, but because it’s everywhere. Millions of developers have already invested in Node-compatible libraries. Enterprises have locked in on them. Tutorials, internal tools, and automation scripts assume npm.

Deno’s npm compatibility layer exists because the only way to beat a moat is either to drain it slowly or to tunnel through it. Deno chose the tunnel: “you want to use existing npm packages? Fine—let’s integrate.”

That’s not a failure of Deno’s ideas. It’s a recognition that language and runtime design don’t operate in a vacuum. If your goal is to move quickly with real-world libraries—databases, SDKs, auth integrations, web frameworks—you can’t ignore the ecosystem you inherit.

So Deno’s best move might not be to replace Node’s entire universe. It might be to keep applying pressure until Node modernizes its defaults. When runtimes compete, ecosystems decide the pace. But ecosystems also respond to pain: security concerns, TypeScript friction, and the constant desire for more consistent module resolution.

What Deno’s legacy could look like: Node pressure, safer defaults

The most likely future isn’t “Deno replaces Node.” It’s “Deno changes what ‘normal’ means.” Even without claiming victory, Deno forces an honest comparison.

When developers and teams build with Deno, they experience its defaults as the baseline:

secure permissions that don’t depend on organizational maturity,
TypeScript that isn’t bolted on,
tooling that doesn’t splinter the dev loop,
APIs that feel familiar if you’ve lived in the browser world.

And once you’ve tasted those defaults, you notice when the alternatives require more ceremony to achieve the same outcome.

In other words, Deno may matter most as a forcing function. Node’s momentum is real, but so are the questions Deno asked out loud. “Why is security opt-out?” “Why isn’t TypeScript first-class everywhere?” “Why does module resolution feel like a pile of compromises?” Once those questions are mainstream, competitors don’t just sell features—they evolve their assumptions.

If you’re working in Node today, the practical lesson is to adopt Deno’s mindset even if you don’t adopt the runtime. Make security explicit. Treat TypeScript as part of your core workflow. Push for predictable module resolution and reproducible dependency handling. Use CI to catch configuration drift. Document runtime permissions like you document environment variables. These are not Deno-specific ideas; Deno just made them obvious.

A practical way to evaluate Deno (without fan fiction)

If you’re considering Deno for real projects, don’t evaluate it as a “replacement for Node.” Evaluate it as a tool that optimizes for specific engineering priorities.

Ask yourself:

Do you run untrusted code or frequently pull third-party dependencies?
If yes, secure-by-default is not a nice-to-have; it’s a risk reducer.
Is your TypeScript workflow currently heavy or inconsistent?
If your dev loop involves too many moving parts, Deno’s native approach can simplify the system.
Do you want web-standard API familiarity and cleaner module semantics?
If you’re building for environments that share web principles, Deno reduces translation layers.
Do you rely heavily on npm-only libraries with no Deno-native equivalents?
If yes, you’ll likely spend time validating compatibility layers and edge cases. Not necessarily a deal-breaker, but it’s real work.

The goal isn’t purity. It’s fit. Deno shines when its defaults align with your constraints; Node shines when its ecosystem alignment matches your reality.

Conclusion: Deno’s ideas already won—even if Deno doesn’t

Deno was right about a lot. It treated security as a default rather than a feature request. It made TypeScript integral instead of optional. It leaned toward web standards and more explicit dependency provenance. Those are objectively better design choices for modern software.

But software isn’t just design—it’s adoption, inertia, and the gravitational pull of npm. Deno’s npm compatibility isn’t a defeat; it’s the acknowledgement that ecosystems are the true battleground. Even so, Deno’s greatest legacy may be forcing Node to modernize its defaults by making the “better way” impossible to ignore.

In the end, the win might not be “Deno takes over.” It might be “the industry learns from Deno’s corrections—and stops requiring heroic effort to be safe.”

Stop Premature Abstractions: Write the Code Three Times Before You Generalize

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 08 Aug 2022 00:00:00 +0000

You don’t “fail fast” by abstracting early—you fail later, with interest. Premature generalization feels clean in the moment, but it quietly welds together parts of your system that haven’t earned a relationship yet. The result is a codebase that’s technically elegant and practically unchangeable.

The fix is not to avoid abstraction forever. It’s to delay it—until you’ve earned it. The rule of three is simple: write the code three times before you generalize. By then, you understand the variation space, and your abstraction has a fighting chance of being the right one instead of the most confident wrong thing.

The Real Enemy Isn’t Duplication—It’s Premature Certainty

Most developers treat duplication as a moral failing. That’s backwards. Duplication is often the symptom of a deeper truth: you don’t yet know what should vary.

When you extract too early, you’re not “DRYing up.” You’re making bets about future requirements using today’s assumptions. Those assumptions become constraints. And constraints become coupling. The coupling doesn’t always show up as bugs right away; it shows up as refactoring friction later, when you need to change one case and suddenly the “shared” code won’t fit.

A practical way to frame it: if you can’t explain, in plain language, what might differ between the cases you’re about to unify, you’re not ready to abstract. You’re ready to copy, at least temporarily.

Why “Second Time” Abstractions Create Coupling You Can’t Undo

The second time you encounter a pattern, you feel a little spark of “I’ve seen this before.” That’s the exact moment to resist.

Here’s a common scenario. You have two flows that both “process orders,” and they look similar enough to tempt you into a shared function:

Flow A: validates input, calculates totals, applies discounts, then writes an invoice.
Flow B: validates input differently, calculates totals with tax rules, may apply promotions, then writes a receipt.

On the surface, both flows perform “order processing.” If you abstract on the second occurrence, you’ll likely create an interface that works for A and B as you understand them today. The moment you add Flow C—say, for a subscription or a marketplace order—you discover the abstraction’s seams were in the wrong places. Now the shared function has become a funnel of conditional logic, special-case flags, or a sprawling parameter list that no one wants to call.

At that point, you don’t refactor an abstraction—you patch it. And patching abstractions is how teams end up with frameworks that only the original author can safely change.

Duplication, by contrast, is honest. When requirements diverge, the duplicated code can diverge too—without forcing everyone through the same narrow abstraction.

The Rule of Three: A Scheduling Strategy for Abstractions

The rule of three isn’t a religious commandment. It’s a workflow rule.

When you see repeated code, don’t immediately extract. Instead:

Duplicate once more on purpose. Keep the code separate.
Observe the differences across occurrences. Names, types, branching, side effects, performance needs—anything that forces divergence matters.
Only then generalize. After you’ve written three versions and felt the shape of variation, extract the stable idea.

Why three? Because the first two instances often share a superficial similarity. The third usually reveals what was missing—what changes, what doesn’t, and what you were about to force into a one-size-fits-all mold.

Think of it like building a model. Two data points let you draw a line. Three points help you identify curvature. In software, the “curvature” is where business logic and system constraints start refusing to conform to your early abstractions.

Concrete Example: “Common” Validation Is Usually a Trap

Let’s say you’re building an API and you keep writing validation code:

Endpoint /users validates required fields, checks email format, and ensures username uniqueness.
Endpoint /admins validates required fields, checks email format, and enforces a different uniqueness rule.
Endpoint /invites validates required fields, checks email format, but also validates token expiry and rate limits.

If you abstract after the second endpoint, you might build something like:

validateUserCommon(data, rules, uniquenessService)

It will look great until /invites shows up. Now your “common” validator needs to understand token semantics and rate limiting, which are not user semantics. So you extend the interface with more parameters. Then you add optional callbacks. Then you sprinkle conditional branches. Eventually your abstraction becomes an orchestration layer with flags like isInvite and enforceRateLimit.

You’ve turned duplication into a framework. It’s not DRY—it’s DRY-ISH, and it’s fragile.

If you waited, you could identify the real stable core: “validate fields and normalize errors,” while allowing the rest to plug in. After three occurrences, you can design a clean boundary:

shared normalization and error formatting
separate strategy objects (or functions) for domain-specific checks

The abstraction becomes smaller and more correct, because it’s based on what truly varies—not on the similarity you observed too early.

When Duplication Is the Better Engineering Trade

It’s worth stating plainly: duplication is not inherently bad. The goal is not to eliminate repeated lines—it’s to manage change.

Duplication can be cheaper because:

It isolates blast radius. Changing one variant doesn’t force every caller through the same contract.
It preserves local intent. Readers see domain logic directly, rather than decoding a generic “framework” layer.
It makes variation visible. Differences become obvious instead of hidden behind abstraction parameters.

The trick is to be disciplined about the kind of duplication you tolerate. There’s a difference between “copying with care” and “copy-pasting chaos.”

A pragmatic guideline:

Duplicate logic that is likely to diverge.
Abstract mechanics that are clearly stable and well-understood (e.g., pure formatting utilities, trivial adapters, obvious invariants).
Don’t abstract business rules until you’ve seen them collide across multiple real cases.

In other words: it’s okay to repeat yourself while your understanding is still forming. It’s not okay to repeat unclear intent forever.

What “Write Three Times” Looks Like in Practice

You need a method that doesn’t collapse under its own effort. Here’s a pattern teams can adopt:

Create a tiny “compare window.” Keep the duplicated code close in your repository (same module or feature folder) so differences are easy to spot.
Name the duplicates as if they’re temporary. For example, validateUser_v1, validateUser_v2 feels awkward, but comments and commit history can serve the purpose. The point is to signal intent: “we’re learning.”
Add targeted tests for each occurrence. As you write the second and third versions, tests teach you what the system truly needs.
After the third, write down the shared intent. Ask: What concept repeats? What varies? What would an interface need to expose? If you can’t answer, you’re not ready.
Refactor only once. When you extract, do it decisively. Partial abstractions that half-bind everything are the worst of both worlds.

Also, be honest about scope. This rule is most valuable in the parts of your code where domain logic and requirements churn—request handling, business workflows, integrations, pricing rules, permissions. In low-change utilities, abstractions may be fine earlier because the variation space is smaller and more predictable.

Conclusion: Earn Abstractions, Don’t Claim Them

Premature abstraction is the architectural version of a false positive: it looks like progress, but it smuggles in assumptions that will cost you later. The rule of three keeps your codebase honest by delaying generalization until you’ve actually observed the variation space.

Duplicate with intent, learn through repetition, then abstract once the pattern is real. Your future self will thank you—not with compliments, but with the rarest gift in engineering: refactoring that doesn’t turn into surgery.

The Case Against Microservices for Your Startup

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 03 Aug 2022 00:00:00 +0000

Microservices are the startup equivalent of putting turbochargers on a bicycle. It feels ambitious. It looks modern. And it’s usually the fastest way to blow your budget, derail your delivery, and lose your team to production fire drills. For most startups, the “correct” architecture isn’t the one with the most moving parts—it’s the one you can change confidently.

Microservices Sell a Story—But You Buy an Operating System

The most common origin story for microservices is simple: “Netflix does it, so we should too.” That’s not strategy; it’s cosplay.

Netflix can afford microservices because it has thousands of engineers and years of operational maturity. It also has business realities that make that complexity worthwhile: high traffic, many teams shipping concurrently, and the organizational need to isolate deployments across large domains. In other words, microservices aren’t just a technical choice—they’re an organizational investment.

Startups rarely have that luxury. If you have a small engineering team, microservices don’t just increase technical complexity; they increase coordination tax. Every new service becomes:

A new repository and release process (even if you try to keep it “light”)
A new deployment target
A new failure mode to understand
A new surface area for authentication, authorization, and rate limiting
A new set of logs, dashboards, alerts, and runbooks

Even if you build it “right,” the system you’re creating is not just code—it’s an operating model. That operating model consumes time you could have spent building the product.

The Hidden Cost: Distributed Complexity Is Real (and It’s Not Free)

Microservices trade one kind of complexity for another. The popular pitch is: “We reduce the complexity of large codebases by splitting them into smaller services.” True—until the complexity moves into the network.

Once you distribute the system, you inherit a zoo of problems that monoliths mostly avoid:

1) Service discovery and deployment choreography

If Service A needs Service B, you now need to handle service discovery, versioning, rollout strategies, and backward compatibility. That turns every change into a coordination event rather than a local refactor.

2) Distributed tracing and debugging

When something breaks, you don’t just inspect one stack trace. You trace a request across multiple services and environments, often with partial data. You’ll eventually develop muscle memory for debugging graphs instead of code.

3) Eventual consistency and data ownership

The moment you avoid a shared database, you face the question: “Who owns the truth?” In practice, you end up with replicated data, asynchronous updates, and edge cases like “user sees stale credit balance for two minutes.” Those edge cases aren’t theoretical—they become real user-reported bugs.

4) Network partitions and retry storms

Networks fail. Even in “healthy” systems, timeouts happen. The blast radius of a failure can grow dramatically if retries are unbounded or if backpressure is missing.

A monolith doesn’t eliminate failures—it just keeps failure modes local enough that your team can reason about them quickly. Microservices push you into cross-team and cross-service failure thinking long before you’ve earned it.

“But We Need to Scale”: Start With the Kind of Scaling You Can Actually Predict

There’s a persuasive but flawed assumption behind many microservices migrations: “We’ll need independent scaling.” It’s not wrong—just uncommon early.

Most startups scale first in predictable ways:

A single app backend handles requests
One or two datastores grow
A bottleneck appears in a specific module (search, reporting, payments integration, or async processing)

When that happens, you don’t need to split the whole system—you need to target the bottleneck. Monoliths are extremely capable at this, especially when structured with clear module boundaries.

A well-structured monolith lets you:

Keep module interfaces explicit
Refactor safely without distributed versioning
Centralize observability
Enforce data invariants where they belong

Then, when you have evidence, you can extract a component.

Here’s the pragmatic way to think about it: extract when you can name a business or technical constraint that forces independence. Examples include:

A module needs to scale 20x faster than the rest
A team needs to own a domain with different deployment cadence
A subsystem has specialized compute needs (e.g., heavy batch processing)
A data boundary is genuinely stable and benefits from isolation

Until you can point to one of those, microservices are more likely to be a guess than a plan.

The “Boring Wins” Monolith Playbook (Yes, You Can Still Be Modern)

A monolith doesn’t mean a junk drawer. “Boring” is only boring if you treat the codebase like it’s disposable. If you want a monolith that won’t collapse under growth, you need discipline.

Design for module boundaries from day one

Even in a single deployable, you can structure code as modules with:

Clear ownership
Explicit interfaces
Minimal cross-module coupling
Dedicated “application services” that coordinate work

Treat module boundaries like contracts. They will later make extraction straightforward, if and when you choose it.

Use an async boundary where it truly helps

A lot of systems benefit from asynchronous workflows without microservices. You can introduce:

A job queue for background tasks
Event-driven updates within the same service boundary
Dedicated workers that handle slow operations

This gives you many of the benefits (decoupling, responsiveness, retries) without multiplying operational complexity across networked services.

Centralize observability

You should be able to answer, in minutes:

What requests are failing?
Where are the slowdowns?
Which dependencies are misbehaving?
What code path is responsible?

A monolith makes tracing and logging simpler because there’s one deployment boundary and fewer hop-to-hop handoffs.

Keep deployment boring too

A single artifact, a single rollout process, a single rollback story. Your CI/CD pipeline becomes a force multiplier rather than a recurring coordination meeting.

If you want a mental model, think of it like this: start with a monolith that behaves like a set of modules—and upgrade to services only when the runtime boundary is necessary.

When Microservices Actually Make Sense (Spoiler: It’s Usually Later)

Microservices can be the right move when two things align:

You have enough scale that failure and latency costs matter.
You have enough organizational maturity that multiple teams can operate independently.

“Later” doesn’t mean “after you’re huge.” It means “after you’ve proven the specific pain.”

Common signals that extraction is justified:

One module has become a release bottleneck (every change depends on a single shared deploy)
The codebase is growing so entangled that refactoring risks breaking unrelated features
Independent scaling is real (not speculative), and the cost of inefficiency is measurable
You’re migrating to a data model where isolation is beneficial and stable
You have a dedicated domain team that can take ownership of the operational burden

When you do extract, don’t start with “everything.” Pick a single, well-contained component with a clean contract and a clear owner. The first service should be boring to operate and easy to debug—not a sprawling “platform” that takes six months to stabilize.

A Concrete Path That Doesn’t Waste Years

Here’s an approach I recommend repeatedly because it fits how startups actually work:

Build a modular monolith with strict internal interfaces.
Add background jobs for slow or failure-prone work (queues, workers, retries, idempotency).
Instrument deeply so you can identify bottlenecks and understand failure rates.
Extract one service at a time when you have proof of necessity—independent scaling, independent release cadence, or a stable data ownership boundary.
Keep integration contracts sharp: version APIs thoughtfully, and design for graceful degradation rather than fragile synchronous calls.

This approach preserves speed now and keeps the door open later. It avoids the trap of “architecture as a deadline,” where the system grows complex before the product earns real traction.

And importantly: it keeps your team shipping. A startup doesn’t need an enterprise platform to succeed—it needs a reliable way to deliver value and learn quickly.

Conclusion: Complexity Is a Tax You Should Only Pay When You Can Afford It

Microservices are not automatically wrong. They’re just expensive—operationally, cognitively, and organizationally. For most startups, a structured monolith is the pragmatic choice: it’s easier to reason about, faster to change, and simpler to observe under pressure. Go distributed only when you have clear evidence that you need the separation—and when your team can genuinely operate it. Boring wins, because shipping wins.

Monorepos Are Worth the Pain (If You Use the Right Tools)

abdecastro@protonmail.com (Antonio B De Castro) — Fri, 22 Jul 2022 00:00:00 +0000

Monorepos don’t become “good” because you put everything in one folder. They become good when you can move fast without breaking things—with tooling that understands what changed, what depends on what, and how to reproduce builds reliably. The monorepo vs. polyrepo debate is loud because the pain is real. But the upside is also real: atomic changes across packages, fewer synchronization headaches, and a developer workflow that doesn’t collapse as your codebase grows.

The real argument isn’t structure—it’s coordination

People fight about monorepos and polyrepos like it’s about architecture aesthetics. It isn’t. It’s about coordination cost.

In a polyrepo setup, even “simple” changes can turn into choreography:

You update a shared library.
You bump a version somewhere.
You update a consumer repo.
You coordinate PRs, merges, and release timing.
You hope everyone tested the same commit state.

In a monorepo, you can often make one atomic change that spans packages:

Update the shared library.
Update the consumer(s).
Run the right tests.
Ship together.

That atomicity is the monorepo’s most practical advantage—not “code sharing,” and certainly not the fantasy that one repo magically makes dependencies painless. If your changes usually cross package boundaries, you’re paying coordination taxes somewhere. Monorepos just give you a chance to pay them once in tooling, rather than repeatedly in process.

The catch: this only works if your monorepo is managed like a system, not like a folder dump.

Why monorepos became nightmares (and how modern tools fix the core issues)

Bad monorepos tend to fail in predictable ways. The usual suspects:

No clear dependency graph If your tooling can’t tell which packages depend on which, you’ll either over-test everything or under-test and ship broken builds.
Slow installs and slow builds Without workspace-aware package management and caching, a monorepo turns every developer action into a waiting room.
“It works on my machine” If builds aren’t reproducible and caching isn’t reliable, remote teams will lose hours to mystery failures.
Testing everything, always The moment “run the tests” becomes “run all the tests,” developers will stop running tests.

Modern monorepo tooling targets these failure modes directly. The winning combination usually looks like:

pnpm workspaces for fast, deterministic dependency management across packages.
Turborepo for caching and task orchestration, including remote caching so CI and dev machines share results.
Nx for “affected-only” thinking—running tests/builds based on what changed and what depends on it.

You’re not adopting tools for the sake of it. You’re replacing brute-force workflows with graph-aware, cache-friendly execution.

pnpm workspaces: the foundation most teams underestimate

Before you even talk about caching and graphs, you need sane dependency management. pnpm workspaces help by treating the monorepo as a coherent package universe rather than a set of unrelated projects.

In practical terms, pnpm workspaces give you:

Centralized install behavior across packages.
A shared store that avoids reinstalling the world.
Predictable resolution so dependency drift is less likely.

Here’s what this changes for a developer workflow. Suppose you’re working on @acme/ui and a related app @acme/web. With pnpm workspaces, switching branches or adding a dependency in @acme/ui doesn’t require rethinking how the whole repo is installed. That matters because developers will only embrace monorepo workflows if everyday actions are quick.

Also, workspaces make it easier to enforce consistent package standards: lint scripts, TypeScript settings, versioning conventions—whatever your team decides should be uniform.

If you skip this foundation, everything above it gets harder.

Turborepo: make “run the right tasks” feel effortless with caching

Turborepo’s pitch is simple: orchestrate tasks across packages and cache results so repeated work disappears.

The monorepo pain point is that “run tests for one change” is deceptively hard. Without orchestration, you end up reinventing it with brittle scripts. With Turborepo, you model tasks like build, test, and lint across your package graph—and it decides what to run and what it can reuse.

The most impactful feature is (remote) caching. Caching changes the psychology of monorepos. Instead of “CI might take forever,” it becomes “CI will often be instantaneous,” because the output for a given task and inputs already exists.

Concrete example:

You change a shared utility package: @acme/utils.
You run turbo test.
Turborepo figures out what depends on @acme/utils.
It runs the tests for those dependent packages.
For tasks you’ve already executed with the same effective inputs, it pulls results from cache rather than rebuilding.

Now imagine a team workflow:

Developer A runs tests and populates cache.
Developer B pulls the changes, runs the same tasks, and gets results quickly.
CI verifies the exact same task graph outcomes without burning compute.

That feedback loop is how monorepos stop feeling like punishment and start feeling like leverage.

Nx: trust the dependency graph, then run only what’s affected

If Turborepo focuses on task execution and caching, Nx emphasizes “affected-only” operations: run what’s needed based on the dependency graph and the changes you made.

The key benefit is developer trust. When you run affected:test (or the equivalent patterns Nx enables), you’re confident the system isn’t blindly running everything—or, worse, missing critical checks.

A typical monorepo setup has three layers of work:

Lint (fast, catches style and type issues early)
Unit tests (medium cost, validates behavior)
Builds (expensive, ensures distributable outputs)

Affected-only execution lets you scale these layers without turning “try a small change” into “wait half an hour.”

What it looks like in practice:

You modify @acme/auth.
Nx identifies which packages depend on it (say @acme/api and @acme/web).
You run tests for those affected packages, not the entire universe.

This is the difference between a monorepo that stays interactive and one that quietly trains developers to stop running checks. Affected-only tooling keeps the “inner loop” tight, which is where engineering velocity is won.

The monorepo superpower: atomic changes across packages

Here’s the real reason monorepos are worth the pain: they make coordinated changes boring.

In a polyrepo world, a breaking change in a shared package often requires coordinated PRs:

PR in the library repo
PR in each consumer repo
Potential version bump choreography
Release coordination, or at least a carefully timed merge

In a monorepo, you can do this as a single coherent unit of work:

Update @acme/auth.
Update @acme/web and @acme/api to match.
Run impacted tests.
Merge once.

Even better, you can codify this into your workflow:

Require that affected tests pass before merge.
Use caching so PR checks don’t grind to a halt.
Keep the dependency graph authoritative so “what depends on what” is never a guessing game.

This is also where tooling choice matters. Without Turborepo/Nx-style execution, atomic changes turn into atomic failures—because everything is rebuilt and tested so slowly that people stop relying on automation. The tooling isn’t a luxury; it’s what turns atomicity into shipping.

When it’s worth it (and when it’s not)

Here’s my opinionated rule of thumb: if your team ships more than a few related packages, you should seriously consider a monorepo. If you have exactly one shared package and the rest are independent projects, a polyrepo might be simpler and perfectly fine.

But the decision should be driven by change patterns, not ideology:

Do your updates frequently cross package boundaries?
Do you regularly need coordinated releases?
Are you already losing time to “wait for another PR” or version bump logistics?
Is your shared code evolving under active development?

If yes, monorepo tooling has matured enough that the pain is mostly solvable. The hard part isn’t putting code in one repository. The hard part is building a workflow where developers can safely move fast.

Conclusion: manage complexity, don’t pretend it won’t exist

Monorepos aren’t inherently better than polyrepos. They’re better when you use the right tools to manage complexity: pnpm workspaces for dependency sanity, Turborepo for orchestrated tasks and remote caching, and Nx for affected-only correctness. Do that, and the monorepo becomes what it’s always promised to be—an environment where atomic changes are practical, feedback is fast, and coordination costs finally stop haunting every release.

Bun Is the JavaScript Runtime Nobody Asked For (That We Desperately Need)

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 11 Jul 2022 00:00:00 +0000

JavaScript developers have been living with a quiet assumption: “the runtime wars are basically over.” Node.js won, Deno tried to clean up the mess, and most of us just built our apps and pretended the platform never changed. Then Bun showed up—fast, opinionated, and bundled so aggressively it feels less like a runtime and more like a complete development environment that fell out of the sky. Nobody asked for another contender. That’s exactly why we need one.

The messy backstory: why “fast runtimes” keep happening

At some point, performance stopped being a competitive advantage and became a baseline expectation. Cold starts matter. CI minutes matter. Tooling latency matters. Developers want “save → run” to feel instant, not “save → wait” like it’s 2013.

Node.js built the modern JavaScript server world, but it also set habits: the ecosystem grew around it, tooling targeted it, and even non-Node environments often emulate its behavior. Deno arrived with a different philosophy—secure by default, less configuration, and a runtime that treats the standard library like a first-class citizen. But adoption takes time, and time is expensive.

Bun entering the ring isn’t really about a newcomer trying to prove it can run JavaScript. It’s about pressuring the status quo. Runtimes don’t improve in a vacuum; they improve when they have to compete with something better—or at least different enough to force everyone else to respond.

What Bun actually is (and why it feels like cheating)

Bun isn’t just “another way to run JavaScript.” It’s written in Zig, and it ships a full toolchain with it: a bundler, a transpiler, a package manager, and a test runner. That design choice is more strategic than it looks.

If you’ve ever had to stitch together:

a bundler (or multiple build steps),
a package manager,
a test runner,
and a transpiler configuration

…you already know how quickly your “simple setup” becomes an ecosystem of scripts that all have their own version constraints and failure modes. Bun’s pitch is basically: stop duct-taping your dev workflow; let the runtime own the experience.

Concretely, that means you can start a project, install dependencies, bundle assets, and run tests without the usual ceremony. It’s the difference between buying a car and assembling one from parts labeled “engine (probably), wheels (maybe), and instructions (good luck).”

And yes—Bun’s benchmark numbers are hard to ignore. The point isn’t that benchmarks are a universal truth; it’s that they demonstrate an attention to performance that most developers now experience only indirectly through “wait, why is Node so slow in this one case?”

“Absurd benchmarks” and the more interesting question: what’s the tradeoff?

When people talk about Bun’s speed, they often jump straight to performance screenshots. That’s satisfying, but it misses the real conversation: how does Bun achieve these gains, and what does it cost you?

Here are the tradeoffs worth thinking about, especially if you’re considering Bun for real work:

Workflow coupling.
Bun’s bundler/transpiler/test runner are part of the runtime story. That’s great for convenience—but if you have specialized build tooling (custom Babel plugins, complex bundler pipelines, or internal tooling), you may need to validate compatibility early.
Ecosystem reality.
JavaScript libraries assume certain runtime behaviors. Most packages work everywhere, but “most” isn’t “guaranteed.” The practical approach is to pilot Bun on a non-critical service or a smaller app where you can surface incompatibilities quickly.
Operational confidence.
Speed is meaningless if deployment stability becomes a guessing game. You’ll want to run performance tests and failure-mode tests in your environment, not just in the blog post that made Bun look unbeatable.

My opinionated takeaway: don’t pick Bun because it’s faster in a benchmark. Pick it because it’s faster and it gives you an integrated workflow. Then confirm—measurably—that it behaves well with your dependencies and deployment model.

The ecosystem risk nobody wants to say out loud

Your biggest fear with three runtimes (Node, Deno, Bun) isn’t performance. It’s fragmentation. Code reuse is the real engine of developer productivity, and fragmentation is what happens when compatibility breaks in subtle ways.

The “implosion” scenario looks like this:

Frameworks add runtime-specific branches.
Tooling authors stop testing across all three.
Tutorials start to assume one runtime.
Bugs become hard to reproduce because they’re specific to one environment.
Teams end up with “works on my machine” that means “works on my runtime.”

But here’s the twist: fragmentation is also pressure. If Bun, Deno, and Node all have to satisfy serious users, that pressure can force ecosystems to become more consistent instead of less.

The key is how maintainers respond. If the community treats runtime differences like annoying edge cases—and builds libraries and tooling that are runtime-agnostic by default—fragmentation becomes manageable. If the community embraces per-runtime divergence as a feature, you’ll feel the pain.

My bet: Bun’s real contribution is forcing everyone to speed up

Bun’s success isn’t just measured in star counts or headlines. It’s measured in how quickly other parts of the JavaScript platform react.

Here’s what I think Bun is doing that matters most: it makes the “Node is fast enough” story harder to tell. Node is still the center of gravity, but now there’s a visible alternative that developers can try without asking for permission from their entire stack.

That creates incentives across the ecosystem:

Node maintainers accelerate optimization work because “fast enough” no longer holds up in public comparisons.
Tooling becomes more runtime-aware—which sounds scary, but often results in fewer assumptions and better portability.
Library authors tighten standards because every runtime that claims compliance becomes a test harness for sloppy behavior.

Deno gets dragged into this too, whether it wants to or not. Even if Bun wins users, the existence of multiple runtimes pushes everyone toward better conformance and clearer boundaries.

And the best part? When runtimes compete, end users win with faster installs, faster tests, quicker feedback loops, and fewer build-time mysteries.

Practical advice: how to evaluate Bun without gambling your project

If you want Bun’s benefits without taking reckless risks, do it like a grown-up: test it where it matters, before you bet the farm.

1) Start with a small but representative service

Pick something with:

real dependencies (including at least a couple from the ecosystem),
your typical build/test flow,
and a deployment path that resembles production.

If your app is tiny and dependency-free, you won’t learn anything meaningful.

2) Validate the “edge” behaviors you actually care about

Don’t stop at “it runs.” Check:

file system access patterns,
environment variables handling,
network calls,
worker/thread behavior (if you use it),
and your bundling strategy.

Your goal is confidence that the runtime works like your application expects—not just that the syntax parses.

3) Run performance tests against your bottlenecks

Benchmarks are abstractions. Your bottleneck is specific: maybe JSON serialization, maybe startup time, maybe test execution time, maybe bundling. Measure your pipeline with Bun and with your current runtime.

If Bun doesn’t improve the part you feel day-to-day, it may not be worth switching.

4) Watch ecosystem friction signals early

During evaluation, pay attention to:

dependency issues that appear only on Bun,
unclear errors that waste time,
and tooling gaps that force you into workarounds.

If you hit those, you can still use Bun—but you should decide whether you’re willing to carry the compatibility tax.

Conclusion: Bun isn’t a revolution—it’s a correction

Bun is the JavaScript runtime nobody asked for, and that’s precisely why it might be the one we desperately need. It’s not just another engine; it’s a push toward integrated developer workflows, sharper performance focus, and better cross-runtime discipline.

Will the JavaScript ecosystem fragment? It could. But competition also forces the opposite: shared standards, tighter tooling, and faster iteration everywhere. If you evaluate Bun with discipline—on representative workloads, with real dependencies—you can take the upside without courting chaos.

In other words: don’t worship the benchmarks. Use Bun as leverage. And watch the platform get better because of it.

The Developer Experience Gap Is the New Performance Gap

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 05 Jul 2022 00:00:00 +0000

Performance used to be the deciding factor. You could feel it: faster servers, lower latency, more throughput. But the world didn’t stop there—most teams now build on stacks where raw execution speed is “good enough.” What’s left as a differentiator isn’t the runtime. It’s the moment between your intention and your code doing something useful.

That gap has a name: developer experience (DX). And it’s no longer a nice-to-have. It’s the new performance gap—because DX governs how quickly you can think, test, fix, and ship. Teams that optimize for DX don’t just move faster; they produce fewer bugs, retain better engineers, and quietly build more reliable systems over time.

Why “Performance” Moved Down the Stack

A decade ago, swapping tech stacks could materially change user-facing performance. Today, for most applications, the core bottleneck is rarely “the language is slow.” It’s the human pipeline: build times, deploy friction, debugging loops, and how hard it is to reproduce issues.

Think about what actually slows teams down day-to-day:

Waiting for builds to finish just to see a tiny UI change
Spinning up local environments that don’t match production
Wrestling with database setup every time a new feature branch needs a test dataset
Duplicating configuration between machines, services, and environments
Losing time to “what changed?” because logs, tracing, and rollback workflows are too manual

At a certain point, performance becomes table stakes. DX is what determines whether engineering feels like momentum or like wrestling.

The DX Compounding Effect: Speed Multiplies Everything

Here’s the key idea: DX isn’t one metric—it’s a multiplier on every other metric you care about.

When your loop is tight, you iterate more. More iteration means:

More opportunities to catch bugs while they’re cheap to fix
Smaller pull requests (because you can test them sooner)
Better code review outcomes (because changes are easier to understand)
Faster onboarding (because tools behave predictably)
Higher morale (because “waiting” is a form of attrition)

A good DX improvement has the same shape as performance improvements: it compounds. If it takes you 15 seconds less to get from edit to feedback, and you run that loop dozens of times every day, you’re buying back real engineering time. Multiply it across a year and the “minor” seconds become dozens of working days.

And that’s before you count the second-order effects: fewer long-lived bugs, fewer broken merges, and fewer production incidents caused by rushed releases.

The Tooling Pattern: Instant Feedback, One-Command Setup, Push-to-Deploy

You don’t have to take DX on faith. Look at the tools that people adopt and stick with. They share patterns: faster feedback, less setup, and fewer manual steps.

Instant HMR: Vite and the Art of Staying in Flow

Hot Module Replacement (HMR) is deceptively powerful. It doesn’t just reduce build times—it reduces context switching.

With tools like Vite, your browser updates almost immediately as you change code. That changes the psychology of development:

You experiment more boldly
You refactor sooner instead of “later”
You trust the feedback loop enough to keep going

If your developers routinely say, “Let’s wait for the build,” you’ve already lost a measurable amount of throughput and quality.

Practical move: audit your feedback loop. Where does time go—type-checking, bundling, tests, linting, or environment startup? Optimize the loop that developers actually feel, not the one you can brag about in a benchmark.

One-Command Database: Turso and Environment Parity

Databases are where DX often goes to die. Every team has stories about “works on my machine,” migrations that don’t match, seed scripts that drift, and local schemas that are subtly broken.

A tool like Turso’s “one-command” setup pattern encourages parity: developers can spin up a usable database quickly and reliably. That means:

Feature branches can test against real-ish data
Integration testing becomes normal instead of exceptional
Bugs related to schema or data shape show up earlier

Practical move: treat local environment setup as a product. Make it reproducible, fast, and documented in the same place as your code. If new contributors can’t get to a working state in minutes, the system is pushing them toward errors.

Push-to-Deploy: Railway and the Removal of Release Drag

The fastest teams ship not because they have heroic release managers, but because releases aren’t painful.

Push-to-deploy platforms like Railway reduce the “release tax”—the time and attention cost required to deploy, configure, and verify changes. When deployment is easy:

Teams ship smaller changes more frequently
Rollbacks are less scary
Production feedback becomes part of the standard workflow, not a once-a-week scramble

Practical move: design your release workflow so the default path is safe. Automate environment configuration, make staging mirror production, and ensure every deploy has an observable outcome (logs, metrics, and a rollback plan).

DX as a Quality System, Not a Productivity Hack

The common mistake is thinking DX is about developer happiness alone. It’s not. DX is a quality system because it affects the kinds of decisions developers make under pressure.

When the loop is slow or unreliable, engineers compensate with shortcuts:

They skip tests or run only a subset
They batch changes into giant PRs
They avoid refactors because the risk feels too high
They rely on tribal knowledge rather than tooling

Conversely, when DX is strong, engineers do the “correct” things more often because the system makes them cheap:

Run tests frequently because they finish quickly
Create smaller PRs because feedback arrives sooner
Add observability because it’s easy to wire in
Debug locally because the environment is trustworthy

A striking sign of DX maturity is that your bug reports start to look different. Instead of vague issues like “it sometimes fails,” you get logs, reproduction steps, failing tests, and clear diffs. That’s not just engineering discipline—it’s the tooling enabling it.

How to Measure DX Without Reducing It to Hype

DX is often discussed vaguely—“it feels faster”—which is why it gets deprioritized. You need instrumentation.

Start with measurements that map directly to developer loops:

Time to first local run: from clone to working app
Time to feedback: edit → browser update, or edit → unit test results
Time to diagnose: how long it takes to identify the cause of a regression
Release cycle time: from merge to deployed and verified
Failure rates: flaky tests, broken builds, dependency drift, environment setup errors

Then connect those to outcomes you already care about:

Bug escape rate (production issues per release)
Mean time to resolution (MTTR)
Engineering throughput (cycle time, PR size, deployment frequency)
Retention signals (self-reported friction, churn reasons, onboarding satisfaction)

A practical approach: run a short “DX retro” with developers. Ask for three moments where they lose the most time, then quantify them. You’ll usually find the biggest wins are not flashy—they’re boring fixes: caching, better defaults, simpler local setup, faster test selection, and fewer manual steps.

Building Your DX Roadmap: Focus on the Bottlenecks That Hurt

If DX is the new performance gap, you should manage it like performance: find the bottleneck and remove it.

Here’s a roadmap that works across teams:

Measure the loop
Track time to feedback and time to diagnose. Baseline it before changing anything.
Optimize the “inner loop” first
Start with build/HMR/test speed. If developers wait for feedback, nothing else matters.
Make environments reproducible
One-command setup, consistent configuration, and predictable migrations beat complicated documentation.
Automate releases and verification
Push-to-deploy isn’t just convenience—it’s risk reduction through standardization.
Invest in observability for developers
When debugging is easy, fewer bugs slip through. Logs and traces that are actually usable are DX.
Close the loop with developer feedback
DX isn’t static. Treat it as a living system with regular improvements.

And be selective: a DX overhaul that chases every tool at once will turn into churn. The best DX work is incremental and targeted—each change should remove an obstacle developers hit every day.

Conclusion: DX Is the Real Competitive Advantage

Performance still matters, but it’s no longer the differentiator it once was. Most teams can run on “fast enough” infrastructure. The real edge is how quickly developers can go from idea to validated change—and how reliably the workflow supports quality.

Vite’s instant feedback, Turso’s streamlined local database setup, Railway’s push-to-deploy flow: these patterns win adoption because they reduce friction, not because they chase benchmarks. And the compounding effect is real. Better DX accelerates shipping, improves retention, and reduces the number of bugs that make it past your team’s gates.

If you want a competitive advantage, stop measuring only runtime. Measure the distance between a developer’s intent and a verified result. That gap is where the new performance lives.

GitHub Copilot Just Shipped, and Everything Is Different Now

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 29 Jun 2022 00:00:00 +0000

GitHub Copilot is finally out of the preview era, and if you’ve been watching from the sidelines, this is your moment: the “AI autocomplete” story was always incomplete. What just shipped is the first widely available, real pair programmer experience—and it’s both more useful and more dangerous than most teams are prepared for.

After months of using Copilot in preview mode, I’m convinced this is a genuine paradigm shift. It’s disturbingly good at boilerplate, surprisingly decent at algorithmic code, and absolutely unreliable when domain knowledge matters. The productivity gains are real, but uneven—and the downside lands hardest on the people least able to detect subtle wrongness.

What “Copilot GA” Really Changes

Copilot GA isn’t just a pricing or branding milestone. It changes how software gets drafted.

In the early days of developer tooling, automation usually targeted something mechanical: formatting, linting, scaffolding, code generation from schemas. Copilot targets something more conversational: it can propose an implementation based on the code around it and your intent (as text). That means the feedback loop tightens. You go from “write it yourself, then run tools” to “try, iterate, and correct in real time.”

Here’s what that looks like in practice:

You start with a function signature and a comment like “// Parse user input into a validated command.”
Copilot suggests a complete function with error handling and edge-case branches.
You accept most of it, tweak what’s obviously wrong, and move on.

For experienced developers, this feels like using a strong junior who’s fast and enthusiastic—except the junior has an uncanny talent for generating code that compiles, until the moment you discover it shouldn’t.

The Parts It Nails: Boilerplate and Mechanical Code

Let’s talk about where Copilot shines, because that’s where the ROI shows up immediately.

Copilot is excellent at repetitive patterns and conventional structure: CRUD handlers, DTOs, mapping layers, view models, migrations, pagination logic, and the glue code that turns one library into another. It’s also very good at “fill in the blanks” tasks where your project already provides a clear shape.

A concrete example: adding a new API endpoint.

You write the route and the handler stub.
Copilot generates request parsing, validation scaffolding, and the typical response wrapping.
You wire it to existing services and data access.

The value isn’t that Copilot “understands your product.” It’s that your product’s architecture is already in the codebase. Copilot can reflect that architecture back at you quickly—especially when the patterns are consistent.

This is why senior engineers benefit most. A senior can accept a large chunk of generated code while quickly spotting whether it matches the intended behavior. The tool reduces time spent on routine work; it doesn’t eliminate judgment.

The Parts It’s Good At: Algorithmic Code (Sometimes)

Copilot is also surprisingly capable when the task resembles a well-trodden problem: parsing, sorting, basic graph traversal, string processing, and standard data transformations.

For instance, if you prompt for a function like “implement a stable sort for a list of objects by priority,” it often produces a plausible implementation with the right edge handling. In many cases, it even uses appropriate data structures for the job.

But “plausible” is the operative word. Algorithmic code still has failure modes:

Off-by-one errors in indexes or loop bounds
Incorrect assumptions about input normalization
Silent behavior changes (e.g., treating nulls one way instead of another)
Performance surprises when you scale beyond the test fixture

Here’s the practical rule I’ve adopted: treat Copilot-generated algorithmic code like a draft written by someone who can follow instructions well, but can’t reliably infer the constraints you care about. If your system has invariants—like “inputs may contain Unicode combining characters” or “we must not allocate per request”—Copilot may miss them unless you spell them out.

The Parts It Fails: Domain Knowledge and Hidden Requirements

This is the part that matters most for safety: Copilot can be confidently wrong when domain knowledge is involved.

“Domain knowledge” doesn’t just mean business rules. It means everything you know about the system but that isn’t explicitly written as code:

Legal or compliance requirements
Security constraints (“never log secrets,” “authorization must be enforced before lookup”)
Data correctness rules that are only documented in tribal knowledge
Performance constraints tied to production realities
Compatibility expectations between services and data contracts

Copilot often struggles in those zones because the model doesn’t inherently know what’s sacred in your context. It fills in what looks right based on the surrounding patterns.

A classic example: authentication and authorization glue.

A tool may generate:

a decorator that checks a role,
a method that fetches a user record,
and a response wrapper,

but it might check the wrong field, skip an authorization step in a branch, or mis-handle “resource ownership” semantics. The result compiles and even passes superficial tests—until it doesn’t.

The real risk isn’t that Copilot “will replace developers.” It’s that developers—especially junior developers—may stop asking the questions that keep systems correct. When the code arrives already assembled, it’s easy to skip the interrogation.

How Seniors Should Use Copilot (and Why Jrs Need Guardrails)

If you’re a senior developer, you should treat Copilot like a co-pilot, not an autopilot.

My recommended workflow:

Use it for scaffolding and translation, not authority.
Generate boilerplate, adapters, and structure. Then own the behavior.
Demand explicit invariants.
If correctness depends on constraints, encode them in tests or in comments that Copilot can see and that reviewers can verify.
Refuse “accept-all” habits.
Don’t rubber-stamp the entire suggestion. Read it like you wrote it under time pressure.
Use diff-driven review.
When Copilot proposes a change, the only acceptable review is one that scrutinizes control flow, error handling, and side effects.

For junior developers, the danger is more subtle: Copilot can become a shortcut around fundamentals. When you’re learning, you need to build working mental models—of data flow, invariants, security boundaries, and failure handling. If the tool writes the code before you understand it, your learning becomes accidental.

So teams should implement guardrails that keep juniors productive without letting them bypass understanding:

Require unit tests for any Copilot-authored logic beyond trivial boilerplate.
Mandate review explanations: “What does this code assume? What happens on invalid inputs?”
Provide a style guide plus behavioral checklists (e.g., how to handle errors, how to validate input, what not to log).
Limit early access to Copilot for high-risk areas like authentication, billing, and data migrations—at least until competency is proven.

This isn’t about restricting creativity. It’s about making sure the shortcut doesn’t become a blindfold.

Practical Advice for Teams Shipping Faster Without Shipping Flawed Code

Copilot’s biggest advantage is speed—but speed without discipline is just faster failure. If you want to capture the productivity benefits without the downside, you need process changes that are boring in the best way.

Here’s a set of pragmatic moves:

Create “safe lanes” in your codebase.
For example: allow Copilot-generated changes in UI components, view models, and serialization layers with automated tests. Force manual scrutiny in security-critical modules.
Add targeted tests for the tricky parts.
Property-based tests can be especially helpful when Copilot might mishandle edge cases. Even a small suite that asserts invariants catches a lot.
Use static analysis as a backstop, not a substitute.
Linters and type checks help, but they won’t detect semantic flaws like “authorization performed too late.”
Adopt a review rubric that explicitly covers risk.
Your reviewer should check: input validation, error handling, security boundaries, performance assumptions, and logging hygiene.
Log what Copilot produces—then learn from it.
Keep an internal record of which Copilot suggestions were accepted, corrected, or rejected. Over time, you’ll learn where the model is reliably helpful in your stack.

The point isn’t to pretend Copilot is “bad.” It’s to stop treating it like an all-knowing collaborator. It’s a code generator with a remarkable ability to match the shape of your project. That can accelerate delivery—or accelerate mistakes—depending on how you steer it.

Conclusion: The Tool Isn’t the Threat—The Habits Are

GitHub Copilot GA is a real shift in how code gets written. It’s excellent for boilerplate, often competent for generic algorithmic tasks, and unreliable where domain knowledge and subtle invariants matter. The productivity gains are real, but uneven—and the biggest danger isn’t that it replaces developers.

It’s that teams accidentally replace learning with output. If you treat Copilot as a generator you must verify—and you build guardrails that keep junior engineers grounded in fundamentals—you’ll get faster without getting sloppy. Ignore that, and you’ll ship software that feels smooth right up until it breaks in ways nobody can explain.

Tailwind CSS: The Ugly Truth About Why It Works

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 19 Jun 2022 00:00:00 +0000

There’s a moment every front-end developer recognizes: you open a component, see a wall of class names, and feel your soul leave your body. Then—almost immediately—you start shipping faster. That’s the paradox of Tailwind CSS: aesthetically offensive, pragmatically brilliant, and weirdly aligned with how real teams actually build software.

Why Tailwind Looks Like It “Shouldn’t” Work

Let’s be honest: the default Tailwind experience is visually loud. The class attribute becomes a mini-program you’re forced to parse: flex justify-center items-center p-4 bg-blue-500. It’s not subtle, and it doesn’t pretend to be.

If you’re a CSS purist—someone who believes in clean separation, semantic naming, and “styles should live in CSS, not in markup”—Tailwind feels like a violation. The HTML stops being HTML and starts acting like a template for CSS rules. It’s aesthetically offensive, and not in an ironic, design-nerd way. More like: “Did we break the boundary between content and presentation?”

And yet, the ugliness is part of the point. Tailwind refuses to hide decisions behind names that mean nothing. It spells them out in the open, in plain view, right where the UI is defined.

The Real Reason Tailwind Works: It Makes Choices Cheap

The mainstream pitch for Tailwind is productivity: fewer context switches, less hand-written CSS, faster iteration. True, but incomplete. The deeper reason Tailwind works is structural: it makes design decisions cheap and reversible.

In a traditional workflow, you often “name the thing” before you style it. You create ButtonPrimary, then later ButtonPrimary:hover, then you discover you need a slightly different padding for a specific layout, so you either:

add another variant,
introduce a new component,
or tweak the existing one and hope you didn’t break something elsewhere.

That’s not just bureaucracy—it’s friction baked into the system. Tailwind flips the cost model. You can change spacing, alignment, or color in seconds without inventing a new semantic artifact for every tiny variation.

Concrete example: imagine a card layout.

Traditional approach: you define .card, .card-title, .card-body, .card--highlighted, and eventually you add more selectors when reality differs from the initial plan.
Tailwind approach: you describe the card where it lives: p-6 rounded-xl border bg-white shadow-sm, then optionally bg-blue-50 border-blue-200 for the highlighted state.

Yes, the class list grows. But the feedback loop gets dramatically tighter. You iterate against the actual UI, not against an abstract CSS taxonomy.

“It’s Just Classes” Isn’t the Point—Design Systems Are

Here’s the ugly truth behind Tailwind that most debates miss: Tailwind utilities aren’t the end state. They’re the raw material.

A real design system doesn’t aim to give developers infinite freedom. It constrains choices. Tailwind is most powerful when you configure it to encode your decisions—colors, spacing scale, typography, radii, shadows—so your “ugly” class strings become consistent with your brand.

For example, instead of relying on arbitrary values like bg-blue-500, you can set up semantic tokens in your Tailwind config (and then use them via the theme). You can enforce that buttons use a controlled palette, that spacing follows a scale your design team agreed on, and that components stay coherent.

And importantly: you don’t have to accept the full chaos of utility-first CSS. You can still create components when it’s beneficial. Tailwind encourages composition: use utilities for layout and specifics, and wrap repeated patterns into a component only when the pattern stabilizes.

Pragmatic rule of thumb: let utilities power the exploration; graduate to components when you’ve proven the shape.

Specificity Wars: Tailwind’s Quiet Superpower

One of the most underrated benefits of Tailwind is that it sidesteps the whole specificity drama. When styles live in dedicated CSS files and components stack on top of each other, you eventually hit the same familiar cliff:

some rule “should” apply but doesn’t,
another rule overrides it unexpectedly,
and now you’re reaching for !important or reorganizing selectors like it’s a hostage negotiation.

Tailwind’s utilities typically apply through a predictable class-based mechanism. You still have overrides, but you’re not constantly fighting your own stylesheet architecture.

This is especially valuable in real projects where multiple contributors touch the same components. Without a disciplined CSS strategy, “quick fixes” accumulate. Tailwind doesn’t magically remove design flaws, but it prevents the most common failure mode: dead CSS growing silently while layout breaks loudly.

A practical example: conditional styling for error states. With Tailwind you can keep the logic near the markup:

Normal: border-gray-300 text-gray-900
Error: border-red-500 text-red-700

Instead of adding selectors like .field.error .label and hoping nothing else overrides them, you switch classes based on state. The specificity problem simply doesn’t get a seat at the table.

Team Adoption: How to Keep Tailwind from Becoming a Mess

Tailwind works best when the team treats it like a system, not a free-for-all. Here are concrete ways to avoid the pitfalls—and yes, the “ugly HTML” complaint still matters, even if it’s not the whole story.

1) Adopt a class ordering convention.
When you see p-4 bg-blue-500 flex justify-center, your brain pays a tax every time. Decide on an order (layout → spacing → typography → colors → states), and stick to it. Tools like editor plugins can enforce sorting. The goal isn’t beauty for its own sake—it’s faster scanning and fewer mistakes.

2) Use components where repetition proves itself.
If the same utility combination appears in twenty places, it’s time to abstract. Don’t wait for “architecture purity”—wait for repetition. That’s how you avoid premature abstraction while still keeping the codebase sane.

3) Prefer semantic tokens over raw magic.
bg-blue-500 might be fine for a prototype. In a mature system, you want consistency and intent: “surface” and “primary” beat arbitrary shades. Configure your theme so your utilities reflect the product’s vocabulary.

4) Keep utilities for styling, not for logic.
Tailwind can tempt you to express complex decisions in long class lists. Use conditional class merging thoughtfully, and keep state logic readable. If your component’s class attribute becomes a novel, your UI logic is probably due for refactoring.

5) Don’t pretend it eliminates design work.
Tailwind doesn’t remove the hard parts of UI—accessibility, responsive behavior, interaction states, and visual hierarchy still matter. It just reduces the friction between design intent and implementation.

The “Dead CSS” Argument Is Real—and Tailwind Refuses to Lie About It

Traditional CSS workflows have a silent cost: styles accrete even after components are removed or redesigned. Even teams with good intentions end up with stale selectors, unused variables, and “maybe we still need it” code. Purging helps, but it’s often procedural and easy to postpone.

Tailwind flips the model. If a utility class isn’t used, it won’t matter. Your stylesheets are generated around what you actually reference. This directly addresses the fear that utility-first CSS creates noise. Tailwind doesn’t eliminate the need for discipline—it eliminates the need for constant housekeeping just to avoid CSS archaeology.

The result is practical: fewer leftovers, fewer surprises, and fewer moments where the UI looks wrong because someone forgot which CSS file is still doing something.

Conclusion: Ugly Markup, Beautiful Outcomes

Tailwind CSS doesn’t win because it’s pretty. It wins because it matches how development actually happens: fast iteration, shared components, shifting requirements, and teams that can’t afford endless specificity battles.

The real insight isn’t that you should sprinkle utilities everywhere forever. It’s that design systems should constrain choices, not enable infinite ones—and Tailwind gives you a framework to encode constraints directly into the tooling. Yes, the HTML looks like someone threw up. But the product ships, the code stays coherent, and the system scales. That’s the ugly truth—and the pragmatic brilliance underneath it.

Elixir Is the Best-Kept Secret in Web Development

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 12 Jun 2022 00:00:00 +0000

If you’ve ever watched your “simple” web app turn into a concurrency nightmare—mysterious timeouts, cascading failures, and heroic scaling efforts—you already know the problem: most web runtimes treat concurrency as an afterthought. Elixir doesn’t. It leans into concurrency as a first-class design principle, and the result is a stack that feels both modern and strangely inevitable.

This is why the BEAM VM (the engine behind Elixir and Erlang) keeps winning the same argument from different angles: lightweight concurrency, fault-tolerant architecture, and message passing that makes reliability easier—not harder. Meanwhile, the JavaScript and Python ecosystems keep papering over edge cases with more servers and more glue code.

The real reason you’re struggling with concurrency

Let’s name the thing everyone dances around: concurrency isn’t just “how many requests per second.” It’s how your system behaves when everything is happening at once—slow clients, intermittent network issues, timeouts in dependencies, retries, and partial failures.

In many stacks, the runtime gives you primitives (threads, async/await, event loops), and then your application code becomes the safety net. You end up implementing:

backpressure handling (usually late),
supervision logic (often as custom retry loops),
isolation between failures (rarely comprehensive),
and resource control (mostly via operational discipline).

So when the system degrades, you don’t get a clean failure. You get a feedback loop: one component slows down, queues grow, memory spikes, latency rises, and suddenly the entire service becomes “unavailable” even though most of it is still technically working.

Elixir’s approach is different: it’s designed for concurrency and failure as normal conditions, not exceptional ones.

BEAM’s concurrency model: processes, not promises

The BEAM VM runs your code with lightweight “processes” and a scheduler built for massive concurrency. These are not OS threads, and they’re not the same mental model as Node’s event loop or Python’s async tasks.

Here’s the practical distinction: you can structure your application around many independent processes that do one thing well, communicate by sending messages, and fail without taking down the world.

A concrete example: a connection-heavy web service

Imagine a WebSocket service that tracks presence, chat messages, and typing indicators. In a typical JavaScript implementation, you might end up with:

one large event loop coordinating everything,
shared state guarded by careful code discipline,
lots of “just do async” and “don’t block” rules,
and a web of try/catch, retry policies, and cleanup logic.

With BEAM/Elixir, you can model each connection as its own process. That gives you isolation by default:

If one client behaves badly, you can time out and terminate just that process.
If message handling for one connection crashes, supervisors can restart it cleanly.
If a downstream dependency hiccups, the rest of the system continues.

And because message passing is built into the runtime model, you don’t need to invent a concurrency strategy from scratch. You write processes and define what happens when they fail. The VM does the scheduling and the heavy lifting.

This is why concurrency discussions in other ecosystems often feel like they’re chasing a moving target. BEAM started with concurrency as the foundation. Everything else was layered later.

Supervision trees: reliability you can actually reason about

Fault tolerance in many runtimes is reactive. You detect failure, log it, and hope it doesn’t cascade. In the BEAM world, fault tolerance is explicit and structured.

Elixir’s supervision trees are a hierarchy of processes where parents oversee children. If a child process crashes, the supervisor decides what to do: restart it, escalate, or shut down a branch.

That sounds like an implementation detail—until you watch what it does to operational reality.

Practical payoff: stop “unknown state” incidents

A common production horror story looks like this:

A background job crashes halfway through a workflow.
Some in-memory state is now inconsistent.
Subsequent retries either fail again or, worse, corrupt more state.
The only safe fix is manual intervention.

With supervision, you can design systems so that crashing is survivable. For example:

Your connection process can crash and restart without leaving phantom subscriptions.
Your worker can restart from a known baseline (or fetch state from a datastore) rather than continuing in a half-broken memory state.
Your supervisors can apply backoff strategies when dependencies are unhealthy.

The key idea is not “fail less.” It’s “fail in a way that your architecture expects.”

Phoenix delivers Rails-like velocity, but keeps the reliability spine

Elixir is only half the story. Phoenix is where it becomes a product-building machine.

Phoenix gives you an approach that feels familiar if you’ve built with Rails: a cohesive framework, conventions, and a clear path from controller to template to channel. You get productivity without surrendering the runtime advantages that come from BEAM’s concurrency model.

Consider real-time features. Phoenix Channels let you implement WebSockets and long-lived connections without turning your codebase into a tangle of ad-hoc event handlers. You can build chat, notifications, dashboards, and collaborative experiences with the same disciplined process model—because the framework and runtime are designed to cooperate.

And because Phoenix is built around Elixir’s concurrency primitives, you don’t have to contort your application architecture to “fit” the runtime. You simply build the way BEAM wants you to build.

“Two million connections” isn’t the point—predictable behavior is

It’s tempting to lead with headline performance claims, but the more important takeaway is predictability under load.

When people say Elixir can handle massive concurrency “without breaking a sweat,” what they usually mean is this:

the system continues to respond under pressure,
failures remain contained,
and resource usage doesn’t turn chaotic in the same way that often happens in less structured concurrency models.

In other words, you’re not just buying throughput. You’re buying control.

A practical rule of thumb

In ecosystems that rely heavily on shared event loops and async glue, you can often “get away with it” until you hit the wrong combination of:

slow clients,
burst traffic,
and downstream latency.

Elixir’s model pushes you toward isolation and explicit recovery. That means you don’t just scale horizontally—you scale safely, because the failure modes are governed by design, not luck.

The adoption problem is cultural, not technical

Let’s be blunt: Elixir isn’t less popular because it’s hard. It’s less popular because the industry has trained itself to distrust anything that doesn’t look like it already knows how to work.

There’s a persistent bias for curly braces, a preference for tooling that matches existing workflows, and a tendency to treat unfamiliar languages as “niche experiments.” That’s not a technical argument; it’s an inertia problem.

Elixir is modern, pragmatic, and deeply engineering-oriented:

Functional programming without turning everything into academic puzzles.
A framework that emphasizes real-world application needs.
Runtime behavior designed for reliability, not just speed.

If your team can learn how to build with Elixir once, the architecture tends to become the kind of “default good taste” that prevents whole categories of production failures.

Conclusion: stop papering over concurrency—embrace it

Elixir’s best-kept-secret value isn’t that it can out-benchmark your stack on a chart. It’s that BEAM treats concurrency and failure as foundational concerns rather than afterthoughts.

Phoenix then makes that runtime advantage practical: you can build real web apps—controllers, templates, channels, background work—with a framework that rewards disciplined architecture. And the biggest win? You spend less time firefighting because your system is structured to recover.

If your current stack feels like it’s scaling by duct tape, Elixir is the rare alternative that doesn’t just add more features—it changes the shape of reliability itself.

PostgreSQL Won the Database War While Nobody Was Watching

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 07 Jun 2022 00:00:00 +0000

For years, developers watched database headlines like sports—Mongo this, NewSQL that, graphs everywhere, streams always. Meanwhile, one unglamorous workhorse quietly kept showing up in production, powering dashboards, APIs, admin panels, and “just one more feature” workflows. PostgreSQL didn’t win with drama. It won with taste, reliability, and the kind of tooling that makes you forget you’re using a database at all.

The real “war”: friction, not features

Most database debates aren’t about raw capability. They’re about friction—how quickly you can ship, how safely you can change, and how much pain you’ll feel when the product inevitably grows teeth.

PostgreSQL won because it handles the boring stuff extremely well:

Correctness under pressure: transactions, constraints, and consistent query behavior aren’t optional when your business logic has edge cases.
A sane query language: SQL is expressive enough to model real problems without turning your app into a data-munging Rube Goldberg machine.
Operational maturity: backups, migrations, monitoring, and failure recovery are not “enterprise-only fantasies.”

NoSQL hype promised escape from relational rigidity. What teams actually needed was escape from operational chaos. PostgreSQL gave them that—and did it without asking them to rewrite everything into a new mental model.

A practical example: imagine you’re building a billing system. You don’t want “eventually consistent” charges that get reconciled later by a nightly job you don’t fully trust. You want atomic updates, constraints, and queries that can answer questions like, “Show me customers whose invoice totals don’t match payments due to refunds within the last 30 days.” That’s the relational sweet spot.

The trap in the NoSQL story: you still need relationships

MongoDB (and other document databases) did something important: they made “schema” feel optional and made it easy to store JSON-like documents. That lowered the barrier to building prototypes fast—especially for teams that were already living in JavaScript objects.

But production has a way of demanding structure. Over time, applications discover that they need:

joins (even if they’re inconvenient),
referential integrity (even if it’s “later”),
complex filtering across entities,
and consistency guarantees when money or permissions are involved.

PostgreSQL absorbed the best parts of the modern web without abandoning relational discipline. JSON support means you can keep the flexibility you want. Relational modeling means you don’t paint yourself into a corner when “flexible” starts to mean “ambiguous.”

And for many teams, that’s the key takeaway: PostgreSQL isn’t a relic of old databases. It’s the database that lets you postpone schema decisions without permanently surrendering the ability to reason about data.

Postgres covers the messiest 90%—and then gets out of the way

If you’ve ever built an application that started simple and ended up with a web of requirements—search, filters, locations, analytics, background jobs—you know the “single database” fantasy rarely survives contact with stakeholders.

PostgreSQL’s advantage is that it can grow with you inside one system. Instead of introducing new infrastructure every time you hit a capability gap, Postgres has a growing set of built-in features and extensions that keep the stack coherent.

Here are a few common requirements and how Postgres handles them without ceremony:

JSON without losing query power

You can store semi-structured data in jsonb and still query it efficiently. In real projects, this often looks like: store user metadata, feature flags, or third-party payloads as JSON, then index the parts you actually filter on.

Instead of “everything is a document and we hope,” you get “we store the flexible stuff, and we still know how to ask questions.”

Full-text search that doesn’t feel like a separate universe

Postgres can handle search use cases without immediately pulling in a separate search engine. You can implement keyword search, ranking, and text normalization in ways that integrate cleanly with your relational data.

A good pattern: keep your core records in Postgres, and only escalate to a dedicated search platform when you truly need advanced relevance tuning or massive scale.

Geospatial queries that work with your data model

If your product has locations—delivery zones, user proximity, asset tracking—PostGIS turns Postgres into a geospatial powerhouse. Crucially, it keeps your location data tied to the rest of your domain: permissions, ownership, time windows, status transitions.

The “just one more feature” effect

Most teams don’t die from missing features. They die from feature sprawl. When your database strategy forces you to split state across multiple systems, every new requirement becomes a distributed-systems problem.

PostgreSQL makes it easier to stay focused on product work instead of infrastructure glue.

The extension ecosystem: Postgres as a platform, not a product

The modern Postgres story isn’t “here’s a database.” It’s “here’s a platform.” That might sound like marketing, but in practice it changes how teams design systems.

When your needs expand—from time-series metrics to embeddings for AI features—Postgres can often extend rather than replace.

Some of the most practical examples:

PostGIS for geospatial data and queries.
TimescaleDB for time-series patterns like rollups, retention policies, and efficient queries over time-bounded windows.
pg_vector for vector similarity search, letting you bring embeddings into the same database that already owns your user and permission data.

Here’s why that matters: when you move everything into one consistent data store, you reduce the number of sources of truth. Your application logic becomes simpler because data retrieval is consistent and transactional where it matters.

Even if you still use other systems (caches, message queues, dedicated analytics warehouses), you avoid turning your core domain model into a patchwork.

A concrete design tip: if you’re building something AI-adjacent, store the canonical entity data in Postgres, store embeddings in Postgres via a vector extension, and only add a specialized vector database if you outgrow your query patterns. Start with fewer moving parts. Upgrade when you have evidence, not vibes.

Why developers kept coming back: SQL beats rewrites

The hype cycles always sell a version of the dream: “Reimagine your data model from scratch.” And sometimes that works—especially for products that are tightly scoped or whose domain is inherently document-structured.

But for most software teams, rewriting is the real cost. It’s not the database choice at day one. It’s the migration pain at day 600, when requirements are entrenched and institutional knowledge lives in production code.

SQL also has an underrated advantage: it scales across teams. Querying data is something you can teach, review, and audit. You can reason about it with plain text. You can introspect the schema. You can validate assumptions.

PostgreSQL’s strongest feature may be its pragmatism. It’s a database that doesn’t demand ideology. If you want relational integrity, it’s there. If you want JSON flexibility, it’s there. If you want full-text search or geospatial queries, it’s there. And if you want new capabilities, the extension ecosystem often meets you halfway.

The result is the “quiet victory” you can feel in teams: fewer database debates, more shipping, and fewer late-night incidents caused by mismatched persistence assumptions.

Conclusion: the quiet win is the best kind

PostgreSQL didn’t conquer the database war by being loud. It conquered it by being useful—again and again—across the messy reality of application development.

If you’re choosing a database today, don’t treat Postgres as a default because it’s old. Treat it as a default because it’s complete: relational rigor with modern flexibility, powerful built-ins, and extensions that turn it into a real data platform. In a world obsessed with the next thing, that kind of stability is rare—and worth paying attention to.

Vim Motions Changed How I Think About Text Editing

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 26 May 2022 00:00:00 +0000

I didn’t “learn Vim” so much as I discovered a different way to talk to my editor. For fifteen years I used conventional shortcuts—Ctrl+X here, Ctrl+F there—without ever feeling in control of the structure of my text. Then I started using Vim motions, and suddenly every change I made felt less like hunting and pecking and more like composing a sentence. The mouse still works, but now it feels like writing with mittens on.

And no, you don’t need to ditch VS Code or switch to Neovim to get the benefit. What you need is the grammar of modal editing: verbs that define intent (yank, delete, change) combined with nouns that define scope (word, paragraph, matching bracket). Learn that grammar, and your editing becomes fast in the specific way that only composable tools feel fast.

The moment it stopped being “shortcuts” and became “language”

Most editors teach you keystrokes as a set of tricks. “Press Ctrl+Shift+L to select multiple cursors,” “Use Alt+Click to add cursors,” “Hit Ctrl+K, Ctrl+C to comment.” Useful, but still mostly procedural: do this, then that, then maybe a third thing.

Vim is different. Modal editing flips the model from actions to commands. In normal mode, you don’t “manipulate” text; you request transformations in a compact syntax:

Verb: what you want to do (yank, delete, change, etc.)
Noun: what you want to affect (word, line, paragraph, block, bracketed text, etc.)
Optional modifiers: how precisely you mean it (counts like 3, motions like f/t, and text objects)

Once you start thinking in those terms, your brain stops asking “what’s the shortcut?” and starts asking “what’s the unit of text I intend to operate on?” That shift is the real turbo mode.

The simplest way to understand Vim motions is this: normal mode is for navigating and transforming, insert mode is for writing, and every key press is categorized.

In conventional editors, the same key might both navigate and edit depending on timing or focus state. That’s one reason keyboard-driven editing can feel chaotic—your hands are constantly negotiating context.

Vim resolves that by making state explicit:

Normal mode: commands like dw, ci(, yip, ggVG
Insert mode: you’re literally typing
Visual mode: you’re selecting something to operate on

A practical example: imagine you’re editing a function and want to replace the argument list.

In a traditional workflow you might: select, delete, retype, and then carefully re-check commas and spacing.

In Vim grammar, you can do something like:

ci( — change inside the parentheses

Even without deep knowledge of Vim, the intent is readable. You’re telling the editor: target the argument region, and replace it. Your eyes can stay on the structure; your fingers don’t have to “search for the right selection behavior.”

The core “grammar”: verb + noun (with real examples)

If you take nothing else from Vim motions, take this: the most productive commands are built from reusable parts.

Verbs you’ll use constantly

y = yank (copy)
d = delete
c = change (delete and enter insert mode)
> / < = indent shift
= = re-indent a region (handy when formatting drifts)

Nouns (targets) that map to how humans think

w = word
W = WORD (big, space-delimited)
s / p = sentence / paragraph
(, {, [, < = matching bracketed expressions
i / a text objects: inside vs around (more on this next)

Two examples that show the pattern

Delete a word

dw: delete from the cursor to the start of the next word
This turns “remove the next word” into a single, repeatable instruction.

Change inside braces

ci{ (or more generally ci{ after a cursor near {)
You’re not selecting manually. You’re declaring the semantic boundary: inside the braces.

Here’s the mental advantage: the command reads like a plan. Once you internalize that, you stop fighting the selection tool and start steering the document.

Text objects: the superpower you’ll feel after a few days

Navigation motions get you to places. Text objects let you grab meaningful chunks without measuring by hand.

The classic pair is:

i = inside
a = around

So:

iw / aw = inside/around a word
ip / ap = inside/around a paragraph
i( / a( = inside/around parentheses
i{ / a{ = inside/around braces

A concrete scenario: you’re refactoring a config file and need to swap a JSON value that sits between braces. You don’t want to highlight a range by eye and risk including or excluding quotes and commas. Instead, you can:

move the cursor somewhere within the target region
use a text object to define the boundary
apply a verb: ci{ to replace, di{ to remove, or yi{ to copy

This is where the “turbo mode” feeling really kicks in: you’re not spending time micromanaging the edit region. You’re describing it.

“Just learn the grammar”: a practical two-week ramp

You don’t need to memorize the entire keymap. You need a small set of moves that let you build confidence, then expand.

Here’s a sane two-week approach that matches how people actually learn:

Days 1–3: learn verbs + motions that map to your muscle memory

Pick a few everyday actions you already do:

delete a word (dw)
yank a word (yw)
change a word (cw)
move by word (w / b)

Practice with tiny edits in a scratch buffer or a real file you’re already touching. The goal is to stop thinking about “shortcuts” and start thinking “word boundaries, sentence boundaries, block boundaries.”

Days 4–7: add text objects

Introduce just one family:

i( and a( for parentheses
i{ and a{ for braces
ip for paragraphs (great for prose and comments)

Then practice a single loop: replace something inside a structure. If you can do that confidently, your editing strategy will start to change immediately.

Days 8–14: build a small repertoire of repeatable commands

Add:

. to repeat the last change (this alone can feel like cheating)
dd for deleting a line
yy for yanking a line
selection via Visual mode for when you need “human judgment” rather than grammar

You’ll feel slow early on. That’s normal. After a week, you’ll start issuing commands almost without looking at the keys. After two weeks, the mouse will become optional—not because you’re stubborn, but because the keyboard finally has a coherent system.

You can start in VS Code with a Vim-style extension—no ideology required

If your current setup is VS Code, you can get 90% of the benefit without religiously switching editors. Install a Vim extension in VS Code and treat it like a training regimen.

Important advice: don’t wait for “perfect Vim.” Use the extension on tasks where you edit text repeatedly—code review, logs, refactors, documentation. When you hit a command you don’t know, don’t quit. Look it up, try it once, and move on.

Two weeks is realistic because you’re not learning “Vim as an identity.” You’re learning a language for editing: verbs and nouns, composable targets, and a reliable state machine (normal vs insert vs visual).

Conclusion: once you think in commands, the mouse feels clumsy

Vim motions didn’t just make me faster—they changed how I frame the act of editing. Instead of selecting regions and hoping I got the boundary right, I started describing transformations: delete this unit, change that structure, yank this block. That’s why the mouse suddenly feels like writing with mittens on. It’s not that it’s bad; it’s that it’s no longer the most natural way to express intent.

Give it two weeks. Learn the grammar—verbs, nouns, and text objects—and watch your text editing stop being a grab-bag of shortcuts and start behaving like composition.

Every Developer Should Understand Observability (Not Just Monitoring)

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 14 May 2022 00:00:00 +0000

You can’t reliably fix what you can’t explain. Monitoring may light up a dashboard when your system is in trouble, but observability is what lets you answer the real question: why did it break, where did it start, and what changed? In modern production systems—especially distributed ones—understanding observability isn’t optional. It’s core engineering literacy.

Monitoring vs. Observability: Two Different Answers to Two Different Questions

Monitoring and observability often get lumped together, but they solve different problems.

Monitoring is proactive detection. You set thresholds (“CPU > 90%,” “error rate > 1%,” “P99 latency > 500ms”) and alert when something crosses them. This is valuable, but it’s inherently reactive and limited: monitoring tells you that you have an issue, not why.

Observability is about diagnostic capability. You instrument your system so that, when something goes wrong, you can ask arbitrary questions—questions you didn’t pre-plan—using the data you already emitted. Instead of building one dashboard per incident, you build a system of signals that can be queried to reconstruct causality.

A useful mental model: monitoring answers “Are we broken?” Observability answers “What’s broken and why?” When teams say they “moved to observability,” what they usually mean is: they stopped treating telemetry as a checklist and started treating it as an investigative tool.

The Three Lenses: Logs, Metrics, and Traces—One System, Different Views

Logs, metrics, and traces are often presented as three separate stacks. In practice, they’re three lenses on the same runtime behavior. Treating them as one correlated system is the difference between “we have dashboards” and “we can explain production.”

Logs: Context and narrative

Logs are your detailed narrative—events in time order. The key is to make logs structured and queryable, not just “human-readable text dumped to stdout.”

A structured log line might look like this conceptually:

service.name: checkout-api
user.id: 12345
correlation_id: b7f8...
event: payment_authorization_failed
error.code: card_declined
duration_ms: 42

Without structure, you end up grepping through noise during an incident. With structure—and consistent fields—you can slice logs by correlation IDs, service boundaries, error codes, and time windows.

Metrics: Quantities you can slice

Metrics summarize behavior over time. They’re excellent for trend detection and for measuring performance characteristics like latency distributions and saturation (CPU, memory, queue depth).

The trap is cardinality—labels with too many unique values (like raw user IDs or request IDs) can explode cost and overwhelm your time-series database. The practical rule: labels should represent dimensions of analysis, not raw identifiers.

Use labels like:

route: /checkout
dependency: payment-gateway
status_code: 200|400|500
region: us-east-1

Avoid labels like:

request_id: unique per request (unless you’re using it carefully in limited contexts)
user_id: unbounded

Traces: Causality across boundaries

Traces are the glue for distributed systems. A trace represents a single request (or workflow) flowing across services, with spans for each hop. Traces let you see where time is spent, where errors originate, and how dependencies behave.

The critical point: traces are most powerful when they’re connected to logs and metrics via shared identifiers (especially correlation IDs / trace IDs).

Instrumentation That Actually Helps: Correlation IDs and OpenTelemetry

If you want observability that can answer “why,” you need consistent instrumentation. That means two things:

Propagate context across services
Emit data in compatible formats with consistent fields

Start with correlation IDs

A correlation ID is the simplest “thread” you can follow end-to-end. In an HTTP request, you can generate a correlation ID at the edge, include it in response headers, and propagate it to downstream calls.

In practice:

If you’re behind an API gateway or load balancer, inject the correlation ID there.
In your application, read the incoming header (if present) and set it on outgoing requests.
Make sure every log line includes it.

Then adopt distributed tracing (OpenTelemetry)

Distributed tracing becomes real when it’s standardized and automatically handled at scale. OpenTelemetry gives you a common way to:

create spans
capture timing and errors
propagate trace context between services

A strong implementation pattern looks like this:

Each incoming request creates a root span.
Each outbound dependency call becomes a child span.
Errors are recorded on the span with meaningful attributes.
Your exporter ships traces to your tracing backend.

The best part? Once you have trace IDs in your logs and trace summaries in your tracing UI, you can pivot instantly:

“This request is slow” → “Show me the trace” → “Which span was slow?” → “Open related logs for that span.”

Cardinality, Sampling, and the Reality of Production Costs

Observability isn’t free. Good systems engineering includes constraints and trade-offs.

Cardinality rules your budget

If you label metrics with overly specific identifiers, you’ll pay in storage, query performance, and cost. Even worse, developers stop using the metrics because results are unreliable or expensive to query.

Practical advice:

Prefer enums with bounded values (status_code, region, route)
Bucket dimensions (e.g., latency buckets, not raw durations)
For high-cardinality fields, move them to logs or traces where they belong

Sampling isn’t a compromise—it’s a strategy

You generally can’t trace every request forever. Sampling controls volume. But sampling done blindly can make incidents harder to debug.

Better approaches:

Head-based sampling: choose a sample rate and accept that you’ll miss some traces.
Tail-based sampling (where supported): keep traces that match “interesting” criteria (errors, high latency).
Dynamic sampling policies: increase sampling when incidents start or when error rates spike.

The goal is to preserve the ability to answer why during failures. During normal periods, you can sample more aggressively.

Treat telemetry like product code

Observability instrumentation changes over time. Add fields carefully. Deprecate old ones. Ensure that changes don’t break your correlation strategy. A common failure mode is “instrumentation drift,” where one service starts emitting different attribute names and suddenly dashboards and trace searches stop working.

How Developers Use Observability During Real Incidents

This is where observability earns its keep. Consider a scenario that monitoring catches quickly:

Alerts fire for “P99 latency increased” last Tuesday.
Error rates may or may not be elevated.
You need a root cause fast.

With a mature observability setup, your investigation might look like this:

Confirm the scope
- Use metrics to pinpoint the affected service and route.
- Break down latency by region and dependency.
- You discover, for example, that only /checkout in eu-west-1 is impacted.
Find the failing dependency
- Compare latency metrics labeled by dependency (e.g., payment-gateway).
- If the dependency latency spikes, your suspicion narrows quickly.
Pivot to traces
- Filter traces by trace_id (from logs) or by time window and service attributes.
- Identify a span with long duration and check error tags.
- You might see payment-gateway > auth_request consistently taking longer during the incident window.
Read the logs behind the spans
- Open logs correlated to a representative trace.
- Look for structured attributes like error.code, retry_count, timeout_ms, or circuit breaker state.
- You may discover the gateway started throttling and your client retried until a timeout.
Turn the story into action
- Implement backoff/jitter or circuit breaker tuning.
- Adjust request timeouts based on observed dependency behavior.
- Add targeted dashboards for the exact attribute you used to debug (“throttling response code,” “retries,” “timeout_ms buckets”).

Notice what’s happening: you aren’t just reading one chart. You’re reconstructing causality across the system using correlated signals.

Building an Observability Stack Your Team Will Actually Use

The temptation is to “set up tools” and assume the value follows. It won’t. The real work is aligning instrumentation, naming, and developer workflows.

Define the fields that matter

Agree on conventions for:

service.name
environment (prod/staging)
route or operation
correlation_id / trace_id
error.code
dependency.name

Make sure every team uses the same names so queries don’t become archaeology.

Make it easy to pivot

Your tooling should support the same flow every time:

click from a metric spike to traces
click from a trace to logs for a specific span
use shared IDs to avoid manual searching

If this pivoting isn’t smooth, people will fall back to guesswork.

Start small, then deepen

You don’t need perfect coverage everywhere on day one. You need coverage where it counts:

critical request paths
high-impact dependencies
services with known latency or reliability risk

Then iterate. The second biggest observability mistake (after missing correlation) is stopping too early.

Conclusion: Observability Is Developer Power

Monitoring tells you when something is broken. Observability tells you how it broke, where it started, and what to change next. When logs, metrics, and traces work as three lenses on the same system—connected by correlation IDs and standardized by OpenTelemetry—you gain the ability to ask arbitrary questions about production, not just respond to pre-written alerts.

If you can’t explain why your P99 spiked last Tuesday, you don’t need “more dashboards.” You need better instrumentation and correlated signals. That’s a developer competency—so build it, own it, and make it part of how you ship.

Why Every Team Should Have a Developer Platform

abdecastro@protonmail.com (Antonio B De Castro) — Sun, 08 May 2022 00:00:00 +0000

Your engineers don’t actually spend their time “building software.” They spend their time coordinating—waiting for environments, chasing failing CI jobs, guessing which deployment steps belong to which service, and rediscovering tribal knowledge that lives only in Slack threads. A developer platform turns that chaos into a reliable workflow. Not because it’s fashionable, but because it’s the clearest lever you have to move from 1x delivery to 10x.

The real bottleneck isn’t talent—it’s friction

In high-performing orgs, the difference isn’t that developers are smarter. It’s that the path from idea to production is short, predictable, and repeatable.

Think about the typical “day in the life” of a modern engineering team:

A developer writes code, but can’t run it locally the same way it will run in production.
CI runs, but failing jobs are hard to interpret or fix without paging someone from infrastructure.
Environments are scarce, manually provisioned, and often outdated.
Deployments require a checklist, a credential bundle, and a careful sequence of commands that only some team members remember.
Rollbacks involve panic and coordination, because the process varies by service.

This isn’t just inconvenience. It’s compounding delay. Every hour of friction shifts engineering effort away from product work and toward operational babysitting. Over time, velocity drops, confidence erodes, and delivery becomes a series of controlled burns rather than a pipeline.

A developer platform attacks the problem at the source: it removes repeatable toil and turns operational complexity into paved roads.

What an internal developer platform actually includes

“Developer platform” can sound like an abstract ambition. In practice, it’s a set of pragmatic capabilities that make engineering safer and faster:

CI/CD standards and automation
- Opinionated pipelines (or templates) that run tests, build artifacts, scan for issues, and publish deployable outputs consistently.
- Clear failure messages and fast feedback loops.
Environment provisioning
- Automated creation of dev/staging/test environments with sensible defaults.
- Clean teardown to prevent environment sprawl.
- Ideally, preview environments for branches so validation happens before merges.
Service catalog and templates
- A registry of services, ownership, supported runtimes, and integration patterns.
- Templates that generate new services or scaffolding with correct conventions.
Deployment abstractions
- A consistent deployment interface (not a different ritual per repo).
- Rollouts, rollbacks, and release tracking that don’t depend on who happens to be online.
- Guardrails—like required health checks and safe concurrency settings—baked into the workflow.
Observability and operational hooks
- Standard dashboards and alerting for new services.
- Logs/metrics/traces wired by default.
- Links from the developer workflow to the operational evidence they’ll need.

If you’re wondering whether this is “too much,” ask a simpler question: do your engineers repeatedly do the same operational steps for each service? If yes, that’s exactly where a platform pays off.

The moment you feel the difference: day-one deployment

The most persuasive argument for a developer platform is not a theoretical model—it’s the lived experience of onboarding.

Here’s the common reality today: a new hire can deploy on day one only if they already know the org’s operational rituals. Otherwise, they spend their first weeks waiting for accounts, learning undocumented conventions, and coordinating access to environments.

With a developer platform, the promise changes:

The onboarding flow includes a service template and a working pipeline.
Environments are provisioned automatically using a documented request or self-service button.
The deployment path is consistent, so a new team member isn’t learning a new deployment language for every repo.

This is where the “10x vs 1x” framing holds up. You don’t need every engineer to be heroic. You need every engineer—especially new ones—to be unblocked quickly.

Backstage by Spotify became popular as a starting point for a reason: it’s a practical framework for building developer portals and service catalogs. You can adopt it as a foundation, then incrementally add integrations that match how your org works. The goal isn’t to install a tool. It’s to standardize the workflow.

Concrete examples of platform features that cut real work

Let’s make this tangible. What do these capabilities look like in day-to-day engineering?

Example 1: Branch preview environments that actually help

Instead of “staging is shared, and it’s always broken,” your pipeline spins up a short-lived preview environment per pull request. Developers can:

run integration tests against a real deployment,
share a stable URL with product and QA,
validate configuration changes early.

Practical advice: start with one runtime (say, Node or Python), one deployment target (one cluster), and one naming convention. The platform should feel “boringly reliable” before you expand.

Example 2: A deployment command that never surprises you

Imagine a single interface like deploy <service> <env>. Under the hood, it uses the platform’s deployment controller, enforces required checks, and records release metadata. A developer shouldn’t need to remember:

which CI artifact to promote,
which secrets to attach,
what manual step is required for blue/green.

Practical advice: standardize around artifact promotion and environment config management. Even partial standardization reduces cognitive load.

Example 3: Service catalog with ownership and integration info

A service is more than a repository. The platform’s catalog includes:

owners (and on-call escalation paths),
runtime and version constraints,
downstream dependencies,
standard dashboards.

When something breaks, developers don’t start with “where does this run?” They start with “here’s where it runs and who owns it.”

Practical advice: treat the catalog as living documentation. Make updates required in PR workflows when service metadata changes.

Example 4: Built-in quality gates in CI/CD

If every pipeline is slightly different, teams learn to treat CI as a roulette wheel. A platform enforces consistent gates:

unit and integration tests,
dependency scanning,
security checks,
artifact signing (if you use it),
deterministic build outputs.

Practical advice: don’t boil the ocean. Define a minimum standard pipeline that every service must adopt, then progressively add checks based on risk.

The operational truth: platforms turn expertise into leverage

A common pushback is: “We already have infrastructure experts. Why build a platform?”

Because the experts shouldn’t have to be the bottleneck.

In many orgs, operations knowledge is stored in:

tribal memory,
scattered runbooks,
one-off scripts,
personal expertise.

A platform codifies that knowledge into tooling and interfaces. It doesn’t eliminate ops; it changes ops from reactive “helpdesk mode” to proactive “systems design mode.”

The team that owns the platform should be measured by outcomes like:

reduced deployment lead time,
fewer environment-related incidents,
faster onboarding,
fewer CI escalations,
higher deployment frequency without increased risk.

Those metrics only matter if engineers feel the improvement directly. If the platform makes it harder, not easier, developers will route around it—and you’ll be back to Slack archaeology.

How to build a platform without stalling the business

A platform program can fail for one reason: it becomes a multi-quarter replatforming project with no immediate value. The winning approach is incremental and tightly scoped.

Start with one workflow that hurts today—then automate it end-to-end:

Pick a single pain point with clear impact:
- environment provisioning,
- deployment steps,
- CI reliability,
- service template creation.
Deliver a thin “happy path”:
- new service scaffold + working pipeline,
- deploy to dev automatically,
- logs/metrics wired by default.
Add guardrails:
- consistent health checks,
- standardized rollout strategy,
- permissions and secret handling.
Expand coverage:
- more runtimes,
- more environments,
- richer catalog metadata.

If you’re using Backstage, treat it as the interface layer: a place to discover services, provision environments, and trigger workflows. Then wire in the actual automation behind the scenes. The portal is not the platform—the workflows are.

Conclusion: Speed is a system, not a personality

Fast engineering isn’t an accident of hiring. It’s an outcome of how much friction exists between code and production. Internal developer platforms eliminate the repetitive glue work—CI/CD orchestration, environment provisioning, service discovery, and deployment complexity—so engineers can spend their time shipping product, not negotiating processes.

Build the platform one valuable workflow at a time. The payoff arrives quickly: the first new hire who deploys to production on day one, and the last time you have to explain to someone how to “do it the old way.”

The Unreasonable Effectiveness of SQLite

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 02 May 2022 00:00:00 +0000

SQLite doesn’t feel like it should be this good. It’s small, it’s file-based, and it doesn’t come with a deployment ceremony worthy of enterprise budgets. And yet—quietly, everywhere—it runs the stuff that actually matters: phones, browsers, embedded controllers, and the offline-first apps people rely on. The punchline is simple: a lot of backend developers dismiss SQLite as a “toy,” and that dismissal is mostly nostalgia for client-server complexity.

SQLite is everywhere—and not by accident

“Toy” is the wrong word for software that shows up by default across platforms you didn’t choose. SQLite is built into iOS and Android through common libraries, ships inside countless apps, and powers embedded systems where running a separate database server would be an operational joke. Even in more “modern” stacks, SQLite keeps showing up in the cracks: caches, local state, background sync buffers, and analytics scratchpads.

Here’s the deeper reason: SQLite collapses the classic database deployment surface area into something you can reason about. Instead of “database server + network + authentication + migrations tooling + connection pooling + ops,” you get:

a single file (or a set of files),
a small set of modes and pragmas,
and a predictable lifecycle: create DB → write transactions → read results.

That predictability matters when the product is small, the team is lean, and the cost of being wrong is measured in developer hours, not cloud bills.

WAL mode: the concurrency story backend devs usually miss

The most common reason developers underestimate SQLite is that they remember old performance myths or default settings they never touched. SQLite has a concurrency mode that changes the entire conversation: WAL (Write-Ahead Logging).

In WAL mode, SQLite separates reads from writes in a way that’s especially friendly to typical app workloads: many concurrent readers, one writer at a time (or at least “not a writer stampede”). Practically, this means:

Readers don’t block behind writers nearly as often.
You get better performance under mixed read/write traffic.
Long read transactions are safer because they work against a consistent snapshot.

If you’ve ever built an app where the database is “mostly reads” (e.g., serving API responses, resolving user sessions, fetching cached entities), WAL is exactly what you want.

A concrete example: imagine a service that stores user profiles and feature flags. Writes happen when users update settings; reads happen constantly when requests come in. With SQLite in WAL mode, that pattern maps cleanly:

One writer transaction applies updates.
Many readers fetch profile data concurrently.
Clients don’t wait on the writer except when they truly must.

To enable it, you’ll typically set the database pragma once in your app startup:

PRAGMA journal_mode = WAL;

If you’re using a library (ORMs or drivers), confirm it doesn’t override this—and ensure your connection strategy doesn’t fight SQLite with overly aggressive connection churn.

Replication without heroics: Litestream and the real “serverless database” story

If your mental model is “SQLite means no reliability,” you’re thinking about local files as disposable. That’s the wrong framing. You don’t need to abandon SQLite; you need a replication layer that matches its strengths.

Enter Litestream: an approach to replicate SQLite databases continuously so you can treat a local SQLite file as a durable, recoverable data source. The win is that you keep the operational simplicity of SQLite while gaining the safety net you expect from a server-based database.

The practical pattern looks like this:

Your app writes to the local SQLite database (fast, simple, no network round trips).
Litestream continuously ships changes to a remote storage target.
In a failure scenario, you restore from the replicated stream.

This is particularly compelling for systems where you already like the “single writer” or “local-first” design. For example:

A mobile app that syncs to a backend: store locally, replicate server-side from the device or from a companion process.
A web service that prioritizes low latency: write locally to SQLite (on the same host), replicate for durability.
Edge deployments: run a local DB where network jitter exists, replicate changes upstream.

The important point isn’t that SQLite can be replicated; it’s that the replication story can be practical. You’re not asking SQLite to behave like a distributed database. You’re using it the way it’s meant to be used: transactional engine with a clean replication pipeline.

When SQLite beats PostgreSQL (and why “at a fraction of the cost” is believable)

Let’s kill a recurring misconception: SQLite is not “always slower than PostgreSQL.” It’s different. And for a surprising number of real workloads—especially read-heavy workloads with a single-writer pattern—SQLite can outperform PostgreSQL while requiring far less operational overhead.

Why?

Fewer moving parts: no client-server protocol overhead for every request.
Local I/O: reads and writes happen on the same machine (or at least close to it).
Lightweight connections: you don’t fight pool configuration or connection storms.
Simpler deployment: no “database is down” because of networking, auth misconfigurations, or cluster topology issues.

Suppose you’re building a backend for a small SaaS: think dashboards, content delivery, and API endpoints. Writes might happen through background jobs, scheduled syncs, or user actions that are relatively infrequent compared to read traffic. In that scenario, PostgreSQL’s strength—high-concurrency multi-writer workloads and distributed operational features—may be overkill.

SQLite shines when the bottleneck is not “global write throughput under contention,” but “how quickly can we serve requests with clean transactional semantics.”

A rule of thumb I’ve adopted: if your system design doesn’t require the database to coordinate dozens of concurrent writers across many networked instances, start with SQLite. If you later discover a write contention issue, you can revisit the architecture. But you’ll have learned something valuable before you pay the operational tax.

Practical guidance: how to use SQLite like you mean it

If you’re going to take SQLite seriously, treat it like production software, not a demo.

Use WAL mode and plan for cleanup

WAL mode changes the concurrency profile in your favor, but it comes with operational considerations (like checkpointing behavior). Don’t ignore it. Make sure your application or maintenance process runs appropriate checkpointing so WAL files don’t grow without bound.

Design for the single-writer reality

Many systems naturally fit SQLite’s sweet spot: one writer transaction stream, lots of readers. If your design spawns multiple writers aggressively, you’ll feel it. Instead:

Batch writes when possible.
Route all writes through a single queue/worker.
Keep write transactions small and fast.

Pick the right locking assumptions

SQLite locks at the database file level. That means your app should avoid patterns that cause unnecessary writes during request handling. A common anti-pattern is “log to the DB synchronously on every request.” If you want traceability, queue the logs and persist them in a background batch.

Tune your connection strategy

SQLite supports concurrency, but the way you manage connections still matters. Prefer long-lived connections when the runtime is stable, and be careful with high-frequency connect/disconnect loops.

Validate with the workload you actually have

Before declaring victory or failure, load test your real query mix. SQLite performance is sensitive to schema design, indexes, and transaction sizing. If your queries are unindexed or your transactions are chunky, you’ll hurt any database—but SQLite tends to reveal these issues sooner because the system is so direct.

The “no database server” mindset that unlocks shipping

The most compelling benefit of SQLite isn’t raw performance—it’s the ability to ship. Backend projects stall for predictable reasons: database migration pipelines break, production connection settings drift, replication lags, and someone inevitably asks why the cluster is misbehaving “only in staging.”

With SQLite, you remove an entire class of problems. Your database becomes an artifact of your application, not a separately administered service you have to babysit.

And that doesn’t mean you can’t be serious about durability. Replication tools like Litestream let you keep the simplicity while moving from “local file” to “recoverable system.” WAL mode gives you concurrency that fits real-world read patterns. At that point, the “toy database” label starts to look like a bias, not a technical assessment.

If you’re building your next side project, start here. If you’re building your next startup, seriously consider it. Most teams don’t need more infrastructure—they need fewer failure modes and faster iteration loops.

Conclusion: SQLite earns its place, not your nostalgia

SQLite is effective in the unreasonable way: it’s small, boring-looking, and operationally elegant, yet it handles real workloads across phones, browsers, and embedded devices. With WAL mode for concurrency, and replication options like Litestream for durability, it becomes a practical backbone for read-heavy systems with manageable write patterns. Treat it as a first-class backend datastore—not a toy—and you may find you can build faster, deploy safer, and spend less time fighting infrastructure.

Web3 Is Mostly Nonsense, and That's Okay

abdecastro@protonmail.com (Antonio B De Castro) — Wed, 20 Apr 2022 00:00:00 +0000

“Web3” has become a branding incantation: sprinkle “decentralized” on your slide deck, bolt on a token, and somehow everyone forgets to ask whether the product needs a blockchain. The result is a grifter ecosystem so loud it drowns out the genuinely interesting work. The twist is that you don’t need to hate Web3 to see through it—you need to be able to separate hype from primitives.

Here’s my take: most Web3 projects are unnecessary, and many are actively harmful. But the underlying cryptographic ideas are real, useful, and worth learning. If you focus on the primitives—content addressing, verifiable computation, and programmable money—you can ignore the token casino without throwing away the baby with the bathwater.

Why “Blockchain” Is Often Just a UI Feature

Let’s start with the uncomfortable truth: a lot of Web3 is only “decentralized” in the same way a spreadsheet is “database-backed.” In practice, many systems behave like centralized services with extra steps:

Users trust a front-end server to validate data.
The “smart contract” is a billing wrapper around an off-chain database.
The token doesn’t improve anything technically—it just finances the growth stage.
Governance is a forum, not a decision mechanism.

A simple litmus test: if your application can be implemented with normal HTTPS, a relational database, and a queue, then adding a blockchain doesn’t magically make it better. It usually makes it slower, harder to update, and more expensive to operate.

Example: consider a SaaS dashboard that shows user analytics. If the analytics are produced off-chain and merely recorded on-chain for “auditability,” you’ve added cost without improving correctness. If you can’t explain why you need an append-only, globally replicated ledger, you probably don’t need one.

My rule of thumb is brutally practical: use a blockchain when you need a shared, tamper-evident history among parties that don’t fully trust each other. Everything else is usually a marketing problem.

The Interesting Part: Content-Addressed Storage

One of the most useful primitives coming out of the broader ecosystem is content-addressing: the idea that data is identified by a cryptographic hash of its contents, not by a mutable filename. This is conceptually simple, technically powerful, and—crucially—doesn’t require a token.

When you content-address data, you get properties that centralized systems struggle to guarantee:

Integrity: if the content changes, the address changes.
Immutability by reference: you can’t silently swap the underlying bytes while keeping the same address.
Deduplication: identical content naturally maps to the same identifier.

Think about what this enables in real systems:

Verifiable document publishing: publish a document and reference its hash. Anyone can later verify they’re seeing the exact version you claimed.
Reproducible artifacts: build outputs (like model weights or compiled binaries) can be pinned by hash so deployments are auditable.
Portable caching: distributed nodes can fetch content by address without negotiating “which version do you mean?”

If you’ve used Git, you already understand the mental model. Git commit hashes are content-addressed fingerprints of trees and files. Web3 storage systems essentially extend that idea to the wider world, with networks designed to serve data by hash.

Practical advice: if you’re building something that involves long-lived artifacts—images, proofs, bundles, datasets—consider hash-first design. Store content where you want, but treat the hash as the source of truth. The blockchain, if used at all, can reference these hashes—not the other way around.

Verifiable Computation: When “Trust Me” Isn’t Good Enough

Another genuinely interesting primitive is verifiable computation: the ability for one party to produce a computational result and a proof that the result is correct, without requiring the verifier to redo the entire computation.

This category includes a range of techniques—proof systems, zero-knowledge proofs, succinct verification—that aim to make verification fast while keeping the proof itself compact.

Why do people care? Because “trust me” is a weakness you can’t afford in adversarial environments.

Concrete example: Suppose you run a large off-chain computation—say, processing trades, generating game state, or computing eligibility for a reward. A centralized operator could publish the result. But if users don’t trust the operator (or you don’t fully control what users trust), they need assurance that the result is computed correctly from the inputs.

With verifiable computation, the workflow looks like this:

Inputs are committed (often via hashes).
The prover performs computation off-chain.
A proof is generated that the computation followed the rules.
Verifiers check the proof quickly, without re-running the whole process.

Is this trivial? No. It’s engineering-heavy, and the tooling ecosystem is still maturing. But the direction is right: rather than replicating everything on-chain, you prove correctness of what happened somewhere else.

Practical advice for builders: start by asking where verification matters. If your computation directly affects money, permissions, or scarce resources, that’s where proofs can replace brittle trust assumptions. If you can tolerate trusting one party, you probably don’t need proofs yet—build the app first, then harden only the parts that truly require verification.

And yes, this is one area where blockchain can be a useful substrate: smart contracts can act as verifiers, recording proofs and mediating dispute resolution. But the proof system is the primitive, not the chain.

Programmable Money: What Smart Contracts Actually Do

“Programmable money” is often used as a synonym for “token.” That’s marketing. Smart contracts are better understood as deterministic state machines: given inputs, they transition state according to code rules, with transparent execution and a verifiable history.

When programmable money is valuable, it’s usually because you need these properties:

Atomicity: multiple actions either happen together or not at all.
Enforceable rules: parties can rely on code-based constraints rather than bilateral agreements.
Shared settlement: the state lives where multiple parties can consult it.

Classic examples include escrow, royalties, and automated market mechanisms. But the more interesting lesson is this: the contract isn’t magic; it’s a coordination mechanism for parties that don’t want to negotiate everything from scratch.

Here’s the concrete gotcha: smart contracts are only as good as their interfaces. If your contract depends on off-chain data supplied by a trusted party, you’ve introduced a central point of failure. “On-chain” doesn’t automatically mean “trustless.” It means “verifiable where the contract can verify.”

Practical advice:

Prefer designs that are self-contained or that can validate inputs on-chain.
Be suspicious of projects that say “we use decentralization” while quietly relying on centralized operators for the critical data path.
If you must use off-chain data, think hard about incentives, replay protection, and how disputes are resolved.

The Token Casino Problem (and How to Avoid It)

Now for the part almost everyone gets wrong: tokens. Tokens are not inherently evil, but they are frequently used as a substitute for product-market fit.

In a healthy system, a token is typically aligned with a real technical purpose—governance, access control, staking for security, fee markets, or incentives that are actually necessary for the mechanism to work.

In the grifter ecosystem, tokens are a fundraising layer. They fund marketing. They motivate influencers. They provide a distraction from the fact that the app either doesn’t require decentralization or fails at the decentralization part.

How to detect token-first nonsense quickly:

The token can be removed without changing the user experience. If yes, it’s probably not integral.
The “decentralization” is cosmetic. If everything important is controlled by one company, the blockchain is a logging system.
Upgrades are centralized. If governance is hand-wavy and emergencies are single-signer, users are trusting people, not code.
The roadmap is vibes. If there’s no clear technical path to the stated capabilities, you’re watching hype.

Practical advice for teams and investors: separate your analysis into two tracks.

What cryptographic or architectural primitive does this system use?
What is the user value without the token?

If you can’t answer (1) clearly and (2 sounds like a normal product, the token is likely just a financing mechanism.

Learning the Right Stuff Without Getting Burned

If you want to build with integrity in this space, you don’t need to memorize every new chain or token standard. You need to learn the underlying concepts that survive every hype cycle.

A smart developer path looks like this:

Cryptographic fundamentals: hashing, signatures, commitments, and threat models.
Content addressing: how hashes act as references; how immutability-by-reference changes system design.
Proof systems at a high level: what it means to prove computation, what verification costs look like, and where proofs can replace trust.
Smart contract basics as state machines: determinism, gas costs, failure modes, and secure interfaces.

Then keep one cultural discipline: ship small, verifiable slices. If your system can’t be inspected, tested, or audited meaningfully, it’s not mature enough to justify the complexity it adds.

And treat the token ecosystem as optional background noise. You can learn from the primitives without joining the casino.

Conclusion: Ignore the Noise, Build the Primitives

Web3 is mostly nonsense—but not because the technology is fake. It’s mostly nonsense because most builders are using a ledger as a replacement for engineering judgment and because tokens have become a reflexive layer.

The good news is that the interesting ideas are real and practical: content-addressed storage for integrity and long-lived references, verifiable computation for correctness without re-running everything, and programmable state machines for enforceable coordination. Focus on those primitives, demand clear trust properties, and you’ll be positioned to build systems that deserve decentralization—rather than ones that just announce it.

Go Is the Language for People Who Want to Ship

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 09 Apr 2022 00:00:00 +0000

Every engineering team eventually hits the same wall: not “can we build it?” but “can we build it again—and again—without dragging the entire org through a rewrite.” If that’s your problem, Go is the rare language that optimizes for shipping over showing off. Yes, it’s boring. Yes, it’s simpler than the cool kids. And yes, that’s the point.

Boring Is the Operating System, Not a Bug

Go gets criticized for being “too basic,” as if the only acceptable technology is the kind that demands a tutorial and a glossary. But the most successful teams don’t start with language fireworks—they start with reliable delivery.

Go’s surface area is intentionally small. There’s one clear way to format and compile code. Concurrency has a mental model you can explain without a whiteboard dissertation. You don’t need a framework to do “hello web” or “hello API.” You don’t need five different libraries to add TLS, validate input, or make an HTTP call.

A concrete example: consider a service that needs an HTTP endpoint and a background worker. In Go, you can often fit the core of the solution into a few files and run it immediately. The language nudges you toward composition rather than ceremony:

HTTP handler functions are straightforward.
Goroutines are the default tool for concurrency.
Channels are available when you truly need coordination, not as a forced abstraction.

This doesn’t make Go magical. It makes it predictable. Predictability is what lets teams move fast without inventing new “best practices” every sprint.

Deployability: The Single Binary Advantage

Ship speed isn’t just about coding speed—it’s about how frictionless deployment is. Go’s build model supports a workflow that many teams want and few languages make pleasant:

Compile from source.
Produce a single binary.
Deploy that binary.

No runtime dependency chain to reason about. No “works on my machine” caused by a missing version of some interpreter, framework, or transitive dependency that quietly changed overnight. This matters most when your pipeline is busy and your team is tired.

Imagine you run a dozen services, each with its own CI/CD job. In a “clever” ecosystem, you can spend real engineering time untangling dependency graphs, base images, and subtle runtime differences. In Go, you can usually focus on the service itself. Your CI builds something immutable; your deploys move that artifact into place.

Is Go boring? Yes. Does it reduce operational uncertainty? Also yes—and that’s the kind of boring you should want.

The Standard Library: Coverage Without Dependencies

One of the most practical reasons Go ships well is its standard library. It includes what teams commonly need: HTTP servers and clients, JSON encoding, file I/O, TLS helpers, and crypto primitives you can use without chasing half a dozen third-party packages.

This is where “boring” becomes a strategic advantage. Every dependency you add introduces:

A versioning decision.
A security patch path.
An upgrade tax.
A future debugging session when something changes.

A strong team treats dependencies as costs to be justified, not trophies. Go’s standard library covers enough ground that many services can stay dependency-light.

For example, you can build a small REST API with HTTP handlers and JSON without pulling in a routing framework. You can validate inputs with the language-level tools you already know. You can do authenticated requests, handle TLS, and manage errors in ways that are consistent across services.

This consistency pays dividends when multiple teams share a platform. New engineers can learn one set of patterns and apply it everywhere.

Error Handling: Verbose, Predictable, and Easy to Debug

Go’s error handling is another lightning rod. Critics complain about verbosity; experienced Go developers appreciate the clarity.

In Go, errors aren’t exceptions that explode up the stack. They’re values you explicitly check. That forces decisions to happen at the right place:

handle locally when you can
wrap with context when you can’t
return upward when it’s the only sane option

Here’s the mindset shift that makes this work: Go makes control flow visible. You can glance at a function and understand what can go wrong and what the function does in those cases.

That visibility matters when your service fails in production at 2 a.m. A “clever” approach might hide the path to failure behind layers of magic. Go doesn’t. The code reads like it’s telling you exactly where it expects trouble—and what it will do when trouble arrives.

You will write more lines. You’ll also spend less time guessing.

Generics Came Late—So What?

Go’s generics arrived later than some ecosystems. Fair criticism. But “late” can still be “right” if teams use the feature when it truly adds value rather than forcing it everywhere.

Even without generics, Go’s approach to maintainable code has been consistent for years:

keep types simple
model your domain with structs
use interfaces where they clarify behavior
write small functions that compose cleanly

When generics finally arrived, they didn’t replace Go’s core strengths. They complemented them. And the practical lesson is: don’t let the presence of a new feature determine architecture. Let needs drive architecture.

If your team wants to ship, you don’t adopt generics because they’re fashionable. You adopt them when they reduce duplication without obscuring meaning. If a generic abstraction makes the code harder to read, it’s not a win—it’s future work disguised as progress.

Concurrency That’s Understandable Under Pressure

Go’s concurrency story is often described as a selling point, and it deserves credit. But “powerful” isn’t the most important word here—“understandable” is.

Goroutines are lightweight, and channels are a clear abstraction for coordination. That combination can lead to systems that scale without becoming an unreadable maze.

A practical example: suppose you need to call three external APIs to build a response. You can fan out requests concurrently and then gather results. In many languages, the pattern is either overly complex or encourages “clever” concurrency frameworks that are hard to reason about. In Go, the concurrency code stays close to the business logic:

start goroutines for independent work
collect results
handle cancellation when the request ends
avoid sharing mutable state without a plan

Even better: because Go makes this style idiomatic, your team can learn it once and apply it everywhere. That’s a “boring” advantage again—shared understanding is a shipping multiplier.

The Real Trade-Off: Fewer Features, More Throughput

Let’s be honest about the trade-off. Go is not trying to be a playground for language maximalists. It gives you fewer features, fewer patterns, and fewer ways to be clever. The compiler is strict. The tooling is straightforward. The ecosystem is practical.

That’s why teams choose Go when they want throughput:

fast compilation helps iteration
single-binary deployment helps operations
standard library coverage reduces dependency sprawl
explicit error handling reduces mystery
understandable concurrency reduces production time sinks

It also means you’ll occasionally fight the language. Error handling can feel wordy. Some abstractions require discipline. You may miss more expressive type systems. But compared to the cost of delays—blocked releases, broken builds, insecure dependencies, unclear production behavior—those complaints often shrink fast.

Boring technology delivered fast beats clever technology delivered never.

Conclusion: Ship-First Engineering Deserves Boring

Go earns its reputation because it makes the path from idea to running service short and repeatable. It doesn’t reward novelty; it rewards momentum. If your team’s bottleneck is delivery—whether you’re building APIs, internal tools, or production services—Go is a strong default.

Choose it when you want code that any developer can read on day one and a workflow that keeps your releases boring in the best possible way.

CSS Grid Changed Layout Forever and Flexbox People Need to Accept It

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 05 Apr 2022 00:00:00 +0000

For years, Flexbox was the hero of modern CSS layout. It made layout feel human again. But the minute you start building real pages—dashboards, marketing grids, responsive galleries—Flexbox runs out of runway. CSS Grid didn’t “replace” Flexbox. It fixed the part Flexbox was never built to do well. If you’ve been nesting flex containers like they’re going out of style, it’s time to learn Grid properly.

Flexbox: incredible for one dimension (and exhausting for two)

Flexbox shines when your layout is essentially one-dimensional: you’re arranging items in a row or a column, and you care about alignment, ordering, and distribution along a single axis.

Classic flex use-cases:

A nav bar with evenly spaced links
A toolbar where buttons wrap or scroll horizontally
A “stack” of components where you want consistent spacing and simple reordering

But once your problem becomes two-dimensional—rows and columns with responsive behavior—Flexbox starts turning into a philosophical argument with yourself. You’ll find yourself:

Creating nested containers to simulate rows and columns
Repeating media queries to adjust widths and spacing
Using flex-wrap and hoping it “just works” across breakpoints

That last point matters. flex-wrap is not a grid system. It’s a wrapping behavior. When you need a predictable matrix, your code should reflect that.

The real mindset shift: stop forcing grids into flexbox

Here’s the pattern I keep seeing in production code: developers learned Flexbox first, so they reach for it by default—then compensate for missing features by nesting more flex containers.

A simplified example of what that looks like:

.cardGrid {
 display: flex;
 flex-wrap: wrap;
 gap: 16px;
}

.cardRow {
 display: flex;
 gap: 16px;
 width: 100%;
}

Then suddenly you need three rows at some widths, two rows at others, and different card sizes in different sections. The fix becomes “more wrappers” and “more breakpoint rules,” not a clearer layout declaration.

Grid flips the relationship: you declare the layout you want—rows, columns, and placement—and let the browser do the math.

CSS Grid: declare the matrix, not the workaround

CSS Grid is brilliant because it treats layout as a two-dimensional problem from the start. You define a grid and place items into it. The mental model is closer to how designers actually think: columns, rows, and areas.

The most productive way to start is to focus on the columns first.

A responsive grid without media-query spaghetti

.gallery {
 display: grid;
 gap: 16px;
 grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
}

That single declaration usually replaces multiple breakpoints. Why? Because you’re telling Grid how to size columns: each card wants at least 240px, and remaining space is shared.

Now add your items:

<div class="gallery">
 <article>...</article>
 <article>...</article>
 <article>...</article>
</div>

You’ll get a responsive layout that naturally adapts as the container width changes. This is what “learn Grid properly” means in practice: stop hand-tuning widths and start describing intent.

Named areas: the cleanest way to communicate layout

Grid’s named areas are one of those features that feel like cheating—until you realize how much time they save and how clearly they express layout structure.

Imagine a landing page section with this layout:

Header spans full width
Main content is left; sidebar is right
A promo band spans full width
Footer spans full width

You can express that like this:

.page {
 display: grid;
 gap: 16px;
 grid-template-columns: 2fr 1fr;
 grid-template-areas:
 "header header"
 "main sidebar"
 "promo promo"
 "footer footer";
}

.header { grid-area: header; }
.main { grid-area: main; }
.sidebar { grid-area: sidebar; }
.promo { grid-area: promo; }
.footer { grid-area: footer; }

Now let it adapt:

@media (max-width: 800px) {
 .page {
 grid-template-columns: 1fr;
 grid-template-areas:
 "header"
 "main"
 "sidebar"
 "promo"
 "footer";
 }
}

Yes, there’s still a media query—but it’s a layout decision, not a width-math patch. You’re changing the shape of the template, not tweaking individual item sizes.

This is the difference between “Grid thinking” and “Flex thinking with extra steps.”

Auto-fit vs auto-fill: choose the behavior you actually want

People treat auto-fit and auto-fill like they’re interchangeable. They aren’t. The difference shows up when there’s leftover space.

auto-fill keeps the grid tracks even if some end up empty.
auto-fit collapses tracks that don’t have content to fill them.

For most “cards that should expand to fill the row” designs, auto-fit feels right. For layouts where you want consistent track structure regardless of how many items there are, auto-fill can be the better fit.

Example:

.tiles {
 display: grid;
 gap: 12px;
 grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
}

If you have three tiles and a wide container, auto-fill will preserve the grid’s track count, keeping the visual rhythm stable. If you’d rather have the existing tiles stretch to occupy the extra space, auto-fit will feel more natural.

A practical rule: if the layout looks “too sparse” with auto-fill, try auto-fit. If it starts looking “too floaty,” stick with auto-fill and control the container width instead.

Subgrid: the missing piece when nested layouts must align

Once you build real systems—design systems, component libraries, complex admin pages—you run into a problem: nested components shouldn’t fight the parent’s alignment.

CSS Grid’s subgrid is the answer for grid-to-grid alignment. It lets a child inherit the parent’s track sizing, so columns and spacing line up without hacks.

Even if you’ve never used subgrid, you’ve probably seen the workaround:

Hard-coded padding values
Re-declared grid-template-columns inside components “so they match”
Mismatched gutters that only appear in edge widths

With subgrid, you can structure layouts so columns remain consistent across component boundaries. The exact availability depends on browser support, so test in your target environments—but as a concept, subgrid is exactly how you should think about nested layout: alignment is a shared contract, not a best-effort coincidence.

So… is Grid a replacement for Flexbox?

No. Flexbox still matters—and if you try to use Grid for everything, you’ll create your own mess.

Use Flexbox when:

You’re aligning items along one axis
You need easy ordering within a row or column
You’re building toolbars, lists, navs, and inline components

Use Grid when:

You need rows and columns as first-class citizens
You want templates that describe layout structure
You’re building responsive page regions (not just “wrapping items”)

Here’s a simple decision shortcut:

If you can draw the layout as a table of rows/columns, use Grid.
If you can describe it as “items in a line,” use Flexbox.

And if you find yourself nesting flex containers to create columns, stop and ask: “Am I recreating a grid with wrappers?” If yes, you already know what to use.

Conclusion: accept Grid as the default for page layout

Flexbox is brilliant for one-dimensional layout. CSS Grid is brilliant for the two-dimensional reality of actual pages. The cost of clinging to Flexbox-first thinking isn’t just longer code—it’s unclear intent, duplicated layout logic, and brittle breakpoints that feel like maintenance debt on day one.

Learn Grid properly: repeat(auto-*, minmax()) for responsive columns, named areas for readable templates, and subgrid for alignment across component boundaries. You’ll write less CSS, communicate layout intent more clearly, and stop fighting the browser.

Stop Writing Unit Tests for Your React Components

abdecastro@protonmail.com (Antonio B De Castro) — Mon, 28 Mar 2022 00:00:00 +0000

React unit tests have become a habit loop: write tests, ship code, refactor, watch tests explode anyway. It’s not that unit tests are “bad”—it’s that most React teams accidentally use them to test the wrong thing. When your tests mostly assert implementation details, you pay twice: first in time, then in constant maintenance. The fix isn’t to write more tests. It’s to write better tests—fewer, behavior-driven integration tests that exercise the UI like a user would.

Why React Unit Tests Fail in Practice

A typical “unit test for a component” story goes like this:

Render the component shallowly.
Mock half the world.
Assert internal calls: dispatch happened, a prop was passed, a callback was invoked, a certain component was rendered.

This approach tends to couple your tests to how the component is built rather than what it does. You refactor the component—rename a handler, lift state, switch from one component to another, change how props are wired—and the tests break even though the UI still behaves correctly.

Worse, the “shallow rendering” era taught many teams to verify structure, not behavior. Snapshot tests reinforced the same problem: if the rendered output changes, the snapshot changes, and now you’re deciding whether the test or your refactor is “right.” That’s not confidence. That’s noise.

The real goal of a test is simple: answer “Will this user-facing behavior still work?” Unit tests often can’t answer that question without turning into brittle mocks and internal assertions.

Behavior Beats Implementation: What Testing Library Changed

Testing Library flipped the default mindset. Instead of reaching into the component and interrogating its internal shape, you query the rendered UI the way a user would:

Find elements by accessible role or label.
Interact using events that simulate reality (typing, clicking, submitting).
Assert outcomes that matter (text appears, navigation happens, a request is sent, an error is displayed).

This style is powerful because it naturally discourages testing internal implementation. When you query by label, you’re asserting “the form is usable.” When you submit and check for success, you’re asserting “the flow works.” Refactors become less scary because the test is anchored to behavior, not structure.

Here’s the key shift: you’re not testing React components. You’re testing user journeys through your interface.

The Integration Test That Replaces a Pile of Unit Tests

Consider a simple but realistic case: a checkout form.

In a unit-test-heavy world, you might write fifteen tests:

Renders fields
Validates email format
Validates credit card fields
Shows error message when invalid
Calls the submit function with correct payload
Disables button while loading
Shows spinner
Handles API error
Handles API success
Resets form on success
…and so on

Each “unit” test focuses on a piece of logic in isolation. That sounds thorough—until the form grows, a validation rule changes, or you refactor your state management. Suddenly, the tests don’t reflect what the user experiences anymore.

A single integration test can cover the same risk surface with far less maintenance:

Render the form.
Enter values.
Submit it.
Assert the resulting UI state.

Example (with Testing Library):

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import CheckoutForm from './CheckoutForm';

test('submits valid checkout and shows confirmation', async () => {
 const user = userEvent.setup();
 render(<CheckoutForm />);

 await user.type(screen.getByLabelText(/email/i), 'ava@example.com');
 await user.type(screen.getByLabelText(/card number/i), '4242 4242 4242 4242');
 await user.type(screen.getByLabelText(/name on card/i), 'Ava Example');
 await user.type(screen.getByLabelText(/expiration/i), '12/34');
 await user.type(screen.getByLabelText(/cvv/i), '123');

 await user.click(screen.getByRole('button', { name: /place order/i }));

 expect(await screen.findByText(/order confirmed/i)).toBeInTheDocument();
 expect(screen.getByText(/receipt/i)).toBeVisible();
});

That test is not “just one more test.” It’s the highest-signal one: it checks the entire flow works, end to end, in the same way users do. It will also catch real integration bugs—miswired handlers, broken form wiring, incorrect disabling logic, missing success rendering, and many more issues that unit tests often miss.

When Unit Tests Still Make Sense (Yes, Really)

Let’s be clear: unit tests aren’t inherently evil. The mistake is using them as the primary safety net for UI behavior.

Unit tests are excellent for:

Pure utilities: date formatting, validation functions, mapping transforms, reducers.
Business rules with no UI: if you can feed inputs and assert outputs without rendering.
State machines / selectors: where behavior is deterministic and stable.

But the closer your code gets to the UI layer, the more your tests should resemble usage. If your “unit test” is mostly verifying that a particular internal prop was passed to a child component, it’s probably testing implementation detail. Prefer asserting what the user sees instead: the child content appears, the button enables, the message changes.

A practical rule I’ve found useful:
If you can delete your component and still keep the unit test meaningful, it’s probably not a UI behavior test. That’s fine—just move it to the right layer (utility or domain tests). If the component must exist for the test to be meaningful, then test the UI behavior.

How to Write Fewer, Better Tests (Without Losing Coverage)

If you’re currently drowning in tests, don’t “refactor tests.” Replace them with a smaller set of integration tests that cover the critical paths.

Here’s a strategy that works well on real teams:

1) Identify the user journeys, not the components

Instead of “Test UserProfileCard,” think “Test viewing the profile.” You want the test to fail when the user experience breaks.

For example:

“Login with valid credentials shows the dashboard”
“Submitting an invalid form highlights the correct fields”
“Deleting an item updates the list immediately”

2) Use the UI as your API

Write tests that interact with:

getByRole, getByLabelText, getByText
buttons by accessible name
inputs by labels

If you find yourself querying componentInstance or reaching into internals, that’s a smell.

3) Mock only what you must

For network calls and external dependencies, mocking is normal. But avoid mocking everything under the sun. A common pattern is to mock the API layer and let the component’s wiring happen naturally.

If your form submits via fetch, mock the request and assert on UI outcomes—not internal fetch call counts unless it truly matters.

4) Assert outcomes, not call chains

Good assertions:

Success message appears
Error message is shown
The submit button re-enables after failure
Navigation occurs (or a route change indicator updates)

Weak assertions:

handleSubmit was called with exact arguments
dispatch was called N times
ChildComponent was rendered with prop X

Call-chain assertions may catch bugs, but they’re brittle. Outcome assertions catch more bugs with less maintenance.

Common Traps (And How to Avoid Them)

Even behavior-driven integration tests can go wrong. Avoid these traps:

Testing non-accessible UI selectors: If you rely on data-testid everywhere, you’ll end up recreating brittle coupling. Use it sparingly—accessibility queries should be your first choice.
Overfitting to exact text: Assert key phrases or patterns that represent user intent, not the entire formatting of a sentence that designers love to tweak.
One giant test for everything: Integration tests should still be focused. One test can cover one journey. If you’re testing five different flows in a single file, split it into separate behavior tests.
Snapshotting UI: Snapshots are useful for debugging, not for long-term confidence. If the UI changes frequently, snapshots become maintenance work disguised as verification.

The goal is stable tests that tell you something meaningful when they fail. When tests fail, you should understand the user-facing behavior that broke.

Conclusion: Replace Brittle Unit Tests With Real Confidence

React unit tests often become a maintenance tax because they validate implementation details, not user behavior. Integration tests with Testing Library give you a better signal: render the UI, interact like a user, and assert outcomes that matter. You’ll write fewer tests, catch real bugs, and refactor with confidence instead of dread.

Docker Changed Everything. Kubernetes Is Changing It Again.

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 17 Mar 2022 00:00:00 +0000

Containers didn’t just make deployments easier—they changed the mental model. Overnight, “it works on my machine” became less of a battle cry and more of an embarrassing punchline. Docker made packaging software feel portable and predictable. And then Kubernetes arrived and promised something even bigger: not just portability, but automation at scale.

Here’s the dirty secret, though: most teams running Kubernetes don’t need Kubernetes. The orchestration layer is where complexity hides—exactly the kind of complexity that can slow down teams who are still growing, still learning, or still delivering business value faster than they’re managing infrastructure.

Why Docker Felt Like Magic (And Why It Stuck)

Before containers, deployments were a patchwork of scripts, SSH sessions, bespoke server images, and tribal knowledge. Docker turned that into a repeatable artifact: build once, run anywhere. That’s not just a developer convenience—it’s an operational upgrade.

Consider a common workflow: you have a web app, a background worker, and a database. With Docker, you can define services, wire them together, and run the whole stack locally exactly as it behaves in production—down to environment variables, filesystem layout, and network expectations. That consistency reduces debugging time and makes CI more trustworthy.

Even better, Docker made “deployment” less about what your servers look like and more about what your images contain. Your pipeline builds images, pushes them to a registry, and your runtime pulls them. Clear boundaries. Fewer surprises.

This is why Docker became the default building block for modern systems. It lowered the cost of shipping.

Kubernetes: Great Promise, Heavy Machinery

Kubernetes is not “Docker, but better.” It’s a whole operational philosophy: declarative desired state, continuous reconciliation, and a control plane that keeps running systems aligned with your intentions.

If you’re only running a couple services with straightforward scaling patterns, Kubernetes can feel like bringing a full orchestra to play a single song on a piano. The piano works. The orchestra sounds impressive. But the rehearsal schedule is brutal.

The overhead isn’t theoretical. It shows up in work you didn’t plan for:

Cluster management: upgrades, node scaling, networking quirks, security policies.
Operational maturity: observability, incident response, rollback strategy, service discovery.
Workflow complexity: YAML-heavy manifests, Helm charts (often), GitOps tooling (sometimes), and debugging reconciliation loops.

Kubernetes requires a certain kind of muscle memory. If your team doesn’t have it yet, that’s not a moral failing—it’s just reality. For smaller teams, the operational surface area can steal attention from the engineering that actually differentiates your product.

And that’s the core tension: containers won the deployment war, but orchestration is where the real complexity lives.

The Reality Check: When Kubernetes Is the Right Tool

Kubernetes becomes worth it when you have system-level needs that are hard to automate reliably with simpler tools. “Hard” here means operationally risky, not just inconvenient.

You’re more likely in the right zone if you have several of the following:

Multiple environments with frequent change: staging and production with different constraints, plus regular rollout patterns.
Unpredictable load requiring robust autoscaling and workload isolation.
Dozens (or hundreds) of services with consistent patterns for networking, discovery, and scaling.
Complex availability requirements: multiple failure domains, strict rollout strategies, and mature rollback behavior.
Platform goals: you’re building an internal ecosystem where teams deploy services without touching infrastructure.

A practical rule of thumb: if your deployment process is already stable and your scaling needs are predictable, Kubernetes is often a tax, not a benefit. If you’re outgrowing that stability—if failures and scaling edge cases start to dominate your time—Kubernetes starts looking less like machinery and more like leverage.

The Case for Docker Compose + CI/CD (Even in Production)

If you’re under 50 engineers—or even close—there’s a strong argument to stop romanticizing Kubernetes and focus on shipping. Docker Compose and a disciplined CI/CD pipeline can handle a surprising amount of real-world production work.

A concrete example: a service with a web tier and worker tier

You can structure this cleanly:

A web container (stateless)
A worker container (consumes jobs)
A database (managed externally, or containerized if appropriate)
Shared configuration via environment variables and secrets injection

With Docker Compose, your local environment mirrors integration behavior:

docker compose up for developer parity
deterministic local dependency graph
reproducible config for tests

Then, your CI/CD does the serious work:

Build images for web and worker.
Run tests and integration checks (at least against a disposable environment).
Promote images to a staging registry/release tag.
Deploy using a repeatable mechanism (often pulling the same image tags from the registry).

The result: you get container portability without inheriting Kubernetes’ orchestration tax.

What about scaling and reliability?

If scaling is needed, you can scale at the infrastructure level (load balancer, horizontal scaling in the platform, or managed services) without implementing every orchestration concept yourself. Many teams use a managed runtime (VMs, container platforms, or platform-as-a-service) where the heavy lifting—process supervision, networking plumbing, and rolling updates—is handled by the platform.

The key isn’t “no orchestration.” It’s “appropriate orchestration.”

For many teams, that means you orchestrate workflows in CI/CD and let infrastructure handle the mechanics.

When You Outgrow It: A Migration Path That Doesn’t Hurt

If Kubernetes is the destination, don’t treat it like a monolithic switch. Treat it like a staged migration with clear wins.

A sensible progression looks like this:

Step 1: Standardize your images and rollout strategy

Before you touch Kubernetes, make sure your Docker images are consistent, versioned, and immutable. Your CI should already be producing the same artifacts you would deploy anywhere.

Step 2: Introduce “Kubernetes-ready” patterns

Build with:

clear health checks (liveness/readiness concepts)
stateless services where possible
explicit resource limits
predictable configuration via environment variables

Step 3: Run one service on Kubernetes

Pick a low-risk service or a service with strong boundaries. Migrate it first. Evaluate operational overhead with real workloads—not fantasy.

Step 4: Decide if it’s platform-level, or service-level

Some teams use Kubernetes as a service deployment target. Others use it as a platform. The latter is where the real complexity ramps up. Be honest: if you want a platform, you must invest in it—documentation, tooling, and operational ownership.

Step 5: Keep Docker (yes, really)

Kubernetes doesn’t replace the container model. It replaces the deployment and runtime mechanics. Your images still matter. Your CI/CD still matters. Kubernetes just becomes the orchestrator.

The best migrations preserve what’s working: build pipelines, artifact discipline, and deployment confidence.

A Sharp Opinion: Optimize for Team Velocity, Not Tool Prestige

It’s fashionable to frame Kubernetes adoption as inevitable. But inevitability is a myth businesses like because it sounds like certainty. Teams don’t need inevitability—they need velocity.

For many organizations, especially those that are still building, Kubernetes overhead can show up as:

more time spent debugging infrastructure
more time writing deployment manifests instead of improving product code
harder incident response due to more moving parts
operational burnout from cluster babysitting

Meanwhile, Docker Compose plus CI/CD gives you a tighter feedback loop:

fewer systems to learn
fewer failure modes to manage
clearer ownership boundaries
easier onboarding for new engineers

Kubernetes is powerful. It’s also opinionated. And power has a cost.

So the question isn’t “Which tool is modern?” The question is: “What complexity are we willing to own so we can ship faster?”

Conclusion: Containers First, Orchestration When It’s Worth the Price

Docker changed software deployment by making artifacts portable and repeatable. Kubernetes can extend that story by automating orchestration and scale—but it also introduces a level of operational complexity that many teams don’t need.

If you’re not at scale, start with Docker Compose and a strong CI/CD pipeline. Standardize your images, make rollouts boring, and let infrastructure handle the mechanics where possible. When your requirements outgrow the simple path, migrate deliberately—service by service, with discipline.

Containers got you to “works everywhere.” Orchestration is what you add when “works reliably everywhere” becomes the real business demand.

The Git Workflow That Actually Scales

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 10 Mar 2022 00:00:00 +0000

Most Git workflows fail for the same reason: they’re optimized for the moment you tag a release, not for the reality of everyday change. If your developers spend their time shepherding long-lived branches through manual merges, you’re not scaling—you’re amortizing pain.

Trunk-based development with short-lived branches isn’t a trend. It’s a response to how modern teams deliver software: continuous integration, frequent deployments, and feedback loops measured in minutes, not sprints. And yes—done properly, it beats GitFlow.

Why GitFlow Breaks in the Real World

GitFlow assumes a world where work funnels through scheduled releases and well-defined QA gates. In that world, it’s rational to have long-lived develop, a release branch, and supporting branches that exist long enough to “collect changes” for the next drop.

But most teams don’t actually operate like that. They work in smaller increments, merge multiple times per day, run automated tests constantly, and release whenever a build passes a checklist—not when a calendar tells them to.

Here’s what goes wrong when GitFlow meets that reality:

Merge conflicts become inevitable, not exceptional. The longer a feature branch exists, the more it diverges from develop, and the more painful the eventual integration becomes.
“Integration debt” accumulates. Your team can work for days without truly integrating anything. Then one person spends half a day resolving conflicts while everyone else waits.
Release branches become confusion magnets. Changes land in the wrong place, or get partially backported, or get re-labeled because “release X” now needs to include “that other thing.”

The core issue isn’t that GitFlow is “bad.” It’s that its model is mismatched to modern delivery systems. If your branching strategy relies on weeks of parallel work, you’ve designed for a bottleneck.

Trunk-Based Development: The Principle Behind the Practice

Trunk-based development (TBD) flips the default assumption: the source of truth lives on the trunk (usually main), and changes merge into it frequently. You still use branches—but they’re tools for short-lived isolation, not storage for weeks of work.

A healthy TBD workflow has three non-negotiables:

Short-lived branches: merge readiness in hours, not weeks. A practical rule of thumb is under 24 hours. If your branch regularly lives longer than a day, it’s signaling a process problem.
Automated integration: every pull request (PR) runs CI, including relevant tests, linters, and builds. “Green” should mean something.
Frequent deployments: if you can’t deploy often, you can’t safely hide unfinished work. You’ll start treating deployment like a gate again—recreating GitFlow’s pain.

Done correctly, this produces a simple outcome: engineers get fast feedback because the trunk constantly evolves, and teams avoid the integration cliffs that long-lived branches create.

The Mechanics: Short-Lived Branches That Stay Mergeable

Let’s make this concrete. A typical TBD day might look like this:

Create a branch: feature/payments-endpoint-refactor
Make incremental commits
Open a PR early, even if the feature isn’t fully finished
Let CI gate merge until the code compiles and passes the relevant automated checks
Merge quickly
Continue iterating as new commits and PRs land on the trunk

The secret to making this work isn’t only “short branches.” It’s keeping them mergeable:

Slice work vertically. Build a thin, working slice that compiles, passes tests, and can be safely enabled or disabled. Don’t chase “perfect completeness” before integration.
Avoid mega-branches. If a branch requires coordinating multiple teams or waiting on external dependencies, you’re not isolating risk—you’re postponing it.
Keep PRs small enough to review fast. If you can’t review it within a reasonable time window, it won’t merge quickly, and it’ll start drifting.

One practical tactic: treat the PR title like a user story boundary. If the PR can’t be described as “make X work in Y scenario,” it’s probably too broad.

Feature Flags: Your Safety Net for Incomplete Work

Short-lived branches only solve half the problem. The other half is what happens when unfinished code lands on main. That’s where feature flags come in.

A feature flag lets you merge code even if you can’t—or shouldn’t—turn it on for every user yet. Your workflow becomes:

Merge code behind a flag
Deploy continuously
Enable the feature for a limited audience (or 0% traffic)
Gradually expand once confidence is earned

Example: Suppose you’re rewriting a checkout endpoint and you want to reduce risk.

You implement the new path behind checkout_v2_enabled
CI runs tests for the new code
The code merges into main immediately
Deployment occurs multiple times per day
You enable the flag for internal traffic first
Then you expand to a small percentage of production traffic
Finally, you remove the old code once the new path is stable

This approach prevents the classic GitFlow scenario where the branch exists “until QA is done.” Instead, QA becomes continuous and operational: monitoring, automated checks, and controlled rollout replace the big manual handoffs.

If feature flags sound like extra complexity, that’s fair—but the complexity is preferable to the alternative. When you don’t use flags, you must delay merging until everything is ready, which forces the long-lived branches TBD exists to eliminate.

CI/CD and Guardrails: Fast Feedback Without Chaos

Trunk-based development works only if your tooling enforces quality at speed. Otherwise, “frequent merges” turn into “frequent breakage.”

A scalable TBD setup typically includes:

Branch protections on main:
- require PRs
- require CI to pass
- require review approvals from relevant owners
A clear CI split:
- fast checks on every PR (lint, unit tests, compile)
- broader checks either on schedule or for specific changes
Automated deployment to at least staging continuously, and production frequently

You don’t need a perfect pipeline from day one. But you do need guardrails that make it difficult to merge broken code.

Here’s a practical framing that works: define your pipeline as a contract. Every PR promises, “If this merge lands, the trunk remains buildable and tests remain meaningful.” When that contract holds, engineers stop fearing main and start trusting it.

What to Do If You’re Still “Branching Like GitFlow”

If your branches currently live for weeks, don’t try to flip the switch overnight. You need a migration plan that reduces pain immediately.

Start with these steps:

Measure your current branch lifetimes. If most branches last multiple weeks, expect merge conflicts and delayed integration—because that’s what your process is doing.
Reduce branch scope. Break work into vertical slices that can be reviewed and merged sooner. Even if branches still last longer than ideal, this makes them less divergence-heavy.
Introduce feature flags for risky changes. Begin with one area—say, customer-facing UI toggles or a single backend endpoint—then expand.
Shift release thinking to deployment thinking. Instead of “release when ready,” aim for “deploy whenever safe.” If you can’t deploy yet, the branch strategy can’t fully evolve.
Set a hard expectation for branch duration. Not as bureaucracy, but as a forcing function. If a branch is approaching 24 hours, either merge it behind flags or split it.

Be opinionated about it: if the branch can’t be merged quickly, the work isn’t ready to be isolated—it’s ready to be re-sliced.

Conclusion: Scaling Is Integration, Not Scheduling

GitFlow is elegant for a world of scheduled releases and manual gates. Modern teams don’t live there. They live in CI, continuous deployment, and constant user feedback—and they need a Git workflow that supports that reality.

Trunk-based development scales because it keeps integration continuous. Short-lived branches keep merges boring. Feature flags keep “unfinished” safe. And CI/CD keeps the trunk trustworthy.

If your branches regularly last weeks, you don’t have a branching strategy—you have a merging problem. Fix that, and everything else gets easier: fewer conflicts, faster reviews, and a workflow your team actually wants to use.

Your REST API Is Probably Fine. Stop Reaching for GraphQL.

abdecastro@protonmail.com (Antonio B De Castro) — Sat, 05 Mar 2022 00:00:00 +0000

GraphQL gets a lot of attention because it’s clever. But clever isn’t the same thing as better for your business. In most teams, your REST API isn’t the bottleneck—your product requirements, data modeling, and API ergonomics are. If you’re considering GraphQL “because the industry does,” pause. REST with good design already solves the majority of real-world problems, and it comes with fewer moving parts when you’re trying to ship.

The GraphQL pitch: fewer round trips, more flexibility

GraphQL’s core value is simple: clients request exactly the fields they need, in exactly the shape they want. Instead of endpoints like:

GET /users/123
GET /users/123/orders
GET /users/123/orders/456/items

GraphQL lets a client request a nested graph in one call:

query {
 user(id: "123") {
 name
 orders {
 id
 items {
 sku
 quantity
 }
 }
 }
}

That flexibility is legitimate. It’s also seductive for teams wrestling with multiple clients—say, web, mobile, partner integrations—each wanting different subsets of the same data.

But the key is not whether GraphQL is capable. The question is whether your constraints match what GraphQL optimizes.

The reality check: most teams don’t need a query language

Most projects don’t have deeply nested, highly variable data requirements across many clients. Most teams have:

A handful of predictable views or screens
A relatively stable set of resources
A client-server communication pattern that looks like “fetch list, fetch details, submit mutation”

In those cases, a well-designed REST API is not “less modern.” It’s simpler, more observable, and easier to evolve without building an internal tooling stack around a query language.

Here’s the important nuance: GraphQL isn’t just “REST with one endpoint.” It changes how caching works, how debugging looks, and how you think about authorization and performance. Those are solvable problems—but they’re not free.

If your system is mostly CRUD-shaped, you’ll feel GraphQL overhead more than its benefits.

Why REST wins for day-to-day engineering: caching, errors, debugging

REST’s superpower for many teams is that it fits the web’s mental model.

HTTP caching is straightforward

With REST, you can lean on standard caching semantics—ETags, Cache-Control, conditional requests—without inventing new rules.

Example: you can set an ETag on:

GET /products/sku-123

Then clients can revalidate efficiently:

If-None-Match: "abc123"

GraphQL can approximate this, but you’re building policy around a transport that no longer maps cleanly to resource identity the way HTTP does.

Error handling stays obvious

REST encourages you to model failure modes clearly:

404 Not Found means missing resource
400 Bad Request means validation issues
409 Conflict means concurrency or state conflicts

GraphQL often returns HTTP 200 with an errors array (or other variations), which means your client and observability tooling have to work harder to correctly interpret outcomes. You can fix this, but again: more moving parts.

Debugging is easier when requests are deterministic

A REST request maps to a URI, an HTTP method, and a payload. When something goes wrong, the reproduction path is obvious:

“Call this endpoint with these parameters.”

With GraphQL, the “shape” is in the query document itself. Two queries might hit the same endpoint but represent very different workloads. That makes tracing and performance analysis trickier unless you invest in mature tooling and conventions.

The real “GraphQL-shaped” problems (and when to actually use it)

GraphQL becomes compelling when you truly have the conditions it’s designed for:

Multiple clients with different data needs
- Example: web needs a compact dashboard; mobile needs more context; partner APIs need a different projection.
Complex object graphs
- Example: permissions and nested associations where clients frequently need multi-hop data in one go.
UI-driven data shaping
- Example: front-end teams iterating rapidly on screens that assemble data from many related entities.

If your team is building something like a rich internal platform—where dozens of screens request overlapping, nested structures—GraphQL can reduce chattiness and improve developer productivity.

But if your API is basically:

GET /resources
GET /resources/:id
POST /resources
PATCH /resources/:id

…then the “GraphQL flexibility” is mostly theoretical. You’re paying complexity tax for flexibility you don’t regularly exercise.

If you want to modernize REST, do it the right way

“Stop reaching for GraphQL” doesn’t mean “do nothing.” It means fix the things that actually make REST feel painful.

1) Add a small set of purpose-built endpoints

If your clients repeatedly need the same aggregation, don’t force them to stitch it together manually.

Instead of requiring multiple calls, offer a dedicated projection:

GET /users/:id/summary
GET /users/:id/permissions
GET /users/:id/activity?from=...&to=...

This isn’t reinventing GraphQL. It’s acknowledging that clients want use-case-driven payloads.

2) Use pagination and filtering consistently

A lot of REST pain comes from inconsistent list behavior.

Pick a pagination strategy and stick to it:

limit/offset for simplicity, or
cursor-based pagination when datasets are large and change often.

Then enforce:

predictable query parameter names
clear semantics for filters and sorting

3) Make resource identity cache-friendly

Resources should have stable URIs. If the “resource” is the shape itself (like a query result), think twice—caching becomes fragile. Prefer caching stable entities and letting the server compute derived representations when necessary.

4) Improve client performance with batching, not query language

If you’re fighting “N+1 requests,” consider:

server-side composition endpoints (as above)
request batching at the transport layer
background prefetch patterns in clients

You can get the performance wins without bringing in a whole query ecosystem.

5) Tighten error contracts

Define a consistent error shape, with machine-readable codes and actionable details. Make your clients resilient. When errors are predictable, debugging becomes routine rather than heroic.

Example error payload:

{
 "error": {
 "code": "VALIDATION_FAILED",
 "message": "Email format is invalid",
 "details": [
 { "field": "email", "reason": "must match RFC 5322 format" }
 ]
 }
}

That’s what developers actually need—not a new language.

A practical decision framework: keep REST unless you hit these walls

Here’s a simple gut-check you can run with your team:

Are multiple distinct clients requesting different projections of the same nested graphs often?
Do you frequently see front-end workarounds caused by over-fetching/under-fetching?
Are you willing to invest in GraphQL-specific infrastructure: schema governance, resolver performance monitoring, query complexity limits, and developer experience?

If the answer to the first two is “not really,” you’re probably not buying the right tool. If the third is a hard “no,” then GraphQL is not a small decision—it’s a platform decision.

Most teams should start by upgrading their REST design and consistency. You’ll get better outcomes sooner, with fewer hidden costs.

Conclusion: GraphQL is a tool, not a default

GraphQL is an incredible technology for specific problems: deeply nested data, complex object graphs, and multiple clients with divergent needs. For the rest, REST—when designed with care—remains the most practical choice: better caching behavior, clearer error handling, and less debugging friction. If your REST API is “fine,” stop fixing what isn’t broken. Invest that effort into endpoints and contracts your team can understand, test, and operate confidently.

Rust Is the Language Your Future Self Will Thank You For

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 22 Feb 2022 00:00:00 +0000

You can write buggy software in any language—but you can only prevent certain classes of bugs when your tools actively refuse to let bad code exist. Rust is exactly that kind of language. The hype is real, yes, but the deeper story is more practical: memory safety without garbage collection, enforced by the compiler, with a learning curve that—once you conquer it—changes how you think about correctness forever.

The “loved” part is catching up to the “used” part

It’s easy to dismiss “most loved language” lists as popularity contests. But language love has a habit of turning into adoption once the pain becomes undeniable and the wins become consistent.

Rust’s momentum isn’t just social. It’s structural. Developers don’t just like Rust; they feel the difference when they ship software:

Fewer crashy edge cases during refactors
Less time chasing “use-after-free” and “data race” ghosts
A compiler that acts like a tireless code reviewer, even when you’re tired, rushed, or distracted

In other words, Rust converts admiration into engineering leverage. The gap between “this is awesome” and “we should use this” keeps shrinking because teams are increasingly seeing that the cost of Rust isn’t merely syntax or tooling—it’s a mindset shift toward making invalid programs unrepresentable.

Why the borrow checker feels brutal (and why that’s the point)

The borrow checker is the compiler’s way of answering a question that most languages leave to humans: Who owns this memory, and who is allowed to access it?

In C and C++, you can write code that compiles while violating the rules of safe access. Those bugs can hide for years—until a particular timing window, optimization, or input triggers them. Unit tests might catch them occasionally, but tests are sampling, not proof.

Rust attacks the root cause by enforcing rules about borrowing:

You can have either one mutable reference or any number of immutable references, but not both at the same time.
References must not outlive the data they point to.
Aliasing mutable state in ways that lead to races or invalid access is rejected early.

The result is the “brutal” experience you hear about: the compiler stops you from continuing until your intent is precise. That pressure is uncomfortable—because it’s replacing habits you didn’t realize you had. But it’s also why Rust tends to produce a distinct kind of confidence: not “I think it works,” but “this can’t go wrong in these specific ways.”

A quick example: the bug Rust prevents

Imagine you have a function that returns a reference to data owned by a local variable. In C++, it might compile and appear to work, until it doesn’t—classic dangling reference territory.

In Rust, the compiler requires lifetimes to be coherent. If your reference would outlive the data, Rust refuses to compile the program. That’s not pedantry; it’s reliability.

“Memory safety without garbage collection” isn’t marketing—it’s engineering

Garbage collection (GC) helps manage memory lifetime, but it comes with tradeoffs: pauses, runtime overhead, and sometimes design constraints. Rust takes a different approach: it uses ownership and borrowing to ensure memory safety at compile time, not runtime.

Here’s the high-level model:

Each value has an owner.
When the owner goes out of scope, the value is dropped deterministically.
Moving values transfers ownership safely.
Borrowing creates references that Rust tracks with lifetimes.

This doesn’t just prevent memory bugs. It changes your system design. You start to think in terms of:

Where state truly belongs
How data should flow
What should be shared (and how safely)

And yes—this is why people often say they “can’t go back.” Once you’ve felt the compiler guard your invariants, writing code that can silently violate them starts to feel like borrowing trouble.

The C++-to-Rust experience: same power, fewer landmines

Every C++ developer I’ve seen try Rust eventually reports the same arc:

Confusion: “Why is the compiler yelling at me?”
Frustration: “Why does this need so many lifetimes?”
Breakthrough: “Oh. The compiler is forcing me to state my intent.”
Relief: “I’m no longer afraid to refactor this module.”

Rust doesn’t remove low-level control. It gives you control with guardrails. For teams migrating incrementally, that can be a big deal: you can adopt Rust for performance-critical components, security-sensitive services, or developer productivity hotspots without boiling the ocean.

Practical migration strategies include:

Build a small Rust library for a well-defined task (parsing, indexing, crypto wrappers, data validation).
Expose a stable API to the rest of the system.
Let Rust own the tricky safety invariants internally.
Gradually expand scope once the team trusts the workflow.

Rust also interoperates with C and C++ through well-established approaches, so you’re not forced into “rewrite everything” thinking. The goal is to shrink the surface area of memory-unsafe code, not to torch your existing architecture.

Unit tests are great—Rust makes them less necessary for some bugs

It’s tempting to treat Rust as “tests, but with fewer failures.” That’s wrong. Tests are still essential. What Rust does is eliminate entire categories of problems before you run anything.

Consider the kinds of issues that often slip past unit tests:

Use-after-free that only happens under a specific timing pattern
Data races that appear only with thread scheduling variability
Rare lifetime bugs that show up in production inputs
Refactors that accidentally invalidate assumptions

Rust’s guarantees apply even when your tests are thin, your input space is incomplete, and your team is under pressure. That matters because real-world software rarely enjoys ideal test coverage.

The real payoff is psychological and operational. When you refactor, you’re not just asking “Will tests pass?” You’re asking “Will the compiler accept the new ownership and borrowing relationships?” The compiler becomes a safety net that doesn’t depend on what you thought to test.

Learning Rust: how to avoid getting stuck on the hardest parts

The borrow checker is real, and yes, it can take time. But you don’t need to “get everything” immediately. You need a path.

Here are practical ways to learn without burning out:

Start small and work outward. Write simple functions, then gradually add references, structs, and collections.
Treat the error messages like puzzles. They’re not always perfect, but they often contain the exact rule you violated.
Prefer owned data first. Use borrowing when you actually need it for performance or to avoid copies.
Use the compiler as a tutor. Don’t fight it for hours—iterate, adjust, recompile.
Learn the standard patterns. Most Rust code you’ll write involves familiar shapes: Option/Result, iterator chains, structs with lifetimes where needed, and concurrency primitives that enforce safety.

One mindset shift helps more than any trick: when Rust complains, it’s not accusing you of being careless—it’s asking you to clarify your intent. If you respond by making ownership and access explicit, the language starts to feel less like a gatekeeper and more like a collaborator.

And if you’re already comfortable with systems concepts—memory layout, pointers, lifetimes in principle—you’ll adapt faster. Rust rewards that mental model, just with stronger enforcement.

Conclusion: you’re not choosing a language—you’re choosing fewer regrets

Rust is worth learning because it turns memory safety into a compile-time guarantee. It’s also worth learning because it changes how you structure software: you stop treating “correctness” as an afterthought and start treating it as something the toolchain should enforce.

If you’re considering Rust, don’t ask whether you can afford the learning curve. Ask whether you can afford to keep building and maintaining code that lets entire classes of memory and concurrency bugs slip through until production proves you wrong. Your future self will notice the difference—every time you refactor without fear.

Why I Still Reach for Python When Speed Doesn't Matter

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 15 Feb 2022 00:00:00 +0000

Every time someone posts a benchmark screenshot, it turns into the same argument: “Python is slow.” Sure—sometimes it’s very slow. But for most software I build and maintain, speed is not the constraint. Clarity is. Ecosystem depth is. The ability to prototype, iterate, test, and ship is what keeps projects from stalling. In that world, Python remains my default—then I optimize the few places that truly deserve it.

Python’s real reputation: slow where it matters least

Let’s get something out of the way: Python can be slower than compiled languages for CPU-bound workloads. That’s not a myth; it’s a design trade-off. Python emphasizes expressiveness and a rich runtime over raw execution speed.

But the “Python is slow” argument often collapses the real question into a single metric. Your application rarely spends its entire time in Python bytecode. It might wait on a database, call an external API, stream data over the network, block on I/O, or spend most of its life in glue code—moving information between systems.

Consider a common internal tool: a small service that ingests customer events, normalizes them, writes rows to a warehouse, and triggers alerts. The hot path isn’t “how fast can Python add integers?” The hot path is “how quickly can we understand the data, handle edge cases, add retries, and ship the feature without breaking production?”

In that scenario, Python isn’t the bottleneck—because your biggest delays are human and architectural: unclear requirements, missing instrumentation, brittle integration logic, and slow feedback loops.

Readability is a performance feature (and Python wins that battle)

Speed isn’t just CPU cycles. It’s also the time it takes humans to understand and safely change code. Python’s biggest advantage for most teams is that it reads like an executable explanation.

A few practical examples I’ve seen play out repeatedly:

Data transformations: If you’re mapping, filtering, grouping, and reshaping data (pandas-style patterns), Python makes the intent obvious. Colleagues can review logic quickly and catch bugs earlier.
Automation and orchestration: Scripting the workflow—fetching data, running jobs, reporting results—becomes straightforward. The code communicates “what happens” more than “how to fight the compiler.”
API handlers and glue logic: The messy parts of software—validation, serialization, retries, error messages—are where clarity prevents outages.

When readability improves, you get compounding benefits: fewer regressions, faster onboarding, and less time spent debugging “what this code is trying to do.” That’s real performance, measured in engineering time and reliability—not in microseconds.

If you want a rule of thumb: if the code is hard to read, it will be hard to optimize later. Python’s readability keeps the path open for incremental improvements instead of forcing rewrites.

The ecosystem depth is the real reason Python keeps winning

The second reason I reach for Python is the ecosystem. Python isn’t just a language—it’s a collection of libraries that solve high-leverage problems without you having to become an expert in everything at once.

When you’re building software in these categories, Python gives you an enormous head start:

Data pipelines and ETL: You can move and transform data quickly with mature tools, and you can integrate with warehouses and streaming systems without wrestling too much boilerplate.
Scientific computing and data analysis: If your project involves modeling, simulation, or analytics, Python’s package ecosystem is simply deep.
Automation and DevOps-adjacent tooling: From scripting to workflow orchestration, Python tends to be the “glue language” that keeps teams moving.
APIs and backend services: Modern frameworks make it easy to build consistent interfaces, validate inputs, and add observability.

In practice, the “time-to-value” advantage dominates. Suppose you’re building a service that predicts something based on historical features. Even if you could write the math in C++ or Rust, you’ll still need data access, feature engineering, evaluation, logging, and iteration. Python tends to be where that work gets done fastest—and the model quality improves faster because you can experiment without friction.

And yes: production-grade Python is common. You can scale it with the right architecture: background workers, horizontal scaling, caching, and careful I/O. Raw interpreter speed is only one variable in the system.

Time-to-prototype beats theoretical throughput for most work

Most projects don’t fail because they’re “too slow.” They fail because they’re unclear, incomplete, or wrong.

Python accelerates the most important early phase: turning ideas into working software that can be tested against reality. That includes:

building a minimal end-to-end pipeline,
validating inputs and assumptions,
writing tests for behavior (not just for code paths),
and getting feedback from users or stakeholders.

A concrete example: imagine you’re tasked with building a data pipeline that ingests logs, extracts fields, and populates a dashboard. The first iteration will probably be wrong. You’ll discover missing fields, inconsistent formats, and “special cases” that only show up in production data.

If your prototype takes weeks to stand up because you chose a low-level approach, you’ll spend those weeks discovering issues more slowly. If your prototype is in Python and working in days, you can identify the real bottlenecks and refine the solution while everyone still has momentum.

That velocity matters so much that I treat it as a primary performance metric. In most teams, the time saved in iteration cycles and debugging outweighs any initial execution overhead.

Optimize like a professional: measure, isolate, rewrite selectively

The common compromise I recommend is simple and disciplined:

Write in Python first.
Profile the actual workload.
Identify the small fraction that truly costs time.
Rewrite only that portion in something faster—if needed.

This approach avoids the trap of premature optimization, where you “speed up” code that doesn’t matter while the real problems—data quality, correctness, and integration—remain unaddressed.

Here are practical tactics:

Use profiling tools to find hot spots, not guesses. You’re looking for the specific functions and loops that consume the majority of runtime.
Separate compute from I/O. If most time is waiting on the network or database, speeding up Python won’t help much; you’ll want better batching, caching, query tuning, or async I/O.
Move inner loops to vectorized or compiled paths where it fits the problem. Often you don’t need to rewrite the whole system; you just need to avoid Python-level iteration on large arrays.
Introduce caching at the edges. Many systems are slow because they recompute the same results repeatedly, not because arithmetic is expensive.
Keep the interface stable when rewriting. If you encapsulate a performance-critical function behind a narrow boundary, you can swap implementations without turning your project into a rewrite.

A pattern I’ve used successfully: keep business logic and orchestration in Python, but let numeric kernels live in optimized libraries (which may be written in C/C++ under the hood) or in compiled extensions when absolutely necessary. The result is usually a system that stays readable while still meeting performance requirements.

When Python isn’t the right tool (and what to do instead)

To be clear, there are cases where Python shouldn’t be your first choice—particularly when you have strict, predictable CPU-bound requirements and you know exactly where the time goes.

If you’re building a latency-sensitive service with tight budgets and high request rates, you may prefer a language with deterministic performance characteristics from the start. Or you may still build in Python but design the architecture so the low-latency portion is handled by a faster component, while Python remains the orchestration layer.

The key is not dogma. It’s architecture:

Use Python where productivity matters most: pipelines, APIs, integrations, and control-plane logic.
Use other languages or optimized runtimes where the bottleneck is truly compute-heavy and measurable.
Treat “performance” as a system property, not a language brag.

In other words: Python is my default, not my religion.

Conclusion: Python optimizes the work you can’t benchmark

Python’s weakness in raw execution speed is real. But in most software, speed is not the deciding factor. Readability reduces risk. The ecosystem reduces time-to-value. And selective optimization ensures you only pay complexity costs where they actually buy results.

So I’ll keep reaching for Python—not because it’s the fastest option, but because it’s the fastest path to correct, maintainable software that can evolve. Then, when performance truly matters, I’ll profile first and rewrite the 5% that earns it.

The Absolute State of CSS in 2022

abdecastro@protonmail.com (Antonio B De Castro) — Thu, 10 Feb 2022 00:00:00 +0000

For years, CSS felt like the language of “just make it line up.” Meanwhile, JavaScript got all the headlines: frameworks, state management, and the never-ending debate about what “the best way” is. But in 2022, CSS stopped being background music and started dropping feature-level power. Container queries, cascade layers, and :has() didn’t just polish the surface—they rewired how you design responsive, predictable interfaces without reaching for hacks or heavy scripts.

If you write UI, you should care. Not someday. Now.

Container Queries: Stop Punishing the Viewport

For as long as responsive design has existed, CSS has relied on the viewport as the source of truth. That’s an awkward choice: many components don’t live at the top level. They live in sidebars, cards, modals, tool panes, and grids—containers whose size may have nothing to do with the viewport’s width.

Container queries fix that.

The old way (viewport-based)

You might write:

.card .title {
 font-size: 1.25rem;
}

@media (max-width: 600px) {
 .card .title {
 font-size: 1rem;
 }
}

This implicitly assumes your card collapses when the viewport does. In real layouts, it’s the container that matters.

The modern way (parent-based)

With container queries, you define a container and then query its dimensions:

.card {
 container-type: inline-size;
}

.card .title {
 font-size: 1.25rem;
}

@container (max-width: 420px) {
 .card .title {
 font-size: 1rem;
 }
}

Now the title scales based on the card’s available width—whether that card is in a wide layout, a narrow column, or a collapsed drawer.

Practical advice

Use container-type: inline-size for width-driven components (most UI layout depends on inline size).
Name your containers conceptually. Even if you don’t have container names everywhere, keep your mental model clean: “This component responds to its own space.”
Replace brittle viewport media queries that target component internals. If your CSS targets .sidebar .widget differently depending on where it’s rendered, container queries are usually the correct escape hatch.

Cascade Layers: Make Specificity Boring Again

If you’ve ever said, “Why is this CSS not applying?” you already understand the pain cascade layers are designed to eliminate.

Traditional CSS specificity can turn the stylesheet into a battlefield:

Later rules win when specificity ties.
Higher specificity silently overrides lower specificity.
“Quick fixes” accumulate until the cascade becomes unmaintainable.

Cascade layers let you explicitly order groups of styles, so you stop playing whack-a-mole with specificity.

Think of layers as “priority buckets”

A clean pattern is:

Base styles
Component styles
Overrides (if you must)

@layer base, components, overrides;

@layer base {
 button {
 font: inherit;
 }
}

@layer components {
 .primary {
 background: #2563eb;
 color: white;
 }
}

@layer overrides {
 /* Intentionally last-resort */
 .primary {
 background: #1d4ed8;
 }
}

Even if .primary appears in multiple places, the layer order defines the outcome—without turning everything into !important or specificity gymnastics.

Practical advice

Put your framework-ish styles into one layer and your app overrides into another. You want the override layer to always beat the base layer, regardless of selector complexity.
Use layers to control “CSS ownership.” For teams, this is huge: a component author can ship styles without fear that random app-level selectors will accidentally bulldoze them.
Don’t treat layers as a magic wand. If everything goes into one layer, you’ve gained little. The value is in partitioning.

`:has()` : The Parent Selector You Always Wanted

:has() is the most developer-empathic feature in recent CSS memory. It lets you style an element based on its descendants—and it does so without JavaScript.

Yes, it’s effectively a parent selector.

The old way (JavaScript or extra markup)

Common pattern: “If a wrapper contains something that matches X, change the wrapper’s style.”

With JS you might:

Query the DOM
Check conditions
Toggle classes

Or you might add “state” classes manually.

The CSS way

Now you can write:

.card:has(.status-badge) {
 padding-top: 1.5rem;
}

Or:

.input-group:has(input:focus) {
 border-color: #2563eb;
}

This is a big deal because the UI state is already present in the DOM; :has() lets CSS react to it.

Practical advice

Use :has() to reduce “state class” boilerplate. Your markup already expresses the relationship—let CSS leverage it.
Prefer :has() for styling changes, not for heavy behavioral logic. CSS isn’t a state machine; it’s a renderer. Keep it focused.
Be mindful of performance in deeply nested or frequently changing DOMs. If you’re using it on large lists with constant mutation, measure. In most typical interface patterns, it’s a clean win.

Together, They Change How You Build Components

Individually, these features are excellent. Together, they feel like a tectonic shift in component design philosophy.

Consider a common UI card:

It should adjust internal layout based on its own width.
It should style itself differently depending on whether it contains certain elements.
It should not fight with global styles or third-party CSS overrides.

Before:

Viewport media queries determine structure.
JS toggles classes to represent internal conditions.
Specificity wars decide what wins.

After:

Container queries handle sizing.
:has() handles structural conditions.
Cascade layers handle stylesheet priority.

A cohesive example

@layer base, components;

@layer components {
 .card {
 container-type: inline-size;
 padding: 1rem;
 }

 .card:has(.warning) {
 border-color: #f59e0b;
 }

 .card:has(.warning) .title {
 font-weight: 700;
 }

 @container (max-width: 420px) {
 .card .meta {
 display: none;
 }
 }
}

No viewport assumptions. No manual state classes. No “why is my selector losing?” drama. Just declarative rules that match how the component behaves.

Stop Sleeping on Native CSS: Replace JavaScript With Rendering Logic

Here’s the uncomfortable truth: a lot of JavaScript UI logic exists because CSS couldn’t express certain relationships. With these features, some of that logic can move back to CSS, where it belongs.

Where CSS shines now

Layout adaptation based on parent sizing (container queries)
Conditional styling based on DOM structure (:has())
Predictable styling order across teams and dependencies (cascade layers)

Where you still need JavaScript

Real event-driven behavior (timers, network calls, complex interactions)
State that isn’t representable in the DOM structure (or isn’t stable enough)
Animations that require imperative control, not just style transitions

A practical migration mindset

Identify one UI component with:
- fragile media queries,
- class toggling based on DOM content,
- and “override by selector power” problems.
Replace viewport rules with container queries.
Replace “if it contains X, add class” logic with :has().
Put component styles into a dedicated cascade layer and reserve an override layer for app-level exceptions.

Do this incrementally. You don’t need to rewrite the entire frontend in a weekend. You just need to stop accepting that “CSS can’t do that” as a permanent limitation.

Conclusion: CSS Is Finally Playing the Same Game

2022 wasn’t just “nice-to-have” CSS. It was structural progress: container queries let components reason about their real space, cascade layers let styles stop fighting for dominance, and :has() gives CSS the missing parent-level awareness that developers have wanted for years.

If you’re still sprinkling JavaScript for styling conditions, betting your layout on viewport breakpoints, or relying on specificity tricks, you’re paying a tax that CSS no longer demands. Native CSS isn’t catching up—it’s already capable of a lot of what your frontend codebase does today. The real win is simple: let CSS render, and let JavaScript handle what only JavaScript can do.

TypeScript Is Not Optional Anymore

abdecastro@protonmail.com (Antonio B De Castro) — Tue, 01 Feb 2022 00:00:00 +0000

If you’re starting a new JavaScript project in 2022 without TypeScript, you’re not being “flexible.” You’re deliberately buying a future problem with interest. TypeScript has moved from preference to infrastructure: it’s how modern teams prevent avoidable bugs, document intent, and scale codebases without turning every refactor into a gamble.

JavaScript Without Types Is a Design Decision—Not a Default

Vanilla JavaScript isn’t “wrong.” It’s just ambiguous by default. When everything is dynamically typed, the language cannot help you catch mistakes that are obvious to humans: passing the wrong shape of data, calling a function with the wrong arguments, forgetting a field that another part of the app expects, or misunderstanding what a value can be.

That ambiguity might feel productive at the start. The first week is fast because you’re not fighting the compiler. But the cost shows up later when the project grows beyond a small script. The code becomes self-contradictory: naming suggests one contract, runtime reality enforces another. You end up relying on tests, runtime checks, and tribal knowledge to enforce what the type system could have enforced immediately.

My position is simple: if you’re building anything that will change—features, APIs, UI flows, integrations—then skipping types is not neutral. It’s a design decision that knowingly increases risk.

“Framework Support” Isn’t the Point—Tooling Feedback Is

Yes, most major frameworks now provide strong TypeScript support. That matters, but it’s not the whole story. The real advantage is feedback speed.

TypeScript turns the editor into a co-pilot:

Autocomplete becomes reliable because the IDE understands your data shapes.
Refactors become safer because renames and signature changes propagate through the codebase.
You can model domain concepts directly: UserId, OrderStatus, Email, Money—not just strings that “probably” mean the right thing.

Consider a typical bug pattern in JavaScript:

// JavaScript
function formatPrice(price) {
 return `$${price.toFixed(2)}`;
}

fetch("/api/order")
 .then(res => res.json())
 .then(order => {
 // order.total might be a string, or null, or missing
 document.body.textContent = formatPrice(order.total);
 });

This can fail at runtime in multiple ways—too late, often in production, and usually with vague error messages. With TypeScript you can encode the contract:

type Order = {
 total: number;
};

function formatPrice(price: number) {
 return `$${price.toFixed(2)}`;
}

// If order.total can be null or a string, TypeScript forces you to handle it.

Now the compiler becomes your first line of defense. That’s not “extra.” It’s a measurable reduction in avoidable bugs because you catch mismatches before you ship.

TypeScript Changes How You Think About APIs

A major reason TypeScript is worth it: it forces you to define interfaces. In other words, it makes your contracts explicit.

In JavaScript, API shapes often emerge indirectly: you infer them from usage. That works until it doesn’t. When multiple parts of the system (frontend, backend, worker processes) evolve independently, the “shape” of a thing becomes a rumor.

TypeScript helps you replace rumors with definitions. For example, if you have an API response for users:

type User = {
 id: string;
 email: string;
 displayName?: string; // optional means not always present
};

That single type becomes a shared source of truth. When someone adds displayName, removes it, or changes semantics, you’ll see the impact immediately. Even better: your IDE can guide developers to the right usage patterns because the type tells you what’s safe.

And yes, you still need runtime validation at boundaries (APIs, user input). TypeScript doesn’t eliminate runtime concerns; it prevents most internal confusion before it gets to the boundary. You stop treating “undefined behavior” as normal.

The Real Cost: Refactoring Without Confidence

Every team eventually hits the same wall: you want to refactor, but you can’t trust the codebase. The lack of types doesn’t just allow bugs—it blocks velocity.

Here’s what that looks like in practice:

Renaming a property becomes risky because there’s no reliable way to find all usages.
Changing a function signature leads to silent breakage when call sites aren’t updated correctly.
“We’ll fix it when it breaks” becomes the workflow.

TypeScript doesn’t magically make refactors perfect, but it makes them searchable. The compiler acts like a map of your code’s expectations. If your refactor changes a contract, TypeScript tells you where that contract is assumed.

In a larger system, that means fewer late surprises and less time spent hunting issues that should have been caught at development time. The payoff is compounding: the more you type, the easier it becomes to safely evolve the code.

Counterargument: “We’re Too Busy to Add TypeScript”

This is the most common pushback, and it sounds reasonable until you compare it to the cost of not doing it.

Adding TypeScript is usually incremental. You don’t need to “rewrite everything” before you benefit. In many projects, you can start by:

Converting the most critical modules first (data fetching, domain logic, API clients).
Enabling strictness gradually (or starting with a moderate level, then tightening over time).
Using JSDoc types temporarily in legacy files to establish contracts while you migrate.

You also don’t have to aim for perfection overnight. The goal is to start building type-aware confidence in the areas that change most frequently.

More importantly: if you’re “too busy” to add TypeScript to a new project, you’re also too busy to maintain a codebase where bugs are discovered later and refactors take longer. TypeScript is not a luxury feature—it’s an accelerant that reduces the time you spend cleaning up avoidable problems.

Practical Rule: Type the Edges, Then Type the Core

The easiest way to get value without boiling the ocean is to apply a simple strategy:

Type the edges

Anything entering or leaving your system is a boundary:

HTTP requests and responses
WebSocket messages
Worker events
Form inputs and user-generated content

Define the types for those payloads. Then enforce them at runtime if needed. This prevents the “undefined becomes a string becomes a crash” class of bugs.

Type the core

After the edges, focus on the code that represents your domain:

business rules
calculations
state transitions
permission checks
mapping from API data to UI models

When your core is typed, the rest of the system becomes easier to understand and harder to misuse. That’s where TypeScript pays off most.

A small example: if you have a reducer managing UI state, types make illegal states unrepresentable. In JavaScript, “impossible” states still happen constantly because nothing stops them. In TypeScript, you can force the code to reflect reality—because the compiler won’t let you lie about it.

Conclusion: New Projects Shouldn’t Start With Hidden Risk

TypeScript isn’t optional anymore because modern development isn’t just about running code—it’s about building systems that evolve. If you start a new JavaScript project without TypeScript, you’re accepting a workflow where correctness depends on memory, tests, and luck.

TypeScript gives you earlier feedback, clearer contracts, safer refactors, and a codebase that scales without becoming haunted. If you’re building in 2022—and you want to move fast without breaking things—TypeScript isn’t an add-on.

It’s the baseline.