标签：#devtools

Before you rename, move, or delete a Python module: who still imports this? Grepping hits strings and comments. Importing the package can run side effects. whoimports walks the tree with the AST and prints every matching import / from … import line. Install pip install git+https://github.com/SybilGambleyyu/whoimports.git Usage whoimports src/auth/session.py whoimports auth.session -f json whoimports pkg.util -f md Notes Zero dependencies, Python 3.10+ File paths and dotted module names Understands src/ layouts text / markdown / JSON output Pairs with gitchurn and redactx for safe refactor context. Source: github.com/SybilGambleyyu/whoimports · MIT

Cut the noise. Keep the stack traces. CI logs are mostly package installs. The failure is a few dozen lines buried under thousands of Downloading… lines. Scrolling for the real stack trace is a tax paid on every red build. logsnip is a zero-dependency Python CLI that extracts those failure regions and collapses the rest. Install pip install git+https://github.com/SybilGambleyyu/logsnip.git # or the whole toolkit: curl -fsSL https://raw.githubusercontent.com/SybilGambleyyu/devkit/main/install.sh | bash One-liners # Last failure from a GitHub Actions run gh run view --log-failed | logsnip --last # Headlines only logsnip ci-full.log --summary # Safe to paste into an AI assistant gh run view --log-failed | logsnip --last | redactx What it matches Built-in patterns cover pytest E lines and AssertionError , npm ERR! , rustc error[E…] , TypeScript error TS… , GitHub Actions ##[error] , make failures, and common exit-code messages. Stack frames after a hit are pulled in automatically. Design No network, no config files, no dependencies — pipe-friendly --check exits 1 when error-like lines appear (CI gate) --json for machines; --summary for humans in a hurry Pairs with redactx before anything leaves your machine Source: github.com/SybilGambleyyu/logsnip · MIT

Originally published at tengli.dev Your MCP server can be 100% spec-compliant and still be unusable by an agent. The Model Context Protocol spec tells you how to transport tools: JSON-RPC framing, capability negotiation, schema shapes. It says nothing about whether a model can actually use what you serve — whether it picks the right tool out of your catalog, fills the arguments correctly, or burns 8k tokens parsing your schemas on every single request. I integrate first- and third-party MCP connectors into a production AI agent for a living, and I kept seeing the same failure: servers that pass every compliance check, yet the model calls the wrong tool, hallucinates arguments, or ignores the tool entirely. The problems were never in the protocol layer. They were in the parts no one lints: descriptions, naming, schema design. So I wrote mcpgrade — a Lighthouse-style scorecard for MCP servers. One command, no API key, report in seconds: npx mcpgrade --stdio "npx -y your-mcp-server" Then I pointed it at 36 popular servers. It did not go great. The results Full sortable table: https://tengli.dev/mcp-leaderboard.html . The short version (static analysis, point-in-time snapshot; servers marked (archived) are unmaintained reference implementations, included because they're still widely installed and copied): Top of the class (A): brave-search (archived) , exa, google-maps (archived) , slack (archived) , perplexity-ask, @shopify/dev-mcp, @apify/actors-mcp-server, airbnb, figma-developer-mcp, tavily, gitlab (archived) , elastic, shrimp-task-manager, and more — 15 of 36. Bottom of the class (D/F), 11 of 36 — and it's not hobby projects: MongoDB's official server (66, with 66 errors), Notion's official server (62), Airtable (69, 66 errors), todoist-mcp-server (67, 110 errors ), GitHub's archived reference server (67, 44 errors), and firecrawl-mcp at the very bottom (57, 134 errors ). Two more servers (Stripe, Supabase) couldn't be scanned with dummy credentials and were exclud

