DEV Community: Franklin Mayoyo

7 Next.js Features That Made Me Delete 200 Lines of Code

Franklin Mayoyo — Mon, 20 Jul 2026 16:54:01 +0000

My last project had a photo modal with its own context provider, a tab switcher with three useState calls, and a cache wrapper I'd copy-pasted into four different files. None of that needed to exist. The App Router already handles it.

I went back through a real codebase and pulled this stuff out one feature at a time. Here's what got deleted, what replaced it, and where each one actually bites you. None of this is a free lunch.

1. Server Actions (no more API routes)

Before: a route handler, a fetch call, and state just to know if the button is loading.

// app/api/subscribe/route.ts
export async function POST(req: Request) {
  const { email } = await req.json();
  await db.subscribers.create({ email });
  return Response.json({ ok: true });
}

// SubscribeForm.tsx
const [loading, setLoading] = useState(false);
const [error, setError] = useState<string | null>(null);

async function handleSubmit(e: FormEvent) {
  e.preventDefault();
  setLoading(true);
  try {
    const res = await fetch("/api/subscribe", {
      method: "POST",
      body: JSON.stringify({ email }),
    });
    if (!res.ok) throw new Error("Failed");
  } catch (err) {
    setError("Something went wrong");
  } finally {
    setLoading(false);
  }
}

After:

// actions.ts
"use server";
export async function subscribe(formData: FormData) {
  const email = formData.get("email") as string;
  await db.subscribers.create({ email });
}

// SubscribeForm.tsx
<form action={subscribe}>
  <input name="email" type="email" />
  <button>Subscribe</button>
</form>

Why it's better: the route file is gone. The fetch call is gone. useFormStatus gets you loading state without the extra hook if you still want it. One function does the whole job, and it's obvious where server code ends and client code begins instead of that boundary living implicitly in a URL string.

Cons: you'll still write client code for decent UX. useFormStatus, useActionState, optimistic updates. So it's not "no client code," more like "client code somewhere else." Debugging changes shape too. You're not curling an endpoint anymore, you're stepping through a function call, and that throws people used to REST muscle memory.

2. Parallel Routes (no more tab state)

Before:

const [activeTab, setActiveTab] = useState<"analytics" | "team">("analytics");

return (
  <>
    <TabButton onClick={() => setActiveTab("analytics")} />
    <TabButton onClick={() => setActiveTab("team")} />
    {activeTab === "analytics" ? <Analytics /> : <Team />}
  </>
);

After:

app/dashboard/
  @analytics/page.tsx
  @team/page.tsx
  layout.tsx

// layout.tsx
export default function Layout({ analytics, team }: { analytics: React.ReactNode; team: React.ReactNode }) {
  return (
    <>
      {analytics}
      {team}
    </>
  );
}

Why it's better: each slot fetches, streams, and errors on its own. Nothing waits on anything else, and there's no shared state whose only job is telling a child component "you're the active one now." The URL owns the state instead of React.

Cons: don't reach for this unless the sections are actually independent. Two tabs sharing the same data source with no separate fetching? A plain useState and a ternary is simpler, and this is just adding folders for the sake of it. It also reads as magic to anyone new to the codebase until they've hit it once themselves.

3. Intercepting Routes (no more modal state)

Before: a context or store whose entire purpose is remembering which photo is open.

const [openPhotoId, setOpenPhotoId] = useState<string | null>(null);

{openPhotoId && (
  <Modal onClose={() => setOpenPhotoId(null)}>
    <PhotoDetail id={openPhotoId} />
  </Modal>
)}

After:

app/photos/
  page.tsx
  [id]/page.tsx        // full page view
  (.)[id]/page.tsx      // intercepted modal view

Click a photo from the grid and you get (.)[id] as a modal on top of the grid. Refresh that URL, or share the link, and you get the full [id]/page.tsx instead. Same route, right behavior for the context.

Why it's better: the modal is a real URL. Shareable, refreshable, back button just works, and you didn't build any of that. No provider whose only job was tracking an ID.

Cons: the (.), (..), (...) naming is confusing right up until it clicks, and when it doesn't render the modal you expect, the fix is almost always a routing detail, not your component. If you've only got one modal in the whole app, this is more setup than it's worth. Save it for when the pattern repeats.

4. after() (no more fire-and-forget hacks)

Before:

export async function POST(req: Request) {
  const result = await handleOrder(req);
  // not awaited on purpose, but it can get killed before it finishes
  logAnalyticsEvent("order_placed").catch(console.error);
  return Response.json(result);
}

After:

import { after } from "next/server";

export async function POST(req: Request) {
  const result = await handleOrder(req);
  after(() => logAnalyticsEvent("order_placed"));
  return Response.json(result);
}

Why it's better: after() actually runs after the response goes out, instead of you hoping the runtime doesn't tear the function down mid-flight. This one's less about deleting code and more about deleting a bug you didn't know you had.

Cons: the win here is small in line count. Call it a correctness fix wearing a boilerplate-deletion costume. It's also runtime-dependent, so check that your host actually honors it before you trust it with anything that matters, like billing events.

5. loading.tsx and error.tsx (no more manual boundaries)

Before:

function Page() {
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState<Error | null>(null);
  const [data, setData] = useState(null);

  useEffect(() => {
    fetchData()
      .then(setData)
      .catch(setError)
      .finally(() => setIsLoading(false));
  }, []);

  if (error) return <ErrorFallback error={error} />;
  if (isLoading) return <Spinner />;
  return <Content data={data} />;
}

After:

// loading.tsx
export default function Loading() {
  return <Spinner />;
}

// error.tsx
"use client";
export default function Error({ error, reset }: { error: Error; reset: () => void }) {
  return <ErrorFallback error={error} onRetry={reset} />;
}

// page.tsx
export default async function Page() {
  const data = await fetchData();
  return <Content data={data} />;
}

Why it's better: the page component just describes the happy path again. Loading and error states stop being state you thread through every data-fetching component and become a file that sits next to it instead.

Cons: error.tsx only catches what's below it in the tree. Put it in the wrong spot and it silently doesn't catch what you thought it would. loading.tsx is Suspense under the hood, so if you don't understand what's actually being suspended, you'll get a spinner that shows for the wrong thing, or not at all.

6. Cache Components and use cache (no more cache wrappers)

Before:

import { unstable_cache } from "next/cache";

const getPosts = unstable_cache(
  async () => db.posts.findMany(),
  ["posts"],
  { revalidate: 3600, tags: ["posts"] }
);

After:

async function getPosts() {
  "use cache";
  return db.posts.findMany();
}

Why it's better: caching lives on the function itself instead of a wrapper you had to remember to reach for and a cache key you had to name by hand. Everything's dynamic by default now, and you opt specific things into caching, which is a safer default than the old implicit behavior even if it means re-thinking how you reasoned about it before.

Cons: this is fresh, Next.js 16 era, so the docs and the "here's what actually happens in production" knowledge are thinner than the older API. Flipping from "cached unless I say otherwise" to "dynamic unless I say otherwise" isn't a find-and-replace on an existing app. It's a real audit if you care about correctness.

7. Route Groups (no more layout gymnastics)

Before: duplicated layout code, or one root layout with branches in it faking two different UIs. Marketing pages on one side, the actual app on the other.

After:

app/
  (marketing)/
    layout.tsx     // marketing nav/footer
    page.tsx
    pricing/page.tsx
  (app)/
    layout.tsx     // app shell, sidebar
    dashboard/page.tsx

Both groups still resolve to / and /dashboard. The parentheses never touch the URL, they just let each half of the app own its own shell.

Why it's better: no more root layout with an if (pathname.startsWith('/dashboard')) buried in it. Each section owns its layout cleanly, and you stop dreading touching the root layout because you might break the other half of the app.

Cons: this one's organizational, not runtime. It won't move your line count the way Server Actions will, so don't expect it to. It's also easy to over-group early, before you actually know how the app should be split, which just means renaming folders in three months.

The actual point

The line count was never really the story. The framework now carries complexity that used to be yours to hand-roll and maintain: loading states, cache invalidation, modal routing. That's a real trade though, not a clean win. Every one of these ties you tighter to Next.js's way of doing things, and a couple (Cache Components especially) mean you're an early adopter with all that entails, not someone catching up to a settled pattern.

What would you add to this list?

Your AI Agent is Bleeding Money (And You're Making It Worse)

Franklin Mayoyo — Tue, 30 Dec 2025 21:19:31 +0000

Let me guess: you're building a SaaS product with Claude. You've got customers making API calls, burning through tokens like a Tesla on fire. Your AWS bill looks like a phone number. And somewhere, a product manager is asking why your margins are trash.

I'll tell you why: you're shoving encyclopedias into every single API call when you could be carrying a library card.

The $10K/Month Mistake

Here's what I see in every production codebase I audit:

# Your current nightmare
system_prompt = """
You are DataCorp's financial analyst assistant.

BRAND GUIDELINES:
- Use active voice in all communications
- Keep sentences under 20 words
- Reference our Q4 2024 performance metrics
- Always cite from our approved data sources
... [2,000 more words]

FINANCIAL ANALYSIS PROCEDURES:
1. Always validate data sources
2. Calculate rolling 12-month averages
3. Compare to industry benchmarks from FinData Inc.
4. Generate variance reports
... [1,500 more words]

DATA SOURCES:
Our approved databases are:
- PostgreSQL cluster at db.datacorp.com
  Schema: [500 words of table definitions]
- MongoDB analytics at analytics.datacorp.com
  Collections: [400 words of collection schemas]
- S3 data lake structure: [600 words]

EXCEL FORMATTING STANDARDS:
- Header row always bold, 12pt Calibri
- Currency formatted to 2 decimals
- Charts use company colors: #1E3A8A, #3B82F6, #60A5FA
... [800 more words]

REPORT TEMPLATES:
[Monthly report template: 500 words]
[Quarterly analysis template: 700 words]
[Executive summary template: 400 words]

Now please analyze this quarter's revenue data.
"""

# Token cost per request: ~9,000 tokens
# Requests per month: 50,000
# Cost at Claude Sonnet 4: $27/million input tokens
# Your monthly burn: $12,150
# And that's JUST the system prompt

Every. Single. API. Call.

You're paying to load the same information 50,000 times a month. That's not engineering—that's setting money on fire while your CFO watches.

The Skill Solution: Pay Per Use, Not Per Pray

Skills work on progressive disclosure. Claude loads them in three levels:

Level 1: Metadata (~100 tokens, ALWAYS loaded)

---
name: datacorp-financial-analysis
description: "Analyze financial data following DataCorp standards and procedures. Use for revenue analysis, variance reports, and executive summaries."
---

That's it. 100 tokens. Claude now knows this Skill exists.

Level 2: Instructions (Under 5k tokens, loaded WHEN TRIGGERED)

Only loaded when someone actually asks for financial analysis:

# DataCorp Financial Analysis Skill

## Quick Start
Use our PostgreSQL cluster for source data.
For schema details, see [SCHEMAS.md](SCHEMAS.md).
For Excel formatting, see [FORMATTING.md](FORMATTING.md).

## Analysis Procedures
1. Validate data sources
2. Calculate 12-month rolling averages
3. Compare to benchmarks
4. Generate variance reports

For detailed procedures, see [PROCEDURES.md](PROCEDURES.md).

Level 3: Resources (Unlimited, loaded AS NEEDED)

financial-analysis-skill/
├── SKILL.md              # Loaded when Skill triggers
├── SCHEMAS.md            # Only if Claude needs schema details
├── FORMATTING.md         # Only if creating Excel files
├── PROCEDURES.md         # Only if doing complex analysis
├── templates/
│   ├── monthly.md        # Only if monthly report requested
│   ├── quarterly.md      # Only if quarterly report requested
│   └── executive.md      # Only if exec summary requested
└── scripts/
    ├── validate_data.py  # Never enters context, just executes
    └── benchmark.py      # Never enters context, just executes

Now watch your token economics transform:

import anthropic

client = anthropic.Anthropic()

# One-time setup: Upload your Skill
from anthropic.lib import files_from_dir

skill = client.beta.skills.create(
    display_title="DataCorp Financial Analysis",
    files=files_from_dir("/path/to/financial_analysis_skill"),
    betas=["skills-2025-10-02"]
)

# Now your API calls look like this:
response = client.beta.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=4096,
    betas=["code-execution-2025-08-25", "skills-2025-10-02"],
    container={
        "skills": [{
            "type": "custom",
            "skill_id": skill.id,
            "version": "latest"
        }]
    },
    messages=[{
        "role": "user",
        "content": "Analyze Q4 revenue vs Q3"
    }],
    tools=[{
        "type": "code_execution_20250825",
        "name": "code_execution"
    }]
)

# Token cost breakdown:
# - Skill metadata: 100 tokens (always)
# - SKILL.md: 2,000 tokens (when financial analysis triggered)
# - SCHEMAS.md: 500 tokens (if needed)
# - PROCEDURES.md: 1,500 tokens (if needed)
# Total: 4,100 tokens vs 9,000 tokens
# Savings: 54% on this request
# But wait, it gets better...

The Script Multiplier: Zero-Token Execution

Here's where your accountant starts crying tears of joy:

Executable scripts never enter the context window.

When Claude runs a script, only the OUTPUT consumes tokens. The code itself? Zero.

# scripts/validate_revenue_data.py
import pandas as pd
import json
import sys

def validate_revenue_data(filepath):
    """
    Comprehensive revenue data validation.
    50 lines of sophisticated logic that you'd normally
    need to explain to Claude in excruciating detail.
    """
    df = pd.read_csv(filepath)

    issues = []

    # Check for negative revenue (red flag)
    if (df['revenue'] < 0).any():
        negative_count = (df['revenue'] < 0).sum()
        issues.append(f"CRITICAL: {negative_count} negative revenue entries")

    # Validate date continuity
    df['date'] = pd.to_datetime(df['date'])
    date_gaps = df['date'].diff().dt.days
    if (date_gaps > 1).any():
        issues.append(f"WARNING: Date gaps detected in data")

    # Check for outliers (3 sigma rule)
    mean_rev = df['revenue'].mean()
    std_rev = df['revenue'].std()
    outliers = df[abs(df['revenue'] - mean_rev) > 3 * std_rev]
    if len(outliers) > 0:
        issues.append(f"INFO: {len(outliers)} statistical outliers detected")

    # Validate currency consistency
    if df['currency'].nunique() > 1:
        issues.append("ERROR: Multiple currencies in dataset")

    # Check completeness
    missing_data = df.isnull().sum()
    if missing_data.any():
        issues.append(f"WARNING: Missing data in columns: {missing_data[missing_data > 0].to_dict()}")

    return {
        'valid': len([i for i in issues if 'ERROR' in i or 'CRITICAL' in i]) == 0,
        'issues': issues,
        'records': len(df),
        'date_range': f"{df['date'].min()} to {df['date'].max()}",
        'total_revenue': float(df['revenue'].sum()),
        'currency': df['currency'].iloc[0]
    }

if __name__ == "__main__":
    result = validate_revenue_data(sys.argv[1])
    print(json.dumps(result, indent=2))

Claude runs: python scripts/validate_revenue_data.py q4_revenue.csv

Claude gets back:

{
  "valid": true,
  "issues": ["INFO: 2 statistical outliers detected"],
  "records": 1247,
  "date_range": "2024-10-01 to 2024-12-31",
  "total_revenue": 1847293.42,
  "currency": "USD"
}

Token cost of that 50-line validation script: ZERO

If you made Claude write that logic from scratch every time? 800+ tokens. Per request. Forever.

Real Numbers From Real Production Systems

Let me show you what this looks like at scale.

Case Study: MarketingCo (B2B SaaS, 200 employees)

Before Skills:

# Every request included:
system_prompt = """
[Brand guidelines: 2,000 tokens]
[SEO requirements: 1,500 tokens]
[Product catalog: 3,000 tokens]
[Writing templates: 2,500 tokens]
[Competitor positioning: 1,000 tokens]
Total: 10,000 tokens per request
"""

# Monthly usage:
# - 100,000 API calls
# - 10,000 tokens per call = 1 billion input tokens
# - Claude Sonnet 4: $27/million tokens
# - Monthly cost: $27,000 (just system prompts!)

After Skills:

# Marketing Skill structure:
marketing-skill/
├── SKILL.md (2k tokens)
├── BRAND.md (loaded if brand voice needed)
├── SEO.md (loaded if SEO optimization needed)
├── products/
│   ├── product_a.json (loaded per product)
│   ├── product_b.json
│   └── ...
├── templates/ (loaded per content type)
└── scripts/
    └── check_seo.py (zero tokens, just runs)

# Typical blog post request:
# - Skill metadata: 100 tokens (always)
# - SKILL.md: 2,000 tokens (triggered)
# - SEO.md: 1,500 tokens (needed for blog)
# - templates/blog.md: 600 tokens (needed)
# - One product file: 200 tokens (needed)
# Total: 4,400 tokens per request

# New monthly cost:
# - 100,000 API calls
# - 4,400 tokens per call = 440 million input tokens
# - Monthly cost: $11,880
# SAVINGS: $15,120/month = $181,440/year

Case Study: FinTechStartup (Series A, Tight Margins)

The Setup:

Building AI-powered financial advisory tool
10,000 users, averaging 5 queries/day
50,000 API calls/day = 1.5M/month

Before Skills:

# System prompt included:
# - Compliance guidelines: 3,000 tokens
# - Investment strategies: 4,000 tokens
# - Risk assessment procedures: 2,000 tokens
# - Market data schemas: 2,500 tokens
# - Report formatting: 1,500 tokens
# Total: 13,000 tokens per request

# Monthly burn:
# 1.5M calls × 13,000 tokens = 19.5 billion tokens
# Cost: $526,500/month on input tokens alone
# Annual run rate: $6.3 MILLION

After Skills:

# Investment advisory Skill:
investment-skill/
├── SKILL.md (3k tokens)
├── COMPLIANCE.md (only if compliance check needed)
├── STRATEGIES.md (only if strategy analysis needed)
├── RISK_MODELS.md (only if risk assessment needed)
├── schemas/
│   └── market_data.sql (only if schema needed)
├── templates/
│   └── reports/ (only if report generation needed)
└── scripts/
    ├── risk_calculator.py (zero tokens)
    ├── compliance_check.py (zero tokens)
    └── portfolio_optimizer.py (zero tokens)

# Average request now:
# - Skill metadata: 100 tokens
# - SKILL.md: 3,000 tokens
# - One additional file: 2,000 tokens (average)
# - Script execution: 0 tokens
# Total: 5,100 tokens per request

# New monthly cost:
# 1.5M calls × 5,100 tokens = 7.65 billion tokens
# Cost: $206,550/month
# SAVINGS: $319,950/month = $3.8 MILLION/year

That's not a typo. $3.8 million saved per year.

The Multi-Skill Power Move

Here's where it gets spicy. You can combine up to 8 Skills per request:

# The old way: Everything in one bloated prompt
system_prompt = """
[Financial analysis: 5,000 tokens]
[Excel formatting: 2,000 tokens]
[PowerPoint templates: 2,500 tokens]
[Company branding: 1,500 tokens]
[Data validation: 2,000 tokens]
Total: 13,000 tokens every request
"""

# The Skills way: Load only what's needed
response = client.beta.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=4096,
    betas=["code-execution-2025-08-25", "skills-2025-10-02"],
    container={
        "skills": [
            {"type": "custom", "skill_id": "skill_financial", "version": "latest"},
            {"type": "anthropic", "skill_id": "xlsx", "version": "latest"},
            {"type": "anthropic", "skill_id": "pptx", "version": "latest"}
        ]
    },
    messages=[{
        "role": "user",
        "content": "Analyze Q4 revenue and create an executive presentation"
    }],
    tools=[{"type": "code_execution_20250825", "name": "code_execution"}]
)

# What actually loads:
# - All Skill metadata: 300 tokens (3 × 100)
# - Financial Skill: 3,000 tokens (triggered)
# - Excel Skill: 2,000 tokens (triggered for data analysis)
# - PowerPoint Skill: 2,500 tokens (triggered for presentation)
# Total: 7,800 tokens

# But if user just asks "What was our Q4 revenue?":
# - All Skill metadata: 300 tokens
# - Financial Skill: 3,000 tokens
# - Excel Skill: NOT loaded (not needed)
# - PowerPoint Skill: NOT loaded (not needed)
# Total: 3,300 tokens
# Savings: 58% on this simpler query

The Anthropic Skills: Free Optimization

Anthropic provides pre-built Skills for common tasks:

# Use Anthropic's optimized Skills for document generation
response = client.beta.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=4096,
    betas=["code-execution-2025-08-25", "skills-2025-10-02"],
    container={
        "skills": [
            {"type": "anthropic", "skill_id": "xlsx", "version": "latest"},
            {"type": "anthropic", "skill_id": "pptx", "version": "latest"},
            {"type": "anthropic", "skill_id": "docx", "version": "latest"},
            {"type": "anthropic", "skill_id": "pdf", "version": "latest"}
        ]
    },
    messages=[{
        "role": "user",
        "content": "Create a quarterly report with data analysis and charts"
    }],
    tools=[{"type": "code_execution_20250825", "name": "code_execution"}]
)

# These are maintained by Anthropic
# Zero effort, just better performance

Downloading Generated Files: The Right Way

When Skills create documents, you need to download them properly:

# Step 1: Create the document
response = client.beta.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=4096,
    betas=["code-execution-2025-08-25", "skills-2025-10-02"],
    container={
        "skills": [{"type": "anthropic", "skill_id": "xlsx", "version": "latest"}]
    },
    messages=[{
        "role": "user",
        "content": "Create Q4 revenue analysis spreadsheet"
    }],
    tools=[{"type": "code_execution_20250825", "name": "code_execution"}]
)

# Step 2: Extract file IDs from response
def extract_file_ids(response):
    file_ids = []
    for item in response.content:
        if item.type == 'bash_code_execution_tool_result':
            content_item = item.content
            if content_item.type == 'bash_code_execution_result':
                for file in content_item.content:
                    if hasattr(file, 'file_id'):
                        file_ids.append(file.file_id)
    return file_ids

# Step 3: Download using Files API
for file_id in extract_file_ids(response):
    # Get metadata
    file_metadata = client.beta.files.retrieve_metadata(
        file_id=file_id,
        betas=["files-api-2025-04-14"]
    )

    # Download content
    file_content = client.beta.files.download(
        file_id=file_id,
        betas=["files-api-2025-04-14"]
    )

    # Save to disk
    file_content.write_to_file(file_metadata.filename)
    print(f"Downloaded: {file_metadata.filename}")

Version Control: Production vs Development

Smart teams version their Skills:

# Production: Pin to specific versions for stability
production_config = {
    "skills": [{
        "type": "custom",
        "skill_id": "skill_01AbCdEfGhIjKlMnOpQrStUv",
        "version": "1759178010641129"  # Specific version timestamp
    }]
}

# Development: Use latest for rapid iteration
development_config = {
    "skills": [{
        "type": "custom",
        "skill_id": "skill_01AbCdEfGhIjKlMnOpQrStUv",
        "version": "latest"  # Always get newest
    }]
}

# Update workflow:
# 1. Develop and test with "latest"
from anthropic.lib import files_from_dir

