DEV Community: Tyson Cung

How APIs Actually Work — The Simplest Explanation You'll Find

Tyson Cung — Sat, 11 Apr 2026 23:49:36 +0000

APIs are everywhere. Every app you use talks to other services through APIs. And yet most explanations make it more complicated than it needs to be.

Let me give you the clearest version I know.

The One Analogy That Works

An API is a waiter.

You're at a restaurant. You don't go into the kitchen. You don't cook the food yourself. You tell the waiter what you want, the waiter goes to the kitchen, the kitchen prepares it, and the waiter brings it back to you.

You never interact with the kitchen directly. The waiter is the interface.

In software:

You're the app (or the developer making the request)
The waiter is the API
The kitchen is the server/database with the data
The food is the response

That's it. That's what an API is.

What Actually Happens When You Use One

Say you're using a weather app. You type in your city and see the current temperature.

Behind the scenes:

The app sends a request to a weather API: "Give me the current temperature for Melbourne"
The API server receives that request
The server looks up the data (from weather sensors, satellites, whatever)
The server sends back a response: {"city": "Melbourne", "temperature": 22, "unit": "celsius"}
Your app reads that response and shows you "22°C"

The whole thing happens in milliseconds. You see a number. The app made an API call.

REST — The Standard

Most APIs you'll encounter are REST APIs (REpresentational State Transfer). REST isn't a technology — it's a set of conventions about how requests and responses should work.

The key ideas:

Resources — Everything is a resource with a URL. A user is /users/123. A list of products is /products. A specific order is /orders/456.

HTTP Methods — Different operations use different methods:

GET — Read data
POST — Create something new
PUT/PATCH — Update something
DELETE — Remove something

Status Codes — Responses include a number telling you what happened:

200 — Success
201 — Created
400 — Your request is wrong
401 — Not authenticated
404 — Not found
500 — Server error

JSON — Data travels in JSON format (key-value pairs, like a dictionary). Easy for both humans and machines to read.

A Real Example

Say you're building an app that shows GitHub repos. You'd call:

GET https://api.github.com/users/tysoncung/repos

GitHub's API receives that request, finds the repos for that user, and sends back a JSON array with all the details. Your app loops through that array and displays them.

You didn't need access to GitHub's database. You didn't need to know how their servers work. You just followed their API documentation and made a request.

Why APIs Matter

For developers: APIs let you build on top of existing services instead of reinventing everything. Need payments? Stripe API. Need maps? Google Maps API. Need user authentication? Auth0 API. Your app becomes a composition of specialized services.

For companies: APIs are how products become platforms. Twitter opened their API and an entire ecosystem of clients and tools emerged. Stripe's API is why developers love them — it's clean, well-documented, and predictable.

For you as a learner: Once you understand APIs, a massive part of modern software development clicks. Every mobile app, most web apps, and increasingly even desktop apps are built around API calls.

What You Should Learn Next

If you want to go deeper:

Authentication — How do APIs know you're allowed to make requests? (API keys, OAuth, JWT)
Rate limiting — Why APIs restrict how many calls you can make
Webhooks — The reverse of an API call: the server pushes data to you instead of you pulling it
API documentation — How to read and use API docs (Swagger/OpenAPI)

But for 80% of what you'll do as a developer, the waiter analogy is all you need to hold in your head. Request, response, JSON, HTTP methods. The rest is details.

What was the first API you integrated? What made it click for you?

Claude Code vs Codex CLI — Two Terminal Coding Agents, One Honest Comparison

Tyson Cung — Sat, 11 Apr 2026 23:48:30 +0000

The terminal got interesting. AI coding started in IDEs with Copilot autocomplete, moved to chat interfaces, and now we've got full agents that run inside your terminal and can edit code, run tests, and loop until they get it right.

Claude Code (from Anthropic) and Codex CLI (from OpenAI) are the two most talked-about examples of this. I've used both. Here's what actually matters.

What They Are

Claude Code is Anthropic's CLI that brings Claude Sonnet/Opus directly into your terminal. You run claude from inside a git repo, give it a task, and it reads files, writes code, runs commands, and iterates. It operates with explicit permission prompts before making changes, which is either reassuring or slow depending on your mood.

Codex CLI is OpenAI's terminal agent, using GPT-4 (and now GPT-4.1 class models). Similar concept: runs in your repo, takes tasks, makes changes. OpenAI's approach gives it a bit more autonomy by default — it'll chain commands without as many interruptions.

The Core Experience

Both are surprisingly capable at well-scoped tasks. "Add error handling to this function," "write tests for this module," "refactor this to use the strategy pattern" — these work well in both. You describe what you want in natural language, the agent reads your code, and it produces a reasonable implementation.

The difference shows up at the edges.

Claude Code is better at understanding context in large codebases. Anthropic has invested heavily in Claude's ability to hold large amounts of code in context and reason about the relationships between files. When I give it a task that touches five different modules, it tends to understand the architecture and make changes that are consistent with existing patterns.

Codex CLI is faster for single-file tasks. It's snappier, iterates quickly, and feels more aggressive (in a good way) about just getting things done. For focused tasks — fix this function, implement this endpoint — it's often the quicker path.

Agentic Behavior

Codex CLI is more autonomous. It'll chain tool calls, run tests, see failures, and try fixes without stopping to ask you. Sometimes this is great. Sometimes it goes down a rabbit hole. You can set safety levels (--approval-mode flags) to control how much it acts without permission.

Claude Code is more collaborative. It shows you what it's planning to do and waits for confirmation before executing. This feels slower but means you're always aware of what's happening. For production code, I actually prefer this — I want to review changes before they hit the filesystem.

