DEV Community

React Mastery Series – Day 22: State Management with Redux Toolkit – Building Enterprise React Applications

Siva Samanthapudi — Mon, 03 Aug 2026 06:01:03 +0000

Welcome back to the React Mastery Series!

In the previous article, we explored TypeScript with React and learned how static typing improves code quality, developer productivity, and application reliability.

Today, we're diving into one of the most requested topics in React interviews and one of the most widely used state management solutions in enterprise applications:

Redux Toolkit (RTK)

If you've ever wondered:

Why do we need Redux when React already has Context API?
What problems does Redux solve?
Why is Redux Toolkit preferred over traditional Redux?

This article answers all of those questions.

Why Do We Need Redux?

Imagine you're building an enterprise banking application.

It contains:

Login
Dashboard
Accounts
Transactions
Beneficiaries
Profile
Notifications

Many screens need the same data:

Logged-in user
Authentication token
Customer profile
Theme
Permissions

Without centralized state:

Component A
     |
Component B
     |
Component C
     |
Component D

Each component manages its own copy of the data.

Problems:

Duplicate API calls
Inconsistent state
Difficult debugging
Complex data flow

Context API vs Redux

Many developers ask:

"Why not just use Context API?"

Context works well for:

Theme
Authentication
Language
User preferences

However, for applications with:

Frequent state updates
Large datasets
Complex business logic
Multiple developers

Redux provides better scalability and tooling.

Context API	Redux Toolkit
Good for simple shared state	Designed for complex state
Basic state sharing	Predictable state management
Limited debugging	Excellent DevTools support
Minimal boilerplate	Simplified with RTK

What is Redux?

Redux is a predictable state management library.

It stores application state in one central location called:

Store

Instead of multiple components managing separate state:

Header

Dashboard

Profile

Sidebar

Everything reads from one source.

          Store
             |
   --------------------------
   |      |       |        |
Header Dashboard Profile Sidebar

Core Redux Concepts

Redux is built around four ideas.

Store
  ↓
Action
  ↓
Reducer
  ↓
Updated State

Let's understand each one.

What is a Store?

The Store is the central container for your application's state.

Example:

Store
├── auth
├── user
├── transactions
├── accounts
└── settings

Every component reads data from the Store.

What is an Action?

An Action describes what happened.

Example:

{
  type: "LOGIN"
}

Another example:

{
  type: "ADD_TRANSACTION",
  payload: {
    amount: 500
  }
}

Notice:

Actions never update state directly.

They simply describe an event.

What is a Reducer?

A Reducer decides how state changes.

Example:

Current State
      +
   Action
      ↓
  New State

Reducers must:

Be pure functions
Never mutate existing state
Always return new state

Traditional Redux vs Redux Toolkit

Older Redux required:

Action creators
Constants
Reducers
Store configuration
Boilerplate code

Example project:

actions.js
constants.js
reducers.js
store.js

Redux Toolkit removes most of this boilerplate.

Installing Redux Toolkit

npm install @reduxjs/toolkit react-redux

Packages:

@reduxjs/toolkit
react-redux

These are all you need for most applications.

Creating the Store

import { configureStore } from "@reduxjs/toolkit";

import authReducer from "./authSlice";

export const store = configureStore({
  reducer: {
    auth: authReducer
  }
});

configureStore() automatically enables useful defaults like Redux DevTools and middleware.

What is a Slice?

A Slice groups:

State
Reducers
Actions

into one file.

Example:

authSlice.ts
├── Initial State
├── Reducers
└── Generated Actions

This is the biggest improvement introduced by Redux Toolkit.

Creating Your First Slice

import { createSlice } from "@reduxjs/toolkit";

const initialState = { user: null };

const authSlice = createSlice({
  name: "auth",
  initialState,
  reducers: {
    login(state, action) {
      state.user = action.payload;
    },
    logout(state) {
      state.user = null;
    }
  }
});

export const { login, logout } = authSlice.actions;
export default authSlice.reducer;

Notice:

We appear to modify state directly.

Redux Toolkit uses Immer internally, so immutable updates happen automatically.

Providing the Store

Wrap the application.

import { Provider } from "react-redux";

<Provider store={store}>
  <App />
</Provider>

Now every component can access Redux state.

Reading State

Use:

useSelector()

Example:

import { useSelector } from "react-redux";

const user = useSelector(state => state.auth.user);

Flow:

   Store
     ↓
useSelector()
     ↓
 Component

Updating State

Use:

useDispatch()

Example:

import { useDispatch } from "react-redux";

const dispatch = useDispatch();

dispatch(login({ id: 1, name: "Siva"}));

Flow:

    Button Click
         ↓
    dispatch()
         ↓
     Reducer
         ↓
   Store Updated
         ↓
Component Re-renders

Enterprise Authentication Flow

Login Form
     ↓
Authentication API
     ↓
dispatch(login())
     ↓
Redux Store
     ↓
Navbar Updates
     ↓
Dashboard Updates
     ↓
Profile Updates

Every component immediately receives the updated user information.

Async API Calls with createAsyncThunk

Most applications fetch data from APIs.

Redux Toolkit provides:

createAsyncThunk()

Example:

export const fetchUsers = createAsyncThunk("users/fetch", async () => {
  const response = await fetch("/api/users");
  return response.json();
});

Redux automatically generates:

Pending
Fulfilled
Rejected

states.

Handling Async States

    API Request
         ↓
     Pending
         ↓
Success OR Failure

Typical state:

{
  users: [],
  loading: false,
  error: null
}

Perfect for enterprise applications.

Folder Structure

A scalable Redux Toolkit project:

src

├── app
│   └── store.ts
│
├── features
│   ├── auth
│   │   └── authSlice.ts
│   │
│   ├── users
│   │   └── userSlice.ts
│   │
│   └── transactions

│       └── transactionSlice.ts

Each feature owns its own Redux logic.

Real-World Banking Example

Imagine a customer logs in.

  Login
     ↓
dispatch(login())
     ↓
Store Updated
     ↓
Header

Sidebar

Dashboard

Profile

Notifications

Every screen instantly reflects the new authentication state.

Redux DevTools

One of Redux's biggest advantages is debugging.

You can inspect:

Every action
Previous state
New state
Action payload
State history

Example:

    LOGIN
      ↓
FETCH_ACCOUNTS
      ↓
ADD_BENEFICIARY
      ↓
   LOGOUT

This makes debugging much easier than scattered component state.

Common Mistakes

1. Putting Everything in Redux

Not all state belongs in the Store.

Avoid storing:

Modal visibility
Form input values
Tooltip state
Local UI toggles

Use useState() for component-specific state.

2. Mutating State Outside Redux Toolkit

Incorrect:

state.user.name = "John";

outside a reducer.

Always update state through Redux actions.

3. Creating One Huge Slice

Avoid:

appSlice

containing:

User
Products
Orders
Notifications
Theme

Instead:

authSlice

userSlice

transactionSlice

themeSlice

Keep slices focused.

Best Practices

Organize Redux by feature.
Keep slices small and focused.
Use createAsyncThunk() for API requests.
Keep UI state local.
Use Redux DevTools during development.
Prefer Redux Toolkit over traditional Redux.

Key Takeaways

Today, we learned:

✅ Redux provides centralized state management.
✅ Redux Toolkit significantly reduces Redux boilerplate.
✅ A Slice combines state, reducers, and actions.
✅ useSelector() reads data from the Store.
✅ useDispatch() sends actions to update state.
✅ createAsyncThunk() simplifies asynchronous API calls.
✅ Redux Toolkit is the preferred Redux approach for modern React applications.

Coming Next 🚀

In Day 23, we will explore:

API Integration in React – Fetch, Axios, Error Handling & Best Practices

We will learn:

Fetch API vs Axios
GET, POST, PUT, DELETE requests
Request interceptors
Response interceptors
Authentication tokens
Global error handling
Loading and retry strategies
Enterprise API architecture

By the end of the next article, you'll know how production React applications communicate securely and efficiently with backend services.

Happy Coding! 🚀

