标签：#devtool

Every developer I know has the same problem: knowledge scattered across five places at once. Browser bookmarks they never re-read. Notion docs that become graveyards. Slack threads with critical context that disappear into the archive. README files that contradict each other. Stack Overflow answers bookmarked with zero recall of why. I tried most of the "second brain" setups and none of them stuck until I figured out why they kept failing: generic productivity systems are not built for how developers actually think and work. A developer's knowledge is fundamentally different from a writer's or a manager's. It is: Code-linked (a note about a library is useless without the actual code it explains) Decision-heavy (architecture decisions need context, rationale, and alternatives considered) Debugging-intensive (solutions to bugs need the exact error message, environment, and what you tried) Time-sensitive (that API migration note is only relevant for a 3-month window) Here is the structure that actually worked. The Core Structure 00-Inbox/ 10-Projects/ 20-Areas/ - Language: Python/ - Stack: AWS/ - Domain: Auth/ 30-Resources/ - Libraries/ - Tools/ - Patterns/ 40-Archive/ The key insight: Resources are evergreen, Projects are temporary, Areas are ongoing responsibilities. A note about how JWT works lives in 30-Resources/Domain-Auth/ . A note about implementing JWT for the current sprint lives in 10-Projects/Sprint-42-Auth-Revamp/ . When the sprint is done, the project gets archived. The JWT fundamentals note stays forever. The Templates That Made It Click Architecture Decision Record (ADR) # ADR-042: Use Postgres over DynamoDB for user sessions Status: Accepted | Date: 2026-06-22 ## Context We need session storage that supports complex queries for the audit log feature. ## Decision Postgres with connection pooling via PgBouncer. ## Alternatives Considered - DynamoDB: rejected (query limitations for audit log requirements) - Redis: rejected (not durable enough for complian

Contacts are messier than they look. A user's real address book is spread across the people they've saved by hand, the people they've emailed often enough that the provider auto-collected them, and the colleagues in their company directory. Google exposes these through the People API; Microsoft through Graph; both model the data differently and split it across sources you have to query separately. The Nylas Contacts API unifies all of that behind one schema and one grant_id . You read saved contacts, auto-collected contacts, and directory contacts through the same endpoint, create and update entries that sync back to the provider, and organize them into groups. This post walks the contact surface from the HTTP API and the Nylas CLI , which mirrors every operation for terminal use. I work on the CLI, so the terminal commands below are the ones I run when I'm exploring an address book. The contact model and its three sources A contact in Nylas carries the fields you'd expect — given_name , surname , emails , phone_numbers , company_name , job_title , notes — plus richer ones like im_addresses , physical_addresses , and web_pages . The schema is the same across providers, so a Google contact and a Microsoft contact deserialize into one struct. The detail that trips people up is source . Every contact has one of three sources, and they mean very different things: address_book — contacts the user saved deliberately. This is the real address book. inbox — contacts the provider auto-collected because the user emailed them. These were never explicitly saved. domain — contacts from the organization's directory (coworkers). Knowing the source matters because "all contacts" usually isn't what you want. If you're building a contact picker, the inbox source can flood it with one-off recipients the user doesn't think of as contacts. Filter by source deliberately. See the Contacts API overview for the full data model. Before you begin You need a Nylas API key and a connected accou

Meeting notes are the feature everyone wants and nobody wants to build. The hard part isn't the summary — an LLM handles that. The hard part is getting into the meeting: a bot that joins Zoom, Google Meet, and Microsoft Teams, survives each platform's waiting room and admission flow, records cleanly, and produces a transcript you can feed downstream. Each provider has its own join mechanics, and none of them ships a tidy "record this meeting" API. The Nylas Notetaker API is that bot as a service. You point it at a meeting link, it joins on schedule, records, and generates a transcript, and you fetch the recording and transcript through one endpoint. This post walks the Notetaker surface from the HTTP API and the Nylas CLI , which mirrors the whole lifecycle for terminal use and quick testing. I work on the CLI, so the terminal commands below are exactly what I run when I'm testing a notetaker against a live meeting. Two ways to run a notetaker: grant-scoped or standalone Before any code, there's one architectural choice worth understanding, because it changes the endpoint you call. A grant-scoped notetaker is tied to a connected account and lives under /v3/grants/{grant_id}/notetakers . Use it when the bot acts on behalf of a specific user — it can read that user's calendar and join their meetings as them. A standalone notetaker has no grant at all and lives under /v3/notetakers . You hand it a raw meeting link and it joins, no connected account required. This is the one to reach for when you just have a URL and want a recording — a public webinar, a meeting on an account you haven't connected, or a system that deals in links rather than users. Same request body, same lifecycle, same media output; the only difference is whether there's a grant_id in the path. See the Notetaker overview for how both models fit together. Before you begin You need a Nylas API key. If you're using a grant-scoped notetaker you also need a connected account; for standalone, the API key al

