DEV Community: Shubham

Type-Driven Security: Reducing OWASP Risk With Strong Types

Shubham — Sun, 26 Jul 2026 01:07:06 +0000

Security failures often begin at ordinary boundaries: a database record is returned directly from an API, an identifier from one domain is accepted in another, untrusted input is treated as valid, or a query is assembled as a string. Framework defaults, reviews, tests, and monitoring remain essential but a well-designed type system can make some of these mistakes harder to write and easier to spot.

Scope matters: types do not stop or eliminate OWASP vulnerabilities on their own. They cannot prove that an authenticated user is authorized, make hostile network input trustworthy, sanitize HTML, or replace parameterized database APIs. They are one defense-in-depth layer that can encode security-relevant intent in application code.

What types are good at

Types are especially useful when a security property is about which values may cross a boundary. They can distinguish public response data from persistence models, prevent accidental mixing of identifiers, require explicit construction of sensitive values, and make unsafe APIs inconvenient to call.

That shifts some failures from production behavior to compiler feedback. It does not eliminate the need for runtime controls at trust boundaries.

Use DTOs and controlled serialization to prevent accidental exposure

Database models commonly contain fields that should never reach clients or logs. Returning them directly makes every caller responsible for remembering what to remove. Prefer an explicit response DTO and a single mapping function.

type UserRow = {
  id: string;
  email: string;
  passwordHash: string;
  mfaSecret: string | null;
  internalNotes: string | null;
};

type PublicUserDto = {
  id: string;
  email: string;
};

function toPublicUser(user: UserRow): PublicUserDto {
  return { id: user.id, email: user.email };
}

// res.json(toPublicUser(user));
// Never serialize UserRow directly at an HTTP boundary.

The allow-list is the important part: adding a sensitive database column does not automatically expose it. Apply the same idea to logging. Create log-specific DTOs or redaction helpers rather than passing arbitrary objects to JSON.stringify.

type LoginAudit = {
  userId: string;
  outcome: "success" | "failure";
};

logger.info({ userId: user.id, outcome: "success" } satisfies LoginAudit);

Make identifier and authorization context explicit

Two strings may have very different authority. A plain string makes it easy to pass a tenant ID where an account ID is expected. Branded types can prevent accidental mixing inside TypeScript code.

declare const tenantBrand: unique symbol;
declare const userBrand: unique symbol;
type TenantId = string & { readonly [tenantBrand]: true };
type UserId = string & { readonly [userBrand]: true };

function loadUser(tenantId: TenantId, userId: UserId) {
  // Query constrained by tenantId and userId.
}

Authorization can be represented explicitly too, rather than relying on a vague boolean passed through several layers.

type Viewer = { kind: "viewer"; userId: UserId };
type ProjectEditor = { kind: "project-editor"; userId: UserId; projectId: string };

type ProjectAccess = Viewer | ProjectEditor;

function renameProject(access: ProjectEditor, name: string) {
  // Only a caller that established editor access can call this API.
}

This improves API design, but it is not authorization by itself. The server must still authenticate the request and verify the tenant, project membership, ownership, and policy against trusted data on every relevant request. Brands disappear at runtime, so external values must be validated before they are cast or constructed.

Keep SQL parameterized types are not a SQL-injection fix

Parameterized queries are the primary control against SQL injection. Types can help shape query inputs, but they do not make string interpolation safe.

// Good: data remains a parameter, not SQL syntax.
const result = await db.query(
  "SELECT id, email FROM users WHERE tenant_id = $1 AND id = $2",
  [tenantId, userId]
);

// Do not do this even if userId has a TypeScript type:
// db.query(`SELECT * FROM users WHERE id = '${userId}'`);

For dynamic identifiers such as sort columns, use a fixed allow-list and construct only from known literals. Parameter placeholders generally cannot substitute SQL identifiers or keywords.

HTML requires a trusted/sanitized boundary

Encoding and sanitization are runtime problems because HTML often originates outside the type checker. Treat raw user HTML and sanitized HTML as distinct concepts, but do not confuse a type assertion with sanitization.

declare const sanitizedHtmlBrand: unique symbol;
type SanitizedHtml = string & { readonly [sanitizedHtmlBrand]: true };

function sanitizeHtml(input: string): SanitizedHtml {
  // Use a maintained sanitizer with an application-specific allow-list.
  return DOMPurify.sanitize(input) as SanitizedHtml;
}

function renderRichText(html: SanitizedHtml) {
  return { __html: html };
}

Use framework escaping by default. Only render HTML through a reviewed sanitizer, and account for URL policies, rich-text features, server-side rendering, and sanitizer updates. A SanitizedHtml type is useful only if its constructor is tightly controlled.

Validate runtime input before it becomes a domain type

TypeScript types describe developer intent but are erased at runtime. JSON payloads, environment variables, queue messages, database rows, and third-party webhooks are all untrusted until validated.

import { z } from "zod";

const CreateProject = z.object({
  name: z.string().trim().min(1).max(120),
  visibility: z.enum(["private", "team"]),
});

type CreateProjectInput = z.infer<typeof CreateProject>;

function parseCreateProject(body: unknown): CreateProjectInput {
  return CreateProject.parse(body);
}

Validation should happen at the edge, with clear error handling, size limits where appropriate, and authorization checks after identity and relevant resource state are known. Schema validation libraries complement static types; they do not replace business-rule validation.

Trade-offs and failure modes

More types and mappers: DTOs, schemas, and branded values add code and maintenance.
Unsafe escape hatches: broad as casts, any, and non-null assertions can bypass the guarantees. Restrict and review them.
False confidence: compile-time correctness says nothing about deployment configuration, access control policy, dependencies, or runtime input unless those are separately handled.
Boundary drift: generated clients, ORMs, and serializers may bypass carefully designed domain types. Test the actual HTTP and database behavior.

Adoption checklist

Identify high-risk boundaries: HTTP responses, logs, SQL access, webhooks, queues, and rich-text rendering.
Introduce explicit public DTOs and allow-list serializers for sensitive entities.
Use distinct ID and authorization-context types where mix-ups could cross tenant or resource boundaries.
Require parameterized SQL APIs; allow-list dynamic identifiers.
Validate all external data at runtime with schemas before creating domain values.
Keep raw HTML separate from sanitized/trusted HTML, and use a maintained sanitizer.
Back the design with authorization tests, integration tests, dependency updates, monitoring, and security review.

Conclusion

Strong types are most valuable when they make the secure path the natural path: explicit data transfer objects, constrained identifiers, narrow authority-bearing APIs, and visible trust boundaries. Used alongside runtime validation, parameterized queries, output encoding and sanitization, authorization enforcement, and operational controls, they can reduce the chance that common security mistakes reach production. They are not a substitute for those controls and they should never be presented as one.

Architecture from Day One: The Practical Guide to Scalable Backend Systems

Shubham — Sun, 19 Jul 2026 05:20:11 +0000

Every backend engineer wants to build systems that scale. But scalability is not a feature to casually bolt onto version 2.0; it is an emergent property of deliberate architectural choices, operational discipline, and evidence from real workloads.

After years of building and operating high-throughput systems across fintech and aviation, these are the foundational principles and production patterns that matter when moving from thousands of users to millions.

1. Define “scalable” beyond the buzzwords

Scaling is not simply handling more users. It is maintaining an agreed level of service as load grows: latency, correctness, availability, and cost all matter. A system that works for 1,000 users but collapses at 10,000 has a bottleneck to understand not merely “high load.”

A practical rule: do not judge scalability by raw requests per second alone. Define SLOs, then observe latency at the tail (especially p95 and p99), error rate, and resource saturation as load increases. A flat median can conceal a failing tail.

Run load tests that resemble production: realistic request mixes, payloads, connection behavior, data sizes, and downstream dependencies. Track queue depth, CPU, memory, database connections, disk and network saturation alongside user-facing SLOs. The useful question is: at what load do the SLOs, error budget, or cost envelope stop being acceptable?

Horizontal and vertical scaling: choose with evidence

Vertical scaling is often the fastest, safest next step. A larger database instance, more memory for a cache, or a faster machine can be appropriate until availability, failure-domain, or cost limits make it unattractive. Horizontal scaling adds capacity and resilience, but also coordination, deployment, and consistency complexity.

Stateless services: scale horizontally when demand and redundancy justify it.
Stateful services: first optimize queries, indexes, schema, and instance sizing; use replicas, partitioning, or sharding when measurements show they are needed.
Mixed workloads: separate stateful and stateless responsibilities so each can be tuned and scaled independently.

Sharding is not a default milestone. It raises operational and application complexity routing, rebalancing, cross-shard queries, and recovery. Introduce it only when observed data volume, write throughput, storage, or availability requirements exceed what simpler approaches can meet.

2. Stateless design enables elastic application capacity

Keeping request-specific state out of application memory makes ordinary HTTP request handling easier to distribute across instances. Sessions, shared rate-limit counters, and durable workflow state should live in purpose-built external stores rather than a process-local map.

// Bad: process-local session state is lost on restart and is not shared.
const sessions = new Map<string, Session>();
function getSession(id: string) {
  return sessions.get(id);
}

// Better: use a shared store with expiry and appropriate availability controls.
async function getSession(id: string) {
  return redis.get(`session:${id}`);
}

Statelessness does not mean every instance can be terminated without coordination. WebSockets, server-sent events, streaming responses, in-flight requests, local uploads, and long-running jobs may still be attached to an instance. Use readiness checks and graceful draining: stop accepting new work, allow bounded in-flight work to finish, notify or reconnect long-lived clients when appropriate, and enforce a termination deadline. Sticky routing may still be useful for connection affinity or performance, even if it is not required for ordinary shared-session HTTP traffic.

3. Multi-layer caching without correctness surprises

Caching is high leverage for read-heavy workloads, but its common risks are stale reads, inconsistent invalidation, cache-key mistakes, eviction behavior, and thundering herds not an automatic guarantee of data corruption or split brain. Treat the backing datastore as the source of truth unless you have explicitly designed a stronger consistency model.

Cache layer

Typical targets

Useful characteristics

Edge / CDN

Public, cacheable assets and responses

Low latency near users; deliberate cache-control and purge strategy

Application / distributed cache

Derived objects, sessions, rate limits

Shared across instances; explicit TTLs, keys, and invalidation

Database buffer / replicas

Frequently read database pages and read traffic

Helps throughput, but replicas can have replication lag

Choose a pattern deliberately: cache-aside is simple for many reads; write-through can reduce stale-cache windows; write-behind trades simplicity for durability and recovery concerns. Version cache keys when schemas change, invalidate or update entries on writes, and set bounded TTLs even when invalidation exists.

Protect the origin from a cache stampede. Coalesce concurrent misses with request locking or single-flight, refresh hot entries ahead of expiry where suitable, and add jitter to TTLs so many keys do not expire together. Monitor hit rate, miss rate, eviction, keyspace growth, memory pressure, origin fall-through, refresh failures, and stale-serving behavior. Test failure modes: cache unavailable, invalidation delayed, and an expired hot key under peak traffic.

4. Data scaling and the CAP theorem

Replication improves read capacity and resilience, but it introduces lag and failover trade-offs. Route reads only where the consistency required by the operation is available; a user who has just written data may need read-your-writes behavior rather than an asynchronous replica.

CAP is specifically about what a distributed system does during a network partition. When replicas cannot communicate, a system cannot simultaneously guarantee both a single consistent view of data and availability of every request. The design chooses its behavior per operation: reject or block some requests to preserve consistency, or serve potentially stale/divergent data and reconcile later. Outside a partition, latency, quorum configuration, and implementation choices still determine practical behavior.

Use evidence before introducing partitions or shards: sustained write bottlenecks, storage limits, noisy-neighbor isolation, geographic requirements, or demonstrated availability needs. Define a shard key that spreads traffic, avoid cross-shard transactions where possible, and plan rebalancing, backups, and repair before the first shard is created.

5. Control overload at every boundary

Load balancers distribute traffic; they do not create infinite capacity. Set connection and concurrency limits at services and dependencies, and propagate deadlines so doomed work does not continue consuming resources. Timeouts should be explicit and shorter than the caller’s remaining deadline.

Backpressure and load shedding: bound queues, reject low-priority work early, and return clear overload responses instead of allowing unbounded latency and memory growth.
Retries: retry only operations that are safe or idempotent; use exponential backoff with jitter, a maximum attempt count, and a retry budget so an incident does not become a retry storm.
Circuit breakers: temporarily stop calls to a demonstrably unhealthy dependency, fail fast or use a defined fallback, and probe recovery carefully.
Bulkheads: isolate thread pools, connection pools, queues, and tenant limits so one slow dependency or customer does not exhaust the whole service.

Instrument saturation and queueing, not only successful request rate. Alert on SLO burn, p95/p99 regressions, error rate, exhausted pools, queue age, and dependency health.