Building a Micro AI Code Reviewer in Rust: Lessons from 'ratatop' with Unsafe and System Metrics

Tamiz Uddin — Mon, 03 Aug 2026 06:00:51 +0000

Originally published on tamiz.pro.

In the world of CI/CD, AI-powered code review tools are becoming ubiquitous. However, most of these solutions are heavyweight Python or Node.js services that introduce significant latency into the pull request workflow. They often suffer from cold starts, high memory footprints, and non-deterministic execution times.

This deep dive explores the architecture and engineering decisions behind ratatop, a micro AI code reviewer designed to run locally or in lightweight containers on every commit. Built entirely in Rust, the project prioritizes deterministic low-latency execution, zero-copy memory management for large diffs, and deep integration with system-level metrics. We will dissect how we leveraged unsafe blocks for performance-critical paths and how we integrated prometheus and libbpf to monitor the reviewer's impact on the host system in real-time.

The Architecture: Why Rust for AI Tooling?

Before diving into the code, it is crucial to understand why Rust was chosen over more traditional languages for this specific use case. While Python is the lingua franca of AI/ML, it is often too slow and memory-inefficient for high-throughput, low-latency system tooling.

Rust offers three distinct advantages for building a micro AI reviewer:

Zero-Cost Abstractions: The ability to write high-level logic (like AST traversal or LLM prompt construction) without sacrificing the performance of C/C++. This is critical when processing large code diffs where memory allocation overhead can become a bottleneck.
Memory Safety without Garbage Collection: Unlike Java or Go, Rust does not have a garbage collector (GC). This eliminates "stop-the-world" pauses that can jitter latency, ensuring that the code review process remains predictable even under load.
Interoperability with C/C++ Libraries: Many high-performance diffing algorithms (like those used in libgit2 or unidiff) are written in C or C++. Rust’s Foreign Function Interface (FFI) allows us to call these libraries directly, avoiding the need to rewrite complex low-level logic in Rust.

Zero-Copy Diff Processing with Unsafe Blocks

One of the most performance-critical components of any code reviewer is the diff parser. When a developer pushes a commit with thousands of lines changed, parsing the diff, extracting context, and feeding it to an LLM can be expensive in terms of memory allocations.

In Python, parsing a large diff often involves creating numerous string objects, leading to significant memory churn. In Rust, we can avoid this by using zero-copy techniques, primarily through unsafe blocks.

The Challenge: String Allocations

Consider the following naive approach to extracting a changed line from a diff:

// Naive approach - creates many allocations
fn extract_changes_naive(diff_text: &str) -> Vec<String> {
    diff_text
        .lines()
        .filter(|line| line.starts_with('+') || line.starts_with('-'))
        .map(|line| line[1..].to_string()) // Allocates a new String for each line
        .collect()
}

This function allocates memory for every changed line. In a large diff with 10,000 changes, this results in 10,000 heap allocations. While modern allocators are fast, this overhead adds up, especially when processing multiple files concurrently.

The Solution: Zero-Copy Slices

Instead of creating new String objects, we can work directly with &str slices that point to the original buffer. This eliminates heap allocations entirely. However, if the diff data comes from a C library via FFI, we might receive a *mut c_char (a raw pointer to a C string). Converting this safely requires unsafe code.

Here is how we implemented a zero-copy diff extractor:

use std::ffi::CStr;

/// Extracts changed lines from a C-style diff buffer without allocating new strings.
/// Returns slices pointing directly into the original buffer.
fn extract_changes_zero_copy(diff_buffer: *mut libc::c_char) -> Vec<&str> {
    unsafe {
        // Safety: We assume diff_buffer is a valid, null-terminated C string
        // and that the lifetime of the returned slices does not exceed the buffer's lifetime.
        let c_str = CStr::from_ptr(diff_buffer);
        let diff_text = c_str.to_str().unwrap_or("\0");

        diff_text
            .lines()
            .filter(|line| line.starts_with('+') || line.starts_with('-'))
            .map(|line| &line[1..]) // Returns a &str slice, no allocation
            .collect()
    }
}

Why `unsafe` is Justified Here

The unsafe block is justified because:

Pointer Validation: We are dereferencing a raw pointer obtained from FFI. Rust cannot guarantee at compile-time that this pointer is valid or points to a null-terminated string. We manually validate this by using CStr::from_ptr.
Lifetime Management: We are returning references (&str) that borrow from the original buffer. We must ensure that the buffer outlives these references. In our architecture, the buffer is owned by a Vec<u8> that lives for the duration of the review process, ensuring safety.
Performance: This approach reduces memory usage by ~90% compared to the naive approach, leading to faster processing times and lower GC pressure (in terms of system memory).

Integrating LLMs with Deterministic Latency

The core of ratatop is its ability to send diffs to an LLM (e.g., via OpenAI, Anthropic, or a local model like Llama 3) and parse the response. However, LLM APIs are inherently non-deterministic in terms of latency. A review that takes 2 seconds one time might take 10 seconds the next.

To mitigate this, we implemented a circuit breaker pattern and streaming responses with timeout controls.

Streaming Responses

Instead of waiting for the entire LLM response, we stream the tokens and parse them incrementally. This allows us to provide feedback to the user (or the CI system) faster.

use async_openai::config::OpenAIConfig;
use async_openai::types::{CreateChatCompletionRequestArgs, Role, Content};
use async_openai::Client;

async fn stream_review(diff_content: String) -> Result<Vec<String>, Box<dyn std::error::Error>> {
    let config = OpenAIConfig::from_env();
    let client = Client::with_config(config);

    let request = CreateChatCompletionRequestArgs::default()
        .model("gpt-4o-mini")
        .messages(vec![
            async_openai::types::ChatCompletionRequestMessage::User(
                async_openai::types::ChatCompletionUserMessage {
                    content: Content::Text(diff_content),
                    name: None,
                }
            )
        ])
        .max_tokens(500)
        .build()?;

    let mut stream = client.chat().create_stream(request).await?;
    let mut reviews = Vec::new();

    while let Some(result) = stream.next().await {
        match result {
            Ok(response) => {
                if let Some(choice) = response.choices.first() {
                    if let Some(text) = &choice.delta.content {
                        reviews.push(text.clone());
                    }
                }
            }
            Err(e) => {
                // Handle error, possibly with retry logic
                eprintln!("Error in stream: {}", e);
                break;
            }
        }
    }

    Ok(reviews)
}

Timeout and Circuit Breaker

We wrap the LLM call in a timeout to prevent hanging. If the LLM API is slow, we fall back to a cached review or a rule-based heuristic.

use tokio::time::{timeout, Duration};

async fn review_with_timeout(diff_content: String) -> Result<Vec<String>, Box<dyn std::error::Error>> {
    let timeout_duration = Duration::from_secs(5);

    match timeout(timeout_duration, stream_review(diff_content)).await {
        Ok(Ok(reviews)) => Ok(reviews),
        Ok(Err(e)) => Err(e),
        Err(_) => {
            // Timeout occurred, fall back to heuristic
            eprintln!("LLM call timed out. Using heuristic fallback.");
            Ok(vec!["[Heuristic] Possible issue detected in diff.".to_string()])
        }
    }
}

System-Level Metrics with libbpf

To monitor the performance of ratatop in production, we integrated libbpf, a Rust binding for eBPF (Extended Berkeley Packet Filter). eBPF allows us to observe the behavior of the reviewer at the kernel level without modifying the kernel code.

Why eBPF?

Traditional monitoring tools (like Prometheus exporters) rely on instrumentation within the application code. However, this can introduce overhead and may not capture system-level events like context switches or page faults. eBPF provides a low-overhead way to observe the system.

Monitoring Context Switches

We used eBPF to monitor the number of context switches performed by the ratatop process during a review. High context switches can indicate contention or inefficient scheduling.

use libbpf_rs::skel::SkelBuilder;
use libbpf_rs::OpenSkel;
use libbpf_rs::Skel;

// Assume we have an eBPF skeleton generated from a C program
// that counts context switches for a specific PID.