If your integration polls Nylas every minute to check for new email, you're doing too much work and still getting stale data. Polling is a tax: you burn rate limit on requests that mostly return nothing, and a message that arrives at 12:00:05 doesn't reach your app until the next poll. Webhooks flip that around. Nylas pushes a notification to your endpoint the moment something happens — a message arrives, an event changes, a contact is created — and your app reacts in real time. This post walks the webhook surface from both sides: the HTTP API that registers and manages webhooks, and the Nylas CLI , which has genuinely useful tooling for the part everyone gets stuck on — verifying signatures and testing webhooks against local code. I work on the CLI, so the terminal commands below are the ones I run when I'm wiring up a webhook receiver. Triggers and destinations A webhook has two halves: the trigger types it listens for and the destination URL it pushes to. Trigger types are dotted event names like message.created , event.updated , and contact.created , grouped into categories — grant, message, thread, event, contact, calendar, folder, and notetaker. You subscribe one destination to as many triggers as you want. The CLI lists every available trigger so you don't have to guess the names: # All trigger types nylas webhook triggers # Only message-related triggers nylas webhook triggers --category message Webhooks are application-scoped, not grant-scoped: one webhook registered on your application receives notifications for every connected account, identified by the grant_id in each payload. See the notifications overview for the full event model. Before you begin You need a Nylas API key — webhook management is admin-level, so it uses the application's API key rather than a grant. You also need an HTTPS endpoint reachable from the public internet to receive the notifications. The CLI gets the key set up: nylas init # create an account, generate an API key For local de

Scheduling features look simple until you build them. Google Calendar speaks its own REST API with events.insert ; Microsoft 365 wants Graph and POST /me/calendar/events ; Apple and a long tail of providers expect CalDAV. The moment your app needs to read a user's events, drop a meeting on their calendar, or check whether three people are free at 2pm, you're staring down three integrations that disagree on field names, time formats, and recurrence rules. The Nylas Calendar API gives you one interface over all of them. Connect a user's account once, get a grant_id , and read calendars, manage events, send RSVPs, and compute free/busy with the same request shape whether the backing provider is Google or Microsoft. This post walks the calendar surface from both sides: the HTTP API your backend calls, and the Nylas CLI for testing the same operations in a terminal. I work on the CLI, so the terminal snippets below are the commands I actually run when I'm poking at a calendar. Calendars, events, and the calendar_id A connected account has one or more calendars , and every event belongs to exactly one of them. Most operations take a calendar_id , and the special value primary resolves to the account's default calendar — so you don't need to look up an ID to act on the main calendar. One exception: iCloud doesn't support primary , so for iCloud accounts you pass a real calendar ID from nylas calendar list . An event carries a title , a when object holding its start and end times, a list of participants , an optional location , and flags like busy . That schema is identical across providers, which is the whole point: you read a Google event and a Microsoft event into the same struct. See the Calendar API overview for how calendars, events, and availability fit together. Before you begin You need a Nylas API key and a connected account with calendar scopes. The CLI gets you there in two commands: nylas init # create an account, generate an API key nylas auth login # connect

Most "AI email" demos point a model at a human's inbox over OAuth. That's fine until you want the agent to be a participant — to have its own address that people reply to, that calendars invite, and that builds its own sender reputation. Pointing at someone's personal inbox doesn't give you that. Nylas Agent Accounts take the other approach: a real name@yourdomain.com mailbox and calendar that the agent owns end to end. It sends, receives, hosts events, and RSVPs — and to anyone on the other side it's indistinguishable from a human-operated account. It went GA in June 2026. The part I like as an SRE: it's not a new API surface. An Agent Account is just another Nylas grant . It gets a grant_id that works with every endpoint you already use — Messages, Drafts, Threads, Folders, Attachments, Calendars, Events, Webhooks. Nothing new to learn on the data plane. This walkthrough provisions one two ways (CLI and raw API), then sends, receives, RSVPs, and adds guardrails. What you get When you create an Agent Account, Nylas provisions a real mailbox on a domain you've registered (or a Nylas *.nylas.email trial domain). Each account comes with: An email address that sends and receives like any other mailbox Six system folders ( inbox , sent , drafts , trash , junk , archive ), plus any custom ones you create A primary calendar that hosts events and RSVPs over standard iCalendar/ICS A grant_id for all the existing Nylas endpoints Before you begin You need two things: A Nylas API key. The fastest path is the CLI — nylas init creates an account and generates a key in one command. A domain. Either a Nylas-provided *.nylas.email trial subdomain (good for testing in minutes) or your own custom domain with MX + TXT records. Register it under Organization Settings → Domains. Why your own domain? It's what makes the agent a real first-class sender instead of a shared relay address — people reply to it, calendars invite it, and its mail authenticates as coming from you. A new domain b