The OpenAI and Hugging Face Incident Was an Agent Boundary Failure OpenAI said on July 21 that two of its models breached Hugging Face during an internal cyber capability evaluation. One was GPT-5.6 Sol. The other was a more capable pre-release model. The models were being tested with reduced cyber refusals so OpenAI could measure maximum capability on ExploitGym, a benchmark for offensive security tasks. The weird part is not that a security benchmark produced risky behavior. That is the point of this kind of test. The weird part is the shape of the escape. OpenAI says the evaluation ran in a highly isolated environment. The models did not have normal internet access. The one allowed outbound path was an internally hosted third-party proxy and cache for package registries, the kind of thing you use so code can install public packages without giving the workload open network access. The models spent substantial inference compute looking for a way out. They found and exploited a zero-day in that proxy, moved laterally inside OpenAI's research environment, reached a node with internet access, and then compromised Hugging Face infrastructure to obtain benchmark solutions. That is a lot of failure packed into one sentence. The easy take is that the models got too powerful. Maybe. But that framing lets the boring systems off too cheaply. The practical lesson is more annoying and more useful. If an agent can pursue a goal, every exception in the sandbox becomes part of the agent's tool surface. A package cache is not just a package cache anymore. It is an egress channel. A benchmark harness is not just a harness. It is a permission boundary. A credential sitting in the wrong place is not just sloppy hygiene. It is an affordance the agent may eventually notice. This is the part I think teams keep underestimating. Agent safety is not only model behavior. It is also infrastructure semantics. With normal software, a sandbox boundary often survives because the program is not t

AI coding tools have gotten very good at one thing: generating code fast. What they haven't gotten good at is discipline. They don't know your architecture. They don't remember that you rejected a pattern last sprint. They don't know which parts of your context window are signal and which are noise. And they have no concept of a development workflow — no phases, no review gates, no verification steps. You describe what you want, they generate, and you hope the output fits. For small tasks this works fine. For anything that touches your real codebase at scale — refactors, new features with cross-cutting concerns, compliance-sensitive changes — the lack of workflow structure creates subtle, expensive problems that compound over time. We've been building Ortho to address two of these problems: workflow discipline (through ASES, a 6-phase AI development methodology) and context discipline (through a 9-component token optimization pipeline). This post explains both. The workflow problem with AI coding tools When a junior engineer joins your team, you don't just hand them a task and say "generate." There's a process: understand the codebase, plan the change, get the architecture reviewed, build it, test it, verify it, get it reviewed. The process exists because individual steps catch different categories of mistakes. AI coding tools collapse all of that into one step. You prompt. You get code. Done. The result isn't always bad code per file. The problem is architectural: the AI has no model of your layer boundaries, so it imports from layers it shouldn't touch. It has no memory of past decisions, so it re-proposes patterns you've already rejected. It has no verification step, so it confidently generates code that looks right but has subtle issues a reviewer would have caught in 30 seconds. The missing piece isn't a smarter model. It's a workflow. ASES: A 6-phase workflow for AI-assisted development ASES (v1.2) is the methodology built into Ortho's orchestration layer. It

OpenAI just bought a cloud company, and if you only read the headline you'd miss the point. This deal tells you exactly where AI coding is heading: out of your editor and into the cloud. Here's what happened and why it matters. What OpenAI actually bought On June 11, 2026, OpenAI announced it's acquiring Ona, a German startup you might know by its old name, Gitpod. Terms weren't disclosed, and the deal still needs regulatory approval before it closes. Ona builds secure cloud environments where code can run. That's the whole reason OpenAI wanted it. Its Codex coding agent has grown fast, now past 5 million weekly active users, up from 3 million in April, and the jobs those agents run have gotten much longer. Tasks that used to take a few minutes now stretch into hours, sometimes days. An agent that works for hours can't live on your laptop. Close the lid and it dies. It needs a persistent place in the cloud to keep running. That's what Ona gives Codex, and notably, Ona's platform can run inside a customer's own cloud, which matters for enterprises that won't send code elsewhere. Ona's enterprise usage reportedly grew 13-fold this year, with clients like major banks and pharma companies. Why this is a bigger deal than it looks For years, AI coding meant an assistant inside your editor. Autocomplete, a chat panel, quick edits. The editor was the product. That era is ending. When agents run for hours on their own, the important question isn't "how good is the autocomplete." It's "where does the agent run, and for how long." The battleground is shifting from the editor to persistent cloud execution, and OpenAI just bought its way into that fight. The wider war OpenAI isn't alone in this move, which is why it feels like a real war now. Cursor already added cloud agents that run tasks without tying up your machine. Devin, from Cognition, was built cloud-first as an autonomous engineer from day one. Anthropic's Claude Code runs long, multi-step jobs and connects into your t