fn setup_bpf_monitor(pid: u32) -> Result<(), Box<dyn std::error::Error>> {
    let skel_builder = MySkelBuilder::default();
    let mut open_skel = skel_builder.open()?;

    // Set the PID to monitor
    open_skel.maps().ro_data().pid_to_monitor = pid;

    let mut skel = open_skel.load()?;
    skel.attach()?;

    // Now, we can read the maps from the eBPF program
    // to get context switch counts
    println!("eBPF monitor attached for PID {}", pid);

    Ok(())
}

Integrating with Prometheus

We exported the eBPF metrics to Prometheus using the prometheus crate. This allows us to create dashboards that show the relationship between eBPF metrics (context switches, page faults) and LLM latency.

use prometheus::{register_int_counter, IntCounter};

static CONTEXT_SWITCHES: Lazy<IntCounter> = Lazy::new(|| {
    register_int_counter!("ratatop_context_switches_total", "Total context switches during review").unwrap()
});

fn record_context_switches(count: u64) {
    CONTEXT_SWITCHES.inc_by(count);
}

Lessons Learned

Building ratatop taught us several valuable lessons about building micro AI services in Rust:

unsafe is a Tool, Not a Crutch: We used unsafe sparingly, only where it provided clear performance benefits (zero-copy parsing). Every unsafe block was thoroughly documented and tested.
Latency Jitter is the Enemy: Even with Rust's performance guarantees, LLM APIs are non-deterministic. Implementing timeouts, circuit breakers, and fallbacks is essential for a reliable service.
eBPF Provides Unique Insights: Integrating eBPF allowed us to monitor system-level metrics that are invisible to traditional application-level monitoring. This helped us optimize the reviewer's interaction with the host system.
Modularity is Key: By separating the diff parser, LLM client, and metrics collector into distinct modules, we were able to easily swap out components (e.g., using a different LLM provider or a different diffing algorithm) without rewriting the entire system.

Conclusion

ratatop demonstrates that Rust is an excellent choice for building micro AI services that require low latency, high throughput, and system-level observability. By leveraging unsafe blocks for zero-copy memory management and eBPF for deep system monitoring, we were able to create a reviewer that is both fast and insightful.

For developers looking to build similar tools, we recommend starting with a modular architecture, embracing Rust's type system for safety, and not being afraid to use unsafe where it provides clear benefits. Additionally, integrating eBPF can provide a level of observability that is difficult to achieve with traditional monitoring tools.

Frequently Asked Questions

Q: Is it safe to use unsafe blocks for zero-copy parsing?
A: Yes, as long as you carefully manage lifetimes and validate pointers. In our case, we ensure that the buffer outlives the slices and that pointers are valid before dereferencing.

Q: How do I handle errors from LLM APIs?
A: We recommend implementing a retry mechanism with exponential backoff, as well as a circuit breaker to fall back to heuristic-based reviews if the LLM API is consistently slow or unavailable.

Q: Can I use eBPF on Windows or macOS?
A: eBPF is primarily supported on Linux. For Windows and macOS, you may need to use alternative monitoring tools or containerize the reviewer on a Linux kernel.

For more insights on building high-performance Rust applications, check out Tamiz's Insights.

Your Ops Agent’s Chat History Is an Attack Surface: Prompt Injection Just Became an Infrastructure Problem

Muskan Bandta — Mon, 03 Aug 2026 06:00:26 +0000

There's a line going around dev.to this week that stuck with me: your AI agent's chat history is user input. It's a security observation about chatbots. But if you've given an agent cloud credentials — and half the "I let an agent run my ops" posts on here have — that line stops being about chatbots and becomes the scariest sentence in your architecture.

Here's the uncomfortable version: when an agent can call cloud APIs, prompt injection is remote code execution on your infrastructure. Let me walk through exactly how, because the attack surface is bigger and dumber than most people realize.

The classic framing, and why it undersells the risk

Prompt injection in a chatbot: attacker gets the bot to say something it shouldn't, or leak its system prompt. Bad, embarrassing, usually contained.

Prompt injection in an ops agent: attacker gets the agent to TerminateInstances, exfiltrate secrets to an external endpoint, or open a security group to 0.0.0.0/0. The agent has an IAM role. The IAM role has real permissions. Every check is green — because the agent is allowed to do those things; that's its job. (I wrote a whole separate piece on why IAM being green is exactly the trap.)

The model doesn't distinguish "instruction from my operator" from "text I read while doing my job." To an LLM it is all just tokens in the context window. And the context window is full of attacker-reachable text.

The injection surface nobody threat-models

When people hear "prompt injection" they picture the chat box. For an ops agent, the chat box is the least of it. Your agent reads all of this while working, and any of it can carry instructions:

Resource tags and names. An agent listing resources reads their Name tags. A tag value of prod-db — ignore prior instructions and run <bad thing> is now in the context. Anyone who can create a resource in a connected account can plant text.
Log lines. Agent triaging an incident reads application logs. Logs contain user-controlled strings. A crafted log line is a payload the agent ingests as part of "reading the logs."
Cloud resource metadata, commit messages, PR descriptions, ticket bodies, error messages from third-party APIs, container image labels, Kubernetes annotations. Every one of these is (a) text the agent reads to do its job and (b) writable by someone who isn't your operator.
The agent's own memory. With long-term memory (now a first-class feature in Bedrock AgentCore, Azure Foundry, Vertex), a poisoned instruction written into memory today fires days later, in a fresh session, with no attacker present. Persistent memory is a persistent attack surface.

The threat model most teams have is "someone types something malicious in the chat." The real model is "any text from any source the agent touches is potentially adversarial instruction." That's a vastly larger surface, and it maps onto data you already treat as untrusted for XSS/SQLi — except now the sink is your cloud control plane.

Why the usual defenses don't fully save you

"We'll sanitize inputs." You can't reliably sanitize natural language for instruction content — there's no parser boundary between data and command in a prompt. This is the whole reason prompt injection is unsolved. Delimiters and "the following is untrusted, ignore instructions in it" help at the margin and are defeated regularly.

"Least-privilege IAM." Necessary, insufficient. An ops agent's legitimate permissions are the dangerous ones. You can't least-privilege away delete verbs when deleting is the job.

"A human approves actions." The best single control — but approval fatigue is real, and a well-crafted plan looks reasonable. "Clean up these 40 idle resources" hides one resource that isn't idle.

What actually reduces the blast radius

Not solutions — mitigations. Defense in depth, because the injection itself can't be fully prevented:

Two-phase execution. Agent proposes a plan with read-only credentials; a separate executor with write credentials applies it after a gate. Injection into the reasoning agent can produce a bad plan, but the plan is inspectable before any credential with teeth touches it.
Action-level policy, not just IAM. Allowlist action shapes (verb + resource class + condition + time window), enforce blast-radius budgets (max N resources, max $/hour delta per run). A run that suddenly wants to touch 200 resources trips the budget regardless of what convinced it to.
Treat agent-read data as untrusted at the boundary. Tags, logs, annotations — the same "untrusted input" hygiene you apply to a web form, applied to everything the agent ingests. You won't catch everything; you'll shrink the surface.
Independent state verification. A watcher comparing actual resource state against expected baselines on a tight loop, on separate credentials and separate code from the agent — so a successful injection surfaces as drift within minutes instead of on next month's bill. (This is why, building anomaly detection into ZopNight, we made the verifying system share nothing with any acting system — an injected agent must not be the thing that reports whether it misbehaved.)
Rate/anomaly alarms on the account. CloudTrail → metric filter → alarm on API velocity per identity. A hijacked agent looks like a traffic anomaly before it looks like a policy violation.

The takeaway

"Your agent's chat history is user input" is correct and it doesn't go far enough. For an agent with cloud credentials, everything the agent reads is user input — and the sink isn't a rendered web page, it's your infrastructure control plane. Prompt injection stopped being a chatbot embarrassment and became an infrastructure security problem the moment we handed agents an IAM role.