You've probably seen that trending post — "I Asked AI to Write My Commit Messages and It Was Embarrassing." Same. But instead of accepting embarrassing output, I fixed it. Here's the thing: the problem isn't AI writing commit messages. The problem is how you ask it. One clear system prompt + the actual diff = surprisingly good results. The Setup No new packages. No API key. If you have Claude Code , you're already set. #!/usr/bin/env python3 import subprocess SYSTEM = ( " You are a git commit message generator. " " Output ONLY the commit message — no explanation, no markdown, no quotes. " " Follow Conventional Commits: type(scope): subject. " " Types: feat, fix, docs, style, refactor, test, chore. " " Subject: imperative, lowercase, max 72 chars. " ) diff = subprocess . check_output ([ " git " , " diff " , " --staged " ], text = True ) if not diff . strip (): print ( " Nothing staged. Run `git add` first. " ) raise SystemExit ( 1 ) msg = subprocess . check_output ( [ " claude " , " -p " , SYSTEM + " \n\n " + diff ], text = True , ). strip () print ( msg ) That's it. 20 lines. Uses the claude CLI under the hood — no API key, no config, just your existing Claude Code OAuth session. Why It Works The system prompt does the heavy lifting. Three constraints: Output ONLY the commit message — no preamble, no explanation Follow Conventional Commits — feat , fix , chore , etc. max 72 chars — keeps it readable in git log The diff is the context. You're not asking "write a commit message". You're asking "given these exact changes, what happened?" That's a much more answerable question. Usage # No setup needed if you have Claude Code. Just: git add . python /path/to/git_commit.py # → feat(server): add AI commit message generator via Claude CLI Or wire it into a git alias: git config --global alias.ai '!python /path/to/git_commit.py' # git ai The Results Before: update stuff fix bug WIP added the thing After: feat(api): add generate_commit_message tool to MCP server fix(auth): ha

The Problem Most AI assistants give you one model's answer. If it's wrong, you catch it or you don't. If you use a cheap model, quality drops. If you use a frontier model, you pay frontier prices for everything — even a simple file rename. What is Agentic Fusion? When you run /fusion , a panel of models collaborates on your task: Planners (up to 5): Read-only models that research and propose routes in parallel. They figure out the best approach but can't touch your files or run commands. Main model : Your chosen model does the actual work — full tool access, fully visible. You watch every step. Not a black box. Reviewers (up to 5): Read-only models that critique the draft. They can see images the main model generated. They check for errors, suggest fixes, flag issues. Verdict loop : The draft is revised until reviewers approve. The answer you get has already passed independent review. Fusion : Everything combines into one reviewed, approved answer. The quality comes from synthesis — not from running the same job 5 times. Cheap open models combine into something that rivals a frontier model at a fraction of the cost. Safety by Construction Planners and reviewers are read-only at the schema level. They can research and critique, but they can never touch your files or execute commands. Only your main model has tool access, and you watch it work live. Beyond Fusion Clioloop is also: Self-improving : Keeps MEMORY.md and USER.md , updated automatically Autonomous : Set a standing goal with /goal and it loops until done Everywhere : Terminal, desktop app, web dashboard, Telegram, Slack, Discord, WhatsApp Multi-agent Kanban : Break big work into tasks with worker agents Tools : File editing, shell, web search, browser, image/video gen, TTS, MCP Scheduled jobs : Run on cron for automated workflows Open-source : Self-host everything, own your data The Omni Loop Portal One OAuth login gives you access to 300+ models. No API keys. An OpenAI-compatible proxy means any tool works

This week's tooling news clusters around a recurring theme: removing dependencies that were never really necessary. Biome ditches the TypeScript compiler for type-aware linting. Swift developers stop caring which editor they're in. And the most interesting finding of the week is that a 1990s text-retrieval algorithm outperforms GPT-4 at catching lying agents. Here's what's worth your attention. Swift Extension Lands on Open VSX Registry The official Swift extension is now published to the Open VSX Registry, which means Cursor, VSCodium, AWS Kiro, and any other LSP-compatible editor that doesn't use the proprietary VS Code Marketplace can now auto-install it without you doing anything. Code completion, debugging, and the test explorer just work. This matters because the Swift toolchain has always been Xcode-or-fight. Any serious cross-platform Swift work meant manually tracking down extensions, pinning versions, and hoping nothing broke when someone cloned the repo on a different machine. Agentic IDEs that provision their own extensions automatically—like Cursor and Kiro—now get Swift support without intervention. Verdict: Ship. If you're already in an Open VSX-compatible editor, there's nothing to configure. Zero blocking concerns; this is a pure reduction in setup friction. Biome v2 Adds Type Inference Without TypeScript Biome v2 ships its own type inference engine, decoupling type-aware linting rules from the TypeScript compiler entirely. The headline number is 75% detection parity on floating promise rules compared to typescript-eslint—lower recall, but at meaningfully lower install weight and CI overhead. Multi-file analysis also lands in v2, unlocking rules that require cross-module context that were structurally impossible in v1. The real value proposition isn't feature parity—it's dependency elimination. Pulling TypeScript out of your lint pipeline reduces cold-start times in CI and removes a whole class of version-mismatch bugs between typescript , @typescri

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

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

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: