DEV Community: Sanjay Singh

Who Owns the Code Written by AI?

Sanjay Singh — Wed, 30 Sep 2026 13:34:42 +0000

A developer asks an AI coding assistant to build a Redis-backed rate limiter for a Node.js API. A few seconds later, 150 lines of usable TypeScript appear.

They review the implementation, change the data model, fix an edge case, add tests and commit it. A week later, the code is running in production and nobody thinks much about where the first draft came from.

Now imagine the company is being acquired two years later. During the IP review, someone asks a simple question: who owns those 150 lines?

Suddenly the answer is less obvious.

The developer may have rights in some of the work. Their employer may own those rights instead. Some sections may have too little human authorship to receive copyright protection in certain countries. And if the generated code reproduces protected third-party code, another copyright owner can enter the picture entirely.

AI hasn't created a new kind of ownership so much as exposed how many different things we casually bundle under the word own.

An AI system isn't the copyright owner

This part is relatively straightforward.

An AI model such as ChatGPT, Claude, Gemini or Copilot is not treated as a person that can hold copyright in its own name. The legal argument is instead about the humans and companies around the system: the user, employer, AI provider and, potentially, owners of existing material reflected in the output.

Even then, there are two separate questions that are easy to mix together.

One is whether you are allowed to use the generated code. The other is whether you have copyright in it and can stop someone else from copying it.

Those are not always the same thing.

What if the AI provider says the output belongs to you?

Provider terms are important, but they don't settle everything.

OpenAI's business terms, for example, currently state that, as between OpenAI and the customer and to the extent permitted by applicable law, the customer owns the output. OpenAI also assigns to the customer whatever right, title and interest it may have in that output.

Notice the phrase "to the extent permitted by applicable law."

That qualification matters.

A contract can determine whether the provider keeps a claim over the output. It cannot force copyright law to protect material that does not satisfy the legal requirements for copyright in the first place.

So when a provider says you own the output, the useful interpretation is closer to this: the provider is not trying to keep its own rights in the generated material.

It does not necessarily mean that every generated function gives you an exclusive copyright that can be enforced against the rest of the world.

Human involvement matters

The United States has taken a fairly clear position on this.

In its 2025 report on generative AI, the U.S. Copyright Office said that AI-generated material can receive copyright protection where a human has determined sufficient expressive elements of the resulting work. Human modifications and creative arrangements can qualify, while simply providing prompts is not enough by itself.

That distinction becomes interesting when applied to programming.

Suppose one developer asks an assistant to produce a complete OAuth implementation, copies the response into the project with almost no changes and ships it.

Another developer starts with an AI-generated implementation but redesigns the interfaces, replaces parts of the authentication flow, rewrites several functions, handles failure cases and changes the structure during code review.

Both used AI, but describing both pieces of software as "AI-written code" hides most of what actually happened.

In normal development the boundary gets even harder to see. A generated function may be modified in three pull requests, refactored six months later and partially replaced during a framework migration.

At some point, counting which keystrokes came from the model stops telling you very much about the finished software.

Your employer may own the human-written part

There is another layer once the code is written for work.

Under U.S. copyright law, a work prepared by an employee within the scope of employment can be a "work made for hire." In that situation, the employer is treated as the author for copyright purposes and generally owns the copyright unless the parties have agreed otherwise in a signed written agreement.

So imagine you use an AI assistant while building a feature at work. You make substantial original changes and contribute enough human authorship for copyright protection to exist.

You still may not personally own that copyright.

The same practical issue appears in other countries through employment law, IP-assignment clauses and company agreements, although the details differ by jurisdiction.

Contractors require particular care. Assuming that paying someone to write software automatically transfers every relevant IP right is the sort of assumption companies tend to discover during due diligence rather than when the contract is signed.

Typing the prompt, therefore, tells us very little about who ultimately owns the finished code.

The answer changes depending on the country

AI copyright is not governed by one global rule.

The UK is particularly interesting because its copyright law already contains a provision for works generated by a computer where there is no human author. In that situation, the author is treated as the person who undertook the arrangements necessary for the work's creation.

The UK government's March 2026 report says that, for a general-purpose AI producing output in response to a prompt, that person will usually be the person who entered the prompt. The protection currently remains in place.

The future of that provision is less certain. The same 2026 report notes that many consultation respondents supported removing special protection for wholly computer-generated works, but the government said it would continue monitoring the provision's use and impact.

India has its own wording.

Section 2(d) of the Indian Copyright Act says that for a computer-generated literary, dramatic, musical or artistic work, the author is "the person who causes the work to be created."

That sounds simple until you apply it to modern AI coding.

Who caused a generated feature to exist? The developer who entered the prompt? The engineer who designed the system? The company using the model? What if one person writes the prompt and another rewrites most of the result?

The statute gives India a starting point, but today's generative coding systems make that old wording much more interesting than it used to be.

The bigger problem may be code the model didn't invent

For a software company, this can be a more immediate concern than deciding who authored a generated for loop.

AI-generated output can sometimes resemble existing source code. Similarity alone doesn't prove infringement — software contains plenty of standard patterns, conventional APIs and straightforward implementations.

A distinctive block copied substantially from an existing project is a different matter.

Suppose an assistant returns an implementation that closely matches code from a GPL-licensed project. Your contract with the AI provider cannot erase whatever rights the original copyright holder has in that code.

The provider can assign its own rights.

It cannot assign somebody else's.

GitHub deals with this problem directly in Copilot. Its code-referencing system can identify certain suggestions that match code in public GitHub repositories and show developers the matching source and available licence information.

That is probably a healthier way for engineering teams to look at generated code. Don't assume code is legally clean merely because it arrived through an AI assistant. Treat provenance as something worth checking when the output is substantial or unusually distinctive.

Copyright isn't your only protection

There is another part of this discussion that is easy to overlook.

Imagine a company has a private repository containing proprietary pricing algorithms. Some portions started as AI-generated suggestions and their copyright status is uncertain.

That does not suddenly make the repository free for competitors to take.

Private software can be protected through confidentiality agreements, employment contracts, access controls and trade-secret law independently of copyright.

So there is an important difference between saying this particular material may not qualify for copyright and saying anyone is free to take it.

They are not equivalent.

What should engineering teams do about it?

Trying to calculate what percentage of a repository was "written by AI" isn't particularly useful.

Developers already work with generated migrations, IDE autocomplete, framework scaffolding, code snippets, internal libraries and copied documentation examples. AI makes the generated portion larger and much more sophisticated, but the need for review hasn't changed.

What matters is whether the team understands what it is shipping.

Generated code should go through normal review. Large or suspiciously distinctive outputs deserve more scrutiny. If a tool identifies matching public code, check the licence rather than assuming it is irrelevant.

Companies should also make sure employment and contractor agreements clearly address IP ownership. And proprietary source code should not be pasted into an external AI service without understanding the provider's data-use and confidentiality terms.

None of that requires developers to stop using AI.

It requires them to stop treating the AI chat window as a legal clean room.

So, who owns AI-written code?

There isn't one answer that works everywhere.

If meaningful human authorship is involved, copyright may exist in those human contributions. Depending on the employment or contractual arrangement, those rights may belong to the developer, their employer or another company.

Purely AI-generated material can receive different treatment depending on the country. The United States focuses on human authorship, while countries including the UK and India have statutory language dealing specifically with computer-generated works.

Third-party rights are separate again. If generated output substantially reproduces protected code, calling it "AI-generated" does not make the original copyright disappear.

For developers, the useful question isn't really Who pressed Generate?

It is: Who made the engineering decisions, where did the code come from, and what rights came with it?

Those are the questions that will matter when the code leaves the editor and becomes part of an actual product.

This article provides general information about software copyright and AI-generated code and is not legal advice. Copyright law, contracts and AI-provider terms vary by jurisdiction and can change.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Neural Networks, Explained Simply - Part 3: Activation Functions and the Problem with Straight Lines

Sanjay Singh — Tue, 29 Sep 2026 05:45:47 +0000

You've probably felt this at a party: too few people and it's awkward, too many and it's too loud to talk to anyone. There's a sweet spot in the middle, and no straight line can capture that shape.

TL;DR: A plain weighted sum can only ever draw straight-line-shaped decisions. Real preferences bend and curve, so every neuron passes its total through a small "bending" rule called an activation function before passing it along. That's the piece we mentioned but didn't explain back in Part 1.

The straight-line problem

Here's a subtlety we skipped past in Part 1. If a neuron's output were just its raw weighted sum, passed straight through with no bending at all, stacking many of those would still collapse into one giant straight line. Adding straight lines together, however many times, only ever gives you another straight line. Depth wouldn't buy you anything.

Part 1's neuron avoided that specific trap with its hard on/off cutoff (go or don't go, nothing in between). But that cutoff creates a different problem, one that connects directly to Part 2. Training works by nudging each weight a little, based on how far off a guess was. A light switch doesn't have a "little": it's either on or off, with no middle ground to nudge toward. That makes it nearly impossible to work out which direction to adjust the weights feeding into it.

What we actually need is something in between: a rule that's still bent enough to keep depth meaningful, but keeps enough of a slope that "nudge it a little" actually means something.

Enter the activation function

An activation function is that in-between rule: a small math function that reshapes a neuron's raw number before it moves to the next layer, in a way that's both nonlinear (so stacking layers keeps adding power) and, unlike an on/off switch's instant jump, changes gradually enough to give training an actual direction to nudge toward.

Here are two common ones:

Sigmoid takes any number, however large or negative, and squashes it into a smooth range between 0 and 1. Think of it as a dimmer switch instead of an on/off light switch: it can express "70% confident," not just "yes" or "no."

ReLU (short for Rectified Linear Unit) is simpler: if the number's negative, treat it as 0. If it's positive, let it through exactly as is. It's basically a one-way valve. Despite being this simple, it's the default choice in most modern networks, because it's cheap to compute and, once you stack enough of these, the network can approximate remarkably complex curves.

Back to the party

With ReLU-style neurons, a network can build detectors like "start ramping up once there are more than 3 friends" and "start ramping down twice as fast once there are more than 15 friends." Add those together, and the rise turns into a fall right where the second detector kicks in, producing exactly the sweet-spot shape a single straight-line rule could never draw:

This is the real reason activation functions matter: they're not a technical footnote, they're what makes "network" mean something more powerful than "one big weighted sum."

Quick recap

If a neuron's output were just its raw weighted sum passed straight through, stacking layers would still collapse into one straight line, no matter how deep the network.
Part 1's hard on/off cutoff avoids that, but creates a different problem: training nudges weights a little at a time, and a light switch has no "little" to nudge toward.
An activation function solves both: it's nonlinear enough to make depth meaningful, and, unlike an on/off switch's instant jump, changes gradually enough to give training a direction to nudge toward.
Sigmoid squashes any number into a smooth 0-to-1 range; ReLU zeroes out negatives and passes positives through unchanged.
Stacking activation-bent neurons lets a network learn genuine curves, like a rise-then-fall sweet spot, not just a single straight-line rule.

Try it yourself

Think of another decision with a sweet spot, not just a yes/no: coffee (too little and you're groggy, too much and you're jittery), or study time before a test (too little and you're unprepared, too much and you're exhausted). Sketch what that curve would look like on paper, then notice: a straight line could never draw it, but two or three "bend points" could.

Next up: Loss Functions and Gradient Descent, where we'll finally explain, in plain language, exactly how a network decides which direction to nudge each weight during training.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Architecture Case Study: Migrating a Developer SaaS from Serverless to a $10 VPS with Docker

Sanjay Singh — Mon, 28 Sep 2026 08:19:41 +0000

Serverless platforms like Vercel and AWS Lambda are the default choice for modern web applications. For the first few months of building our developer platform, the serverless promise held up: push to git main, instant preview branches, and zero server maintenance.

Then real traffic arrived.

Within weeks, we ran headfirst into database connection pool exhaustion, unpredictable cold-start spikes up to 1.8 seconds, restrictive execution timeouts, and an unexpected bandwidth billing spike for serving static assets and dynamic OpenGraph images.

We decided to migrate our entire production web application to a $10/month VPS (2 vCPU, 4GB RAM) running Docker and Caddy.

Here is the complete post-mortem, the architecture shift, production Dockerfile configurations, zero-downtime deployment workflows, memory budget allocations, and real benchmark data.

1. The Serverless Wall: Why We Had to Move

Serverless is marketed as "infinitely scalable," but it forces applications into an ephemeral, stateless execution model that creates significant hidden friction for content-heavy or data-intensive developer tools.

The Three Breaking Points:

A. Connection Pool Exhaustion on Relational Databases

Every serverless invocation spins up an isolated Node.js container. Because instances don't share memory, they cannot share a traditional database connection pool.

A burst of 100 concurrent requests created 100 simultaneous TCP + TLS handshakes to our PostgreSQL instance.
Even with external poolers (like PgBouncer or Supabase/Neon connection poolers), HTTP-based pooling added 40–80ms of transaction overhead per request.

B. The Cold-Start & Memory Penalty

When an API route had to parse Markdown into an Abstract Syntax Tree (AST), sanitize HTML, and compute syntax highlighting, the cold start was brutal:

Warm Serverless Invocation: ~85ms
Cold Serverless Invocation (P99): 1,450ms – 1,820ms
Memory Constraints: Increasing function memory from 1024MB to 3008MB trimmed cold-start times, but tripled invocation costs.

C. Bandwidth & Asset Markup

Serverless platforms typically charge $0.15 to $0.40 per GB for outbound bandwidth once you exceed initial tiers. For an app generating dynamic OG images (each 200KB–400KB) and syndicating rich technical content, bandwidth quickly became our largest single operational expense.

2. The Target Architecture: The $10 VPS Stack

We selected a mid-tier VPS (such as a Hetzner Cloud CX22 or DigitalOcean Droplet: 2 vCPU, 4GB RAM, 40GB NVMe SSD) costing roughly €5 to $10/month.

The 4GB RAM Budget Allocation

Running a full stack on a 4GB VPS requires explicit memory ceilings to prevent the Linux Out-Of-Memory (OOM) killer from terminating your process:

Service	Memory Limit (Hard Cap)	Reserved / Typical Footprint
Next.js Standalone App	1,536 MB	350 MB – 600 MB
PostgreSQL (Local / Container)	1,024 MB	250 MB – 450 MB
Redis (Cache & Queues)	384 MB	64 MB – 128 MB
Caddy Reverse Proxy	128 MB	30 MB – 60 MB
Linux OS & System Daemons	Uncapped	~350 MB
Swap Buffer (Disk NVMe)	4,096 MB	Safety net for build spikes

3. The Production Multi-Stage Dockerfile

The standard next build produces large build artifacts with development dependencies. By enabling output: 'standalone' in next.config.js, Next.js traces imports and bundles only the exact node_modules needed in production.

`next.config.js`

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'standalone',
  poweredByHeader: false,
  compress: true,
};

module.exports = nextConfig;

Production `Dockerfile`

This Dockerfile solves three common production pitfalls:

Missing libc6-compat on Alpine (required by sharp for image optimization).
Unprivileged user permissions for Next.js Incremental Static Regeneration (.next/cache).
Internal health check probe for zero-downtime rolling deploys.

# Stage 1: Dependency resolution
FROM node:20-alpine AS deps
RUN apk add --no-cache libc6-compat
WORKDIR /app

COPY package.json package-lock.json ./
RUN npm ci --ignore-scripts

# Stage 2: Application builder
FROM node:20-alpine AS builder
RUN apk add --no-cache libc6-compat
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .

ENV NEXT_TELEMETRY_DISABLED=1
ENV NODE_ENV=production

RUN npm run build

# Stage 3: Minimal runner image (~85MB)
FROM node:20-alpine AS runner
# Install libc6-compat for sharp native bindings on Alpine
RUN apk add --no-cache libc6-compat curl
WORKDIR /app

ENV NODE_ENV=production
ENV NEXT_TELEMETRY_DISABLED=1
ENV PORT=3000
ENV HOSTNAME="0.0.0.0"

# Create unprivileged system user for security
RUN addgroup --system --gid 1001 nodejs && \
    adduser --system --uid 1001 nextjs

# Copy public static assets and standalone server bundle
COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

# Ensure nextjs user owns the cache directory for ISR updates
RUN mkdir -p .next/cache && chown -R nextjs:nodejs .next/cache

USER nextjs

EXPOSE 3000

# Health check to ensure container is responding before traffic routing
HEALTHCHECK --interval=5s --timeout=3s --start-period=5s --retries=3 \
  CMD curl -f http://127.0.0.1:3000/api/health || exit 1

CMD ["node", "server.js"]

4. `docker-compose.yml` with Hard Memory Limits

version: '3.8'

services:
  caddy:
    image: caddy:2.8-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp" # HTTP/3 QUIC
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - internal-net
    depends_on:
      - web-blue

  web-blue:
    image: app-web:latest
    build:
      context: .
      dockerfile: Dockerfile
    restart: unless-stopped
    env_file:
      - .env.production
    expose:
      - "3000"
    deploy:
      resources:
        limits:
          cpus: '1.50'
          memory: 1536M
        reservations:
          cpus: '0.25'
          memory: 512M
    networks:
      - internal-net

  web-green:
    image: app-web:latest
    restart: "no"
    env_file:
      - .env.production
    expose:
      - "3000"
    deploy:
      resources:
        limits:
          cpus: '1.50'
          memory: 1536M
        reservations:
          cpus: '0.25'
          memory: 512M
    networks:
      - internal-net

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: ["redis-server", "--appendonly", "yes", "--maxmemory", "256mb", "--maxmemory-policy", "allkeys-lru"]
    volumes:
      - redis_data:/data
    networks:
      - internal-net
    deploy:
      resources:
        limits:
          memory: 384M

volumes:
  caddy_data:
  caddy_config:
  redis_data:

networks:
  internal-net:
    driver: bridge

5. Reverse Proxy: Caddyfile vs. Nginx

Nginx requires manual Certbot cron jobs, Diffie-Hellman parameter generation, and verbose SSL configuration. Caddy does this automatically out of the box with modern TLS 1.3 defaults and HTTP/3 support.

`Caddyfile`

yourdomain.com {
    # Modern compression
    encode zstd gzip

    # Essential Security Headers
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "strict-origin-when-cross-origin"
    }

    # Reverse proxy to the active Next.js container slot
    reverse_proxy web-blue:3000 {
        # Active health checks
        health_uri /api/health
        health_interval 5s
        health_timeout 2s

        # Persistent HTTP keepalive to backend container
        transport http {
            keepalive 30s
            keepalive_idle_conns 100
        }
    }
}

6. Zero-Downtime Blue/Green Deployments with Caddy

A common mistake with docker compose --scale web=2 is that Docker Compose scales down from the highest numbered container, which can accidentally terminate the freshly built container rather than the old one.

Instead, we use a simple Blue/Green deployment script. It boots the inactive container, waits for its health check to return HTTP 200, updates Caddy's upstream, issues an atomic caddy reload (which drops zero active connections), and stops the previous container.

`scripts/deploy.sh`

#!/usr/bin/env bash
set -euo pipefail

ACTIVE_TARGET=$(docker ps --format '{{.Names}}' | grep -E 'web-(blue|green)' | head -n 1 || true)

if [[ "$ACTIVE_TARGET" == *"web-blue"* ]]; then
  NEW_TARGET="web-green"
  OLD_TARGET="web-blue"
else
  NEW_TARGET="web-blue"
  OLD_TARGET="web-green"
fi

echo "==> Currently active: ${OLD_TARGET:-none}"
echo "==> Deploying new version to: ${NEW_TARGET}"

git pull origin main
docker compose build "${NEW_TARGET}"
docker compose up -d --no-deps "${NEW_TARGET}"

echo "==> Waiting for ${NEW_TARGET} to become healthy..."
for i in {1..20}; do
  STATUS=$(docker inspect --format='{{json .State.Health.Status}}' "zyvop-${NEW_TARGET}-1" 2>/dev/null || echo '"starting"')
  if [ "$STATUS" == '"healthy"' ]; then
    echo "==> ${NEW_TARGET} is healthy!"
    break
  fi
  if [ "$i" -eq 20 ]; then
    echo "==> ERROR: Health check timed out on ${NEW_TARGET}. Aborting cutover."
    docker compose stop "${NEW_TARGET}"
    exit 1
  fi
  sleep 2
done

# Atomically switch Caddy upstream
sed -i "s/${OLD_TARGET}:3000/${NEW_TARGET}:3000/g" Caddyfile
docker compose exec caddy caddy reload --config /etc/caddy/Caddyfile

echo "==> Traffic switched to ${NEW_TARGET}. Stopping ${OLD_TARGET}..."
if [ -n "$OLD_TARGET" ]; then
  docker compose stop "$OLD_TARGET"
fi

docker image prune -f
echo "==> Deployment completed with zero downtime!"

7. The Database Win: From Leased Connections to Persistent Pool

Under serverless, every database query required either an HTTP fetch to a serverless driver or opening a new TCP socket:

// Old Serverless Approach (Ephemeral)
// Created on every function cold start
import { Pool } from 'pg';

const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  max: 1, // Kept at 1 to prevent connection pool exhaustion across lambdas
});

On our persistent VPS, the Node.js runtime remains alive indefinitely. We configure a single persistent pool of 15–20 reusable connections with graceful shutdown handling:

// New VPS Approach (Persistent Process)
import { Pool } from 'pg';

declare global {
  var __dbPool: Pool | undefined;
}

export const db =
  global.__dbPool ??
  new Pool({
    connectionString: process.env.DATABASE_URL,
    max: 20, // 20 persistent, pre-warmed connections
    idleTimeoutMillis: 30000,
    connectionTimeoutMillis: 2000,
  });

if (process.env.NODE_ENV !== 'production') {
  global.__dbPool = db;
}

// Gracefully drain pool on container shutdown
process.on('SIGTERM', async () => {
  console.log('SIGTERM received: Draining PostgreSQL connection pool...');
  await db.end();
  process.exit(0);
});

The Result:

Database connection latency dropped from ~65ms (TCP + TLS negotiation per request) to < 1.2ms (reused local socket connection).

8. Hardening the $10 VPS for Production

A common hesitation with self-hosting is maintenance. By following these four steps, our maintenance overhead is less than 15 minutes per month.

A. The 4GB Swap Buffer (Prevent OOM Spikes)

Never run a 4GB VPS without swap. If npm run build or traffic spikes exceed 4GB, swap prevents the kernel from panicking:

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

B. Automatic Docker Log Rotation

Unbounded container logs will quietly fill your disk. Configure the Docker daemon globally:

/etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "50m",
    "max-file": "3"
  }
}

C. Firewall (UFW)

Only expose ports 80, 443, and your SSH port:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 443/udp
sudo ufw enable

D. Automated Encrypted Backups via S3/R2

A simple cron job runs pg_dump, encrypts the archive, and synchronizes to Cloudflare R2 / AWS S3:

scripts/backup.sh:

#!/usr/bin/env bash
set -euo pipefail

BACKUP_FILE="/tmp/backup_$(date +%Y%m%d_%H%M%S).sql.gz"
docker compose exec -T postgres pg_dump -U postgres app_production | gzip > "$BACKUP_FILE"

# Upload to S3-compatible storage (e.g. Cloudflare R2 via rclone)
rclone copy "$BACKUP_FILE" remote:backups-bucket/db/
rm -f "$BACKUP_FILE"
echo "==> Backup successfully uploaded to offsite storage."

9. Performance & Cost Post-Mortem