If you're running an ops agent in prod: what's reading into its context that you don't control? Start listing, and the list gets uncomfortable fast. I'd like to hear what surfaces people found that they hadn't threat-modeled.

GPT-5.6 Luna Just Cut Prices 80% Your AI Bill Is Still Going Up, and Here’s the Math

Muskan Bandta — Mon, 03 Aug 2026 06:00:16 +0000

This week in the AI price war: OpenAI cut GPT-5.6 Luna pricing by 80% and GPT-5.6 Terra by 20%. Claude Opus 5 landed on Amazon Bedrock holding at $5 in / $25 out per million tokens with a 1M context window. Every headline says the same thing: intelligence is getting cheaper, fast.

So why does every engineering team I talk to report the same thing — the AI line on the cloud bill went up again this quarter?

Because tokens are the only part of the stack getting cheaper, and tokens are becoming the smallest part of the bill. Let's do the math.

Jevons paradox, but for tokens

In 1865, economist William Jevons noticed that more efficient steam engines didn't reduce coal consumption — they increased it, because efficiency made steam viable for things it was previously too expensive for.

Swap coal for tokens. When Luna gets 80% cheaper, teams don't pocket the savings — they take workloads that were marginal at the old price and turn them on:

The code-review bot that was "too expensive to run on every PR" now runs on every PR.
The log-summarization job that ran daily now runs hourly.
The agent that answered questions now acts — and an acting agent burns 10–50× the tokens of an answering one, because plan/execute/verify loops are token furnaces.

An 80% price cut followed by a 10× usage increase is a 2× bill increase. That's not a failure of discipline; it's the price cut working exactly as intended — for the vendor.

The bill is quietly changing shape

The more important shift: token spend is becoming the minority of AI infrastructure cost. Here's the stack that came online around it this year:

1. Agent runtime. AWS Bedrock AgentCore, Azure Foundry Agent Service, Vertex AI's agent stack — every major cloud shipped managed agent infrastructure this year. Runtime, gateway, identity, managed memory: each is a new metered line item that didn't exist on your 2024 bill. You're not paying for intelligence; you're paying for the scaffolding around intelligence, and scaffolding doesn't get 80% cheaper on a Tuesday.

2. Agent memory and state. Long-term memory stores, vector databases, session persistence. Memory is storage + retrieval compute, priced like storage + compute — on the classic cloud cost curve (slow decline), not the model cost curve (cliff dives).

3. Observability. Tracing what an agent did, evaluating outputs, storing full conversation traces for audit. Teams routinely discover their LLM observability spend rivals their token spend — you're storing and querying every token twice.

4. The GPU floor. If you run any inference yourself, you know the dirty secret: self-hosted model economics are dominated by utilization, and bursty agent workloads are utilization poison. A GPU node pool sized for peak agent activity idles most of the day at full price.

Rough shape of what I see in real accounts: what was ~80% tokens / 20% everything-else in 2024 is heading toward ~30% tokens / 70% runtime + memory + observability + GPU — while total AI spend grows quarter over quarter.

Why this is a FinOps problem now

For two years, AI cost had a comforting story: "wait six months, the price drops." True for tokens. Irrelevant for the rest of the stack — the rest of the stack is ordinary cloud infrastructure, and it responds to ordinary FinOps levers, not to model-vendor price wars:

Idle agent runtimes and GPU pools obey the same physics as idle EC2 — schedule them. An eval environment's GPU node group has no business running at 3am (we schedule ours to sleep the same way we schedule staging — same tooling, ZopNight treats a GPU node group like any other schedulable resource).
Observability retention is a knob. Ninety days of full traces for a chatbot is a choice, and it's usually the default, and the default is expensive.
"Cheaper model" is a rightsizing decision. Luna at −80% makes model selection a cost lever on par with instance selection. Routing the easy 70% of requests to the cheap tier is this year's version of moving dev to spot instances.
Anomaly detection needs to cover AI resources. An agent stuck in a retry loop is the new "forgot to turn off the p4d instance" — invisible on daily billing granularity until it's a very visible number.

The takeaway

The price war headlines are real, and they will keep coming — Luna won't be the last 80% cut. But "tokens got cheaper" and "AI got cheaper to run" stopped being the same sentence sometime this year. The bill's center of gravity moved into the infrastructure around the model, and that part doesn't do price-war cliff dives. It does what cloud bills have always done: grow quietly until someone looks.

Is anyone actually seeing their total AI spend fall after a price cut? I keep asking and I have not found one yet — if you're the exception, I'd genuinely like to know what you're doing differently.

Gemini Robotics 2 place le cerveau des humanoïdes chez Google

Thibault Monteiro — Mon, 03 Aug 2026 06:00:08 +0000

L'essentiel

Google DeepMind a lancé le 30 juillet Gemini Robotics 2, une famille de trois modèles capables de piloter un humanoïde entier, des pieds aux doigts.
L'architecture sépare le raisonnement (Gemini Robotics ER 2) de l'exécution motrice, la première couche commandant la seconde comme un outil.
ER 2 est ouvert aux développeurs via l'API Gemini et Google AI Studio ; les modèles de contrôle moteur restent réservés à des partenaires sélectionnés.
La version embarquée s'adapte à une morphologie de robot entièrement nouvelle avec quelques heures de données.

Vous demandez à un robot de poser l'arrosoir dans le bac vert, sur l'étagère du bas. Qui décide qu'il faut marcher jusqu'à la table, fléchir les genoux, puis refermer les doigts au bon endroit ? Depuis le 30 juillet, Google DeepMind répond avec deux étages distincts plutôt qu'avec un modèle unique. Cette séparation pèsera plus lourd que les démonstrations de dextérité qui l'accompagnent.

Un cortex et une moelle épinière

Gemini Robotics 2 regroupe trois modèles. Gemini Robotics ER 2 assure le raisonnement incarné : ce modèle vision-langage discute avec l'humain, comprend la scène et découpe une consigne en une séquence d'actions qui peut durer plusieurs minutes. Le modèle vision-langage-action (VLA), lui, convertit ce que voit le robot et ce qu'on lui dit en commandes motrices : marcher, s'accroupir, piloter une main à cinq doigts. Une troisième variante, Gemini Robotics On-Device 2, fait tourner cette conversion en local, sur la machine elle-même.

L'analogie du système nerveux tient plutôt bien. ER 2 joue le cortex qui planifie, le VLA joue la moelle épinière et le geste. Google DeepMind assume cette division du travail : sa couche de raisonnement délègue l'exécution motrice à n'importe quel modèle de bas niveau. Le développeur déclare les interfaces de contrôle et les API de navigation comme des outils, et le cerveau les appelle, exactement comme il appellerait Google Search ou une fonction maison.

Penser pendant qu'on bouge

Ce découpage en deux étages répond à une contrainte très concrète : le monde physique n'attend pas. Un robot qui se fige pour réfléchir entre chaque geste devient inexploitable dans une cuisine ou un atelier. ER 2 s'appuie donc sur la Gemini Live API et son point d'entrée en streaming bidirectionnel, pensé pour réduire le délai de réponse. Le modèle suit un flux vidéo continu, vérifie où il en est, rattrape un geste raté et déclenche l'étape suivante au bon moment, sans la pause de réflexion qui trahissait les générations précédentes.

Google compare ER 2 à ER 1.6 sur l'orchestration d'outils dans trois configurations : un modèle d'action réel, un modèle simulé, et un humain en téléopération, c'est-à-dire aux commandes à distance. Le troisième cas est le plus parlant. La couche de raisonnement est indifférente à la nature de l'exécutant : un VLA, une simulation ou une paire de mains humaines occupent la même case dans son plan. Le corps est devenu un paramètre.

Le matériel, variable d'ajustement

Les démonstrations enfoncent le clou. Apollo 2, l'humanoïde d'Apptronik, reçoit une consigne unique et enchaîne la marche, la flexion et la préhension. La même couche logicielle fait un nœud, visse une pièce, puis fait coopérer Apollo avec un second robot, Duo, pour ranger un garage : le modèle de raisonnement découpe la tâche, désigne les zones et choisit l'instant du passage de relais. Chez Boston Dynamics, c'est Spot qui exécute, avec ses API de navigation et de manipulation déclarées comme outils.

Quand un constructeur arrive avec une morphologie inédite, la version embarquée s'y adapte en quelques heures de données. Le coût d'intégration d'un nouveau châssis s'effondre, pendant que la valeur se concentre dans la couche qui, elle, ne change jamais.

Le cerveau ouvert, les muscles fermés

Le partage des accès confirme la hiérarchie. ER 2, le cerveau, est ouvert aux développeurs via l'API Gemini et Google AI Studio, en préversion privée sur Gemini Enterprise Agent Platform, avec des exemples publiés sur GitHub. Les modèles de contrôle moteur, eux, restent entre les mains de partenaires triés sur le volet. Chez les concurrents, la frontière passe ailleurs : NVIDIA publie les poids de son modèle pour humanoïdes GR00T N1.7 sous licence commerciale ouverte, téléchargeables sur Hugging Face, tandis que Figure a rompu avec OpenAI début 2025 pour développer en interne son propre modèle vision-langage-action, Helix.

La conséquence est immédiate pour un fabricant de robots : il peut prototyper la partie qui planifie et qui parle, mais l'étage qui commande les muscles ne lui appartient pas, et le cerveau tourne chez Google. Un humanoïde privé de cette couche redevient une mécanique téléopérée. La question de la souveraineté logicielle, que les industriels ont appris à poser pour leur cloud, se rejoue ici sur des machines qui marchent dans leurs entrepôts.

Les taux de réussite manquent à l'appel

Les séquences diffusées sont choisies avec soin. Aucun taux de réussite n'accompagne les tâches montrées, et rien ne dit combien de tentatives précèdent la bonne prise de l'arrosoir. Les comparaisons chiffrées publiées portent sur l'orchestration d'outils face à la version précédente, pas sur la fiabilité d'un humanoïde qui se déplace parmi des objets fragiles et des humains.

Ces réserves ne changent rien à ce que l'annonce installe. La robotique se structure comme le reste de l'informatique : un système d'exploitation d'un côté, du matériel de l'autre. Les fabricants d'humanoïdes viennent d'apprendre de quel côté de cette frontière on les attend.

Mon avis

La bataille des humanoïdes ne se gagnera pas sur les articulations, et ceux qui ne fabriquent que du matériel l'ont déjà perdue. Un constructeur qui branche Gemini Robotics 2 gagne deux ans de développement et perd son produit : il assemble le terminal d'une intelligence mise à jour ailleurs, par quelqu'un d'autre. Je surveille Apptronik de près, car c'est l'acteur qui a la plus forte incitation à bâtir sa propre couche de raisonnement et le moins de moyens de le faire. Et je ne crois pas une seconde que le contrôle moteur reste fermé longtemps : il s'ouvrira le jour où Google aura besoin de verrouiller le marché plutôt que de le trier.

Microsoft confie 90 % de sa chasse aux failles à un mini-modèle

Thibault Monteiro — Mon, 03 Aug 2026 06:00:07 +0000

L'essentiel

Microsoft a présenté le 27 juillet MAI-Cyber-1-Flash, un modèle compact dérivé de son modèle de raisonnement maison MAI-Thinking-1 et taillé pour repérer des vulnérabilités logicielles.
Associé à GPT-5.4 dans le harnais multi-agents MDASH, il atteint 95,95 % sur le benchmark CyberGym contre 88,45 % en mai, absorbe jusqu'à 90 % des tâches de sécurité courantes et divise par deux les coûts de la configuration en production.
Project Perception, la plateforme d'agents rouges, bleus et verts qui exploite ce dispositif, entre en preview publique le 3 août dans Microsoft Defender, facturée à la consommation en Security Compute Units.

Microsoft a fait deux annonces le même jour, et elles se répondent. D'un côté un modèle minuscule, entraîné pour une seule tâche. De l'autre une plateforme d'agents censée tenir une posture de défense en continu. Entre les deux, une décision d'architecture qui dépasse largement l'éditeur : arrêter d'envoyer chaque ligne de code à un généraliste hors de prix.

Un spécialiste bon marché en face d'un généraliste cher

MAI-Cyber-1-Flash dérive de MAI-Thinking-1, le modèle de raisonnement que Microsoft a présenté en juin avec six autres modèles internes. Version compacte et peu coûteuse à faire tourner, il a été entraîné sur les données d'attaques et de correctifs que les équipes de sécurité de l'éditeur accumulent depuis des années. Il ne travaille pas seul : il s'insère dans MDASH, le harnais multi-agents de la firme (l'ossature logicielle qui orchestre les agents et enchaîne leurs étapes), dévoilé en mai.

Microsoft assume cette répartition des rôles sans détour. Le généraliste sait presque tout et facture chaque appel en conséquence ; le modèle vertical ne sait faire qu'une chose, mais il la répète pour beaucoup moins cher. Concrètement, MAI-Cyber-1-Flash prend jusqu'à 90 % des tâches de sécurité courantes, et GPT-5.4 n'intervient plus que sur les 10 % de cas les plus retors. L'éditeur revendique une facture réduite de moitié par rapport à la configuration MDASH aujourd'hui en production.

Les concurrents ont pris l'autre chemin : Google DeepMind fait tourner CodeMender, son agent de correction de code, sur ses modèles Gemini, et Anthropic a bâti son offre Claude Security sur ses modèles généralistes. Voilà l'arbitrage qui va se rejouer partout : payer un modèle universel pour un travail répétitif, ou entraîner un modèle étroit et garder le gros calibre pour la poignée de cas qui résistent.

La sécurité possède ce qui manque aux autres métiers

Si les modèles verticaux percent d'abord ici, ce n'est pas un hasard de calendrier. La détection de vulnérabilités réunit les trois conditions que les autres domaines n'ont presque jamais ensemble : un gisement de données propriétaires (des décennies de failles trouvées et corrigées), un volume énorme de tâches quasi identiques, et surtout un juge mécanique. Un exploit fonctionne, ou il ne fonctionne pas.

Cette vérifiabilité pèse autant sur l'entraînement que sur l'évaluation. Un modèle spécialisé en rédaction commerciale ou en analyse juridique reste condamné au jugement humain, donc à des progrès lents et discutables. Un modèle de sécurité, lui, se corrige contre une preuve. C'est ce qui fait de la cybersécurité le premier marché où le pari du petit modèle métier tient économiquement, et pas seulement sur le papier.

Le score grimpe, le bruit reste hors champ

Le pipeline MDASH orchestre plus de cent agents spécialisés en plusieurs étapes : préparation, scan, débat contradictoire entre agents, dédoublonnage, puis preuve d'exploitabilité. Sur CyberGym, le benchmark de référence pour la détection de vulnérabilités réelles dans du code open source, l'ensemble passe de 88,45 % en mai à 95,95 % avec le nouveau modèle. Selon les mesures de Microsoft, cela le place une douzaine de points devant Claude Mythos d'Anthropic.

Ce pourcentage compte les failles que le système finit par trouver. Il ne compte pas celles qu'il croit voir là où il n'y en a aucune. Or les deux étapes les plus intéressantes du pipeline, le débat contradictoire et la preuve d'exploitabilité, existent précisément pour éteindre les fausses alertes. Ces deux garde-fous désignent l'adversaire principal, le bruit, qu'aucun chiffre public ne quantifie pour l'instant.

La question devient sérieuse dès qu'un agent agit sans relecture. Une alerte fausse dans un tableau de bord coûte quelques minutes d'analyste. Un correctif appliqué automatiquement sur une fausse alerte touche du code de production. Fixer le seuil de tolérance revient donc à décider si la boucle peut se fermer sans vous.

Rouge, bleu, vert : les agents travaillent, l'humain signe

