标签：#devto

This week's releases split neatly into two categories: useful incremental hardening (uv, GitLab, Copilot) and things that should change how you architect systems today (Spring CVEs, pg_durable, and a Cornell paper that quietly invalidates a lot of RAG assumptions). The Spring security cluster alone is enough to justify a dependency audit before the weekend. uv 0.11.19 adds CPython 3.15 beta support uv now always computes SHA256 checksums for remote distributions—previously this was situational—and adds PyEmscripten platform support per PEP 783, which formalizes Python packaging for browser and WASM targets. CPython 3.15.0b2 is available as a managed runtime, and a cross-platform installation edge case on Windows hosts has been resolved. The SHA256 change is the one worth noting for security posture. Making verification unconditional rather than optional closes a gap where distribution integrity could go unchecked depending on resolver path. The PyEmscripten addition matters if you're packaging Python for browser runtimes—previously you were working around the absence of a formal platform tag; now you're not. Verdict: Ship. Drop-in upgrade, no breaking changes. If you manage Python distributions or target WASM, update now. Everyone else should still update—supply-chain hardening by default is worth the two minutes. GitLab 19.0 adds group-level review instructions, secrets manager GitLab 19.0 ships two meaningful additions for teams: group-level custom review instructions for Duo code review, configured via .gitlab/duo/mr-review-instructions.yaml with cascading inheritance across projects, and a Secrets Manager that exits closed beta for Premium and Ultimate tiers. Group-level review instructions solve a real annoyance—if you've been maintaining per-project AI review configuration across a monorepo organization, you can now centralize that and let projects inherit or override. It's the kind of change that sounds minor until you've had to sync a guideline update across

This week's AI tooling news splits cleanly between infrastructure you can ship today and capability bets that require more careful evaluation. Anthropic dropped two significant releases—Fable 5 and Managed Agents updates—while the Workflow SDK landed a cancellation primitive that eliminates entire categories of homegrown plumbing. Underneath all of it, a sharp incident review from Anthropic is the most practically useful thing published this week if you're running multi-turn agents in production. Workflow SDK adds AbortController cancellation support The Workflow SDK now threads AbortSignal through workflow steps, using the same web-standard API you already use with fetch . Pass an AbortSignal into your workflow, inspect it inside steps, and you get cooperative cancellation that survives durable suspension and replay. This matters because cancellation in long-running workflows has historically required custom infrastructure—timeout flags passed through context, manual cleanup hooks, bespoke race logic. That's not interesting code to write or maintain. With AbortController support, you get timeout steps, request racing, and parallel work cancellation with patterns your team already knows. Two important caveats: this requires workflow@beta , and cancellation is cooperative. The runtime won't forcibly terminate a step—your step code needs to inspect the signal and respond. If you have steps with opaque third-party calls that don't accept signals, you're still writing wrapper logic. Verdict: Ship. If you're on Workflow SDK 5 and running long-horizon workflows with timeout or race requirements, upgrade and wire this in now. The pattern is standard, the boilerplate reduction is real, and there's no meaningful downside if your steps are already structured around explicit control flow. Anthropic adds dreaming, outcomes to Managed Agents Two distinct additions here. Outcomes let you define explicit success criteria enforced by a separate grader agent—replacing manual prompt

This week's tooling news splits cleanly between performance and compliance: a Go Protobuf parser that closes the gap between reflection and generated code, and a GitLab update that finally makes air-gapped AI deployments practical. Layered in are a forced AWS migration, a cost-pressure move in reasoning model pricing, and an Elasticsearch alternative picking up serious enterprise backing. Here's what's worth your attention. hyperpb Dynamic Parser Matches Generated Code Speed hyperpb is a runtime-compiled Protobuf parser for Go. You feed it a schema at startup, it runs an optimization pass, and the result is a compiled message type you can reuse across requests. Benchmarks show 10x faster parsing than dynamicpb and roughly 3x faster than hand-written generated code. The implication for generic Protobuf services—brokers, validators, schema registries—is significant. If you're doing broker-side validation today with dynamicpb , you're likely throttling throughput or skipping validation under load. hyperpb removes that tradeoff. The catch is that compiled types require caching (the optimization pass is slow and should not run per-request) and field access remains reflection-only—you're not getting struct field ergonomics. Verdict: Ship. If your validation pipeline is hitting dynamicpb throughput limits, this is a drop-in replacement for the hot path. Cache your compiled message types at initialization, and profile field access patterns before assuming it fits your read-heavy workloads. Quickwit Joins Datadog, Relicenses to Apache 2.0 Quickwit, the Rust-based petabyte-scale log search engine, has been acquired by Datadog and relicensed from AGPL to Apache 2.0. Development continues as open source. Distributed ingest and cardinality aggregations are on the near-term roadmap. The production credibility is already there—Binance runs 1.6PB/day through it, Mezmo has petabyte-scale logs in production. The Apache 2.0 relicense removes the corporate control concern that kept som