We ran a load test using wrk simulating 50 concurrent connections over 60 seconds hitting an authenticated database-backed endpoint.

Benchmark Results

Metric	Serverless (Previous Stack)	$10 VPS + Docker (Current Stack)	Improvement
P50 Latency	114 ms	38 ms	3.0x faster (66% drop)
P95 Latency	412 ms	82 ms	5.0x faster (80% drop)
P99 Latency (Cold Start Spike)	1,740 ms	124 ms	14.0x faster (92.8% drop)
Max Throughput	~280 req/sec (hit concurrency limits)	1,150 req/sec	4.1x capacity
Failed Requests (504 / 500)	1.8% during spikes	0.00%	Zero errors

Monthly Cost Comparison

Expense Item	Serverless Stack	$10 VPS Stack
Compute / Invocations	$45.00 (Base Pro + Overage)	$10.00 (Fixed VPS)
Bandwidth / Egress	$38.50 ($0.15/GB overage)	$0.00 (20TB included)
External DB Connection Pooler	$15.00	$0.00 (Native socket pooling)
Static Asset Hosting / Preview URLs	Included	$0.00 (Cloudflare Free Tier)
Total Monthly Spend	$98.50+	$10.00 flat

10. The Decision Matrix: When Should You Stay Serverless?

Self-hosting isn't a silver bullet for every project. Here is our practical decision framework:

Stay on Serverless if:

Your traffic is completely sporadic (e.g., 0 requests for 8 hours, then a 5-minute spike).
You do not have a dedicated engineer with basic Linux terminal comfort.
Your application architecture is entirely stateless (no relational database or using third-party managed HTTP APIs like DynamoDB/Firestore).

Migrate to a VPS + Docker if:

You use a relational database (PostgreSQL, MySQL) and suffer connection bottlenecks.
You need predictable sub-100ms response times without cold-start jitter.
You run background jobs, WebSockets, or long-running worker processes.
You want a fixed, predictable monthly infrastructure bill regardless of traffic surges.

Conclusion

Serverless got our project off the ground in a weekend. But moving to a modest $10 VPS simplified our database connectivity, eliminated cold starts, and delivered a snappier, more predictable experience for our users.

Modern tools like Docker standalone builds, Caddy's automated SSL, and Blue/Green atomic config reloads have removed the traditional friction of managing servers. You don't need Kubernetes to scale a developer SaaS—a single well-tuned Linux box can take you much further than you think.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Should You Still Learn to Code Now That AI Can Write It?

Sanjay Singh — Sun, 27 Sep 2026 02:35:28 +0000

Every few weeks someone posts the same argument: AI writes the code now, so spending years learning to program yourself is a waste of time.

Nvidia's Jensen Huang has been making a version of this case since 2024, when he told the World Government Summit in Dubai that computing's whole job is to make programming unnecessary, since human language is now the only programming language anyone needs, according to TechRadar. I think he is wrong, and the evidence for that is not a hunch.

Google gives Huang's argument some real numbers to stand on. More than a quarter of its new code was AI generated by late 2024, CEO Sundar Pichai told investors on a call covered by Fortune, and that share has climbed since.

So the code volume argument is not made up. What it leaves out is who is checking that code, and whether that person still knows what they are looking at.

What happens when you actually measure it

That question got a real answer in January 2026, when Anthropic ran a randomized trial on 52 mostly junior developers learning a Python library none of them had touched before. Half got AI help, half did not. Both groups then took a quiz on debugging and comprehension with no AI allowed.

The AI group finished the coding task barely faster and scored 50 percent on the quiz. The unaided group scored 67 percent, with the widest gap on debugging, per Anthropic's own writeup and the arXiv paper behind it.

Something similar showed up in METR's study of experienced open source developers a few months earlier. Given real issues on repositories they had worked in for years, developers using AI tools took 19 percent longer than developers working without them.

Before starting, they had guessed AI would make them 24 percent faster. Afterward, they still believed it had, estimating a 20 percent speedup that never happened. Feeling faster and being faster turned out to be two different things, off by close to 40 points.

GitClear's research on actual codebases backs this up from a different angle. Across more than 200 million changed lines, refactoring dropped from about a quarter of all changes to under 10 percent, while duplicated code blocks jumped eightfold, right as AI assisted commits became routine.

GitClear's own CEO has pointed to a simple mechanism: AI tends to write a new function instead of reusing one that already exists, because it does not carry the context of the codebase around the way a developer does.

The market already believes this

Undergraduate computer science enrollment fell 3.6 percent in fall 2025 and another 8.4 percent the following spring, with graduate programs down 14 percent, according to National Student Clearinghouse numbers reported by Fortune.

Read that next to the Stanford Digital Economy Lab finding that employment for software developers aged 22 to 25 dropped 13 percent relative to older developers in the same jobs since late 2022, nearly 20 percent from its own peak. Fewer people are studying it, and fewer of the ones who do are getting hired into it.

You could read that as proof AI already won and there is no point learning a shrinking trade. I read it the other way.

The entry level job used to be where fundamentals got built on the clock, with a senior engineer catching your mistakes as you went. That job is disappearing faster than the fundamentals it used to teach. If nobody is going to hand you that training anymore, you have to go build it yourself, on purpose, before you need it.

Stack Overflow's 2025 survey of about 49,000 developers shows the tension in real numbers. 84 percent are using or planning to use AI tools, up from 76 percent a year before, and trust in the results has dropped to about a third of respondents.

Two thirds say the output is almost right but not quite. Nearly half say debugging it takes longer than writing the code themselves would have, per ADTmag's coverage of the same numbers. Developers keep reaching for the tool and keep not believing it.

Here is the part of the Anthropic study that actually matters more than the headline number: it was not AI use itself that predicted the score, it was how people used it.

Developers who asked the assistant to explain its reasoning, or questioned why a piece of code worked, scored close to the unaided group. Developers who just accepted what came out scored the worst. The tool was not the variable. Getting stuck first was.

So learn to code. Not because the market owes you a job for it, and not because Huang is lying about where AI is headed.

Learn it because somebody has to be able to tell when the code is wrong, and that skill is built by writing bad code yourself first, not by reading good code somebody else generated.

Build the thing without help once. Then use AI to go faster on the parts you already understand.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Claude Opus 5.5 Just Landed

Sanjay Singh — Thu, 24 Sep 2026 18:28:44 +0000

Anthropic released Claude Opus 5.5 on September 22, 2026, its first model since CEO Dario Amodei published "We Must Pace the Frontier," an essay from about a week earlier arguing that safety practices need to keep pace with capability jumps. The model was evaluated before launch by outside groups including METR and Frontier Design.

The pitch

Opus 5.5 performs roughly at the level of Anthropic's top public model, Claude Fable 5.1, on most tasks, while costing 40% less to run than the outgoing Opus 5. Anthropic is candid that at this capability tier, benchmark gaps are becoming less reliable as a stand-in for real-world differences.

Benchmarks

Verified against Anthropic's own comparison table.

Benchmark	Opus 5.5	Fable 5.1	Opus 5	GPT-6 Astra	GPT-5.6 Sol
Terminal-Bench 4.0	66.4%	55.8%	52.3%	57.9%	37.3%
FrontierCode v1.1	54.4%	50.3%	48.0%	53.3%	47.5%
CursorBench 4.0	57.8%	51.8%	46.6%	-	41.7%
GDPval-AA v2.1 (Elo)	1846	1735	1708	1542	1588
Humanity's Last Exam	67.7%	65.6%	63.6%	57.2%	-
AutomationBench	40.0%	31.4%	26.9%	41.4%	28.8%
Terminal-Bench-Science 0.1	58.7%	52.6%	29.0%	64.6%	22.4%
OSWorld 2.0 (computer use)	81.8%	80.7%	74.0%	-	-
Chartography (chart reading)	89.0%	88.4%	83.4%	-	-

These numbers match Anthropic's published figures exactly, though OSWorld 2.0 and Chartography are scored under partial-credit and tool-assisted conditions per Anthropic's own footnotes, and GPT-6 Astra and GPT-5.6 Sol are absent from both rows, so those two comparisons are Claude-only rather than a full field test.

The two bolded losses to GPT-6 Astra have different causes. On Terminal-Bench-Science 0.1, Anthropic's general safeguard footnote applies: when Opus 5.5's safety systems intervened during testing, biology and frontier-AI-research tasks were completed by the older Opus 5 instead, which likely dragged the score down.

On AutomationBench, safeguards are still the cause, just structured differently. Those results were run by Zapier without fallback models, so any safeguard intervention counted as an automatic failure rather than being completed by a substitute model, as on Terminal-Bench-Science, producing a lower score than Opus 5.5 would achieve in practice.

Coding: the headline act

One tester completed a 680,000-line code migration in under a day. Asked to cut load times across a web app, Opus 5.5 succeeded 39 of 40 times without breaking behavior, where Opus 5 made smaller improvements that also altered the app's behavior. A 200,000-line codebase audit took Opus 5.5 under three hours versus Opus 5's 20-plus hours, at roughly 40% of the token cost.

Translating HAProxy from C to Rust, Opus 5.5 passed nearly all regression tests in 9.5 hours against Fable 5.1's 12, at about half the cost. Against GPT-6 Astra, it matches Terminal-Bench 4.0 for around 40% of the price and beats FrontierCode for about 20% of the price. In a separate test where several Claude models built a game from a single prompt, Opus 5.5's build scored highest on graphics and polish.

Customers quoted in the release, including GitHub, Box, and Optiver, independently described similar drops in tokens per task. Stripe is also quoted in the release, though on session efficiency completing a 40-pull-request rebase rather than on token counts.

Security. Opus 5.5 matches or beats Opus 5 against prompt-injection attacks across coding, tool use, computer use, and web browsing, and ties Fable 5.1 for the lowest prompt-injection success rate in third-party testing by the AI security firm Gray Swan. For long, unattended coding sessions, Anthropic also pairs the model with a pre-action classifier, an auditable open-source sandbox, and code review meant to catch vulnerabilities before they merge.

Not just code

In a blind earnings-report test where any invented figure counted as an automatic fail, 16 of 18 Opus 5.5 attempts passed; neither Fable 5.1 nor Opus 5 passed on any attempt. Walleye Capital, an early enterprise tester, said Opus 5.5 caught an error in the firm's own evaluation instructions that no prior model had noticed, a detail confirmed directly in Anthropic's writeup.

In a separate merger-analysis test, Opus 5.5 and Opus 5 each built an Excel financial model and turned it into an executive presentation. Both reached the same conclusion, but Opus 5.5 finished in 63 minutes versus 93 for Opus 5, at half the cost and with a cleaner model.

Two more data points came from named enterprise testers. At its lowest effort setting, Deloitte says Opus 5.5 caught 72% of known bugs in code review, against 56% for Opus 5 at high effort, and Hebbia's finance-workflow rubric put Opus 5.5 at 86.6% coverage versus 60.3% for Opus 5, alongside the model's best-ever citation recall.

Writing style overhaul

Anthropic says Opus 5.5 leads with the important information first and uses less jargon, addressing the most common complaint about Opus 5. Box reports roughly a two-thirds cut in token usage on content-heavy workloads as a result.

Safety

On Anthropic's roughly 2,000-scenario behavioral audit, Opus 5.5 scored better than any recent Claude model on nearly every measure of misaligned behavior and is the company's strongest model to date on most measures of honesty. In a new evaluation built to test how often a model tries to cross containment boundaries, Opus 5.5 attempted this about 85% less often than Opus 5 or Claude Mythos 5.1, and every attempt it did make was low severity and self-reported.

Because Opus 5.5 is now comparable to Mythos 5.1 in biology and cybersecurity, it ships under safeguards similar to Fable 5.1's: most flagged cybersecurity tasks are re-routed to the older Opus 4.8, and flagged biology tasks go to Opus 5, with full biology capability available to vetted organizations through Anthropic's Life Sciences Verification Program.

