serverless-optimizer

name	serverless-optimizer
description	Analyze Vercel serverless functions, identify expensive code, and optimize it via Kai Evolve
version	2.0.0
author	kai-agent
metadata	{"kai":{"tags":["kai","vercel","serverless","cost","optimization"],"related_skills":["optimization-workflow","evaluator-creation","aws-cost-optimizer"]}}

Serverless Optimizer

Analyze Vercel serverless functions, identify expensive code paths, and optimize them using Kai's evolutionary optimization engine. Findings become GitHub issues with before/after code from real optimization runs.

Prerequisites

• Workspace with Vercel integration connected
• Repository added to workspace (the repo backing the Vercel project)
• Evaluator creation skill loaded (for writing fitness functions)
• Optimization workflow skill loaded (for running optimizations)

Phase 1: Discovery

Step 1: Activate tools

kai_activate_category(category="optimization")

Vercel tools are first-party vercel_* tools in the serverless category — activate them with kai_activate_category(category="serverless"). They call Vercel's REST API via the workspace's marketplace OAuth token; Vercel is NOT a proxy MCP (mcp.vercel.com is allowlist-only), so it does NOT appear in kai_list_integrations and the tools are named vercel_*, not mcp_vercel_*.

Step 2: List projects and pick targets

vercel_list_projects()

Pick projects by: most deployments, highest build times, or user request. (These are first-party vercel_* tools from the backend's serverless category — not an upstream MCP. If you don't see them, run kai_activate_category(category="serverless") or find_tools(query="vercel").)

Step 3: Get deployment metrics

vercel_get_function_metrics(projectId)

Extract:

• Build times (avg/p95) — slow builds = large bundles = slow cold starts
• Deploy frequency — active projects are worth optimizing
• Sources — git-connected projects have repos we can read

Step 4: Inspect functions

vercel_list_functions(projectId)

Note runtime, memory, region for each function.

Phase 2: Code Analysis

Step 5: Read the function source code

The Vercel project must have its backing repo added to the workspace. Use repo tools:

browse_repository_files(workspaceId, repoId)
read_repository_files(workspaceId, repoId, paths=["src/app/api/...", "pages/api/..."])

For each API route / serverless function, look for patterns from references/optimization-patterns.md:

• Category A: SSR pages that should be ISR
• Category B: Handlers that could run on Edge Runtime
• Category C: Heavy imports in lightweight routes
• Category D: Missing cache headers
• Category E: Cold start issues (large bundles, per-request DB connections)
• Category F: Architecture issues (proxy routes, monolithic handlers)

Step 6: Rank candidates

Rank optimization candidates by impact. Only proceed with candidates where:

1. The code is in a function that runs frequently (deploy metrics confirm activity)
2. There's a measurable metric to optimize (latency, bundle size, memory)
3. The optimization can be expressed as a fitness function

Phase 3: Optimize via Kai Evolve

For each optimization candidate, run through the Kai optimization pipeline.

Step 7: Write a custom evaluator

Write a Python evaluator targeting the specific serverless function. See the evaluator-creation skill for full details.

Serverless-specific evaluator patterns:

For cold start / bundle size optimization:

import ast
import sys

def evaluate(module):
    """Score on code size and import count (proxy for bundle size)."""
    source = inspect.getsource(module)
    tree = ast.parse(source)
    
    import_count = sum(1 for node in ast.walk(tree) if isinstance(node, (ast.Import, ast.ImportFrom)))
    line_count = len(source.splitlines())
    
    # Fewer imports and lines = smaller bundle = faster cold start
    # Penalize heavily for known-heavy imports
    heavy_imports = ['pandas', 'numpy', 'scipy', 'tensorflow', 'torch']
    heavy_penalty = sum(50 for node in ast.walk(tree) 
                        if isinstance(node, ast.ImportFrom) and node.module and any(h in node.module for h in heavy_imports))
    
    return max(0, 200 - import_count * 5 - line_count * 0.1 - heavy_penalty)

For response latency optimization:

import time
import statistics

def evaluate(module):
    """Score API handler on response latency with mock request."""
    times = []
    for _ in range(10):
        start = time.perf_counter()
        # Call the handler with a realistic mock request
        module.handler(mock_request)
        elapsed = time.perf_counter() - start
        times.append(elapsed)
    
    median_ms = statistics.median(times) * 1000
    return max(0, 1000 / (median_ms + 1))

Upload the evaluator in one step:

create_evaluator_from_code(workspaceId, repoId, code=evaluator_code, name="Serverless: /api/X latency")
# → returns { evaluatorId }

Step 8: Run optimization

config = {
    "llm": {"models": [{"name": "openai/gpt-4o", "weight": 1.0}]},
    "prompt": {"systemMessage": "Optimize this Vercel handler for cold start / latency. Keep the HTTP contract unchanged."},
}
scopes = [{"path": "src/app/api/X/route.ts", "fromLine": 1, "toLine": 120}]
start_code_optimization(workspaceId, repoId, config, scopes, evaluatorId)

Use scopes[].path / fromLine / toLine (not filePath / startLine / endLine), config.llm.models as an array, and config.prompt.systemMessage (not goal).

Step 9: Monitor and wait

get_code_optimization_progress(optimizationId)
get_optimization_iterations(optimizationId)

Report milestones to the user as they happen.

Step 10: Review optimized code

get_optimized_programs(optimizationId)

Verify:

• Correctness preserved (same API contract)
• Improvement is real (not gaming the evaluator)
• Code is readable and maintainable

Phase 4: Deliver

Step 11: File GitHub issues with results

For each successful optimization, create a GitHub issue with:

• The finding from Phase 2 (what was wrong)
• The optimized code from Phase 3 (what Kai produced)
• Before/after metrics from the optimization run
• Cost impact estimate using references/vercel-pricing.md

Use the template from references/issue-template.md.

Step 12: Summary report

Present a summary to the user:

Serverless Optimization Report — {project name}

Profile: {framework} | {N} functions | {region} | avg build {X}s

#	Function	Finding	Optimization	Improvement
1	/api/feed	SSR → ISR	optimizationId: X	2.3x fewer invocations
2	/api/health	Serverless → Edge	manual (config)	~200ms cold start eliminated
3	/api/export	Heavy imports	optimizationId: Y	1.4x faster cold start

Estimated monthly savings: $X — $Y (depending on traffic)

Step 13: Save learnings

workspace_learnings_add(category="optimization", content="Vercel project [name]: optimized [N] functions. Key finding: [pattern]. Evaluator [id] measured [metric].")

Rules

• Never skip code reading — metrics tell you WHERE, code tells you WHAT
• Always run through Kai Evolve for code changes — don't just suggest diffs manually
• For config-only changes (Edge Runtime, cache headers, ISR revalidate): if the edit is small and the fix is clear, propose a lifecycle action and ship the change as a PR via kai_create_pull_request (activate the integrations category first). For broader config decisions that need team input, file an issue via kai_create_github_issue with labels=["serverless", "performance"]. Don't run a Kai Evolve optimization on pure config — it's the wrong tool for the job.
• Custom evaluators > AI evaluators > LLM-only mode
• Present cost estimates as ranges — Vercel pricing depends on plan tier