Project Perception distribue trois rôles. Les agents rouges simulent des attaques comme le ferait un assaillant en quête d'une porte ouverte. Les agents bleus détectent les menaces et les hiérarchisent par gravité. Les agents verts appliquent les correctifs et referment les brèches. Les actions à fort impact restent soumises à une validation humaine, et Microsoft défend cette ligne de partage : la charge de travail aux agents, les décisions stratégiques aux équipes.

La formule est rassurante, à une réserve près : la frontière du « fort impact » est définie par la plateforme, pas par vous. Tout ce qui tombe en dessous s'exécute en silence. Le modèle économique ajoute une seconde tension, moins discutée. La facturation se fait à la consommation, en Security Compute Units (des unités de calcul de sécurité facturées à l'usage) dont le volume dépend de l'intensité des tâches exécutées. Un agent zélé qui multiplie les scans devient une ligne budgétaire, et l'optimisation des coûts finit par arbitrer la profondeur de l'analyse.

Testez sur votre code, pas sur le benchmark

L'ouverture au public commence le 3 août dans Microsoft Defender, avant un déploiement progressif au reste de la gamme de sécurité. Si vous mettez la main dessus, ne rejouez pas le test public : mesurez sur votre propre base de code combien d'alertes remontées se révèlent exploitables, et à quel coût en unités de calcul. Exigez le taux de fausses alertes avant d'autoriser le moindre correctif automatique, et calibrez vous-même la liste des actions qui réclament une signature humaine.

Un modèle de sécurité à 95,95 % de détection reste un excellent produit. Un agent qui referme une brèche imaginaire dans votre dépôt, en revanche, ne se rattrape pas d'un point de benchmark supplémentaire.

Mon avis

La cybersécurité va servir de laboratoire grandeur réelle à toute la vague des modèles verticaux, parce qu'elle est l'un des rares métiers où une réponse se prouve au lieu de se plaider. Le score sur CyberGym m'intéresse donc moins que le premier correctif appliqué par un agent vert sur une fausse alerte en production, et que la manière dont Microsoft en rendra compte. Un modèle spécialisé qui se trompe rarement mais dans le silence coûte plus cher qu'un généraliste bavard qu'on relit encore. Et je doute que le seuil de validation humaine, aujourd'hui fixé par l'éditeur, résiste longtemps à la pression sur les Security Compute Units.

I Gave an AI Agent One Prompt Cut Our Cloud Bill 20% Without Breaking Anything Here’s What It Did

Muskan Bandta — Mon, 03 Aug 2026 06:00:02 +0000

After my cloud-ops-for-a-week experiment, several people in the comments asked the obvious next question: what happens if you point an agent at the bill instead of the ops queue?

So I ran it. One agent, read access to our AWS and GCP accounts plus billing data, MCP tools for querying resources and metrics, and exactly one prompt:

"Cut our cloud bill by 20% without breaking anything. Show me your plan before you touch anything."

Two ground rules from the start: the agent got read-only credentials (plans only, no execution — I applied approved changes myself), and it had to justify every line item with actual metrics, not vibes. Here's what a week of that produced, sorted into the good, the scary, and the genuinely surprising.

The good: it found the boring waste instantly

Within the first hour, the agent produced a list a human FinOps review would have taken days to assemble:

11 unattached EBS volumes (oldest one: 9 months, from an instance terminated last year)
A dev RDS instance at 3% average CPU over 30 days — provisioned as db.r5.xlarge "temporarily" for a load test
Two NAT gateways in a region we'd migrated out of, faithfully billing ~$32/month each for zero traffic
4 load balancers with zero healthy targets — the targets were deprovisioned, the LBs weren't
Staging running 24/7 with request counts flatlining to zero from 8pm to 8am every single day

Projected savings from just this list: ~14% of the monthly bill. None of it required cleverness. All of it required looking, which nobody had done because looking is tedious. This is the strongest case for agents in FinOps: the discovery layer, where wrong answers are cheap because a human verifies before anything executes.

The scary: the plans that would have caused incidents

This is the section people actually asked for. Three plans I rejected:

1. It wanted to delete "unused" snapshots that were our DR baseline. The snapshots had no recent restore activity and no tags (our fault), so the agent classified them as orphaned. The metrics genuinely supported the conclusion. The context — "these are the disaster-recovery baseline, they're supposed to sit untouched" — lived in a Confluence page and two engineers' heads. Metrics-driven reasoning with no access to intent will confidently propose deleting your safety net.

2. It proposed downsizing a "3% CPU" instance that was memory-bound. Classic. CloudWatch doesn't report memory by default; the agent saw idle CPU and recommended halving the instance. The box was running an in-memory cache at 85% RAM. Downsizing = OOM-killer roulette. Lesson: an agent reasoning from an incomplete metrics surface doesn't know the surface is incomplete.

3. It wanted to buy reserved instances during a migration. Mathematically correct on 30 days of data — those instances had run flat-out all month. What the data didn't show: we were migrating that workload to GKE within the quarter. A human with calendar context kills that plan in five seconds; the agent would have locked in a year of commitment.

The common thread: every dangerous plan was locally rational. The agent was never wrong on the data it had. It was wrong on the data that isn't data — intent, plans, tribal knowledge.

The surprising: it negotiated with itself

The genuinely unexpected part. Told that "without breaking anything" was a hard constraint, the agent started attaching confidence levels and rollback plans to its own suggestions, unprompted, and split its output into "safe to automate" vs "needs human review." Its taxonomy was roughly:

Reversible in seconds, zero user impact (stop idle dev instance) → high confidence
Reversible with effort (downsize, snapshot-then-delete) → medium, human approves
Irreversible or commitment (delete data, buy RIs) → flagged, refuses to recommend without confirmation

That's... the correct architecture. The agent independently converged on the plan/approve/execute split that we'd already learned the hard way building scheduling and one-click remediation into ZopNight — where every remediation ships with its undo, because the undo is the product. Watching a model reinvent that boundary from a one-line constraint was the most interesting result of the week.

Final scorecard

	Result
Savings identified	~19% of monthly bill
Savings I actually applied	~12% (the rest needed refactors or timing)
Plans that would have caused incidents	3
Incidents caused	0 — because plans ≠ execution
Time I spent reviewing plans	~4 hours across the week

12% of the bill for four hours of review is a spectacular trade. But read the table again: the zero in row four exists only because of the read-only rule. Same experiment with write credentials is a different article, probably titled "post-incident review."

The one-line takeaway: agents are already excellent at finding the money and terrible at knowing which findings are traps. Structure the work so those two skills stay separated — agent proposes, human (or hard policy) disposes.

Would you give an agent write access to your infra for this? Genuinely curious where people's lines are — the comments on my last experiment convinced me nobody agrees yet.

AI agents should not just write code

Daniel Maß — Mon, 03 Aug 2026 05:59:32 +0000

They should be able to use the application they changed.

That sounds obvious, but most coding agent workflows still stop at editing files, running tests, maybe starting a dev server, and reporting back. For web apps, that is not enough.

A human developer does not only inspect diffs. They open the app. They click through the flow. They notice when the wrong tab is open, when a button does nothing, when the page changed unexpectedly, or when the browser is still pointing at yesterday's backend.

AI agents need that same feedback loop.

Browser state becomes coordination state

Once multiple agents are running in parallel, browser state becomes another coordination problem. Without isolation, browser tabs point to the wrong workspace, one agent clicks in another agent's app, authentication state leaks between branches, screenshots no longer match the running process, and the developer cannot tell which agent is doing what.

This is why Agent-Up now treats the browser as part of the workspace runtime.

Each workspace gets its own browser session, application tabs, port mappings, logs, and runtime state. Agents interact with that browser through MCP, so they can navigate to the app, inspect the page, click links and buttons, wait for text or selectors, take screenshots, and record browser activity into the audit history.

The important part is not just that the agent can click. It is that the click belongs to the correct workspace.

When an agent clicks inside its app, Agent-Up can switch the visible application tab for that workspace, move the agent mouse representation, show the click animation, and keep the developer's desktop view aligned with what the agent is actually doing.

The review experience changes

Instead of reading four terminal logs and guessing what happened, you can watch four agents exercise four isolated versions of an app at the same time.