Model Quality

This is the hard part to compare because it changes with every model update. Both agents are essentially wrappers around powerful LLMs, and the model quality matters more than the agent shell.

Right now: Claude's reasoning on complex architectural questions tends to be better. GPT-4 class models have slightly better code style consistency in my experience, particularly for Python and TypeScript.

Both will make mistakes. Neither replaces code review. The agent loop (write → run → fail → fix) helps catch some errors automatically, but you still need to read what it produces.

Pricing

Both are pay-per-use via API tokens. For intensive coding sessions, costs add up quickly — I've spent $5-10 in a session doing heavy refactoring. Neither is "free" at serious usage volumes.

Claude Code has a subscription tier through Anthropic's API. Codex CLI uses OpenAI API credits.

The Honest Take

If you're doing large codebase work, complex architectural changes, or tasks that require understanding how many parts of a system interact: Claude Code.

If you want a fast, aggressive agent for focused tasks and you're comfortable with more autonomous behavior: Codex CLI.

Both are worth trying. Neither is the magic wand that writes your code for you. They're tools that handle the tedious parts better than they used to, and they're getting better fast.

Are you using AI terminal agents yet? What's been your experience?

Your Dashboard Numbers Are Wrong — And Your Team Is Making Decisions Based on Them

Tyson Cung — Sat, 11 Apr 2026 23:47:58 +0000

I've sat in too many meetings where someone points at a number on a dashboard and says "look, it's working" or "look, it's broken" — and the number is measuring the wrong thing, or measuring the right thing wrong, or both.

This isn't a data engineering problem. It's a measurement problem. And it's more common than anyone wants to admit.

Why Dashboard Numbers Lie

Problem 1: The metric was defined in a meeting, not in code

Someone says "we need to track active users." Everyone nods. Nobody asks what "active" means. Is it users who logged in today? Users who performed any action? Users who performed a meaningful action (not a bot ping)? Users who paid?

The engineer implements something. The product manager had something different in mind. The exec reading the dashboard has a third interpretation. The number exists, it changes over time, and everyone is confidently wrong about what it means.

Fix: Define metrics in writing before building. "Active user: a user account that submitted at least one form in the last 30 days, excluding accounts marked as test or internal." That's a spec, not a vibe.

Problem 2: The data pipeline has bugs

Metrics pipelines are production code. They fail, they drift, they have edge cases. But unlike application bugs that show up as broken features, data bugs show up as slightly wrong numbers. Slightly wrong numbers are the most dangerous kind because they feel believable.

A query that's double-counting events because someone joins the wrong way. A timezone issue that moves events between days. A column that changed meaning when the schema evolved but the query didn't update.

Nobody knows these exist. The dashboard looks fine. Decisions get made.

Fix: Treat your data pipeline like you treat application code. Tests, code review, alerts when outputs go outside expected ranges. "This metric dropped 40% overnight" should be an automated alert, not something someone notices in a quarterly review.

Problem 3: The metric is easy to measure, not important to measure

Page views. Email opens. Time on site. These are easy to measure and frequently wrong proxies for what you actually care about.

Page views go up if your site is slow and people reload. Email opens are inflated by Apple's Mail Privacy Protection. Time on site goes up if your UX is confusing.

You optimize for what you measure. If you measure the wrong thing, you optimize in the wrong direction.

Fix: Work backward from business outcomes. What does success actually look like? Revenue, retention, task completion rate, NPS. Then find metrics that lead to those outcomes. Resist the urge to track what's easy.

Problem 4: Survivorship bias in the sample

Your dashboard probably shows data about the users you have. It probably doesn't show you much about the users you lost.

Churn dashboards that only track reasons given by departing customers miss the 60% who leave without clicking the feedback button. Conversion funnels show where people drop off but not why. Satisfaction scores track satisfied users more than dissatisfied ones who've already moved on.

Fix: Design for the data you don't have. Exit surveys. Cohort analysis that follows users from signup through churn. Win/loss interviews. The data you're missing is often more important than the data you have.

The Uncomfortable Conclusion

Most dashboards tell you what happened. The useful question is why it happened and whether it matters.

A metric without context is just a number. "DAUs up 12%" is not useful without knowing whether that's a trend or a spike, whether it's driven by the user segment you care about, and whether it maps to outcomes that actually matter for the business.

The best data teams I've seen spend more time on measurement strategy — defining what to track and why — than they do on building pipelines. The pipeline is the easy part. Getting the right number is hard.

What's the most misleading metric you've ever seen a team optimize for? I want to hear the stories.

AWS vs Azure vs GCP — Which Cloud Should You Learn in 2026?

Tyson Cung — Sat, 11 Apr 2026 23:47:27 +0000

This is the cloud question that comes up in every bootcamp, every career change conversation, and every "where should I focus" thread on Reddit. The answer isn't as complicated as the cloud vendors want you to think.

The Market Reality

AWS holds roughly 30% of the cloud market. Azure is around 22%. GCP sits at about 12%. The rest is distributed across other providers.

This matters because it tells you where the jobs are. AWS has the most adoption across the broadest range of companies — startups, enterprises, government, everything. Azure dominates in enterprises that are already deep in the Microsoft ecosystem (Office 365, Active Directory, .NET). GCP is strong in companies doing heavy data/ML work and startups that want to run Kubernetes on managed infrastructure.

If you're optimizing for job market breadth, AWS first.

AWS — The Default Choice

AWS has the widest service catalog (200+ services), the deepest documentation, and the largest community. There are more Stack Overflow answers, more YouTube tutorials, more blog posts, and more job postings for AWS than the other two combined.