6. Event-driven architecture needs delivery discipline

Event-driven architecture (EDA) can decouple producers from consumers and smooth bursty work, but a broker does not remove distributed-systems failure modes. Most practical consumers operate with at-least-once delivery, so duplicates are normal rather than exceptional.

Make handlers idempotent using stable event IDs, deduplication records, or idempotent writes.
Retry transient failures with bounded exponential backoff and jitter; send poison messages to a monitored dead-letter queue (DLQ) with a replay process.
Document ordering scope. Ordering may exist only within a partition/key, and retries can change the apparent order.
Use the transactional outbox pattern when a database write and event publication must not diverge. Persist the intent with the business transaction, then reliably relay it to the broker.
Version event schemas and preserve compatibility during producer and consumer rollouts.

Measure lag, consumer throughput, retry counts, DLQ volume, duplicate rate, and end-to-end processing latency. These metrics turn “asynchronous” into an observable service commitment.

7. Build the feedback loop

Capacity planning is a continuous loop: establish SLOs, instrument real workloads, test failure and load scenarios, remove the measured bottleneck, and repeat. Prefer the simplest architecture that meets current reliability and growth needs, while leaving clean seams for the next proven constraint.

Scalable systems are not the ones with the most components. They are the ones that make trade-offs explicit, degrade predictably under stress, and give operators enough observability to act before customers notice.

How I Built a Personal AI Assistant That Lives in Telegram

Shubham — Sun, 19 Jul 2026 05:15:49 +0000

I wanted a personal AI assistant that lived where I already communicate: Telegram. Not another dashboard to remember, not a browser tab that disappears into the pile, and not a demo that can write clever text but cannot actually help me do things.

The result is a Telegram bot that can answer questions, remember useful context, schedule reminders, retrieve information, and use connected services through tightly controlled tools. It is intentionally practical rather than magical. The interesting work was not making a model produce text; it was building the systems around it so that tool use, scheduling, failures, and external side effects behave predictably.

This post explains the architecture, the trade-offs I made, and the safeguards that make a personal assistant useful without turning it into an unattended automation machine.

What I Optimized For

Telegram-first interaction: send a message, receive a useful response, and avoid a separate product surface.
Tool use with boundaries: it can retrieve data and invoke integrations, but it cannot freely perform side effects.
Durable personal state: reminders, notes, job history, and operational records must survive restarts.
Simple operations: one deployable service, observable logs, backups, and understandable failure modes.
Honest scaling limits: start with SQLite and one active bot consumer; change the architecture only when the workload requires it.

I did not optimize for a fully autonomous agent. For a personal assistant, reliability and control are more valuable than letting a model take unlimited actions.

Architecture Overview

At a high level, the system has five layers:

Telegram ingress: Telegraf receives updates and normalizes messages into an application request.
Conversation orchestration: the application loads relevant context, calls OpenAI, and runs a bounded tool-execution loop.
Tool layer: local capabilities such as notes, reminders, weather, and database reads sit behind explicit schemas and policies. Connected third-party services are accessed through Composio.
Durable state: SQLite stores sessions, scheduled jobs, execution attempts, idempotency keys, and operational data.
Background worker: a scheduler claims due jobs, executes them, records the result, and retries safely where appropriate.

Telegram
   │
   ▼
Telegraf handler ──► auth + rate limits ──► assistant orchestrator
                                              │
                         ┌────────────────────┼────────────────────┐
                         ▼                    ▼                    ▼
                     OpenAI API          local tools           Composio
                         │                    │                    │
                         └──────────────► SQLite ◄─────────────────┘
                                               ▲
                                               │
                                        scheduler worker

The application is deliberately not a collection of unconstrained agents talking to each other. A single orchestrator owns the request lifecycle. That makes it easier to trace what happened, apply policy consistently, and keep failures from becoming confusing.

Why Bun, Telegraf, OpenAI, Composio, and SQLite

I chose Bun because it gives me a fast TypeScript runtime, package management, and a straightforward deployment target. It keeps the service compact without requiring a complicated build pipeline for a small application. Bun is not the reason the assistant is reliable, though; explicit application boundaries and durable state are.

Telegraf is a mature, ergonomic Telegram framework. It handles the Telegram update format well while leaving routing, middleware, and error handling under my control. The bot layer should be boring: validate the sender, acknowledge the message lifecycle, and hand work to the application layer.

OpenAI provides the language model and structured tool-calling interface. Tool definitions help the model select an operation and produce arguments in an expected shape. They do not replace runtime validation. The model can still select an inappropriate tool, provide malformed data, or request an action the current user should not be allowed to take.

Composio is useful for OAuth-backed integrations. Instead of implementing every third-party OAuth flow, token lifecycle, and API wrapper myself, I can use a consistent connection layer for supported external services. That convenience does not eliminate security work: every integration still needs an allowlist, narrow scopes, and separate treatment for read operations versus side effects.

SQLite is the right database while the assistant is a single-user or low-volume system. It is portable, inexpensive to operate, and excellent for transactional local state. I use it for data that must be durable: reminders, job execution records, sessions, and idempotency keys. It is not a distributed queue, and it is not the long-term answer for multiple independently writing application instances.

Polling Instead of Webhooks

I use Telegram long polling rather than webhooks. For a personal deployment, polling avoids exposing a public HTTPS endpoint, certificate management, reverse-proxy setup, and webhook routing. The process asks Telegram for updates, processes them, and advances through the update stream.

The important caveat is that polling needs exactly one active consumer for a bot token. Running two polling instances at once can create conflicts and unpredictable update handling. If I deploy a replacement instance, I make sure the previous consumer is stopped before the new one begins polling.

Offset handling matters too. Telegram updates have monotonically increasing identifiers, and the consumer must advance its offset only after it has safely recorded or processed an update. In practice, I also keep a durable update or message idempotency record. That protects against duplicate handling after a process crash, a network timeout, or a restart near the boundary between receiving and committing an update.

const seen = db.query(
  "SELECT 1 FROM processed_updates WHERE update_id = ?"
);

async function handleUpdate(update: TelegramUpdate) {
  if (seen.get(update.update_id)) return;

  db.run("BEGIN IMMEDIATE");
  try {
    db.run(
      "INSERT INTO processed_updates (update_id, processed_at) VALUES (?, ?)",
      [update.update_id, new Date().toISOString()]
    );
    db.run("COMMIT");
  } catch (error) {
    db.run("ROLLBACK");
    throw error;
  }

  await processMessage(update);
}

The exact transaction design depends on what is being processed, but the principle is consistent: duplicate delivery is normal in distributed systems, so handlers should be safe to run more than once.

From Message to Tool Call to Reply

When a Telegram message arrives, the bot does not immediately hand raw text to a model and execute whatever comes back. The request follows a controlled pipeline:

Verify that the chat and user are permitted to use the assistant.
Apply per-user and global rate limits.
Load the minimum relevant conversation context and persistent memory.
Send the model a system policy, the user message, and a small allowlisted tool catalog.
Validate every requested tool call against a runtime schema and authorization policy.
Execute approved tools, append structured results, and continue the model loop within a strict step limit.
Persist useful state and send the final answer back through Telegram.

The model loop is intentionally bounded. A tool-capable model can ask for another tool result after receiving the previous one, so a useful assistant needs multiple steps. But it also needs a ceiling to prevent accidental loops, excessive API cost, or an unexpected chain of actions.

const MAX_TOOL_STEPS = 5;

for (let step = 0; step < MAX_TOOL_STEPS; step++) {
  const response = await openai.responses.create({
    model: MODEL,
    input,
    tools: allowedToolsFor(user),
  });

  const calls = extractToolCalls(response);
  if (calls.length === 0) {
    return extractText(response);
  }

  for (const call of calls) {
    const result = await runApprovedTool({
      userId: user.id,
      chatId: chat.id,
      call,
    });

    input.push(toolResultMessage(call, result));
  }
}

throw new Error("Tool loop exceeded its configured limit");

I also set timeouts at the boundaries: Telegram delivery, model requests, database operations, and external integrations. One slow provider should not hold a message handler forever.

A Safe Tool Policy

Tool calling is where an assistant becomes useful and where it can become unsafe. My policy is based on capability rather than prompt wording.

First, tools are allowlisted. The model sees only tools appropriate for the current user and context. A read-only stock quote tool, for example, is fundamentally different from a tool that sends an email or creates a calendar event. I do not expose administrative or infrastructure operations to a general chat flow just because the model could describe them.

Second, every tool has runtime argument validation. TypeScript types are useful during development, but they disappear at runtime. Tool arguments from a model or an external API are untrusted input. I validate them with a schema library or explicit checks before calling application code.

const createReminderSchema = z.object({
  task: z.string().min(1).max(500),
  time: z.string().regex(/^\d{2}:\d{2}$/),
  scheduleType: z.enum(["once", "daily", "weekdays", "weekly"]),
  dayOfWeek: z.string().optional(),
});

function validateReminder(args: unknown) {
  return createReminderSchema.parse(args);
}

Third, external side effects require explicit confirmation. If the assistant is about to send a message, create an event, modify a document, or perform another consequential action, it prepares a preview and asks the user to confirm. A confirmation is tied to the intended action, expires quickly, and is consumed once. The system should not interpret “yes” from an unrelated later conversation as approval to send something.

Fourth, side-effecting operations receive an idempotency key. A network failure after a provider accepts a request is ambiguous: retrying without a key can create duplicate events, emails, or tasks. Where a provider supports idempotency, I pass a stable key. Where it does not, I persist an operation record and use provider-specific lookup or reconciliation where possible.

Finally, OAuth connections are scoped and isolated. I request the narrowest permissions needed, avoid broad account access by default, store connection references rather than casually exposing raw tokens, and make disconnecting an integration straightforward. Secrets belong in the deployment environment or a secret manager, never in source control, logs, prompts, or tool output.

SQLite, WAL, and Scheduling Correctness

I run SQLite in write-ahead logging mode:

PRAGMA journal_mode = WAL;
PRAGMA foreign_keys = ON;
PRAGMA busy_timeout = 5000;

WAL improves concurrency for this workload because readers can continue while a writer is committing. It does not turn SQLite into a multi-writer database. There is still one writer at a time, so transactions should be short, indexes should support the scheduler’s queries, and write-heavy background work should not be mixed carelessly with long interactive transactions.

The scheduler stores jobs in SQLite rather than trusting in-memory timers. A worker periodically finds due jobs, atomically claims one, runs it, and records the outcome. The claim prevents two worker loops from executing the same job simultaneously in the same database.

UPDATE scheduled_jobs
SET status = 'running',
    locked_at = :now,
    lock_token = :token
WHERE id = (
  SELECT id
  FROM scheduled_jobs
  WHERE status = 'pending'
    AND run_at <= :now
  ORDER BY run_at
  LIMIT 1
)
AND status = 'pending';

A worker is not a durable queue merely because it runs in a loop. Durability comes from the database records: pending jobs, attempts, lock timestamps, completion state, and idempotency keys. If the process dies after claiming a job, recovery logic detects stale locks and returns eligible work to the pending state. If the process dies after an external side effect but before recording completion, idempotency and reconciliation logic determine whether it is safe to retry.

For recurring jobs, I calculate the next run after a successful execution and store times consistently, typically in UTC with the user’s timezone retained for display and recurrence rules. Timezones and daylight-saving transitions deserve dedicated tests; “every day at 9” is more complicated than adding 24 hours.

Error Handling, Rate Limits, and Operations

Every integration can fail. Telegram can time out, an OAuth token can be revoked, OpenAI can rate-limit a request, and a third-party API can return malformed data. The assistant should explain failures plainly without leaking secrets or internal stack traces.

I categorize errors into retryable and non-retryable classes. Network timeouts, temporary 429 responses, and many 5xx errors can be retried with exponential backoff and jitter. Invalid arguments, revoked permissions, and user-denied confirmations should not be blindly retried. Retries have caps, deadlines, and structured logs so a bad provider does not create an infinite background loop.

Rate limits exist at multiple layers: Telegram message handling, model calls, tool calls, and external APIs. For interactive chat, a per-user token bucket or short rolling window is usually sufficient. I also limit tool-loop depth, tool-call count, payload size, and concurrent outbound requests. These controls protect both cost and availability.

Deployment is intentionally simple: one application instance, persistent storage mounted outside ephemeral container layers, environment-based configuration, and a process supervisor or platform health checks. Before each deploy, I run migrations in a controlled step and ensure the prior polling consumer has stopped. Health checks verify that the process is alive; readiness checks should also verify that configuration and the database are usable.

Backups are not optional because SQLite is the system of record. I take regular backups from a consistent SQLite snapshot, retain multiple recovery points, encrypt backups where appropriate, and periodically test restoration. A backup that has never been restored is only a theory.

Tests, Observability, and Scaling Boundaries

The highest-value tests are not model snapshot tests. They cover authorization decisions, runtime validation, confirmation expiry, idempotency, scheduler claims, stale-lock recovery, timezone behavior, and duplicate Telegram updates. I use mocked provider clients for deterministic unit tests, then run a small number of integration tests against isolated credentials or test resources.

For observability, each incoming Telegram update receives a correlation id. Logs include the update id, user or chat identifier where safe, request duration, model request id when available, tool name, retry count, and job id. I record metrics for error rates, latency, tool failures, queue age, worker recovery, and rate-limit rejections. I log metadata, not secrets or private message content by default.

This architecture has clear scaling boundaries. SQLite with one active polling process is excellent for a personal assistant and modest traffic. It becomes a constraint when multiple application instances need concurrent writes, background work grows significantly, or webhook-based horizontal ingress becomes necessary. At that point, I would move durable state to a server database such as Postgres and use a real queue for independently scalable workers. I would not pretend that adding more containers around one SQLite file solves distributed coordination.

Build Checklist

Create a Telegram bot and restrict initial access to known user or chat ids.
Start with Telegraf long polling and ensure only one consumer runs at a time.
Build a small OpenAI orchestration loop with a maximum number of tool steps.
Expose only an explicit, per-user allowlist of tools.
Validate every tool argument at runtime before execution.
Split read-only tools from side-effecting tools; require preview and confirmation for the latter.
Use scoped OAuth connections and keep credentials out of code, prompts, and logs.
Persist jobs, attempts, locks, and idempotency keys in SQLite.
Enable WAL, keep write transactions short, and plan around SQLite’s single-writer model.
Implement stale-lock recovery and bounded retry behavior for workers.
Add structured logs, metrics, alerts, and restoration-tested backups.
Test duplicates, retries, revocations, crashes, and timezones before relying on automation.

Repository and Implementation Notes

The implementation evolves, but the core idea remains stable: keep the chat interface simple and put the engineering effort into policy, persistence, and recoverability.

View the project source on GitHub.

Conclusion

A useful personal AI assistant is less about giving a model unlimited access and more about designing reliable boundaries around it. Telegram provides the interface, OpenAI provides reasoning and language, Composio can provide controlled access to connected services, and SQLite provides a durable foundation for a small deployment.

The hard parts are familiar engineering problems: authorization, input validation, duplicate delivery, idempotency, retries, recovery, backups, and observability. Solving those deliberately turns an impressive chatbot demo into an assistant I can trust to use every day.

What's All Am I Hosting? Full Infrastructure Breakdown

Shubham — Sat, 04 Jul 2026 18:52:41 +0000

Every few months, someone asks me how I run my entire online presence for basically nothing. The short answer is: I don't pay for what I can get for free.

The long answer is this post.

My entire infrastructure this site, APIs, email, monitoring, URL shortener, dev tools runs on free-tier cloud services. Total cost: $0/month. That's less than a single AWS load balancer costs for an hour.

Here's exactly how it works, why I chose each piece, and what I'd do differently.

The Philosophy: Free Tier First

I have a simple rule: if a service has a generous free tier that covers my use case, I use it. If I outgrow it, I'll pay but most of us never outgrow free tiers for personal projects.

The second rule: own the critical paths. DNS is the backbone, so it's on Cloudflare (free, but best-in-class). The main site is on Vercel (free, seamless Next.js deployment). Everything else databases, email, APIs, monitoring is a managed service that solves exactly one problem well.

DNS: Cloudflare (The Glue That Holds It All Together)

Everything starts with DNS. Cloudflare runs chan.ns.cloudflare.com and dave.ns.cloudflare.com as my authoritative nameservers. Every subdomain in this post is a DNS record that Cloudflare serves for free.

I use Cloudflare as a pure DNS provider no CDN proxying on most records except a few redirects (cal, link, mail). The proxied records hide my origin IP and give me free SSL termination, but I keep most records direct because I want full control over the traffic path.

Why Cloudflare over Route53 or self-hosted? Cloudflare's free plan includes unlimited DNS queries, DNSSEC, easy API access, and their dashboard is fast. Route53 charges per query. Self-hosting DNS is unnecessary complexity. Free + best-in-class = no contest.

The Main Site: Vercel

shubhkumar.in is hosted on Vercel's free tier. The apex domain uses an A record to 216.198.79.1 (Vercel's anycast IP for apex domains you can't use a CNAME at the root).

Vercel's free tier includes 100GB bandwidth, 6000 build minutes, automatic SSL, and edge network distribution. For a Next.js site with ISR, this is more than enough. The site loads fast everywhere because Vercel serves it from their edge network.

The www subdomain CNAMEs to the root standard practice.

Other Vercel-Hosted Sites

cv.shubhkumar.in Resume site. Next.js, deploys from GitHub.
news.shubhkumar.in Another Next.js site.

Hosted Applications: The Free Tier Dream Team

Render API Server

api.shubhkumar.in runs on Render's free tier. It handles contact forms, webhooks, and server-side endpoints the static site can't handle. Render gives 750 hours/month plenty for a low-traffic personal API.

Why Render over Railway or Fly.io? Render has the most generous free tier for this use case. The deploy experience is smooth (Git push → deploy), and SSL is automatic.

GitHub Pages Lightweight Pages

connect.shubhkumar.in is a simple social link aggregator Linktree-style but self-hosted. Single HTML page, zero cost, instant deploy from a GitHub repo.

Infrastructure: The Stuff That Runs in the Background

Tailscale Private Network Bridge

tail.shubhkumar.in points to my Tailscale node at 100.115.133.19. Tailscale creates a WireGuard mesh across all my devices laptop, home server, cloud VMs. The DNS record lets me reach my home lab from anywhere using a proper subdomain.

The real magic: Tailscale handles NAT traversal automatically. My home server is behind CGNAT (common with Indian ISPs), and Tailscale punches through without any port forwarding. Free tier: up to 100 devices.

Databases Managed, Never Self-Hosted

I use managed databases exclusively. Supabase (Postgres) for anything that needs relational queries and real-time subscriptions. MongoDB Atlas for document storage when the schema is fluid. Both on free tiers or their cheapest paid plans whichever covers the workload.

Self-hosting a database is the fastest way to turn a weekend into an ops nightmare. Backups, replication, patches, disk space all someone else's problem. The managed premium is worth every rupee.

Fly.io Lightweight Apps

track.shubhkumar.in hosts WakaAPI (self-hosted WakaTime stats) on Fly.io. Free allowance covers the tiny resource usage 3 shared-CPU VMs with 256MB RAM, 3GB storage, 160GB outbound.

Cal.com Scheduling

cal.shubhkumar.in Cloudflare-proxied redirect to Cal.com. Self-hosting a calendar scheduler isn't worth my weekend.

Better Uptime Monitoring

status.shubhkumar.in Free tier. Monitors all endpoints, notifies on Slack. 10 monitors with 3-minute checks and a public status page.

Tools and Redirects

Dub.co URL Shortener

go.shubhkumar.in runs on Dub.co's free tier. Short, memorable links go.shubhkumar.in/github, etc. Open-source, great API, free tier includes custom domains and basic analytics.

Used to run YOURLS on a VPS. Moving to Dub.co saved maintenance and gave better analytics.

Simple Redirects

link.shubhkumar.in and mail.shubhkumar.in are Cloudflare-proxied redirects using 192.0.2.1 (Cloudflare's placeholder IP). No server needed Cloudflare page rules handle the redirects.

Email Infrastructure: The Hardest Part

Email is the hardest thing on a personal domain. I run three services for different purposes because each solves a specific problem.

Zoho Mail Primary

Primary email on Zoho's free plan 5 mailboxes with 5GB each, custom domain, IMAP/SMTP, calendar. The last remaining free tier for professional email on a custom domain after Outlook killed their free custom domain offering and Google Workspace charges $6/user/month.

MX: mx.zoho.com (priority 10), mx2/3 as fallbacks. DMARC set to reject with Cloudflare reporting.

Trade-off: Zoho's spam filtering is decent but not Gmail-level. For free, acceptable.

SimpleLogin Email Aliases

simple.shubhkumar.in Creates aliases that forward to my primary inbox. If a service sells my email, I delete the alias. Free tier: 15 aliases, PGP encryption, open-source.

Resend Transactional + Broadcast Emails

I use Resend for all outgoing emails transactional notifications, broadcast newsletters, and contact form submissions. It handles everything through a single clean API with good deliverability out of the box.

Resend's free tier includes 100 emails/day, which covers my low-volume needs. DKIM and SPF configured through forms.shubhkumar.in for proper authentication.

Security and Verification Records

DMARC (reject) Strictest policy. Reports to Cloudflare's DMARC reporting. Caught email spoofing attempts at least twice.
BIMI Shows my logo next to authenticated emails. Mostly vanity but looks professional.
Keybase Domain ownership proof.
Google Search Console Site ownership for search analytics.

What I Don't Use (And Why)

No Kubernetes. Everything fits in docker-compose or managed platforms. K8s is operational overkill for one person.
No AWS. Pricing model punishes hobbyists. One misconfigured resource = surprise bill. I use SES for email only when necessary.
No self-hosted CI. GitHub Actions is free for public repos.
Databases: Managed Supabase (Postgres), MongoDB Atlas, etc. Free tiers + cheapest plans cover everything. Self-hosting a database is unnecessary ops overhead.

Cost Breakdown

Service

Cost

What It Runs

Vercel

Main site (Next.js) + CV + News

Cloudflare DNS

All DNS records, proxied redirects

Render

API server

GitHub Pages

Link aggregator

Fly.io

WakaAPI instance

Better Uptime

10 monitors, status page

Dub.co

URL shortener

Zoho Mail

Primary email, custom domain

SimpleLogin

15 email aliases

Resend

Transactional + broadcast emails

Tailscale

Mesh VPN, 100 devices

Supabase

Managed Postgres (free tier)

MongoDB Atlas

Managed MongoDB (free tier)

Total

$0/mo

~15 services, one domain, full infra

Lessons Learned

You don't need to self-host everything. Used to run my own email server, Git server, CI huge time sink for zero benefit. Managed services let you focus on what matters.
DNS TTL matters. Low TTL (1–300s) on frequently changed records. High TTL (86400) on stable records for faster lookups.
Email deliverability is a second job. DKIM + SPF + DMARC + BIMI + reverse DNS + feedback loops takes a full day to set up. Get it right once, don't touch it.
Free tiers are designed to hook you. That's fine as long as you understand the migration cost before you're locked in.
Monitoring is not optional. Better Uptime caught three outages I wouldn't have noticed until someone emailed me.

The Reality

Running your own infrastructure is a trade-off setup time and occasional debugging for complete control and zero ongoing cost. For me, it's worth it.

But I also know when to stop. I don't self-host email. I don't run a Docker registry. I don't build custom dashboards. The services I chose handle those well enough that my time is better spent building on top of them.

Building My Personal Website From Scratch: Tech Stack, Architecture, and Lessons Learned

Shubham — Sat, 27 Jun 2026 19:12:59 +0000

A personal website is more than just a portfolio it's a playground for experimenting with architecture, performance, and production-ready engineering.

Introduction

Ask ten software engineers what their personal website is for, and you'll probably hear the same answer: "It's my portfolio."

While that's true, I wanted mine to be something more.

I wanted shubhkumar.in to be a platform that could grow with me a place to showcase projects, host my CV, publish technical blogs, and experiment with ideas before applying them in production systems.

Rather than using a static template or website builder, I decided to build everything from scratch. My goal wasn't to use the most technologies possible; it was to create a clean architecture that was fast, maintainable, and easy to extend.

Today, the website consists of two main parts:

A Next.js frontend deployed on Vercel
A Node.js + Express backend deployed on Render

Behind the scenes, MongoDB stores dynamic content, while Redis speeds up API responses through caching.

It sounds like a fairly standard stack and in many ways, it is. But the interesting part wasn't choosing the technologies. It was designing how they work together.

Why Build It From Scratch?

There are countless templates and portfolio generators available today. They look great, take minutes to deploy, and require almost no maintenance.

So why spend time building everything yourself?

For me, the answer was simple.

I wanted complete control.

Not just over the design, but over the architecture.

I wanted a backend that wasn't tightly coupled to a frontend. I wanted my content to live in one place instead of being duplicated across pages. Most importantly, I wanted a project that reflected how I build software professionally.

Every new feature became an opportunity to solve a real engineering problem instead of simply adding another section to a webpage.

The Tech Stack

I deliberately kept the stack simple.

Frontend

Next.js
Tailwind CSS
Hosted on Vercel

Next.js gives me everything I need for a modern website:

Server Components
Static rendering
Excellent SEO
Fast routing
Built-in image optimization
Incremental Static Regeneration (ISR)

Tailwind CSS keeps styling consistent without maintaining a large CSS codebase.

Deploying to Vercel makes the frontend almost effortless. Every push automatically builds and deploys the latest version.

Backend

Instead of relying on Next.js API routes, I built a dedicated backend using:

Node.js
Express
Hosted on Render

This backend acts as the single source of truth for all dynamic content.

Whether it's:

portfolio information
experience
projects
resume data
future APIs

everything is served from one backend.

Keeping the backend independent means it can later power:

a mobile app
an admin dashboard
CLI tools
browser extensions
or any future frontend

without changing business logic.

Database

Dynamic content is stored in MongoDB.

Documents include:

Profile information
Experience
Skills
Projects
Portfolio data

Interestingly, blog posts are not stored in MongoDB. They are maintained separately, allowing the website content and blog content to evolve independently.

Caching

To reduce unnecessary database queries, the Express API caches responses in Redis.

The flow looks like this:

Client
   │
   ▼
Express API
   │
   ▼
Redis
   │
Cache Hit?
   │
 ┌─┴─────────────┐
 │               │
Yes             No
 │               │
 ▼               ▼
Return      MongoDB
Response        │
                ▼
          Store in Redis
                │
                ▼
          Return Response

Most requests never reach MongoDB.

This keeps API responses fast while reducing database load.

Overall Architecture

At a high level, the system looks like this.

                 +----------------------+
                 |      Next.js         |
                 |   Hosted on Vercel   |
                 +----------+-----------+
                            |
                            |
                     HTTP Requests
                            |
                            ▼
                +----------------------+
                |   Express Backend    |
                |   Hosted on Render   |
                +----------+-----------+
                           |
               +-----------+-----------+
               |                       |
               ▼                       ▼
        Redis Cache             MongoDB Atlas

Although there are multiple services, each one has a single responsibility.

Next.js renders pages.
Express serves business logic.
Redis caches responses.
MongoDB stores data.

Keeping responsibilities separate makes the system easier to reason about and easier to extend.

Why I Didn't Use Next.js API Routes

This was probably the architectural decision that influenced the project the most.

Many Next.js applications place all backend logic directly inside API routes.

There's absolutely nothing wrong with that approach.

But I wanted something reusable.

By separating the backend, the frontend becomes just another client.

Tomorrow, if I decide to build:

an Android app
an iOS app
a desktop application
another website

they can all consume the exact same API.

No duplicated logic.

No duplicated validation.

No duplicated database queries.

Everything lives in one place.

Making the Backend the Single Source of Truth

The homepage.

The portfolio.

The CV.

Future applications.

All of them consume the same backend.

Instead of every page maintaining its own copy of data, everything originates from one API.

Updating my experience in MongoDB automatically updates every place where it's displayed.

This significantly reduces maintenance and prevents data from going out of sync.

The Unexpected Problem: Cache Invalidation

The most interesting problem wasn't building the website.

It was keeping it fresh.

Initially, everything looked perfect.

MongoDB stored the latest content.

Redis cached API responses.

Next.js generated static pages.

Performance was excellent.

Yet something strange happened.

Whenever I updated content, users didn't always see the changes immediately.

Sometimes it took several seconds.

Sometimes much longer.

At first, I assumed Redis was serving stale data.

After debugging for a while, I realized Redis wasn't the problem at all.

The real issue was that there were two completely independent caching layers.

The API cache and the frontend cache.

The API could already have fresh data while Next.js continued serving previously generated pages.

Everything was technically working exactly as intended.

The architecture, however, wasn't.

Solving It with Event-Driven Revalidation

Instead of waiting for caches to expire naturally, I switched to an event-driven approach.

Whenever content changes, the following sequence happens:

Admin API

      │

      ▼

Update MongoDB

      │

      ▼

Trigger Next.js Revalidation

      │

      ▼

Flush Redis Cache

      │

      ▼

Users receive fresh content

This means content updates propagate almost immediately without waiting for cache expiration.

The important lesson here is that caching is only half the problem.

The other half is knowing exactly when to invalidate that cache.

Designing a reliable invalidation strategy is often harder than adding caching in the first place.

Hosting Strategy

Keeping the frontend and backend separate also simplified deployment.

Frontend

The Next.js application is deployed on Vercel.

Benefits include:

Automatic deployments
Preview environments
Global CDN
Optimized image delivery

Backend

The Express server runs independently on Render.

Separating deployments means I can:

deploy backend fixes without rebuilding the frontend
deploy UI updates without touching backend services
scale each independently in the future

Lessons Learned

Building this website taught me several lessons that extend far beyond personal projects.

1. Simplicity scales

A small, well-structured architecture is easier to maintain than an unnecessarily complex one.

2. Separate responsibilities

Frontend rendering, backend logic, caching, and persistence all have different jobs.

Keeping those responsibilities isolated makes the system easier to evolve.

3. Build reusable APIs

The backend shouldn't exist solely for one website.

Treating it as a standalone service opens the door for future applications without additional work.

4. Cache invalidation deserves as much attention as caching

Adding Redis is easy.

Designing when and how cached data should be refreshed is where the real engineering begins.

5. Personal projects are the best place to experiment

Production systems often have strict requirements.

Personal projects provide the freedom to test ideas, refine architectures, and learn from mistakes.

Many of the lessons learned while building this website are directly applicable to larger production systems.

What's Next?

The website continues to evolve.

Some ideas I'm exploring include:

A richer admin experience for managing content
Better analytics and monitoring
Search functionality
AI-powered features
Additional APIs for future projects
More automation around content publishing

Because the architecture is modular, adding new capabilities doesn't require rewriting existing components.

That's exactly how I wanted the system to grow.

Final Thoughts

Building shubhkumar.in wasn't about creating another portfolio website.

It was about building a platform that reflects how I think about software engineering.

Choosing Next.js, Tailwind CSS, Node.js, Express, MongoDB, and Redis wasn't about following trends. It was about selecting tools that work well together while keeping the architecture clean and maintainable.

The biggest lesson wasn't learning a new framework or deploying another application.

It was realizing that good architecture isn't defined by how many technologies you use.

It's defined by how clearly each piece of the system is responsible for one job and how well those pieces work together.

If there's one takeaway I'd leave you with, it's this:

Treat your personal projects like production systems. Not because they need enterprise-scale complexity, but because they're the best place to learn the engineering practices you'll eventually use in production.

After all, the best portfolio isn't the one with the fanciest animations it's the one that demonstrates how you think as an engineer.

Moving from 60s to 6s: Latency Optimization Lessons from Functional Programming

Shubham — Wed, 24 Jun 2026 10:36:02 +0000

The broader tech community often views functional programming (FP) as an elegant academic exercise: useful for type systems, formal reasoning, and compiler guarantees, but distant from high-throughput production systems.

That framing misses something important. FP can improve the way teams model asynchronous work, failures, and state transitions. But it is not a substitute for finding the actual source of latency.

In a distributed workflow engine, we reduced observed end-to-end completion time from roughly 60 seconds to under 6 seconds for the common successful path. The primary cause was architectural: we removed repeated polling and queue wait from the synchronous execution path. PureScript and Haskell helped us express the resulting asynchronous flow explicitly and safely; they did not, by themselves, create a 10x latency improvement.

This is the engineering story behind that change, the measurements it supports, and the tradeoffs it introduced.

What the numbers mean

The 60-second and under-6-second figures are observed end-to-end timings for the workflow’s common success path, measured from request acceptance through the final response. They are not a universal service-level objective, a benchmark of every workflow type, or a claim about every percentile under every load level.

For a production latency claim, the useful view is a before/after comparison with the same workload and scope:

Scope: identical successful workflow type, including validation, business-rule evaluation, external calls, state update, and response.
Load: compare equivalent request rate, worker availability, dependency health, and database conditions.
Distribution: report p50, p95, and p99, along with sample size and the observation window, rather than relying on a single elapsed time.
Boundaries: state whether timings include client/network time, queue time, retries, and downstream-service time.

In this case, the roughly 60-second to under-6-second result should be read as an observed common-path improvement. The main lesson is diagnostic: most of the old latency was scheduled waiting, not useful computation.

The bottleneck: polling-based workflow execution

The original system used a pull-based worker architecture. Each request moved through sequential stages: validation, business-rule evaluation, external-service interactions, state transitions, and final reconciliation.

A database-backed work queue coordinated that workflow:

A worker completed a step and persisted the updated state.
A later worker polled the database for pending work.
After discovering the work, it executed the next stage and persisted the result.
The cycle continued until the workflow completed.

This design had real benefits. It made work durable, gave operators a visible recovery point, and supported retries. It also inserted a scheduling delay between stages. With several sequential transitions, those polling intervals and queue waits accumulated.

The system was not primarily compute-bound. It was wait-bound.

The architectural change: a fast path and a durable path

We separated the responsibilities that had previously been forced through one path:

Fast path: execute the request directly when the workflow can complete synchronously.
Durable path: retain queued execution for retries, recovery, delayed work, and cases that cannot safely finish inline.

A representative fast path is:

Request → Validation → Business Rules → External Service Call → State Update → Response

Instead of persisting and waiting for a poll between every step, the request continues through that chain while the required dependencies are available. Removing those handoffs is what removed the dominant source of delay.

The queue was not eliminated because it was bad. It was moved out of the successful synchronous path because its durability and scheduling semantics were unnecessary for every transition.

Where functional programming helped

PureScript’s Aff runtime gave the direct path a useful execution model: non-blocking asynchronous effects, composable sequencing, structured error handling, and cancellation/resource-safety primitives. Similar properties are available in other ecosystems; the language was an enabler, not the performance mechanism.

FP techniques improved the implementation in three practical ways:

Explicit effects: database writes, remote calls, logging, and retries are visible in the program’s effectful boundary instead of being hidden in incidental control flow.
Typed outcomes: expected failure modes can be represented as data, making it clearer which errors respond immediately, retry, or transfer to durable processing.
Composable stages: validation, rule evaluation, and external interactions can be assembled and tested as small units without scattering callback or exception handling across the workflow.

These properties made the fast path easier to reason about and operate. They did not compensate for a queueing architecture that was adding avoidable wait.

Failure handling and async decoupling tradeoffs

The direct path makes a request faster by coupling more work to the request lifetime. That tradeoff needs to be deliberate.

Queued workflows decouple producers from consumers, absorb bursts, provide durable handoff points, and allow retry/recovery to proceed after the original request has ended. A synchronous fast path gives up some of that decoupling in exchange for lower latency. It can increase pressure on downstream dependencies, expose callers to longer in-flight work, and require careful timeout, cancellation, idempotency, and backpressure policies.

The design therefore needs a clear transfer rule. When the direct path encounters a retryable failure, an unavailable dependency, a deadline risk, or work that must outlive the request, it records enough durable state and hands the workflow to the durable path. That handoff must be idempotent so a timeout or ambiguous response does not duplicate an externally visible action.

Useful safeguards include:

per-stage deadlines and bounded retries;
idempotency keys for state-changing external calls;
circuit breaking and concurrency limits around dependencies;
durable audit records at defined commit points; and
separate metrics for direct completion, fallback, retry, and recovery outcomes.

Measure the architecture, not just the aggregate

Average latency can hide both queueing and tail failures. Instrument each transition so the system can distinguish queue wait, execution time, persistence time, and downstream-service time. Then compare p50, p95, and p99 before and after the change under matched load.

For this workflow, the key measurement was not merely that a request became faster. It was that the old path spent substantial time waiting between otherwise short stages. That evidence justified changing the execution model. The percentile view then verifies whether the fast path improves typical and tail behavior, while fallback and error metrics show whether reliability has regressed.

Conclusion

The useful conclusion is not that functional programming delivers a fixed latency multiplier. The observed reduction from roughly 60 seconds to under 6 seconds came primarily from removing polling and queue wait from the common successful path.

Functional programming contributed by making the asynchronous orchestration, failure cases, and fallback boundary easier to express and review. The durable workflow system continued to matter for the work that needs decoupling, retries, and recovery.

Find the waiting first. Then choose an architecture that removes unnecessary waiting while preserving the operational guarantees the workload actually requires.

The Disconnected Edge: How We Solved In-Flight Data Sync at 35,000 Feet

Shubham — Sun, 14 Jun 2026 01:55:15 +0000

Most application architectures assume the network is available often enough to repair mistakes: fetch fresh configuration, retry an API call, consult a central database, or stream a missing asset from a CDN.

An aircraft edge system does not get that safety net. For long stretches, the onboard platform must operate as if the backend does not exist. When a connection appears, it may be short, expensive, slow, or interrupted halfway through a transfer.

That changed how we designed an in-flight entertainment platform. The hard part was not serving movies, games, catalogs, and passenger experiences locally. The hard part was moving the right data between a central backend and intermittently connected aircraft without leaving either side in an ambiguous state.

This is the offline-first model we used: make the aircraft independently useful, treat synchronization as a deliberate protocol rather than a background convenience, and make every partial failure recoverable. Specific identifiers and thresholds here are illustrative; the design principles are the point.

The operating environment: disconnected by default

Each aircraft carried an embedded edge system responsible for the passenger experience: media, applications, digital publications, catalogs, configuration, and operational telemetry. It had local storage and local services, but no guarantee of a usable path to the internet.

That creates constraints that are easy to underestimate from a cloud-first mindset:

Connectivity windows are intermittent and may end without warning.
Bandwidth can be scarce, variable, and costly.
Devices must keep serving known-good content while updates are incomplete.
A reboot, power event, or failed transfer cannot corrupt the active passenger experience.
Central systems must distinguish “not yet uploaded” from “lost forever.”

The backend remained authoritative for centrally managed content, configuration, and policy. But the aircraft had to be operationally autonomous. Offline mode was not a degraded fallback; it was the normal mode.

Separate the data lanes before designing sync

“Sync everything” is not a protocol. Different kinds of data have different correctness rules, sizes, and priorities. We treated them as separate lanes:

Content: large immutable media and application assets. Correctness means every byte matches a known version.
Configuration: smaller, product-sensitive settings. Correctness means a complete, compatible version is activated atomically.
Telemetry and analytics: append-only events generated onboard. Correctness means no silent loss and no harmful double counting.
Operational commands: centrally issued intent, such as a requested content set. Correctness means explicit acknowledgement and an auditable lifecycle.

Once the lanes were separated, we could give each one a suitable delivery, retry, and conflict model instead of forcing all data through one generic “sync” abstraction. It also gave the scheduler useful priorities: a small compatible configuration update can be more valuable than the next chunk of a large optional asset.

Make sync a persisted state machine

A sync worker that only lives in memory is fragile. It forgets why it stopped after a reboot, cannot distinguish a paused transfer from a failed one, and makes recovery dependent on log archaeology. We modeled synchronization as a small persisted state machine.

idle → discovering → planning → transferring → verifying
   ↑                                      ↓
   └──── paused / retry_wait ← activating ← ready
                              ↓
                         quarantined

The exact labels are less important than the invariant: every transition is durable and restartable. The device records the active release, requested release, manifest version, compatibility result, artifact/chunk progress, retry schedule, event-upload cursor, and the reason for any terminal failure. On startup, the worker reads that state and resumes conservatively rather than guessing from partial files.

{
  "activeRelease": "release-2026-05",
  "desiredRelease": "release-2026-06",
  "syncState": "transferring",
  "manifestHash": "...",
  "verifiedBytes": 734003200,
  "eventCursor": 817291,
  "nextRetryAt": "2026-06-13T08:15:00Z"
}

Persisted state also creates a useful boundary between mechanism and policy. The transfer mechanism knows whether a chunk is verified. Policy decides whether to retry now, defer a nonessential asset, quarantine a release, or ask an operator to investigate.

Versioned manifests made content deterministic

For content and application bundles, we avoided asking the device to infer what changed from a directory listing. The backend produced an immutable, versioned manifest describing the desired release: asset identifiers, sizes, hashes, dependencies, compatibility requirements, and configuration version.

{
  "releaseId": "ife-2026.06.13",
  "minPlatformVersion": "4.8.0",
  "schemaVersion": 3,
  "assets": [
    {
      "path": "movies/example.mp4",
      "sha256": "…",
      "bytes": 1789423412
    }
  ],
  "configVersion": "cfg-2026-06-13-02"
}

An edge device first fetched the small manifest, checked signature and compatibility, compared it with local state, and then downloaded only missing or changed artifacts. Every artifact was verified before it could be considered ready. A successful HTTP response was not proof of correctness; the expected hash was.

Large files were transferred in chunks with persisted progress. A connection loss simply paused work at the latest verified boundary. On the next window, the device resumed instead of starting again.

for each required asset:
  read verified chunk offsets from local state
  request missing ranges
  verify each completed chunk
  verify final asset hash
  mark asset ready only after verification

Compatibility is part of correctness. A manifest can demand a platform version, a schema version, or a migration path that the device does not support. In that case the worker must reject the release explicitly and report why; silently applying a newer structure to an older runtime creates harder failures later.

Never activate a half-synced release

Downloading a release and serving it are separate operations. New artifacts were staged outside the active content set. Only when the entire manifest was present, verified, compatible, and accompanied by a valid configuration did the device switch the active pointer in one durable operation.

BEGIN TRANSACTION;
  assert release is complete and verified;
  assert configuration is compatible;
  set active_release = :releaseId;
  record activated_at = :timestamp;
COMMIT;

This is the key recovery property: a failed or interrupted sync leaves the previous known-good release active. The next sync can resume staging. It never turns an incomplete directory into the passenger experience.

Rollback followed the same model. Retaining a previous verified release made recovery a pointer change rather than an emergency re-download. The device reported both its desired release and active release so the backend could distinguish “download in progress” from “activation failed.”

An end-to-end sync window

A typical connection window followed a deliberately boring sequence. First, the device authenticated and sent a compact status summary: software version, active release, desired-release status, storage pressure, event cursor, and the outcome of the prior attempt. The backend replied with policy and the latest eligible manifest.

Next, the device planned work. It verified that the release was compatible and that there was enough staging capacity. It then prioritized small metadata, critical configuration, and pending commands before large content artifacts. Meanwhile, telemetry upload ran in bounded batches so that a large backlog could not starve a critical update, and a big download could not starve telemetry indefinitely.

During transfer, every request had a deadline. Completed ranges were recorded only after verification. If the connection disappeared, the worker retained its exact state and backed off until the next viable attempt. If all assets passed verification, activation was a separate, short transaction. Finally, the device sent an acknowledgement containing the active release and any rejected or quarantined items.

That acknowledgement closed the loop. The backend could not infer success from having served a manifest. A release was operationally complete only after the device reported it active.

Upload events as an idempotent append-only stream

Telemetry and passenger analytics are fundamentally different from content. They are produced locally while disconnected, then uploaded later. The edge system persisted events before attempting delivery and assigned each event a stable identity, such as a device id plus a monotonic sequence number or a generated UUID.

{
  "deviceId": "aircraft-edge-42",
  "sequence": 817292,
  "eventId": "01J…",
  "type": "content_started",
  "occurredAt": "2026-06-13T08:12:24Z",
  "payload": { "contentId": "movie-123" }
}

The backend accepted batches idempotently. If a connection failed after the server accepted a batch but before the aircraft received acknowledgement, retrying the same events was safe because the backend could recognize identities it had already processed.

Server acknowledgements advanced a durable cursor only after accepted events were recorded. The edge node retained data until that acknowledgement was committed, then compacted acknowledged records according to retention policy. This produces at-least-once transport with effectively-once accounting when the consumer deduplicates by event identity.

Not every failure deserves an infinite retry. A temporarily unavailable endpoint may be retried with backoff. A malformed event, unsupported schema, or permanently rejected payload should move to a quarantine or dead-letter record with a reason, preserving evidence without blocking the entire queue. Operators can inspect, repair, discard, or replay it through an explicit process.

Conflicts need a taxonomy, not a universal CRDT

Offline systems do create conflicts, but “use CRDTs” is not a complete answer. A conflict policy should follow ownership and business semantics.

Server-authoritative data: release manifests, pricing policy, and centrally managed configuration should have a single authority. The device applies a compatible version; it does not merge edits.
Append-only facts: telemetry is normally merged by deduplication, ordering metadata, and domain-specific aggregation not by overwriting records.
Locally authored mutable state: if multiple offline writers can independently edit the same logical object, a CRDT may be appropriate when its merge semantics match the product. Counters, sets, and collaborative metadata are possible examples.
Irreconcilable changes: some domains require explicit rejection or human review. Last-write-wins is a policy choice, not a conflict-resolution strategy.

CRDTs are valuable because they can guarantee convergence under particular operations and merge rules. They do not create correct business semantics automatically. For most centrally controlled data, immutable versions plus server authority were easier to reason about and audit.

Bandwidth, storage, and rollout policy

A device did not attempt every task whenever a network interface looked available. It assessed the connection, applied policy, and worked through a priority queue. Small manifests and critical configuration came first; event uploads and large optional artifacts were scheduled according to remaining budget and product priority.

Transfers used bounded concurrency, request deadlines, exponential backoff with jitter, and persisted state. Retrying blindly can consume an entire connectivity window, so retries were capped and re-evaluated when conditions changed. Each request carried enough identity to make retries observable and safe.

Storage required policy too. The active release and a known-good rollback release were protected from normal eviction. Incomplete staging content could be removed safely when it no longer matched the desired manifest. Optional, verified assets could be evicted only according to explicit rules, never based on a generic filesystem cleanup that might remove an activation dependency.

Rollouts were also progressive. A new release should first be eligible for a limited ring of devices, then expand only when acknowledgements, validation results, and operational signals remain healthy. A spike in compatibility failures, verification errors, activation failures, or abnormal backlog growth should pause expansion. The design needs a clear rollback path before a release is ever offered to a wider fleet.

Security, credentials, and privacy at the edge

An offline device still needs a trust model. Transport encryption protects an available connection, but it does not prove that a downloaded artifact is an approved release. Manifests and artifacts need integrity verification; depending on the threat model, signed manifests provide stronger provenance than hashes fetched from the same channel as the content.

Devices should authenticate with distinct, scoped, revocable identities. Credential rotation needs a tolerable overlap period: the device validates a replacement credential, records it durably, and retains the old one only long enough to avoid being stranded during an interrupted rotation. Revocation and expiry must be visible in device state and backend operations.

Data minimization matters as much as transport security. Sync only data the aircraft needs to operate, collect only telemetry necessary for product and operational use, and define retention boundaries for local queues and backend ingestion. Avoid logging access tokens, passenger-sensitive data, or complete event bodies when metadata will do. Backend authorization should scope every request to the device and fleet it is permitted to access.

Operations: measure partial progress

Intermittent systems need better observability than a simple “online” metric. We tracked release state, manifest version, bytes remaining, verified chunks, last successful contact, event backlog age, upload acknowledgement cursor, retry counts, active release, failed validation reasons, and storage pressure.

Those signals made it possible to answer useful operational questions: which devices are running an old release, which are stuck on a corrupt artifact, which have an increasing analytics backlog, and whether a rollout problem is global or isolated to a connection path.

The health objective is not constant connectivity. It is eventual convergence without harming the active experience: a device should remain useful on a known-good release, make measurable progress when a connection exists, and surface failures that need intervention. Recovery paths were deliberate: stale transfer leases could be reclaimed, incomplete staging directories could be cleaned safely, old verified releases could be rolled back to, and event batches could be replayed without double counting.

Test the failure modes, not only the protocol

The system needed tests for conditions that are rare in a development environment but routine at the edge:

Connection loss during manifest retrieval, range download, upload, and acknowledgement.
Process restart or power loss before and after an active-release pointer change.
Duplicate event batches, reordered responses, and stale acknowledgements.
Corrupted chunks, incompatible manifests, expired credentials, and full disks.
Clock drift, long offline periods, and recovery after a device misses multiple releases.
Stale locks, interrupted credential rotation, and release rollback during an active sync.

Fault injection was more useful than happy-path tests alone. We simulated slow links, short connections, partial range responses, duplicate uploads, backend timeouts, and storage exhaustion. The invariant under test was simple: after any interruption, the device must either continue serving the last verified release or recover to a well-defined state without inventing completion.

What changed in our design process

Building for aircraft made us stop treating the network as a dependable dependency. The device had to remain useful with a stale but verified local state. The backend had to accept delayed, duplicate, and partial communication without losing its understanding of the fleet.

That led to a few durable rules:

Make offline operation a first-class product requirement.
Persist sync state; never rely on a process remembering where it was.
Use immutable manifests and hashes for large artifacts.
Stage, verify, and atomically activate releases; retain a known-good rollback target.
Persist outbound events and make server ingestion idempotent.
Define conflict policy by ownership and domain semantics; use CRDTs only where their merge model fits.
Prioritize work intentionally across bandwidth and storage constraints.
Measure partial progress, backlog age, and recovery not only availability.

Conclusion

Offline-first synchronization is not a smaller version of cloud sync. It is a distributed-systems problem where partitions are normal and recovery must be designed before the failure happens.

For an in-flight edge platform, immutable releases, resumable verified transfer, atomic activation, idempotent event delivery, explicit conflict rules, and clear operational state made the system dependable even when connectivity was not. Those patterns apply far beyond aircraft: ships, retail stores, factories, field devices, and any product that must keep working when the network disappears.

Turning Your AI Into an Adversarial Security Agent: The SKILLS.md Framework

Shubham — Sun, 07 Jun 2026 09:18:06 +0000

A continuation of: Breaking to Build: How CTF and Bug Bounty Hunting Rewires System Design

In my previous article, I explored how offensive security permanently changes the way engineers think about systems. Once you've spent enough time exploiting race conditions, bypassing authorization boundaries, abusing SSRF chains, and breaking assumptions hidden deep inside application logic, you stop viewing software as a collection of features.

You start viewing it as an attack surface.

That shift fundamentally changes how you design production systems. The problem is that modern software development is no longer purely human-driven. Today, a massive percentage of engineering work happens alongside AI coding assistants. Tools now generate thousands of lines of code faster than most engineers can review them.

And that introduces a brand new problem.

AI systems are optimized for one thing: Generate code that works.
Attackers are optimized for something completely different: Find code that breaks.

That difference matters. A generated API endpoint might pass every functional test while still exposing a devastating BOLA (Broken Object Level Authorization) vulnerability. A generated webhook handler might function perfectly while allowing SSRF into your internal infrastructure. A generated payment workflow might appear correct while collapsing into a double-spend condition under concurrent execution.

The code works. The architecture fails. And that is exactly where real-world vulnerabilities are born.

The Missing Layer in AI-Assisted Development

Most teams currently treat AI coding agents like extremely fast junior engineers. They give them instructions like:

"Build this feature"
"Refactor this service"
"Create this migration"

The model responds by optimizing for correctness, readability, and implementation speed. Security is rarely treated as a first-class objective.

Most AI systems are never explicitly taught to think like attackers. They are taught how software should behave; they are not taught how software is abused.

That distinction becomes increasingly dangerous as organizations move toward autonomous code generation, AI-assisted architecture, and agentic development workflows.

The solution turns out to be surprisingly simple: instead of prompting for features alone, we inject a persistent security reasoning framework directly into the agent's operating context.

That framework is SKILLS.md.

What Is SKILLS.md?

SKILLS.md is a structured operational framework that teaches an AI agent how to evaluate software through an adversarial lens. It is not a prompt, a simple checklist, or another copy-paste of the OWASP Top 10. It is a behavioral framework that continuously pushes the model to ask "How would an attacker abuse this?" before it asks "How do I implement this?"

The goal is to transplant the mindset developed through years of CTF competitions, bug bounty hunting, and incident response directly into the AI’s reasoning process.

Why Traditional Security Checklists Fail

Most security documentation focuses on known vulnerability categories (XSS, SQLi, CSRF, SSRF, IDOR). These are important, but attackers rarely think in categories. They think in assumptions.

Every vulnerability exists because somebody assumed something was true:

The frontend won't send invalid values.
Only authenticated users can reach this endpoint.
This request executes once at a time.
Nobody can access that internal network.

Bug bounty hunting teaches you something uncomfortable: assumptions are where systems fail. Security is often less about blocking payloads and more about eliminating dangerous assumptions. SKILLS.md is built entirely around that philosophy.

The Evolution From Builder To Breaker

Plaintext

Traditional Engineering:
Requirement ──> Implementation ──> Testing ──> Deployment

Security-Oriented Engineering:
Requirement ──> Implementation ──> Abuse Analysis ──> Boundary Verification ──> Concurrency Analysis ──> Deployment

The first workflow asks: Does this feature work?

The second asks: What happens when somebody intentionally tries to break it?

SKILLS.md forces AI agents into the second mode.

The Specifications: SKILLS.md

Modern AI tools and tools like Claude Code have evolved past static, single-file home directory configurations. They utilize the Agent Skills Standard, which relies on a nested folder footprint (skills/<skill-name>/SKILL.md) and mandatory YAML frontmatter.

The frontmatter contains semantic metadata. When you start an AI session, the engine scans the description block to automatically determine when to pull this skill into context.

Here is the production-ready implementation file.

Markdown

---
name: secure
description: "Evaluates software architecture and code through an adversarial lens. Automatically invokes when generating APIs, designing features, reviewing code, or managing authentication, state, and data boundaries."
user-invocable: true
---

# Security-First Architecture Skill

**Axiom:** Inputs malicious. Clients untrusted. Networks hostile. Dependencies may be compromised. Never trust; always verify at execution point.

---

## Domain Controls

| # | Domain | Attacks | Key Controls | Core Question |
|---|--------|---------|-------------|---------------|
| 1 | **State / Race** | TOCTOU, double-spend, optimistic-lock loss | `SELECT FOR UPDATE`; distributed lock (Redis `SET NX PX`); validate ETag every write | Can same op succeed twice in parallel, or state change between check and act? |
| 2 | **AuthZ / BOLA** | IDOR, BOLA, mass assignment, GraphQL introspection | Ownership check at data layer, not route; allowlist binding (strong_params/Pydantic DTO); disable introspection in prod; tenant-scope every query | What changes if resource ID or any request field changes? Who verified ownership? |
| 3 | **SSRF** | Metadata endpoint, DNS rebind, redirect chain, `gopher://` | Resolve DNS → re-validate IP vs RFC-1918+169.254+fc00 denylist; allowlist domains; HTTPS-only via egress proxy; proxy follows redirects, not app code | Who controls final destination after DNS resolution and redirects? |
| 4 | **Path Traversal** | `../../`, URL-encode, null byte, Zip Slip, symlink | `realpath()`/`Path.resolve()` → verify under root; never concat user input to paths; use UUIDs as storage keys; validate archive entries before extract | Can user-controlled string, after normalization, escape storage boundary? |
| 5 | **Blast Radius** | Lateral movement, over-permissive IAM, credential reuse | Non-root containers, read-only rootfs, `--cap-drop ALL`; per-service least-privilege IAM; separate creds per env/service; mTLS between services | If this service is fully compromised, what else is reachable without new creds? |
| 6 | **Fail-Closed** | Broad catch-continue, feature-flag default-on, null bypass | Default DENY in every auth check, exception block, conditional; feature flags off for security features; `default: deny` in all security-relevant switches | What does system permit on unexpected error, null, or undefined in auth path? |
| 7 | **Secrets / Crypto** | Log leak, `alg:none` JWT, weak HMAC, IV reuse, timing oracle, weak PRNG | Secrets Manager + rotation; CSPRNG only; pin JWT alg server-side; RS256/ES256 cross-service; `timingSafeEqual`; AES-256-GCM unique nonces; ban MD5/SHA-1/DES/RC4 | Can credential be recovered, forged, or brute-forced from token, log, or build output? |
| 8 | **Supply Chain** | Typosquat, dep-confusion, `postinstall` RCE, unpinned deps | Exact-version pin + lockfile; verify signatures/hashes; audit `postinstall` scripts; private registry namespace; `npm audit`/`pip-audit`/`cargo audit` in CI | What third-party code executes in build/runtime that we don't own and audit? |
| 9 | **Event Integrity** | Replay, out-of-order, schema-invalid crash, webhook spoof | Idempotency keys (Redis TTL); strict schema → DLQ on malformed; HMAC-SHA256 webhook sig + 5-min timestamp window; sequence numbers for ordering | Can replaying/reordering an event corrupt state? Is every inbound event cryptographically authenticated? |
| 10 | **LLM / AI** | Prompt injection (direct/indirect), agentic tool abuse, secondary injection | Treat model output as untrusted input; explicit tool-auth gateway per user permission; strict output schema (JSON Schema/Pydantic); human-in-loop for irreversible actions; no ambient creds in agent env | What auth boundaries exist between model output and execution? Can injected content in retrieved data override system instructions? |
| 11 | **Injection** | SQLi, XSS, CMDi, SSTI, XXE, NoSQLi, ReDoS | Parameterized queries; `execFile([...])` not `exec(string)`; context-aware output encoding; disable XML external entities; reject `$`-prefix JSON keys; audit regexes for backtracking; never eval user input in templates | Does any user-controlled string reach an interpreter without structural separation? |
| 12 | **AuthN / Session / OAuth** | Credential stuffing, session fixation, missing server-side invalidation, redirect-URI wildcard, missing PKCE, token-in-URL | CSPRNG session tokens; rotate on login/priv-escalation; server-side invalidation on logout; `Secure;HttpOnly;SameSite=Strict`; Argon2id (64MB/3-iter) or bcrypt≥12; exact-match `redirect_uri`; PKCE for public clients; bind `state` to session; identical error messages + timing | Can attacker reuse, predict, fix, or intercept session/token/auth-code without knowing original secret? |
| 13 | **Log Exposure** | Credential leak, PII capture, log forgery via `\n\r`, stack-trace disclosure | Scrub tokens/JWTs/keys/PAN/SSN/email before every log write; allowlist loggable fields; sanitize `\n\r\033` in user input; disable verbose stack traces in prod responses | If every log line leaked, what sensitive data would be visible? |
| 14 | **Deserialization** | pickle/ObjectInputStream/`yaml.load`/Marshal RCE, gadget chains, DoS via nested structures | Never deserialize untrusted data with native formats; use JSON/Protobuf + schema validation; if unavoidable: allowlist filter + HMAC-sign payload; always `yaml.safe_load` | Does any code path deserialize attacker-influenced data with a class-instantiating deserializer? |
| 15 | **Rate Limits / DoS** | Credential stuffing, ReDoS, zip bomb, billion-laughs, large upload, unbounded pagination | Rate limits per-IP + per-user at gateway and app; tightest on auth/reset/OTP; cap body/upload size at ingress; GraphQL depth+complexity limits; timeouts on all external calls + queries; queue expensive ops; `limit ≤ 100` on pagination; return 429 + `Retry-After` | Can a single actor trigger resource consumption that degrades availability for others? |
| 16 | **HTTP Controls** | CORS credential theft, XSS via missing CSP, clickjacking, MIME-sniff bypass, SSL-strip | Exact-origin CORS allowlist (never reflect `Origin`, never `*` + credentials); HSTS `max-age=63072000;includeSubDomains;preload`; CSP allowlist `script-src`, no `unsafe-inline/eval`; `X-Content-Type-Options:nosniff`; `X-Frame-Options:DENY`; `Referrer-Policy:strict-origin-when-cross-origin`; `__Host-` cookie prefix | Can cross-origin page, framed page, or MIME-sniffed resource exploit browser trust in this origin? |
| 17 | **File Upload** | Zip Slip, polyglot exec, oversized upload, SVG XSS, archive bomb | UUID storage keys (never user filename); separate origin (S3 bucket/CDN subdomain) + `Content-Disposition:attachment`; validate by magic bytes not MIME; enforce size+count at ingress; reject SVG/HTML or sanitize with DOMPurify; cap archive extraction size + entry count | Can an uploaded file execute code, escape storage, or gain application-origin trust? |
| 18 | **Info Disclosure** | Stack traces, version headers, debug endpoints, username enum, timing leak | Opaque error IDs to clients, full detail server-side only; remove `Server`/`X-Powered-By`/`X-AspNet-Version`; disable debug/admin/introspection in prod (fail startup if debug=prod); identical error messages + response times; scan for exposed debug routes | Does any response, header, error, or timing difference reveal internal structure to unauthorized caller? |
| 19 | **Build Pipeline** | Compromised CI, over-permissive build IAM, unsigned images, secrets in logs, fork PR secret leak | Pin CI actions to commit SHAs; secrets only on protected branches; read-only source + write-only artifact IAM for build; sign images (cosign/Sigstore) + verify at deploy; OIDC ephemeral creds (no long-lived keys); branch protection: review + CI + signed commits required | Can compromised dependency update, CI job, or PR introduce malicious code reaching production without human review? |

---

## Verification Protocol (run sequentially on every review/design)

1. **Trust Boundaries**   map all input sources (HTTP, queues, webhooks, files, env); strip all safety assumptions
2. **Concurrency**   find TOCTOU windows; verify DB-level locking on every state mutation
3. **AuthZ**   confirm ownership check at data-access layer, not route layer, on every request
4. **Privileges**   least-privilege IAM, service accounts, container caps, DB permissions
5. **Blast Radius**   full compromise simulation: map reachable services/creds/data without new credentials
6. **Interpreter Paths**   trace user input to SQL/shell/template/XML/YAML/pickle; confirm structural separation
7. **Auth Surface**   session lifecycle (issue→rotate→invalidate), MFA, OAuth parameter binding, credential storage
8. **Log Audit**   confirm no secrets/PII/payment/raw bodies in any log path including error handlers and APM agents
9. **Rate Controls**   sensitive endpoints have per-user + per-IP limits; expensive ops queued with concurrency caps
10. **HTTP Controls**   CORS allowlist, security headers, CSP, no verbose error leakage on all response paths
11. **Upload & Deserialization**   files stored outside app origin with server-generated keys; no native deserializer on untrusted data
12. **Build Pipeline**   CI secrets scoped, actions SHA-pinned, images signed and verified at deploy

> **Target:** Code that behaves predictably when an adversary is actively attempting to shatter it.

Installation Guide

To ensure your AI assistant picks up this framework without breaking file path scopes, use the explicit terminal setups below depending on your favorite environment.

1. Claude Code

Claude Code evaluates configurations from your global home configuration space (~/.claude) or local workspaces (.claude).

Global Installation (Applies across all code repositories on your machine without altering git states):

Bash

mkdir -p ~/.claude/skills/security-review
# Save the Markdown block above into this file:
nano ~/.claude/skills/security-review/SKILL.md

* **Project-Specific Installation** *(Committed directly into git to enforce security rules across the whole engineering team)*:

bash
mkdir -p .claude/skills/security-review
nano .claude/skills/security-review/SKILL.md


### 2\. Cursor (and custom IDEs)

Cursor indexes markdown definitions gracefully via workspace indexing or dedicated custom instructions.

Bash

shell
mkdir -p .cursor/skills/security-review
nano .cursor/skills/security-review/SKILL.md


_(Alternatively, you can save it as a top-level_ `SKILLS.md` _file in your root workspace)._

### 3\. Orchestrated Agent Frameworks (CrewAI / LangGraph)

For autonomous multi-agent pipelines, pass the file directly as system background data inside your orchestration configuration:

YAML

yaml
agent:
role: Adversarial Security Auditor
backstory: You analyze architectural code changes strictly through the lens of SKILLS.md rules.
instructions:
- Ingest the custom SKILLS.md baseline constraints.
- Check every generated code route against Concurrency and Trust Boundaries.


## How to Use the Framework

Once installed, you don’t need to repeatedly copy-paste security prompts. The framework leverages both passive and active execution behaviors.

### Method A: Automated Semantic Triggering (Passive Mode)

Because the custom frontmatter contains a deep `description` string, the AI continuously evaluates your inputs. If you type a standard prompt that crosses defensive boundaries, the engine auto-activates the skill behind the scenes.

*   **Your Prompt:** _"Write an endpoint that takes a user's uploaded image URL, downloads it, and processes metadata."_

*   **The AI's Internal Action:** The engine intercepts words like _URL_ and _downloads_. It auto-loads `security-review` from disk, catches the **SSRF / Deterministic Routing** rule, and adds domain validation code before outputting the feature.


### Method B: Manual Slash Invocation (Active Mode)

If you want to explicitly mandate an application review, call the skill directly via standard interface paths.

*   **In Claude Code:** Use the custom command shortcut directly inside your terminal session:

    Bash

    ```


    /security-review Review our new database migration file for potential data isolation vulnerabilities.


    ```

plaintext

In Cursor Composer: Force index mapping by targeting the file handle directly inside the chat bar:

  Please build out our stripe payment callback router following the criteria defined in @SKILL.md

Real-World Transformations: Before and After

When SKILLS.md is active, the agent stops acting like a passive code generator and starts acting like an unyielding architecture reviewer.

Example: Payment Balance Deduction

Without SKILLS.md: The user asks for a simple point redemption function. The AI generates a standard SELECT balance followed by an UPDATE balance sequence. It looks clean, passes unit tests, but immediately falls to a race condition exploit when a user executes parallel curl requests.
With SKILLS.md: The agent's internal reasoning detects a state change trigger. It forces the SQL generation to include row-level isolation via SELECT ... FOR UPDATE or requires a strict Idempotency-Key header transaction check.

Example: User-Configured Webhooks

Without SKILLS.md: The user prompts the AI to build an outbound webhook engine so users can get alerts. The AI uses a simple Axios/Fetch call passing the target parameter. An attacker signs up, sets their webhook to [http://169.254.169.254/latest/meta-data/](http://169.254.169.254/latest/meta-data/), and extracts cloud infrastructure IAM keys.
With SKILLS.md: The agent flags the user-controlled URL routing pattern. It refuses to output the code until it builds an accompanying domain allowlist check, wraps the execution in an isolated egress proxy, or isolates the protocol rules.

The Bigger Shift

Today, engineers review AI-generated code. Tomorrow, AI systems will review AI-generated code. Eventually, entire engineering workflows will become completely autonomous.

When that happens, security can no longer exist as an afterthought or a final manual compliance checklist performed at the tail end of a sprint. It has to become a core property of the AI's internal reasoning loop.

AI does not automatically inherit security instincts. It inherits whatever mental models we explicitly give it. If you train an AI to think only like an engineer, it will build systems. If you train it to think like an attacker, it will help you build resilient systems.

The future belongs to the teams that can do both. Secure software is not created by accident; it is forged when someone spends enough time thinking about how it breaks first.

Breaking to Build: How CTF and Bug Bounty Hunting Rewires System Design

Shubham — Sun, 31 May 2026 18:50:37 +0000

Software engineers are trained to create: read a requirement, design the happy path, write the code, pass tests, and ship. Authorized security practice adds a useful second question: what assumptions does this design make, and how could those assumptions fail?

Capture The Flag exercises and properly scoped vulnerability research are valuable because they train that question. The point is not to treat production systems as puzzles or to chase clever exploits. It is to bring adversarial thinking back into normal engineering work: define trust boundaries, verify authorization, reduce capability, log important decisions, and make unsafe behavior difficult by default.

That change in perspective has improved how I design APIs, multi-tenant services, background workers, and operational tooling. These are the system-design lessons that stick.

1. Data has provenance, not automatic trust

A database is durable storage, not a trust boundary. A value may have originated in a user form, webhook, import, support tool, partner API, or an earlier application bug. Reading it back from PostgreSQL does not make it safe for every new context.

The key distinction is between a value’s provenance and the sink where it will be used. A display name may be valid as text in a JSON response but unsafe if inserted as HTML, used in a shell command, or interpolated into a query. The correct defense depends on that destination.

untrusted input → validate shape at ingress → store as data
                                             ↓
                                 encode or parameterize at each sink

For HTML, prefer framework auto-escaping and avoid raw HTML rendering. If rich user-authored HTML is a genuine product requirement, sanitize it with a maintained, context-appropriate library and keep the allowed elements and attributes intentionally small. For SQL, use parameterized queries. For commands, avoid shell interpolation; use APIs that pass arguments separately whenever possible.

// Good: the database driver keeps data separate from SQL syntax.
const project = await db.query(
  "select id, name from projects where tenant_id = $1 and id = $2",
  [tenantId, projectId]
);

// Prefer UI/framework escaping for text. Avoid injecting user data as raw HTML.
renderText(project.name);

“Sanitize everything” is too vague to be a reliable rule. Validate structure at ingress, preserve data as data, and encode or parameterize it for the specific output context. That approach also makes code review more precise: reviewers can ask, “what is the sink, and what protection matches it?”

2. Design authorization into every object lookup

Broken object-level authorization (often called IDOR or BOLA) is rarely fixed by choosing less guessable identifiers. UUIDs can reduce accidental enumeration, but they do not establish ownership or permission. The server must decide whether the authenticated principal may perform the requested action on the requested object.

I prefer authorization-first repository methods over a generic “load by id” followed by an easily forgotten policy check. The method shape makes tenant and actor context mandatory.

type Actor = { userId: string; tenantId: string; roles: string[] };

action async function loadProjectForRead(actor: Actor, projectId: string) {
  return db.oneOrNone(
    `select id, name, status
       from projects
      where id = $1
        and tenant_id = $2`,
    [projectId, actor.tenantId]
  );
}

async function getProject(actor: Actor, projectId: string) {
  const project = await loadProjectForRead(actor, projectId);
  if (!project) throw new NotFoundError();
  return project;
}

Production policies are often more nuanced than tenant membership: roles, project membership, delegated access, ownership, resource state, and action type may all matter. Centralize that policy where possible, test both allow and deny cases, and return responses that do not reveal unnecessary details about resources outside the caller’s scope.

3. Turn ambient power into explicit capabilities

Many high-impact failures begin with code that has more authority than it needs. A request handler that receives an all-powerful database client, a broad cloud credential, or a general-purpose administrative service can accidentally cross boundaries.

Instead, expose narrow operations that express intent: createInvoiceForTenant, readOwnProfile, or queueReportForProject. Pass an actor or capability explicitly. This makes authorization visible in APIs and reduces the chance that a helper silently acts with system-wide privileges.

type RefundCapability = {
  actorId: string;
  tenantId: string;
  maxAmountCents: number;
};

async function requestRefund(
  capability: RefundCapability,
  invoiceId: string,
  amountCents: number
) {
  if (amountCents > capability.maxAmountCents) {
    throw new ForbiddenError("Refund amount exceeds approval limit");
  }

  // Scope the invoice lookup and record the decision before side effects.
  return refunds.create({ capability, invoiceId, amountCents });
}

This is not a replacement for database permissions, network controls, or policy enforcement. It is an application-level design habit that makes least privilege easier to preserve.

4. Threat model before implementation details harden

A short threat-modeling session early in a feature often prevents expensive rewrites later. It does not need a large ceremony. For a new endpoint or worker, I ask:

What assets, actions, and data are worth protecting?
Who are the actors, and which identities or credentials can they present?
Where does untrusted data enter, cross a boundary, or reach a sensitive sink?
Which actions are irreversible, high-value, or easy to replay?
What evidence will help us detect and investigate misuse?

The output can be a few bullets in the pull request. The value is forcing assumptions into the open before they become interfaces that every later service depends on.

5. Secure defaults beat security checklists

Security controls are more reliable when the safe path is the easiest path. Require tenant context in repository queries. Make internal fields opt-in in serializers. Set conservative timeouts. Deny access unless a policy grants it. Keep development diagnostics away from production responses.

Good defaults also apply to sessions and credentials: short-lived tokens where practical, scoped service accounts, rotation procedures, explicit expiry, and revocation paths. A system should be able to remove access quickly without requiring a redesign during an incident.

6. Observability is a security control

A policy decision that cannot be investigated is difficult to trust. Audit events should make important actions reconstructable: who initiated an operation, which resource and tenant were involved, which policy path allowed it, and whether the action succeeded.

audit.info({
  event: "project.read",
  actorId: actor.userId,
  tenantId: actor.tenantId,
  projectId,
  outcome: "allowed",
  requestId,
});

Logs must be useful without becoming a second data leak. Avoid raw credentials, authentication headers, full payment details, and sensitive message bodies. Apply retention controls, restrict access to audit stores, and alert on meaningful patterns such as repeated authorization denials or unusual bursts of privileged actions.

7. Test defenses in authorized environments

Security testing belongs in environments where you have permission: local labs, CTFs, intentionally vulnerable training applications, staging systems, or programs with an explicit scope and safe-harbor policy. The goal is to validate defenses without creating risk for other people’s data or services.

For product code, turn lessons into repeatable tests. Add authorization tests for cross-tenant access, property tests for parsers, integration tests for output encoding and serialization, and regression tests for issues already fixed. Treat a discovered weakness as an opportunity to improve a class of failures, not merely patch one endpoint.

If you find a vulnerability in someone else’s system, follow the program’s reporting policy or use coordinated disclosure. Share the minimum evidence needed for reproduction, protect sensitive data, and give maintainers time to investigate and remediate.

Engineering checklist

Document data provenance and trust boundaries for new flows.
Validate at ingress; encode or parameterize for each output sink.
Scope every object lookup to the authenticated actor, tenant, and action.
Expose narrow capabilities instead of ambient administrative access.
Threat-model irreversible or high-value workflows before implementation.
Use deny-by-default policies, short-lived credentials, and explicit revocation.
Log security-relevant decisions without logging secrets or unnecessary personal data.
Test authorization boundaries and regressions in authorized environments only.

Conclusion

Authorized offensive-security practice is valuable because it makes system design assumptions visible. It teaches that storage is not trust, identifiers are not authorization, and a working happy path is not the same as a safe system.

The best outcome is not becoming suspicious of every line of code. It is building systems where boundaries, permissions, and recovery paths are explicit enough that ordinary engineering work stays secure by default.

Demystifying the Trinity: Functor, Applicative, and Monad in PureScript

Shubham — Sat, 30 May 2026 04:24:48 +0000

Functor, Applicative, and Monad can sound like a barrier to functional programming. They are not three competing ideas or magical containers. They are progressively more capable interfaces for working with a value while preserving the structure around it.

In PureScript, that structure might represent an optional value (Maybe a), a computation that can return an error (Either e a), an array of possibilities, or an effectful program (Effect a). The useful question is not “what metaphor fits?” but: what can I do without manually taking the value out and rebuilding its context?

Start with the type, not the metaphor

Maybe a says a value of type a may be absent. Either e a says a computation produces either an error e or a successful value a. Effect a describes a program which, when run, may perform synchronous JavaScript effects and produce a; asynchronous work is conventionally represented with Aff a.

These types are not runtime security or validation by themselves. Data from HTTP, a database, or JavaScript is still untrusted until validated at the boundary. The abstractions below help us compose the resulting typed values cleanly.

Functor: transform a value while keeping its context

A Functor supports map (also written <$>). Given a normal function a -> b, it transforms the value inside f a into f b.

class Functor f where
  map :: forall a b. (a -> b) -> f a -> f b

For Maybe, mapping runs the function for Just and preserves Nothing.

module Main where

import Prelude
import Data.Maybe (Maybe(..))
import Effect (Effect)
import Effect.Console (logShow)

toCents :: Int -> Int
toCents dollars = dollars * 100

main :: Effect Unit
main = do
  let amount = Just 50 :: Maybe Int
  let missing = Nothing :: Maybe Int

  logShow (toCents <$> amount)  -- Just 5000
  logShow (toCents <$> missing) -- Nothing

toCents stays a simple Int -> Int function. The Maybe Functor owns the “what happens when the value is missing?” rule. Use a Functor whenever the next operation is a pure transformation of one available value.

Applicative: combine independent contextual values

An Applicative extends Functor with pure, which places a value in a context, and apply (written <*>), which applies a contextual function to a contextual value.

class Functor f <= Applicative f where
  pure :: forall a. a -> f a
  apply :: forall a b. f (a -> b) -> f a -> f b

This is especially readable when a constructor needs several independently obtained values.

import Prelude
import Data.Maybe (Maybe(..))

type User = { name :: String, id :: Int }

makeUser :: String -> Int -> User
makeUser name id = { name, id }

maybeName :: Maybe String
maybeName = Just "Alice"

maybeId :: Maybe Int
maybeId = Just 1024

maybeUser :: Maybe User
maybeUser = makeUser <$> maybeName <*> maybeId
-- Just { name: "Alice", id: 1024 }

If either input is Nothing, the result is Nothing. Notice the function itself remains pure; Applicative handles the shared Maybe context. pure 42 :: Maybe Int produces Just 42.

“Independent” matters. Applicative composition fits when the next computation does not need the previous value to decide what computation to run. For validation that should collect several errors, use a validation type with an error-accumulating Applicative instance; Either normally returns one failure rather than collecting all of them.

Monad: choose the next computation from the previous result

A Monad adds bind (often written >>=). It lets the next function return another contextual value:

class Applicative m <= Monad m where
  bind :: forall a b. m a -> (a -> m b) -> m b

This is needed when a plain map would create nesting such as Maybe (Maybe Int), or when later work depends on an earlier successful result.

import Prelude
import Data.Either (Either(..))
import Data.Int (fromString)
import Data.Maybe (note)

parsePositiveInt :: String -> Either String Int
parsePositiveInt raw = do
  value <- note "Expected an integer" (fromString raw)
  if value > 0 then Right value
  else Left "Expected a positive integer"

orderTotal :: String -> String -> Either String Int
orderTotal rawPrice rawQuantity = do
  price <- parsePositiveInt rawPrice
  quantity <- parsePositiveInt rawQuantity
  pure (price * quantity)

Here, each <- extracts a successful Right for the next line. If parsePositiveInt returns Left, the remaining work is skipped and that error becomes the result. That short-circuiting is behavior of the Either Monad instance not a universal property of every Monad.

`do` notation is readable `bind`

PureScript’s do notation makes sequential composition practical. Conceptually, this:

do
  price <- parsePositiveInt rawPrice
  quantity <- parsePositiveInt rawQuantity
  pure (price * quantity)

is a readable form of:

parsePositiveInt rawPrice >>= \price ->
  parsePositiveInt rawQuantity >>= \quantity ->
    pure (price * quantity)

Use do for effectful programs too. The same sequencing idea works for Effect, Aff, Maybe, and Either; only the meaning of sequencing changes with the instance.

A practical selection guide

Functor: transform one value with a pure function. Example: format a Maybe Date.
Applicative: combine contextual values when their computations are independent. Example: construct a record from optional fields.
Monad: continue with a computation selected by an earlier result. Example: parse an identifier, then load data using that identifier.

Start with the least powerful abstraction that expresses the flow. <$> is often clearer than do for one transformation; <*> clearly communicates independent inputs; use do when sequencing or dependency is genuinely present.

Common mistakes

Calling every generic type constructor a “container.” It is a helpful first picture, not the definition.
Assuming types make untrusted input valid. Decode and validate runtime data before relying on static types.
Using Monad when Applicative expresses the intent better.
Assuming every Monad stops on failure. Arrays, state, readers, and effects have different sequencing behavior.
Confusing Effect with asynchronous work. Use Aff when the operation is asynchronous.

Conclusion

Functor, Applicative, and Monad are less mysterious when treated as composition tools. Functor transforms within a context. Applicative combines independent contextual values. Monad sequences computations whose next step depends on the previous result.

Once these distinctions become familiar, types like Maybe, Either, Effect, and Aff stop feeling like ceremony. They become explicit descriptions of how values and computations should flow through the program.

AI Is Making Senior Engineers 10x Faster - And 10x More Exhausted

Shubham — Thu, 28 May 2026 10:01:24 +0000

When AI coding tools first appeared, I thought:

“Nice. Less boilerplate.”

Now it sometimes feels like I’m managing a team of infinitely fast junior engineers that never sleep, occasionally hallucinate, and submit pull requests every 30 seconds.

As a senior engineer, AI has made parts of my work much faster. It has also increased the amount of attention I have to spend deciding what is safe, useful, and worth keeping.

Both things can be true at the same time.

The “10x” in the title is rhetorical, not a measured productivity claim. Some tasks genuinely shrink from hours to minutes. Others simply move the effort: from typing code to framing the problem, checking assumptions, reviewing output, testing behavior, and owning the consequences after release.

That distinction matters. Faster code generation is valuable. It is not the same thing as faster engineering.

The Good Part: AI Removes a Lot of Friction

There is plenty to like. Used well, LLMs are helpful for repetitive and bounded work:

scaffolding a familiar endpoint or component
writing a first pass at tests and fixtures
summarising an unfamiliar module before reading it closely
suggesting a refactor after the desired design is clear
drafting SQL, migrations, documentation, or scripts
turning notes into a checklist, rollout plan, or incident update

For those jobs, AI can reduce blank-page time and context switching. It can make a prototype cheap enough to test. It can also give experienced engineers more room to focus on the parts that need judgment: product trade-offs, system boundaries, failure modes, and maintainability.

That is real leverage. But leverage only helps when it is pointed in the right direction.

The Trade-Off: More Output Creates More to Validate

The uncomfortable part is that AI changes the shape of senior work. It makes it easy to produce plausible code quickly, including code that is subtly wrong for a particular system.

An assistant does not know the full history behind a strange-looking guard clause, the operational constraint hidden in an old incident report, or the business rule that lives outside the repository. It may infer those things correctly. It may also confidently invent an API, miss an authorization boundary, choose an unsafe default, or optimise the visible path while breaking an important edge case.

That means the senior engineer is not just authoring less. They are acting as editor, reviewer, systems thinker, and accountable owner for a larger stream of generated output.

The risk is not that every AI suggestion is bad. Many are perfectly serviceable. The risk is that clean, fluent code can create an illusion of understanding. Code that looks conventional is easier to accept before anyone has verified that it fits the domain.

So the bottleneck often moves from production to validation:

Does this satisfy the actual requirement, not just the prompt?
What assumptions did it make about data, permissions, latency, or failure?
Does it fit existing conventions and architectural boundaries?
Can the team explain, test, operate, and change it later?

Those are engineering questions. AI can assist with them, but it cannot take ownership of the answer.

Use AI Inside a Deliberate Review Workflow

My most useful rule is simple: generated code should enter the same engineering workflow as any other change. “The model wrote it” is not a reason to lower the bar; if anything, it is a reason to make the path to production more explicit.

A practical workflow looks like this:

Start with the outcome and constraints. Write down the user-facing behavior, non-goals, invariants, affected systems, and rollback plan before asking for an implementation.
Ask for a small change. Prefer one function, one module, or one narrow slice over a large, multi-file rewrite. Smaller diffs are easier to understand and review.
Read the diff as the owner. Do not review it like a copy editor. Trace important inputs and outputs, error paths, state changes, and permission checks.
Run the evidence. Build, lint, type-check, test, and exercise the relevant behavior locally or in a safe environment. Add the tests that would have caught the failure you are worried about.
Use human review for the meaningful change. A second engineer is especially useful when the work crosses service boundaries, changes data, affects security, or introduces a new abstraction.
Release with observability and a way back. Feature flags, metrics, logs, alerts, and a rollback path turn uncertainty into something manageable.

This is not bureaucracy for its own sake. It is how a team prevents speed at the keyboard from becoming risk in production.

Context and Design Still Come First

Good prompts help, but “context engineering” is more than writing a clever instruction. It is the work of making the problem legible: what the system does, where the boundaries are, what must not change, and how success will be observed.

Before generating implementation code, I try to provide or decide:

the desired behavior and examples of valid and invalid cases
the relevant interfaces, schemas, and repository conventions
performance, privacy, security, and compatibility constraints
which dependencies are allowed and which patterns are off limits
the tests, metrics, or acceptance criteria that define “done”

For complex work, it is often better to ask AI for options than for a finished patch. Ask it to identify trade-offs, list likely failure modes, or compare approaches against stated constraints. Then make the design decision deliberately. Once the design is clear, generation becomes much safer and faster.

The senior skill is not producing the largest prompt or accepting the most output. It is reducing ambiguity before output exists.

Quality Guardrails Make Speed Safer

Guardrails are not a substitute for judgment, but they reduce the chance that a rushed change becomes a costly surprise.

At a minimum, teams should keep the ordinary safeguards healthy: formatting, linting, type checks, automated tests, dependency and secret scanning, code review, and CI that blocks obvious regressions. The exact stack will vary, but the principle is stable: make the safe path the easy path.

AI-assisted work deserves a few additional habits:

Keep pull requests reviewable. Split mechanical changes from behavioral changes. Avoid combining a broad refactor with a feature unless there is a compelling reason.
Require ownership of every line. The author should be able to explain why the code exists, what it assumes, and how it fails.
Treat generated dependencies and snippets with caution. Verify package names, licenses, versions, APIs, and security implications rather than trusting a suggestion.
Test boundaries, not only happy paths. Focus on authorization, concurrency, retries, partial failure, malformed input, migration safety, and backward compatibility where relevant.
Protect sensitive context. Follow company policy for source code, credentials, customer data, and internal documents. A convenient prompt should not become a data-handling mistake.

These practices help regardless of who wrote the first draft. AI just makes their absence easier to notice because it can create so much change so quickly.

AI Changes Team and Process, Not Just Individual Productivity

The biggest effects are often social. If one person can generate a large patch in an afternoon, review queues can fill faster than reviewers can reason about them. If every task is treated as instant because a tool exists, planning becomes disconnected from integration, verification, and operational work.

Teams should therefore measure more than throughput. Deployment confidence, escaped defects, incident load, lead time through review, on-call pain, maintainability, and the ability of more than one person to work on a system all matter. A higher count of merged lines or tickets is not automatically progress.

There is also a learning concern. Junior engineers still need feedback loops that teach them to reason about systems, debug failures, and make trade-offs. Giving them generated solutions without discussion may accelerate a task while weakening the path to independent judgment. Pairing, design reviews, and asking people to explain a proposed change are more valuable, not less, when code is cheap to produce.

For senior engineers, the role increasingly includes setting norms: when AI is appropriate, what must be disclosed in a pull request, which checks are mandatory, and when a design conversation should happen before generation. Clear expectations reduce both risk and resentment.

Sustainable AI Use Means Protecting Attention

The exhaustion is not caused only by more work. It comes from rapid switching: prompt, inspect, correct, test, prompt again, answer review comments, and repeat. Constantly evaluating plausible output can be mentally expensive, especially when the code touches unfamiliar parts of a system.

To make AI useful without letting it consume the day, I try to use it intentionally:

Batch exploratory prompting instead of interrupting every few minutes.
Reserve uninterrupted time for design, deep reading, and difficult debugging.
Stop generating when I cannot clearly articulate what I am asking for.
Prefer a small, understood solution over a large “complete” patch.
Use checklists for repeatable review work so attention is saved for the novel risks.
Leave a decision record when the reasoning will matter to the next person.

Sometimes the fastest move is to write the small piece of code yourself. Sometimes it is to ask AI for a test matrix or a second opinion. Sustainable use is not maximising prompts. It is choosing the tool mode that preserves clarity and energy for the work only humans on the team can do.

The Real Leverage Is Judgment

AI is making some parts of senior engineering faster, sometimes dramatically. It is also making judgment, review, context, and operational responsibility more visible.

That does not make the tools a mistake. It makes the surrounding discipline more important. Use AI to remove friction, accelerate exploration, and handle bounded work. Keep humans responsible for design, validation, trade-offs, and the health of the system over time.

The goal is not to generate code as fast as possible. The goal is to ship changes the team understands, can support, and can improve without burning out the people accountable for them.