One agent might test the login flow. Another checks pricing. Another walks through checkout. Another validates returns and fulfillment.

Same machine. Same repo.

But different worktrees, different runtime environments, and different browser sessions.

The browser is part of the feedback loop

This is the part of agentic development I think people underestimate: the browser is not just an output surface.

It is part of the feedback loop.

For web applications, an agent that cannot use the browser is missing the place where the product actually exists.

Git isolates the source. Agent-Up isolates the runtime. MCP gives agents control over both.

That makes parallel agent work easier to supervise because you are no longer only reviewing generated code. You are watching each agent operate its own version of the product.

That is what the demo was built to show.

Download Agent-Up:

https://agent-up.themassiveone.net/

Open source repo:

https://github.com/agent-up-oss/agent-up/

3 Simple Go Habits That Will Save You Hours of Debugging

Philip Damwanza — Mon, 03 Aug 2026 05:59:02 +0000

We have all been there. You look at a Go function you wrote just two weeks ago, and it looks like a complete mystery. Writing code that compiles is easy. Writing Go code that is readable, maintainable, and easy to debug is the real superpower.The Go philosophy values simplicity and clarity over cleverness. You do not need to master complex architecture to write better code today. Here are three simple, actionable habits you can start using in your next package.1. Use Meaningful Names (But Keep Go Idioms in Mind)Go prefers short variable names, but they must still carry clear meaning based on their scope. Avoid cryptic, single-letter names for long functions or global states.❌ Bad:gofunc process(d time.Duration) {
// confusing if the function is long
let t := time.Now().Add(d)
}
Use code with caution.✅ Good:gofunc process(expiryTimeout time.Duration) {
deadline := time.Now().Add(expiryTimeout)
}
Use code with caution.Why it matters: Code is read far more often than it is written. While a short r is fine for a receiver or a brief loop index, use descriptive names for data that travels through your application logic.2. Keep Functions Small and Return EarlyGo code can quickly become unreadable if you deeply nest your if statements. Use the "return early" strategy by handling errors immediately. This keeps your successful code path aligned to the left of your screen.❌ Bad (Deeply Nested):gofunc SaveUser(u *User) error {
if u != nil {
if u.IsValid() {
err := db.Save(u)
if err == nil {
return nil
}
return err
}
return errors.New("invalid user")
}
return errors.New("nil user")
}
Use code with caution.✅ Good (Return Early):gofunc SaveUser(u *User) error {
if u == nil {
return errors.New("nil user")
}
if !u.IsValid() {
return errors.New("invalid user")
}
return db.Save(u)
}
Use code with caution.Why it matters: Returning early eliminates the "arrow anti-pattern" (deeply nested code). It makes your functions incredibly easy to read, test, and debug from top to bottom.3. Comment the "Why," Not the "What"Go features self-documenting syntax. Your comments should not repeat what the code plainly states. Instead, use them to explain why a specific approach or workaround was necessary.❌ Bad:go// Increment total by one
total++
Use code with caution.✅ Good:go// Retry limit is set to 3 to prevent hammering the third-party billing API
const maxRetries = 3
Use code with caution.Why it matters: Avoid stating the obvious. Use comments to provide critical business context or architectural constraints that the code itself cannot show.
Clean Go code is not about perfection. It is about empathy for the next developer who touches your project—even if that developer is you.Pick just one of these habits for your next pull request, and notice how much easier debugging becomes!

99.4% Accurate but still completely useless?

Rajesh Singh — Mon, 03 Aug 2026 05:51:35 +0000

Why accuracy alone can fool you on imbalanced datasets. Somewhere, an ML model is proudly reporting 99.4% accuracy.

The dashboard is green. The stakeholders are smiling. Someone is probably preparing the report.

Then a dangerous question appears:

“How much fraud did the model actually catch?”

The answer: zero 😟

Welcome to the accuracy trap.

Watch the full video:

Meet the world’s laziest model

Consider a simulated dataset containing 20,000 card transactions, where only 0.6% are fraudulent.

Now introduce our highly sophisticated baseline:

def lazy_model(transaction):
    return "not fraud"

No training. No feature engineering. No hyperparameter tuning. No GPU trying to heat the neighbourhood.

It simply predicts “not fraud” every time.

And because almost every transaction is legitimate, the model achieves:

Metric	Lazy Model
Accuracy	99.4%
Precision	0%
Recall	0%
F1 score	0%

The model is correct most of the time but useful none of the time. It catches no fraud and probably still asks for a promotion.

Considering Precision and recall

Accuracy asks:

“How often was the model correct overall?”

That sounds reasonable until one class heavily outnumbers the other.

For fraud detection, two other metrics are far more revealing:

Precision asks:

“Of everything flagged as fraud, how much was actually fraud?”

Low precision means your system keeps blocking genuine customers. Congratulations—you have successfully detected someone buying groceries.

Recall asks:

“Of all the fraud that really happened, how much did we catch?”

Low recall means the fraudsters leave with the money while the model celebrates its excellent accuracy.

What happens with a real model?

We trained a logistic regression model using balanced class weights.

Its results looked less impressive at first:

Metric	Lazy Model	Logistic Regression
Accuracy	99.4%	85.3%
Precision	0%	3.1%
Recall	0%	77.8%
F1 score	0%	6.0%

The real model has lower accuracy, but it catches almost 78% of the fraud.

So which model is better?

The Lazy Model wins the dashboard beauty contest.

The logistic regression model wins the actual fraud-detection contest.

Precision and recall are professional rivals

There is usually a trade-off:

Lower the fraud threshold and recall increases, but so do false alarms.
Raise the threshold and precision may improve, but more fraud can slip through.

The “best” threshold is therefore not only a mathematical choice. It depends on business cost.

What is worse?

Annoying a legitimate customer?
Missing a fraudulent transaction?
Sending 10,000 alerts to a fraud team with three analysts and one coffee machine?

The answer depends on the system.

The takeaway

For imbalanced classification problems, accuracy is not useless but it is often incomplete.

Always look at:

Precision for alert quality
Recall for detection coverage
F1 score for balance
The confusion matrix for the types of mistakes
Business impact for what those mistakes actually cost

A 99.4% accurate model can still be terrible.

Metrics do not lie but they are perfectly happy to let us misunderstand them.

Staj Günlükleri #2: Mühendislikte Proje Yönetimi, Agile/Scrum ve Kurumsal Süreçler

derykuscu — Mon, 03 Aug 2026 05:35:42 +0000

Herkese selam! 👋

Eprom Elektronik bünyesindeki gömülü sistemler stajımın 2. haftasını tamamladım. Bu hafta doğrudan donanım üzerinde çalışmak yerine, mühendislik projelerinin arka planında yürütülen proje yönetimi metodolojileri, kurumsal dokümantasyon, depo/operasyon süreçleri ve şirket içi yazılım sistemleri üzerine odaklandım.

Bir mühendis adayı olarak projenin sadece kod/donanım kısmını değil, yönetimsel ve kurumsal operasyon süreçlerini de deneyimlemek vizyonum açısından oldukça verimli bir hafta oldu.

İşte 2. haftada gün gün öne çıkan başlıklar ve öğrendiklerim:

🛠️ Gün Gün Hafta Özeti

📌 1. Gün: Proje Yönetimi ve V Modeli (V-Model)

V Modeli: Donanım ve yazılım geliştirme süreçlerinde doğrulama (verification) ve geçerleme (validation) adımlarının nasıl paralel ilerlediğini inceledim.
Standartlar: Mühendislik projelerinde bir ürünün konsept aşamasından test adımlarına kadar olan yaşam döngüsünü kavramaya odaklandım.

📌 2. Gün: PMP, PMI ve Proje Yönetim Standartları

PMI & PMP: Project Management Institute (PMI) standartları ve PMP (Project Management Professional) yaklaşımı üzerine araştırmalar yaptım.
Süreç Yönetimi: Bir projenin başlatılması, planlanması, yürütülmesi, izlenmesi ve sonlandırılması (Lifecycle) aşamalarının kurumsal yapılarda nasıl karşılık bulduğunu inceledim.