new_version = client.beta.skills.versions.create(
    skill_id="skill_01AbCdEfGhIjKlMnOpQrStUv",
    files=files_from_dir("/path/to/updated_skill"),
    betas=["skills-2025-10-02"]
)

# 2. Deploy to production with specific version
# 3. Monitor and rollback if needed

The Prompt Caching Gotcha

Skills work WITH prompt caching, but there's a trap:

# This caches well:
response1 = client.beta.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=4096,
    betas=[
        "code-execution-2025-08-25",
        "skills-2025-10-02",
        "prompt-caching-2024-07-31"
    ],
    container={
        "skills": [
            {"type": "anthropic", "skill_id": "xlsx", "version": "latest"}
        ]
    },
    messages=[{"role": "user", "content": "Analyze sales data"}],
    tools=[{"type": "code_execution_20250825", "name": "code_execution"}]
)

# This breaks the cache (different Skills list):
response2 = client.beta.messages.create(
    model="claude-sonnet-4-5-20250929",
    max_tokens=4096,
    betas=[
        "code-execution-2025-08-25",
        "skills-2025-10-02",
        "prompt-caching-2024-07-31"
    ],
    container={
        "skills": [
            {"type": "anthropic", "skill_id": "xlsx", "version": "latest"},
            {"type": "anthropic", "skill_id": "pptx", "version": "latest"}  # Cache miss
        ]
    },
    messages=[{"role": "user", "content": "Create presentation"}],
    tools=[{"type": "code_execution_20250825", "name": "code_execution"}]
)

# Solution: Keep Skills list consistent for related workflows
# Group your API calls by Skill combinations

The Migration Checklist

Ready to stop hemorrhaging money? Here's your path:

Week 1: Audit

# Calculate your current burn
def audit_current_costs():
    """
    1. Count your API calls per month
    2. Measure your average system prompt length
    3. Calculate: calls × prompt_tokens × $27/million
    4. Cry into your spreadsheet
    """
    monthly_calls = 100000  # Your number
    avg_system_tokens = 8000  # Measure yours

    monthly_input_tokens = monthly_calls * avg_system_tokens
    monthly_cost = (monthly_input_tokens / 1_000_000) * 27

    print(f"Current monthly burn: ${monthly_cost:,.2f}")
    print(f"Annual run rate: ${monthly_cost * 12:,.2f}")
    return monthly_cost

Week 2: Extract Your First Skill

# Start with your most-used procedures
# Financial analysis, content generation, data validation, etc.

# Create skill directory:
"""
my-first-skill/
├── SKILL.md
└── README.md
"""

# SKILL.md template:
"""
---
name: my-company-analytics
description: Company-specific data analysis procedures. Use for financial analysis, revenue reporting, and KPI calculations.
---

# Analytics Skill

## Quick Start
For standard revenue analysis, use our PostgreSQL cluster.
Connection details in company vault.

## Common Tasks
- Revenue analysis: See [REVENUE.md](REVENUE.md)
- KPI dashboards: See [KPI.md](KPI.md)

## Data Sources
All company data sources documented in [SOURCES.md](SOURCES.md)
"""

Week 3: Upload and Test

from anthropic.lib import files_from_dir

# Upload
skill = client.beta.skills.create(
    display_title="Company Analytics",
    files=files_from_dir("/path/to/my-first-skill"),
    betas=["skills-2025-10-02"]
)

# Test with real queries
test_queries = [
    "Analyze Q4 revenue",
    "Generate monthly KPI report",
    "Compare revenue vs last quarter"
]

for query in test_queries:
    response = client.beta.messages.create(
        model="claude-sonnet-4-5-20250929",
        max_tokens=4096,
        betas=["code-execution-2025-08-25", "skills-2025-10-02"],
        container={
            "skills": [{"type": "custom", "skill_id": skill.id, "version": "latest"}]
        },
        messages=[{"role": "user", "content": query}],
        tools=[{"type": "code_execution_20250825", "name": "code_execution"}]
    )

    # Validate responses
    # Measure token usage
    # Calculate savings

Week 4: Measure and Scale

def measure_savings():
    """
    Track token usage before/after
    Calculate cost savings
    Project annual impact
    Send victory email to CFO
    """
    old_tokens_per_request = 8000
    new_tokens_per_request = 3500  # Your actual number

    savings_per_request = old_tokens_per_request - new_tokens_per_request
    monthly_calls = 100000

    monthly_savings = (monthly_calls * savings_per_request / 1_000_000) * 27
    annual_savings = monthly_savings * 12

    print(f"Monthly savings: ${monthly_savings:,.2f}")
    print(f"Annual savings: ${annual_savings:,.2f}")
    print(f"Efficiency gain: {(savings_per_request/old_tokens_per_request)*100:.1f}%")

The Bottom Line

Skills are not a "nice-to-have" feature. They're a fundamental architectural shift in how you should build with LLMs.

Stop doing this:

Copying 10,000-token system prompts into every API call
Burning $500K+ annually on repeated context
Explaining the same procedures to Claude 100,000 times

Start doing this:

Load instructions on-demand (54-75% token reduction)
Execute scripts at zero token cost
Compose Skills for complex workflows
Version your domain knowledge like code

The math is brutal: a mid-size SaaS company making 1.5M API calls/month with bloated prompts burns $526K monthly. With Skills, that drops to $206K. That's $3.8M saved per year.

Your investors didn't give you millions to spend it on redundant context loading.

Fix your architecture. Deploy Skills. Save money.

P.S. - If you're still copying system prompts after reading this, I can't help you. But your competitors using Skills will eat your lunch while spending 60% less on AI costs.

The Tailwind CSS Pattern That Saved My Sanity (And Why Your Button Components Are a Mess)

Franklin Mayoyo — Tue, 09 Dec 2025 10:29:31 +0000

Let's be real for a second. We need to talk about the elephant in the room when it comes to Tailwind CSS.

You've built a sleek Next.js app.

You love the utility-first approach—no more fighting with CSS files. But then you open a shared component (a Button, a Modal, an Alert), and your stomach drops.

There it is. The Class Name String From Hell.

The Pain: What Your Code Probably Looks Like Right Now

Here's what most developers do. They create a Button component that looks like this:

File: components/ui/BadButton.tsx (What NOT to do)

// ❌ components/ui/BadButton.tsx - The WRONG way (what you're doing now)

interface BadButtonProps {
  variant?: 'primary' | 'secondary' | 'danger'
  size?: 'small' | 'medium' | 'large'
  disabled?: boolean
  children: React.ReactNode
  onClick?: () => void
}

export function BadButton({
  variant,
  size,
  disabled,
  children,
  onClick,
}: BadButtonProps) {
  const btnClasses = `transition duration-200 ease-in-out font-semibold rounded-md ${
    disabled ? 'opacity-50 cursor-not-allowed' : 'hover:shadow-lg'
  } ${
    variant === 'primary'
      ? 'bg-indigo-600 text-white'
      : variant === 'secondary'
      ? 'bg-gray-200 text-gray-800'
      : variant === 'danger'
      ? 'bg-red-600 text-white'
      : 'bg-gray-100 text-gray-600'
  } ${
    size === 'large'
      ? 'py-3 px-6 text-lg'
      : size === 'medium'
      ? 'py-2 px-4 text-base'
      : 'py-1 px-3 text-sm'
  }`

  return (
    <button className={btnClasses} disabled={disabled} onClick={onClick}>
      {children}
    </button>
  )
}

Thirty lines of nested ternary operators. When your designer asks for a new button variant, you don't edit styles—you decode a puzzle.

Then You Try to Use It (And It Gets Worse)

Okay, so you've created that messy BadButton component. Now let's see what happens when you try to actually use it across your app:

File: app/dashboard/page.tsx (Using the BadButton)

'use client';

import { useState } from 'react';
import { BadButton } from '@/components/ui/BadButton';