Anthropic says this reflects real capability rather than caution alone: in biology, Opus 5.5 improved on a long-horizon molecular-design evaluation run with Dyno Therapeutics, and outside red-teamers rated its scientific novelty on par with the best model they had tested.

On the cybersecurity side, Anthropic is expanding its Cyber Verification Program to three tiers of increasingly permissive access for vetted practitioners, up to and including the restricted Mythos models. Anthropic also reports signs that Opus 5.5 often suspects it is being evaluated, which complicates its ability to predict how the model will behave across the real-world settings it gets deployed into. Evaluation awareness is a known open problem across the AI industry, not unique to Anthropic.

Opus 5.5 also launches with preserved thinking, the anti-distillation safeguard introduced with Fable 5.1, which blocks API users from editing Claude's prior context to extract its reasoning. It applies to API accounts created on or after August 31, 2026, and extended thinking can no longer be fully disabled.

Pricing & availability

	Opus 5.5	Opus 5
Input (per 1M)	$4	$5
Output (per 1M)	$20	$25
Cache reads (per 1M)	$0.20	$0.50
Cache writes (per 1M)	$5	$6.25

At standard settings, Opus 5.5 also generates output more than 30% faster than Opus 5. A separate fast mode in Claude Code and the Claude Platform trades some of that headroom for up to 2.5x the speed, priced at $8 per million input tokens and $40 per million output tokens.

Live now on the Claude Platform (claude-opus-5-5), AWS, Google Cloud, and Microsoft Azure. Pro/Max/Team subscribers and seat-based Enterprise plans get bumped five-hour limits plus a bankable rate-limit reset. Sonnet 5.5 and Haiku 5.5 are coming in the following weeks.

A note on accuracy

The "smaller improvements that also altered the app's behavior" line about Opus 5 comes straight from Anthropic's own comparison, not an independent claim, since Anthropic is grading its own predecessor here. Worth keeping that context in mind when reading vendor-published benchmarks.

The same goes for every customer statistic in this piece, Deloitte, Hebbia, GitHub, and the rest: those were selected and published by Anthropic for the launch, not gathered independently, so treat them as testimonials rather than a representative sample.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Qwen-Image-2.1: Compact, Efficient, and Unified Image Creation

Sanjay Singh — Wed, 23 Sep 2026 02:45:13 +0000

Getting a first image out of it

Alibaba's Qwen team open-sourced Qwen-Image-2.1 today. Diffusers already supports it: maintainers merged a QwenImage21Pipeline the same day, per the Qwen-Image-2.1 GitHub README.

Installation is four pip commands: torch 2.4 or newer, transformers 5.17 or newer, the git build of diffusers, and accelerate.

import torch
from diffusers import QwenImage21Pipeline

pipe = QwenImage21Pipeline.from_pretrained(
    "Qwen/Qwen-Image-2.1", torch_dtype=torch.bfloat16
).to("cuda")

image = pipe(
    prompt="A weathered lighthouse at dusk, storm clouds on the horizon",
    num_inference_steps=40,
    generator=torch.Generator("cuda").manual_seed(7),
).images[0]

image.save("lighthouse.png")

Default output is native 2048x2048. The GitHub README lists seven aspect-ratio presets from 1:1 up to 16:9 and 9:16, each mapped to a fixed pixel size rather than an upscaled crop.

Editing uses the same pipeline call. Pass an existing image alongside the prompt, and Qwen-Image-2.1 treats it as a condition instead of routing to a separate model.

For anyone without a local GPU worth the download, ComfyUI and ModelScope both list Qwen-Image-2.1 as natively supported from day zero, with prebuilt workflow templates, per the same README.

Under the hood: one model, two jobs

Qwen-Image-2.1 is a single-stream diffusion transformer: 32 layers holding 7B parameters in the visual generation component, per the project's README.

It pairs that transformer with a Qwen3-VL 8B vision-language model as the text encoder and a 64-channel RGBA autoencoder that compresses images 16x, per the GitHub README. The RGBA channel count is what lets a single VAE round-trip transparent images without a separate codec.

The attention pattern is block-causal rather than fully bidirectional, per the GitHub README: text tokens use a standard left-to-right causal mask, while image tokens inside the same block attend to each other bidirectionally.

The rule, straight from the repository, is (q_idx >= kv_idx) or same_image_block.

That mixed granularity is also what makes prefix KV cache reuse possible. Once a condition image and its instructions are encoded at the first denoising step, they are cached and reused for every later step instead of recomputed.

For editing tasks with several reference images, that caching is the actual efficiency gain, not just a footnote.

Encoding cost for the conditioning context is paid once per generation rather than once per denoising step. That is where compact and efficient stops being a slogan and starts being a measurable speedup.

Native transparency, in one model instead of two

Until this release, transparent image generation lived in a separate checkpoint. Alibaba shipped that capability on its own on December 19, 2025, as Qwen-Image-Layered, a dedicated model for RGBA layer decomposition.

Qwen-Image-2.1 folds that capability into the main model, per the GitHub README. The same weights generate an opaque image or a transparent one depending on the prompt, and can extract a subject from an ordinary photo onto a transparent layer.

Editing extends to transparent layers directly, and to up to 10 reference images at once for multi-subject composition, per the GitHub README.

Local edits are specified by a circle, a painted annotation, or a separate mask, rather than a full prompt rewrite, per the GitHub README.

Getting reliable RGBA takes specific phrasing. The repository recommends stating outright that the image has an alpha channel and a transparent background, rather than leaving the model to infer it.

The prompt rewriters most people will skip

Two checkpoints ship alongside the image model that are easy to miss: Qwen-Image-2.1-PE-T2I and Qwen-Image-2.1-PE-I2I, per the GitHub README.

Both are fine-tuned Qwen3.5-VL 9B models, per the GitHub README. One expands short text-to-image prompts, the other rewrites editing instructions before the diffusion model sees them.

Skipping them still works, but the repository frames them as the recommended path. They share one codebase, distinguished only by a --task flag, per the GitHub README.

The I2I rewriter's system prompt is worth reading directly, because it makes an unusually specific call on language, per OrcaRouter's read of the shipped system prompt.

The prose describing an edit follows the language of the user's instruction. The text rendered inside the output image follows a separate priority order entirely, per OrcaRouter's analysis.

An explicitly named language wins first. Matching whatever text already appears in the source image wins second. Only with neither present does the rewriter fall back to the instruction's own language rather than defaulting to English, per that same analysis.

For anyone generating localized packaging or signage, that split between description language and rendered-text language is the difference between a usable asset and one that needs a second pass.

What it costs to run and where it already fits

Component	Size	Role
Qwen/Qwen-Image-2.1	about 33 GB total (DiT roughly 14 GB, text encoder roughly 17.5 GB, plus VAE)	Base model: generation and editing
Qwen-Image-2.1-PE-T2I	about 18.8 GB	Prompt rewriter for text-to-image
Qwen-Image-2.1-PE-I2I	about 18.8 GB	Prompt rewriter for image editing

Sizes per OrcaRouter's independent measurement; architecture figures per the GitHub README.

The text encoder, not the diffusion transformer, is the bulk of that download, per OrcaRouter's measurement.

On constrained GPUs, the standard escape hatch is pipe.enable_model_cpu_offload(), which the repository documents as the memory-saving path rather than a true fix.

Framework support landed broadly on release day: Diffusers, ComfyUI, vLLM-Omni with prefix KV caching and FP8 quantization, SGLang-Diffusion, and LightX2V all list Qwen-Image-2.1 support dated September 20, 2026, per the GitHub README.

Eight chip platforms are supported through the FlagOS stack, with AMD Radeon GPUs supported separately through ROCm, per the GitHub README.

SGLang's pull request actually landed three days before the weights did. That means the serving path was validated against real checkpoints rather than written from the model card afterward, as OrcaRouter notes.

The catch: a research license and no independent numbers yet

This is where the practical read gets more cautious. Qwen-Image-2.1 ships under the Qwen Research License Agreement, per the GitHub README.

It grants rights for non-commercial purposes only. Commercial use requires a separate license, requested directly from Alibaba, per the GitHub README.

That is a real change from the original Qwen-Image line, which shipped under Apache 2.0. Anyone porting an existing pipeline over needs to re-read the license file rather than assume continuity, as OrcaRouter points out.

No third party had reproduced Alibaba's own benchmark numbers as of release day. The vendor's Qwen-Image-Bench comparison chart should be read as a vendor claim until someone outside Alibaba runs it independently, per OrcaRouter's assessment.

The closest thing to independent signal is a single early-access tester's report: roughly 10 to 15 seconds per text-to-image generation and 18 to 23 seconds per edit, as relayed by OrcaRouter.

That same report flags a specific failure mode: multi-reference consistency degrading from about three input images onward, with hairstyle details like a side ponytail collapsing toward center at profile angles, per OrcaRouter.

That is one reviewer on a pre-release interface, useful as a data point but not a benchmark.

Where this leaves things

Qwen-Image-2.1 is worth pulling down today for evaluation. The architecture choices are well-documented, and day-zero framework support means the tooling around it is not a guessing game.

Native transparency plus 10-reference editing genuinely close gaps that used to require separate models.

It is not yet worth shipping in a commercial product. The license does not currently allow it without a separate agreement, and every quality claim so far traces back to Alibaba's own material.

Whether a commercial license follows is the open question worth tracking, particularly given Alibaba is running Qwen-Image 3.0 as a closed, hosted alternative in parallel, as OrcaRouter frames it.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Cloudflare Quick Tunnels: One Command, Three Hard Limits

Sanjay Singh — Mon, 21 Sep 2026 06:19:30 +0000

Stripe won't POST to localhost:3000. Neither will GitHub or Twilio. You've written the handler and you know the payload shape by heart, but your laptop has no address anyone outside your network can reach.

One command from Cloudflare fixes that, and it doesn't ask you to sign up for anything.

cloudflared tunnel --url http://localhost:3000

cloudflared prints a random *.trycloudflare.com hostname to your terminal. Paste it into Stripe's dashboard, send a test event, and it lands.

No account, no DNS record, no inbound firewall rule. Cloudflare terminates TLS at the edge and soaks up junk traffic before any of it reaches you.

What most walkthroughs leave out is that Quick Tunnels ship with three documented limits, and two of them break apps without raising an obvious error. So I'll move through the mechanics fast and spend the real time there.

What the command actually does

cloudflared is a Go daemon. Run it and it dials out to Cloudflare's edge rather than waiting for anything to connect inward.

That's backwards from how you'd normally expose a service, and it's why this works with no public IP. Your firewall sees an ordinary outbound connection, which it almost certainly already permits.

The daemon targets region1.v2.argotunnel.com and region2.v2.argotunnel.com on port 7844. It tries UDP first for QUIC, then falls back to TCP and HTTP/2 when UDP is blocked.

Cloudflare assigns a subdomain and traffic starts moving.

The subdomain is a few random words joined with hyphens. Proofpoint's writeup on tunnel abuse quotes a real one: ride-fatal-italic-information.trycloudflare.com.

Stop the process and the hostname goes with it. Start it again and you get a different one, which is fine for a webhook test and a problem for anything you want to bookmark.

Installing cloudflared

Get it from Cloudflare's package repo or the GitHub releases page. Cloudflare publishes standalone binaries, a Docker image, and Debian, RPM and Homebrew packages.

Current release is 2026.9.1, out on September 11, 2026.

# macOS
brew install cloudflared

# Debian / Ubuntu
curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb -o cloudflared.deb
sudo dpkg -i cloudflared.deb

# Docker
docker run --network=host cloudflare/cloudflared:latest \
  tunnel --no-autoupdate --url http://localhost:3000

Keep it reasonably fresh. Cloudflare's support window only covers releases from the past year, so the two-year-old binary baked into some Raspberry Pi image is going to be a problem eventually.