The certification path is mature — Solutions Architect Associate is recognized across the industry and genuinely tests useful knowledge. The downside is complexity: AWS grew organically and the UI is notoriously confusing. Some services exist for historical reasons that no longer make sense. The pricing is opaque.

Learn AWS if: You want the widest job options, you're going into a startup or general tech company, or you're targeting cloud engineering as a career.

Azure — The Enterprise Path

If you're already working at a company in Microsoft's orbit (Windows, Office, SQL Server, Active Directory), you're probably already touching Azure or about to. Azure's integration with Microsoft's identity systems and developer tooling is genuinely better than the alternatives for Windows-heavy shops.

Azure DevOps is a legitimate competitor to GitHub Actions for enterprise CI/CD. Azure Active Directory (now Entra ID) is how most large enterprises handle identity. If you want to work in enterprise IT and cloud, Azure knowledge is often more valuable than AWS knowledge.

Learn Azure if: You're targeting enterprise clients, your company is Microsoft-heavy, or you're coming from a traditional IT background.

GCP — The Data/ML Play

Google's cloud has historically punched below its weight in enterprise adoption but has genuine technical advantages in certain areas. BigQuery for data warehousing is legitimately best-in-class. Vertex AI for ML workloads is excellent. GKE (Google Kubernetes Engine) is arguably the easiest managed Kubernetes to operate.

If you're going into data engineering, ML engineering, or you want to understand Kubernetes deeply, GCP is worth learning. The job market is smaller but the roles tend to be more specialized and often pay well.

Learn GCP if: You're going into data engineering, ML, or you want to work at companies that run large-scale data infrastructure.

The Real Answer

Learn one deeply, understand the others at a conceptual level.

The fundamentals transfer: VMs, storage, networking, databases, serverless functions, IAM — every cloud does these things. Once you understand how AWS does it, Azure and GCP are variations on the same theme. The vendor-specific details matter for day-to-day work but the concepts are portable.

Most companies that ask for "cloud experience" in a job posting are happy with any cloud background. They'll train you on their specific vendor. What they actually want to know is whether you understand how cloud infrastructure works.

So: pick the one most relevant to the jobs you want, get certified (it signals commitment and tests real knowledge), and don't overthink the choice. In 12 months you'll have enough experience that the original pick matters less than you think.

Which cloud are you using? Did you deliberately choose it or just end up there? Tell me below.

Windsurf vs Cursor — Two AI IDEs Walk Into a Bar

Tyson Cung — Sat, 11 Apr 2026 23:46:57 +0000

The AI-native IDE wars are heating up. For a while, Cursor was the obvious choice if you wanted an editor built around AI coding. Then Codeium shipped Windsurf and claimed the throne for a minute. Now we've got two serious contenders and developers trying to figure out which one to actually use.

I've been switching between both. Here's my take.

What Are We Actually Comparing?

Cursor is a VS Code fork with AI deeply integrated — not as an extension, but as first-class functionality. Tab completions, Cmd+K inline edits, the Composer (now called Agent) for multi-file edits. It uses a mix of frontier models and caches aggressively to keep latency low.

Windsurf is Codeium's full IDE, also VS Code-based, with their "Cascade" agent as the centerpiece. Cascade can take on multi-step tasks autonomously, browse the web, run terminal commands, and edit across multiple files. It's marketed as the more "agentic" of the two.

Day-to-Day Editing

Cursor wins here for most developers. The Tab completion is genuinely magical — it predicts multi-line edits with high accuracy, and the Cmd+K inline edit mode is fast and reliable. The UX has been refined over years of iteration.