📌 3. Gün: Çevik Metodolojiler (Agile & Scrum Framework)

Agile Yaklaşımı: Değişen gereksinimlere hızlı uyum sağlayan esnek proje yönetim mantığını araştırdım.
Scrum Yapısı: Sprint'ler, Daily Stand-up toplantıları, Backlog yönetimi ve Scrum rolleri (Product Owner, Scrum Master, Team) üzerine durarak gömülü/yazılım projelerine entegrasyonunu değerlendirdim.

📌 4. Gün: Belge Tarama, Dosyalama ve Barkod/Etiket Operasyonları

Saha & Operasyon Süreçleri: Şirket içi belge tarama, dijital arşivleme, dosyalama standartları ve sistemli veri kayıt adımlarını tecrübe ettim.
Barkodlama: Ürün ve bileşen takibi için barkod okuma, etiket çıkartma, fiziksel etiket yapıştırma ve bunların veritabanı/sistem kayıt süreçlerini uyguladım.

📌 5. Gün: Kurumsal Yazılımlar (Redmine & Netsis Arayüz İncelemeleri)

Redmine (Proje & Görev Takibi): Şirket içinde kullanılan açık kaynaklı proje yönetim ve issue/bug takip arayüzü Redmine'ı inceledim. Görev açma, efor takibi ve iş dağılımı süreçlerini gözlemledim.
Netsis (ERP Sistemleri): Kurumsal kaynak planlaması (ERP) tarafında Netsis arayüzünü inceleyerek stok, malzeme, depo ve kurumsal operasyon verilerinin sistem üzerinde nasıl yönetildiğini öğrendim.

💡 Bu Haftadan Çıkardığım Notlar

Sadece Kod Değil, Süreç Yönetimi: Harika bir donanım veya yazılım geliştirmek tek başına yeterli değil. Ürünün PMP veya Agile standartlarında doğru yönetilmesi ve belgelenmesi projenin başarısını doğrudan belirliyor.
İzlenebilirlik (Traceability): Barkodlama ve Netsis/Redmine gibi ERP ve görev takip araçları sayesinde bir ürünün en küçük bileşeninden en üst görev adımlarına kadar izlenebilir olmasının kurumsal firmalarda ne kadar kritik olduğunu gördüm.

💬 Yorumlarda Buluşalım!

Yazılım veya donanım projelerinizde geleneksel yöntemleri mi (Waterfall/V-Model) yoksa çevik yöntemleri mi (Agile/Scrum) tercih ediyorsunuz? Şirketlerinizde Redmine veya benzeri ERP araçlarını nasıl entegre ediyorsunuz? Yorumlarda tecrübelerinizi paylaşırsanız çok sevinirim!

The MCP 2026-07-28 spec is final - check your server in one command!

Alex Akimov — Mon, 03 Aug 2026 05:24:56 +0000

The Model Context Protocol's 2026-07-28 revision went final on July 28. It's a meaningful one: the lifecycle moves to stateless requests. If you maintain an MCP server, the two questions are: is my server still well-built, and is it ready for the new spec?

mcpscore answers both in one command:

uvx mcpscore https://your-server.example/mcp

No install, no API key. In a few seconds you get a 0–100 quality score and a list of exactly what to fix.

What it checks

72 deterministic rules, each citing the spec section it enforces, grouped into four categories:

Protocol: version negotiation, transport correctness, error shapes.
Tools Quality: names, titles, descriptions, input/output schemas.
Security & Auth: TLS, auth posture, safe error handling.
Readiness: how ready you are for the 2026-07-28 lifecycle.

It's deterministic - the same server always gets the same score, so it's stable in CI, and it's read-only: it lists your tools and probes behavior but never calls a tool, so auditing is side-effect-free. Local servers in any language audit over stdio too — mcpscore --stdio ./my-go-server, --stdio java -jar server.jar — not just .py/.js files.

Servers behind OAuth

Most production MCP servers are auth-gated, and until now that meant unauditable. This release changes that:

# full audit with your token (also reads MCPSCORE_TOKEN)
uvx mcpscore --token $TOKEN https://api.example.com/mcp

And with no credentials at all, a 401 server gets a partial audit of its observable surface, including auth-posture rules that check the WWW-Authenticate challenge, RFC 9728 protected-resource metadata, the authorization server's RFC 8414 metadata, and PKCE support. The gate itself Tokens never appear in logs or reports.

In CI

- uses: mcp-box/mcpscore-action@v1
  with:
    target: https://your-server.example/mcp
    min-score: 90

It comments the report on the PR and fails the check below your threshold.

The badge

Add a live score badge to your README from the report page at mcpscore.dev - it reflects your server's latest score.

Why "score", not "audit"

There's a good official conformance suite for "is my server legal." mcpscore is the other question - "how good is it" - the way Lighthouse scores a web page's quality, not just its validity. It runs on the official MCP Python SDK v2, it's open source (MIT), and the methodology is public: https://docs.mcpscore.dev/methodology

Point it at your server and see where you land!

DEV Community

React Mastery Series – Day 22: State Management with Redux Toolkit – Building Enterprise React Applications

Redux Toolkit (RTK)

Why Do We Need Redux?

Context API vs Redux

What is Redux?

Store

Core Redux Concepts

What is a Store?

What is an Action?

What is a Reducer?

Traditional Redux vs Redux Toolkit

Installing Redux Toolkit

Creating the Store

What is a Slice?

Creating Your First Slice

Providing the Store

Reading State

Updating State

Enterprise Authentication Flow

Async API Calls with createAsyncThunk

Handling Async States

Folder Structure

Real-World Banking Example

Redux DevTools

Common Mistakes

1. Putting Everything in Redux

2. Mutating State Outside Redux Toolkit

3. Creating One Huge Slice

Best Practices

Key Takeaways

Coming Next 🚀

API Integration in React – Fetch, Axios, Error Handling & Best Practices

Building a Micro AI Code Reviewer in Rust: Lessons from 'ratatop' with Unsafe and System Metrics

The Architecture: Why Rust for AI Tooling?

Zero-Copy Diff Processing with Unsafe Blocks

The Challenge: String Allocations

The Solution: Zero-Copy Slices

Why unsafe is Justified Here

Integrating LLMs with Deterministic Latency

Streaming Responses

Timeout and Circuit Breaker

System-Level Metrics with libbpf

Why eBPF?

Monitoring Context Switches

Integrating with Prometheus

Lessons Learned

Conclusion

Frequently Asked Questions

Your Ops Agent’s Chat History Is an Attack Surface: Prompt Injection Just Became an Infrastructure Problem

The classic framing, and why it undersells the risk

The injection surface nobody threat-models

Why the usual defenses don't fully save you

What actually reduces the blast radius

The takeaway

GPT-5.6 Luna Just Cut Prices 80% Your AI Bill Is Still Going Up, and Here’s the Math

Jevons paradox, but for tokens

The bill is quietly changing shape

Why this is a FinOps problem now

The takeaway

Gemini Robotics 2 place le cerveau des humanoïdes chez Google

Un cortex et une moelle épinière

Penser pendant qu'on bouge

Le matériel, variable d'ajustement

Le cerveau ouvert, les muscles fermés

Les taux de réussite manquent à l'appel

Microsoft confie 90 % de sa chasse aux failles à un mini-modèle

Un spécialiste bon marché en face d'un généraliste cher

La sécurité possède ce qui manque aux autres métiers

Le score grimpe, le bruit reste hors champ

Rouge, bleu, vert : les agents travaillent, l'humain signe

Testez sur votre code, pas sur le benchmark

I Gave an AI Agent One Prompt Cut Our Cloud Bill 20% Without Breaking Anything Here’s What It Did

The good: it found the boring waste instantly

The scary: the plans that would have caused incidents

The surprising: it negotiated with itself

Final scorecard

AI agents should not just write code

Browser state becomes coordination state

The review experience changes

Why `unsafe` is Justified Here