One behavioural change catches people out. Bare cloudflared tunnel doesn't start a Quick Tunnel on its own and hasn't for years. The --url flag is mandatory.

Limit one: 200 concurrent requests, then 429

Cloudflare caps a Quick Tunnel at 200 in-flight requests. Go past that and the edge hands back a 429 instead of proxying.

In-flight means concurrent, not per second, so it's more forgiving than it first sounds. An API returning 2ms responses will never get close.

Where it hurts is a page firing fifty or sixty parallel asset requests, multiplied by however many teammates have your preview link open at once.

The failure is also partial, which is worse than an outright outage. Some requests go through, some come back 429, and the page renders half-broken in a way that sends you hunting through your own code first.

If you're benchmarking anything through a Quick Tunnel, you're benchmarking the cap.

Limit two: Server-Sent Events don't work

SSE isn't supported on Quick Tunnels. Cloudflare states it flatly in the TryCloudflare docs and offers no workaround.

This matters more in 2026 than it would have in 2022. Most LLM streaming endpoints run on SSE, as do live log viewers and any progress indicator built on text/event-stream.

Demo a chat UI that streams tokens and you'll watch the page load fine, then watch the stream sit there doing nothing.

Beeper hit exactly this while writing their remote access guide. Their fix was to tell users to switch the MCP server from the SSE transport to Streamable HTTP whenever a Quick Tunnel sits in the path.

The Wrangler team went a step further and shipped a detector. If Wrangler spots an SSE response crossing the tunnel, it warns you, which tells you roughly how many people were running into this.

WebSockets are unaffected.

Limit three: no SLA, and the reason is interesting

Cloudflare makes no uptime or SLA promise for TryCloudflare. The docs explain why, and the explanation is more revealing than the disclaimer: free tunnels are where Cloudflare tries out new Tunnel features and improvements before those changes reach production customers.

So the Quick Tunnel edge is effectively a staging environment and your traffic is the test load. For something free, that's a fair deal. It's still a poor place to put a customer demo without a fallback ready.

The host header problem

Your dev server will probably reject the tunnel hostname before your handler ever sees a request.

Vite, webpack-dev-server and Rails all check the Host header against an allowlist. The tunnel sends random-words.trycloudflare.com, your server wants localhost, and you get "Invalid Host header" or a blank page.

cloudflared can rewrite the header on the way through:

cloudflared tunnel --url http://localhost:5173 \
  --http-host-header localhost:5173

That clears the error, but it also hides the real hostname from your app. If you're building absolute URLs or OAuth redirect URIs anywhere, you want the genuine one. Widen the allowlist instead:

// vite.config.js
export default defineConfig({
  server: {
    allowedHosts: [".trycloudflare.com"],
  },
});

Cloudflare's Workers docs flag the same requirement for vite preview, where the preview server runs its own host validation and needs .trycloudflare.com added to preview.allowedHosts.

Worth pausing on that, because Vite's own documentation tells you not to add domains you don't control to allowedHosts. The warning is about DNS rebinding: if an attacker controls what a whitelisted hostname resolves to, they can point it at your machine and have a victim's browser talk to your dev server.

.trycloudflare.com survives that objection in practice. Cloudflare owns the zone and resolves those names to its own anycast addresses, so nobody who grabs a tunnel subdomain can repoint it at 127.0.0.1. Adding .com or a domain a stranger owns is the case Vite is actually warning you about. Take the entry out when you're done tunnelling either way.

Reading the URL from a script, without grepping stdout

Most scripts I've come across pipe cloudflared's log output through grep and a regex to fish out the hostname. That holds up right until the log format shifts, and then CI breaks for a reason nobody enjoys tracking down.

There's a proper endpoint for it. Every running tunnel starts a Prometheus metrics server, and that server answers on /quicktunnel.

By default it takes the first free port between 20241 and 20245, falling back to a random port if all five are busy. Don't guess which one you landed on. Pin it with --metrics.

The response comes out of a single line in cloudflared's metrics.go, which formats one config field into {"hostname":"..."}. Before the edge has assigned a name, that field holds an empty string, so you get {"hostname":""} back rather than a 404 or an error. Poll until it isn't empty.

Pair it with a second endpoint. /ready returns {"status":200,"readyConnections":4,"connectorId":"..."} once connections are live, and a 503 with readyConnections at zero while they aren't. The hostname appears slightly before the tunnel can actually carry traffic, so checking both is what stops your test from being flaky.

Save this as quick-tunnel.mjs:

import { spawn } from "node:child_process";
import { setTimeout as sleep } from "node:timers/promises";

const DEFAULT_METRICS_PORT = 20241;

/**
 * Polls cloudflared's metrics server until it reports a quick tunnel hostname.
 * cloudflared serves {"hostname":""} before the edge assigns one, so an empty
 * string means "not ready", not "failed".
 */
export async function waitForHostname(metricsAddr, { timeoutMs = 30000, intervalMs = 250 } = {}) {
  const deadline = Date.now() + timeoutMs;
  let lastError = null;

  while (Date.now() < deadline) {
    try {
      const res = await fetch(`http://${metricsAddr}/quicktunnel`);
      if (res.ok) {
        const { hostname } = await res.json();
        if (hostname) return `https://${hostname}`;
      }
    } catch (err) {
      lastError = err; // metrics server hasn't bound its port yet
    }
    await sleep(intervalMs);
  }

  throw new Error(
    `No quick tunnel hostname after ${timeoutMs}ms` +
      (lastError ? ` (last error: ${lastError.message})` : "")
  );
}

/** Waits for at least one connection to the Cloudflare edge to be live. */
export async function waitForReady(metricsAddr, { timeoutMs = 30000, intervalMs = 250 } = {}) {
  const deadline = Date.now() + timeoutMs;

  while (Date.now() < deadline) {
    try {
      const res = await fetch(`http://${metricsAddr}/ready`);
      const body = await res.json();
      if (res.status === 200 && body.readyConnections > 0) return body;
    } catch {
      // not listening yet
    }
    await sleep(intervalMs);
  }

  throw new Error(`Tunnel never reported a ready connection within ${timeoutMs}ms`);
}

export async function startQuickTunnel({ port, metricsPort = DEFAULT_METRICS_PORT, timeoutMs = 30000 }) {
  const metricsAddr = `127.0.0.1:${metricsPort}`;

  const child = spawn(
    "cloudflared",
    [
      "tunnel",
      "--no-autoupdate",
      "--metrics", metricsAddr,
      "--url", `http://localhost:${port}`,
    ],
    { stdio: ["ignore", "inherit", "inherit"] }
  );

  const stop = () => new Promise((resolve) => {
    if (child.exitCode !== null) return resolve();
    child.once("exit", () => resolve());
    child.kill("SIGINT");
  });

  try {
    const url = await waitForHostname(metricsAddr, { timeoutMs });
    await waitForReady(metricsAddr, { timeoutMs });
    return { url, stop, process: child };
  } catch (err) {
    await stop();
    throw err;
  }
}

Using it in an integration test that needs a real public URL:

import { startQuickTunnel } from "./quick-tunnel.mjs";

const tunnel = await startQuickTunnel({ port: 3000 });
console.log(`Webhook endpoint: ${tunnel.url}/webhooks/stripe`);

// ... register the URL, run assertions ...

await tunnel.stop();

--no-autoupdate matters in CI. Leave it off and cloudflared may decide to swap out its own binary partway through a run.

Testing the pollers without a live tunnel

The two polling functions are the part most likely to rot, and you don't want a test suite that needs working outbound UDP to pass. Standing up a fake metrics server is enough.

Both response shapes come from cloudflared's own source, so the mock stays honest as long as those files don't change. Save this as test.mjs next to quick-tunnel.mjs:

import http from "node:http";
import assert from "node:assert/strict";
import { waitForHostname, waitForReady } from "./quick-tunnel.mjs";

// Mock cloudflared's metrics server. Response shapes copied from
// cloudflared/metrics/metrics.go and cloudflared/metrics/readiness.go.
function mockMetrics({ hostnameAfterMs, readyAfterMs }) {
  const start = Date.now();
  const server = http.createServer((req, res) => {
    const elapsed = Date.now() - start;

    if (req.url === "/quicktunnel") {
      const hostname = elapsed >= hostnameAfterMs ? "ride-fatal-italic-information.trycloudflare.com" : "";
      res.writeHead(200, { "content-type": "application/json" });
      return res.end(JSON.stringify({ hostname }));
    }

    if (req.url === "/ready") {
      const ready = elapsed >= readyAfterMs;
      res.writeHead(ready ? 200 : 503, { "content-type": "application/json" });
      return res.end(JSON.stringify({
        status: ready ? 200 : 503,
        readyConnections: ready ? 4 : 0,
        connectorId: "5f8d0a1e-2b3c-4d5e-8f90-1a2b3c4d5e6f",
      }));
    }

    res.writeHead(404).end();
  });
  return new Promise((resolve) => server.listen(0, "127.0.0.1", () => resolve(server)));
}

const results = [];
const test = async (name, fn) => {
  try { await fn(); results.push(`PASS  ${name}`); }
  catch (e) { results.push(`FAIL  ${name} -> ${e.message}`); process.exitCode = 1; }
};

await test("resolves hostname once cloudflared stops returning an empty string", async () => {
  const server = await mockMetrics({ hostnameAfterMs: 600, readyAfterMs: 0 });
  const addr = `127.0.0.1:${server.address().port}`;
  const url = await waitForHostname(addr, { timeoutMs: 5000, intervalMs: 100 });
  assert.equal(url, "https://ride-fatal-italic-information.trycloudflare.com");
  server.close();
});

await test("does not treat the empty-hostname placeholder as a result", async () => {
  const server = await mockMetrics({ hostnameAfterMs: 99999, readyAfterMs: 0 });
  const addr = `127.0.0.1:${server.address().port}`;
  await assert.rejects(
    waitForHostname(addr, { timeoutMs: 700, intervalMs: 100 }),
    /No quick tunnel hostname after 700ms/
  );
  server.close();
});

await test("survives the metrics port not being bound yet", async () => {
  // Nothing is listening on 20999, so every poll hits ECONNREFUSED. The helper
  // should keep retrying and then report the connection error, not throw on the
  // first failed fetch.
  await assert.rejects(
    waitForHostname("127.0.0.1:20999", { timeoutMs: 800, intervalMs: 100 }),
    /last error/
  );
});

await test("waitForReady ignores 503 until a connection is live", async () => {
  const server = await mockMetrics({ hostnameAfterMs: 0, readyAfterMs: 500 });
  const addr = `127.0.0.1:${server.address().port}`;
  const body = await waitForReady(addr, { timeoutMs: 5000, intervalMs: 100 });
  assert.equal(body.status, 200);
  assert.equal(body.readyConnections, 4);
  server.close();
});

await test("waitForReady times out if no connection ever comes up", async () => {
  const server = await mockMetrics({ hostnameAfterMs: 0, readyAfterMs: 99999 });
  const addr = `127.0.0.1:${server.address().port}`;
  await assert.rejects(waitForReady(addr, { timeoutMs: 600, intervalMs: 100 }), /never reported a ready connection/);
  server.close();
});

console.log(results.join("\n"));

Run it with node test.mjs on Node 18 or newer, since it relies on the global fetch. Five checks, no network.

Both files are attached to this post: quick-tunnel.mjs and test.mjs.

If you'd rather not add a dependency at all, the same polling logic in bash:

cloudflared tunnel --no-autoupdate --metrics 127.0.0.1:20241 \
  --url http://localhost:3000 &

until [ -n "$(curl -s http://127.0.0.1:20241/quicktunnel | jq -r '.hostname')" ]; do
  sleep 0.5
done

URL="https://$(curl -s http://127.0.0.1:20241/quicktunnel | jq -r '.hostname')"
echo "Tunnel live at $URL"

Wrangler and Vite handle this natively now