This week's tooling landscape is quieter on the AI-native side but dense with infrastructure moves that affect how AI-driven workloads actually run in production. Cloudflare's Workflows scaling overhaul is the clearest signal: agent-triggered execution is now an assumed pattern, not a novelty, and platforms are rearchitecting accordingly. The rest of the week rounds out with a kernel maintenance drop, a meaningful abstraction removal in tRPC, and a Biome beta that's finally making ESLint replacement feel plausible. Linux 7.1 Released with Driver and Networking Fixes 7.1 is a maintenance release. No architectural changes, no new subsystems—just patches you should care about if you're running affected hardware or kernel-adjacent tooling. The two fixes worth flagging are heap overflows in the USB serial io_ti driver ( get_manuf_info() and build_i2c_fw_hdr() ), plus memory leak corrections scattered across drivers and networking subsystems. Trace tooling also gets updates, which matters if you're doing kernel-level performance analysis on production systems. One operational note: Torvalds is traveling, so merge window latency may be irregular. If you're tracking pull request timelines for custom kernel builds, plan for slippage. Verdict: Ship — if you're on 7.0 and running USB serial hardware or affected networking paths, upgrade on your normal kernel cycle. No breaking changes, no new dependencies, nothing to validate beyond your existing regression suite. tRPC Drops Abstraction Layer for React Query This is the kind of change that looks small in a changelog and feels large in daily development. The new tRPC client exposes native TanStack Query interfaces— QueryOptions and MutationOptions —directly, rather than wrapping them in tRPC-specific hooks. The practical effect: if you're already using TanStack Query elsewhere in your app, you stop context-switching between two similar-but-different mental models. You call .queryOptions() and .mutationOptions() factories and pa

Disclosure up front: I'm affiliated with diagram.now — I'm connected to the product. I'm posting this to get developer feedback on diagram import/export interoperability, not to pitch an install. Most teams I've worked with don't have one source of truth for their diagrams. They have: a few Mermaid blocks living in READMEs and Markdown docs, an old Visio ( .vsdx ) or Lucidchart file someone made two reorgs ago, a SQL schema that is secretly the "real" ERD, and a pile of screenshots pasted into docs and tickets. The diagram is rarely the hard part. The hard part is that the same diagram lives in five formats and none of them stay in sync with the docs they're supposed to explain. I've been working on diagram.now , a browser-based editor for technical diagrams — flowcharts, UML, ERD, BPMN, cloud/network architecture, mind maps, wireframes. It's a free browser editor with no signup to start. There's an optional Confluence app for teams that want diagrams editable inside Confluence pages, but that's intentionally not what I want to talk about here. I want feedback on the editor itself, and specifically on the interoperability story. What it does today Import/insert from Mermaid and SQL — paste a Mermaid graph or a CREATE TABLE block to start an editable diagram instead of a static render. Import Lucidchart and Visio .vsdx files — this is migration-oriented, and honestly the part I most want real-world files to stress-test. Export to PNG, SVG, PDF, or a URL. Templates/shapes for the diagram categories above. I'm deliberately keeping the Confluence side secondary. The thing I actually want to learn is whether the browser editor plus import/export is useful on its own. Where I'd love feedback Imports: Which format matters most to you — Mermaid, SQL→ERD, .vsdx , Lucidchart, or something else (PlantUML, draw.io XML, Graphviz)? If you've ever tried to migrate diagrams between tools, where did it break? URL export: Is a shareable diagram URL genuinely useful in your workflow (

