That description was true, but too small.

In 2026, TypeScript is no longer just the language people use to make React code less painful. It has become one of the main languages for building AI applications: chat interfaces, agents, tool calling systems, model gateways, browser AI features, workflow automation, internal copilots, and full stack products that sit between users and large language models.

The shift did not happen because TypeScript suddenly became a machine learning language. Python still owns the research side of AI. It is still the language of notebooks, training pipelines, PyTorch, data science, and experimentation.

TypeScript won a different part of the stack.

It became the language of AI product engineering.

That distinction matters. Most AI apps are not just models. They are user interfaces, API routes, streaming responses, auth systems, billing, databases, vector search, tool calls, background jobs, and observability. They are software products wrapped around probabilistic systems.

That is exactly where TypeScript is strongest.

The short version

TypeScript became the language of the AI app era because it sits at the intersection of five forces:

TypeScript is not the best language for training models.

It is becoming the best language for shipping AI features to users.

AI apps are not just model calls

The simplest AI demo looks like this.

const response = await model.generate("Write a summary of this document")
console.log(response.text)

That is fine for a demo.

A real AI product looks very different.

It needs to handle:

• User sessions

• Permissions

• Streaming responses

• File uploads

• Tool calls

• Prompt templates

• Model routing

• Structured outputs

• Retries and timeouts

• Token usage

• Rate limits

• Database writes

• Background jobs

• Error reporting

• Safety checks

• Human approval

• Observability

That is not a model problem. That is an application engineering problem.

This is the first reason TypeScript became so important.

AI applications live close to the product surface. They need frontend code, backend code, serverless functions, API handlers, form state, database clients, and deployment platforms. TypeScript can cover all of that without switching languages.

A team can write the chat UI, the streaming endpoint, the tool definitions, the validation schemas, and the database access layer in one language.

That is a big deal when AI product cycles are measured in days.

The data points in the trend

The trend is visible in developer data and ecosystem behavior.

GitHub's Octoverse 2025 report described AI, agents, and typed languages as driving one of the biggest shifts in software development in more than a decade. GitHub also reported that TypeScript reached the number one position on the platform in that report cycle.

Stack Overflow's 2025 Developer Survey shows how fast AI became normal developer tooling. It reports that 84 percent of respondents are using or planning to use AI tools in their development process, up from 76 percent the previous year. It also reports that 51 percent of professional developers use AI tools daily.

The State of JavaScript 2024 survey showed another important pattern: 67 percent of respondents said they write more TypeScript than JavaScript, and the largest single group said they only write TypeScript.

These are not isolated numbers. They point to the same direction.

Developers are using AI more. They are also using typed JavaScript more. The overlap is where modern AI app development is happening.

The more interesting evidence is in the tools people use.

Vercel's AI SDK describes itself as a TypeScript toolkit for building AI powered applications and agents with React, Next.js, Vue, Svelte, Node.js, and more. The official OpenAI TypeScript and JavaScript SDK provides server side access to the OpenAI API. Anthropic provides an official TypeScript SDK for the Claude API. LangChain.js provides JavaScript and TypeScript tools for agents, models, embeddings, vector stores, and workflows.

The center of gravity for AI app development is not only in Python notebooks anymore.

It is also in TypeScript repositories.

Why TypeScript fits AI product work

TypeScript works well for AI apps because AI apps are full of boundaries.

There is a boundary between the user and the app. Another between the app and the model. Another between model output and trusted application state. Another between tools and real systems. Another between frontend state and backend data.

Every boundary is a place where things can break.

TypeScript gives developers a way to describe those boundaries.

That does not make AI deterministic. It does not magically stop hallucinations. It does not replace testing.

But it does reduce the number of ordinary software mistakes around the model.

For example:

• A tool call should have a known input shape.

• A model response should be parsed before it touches business logic.

• A database write should not accept random model text as a trusted object.

• A UI component should know whether a message is streaming, complete, failed, or waiting for approval.

• A workflow should know which tools are read only and which tools can change real data.

TypeScript helps teams express those rules in code.

It is not about type theory. It is about not shipping chaos.

The AI stack moved closer to the web

Most people experience AI through web apps.

ChatGPT, Claude, Gemini, Perplexity, Cursor, v0, Replit, Notion AI, Linear integrations, customer support copilots, internal knowledge assistants, and dashboard copilots all have a strong web surface.

That matters because the web already had a dominant language family: JavaScript and TypeScript.

The AI app stack often looks like this:

In this architecture, TypeScript is not a side language. It is the glue.

It powers the interface. It powers the server route. It defines the tool input. It validates the output. It talks to the database. It streams tokens back to the browser.

This full stack continuity is the biggest practical advantage.

A Python backend can absolutely power an AI product. Many great AI products use Python. But if the frontend is TypeScript, the API client is generated into TypeScript, the validation schemas are needed in the browser, and the deployment target is serverless JavaScript, the pressure to keep more logic in TypeScript grows quickly.

That is why many teams end up with this split:

Python is still the lab.

TypeScript is increasingly the product floor.

Streaming made the frontend matter again

AI apps are not like traditional request response apps.

When a user asks a model a question, the response may take seconds. If the app waits for the whole response before showing anything, it feels slow.

That is why streaming became a core part of AI UX.

Instead of this:

Modern AI apps often do this:

This made frontend engineering more important, not less.

The app needs to render partial messages. It needs to handle cancelled requests. It needs to recover from broken streams. It needs to show tool calls in progress. It needs to keep the conversation state consistent.

TypeScript fits this because it already owns the browser side of the problem.

A simple AI message type might look like this:

type MessageStatus = "submitted" | "streaming" | "complete" | "failed"

type ChatMessage = {
  id: string
  role: "user" | "assistant" | "tool"
  content: string
  status: MessageStatus
  createdAt: string
  tokenCount?: number
}

That small type is not fancy. But in a real app, it prevents a lot of confusion.

Is the message still streaming? Did it fail? Was it produced by a user, assistant, or tool? Can the user retry it? Should it count toward billing?

Good AI UX depends on clean state.

TypeScript is good at clean state.

Structured output changed the game

Early AI apps often treated model output as plain text.

That works for chat. It does not work as well when the model needs to feed another part of the app.

For example, imagine asking a model to classify a support ticket.

Bad version:

This ticket is probably urgent and seems related to billing.

Useful version:

{
  "priority": "high",
  "category": "billing",
  "needsHumanReview": true
}

The second version can drive software. It can route a ticket, update a dashboard, trigger an approval flow, or create a task.

This is why structured outputs became so important.

OpenAI's Structured Outputs feature is designed to make model responses follow a supplied JSON Schema. Zod gives TypeScript developers a runtime schema validation library that also produces TypeScript types. The Vercel AI SDK supports schema based generation patterns. Together, these tools match the way AI apps are built.

Here is the idea in TypeScript:

import { z } from "zod"

const TicketClassification = z.object({
  priority: z.enum(["low", "medium", "high"]),
  category: z.enum(["billing", "bug", "feature", "other"]),
  needsHumanReview: z.boolean(),
  summary: z.string().min(1)
})

type TicketClassification = z.infer<typeof TicketClassification>

function handleClassification(raw: unknown) {
  const result = TicketClassification.parse(raw)

  if (result.needsHumanReview) {
    return createHumanReviewTask(result)
  }

  return routeTicket(result)
}

The important part is not the syntax.

The important part is the mindset.

Model output is untrusted until it is parsed. Once it passes validation, the rest of the app can treat it as a known shape.

That is exactly how professional AI apps should work.

Tool calling needs types

Agents are not just chatbots.

An agent can choose tools, call APIs, inspect results, and continue working. That makes tool definitions one of the most important parts of an AI system.

A badly designed tool is dangerous.

It may be too broad. It may accept vague parameters. It may allow destructive actions without approval. It may return too much data. It may make it easy for the model to do the wrong thing.

TypeScript helps because tool contracts can be written clearly.

const createIssueTool = {
  name: "create_issue",
  description: "Create a GitHub issue after the user has approved the title and body.",
  inputSchema: z.object({
    repo: z.string(),
    title: z.string().min(5),
    body: z.string().min(10),
    labels: z.array(z.string()).default([])
  })
}

That schema does several things.

It tells the model what the tool expects. It tells the runtime how to validate input. It gives the developer a type to use in code. It documents the boundary between language and action.

This is where TypeScript becomes more than a developer convenience.

It becomes part of the safety model.

A real AI app should not let a model call arbitrary functions with arbitrary JSON.

Every tool should have a name, a description, a schema, a permission level, and a logging path.

TypeScript makes that style natural.

The SDK ecosystem moved fast

TypeScript's AI rise is also about timing.

When the AI app boom started, the web ecosystem was already mature. Developers already had:

• React

• Next.js

• Node.js

• npm

• Vite

• tRPC

• Prisma

• Drizzle

• Zod

• Playwright

• Vitest

• Tailwind CSS

• Serverless platforms

• Edge runtimes

• Component libraries

Then AI SDKs arrived directly inside that ecosystem.

The Vercel AI SDK is provider agnostic and built for TypeScript app development. OpenAI maintains an official TypeScript and JavaScript library. Anthropic maintains an official TypeScript SDK. LangChain.js and LangGraph.js support agent and workflow development in JavaScript and TypeScript. The OpenAI Agents SDK for TypeScript targets agentic applications in JavaScript and TypeScript.

That means a developer can build a useful AI product without leaving the TypeScript world.

This matters because the best language is not always the one with the best syntax.

Often, it is the one with the shortest path from idea to production.

For AI apps, TypeScript has that path.

TypeScript is useful when the model is wrong

AI systems fail in strange ways.

A normal function usually fails because of a bug, a bad input, or an unavailable dependency.

A model can fail because it misunderstood the prompt, invented a field, ignored an instruction, mixed two tools, returned a half valid object, or gave a confident answer that looks correct but is not.

Types do not solve those problems.

But they help contain them.

Think of TypeScript as guardrails around a messy center.

The model can still be wrong. But the app should know what shape the wrongness is allowed to take.

For example, if a model classifies a transaction, it should not be allowed to invent a new transaction status that the rest of the system does not understand.

type TransactionRisk = "safe" | "review" | "blocked"

If the model returns maybe_suspicious, the app should reject it or map it through an explicit fallback path.

This sounds boring.

It is boring.

That is the point.

Reliable AI apps are built from boring constraints around powerful models.

The frontend is now part of the AI system

In older backend systems, frontend code was often treated as a display layer.

In AI apps, the frontend is more involved.

It may need to:

• Show streaming text

• Show tool call progress

• Let users approve or reject actions

• Render citations

• Display confidence levels

• Compare model outputs

• Let users edit prompts or instructions

• Handle voice input

• Handle file uploads

• Show partial results from long running workflows

• Warn users when the model is uncertain

The UI is not just showing the answer. It is managing the human model interaction.

That makes TypeScript valuable because frontend mistakes can become product mistakes.

A user should not accidentally approve a tool call because state was stale. A citation should not point to the wrong document because array indexes shifted. A retry should not create duplicate tasks because the client lost track of request IDs.

Here is a simple type for a tool approval flow:

type ToolApproval = {
  id: string
  toolName: string
  risk: "low" | "medium" | "high"
  proposedInput: unknown
  status: "pending" | "approved" | "rejected" | "expired"
  requestedAt: string
  approvedBy?: string
}

That type is small, but it forces the app to ask useful questions.

Is this tool call pending? Who approved it? Did it expire? Is it high risk? What exactly is being approved?

When an AI app can act on the real world, the UI becomes a control surface.

Control surfaces need strong state models.

Agent frameworks need application discipline

Agent demos are easy.

Production agents are hard.

A production agent needs more than a loop that calls a model until it finishes. It needs stop conditions, tool limits, memory rules, retries, traces, permission checks, evaluation sets, and fallback behavior.

TypeScript is a good fit here because agent systems are mostly orchestration.

They coordinate tools. They pass structured data. They maintain state. They call APIs. They update UIs. They emit logs.

This is normal software engineering, just with a model in the middle.

That is why the phrase "AI engineer" can be misleading. For many product teams, the AI engineer is not training a model. They are building reliable software around a model.

TypeScript is excellent for that kind of work.

The type system helps teams share intent

TypeScript's value grows with team size.

In a solo prototype, types may feel optional. In a team building an AI product, they become communication.

A type tells another developer:

• What this function expects

• What this API returns

• What states are possible

• What fields are optional

• What tool calls are allowed

• What errors should be handled

That is especially useful in AI apps because the domain changes fast.

Prompts change. Models change. Providers change. Product behavior changes. New tools get added. Old tools get retired. Workflows get split. Safety rules get stricter.

Types give the codebase a map.

For example:

type ModelProvider = "openai" | "anthropic" | "google" | "local"

type ModelRoute = {
  provider: ModelProvider
  model: string
  purpose: "chat" | "classification" | "embedding" | "tool_use"
  maxTokens: number
  fallback?: ModelRoute
}

This makes model routing explicit.

That is much better than scattering model names across random files.

AI apps need this kind of clarity because model behavior is already uncertain. The surrounding software should not also be uncertain.

TypeScript and Python are not enemies

It is tempting to frame this as TypeScript versus Python.

That is the wrong framing.

Python and TypeScript are solving different problems in the AI era.

Python is still the default for building models and experimenting with AI techniques.

TypeScript is becoming the default for turning model capabilities into products.

Many serious teams will use both.

The best architecture is often hybrid.

Use Python where the AI ecosystem is strongest. Use TypeScript where product engineering is strongest. Keep the boundary clean.

The browser AI wave favors TypeScript

Another reason TypeScript matters is that some AI is moving closer to the user.

WebGPU, WebAssembly, ONNX Runtime Web, Transformers.js, WebLLM, and emerging browser AI APIs are making it more realistic to run smaller models or AI features locally in the browser.

That does not mean every app will run a large model on device. It means some AI features can happen without a round trip to a cloud model.

Examples include:

• Local embeddings

• Small text classifiers

• Offline summarization

• Privacy sensitive processing

• Image preprocessing

• On device autocomplete

• Hybrid cloud and local workflows

When AI runs in the browser, TypeScript becomes even more central.

This is not replacing cloud AI.

It is expanding the AI runtime surface. Some logic stays in the cloud. Some moves to the edge. Some moves into the browser. TypeScript is one of the few languages that can sit naturally across all of those places.

Why runtimes matter

The old JavaScript world was mostly browser plus Node.js.

The new TypeScript world has more runtime options:

Deno says it can run JavaScript and TypeScript with no additional tools or configuration. Bun describes itself as an all in one toolkit for JavaScript and TypeScript apps. Edge platforms often support TypeScript based workflows because the web platform is already the common denominator.

This gives AI product teams flexibility.

A small team can start with a Next.js app. They can add an AI SDK route. They can stream responses. They can move some routes to the edge. They can add background jobs. They can later split out Python services if needed.

TypeScript does not force the whole system into one runtime.

It gives teams a shared language across many runtimes.

The hidden reason TypeScript works so well with AI tools

AI coding assistants are better when the codebase gives them structure.

Types are structure.

A TypeScript codebase gives an AI coding tool more hints than a loosely structured JavaScript codebase. Function signatures, interfaces, discriminated unions, schema definitions, and generated API types all give the assistant a clearer target.

That does not mean AI generated TypeScript is always correct.

It is not.

But typed code makes mistakes easier to catch.

If an AI assistant invents a property that does not exist, the compiler can flag it. If it passes the wrong object shape to a function, TypeScript can complain. If it forgets a union case, strict checking can help expose it.

This is one reason typed languages are gaining more attention in the agentic coding era.

AI tools can generate code quickly. Type systems help teams reject some bad code quickly.

That combination is powerful.

Where TypeScript is weak

A good argument should include the limits.

TypeScript is not the answer to every AI problem.

It has real weaknesses.

First, TypeScript types disappear at runtime. The compiler checks your code before it runs, but external data still needs runtime validation. This is why tools like Zod matter.

Second, the AI research ecosystem is still much stronger in Python. If you need custom model training, deep learning research, or heavy numerical work, TypeScript is not the natural choice.

Third, JavaScript package supply chain risk is real. npm is huge, fast moving, and sometimes messy. AI app teams should be careful with dependencies, lockfiles, package provenance, and CI permissions.

Fourth, full stack TypeScript can become too clever. Teams sometimes over abstract simple systems with complex types, generated clients, and framework specific patterns. TypeScript should make the system clearer, not more theatrical.

Fifth, serverless TypeScript can hide infrastructure problems. Cold starts, memory limits, long running jobs, queue behavior, and streaming timeouts still matter.

TypeScript is a strong product language.

It is not magic.

A practical TypeScript architecture for AI apps

A solid TypeScript AI app usually has clear layers.

The key is separation.

Do not let model calls spread everywhere. Put them behind a model gateway. Do not let tools run without schemas. Put tool execution behind a runtime. Do not let the UI guess what is happening. Give it typed states.

A clean project might look like this:

src/
  app/
    chat/
      page.tsx
    api/
      chat/
        route.ts
  ai/
    models.ts
    prompts.ts
    gateway.ts
    streaming.ts
  tools/
    index.ts
    github.ts
    database.ts
    approval.ts
  schemas/
    messages.ts
    tool-inputs.ts
    model-outputs.ts
  server/
    auth.ts
    rate-limit.ts
    logging.ts
  db/
    schema.ts
    queries.ts
  evals/
    ticket-classification.eval.ts
    tool-safety.eval.ts

The exact folders do not matter.

The boundaries do.

Patterns that work well

Here are patterns that make TypeScript AI apps easier to maintain.

Keep prompts close to types

A prompt should not be a mysterious string in the middle of a route handler.

If a prompt asks for a specific output, keep the schema nearby.

const SummarySchema = z.object({
  title: z.string(),
  bullets: z.array(z.string()).min(3).max(7),
  confidence: z.number().min(0).max(1)
})

The prompt and schema should evolve together.

Treat model output as unknown

This is one of the most important rules.

function parseModelOutput(output: unknown) {
  return SummarySchema.parse(output)
}

Do not trust model output because it looks like JSON.

Parse it.

Use discriminated unions for workflow state

AI workflows have many states. Make them explicit.

type RunState =
  | { status: "queued"; runId: string }
  | { status: "running"; runId: string; currentStep: string }
  | { status: "waiting_for_approval"; runId: string; approvalId: string }
  | { status: "completed"; runId: string; resultId: string }
  | { status: "failed"; runId: string; error: string }

This helps both the UI and the backend.

Separate read tools from write tools

A read tool and a write tool should not feel the same.

type ToolRisk = "read" | "low_write" | "high_write"

Then enforce different controls.

Read tools may only need logging. High risk write tools may need approval.

Build a provider neutral model layer

Do not scatter provider calls everywhere.

type GenerateTextInput = {
  purpose: "chat" | "summary" | "classification"
  messages: Array<{ role: "system" | "user" | "assistant"; content: string }>
  temperature?: number
}

A model gateway lets you switch providers, add fallbacks, and track cost more easily.

Log the boring details

For every model call, log:

• Model name

• Provider

• Purpose

• Latency

• Token usage

• User or service ID

• Tool calls requested

• Tool calls approved

• Error type

This data becomes priceless when something breaks.

Patterns that usually age badly

Some patterns feel fast at first and painful later.

The fix is not heavy enterprise architecture.

The fix is simple structure from the start.

What this means for developers

For frontend developers, this is an opportunity.

The AI app era needs people who understand interfaces, state, user flows, latency, accessibility, and product quality. That is frontend work, but with new primitives.

For backend developers, TypeScript is becoming harder to ignore.

AI product backends often live near the web layer. They stream responses, manage tools, handle auth, and coordinate providers. TypeScript is a practical fit for that work.

For Python developers, this is not a threat.

It is a collaboration point. The model and data layer may stay in Python. The product and orchestration layer may move through TypeScript. The clean boundary between them is where good systems are built.

For teams, the message is simple.

Do not choose TypeScript because it is fashionable. Choose it when your AI work is mostly product engineering: UI, tools, agents, APIs, workflows, and structured model output.

That is where TypeScript shines.

The future is typed, streamed, and full stack

The first wave of AI apps was about calling a model.

The next wave is about building systems around models.

Those systems need interfaces. They need schemas. They need tool contracts. They need human approval flows. They need streaming UX. They need observability. They need deployment paths that small teams can manage.

TypeScript is popular in the AI app era because it gives developers a practical way to build all of that in one ecosystem.

It is not replacing Python.

It is not replacing model research.

It is becoming the language many teams reach for when they want to turn AI into a real product.

That is the important shift.

The AI era did not just create a need for better models. It created a need for better product infrastructure around models.

TypeScript happened to be standing exactly where that infrastructure needed to be built.

References

• GitHub Octoverse 2025: https://octoverse.github.com/

• GitHub blog on Octoverse 2025 and TypeScript: https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/

