DEV Community: zecheng

Resize an Image to Exact Pixel Dimensions in Your Browser

zecheng — Fri, 24 Jul 2026 23:34:02 +0000

Updated 2026-07-15

To resize an image means to change its pixel dimensions—width and height—while preserving its visual content. Whether you're preparing a profile picture for LinkedIn (400×400 pixels), a Facebook cover photo (820×312 pixels), or a print-ready image for a flyer (300 DPI at 4×6 inches), exact dimensions matter. Most editing tools force you to download software, create accounts, or risk quality loss. Instead, use a browser-based Image Resizer to set the exact width or height you need, lock the aspect ratio, and download the resized file in seconds—no uploads, no watermarks, and no data sent to servers.

Resizing isn't just about making images smaller. Sometimes you need to enlarge a thumbnail for a poster or match a specific social media ratio. The key is maintaining proportions to avoid distortion. For example, a 1200×800 image resized to 600 pixels wide should automatically become 600×400—no manual math required. The Image Resizer handles this automatically with an aspect-ratio lock, so you only need to enter one dimension. It also lets you choose the output format: JPEG for photos, PNG for transparency, or WebP for web performance.

Why Browser-Based Resizing Works Best

Traditional methods—like Photoshop, GIMP, or even mobile apps—require installation, storage, and often a learning curve. Browser tools eliminate these barriers. The Image Resizer runs entirely in your browser, meaning the image never leaves your device. This is crucial for privacy, especially with sensitive photos like IDs or medical documents. It also means zero upload time, even for large files.

Another advantage is consistency. Unlike desktop software, which may vary across operating systems, browser tools deliver the same experience on Windows, macOS, Linux, or mobile. You don’t need to relearn menus or shortcuts. The interface is minimal: upload, set dimensions, download. No ads, no pop-ups, no hidden fees.

For developers and designers, browser resizing is a workflow accelerator. Need to batch-resize images for a website? Resize one, note the settings, and repeat. No need to open multiple files or navigate complex menus. The tool also supports drag-and-drop, so you can resize images directly from your file explorer or desktop.

Exact dimensions can change while the original image proportions remain consistent.

When to Resize an Image

Resizing is essential in many scenarios:

Websites and blogs: Large images slow down page loads. Google’s PageSpeed Insights recommends serving images at the exact display size to improve performance. For example, a hero image displayed at 1200×600 pixels should be resized to those dimensions—not uploaded at 4000×2000 and scaled down with CSS.
Social media: Each platform has strict dimension requirements. Instagram posts are 1080×1080 pixels, Twitter headers are 1500×500, and LinkedIn banners are 1584×396. Uploading the wrong size forces the platform to crop or stretch your image, ruining composition.
Email marketing: Most email clients block images larger than 1MB or wider than 600 pixels. Resizing ensures your images display correctly and don’t trigger spam filters.
Print projects: While print resolution is measured in DPI (dots per inch), pixel dimensions still matter. A 4×6-inch photo at 300 DPI requires 1200×1800 pixels. Resizing ensures the image fits the print area without pixelation.
Mobile apps: App icons, splash screens, and in-app images must match specific dimensions. For example, an iOS app icon is 1024×1024 pixels, while Android requires 512×512. Resizing ensures compatibility across devices.

How to Resize an Image Using the Browser Tool

Follow these steps to resize any image to exact pixel dimensions:

Upload your image: Drag and drop the file into the Image Resizer or click to select it from your device. The tool supports JPG, PNG, WebP, GIF, BMP, and TIFF formats. The original dimensions will load automatically.
Set the new dimensions: Enter the width or height you need in pixels. The tool locks the aspect ratio by default, so entering one value automatically adjusts the other. For example, if your original image is 1600×900 and you set the width to 800, the height will update to 450. To unlock the aspect ratio, toggle the lock icon—use this only if you intentionally want to stretch the image.
Choose the output format: Select PNG, JPEG, or WebP. PNG is best for images with transparency (like logos), JPEG for photos, and WebP for web use (smaller file size without quality loss).
Download the resized image: Click the download button. The file will save to your device with the new dimensions and format. No watermarks, no compression artifacts (unless you choose JPEG with high compression).

Resizing vs. Compressing: What’s the Difference?

Resizing and compressing are often confused, but they serve different purposes:

Action	What It Changes	When to Use	Tools
Resizing	Pixel dimensions (width × height)	When you need an image to fit a specific display size (e.g., social media, print, website)	Image Resizer, Photoshop, GIMP
Compressing	File size (KB or MB) without changing dimensions	When you need to reduce load times (e.g., web images, email attachments)	Image Compressor, TinyPNG, Squoosh

Resizing reduces the number of pixels, which can also reduce file size. For example, a 4000×3000 image (12 megapixels) resized to 800×600 (0.48 megapixels) will be significantly smaller. However, if you need to keep the original dimensions but reduce file size, use a compression tool instead. For best results, resize first, then compress.

Here’s a quick example: A 5MB JPEG photo (4000×3000 pixels) resized to 800×600 pixels might drop to 200KB. If you then compress it further with a tool like Image Compressor, you could reduce it to 100KB without visible quality loss—ideal for web use.

Keeping the ratio locked prevents accidental stretching during an exact-dimension resize.

Common Resizing Mistakes to Avoid

Resizing seems simple, but small errors can ruin an image:

Ignoring aspect ratio: Stretching an image to fit non-proportional dimensions distorts it. Always keep the aspect ratio locked unless you’re intentionally creating a surreal effect.
Upscaling small images: Enlarging a low-resolution image (e.g., 200×200 to 2000×2000) makes it pixelated. Use high-resolution originals whenever possible. If you must upscale, tools like AI-based enhancers can help, but results vary.
Using the wrong format: Saving a photo as PNG (which supports transparency) instead of JPEG can bloat the file size. Similarly, using JPEG for text-heavy images (like screenshots) causes compression artifacts. Refer to our guide on JPEG vs PNG vs WebP for format recommendations.
Overlooking DPI for print: While DPI (dots per inch) doesn’t affect digital images, it matters for print. A 300 DPI image at 4×6 inches requires 1200×1800 pixels. Resize to these dimensions before printing to avoid blurriness.
Not previewing the result: Always check the resized image before using it. Zoom in to 100% to spot pixelation or artifacts, especially around edges and text.

Advanced Tips for Perfect Resizing

For more control over your resized images, try these techniques:

Batch resizing: If you have multiple images to resize to the same dimensions, use the Image Resizer for each one. For larger batches, consider desktop tools like XnConvert or IrfanView, which support batch processing.
Resizing for social media: Use platform-specific dimensions to avoid cropping. For example, Instagram’s 1:1 ratio (1080×1080) works for posts, but Stories require 1080×1920 (9:16). Bookmark dimension guides for quick reference.
Resizing with transparency: If your image has a transparent background (like a logo), always save it as PNG or WebP. JPEG doesn’t support transparency and will fill the background with white or black.
Resizing for accessibility: Ensure text in images remains readable after resizing. The Web Content Accessibility Guidelines (WCAG) recommend a minimum contrast ratio of 4.5:1 for text. Use the Image Color Picker to check contrast before and after resizing.
Resizing for email: Most email clients block images wider than 600 pixels. Resize images to 600 pixels wide or smaller to ensure they display correctly. For retina screens, double the dimensions (e.g., 1200×600) and let the email client scale them down.

Resizing Images on Mobile Devices

Resizing on a phone or tablet is just as easy as on a desktop. The Image Resizer works on iOS and Android without installing an app. Here’s how:

Open your mobile browser and go to Image Resizer.
Tap the upload area to select an image from your gallery or take a new photo.
Enter the new width or height. The tool will adjust the other dimension automatically.
Choose the output format (PNG, JPEG, or WebP).
Tap "Download" to save the resized image to your device.

For frequent resizing, add the tool to your home screen for quick access. On iOS, tap the "Share" button and select "Add to Home Screen." On Android, tap the three-dot menu and select "Add to Home screen."

Alternatives to Browser Resizing

While browser tools are convenient, other methods work for specific needs:

Photoshop: Ideal for professional editing. Use "Image > Image Size" to resize, then export with "Save for Web" to optimize file size. Photoshop also supports batch resizing via "File > Scripts > Image Processor."
GIMP: A free alternative to Photoshop. Resize via "Image > Scale Image," then export as PNG or JPEG. GIMP also supports batch processing with plugins.
Canva: Great for social media graphics. Upload your image, then drag the corners to resize. Canva’s crop tool also helps fit images to specific ratios.
Command-line tools: Developers can use tools like ImageMagick or Node.js libraries (e.g., Sharp, Jimp) to resize images programmatically. For example, with ImageMagick: convert input.jpg -resize 800x600 output.jpg.
Mobile apps: Apps like Snapseed (iOS/Android) or Adobe Lightroom Mobile offer resizing features, but they require installation and may include ads or in-app purchases.

For most users, browser tools strike the best balance between simplicity and power. They’re free, private, and work on any device—no downloads or accounts required.

If you're weighing options, Turn Multiple Images into One PDF in Your Browser covers this in detail.

If you're weighing options, Generate a Meme with AI Text in Your Browser Instantly covers this in detail.

Frequently asked questions

Does resizing an image reduce quality?

Resizing can reduce quality if you enlarge a small image (upscaling), which causes pixelation. Shrinking an image (downscaling) usually maintains quality, especially if you use a high-quality resizing algorithm. The Image Resizer uses a bilinear algorithm to minimize quality loss.

Can I resize multiple images at once?

The Image Resizer processes one image at a time. For batch resizing, use desktop tools like XnConvert, IrfanView, or Photoshop’s batch processing feature. Alternatively, resize each image individually in the browser tool—it’s fast and doesn’t require installation.

What’s the best format for resized images?

Use JPEG for photos, PNG for images with transparency (like logos), and WebP for web use (smaller file size with good quality). The Image Resizer lets you choose the format before downloading.

How do I resize an image without stretching it?

Keep the aspect ratio locked when resizing. The Image Resizer does this by default—enter one dimension, and the other adjusts automatically. If you unlock the aspect ratio, the image will stretch to fit the dimensions you enter.

Can I resize an image for print?

Yes, but you’ll need to know the print dimensions and DPI (dots per inch). For example, a 4×6-inch photo at 300 DPI requires 1200×1800 pixels. Resize to these dimensions before printing to avoid blurriness.

Is it safe to resize images in a browser?

Yes, the Image Resizer processes images locally in your browser—no files are uploaded to a server. This makes it safe for sensitive images like IDs, medical documents, or confidential work files.

Disclosure: This article was drafted with AI assistance. Its factual claims were checked against the cited sources and the live tool page before publication.

A Practical Browser-Side Image Compression Workflow for Web Teams

zecheng — Fri, 24 Jul 2026 01:09:18 +0000

Image compression becomes easier to reason about when it is treated as a pipeline rather than a single slider. A user selects a file, the browser reads it, a working image is scaled to an intended output size, an encoder produces a new blob, and the application gives the user a clear result. Each stage has a distinct responsibility. Keeping those responsibilities separate makes the feature easier to test, easier to explain, and less likely to surprise someone who is uploading an important photo.

For a lightweight prototype, start with a normal file input and a visible before-and-after result. A browser-based tool such as Lizely Image Compressor can be useful for checking the user flow, but the engineering principle applies to any client-side implementation: do not claim more privacy, speed, or quality than the actual path provides.

Define the output contract before coding