AI agents are making software development faster. That is great. But there is a problem I do not think we are talking about enough: testing is not speeding up in the same way. In many teams, testing is still held together by spreadsheets, meeting notes, screenshots, chat messages, and the memory of a few experienced QA engineers. That worked when delivery was slower. It becomes fragile when one developer can use multiple agents to change code across several modules in a single afternoon. The bottleneck is no longer "can we write more test cases?" The bottleneck is: Can the team prove what was tested, why it was tested, what failed, what was fixed, and whether the release is safe? That is the problem I built testboat for. The Most Dangerous Sentence Before A Release The sentence I worry about most is not: We did not test this. At least that is honest. The dangerous sentence is: I think we tested this. That sentence usually means the team has test artifacts, but they are disconnected: requirements live in a doc test cases live in a spreadsheet automation scripts live somewhere in the repo execution results live in CI logs or chat bugs live in an issue tracker release reports are written manually before sign-off Each piece may be useful on its own. But when a Tech Lead asks, "Which requirements are not covered?" or a founder asks, "Can we release today?", the team has to reconstruct the answer manually. That is not a testing process. That is institutional memory under pressure. AI Makes This Gap Worse AI agents are very good at increasing throughput. They can: implement a feature faster refactor code faster generate UI faster write automation faster fix bugs faster But faster change creates more testing uncertainty. If an agent changes the authentication module, what should be rerun? If a test fails, is it a product bug, a flaky automation script, or an environment issue? If a developer says "fixed", has the failed test actually been rerun? If a release report says "ma

Every developer has done it. You hit a README, you see the install command: curl -fsSL https://example.com/install.sh | sh And you run it. Maybe you skim the script first. Maybe you don't. But you run it. I've been doing this for years. And each time, a small voice in the back of my head says: you have no idea what that script actually does. You just piped a stranger's code straight into your shell. Eventually I got tired of ignoring that voice. What the pattern actually is curl | sh is not a bad pattern — it's a fast, convenient pattern with a real trust gap. The script runs with your permissions, in your shell, right now. It can: Install something with sudo Delete files with rm -rf Write to your disk with dd Access your SSH keys or .env files Set up a cron job or a systemd service that runs again next reboot Decode and run a payload with base64 | eval Most install scripts do none of these things maliciously. But many do several of them legitimately — and you wouldn't know which ones until something went wrong. --- ## What I built instead I'm a solo founder based in Ouagadougou, Burkina Faso. I build with heavy AI pairing — I'm not a trained engineer, I work with Claude, review the output, and ship. This tool ( peek ) was AI-paired and reviewed by me before release. peek is a ~130-line POSIX shell script that sits in front of the pattern: # Instead of: curl -fsSL https://example.com/install.sh | sh # Do: peek https://example.com/install.sh Before anything runs, peek: Fetches the script Scans it for risky patterns Prints a risk score and the exact dangerous lines Asks you to confirm — and refuses to auto-run a HIGH-RISK script unless you type RUN You can also pipe into it, or run it in analysis-only mode: curl -fsSL https://example.com/install.sh | peek # analyze from a pipe peek --print ./downloaded.sh # never runs, analysis only What it flags (and what it doesn't) The patterns peek checks: Root escalation — sudo , running as root Destructive file ops — rm -rf , fi

AI for API Design & Testing in 2026: Speakeasy vs Swagger AI vs Postman AI — I Built 3 APIs with Each API design is one of the most tedious parts of backend development. Writing OpenAPI specs, generating SDKs, testing endpoints, maintaining documentation — it's all hours of work that could be automated. In 2026, three tools are fighting for your API workflow: Speakeasy , Swagger AI , and Postman AI . I spent 4 weeks building the same REST API with each one, tracking time savings, code quality, and actual developer experience. Here's what actually happened. The Test Setup: Building a Real API I built a simple but realistic ecommerce API (GET/POST products, orders, user management) three separate times, measuring: Time to spec — writing the OpenAPI definition Time to SDK generation — generating client libraries Time to testing — setting up test cases and running them Documentation quality — readability, examples, completeness Iteration speed — how fast you can modify the API and regenerate everything All three tools were given the same requirements. Same laptop, same environment, same skill level (senior backend engineer). Speakeasy: The SDK Generation King Setup time: 8 minutes (CLI install, auth, first config) Learning curve: Low — clear docs, straightforward CLI Speakeasy is laser-focused on one problem: turning your API spec into production-ready SDKs. It generates TypeScript, Python, Go, Java, and more from a single OpenAPI definition. The Good SDK quality is exceptional. The generated TypeScript SDK was production-grade immediately — proper error handling, retry logic, request/response typing, retries built in. No cleanup work needed. Multi-language generation is instant. After writing the OpenAPI spec once, I had Python, Go, and TypeScript SDKs in < 2 minutes total. Each one was framework-idiomatic (using popular libraries in each language). Versioning is smart. Speakeasy automatically versioned SDKs and generated changelogs. When I modified the spec, it detect