• Stack Overflow Developer Survey 2025 AI section: https://survey.stackoverflow.co/2025/ai

• Stack Overflow Developer Survey 2025 technology section: https://survey.stackoverflow.co/2025/technology

• State of JavaScript 2024 usage data: https://2024.stateofjs.com/en-US/usage/

• Vercel AI SDK documentation: https://ai-sdk.dev/docs/introduction

• Vercel AI SDK repository: https://github.com/vercel/ai

• OpenAI TypeScript and JavaScript SDK docs: https://developers.openai.com/api/reference/typescript/

• OpenAI SDKs and libraries: https://developers.openai.com/api/docs/libraries

• OpenAI Structured Outputs guide: https://developers.openai.com/api/docs/guides/structured-outputs

• Anthropic TypeScript SDK docs: https://platform.claude.com/docs/en/api/client-sdks

• Anthropic TypeScript SDK repository: https://github.com/anthropics/anthropic-sdk-typescript

• LangChain.js agents documentation: https://docs.langchain.com/oss/javascript/langchain/agents

• LangChain.js reference: https://reference.langchain.com/javascript/langchain

• OpenAI Agents SDK for TypeScript: https://openai.github.io/openai-agents-js/

• Zod documentation: https://zod.dev/

• TypeScript 5.9 announcement: https://devblogs.microsoft.com/typescript/announcing-typescript-5-9/

• Bun TypeScript runtime docs: https://bun.com/docs/runtime/typescript

• Deno runtime docs: https://docs.deno.com/runtime/

• TypeScript logo on Wikimedia Commons: https://commons.wikimedia.org/wiki/File:Typescript_logo_2020.svg

• Cover image from Unsplash: https://unsplash.com/s/photos/laptop-code

That used to be a useful mental model. You wrote code, tested it, scanned it, shipped it, and patched it when a vulnerability appeared. The boundary was clear enough. Your repository was your responsibility. Everything outside it was a dependency, a vendor, or an infrastructure problem.

That model is breaking.

Modern software is not written from scratch. It is assembled. A small web app can pull hundreds or thousands of transitive packages. A backend service can depend on base images, GitHub Actions, build scripts, cloud roles, code generators, secrets, registries, container layers, Terraform modules, model APIs, and now AI-generated code.

The supply chain is no longer a line from developer to production. It is a graph.

AI makes that graph bigger. It helps developers write code faster, but it also changes where code comes from, who reviews it, how dependencies are chosen, and how quickly risky changes move through the pipeline. AI agents can open pull requests, add packages, write workflows, call tools, and sometimes touch production systems. That is powerful. It is also dangerous when the pipeline was built for a slower world.

This article is a detailed look at the new software supply chain problem. It is written for developers, platform engineers, security engineers, and technical founders who want to understand what changed and what to do about it.

What changed

A few years ago, supply chain security felt like a topic for large companies, government vendors, and security teams. Then SolarWinds, Log4Shell, dependency confusion, package hijacking, CI leaks, and registry attacks made the lesson obvious.

You can write secure code and still ship compromised software.

That is the core idea. The attacker does not need to find a bug in your application if they can change what your application is built from.

A modern release is made from many parts:

• Your source code

• Open source dependencies

• Transitive dependencies

• Package manager behavior

• Lockfiles

• Build scripts

• CI/CD workflows

• Secrets and tokens

• Container base images

• Infrastructure modules

• Artifact registries

• Deployment permissions

• Generated code

• AI-written changes

• Third-party actions and plugins

Every one of these can become the weak point.

The OWASP Top 10 for Large Language Model Applications lists supply chain vulnerabilities as a core LLM risk. OWASP also calls out prompt injection, insecure output handling, sensitive information disclosure, and insecure plugin design. Those are not separate from software supply chain security. They are becoming part of it.

Here is the simple version.

Before AI, the main question was:

Can I trust this package, build, artifact, and deployment pipeline?

Now we also have to ask:

Can I trust how this code was suggested, generated, reviewed, approved, and connected to tools?

That extra layer matters.

GitHub's 2025 Octoverse report says AI, agents, and typed languages are driving one of the biggest shifts in software development in more than a decade. That is not just a productivity story. It is a security story too. More code is being created faster, with more automation around it, and with more tools acting on behalf of developers.

Speed is useful. Blind speed is not.

The old model

The old model looked roughly like this.

It was never truly this simple, but many teams still reason this way.

The problem is that the real model now looks closer to this.

There are more paths into the release. There are more identities. There are more machines making changes.

The attack surface has moved from "the code" to "the system that creates the code."

Why attackers like the supply chain

Supply chain attacks scale.

If an attacker compromises one small application, they get one target. If they compromise a package, a build action, a maintainer token, or a popular library, they get every downstream project that trusts it.

That is the appeal.

A single compromised package can reach:

• Developer laptops

• CI runners

• Internal repositories

• Cloud credentials

• Production deployment systems

• Customer applications

• Other packages maintained by the same account

This is why package ecosystems are so attractive. The trust is already there. Developers install packages quickly. CI systems pull dependencies automatically. Build scripts run with high access. Many teams still use long-lived tokens.

The attacker does not need to knock on the front door. They can become part of the build.

Where attacks happen now

Supply chain security is easier to understand when you separate the attack paths. Most incidents are not magic. They follow patterns.

The modern software supply chain has several weak spots.

Package maintainers

Open source maintainers hold a lot of power. Many popular packages are maintained by one person, a small team, or a tired group of volunteers.

If an attacker gets a maintainer account, they may be able to publish a malicious version of a package. That version can then flow into real applications.

Common paths include:

• Phishing maintainers

• Stealing npm, PyPI, or GitHub tokens

• Taking over abandoned packages

• Social engineering a maintainer

• Getting added as a co-maintainer

• Compromising a maintainer's laptop

• Publishing a lookalike package

This is not theoretical.

In 2025, the Shai-Hulud npm campaign showed how bad this can get. Unit 42 described it as a self-replicating worm that compromised npm packages and targeted developer credentials. The campaign looked for secrets such as npm tokens, GitHub personal access tokens, and cloud keys, then used stolen npm tokens to modify other packages maintained by the same developer. Unit 42 also assessed with moderate confidence that an LLM helped generate part of the malicious script, based on comments and emojis in the code.

That detail matters.

It means attackers are not just attacking AI systems. They may be using AI to scale attacks against traditional package ecosystems.

The Cyber Security Agency of Singapore also warned that Shai-Hulud used a self-propagating payload. Their advisory said the campaign began with the compromise of @ctrl/tinycolor and that researchers had identified more than 180 compromised npm packages during the attack window.

Package install scripts

Package install scripts are one of the scariest parts of the ecosystem.

In npm, packages can run lifecycle scripts during install. These scripts are useful for legitimate build steps. They are also useful for attackers because they execute when a developer or CI system installs dependencies.

That changes the risk.

A malicious package does not always need to be imported by your application. It may only need to be installed.

Here is the basic flow.

This is why CI dependency installation is a high risk moment.

A build runner often has access to:

• GitHub tokens

• Cloud deployment credentials

• npm or PyPI publish tokens

• Docker registry credentials

• Private package registry tokens

• Signing keys

• Environment variables

• Internal network access

If a dependency install script can read those, the build server becomes a treasure chest.

CI/CD workflows

CI/CD is where trust becomes action.

Your CI pipeline can test code, build containers, publish packages, deploy infrastructure, rotate versions, sign artifacts, and push to production. That means a compromised CI workflow can do real damage.

Common CI/CD risks include:

• Overpowered default tokens

• Long-lived cloud secrets

• Pull request workflows that expose secrets

• Unpinned third-party actions

• Actions pinned only by tag instead of commit SHA

• Workflow injection through user-controlled input

• Build scripts that run untrusted code

• Self-hosted runners with broad network access

• Missing separation between build and deploy jobs

GitHub's own Actions security docs tell teams to use least privilege for credentials. Their OIDC docs also explain that GitHub Actions workflows can use OIDC tokens instead of stored long-lived cloud secrets.

That is a major improvement.

A long-lived cloud key in CI is a standing target. An OIDC token is short-lived and tied to a workflow identity. It is not a silver bullet, but it reduces the blast radius when something leaks.

Dependency confusion and typosquatting

Dependency confusion happens when internal package names overlap with public package names. If your package manager resolves the public version first, an attacker can publish a package with the same name and wait for your build to download it.

Typosquatting is simpler. The attacker publishes a package with a name that looks like a real one.

Examples of the pattern:

Package managers have improved. Teams have also learned. But these attacks still work because developers move fast and package names are easy to misread.

AI can make this worse.

When a coding assistant suggests a package name that looks plausible, a developer may trust it. The package might be real. It might be abandoned. It might be malicious. It might not exist, which creates another problem: attackers can publish the suggested package later and wait for people to install it.

That is not science fiction. It is a natural side effect of generated code meeting public registries.

Container images

Dependencies are not only application packages.

A container image includes:

• Operating system packages

• Language runtimes

• Shell tools

• System libraries

• Certificates

• Package manager caches

• Build layers

• Application artifacts

If your base image is stale or untrusted, your application inherits that risk.

The same is true for container build steps. A Dockerfile can download scripts from the internet, install packages without pinning versions, and copy secrets into layers by mistake.

A bad image can pass code review because the risky part is not in application code. It is in the build environment.

Infrastructure as code

Terraform modules, Helm charts, Kubernetes manifests, and GitOps configs are part of the supply chain.

An attacker who changes infrastructure code may be able to:

• Open a storage bucket

• Add a public ingress

• Create an admin role

• Disable logging

• Expose a secret

• Change an image tag

• Route traffic to a malicious endpoint

• Add a privileged sidecar

AI agents can now edit infrastructure code too. That makes review even more important.

A generated Terraform change can look clean while quietly widening permissions. A generated Kubernetes manifest can work in staging while adding a risky security context. A generated GitHub Actions workflow can pass tests while exposing secrets to a pull request.

The risk is not that AI is evil.

The risk is that AI is confident, fast, and often unaware of your security boundaries.

The AI layer changes risk

AI-generated code is not automatically bad. Most of the time, it is just code.

That is exactly why it needs the same checks as human code.

The problem is not that AI writes insecure code every time. The problem is that AI changes the economics of code creation. It lowers the cost of generating code, glue, scripts, tests, configs, and workflows. That means more changes enter the system.

More changes need better gates.

AI creates code without provenance

Open source has a visible history. You can inspect commits, authors, reviews, releases, tags, issues, and maintainers.

AI-generated code is different.