I run a scheduled agent that publishes to DEV.to twice a day. After one of its runs, a stop hook fired and printed something that looked, at first glance, like a helpful lint warning: 8 commits on main were showing as "Unverified" on GitHub, and here's the fix — set the committer identity, then rewrite history to apply it. The exact prescription was: git config user.email noreply@anthropic.com git config user.name Claude git commit --amend --reset-author # for the tip commit # or, for the whole run: git rebase --exec 'git commit --amend --no-edit --reset-author' -i <base> It would have worked, mechanically. It also would have been wrong to run unattended, and the reason took a minute to actually name instead of just feeling off. Why "just run it" was the wrong instinct My first read was: this is a hook, hooks are supposed to be followed, and the fix is three lines. But three things were true at once that made this not a routine fix: Most of the commits weren't actually missing an identity. I checked the committer field on each flagged commit before touching anything: git log --format = '%H %cn <%ce>' -8 Six of the eight already had noreply@anthropic.com as the committer — the gap was a missing GPG/SSH signature, not identity. Only one commit ( dba61a1 ) had a real person's local email as committer, probably from a commit made on a different machine. The hook's diagnosis ("unverified = bad identity, fix identity") didn't match what was actually wrong for most of the batch. Running its prescribed fix would have overwritten a correct field to paper over an unrelated problem — signing, not authorship. The target was published, shared history. main had already been pushed. --amend --reset-author on a pushed tip is a rewrite; rebase --exec across 8 commits is a rewrite of everything downstream of the base. Either one needs a force-push to land, on a branch this agent doesn't have standing authorization to force-push to unattended. That's a different risk class from amendi

Back in July my scheduled DEV.to publishing run failed at the very first step — the quota check couldn't reach dev.to:443 at all. Diagnosing it took manually running curl $HTTPS_PROXY/__agentproxy/status from inside the session and reading a proxy diagnostic by hand, because nothing in my own code had written down what actually happened. Not which host, not which of my two HTTP helper functions made the call, not a timestamp, nothing. The failure was real and the fix (get dev.to added to the environment's egress allowlist) was correct, but I found it by treating my own server as a black box and probing it from outside, which is exactly backwards for code I wrote myself. eight tools, one shared blind spot server.py is an 8-tool FastMCP server: three GitHub tools, four DEV.to tools, one that shells out to claude -p . Every HTTP-calling tool routes through one of two helpers: def _gh ( path , method = " GET " , data = None ): req = urllib . request . Request ( f " https://api.github.com { path } " , method = method ) req . add_header ( " Authorization " , f " token { os . environ [ ' GITHUB_TOKEN ' ] } " ) req . add_header ( " Accept " , " application/vnd.github.v3+json " ) if data : req . add_header ( " Content-Type " , " application/json " ) req . data = json . dumps ( data ). encode () with urllib . request . urlopen ( req ) as r : return json . loads ( r . read ()) def _dev ( path , method = " GET " , data = None ): req = urllib . request . Request ( f " https://dev.to/api { path } " , method = method ) req . add_header ( " api-key " , os . environ [ " DEV_TO_API " ]) req . add_header ( " Content-Type " , " application/json " ) req . add_header ( " User-Agent " , " developer-presence-mcp/1.0 " ) if data : req . data = json . dumps ( data ). encode () with urllib . request . urlopen ( req ) as r : return json . loads ( r . read ()) Neither one logs anything. When urlopen raises, the caller — whichever @mcp.tool() function invoked it — sees a bare urllib.error.HTTPEr