Windsurf's editing experience is good but plays second fiddle to Cascade. If you're not using Cascade, you're leaving most of Windsurf's value on the table. The basic completions are solid (it's Codeium under the hood) but don't feel as polished as Cursor's Tab.

The Agentic Story

This is where Windsurf pulls ahead — or at least, where it's making its bet. Cascade is more autonomous than Cursor's Agent. It'll plan a task, execute steps, check its work, and loop back when something fails. For big refactors or implementing features from scratch, Cascade can handle more without needing you to guide it.

Cursor's Agent has caught up significantly in recent updates. It's also now capable of multi-file edits, running tests, and iterating. But in my experience, Cascade still takes on messier tasks with less hand-holding required.

That said, agentic AI is still unreliable enough that I don't trust either to run unsupervised on important code. Both are tools that require oversight.

Performance and Stability

Cursor is more stable. It's older, more battle-tested, and the VS Code base it's built on is rock solid.

Windsurf has had more rough edges in my testing — occasional slowdowns, Cascade sometimes losing track of what it was doing, and the occasional crash. It's improving quickly, but if stability matters to you (and it should), Cursor is the safer choice right now.

Pricing

Cursor: $20/month Pro, includes fast requests to frontier models and unlimited slower requests.

Windsurf: $15/month Pro. Codeium's free tier works in Windsurf for basic completions. Cascade is usage-limited on free.

Who Should Use Which

Cursor is the better default choice. It's more polished, more stable, and the Tab completion is class-leading. If you're a developer who wants AI that enhances how you already work, Cursor nails it.

Windsurf is worth trying if you're excited about agentic workflows and willing to tolerate some rough edges for the payoff of a more autonomous AI. If Cascade's roadmap keeps improving, this could flip.

Both are far better than using Copilot in a regular VS Code window. The fully integrated experience — completions, chat, and agents in one tool — changes how you code in a way that extensions just don't.

The honest answer: try both. They both have free tiers. Your preference will probably come down to whether Tab completion or Cascade resonates more with how you think about writing code.

Cursor or Windsurf person? Or are you still on vanilla VS Code? Let me know.

GitHub Copilot vs Codeium — I Used Both for a Month. Here's What I Actually Think.

Tyson Cung — Sat, 11 Apr 2026 23:46:28 +0000

The AI coding assistant market split somewhere between "pay for quality" and "free is good enough." GitHub Copilot sits squarely in the first camp. Codeium decided to be the second.

I've spent the last few months switching between them on real projects — not demos, not tutorials, just actual work. Here's what I found.

What Each Is Trying to Do

GitHub Copilot is built on OpenAI's Codex (and increasingly GPT-4 class models) with GitHub's training data advantage. It's deeply integrated into VS Code, JetBrains, and a growing list of editors. At $10/month individually or $19 for Business, it's not cheap for a single developer but is reasonable for a team.

Codeium is free for individuals and positions itself as the "Copilot but without the paywall." It covers 70+ languages, supports VS Code, JetBrains, Neovim, and a bunch of others. Enterprise tier exists for teams.

Completion Quality

Copilot has better context over larger files. When I'm in a module with 300+ lines, Copilot tends to understand the patterns I've established and suggests completions consistent with my code style. Codeium's suggestions are good but occasionally feel disconnected — like it's completing based on the local context without understanding the broader patterns.

For boilerplate (CRUD operations, tests, simple transformations), Codeium is nearly as good. The gap shows most on complex logic or when you're building on top of patterns you've established in the same file.

Speed

Codeium is faster. Noticeably so. I think this is partly infrastructure (they've clearly invested in latency) and partly model architecture choices. When I'm in a flow state and just want completions quickly, Codeium's responsiveness beats Copilot.

Copilot's latency is acceptable — maybe 300-500ms for suggestions — but Codeium regularly comes in under 200ms in my experience. That's a real difference when you're completing several lines per minute.

Chat / Explain Features

Copilot Chat (requires the separate chat extension or VS Code's built-in integration) is genuinely useful for explaining code, generating tests, and refactoring suggestions. The conversation quality is good.

Codeium also has a chat feature and it's solid, but Copilot Chat has the edge on nuanced requests. When I ask "what's wrong with this function" and there are three issues, Copilot is more likely to catch all three.

Privacy Tradeoffs

This is where many teams make their decision. Copilot Business offers code snippet exclusion (your code doesn't get used to train the model), dedicated enterprise options, and clearer compliance documentation.

Codeium's free tier privacy policy is... less detailed. For hobby projects and personal learning, this doesn't matter. For work on proprietary codebases, read the fine print before installing it.

The Actual Verdict

If you're a student, learning to code, working on open source, or just can't justify $10/month — Codeium is excellent for free. Don't let "free" make you assume it's bad. It genuinely accelerates your workflow.

If you're working on commercial software, especially in a team environment, Copilot's quality edge and clearer enterprise policies make the $10-19/month worth it. The suggestions are better on complex code, and the peace of mind on data handling is real.

The competition between them is good for developers either way. A year ago there was no credible free alternative to Copilot. Now there is. That's kept Copilot honest and improved both products.

Which AI coding tool are you using? Have you switched recently? Tell me in the comments.

Why Most APIs Fail — 3 Mistakes That Kill Developer Experience

Tyson Cung — Sat, 11 Apr 2026 23:45:56 +0000

I've integrated hundreds of APIs over the years. Some were a pleasure. Most were a chore. A handful were genuinely painful experiences that made me question the life choices that led me to this career.

The frustrating part: the same three mistakes show up over and over. They're not exotic bugs. They're design decisions that seemed fine at the time and became load-bearing walls of confusion later.

Mistake 1: Inconsistent Naming

This sounds trivial. It isn't.

I once integrated with an API where the user ID was called userId in the auth endpoints, user_id in the profile endpoints, and uid in the events endpoints. Same field. Three names. Zero documentation explaining why.

Inconsistent naming forces developers to check the docs for every single call. It breaks the intuition that good APIs build — the feeling that you can guess what a field is called because everything follows the same pattern.

The fix is boring: pick a convention (camelCase, snake_case, kebab-case — doesn't matter which) and use it everywhere. Make a linter rule if you have to. Never let "we just called it something different here" ship to production.

Bonus failure mode: Naming things what they are today, not what they'll need to be. isAdmin becomes a lie the moment you add a second role type. premiumUser breaks when you launch three tiers. Use abstract names that survive your roadmap.

Mistake 2: No Versioning

Every API will change. If you're not versioning, you're setting up for one of two bad outcomes:

You never change anything because you're afraid of breaking integrations (stagnation)
You change things and break integrations (chaos)

Versioning buys you the ability to evolve without punishing your existing users. /v1/users stays stable. /v2/users adds the new fields. Clients migrate on their schedule, not yours.

The most common excuse for not versioning: "We'll add it when we need it." By the time you need it, you have production clients that assume the unversioned endpoint is permanent. Adding a version prefix to existing routes is a breaking change. You've trapped yourself.

Start with versioning. Even if v1 never changes, having the habit in place means v2 doesn't cause a crisis.

URL vs Header versioning: Both work. URL (/v1/endpoint) is more visible and easier to debug. Header versioning (Accept: application/vnd.api+json;version=2) is cleaner architecturally but harder to test in a browser. Pick one and document it clearly.

Mistake 3: Poor Error Responses

This is the one that makes me lose my mind most often.

{"error": "Something went wrong"}

That's not an error response. That's an apology. It tells me nothing I can act on.

A good error response tells me:

What went wrong (specific, not generic)
Why it went wrong (validation failure? rate limit? bad auth?)
What I can do about it (retry? fix the request? check my credentials?)

The gold standard:

{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "The 'email' field must be a valid email address",
    "field": "email",
    "docs": "https://api.example.com/docs/errors#VALIDATION_ERROR"
  }
}

I can read that, understand it, and fix my request without a support ticket.

Also: use the right HTTP status codes. 200 OK with an error body is a crime against HTTP. 401 vs 403 is not interchangeable. 404 vs 410 (gone vs not found) matters for caching behavior. These distinctions exist for a reason — use them.

The Real Cost of Getting This Wrong

Bad API design doesn't just frustrate developers. It costs you:

Support time — most support tickets are "what does this error mean" or "where is this field"
Integration time — slow, painful integrations mean fewer third-party developers bother
Churn — if your API is harder than a competitor's, the technical buyer notices

The best APIs are the ones where developers get to the first successful call in under 10 minutes. That's the goal. Consistent naming, versioning from day one, and real error responses get you most of the way there.

The boring stuff is usually the most important.

Which API gave you the worst integration experience? I want to hear the horror stories.

Tech Debt Compounds Like Interest — And Most Teams Are Already Bankrupt

Tyson Cung — Sat, 11 Apr 2026 23:45:22 +0000

Tech debt is the one thing every dev knows is a problem and almost nobody actually deals with it until it's too late.

I've watched teams go from "we'll clean this up later" to "we can't ship anything without breaking three other things" in under a year. The compounding isn't a metaphor — it's mechanical.

What Actually Happens

Every shortcut you take today creates friction for every engineer who touches that code afterward. That friction slows decisions, causes bugs, and makes refactoring scarier than it needs to be.

Here's the thing about compound interest: small rates don't feel dangerous until you do the math. 10% compounding annually turns $1,000 into $6,727 in 20 years. Tech debt works the same way — a "quick hack" that saves 3 hours this sprint could cost 30 hours across the next six months as it calculates wrong, misleads other devs, and generates bug reports.

The Three Phases Teams Go Through

Phase 1 — Ignorance is bliss. The codebase is young, features ship fast, nobody talks about tech debt because there isn't much of it. This is the honeymoon.

Phase 2 — Accumulation. Deadlines get tight, shortcuts get taken. "We'll refactor this after launch" becomes a running joke. Each sprint adds more interest to the principal.

Phase 3 — The wall. New features take three times as long. Bugs reproduce only in production. Onboarding new engineers becomes a multi-week affair because nobody can explain how anything actually works. This is the phase teams call "rewrite" — and that's almost always the wrong answer.

Where It Actually Comes From

Not just "bad developers" cutting corners. More often:

Deadline-driven decisions — someone above the team decided the date, and engineering bore the cost
Evolving requirements — code written for spec A doesn't gracefully handle spec B three iterations later
Context loss — the original author left, the code lives on, nobody knows why it works the way it does
Tooling drift — the ecosystem moved on but the codebase didn't

The last one is underrated. Code written with React 16 patterns in a React 18 codebase isn't "wrong" exactly, but it's drag.

How to Actually Manage It

You can't eliminate tech debt. Trying to is its own form of inefficiency. What you can do:

Track it explicitly. Create tickets for known debt. Not a shame list — a backlog item with an actual cost estimate. "This authentication module has three known race conditions, estimated 2 days to fix properly." When it gets expensive enough, it gets prioritized.

Budget for it. Some teams do 20% of sprint capacity on debt reduction. Others do one full "hardening sprint" per quarter. Either works. Nothing earmarked means nothing happens.

Pay debt at the point of touch. Before adding a feature to a module, spend 30 minutes cleaning it up first. Boy Scout Rule: leave the codebase better than you found it. Marginal cost is low when you're already there.

Don't let it block you. Some debt is fine to live with. A poorly-named variable in a stable module nobody touches isn't worth a dedicated sprint. Save the effort for the high-traffic, high-churn areas.

The Real Cost

Here's what nobody says in the business meetings: tech debt is a transfer of cost from now to future-you. Your team isn't saving time by taking shortcuts. They're borrowing it. And the interest rate isn't fixed — it tends to go up as the codebase grows and the shortcut touches more things.

The teams that consistently ship fast, year over year, are usually the ones treating their codebase like infrastructure worth maintaining. Not perfect — just maintained.

If you're in Phase 2 right now, the best time to start was six months ago. The second best time is this sprint.

What's the most expensive piece of tech debt you've ever had to deal with? Drop it in the comments.

RAG vs Fine-Tuning — I've Used Both in Production, Here's What Actually Matters

Tyson Cung — Mon, 06 Apr 2026 07:51:27 +0000

Every AI team hits this fork in the road: do we bolt on RAG, or fine-tune the model? I've shipped both approaches in production systems, and the "right answer" is less about technology and more about what problem you're actually solving.

The Core Difference in 30 Seconds

RAG (Retrieval-Augmented Generation) keeps your base model untouched. At query time, you fetch relevant documents from a vector store and stuff them into the prompt. The model reads your data like a student reading notes during an open-book exam.

Fine-tuning changes the model's weights. You train it on your specific data so the knowledge becomes baked in. Closed-book exam — the student actually studied.

Two fundamentally different strategies. One gives context, the other changes cognition.

When RAG Wins

RAG is the right call when your data changes frequently. Customer support knowledge bases, product catalogs, internal wikis — anything where yesterday's answer might be wrong today. You swap out the documents, and the model immediately reflects the update. No retraining.

RAG also wins when you need citations. Because the model is working from retrieved chunks, you can point users to the exact source document. That's huge for compliance, legal, and any domain where "trust me" isn't good enough.

Cost is another factor. Setting up a vector database (Pinecone, Weaviate, pgvector) and an embedding pipeline is straightforward. You're looking at days of work, not weeks. A decent RAG system on GPT-4o or Claude costs pennies per query.

I've built RAG pipelines that went from prototype to production in under a week. Try doing that with fine-tuning.

When Fine-Tuning Wins

Fine-tuning shines when you need the model to adopt a specific style, tone, or behavior pattern that's hard to capture in a prompt. If you want your model to respond like a particular brand voice consistently, or follow a complex output schema without constant prompt engineering — fine-tuning is your move.

It's also better for specialized reasoning. A model fine-tuned on medical literature doesn't just retrieve facts; it develops intuitions about medical terminology, relationships between conditions, and how to weigh evidence. RAG can surface the right document, but the base model still reasons like a generalist.

Latency matters too. RAG adds a retrieval step — embedding the query, searching the vector store, ranking results, then generating. Fine-tuned models skip all that. For real-time applications where every millisecond counts, that overhead adds up.

The Decision Framework I Actually Use

Forget the theoretical debates. Here's how I decide:

Start with RAG if:

Your data updates more than monthly
You need source attribution
You have less than 10,000 training examples
Your budget is under $5K
You need it working this week

Consider fine-tuning if:

RAG retrieval keeps pulling irrelevant chunks
You need consistent style/format that prompt engineering can't nail
Latency requirements are tight (<200ms)
You have 10K+ high-quality labeled examples
The task is narrow and well-defined

Do both when:

You're building something serious. Most production systems I've seen at scale use a fine-tuned model with RAG for dynamic knowledge. The fine-tuned model handles reasoning and style; RAG handles freshness. This is where the magic happens.

Real Numbers

RAG setup cost: $500-2,000 (embedding pipeline + vector DB hosting). Per-query cost: $0.001-0.01 depending on model and chunk count.

Fine-tuning cost: $50-500 for the training run itself (OpenAI pricing for GPT-4o mini). But the real cost is data preparation — cleaning, labeling, and validating your training set easily takes 40-100 hours of human work.

Most teams underestimate the data prep for fine-tuning by 5-10x.

The Mistake Everyone Makes

Teams jump to fine-tuning because it sounds more sophisticated. "We fine-tuned our model" is a better conference talk than "we set up a vector database." But sophistication isn't the goal — solving the problem is.

I've seen a startup spend three months fine-tuning a model on their customer data when a RAG pipeline would have worked in a week and handled updates automatically. By the time their fine-tuned model was ready, half the training data was stale.

Start with RAG. Measure where it falls short. Fine-tune to fill those specific gaps. That's the path that actually works.

Quick Reference

Factor	RAG	Fine-Tuning
Setup time	Days	Weeks
Data freshness	Real-time	Snapshot
Cost to start	Low	Medium-High
Citation support	Built-in	Not native
Style control	Limited	Strong
Latency	Higher	Lower
Maintenance	Ongoing (data pipeline)	Periodic (retraining)

The AI space loves binary debates. RAG or fine-tuning. In practice, the answer is almost always "RAG first, fine-tune later, combine when needed." Skip the ideology and follow the data.

Event Sourcing Broke My Brain — Then Fixed My Architecture

Tyson Cung — Sat, 04 Apr 2026 12:07:27 +0000

I spent three years building CRUD apps before someone showed me event sourcing. My first reaction: "This is insane. Why would anyone store every change instead of just the current state?"

My second reaction, about two weeks later: "Oh. This is how everything should work."

Your Database Is Lying to You

A traditional database stores current state. Your user's account balance is $500. That's all you know. How did they get to $500? What happened yesterday? Was there a refund? A double charge? A disputed transaction?

With CRUD, you'd need separate audit tables, changelog triggers, and a prayer that nothing got missed. Most teams skip this entirely and discover the gap during an incident — when a customer says they were charged twice and your database says their balance is correct.

Event sourcing flips this. Instead of storing "balance = $500," you store every event that led there:

AccountCreated { balance: 0 }
DepositMade { amount: 1000 }
WithdrawalMade { amount: 300 }
TransferSent { amount: 200 }

The current balance is derived by replaying these events. You can always recalculate it. You can also answer questions that CRUD databases can't: "Show me every state this account has ever been in."

Banks Figured This Out Centuries Ago

Double-entry bookkeeping — invented in the 15th century — is event sourcing. You never erase a ledger entry. You append corrections. The running total is always derivable from the full history.

When a bank processes a refund, they don't go back and delete the original charge. They add a new entry: "Credit: $50, reason: refund for transaction #4821." The history is complete, auditable, and immutable.

Modern banking systems, payment processors like Stripe, and even Git itself all use this same principle. Git doesn't store your current codebase — it stores every commit, every change, in sequence. Your working directory is a projection of that event history.

The Three Core Pieces

1. Event Store — An append-only log. Events go in, nothing comes out (as in, nothing gets deleted or modified). Each event has a type, a timestamp, and a payload. The store is the source of truth.

2. Aggregates — Domain objects that process commands and emit events. When you tell a shopping cart to "add item," the cart aggregate validates the command and produces an ItemAdded event. The aggregate's current state is rebuilt by replaying its events.

3. Projections — Read-optimized views built from events. Think of them as materialized views that update whenever new events arrive. You might project the same events into a dashboard table, a search index, and an analytics database — each optimized for its specific query pattern.

This naturally leads to CQRS (Command Query Responsibility Segregation): writes go through aggregates and produce events; reads come from projections. The write model and read model are separate, scaled independently, optimized for their specific jobs.

A Concrete Example

Say you're building an e-commerce order system. With CRUD:

UPDATE orders SET status = 'shipped' WHERE id = 42;

The previous status? Gone. When did it change? Hope you have a modified_at column. Who changed it? Better check the application logs.

With event sourcing:

OrderPlaced { orderId: 42, items: [...], total: 89.99 }
PaymentProcessed { orderId: 42, amount: 89.99 }
OrderShipped { orderId: 42, trackingNumber: "1Z999..." }

You know exactly what happened, when, and in what order. Need to add a new feature that tracks time between order and shipment? Replay the events. The data was always there — you just didn't need it before.

When Event Sourcing Is Worth the Complexity

I'm not going to pretend this is free. Event sourcing adds real complexity. You need to handle event versioning (what happens when event schemas change?). You need snapshot strategies for aggregates with thousands of events (replaying 50,000 events to get current state is slow). You need to think about eventual consistency, because projections update asynchronously.

It pays off when:

Audit requirements are strict — financial services, healthcare, legal tech. Regulators want to see every state change, not just the current state.
Temporal queries matter — "What did this account look like last Tuesday at 3pm?" Event sourcing answers this natively. CRUD requires time-travel infrastructure you probably don't have.
Multiple read models serve different consumers — your mobile app needs a different data shape than your admin dashboard. Projections handle this elegantly.
Debugging production issues — replay the exact sequence of events that led to a bug. Reproduce it deterministically. Fix it. Done.

It's overkill when:

Simple CRUD is genuinely enough — a blog, a TODO app, a settings page. Don't add architectural complexity for its own sake.
Your team is small and moving fast — event sourcing has a learning curve. If you're three people shipping an MVP, use Postgres and move on.
Event ordering doesn't matter — if your domain doesn't care about the sequence of changes, you're paying the event sourcing tax for nothing.

The Tools

EventStoreDB (now Kurrent) is purpose-built for this pattern — Greg Young designed it specifically around event sourcing. Kafka works as an event store if you configure retention and compaction carefully, though it wasn't designed for it. Axon Framework handles the wiring in Java/Kotlin. Marten does the same for .NET with PostgreSQL as the backing store.

You can also build a minimal event store on top of any database with an append-only table. It won't scale like EventStoreDB, but it'll teach you the pattern without learning a new database.

The Mental Shift

The hardest part isn't the code. It's thinking in events instead of state. Instead of "the order is shipped," think "a shipment event occurred for this order." Instead of "the user changed their email," think "an EmailChanged event was recorded."

Once this clicks, you start seeing events everywhere. Your bank statements are event logs. Your browser history is an event log. Your life is a sequence of events that projects into your current state.

Whether that's enlightening or existentially unsettling is between you and your therapist.

What architecture patterns should I break down next? CQRS deep dive? Saga pattern? Domain-driven design? Drop it in the comments.

Bolt vs Lovable vs v0 — I Built the Same App With All Three

Tyson Cung — Sat, 04 Apr 2026 12:06:36 +0000

I gave all three AI app builders the same prompt: build a task management dashboard with user auth, a Kanban board, and a settings page. Same requirements. Same afternoon. Very different results.

Here's what actually happened.

Bolt: Speed Demon, Shallow Thinker

Price: From $20/month (free tier available)

Bolt had a working prototype in about 90 seconds. I'm not exaggerating. You type a description, it generates a full-stack app in the browser, and you can preview it immediately. For hackathons and "I need this yesterday" demos, nothing touches it.

The generated code was decent JavaScript/TypeScript — readable, functional, reasonably structured. It connected to Supabase for the database without me configuring anything manually. The Kanban board dragged and dropped. The auth flow worked.

But the moment I asked for something custom — a specific drag animation, a webhook integration, a non-standard data relationship — Bolt started guessing wrong. It's fast because it leans heavily on templates and common patterns. Step outside those patterns and you're fighting the AI more than working with it.

Bolt is cloud-only. No local dev environment. If your internet drops, you're staring at a loading spinner.

My take: Best for speed. Worst for customization.

Lovable: The Polish Machine

Price: From $25/month (no free tier)

Lovable took longer to generate the initial app — maybe 3-4 minutes — but what it produced was noticeably more polished. The UI looked like someone actually designed it. Consistent spacing, proper color hierarchy, responsive layout that didn't break on mobile.

The full-stack generation is Lovable's real strength. It scaffolded the database schema, auth system, and API routes together. The code it generated for the backend was cleaner than what I'd write in a rush. Integrated authentication and payment components come built-in.

The visual editor lets you drag components around and tweak layouts without touching code. For founders who can't code — or developers who don't want to waste time on pixel-pushing — this is genuinely useful.

The downside: Vendor lock-in is real. Exporting your project and running it elsewhere takes work. The generated code is tightly coupled to Lovable's infrastructure. You're renting, not owning.

My take: Best output quality. Worst for portability.

v0: The React Developer's Best Friend

Price: From $20/month (free tier available)

v0 is Vercel's tool, and it shows. Everything it generates is React + Tailwind CSS + Next.js. If that's your stack, the output is excellent — clean component structure, proper TypeScript types, production-ready code you can drop straight into an existing project.

Here's the thing: v0 doesn't do backend. At all. No database generation, no auth scaffolding, no API routes. It's purely a frontend tool. For my task management app, v0 gave me a beautiful Kanban board component and a settings page layout, but I had to wire up everything else myself.

That limitation is also its strength. Because v0 focuses entirely on UI, the quality of its frontend output is the highest of the three. The components are accessible, responsive, and follow React best practices. You can export them into any Next.js project with copy-paste.

My take: Best code quality. Most limited scope.

The Honest Comparison

After building the same app three times, here's my ranking by use case:

"I need a demo by tomorrow" → Bolt. Nothing is faster for getting something on screen.

"I need a real MVP to show investors" → Lovable. The polish level and full-stack generation means you ship something that looks professional without a design team.

"I'm a developer adding AI to my workflow" → v0. The code quality is genuinely good enough to use in production projects. But you need to know React, and you need your own backend.

What None of Them Do Well

All three struggle with complex business logic. A multi-step approval workflow? A permissions system with role hierarchies? Custom reporting with aggregated data? You're writing that yourself regardless of which tool you pick.

They also all share a scaling problem. These tools are excellent for going from zero to prototype. Going from prototype to production-grade application still requires a real developer making real architectural decisions. The AI gets you 60-70% of the way there. The last 30% is where the actual engineering happens.

I wouldn't trust any of them to generate a production backend I'm not going to review line by line. But for getting started fast? All three are genuinely useful. Pick the one that matches your skill level and what you actually need built.

Which AI app builder are you using? Have you tried combining them — like v0 for frontend and Lovable for backend? I'm curious what workflows people are developing.

Cursor vs Claude Code vs GitHub Copilot — Which AI Coding Tool Is Actually Worth It?

Tyson Cung — Sat, 04 Apr 2026 06:39:47 +0000

I've used all three of these tools on real projects — not toy demos, not benchmarks. Production code, messy codebases, tight deadlines. Here's what I actually think.

GitHub Copilot: The Gateway Drug

Price: $10/month (Individual) | $19/month (Business)

Copilot was the first AI coding tool that felt useful rather than gimmicky. Tab-complete on steroids. It lives inside your editor, suggests code as you type, and mostly stays out of your way.

The autocomplete is solid for boilerplate. Writing a REST endpoint? Copilot will finish the handler, the error checking, the response formatting. Tedious stuff that doesn't require creative thinking — Copilot eats it for breakfast.

Copilot Chat (the sidebar conversation mode) is decent for quick questions. "What does this regex do?" or "Write a test for this function" — the answers are usually correct.

The catch: Copilot thinks one file at a time. It doesn't understand your project structure, your architectural patterns, or why you named that service LegacyBillingAdapter. For single-file tasks, great. For anything involving multiple files or system-level reasoning, it hits a wall fast.

Also, if you're not using VS Code or a JetBrains IDE, your options are limited.

Cursor: The AI-Native IDE

Price: $20/month (Pro) | $40/month (Business)

Cursor is what happens when you build an editor around AI instead of bolting AI onto an editor. It's a VS Code fork, so the transition is painless — your extensions, keybindings, and themes carry over.

The killer feature is multi-file awareness. Ask Cursor to refactor an API endpoint and it'll update the route handler, the service layer, the types, and the tests. It sees your whole project, not just the open file.

Composer mode is where Cursor shines — describe a change in natural language and it generates a multi-file diff you can review and apply. For medium-complexity features, this saves genuine hours.

The catch: At $20/month, it's double Copilot's price. The premium request limits (for GPT-4/Claude models) run out fast if you use it heavily. And it's VS Code only — if your team uses JetBrains, Cursor isn't an option.

The quality also varies with the underlying model. Cursor with Claude is noticeably better than Cursor with GPT-4 for most coding tasks. You're paying for the IDE wrapper, but the brain underneath matters a lot.

Claude Code: The Terminal Power Tool

Price: $20/month (Pro via Anthropic) to $200/month (heavy usage)

Claude Code is the odd one out. It's not an IDE plugin — it's a CLI agent that operates directly in your terminal. You describe what you want, and it reads files, writes code, runs commands, and iterates on errors autonomously.

This sounds scary, and honestly it should. But the results are impressive. Claude Code understands project-wide context better than either competitor. Hand it a bug report and it'll grep through your codebase, identify the relevant files, trace the logic, write a fix, and run the tests.

For complex tasks — "add authentication to this API" or "migrate this module from REST to GraphQL" — Claude Code produces the most complete solutions. It thinks in terms of systems, not snippets.

The catch: It's a terminal tool. No visual diff review. No inline suggestions. The workflow is fundamentally different — you're delegating to an agent, not pair-programming with an autocomplete.

The cost scales with usage. Light users pay $20/month. Heavy users can hit $100-200/month easily. And trusting an AI to run shell commands on your machine requires confidence in your git hygiene.

My Honest Recommendation

If you're starting out: GitHub Copilot. It's cheap, low-risk, and teaches you how to work with AI. The free tier lets you experiment before committing.

If you build features daily: Cursor. Multi-file awareness and Composer mode are game-changers for real development. The productivity gain justifies the price bump over Copilot.

If you work on complex systems: Add Claude Code to your toolkit. Don't replace Cursor — use Claude Code for the big, messy tasks that need system-level reasoning. Use Cursor for the day-to-day.

If you can only pick one: Cursor. It's the best balance of capability, usability, and price. Copilot is cheaper but less capable. Claude Code is more powerful but harder to integrate into a smooth workflow.

The real winner? Using two tools together. Cursor for daily coding, Claude Code for heavy lifts. They complement each other better than any single tool covers on its own.

What's your AI coding setup? Have you tried combining tools or do you stick with one? I'd love to hear what's working for real projects.