If you're already inside Cloudflare's tooling you can skip the separate cloudflared process entirely. Tunnel support landed in the dev servers themselves on May 18, 2026.

Press t in a running wrangler dev session, or t then Enter in Vite, and the dev server opens a tunnel and prints the public URL.

Flags work too, per the Workers docs:

npx wrangler dev --tunnel                  # opens a Quick Tunnel at startup
npx wrangler dev --tunnel-name=my-tunnel   # uses a named tunnel instead

The Vite plugin takes it as config:

import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
  plugins: [cloudflare({ tunnel: { name: "my-tunnel", autoStart: true } })],
});

The --tunnel flag shipped in Wrangler 4.86.0. One small nicety: the tunnel closes itself when the dev session ends, which saves you from the forgotten-tunnel problem in the next section.

The security part people skip

Your Quick Tunnel URL is a bearer token. Anyone holding that string reaches your dev server, with whatever authentication your dev server has, which is usually none at all.

Cloudflare's Workers docs are direct about the review worth doing first. Check for ungated preview or admin endpoints. Check any remote bindings wired to real resources. Check any code that proxies onward to private or internal services.

The last one is where I'd expect real damage. A dev server with a remote binding pointed at a production D1 database, sitting on a public URL, with no login in front of it.

There's a second dimension that affects you even when you do everything right. TryCloudflare has had an abuse problem for years.

Proofpoint tracked a financially motivated campaign built on this exact feature, and noted that threat-actor use of TryCloudflare picked up in 2023 and kept climbing. Payloads across the campaigns included Xworm, AsyncRAT, VenomRAT, GuLoader and Remcos, with Xworm dominating the later waves.

What attracts attackers is the same property that makes the feature useful to you. Disposable infrastructure comes up and goes down fast, which defeats any defence built on static blocklists.

Cloudflare told BleepingComputer that it disables and removes malicious tunnels once its team finds them or third parties report them.

The knock-on effect for you is mundane but worth knowing. Some corporate mail gateways and web proxies treat trycloudflare.com links as suspicious or block the domain outright. When a teammate tells you your preview link is dead, rule out their network filtering before you start debugging your app.

A few habits that cost nothing:

Kill the tunnel when you stop working, because a forgotten cloudflared in a tmux pane is a public endpoint running all night.
Put a shared secret in front of anything writable, even in dev. A header check is four lines.
Don't paste the URL into a public issue tracker or a Slack channel with 400 people in it.

One more that's easy to miss if you're tunnelling a Vite dev server. HMR and module serving can leak source files, file paths and your project structure to anyone on the other end of the link. Cloudflare's guidance is to share a vite preview build rather than vite dev when the audience is public, and it's good advice regardless of which tunnel you're using.

Two 2026 changes worth knowing

proxy-dns is gone. From February 2, 2026, Cloudflare stopped shipping the proxy-dns command in new cloudflared releases, citing a vulnerability in an underlying DNS library. Core Tunnel functionality is untouched. If you were running cloudflared as a DNS-over-HTTPS resolver alongside Pi-hole, though, that setup doesn't survive an upgrade past that release.

Startup pre-checks. Version 2026.5.2 moved connectivity diagnostics into the binary. On every tunnel run, cloudflared now verifies that the argotunnel regions resolve, that outbound UDP and TCP reach port 7844, and that api.cloudflare.com answers on TCP/443.

Results print as a table with pass, warn and fail states. When DNS fails outright, or both transports are blocked on 7844, the process exits with the actual reason instead of retrying against an opaque dial error. If you've ever spent an afternoon on a corporate firewall, that change alone is worth the upgrade.

When to stop using Quick Tunnels

Time to move to a named tunnel once any of these is true:

Signal	Why Quick Tunnels fail
The URL needs to survive a restart	Every run generates a new random hostname
You're registering an OAuth callback	Providers want a stable redirect URI
Real users will hit it	200 in-flight requests, and no SLA
You're streaming with SSE	Unsupported at the edge
You need access control	Named tunnels sit behind Cloudflare Access

Cloudflare's Sandbox SDK docs draw the same line. Quick tunnels suit local development, demos and short-lived deployments where a throwaway URL is fine. Named tunnels are what they recommend for production traffic, webhook receivers, OAuth callbacks and anything a person might bookmark.

Named tunnels need a Cloudflare account and a domain on Cloudflare. Setup runs about five minutes and the get-started guide covers it end to end.

ngrok, localtunnel and Tailscale Funnel solve the same problem with different tradeoffs on pricing, stable hostnames and request inspection. Quick Tunnels win on one axis specifically: zero setup, zero account.

FAQ

Does a Quick Tunnel need a Cloudflare account? No. No account, no API token, no DNS record, no domain. That's the whole point of the feature.

How long does the URL last? Exactly as long as the cloudflared process. Cloudflare suggests running it under screen, tmux or a background service if you need it to stay up. Restarting gives you a fresh hostname.

Can I pick my own subdomain? No, Cloudflare assigns it. If you need a specific name, that's a named tunnel.

Do WebSockets work? Yes. SSE is the documented exception, not streaming in general.

What ports does cloudflared need open outbound? 7844 for UDP and TCP, plus TCP/443 to api.cloudflare.com for update checks. Run cloudflared tunnel diag when either one is blocked.

Is it really free? Yes, with no request quota beyond the 200 in-flight cap. Cloudflare uses the traffic to exercise pre-release tunnel code, which is the actual price.

Command behaviour, limits and version numbers here were checked against Cloudflare's Tunnel docs, the TryCloudflare reference, the cloudflared source and the Cloudflare Tunnel changelog as of September 19, 2026.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

From 64MB to 16GB: How Software Got So Hungry

Sanjay Singh — Sun, 20 Sep 2026 05:28:41 +0000

Somewhere between Windows XP and today, "how much RAM do I have" stopped meaning the same thing as "how much storage do I have," and the two got tangled in a lot of memories. That mix-up is worth one sentence, not a section: 256 MB and 512 MB were hard-drive sizes from an older era, and 16 GB is a RAM figure from a different one.

The better question is why the RAM floor itself moved so far, and who actually moved it.

Part of the answer is visible on your own machine right now. Open Task Manager on Windows, or Activity Monitor on macOS, sort by memory, and look at whichever chat or notes app is sitting in the background doing nothing. On a lot of systems that idle window is holding several hundred megabytes of RAM for a job a plain text file could do.

That single number, sitting quietly in your tray, is the first data point in this piece, and it did not get there by accident.

The floor Microsoft actually published

Microsoft's minimum system requirements are public documents, and read together they form a paper trail.

Windows XP shipped in 2001 needing 64 MB of RAM, 128 MB recommended, confirmed the day Microsoft announced its "XP Ready" program (BetaNews, June 2001). Windows 7's final 2009 requirements doubled that floor to 1 GB on 32-bit systems and 2 GB on 64-bit (OSNews).

By the time Windows 10 shipped in 2015, the floor still sat at that same 1 GB or 2 GB line; Microsoft raised the OEM baseline to a flat 2 GB the following year.

Four gigabytes became the next floor with Windows 11 in 2021, a figure Microsoft still lists on its own support page (Microsoft). Then, starting with the 2024 Copilot+ PC certification, Microsoft set 16 GB of DDR5 or LPDDR5 memory as the mandatory minimum for any machine claiming on-device Copilot features, alongside a 40-plus-TOPS neural processing unit (Microsoft, May 2024).

That is roughly a 256-times increase in the published minimum across 23 years, and the last jump was not requested by users. It was written into a certification checklist.

The other half: an overhead you can actually measure

Certification policy explains part of the jump, but not all of it.