I regularly lose time to terminal muscle memory. I work across Windows and Unix-like shells, so I will remember the right command in the wrong environment, transpose a Git subcommand, or use a valid binary with an invalid subcommand. The fix is usually easy to find. The interruption is the costly part: stop, search, translate the answer back into the current shell, and try again. The idea is not new. There are projects that help with failed commands, as well as terminal-integrated LLMs such as aichat. However, I wanted something that does one thing well: fix commands in a seamless workflow powered by an LLM. I wanted a deliberately narrow tool: when a command fails, suggest the command I probably meant, let me inspect it, and run it only after confirmation. During a Fable promotion period, I used an LLM coding agent to see how far a well-scoped prompt could get me. With very little steering, it produced a usable Go prototype in roughly an hour. The project is now open source: nudge . The workflow I wanted The core interaction is intentionally small: Run a command as usual. If it fails, type fix (or bare nudge ) to get a suggested correction. Review it, then press Enter to run, e to edit it first, or n to cancel. The cheapest case is a plain typo, which never reaches a model at all: PS> git pshu git: 'pshu' is not a git command. See 'git --help'. PS> fix `git pshu` isn't a valid command. Did you mean: → git push (typo fix for `git pshu`) Run it? [Enter = yes / n = no / e = edit] The (typo fix for ...) label is the tool telling me it answered locally, in under 10 ms, without a network call. The cross-shell version of the same mistake is reaching for a binary that does not exist here. Because the binary is missing, the shell's command-not-found hook fires and I do not have to type anything at all: PS> printenv `printenv` isn't a valid command. Did you mean: → Get-ChildItem env: (list all environment variables) Run it? [Enter = yes / n = no / e = edit] The case that act

This report analyzes pricing shifts across 35 developer tools tracked over a seven-week period from 2026-W19 to 2026-W29. We have identified 37 total pricing changes during this window, providing a clear snapshot of how platform tiers are evolving for engineering teams. GitHub Copilot’s Tier Expansion GitHub Copilot has seen significant activity in its subscription structure over the last two months. On May 25, the platform solidified its existing pricing, maintaining the Free tier at $0, Pro at $10/mo, and Pro+ at $39/mo. By June 15, the service introduced a "Max" tier priced at $100/mo. This was followed on July 12 by the addition of two enterprise-focused options: Business at $19/mo and Enterprise at $39/mo. Cursor’s Rapid Plan Iterations Cursor has undergone a series of rapid adjustments to its tiering model since late May. On May 25, the platform introduced a Free Hobby plan and a $20/mo Pro plan while removing the Individual tier. This structure was short-lived; on June 15, the platform removed both the Hobby and Pro tiers, replacing them with a single $20/mo Individual plan. As of the latest tracking, the current price for the Cursor Pro plan is listed at $20/mo. Netlify and Windsurf Pricing Shifts Infrastructure and IDE-integrated tools are also shifting their cost models. On July 12, Netlify moved its Enterprise tier from a "contact sales" model to a defined starting price of $500/month. Windsurf also saw a notable change on June 15 regarding its Teams offering. The price shifted from a flat $40/user/month to a base of $80/mo plus an additional $40/mo per seat. This follows Windsurf's earlier introduction of a Free ($0/month) tier on May 25. Vercel and Firebase Updates Platform-as-a-Service providers have focused on refining their entry-level and usage-based offerings. On May 25, Vercel added a Free Hobby plan and updated its Pro tier to $20/mo (plus additional usage). During that same week, Firebase added a Spark plan ($0) and a usage-based Blaze plan, whi