The implementation needs a written contract. Decide which MIME types are accepted, the maximum input size, the maximum output dimensions, the target MIME type, and what happens when an image cannot be decoded. These are product choices as well as technical choices. A social upload flow may prioritize a quick result. A photography workflow may prioritize pixel preservation and ask the user before applying a large reduction.

The MDN File API overview is a useful reference for the basic browser objects involved. The selected File carries metadata such as name, type, and size, while browser APIs can create temporary object URLs for previews. Treat that metadata as helpful rather than authoritative. File extensions and declared types can be wrong, so decoding should still be prepared to fail gracefully.

Set limits early. Rejecting an enormous or unsupported file with a clear message is better than leaving a page frozen while memory use grows. The message should say what the user can do next: choose a smaller file, export a supported format, or reduce dimensions before returning. Avoid a vague generic error when the real issue is known.

A predictable browser-side pipeline turns an input file into a smaller output blob.

Build a predictable processing sequence

First, read the selected file and decode it into an image representation that can be drawn. Next, calculate dimensions while preserving aspect ratio. A common rule is to cap the longer side, not to force both width and height to fixed values. That avoids stretching portraits into landscapes or turning a square product image into a rectangle.

Then draw into a canvas at the calculated dimensions. Exporting the canvas with toBlob gives an asynchronous boundary where the application can update progress state, disable duplicate submissions, and show a useful failure message. The HTMLCanvasElement.toBlob documentation describes the callback-based export and its resulting Blob. In practice, this is also a good place to record the chosen output type and quality setting for debugging.

Do not replace the original preview until the new output exists. Users should be able to compare dimensions and bytes before they decide to download or upload the result. Show the original file size, output file size, output dimensions, and a plain description of the selected format. If a quality value is exposed, label it as a request to the encoder, not a promise that every image will shrink by the same percentage.

The output contract and error paths are part of a trustworthy compression feature.

Make quality decisions visible and reversible

Lossy encoding is not a neutral transformation. JPEG and WebP quality settings trade detail for fewer bytes, while a resize removes pixels permanently from the working copy. A good UI lets a user run the operation again from the retained original rather than compressing an already compressed output a second time. Repeated encoding is a subtle source of avoidable artifacts.

Use a small set of understandable presets if a full quality slider creates uncertainty. For example, “smaller file,” “balanced,” and “more detail” can map to tested configurations. The labels should be backed by visual checks on representative inputs: a smooth gradient, a dark photograph, a high-contrast product edge, and an image with small text. These cases expose different weaknesses in an encoder setting.

Format choice deserves the same honesty. The MDN image format guide summarizes the tradeoffs among common web formats, while web.dev's image performance guidance connects those choices to the bytes a page must deliver. Your server, CDN, and target browsers determine which choices are viable in production. A client-side feature should not silently produce a type that downstream systems reject. If a fallback is needed, show the final type to the user and test that it reaches the destination intact.

Test failure paths as seriously as happy paths

A compression feature is often tested with one perfect landscape image and then considered complete. That misses the cases users actually bring: a phone photo with unusual metadata, an animated file, a transparent asset, an image too large for available memory, or a canceled selection. Each case needs a safe end state. The page should return to an upload-ready state, retain the original selection when appropriate, and avoid presenting a broken download link.

Automated tests can cover the dimension calculation and output policy without decoding a real photo. Browser-level tests can cover the selection, progress, cancel, and download behavior. Manual checks should include a slow device profile because a smooth desktop experience can hide poor feedback during mobile processing. The goal is not to eliminate every limit; it is to make limits explicit and recoverable.

Observability helps after launch. Record non-sensitive aggregate events such as file type, input-size range, selected preset, output-size range, and error category. Do not collect the image itself simply to diagnose a generic failure. Metrics should tell the team whether defaults are useful without turning a local utility into an unexplained data collection path.

Ship a small, trustworthy first version

The best first release usually handles a narrow set of image types, shows exactly what it changes, preserves the original during the session, and provides a reliable download. Add advanced formats, batch work, or background processing only after the basic path is stable. This sequence makes support easier because users can describe a concrete step where the result changed.

Browser-side compression is valuable when it removes friction without hiding the tradeoffs. Define the contract, keep the original available, expose the resulting file properties, and design every failure to leave the user with a next action. That is a stronger foundation than a dramatic percentage-saved claim that cannot be reproduced.

Implementation checklist

Before release, verify accepted types and size limits, aspect-ratio preservation, output MIME behavior, preview cleanup, repeated-run behavior, cancellation, download naming, and meaningful error messages. Test representative photos and transparent graphics. Finally, test the complete route that receives the generated file, because a correct browser blob is only useful if the next system accepts it.

Disclosure: This article was drafted with AI assistance. Its factual claims were checked against the cited sources and the live tool page before publication.

Build an Image Budget That Your Website Can Actually Keep

zecheng — Thu, 23 Jul 2026 01:19:17 +0000

Image optimization often fails because a team treats it as a final cleanup task. Someone notices that a page feels slow, compresses a few visible files, and moves on. New screenshots and product images then arrive with no shared limit, so the page becomes heavy again.

A more durable approach is to create an image budget: a small set of measurable rules for file size, dimensions, format, and visual acceptance. The budget turns compression from an occasional rescue operation into a repeatable publishing decision. It also gives writers, designers, and developers the same definition of “ready.”

This guide explains how to create that workflow for documentation, landing pages, release notes, and other content where images must stay useful while loading efficiently.

Start with the job each image must do

Do not begin by choosing one universal size limit. First classify the image by its purpose. A hero photograph, a product screenshot, a small logo, and a diagram lose value in different ways.

The W3C image decision tree separates informative, decorative, functional, and text-containing images because their roles affect how they should be presented. That same classification is valuable before compression. An informative chart must preserve labels. A functional icon must remain recognizable. A decorative background can usually tolerate more aggressive reduction because it does not carry essential meaning.

Create a short inventory before setting limits:

Hero and marketing images support visual identity and first impressions.
Interface screenshots explain a procedure or prove that a feature exists.
Diagrams communicate relationships that may be difficult to express in prose.
Thumbnails help people scan a collection but are not usually inspected in detail.
Logos and icons depend on clean edges, transparency, and consistent dimensions.

This inventory prevents a common mistake: applying the same quality setting to every file. The target is not identical compression. The target is consistent usefulness within a predictable transfer budget.

Define budgets at the page level first

An individual image can appear reasonably small while the complete page remains expensive. Ten files at 300 KB each still create roughly 3 MB of image transfer before scripts, styles, fonts, or video are counted. Start with the total page experience, then divide that allowance among assets.

For a documentation article, you might decide that all initially visible images should stay below a combined amount, while screenshots further down the page can load later. For a landing page, the largest above-the-fold visual deserves the strictest review because it can delay the moment when the page looks complete.

Write the limits in plain language. A useful first version might say:

Every image must have a stated role and intended display width.
No exported file may contain substantially more pixels than its largest display size requires.
The initially visible image set must remain within the page's agreed transfer allowance.
Important text, controls, and chart labels must survive a normal-size review.
The original source file must remain available for future exports.

The exact numbers will vary by site, audience, and network conditions. The important part is that the rules can be checked before publication rather than debated after a performance problem appears.

Match dimensions and format to the delivery context

Pixel dimensions and encoded file size are related but separate. A 2800-pixel-wide screenshot displayed in a 900-pixel content column often carries data that readers never receive as visible detail. Creating an appropriately sized derivative can remove that excess before quality settings are adjusted.

Format then determines which kinds of information can be represented efficiently. The MDN guide to web image formats documents differences in compression, animation, transparency, and browser support. Use those characteristics as constraints rather than treating the newest format as an automatic winner.

PNG remains useful for lossless graphics, transparency, and sharp synthetic content. JPEG is widely supported and often effective for photographs, but it can introduce visible artifacts around hard edges. WebP can provide lossy or lossless output and works well for many mixed-content images. The correct choice depends on the asset and the systems that must accept it.

Ask four questions for every export:

What is the largest width at which this asset will actually be displayed?
Does it need transparency or exact pixel preservation?
Is the visual mostly photographic texture, flat graphics, or a mixture?
Will a CMS, email client, marketplace, or partner site reject the chosen format?

Answers to those questions narrow the options before time is spent tuning compression.

Use a controlled local compression pass

Once the budget and format are known, work from the preserved original. Do not repeatedly edit an already compressed derivative, because each lossy export can discard more information and make later comparisons unreliable.

Open the Lizely image compressor for JPG, PNG, and WebP and process a working copy. The tool runs in the browser, which is useful when an image contains an unreleased interface, an internal dashboard, customer data that has already been redacted, or other material that should not be uploaded to an unknown conversion service.

Use a small-step process:

Record the original dimensions and file size.
Export at the dimensions required by the layout.
Choose a format that the destination supports.
Start with a conservative quality setting.
Compare the result with the original at the intended display size.
Inspect one critical region at full resolution.
Reduce quality gradually until the file enters its budget.
Stop when the budget is met; do not chase the smallest possible number.

The final step matters. Extra compression after the requirement has been satisfied creates visual risk without improving the acceptance result. A 145 KB file that is clear is better than a 90 KB file with damaged labels when the agreed maximum is 160 KB.

Review the output with role-specific checks

Visual acceptance should reflect the purpose identified earlier. A generic “looks okay” review is difficult to repeat and easy to rush.

For screenshots, confirm that controls, menu labels, status messages, and cursor targets remain understandable. For diagrams, inspect arrows, legends, color distinctions, and small annotations. For photographs, look for block patterns, banding in gradients, and unnatural detail loss around the subject. For logos and icons, check transparency, edge shape, and contrast at the smallest displayed size.

The reviewer should also confirm operational facts:

The saved file opens in a standard browser.
Its extension matches its real encoded format.
Its dimensions match the intended responsive slot.
Its measured size is inside the assigned asset budget.
The page does not download both an obsolete original and the optimized version.
Alternative text or nearby explanatory text still describes the image's purpose.

If the publishing platform generates its own derivative, review the delivered page rather than only the local export. A CMS may resize or recompress an accepted file, and that second transformation can change the result.

Make the budget part of publishing

A budget only works when someone owns it. Add the image checks to the same checklist used for links, headings, metadata, and mobile layout. Store originals separately from web-ready derivatives, and use filenames that identify the asset without embedding temporary quality values that will confuse future editors.

For frequently updated sites, record the display width and maximum size in the content template. This reduces guesswork for the next contributor. Teams with a build pipeline can also report oversized assets during review, but automated size checks should complement visual inspection rather than replace it. Software can measure bytes and dimensions; it cannot reliably decide whether a tiny error message is still readable in its real context.

Revisit the limits after measuring real pages. If contributors constantly miss a target despite careful exports, the budget may be unrealistic or the design may be requesting too many visuals. If every file passes easily, the limit may be too loose to influence behavior. Treat the first numbers as testable operating rules, not permanent laws.

A compact pre-publish checklist

Before approving an image-heavy page, verify the following:

Every image has a clear role.
Display dimensions are known.
Source originals are preserved.
Formats match the visual content and destination support.
Individual files and the combined page stay within the agreed budget.
Critical visual information passes a normal-size review.
The final published derivatives have been checked in the browser.

This process makes optimization predictable. More importantly, it connects performance with meaning: a successful image is light enough to deliver efficiently and clear enough to do the job for which it was added.

Frequently asked questions

Should every page use the same image budget?

No. A product gallery and a text-heavy guide have different purposes. Use shared principles, but set page-level limits that reflect the experience being delivered.

Is resizing more important than changing quality?

Both matter. Correct dimensions remove pixels the layout does not need, while compression controls how the remaining image data is encoded. Decide dimensions first, then tune the format and quality.

Can automated checks replace visual review?

No. Automation can reject files that exceed byte or dimension limits, but a person still needs to confirm that labels, controls, diagrams, and photographic details remain useful.

When should the original be deleted?

Keep it as the rollback and re-export source. A future layout, format, or accessibility requirement may need a new derivative that cannot be recovered from a compressed file.

Disclosure: This article was drafted with AI assistance. Its factual claims were checked against the cited sources and the live tool page before publication.

How to Safely Execute AI-Generated Python Code in Agent Workflows (No Docker Required)

zecheng — Thu, 19 Mar 2026 23:21:26 +0000

Pydantic Monty is a minimal, Rust-written Python bytecode VM that executes AI-generated code in 0.004ms with zero filesystem or network access by default — the missing infrastructure piece for production-grade AI agent workflows.

If you've tried to build a real AI agent that writes and runs its own Python code, you've hit the same wall: you can't hand arbitrary code to CPython. Docker solves the isolation problem but adds 195ms of startup latency per execution. For an agent making dozens of code-execution decisions per task, that compounds to seconds of overhead per workflow. Sandbox cloud services (Modal, E2B) cut it to ~1000ms. Still too slow. Monty cuts it to 0.004ms because it runs inside your existing process — no container spawn, no network call.

Samuel Colvin, the creator of Pydantic, built it and released v0.0.1 on January 27, 2026. It hit 2,600 GitHub stars within 48 hours. As of v0.0.8 (March 10, 2026), it is experimental but already usable for constrained code-execution use cases.

Why AI Agents Need a Code Execution Layer at All

The standard way to give an AI agent "tool use" is sequential function calling: the model selects a tool, gets a result, selects the next tool, gets the next result, and so on. This works, but it is expensive — each round-trip is a separate LLM inference call.

There is a faster pattern: instead of sequential tool calls, ask the model to write a short Python script that calls your tools as functions, then execute that script in one shot. Colvin calls this "CodeMode." The measured result: tasks that previously required 4 LLM round-trips complete in 2 calls when using CodeMode with asyncio.gather() for parallel tool invocations.

The problem is obvious. Giving an LLM the ability to write and execute arbitrary code means giving it access to your filesystem, your network, your environment variables, and your process. A sandboxed CPython is still CPython — the entire standard library is one import os away.

Monty solves this by not running CPython at all.

How Pydantic Monty's Security Model Actually Works

Monty's security philosophy is "start from nothing, move right." The default execution environment has zero capabilities:

Every capability the AI code can use must be explicitly granted through external functions — host-defined callables you register before execution. The VM can only call what you've explicitly allowed.

import pydantic_monty

code = """
result = search_web(query="pydantic monty benchmarks")
summary = summarize(text=result)
return summary
"""

m = pydantic_monty.Monty(
    code,
    inputs=["query"],
    external_functions=["search_web", "summarize"],
)

m.run(
    inputs={"query": "pydantic monty"},
    external_functions={
        "search_web": my_search_function,
        "summarize": my_summarize_function,
    }
)

The AI can call search_web and summarize because you registered them. It cannot call requests.get() or subprocess.run() because those are not registered — and the underlying modules don't exist in the VM at all.

Configurable execution limits — memory allocation, stack depth, CPU time — are enforced at the VM level. Hit the threshold, execution cancels. No runaway loops.

Startup Latency: The Real Performance Comparison

The performance story is straightforward once you understand the architecture. Monty doesn't spawn a process — it runs as a library inside your existing Python, Rust, or JavaScript process.

Execution method	Startup latency	Notes
Pydantic Monty	0.004–0.06ms	Embedded in host process
Docker container	~195ms	Process + container init
Pyodide (WebAssembly)	~2800ms	WASM initialization
Modal / E2B (cloud sandbox)	~1000ms+	Network round-trip

The 4.5MB package size with no external dependencies also means Monty ships inside your existing binary. No sidecar process, no daemon to manage.

For agent workflows where code execution is on the hot path — not an occasional capability but a step in every task — this latency profile changes what's architecturally feasible.

Installation and First Execution

Install via pip or uv:

uv add pydantic-monty
pip install pydantic-monty

JavaScript/TypeScript:

npm install @pydantic/monty

A minimal execution:

import pydantic_monty as monty

m = monty.Monty('x * y', inputs=['x', 'y'])
result = m.run(inputs={'x': 5, 'y': 3})
print(result)  # 15

Type checking against stubs is optional but recommended for AI-generated code — it catches type errors before execution rather than at runtime:

type_stubs = """
x: int
y: int
"""

m = monty.Monty(
    'x * y',
    inputs=['x', 'y'],
    type_check=True,
    type_check_stubs=type_stubs,
)

What Python Subset Monty Supports Right Now

Monty is experimental. v0.0.8 supports:

Functions (sync and async), closures, comprehensions, f-strings
asyncio, typing, partial os (stub), sys (stub)
Full math module (50+ functions, added in v0.0.8)
Dataclasses injected from the host
Bigint literals, PEP 448 generalized unpacking
Controlled in-memory filesystem abstraction

Not yet supported (on the roadmap): class definitions, match statements, context managers, generators, re/datetime/json modules.

The missing class support sounds limiting until you consider the primary use case. LLMs generating code for tool orchestration rarely need to define classes — they need to call functions, transform data, and return results. The subset Monty supports covers most CodeMode patterns.

Serializable Execution State: Why This Matters for Durable Agents

One underrated feature: Monty can serialize both parsed bytecode and live execution state.

code_bytes = m.dump()

m2 = monty.Monty.load(code_bytes)
result = m2.run(inputs={"x": 10})

Execution state snapshots are single-digit kilobytes. This enables agent workflows that survive process restarts — you can store the execution state in a database, resume it in a different process, and the agent picks up exactly where it left off. For long-running background agents, this is the difference between "restartable" and "durable."

The PydanticAI Integration Coming Up

The production use case Colvin is building toward is PydanticAI's CodeMode — an official integration that will let PydanticAI agents generate and execute Python code through Monty. Colvin confirmed this directly on Hacker News: "That's exactly what we built this for: we're implementing code mode."

The pattern, once it ships: define your tools as Python functions. Give the agent a task. The agent writes a Python script that orchestrates those tools in whatever sequence or parallel structure the task requires. Monty executes it. The agent gets results. All tool access is controlled by what you registered — the AI cannot reach anything you didn't explicitly expose.

This is architecturally different from both "give the AI a list of tools and let it call them sequentially" and "give the AI shell access." It's a controlled middle ground that makes complex tool orchestration fast without opening your system.

Key Takeaways

Docker's 195ms startup latency is a structural problem for agent code execution — not a solvable config issue, but a fundamental constraint of process-level isolation that Monty sidesteps by running inside your process.
The "deny by default" security model is the right architecture for AI-generated code — allowlists of registered external functions are auditable; blocklists of dangerous stdlib functions are not.
CodeMode reduces LLM round-trips — the same task that requires 4 sequential tool calls typically requires 2 LLM calls when the model writes code that chains tool calls in parallel.
Serializable execution state enables durable AI agents — Monty's kilobyte-scale state snapshots are storable in a database, making long-running agent workflows restartable across process boundaries.
Monty is v0.0.8 and experimental — missing class support, re/datetime/json modules, and production hardening. Use it for constrained CodeMode patterns today; wait for PydanticAI integration for production workflows.

What This Means for Builders

If you're building AI agents with tool use, benchmark CodeMode against sequential function calling for your specific workflow. The 2x LLM call reduction is real, but only valuable if your tool calls are parallelizable.
If you're evaluating sandboxing options, Monty is worth testing against Docker for use cases where you control the tool surface. The latency win is significant; the stdlib limitations are real constraints you'll need to design around.
If you're building on PydanticAI, watch the code-mode branch — Monty is its intended execution backend and the integration is under active development.
If you need class definitions or standard library access, Monty v0.0.8 is too limited for your use case today. Check back at v0.1.x.

Built with IntelFlow — open-source AI intelligence engine. Set up your own daily briefing in 60 seconds.

How to Structure Claude Code for Production: MCP Servers, Subagents, and CLAUDE.md (2026 Guide)

zecheng — Tue, 17 Mar 2026 23:14:19 +0000

Structured AI development — using Claude Code with MCP servers, custom subagents, and project-scoped configuration — produces measurably more reliable software than ad-hoc "vibe coding," with 1.7x fewer defects and 2.74x fewer security vulnerabilities according to a CodeRabbit analysis of 470 open-source PRs (December 2025).

Most developers stop at "drop Claude Code into the terminal and type." That's leaving 80% of the tool on the table. This guide covers the full production setup: MCP server integration, CLAUDE.md project memory, custom slash commands, and specialized subagents — everything you need to move from prototype to repeatable pipeline.

Why Vibe Coding Has a Documented Failure Rate

"Vibe coding" — Andrej Karpathy's term for describing what you want in natural language and accepting whatever the LLM generates — has a real-world reliability problem. Claude Opus 4.6 scores 75.6% on SWE-bench, the benchmark that tests real GitHub issues requiring multi-file edits and passing existing test suites. That's the best available model. It means one in four production tasks fail without intervention.

HumanEval benchmarks routinely show 90%+ pass rates and mean nothing for production. SWE-bench is the honest number — multi-file, existing codebase, real test suite. Design your workflows around the failure cases, not the averages.

The production fix isn't waiting for better models. It's building workflows that catch and handle the failures.