Two weeks ago I published a piece explaining exactly why AI detectors are unreliable. Then Sloan...

Hermes AI Agent handles multi-step workflows well. The planning layer holds up. Memory across sessions works. What kept breaking down was the tool layer. Once a workflow touched three or four external systems, I was spending more time on auth configs, mismatched response formats, and per-tool retry logic than on the workflows themselves. I fixed this by routing all external tool calls through a unified MCP gateway. The agent logic stayed the same. The integration complexity moved into one place I could actually manage. This post walks through how that works, how to set it up, and where it is genuinely useful. How Hermes runs tasks Hermes is an open-source, self-hosted agent runtime from Nous Research, released in February 2026 under the MIT license. It runs persistently on your own infrastructure and executes goals as structured, stateful workflows. Four layers handle execution. The planning layer breaks a goal into sequenced steps and adjusts them as intermediate results come in The execution layer runs each step and fires tool calls when external data or action is needed The memory layer stores task state and session history in SQLite with FTS5, so context carries over across restarts The skills layer captures completed workflows as reusable documents retrieved on future tasks After a task finishes, Hermes writes a skill file with the procedure and known failure points, then stores it for retrieval next time a similar task runs. Tool execution is embedded in the runtime loop. External capabilities come through MCP-based interfaces, which is where the gateway plugs in. What breaks when integrations live inside the agent In a standard MCP setup, each client connects one-to-one with a specific MCP server. That works fine with two or three tools. With ten, it becomes a maintenance problem that grows with every tool you add. A task spanning a web search, a product API, and a SERP scraper means three separate auth setups, three response formats to parse, and three diffe

Mine got flagged twice in one day. Both essays generated more engagement than anything else I've...

Every AI agent skill you write burns context on every turn. Not just when the skill is running. On every turn. The agent keeps each skill's name and description loaded permanently so it knows when to invoke them. A vague description is not just a documentation problem. It is a tax you pay per message, forever. That is the problem I built skillscore to catch. When addyosmani/agent-skills hit 52,000 stars and went to #1 trending on GitHub, I had my benchmark. 24 production-grade skills written by people who clearly know what they are doing. If a static linter has anything useful to say at this level, this is where to find out. So I ran it. One command. 24 skills. Two seconds. This is what skillscore 0.2.0 can do now: skillscore /path/to/agent-skills/ One command scores everything in the tree. Here is the output: Three skills from addyosmani/agent-skills scored in one command, then a drill-down into the lowest scorer. The full results Skill Score Grade spec-driven-development 91 A browser-testing-with-devtools 91 A deprecation-and-migration 91 A frontend-ui-engineering 91 A test-driven-development 88 B code-review-and-quality 88 B interview-me 86 B ci-cd-and-automation 85 B code-simplification 85 B context-engineering 85 B documentation-and-adrs 85 B incremental-implementation 85 B security-and-hardening 85 B shipping-and-launch 85 B source-driven-development 85 B using-agent-skills 85 B doubt-driven-development 80 B observability-and-instrumentation 80 B planning-and-task-breakdown 80 B api-and-interface-design 78 C debugging-and-error-recovery 77 C git-workflow-and-versioning 77 C idea-refine 77 C performance-optimization 77 C Average: 84/100 (B) To be clear: 84 across 24 production skills is excellent. No failures. No D grades. Most skill libraries I have tested do not get close to this. The instruction content inside these skills is genuinely good. What the linter found is at the edges, not in the core. Two gaps. Five skills. Every single C. I drilled into all five