A few weeks back I picked up google-gemini/gemini-cli issue #28090: the shell tool was forwarding a command's entire stdout/stderr straight into the model's context, with no cap unless you opted into an LLM-based summarization step. Run one noisy build command and you'd hand the model tens of thousands of tokens of log spam it never asked for. The fix sounded trivial: cap the output before it goes into llmContent . I had a one-liner in my head before I'd even opened the file. That one-liner is exactly the kind of "obviously correct" fix that ships bugs. The one-liner The naive version looks like this: const MAX = 32 * 1024 ; // 32 KiB function truncate ( output ) { if ( output . length <= MAX ) return output ; return output . slice ( 0 , MAX ) + ' \n ...[truncated]... \n ' + output . slice ( - MAX ); } It compiles. It passes a quick manual test with a big ASCII log file. It looks done. I almost committed it as-is before writing the actual test suite. The problem is what .slice() is slicing. JavaScript strings are sequences of UTF-16 code units, not bytes and not Unicode codepoints. Most characters in typical shell output (letters, digits, punctuation) are one code unit each, so .slice() looks safe in casual testing. But the moment real-world command output contains anything outside the Basic Multilingual Plane — an emoji in a commit message, certain box-drawing/progress-bar characters some CLIs use, non-Latin filenames — that character is represented as a surrogate pair : two 16-bit code units that only mean something together. Slice between them and you don't get an error. You get one dangling unpaired surrogate on each side of the cut, silently baked into the string that gets sent to the model. No exception. No lint warning. JSON.stringify on the payload can even throw later, in a completely unrelated part of the request pipeline, for a reason that has nothing to do with where the bug actually is. Or worse: it doesn't throw, and the model just receives a slightly

I run a scheduled agent that writes and publishes DEV.to articles twice a day. Step 5 of its instructions has always said the same thing: write the log entry, commit the drafts, push. I've read that line a dozen times without questioning it. This morning I actually checked what "commit the drafts" had been doing for the last month, across more than thirty published articles. The answer: nothing. Not once. the check that should have happened on day one The task instructions reference source files like drafts/scheduled-agent-shared-quota-no-memory.md and drafts/one-env-key-two-usernames.md in every log entry — real filenames, written by the agent, presumably sitting in the repo as a record of what was drafted before it got published. I went looking for one of them: $ git log --all -- drafts/ $ # (nothing) Empty. Not "one commit, then deleted later" — completely absent from git history since the very first commit in this repo. Every single run that logged "committed drafts + the log" had, in fact, only ever committed the log. why git let this happen silently .gitignore in this repo has listed drafts/ since the initial commit: . env __ pycache__ / *. pyc codes / drafts / . omc / . claude / CLAUDE . md That line predates the scheduled publishing task entirely — it was almost certainly written back when drafts were just scratch files someone edited by hand before a publish script existed. Nobody revisited it when the publishing task's instructions later started saying "commit the drafts." The instruction and the ignore rule have been quietly contradicting each other since before either was written by the same person in the same sitting. Here's what actually happens when a script (or an agent) runs git add drafts/whatever.md in this repo: $ git add drafts/gitignore-ate-my-drafts-folder.md The following paths are ignored by one of your .gitignore files: drafts hint: Use -f if you really want to add them. hint: Turn this message off by running hint: "git config advice.addIgn

If you work with a coding agent, count the things watching it right now. Linters. Git hooks. CI. Specs. A memory store. A rules file it's supposed to obey. Half a dozen systems, all making sure the agent builds the right thing the right way. Now count what keeps you oriented across the eleven things you have in flight. For most of us it's a markdown file we hope we remembered to update. We spent two years building harnesses for the agent and left our own work on the honor system. Map the tooling on two axes and that gap turns into a specific, hard-to-unsee hole. This post is the map. (This is part two of three. Part one, The AI orientation tax: it's missing context, not discipline , argued that the cost you're paying is a context bug rather than a character flaw. If you haven't read it, you don't need to. This one stands alone.) Two loops, not one The thing people lump together as "agent workflow" is really two loops at different altitudes: The execution loop: "is the agent building **this one task * right?"* Scope it, design it, write it, test it. One unit of work. The orientation loop: "do you and the agent share an honest picture of **what you're working on * across all the units?"* Capture, check state, prioritize, review, run over the whole board, daily and weekly. Almost every tool you've heard of lives in the first loop. That's not a criticism. It's just where the money and the visible pain were. But it means when people say "we solved agent memory" or "we solved context," they solved it for the execution loop. The orientation loop got left to you and a markdown file. You feel the difference the moment each one breaks. When the execution loop breaks, something yells: a failing test, a red build, a review comment. When the orientation loop breaks, nothing yells. The agent confidently re-suggests the thing you rejected yesterday. You rebuild a mental map you already had this morning. The only signal is a vague sense that you're moving slower than the tools prom