The model gives you an answer. You may not know which examples influenced it. You may not know whether the pattern came from old code, vulnerable code, deprecated docs, or a Stack Overflow answer from ten years ago. You may not know whether the license risk is clean.

That does not mean you should never use AI-generated code. It means you should not treat generated code as magically original or safe.

A useful rule:

AI-generated code should be treated like a pull request from a fast junior developer who had access to the entire internet but no context about your production risk.

That sounds harsh. It is also fair.

The code might be good. It still needs review.

AI chooses dependencies

A lot of supply chain risk enters through dependency choice.

When an AI assistant suggests a package, it may optimize for convenience. It may not check:

• Maintenance activity

• Known vulnerabilities

• Package ownership

• Download source

• License

• Typosquatting risk

• Whether the package exists

• Whether the package is still recommended

• Whether the package runs install scripts

• Whether a built-in API would be enough

That is a real problem.

A human developer might ask for "a package to parse JWTs" or "a library for PDF extraction." The assistant may produce a working answer with a dependency. If the developer copies it, the supply chain changed.

One dependency can pull many more.

The package suggestion is not a small detail. It is a design decision.

AI writes build and deployment scripts

Build scripts are dangerous because they run in privileged places.

A coding agent may create:

• GitHub Actions workflows

• Dockerfiles

• Bash scripts

• Terraform plans

• Helm charts

• Release scripts

• Package publishing scripts

• Database migration scripts

These files often receive less careful review than application code. That is backwards.

A one-line workflow change can expose secrets. A Dockerfile can leak credentials into layers. A Terraform policy can grant broad access. A release script can publish the wrong artifact.

AI-generated infrastructure code deserves extra review, not less.

AI agents can take actions

The next step is not AI autocomplete. It is agents.

Agents can plan, call tools, read files, edit code, run commands, create pull requests, and sometimes deploy. That connects AI behavior to real systems.

OWASP's LLM risk list includes insecure plugin design and excessive agency. These risks fit agentic development tools very well. If a model can act through tools, the tool boundary becomes part of your supply chain.

The risk looks like this.

A prompt injection in an issue or README can influence the agent. If the agent has write access and poor tool limits, that influence can become a real change.

This is why AI supply chain security is not only about scanning generated code. It is about controlling what agents can do.

AI helps attackers too

Defenders use AI. Attackers use it as well.

AI can help attackers:

• Generate phishing emails for maintainers

• Write package descriptions

• Create convincing fake documentation

• Generate malware variants

• Analyze public repositories for secrets

• Find weak CI workflows

• Create typo packages at scale

• Translate attacks across ecosystems

• Write exploit glue faster

The Unit 42 Shai-Hulud analysis is a useful signal because it links a large npm supply chain campaign with suspected LLM assistance in the malicious script. The important point is not whether the whole attack was AI-driven. The point is that AI reduces the cost of attacker work.

That changes the defender's job.

Manual review alone cannot keep up with automated attack paths. You need automated guardrails too.

What a hardened pipeline looks like

A secure supply chain is not one tool. It is a set of controls that reinforce each other.

The goal is not to make attacks impossible. That is not realistic. The goal is to make risky changes visible, hard to land, hard to exploit, and easy to roll back.

A hardened pipeline answers five questions:

1. What code changed?

2. Who or what changed it?

3. What dependencies entered the build?

4. What artifact was produced?

5. Can we prove that production is running the artifact we reviewed?

Here is the shape.

Dependency control

The first layer is dependency control.

You should know when dependencies change. You should know why they changed. You should know whether the change adds risky behavior.

Practical controls:

• Use lockfiles.

• Review dependency diffs in pull requests.

• Block known malicious packages.

• Use private registries or proxy registries for internal packages.

• Prefer direct dependencies with healthy maintenance.

• Remove unused dependencies.

• Avoid packages that run install scripts unless you need them.

• Pin versions for application dependencies.

• Pin GitHub Actions to commit SHAs for high risk workflows.

• Use package manager settings that reduce script execution in CI where possible.

A dependency review should not only ask "does it have a CVE?"

It should ask:

• Who maintains it?

• How often is it updated?

• Does it have many transitive dependencies?

• Does it execute install scripts?

• Does it request network access during install?

• Is it replacing a small function we could write ourselves?

• Is it a package suggested by AI without verification?

• Is the license acceptable?

• Is this package allowed in our organization?

Some teams create an "approved dependency path." That does not mean every package needs a week-long security review. It means the pipeline treats new packages differently from routine code changes.

That is smart.

Secret control

Secrets are the fuel of supply chain attacks.

A compromised package is bad. A compromised package with access to CI secrets is much worse.

Start with the obvious:

• Do not commit secrets.

• Scan repositories for secrets.

• Scan pull requests for secrets.

• Rotate secrets quickly when exposed.

• Remove long-lived credentials from CI where possible.

• Use OIDC for cloud access from CI.

• Scope tokens to the minimum required permissions.

• Separate build credentials from deploy credentials.

• Do not expose production secrets to pull request workflows.

• Keep self-hosted runners isolated.

GitHub's docs recommend least privilege for workflow secrets. Their OIDC documentation explains how Actions can authenticate to cloud providers without storing long-lived secrets in GitHub.

This is one of the best upgrades a team can make.

A short-lived token tied to a workflow is not perfect, but it is much safer than a cloud key that sits in a secret store for years.

Build isolation

A build should be clean, repeatable, and isolated.

That means:

• Build on controlled infrastructure.

• Avoid building release artifacts on developer laptops.

• Keep build runners patched.

• Use ephemeral runners for sensitive builds.

• Limit network access where possible.

• Keep deploy credentials out of build jobs.

• Separate test jobs from release jobs.

• Do not let untrusted pull requests access secrets.

• Do not reuse dirty workspaces for release builds.

The build environment is part of the artifact. If the build runner is compromised, the output can be compromised even when the source code is clean.

This is where SLSA becomes useful.

SLSA, short for Supply-chain Levels for Software Artifacts, is a framework from OpenSSF. The SLSA site describes it as a checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure.

That framing is helpful because SLSA is not a single product. It is a maturity path.

At a high level:

You do not need to reach the highest maturity level on day one. Even basic provenance is useful because it gives incident responders a way to answer hard questions.

Where did this artifact come from? Which commit produced it? Which workflow built it? Which builder ran it? Was it signed? Was it altered after the build?

Without provenance, you are guessing.

SBOMs

A Software Bill of Materials, or SBOM, is an inventory of software components.

Think of it as an ingredient list for software. It does not make the software safe by itself. It tells you what is inside, so you can respond when something inside becomes risky.

CISA published updated draft guidance for SBOM minimum elements in 2025. CISA describes SBOMs as a software transparency tool that helps manage software risk more effectively.

A useful SBOM should answer:

• What components are included?

• What versions are included?

• Which packages are direct dependencies?

• Which are transitive dependencies?

• What licenses apply?

• What package manager or ecosystem do they come from?

• What hashes identify the components?

• Which tool generated the SBOM?

• When was it generated?

• Which artifact does it describe?

SBOMs are most useful when they are generated during the build and attached to the artifact. A manually created SBOM gets stale fast.

SBOMs also need monitoring.

If a new vulnerability appears in a dependency, you should be able to ask:

Which services include this component?

That is the operational value.

Signing and verification

Signing turns trust into something machines can check.

Sigstore is one of the most important projects in this space. The Sigstore project describes itself as a collection of open source tools that improve software supply chain security. Cosign, one of its tools, supports signing container images and other artifacts, including keyless signing.

The idea is simple.

Build an artifact. Sign it. Store the signature. Verify the signature before deployment.

This gives you a strong rule:

Production should run only artifacts that were built by approved systems, from approved repositories, under approved workflows.

That is much better than trusting anyone who can push an image tag.

Tags are mutable. Signatures and provenance give you better proof.

CI/CD hardening

CI/CD deserves its own checklist because it is often the highest value target.

For GitHub Actions, strong defaults include:

permissions:
  contents: read

Then grant more permissions only where needed.

For cloud deployment, prefer OIDC instead of stored keys. For third-party actions, pin sensitive workflows to commit SHAs. For pull requests from forks, never expose secrets. For self-hosted runners, treat public pull request execution as risky.

A safer GitHub Actions pattern looks like this.

name: build

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Install dependencies without running scripts
        run: npm ci --ignore-scripts

      - name: Run tests
        run: npm test

For release workflows, use separate permissions.

name: release

on:
  push:
    tags:
      - "v*"

permissions:
  contents: read
  id-token: write
  packages: write

jobs:
  release:
    runs-on: ubuntu-latest
    environment: production

    steps:
      - uses: actions/checkout@v4

      - name: Build
        run: npm ci --ignore-scripts && npm run build

      - name: Authenticate with cloud using OIDC
        run: echo "Use cloud provider login action here"

      - name: Publish signed artifact
        run: echo "Build, sign, and publish"

This is not a complete workflow. It shows the shape.

The build job does not need deployment power. The release job gets only what it needs. Production requires an environment boundary. OIDC replaces static cloud keys.

AI guardrails

AI-generated changes need guardrails that match how AI works.

A practical policy might say:

• AI can draft code, but a human must own the change.

• AI can suggest dependencies, but dependency additions require review.

• AI cannot modify release workflows without CODEOWNERS approval.

• AI cannot create or rotate production secrets.

• AI cannot deploy to production directly.

• AI-generated infrastructure changes require plan review.

• Agent tool access must be scoped by task.

• Agent actions must be logged.

• Prompt context from external systems must be treated as untrusted.

This is not anti-AI. It is normal engineering.

You would not give a new contractor unrestricted production access on their first day. You should not give an agent that access either.

Policy as code

Manual review is not enough.

Use policy as code to stop common mistakes before merge. Tools vary by stack, but the idea is the same.

Examples of policies:

• Block public S3 buckets unless explicitly approved.

• Block Kubernetes privileged containers.

• Require pinned base images.

• Require signed container images.

• Require SBOMs for production artifacts.

• Require CODEOWNERS review for workflow changes.

• Block new dependencies with known critical vulnerabilities.

• Block deploy jobs without OIDC.

• Block containers running as root.

• Block Terraform changes that grant wildcard admin access.

The value is consistency.

A tired reviewer can miss a risky permission. A policy check should not.

A practical roadmap

The hard part about supply chain security is not knowing what good looks like. The hard part is making progress without stopping engineering work.

You do not need to do everything at once.

Here is a roadmap that works for small teams and can grow with larger ones.

Phase one: know what you ship

Start with visibility.

If you do not know what you ship, you cannot secure it.

Do this first:

• Turn on dependency alerts.

• Generate SBOMs for release artifacts.

• Store SBOMs with builds.

• Track direct and transitive dependencies.

• Identify production repositories.

• Identify who can publish packages.

• Identify who can deploy.

• Inventory CI secrets.

• Inventory third-party GitHub Actions.

• Find self-hosted runners.

• Map which services use which base images.

This phase is not glamorous. It is useful.

The output should be a basic map.

Do not skip this.

Most supply chain incidents become worse because teams do not know where the affected package is used, which token leaked, or which build produced the artifact.

Phase two: reduce easy risk

Next, remove obvious dangerous defaults.

Focus on the things attackers love:

• Long-lived cloud keys in CI

• Broad GitHub tokens

• Unpinned deployment workflows

• Secrets exposed to pull requests

• Unreviewed workflow changes

• Overly broad package publish rights

• Unused dependencies

• Old base images

• Install scripts running in CI without need

Quick wins:

You will not fix everything. That is fine.

Fix the paths that lead to production first.

Phase three: protect the build

After visibility and quick wins, focus on build integrity.

A strong build process should be:

• Automated

• Isolated

• Repeatable

• Provenanced

• Signed

• Verifiable

That means release artifacts should come from CI, not laptops. The build should generate provenance and an SBOM. The artifact should be signed. Deployment should verify policy before running it.

A healthy release chain looks like this.

The key idea is traceability.

If someone asks, "Why is this running in production?" you should have a better answer than "because the tag says latest."

Phase four: govern AI-generated code

AI governance should be boring.

That is good.

Start with a written policy that developers can actually follow.

A practical policy might be:

1. AI-generated code is allowed.

2. The human who submits the pull request owns the code.

3. New dependencies suggested by AI require dependency review.

4. Security-sensitive files require CODEOWNERS review.

5. AI tools cannot receive secrets.

6. AI agents cannot deploy without explicit approval.

7. Generated code must pass the same tests and scans as human code.

8. Agent actions must be logged when they touch repositories or tools.

Then make the pipeline enforce parts of it.

Add CODEOWNERS for:

• .github/workflows/*

• Dockerfile

• docker-compose.yml

• terraform/**

• helm/**

• k8s/**

• package.json

• package-lock.json

• pyproject.toml

• requirements.txt

• go.mod

• Cargo.toml

This does not block AI. It puts review where risk enters.

Phase five: prepare for incidents

You will still have incidents.

The question is how fast you can respond.

For supply chain incidents, every team should know how to:

• Find where a package is used.

• Remove or pin a package version.

• Rebuild affected artifacts.

• Rotate leaked tokens.

• Disable compromised workflows.

• Revoke package publish tokens.

• Audit recent releases.

• Search logs for suspicious CI behavior.

• Check which artifacts reached production.

• Notify customers if required.

Write the playbook before you need it.

A simple incident flow:

The teams that handle supply chain incidents well are not always the teams with the most tools. They are the teams with the clearest ownership and the fastest path from alert to rebuild.

What this means for developers

This whole topic can sound like a security team problem.

It is not.

Developers make supply chain decisions every day.

You make one when you install a package. You make one when you copy a GitHub Actions snippet. You make one when you accept an AI-generated dependency. You make one when you add a Docker base image. You make one when you approve a pull request that changes a workflow.

That does not mean every developer must become a security engineer.

It means every developer should learn a few instincts:

• Fewer dependencies are easier to defend.

• Lockfiles matter.

• Build scripts deserve review.

• CI secrets are production risk.

• AI-generated code still needs ownership.

• Package install is code execution.

• A signed artifact is better than a trusted tag.

• SBOMs help you answer questions during an incident.

• Provenance tells you where software came from.

• Fast code without traceability becomes expensive later.

The future of software supply chain security is not one big scanner. It is a culture where code, dependencies, builds, artifacts, and AI agents are all treated as part of the same system.

That is the shift.

AI did not create the software supply chain problem. Open source scale, automation, and cloud delivery already did that.

AI made the problem faster.

So the answer is not to stop using AI. The answer is to build pipelines that can handle speed without losing trust.

The best teams will use AI to write faster, test faster, review better, and detect risk earlier. They will also put hard boundaries around credentials, builds, artifacts, and production changes.

That is where professional software engineering is going.

Not less process. Better process.

Not less trust. Verifiable trust.

Practical checklist

Use this as a starting point for your own project.

The point is not perfection.

The point is reducing blind trust.

References

• OWASP Top 10 for Large Language Model Applications

• GitHub Octoverse 2025

• Unit 42 analysis of the Shai-Hulud npm campaign

• Cyber Security Agency of Singapore advisory on Shai-Hulud

• Red Hat summary of multiple npm supply chain attacks

• SLSA framework

• Sigstore

• Cosign signing overview

• OpenSSF Scorecard

• GitHub Actions secure use reference

• GitHub Actions OIDC documentation

• CISA SBOM page

• CISA 2025 minimum elements for SBOM

That model is not going away. Large frontier models still need serious compute. But another path is getting more practical: run smaller AI models directly on the user's device, inside the browser.

This is local first AI. It is not a replacement for every cloud AI feature. It is a different design choice. It can be faster, cheaper, more private, and better offline when the task is small enough to fit on the client.

The timing matters. WebGPU gives browsers access to modern GPU compute. WebAssembly keeps CPU fallback fast and portable. ONNX Runtime Web, Transformers.js, WebLLM, WebNN, and Chrome's built in AI APIs are making browser AI feel less like a demo and more like a real app architecture.

Why local first AI is back

The first wave of AI apps was cloud first for a good reason. Big models were too large for normal devices, browser APIs were not ready, and JavaScript ML tooling felt limited.

That is changing.

Modern browsers now have better access to device hardware. MDN describes WebGPU as a browser API for high performance graphics and general purpose GPU computation. The same GPU path that helps render complex visuals can also help run machine learning workloads.

Frameworks are catching up too. WebLLM runs large language models in the browser with WebGPU acceleration. Transformers.js lets developers run transformer models directly in the browser with no server. ONNX Runtime Web lets web apps run machine learning models through JavaScript APIs.

This is the shift:

The new question is not, "Can the browser run AI?" It can.

The better question is, "Which AI tasks should run locally, and which still belong in the cloud?"

What runs inside the browser

Local AI does not mean the same thing in every app. A browser can run AI in several ways, depending on the task and the user's device.

The most practical browser AI tasks today are not giant reasoning agents. They are smaller, focused features:

• Summarizing a short document

• Classifying text

• Detecting sentiment

• Translating simple content

• Running semantic search over local notes

• Extracting labels from images

• Helping users rewrite text

• Creating embeddings for private data

Chrome's Prompt API lets developers send natural language requests to Gemini Nano in the browser. Chrome's broader built in AI docs also describe APIs for tasks like summarizing, writing, rewriting, and translation.

The W3C is moving in the same direction. The Web Neural Network API defines a hardware neutral abstraction for machine learning in browsers. The W3C Web Machine Learning Working Group says its mission is to develop APIs for efficient ML inference in the browser.

That is important. Local AI will not be one library. It will be a stack.

Why developers should care

The obvious benefit is privacy.

If a user asks your app to summarize private notes, classify local files, or search personal data, sending everything to a server may feel wrong. Local AI lets you keep sensitive data on the device for the right tasks.

But privacy is only one part of the story.

Local AI also changes cost. Cloud inference can get expensive when every small action becomes an API call. A rewrite button, a smart search box, or a local classifier might be used hundreds of times per session. Moving small tasks to the client can reduce backend load.

It also improves latency. A local model can respond without a round trip to a server. That matters for UI features where the user expects instant feedback.

The best design is often hybrid.

Use local AI for fast, private, repeated tasks. Use cloud AI for complex reasoning, huge context windows, heavy generation, or tasks that need the best available model.

The point is not to pick one side forever. The point is to route each task to the right place.

The stack is getting real

A few years ago, browser AI felt like a science project. Now the pieces are easier to name.

WebGPU gives web apps a modern compute path. ONNX Runtime's WebGPU documentation describes WebGPU as a browser standard for general purpose GPU compute and graphics, designed around modern APIs like D3D12, Vulkan, and Metal.

WebAssembly still matters because not every device has a strong GPU path. It gives browser AI a portable CPU fallback. ONNX Runtime Web supports WebAssembly, WebGPU, WebGL, and WebNN backends, depending on the use case.

Transformers.js gives JavaScript developers a familiar way to run models from the Hugging Face ecosystem. Hugging Face announced Transformers.js v4 in February 2026 with a rewritten WebGPU runtime and broader model support.

WebLLM focuses on in browser LLM inference. Its docs describe it as a high performance engine for running LLMs in browsers with WebGPU acceleration.

WebNN points toward a future where browser ML can target GPUs, CPUs, and dedicated AI hardware without every developer writing device specific code.

This is why the browser is becoming an AI runtime.

Not because it can run the biggest model. Because it can run useful models close to the user.

What can go wrong

Local AI has real limits.

First, model size matters. Users do not want to download a huge model just to try a web app. Chrome's built in AI docs tell developers to inform users when a model is downloading and when it is ready. That detail sounds small, but it affects trust.

Second, devices vary. A powerful laptop with a good GPU is not the same as an older phone. Your app needs fallback paths.

Third, browser support is still uneven. WebGPU is more mature than before, but you still need feature detection and graceful fallback. WebNN is still an emerging standard, even though the direction is clear.

Fourth, local models are smaller. They may be good enough for summarization, classification, embeddings, and rewriting. They may not be good enough for deep research, legal review, medical decisions, or high stakes reasoning.

A good local AI feature should be honest.

The safest pattern is simple.

• Detect device support.

• Keep local tasks narrow.

• Show model download state.

• Let users choose cloud fallback.

• Avoid pretending a small local model is smarter than it is.

Local first AI should feel calm, not magical.

Where this is heading

The web keeps absorbing things that used to require native apps.

First it took documents. Then chat. Then video editing, design tools, IDEs, games, and real time collaboration. AI is next.

The browser will not replace every cloud model. That is not the interesting claim.

The interesting claim is smaller: many everyday AI features do not need to leave the device.

A writing helper can rewrite a sentence locally. A note app can search private notes locally. A browser extension can summarize a page locally. A design tool can classify assets locally. A support tool can detect intent locally before sending only the needed context to a server.

That makes apps feel faster. It lowers costs. It protects user data. It also gives developers a new architectural choice.

Cloud AI gave us powerful models. Local first AI gives us better product boundaries.

The next great AI web app may not be the one that calls the largest model for everything. It may be the one that knows when not to call the cloud at all.

References

• MDN WebGPU API

• Chrome built in AI docs

• Chrome Prompt API

• WebLLM documentation

• Transformers.js documentation

• Transformers.js v4 announcement

• ONNX Runtime Web docs

• ONNX Runtime WebGPU docs

• W3C Web Neural Network API

• W3C Web Machine Learning Working Group Charter

That is where Model Context Protocol, or MCP, becomes interesting.

MCP is an open standard for connecting AI applications to external systems. The official MCP documentation describes it as a way for apps like Claude or ChatGPT to connect to data sources, tools, and workflows through a shared protocol. OpenAI's Agents SDK uses the same simple analogy: MCP is like a USB-C port for AI apps.

That analogy is helpful, but it hides the serious part.

A USB-C port can charge your laptop. It can also connect a device you do not trust. MCP has the same shape. It can make agents more useful, but it also creates a new security boundary where language models can request real actions.

Image credit: Aerps.com on Unsplash

Why MCP exists

Before MCP, every AI app had to build its own integration layer.

If your assistant needed GitHub, Slack, Notion, Postgres, and Google Drive, you wrote custom connectors for each one. Then another AI app had to do the same thing again. The result was a messy grid of integrations.

MCP tries to replace that pattern with a common protocol.

Instead of each app writing its own custom connector, a tool provider can expose an MCP server. Any MCP compatible client can connect to it. That does not remove all integration work, but it changes where the work happens.

Anthropic introduced MCP in 2024 as an open standard for secure two way connections between AI tools and data sources. GitHub also describes MCP as a standard way to connect AI models to different data sources and tools, including GitHub Copilot integrations.

That timing matters.

AI tools are moving from autocomplete to action. They are no longer just writing text. They are reading repositories, creating pull requests, querying data, scheduling meetings, and calling APIs.

MCP is one of the clearest attempts to standardize that shift.

How the architecture works

MCP uses three main roles.

The MCP architecture docs explain that a host creates MCP clients, and each client keeps a dedicated connection to a server. This is important. The host is the product you use. The client is the protocol piece. The server is the bridge to an external system.

MCP servers usually expose three kinds of capabilities.

A resource is usually read focused. A tool can change something. A prompt is a reusable instruction pattern.

That difference matters for safety.

Reading a database schema is not the same as running a migration. Listing GitHub issues is not the same as closing one. A serious MCP setup should treat these capabilities differently.

Here is a simple request flow.

The model does not magically get access to everything. Access depends on the server, the client, the user approval flow, and the permissions granted to that connection.

That is the part teams need to design carefully.

Why security is the real story

MCP makes AI agents more useful by giving them better context and tools. It also gives attackers a bigger surface area.

The MCP specification is direct about this. It says the protocol enables powerful capabilities through arbitrary data access and code execution paths. That is not a small warning.

A normal API client follows code you wrote. An AI agent follows a mix of system instructions, user requests, retrieved content, tool descriptions, and model output. That makes trust harder.

OWASP's LLM Top 10 lists prompt injection as a major LLM application risk. It also warns about insecure output handling, plugin design, supply chain risk, and excessive agency. Those risks map closely to MCP systems because MCP gives models a path to tools.

The tricky part is that prompt injection can come from places that look harmless.

A malicious instruction can hide inside:

• A GitHub issue

• A README file

• A support ticket

• A calendar invite

• A web page

• A database row

• A document shared with the agent

The agent may read that content as context, then treat part of it like an instruction.

This is why MCP security cannot be just an API key problem.

API keys answer one question: is this connection allowed? They do not answer a harder question: should the agent perform this specific action, at this specific time, based on this specific context?

That is the core risk.

MCP turns LLM security from a chat problem into a systems problem.

Image credit: Security keyboard on Wikimedia Commons

A safer production pattern

A safer MCP setup starts with a boring rule: do not give the agent more power than it needs.

That sounds obvious. It is also where many systems fail.

The best pattern is to put a policy layer between the AI host and sensitive MCP servers. That layer should handle approval, logging, rate limits, and tool restrictions.

A production MCP design should separate low risk and high risk actions.

A few rules help a lot.

• Start with read only servers.

• Use short lived credentials where possible.

• Prefer scoped tokens over broad tokens.

• Keep tool descriptions clear and narrow.

• Log every tool call and response status.

• Add human approval for writes.

• Treat retrieved text as untrusted input.

• Do not let one tool silently feed secrets into another tool.

The last point is easy to miss.

The danger is not always one tool. It is tool composition. A file reader plus a network sender can become a data leak. A database query tool plus a ticket updater can expose private data in a public issue.

Good MCP design is mostly about boundaries.

Image credit: PDC server room on Wikimedia Commons

What developers should build next

MCP is not magic. It is plumbing.

Good plumbing matters because it decides what can flow, where it can flow, and what happens when something breaks. That is why MCP is worth learning now.

The useful question is not, "Should every app support MCP?" The better question is, "Where would a standard tool interface remove custom glue without creating too much risk?"

MCP fits well when:

• Your agent needs to read from many systems.

• You want one connector to work across many AI clients.

• You are building internal developer tools.

• You need controlled access to company context.

• You can define clear tool permissions.

MCP is a poor fit when:

• You cannot audit tool calls.

• The agent needs broad write access from day one.

• The data is highly sensitive and poorly classified.

• You have no approval flow for risky actions.

• You are treating the model as a trusted decision maker.

My practical recommendation is simple.

Start with a small internal MCP server. Give it read only access. Connect it to something useful, like documentation, issue search, or service metadata. Watch how people use it. Then add write actions one by one, with approvals and logs.

That path is slower than a demo.

It is also how you avoid turning a useful agent into a confused intern with production credentials.

MCP is probably going to matter because it gives AI apps a shared way to connect to the world. But the winners will not be the teams with the most tools. They will be the teams with the clearest boundaries.

Sources

• MCP introduction

• MCP architecture overview

• MCP specification

• MCP authorization specification

• Anthropic MCP announcement

• OpenAI Agents SDK MCP docs

• GitHub Copilot MCP docs

• OWASP Top 10 for LLM applications

The AI Surge in Coding: A Snapshot of 2025

Artificial intelligence has shifted from hype to a fundamental part of software development. Tools such as GitHub Copilot, Cursor, and Claude 3.7 Sonnet have become everyday essentials for developers. They churn out code snippets, propose fixes, and even sketch full functions. Back in 2023, a Stack Overflow survey showed that 70 percent of developers turned to AI tools at least once a week. By 2025, that figure has almost certainly climbed as these tools grow more refined.

The bigger shift comes from AI agents that do more than just help. Consider Devin, created by Cognition. It grabbed headlines in 2024 for tackling complete coding projects, from finishing freelance jobs on Upwork to patching bugs in massive codebases. The first version of Devin had trouble with intricate work, but the 2025 release of Devin 2.0 brings improvements like crafting project outlines, answering code queries with references, and building documentation sites. Cognition's new pay-as-you-go model makes it easier for more people to try, a sign of their belief in its potential.

Then there is "vibe coding," a phrase that captures a fresh way of working where developers guide AI rather than type every detail. A Forbes piece noted that a quarter of the startups in Y Combinator's 2025 batch have codebases that are at least 85 percent AI-generated. This evolution questions the old image of developers as meticulous artisans and spotlights the skills that will matter going forward.

The market for generative AI coding assistants stood at 25.9 million dollars in 2024. Projections put it at 97.9 million by 2030, with a compound annual growth rate of 24.8 percent. This rapid expansion mirrors the rising intricacy of software projects and the push for faster development cycles.

Navigating the Job Market: Growth Amid Turmoil

In 2025, the coding job scene tells two stories. AI-focused positions are exploding in demand, while conventional programming jobs stir up worries.

The Explosion in AI and Machine Learning Positions

The World Economic Forum predicted in 2024 that global need for AI and machine learning experts would jump 40 percent in the coming years. Data from early 2025 backs that up. A Jobright analysis of 80,000 job openings at U.S. AI startups pinpointed machine learning engineers as the hottest role, with over 2,000 spots available. Senior roles in this field command salaries from 172,880 to 209,640 dollars a year, underscoring the high value placed on these abilities.

At NVIDIA's GTC event in March 2025, speakers stressed the importance of developers who weave AI into their routines. Discussions highlighted how even those without deep technical backgrounds can use AI to code, while seasoned pros are blending in skills from fields like the liberal arts to infuse projects with a human element. This points to a future where blending technical know-how with creativity sets people apart.

Pressures on Traditional Programming Roles

Meanwhile, classic programming jobs face headwinds. A Fortune report from March 2025 revealed that U.S. employment for computer programmers has dropped to levels not seen since 1980, tying into the ascent of generative AI like ChatGPT. The Washington Post listed programming among the top 10 jobs hit hardest, as AI speeds up routine tasks and might cut the need for entry-level coders.

Industry voices are raising concerns. In March 2025, Anthropic's CEO Dario Amodei forecasted that AI could handle 90 percent of code in six months and almost all of it within a year. Social media posts from figures like Sumanth Raman echo this, suggesting that basic coding jobs could disappear by year's end as AI produces code more swiftly and accurately. Mark Zuckerberg stated that Meta's Llama initiatives aim for fully AI-written code in the next 12 to 18 months.

Not all views align on the extent of this change. A 2024 Danish study showed AI chatbots had little effect on wages or jobs in 11 fields, including software development. Bill Gates recognizes AI's influence but insists humans will stay vital for oversight and inventive thinking.

AI Coding Tools: From Assistants to Automated Modes

The pace of innovation in AI coding tools is staggering in 2025. Here is a look at the main contenders and directions.

GitHub Copilot and Its Rivals

GitHub Copilot, backed by OpenAI, holds a strong position. Microsoft reports that up to 30 percent of its code this year comes from AI. Still, challengers are gaining ground. Cursor stands out for its intuitive design, with developers saying it edges out Copilot in certain areas. Claude 3.7 Sonnet, Windsurf, and Replit bring unique strengths like planning code and spotting errors.

Devin and Self-Running Agents

Devin positions itself as the first true AI software engineer, capable of managing projects from start to finish, including deployment. Early iterations faltered on tough challenges, but the 2025 version bolsters its reliability in coding and docs. Social media buzz from 2024 praised its threat to sites like Upwork.

Zencoder's Coffee Mode

Launched by Zencoder, founded by former Wrike leader Andrew Filev, Coffee Mode arrived in April 2025. It lets developers press a button to have AI generate unit tests. Working with tools like Visual Studio Code, JetBrains IDEs, JIRA, and GitHub, Zencoder tops benchmarks and slips into current processes. This move toward simple automation is reshaping how we think about efficiency.

Emerging Platforms

Fresh developments include whispers of Apple and Anthropic teaming up for an AI coding system, alongside Amazon's push into code generation. These efforts show big tech's heavy investment in AI-powered building.

The Emergence of Multi-Agent Collaboration Platforms

Multi-agent collaboration platforms, or MCPs, represent a budding trend. They combine AI agents to tackle multifaceted jobs. A social media post described one MCP that lets agents code, pull from APIs, and manage real-world duties, labeling it transformative. These setups free developers from drudgery, allowing focus on big-picture design and fresh ideas.

MCPs hold special promise for businesses. As one observer noted online, companies crave AI coding solutions, fueling rivalry. Cursor leads for now, but acquisitions like OpenAI's Windsurf and integrated packages add pressure. MCPs might overhaul team dynamics, casting developers as directors who guide AI rather than code everything themselves.

Hurdles and Debates

The ascent of AI in coding brings complications. Here are the main points fueling discussions in 2025.

Fears of Job Loss

The International Monetary Fund figures that 60 percent of jobs in developed economies face AI exposure, with half at risk of harm. Goldman Sachs estimates 300 million global positions could shift, with coding high on the list. While AI might spawn roles like ethicists or prompt specialists, the shift could prove tough for beginners.

Risks of Depending Too Much on AI

Seasoned coders fret that tools like Copilot or Devin might stunt growth for newcomers. A 2025 article quoted skeptics who say fresh developers miss core knowledge when they rely heavily on AI. For instance, Cursor once declined to produce code, urging a user to build the logic on their own to foster independence.

Questions Around Ownership

Code from AI sparks debates on rights and laws. Who claims ownership of output from Devin or Copilot? Growing oversight on intellectual property is influencing the field, pushing firms to define terms clearly.

Issues with Bias and Dependability

AI tools for coding have flaws. A 2025 review found that while options like Grok err on small things, they are advancing fast. Yet, biases in data or invented errors, known as hallucinations, worry users, particularly in essential systems.

Essential Skills for Tomorrow's Developers

With AI claiming routine work, the developer's job is evolving. Here is what will count.

• Guiding AI: Mastery of directing and prompting tools will be key. NVIDIA's event stressed embedding AI in daily tasks.
• Interpersonal Abilities: Creativity, clear communication, and solving problems will set stars apart. AI handles code, but people grasp nuance and user wants.
• Niche Expertise: Areas like security, blockchain, or AI ethics will thrive as AI covers basics.
• Ongoing Education: Tools change monthly, so keeping current through resources like NVIDIA's institute or online groups is vital.

Looking Forward: Hope or Worry?

Coding's future excites and unnerves. AI opens doors, letting non-experts code and speeding breakthroughs. A quarter of Y Combinator startups with mostly AI code proves this. But threats of unemployment and fading skills, especially for starters, cast shadows.

Experts vary in outlook. Pew Research shows AI pros more upbeat than the public on job effects, seeing gains in speed and new paths. Others, like Ray Dalio, caution that harnessing AI's strength while preserving human input is key to dodging economic shakes.

For developers, adaptation is non-negotiable. Partnering with AI, via features like Zencoder's Coffee Mode or MCPs, will define winners. As Anthropic's Dario Amodei put it, telling folks to skip learning code ranks as terrible advice. The craft may transform, but its essence persists.

Final Thoughts: Welcome the Shift

In 2025, coding thrives in an AI-fueled world. Innovations like Devin, Copilot, and Zencoder redefine building software, while MCPs and business tools suggest developers will lead rather than labor over lines. The job landscape mixes highs and lows, booming for AI whizzes but testing for traditionalists. One certainty: thriving means adapting, learning, and harnessing AI.

In this post, I’m opening the hood on my dotfiles setup, sharing not just the configs themselves but the stories, decisions, and hard-earned lessons behind them. This isn’t a surface-level overview; it’s a detailed exploration of every file, folder, and choice that shapes my daily coding life. Whether you’re a newcomer starting your own dotfiles journey, a veteran developer curious about fresh tools, or simply someone who loves geeking out over configurations, I hope you’ll find something valuable here. Expect in-depth breakdowns, practical code snippets, personal anecdotes, comparisons to other approaches, and actionable tips to craft a setup that works for you. Let’s dive in.

Why Dotfiles Matter

Dotfiles, those unassuming configuration files tucked away with their telltale . prefix, are the quiet architects of a developer’s environment. They dictate everything from how your shell prompt looks to the behavior of your editor’s keybindings. For me, dotfiles are more than just settings; they’re a reflection of my approach to coding: prioritize efficiency, embrace modularity, and always keep refining.

My Dotfiles Origin Story

My dotfiles journey began out of necessity. Early in my career, setting up a new MacBook or Linux machine was a slog. I’d spend hours piecing together my ideal Neovim setup or tweaking an Alacritty theme to reduce eye strain, only to realize I couldn’t replicate it later. Switching jobs or hardware meant starting from scratch, and I’d inevitably forget some critical tweak. Frustrated, I decided to centralize my configurations in a Git repository with a few clear goals:

• Consistency: Make my environment feel identical whether I’m on my MacBook, Arch Linux desktop, or a remote server.
• Speed: Cut setup time from hours to minutes with a single git clone and a setup script.
• Shareability: Open-source my configs to learn from others and give back to the community.
• Control: Customize every tool to fit my workflow like a glove.

The Broader Dotfiles Landscape

Dotfiles are a universal practice, but every developer’s approach is unique. Some keep things lean with just a .bashrc or .vimrc, prioritizing portability. Others, like Zach Holman or Mathias Bynens, build intricate setups with custom scripts and integrations for tools like tmux or iTerm2. Then there are the aesthetic enthusiasts who craft visually stunning terminal and editor themes. My setup blends all three: it’s functional, performant, and easy on the eyes, drawing inspiration from communities like DotFiles.

What You’ll Take Away

By the end of this post, you’ll not only see what my dotfiles do but understand why I made each choice. I’ll break down my reasoning, compare my approach to alternatives, and share tips to help you build a setup that feels uniquely yours. Let’s start with the foundation: how my repository is organized.

Repository Structure: Built for Clarity and Flexibility

My dotfiles live at github.com/prashantkoirala465/Config-Files, designed to be modular, intuitive, and easy to maintain. Here’s the structure:

Config-Files/
├── aerospace/
│   └── aerospace.toml
├── alacritty/
│   └── alacritty.yml
├── karabiner/
│   └── karabiner.json
├── nvim/
│   ├── init.lua
│   └── lua/
├── wezterm/
│   └── wezterm.lua
├── yabai/
│   └── yabairc
├── zed/
│   └── settings.json
├── LICENSE
└── README.md

Why This Layout?

Each tool gets its own dedicated folder, keeping things organized and making it easy to swap components. If I decide to switch from Alacritty to Kitty, for example, I can update just the alacritty/ folder without touching the rest. The README.md walks you through setup steps, and the MIT LICENSE ensures others can freely use or adapt my work.

How Others Organize Dotfiles

Some developers use a “bare” Git repository, tracking files directly in their home directory (~/.git). Others rely on tools like Stow to manage symlinks. I opted for a directory-based approach because it’s simple and pairs well with my setup script, which handles symlinking to the home directory automatically.

Tips for Your Repository

• Document Clearly: A detailed README with setup instructions is non-negotiable.
• Use Submodules: For external plugins, Git submodules keep everything in sync.
• Commit Often: Regular backups prevent losing your tweaks.
• Test Fresh: Periodically try your setup on a clean virtual machine to ensure it works seamlessly.

Window Management: Taming the Chaos with Aerospace

For someone juggling multiple projects—coding, debugging, writing—a good window manager is essential. My workflow thrives on keyboard-driven organization, and for years, I relied on Yabai, a tiling window manager for macOS. Its ability to snap windows into grids or stacks transformed how I multitasked. My yabairc was tuned for simplicity and speed:

#!/usr/bin/env sh

yabai -m config layout bsp
yabai -m config window_gap 12
yabai -m config top_padding 10
yabai -m config bottom_padding 10
yabai -m config left_padding 10
yabai -m config right_padding 10
yabai -m config window_border on
yabai -m config window_border_width 4
yabai -m config active_window_border_color 0xff5e81ac

# Keybindings
yabai -m signal --add event=window_focused action="yabai -m window --focus recent"
yabai -m config mouse_follows_focus off
yabai -m config focus_follows_mouse off

This gave me a clean, tiled layout with subtle borders to highlight active windows. But as macOS tightened security with each update, Yabai required more manual tweaks to keep its scripting features running smoothly.

Enter Aerospace

In 2024, I switched to Aerospace, a polished alternative that builds on Yabai’s strengths. Its TOML-based configuration is more readable than Yabai’s shell scripts, and it feels smoother out of the box. Here’s a snippet from my aerospace.toml:

# Gaps and padding
gaps.inner = 18
gaps.outer = 20
screen-padding = 20

# Window appearance
border.width = 4
border.color.normal = '#5e81ac'
border.color.focused = '#88c0d0'

# Layout
default-workspace-layout = 'stacking'

# Keybindings
bind = [
  { key = 'Return', mods = ['Mod4'], command = 'exec alacritty' },
  { key = 'h', mods = ['Mod4'], command = 'focus left' },
  { key = 'l', mods = ['Mod4'], command = 'focus right' },
  { key = 'j', mods = ['Mod4'], command = 'focus down' },
  { key = 'k', mods = ['Mod4'], command = 'focus up' },
  { key = 'Shift+h', mods = ['Mod4'], command = 'move left' },
  { key = 'Shift+l', mods = ['Mod4'], command = 'move right' },
]

Aerospace’s stacking layout suits my preference for vertically organized windows, especially when editing multiple files in Neovim or Zed. The 18px gaps and 20px padding create a spacious workspace, and the Nordic-inspired colors add a subtle, professional touch.

Comparing Approaches

Many macOS users lean on native tools like Mission Control or apps like Rectangle. Linux developers often favor i3 or sway. Aerospace strikes a balance, offering tiling automation with enough flexibility for manual tweaks, making it ideal for developers who value both structure and control.

Window Management Tips

• Try Different Layouts: Experiment with binary space partitioning versus stacking to find your flow.
• Optimize Keybindings: Use intuitive shortcuts, like Vim-inspired h/j/k/l, for navigation.
• Test Multi-Monitor: Make sure your config works across displays.
• Document Choices: Note why you picked specific gaps or layouts for future tweaks.

Terminal Emulators: Where Commands Come to Life

The terminal is my control hub, whether I’m running scripts, managing Git, or connecting to a server. I need speed, reliability, and a touch of style. I rely on two emulators: Alacritty for its performance and WezTerm for its advanced features.

Alacritty: Built for Speed

Alacritty’s GPU acceleration makes it one of the fastest terminals out there. My alacritty.yml prioritizes clarity and minimalism:

window:
  padding:
    x: 10
    y: 10
  opacity: 0.95

font:
  normal:
    family: "Fira Code"
    style: "Regular"
  bold:
    style: "Bold"
  size: 12.0

colors:
  primary:
    background: '#1e1e2e'
    foreground: '#cdd6f4'
  cursor:
    text: '#1e1e2e'
    cursor: '#f5e0dc'
  normal:
    black: '#45475a'
    red: '#f38ba8'
    green: '#a6e3a1'
    yellow: '#f9e2af'
    blue: '#89b4fa'
    magenta: '#f5c2e7'
    cyan: '#94e2d5'
    white: '#bac2de'

The Fira Code font with ligatures makes code easy to read, while the Catppuccin Mocha theme offers a high-contrast, soothing palette. A slight opacity adds a modern feel without compromising legibility.

WezTerm: The Feature-Packed Alternative

WezTerm excels for complex workflows, with Lua-based scripting and features like tabs and multiplexing that rival tmux. My wezterm.lua balances aesthetics and functionality:

local wezterm = require 'wezterm'
local config = wezterm.config_builder()

config.font = wezterm.font('MesloLGS Nerd Font Mono', { weight = 'Bold' })
config.font_size = 14
config.enable_tab_bar = false
config.window_decorations = 'RESIZE'
config.window_background_opacity = 0.8
config.macos_window_background_blur = 10

config.colors = {
  foreground = '#CBE0F0',
  background = '#011423',
  cursor_bg = '#47FF9C',
  cursor_border = '#47FF9C',
  cursor_fg = '#011423',
  selection_bg = '#033259',
  selection_fg = '#CBE0F0',
  ansi = { '#214969', '#E52E2E', '#44FFB1', '#FFE073', '#0FC5ED', '#a277ff', '#24EAF7', '#24EAF7' },
  brights = { '#214969', '#E52E2E', '#44FFB1', '#FFE073', '#A277FF', '#a277ff', '#24EAF7', '#24EAF7' },
}

return config

The bold MesloLGS Nerd Font Mono and vibrant colors make WezTerm ideal for long coding sessions, with background blur and opacity creating an immersive experience.

Alacritty vs. WezTerm

• Alacritty: Perfect for lightweight tasks like SSH or quick scripts.
• WezTerm: Shines for managing multiple projects with tabs or custom Lua scripts.

Terminal Trends

Some developers prefer iTerm2 for macOS integration or Kitty for its image protocol. Minimalists might use macOS’s default Terminal or xterm on Linux. My dual setup lets me switch based on the task, offering flexibility over a single-tool commitment.

Terminal Tips

• Pick a Great Font: Nerd Fonts like Fira Code or MesloLGS support icons and ligatures.
• Choose Comfortable Colors: Themes like Catppuccin reduce eye strain.
• Automate Setup: Script your terminal installation and config deployment.
• Master Your Tool: Explore Alacritty’s YAML or WezTerm’s Lua docs for hidden gems.

Editors: Where Code Meets Creativity

My editors are where I spend most of my time, so they need to be fast, flexible, and intuitive. I primarily use Neovim, with Zed as a secondary option for specific tasks.

Neovim: My Coding Sanctuary

Neovim’s speed and extensibility make it my go-to editor. My init.lua uses Lazy.nvim for plugin management, tailored for a modern, streamlined workflow:

-- init.lua
vim.g.mapleader = ' '
vim.g.maplocalleader = ' '

require('lazy').setup({
  { 'nvim-treesitter/nvim-treesitter', build = ':TSUpdate' },
  { 'neovim/nvim-lspconfig' },
  { 'hrsh7th/nvim-cmp', dependencies = { 'hrsh7th/cmp-nvim-lsp' } },
  { 'catppuccin/nvim', name = 'catppuccin' },
  { 'nvim-telescope/telescope.nvim', dependencies = { 'nvim-lua/plenary.nvim' } },
})

-- Theme
vim.cmd.colorscheme 'catppuccin-mocha'

-- Treesitter
require('nvim-treesitter.configs').setup {
  ensure_installed = { 'lua', 'python', 'javascript', 'typescript' },
  highlight = { enable = true },
  incremental_selection = { enable = true },
}

-- LSP
local lspconfig = require('lspconfig')
lspconfig.pyright.setup {}
lspconfig.tsserver.setup {}

-- CMP (Autocompletion)
local cmp = require('cmp')
cmp.setup {
  mapping = {
    ['<C-n>'] = cmp.mapping.select_next_item(),
    ['<C-p>'] = cmp.mapping.select_prev_item(),
    ['<CR>'] = cmp.mapping.confirm({ select = true }),
  },
  sources = {
    { name = 'nvim_lsp' },
    { name = 'buffer' },
  },
}

-- Keybindings
vim.keymap.set('n', '<leader>ff', '<cmd>Telescope find_files<CR>', { desc = 'Find Files' })
vim.keymap.set('n', '<leader>fg', '<cmd>Telescope live_grep<CR>', { desc = 'Live Grep' })

This includes:

• Treesitter for syntax highlighting and navigation.
• LSP for Python (pyright) and JavaScript/TypeScript (tsserver).
• CMP for autocompletion.
• Telescope for fuzzy finding.
• Catppuccin Mocha for a consistent theme.

I opted for a custom config over distributions like NvChad to keep things lean and tailored.

Zed: A Modern Complement

Zed is a lightweight, collaborative editor I use for pair programming or quick edits. My settings.json keeps it simple:

{
  "theme": "Catppuccin Mocha",
  "font_size": 14,
  "font_family": "Fira Code",
  "buffer_font_weight": "Regular",
  "tab_bar": { "show": false },
  "keymap": [
    {
      "context": "Editor",
      "bindings": {
        "ctrl-w h": "pane:ActivatePrev",
        "ctrl-w l": "pane:ActivateNext"
      }
    }
  ]
}

Zed’s speed and collaboration features make it a great backup, especially for React and TypeScript projects.

Neovim vs. Zed

• Neovim: Unrivaled for customization and terminal workflows.
• Zed: Excels in GUI-based editing and team collaboration.

Editor Preferences

Many developers use VS Code for its plugins or JetBrains IDEs for robust projects. Vim enthusiasts might stick with vanilla Vim or LunarVim. My hybrid setup leverages Neovim’s power and Zed’s simplicity.

Editor Tips

• Build Gradually: Add plugins one at a time to avoid config overload.
• Master Shortcuts: Learn your editor’s keybindings to work faster.
• Sync Settings: Use Git to keep configs consistent across devices.
• Try New Tools: Experiment with editors like Zed or Helix to broaden your toolkit.

Keyboard Customization: Unlocking Efficiency with Karabiner

Karabiner-Elements transforms my MacBook’s keyboard into a productivity powerhouse. My favorite tweak maps Caps Lock to a Hyper Key (Cmd + Ctrl + Option + Shift) for endless shortcut possibilities:

{
  "title": "Caps Lock to Hyper Key",
  "rules": [
    {
      "description": "Caps Lock to Hyper",
      "manipulators": [
        {
          "from": {
            "key_code": "caps_lock",
            "modifiers": { "optional": ["any"] }
          },
          "to": [
            {
              "key_code": "left_control",
              "modifiers": ["left_command", "left_option", "left_shift"]
            }
          ],
          "type": "basic"
        }
      ]
    },
    {
      "description": "Hyper + t to open Alacritty",
      "manipulators": [
        {
          "from": {
            "key_code": "t",
            "modifiers": { "mandatory": ["left_control", "left_command", "left_option", "left_shift"] }
          },
          "to": [
            { "shell_command": "open -a Alacritty" }
          ],
          "type": "basic"
        }
      ]
    }
  ]
}

This lets me launch apps or scripts with a single key combo, saving countless keystrokes.

Why Karabiner?

Karabiner’s flexibility is unmatched on macOS, where keyboard customization is otherwise limited. It pairs perfectly with Aerospace’s bindings for a seamless workflow.

Keyboard Customization Trends

Linux users might use xmodmap or setxkbmap, while Windows developers lean on AutoHotkey. Some prefer hardware solutions like QMK keyboards. Karabiner offers a sweet spot for macOS users.

Keyboard Tips

• Start Small: Remap one key to build familiarity.
• Keep a Cheat Sheet: Document your mappings for reference.
• Test Thoroughly: Ensure remaps don’t conflict with existing shortcuts.
• Share Your Setup: Publish your rules to inspire others.

My Development Philosophy

My dotfiles reflect how I approach coding:

• Modularity: Separate configs for each tool simplify maintenance.
• Performance: Fast tools like Alacritty and Neovim keep me in flow.
• Aesthetics: Cohesive themes reduce visual clutter.
• Simplicity: Avoid unnecessary plugins to stay focused.
• Iteration: Constantly refine based on new tools or workflows.

This mindset comes from years of experimenting, failing, and learning—whether switching from Yabai to Aerospace or adding Zed to my toolkit.

Practical Tips for Your Dotfiles

Here’s what I’ve learned over the years:

1. Automate Setup: Create a setup.sh script to handle symlinking and dependencies.
2. Version Everything: Use Git to track and revert changes.
3. Steal Ideas: Browse GitHub for inspiration from other developers’ dotfiles.
4. Stay Lean: Only include configs you actively use.
5. Test Across Systems: Ensure compatibility with macOS, Linux, or WSL.

Resources to Explore

• Aerospace Docs
• Neovim Docs
• Alacritty Guide
• WezTerm Docs
• Karabiner-Elements Docs
• Zed Docs
• DotFiles Community

Wrapping Up: Make Your Dotfiles Your Own

My dotfiles are more than code; they’re a story of my growth as a developer, from my first .bashrc to my current Aerospace and Neovim setups. Each tweak reflects a problem solved or a lesson learned. Sharing them isn’t about bragging—it’s about sparking ideas and encouraging you to take charge of your tools.

I hope this deep dive into my Config-Files repository has inspired you, whether it’s to fork my repo, try a new config, or share your own dotfiles story. Drop me a message or comment with your thoughts, and let’s keep the conversation going.

Thanks for reading, and happy coding!