The default for AI-assisted development is one of two failure modes. Either you're babysitting the agent line by line — approving each diff, re-explaining context it dropped three messages ago — or you've handed it the wheel and you're hoping the PR that lands at the end resembles what you asked for. Son of Anton is neither. It's a delivery orchestrator built on a single claim: there are exactly three moments where a developer's judgment is irreplaceable. The orchestrator owns everything in between. The three gates Every project moves through three human decision points. Nothing important happens without you signing off. Gate 01 — Approve the WHAT ( /soa plan ) A grill-me session forces the AI to surface its assumptions, constraints, and scope decisions back to you before a single ticket exists. You say yes or you refine. It does not proceed until you have. Gate 02 — Approve the HOW ( /soa decompose ) The approved plan becomes a ticket stack — ordered, dependency-aware, sized for review. Architectural judgment stays with you. Ticket authorship goes to the agent. Gate 03 — Approve DONE ( /soa closeout ) An adversarial subagent reviews every ticket before its PR opens. When the phase is complete, you decide whether to accept. Closeout squash-merges the stack onto main. Nothing merges without you. Between the gates, you are not needed That's the whole point. Once you've approved the plan and the tickets, the orchestrator runs the loop:

Every tool sprawl thread I read starts with license math, and license math is a decoy. Last quarter I added up what our seven-tool delivery stack actually cost us, and the subscriptions came to about 15% of the total. The other 85% never appears on an invoice, which is exactly why nobody budgets for it and nobody fixes it. Some background so you can judge whether my numbers transfer to your team. I spent years building automation in banking before running my own product team, so I am professionally allergic to process waste. Despite that, our stack had drifted into the usual shape: Jira for tickets, Confluence for docs, Lucidchart for architecture, TestRail for test cases, two spreadsheets doing unpaid overtime in the gaps, and an AI chatbot bolted on the side that had never seen any of it. The licenses for all of that, for six people, ran about $700 a month. Annoying. Not a crisis. And that is precisely why the "consolidate your tools" pitch dies in so many budget conversations. Saving a few hundred dollars a month does not justify a migration, and everyone in the room knows it. If licenses were the real cost, I would side with the skeptics. The audit: two weeks of logging every re-key So we measured the part nobody measures. For two weeks, everyone on the team logged every re-key: any moment a human moved or restated information that already existed in another tool. Copying acceptance criteria from Confluence into a Jira ticket. Updating TestRail because a story changed shape. Redrawing a Lucidchart flow that had drifted from the code. Reassembling a status update by hand from three tabs. Pasting project context into the chatbot, again, because it forgot everything since yesterday. The rules were strict so the number would survive scrutiny. Log transfer time only, not thinking time. Round down when unsure. If the same fact got re-keyed twice, log it twice, because it cost twice. Each entry went into a shared CSV with four columns, and this script turned it into th

I didn't set out to build a content API. I set out to stop copy-pasting. Every week, the same ritual: open a doc, stare at a blank page, write a headline, delete it, write it again. Multiply that by every client, every product page, every email drip campaign. I wasn't doing creative work — I was doing assembly-line work while pretending it was creative. PostAll started as a script I wrote to stop doing that. The API is what that script became after other developers asked if they could use it too. This guide walks you through integrating PostAll's API into your own workflow — authentication, the endpoints you'll actually use, real working code in both Python and Node.js, and the specific places things will break before they work. By the end, you'll have a functioning pipeline that generates formatted, CMS-ready content programmatically. What you'll build A script that takes a list of content briefs (keywords, tone, target length) and returns publish-ready content — with proper formatting, metadata, and error handling for the rate limits you'll hit in production. Here's the shape of what you're building: [ CSV of briefs ] → [ PostAll API ] → [ formatted content objects ] → [ your CMS / database ] The full working code for both languages is at the end of each section. I'll explain the interesting parts inline. Prerequisites A PostAll account with API access enabled (free tier works for this guide — rate limits noted below) Node.js 18+ or Python 3.10+ Basic familiarity with async/await in either language An HTTP client: axios or native fetch for Node, httpx for Python Step 1: Authentication PostAll uses API key authentication. Every request needs your key in the Authorization header. Get your key: Dashboard → Settings → API Keys → Generate New Key Store it as an environment variable. Never hardcode it. export PostAll_API_KEY = "postall_live_xxxxxxxxxxxxxxxxxxxx" Your key has two prefixes: postall_live_ for production, postall_test_ for the sandbox. The sandbox returns r

Every low-code vendor says "we support customization." But supports is a weasel word — recoloring a button is customization, and rewriting a scheduling engine is also customization. What actually decides whether a platform locks you in is how far up its extensibility goes. Here's a ruler. The three levels of customization Level What you can do Most no-code A real dev framework L1 — Config Fields, forms, workflows, permissions, themes ✅ ✅ L2 — Extension Custom components, custom actions, external API calls, business rules ⚠️ limited ✅ L3 — Framework Modify/extend the core, custom engines, deep rewrites, source under control ❌ wall ✅ (when open/controllable) Where it stops is where your ceiling is. Plenty of no-code platforms are delightful at L1, then hit "can't do that" at L2/L3 — and you retreat to writing your own thing next to it. Now low-code is the burden. Why you get locked in Black-box SaaS — no source, so any extension point the vendor didn't expose is simply out of reach. Two sources of truth — your extension code and the platform's config live in different systems, so a platform upgrade breaks/voids your work. Crippled self-hosting — the on-prem edition quietly drops extension capabilities. Closed ecosystem — only their component marketplace; your stack can't get in. How model-driven + open source raises the ceiling One unified extension system — your extensions (custom fields/components/actions) and the platform itself are built on the same metadata. Extension isn't a bolt-on, it's a first-class citizen — upgrades don't wipe your customizations. Source under your control — open + self-hostable is what makes L3 framework-level extension actually possible: an extension point you can't reach, you can add. AI at the metadata layer — AI-generated extensions land in the same model, so they stay maintainable and evolvable. That's the road Oinone takes: 100% metadata-driven, front + back end open source, self-hostable — customization reaches L3. How to stress-tes

Intro You’re using ChatGPT or Claude to speed up development. Good. Then suddenly: your migrations are broken. AI tools love editing files they shouldn’t touch , especially: SQL migration scripts EF Core migration files Schema snapshots This is dangerous. One wrong change can corrupt your database history. Recognize migration files EF Core migrations Typical structure: /Migrations/ 20240101120000_InitialCreate.cs 20240102130000_AddUsers.cs MyDbContextModelSnapshot.cs Example: public partial class AddUsers : Migration { protected override void Up ( MigrationBuilder migrationBuilder ) { migrationBuilder . CreateTable ( name : "Users" , columns : table => new { Id = table . Column < int >( nullable : false ) }); } } SQL migrations /db/migrations/ V001__init.sql V002__add_users.sql Example: CREATE TABLE Users ( Id INT PRIMARY KEY ); Key indicators Timestamp or version prefix Sequential naming Contains schema changes only Stored in a dedicated folder Understand the risk WRONG (AI rewriting history) AI might do this: // Modified existing migration (BAD) migrationBuilder . DropTable ( "Users" ); migrationBuilder . CreateTable ( "Customers" ); or: -- Edited old migration (BAD) ALTER TABLE Users RENAME TO Customers ; This breaks every environment except fresh ones. This is extremely dangerous if your AI does not recognize them. CORRECT (append-only) Always create a new migration : // New migration migrationBuilder . RenameTable ( name : "Users" , newName : "Customers" ); Step 3: Lock migration files from Claude AI editing Explicit blocking of editing We will create 2 new files. These files will instruct that CALUDE is not allowed to modify existing files. What we actually want to achieve is a way to keep appending the files. { "$schema": "https://json.schemastore.org/claude-code-settings.json", "hooks": { "PreToolUse": [ { "matcher": "Edit|Write|MultiEdit", "hooks": [ { "type": "command", "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/block-migration-edits.sh\"" } ] }

Last week I did something dumb: I sat down and wrote 50 Claude Code prompts in one sitting. Halfway through I was sure most of them would never get used. But I finished, pushed them to GitHub, and made myself use them for an entire week -- no ad-hoc prompting allowed. The result surprised me. Some skills were life-changing. Others were useless. Here is the honest breakdown. The Methodology I categorized the 50 skills into 5 types: Analysis (12), Generation (14), Debugging (8), Planning (10), Maintenance (6). Rule: every time I hit a task, I must use a skill file or admit I did not have one. The 7 That Actually Saved Me Hours 1. Code Review Assistant (saved ~3h) This was the biggest surprise. I usually review PRs by gut feel -- scan the diff, look for obvious bugs, approve. The Code Review skill forced me to be systematic: On a 400-line PR it caught 2 security issues I would have missed. That alone justified the experiment. 2. Bug Investigator (saved ~2h) Instead of pasting errors and asking "why?", this skill forces you to provide: error message, file context, hypothesis. 3. Dependency Audit (saved ~1h) Scanned a 3-year old Node project. Found 2 CVEs, 8 unused devDependencies (21 MB). 4. Auto Commit Messages (saved ~30m) Saves 2 minutes per commit. Over 15 commits in a week that is 30 minutes. 5. Test Generator (saved ~2h) Generates 5-8 test cases per function in seconds. 6. Refactoring Planner (saved ~1h) Reads the function, identifies extraction candidates, outputs a dependency-ordered plan. 7. Performance Audit (saved ~30m) Found an unoptimized 3 MB hero image and a render-blocking script. The Ones I Never Touched About 8 out of 50 were "not this week" -- Database Migrations, API Documentation, CI/CD Pipeline. What I Learned The ROI is in the analysis skills. Code review, bug investigation, dependency audit -- these are high-judgment tasks where Claude thoroughness beats speed. Skills are habit, not technology. The hardest part was not writing the prompts -- it w