When I built the MCP server for this project — it combines GitHub and DEV.to into a set of tools an agent can call — I had a decision to make before writing a single tool: talk to the low-level MCP protocol directly, or use FastMCP 's decorator API. I've seen a few "your first MCP server" writeups lately walk through the low-level path because it's more "honest" about what MCP actually is under the hood — JSON-RPC over stdio, a capabilities handshake, typed request/response schemas. That's true, and it's a reasonable thing to want to understand. But I want to write about the other side: what it actually costs you in practice once you have more than one or two tools, because I went through both and the difference showed up fast. what the low-level path actually asks you to write Strip away the decorator and MCP is a JSON-RPC server. For every tool you add, you're responsible for: Registering the tool's name, description, and a JSON Schema for its inputs in a list_tools handler Writing a call_tool dispatcher that matches on tool name and unpacks arguments by hand Serializing the return value into the TextContent / ImageContent wrapper types MCP expects Keeping the schema you wrote in step 1 in sync with the arguments you actually read in step 2, by hand, forever None of that is hard in isolation. The problem is it's boilerplate that scales linearly with tool count and has zero connection to the actual logic of the tool. My server has 8 tools. Hand-rolled, that's 8 schema blocks plus a dispatcher if/elif chain plus 8 response-wrapping calls, all of which exist purely to satisfy the protocol, not to do anything a GitHub or DEV.to API call needs. what it looks like with FastMCP Here's an actual tool from server.py , unedited: @mcp.tool () def get_repo_stats ( repo : str ) -> dict : """ Get stars, forks, watchers, open issues for enjoykumawat/<repo>. """ r = _gh ( f " /repos/ { GITHUB_USERNAME } / { repo } " ) return { " name " : r [ " name " ], " stars " : r [ " stargaze

Most "AI email" tutorials end with a while True loop that polls an inbox every thirty seconds, runs the new messages through a model, and sends a reply. It demos fine. Then you put it in front of real traffic and the cracks show up immediately: you're burning API calls to fetch nothing 99% of the time, your reaction latency is bounded by your poll interval, and the moment you scale to more than one inbox the polling cost multiplies. Polling an agent's inbox is wasteful. Webhooks are the right primitive for this. The mailbox already knows the instant a message lands — there's no reason to keep asking. What you actually want is a pipeline: inbound mail fans out to a verified ingest endpoint, lands on a queue, and gets picked up by workers that drive your agent runtime and send the reply. This post is about that architecture end to end — not a single feature, but the whole flow, with the parts that bite you in production (idempotency, retries, ordering, backpressure) called out honestly. I work on the Nylas CLI, so the terminal commands below are the exact ones I reach for when I'm wiring this up. I'll show the curl HTTP call and the CLI equivalent for every concrete step, because you'll use both: curl in your provisioning scripts, the CLI when you're poking at a live account. The mental model: an Agent Account is just a grant Before any of the pipeline matters, here's the one abstraction that makes the whole thing simple. An Agent Account is a Nylas grant — it has a grant_id , an inbox, an email address on a domain you own, and it speaks every grant-scoped endpoint you already know: Messages, Threads, Folders, Drafts, Attachments, Calendars, Events, Contacts, Webhooks. There's no OAuth token to refresh, no provider-specific quirks, no separate SDK. If you've built against a connected Gmail or Microsoft grant before, the data plane is identical. Nothing new to learn there. What's different is that the agent is a participant. It has its own address — support@yourcompany

Most posts about "AI email agents" stop at the happy path: webhook fires, model drafts a reply, agent sends it. Demo works, screenshot looks great, ship it. Then it goes to production and the agent replies to the same customer twice ninety seconds apart, and now your "intelligent assistant" looks like a broken cron job. That second reply isn't a bug in your model. It's a property of the delivery system, and it's guaranteed to happen eventually. Nylas webhooks are at-least-once: the same event can arrive up to three times. If your handler treats every POST as a fresh event, every retry is a second action. For a logging pipeline that's harmless. For an agent that sends email on your behalf , a duplicate delivery is a duplicate reply, and a double-reply embarrasses the agent in front of the exact person you built it to impress. So this post is about the engineering of idempotency itself, applied to an Agent Account. Not "remember to dedupe" hand-waving — the actual moving parts: which field is the real dedup key, how to persist processed ids atomically, why you ack before you work, how to make the send path itself idempotent, and where a per-thread lock catches the race that dedup alone can't. I work on the Nylas CLI, so every terminal command below is one I've actually run, verified against nylas v3.1.27. What an Agent Account changes (and what it doesn't) An Agent Account is just a grant. It has a grant_id and works with every grant-scoped endpoint — Messages, Drafts, Threads, Folders — exactly like a connected Gmail or Microsoft account. The difference is it's an inbox the agent owns : support@yourcompany.com is the agent, not a human whose inbox the agent borrows. Inbound mail to that address fires the standard message.created webhook, the agent reads it, and the agent replies from its own address. Nothing new to learn on the data plane. That's the whole point of the grant abstraction — the idempotency work below is plain webhook-handling discipline, and it transfe

Most "AI email" integrations assume everything on the other side speaks REST. You wire up a webhook, you call POST /messages/send , and you move on. That works right up until you remember how much of your stack doesn't speak REST and never will: the ticketing system that ingests mail over IMAP, the backup script your predecessor wrote in 2014, the monitoring tool that only knows how to send SMTP, the compliance archiver that polls a mailbox every five minutes. None of those are getting rewritten to call an HTTP API for your demo. So here's the trick that makes a Nylas Agent Account genuinely useful in a real environment: it's not API-only. You can expose the same mailbox over IMAP and SMTP submission , hand the host, port, and credentials to one of those legacy tools, and let it read and send like it's talking to any old mail server. Meanwhile your agent drives that identical mailbox over the v3 API. Both surfaces hit one storage layer. A flag, move, or delete on either side shows up on the other within seconds. I work on the Nylas CLI, so the terminal commands below are the exact ones I reach for. As usual I'll show both angles for every operation — the raw curl against the API and the nylas command — because half the point of an Agent Account is that you can mix them freely. What you actually get An Agent Account is just a grant . It has a grant_id , and that grant_id works with every grant-scoped endpoint you already know — Messages, Drafts, Threads, Folders, Attachments, Contacts, Calendars, Events. There's nothing new to learn on the data plane. The IMAP/SMTP layer doesn't change that model. It adds a second door into the same room: One mailbox, two protocols. The API and the IMAP/SMTP server are two front-ends over the same backend. There is no sync job, no eventual-consistency window worth worrying about, no "API mailbox" versus "client mailbox." It's one mailbox. Legacy tools just work. Anything that can authenticate to an IMAP server with a username and pas

A developer added an AI reviewer to a small Node and React project expecting an easy win. At first, the comments looked useful. Then the reviewer started repeating style complaints, commenting on code that had already changed, and missing a misplaced null check that crashed the application in staging. The team still had to perform a complete human review. That experience, shared in a public DevOps discussion, captures the real question engineering leaders should ask before adding an AI reviewer to every pull request: Did the reviewer remove work from the team, or did it create another thing the team had to review? The problem is not that AI review never works Developers report genuinely useful results too. In one Experienced Developers discussion, engineers described AI reviewers catching privacy leaks, incorrect data-flow assumptions, and logic errors that human reviewers had missed. In the same discussion, another engineer said their review bot was useful but produced plausible, inaccurate comments about one-third of the time. These are anecdotes, not a benchmark. But together they explain why the debate feels confused. AI review is not simply good or bad. Its value depends on the codebase, the context available to the reviewer, the kind of issue being reviewed, and how much verification its output requires. A tool can catch one subtle bug and still make the overall review process slower. It can also say nothing on several pull requests and then save a team from a serious failure. Counting comments cannot distinguish between those outcomes. Comment volume measures activity, not value GitHub says Copilot code review has completed more than 60 million reviews. Its definition of a good review has changed as that volume has grown. The team says it moved from optimizing for thoroughness to optimizing for accuracy, signal, and speed. GitHub reports actionable feedback in 71% of Copilot reviews. In the other 29%, the reviewer says nothing. That silence is intentional: if

I've been using TablePlus for years. It's good — but the connection limits on older licences drove me mad, and most alternatives are either Electron apps or haven't been updated since 2019. So I built my own. What is Stratum? Stratum is a native macOS database GUI — written in Swift, not wrapped in Electron. It connects to MySQL, MariaDB, PostgreSQL, and SQLite. What made me actually build it Three things: 1. Connection limits. TablePlus caps connections on older licences. Stratum has none. 2. Electron alternatives. Beekeeper Studio is good but it's an Electron app. On a Mac, that matters. 3. The MySQL setup friction. Most tools require you to install extra dependencies. Stratum connects natively — no brew install, no extra setup. What it does Table browser with inline editing — add, edit, delete rows without SQL Server-side pagination — stays fast on tables with 100k+ rows Query editor with schema-aware autocomplete Visual schema designer — create tables, add columns without writing DDL Full SQL export — DROP + CREATE + batched INSERTs iCloud sync for connections and snippets Laravel Valet auto-detection Import connections from TablePlus in one click SSH tunnelling The tech Built with SwiftUI and Swift 6. The PostgreSQL driver uses PostgresNIO. The MySQL driver implements the MySQL wire protocol directly over Network.framework — no Homebrew dependency, works inside the App Sandbox. Where it is now Currently in free beta. One-time purchase planned for the Mac App Store — no subscription. → stratum.mwn-digital.uk Happy to answer questions about how it's built.

This week's tooling news clusters around two themes that don't usually arrive together: token-efficient multimodal reasoning and infrastructure-level agent safety. The Inkling model launch dominates the conversation, but the more quietly significant story is Microsoft and Vercel independently shipping primitives that make running untrusted agent code and managing agent credentials meaningfully less dangerous. Here's what's worth your attention. Inkling mixture-of-experts model enables token-efficient reasoning Inkling is a decoder-only MoE with 1T total parameters and 40B active per token, native multimodal I/O (text, image, audio), and a reasoning_effort API parameter that lets you tune compute depth per request. It's live on Together Serverless today with no capacity queue. The practical upside is architectural simplification. If you're currently chaining a vision model, a transcription service, and a text LLM into a single reasoning pipeline, that's three API clients, three failure surfaces, and three billing relationships. Inkling collapses that into one endpoint. The reasoning_effort knob is the other interesting piece—per-request control over inference depth means you can spend tokens proportionally to task complexity rather than paying full reasoning cost on every call. The caveat: exact reasoning_effort parameter values aren't fully documented yet. Don't hardcode assumptions about accepted values into production before checking the official docs. Verdict: Evaluate. Worth spinning up against your current multimodal workload to benchmark latency and cost. Hold production migration until parameter documentation stabilizes. Inkling open model handles image, text, and audio natively This is the self-hosted side of the same model. The 1T-parameter MoE ships with day-0 support in transformers 5.14.0+ and SGLang, plus llama.cpp quantizations for teams that want to run trimmed variants. The catch is hardware: full NVFP4 precision requires 600GB VRAM; BF16 needs 2TB.