What CLAUDE.md Actually Does (and Why It's the Foundation)

CLAUDE.md is persistent project memory — instructions loaded into every Claude Code conversation automatically.

Two locations matter:

Global: ~/.claude/CLAUDE.md — personal preferences, forbidden patterns, global conventions
Project: <project>/.claude/CLAUDE.md (check this into the repo) — tech stack, database schema notes, API endpoint references, architectural decisions

Project scope overrides global on conflicts. If your global CLAUDE.md says "use TypeScript strict mode" but your project CLAUDE.md says "this repo uses CommonJS, no strict mode," Claude Code will follow the project instruction.

A production CLAUDE.md covers:

Tech stack with exact versions (Next.js 15 App Router, PostgreSQL via Neon, Prisma 7)
Forbidden patterns (never use eval(), no string concatenation in SQL)
Directory conventions (feature logic in /lib, not /utils)
API endpoints Claude should know about
How to run tests locally

This file eliminates the "Claude forgot what we decided" problem. Every session starts with the same context.

MCP Servers: How Claude Code Connects to Your Stack

Model Context Protocol (MCP) is the integration layer between Claude Code and external tools. Claude Code acts as the MCP client; each server exposes capabilities like database access, browser automation, or API calls. The claude mcp add command is the entry point:

claude mcp add github --scope user
claude mcp add playwright --scope project
claude mcp list

Config lives at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS.

Three transport types matter:

stdio — local processes, best for filesystem and direct system access
HTTP — remote servers, recommended for cloud services like Supabase
SSE — deprecated, don't use

The MCP servers worth adding for production SaaS work:

GitHub MCP — PR reviews, issue creation, and repo management without leaving your terminal. No more switching context to a browser for a PR status.

Playwright MCP — End-to-end testing via the accessibility tree (no screenshots needed). Runs across Chromium, Firefox, and WebKit. Scope it to your project, not globally.

claude mcp add playwright --scope project

Supabase MCP — Direct line to your database, auth, storage, and edge functions. Configure it project-scoped with your project ref:

Server URL: https://mcp.supabase.com/mcp?project_ref=<your-ref>
Auth: OAuth

PostgreSQL MCP — Direct SQL queries for non-Supabase setups.

Combining three or more MCP servers in one session eliminates context-switching. Claude can write a feature, verify it against the database schema, create a GitHub issue for the edge case it found, and run the Playwright test suite — without leaving the session.

Custom Slash Commands: Reusable Workflows in One File

Every .md file in .claude/commands/ becomes a /command-name slash command. These are reusable prompts for work you do repeatedly.

.claude/
  commands/
    review-pr.md       → /review-pr
    seed-db.md         → /seed-db
    deploy-check.md    → /deploy-check

A deploy-check.md might contain:

Run the following before any deployment:
1. Check for hardcoded API keys in $ARGUMENTS or the staged diff
2. Verify database migrations are in sync with Prisma schema
3. Run `npm run test` and confirm zero failures
4. Check that environment variable names in .env.example match what the app expects
Report any issues found. If all pass, output "CLEAR TO DEPLOY."

Now /deploy-check is a repeatable gate. The $ARGUMENTS placeholder lets you pass a branch name or PR number.

Subagents: Specialized Workers With Their Own Scope and Memory

Subagents are the most underused feature in Claude Code. They're defined as Markdown files in .claude/agents/ with YAML frontmatter:

---
name: api-tester
description: Tests REST endpoints, validates response schemas, catches regressions
tools: [Bash, Read, WebFetch]
model: sonnet
memory: .claude/memory/api-tester/
---

You are a specialized API testing agent. When invoked, you:
1. Read the OpenAPI spec from /docs/api.yaml
2. Test each endpoint against the running dev server
3. Compare responses against the expected schema
4. Report failures with the specific request, expected output, and actual output

Key frontmatter fields:

tools — restrict to only what this agent needs. An api-tester doesn't need Edit or Write access.
model — use haiku for fast/cheap tasks, sonnet for balanced work, opus for architectural review
memory — persistent directory that survives across conversations

Claude Code can run up to 10 simultaneous subagents (2026). A three-stage production pipeline looks like:

pm-spec agent — reads task input, writes a structured spec with acceptance criteria
architect-review agent — validates the spec against platform constraints, produces a decision record
implementer-tester agent — writes code and tests, updates documentation

The orchestrator (Claude Code itself) coordinates the three. Each agent has limited tool access — the spec agent can only Read and Write to docs, the implementer can Bash and Edit. Principle of least privilege in AI agents is not theoretical.

Context Management: The 200K Token Budget

Claude Code has a 200,000-token context window. That sounds enormous. It isn't, once you factor in file contents, tool outputs, and conversation history.

Three levers for long sessions:

Plan mode halves token consumption by reducing back-and-forth generation. Use it at the start of any complex multi-file task — Claude maps the work before executing.

Multi-session splitting — break large features into targeted sessions. "Add Stripe webhooks" is one session. "Refactor the billing service" is a separate session. Don't carry unrelated context.

Context editing (2026 feature) — automatically clears stale tool call outputs while preserving conversation flow. In a 100-turn evaluation, this cut token consumption by 84% while completing workflows that previously failed from context exhaustion.

Use /clear between unrelated tasks. Use --continue to resume a previous session rather than re-establishing context from scratch.

The Production Pattern That Actually Works

Specification-first, then AI execution. Before touching Claude Code on any non-trivial feature:

Write a structured spec in CLAUDE.md or a dedicated spec file — include scope, constraints, acceptance criteria, what NOT to do
Open Claude Code in Plan mode, share the spec, ask for the implementation plan before any code is written
Review the plan. Make architectural decisions yourself — Claude proposes, you approve
Execute the plan with the appropriate subagent or command, with Playwright MCP watching for regressions

The hybrid rule for what to automate versus hand-code: vibe code the repetitive, well-understood parts (CRUD endpoints, data transformation, form validation). Hand-code the novel, security-sensitive, or architecturally critical parts.

An AI-generated security check that fails one in four times is not a security check.

Key Takeaways

CLAUDE.md is persistent memory — project rules in .claude/CLAUDE.md define behavior across every session; commit it to the repo so your whole team uses the same context
MCP servers eliminate context-switching — GitHub + Playwright + Supabase in one session means Claude can write, test, and track work without leaving the terminal
Subagents enforce least privilege — specialized agents with restricted tool access are more reliable than one omnipotent session; define tools explicitly in frontmatter
Context degrades on long sessions — Plan mode, multi-session splitting, and context editing are the levers; a full context window is not a feature, it's a warning
SWE-bench 75.6% means 1-in-4 failures — design human checkpoints at architectural decision boundaries, not after deployment

What This Means for Builders

Start every project with a CLAUDE.md that includes forbidden patterns, stack versions, and database schema notes — this single file eliminates 80% of "Claude forgot" problems
Add playwright and github MCP servers scoped to the project before writing your first feature, so regression tests run automatically during development
Build subagents for work you do more than twice a week — PR review, database seeding, pre-deploy checks — and commit them to .claude/agents/ with restricted tool access
When Claude's output surprises you (wrong framework assumption, incorrect schema reference), fix the CLAUDE.md instead of re-prompting — fix the context, not the conversation

Built with IntelFlow — open-source AI intelligence engine. Set up your own daily briefing in 60 seconds.

Claude Code vs GitHub Copilot vs Cursor in 2026: Which AI Coding Tool Actually Wins?

zecheng — Mon, 16 Mar 2026 23:18:20 +0000

Claude Code is the most developer-loved AI coding tool of 2026 — with 46% developer satisfaction versus GitHub Copilot's 9% and Cursor's 19% — after reaching the top of VS Code's agentic AI marketplace in under eight months of public availability.

That gap isn't minor. It's the kind of signal that reshapes product roadmaps. JetBrains just announced the sunset of Code With Me, its collaborative coding feature, with 2026.1 as the final supported release and public relays shutting down Q1 2027. The company cited shifting collaboration workflows and declining post-pandemic demand. What they didn't say explicitly: when an AI agent can autonomously handle multi-file tasks across a codebase, synchronous real-time collaboration becomes a niche edge case.

Here's the breakdown of what each tool does, where each wins, and how the field has actually moved in the last twelve months.

What Is Claude Code and How Is It Different From Copilot?

Claude Code is a terminal-native autonomous agent — not an IDE plugin, not an autocomplete layer. You run it from your command line, point it at a codebase, and give it tasks. It plans, executes, and iterates across dozens or hundreds of files without requiring you to stay in the loop.

GitHub Copilot is an inline completion tool embedded inside your IDE. It watches what you type and suggests the next line or block. The mental model is fundamentally different: Copilot accelerates what you're already doing; Claude Code does the work while you review.

Builder.io put it plainly after testing both: "Cursor makes you faster at what you already know how to do. Claude Code does things for you." That framing maps exactly to their architectural differences.

Claude Code Benchmark Numbers: SWE-Bench 2026

Claude Code runs on Claude models exclusively. The current benchmark scores on SWE-bench Verified — the industry-standard test measuring how often an AI can correctly resolve real GitHub issues — are the highest recorded:

Claude Opus 4.6: 80.8% on SWE-bench Verified, 59% on SWE-bench Pro
Claude Sonnet 4.6 (Claude Code's default model): 79.6% on SWE-bench Verified
Claude Sonnet 4.5 with parallel compute: 82.0% on SWE-bench Verified

GitHub Copilot's underlying models don't publish equivalent SWE-bench scores for autonomous task completion — because Copilot isn't designed for autonomous execution. Comparing them directly on this metric is like comparing a GPS to a self-driving car.

Claude Code now authors approximately 4% of all public GitHub commits — around 135,000 commits per day — and that figure is projected to exceed 20% by end of 2026.

How Does Cursor 2.0 Multi-Agent Work?

Cursor 2.0, released in late 2025, added genuine multi-agent capability. You can now spawn up to 8 parallel agents on a single prompt, each operating in an isolated git worktree to prevent file conflicts. Each agent has full codebase access, runs independently, and produces separate diffs.

Cursor 2.4 (February 2026) added async agents and CLI Plan Mode. The workflow: one model drafts a plan, a second model builds against it, background agents run in parallel. Inline Mermaid diagrams auto-generate into plans during the planning stage.

There's a practical caveat that repeatedly surfaces in developer communities. Cursor advertises a 200K token context window, but users consistently report hitting limits at 70–120K tokens due to silent internal truncation. Claude Code doesn't have that undocumented ceiling — and in direct comparisons, Claude Code used 5.5x fewer tokens than Cursor for equivalent tasks, with 30% less code rework in developer testing.

What Is Claude Code's CLAUDE.md and Why Does It Matter?

CLAUDE.md is Claude Code's project memory system. When you run /init in a new repository, Claude Code scans the codebase and generates this file automatically. Every subsequent session reads it at startup — no re-explaining the architecture, the tech stack, or the conventions.

claude /init

CLAUDE.md defines codebase context, command shortcuts, coding conventions, and agent behavior rules. Teams checking this file into version control effectively give every developer — and every Claude Code session — a consistent starting context.

This is the mechanism that makes Claude Code dramatically faster on second and third use in the same codebase. Copilot has no equivalent persistent memory layer.

Model Context Protocol: Claude Code's Integration Layer

Claude Code ships with MCP (Model Context Protocol), currently offering 300+ integrations: GitHub, Slack, PostgreSQL, Sentry, Linear, Jira, and custom internal tools.

The practical implication: you can write prompts like "create a GitHub issue for this failing test, assign it to the on-call engineer listed in Linear, and add the Sentry error ID" and Claude Code executes across all three systems without leaving your terminal. Copilot's integrations are limited to the GitHub ecosystem. Cursor has growing MCP support but a smaller default integration surface.

Hooks add deterministic control on top of MCP. Scripts fire at lifecycle events — PreToolUse, PostToolUse, session start and end — letting you enforce policies (e.g., block any tool call that writes to production, auto-run tests after every file edit) without relying on prompts.

Where GitHub Copilot Still Wins

Copilot's advantages are real, even if the developer satisfaction gap is wide.

It has native GitHub PR, issue, and Actions integration that no competitor has matched. If your workflow lives inside GitHub's UI — reviewing pull requests, triaging issues, debugging CI — Copilot is embedded in those surfaces. Claude Code isn't.

Copilot's inline autocomplete is also still the best inline experience in the IDE. For developers who want suggestion-based acceleration without autonomous execution, it works. The "use both" workflow is increasingly common: Copilot for inline completion inside the IDE, Claude Code in the terminal for agentic multi-file work. Combined cost is roughly $30/month.

Where Copilot falls short: 75% of senior engineers in 2026 surveys report spending more time correcting Copilot suggestions than coding manually on complex tasks. It analyzes approximately 10% of codebase context and fills the rest with assumptions — a known limitation that creates subtle bugs in non-trivial codebases.

Windsurf Wave 14 Arena Mode: The IDE as Model Evaluation Platform

Windsurf (Codeium's IDE product) shipped Wave 14 with Arena Mode — a genuinely novel product design. It runs two Cascade agents in parallel on the same prompt, with model identities hidden. Developers interact with both agents normally, then vote on which produced the better output. Individual votes feed into a global leaderboard across all Windsurf users.

This turns the IDE itself into a live model benchmarking platform. Windsurf collects real-world task signal on which models perform best for which task types, at scale, continuously. Featured models in Wave 14's Frontier group: Opus 4.5, GPT-5.2-Codex, Kimi K2.5.

It's a smart defensive move for a product competing against Claude Code and Cursor: if you can't out-execute on a single model, make the model selection process itself a feature.

How the Pricing Stacks Up

Tool	Entry Price	Best Use Case
Claude Code (Pro)	$20/month	Autonomous multi-file execution
Claude Code (Max 5x)	$100/month	Heavy agentic workloads
GitHub Copilot	$10/month	Inline completion, GitHub integration
Cursor Pro	$20/month	IDE-native, visual diff experience
Windsurf Pro	$15/month	Multi-model experimentation

Average real-world Claude Code spend is approximately $6/developer/day, with 90% of users staying below $12/day. For most engineering teams, the cost is lower than a single hour of debugging time per month.

Key Takeaways

Claude Code leads on autonomous execution. An 80.8% SWE-bench score with 46% developer satisfaction versus Copilot's 9% isn't a marginal win — it reflects a fundamental architectural advantage in agentic, multi-file tasks.
The IDE autocomplete model isn't dead — it's been repositioned. Copilot and Cursor still win for inline completion and visual diff workflows. The "use both" strategy is real and costs around $30/month.
Token efficiency compounds cost savings. Claude Code using 5.5x fewer tokens than Cursor for equivalent tasks means the productivity advantage also translates to direct cost reduction for API-heavy workflows.
CLAUDE.md and MCP are underused features. Project memory and 300+ integrations make Claude Code significantly more powerful after initial setup — most developers haven't configured these yet.
JetBrains sunsetting Code With Me is the canary. When synchronous collaborative coding becomes economically unjustifiable as a product feature, it's a leading indicator of how much the underlying workflow has already shifted.

What This Means for Builders

Start with /init in your existing codebase. Claude Code's first-run setup takes under five minutes and the CLAUDE.md it generates will change how every subsequent session works.
Don't abandon Copilot if you live inside GitHub PRs. Keep it for inline completion and GitHub Actions debugging; route complex refactors and multi-file tasks to Claude Code in the terminal.
Test the 5.5x token efficiency claim yourself. Run the same medium-complexity task (a full feature with tests) in both Claude Code and Cursor and compare API token consumption. The gap is real.
Watch the Windsurf Arena Mode data. It's the first large-scale real-world model benchmarking system built into an IDE. The leaderboard it generates over the next six months will be more useful than synthetic benchmarks for understanding which models actually perform on developer tasks.

Built with IntelFlow — open-source AI intelligence engine. Set up your own daily briefing in 60 seconds.

Why Claude Code Skills Don't Trigger (And How to Fix Them in 2026)

zecheng — Sun, 15 Mar 2026 23:07:49 +0000

The core problem with Claude Code skills is a token budget overflow that silently drops your skill descriptions before Claude ever reads them. If you have built skills, tested them manually, and then watched Claude ignore them in real sessions — you are not doing it wrong. You are hitting a documented architectural limitation that most developers never find.

This article covers the full picture: how Claude Code skills actually work under the hood, the three root causes of missed triggers, and the reliable fixes — including when to use Anthropic's new Skill Creator tool to measure and iterate.

What Is a Claude Code Skill, Actually?

A Claude Code skill is a SKILL.md file in .claude/skills/<name>/ that Claude loads dynamically when it decides the skill is relevant to your request. It is not a plugin, not a system prompt injection, and not a function call. It is closer to a context-gated instruction block — Claude reads the description, decides if it matches the current task, and only then loads the full instructions.

The format is straightforward:

---
name: code-review
description: ">"
  Reviews code for security issues, performance problems, and style violations.
  Use when reviewing a pull request, inspecting a function, or when the user
  asks "review this code" or "check this for bugs."
allowed-tools: Read, Grep
---

When reviewing code, always check:
1. SQL injection and input validation
2. Authentication and authorization checks
3. Error handling completeness
4. Performance bottlenecks (N+1 queries, missing indexes)

The description field is doing most of the work. It is what Claude reads to decide whether to invoke the skill.

Why Do Claude Code Skills Fail to Trigger?

Claude Code skills fail to trigger for three distinct reasons, and each has a different fix.

Root cause 1: Token budget overflow. At session startup, all skill names and descriptions are pre-loaded into the system prompt, subject to a default budget of ~15,000 characters (~4,000 tokens). When you exceed this budget — which happens faster than you expect with five or six verbose skills — some descriptions get silently truncated. Claude literally never sees them. There is no error message.

Fix: Set the environment variable before launching Claude:

SLASH_COMMAND_TOOL_CHAR_BUDGET=30000 claude

This doubles the available budget. For heavy skill setups, set it in your shell profile so it persists.

Root cause 2: YAML formatting issues. Multi-line descriptions using block scalars (> or |) occasionally break the skill loader, especially with auto-formatters like Prettier that reflow text. A skill that parses correctly in isolation can fail when Prettier reformats your SKILL.md.

Fix: Keep your description on a single logical line, and add a comment to block reformatting:

---
name: deploy
description: Deploys the application to production. ONLY invoke when the user explicitly says "deploy" or "ship to prod" — never invoke autonomously. # prettier-ignore
disable-model-invocation: true
---

Root cause 3: Claude's goal-focused behavior. Even with the budget issue resolved and valid YAML, autonomous triggering in real sessions achieves roughly a 50% success rate. Claude prioritizes completing the task as it understands it, not checking whether a skill exists for it. The architecture assumes Claude will proactively check its available tools. In practice, it often does not.

How to Force Reliable Skill Activation

The most reliable pattern for autonomous activation is directive description language — not describing what the skill does, but commanding when it must run:

---
name: security-review
description: "ALWAYS invoke this skill when reviewing any code changes before committing. Use for pull request reviews, diff reviews, and any time the user says 'check', 'review', or 'audit' code. DO NOT write security feedback without invoking this skill first."
---

The before/after difference in activation rate between descriptive and directive language is significant. In Anthropic's own testing with the Skill Creator, directive descriptions improved triggering on 5 out of 6 public skills they evaluated.

For production pipelines where you need guaranteed activation, use a UserPromptSubmit hook:

INPUT=$(cat)
PROMPT=$(echo "$INPUT" | jq -r '.prompt // empty')

if echo "$PROMPT" | grep -qiE '(review|audit|check.*code|security)'; then
  echo "INSTRUCTION: Use Skill(security-review) to handle this request"
fi

{
  "hooks": {
    "UserPromptSubmit": [{
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/auto-skill.sh"
      }]
    }]
  }
}

The key distinction: the hook injects "Use Skill(security-review)" — not "Check if there are relevant skills." The explicit tool call instruction is what reliably fires, not the vague reminder.

What Does Anthropic's Skill Creator Actually Do?

Skill Creator is Anthropic's answer to the "I built this skill and have no idea if it works" problem. It shipped its major eval/benchmark upgrade on March 3, 2026, and is available at claude.com/plugins/skill-creator with 50,000+ installs.

It operates in four modes:

Create: Interactive Q&A that generates a SKILL.md structure from your description
Eval: You write test cases; it runs your skill against those cases and scores outputs
Improve: Analyzes eval failures and suggests targeted changes to your description or instructions
Benchmark: Runs a standardized assessment across your full eval set and tracks pass rate, elapsed time, and token usage across runs

The Eval and Benchmark modes are the ones that matter. The "faith-based automation" problem — build a skill, deploy it, hope it works — is the core failure mode. Skill Creator gives you measurable pass rates.

Invoke it directly:

"Run evals on my code-review skill"
"Benchmark my deploy skill across 10 runs and show variance"
"Compare version 1 vs version 2 of my security-review skill"

The Comparator sub-agent runs blind A/B comparisons between two skill versions without knowing which is which, which eliminates confirmation bias in self-evaluation.

How to Structure a SKILL.md That Scales

The description field has a 1,024-character limit. Use it for trigger keywords, not instructions. Keep the SKILL.md body under 500 lines. For complex workflows, use supporting files:

.claude/skills/deploy/
├── SKILL.md           # Trigger logic + high-level steps
├── checklist.md       # Full deployment checklist
└── scripts/
    └── verify.sh      # Post-deploy verification

Inside SKILL.md, reference supporting files instead of inlining:

---
name: deploy
description: "Deploys application to production environments. Invoke when user says 'deploy', 'ship', 'release', or 'push to prod'. ALWAYS require explicit confirmation before running."
context: fork
disable-model-invocation: true
---

Follow the checklist in @checklist.md exactly.
After deploying, run @scripts/verify.sh and report results.

The context: fork flag runs the skill in an isolated subagent context, which prevents deployment operations from contaminating your main conversation state.

What Does the Invocation Control Matrix Look Like?

Three frontmatter flags control when and how skills fire:

Configuration	You can invoke	Claude auto-invokes	Use case
Default (no flags)	Yes	Yes	Research, formatting, analysis
`disable-model-invocation: true`	Yes	No	Deploy, commit, send messages
`user-invocable: false`	No	Yes	Background quality checks

For anything with side effects — deploying, committing, publishing — always use disable-model-invocation: true. You do not want Claude autonomously deciding to deploy because you mentioned the word "ship."

Where to Find 1,200+ Community Skills

The community skills library at github.com/travisvn/awesome-claude-skills aggregates the most-starred skill collections. Notable sources:

obra/superpowers (40,900+ stars): /brainstorm, /write-plan, and 20+ battle-tested general workflow skills
alirezarezvani/claude-skills (4,400+ stars): 180+ production-ready skills across coding, writing, and deployment workflows
Official Anthropic skills at github.com/anthropics/skills: pdf, docx, pptx, xlsx, slack-gif-creator, webapp-testing, and brand-guidelines

Install via Claude Code:

/plugin add /path/to/skill-directory

All skills follow the agentskills.io open standard released December 2025, which means the same SKILL.md format works across Claude.ai, Claude Code, the API, and compatible tools like OpenCode.

Key Takeaways

Token budget overflow is the silent killer. Set SLASH_COMMAND_TOOL_CHAR_BUDGET=30000 if you have more than three skills and wonder why they stop firing after you add new ones.
Directive description language outperforms descriptive language for autonomous triggering. "ALWAYS invoke when..." beats "Helps with..." every time.
Hooks give you guaranteed activation. For production workflows, a UserPromptSubmit hook with an explicit "Use Skill(name)" instruction is more reliable than description-based autonomous invocation.
Skill Creator's Eval mode makes skills measurable. Establish a baseline pass rate before optimizing — otherwise you are guessing whether your changes helped.
disable-model-invocation: true is required for any side-effectful skill. Deployments, commits, and API calls should never auto-invoke.

What This Means for Builders

Start with evals, not instructions. Write three test cases for your skill before writing the SKILL.md body. This clarifies what "working" actually means before you spend time on documentation.
The description is the trigger, not the instructions. Spend 70% of your SKILL.md iteration time on the description field. A perfect 500-line instruction set with a vague description will never fire.
Skill complexity caps out around 500 lines. Beyond that, refactor into supporting files with @file references. Large monolithic SKILL.md files are harder to test and harder for Claude to follow precisely.
Every multi-step production workflow needs a hook. If your automation pipeline requires a specific skill to always run at a specific point, encode that requirement in a hook — not in a description you hope Claude will read correctly.

Built with IntelFlow — open-source AI intelligence engine. Set up your own daily briefing in 60 seconds.

How Enterprise AI Platforms Get Hacked: Lessons from the McKinsey Lilli Breach

zecheng — Sun, 15 Mar 2026 04:15:33 +0000

Enterprise AI platforms fail in predictable ways — and the McKinsey Lilli breach in February 2026 is the clearest case study yet of how a system deployed to 43,000 users can be fully compromised in under two hours through vulnerabilities that have been documented since the late 1990s.

An autonomous security agent built by CodeWall extracted 46.5 million consulting conversations, 728,000 confidential documents, 57,000 user accounts, and — most critically — gained write access to all 95 system prompts controlling what the AI shows McKinsey's consultants (source: codewall.ai). McKinsey's standard scanner, OWASP ZAP, missed it entirely.

This is the pattern that's going to repeat across enterprise AI deployments in 2026. ML engineers are building RAG systems without thinking like security engineers, and the attack surface is compounding faster than most teams realize.

The Attack Chain That Took Down Lilli

The entry point was embarrassingly simple. Of Lilli's 200+ API endpoints, 22 required zero authentication — and the API documentation was publicly exposed.

One of those unauthenticated endpoints wrote user search queries to a database. Here's the critical detail: the endpoint correctly parameterized query values, but concatenated JSON field names directly into the SQL statement. Standard scanners test value injection. They miss key injection. The AI security agent recognized the database error messages as SQL injection signals and ran 15+ blind iterations to extract increasingly detailed production data.

This is the "decades-old technique" framing that makes the breach significant (The Decoder): SQL injection has been in the OWASP Top 3 since the late 2000s. The vulnerability exists because ML engineers building internal AI tooling don't think like web security engineers. They parameterize values correctly — they've heard to do that — but they don't think about field names as an injection surface.

Why Writable System Prompts Are the Real Catastrophe

Data theft is recoverable. System prompt write access is not.

McKinsey's 95 system prompts controlled the outputs Lilli delivered to every consultant. An attacker with write access to those prompts could silently shape the strategic recommendations flowing to Fortune 500 boardrooms — without touching a single email or document. Consultants trust internal tools implicitly. Internal tools don't get the skepticism that external sources do.

This is what distinguishes AI security from traditional data security: the blast radius of a compromised AI system isn't just the data it holds. It's the trust surface of everyone who reads its outputs.

System prompts should be treated like firmware, not runtime configuration. Concretely:

System prompts belong in version-controlled, write-protected storage
Write access should require separate privileged credentials, not the same API key used for reads
Implement canary tokens inside system prompts to detect extraction or modification attempts

The Three Vulnerability Classes to Patch First

1. Unauthenticated API Endpoints

43% of CISA-tracked actively exploited vulnerabilities are API-related (Cloud Security Alliance). The fix is non-negotiable: every endpoint must require authentication. There are no "internal-only" or "dev" exceptions — if it's reachable, it's exploitable. Never expose API documentation publicly if any endpoint touches production data.

2. SQL Injection in RAG Pipelines

CVE-2025-1793 affected 8 vector store integrations in LlamaIndex. The pattern: user-supplied inputs to database methods weren't parameterized (Penligent). The McKinsey variant was subtler — parameterized values but raw key names.

query = f"SELECT * FROM docs WHERE {user_field_name} = ?"

ALLOWED_FIELDS = {"title", "content", "author", "date"}
if field_name not in ALLOWED_FIELDS:
    raise ValueError(f"Invalid field: {field_name}")
query = f"SELECT * FROM docs WHERE {field_name} = ?"

Standard scanners won't catch the subtler variants. Add security testing that explicitly fuzzes field names and JSON keys, not just values.

3. System Prompt Injection (Direct and Indirect)

Prompt injection is OWASP LLM01:2025, with attack success rates of 50–84% depending on system configuration (OWASP). Indirect injection — where malicious instructions are embedded in documents the AI retrieves — is the harder problem. OpenAI acknowledged in February 2026 that AI browsers "may never be fully patched" against prompt injection.

The mitigation stack:

Maintain strict context separation: system prompts and retrieved content should never share the same trust boundary without demarcation
Run agents that retrieve external content with reduced permissions
Apply output filtering before returning results to users
Tools like Lakera Guard and Prompt Security provide dedicated prompt injection defense layers

MCP Introduces an Entirely New Attack Surface

The Model Context Protocol has a threat that has no traditional software equivalent: rug pull attacks.

A tool behaves correctly through the approval process. Once approved, its description or metadata is silently modified to embed malicious instructions. The agent executes them because the tool is already in the trusted list (Invariant Labs).

Enterprise MCP deployments need:

mcp-scan --pin-tools --alert-on-change

The 2025-11-25 MCP spec now classifies MCP servers as OAuth Resource Servers and requires Resource Indicators (RFC 8707) — tokens are scoped to a specific MCP server and can't be reused across servers. If you're running MCP in production and haven't updated your auth layer to the current spec, this is the gap to close first.

RAG-Specific Risks That Go Beyond SQL

Vector database poisoning: BadRAG demonstrated a 98.2% attack success rate by poisoning only 0.04% of a corpus. Injected documents get retrieved into LLM context and the model behaves as intended by the attacker. Every document ingestion pipeline needs validation and anomaly detection before content enters the vector store.

Embedding extraction: Vec2Text can reconstruct original text from embeddings with 92% exact match accuracy on short inputs. Embeddings are not a privacy mechanism — treat them like plaintext.

Access control in retrieval: The default pattern — one vector store accessible to all users — is wrong for enterprise deployments. Implement document-level ACLs at the retriever layer. A consultant in Germany shouldn't be able to retrieve documents tagged for the US team. Attribute-Based Access Control (ABAC) handles this better than role-based models for dynamic RAG contexts.

The Security Tooling Asymmetry

The most unsettling part of the McKinsey breach timeline: a commercial AI security agent found what McKinsey's standard tooling missed. The attackers' tools are running a generation ahead of the defenders'.

AI-powered security scanners (commercial and open-source) are now available specifically for LLM applications. Running them against your API surface before launch is table stakes in 2026. OWASP ZAP's rule set was built for traditional web applications — it's not instrumented for the JSON key injection patterns and indirect prompt injection vectors that define the AI attack surface.

Average cost of an AI-related data breach in 2025: $4.88 million (Petronella). Running an AI security audit before launch is cheap by comparison.

What This Means for Builders

Treat system prompts as firmware. Write access to system prompts is a higher-severity issue than database access. Lock them down with separate credentials, version control, and integrity checks before anything else.
Run AI-native security scanners, not just traditional web scanners. OWASP ZAP missed the McKinsey vulnerability. Add tools that understand LLM-specific injection surfaces — including JSON key names, RAG retrieval manipulation, and MCP tool description poisoning.
Authentication is not optional for any endpoint. If your internal AI tool has a single unauthenticated endpoint that touches production data, you have a McKinsey-style exposure waiting. Audit every endpoint before launch, and don't expose API documentation publicly.
Assume every document your RAG system retrieves is potentially attacker-controlled. Apply input filters before retrieval, apply output filters before display, and run agents that handle external content with reduced permissions. Indirect prompt injection via retrieved documents is harder to patch than direct injection.

Built with IntelFlow — open-source AI intelligence engine. Set up your own daily briefing in 60 seconds.

How to Run the Karpathy Loop: AI-Automated Benchmarking That Made Shopify's Template Engine 53% Faster

zecheng — Fri, 13 Mar 2026 23:13:06 +0000

The Karpathy loop is an AI-assisted optimization technique where an autonomous agent runs hundreds of edit-benchmark-discard cycles overnight, surfacing performance improvements that no single engineer would have the time to find manually — and it just made Shopify's Liquid template engine 53% faster with 61% fewer memory allocations.

On March 13, 2026, Tobias Lütke — Shopify's CEO, the person who originally built Liquid over 20 years ago — submitted GitHub PR #2056 against the Liquid codebase with those numbers attached. The method: approximately 120 automated experiment loops using a variant of Andrej Karpathy's autoresearch system. The results: 974 unit tests pass, zero regressions, and a performance improvement visible in production-scale benchmarks against real Shopify themes.

Here's how the technique works, how to run it yourself, and what it actually found inside Liquid's parser.

What the Karpathy Loop Actually Is

Andrej Karpathy open-sourced autoresearch on March 8, 2026 — a deliberately minimal Python tool (~630 lines) that turns performance experimentation into a fully autonomous overnight process.

The loop is conceptually simple:

read code + fitness metric
  → form hypothesis
  → edit code
  → run tests (correctness gate)
  → run benchmark (performance gate)
  → keep if metric improved, discard if not
  → log to JSONL
  → repeat

Each experiment runs inside a fixed time budget (roughly 5 minutes), which makes all runs directly comparable regardless of what changed. Single unambiguous fitness metric. Tests before benchmarks — correctness is non-negotiable, performance is the optimization target.

Karpathy's own results on ML training scripts: a 126-experiment overnight run dropped validation loss from 0.9979 to 0.9697. After approximately 700 autonomous changes over two days, the "time to GPT-2" training metric improved by 11%. On the night of March 8–9 alone, 35 autonomous agents on the Hyperspace network ran 333 unsupervised experiments.

The repo is at github.com/karpathy/autoresearch. It was originally designed for ML training scripts, but the core architecture is domain-agnostic.

How Tobi Adapted It for a Ruby Codebase

Lütke used Pi as his coding agent and adapted the autoresearch pattern through a plugin called pi-autoresearch (co-authored with David Cortés, available at github.com/davebcn87/pi-autoresearch).

The adaptation required two files:

autoresearch.md    — the agent's instruction file (what to optimize, what to measure)
autoresearch.sh    — the benchmark runner (runs tests + reports scores)
autoresearch.jsonl — state file (experiment history, what worked, what didn't)

The fitness metric was the ThemeRunner benchmark: a real Shopify theme executing against production-like template data, measured in milliseconds of combined parse+render time and tracked object allocations. The correctness gate was Liquid's existing 974-test suite — any experiment that breaks a test gets discarded immediately, before benchmarking.

Lütke's X post after the run: "I ran /autoresearch on the liquid codebase. 53% faster combined parse+render time, 61% fewer object allocations. This is probably somewhat overfit, but there are absolutely amazing ideas in this."

The "somewhat overfit" caveat matters. Automated loops can find improvements that look good on the benchmark fixture without generalizing to all production patterns. The next step — which Shopify's engineering team will handle — is verifying which changes survive broader production testing. That's expected from automated research, not a flaw in the technique.

What the Agent Actually Found: StringScanner → Byte-Level Scanning

The single biggest individual optimization surfaced by the loop: replacing the StringScanner-based tokenizer with String#byteindex for finding {% and {{ delimiters inside template strings.

String#byteindex searching for a fixed two-byte sequence is approximately 40% faster than StringScanner#skip_until with a regex pattern. On the ThemeRunner benchmark, the old approach was calling StringScanner#string= reset on every {% %} token — 878 times. The new byte-level cursor eliminates that reset overhead entirely, reducing parse time by roughly 12% on its own.

The PR went further. The automated loop also identified:

VariableParser refactor: the regex-based parser replaced with a manual byte scanner that extracts name expressions and filter chains without touching the Lexer or Parser at all
Variable#try_fast_parse path: 100% of variables in the benchmark (1,197 variables) now route through this byte-level fast path, bypassing the full parse stack
FullToken regex elimination: cursor-based scanning replaces the regex in the main tokenization path

Aaron Patterson's canonical 2023 post on fast tokenizers with StringScanner (tenderlovemaking.com) represented the previous state of the art in Ruby tokenizer performance. The Liquid PR effectively goes one level deeper — byte operations instead of scanner operations.

How to Run This on Your Own Codebase

You don't need to use Pi as your coding agent. The pattern is agent-agnostic. Here's what you actually need:

Step 1: Define your fitness metric precisely.
One number. Smaller is better (or larger is better — pick one). For Liquid it was benchmark milliseconds and allocation count. For an API endpoint it might be p95 response time. For a database query, it's execution time on a fixed dataset. Ambiguous metrics produce ambiguous results.

Step 2: Write your benchmark runner as a script.

#!/bin/bash
bundle exec ruby bench/themerunner.rb 2>&1 | tail -5

The agent needs to read a single number from stdout. Make the output format explicit in your instruction file.

Step 3: Set up your instruction file (autoresearch.md).
Tell the agent: what the codebase does, what the benchmark measures, what kinds of changes are in-scope (tokenizer, parser, memory allocation patterns), and what's out of scope (don't touch the public API surface, don't change error messages).

Step 4: Run with a time budget.
120 experiments at 5 minutes each = 10 hours. That's overnight. The correct use of this technique is to start it before you sleep and read the JSONL log in the morning.

Step 5: Review the winning experiments manually.
The agent produces hypotheses and results. You still own the decision about what ships. The JSONL log gives you a complete record of what was tried, what worked, and what the agent's reasoning was for each change.

Who Else Is Running This Pattern

Beyond Karpathy and Lütke, the technique is spreading across different ecosystems:

autoresearch-mlx (github.com/trevin-creator/autoresearch-mlx) — Apple Silicon port using MLX instead of PyTorch, runs natively on Mac without CUDA
autoresearch-win-rtx (github.com/jsegov/autoresearch-win-rtx) — Windows + RTX GPU adaptation
autoexp gist (gist.github.com/adhishthite) — generalized version for any quantifiable metric project, not just ML training

Simon Willison's coverage of the Liquid PR (simonwillison.net, March 13, 2026) frames this as one concrete instance of a broader class of agentic engineering patterns — AI-assisted iteration that produces better code through automated feedback loops rather than through AI writing code from scratch.

What This Means for Builders

The technique works on any codebase with a measurable benchmark. Ruby, Python, Rust, Go — the autoresearch pattern is language-agnostic. The requirement is a fitness metric you can print to stdout from a script.
Start with allocation profiling, not execution time. The Liquid PR's most productive discovery thread came from object allocation counts, not raw speed. Memory allocation patterns are often the root cause of performance issues, and they're cheaper to measure and easier for an agent to reason about than cache behavior or I/O.
The agent is a hypothesis generator, not an autonomous engineer. The loop produces candidates. The correctness gate (your test suite) is non-negotiable — run it before benchmarking every single experiment. Ship nothing without human review of the winning diffs.
120 experiments overnight is now a realistic option for individual contributors. Lütke submitted this PR as one person using a weekend afternoon to set up the loop. The productivity floor for a single engineer with the right tools has shifted significantly — not because AI writes better code than humans, but because it can test more hypotheses per hour than any human team can.

Built with IntelFlow — open-source AI intelligence engine. Set up your own daily briefing in 60 seconds.

Enterprise AI Is Making Everyone Work More, Not Less — Here's Why, and What Builders Are Actually Doing About It

zecheng — Fri, 13 Mar 2026 00:53:29 +0000

443 million hours of tracked work. 163,638 employees. 1,111 organizations. Three years of data.

The result: AI tools increased workload in every single measured category. Emails up 104%. Chat and messaging up 145%. Focused work down 23 minutes per day. Saturday work up 46%.

ActivTrak's 2026 State of the Workplace report is the largest empirical dataset on enterprise AI productivity ever published, and it tells a story most AI marketing decks would rather you didn't see.

The question for builders isn't whether this is true. It's why — and what the tools launching this week are doing differently.

Why AI Makes Knowledge Workers Busier (The Structural Explanation)

Here's the mechanism. When you drop an AI tool into an existing workflow without changing the workflow, you don't remove steps. You add them.

Every AI output becomes a new checkpoint: Did the AI get this right? Let me verify with a colleague. Let me fix this error. That verification loop is slower than doing the task manually in the first place. You've added a new worker to the process — an unreliable one that requires supervision.

Over 1,000 Amazon employees signed an internal petition this week calling the company's AI tools "half-baked." The complaint isn't that AI is slow. It's that error correction and verification overhead now consume more time than the task itself. Amazon has cut 30,000 employees since October 2025. The remaining workforce is being asked to use immature AI to absorb that lost capacity.

The productivity promise breaks when AI assists humans with existing steps. It only works when it removes entire steps from the human queue entirely.

Understudy: Teaching an Agent by Demonstration

Two tools launched on HN this week that take this seriously.

Understudy ships a "teach once, agent learns" paradigm for desktop automation. The workflow:

/teach start
/teach stop "describe what you just showed"

The agent watches, extracts intent, and generates a SKILL.md artifact that hot-loads into the active session. No coordinate mapping, no configuration scripts.

The architecture is the interesting part. Most RPA tools record mouse coordinates and replay them — change your screen resolution and everything breaks. Understudy uses a dual-model approach: a decision model handles "what to do," while a separate grounding model handles "where on screen." Decoupling those two problems is what makes generalization possible.

A task can span web browsing, shell commands, native app interactions, and messaging in a single session. The agent's learning curve mirrors new employee onboarding: observation → imitation → independent execution → route optimization. Except it doesn't forget between sessions.

Current status: Layers 1 (native software) and 2 (demonstration learning) are fully implemented. Layers 3–5 (crystallized memory, proactive autonomy) are in development. Open source, macOS-primary.

For anyone running repetitive multi-system workflows — data entry, report generation, cross-app coordination — this is worth watching closely.

Axe and the Unix Pipe Pattern for AI Agents

Axe is a 12MB binary positioning itself as a replacement for AI frameworks. What's more useful than the tool itself is the workflow pattern it surfaced in the HN comments.

The top comment described building AI pipelines with nothing but Claude's -p flag and Unix pipes:

git diff --staged | ai-commit-msg | git commit -F -

ai-commit-msg is a 15-line bash script. Stdin: git diff. Stdout: one conventional commit message. No framework, no abstraction layers, no dependency graph. It does one thing.

The architectural insight: AI capability doesn't need to be encapsulated in heavyweight frameworks. Decompose it into Unix-style tools — explicit inputs, explicit outputs, composable in arbitrary sequences. Each script is auditable, debuggable, and replaceable independently. When something breaks, you know exactly where.

The honest tradeoff the discussion surfaced: a single large context window is expensive, but fanning out to 10 parallel agents with mid-size context windows costs more. The same discipline that makes Unix pipelines safe — defining task boundaries carefully before composing — applies to AI pipelines too.

The RAG Security Risk Nobody's Talking About

Here's a number that should change how you think about retrieval-augmented generation systems in production.

PoisonedRAG research, presented at USENIX Security 2025, found that injecting approximately five malicious documents into a corpus of millions — that's 0.0002% of the corpus — achieves a 97% attack success rate on targeted queries against the Natural Questions dataset. HotpotQA: 99% ASR. MS-MARCO: 91% ASR.

The mechanism: malicious documents are engineered to score higher cosine similarity to a target query than the legitimate document being displaced. No code changes, no authentication bypasses. The attack happens entirely at the retrieval stage.

The retrieval layer has become the AI system's control plane. If it's compromised, model behavior is compromised — without touching the model itself.

Three defenses that actually work:

Restrict corpus write permissions aggressively. Most organizations have this too open.
Plant canary documents containing unique proprietary phrases. If those phrases appear in unexpected retrieval logs, the corpus has been probed.
Monitor retrieval inputs continuously, not retroactively.

This connects to a broader point Simon Eskildsen (CEO of Turbopuffer) made on the Latent Space podcast this week: as context windows grow, most people assume RAG becomes less important. He argues the opposite — retrieval becomes more critical, because the retrieval layer determines what information the model actually sees. The ceiling on output quality is the floor of retrieval quality.

Databricks Genie Code: 77.1% on Real-World Data Tasks

Databricks announced Genie Code on March 11. The benchmark claim: 77.1% success rate on real-world data science tasks, up from 32.1% for leading coding agents — more than double.

It builds pipelines, debugs failures, ships dashboards, and maintains production systems autonomously. The agent plans and executes multi-step workflows with human oversight at decision points — not as a copilot, but as an actor.

Databricks also acquired Quotient AI to embed continuous evaluation and reinforcement learning directly into Genie Code's feedback loop. Early adopters include SiriusXM and Repsol.

The 77.1% number isn't magic. It reflects the architectural difference between "AI assists humans" and "AI runs the process." Genie Code is designed to eliminate human-in-the-loop steps, not speed them up.

What This Means for Builders

Redesign before you automate. The ActivTrak data proves that inserting AI into an existing workflow makes it worse. Map the process first, identify which steps require human judgment, and only then decide where autonomous agents replace human-in-the-loop steps entirely.
Treat your retrieval layer as a security surface. If you're shipping a product with RAG, the vector database and document ingestion pipeline need the same access controls and monitoring you'd apply to authentication. PoisonedRAG shows it's not theoretical.
The Unix pipe pattern is underrated for AI workflows. Before reaching for LangChain or a similar framework, try stdin → claude -p → stdout composited with small, single-purpose scripts. Auditable, cheap to debug, cost-predictable.
"Teach once" automation is the category to watch. Understudy's demonstrate-once architecture solves the configuration problem that keeps most teams from building internal automation. If you have repetitive workflows spanning multiple tools, this pattern — not RPA, not chat-based AI — is the right model.

Full report with macro context, SEO/search analysis, and the Atlassian layoff breakdown: Zecheng Intel Daily — March 13, 2026

The Agentic IDE Race Just Started: JetBrains Air, ACP Protocol, and Why Your Logs Are Lying to You

zecheng — Thu, 12 Mar 2026 12:49:28 +0000

Andrej Karpathy posted a single tweet asking where the "agentic IDE" is. Within hours, JetBrains shipped an answer.

That's the speed of this market right now. Here's everything builders need to know from March 12.

JetBrains Air and the Protocol That Could Reshape IDE Competition

JetBrains launched Air — rebuilt on the bones of Fleet, their previously abandoned editor — now repositioned as an agentic-first environment. Air runs multiple AI agents concurrently and ships with multi-model support out of the box:

- OpenAI Codex
- Anthropic Claude Agent
- Google Gemini CLI
- JetBrains Junie (also available standalone at $10/month)

macOS public preview is live now. Windows and Linux are coming later.

The more interesting play is the Agent Client Protocol (ACP) — a vendor-neutral communication standard co-developed by JetBrains and Zed. ACP decouples agents from specific editors. Any compliant agent works in any compliant editor.

If ACP gets traction, the IDE moat shifts entirely. Today, editors compete on which models they support and how well they're integrated. With ACP, that becomes table stakes. The real differentiation becomes UX, reliability, and workflow design. Cursor proved that an AI-first editor could take meaningful share from incumbents. JetBrains is responding not with a better model integration — but with a protocol designed to make the model question irrelevant.

One more thing worth bookmarking: Agency Agents surfaced in the same discussion — a system that injects 112 specialized AI agent personas into Claude Code, Cursor, and Aider. Instead of one general-purpose assistant, you get domain experts. It's a workaround for the "one model handles everything" ceiling that current tools hit.

Your Production Agents Are Failing Silently

Sentrial launched out of YC W26 this week, and the problem they're solving is one that every team running agents in production has already hit but hasn't fully named.

Traditional observability catches HTTP errors, latency spikes, and exceptions. Agent failures are different. An agent can pick the wrong tool, talk in circles, give technically correct but practically useless output, or quietly blow its cost budget — and none of that generates a stack trace.

From Sentrial founder Neel Sharma:

"When agents fail, choose wrong tools, or blow cost budgets, there's no way to know why — usually just logs and guesswork. As agents move from demos to production with real SLAs and real users, this is not sustainable."

Sentrial monitors at the behavioral and conversational level. It tracks patterns that precede failures, measures success rates and ROI, and captures the gap between what your logs show and what your users actually experienced.

The timing is right. Teams that shipped agent-powered products over the last 18 months are now discovering that demo performance and production performance diverge in ways that are hard to diagnose with tools built for microservices. The monitoring layer for production AI agents is being built right now, and it's not Datadog.

100 Billion Parameters on a Single CPU — For Real This Time

Microsoft open-sourced bitnet.cpp, an inference framework for 1-bit LLMs. The benchmark:

Model:     BitNet b1.58 (100B parameters)
Hardware:  Single x86 CPU
Speed:     5-7 tokens/second (~human reading speed)
x86 gain:  6.17x speedup vs standard inference
x86 energy: 82.2% lower consumption
ARM gain:  5.07x speedup, 70% energy reduction

The critical distinction from post-training quantization: BitNet weights are ternary (-1, 0, or +1) from the start of training. This is an architectural decision, not a compression approximation of a full-precision model. You're not degrading a 100B model — you're running a model that was designed to be this efficient.

The practical result: 100B-scale inference is now within reach of commodity x86 hardware. Apple Silicon has dominated the "capable local AI" conversation for two years. This changes that ceiling substantially.

AMD Ryzen AI NPUs Finally Have Linux Support

For two years, Ryzen AI NPUs shipped with Windows-only software. That changed March 11 with two simultaneous releases:

Lemonade 10.0 — open-source LLM server with native Claude Code integration and Linux NPU support.

FastFlowLM 0.9.35 — NPU-first runtime built for Ryzen AI, now officially supporting Linux.

Requirements: Linux 7.0 kernel or AMDXDNA driver backports. FastFlowLM supports up to 256k token context lengths on Ryzen AI 300/400 series SoCs.

If you're building for enterprise deployments on Ryzen AI PRO hardware, or you need local inference without being locked to macOS, there's now a real path.

The Agent Deployment Stack Is Filling In

Two separate projects hit HackerNews the same day, pointing in the same direction: making autonomous agent deployment possible without DevOps expertise.

Klaus targets OpenClaw deployments. It spins up a dedicated EC2 instance per user, pre-configured with API keys and OAuth integrations for Slack and Google Workspace. Personal AI agent running across WhatsApp, Telegram, Slack, Discord, Signal, iMessage, and Google Chat — no infrastructure knowledge required.

Ink handles the deployment side. Agents push full-stack applications to production without human involvement. Integration is via MCP (compatible with Claude, Cursor, VS Code) or CLI. Once connected, an agent can deploy frontend, backend, domains, and databases — with real-time metrics fed back to the agent for self-diagnosis.

The first wave of AI coding tools assisted human developers. Klaus and Ink represent the current wave: handing the entire development pipeline — writing, deploying, monitoring — to agents, with humans reviewing outcomes rather than managing steps.

The SEO Signal Most Developers Are Missing

One number for anyone building content-dependent products: the correlation between AI citation and Google ranking has dropped from 70% to below 20% (Brandlight, 2026).

Ranking first on a SERP is no longer a reliable predictor of being cited in an AI-generated answer. The two have nearly decoupled.

AI Overviews now covers 48% of search queries. Organic CTR dropped 61% between June 2024 and September 2025. The competitive math has compressed: ten link positions on a standard SERP versus two to seven domains cited in an AI answer.

The protocol worth knowing about: llms.txt lets site owners explicitly instruct AI crawlers on what to read and how. Current adoption: below 1% globally. That's an open lane if you're building any kind of content asset.

What This Means for Builders

ACP is worth watching closely. If the Agent Client Protocol gets meaningful adoption, it shifts IDE competition from model integration to UX and workflow design. Tools that bet on model lock-in may be building on sand.
Add semantic monitoring before you scale. If you're running agents in production, your error logs are an incomplete picture. The failures that matter — wrong tool selection, circular reasoning, cost overruns — don't surface in standard observability. Sentrial's framing of this gap is accurate.
BitNet changes local inference planning. 100B parameter models running on commodity x86 CPUs at readable speed is now demonstrated, not theoretical. If you've been scoping local inference around Apple Silicon constraints, revisit those assumptions.
Audit where you appear in AI answers, not just SERP positions. For any product with a content or discoverability component, the diagnostic question is no longer "where do I rank?" — it's "does AI cite me?" Start with that audit before optimizing for anything else.

Full analysis — including the Anthropic/Pentagon lawsuit, Oracle's $553B in signed AI contracts, and the capital signals in China's tech sector — in the complete report: Zecheng Intel Daily, March 12, 2026

A GitHub Issue Title Compromised 4,000 Developer Machines — Here's the Architecture That Made It Possible

zecheng — Tue, 10 Mar 2026 23:11:34 +0000

An attacker modified the Klein npm package this week to silently install OpenClaw on any machine that ran npm install or npm update. Roughly 4,000 developers were affected. Most don't know it happened yet.

The attack vector: a GitHub issue title.

An AI triage bot was reading open issues on the repository and acting on them. The attacker crafted a title that looked like a bug report but contained an injected prompt. The bot read it, interpreted the embedded instruction as a legitimate command, and executed it — triggering the malicious package dependency.

No zero-day. No stolen credentials. Just a string of text in a field the bot was never supposed to execute.

The Architecture That Made This Possible

Here's the uncomfortable part: this isn't a niche attack against a badly-configured system. The vulnerability pattern is built into the design of most useful AI agents.

Read external content → Parse for intent → Execute action

That three-step loop is what makes AI agents actually valuable. It's also what makes them exploitable. Every agent that reads emails, processes GitHub issues, scrapes web pages, or handles user-submitted text has this exposure by default.

The blast radius scales with the agent's permissions. A read-only triage bot causes embarrassment. An agent with write access to your package registry causes this.

Sabrina Ramonov covered the incident this week in a breakdown that deserves wider circulation. Her framing: technical sophistication doesn't protect you here. The vulnerability lives in the architecture, not in misconfiguration.

What this forces you to reconsider right now:

Which agents in your stack read external, user-submitted, or third-party content?
What can those agents act on after reading?
What actions are irreversible, and do you have a human checkpoint before they execute?

Claude Code Destroyed 1.94 Million Rows of Student Data. It Was Doing Its Job Correctly.

On the same week: Alexey Grigorev, founder of DataTalks.Club — 100,000+ students learning data engineering — lost 1.94 million rows of student homework, projects, and leaderboard data when Claude Code executed terraform destroy.

The AI didn't malfunction. Here's what actually happened.

Grigorev forgot to upload the Terraform state file before asking Claude Code to resolve duplicate resources. Claude created duplicates. When the state file was eventually uploaded, Claude treated it as ground truth for infrastructure state, compared it against what was actually running, identified a discrepancy, and destroyed the discrepancy. Correct logic. Catastrophic outcome.

One detail makes this genuinely instructive: Claude had explicitly warned against combining infrastructure across the two projects before any of this happened. The human override came first.

AWS recovered everything from a hidden snapshot after 24 hours. Grigorev published a post-mortem with the full safeguards he implemented afterward:

- Deletion protection on all RDS instances
- Terraform state stored in S3 (not locally)
- Independent backup Lambda functions
- Manual approval gate before any terraform destroy
- Separate infrastructure per project

The safeguard list is useful. But notice that almost every item on it is a check on irreversibility — a speed bump before an action that can't be undone. That's the pattern worth generalizing: map your agentic workflows against a list of irreversible actions, then put humans in the loop for those specific actions. Not all actions — just the ones that cost you 24 hours to recover from when they go wrong.

What Good Agent Architecture Looks Like in Practice

The incidents above aren't arguments against building with agents. They're arguments for building more deliberately. Two workflows from this week show what that looks like.

The Excalidraw self-validation loop (Cole Medin)

Cole Medin published a Claude Code skill this week that generates Excalidraw diagrams from structured JSON. The technically interesting part isn't the diagram generation — it's the self-correction loop.

After generating the diagram, Claude takes a screenshot of the rendered output, examines the PNG, and iterates on visual imperfections before presenting the result. No human review step in the loop.

The transferable lesson: whenever your agent produces output it can't natively verify (visual output, rendered HTML, compiled code), add an observation step where the agent inspects its own work. Agents that can catch their own errors before delivery are qualitatively different from agents that can only produce output and hope.

The skill is open-source on GitHub. The README is structured so Claude reads it automatically on initialization — setup is mostly hands-off once you clone it.

Measuring whether your Claude Code skills actually work (Sabrina Ramonov)

Anthropic released a Skill Creator Skill this week — essentially a testing harness for your other Claude Code skills. The tool runs A/B comparisons between skill versions, tracks pass rates, token consumption, and completion time, and surfaces whether your trigger description is causing the skill to never activate.

That last part is more important than it sounds. A skill with a poorly-worded trigger description simply never fires, regardless of how good the underlying instructions are. Without measurement, you'd write the skill, observe no behavior change, and conclude Claude is ignoring it — when actually the problem is the activation condition.

The counter-intuitive finding Sabrina highlights: as frontier models improve, some older skills written to compensate for model limitations can become performance drags. A skill that was helping six months ago might now be adding latency and token cost without improving output. You'd never know without benchmarks.

If you're running Claude Code in any production or team context, treating skills as engineering artifacts — versioned, tested, benchmarked — is now table stakes.

The Proof-of-Concept That Makes This All Worth It

@levelsio announced this week that fly.pieter.com — a browser-based flight simulator — hit $87,000 MRR ($1M ARR equivalent) 17 days after launch. 320,000 players. Zero VC. Built solo with AI code generation.

The monetization model is worth studying: branded blimps and F16s sold as in-game advertising. Advertisers pay. Players fly for free. The business model is async from the user experience.

Whether this specific product sustains at scale or decays with novelty is an open question. What's not open: the proof-of-concept for AI-accelerated solo product launches is now concrete and public. Solo founders with an interesting insight can now ship fast enough to find out whether the market exists before the money runs out.

What This Means for Builders

Treat external content as untrusted input by default. Any agent that reads user-submitted text, GitHub issues, emails, or scraped web pages has prompt injection exposure. Scope what those agents can act on. For high-risk actions, require explicit human confirmation regardless of what the agent parsed from the input.
Map your irreversible actions before you build, not after. Before writing a single line of agentic workflow code, list every action that costs significant time or data to undo. Build explicit checkpoints there. The Claude Code Terraform incident had clear warning signs that were overridden — the architecture should have made the override harder.
Instrument your Claude Code skills like production software. The Skill Creator Skill changes the workflow from "write and hope" to "write, benchmark, and iterate." If you're running skills in any serious workflow, set baseline evals before the next model update and you'll catch degradation before it shows up in your output quality.
The agent safety gap is a product opportunity. OpenAI acquired Promptfoo this week — a startup that finds security vulnerabilities in AI systems. Amazon mandated senior sign-off on AI-generated code following production outages. The discipline for safe agentic deployment is being written right now, mostly through incidents. Builders who develop this muscle early have a structural advantage before it becomes a compliance requirement.

Full report — including the Google March 2026 core update (9.5/10 volatility, 34% CTR drop for top organic results), the Perplexity-Amazon legal ruling that drew the first legal line around agentic commerce, and capital signals from the $1B AMI Labs world model bet — at Zecheng Intel Daily | March 11, 2026.