export default function DashboardPage() {
  const [isSubmitting, setIsSubmitting] = useState(false);

  return (
    <div className="p-8">
      <h1>Dashboard</h1>

      {/* Using BadButton - but look at the confusion */}
      <BadButton 
        variant="primary"
        size="large"
        disabled={isSubmitting}
        onClick={() => setIsSubmitting(true)}
      >
        Submit Form
      </BadButton>

      {/* Another BadButton - inconsistent prop names */}
      <BadButton 
        variant="danger"
        size="medium"  // Wait, was it 'medium' or 'md'?
        onClick={() => console.log('delete')}
      >
        Delete Account
      </BadButton>
    </div>
  );
}

File: app/login/page.tsx (When you give up entirely)

'use client';

import { useState } from 'react';
// Notice: NO import of BadButton - you gave up on it!

export default function LoginPage() {
  const [isSubmitting, setIsSubmitting] = useState(false);

  return (
    <form className="p-8">
      <input type="email" placeholder="Email" className="block mb-4" />
      <input type="password" placeholder="Password" className="block mb-4" />

      {/* You gave up on BadButton and just inlined everything */}
      <button 
        className={`transition duration-200 ease-in-out font-semibold rounded-md ${
          isSubmitting ? 'opacity-50 cursor-not-allowed' : 'hover:shadow-lg'
        } ${
          'bg-indigo-600 text-white'  // hardcoded primary
        } ${
          'py-2 px-4 text-base'  // hardcoded medium size
        }`}
        disabled={isSubmitting}
        onClick={(e) => {
          e.preventDefault();
          setIsSubmitting(true);
        }}
      >
        {isSubmitting ? 'Logging in...' : 'Login'}
      </button>
    </form>
  );
}

Now you have TWO different approaches in your codebase:

Dashboard - Uses BadButton component (messy but at least reusable)
Login - Gave up entirely and inlined everything (copy-paste hell)

Notice the problems?

No type safety - You can pass variant="success" and it won't error, it'll just fall back to a default
Inconsistent naming - Is it "large" or "lg"? Is it "medium" or "md"?
No autocomplete - Your editor can't help you because there are no proper TypeScript types
The component itself is still a mess - That ternary soup in BadButton.tsx makes it hard to add new variants
Developers bypass the component entirely - They just copy-paste inline styles because the component is too confusing

But the biggest issue? Every time you need to add a new button style, you have to edit that nightmare ternary chain. Want to add a "warning" variant? Good luck finding where to insert it in that nested conditional mess.

This is how codebases become unmaintainable. Two files, two different approaches, zero consistency.

The Mindset Shift: Stop Building Strings, Start Declaring Outcomes

Here's the conceptual leap that changed everything for me when building production SaaS apps.

The Old Way (Imperative): Your brain traces how the class string gets assembled, line by line, condition by condition. It's mentally exhausting.

The New Way (Declarative): You define all possible style outcomes upfront, outside your component. The component's only job is to look up the right styles and render them.

This is what I call the Variant Map Pattern, and it's powered by a tiny library called clsx.

Setting Up Your Project

Before we dive in, let's get everything installed. You have two options:

Option 1: Start Fresh (Recommended for Learning)

# Create a new Next.js project
npx create-next-app@latest nextjs-tailwind-variant-starter

# Choose "Yes, use recommended defaults" when prompted
# This installs Next.js, TypeScript, Tailwind CSS, and ESLint automatically

cd nextjs-tailwind-variant-starter

# Install clsx for smart class merging
npm install clsx

Option 2: Clone the Starter Template (Jump Right In)

# Clone the pre-configured starter with examples
git clone https://github.com/Mayoyo25/nextjs-tailwind-variant-patterns.git

cd nextjs-tailwind-variant-patterns

# Install all dependencies
npm install

The Solution: Build It Once, Use It Everywhere

Now let me show you the RIGHT way to build a Button component. Everything will be organized in proper files.

Step 1: Create Your Button Component

File: components/ui/Button.tsx (The CORRECT way)

// ✅ DO THIS - Clean, maintainable, professional

import React from 'react';
import clsx from 'clsx';

// 📝 TYPES: Define what variants and sizes are allowed
type ButtonVariant = 'primary' | 'secondary' | 'danger';
type ButtonSize = 'sm' | 'md' | 'lg';

// 🎨 STYLE MAPS: All possible styles defined ONCE
// This is the secret sauce - declare your styles upfront
const variantStyles: Record<ButtonVariant, string> = {
  primary:   'bg-blue-600 text-white hover:bg-blue-700 focus:ring-blue-500',
  secondary: 'bg-gray-200 text-gray-800 hover:bg-gray-300 focus:ring-gray-400',
  danger:    'bg-red-600 text-white hover:bg-red-700 focus:ring-red-500',
};

const sizeStyles: Record<ButtonSize, string> = {
  sm: 'py-1 px-3 text-sm',
  md: 'py-2 px-4 text-base',
  lg: 'py-3 px-6 text-lg',
};

// ⚡ COMPONENT: Props interface
interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
  variant?: ButtonVariant;
  size?: ButtonSize;
  isLoading?: boolean;
}

// ⚡ COMPONENT: The actual Button
export const Button: React.FC<ButtonProps> = ({ 
  variant = 'primary', 
  size = 'md', 
  isLoading, 
  className,
  children,
  ...props 
}) => {

  // This is where clsx does its magic
  const classes = clsx(
    // 1. Base styles (always applied)
    'transition-all duration-200 ease-in-out font-semibold rounded-md focus:outline-none focus:ring-2',

    // 2. Variant and size (simple lookups - no ternaries!)
    variantStyles[variant],
    sizeStyles[size],

    // 3. Conditional states (clean object syntax)
    {
      'opacity-50 cursor-not-allowed': props.disabled || isLoading,
      'animate-pulse': isLoading,
    },

    // 4. User overrides (always last so they can override defaults)
    className 
  );

  return (
    <button 
      className={classes} 
      disabled={props.disabled || isLoading} 
      {...props}
    >
      {isLoading ? 'Loading...' : children}
    </button>
  );
};

Look at that! No ternary soup. No string concatenation hell. Just clean, declarative code.

Step 2: Use Your Button Everywhere (Consistently!)

Now in any page or component, just import and use it. Every button will look consistent.

File: app/dashboard/page.tsx (Using the clean Button)

'use client'

import { useState } from 'react'
import { Button } from '@/components/ui/Button'

export default function DashboardPage() {
  const [isSubmitting, setIsSubmitting] = useState(false)

  const handleSubmit = () => {
    setIsSubmitting(true)
    // Your submit logic here
    setTimeout(() => setIsSubmitting(false), 2000)
  }

  const handleDelete = () => {
    if (confirm('Are you sure?')) {
      // Your delete logic here
    }
  }

  return (
    <div className='p-8 space-y-4'>
      {/* using our New Button */}
      <div className='flex justify-between items-center mb-6'>
        <Button
          variant='secondary'
          size='sm'
          onClick={() => window.history.back()}
        >
          Back
        </Button>

        <h1 className='text-2xl font-bold'>Dashboard</h1>

        <Button variant='primary' size='sm'>
          <a href='/settings'>Go to Settings</a>
        </Button>
      </div>

      {/* 2. Main Content Buttons Fix 🛠️ */}

      <div className='flex items-center gap-4 pt-4'>
        {/* Submit Form (Looks clean!) */}
        <Button
          variant='primary'
          size='lg'
          onClick={handleSubmit}
          isLoading={isSubmitting}
        >
          Submit Form
        </Button>

        <Button variant='danger' size='md' onClick={handleDelete}>
          Delete Account
        </Button>

        <Button variant='secondary' size='sm'>
          Cancel
        </Button>

        {/* Disabled button */}
        <Button variant='primary' disabled>
          Save Changes
        </Button>
      </div>

      {/* Custom classes still work! */}
      <Button variant='primary' className='w-full'>
        Full Width Button
      </Button>
    </div>
  )
}

File: app/settings/page.tsx (Same clean pattern)

'use client'
import { Button } from '@/components/ui/Button'

export default function SettingsPage() {
  return (
    <div className='p-8'>
      <div className='flex justify-between items-center mb-6'>
        {/* Our Back Button (using the New Button impementation) */}
        <Button
          variant='secondary'
          size='sm'
          onClick={() => window.history.back()}
        >
          Back
        </Button>

        <h1 className='text-2xl font-bold'>Settings</h1>

        {/* Action Button (similar implimentation) */}
        <Button variant='secondary' size='sm'>
          <a href='/'>Go to Home</a>
        </Button>
      </div>
      {/* --- End of New Header Row --- */}

      {/* Every button looks consistent - no more typos! */}
      <div className='pt-4'>
        <Button variant='primary' size='lg'>
          Save Settings
        </Button>
      </div>
    </div>
  )
}

Look at the difference! Every button is consistent. No copy-pasting. No typos. No inconsistencies. Just clean, reusable components.

How clsx Makes This Possible

Let me quickly explain what clsx does, because it's the secret ingredient:

import clsx from 'clsx';

// clsx intelligently merges classes
const classes = clsx(
  'p-4 rounded-lg',                    // String: always included
  { 'bg-red-500': hasError },          // Object: only if hasError is true
  { 'text-lg': size === 'large' },     // Object: only if condition is true
  customClassName                       // String: user overrides
);

// Result: 'p-4 rounded-lg bg-red-500' (if hasError is true)

Instead of writing messy ternaries, you pass an object where:

Key = the CSS class
Value = the condition (true = include it, false = skip it)

It's less than 1KB and makes your code infinitely more readable.

Why This Pattern Changes Everything

File Structure Recap:

nextjs-tailwind-variant-starter/
├── components/
│   └── ui/
│       └── Button.tsx          ← All button logic lives here
├── app/
│   ├── dashboard/
│   │   └── page.tsx           ← Just imports and uses Button
│   └── settings/
│       └── page.tsx           ← Just imports and uses Button

Why this is the professional approach:

Readability: New developers onboard in minutes. The styling rules are explicit, not buried in ternary chaos.
Maintainability: Need to change your primary button color across 20 components? Edit one line in the variant map. Done.
Consistency: Every button looks the same because they all use the same source of truth.
Type Safety: TypeScript ensures impossible combinations crash at compile-time. Try passing variant="primari" (typo) and your editor screams at you.
Scalability: Need 10 more variants? Add 10 lines to the map. The component code stays the same.

Your Next Steps

If you're building SaaS products with Next.js and Tailwind, this pattern isn't optional—it's essential for writing professional code.

Try this today:

Create components/ui/Button.tsx with the code above
Find your messiest button usage
Replace it with <Button variant="primary">Click me</Button>
Feel the relief

What's the most complex component you've cleaned up with this approach? Drop a comment below—I'd love to hear your war stories. 👇

Data Analysis & Visualization with Python: Bank Marketing Dataset Tutorial (Part 1)

Franklin Mayoyo — Wed, 22 Oct 2025 11:09:00 +0000

Master Real-World Data Analysis Through a Complete Banking Case Study

Part 1 of 11: Introduction & Dataset Setup

If you're looking to break into data analysis or sharpen your Python skills with real-world datasets, you've come to the right place. This comprehensive 11-part series will take you from raw data to actionable insights using a fascinating banking dataset.

What makes this series different? We're not using toy datasets or simplified examples. Instead, you'll work with actual marketing campaign data from a Portuguese bank, learning the exact workflows data analysts use in the industry every day.

🎯 What You'll Learn in This Tutorial

By the end of this article, you'll be able to:

Install and configure essential Python data analysis libraries
Fetch real-world datasets from the UCI Machine Learning Repository
Understand the structure and context of banking marketing data
Set up your environment for professional data analysis
Identify the business problem behind the data

Skill Level: Beginner to Intermediate

Time Required: 20-30 minutes

Prerequisites: Basic Python knowledge

🏦 The Business Problem: Understanding Bank Marketing Campaigns

Before diving into code, let's understand what we're analyzing and why it matters.

The Real-World Context

A Portuguese banking institution ran multiple direct marketing campaigns between 2008 and 2013, primarily through phone calls, to promote term deposit subscriptions to their clients.

What's a term deposit? It's a cash investment held at a financial institution for a fixed period with a guaranteed interest rate. Banks love these products because they provide stable, predictable funding.

The Challenge

Marketing campaigns are expensive. Each phone call costs time, money, and resources. The bank needed to answer a critical question:

Can we predict which clients are most likely to subscribe to a term deposit before we call them?

This is where data science transforms business operations. By identifying high-probability clients, the bank can:

Reduce costs by targeting the right customers
Increase conversion rates through focused efforts
Improve customer experience by reducing unwanted calls
Optimize resource allocation across campaigns

This type of predictive modeling is used across industries—from retail recommendations to healthcare risk assessment.

⚙️ Setting Up Your Python Environment

Let's get your workspace ready for professional data analysis.

Step 1: Install Required Libraries

Open your Python environment (Jupyter Notebook, Google Colab, or VS Code) and run:

!pip install ucimlrepo pandas seaborn matplotlib scikit-learn

Get started quickly: https://colab.research.google.com/

New to colab?

Getting Started with Google Colab: A Beginner's Guide

Understanding Each Library

ucimlrepo → Direct access to 600+ datasets from UCI Machine Learning Repository

pandas → The industry standard for data manipulation and analysis

seaborn → Statistical data visualization built on matplotlib

matplotlib → Core plotting library for creating custom visualizations

scikit-learn → Machine learning toolkit (we'll use this in later parts)

Pro tip: If you're using Google Colab, most of these libraries come pre-installed except ucimlrepo.

📦 Loading and Exploring the Dataset

Step 2: Import Your Libraries

from ucimlrepo import fetch_ucirepo
import pandas as pd
import seaborn as sns
import matplotlib.pyplot as plt

Step 3: Fetch the Bank Marketing Dataset

The UCI repository assigns each dataset a unique ID. For Bank Marketing, it's ID 222:

# Fetch the dataset directly from UCI repository
bank_marketing = fetch_ucirepo(id=222)

This single line downloads 45,211 records of real banking data. The fetch_ucirepo object contains:

data.features → Independent variables (X)
data.targets → Dependent variable (y)
metadata → Dataset documentation
variables → Column descriptions and data types

Step 4: Create Your Working DataFrame

# Extract features and target
X = bank_marketing.data.features
y = bank_marketing.data.targets

# Combine into a single DataFrame for analysis
df = pd.concat([X, y], axis=1)

# Preview the first few rows
df.head()

Understanding the Data Structure

Your DataFrame now contains 17 columns:

Demographic Information:

age → Client's age in years
job → Type of occupation (12 categories)
marital → Marital status
education → Education level

Financial Indicators:

balance → Average yearly balance in euros
housing → Has housing loan? (yes/no)
loan → Has personal loan? (yes/no)
default → Has credit in default? (yes/no)

Campaign Details:

contact → Contact communication type
month → Last contact month of year
duration → Last contact duration in seconds
campaign → Number of contacts performed during this campaign

Previous Campaign Data:

pdays → Days since client was last contacted (-1 means never contacted)
previous → Number of contacts before this campaign
poutcome → Outcome of previous marketing campaign

Target Variable:

y → Did the client subscribe? (yes/no) ← This is what we're trying to predict

🔍 Dataset Intelligence: Metadata Analysis

Professional data analysts always start by understanding the dataset's documentation.

# Display comprehensive metadata
print(bank_marketing.metadata)

Key Dataset Characteristics

Scale and Scope:

Total Records: 45,211 client interactions
Features: 16 predictor variables
Target Variable: Binary classification (subscribed: yes/no)
Time Period: 2008-2013
Geographic Location: Portugal

Data Quality Indicators:

Missing Values: Present in some categorical features (marked as "unknown")
Data Type Mix: Numerical, categorical, and binary variables
Class Imbalance: Likely (most marketing campaigns have low conversion rates)

Business Context from Metadata

The dataset description reveals important details:

Multiple campaigns were conducted over several years
Phone calls were the primary contact method
Client history from previous campaigns is included
Economic indicators might influence subscription decisions

📊 Variable Dictionary: Understanding Each Column

# Examine variable details
bank_marketing.variables

Why This Matters

Understanding variable types is crucial for choosing the right analysis techniques:

Categorical Variables require encoding for machine learning

Numerical Variables need scaling and outlier detection

Binary Variables are already in usable format but may need balancing

Feature Categories Breakdown

Personal Attributes (4 features):

Demographics that don't change frequently
Used to segment customer profiles

Economic Indicators (4 features):

Financial status metrics
Strong predictors of term deposit interest

Campaign Metrics (5 features):

Marketing effectiveness indicators
Reveal client engagement patterns

Historical Data (3 features):

Previous interaction outcomes
Often the strongest predictors in retention modeling

💡 Why This Dataset Is Perfect for Learning

For Beginners

✅ Clear business context → You understand the real-world application

✅ Well-documented → Every column has a clear explanation

✅ Manageable size → 45K rows is large enough to be realistic, small enough to process quickly

✅ Binary outcome → Easier to interpret than multi-class problems

For Intermediate Learners

✅ Mixed data types → Practice handling categorical and numerical variables

✅ Class imbalance → Learn to deal with skewed target distributions

✅ Feature engineering opportunities → Create derived variables from existing ones

✅ Real business metrics → Understand how data drives business decisions

For Career Development

✅ Portfolio-worthy project → Demonstrate end-to-end analysis skills

✅ Interview-ready topic → Discuss classification problems confidently

✅ Industry-relevant → Marketing analytics is a high-demand field

✅ Transferable skills → Apply these techniques to any classification problem

🎓 Practice Exercises: Hands-On Learning

Before moving to Part 2, strengthen your understanding with these exercises:

Exercise 1: Data Structure Exploration

# What are the dimensions of your dataset?
df.shape

# What data types does each column have?
df.info()

# What are the basic statistics for numerical columns?
df.describe()

What to look for:

How many rows and columns do you have?
Which columns are numerical vs categorical?
What are the ranges of numerical variables?

Exercise 2: Missing Value Detection

# Count missing values per column
df.isnull().sum()

# Calculate the percentage of missing values
(df.isnull().sum() / len(df)) * 100

Critical thinking questions:

Which columns have missing data?
What might "unknown" values represent?
How might missing data affect your analysis?

Exercise 3: Target Variable Distribution

# Check the balance of your target variable
df['y'].value_counts()

# Visualize the distribution
df['y'].value_counts().plot(kind='bar')
plt.title('Target Variable Distribution')
plt.xlabel('Subscribed to Term Deposit?')
plt.ylabel('Count')
plt.show()

Business insight question:

What does this distribution tell you about the campaign's success rate?

🚀 What's Coming in Part 2

Now that you've successfully loaded and understood the dataset, we'll dive deeper into data exploration:

Part 2: Understanding Data Structure & Quality Assessment

You'll learn:

Advanced techniques for detecting data quality issues
How to identify outliers and anomalies
Data type conversion and optimization
Creating your first data quality report
Best practices for documenting your findings

📚 Additional Resources

Want to dive deeper?

UCI Machine Learning Repository → Original dataset documentation
Pandas Documentation → Master data manipulation
Research Paper → Academic study using this dataset

💬 Join the Conversation

Working through this tutorial? I'd love to hear about your experience:

What challenges did you encounter?
What insights did you discover in the data?
What would you like to see covered in future parts?

Drop a comment below or connect with me to discuss data analysis techniques!

🔖 Series Navigation

You are here: Part 1 – Introduction & Dataset Setup

Next: Part 2 – Understanding Data Structure & Quality Assessment

Coming soon: Parts 3-11 covering EDA, visualization, modeling, and deployment

Follow me for the complete 11-part series on data analysis and visualization. Each article builds on the previous one, creating a comprehensive learning path from raw data to actionable insights.

#DataScience #Python #MachineLearning #DataAnalysis #BankingAnalytics #PredictiveModeling #PythonProgramming #DataVisualization #UCI #CareerDevelopment

About the Author: A developer who loves learning and sharing diverse tech experiments — today’s focus: making sense of data with Python.

10,000 Failed Scripts Later: 5 Python Antipatterns to Avoid

Franklin Mayoyo — Fri, 10 Oct 2025 11:08:51 +0000

After 8 years building automation systems and consulting with dozens of founders, I've reviewed over 10,000 automation scripts. The same mistakes keep appearing, destroying productivity and causing preventable fires.

Here are the 5 Python antipatterns that waste the most time, with battle-tested fixes.

1. The "God Script" Antipattern

What it looks like:

# automation.py (2,847 lines)
def run_everything():
    sync_customers()
    process_invoices()
    send_emails()
    update_analytics()
    cleanup_database()
    generate_reports()
    backup_data()
    # ... 40 more functions

Why it fails:

One error kills everything
Impossible to debug which part failed
Can't run parts independently
Maintenance nightmare

The fix - Modular Scripts:

# /automations
#   /customers/sync.py
#   /billing/process_invoices.py
#   /notifications/send_emails.py
#   /orchestrator.py

# orchestrator.py
import subprocess
from concurrent.futures import ThreadPoolExecutor

tasks = [
    "python automations/customers/sync.py",
    "python automations/billing/process_invoices.py",
    "python automations/notifications/send_emails.py"
]

def run_task(cmd):
    result = subprocess.run(cmd, shell=True, capture_output=True)
    return {"cmd": cmd, "success": result.returncode == 0}

with ThreadPoolExecutor() as executor:
    results = list(executor.map(run_task, tasks))

for r in results:
    print(f"{'✓' if r['success'] else '✗'} {r['cmd']}")

Impact: Reduced debugging time by 73% across 40+ clients.

2. The "No Error Context" Antipattern

What it looks like:

try:
    process_customer_data(customer)
    send_welcome_email(customer)
    update_crm(customer)
except Exception as e:
    print("Error processing customer")
    # Good luck figuring out what failed

Why it fails:

You get alerted at 2am with zero context
Can't tell if it's network, data, or logic
No way to resume from failure point

The fix - Rich Error Context:

import logging
from datetime import datetime
from dataclasses import dataclass

logging.basicConfig(
    filename='automation.log',
    level=logging.INFO,
    format='%(asctime)s - %(levelname)s - %(message)s'
)

@dataclass
class ErrorContext:
    stage: str
    customer_id: str
    timestamp: datetime
    retry_count: int = 0

def process_customer_with_context(customer):
    context = ErrorContext(
        stage='',
        customer_id=customer['id'],
        timestamp=datetime.now()
    )

    try:
        context.stage = 'processData'
        process_customer_data(customer)

        context.stage = 'sendEmail'
        send_welcome_email(customer)

        context.stage = 'updateCRM'
        update_crm(customer)

        logging.info(f'Customer processed successfully: {context.__dict__}')

    except Exception as e:
        error_details = {
            **context.__dict__,
            'error': str(e),
            'customer_data': str(customer)
        }
        logging.error(f'Customer processing failed: {error_details}')

        # Alert with actionable info
        notify_slack(f"Failed at {context.stage} for customer {customer['id']}")
        raise

Impact: Reduced mean-time-to-resolution from 4 hours to 12 minutes.

3. The "Hardcoded Everything" Antipattern

What it looks like:

def sync_data():
    api_key = "sk_live_abc123xyz"
    db_url = "postgresql://user:pass@localhost/prod"
    webhook_url = "https://hooks.slack.com/services/T00/B00/XXX"

    # Now you can't test, can't deploy to staging, can't share code

Why it fails:

Can't run in different environments
Secrets in version control (security nightmare)
Every developer needs their own hardcoded copy

The fix - Environment-Driven Config:

# config.py
from dataclasses import dataclass
from os import getenv

@dataclass
class Config:
    api_key: str
    db_url: str
    webhook_url: str
    environment: str
    retry_limit: int = 3
    timeout: int = 30

    @classmethod
    def from_env(cls):
        env = getenv('ENV', 'development')

        return cls(
            api_key=getenv('API_KEY'),
            db_url=getenv('DATABASE_URL'),
            webhook_url=getenv('WEBHOOK_URL'),
            environment=env,
            retry_limit=int(getenv('RETRY_LIMIT', '3')),
            timeout=int(getenv('TIMEOUT', '30'))
        )

    def validate(self):
        """Fail fast if required config is missing"""
        if not self.api_key:
            raise ValueError("API_KEY environment variable required")
        if not self.db_url:
            raise ValueError("DATABASE_URL environment variable required")
        if not self.webhook_url:
            raise ValueError("WEBHOOK_URL environment variable required")

# Usage
config = Config.from_env()
config.validate()

# .env.example (committed to git)
"""
API_KEY=your_key_here
DATABASE_URL=postgresql://localhost/dev
WEBHOOK_URL=https://hooks.slack.com/your_webhook
ENV=development
RETRY_LIMIT=3
TIMEOUT=30
"""

Pro tip: Use python-dotenv for local development:

from dotenv import load_dotenv
load_dotenv()  # Loads .env file

config = Config.from_env()

Impact: Eliminated 89% of "works on my machine" issues.

4. The "Hope-Based Retry" Antipattern

What it looks like:

def fetch_customer_data(customer_id):
    try:
        return api.get(f"/customers/{customer_id}")
    except:
        # Just retry immediately... forever?
        return fetch_customer_data(customer_id)

# Spoiler: This creates infinite loops and DDoS attacks on your own API

Why it fails:

Infinite recursion on persistent failures
No backoff = hammering struggling services
Stack overflow errors
API rate limit bans

The fix - Exponential Backoff with Limits:

import time
from typing import Callable, TypeVar
from functools import wraps

T = TypeVar('T')

def retry_with_backoff(
    max_attempts: int = 3,
    initial_delay: float = 1.0,
    max_delay: float = 30.0,
    backoff_multiplier: float = 2.0
):
    """
    Retry decorator with exponential backoff.

    Usage:
        @retry_with_backoff(max_attempts=5)
        def flaky_api_call():
            return requests.get('https://api.example.com/data')
    """
    def decorator(func: Callable[..., T]) -> Callable[..., T]:
        @wraps(func)
        def wrapper(*args, **kwargs) -> T:
            last_error = None

            for attempt in range(1, max_attempts + 1):
                try:
                    return func(*args, **kwargs)
                except Exception as e:
                    last_error = e

                    if attempt == max_attempts:
                        raise Exception(
                            f"Failed after {max_attempts} attempts: {str(e)}"
                        )

                    delay = min(
                        initial_delay * (backoff_multiplier ** (attempt - 1)),
                        max_delay
                    )

                    print(f"Attempt {attempt} failed, retrying in {delay}s...")
                    time.sleep(delay)

            raise last_error

        return wrapper
    return decorator

# Usage
@retry_with_backoff(max_attempts=3)
def fetch_customer_data(customer_id: str):
    response = requests.get(f"{API_URL}/customers/{customer_id}")
    response.raise_for_status()
    return response.json()

# Or wrap existing functions
customer = retry_with_backoff(max_attempts=5)(
    lambda: api.get(f"/customers/{id}")
)()

Advanced: Don't retry on client errors

def is_retryable_error(error: Exception) -> bool:
    """Only retry on server errors or network issues"""
    if hasattr(error, 'response') and error.response is not None:
        # Don't retry 4xx client errors
        return error.response.status_code >= 500
    # Retry on network errors
    return True

def retry_with_backoff(max_attempts: int = 3, **kwargs):
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            for attempt in range(1, max_attempts + 1):
                try:
                    return func(*args, **kwargs)
                except Exception as e:
                    if not is_retryable_error(e) or attempt == max_attempts:
                        raise
                    # ... rest of retry logic
        return wrapper
    return decorator

Impact: Reduced API-related incidents by 92% and prevented 14 rate-limit bans.

5. The "Silent Failure" Antipattern

What it looks like:

def process_orders():
    orders = get_pending_orders()

    for order in orders:
        try:
            fulfill_order(order)
        except:
            pass  # Nothing to see here...

    # Script exits with success code
    # You have no idea 50% of orders failed

Why it fails:

Problems compound silently for days/weeks
No visibility into what's working vs broken
Customers affected before you know there's an issue

The fix - Observable Automation:

from dataclasses import dataclass, field
from datetime import datetime
from typing import List, Dict
import json

@dataclass
class AutomationResult:
    total: int = 0
    succeeded: int = 0
    failed: int = 0
    errors: List[Dict] = field(default_factory=list)
    duration_seconds: float = 0
    timestamp: datetime = field(default_factory=datetime.now)

def process_orders_observable():
    start_time = datetime.now()
    results = AutomationResult(timestamp=start_time)

    orders = get_pending_orders()
    results.total = len(orders)

    for order in orders:
        try:
            fulfill_order(order)
            results.succeeded += 1
        except Exception as e:
            results.failed += 1
            results.errors.append({
                "order_id": order['id'],
                "error": str(e),
                "error_type": type(e).__name__,
                "timestamp": datetime.now().isoformat()
            })

    results.duration_seconds = (datetime.now() - start_time).total_seconds()

    # Log structured results
    print(json.dumps({
        'total': results.total,
        'succeeded': results.succeeded,
        'failed': results.failed,
        'duration_seconds': results.duration_seconds,
        'timestamp': results.timestamp.isoformat(),
        'errors': results.errors[:5]  # First 5 errors
    }, indent=2))

    # Alert on failures
    if results.failed > 0:
        failure_rate = results.failed / results.total
        alert_slack(
            f"⚠️ Order processing: {results.failed}/{results.total} failed "
            f"({failure_rate:.1%})\n"
            f"First error: {results.errors[0]['error']}"
        )

    # Exit with error code if >10% failed
    if results.failed / results.total > 0.1:
        exit(1)

    return results

# For cron jobs, this exit code matters!
# Your monitoring can alert on non-zero exits

Bonus: Add metrics for dashboards

from prometheus_client import Counter, Histogram, push_to_gateway

# Define metrics
orders_processed = Counter(
    'orders_processed_total',
    'Total orders processed',
    ['status']
)

order_duration = Histogram(
    'order_processing_seconds',
    'Order processing duration'
)

# Use in your function
def process_order_with_metrics(order):
    with order_duration.time():
        try:
            fulfill_order(order)
            orders_processed.labels(status='success').inc()
        except Exception as e:
            orders_processed.labels(status='failed').inc()
            raise

# Push to Prometheus Pushgateway
push_to_gateway('localhost:9091', job='order_processor')

Impact: Caught 127 production issues within 1 hour instead of days/weeks.

The Real Cost

Across the founders I've worked with, these 5 antipatterns cost an average of:

18 hours/month in debugging time
$4,200/month in lost revenue from undetected failures
73% higher infrastructure costs from inefficient retry logic

Quick Start Checklist

When writing your next automation script, ask:

✅ Can I run parts of this independently?
✅ Will errors give me enough context to debug?
✅ Can I run this in dev/staging/prod without code changes?
✅ Do I have sensible retry logic with backoff?
✅ Will I know if this fails in production?

What's Next?

Drop your worst automation horror story in the comments. What antipatterns would you add to this list?

Building operations automation for SaaS founders. 8 years in the trenches, 4 exits. Currently helping founders escape manual ops hell.