Coding agents — Codex CLI, Claude Code, Cursor, and Pi — are productivity multipliers. But they all assume you are happy sending your code to someone else's servers. For many of us that is a deal-breaker: proprietary codebases, client NDAs, compliance requirements, or just the principle of owning your own compute. This guide shows how to swap out every cloud API with a local Ollama server running qwen3-coder:30b . Same tools, same workflows, no data leaving your network. Why Run AI Locally? The case is simple: Zero data exfiltration. Your code never leaves your machine or LAN. No per-token cost. Run 10,000 completions or 10 — the electricity bill does not care. Works offline. Airplane mode, restricted network, flaky VPN — irrelevant. No rate limits. No 429s at 2 am when you are in flow. The honest tradeoff: frontier models (Claude Opus 4, GPT-5) still outperform local models on complex multi-step reasoning and very large context tasks. For the 80% of day-to-day coding work — autocomplete, refactors, test generation, documentation — a well-chosen local model is more than good enough. Hardware Requirements I run this on an Apple M4 Pro with 48 GB unified memory . Apple Silicon's unified memory architecture is exceptionally well-suited to LLM inference: the GPU and CPU share the same memory pool, so a 22 GB model fits comfortably alongside a full development environment. Minimum viable setup: RAM What fits 16 GB 7–8B parameter models (qwen3:8b, llama3.2:8b) 32 GB 14–20B models (qwen3:14b, gpt-oss:20b) 48 GB 30–35B models (qwen3-coder:30b, qwen3.6:35b) 64 GB+ 70B models (deepseek-r1:70b, llama3.3:70b) On Intel/AMD systems with discrete GPUs the math is different: VRAM is the bottleneck, and models that don't fit entirely in VRAM fall back to slow CPU offloading. Choosing a Model For 48 GB unified memory, these are the models worth knowing about: Model Size on disk Active params Strengths qwen3-coder:30b ~22 GB 3.3B (MoE) Coding, 256K context, HumanEval SOTA qwen3.6:35b

Most AI short-form video demos skip the boring part. They show a finished TikTok, Reel, or YouTube Short. Maybe they show the prompt. Maybe they show the generated script or the final render. But the hard part is not making one video. The hard part is making the fifteenth video without the whole system turning into a pile of one-off scripts, half-remembered FFmpeg commands, broken captions, inconsistent hooks, and manual upload steps. That is where I think the conversation around AI video automation gets more interesting. Not: Can an AI generate a Short? But: What workflow does an AI agent need to generate Shorts repeatedly? I was looking at a Terminal Skills use case for building an AI short video generator, and the useful part is not the fantasy of "push one button, print infinite content." The useful part is the stack. The real job is a pipeline A short-form video generator sounds like one tool. In practice, it is a pipeline: topic research -> script -> voiceover -> footage or visual generation -> subtitles -> assembly -> platform formatting -> upload -> analytics Each step has different failure modes. Topic research can produce generic ideas. Scripts can be too long. Voice can drift from the brand. Footage can mismatch the narration. Subtitles can land under platform UI. FFmpeg can export a technically valid file that a platform still hates. Uploads can succeed in the API but fail the actual publishing workflow. If you try to solve all of that with one giant prompt, the agent has to keep too much operational knowledge in its head. That is fragile. The better pattern is to split the workflow into skills. What a skill gives the agent A skill is not just a code snippet. For this kind of workflow, a useful skill tells the agent: when to use this capability what inputs are expected what output should exist afterward what validation is required when to stop instead of pretending success That last point matters. For media automation, "the command ran" is not enough. Th