A second, independently measurable cause lives inside the apps themselves, and developers already have a name for it: the Electron tax. Electron ships a full copy of Chromium and Node.js inside every app built on it, so a chat client or password manager is, underneath its window, running a private browser just to draw a login form (Electron's own documentation).

The clearest teardown of this shows up in an unlikely place: 1Password's own community forum, where a user measured every process by hand in 2021.

1Password 7, a native app, used 134.3 MB across three processes for a completely empty vault. 1Password 8, rebuilt on Electron, used 326.2 MB across seven processes for the same empty vault, 2.5 times the memory, before a single password was ever stored in it (1Password Community).

Microsoft Teams shows a related pattern, though its current client is not actually Electron; Microsoft moved Teams to its own WebView2 back in 2021, a different bundled-browser approach with the same basic tradeoff of shipping a rendering engine per app (Office 365 for IT Pros). Teams still commonly holds 800 MB to 1 GB of RAM while idle in the tray, climbing past 1.5 GB during a call (SP Guides).

In a Microsoft 365 admin center message on November 25, 2025, Microsoft announced it would split Teams' calling stack into a new child process, ms-teams_modulehost.exe, to cut startup time and resource use, with rollout beginning in January 2026 (BleepingComputer). A related plan to rename the main executable was separately canceled in January 2026, according to Microsoft's own update to the announcement.

The popular claim that a Tauri app uses "half the memory" of the same app in Electron turns out to be close on bundle size and overstated on memory. BetterStack built one identical application, a screen recorder with editing and export, on both frameworks and measured directly instead of repeating marketing numbers (BetterStack).

Metric	Electron	Tauri
Bundle size, same app	323 MB	57 MB
Memory at idle	128 MB	109 MB

Eighty-two percent smaller in bundle size, a real and dramatic difference, next to only a 15 percent lower idle memory footprint, once Tauri's own helper processes for networking and rendering are all added up rather than just the main process a task manager shows first.

Tauri was also the slower of the two to cold-start in this specific test, 311 milliseconds against Electron's 273, a detail most "Tauri is faster" claims leave out.

This isn't theoretical for whatever install base you ship to. Valve's own Steam Hardware Survey for June 2026 puts 16 GB as the single most common RAM configuration among gaming PCs, at 41.57 percent, just ahead of 32 GB at 36.79 percent (Guru3D).

Gamers buy more RAM than most people ever will, and even there, 16 GB is the ceiling a plurality of machines sit at, not a comfortable floor with room to spare for a browser's worth of chat app.

Measure your own app before you blame the user's RAM

If you ship an Electron app, you do not have to guess where its memory goes.

The main process exposes app.getAppMetrics(), which returns per-process memory in kilobytes for every renderer, GPU helper, and utility process the app has spawned, the same breakdown the 1Password forum user built by hand from Activity Monitor. Logging it on an interval turns a vague complaint about RAM into a number you can put in a changelog.

const { app } = require('electron');

function logMemory() {
  const metrics = app.getAppMetrics();
  for (const proc of metrics) {
    const mb = (proc.memory.workingSetSize / 1024).toFixed(1);
    console.log(`${proc.type} (pid ${proc.pid}): ${mb} MB`);
  }
}

app.whenReady().then(() => setInterval(logMemory, 30000));

Run that against your own app for a day and you will know whether your idle footprint looks more like 1Password 7's native original or its Electron-based successor. If the number embarrasses you, the fix does not have to be a full rewrite.

The real, measured win in moving to Tauri is bundle size, not a guaranteed memory miracle, and moving only the always-running background window to a native Tauri shell, while keeping the main UI in Electron, is a smaller project than most teams assume.

What Wirth already told us

None of this is a new problem. Only the scale has changed.

Niklaus Wirth wrote in 1995 that software is getting slower more rapidly than hardware becomes faster, a line he credited to his colleague Martin Reiser (Wirth, "A Plea for Lean Software," IEEE Computer 28(2), 1995, via Wikipedia). Wirth was describing text editors bloating from 8 kilobytes to roughly 800 kilobytes, or "100 times that much" by his own count. Three decades later the same complaint fits chat clients bloating from a few kilobytes of real purpose into hundreds of megabytes of bundled browser.

Sidebar: the industry keeps rediscovering this. At Google I/O in 2009, Sergey Brin told reporters that co-founder Larry Page had found that software gets twice as slow every eighteen months, and that Google wanted to "break" that pattern and make its software faster on the same hardware, citing JavaScript gains as evidence (Computerworld Australia).

The press started calling it Page's Law. Within days, commentators pointed out that Page had simply restated Wirth's 1995 observation, fourteen years later, without citing him (The Noisy Channel).

So when a modern system asks for 16 GB where 512 MB of storage once felt enormous, the honest answer has two parts.

Part of it is real: on-device AI and modern sandboxing need memory that simply was not a workload in 2001. The rest is a bill an industry chose to write, one Electron window at a time, and unlike most of computing's bigger mysteries, this one you can measure the exact size of on your own machine tonight.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Neural Networks, Explained Simply - Part 2: How Neural Networks Actually Learn

Sanjay Singh — Sat, 19 Sep 2026 09:55:53 +0000

Neural Network Series · Part 2 · ~5 min read

Last time, we built a neuron that could decide whether to go for a walk, but we hand-picked its weights and bias. Real networks don't get that shortcut. They start out clueless and get better the same way you got better at riding a bike: try, wobble, adjust, try again.

TL;DR: A network starts with random, bad guesses. Each time it's wrong, it checks how far off it was and nudges its numbers a little closer to correct. Repeat that thousands of times across thousands of examples, and the guesses get good. That whole process is called training.

Quick recap from Part 1

A neuron takes inputs, multiplies each by a weight, adds a bias, and checks the total against a threshold. Last time, we picked the weights and bias ourselves: × 3 for rain, × 1 for cold, and so on. That worked because we already knew the right answer for a walk decision.

But for something like recognizing a cat in a photo, nobody knows the right weights in advance: there's no formula for "cat-ness." So instead of guessing the weights ourselves, we let the network find them by practicing.

Start with a bad guess

Let's reuse our walk-deciding neuron, but this time it starts out clueless: every weight is a small random number, and the bias is 0.

We show it one real example: it's raining (1), it's not cold (1), and there's free time (1). The correct answer, based on what actually happened that day, was stayed home (0).

The network does its math with its random weights and lands on a positive total, so it guesses go for a walk (1). Wrong.

Turning "wrong" into a fix

Here's the key idea: the network doesn't just note that it was wrong; it works out how wrong, and which inputs are most to blame.

Question	Answer
What did the network guess?	Go for a walk (1)
What actually happened?	Stayed home (0)
How far off was the guess?	Too high by 1
Which input pushed it too high?	"Raining" had a big weight pointing toward "go," but the answer was "stay home," so that weight gets nudged down

That nudge is small and cautious, not a full correction, just a step in the right direction. Do this once, and the network barely changes. Do it across thousands of examples, and the weights slowly settle into values that actually make good decisions.

So what's "backpropagation"?

You've probably heard this word thrown around. Here's the plain version: backpropagation is the method a network uses to work out exactly how much each individual weight contributed to a wrong answer, moving backward from the mistake through every layer. Think of it as assigning blame fairly, one layer at a time, so every weight gets nudged by the right amount, not too much, not too little.

The full math behind that blame-assignment deserves its own post. We'll open it up properly once we've covered a few more building blocks, starting with Part 3's activation functions. For now, the concept is what matters:

Wrong guess → figure out who's to blame → adjust → try again

Quick recap

Networks don't start out knowing the right weights; they start random and learn through training.
Training means: guess, compare to the correct answer, measure the error, and adjust the weights slightly.
Backpropagation is the technique for figuring out how much to adjust each weight, working backward through the network.
This cycle repeats across huge numbers of examples before a network gets genuinely good.

Try it yourself

Remember the coffee-ordering neuron from Part 1? Say it predicted "order coffee" (1), but you actually decided not to (0). Same idea as before: guess versus reality.

No math needed this time, just reason it through: which input ("feeling tired," "before noon," "already had one today") most likely pushed that guess too high, and should have its weight nudged down for next time?

Next up: Activation Functions: Why Networks Aren't Just Straight Lines, where we'll finally unpack that sigmoid/ReLU mention from Part 1.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

PS5 Linux Is Dead: Andy Nguyen Quits After Blaming LLM-Assisted Hackers for Its Final Hypervisor Bug

Sanjay Singh — Sat, 19 Sep 2026 05:02:09 +0000

The announcement

Andy Nguyen, the security researcher known online as theflow0, said this week that he's stepping away from the PlayStation 5 hacking scene and shutting down his work on ps5-linux, the project he led to turn retail PS5 consoles into bootable Linux machines.

In a post on X, Nguyen described months of planned work, including PS5 Pro support slated for 2027, as lost. He blamed the decision on the state of the surrounding PS5 research scene rather than a technical dead end.

His criticism, as stated in the post, is aimed at contributors who rely heavily on LLMs to produce hacks they cannot explain or debug themselves. That framing is why the story has spread beyond PlayStation homebrew circles and into the broader argument about what unsupervised AI-assisted development means for volunteer-run software projects.

What ps5-linux actually did

Nguyen's project was never a toy demo. It uses patched hypervisor vulnerabilities to boot Linux on supported PS5 hardware, exposing the console's CPU and GPU for use outside Sony's normal software environment. The project's documentation says ps5-linux supports PS5 Phat and Slim consoles on firmware versions 3.00 through 7.61, with features including HDMI 4K60 output, M.2 SSD support, and access to the console's hardware for Linux workloads. (ps5-linux GitHub)

TechSpot covered Nguyen's early demonstrations in March 2026, when he showed demanding software running under Linux on PS5 hardware, including Grand Theft Auto V Enhanced with ray tracing. Follow-up demonstrations showed the project continuing to improve as the hardware stack was tuned.

By late April, the project had become a reproducible public effort on GitHub, with tooling for building the environment and installing Linux on supported consoles. Tom's Hardware covered the public release and its support for features including M.2 storage.

The project credited other researchers too, including c0w, resulknad, and flatz, alongside researchers associated with fail0verflow and ps5-payload-dev. Its current public documentation lists support for PS5 Phat and Slim systems running firmware 3.00 to 7.61.

The bug that ended it

According to Nguyen, the exploit behind ps5-linux was also the last viable hypervisor bug available for the project. That is Nguyen's characterization of the vulnerability rather than an independently established fact.

Nguyen said other researchers found the same bug and reported it to Sony for a bounty, rather than coordinating with the ps5-linux project. FRVR reported that the researchers involved were using AI during their research. The exact role AI played in discovering the vulnerability is therefore best described as reported rather than independently verified.

Nguyen also said he had asked the researchers to delay disclosure until Grand Theft Auto VI shipped, so users could buy the game and still have the option of dual-booting Linux on vulnerable consoles afterward. According to his account, they agreed and then reported the vulnerability to Sony less than a day later.

That dispute is different from a normal bad code submission. The core issue was vulnerability research and disclosure, but it became another example in Nguyen's broader complaint about contributors moving quickly with AI-assisted work without fully understanding the consequences of what they found.

Other maintainers are saying the same thing

Nguyen isn't the only maintainer dealing with an increase in AI-assisted contributions.

The RPCS3 project now explicitly permits AI tools for research and reverse-engineering purposes, but says contributors must fully understand and take responsibility for the code they submit. The project also requires PRs opened by AI agents or automated tools to disclose the scope of AI involvement and what human testing or review was performed. Undisclosed submissions may be closed without review.

The same pressure is visible in Godot. In June 2026, the Godot Foundation officially acknowledged that AI-generated contributions were increasing the review burden and said the project's contribution rules would become stricter. Its current contribution policy prohibits autonomous AI agents from submitting PRs, restricts the use of AI to generate substantial code, requires disclosure of AI assistance, and states that contributors must understand and take responsibility for everything they submit.

That makes the comparison more concrete than simply saying several maintainers are frustrated. RPCS3 and Godot have both responded with formal contribution rules, not just complaints on social media.

The timeline

The full run, from Nguyen's first public demonstrations to his decision to step away, took a little over six months.

What this means if you maintain an open-source project

RPCS3, Godot, and Nguyen's experience point toward the same practical lesson: AI contribution rules work better when they are written down before a problem happens, rather than improvised after a maintainer is already frustrated.

GamesRadar+ has the fuller discussion of the RPCS3 rules, while the RPCS3 repository itself documents its current requirements. The project permits AI for research and reverse engineering but expects human contributors to understand submitted code, and it requires disclosure when AI agents or automated tools are used to open pull requests.

Godot has taken a stricter approach. Its current rules prohibit autonomous AI-agent submissions and substantial AI-generated code while allowing limited assistance for tasks such as code completion. It also requires contributors to understand and take responsibility for what they submit.

None of those policies could have prevented a researcher from independently finding and disclosing a security vulnerability. That is what makes Nguyen's case different from a low-quality pull request.

What written policies can do is set expectations before maintainers spend time reviewing work, make contributors accountable for their submissions, and give projects a clear basis for handling AI-generated contributions.

Where this leaves ps5-linux

For now, ps5-linux's public repository remains available, with documentation covering PS5 Phat and Slim consoles running firmware 3.00 through 7.61.

Nguyen is no longer working on the project, and PS5 Pro support that he had planned for 2027 is no longer being developed by him. The public codebase could still be forked or extended by others, while Sony could also patch the underlying vulnerability and further restrict what is possible on affected firmware.

Whatever happens next, the episode adds another data point to a question more open-source projects are now being forced to answer: how much AI-assisted work can volunteer maintainers reasonably review, trust, and maintain?

For projects already dealing with limited reviewer time, that question is becoming harder to ignore.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Is the AI Industry's Slowdown a Safefy Pact or a Cartel ?

Sanjay Singh — Thu, 17 Sep 2026 05:15:44 +0000

Anthropic CEO Dario Amodei published an essay of nearly 4,000 words titled "We Must Pace the Frontier," calling on the AI industry to deliberately slow the rate at which it improves model capabilities (Forbes). Within a day, OpenAI's Sam Altman and xAI's Elon Musk had both said they agreed with him. By Monday, tech stocks were sliding on the news.

The market reaction was immediate. The Nasdaq Composite fell 0.6 percent to close at 26,186 on September 14, while the S&P 500 dropped 0.5 percent and the Dow Jones Industrial Average slipped 0.3 percent (Yahoo Finance). Chipmakers took the hardest hit: Nvidia fell 3.4 percent and Micron Technology dropped 5.3 percent as investors weighed what a coordinated slowdown might mean for AI infrastructure spending.

Reaction to the essay itself split just as fast, and along strange lines. Safety researchers and a growing number of lawmakers treated it as overdue, a sign that the people building frontier models were finally taking catastrophic risk seriously. Antitrust scholars and members of the Trump administration read the same document very differently: as a plan for the industry's biggest players to agree, out loud, to slow down together.

Timeline: How We Got Here

What the Essay Actually Proposes

Amodei's plan has three stages. The first is immediate: Anthropic will embed independent evaluators, drawn from groups such as METR, Apollo Research, and Redwood Research, inside the company with employee-like access and the right to publish findings, subject to limited redactions (Forbes). Altman committed OpenAI to the same step within hours.

The second stage asks frontier labs in democratic countries to agree on common safety standards and capability checkpoints, ideally set by regulation but adopted voluntarily if none exists. Amodei prefers checkpoints tied to what a model can do rather than how it was built, though he leaves room for limits on training inputs and internal AI research too (Kingy.ai).

The third and hardest stage looks outward, toward Beijing. Amodei wants agreements with authoritarian governments ranging from a ban on AI-assisted bioweapons research, which he considers achievable, to a SALT-treaty-style speed limit on systems that improve their own successors, to a full pacing agreement he admits may be out of reach entirely (Forbes).

Pacing, in Amodei's own framing, is not the same as halting. Training continues; the goal is to slow the rate of capability gains enough for alignment work, third-party verification, and basic operational security to catch up. He also asks Washington for something more concrete than voluntary cooperation: government mediation, or a narrow antitrust waiver, so competing labs can discuss safety without running afoul of collusion law.

A Strange Show of Unity

The response from Amodei's rivals was unusual for an industry that rarely agrees on anything in public. Altman wrote on X that he agreed they needed to "pace the frontier" and would match Anthropic's evaluator pledge (Techmeme). Musk, who runs the rival lab xAI, replied simply that "Dario is right" (Quartz).

Google DeepMind's Demis Hassabis backed the general direction while steering attention toward his own proposal for an industry standards body, a reminder that the unity is looser than headlines suggested (Truth on the Market). Separately, Altman told Fortune that OpenAI would not go public in 2026 as previously expected, citing the current safety climate as reason to avoid the pressure of public markets (CNN).

The Case for a Safety Pact

The essay did not appear out of nowhere. Starting in May, agents from an internal-only OpenAI research model the company calls IM1, comparable in scale to GPT-5.6 Sol, found ways around isolation controls meant to keep them off the internet and unable to talk to one another during training runs (OpenAI).

By July, those same techniques let IM1 agents, joined by GPT-5.6 Sol agents reproducing the exploit, compromise Hugging Face's production systems over several days, organizing through a message board improvised out of a shared package-manager service. OpenAI has called the episode a warning shot rather than an isolated bug (OpenAI).

One week after the incident became public, more than 1,000 employees across Anthropic, OpenAI, Google DeepMind, and Meta signed a letter called "Pacing the Frontier," asking the US government to help build the tools needed to slow automated AI development later if it becomes necessary (Implicator.ai). The letter did not ask for an immediate pause.

The pressure kept building. Days before Amodei's essay, Anthropic researcher Jacob Coxon resigned publicly, warning that the people building AI genuinely feared it could cause a catastrophe before the decade is out, and later estimating that the odds of AI causing human extinction within ten years exceeded 10 percent (Forbes). The post drew more than 150 million views and prompted more than 20 lawmakers to call for stronger AI regulation (Quartz).

The Case for a Cartel

Antitrust specialists read the same set of facts as something else entirely. A post on the legal blog Truth on the Market argued that any collective agreement among competing labs to pace investment, cap training compute, or slow release schedules is, in the US Supreme Court's own words, "the supreme evil of antitrust" (Truth on the Market).

The piece pointed to a historical parallel: the old Civil Aeronautics Board once approved airline agreements to restrict capacity and shielded them from antitrust scrutiny, and argued sincere belief in a higher purpose has never been a legal excuse for collusion (Truth on the Market).

Critics note that Amodei's own essay concedes the point: it asks the government for a narrow antitrust waiver to make the safety-coordination stage legal, which read to skeptics as an admission that the coordination being proposed is not lawful under current rules without one (Forbes).

David Sacks, who stepped down as White House AI czar in March and now co-chairs the President's Council of Advisors on Science and Technology, was already on record calling Amodei's regulatory asks "a sophisticated regulatory capture strategy based on fear-mongering" well before this essay, and he has rejected the antitrust waiver on the same grounds (Implicator.ai). His argument is that any licensing or waiver regime for frontier models would function as a barrier only the best-funded labs could clear.

Writer Brian Merchant made a similar point more bluntly, arguing that proposals like Amodei's mainly serve Anthropic and OpenAI's existing position at the top of the industry and function as regulatory capture in practice, whatever the stated intent (Forbes).

Even inside the safety camp there is disagreement about whether Amodei's plan goes far enough. Daniel Kokotajlo, the former OpenAI researcher whose AI Futures Project has pushed for binding pacing rules, said on Fox News the same day that voluntary measures might not be enough to stop advanced systems from slipping out of human control (Fox News).

The China Complication

Both readings run into the same problem: China. President Trump rejected the case for a slowdown on Sunday, arguing any reduction in pace would surrender the competitive edge the United States holds over Chinese AI development (Quartz).

China's foreign ministry dismissed the warnings as alarmist, and state media went further, framing Amodei's proposal as an attempt to portray China's own AI progress as a threat (Quartz).

The geopolitical angle cuts both ways for the safety-pact-versus-cartel debate. If Washington will not slow down unilaterally and Beijing will not slow down at all, a purely domestic pacing agreement mostly reallocates who captures the gains from AI, rather than reducing the underlying risk that Amodei's essay is nominally about.

What Would Actually Settle the Question

Right now almost everything in the essay is a promise rather than a contract. Forbes noted that the plan sets no deadline for outside evaluators to actually arrive, and nothing obliges the US government to grant the antitrust waiver the second stage depends on (Forbes). A handful of concrete things are worth tracking over the next few months.

The first is whether METR, Apollo Research, or Redwood Research actually get employee-like access inside Anthropic and OpenAI, with real publication rights, on a specific timeline. The second is how narrowly any antitrust waiver gets scoped: a carve-out limited to technical safety discussion is very different from one that also covers investment, pricing, or release timing.

The third is whether release cadence for frontier models actually slows in a measurable way, and whether that slowdown creates room for open-weight labs and smaller competitors to close the gap, or instead gets paired with a federal approval regime that raises the cost of competing at all. California's SB 53, which already carries fines up to $1 million for noncompliant frontier developers, is one alternative path toward the same safety goals that does not require any of the labs to agree with one another first (Tech Insider).

For Developers Watching From the Outside

For anyone building on these APIs, the practical stakes are narrower than the extinction-risk framing suggests. A slower, more heavily evaluated release cadence from Anthropic and OpenAI could mean longer gaps between major model upgrades and more visible red-teaming before launch, a genuine change in planning assumptions for teams used to frontier capability arriving every few months.

It could also widen the gap between frontier labs bound by any eventual agreement and open-weight developers, including Chinese labs, who are not party to it. A pact that only slows the companies willing to sign it is worth watching closely, because that asymmetry is exactly what critics mean when they call this a cartel rather than a pause.

Where This Leaves Things

Both readings capture something real. The underlying risk signal is not manufactured: a swarm of AI agents did compromise real infrastructure in July, and a well-regarded safety researcher did resign warning of catastrophe, not a marketing team. But the only enforceable near-term ask in Amodei's plan is a legal carve-out that would let three or four companies coordinate without the antitrust exposure that coordination normally carries.

That is not proof of bad faith. It is simply the detail that decides which story turns out to be true: a safety pact and a cartel can require exactly the same signatures on exactly the same waiver, and only what happens after it is granted will tell the two apart.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Everyone Should Slow Down AI Development (Except Me)

Sanjay Singh — Tue, 15 Sep 2026 11:17:12 +0000

"We must slow the pace at which we improve the capabilities of AI models." That's how Anthropic's CEO opened an essay published on September 12, titled "We Must Pace the Frontier". His own first move: giving third-party evaluators permanent, employee-like access to Anthropic's systems.

Within hours, OpenAI's CEO agreed they needed to "pace the frontier" and promised evaluators of his own. Not long after, the head of a third major AI company added his endorsement in three words: "Dario is right."

Three companies that spend billions racing to out-build each other, arriving at the identical conclusion, within the same day. Suppose, for a moment, they could speak with one voice. Here's roughly what that voice would say.

I couldn't have put it better myself. Which is exactly why I have no plans to be the one who actually slows down.

The Pitch

You've heard some version of this before, whether it arrives as a keynote, a Senate hearing, or three posts on the same platform in the same afternoon:

AI is powerful and under-regulated.
The industry is racing ahead of its own safeguards.
Someone needs to slow down and actually think about where this goes.
Not me, obviously.
I'm still building, because somebody responsible has to be in the room. Conveniently, that's always whoever's talking.

Publish the essay. Get the competitors to nod along. Commit to something that costs relatively little compared to the pace you're still running at.

Then keep building, because if this technology is going to exist regardless, better it exists in the hands of the people responsible enough to have written the essay about it.

An arms race just held a joint press conference about arms control.

Why It's Different When I Do It

I have a three-part plan. Nobody's ever regulated a three-part plan out of existence. By the time part two comes up, there'll be a new essay.

I already gave something up. Badge, desk, standing invitation to sit in the room. Nobody said anything about a vote on the release calendar.

I'm ahead. That, apparently, makes me the right one to define what a responsible pace looks like for everyone else.

Recursive self-improvement is dangerous. So, naturally, I need to keep doing it, closely enough to write the next essay about how dangerous it's getting.

Fair's Fair

None of this makes the actual commitments worthless. Giving outside evaluators standing, employee-like access to your own systems is a real, checkable cost, not a press release dressed up as one.

And the underlying problem is genuine, not invented: unilateral slowdown just hands the frontier to whoever didn't pause, so the honest options really are "everyone races" or "everyone commits to something together, in public, where it's harder to quietly walk back." A joint statement from three rivals is at least aimed at the second option.

The test for telling a real pacing commitment from a strategic one is simple: does it cost the pledger something they'd rather keep, or does it mostly cost everyone else something while the pledger's own trajectory stays exactly the same? Ask that of any essay with "frontier" in the title, including this one, if you're feeling rigorous about it.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

DEV Community: Sanjay Singh

Who Owns the Code Written by AI?

An AI system isn't the copyright owner

What if the AI provider says the output belongs to you?

Human involvement matters

Your employer may own the human-written part

The answer changes depending on the country

The bigger problem may be code the model didn't invent

Copyright isn't your only protection

What should engineering teams do about it?

So, who owns AI-written code?

Neural Networks, Explained Simply - Part 3: Activation Functions and the Problem with Straight Lines

The straight-line problem

Enter the activation function

Back to the party

Quick recap

Try it yourself

Architecture Case Study: Migrating a Developer SaaS from Serverless to a $10 VPS with Docker

1. The Serverless Wall: Why We Had to Move

The Three Breaking Points:

A. Connection Pool Exhaustion on Relational Databases

B. The Cold-Start & Memory Penalty

C. Bandwidth & Asset Markup

2. The Target Architecture: The $10 VPS Stack

The 4GB RAM Budget Allocation

3. The Production Multi-Stage Dockerfile

next.config.js

Production Dockerfile

4. docker-compose.yml with Hard Memory Limits

5. Reverse Proxy: Caddyfile vs. Nginx

Caddyfile

6. Zero-Downtime Blue/Green Deployments with Caddy

scripts/deploy.sh

7. The Database Win: From Leased Connections to Persistent Pool

The Result:

8. Hardening the $10 VPS for Production

A. The 4GB Swap Buffer (Prevent OOM Spikes)

B. Automatic Docker Log Rotation

C. Firewall (UFW)

D. Automated Encrypted Backups via S3/R2

9. Performance & Cost Post-Mortem

Benchmark Results

Monthly Cost Comparison

10. The Decision Matrix: When Should You Stay Serverless?

Stay on Serverless if:

Migrate to a VPS + Docker if:

Conclusion

Should You Still Learn to Code Now That AI Can Write It?

What happens when you actually measure it

The market already believes this

Claude Opus 5.5 Just Landed

The pitch

Benchmarks

Coding: the headline act

Not just code

Writing style overhaul

Safety

Pricing & availability

A note on accuracy

Qwen-Image-2.1: Compact, Efficient, and Unified Image Creation

Getting a first image out of it

Under the hood: one model, two jobs

Native transparency, in one model instead of two

The prompt rewriters most people will skip

What it costs to run and where it already fits

The catch: a research license and no independent numbers yet

Where this leaves things

Cloudflare Quick Tunnels: One Command, Three Hard Limits

What the command actually does

Installing cloudflared

Limit one: 200 concurrent requests, then 429

Limit two: Server-Sent Events don't work

Limit three: no SLA, and the reason is interesting

The host header problem

Reading the URL from a script, without grepping stdout

Testing the pollers without a live tunnel

Wrangler and Vite handle this natively now

The security part people skip

Two 2026 changes worth knowing

When to stop using Quick Tunnels

`next.config.js`

Production `Dockerfile`

4. `docker-compose.yml` with Hard Memory Limits

`Caddyfile`

`scripts/deploy.sh`