DEV Community

UTM conventions that stop your analytics turning to mush

Michael Yousrie — Fri, 31 Jul 2026 10:42:05 +0000

Most broken analytics I have seen were not broken by a bug. They were broken by three people tagging links slightly differently for six months.

UTM parameters have no schema. Nothing validates them. Your analytics tool takes whatever string you put in utm_source and treats it as gospel, which means the discipline has to live in you, not the tool. Here is a convention that takes ten minutes to adopt and saves you from a report you cannot trust.

The five parameters, and what each is actually for

utm_source: where the click came from. A single named place: newsletter, instagram, partner-acme.
utm_medium: what kind of channel it is: email, social, cpc, qr, referral.
utm_campaign: which initiative it belongs to: spring-launch, black-friday-2026.
utm_content: which specific link, when one page has several: header-cta, footer-link.
utm_term: paid keyword. Mostly vestigial unless you are running search ads.

The distinction people get wrong is source versus medium. Source is the place, medium is the type. Instagram is a source; social is a medium. Your newsletter is a source; email is a medium. If you find yourself putting instagram in medium, the whole report will fragment later.

Rule 1: lowercase everything, always

This is the single highest-value rule, so it goes first.

utm_source=Instagram
utm_source=instagram
utm_source=INSTAGRAM

Most analytics tools treat those as three different sources. You will not notice for a month. Then you will open a report, see Instagram split across three rows, and have no clean way to merge history.

Lowercase everything. No exceptions, no judgment calls.

Rule 2: hyphens, never spaces or underscores

A space becomes %20 and looks broken in reports. Underscores are fine technically but mixing them with hyphens gives you the same fragmentation problem as casing.

❌ utm_campaign=Spring Launch
❌ utm_campaign=spring_launch
✅ utm_campaign=spring-launch

Pick hyphens. Write it down. Done.

Rule 3: date your campaigns

utm_campaign=black-friday seems fine until it is your third Black Friday and every year is stacked into one row.

✅ utm_campaign=black-friday-2026
✅ utm_campaign=2026-03-product-launch

Year-first works well if you want campaigns to sort chronologically.

Rule 4: never tag internal links

This is the one that silently corrupts data.

If you tag a link from your own homepage to your own pricing page, most analytics tools start a new session at that click and overwrite the original referrer. The visitor came from a newsletter, clicked one internal link, and is now attributed to your own site.

UTMs are for traffic arriving from outside. Internal navigation is what your normal page-path reporting is for.

Rule 5: keep a canonical list

Not a spreadsheet nobody opens. A short list in whatever doc your team actually reads:

sources:  newsletter, instagram, tiktok, linkedin, youtube, partner-<name>
mediums:  email, social, cpc, qr, referral, print
campaign: <yyyy>-<mm>-<short-name>
content:  header-cta, inline-link, footer-link, bio-link

The rule is: if it is not on the list, it does not get used until it is added to the list. That single sentence is what prevents drift, because the failure mode is never one bad decision, it is fifty small ones.

Rule 6: think about what the user sees

A URL like this in an Instagram bio is ugly, and it leaks your internal campaign naming to anyone who looks:

https://example.com/pricing?utm_source=instagram&utm_medium=social&utm_campaign=2026-03-launch&utm_content=bio-link

This is where a short link earns its place. The tagged URL becomes the destination, and the thing you publish stays clean. You keep the attribution and the reader gets a link that fits.

It also means the tagging lives in one editable place. Get a UTM wrong on a printed QR code and you are reprinting; get it wrong behind a short link and you fix the destination.

Rule 7: QR codes need `utm_medium=qr`

Scans from print are not "direct" traffic, but that is where they land if you do not tag them. Tag the URL behind the code, and if the same campaign runs on a poster and a flyer, separate them with utm_content:

utm_source=poster&utm_medium=qr&utm_campaign=2026-03-launch&utm_content=cafe-window

Now "did the flyers do anything" is a question with an answer.

A worked example

Spring launch, promoted through the newsletter, Instagram bio, and a printed flyer:

# newsletter, main button
?utm_source=newsletter&utm_medium=email&utm_campaign=2026-03-spring-launch&utm_content=header-cta

# instagram bio link
?utm_source=instagram&utm_medium=social&utm_campaign=2026-03-spring-launch&utm_content=bio-link

# flyer QR code
?utm_source=flyer&utm_medium=qr&utm_campaign=2026-03-spring-launch&utm_content=cafe-window

Same campaign across all three, so they roll up. Different sources and mediums, so they break down. That is the whole point.

The check that catches drift

Once a month, list your distinct utm_source values. If you see instagram and Instagram, or ig and insta, drift has started. Fix the convention now, because merging historical rows is unpleasant and sometimes impossible.

I build Swyfty, a short-link and analytics tool, which is why I have opinions about this. But none of the above needs my product or any product. It needs a list of allowed values and the discipline to stick to it.

The tooling is never what makes attribution work. Consistency is. A boring convention applied every time beats a sophisticated analytics stack fed inconsistent strings, every single time.

The Human Is Not the Bottleneck. The Human Is the Missing Oracle

Dane Balia — Fri, 31 Jul 2026 10:39:30 +0000

We spent a year optimising the wrong bottleneck.

The harness discourse has been relentless - blueprints, schematics, thought leadership. Impressive engineering, most of it. But read the designs closely and you notice what they're all quietly aiming at: getting the developer out of the pipeline.

The logic seemed sound. Building dropped from days to minutes, and the human became the slow part. The bottleneck. So we designed the human out.

Then the telemetry arrived.

Faros AI instrumented 22,000 developers across 4,000+ teams. Moving from low to high AI adoption: task completion per developer up 34%, epics up 66%. Real gains. Also: bugs per developer up 54%, incidents per pull request up 243%, median review time up 5x, and 31% more PRs merging with no review at all.

Nobody decided to stop reviewing. Reviewers simply couldn't keep pace, and unread merges became normal. We knew this failure before AI. The 2,000-line PR lands in your inbox, and what follows is frustration, cognitive overload, and a silent rubber stamp. The difference is that it used to be the exception. Now it's the throughput model.

The bottleneck didn't disappear. It moved to review and integration - and we'd already removed the person who was supposed to be standing there when it arrived.

Two things worth saying plainly.

First: the human was never the bottleneck. The human is the missing oracle.

We have fast, cheap oracles for correctness. Do the tests pass? Does it lint? Machine-verifiable in seconds. We have no oracle at all for maintainability, intent, or design - and no benchmark I'm aware of currently measures them. GitClear's analysis of 623 million code changes shows what fills that gap: duplication up 81%, refactoring down 70%, error-masking constructs up 47%. Code that looks right and is structurally wrong.

Designing the human out doesn't remove a cost. It removes the only sensor we have for the slowest and most expensive failure mode. "Humans first" isn't sentiment or ethics-washing. It's a claim about where verification capability actually resides right now.

Second: we're borrowing against comprehension and calling it velocity.

Anthropic ran a controlled trial in January. Two groups, same unfamiliar library. The AI-assisted group finished marginally faster and scored 50% on comprehension. The manual group scored 67%. Seventeen points, on code they had written minutes earlier (this is a vendor publishing a result against it's own commercial interest).

That debt doesn't show up in your DORA metrics. It shows up at 2am when nobody on the call can reason about the system they shipped.

The industry response is to build faster agents. So I built the opposite experiment. A harness that puts the human at the centre - not to slow things down, but to make judgment cheap, timely and measurable rather than optional. You can check out the harness here.

Plain bash. Deliberately crude. Built to learn, not to scale.

The rules:

Agents don't move artefacts through the SDLC. They hit mechanical gates.
Humans state intent, write the spec, define acceptance criteria, and read the diff.
Route every check to the cheapest reliable verifier - mechanical gates for what's machine-checkable, calibrated LLM judges only after validation against human labels with explicit thresholds, humans for intent and design.
Diff budget: 200 lines. (Which became 400, excluding tests). If it's more than 400 lines, the feature was scoped wrong. The gate fails and the work gets split.
Only iterate on the harness with confirmed evidence and root cause.

Thirty minutes on an approved spec and a design sketch turns a six-hour adversarial review into a twenty-minute confirmation. The human isn't reviewing more. They're reviewing earlier, where a one-line correction prevents two thousand lines of rework.

237 minutes. 12 features. One engineer, no control group - an experiment, not evidence. I'm publishing the method so it can be argued with.

DORA's finding is that AI is an amplifier: it magnifies whatever your organisation already is. If your answer to a 243% rise in incidents per PR is to remove the last human who might have caught them, the amplifier is working exactly as designed.

What are you actually measuring?

UI/UX Design in 2026: Why Great Products Feel Invisible

Tech Tales — Fri, 31 Jul 2026 10:38:52 +0000

UI/UX Design in 2026: Why Great Products Feel Invisible

When people think about UI/UX design, they often imagine beautiful colors, modern layouts, and smooth animations.

But in 2026, great design isn't measured by how impressive it looks.

It's measured by how little users have to think.

The best digital products today don't force users to learn complicated interfaces. They guide users naturally, helping them accomplish tasks quickly and confidently.

That's why UI/UX has become one of the most important aspects of building successful web and mobile applications.

Good Design Solves Problems

Imagine opening a food delivery app.

You don't want to spend five minutes figuring out where the search bar is or how to place an order.

You simply want food.

That's the goal of good UX.

Users visit applications to complete tasks—not to admire the interface.

Whether it's:

Shopping online
Booking appointments
Applying for jobs
Managing business operations

the experience should feel effortless.

If users have to think too much, the design has already failed.

AI Is Changing User Experience

Artificial Intelligence is no longer just a backend feature.

It's becoming part of the user experience itself.

Modern applications now offer:

Smart search suggestions
Personalized recommendations
AI chat assistants
Predictive text
Automated workflows
Personalized dashboards

Instead of forcing users to search for everything manually, applications increasingly anticipate what users need next.

Good UX in 2026 isn't about adding more features.

It's about reducing unnecessary effort.

Simplicity Never Goes Out of Style

One misconception about UI design is that "minimal" means "basic."

Actually, designing simple interfaces is one of the hardest challenges.

Every unnecessary button...

Every distracting animation...

Every confusing menu...

adds friction.

The best interfaces focus only on what's important.

Think about products like Google Search or Notion.

Their interfaces aren't overloaded with visual effects.

Instead, they prioritize:

Clear typography
Logical spacing
Consistent layouts
Obvious navigation
Purposeful interactions

Simple interfaces help users move faster.

Accessibility Is No Longer Optional

Accessibility isn't just about compliance.

It's about making products usable for everyone.

Good accessibility includes:

High color contrast
Readable typography
Keyboard navigation
Screen reader support
Alternative text for images
Large touch targets

Interestingly, these improvements don't only help users with disabilities.

They improve the experience for everyone.

That's why accessibility has become a core design principle rather than a feature.

Trust Has Become Part of UX

Today's users care about privacy.

They want to know:

Why an application requests permissions
How their data is stored
What information is collected
Whether their account is secure

Designers now focus on creating interfaces that build confidence through:

Transparent privacy settings
Secure authentication flows
Clear confirmation messages
Honest error handling
Predictable user interactions

A beautiful interface may attract users.

A trustworthy experience keeps them.

Designing Beyond One Screen

People don't use a single device anymore.

A user might:

Discover your product on a phone
Continue browsing on a tablet
Complete the purchase on a laptop

That's why responsive design has evolved beyond simply resizing layouts.

Modern UI/UX means creating experiences that feel natural across every screen size while maintaining consistency.

Users shouldn't have to relearn your interface every time they switch devices.

Why Businesses Care About UX

Good UI/UX isn't just good for users.

It's good for business.

Better experiences often lead to:

Higher customer satisfaction
Better engagement
Increased conversions
Lower bounce rates
Improved retention
Fewer support requests

Investing in design often saves far more money than fixing usability issues after launch.

A Few UI/UX Principles That Never Fail

No matter how design trends change, these principles remain timeless:

Design for people, not trends.
Keep interfaces simple.
Remove unnecessary steps.
Make navigation predictable.
Test with real users.
Prioritize accessibility.
Build trust through transparency.
Optimize for performance.
Be consistent across every screen.

Technology changes.

Human behavior doesn't change nearly as fast.

Final Thoughts

Every year introduces new tools, AI capabilities, design systems, and visual trends.

But the goal of UI/UX remains exactly the same:

Help users accomplish their goals with as little effort as possible.

Users rarely remember the color of a button.

They remember how easy—or frustrating—it was to use your product.

The best interfaces aren't the ones with the most animations.

They're the ones users don't have to think about.

Benchmark an AI Coding Task Across Mobile Backgrounding, Network Switches, and Battery Pressure

Roronoa — Fri, 31 Jul 2026 10:37:48 +0000

Most AI coding assistants are demoed on a desk: laptop plugged in, stable Wi-Fi, full attention. But the moment I approve or monitor a long-running AI task from a phone, the environment becomes hostile — the app gets backgrounded, the device hops from Wi-Fi to LTE, iOS starts throttling background execution, and the battery drops below 20%.

This article is a reproducible benchmark method for one question: does an AI coding task survive the mobile lifecycle, and can you tell the difference between 'recovered', 'restarted', and 'silently dropped'?

Test environment (record yours)

Device: iPhone 14, iOS 17.x (note your exact build)
App state: task started from the foreground, screen unlocked
Network: controlled Wi-Fi with the option to toggle airplane mode, plus LTE fallback
Power: start at ~60% battery, charger off; repeat one run in Low Power Mode
Backend: a remote AI coding agent endpoint. For these runs I used MonkeyCode, which offers free model access and a free server option — convenient for this kind of throwaway benchmark because I didn't have to provision my own GPU box or burn a paid quota on test traffic.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Any agent backend with a task ID you can poll works for this method; the benchmark is about the lifecycle, not the vendor.

The one metric that matters

For each run, classify the final state:

Outcome	Definition
Recovered	Same task ID, output continues from where the connection dropped
Restarted	New task ID or duplicate execution; original work discarded or redone
Silent loss	UI shows 'running' or a spinner, but the backend has no live task

Silent loss is the dangerous one. It looks like progress.

The benchmark script (client side)

The client just needs to launch a task, poll by ID, and log transitions with timestamps. Pseudocode you can adapt to React Native, Flutter, or a plain fetch loop:

// lifecycle-bench.mjs — run in your app's debug console or a Node harness
const log = [];
const stamp = (event, extra = {}) =>
  log.push({ t: Date.now(), event, ...extra });

async function launchTask(prompt) {
  const res = await fetch(`${BACKEND}/tasks`, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ prompt }),
  });
  const { taskId } = await res.json();
  stamp("launched", { taskId });
  return taskId;
}

async function poll(taskId) {
  let lastStatus = null;
  for (;;) {
    try {
      const res = await fetch(`${BACKEND}/tasks/${taskId}`);
      const task = await res.json();
      if (task.status !== lastStatus) {
        stamp("status", { status: task.status, progress: task.progress });
        lastStatus = task.status;
      }
      if (["done", "failed"].includes(task.status)) return task;
    } catch (e) {
      stamp("poll_error", { error: String(e) });
    }
    await new Promise((r) => setTimeout(r, 2000));
  }
}

// On app foregrounding, run: poll(savedTaskId)
// Then diff the log against the backend's task history.

After each run, compare the client log with server-side task history. If the client saw poll_error for 4 minutes and the server shows the task still executing, that's a recovered run. If the server shows the task was killed at the disconnect, your UI lied — classify accordingly.

The transition matrix

Run the same prompt (a medium-length task, e.g. 'refactor this module and run the tests') under each condition. One variable per run:

Baseline — foreground, Wi-Fi, charger on. Establishes expected duration.
Background at T+30s — press home, wait 5 minutes, return. Does polling resume? Does the task still exist?
Wi-Fi → LTE handoff mid-task — toggle Wi-Fi off while a poll is in flight. Watch for duplicated requests on reconnect.
Airplane mode 3 minutes — full offline window. On restore, does the client re-attach to the task ID, or submit a new one?
Low Power Mode + background — iOS aggressively defers network activity. Expect longer gaps; check whether the agent times out server-side.
App kill (swipe away) — the harsh case. On relaunch, can you recover the task ID from local storage and re-attach?

Expected observations from my runs: conditions 2–4 are survivable when the client persists the task ID and the backend treats tasks as resumable by ID. Condition 5 is where I've seen silent loss most often — the backend's idle timeout fires while iOS defers the client's keepalive. Condition 6 fails entirely if the task ID only lives in memory.

What to fix when a run fails

Restarted instead of recovered: persist taskId (Keychain/Keystore, not just AsyncStorage if it's sensitive) and re-attach on launch before offering a 'start new task' button.
Silent loss: add a heartbeat with a server-visible lastSeenAt. If server lastSeenAt is stale but UI shows 'running', surface 'connection lost — task status unknown' instead of a spinner.
Duplicate execution after reconnect: make task creation idempotent (client-generated idempotency key), so a retried POST can't fork the run.

Limitations

Single device, single OS version. Android's background execution model (Doze, OEM battery killers) behaves differently — repeat the matrix there before generalizing.
I tested task continuity, not output quality or model latency; those need their own benchmarks with device data.
Free tiers change. The free model access and free server I used here are availability facts as of this writing, not a guarantee of quotas, duration, or performance — verify before building a workflow around them.
Results depend heavily on backend timeout policy; your agent service may behave differently under the same client conditions.

Who shouldn't use this approach

If your tasks are sub-second, this whole matrix is overkill — just retry. And if the task handles sensitive code or credentials on a device you don't control, a free hosted server is the wrong target entirely; test continuity against infrastructure you're authorized to use.

If you run this matrix on your own setup, I'd like to compare notes: device, OS version, which transition you triggered, and whether the task recovered, restarted, or silently disappeared. That last one is the number nobody's dashboard shows.

Why I built a zero-upload, local-first browser video compressor (and why you should stop uploading your MP4s to remote servers)

GG LL — Fri, 31 Jul 2026 10:37:29 +0000

As content creators, video editors, and developers, we compress files almost every single day.

Whether you're exporting a 4K draft for a client, trying to squeeze a gaming clip under Discord’s 10MB limit, or preparing a vertical video for TikTok, file size is a constant hurdle.

But the way we compress videos online today is fundamentally broken. Here is why, and how a shift to "local-first" web tools can solve it.

The Hidden Costs of Cloud Video Compressors
When you search for "compress video online" on Google, you are met with dozens of websites that look free but share the same architecture: you drag your file, upload it to their remote cloud servers, wait for their servers to re-encode it, and download it back.

This architecture introduces three massive pain points:

The Upload Bandwidth Bottle-neck: If you are traveling, working on public Wi-Fi, or have slow upload speeds, uploading a 500MB video to a server can take 15 to 30 minutes. If the connection drops, you start over.
The Privacy Nightmare: You are uploading private camera rolls, client drafts, or raw sensitive footage to a stranger’s remote server. You have no control over where that video is stored or who has access to it.
Gated Paywalls: Because cloud bandwidth and server-side CPU encoding are extremely expensive, these sites must lock basic features behind
9
–
9–15/month subscriptions. They limit your file size to 500MB on free tiers or slap ugly watermarks on your exports.
The Solution: WebAssembly & Local-First Web Tools
I was frustrated by these limitations, so I decided to build a local-first web-based video compressor: CreatorZip.

Instead of renting expensive cloud servers to compress your files, CreatorZip leverages modern browser capabilities. It runs FFmpeg entirely inside your web browser using WebAssembly (WASM).

This architectural shift changes everything:

100% Privacy: The video compression happens entirely on your local machine. Your original footage never leaves your computer, and it never uploads to a remote server. You get the security of offline software with the convenience of an online tool.
Instant Processing: Because there is no upload phase, processing starts immediately. It utilizes your local CPU/GPU hardware acceleration, saving you gigabytes of bandwidth.
Zero Infrastructure Cost = Free for You: Because I don’t have to pay for expensive cloud encoding servers, CreatorZip has virtually zero operating cost. During our open launch phase, it is 100% free, has no ads, no watermarks, and supports files up to 1GB with batch queue processing.
Pro-Tip: How to Defeat Discord's Blurry Auto-Compression
If you share video clips on Discord, you've likely noticed that uploading raw files often results in a pixelated, blocky mess.

This is because Discord uses high-speed, server-side auto-compressors optimized for speed rather than visual fidelity. If your video is over their free upload limit (10MB), they will forcefully crush the bitrate.

The workaround: Compress your video manually to just under 10MB (e.g., 9.8MB) before you upload. Since the file is already within the limit, Discord will accept it as-is without applying their aggressive compression.

CreatorZip has built-in presets for Discord 10MB/50MB, TikTok Smart, and High-Quality Lossless to automate this without you needing to do manual bitrate math.

Try it out & Share your feedback
CreatorZip is an indie project built to make creator workflows faster and safer. If you're tired of upload bars and subscription gates, give it a try:

👉 creatorzip.app

I'd love to hear your thoughts, feedback, and feature requests. What should I build next?

100 Days of Solana is a wrap!

Matthew Revell — Fri, 31 Jul 2026 10:33:05 +0000

Over the past 100 days, we’ve gone from the basics of wallets and transactions to deploying programs on Solana devnet.

Some people completed every challenge. Others joined for a week, an arc, or whenever time allowed. However you took part, congratulations! You learned something new and built on Solana.

And if you missed the live run, you haven’t missed your chance. All 100 challenges are still available, and you can start from Day 1 whenever suits you.

What is 100 Days of Solana?

You may be curious about blockchain development but find that many tutorials assume you already understand the terminology, use cases, and other fundamentals.

100 Days of Solana was designed to provide a clearer route in: from “I’m a web or mobile developer and this looks interesting” to “I can build and deploy something real on Solana.”

Here’s how it works:

100 daily challenges
Most challenges introduce one focused idea in around 10 to 20 minutes.
Each week has a theme that introduces and reinforces a new concept.
It’s free to take part.

And the whole thing is designed so that you can still make progress if you complete just a couple or every challenge from a week.

What we covered

If you start at Day 1, here’s how the journey unfolds.

First: learn to speak Solana

Create a wallet — a cryptographic keypair that acts as your identity — and send your first transactions
Read live data directly from the network
Get to grips with Solana’s account model

Next: create digital assets

Create your own tokens and NFTs, which are built from accounts with clearly defined roles and rules
Configure features such as transfer fees, interest, and transfer restrictions
See how your Solana program enforces those rules on every transfer

Then: write your own programs

Learn the basics of Solana programs
Learn enough Rust to build with Anchor, a framework that provides some of the structure Rails or Express brings to Web2 development
Design state with program-derived addresses, or PDAs: predictable addresses calculated from known values
Call other programs in much the same way that one service calls another service’s API

After that: think like an attacker

Treat every input as hostile, because anyone on a public network can send instructions to your program
Audit your code and write tests that actively try to break it
Use property testing and fuzzing to find edge cases you might never write by hand
Reproduce a real Solana exploit, understand why it worked, and then fix the vulnerability

Finally: ship what you built

Deploy to devnet, Solana’s free staging environment
Publish your program’s interface, roughly the on-chain equivalent of an OpenAPI schema
Build a frontend that connects to a user’s wallet and asks them to approve transactions while their private keys remain under their control
Give an AI agent tightly limited access to a wallet through a deny-by-default policy layer
Bring everything together in a capstone project of your own

By Day 100, you’ll have gone from creating your first wallet to deploying your own program, with an understanding of the major layers in between.

Shout-outs

One of the best things about 100 Days of Solana was the community that formed around it.

People published hundreds of posts here on DEV, while the event Discord became a place to compare approaches, untangle tooling problems, review code, and celebrate first deployments.

If you’re starting the challenges now, those posts are a valuable companion along the way. Whatever error you’re staring at, there’s a good chance someone has already encountered it and written about what they learned.

Thank you to everyone who wrote, demoed, answered a question, or reviewed someone else’s code. You made 100 Days of Solana far better than the challenges could have been on their own.

And a special thank you to Vincent Jande, a graduate of MLH’s Solana Fellows program, who helped reivew and create content throughout the 100 days.

Continue your journey

Whether you’ve just shipped your first Solana project at the end of the 100 days or you’re about to begin day 1, there are several ways to keep going:

Solana Developer Bootcamp — a free, project-based video course from the Solana team for developers who want to go deeper
Global Hack Week — MLH’s free monthly online hackathon, where you can use your Solana skills in a new project
MLH events — find an in-person or digital hackathon and build alongside other developers

The scheduled 100 days may be over but there's always more to explore.

Happy hacking!

How AI Is Transforming Software Development Workflows in 2026

Kai X Intelligence — Fri, 31 Jul 2026 10:31:08 +0000

How AI Is Transforming Software Development Workflows in 2026

By 2026, the question is no longer whether AI is useful in software development, but how deeply it has been woven into the everyday fabric of engineering. We've moved past the era of simple suggestion widgets and autocomplete. The modern developer workspace is a human–AI hybrid environment where autonomous agents handle entire subtasks, review code with sophisticated reasoning, and even manage infrastructure—leaving humans to focus on architecting solutions and making product-level decisions.

This article explores the key ways AI is reshaping software development workflows in 2026, from pair programming to production monitoring, and what that means for developers, teams, and the entire delivery pipeline.

The Shift from Copilots to Autonomous Agents

In 2024, AI assistants were largely reactive: you wrote a function, and the tool suggested the next line. By 2026, the paradigm has shifted to proactive autonomous agents. These agents are context-aware, connected to your repository, issue tracker, and CI system. They don't wait for a prompt—they analyze your branch, understand the epic you're working on, and start implementing subtasks on their own.

For example, a typical workflow might look like this:

A developer creates a branch for a new feature.
An AI agent reads the linked Jira or Linear ticket and scans related code.
The agent generates a first draft of the implementation, including unit tests and refactoring notes.
The developer reviews the code, makes adjustments, and approves.
The agent then documents the changes, updates any relevant API schemas, and opens a pull request.

This doesn't replace the developer—it removes the "grunt work" that often consumes 60% of a day. In 2026, developers treat agents like junior teammates: they delegate tasks, review outputs, and provide concise, high-level feedback.

A Simple Agent Interaction Example

Let's say you're working on a Python service. Instead of searching for a library or skimming Stack Overflow, you can just describe the intent in an inline comment:

# AI-TASK: Add retry logic with exponential backoff to the fetch_product_data function.
# Context: We use httpx, and the external API is flaky. Use a max of 5 retries,
# with jitter, and log warnings when a retry occurs.

def fetch_product_data(product_id: int) -> dict:
    ...

The AI agent in your IDE reads the comment, understands the existing function signature and project conventions, and fills in the implementation. You see a diff you can accept or tweak. This kind of "spec-driven" development has become a standard practice, cutting boilerplate implementation time by an order of magnitude.

AI-Native CI/CD Pipelines

Continuous integration and deployment have always been about automation, but AI is now making pipelines self-healing and adaptive. In 2026, an AI-powered CI system doesn't just run tests—it learns from the entire history of the project to predict failures before they occur.

For instance, a pipeline can:

Identify risky code paths based on change patterns and historical bug data.
Automatically expand or reduce test suites according to risk assessment.
Diagnose failing tests and suggest fixes, often applying a patch directly to the branch.
Roll back or escalate deployments based on runtime signal analysis.

Consider this example of an AI-infused GitHub Actions workflow (conceptually simplified for 2026):

name: AI-Guided CI
on: pull_request

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run AI risk analysis
        uses: ai-risk-analyzer@v2
        with:
          openai_model: 'gpt-heuristic-2026'
          auto_fix: true
          max_attempts: 3
      - name: Run targeted tests
        run: make test

Behind the scenes, the AI engine classifies the PR, estimates the probability of regression, and may even generate new test cases for the changed logic. If a test fails, the agent inspects the stack trace and proposes a fix—not by guessing, but by cross-referencing the project's history and known issue patterns.

This reduces the classic "test failure feedback loop" from hours to minutes. Developers get a failing test with a suggested patch, and if they trust the suggestion, they click "apply." If not, the agent keeps iterating while the developer moves on to other work.

Automated Code Review at a Higher Level

Pull request reviews have always been a bottleneck. In 2026, AI reviewers are ubiquitous, but they're far smarter than the "linter with opinions" of the past. These systems now perform semantic analysis, understand the business intent behind the change, and flag issues that human reviewers might miss—such as security vulnerabilities, performance regressions, or architectural violength.

An AI code reviewer in 2026 does more than comment on syntax:

It evaluates whether the implementation matches the function's spec and comments.
It checks for side effects, race conditions, and edge cases.
It compares the change against similar patterns in other codebases.
It enforces team-specific style guides by reasoning, not regex.

What About Human Review?

Humans are still in the loop, but their role is elevated. Instead of reading every line, human reviewers focus on the AI's summary of the change and the highest-risk areas it has flagged. In many teams, the human reviewer is now seen as the final validator of intent, not the detector of typos.

A typical review comment from an AI might be:

"This caching strategy holds a lock while performing I/O, which could degrade throughput at scale. In similar services, we've used an optimistic lock. Want me to refactor it?"

That's not just a style comment—it's an architectural suggestion, backed by project-specific data.

Self-Writing and Self-Healing Tests

The most notable change in developer workflow is how tests are created and maintained. In 2025, test generation was an add-on. By 2026, it's standard. AI agents write tests at the same time they write production code, and they also update existing tests when requirements change.

This has profound effects:

Test coverage on critical modules is near 100% because agents ensure it.
Error messages from failed tests are now enriched with hypotheses of what caused the failure.
Flaky tests are automatically quarantined and, where possible, fixed.

In practice, a developer rarely sees a failing test and has to dig through logs manually. Instead, the AI presents a concise diagnosis:

Test `test_checkout_with_expired_coupon` failed because the coupon validation
method was called before the session token was verified. The ordering was
changed in commit a1b2c3. Suggested patch: move the validation call after the
session check. Run with --ai-fix to apply.

This level of automation transforms debugging from a detective hunt into a review-and-approve activity.

Documentation and Knowledge Management

Nobody likes writing docs, but AI in 2026 makes it painless. During development, agents continuously update the README, API references, and internal wikis. They capture not only what the code does, but the context of why certain decisions were made.

When you open a project, an AI-generated summary greets you:

This repository contains the checkout microservice. Last updated 2 hours ago by agent-5. It handles payments, invoicing, and refunds. The current branch introduces a new idempotency layer to support retries.

Imagine the onboarding time saved. A new developer can go from reading docs to contributing in half a day instead of two weeks.

The Shift in Team Dynamics and Roles

With AI handling repetitive implementation, debugging, and testing, the developer's role is shifting toward:

System design and architecture
AI-agent orchestration
Code review and quality enforcement
Product and stakeholder communication
Handling ambiguous, novel problems that require genuine creativity

Engineering managers now measure output differently. It's not about how many lines of code you wrote; it's about how effectively you direct the AI agents and validate their work. This is often called "prompt engineering" or "agent wiring," but it's really just higher-level software engineering.

The New "Tech Stack"

In 2026, the modern software stack includes not just languages and frameworks, but a layer of AI tooling:

Agent orchestration: Tools like LangChain, AutoGen, or in-house agent workflows.
Model gateways: Centralized access to LLMs, with prompt caching and safety guardrails.
Integration APIs: Connecting agents to GitHub, Jira, Slack, and your cloud provider.
Human review tools: UIs for reviewing AI-generated diffs, tests, and infra changes.

These are the foundational components of a contemporary engineering workflow.

Addressing the Challenges

It's not all perfect. In 2026, teams have learned to handle several challenges:

Over-reliance: Blindly accepting AI patches can introduce subtle bugs or security issues. Strong governance and human review remain essential.
Prompt injections: Malicious instructions in code comments or external packages can trick agents. Sandboxing and validation are now part of security practice.
Model confusion: AI sometimes hallucinates APIs or library names. Having deterministic tools and unit tests that verify the output is critical.
Maintaining data privacy: Sensitive codebases often require on-premise AI models or private cloud instances, which adds complexity.

Teams that successfully adopted AI in 2026 treat it as a useful but fallible teammate—not an oracle.

Real-World Impact: Case Studies

A large e-commerce company reported that their feature lead time dropped from 14 days to 3 days, mostly due to AI agents handling feature branches and regression testing. Another company specializing in SaaS analytics saw a 70% reduction in flaky tests after deploying an AI test-maintenance agent.

On the infrastructure side, AI is now deeply involved in defining Kubernetes manifests, Terraform plans, and CI/CD configuration. Instead of manually writing YAML files, developers describe the desired state, and an AI agent generates the configuration, applying best practices based on cloud provider recipes. This has reduced misconfiguration incidents by roughly 45%, as the agent can cross-check against live cloud service constraints.

The Future Is Already Here

By 2026, AI isn't just a feature that assists developers; it has become a core layer in the development platform itself. The workflows of tomorrow are not about humans competing with machines to type code fast, but humans collaborating with AI agents to build software that is more reliable, more maintainable, and delivered at a pace we previously thought impossible.

If there is one takeaway, it's this: the developer who thrives in 2026 is the one who learns not just how to code, but how to direct, verify, and improve AI agents. The code is still being written—just with a radically different, deeply collaborative process.

Conclusion

AI has transformed software development workflows from a solo human endeavor into a partnership between human creativity and machine speed. In 2026, the best teams are those that have learned to trust AI for what it's best at (repetitive, well-defined tasks) and reserve human intelligence for what remains irreplaceable (deciding what to build and why). The future of software development is not AI-only; it's AI-assisted, AI-owned for the mundane, and overwhelmingly human-led for the meaningful.

A Hardware Wallet Can Stay Offline and Still Create a Weak Seed

Azalea — Fri, 31 Jul 2026 10:27:49 +0000

Hardware wallets are usually sold around one simple idea: keep the private key away from the internet, and you remove a large part of the risk.

That is true, but only after the key has been created correctly.

A recent warning from Coinkite shows how security can fail much earlier – at the moment the wallet generates its seed phrase. The device may remain offline, never expose the key to a computer and still create a wallet that is far easier to attack than its owner realizes.

On July 30, Coinkite advised users to move funds from wallets whose seed phrases were generated on a Coldcard Mk3 running firmware 4.0.1 or later.

Older firmware versions on the Mk4, Mk5 and Q were also affected, although Coinkite estimates that the problem was less severe on those devices.

The device used the wrong source of randomness

A seed phrase begins with entropy – unpredictable data used to create the wallet’s private keys.

Coldcard was supposed to take that randomness from a hardware true random number generator built into the device. But after a firmware change introduced in 2021, the seed-generation process began calling a software-based fallback instead.

The mistake was easy to miss.

Both implementations used the same function name and interface. The firmware compiled normally. The correct hardware RNG code was still present in the final binary. A reviewer looking for the expected implementation could find it and reasonably assume it was being used.

It was not.

The seed-generation path was reaching the fallback function.

Coinkite’s early analysis estimates that affected Mk3 seeds may have had roughly 40 bits of effective entropy instead of the intended 128 bits.

The Mk4, Mk5 and Q also mixed in randomness from their secure elements, raising the estimate to around 72 bits. That is stronger than the Mk3 result, but still well below the security level users expected.

The difference is not cosmetic.

A 128-bit seed is considered beyond realistic brute-force attacks. A search space closer to 40 bits is much smaller and may be practical for a well-resourced attacker, especially when many potentially vulnerable wallets can be checked at once.

Why keeping the wallet offline did not solve the problem

The attack does not require someone to connect to the device, infect a laptop or extract a key from secure storage.

The weakness already exists inside the seed.

An attacker can generate possible seeds on separate hardware, derive the corresponding Bitcoin addresses and compare them with addresses visible on the public blockchain.

The owner’s Coldcard does not need to be online. It does not even need to be turned on.

This is the part that makes the incident uncomfortable. An air gap can protect signing and reduce exposure to remote attacks, but it cannot repair weak randomness used during wallet creation.

“Offline” describes where the key is stored and used. It does not prove that the key was generated securely.

A firmware update does not repair an old seed

Coinkite released firmware 5.6.0 for the Mk4 and Mk5 and version 1.5.0Q for the Q.

Those updates fix seed generation going forward. They do not add entropy to a seed that already exists.

Anyone covered by the warning needs to create a new wallet and move the funds.

The safer process is straightforward:

Install the corrected firmware on a supported device.
Generate a completely new seed phrase.
Write down the backup and verify it carefully.
Check the wallet fingerprint and receiving address on the device.
Send a small test transaction.
Move the rest only after confirming the test arrived correctly.

Until the transfer is complete, the old wallet should be treated as potentially exposed.

Dice rolls may have helped – but only when used properly

Coldcard lets users add their own randomness by entering physical dice rolls during seed generation.

According to Coinkite, a seed created with at least 50 fair, independent and private rolls is not considered vulnerable to this RNG issue on its own.

The details matter.

Users should not assume they are safe when they entered only a handful of rolls, cannot remember how many they used or recorded the sequence digitally.

In those cases, migration remains the safer option.

A BIP-39 passphrase may also make an attack harder, but it should not be confused with the device PIN. A short, reused or predictable passphrase may still be guessed.

Coinkite recommends moving funds even when a strong passphrase was used.

The real failure happened in the development process

Random-number failures are not new in cryptography. The more useful question is how this particular mistake remained unnoticed for years.

The intended hardware RNG implementation was in the codebase. It was included in the compiled firmware. The fallback function looked compatible. Nothing obvious broke during compilation.

The product worked.

It simply called the wrong function at the most sensitive moment in the wallet’s lifecycle.

That points to a broader engineering problem: checking that secure code exists is not the same as confirming that the application actually uses it.

For security-critical software, reviews need to follow the full execution path:

Which implementation does the final build link to?
Where does the entropy used for seed generation actually come from?
Can fallback RNG code be excluded entirely?
Will the build fail when the wrong symbol is present?
Are critical calls tested by behavior rather than by source inspection alone?

Coinkite says its hotfix now removes the fallback PRNG object and adds a build-time symbol check that fails unless the expected hardware-specific RNG is present.

That is a useful fix, but the wider lesson extends beyond one wallet manufacturer.

A device can isolate a private key perfectly after generation and still fail at the moment that key is created.

For a hardware wallet, that first moment may be the most important one of all.

Fixing Exact Package Search Relevance in npmx

Anil Loutombam — Fri, 31 Jul 2026 10:27:09 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

npmx is an open-source alternative interface for exploring packages from the npm registry. It provides package details, documentation, version history, dependencies, search tools, and other information for JavaScript developers.

Bug Fix or Performance Improvement

I worked on issue #2978, which was reported by another contributor.

When Algolia was selected as the search provider, the page displayed “Relevance” as the active sorting option. However, an exact package-name match did not always appear first.

For example, searching for napkin could show other packages above the exact match. Switching to “Downloads/wk” and then back to “Relevance” changed the results and moved napkin to the top.

I reproduced this behavior locally before investigating the cause.

Code

Issue #2978
Pull request: https://github.com/npmx-dev/npmx.dev/pull/3103

Before and after

Before

private-user-images.githubusercontent.com

After

private-user-images.githubusercontent.com

My Improvements

npmx already made an additional Algolia request to check whether a package with the exact searched name existed.

However, this request retrieved only the package name and used the result only as an existence check. If the exact package was missing from the initial batch of results, the application knew it existed but did not have enough information to display it.

I updated the exact-package request to retrieve the complete package information. When the returned package name matches the searched name, it is placed at the beginning of the results.

Before adding it, the code removes any existing occurrence of the same package. This prevents duplicate results.

I also added two safety checks during review:

A missing Algolia hits array falls back to an empty array.
A returned hit is promoted only when its name matches the requested package.

Finally, I added a regression test that supplies a regular search result and a separate exact-package result. The test verifies that the exact package is detected and placed first.

I validated the change by running the focused Nuxt tests, TypeScript checks, lint and formatting checks, and by testing the behavior manually in the local UI.

After the fix, an exact package-name match appears at the top immediately when “Relevance” is selected.

ratatop day 3: disks, statvfs, and my first unsafe block

Athreya aka Maneshwar — Fri, 31 Jul 2026 10:17:57 +0000

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback.

Day three of building a btop-style system monitor in Rust with ratatui.

Day one was the CPU box.

Day two was memory, where I learned that MemFree is a number nobody should look at.

Today: disks.

And this one broke a rule I had set for myself on day one.

There is no /proc file for this

My rule was simple.

Read /proc and /sys, never shell out to another tool.

CPU came from /proc/stat.

Memory came from /proc/meminfo. Disks would come from... something.

I went looking for the file. /proc/mounts tells you what is mounted.

/proc/diskstats tells you how much I/O happened.

/sys/block/* tells you device sizes.

None of them tell you how full a filesystem is.

That number does not exist as a file anywhere. It only exists behind a syscall: statvfs(2).

The kernel computes it on demand from the filesystem's own metadata, and the only way to ask is to actually make the call.

So I had two options.

Shell out to df and parse it, which breaks my rule and drags in output-format fragility across distros.

Or make the syscall myself, which means the libc crate, which means unsafe.

I picked the syscall.

df itself is just a statvfs wrapper with a printf on top.

Spawning a process to read a number the kernel would hand me directly is silly.

My first unsafe block

Rust's standard library has no statvfs.

So this is FFI territory.

fn usage(mount: &str) -> Option<(u64, u64)> {
    let path = CString::new(mount).ok()?;
    // SAFETY: `path` is a valid NUL-terminated string that outlives the call,
    // and `vfs` is fully initialised by statvfs before we read it. A failed call
    // is reported through the return value, which we check.
    let vfs = unsafe {
        let mut vfs: libc::statvfs = std::mem::zeroed();
        if libc::statvfs(path.as_ptr(), &mut vfs) != 0 {
            return None;
        }
        vfs
    };

    let frsize = vfs.f_frsize as u64;
    let total = (vfs.f_blocks as u64).saturating_mul(frsize);
    let free = (vfs.f_bavail as u64).saturating_mul(frsize);
    Some((total, free.min(total)))
}

Three things worth pointing out, because they are the parts I had to actually think about.

CString::new is not optional. C wants a NUL-terminated string. Rust &str is not NUL-terminated, it carries a length. If you hand C a pointer to raw Rust string bytes, it reads until it happens to find a zero byte, which could be well past the end of your string. CString does the conversion properly, and it returns a Result because a Rust string containing an interior NUL cannot be represented at all.

mem::zeroed() looks worse than it is. We are handing C a buffer to fill in. statvfs writes every field before returning success. Zeroing first means that even in some bizarre partial-write scenario we get zeros rather than whatever was on the stack.

The SAFETY comment is not decoration. Rust convention is that every unsafe block gets a comment explaining why it is actually safe. Writing that comment is a genuinely useful exercise. It forces you to enumerate your assumptions, and if you cannot write the comment, that is your answer about whether the code is correct.

The nice part is that the unsafety is contained.

One function, ten lines, and a safe Option<(u64, u64)> comes out the other end. Everything upstream of it is ordinary safe Rust that cannot tell the difference.

Your filesystem is lying to you by exactly 5%

Now the fun part.

statvfs gives you three block counts, and picking the wrong one gives you the wrong answer.

f_blocks: total blocks in the filesystem
f_bfree: blocks that are genuinely unused
f_bavail: blocks available to an unprivileged process

Those last two are not the same, and the gap is bigger than you would guess. Real numbers from my root filesystem:

total   91.1 GiB
bfree   23.7 GiB
bavail  19.0 GiB

That is 4.67 GiB, exactly 5.1% of the disk, that is free but that I am not allowed to use.

ext4 reserves 5% of the filesystem for root by default. The idea is that if a runaway process fills the disk, root still has room to log in and clean up, and the filesystem has room to avoid the fragmentation that comes with running completely full.

Which number you subtract changes the headline figure:

used via f_bavail   79.1%
used via f_bfree    74.0%

Five percentage points, from one field name.

btop uses f_bavail, and so does df.

That is the honest choice for a monitor: report the space you can actually use, and treat root's reserve as spoken for.

Showing 74% when df says 79% would just make the tool look broken.

Which mounts are even real?

Next problem. /proc/self/mounts on my laptop has around 40 entries.

Four of them are disks.

The rest is proc, sysfs, cgroup2, tmpfs, a dozen snap squashfs images, and a couple of FUSE mounts from the desktop session.

The obvious move is a blocklist of filesystem types to skip.

I started writing one, then realised the kernel already publishes exactly this information:

$ cat /proc/filesystems
nodev   sysfs
nodev   tmpfs
nodev   proc
nodev   cgroup2
    ext4
    vfat

Anything flagged nodev is not backed by a block device.

That is the kernel telling you, authoritatively, which filesystem types cannot possibly be a disk.

So instead of maintaining a list that goes stale, I read theirs:

let mut types: Vec<String> = raw
    .lines()
    .filter_map(|line| line.strip_prefix("nodev"))
    .map(|name| name.trim().to_string())
    .collect();

New pseudo-filesystem lands in a future kernel? Excluded automatically, no code change.

There is a second filter that does a lot of work for one line: the mount's device has to start with /. A real partition is /dev/nvme0n1p2.

Pseudo-filesystems put a bare name there instead, like proc or gvfsd-fuse. No slash, not a disk.

The kernel escapes your mount paths

Small one, but it would have been a confusing bug.

Mount a disk at a path with a space in it, and /proc/self/mounts does not give you the space:

/dev/sdb1 /mnt/my\040disk ext4 rw,relatime 0 0

\040 is octal for a space. The kernel escapes spaces, tabs, newlines and backslashes this way, because the file is whitespace-separated and an unescaped space would make the line unparseable.

If you pass that raw string to statvfs, it fails. No such path exists. The disk silently vanishes from your monitor and you have no idea why.

So you decode it before using it. Four characters starting with a backslash, parse the next three as octal, emit the byte.

I/O comes from somewhere else entirely

Usage is a syscall. Throughput is back to reading files.

btop reads /sys/block/<device>/stat, which gives you a device's cumulative counters:

234345 84965 16346864 796898 486240 189824 21513416 23255863 0 2406558 24197776

The fields I care about are index 2 (sectors read), index 6 (sectors written), and index 9 (io_ticks, milliseconds the device spent with a request in flight).

Two traps here.

A sector is always 512 bytes in this file. Not the device's real block size. My NVMe drive uses 4096-byte blocks, but these counters are still expressed in 512-byte units, for backwards compatibility with software written when that was universal. Multiply by 4096 and your throughput numbers come out eight times too high.

Partitions are nested. /sys/block/nvme0n1/stat exists for the whole drive. The partition I actually mounted lives at /sys/block/nvme0n1/nvme0n1p2/stat, one level deeper. So the lookup checks the top level first, then scans one level down.

io_ticks is the nice one. It is busy-milliseconds, so dividing by the elapsed wall-clock milliseconds gives you utilisation directly:

let busy_ms = counters.io_ticks.saturating_sub(previous.io_ticks) as f64;
disk.io_util = (busy_ms / (seconds * 1000.0) * 100.0).clamp(0.0, 100.0);

Same delta pattern as the CPU box on day one. Third time I have written saturating_sub on a monotonic counter in this project, and it has earned its keep every time: devices get unplugged and re-added, and counters reset to zero when they do.

Swap is a disk that isn't one

btop lists swap in the disks box, which surprised me until it made sense. You care about how full it is, in the same way and for the same reasons.

But it has no filesystem, so statvfs is meaningless. And it may be a file, a partition, or several of both, so there is no single block device to read I/O from.

It comes from /proc/meminfo instead:

SwapTotal:      21092348 kB
SwapFree:       19857688 kB

So swap is a row that shares the layout but skips two of the three data sources.

In my code it is a Disk with is_swap: true, and the render function checks that flag before drawing the I/O graph.

Drawing an empty graph there would imply a measurement of zero, when the truth is there is no measurement at all.

The distinction between "zero" and "unknown" is one of those things that seems pedantic until your tool confidently reports the wrong thing.

The ratatui side was the easy part

Genuinely almost nothing to say here, which is the point.

Three rows per disk, laid out with the same Layout calls as the other boxes:

let [name_row, io_row, used_row] = Layout::vertical([
    Constraint::Length(1),
    Constraint::Length(1),
    Constraint::Length(1),
])
.areas(area);

The Meter widget from day one and the BrailleGraph from day one both dropped straight in with zero changes. Third box, same two widgets. That is the payoff for writing them as plain structs with one render method.

One layout decision worth mentioning: the box only draws disks that completely fit.

let capacity = (inner.height / ROWS_PER_DISK) as usize;

Integer division, so a disk with room for only two of its three rows is not drawn at all. A half-rendered disk looks like a bug, whereas a missing one just looks like a small window.

What's next

Network. /proc/net/dev is another counter file, so the delta machinery is already there, but auto-scaling units across five orders of magnitude will be new.

Then processes, which is the big one.

Reading /proc/[pid]/stat for every process, every tick, and sorting it.

Code so far:

lovestaco / ratatop

Keep an eye on what's cooking in your system

A reimplementation of btop in Rust, built on ratatui.

The goal is a resource monitor that feels like btop: the four-box layout, braille graphs with gradient fills, mouse-driven navigation, and a themable process manager, but written as a modern Rust TUI.

Status

The CPU box works. It samples real data and renders btop's layout:

Per-core braille history graphs, a gradient load bar with sub-cell resolution frequency, package temperature, battery, and load averages.

Everything else, the memory, network, and process boxes, is still to come.

Design notes

Data source: /proc and /sys on Linux first, read directly rather than shelling out. btop's src/linux/btop_collect.cpp is the reference for what to read and how often; the BSD/macOS collectors are out of scope for v1.
Graphs are the hard part. btop's look comes from braille sub-cell plotting with a color gradient applied along the value axis, not from a stock chart widget. Expect…

View on GitHub

Today's lesson, if there is one: the rule I set myself ("only read files, never shell out") was a good rule that had exactly one legitimate exception, and finding out why it was an exception taught me more than following it would have.

Sometimes the file you are looking for does not exist because the number was never a file.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs — without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Git Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

GenAI today is a race car without brakes. It accelerates fast -- you describe something, and large blocks of code appear instantly. But AI agents silently break things: they remove logic, relax constraints, introduce expensive cloud calls, leak credentials, and change behavior -- without telling you. You often find out in production.

git-lrc is your braking system. It hooks into git commit and runs an AI review on every diff before it lands. 60-second setup. Completely free.

In short, git-lrc helps Prevent Outages, Breaches, and Technical Debt Before They Happen

At a glance: 10 risk categories · 100+ failure patterns tracked · every commit…

View on GitHub

Inside Instagram's DASH manifest — from MPD to segment to stitched MP4

ai ai — Fri, 31 Jul 2026 10:16:41 +0000

The first surprise when you reverse-engineer an Instagram Reel download is that there's no single MP4 to fetch. There's an MPD file, separate video and audio representations, and a bunch of segment URLs with TTL-bound signatures. We walk through a real DASH manifest from our 2026-04-22 testing, show the fields that matter, and explain why a one-line ffmpeg command is the bridge between what Instagram stores and what ends up on your disk.

Why 'download this Reel' is harder than it sounds

Pick any Reel on Instagram, open your browser's DevTools Network tab, and watch the requests as the video plays. You won't see a single video.mp4 being fetched. You'll see one MPD (Media Presentation Description) file, then a flurry of 2-5 second .m4s segments, some labeled video, some labeled audio, pulled from scontent-*.cdninstagram.com in parallel.

That's DASH — Dynamic Adaptive Streaming over HTTP, the standard Netflix helped popularize around 2012 and that every major video platform now uses. Instagram sits on top of it. Which means our downloader's job isn't just to copy a file; it's to read the MPD, pick the right representations, pull the right segments, and glue them back into a single MP4. MDN has a clean primer on the Media Source API side of the story at https://developer.mozilla.org/en-US/docs/Web/API/Media_Source_API/Transcoding_assets_for_MSE — we're on the other end of the same pipeline.

The MPD: what's actually in it

An MPD is plain XML. Here's a trimmed, real Instagram MPD we pulled on 2026-04-22 for the @natgeo Reel DH56yy7p3lZ (we're eliding the signature tokens but keeping the structural fields):

<MPD type="static" mediaPresentationDuration="PT60.060S" minBufferTime="PT2.0S">
  <Period>
    <AdaptationSet contentType="video" mimeType="video/mp4">
      <Representation id="v720" codecs="avc1.64001f" width="720" height="1280" bandwidth="1356000">
        <BaseURL>https://scontent-*.cdninstagram.com/.../v720.m4s?oe=...</BaseURL>
      </Representation>
      <Representation id="v360" codecs="avc1.4d001e" width="360" height="640" bandwidth="309000"/>
    </AdaptationSet>
    <AdaptationSet contentType="audio" mimeType="audio/mp4">
      <Representation id="a72" codecs="mp4a.40.5" audioSamplingRate="48000" bandwidth="72000">
        <BaseURL>https://scontent-*.cdninstagram.com/.../a72.m4s?oe=...</BaseURL>
      </Representation>
    </AdaptationSet>
  </Period>
</MPD>

Three fields do most of the work. codecs tells a client what codec profile to expect — avc1.64001f is H.264 High Profile Level 3.1, which every browser and every player since 2012 handles. bandwidth is the mean bitrate in bits per second — the client uses it to pick which representation matches the connection speed. And <BaseURL> is the actual segment URL, signed with an expiry parameter that expires in about an hour.

Why video and audio are separate representations

The historical version: multiplexed MP4s (video and audio interleaved in one file) were the default until streaming platforms realized they were wasteful. Many clients could download the same video track but pick different audio languages, or pair high-quality audio with a lower-bandwidth video. Separating the two lets the client mix and match.

For Instagram specifically there's usually just one audio representation per Reel — they don't ship multiple language tracks. The separation still matters though: the video and audio streams are encoded with completely different codecs (H.264 vs HE-AAC), different framerates, different segment durations. Trying to muxes them in a single file at encode time would mean one codec dictates the segment boundary strategy of the other, which hurts streaming efficiency.

The practical consequence is what we've called out on the reels-downloader tool page: drop the video representation alone and you get a silent clip. Drop the audio alone and you get an M4A with no picture. The merge step isn't optional; it's what makes the download useful.

ffmpeg as the glue

Every download we serve passes through one ffmpeg invocation on our VPS. The command is short enough to paste here without eliding anything:

ffmpeg -i <video-segment-url> -i <audio-segment-url> \
       -c copy -movflags frag_keyframe+empty_moov -f mp4 pipe:1

Three flags that matter. -c copy tells ffmpeg to copy both streams into the output container without re-encoding. The bytes on disk are identical to what Instagram serves — no quality loss, no generation loss, no bitrate change. -movflags frag_keyframe+empty_moov makes the output a fragmented MP4, which means ffmpeg can pipe bytes to the HTTP response as they're produced instead of seeking back to the file's header to write an index. Without this flag ffmpeg wants a seekable output, which a network pipe isn't. And pipe:1 directs the bytes to stdout, which our Next.js handler streams straight to the requesting browser.

The whole thing takes 2-5 seconds on a typical Reel, most of which is fetch time from Instagram's CDN via our residential proxy. The actual remux is CPU-bound at maybe 10-15% of a single core. The bottleneck is the network.

Segment TTL and why your old Reel URLs stop working

Look again at the oe=... query parameter on the segment URLs in the MPD snippet. That's a Unix timestamp in hex, and when you decode it against today's production URLs you get roughly 108 hours (about 4.5 days) after the MPD was generated. After that timestamp, Instagram's CDN rejects requests to those exact segment URLs with a 403 Forbidden response. (An earlier version of this post claimed ~1 hour based on outdated assumptions — we re-measured on 2026-04-23 and the real TTL is closer to 4.5 days. We keep a separate write-up of the full URL signature anatomy at https://cliplatch.com/blog/instagram-cdn-url-signature-anatomy.)

Even with a multi-day window, a naive downloader that caches the parsed MPD indefinitely will start returning 403s eventually, and you can't tell a valid URL from an expired one without making the request. Our solution is to not cache the MPD at all — every user's paste call runs a fresh /api/parse that fetches a new MPD with fresh signatures. It's a little wasteful in proxy cost but it means the download buttons the user sees always reference URLs that haven't expired. The cost tradeoff is explained in https://cliplatch.com/blog/how-residential-proxies-bypass-instagram-cdn.

For the technically curious: the signing is HMAC, with a secret bound to Meta's infrastructure. The oh=... parameter is the actual signature, covering the path, the expiration, and request context. Anyone claiming they can forge these is selling something that breaks the first time Meta rotates the secret.

What we verified on 2026-04-22

Test: @natgeo public Reel DH56yy7p3lZ. macOS + Chrome + residential fiber. Our logs recorded the sequence:

Our /api/parse called Instagram's GraphQL endpoint at www.instagram.com, received the MPD URL, fetched the MPD (3.1 KB XML document), parsed out one video representation at 720×1280 + one at 360×640, plus one audio representation at 72 kbps HE-AAC. Total parse latency: 1308 ms.

User clicked Download 720p. Our /api/merge received the video + audio URLs, spawned ffmpeg, piped the output back through our Next.js handler. Total time click-to-file: 10,603 ms. Resulting file: 10,625,751 bytes (~10.6 MB). ffprobe on the file confirmed H.264 High@L3.1 avc1.64001f at 720×1280, 23.976 fps, 1.35 Mbps video bitrate, HE-AAC stereo 48 kHz audio, duration 60.060 seconds — numbers matching the MPD exactly.

Bit-for-bit, no quality loss from remux — verified via hash of the elementary streams extracted with ffmpeg -i <file> -c copy -bsf:v h264_mp4toannexb video.h264 from both our output and a direct DASH fetch. Identical.

Why this post is longer than it needs to be

Most "how Instagram downloader works" posts stop at "we fetch the MP4". That's never been true of any modern Instagram download. The platform has used DASH since 2018, and if your downloader isn't reading an MPD it's either missing quality variants or downloading silent video. We wanted to write the post we wish we'd found when we started.

Practical takeaway for anyone building something similar: start by reading a real MPD. Paste a Reel URL into any DASH-aware tool (ExoPlayer's test harness, Shaka Player, even yt-dlp --verbose), grab the MPD, look at the fields. Everything downstream — residential proxy sourcing, ffmpeg invocation, CDN TTL handling — becomes obvious once you've seen the manifest once.

FAQ

Can I just download the MPD file and watch it offline?

No — an MPD is only the manifest; it contains URLs to the actual video and audio segments. Opening an .mpd file in a video player would fetch the referenced segments, which expire about an hour after the MPD was generated. To watch offline you need a downloader that fetches the segments and remuxes them into an MP4, which is what cliplatch.com does.

Why not re-encode to a smaller file?

Re-encoding loses quality — even a careful 1080p → 1080p re-encode introduces H.264 quantization artifacts that weren't in the source. Our default is ffmpeg remux (-c copy) precisely to avoid this. If you want a smaller file after download, tools like Handbrake let you re-encode locally with full control over the tradeoff.

Do the MPD segments include subtitles?

Not for Reels or ordinary feed videos. Instagram's auto-captioning runs client-side on the user's device, not as a separate text track in the MPD. If the creator burned captions into the video (baked into the pixels, common for Reels), they'll be in the downloaded MP4. If captions were only shown in-app via Instagram's rendering layer, they won't be in the file.

Does your downloader support DASH-over-HLS fallback?

Instagram hasn't served HLS for Reels in the time we've monitored. The Live Streaming product uses a different pipeline, but that's not something we attempt to download. If Instagram switches primary delivery to HLS we'll write an update post.

Is avc1.64001f the only video codec Instagram ships?

Not anymore. H.264 High Profile Level 3.1 was the default through early April 2026, but on 2026-04-23 we caught Instagram rolling VP9 variants for the same Reel we'd been testing all day (vencode_tag flipped from dash_baseline_1_v1 to dash_vp9-basic-gen2 between morning and evening parse calls). Full write-up at https://cliplatch.com/blog/instagram-vp9-transition-caught-live. Meta had previously tested HEVC in 2023 and AV1 in 2024, rolling both back; VP9 is the current live rollout. MDN's H.264 reference at https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Video_codecs#avc_h.264 covers the profile/level conventions for the H.264 side.

Building Fluentic: I Didn’t Want a Tailwind Preset. Then I Added Two.

OmniDev — Fri, 31 Jul 2026 10:12:34 +0000

TL;DR: Fluentic Style is a new JSX styling library for React, Preact, Solid, and compatible JSX runtimes. It starts with typed style objects and a css prop, then adds selector chains, component slots, scopes, themes, runtime resolution, and optional static CSS extraction for production builds.

Fluentic started as an object-first styling API.

That was intentional.

The original shape was built around typed style objects, explicit composition, selector chains, component slots, scopes, themes, and optional static extraction later.

So the first Fluentic style looked more like this:

import { style } from '@fluentic/style';

const button = style({
  display: 'inline-flex',
  alignItems: 'center',
  gap: 8,
  border: 0,
  borderRadius: 8,
  paddingInline: 16,
  paddingBlock: 8,
  backgroundColor: '#2563eb',
  color: '#ffffff',
}).hover({
  backgroundColor: '#1d4ed8',
});

This is still the Fluentic style I personally reach for first.

It is regular TypeScript. The style is data. The chain adds a state. The result can work at runtime, and the compiler can extract the static parts later.

So when I started thinking about Tailwind support, my first instinct was pretty predictable:

Bring Tailwind’s vocabulary into Fluentic’s object-based style world.

And then, somehow, I ended up adding two Tailwind presets.

The docs for both live here:

The First Preset Was Object-Based

The first version was the Fluentic-shaped answer.

Instead of regular CSS property names, it used a Tailwind-like object dialect:

const button = tw({
  inlineFlex: true,
  items: 'center',
  gap: '$2',
  px: '$4',
  py: '$2',
  bg: '$blue.600',
  text: '$white',
  rounded: '$md',
}).hover({
  bg: '$blue.700',
}).md({
  px: '$6',
});

I still like this API.

It keeps a lot of the things I wanted Fluentic to care about:

styles are grouped as objects
TypeScript can understand the shape
dynamic branches can affect several declarations together
selectors and media stay in chain methods
the output is still Fluentic style data

It also keeps the useful part of Tailwind’s vocabulary: px, py, bg, rounded, items, gap, theme scales, breakpoints, and so on.

But there is a tradeoff.

A Tailwind user still has to translate from the syntax they already know:

inline-flex        -> inlineFlex: true
items-center       -> items: 'center'
gap-2              -> gap: '$2'
bg-blue-600        -> bg: '$blue.600'
hover:bg-blue-700  -> .hover({ bg: '$blue.700' })

That translation is not awful.

But it is still translation.

And if the point of a Tailwind preset is to make Tailwind-oriented codebases easier to adopt, asking every user to move through an object dialect is not always the best bridge.

That was the interesting part.

The first preset matched Fluentic’s original API taste.

But it did not fully match Tailwind’s muscle memory.

So I Added A Class-Name Preset Too

The second preset keeps class names closer to the way Tailwind users already write them:

const button = tw(
  'inline-flex',
  'items-center',
  'gap-2',
  'rounded-md',
  'bg-blue-600',
  'px-4',
  'py-2',
  'text-white',
)
  .hover('bg-blue-700')
  .md('px-6');

This feels much closer to Tailwind.

But it is still Fluentic.

The variants are not packed into the class string:

tw('bg-blue-600')
  .hover('bg-blue-700')
  .md('px-6');

Instead of:

bg-blue-600 hover:bg-blue-700 md:px-6

That part is deliberate.

Fluentic already has chain methods for states, selectors, media queries, scopes, and other styling conditions. I did not want Tailwind support to bypass that.

So class names became the input vocabulary, but chains still carry the structure.

In practice, it looks like this:

class names    -> transform -> Fluentic style data
chain methods  -> selectors, media, and conditions
runtime        -> resolves dynamic styles
compiler       -> extracts static styles
debug tools    -> trace generated CSS back to source

The syntax changed.

The rest of Fluentic stayed the same.

The class-name chain is not just a class string helper either. It also supports the same slot and scope shape as the object-style chain.

The Part That Changed My Mind

Before this, I mostly thought about Fluentic as an object-style API with chain methods.

After adding both Tailwind presets, that felt too narrow.

The object API is still important. It is still the default path. It is still the one I prefer for complex component styling.

But Fluentic can support more than one authoring style.

The input can be regular CSS objects:

style({
  backgroundColor: '#2563eb',
}).hover({
  backgroundColor: '#1d4ed8',
});

It can be a Tailwind-like object dialect:

tw({
  bg: '$blue.600',
}).hover({
  bg: '$blue.700',
});

It can be a Tailwind-like class-name dialect:

tw('bg-blue-600').hover('bg-blue-700');

And projects can define their own naming and transform logic too.

That last part matters most to me.

Fluentic does not need to own every word in the styling language.

It needs to provide the pieces underneath:

style values
selector chains
slots
scopes
tokens
runtime resolution
compiler extraction
debugging metadata

The vocabulary on top can be different per team.

If you want to see the lower-level APIs behind that idea, these docs are the useful ones:

Why Not Just Use Tailwind?

Fair question.

Tailwind is good. A lot of people are fast with it. The naming system is familiar, the docs are strong, and the ecosystem is huge.

I did not add Tailwind presets because I think Fluentic should replace Tailwind.

I added them because Tailwind-style vocabulary is useful, and I wanted to see what happens when that vocabulary runs through Fluentic’s component styling system.

For example, Fluentic still has component slots with the class-name chain:

const card = {
  root: tw.slot('rounded-xl', 'bg-white', 'p-6'),
  title: tw.slot('text-xl', 'font-bold'),
  body: tw.slot('text-slate-600'),
};

And scopes can still target those slots:

const compact = tw.scope([
  card.root('p-4'),
  card.title('text-lg'),
  card.body('text-sm'),
]);

That is the part I care about.

The class names are not the component contract.

The slots are.

The component can decide which parts are styleable without exposing its private DOM structure.

Where This Leaves Fluentic

I did not want a Tailwind preset.

Then I added one.

Then I added another one because the first one was a little too loyal to Fluentic’s original object-first API.

That feels like a useful library-design lesson.

Sometimes the API you prefer is not the API that helps people cross the bridge.

And sometimes supporting another way to write styles does not weaken the idea.

It clarifies what the library is actually responsible for.

Fluentic now supports:

object-based style chains
class-name-based style chains
custom selectors
custom transforms
Tailwind-like presets on top

Both Tailwind presets still go through the same Fluentic path: chains, slots, scopes, runtime resolution, extraction, and debugging.

So no, Fluentic did not become Tailwind.

But adding Tailwind support made Fluentic more honest about itself.

Fluentic is not trying to own every styling word you write.

It is trying to make those words composable once they enter your component system.

Fluentic Style is still new and currently in beta. The core authoring model is usable today, but I am still looking for early users to try it in real React, Preact, Solid, and component-library codebases.

If this direction is interesting, here are the main links:

Feedback would help a lot right now, especially around API shape, Tailwind preset coverage, build integrations, debugging, and whether the slot/scope model makes sense in real component work.

DEV Community

UTM conventions that stop your analytics turning to mush

The five parameters, and what each is actually for

Rule 1: lowercase everything, always

Rule 2: hyphens, never spaces or underscores

Rule 3: date your campaigns

Rule 4: never tag internal links

Rule 5: keep a canonical list

Rule 6: think about what the user sees

Rule 7: QR codes need utm_medium=qr

A worked example

The check that catches drift

The Human Is Not the Bottleneck. The Human Is the Missing Oracle

UI/UX Design in 2026: Why Great Products Feel Invisible

Benchmark an AI Coding Task Across Mobile Backgrounding, Network Switches, and Battery Pressure

Test environment (record yours)

The one metric that matters

The benchmark script (client side)

The transition matrix

What to fix when a run fails

Limitations

Who shouldn't use this approach

Why I built a zero-upload, local-first browser video compressor (and why you should stop uploading your MP4s to remote servers)

100 Days of Solana is a wrap!

What is 100 Days of Solana?

What we covered

First: learn to speak Solana

Next: create digital assets

Then: write your own programs

After that: think like an attacker

Finally: ship what you built

Shout-outs

Continue your journey

How AI Is Transforming Software Development Workflows in 2026

How AI Is Transforming Software Development Workflows in 2026

The Shift from Copilots to Autonomous Agents

A Simple Agent Interaction Example

AI-Native CI/CD Pipelines

Automated Code Review at a Higher Level

What About Human Review?

Self-Writing and Self-Healing Tests

Documentation and Knowledge Management

The Shift in Team Dynamics and Roles

The New "Tech Stack"

Addressing the Challenges

Real-World Impact: Case Studies

The Future Is Already Here

Conclusion

A Hardware Wallet Can Stay Offline and Still Create a Weak Seed

Fixing Exact Package Search Relevance in npmx

Project Overview

Bug Fix or Performance Improvement

Code

Before and after

Before

After

My Improvements

ratatop day 3: disks, statvfs, and my first unsafe block

There is no /proc file for this

My first unsafe block

Your filesystem is lying to you by exactly 5%

Which mounts are even real?

The kernel escapes your mount paths

I/O comes from somewhere else entirely

Swap is a disk that isn't one

The ratatui side was the easy part

What's next

lovestaco / ratatop

Keep an eye on what's cooking in your system

Status

Design notes

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Git Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

Inside Instagram's DASH manifest — from MPD to segment to stitched MP4

Why 'download this Reel' is harder than it sounds

The MPD: what's actually in it

Why video and audio are separate representations

ffmpeg as the glue

Rule 7: QR codes need `utm_medium=qr`