今日已更新 35 条资讯 | 累计 23992 条内容
关于我们

标签:#tools

找到 811 篇相关文章

AI 资讯

The New Code: Why Specifications Will Replace Programming

The agents were doing exactly what I told them to. That was the problem. I'd built a pipeline where AI agents could take a spec file, implement a feature, run the tests, review the result, and commit — without me writing a line of code. It mostly worked. Dozens of features shipped. But I kept reviewing the output and feeling like something was off. Not broken. Just subtly wrong in a way that was hard to name. I spent a while blaming the models. Then the prompts. Then the validation steps. Eventually I had to sit with the obvious: the agents were implementing exactly what I'd written. My specs were underspecified. The bottleneck was always me, at the planning stage. The thing most people throw away There's something that feels right about vibe coding. You're operating at the level of intent — describing what you want and letting the model handle the mechanics. That part is genuinely useful. But watch what most people do with the output: Traditional development: Source code → Compiler → Binary (keep the source; regenerate binary anytime) Vibe coding done wrong: Prompt → LLM → Generated code (delete the prompt; commit the code) You've shredded the source and carefully version-controlled the binary. The prompt — your structured description of what you wanted, why, and what "correct" meant — is the valuable artifact. The generated code is what compiles from it. When you discard the prompt and commit only the output, you've lost the thing that actually mattered. The practical consequence shows up six months later: you're staring at code you wrote and spending twenty minutes reverse-engineering your own intent. The spec would have been a thirty-second read. What a spec-driven pipeline is I built what I call an SDLC (Software Development Lifecycle) harness — a system where instead of writing code directly, you write a spec describing what needs to be built, and AI agents handle the implementation, testing, review, and documentation. The spec is the source. The code is what

2026-06-25 原文 →
AI 资讯

Add email signatures with the Nylas Signatures API

Here's a thing that surprises people the first time: an email sent through the API does not carry the signature the user set up in Gmail or Outlook. Provider signatures live in the provider's compose UI, and a programmatic send bypasses that entirely, so a message your app sends goes out with no signature at all unless you add one. The Nylas Signatures API is how you add it: store an HTML signature once, then attach it to a send by ID, and the signature gets appended to the message for you. This post covers signatures from two angles: the HTTP API your backend calls, and the nylas CLI for creating and testing one from the terminal. I work on the CLI, so the terminal commands below are the ones I reach for when I'm setting a signature up. Nylas signatures are separate from provider signatures The first thing to get straight is that these are not the user's existing signature. Nylas doesn't sync the signature configured in Gmail, Outlook, or any other provider, and that provider signature is never applied to mail sent through the API. If a message your app sends needs a sign-off, you create that signature with this API and attach it explicitly; there's no inheriting it from the connected account. That separation is deliberate, because a programmatic send is a different context from a person typing in their webmail. It does mean the responsibility is yours: a user who connects their mailbox expecting their familiar signature to appear on app-sent mail won't get it automatically. Stored signatures are grant-scoped, living at /v3/grants/{grant_id}/signatures , so each connected account has its own set, and they're HTML, so a branded sign-off with a logo and links works the same as a plain one. Create a signature Creating a signature is a POST /v3/grants/{grant_id}/signatures with a name and an HTML body . The name is for you, a label to find it by later; the body is the markup that gets appended to outbound mail. The response returns the signature with its ID, which is w

2026-06-25 原文 →
AI 资讯

Top Open Source Coding Agents to Replace Claude Code in 2026

Claude Code is a genuinely powerful CLI coding agent. Its context window handling and multi-file reasoning set a high bar in 2026. But it comes with real constraints - it requires an Anthropic API key, charges per token, locks you into Claude models only, and its source code is closed. For developers running local-first workflows, working in air-gapped environments, or simply preferring auditable tooling, those limitations are dealbreakers. The good news: the open-source ecosystem has matured significantly. Nine production-ready alternatives now cover every major workflow pattern - from terminal-first pair programming to fully autonomous task execution. Why Open Source Matters for AI Coding Agents AI coding agents operate at a high level of system trust. They write files, run commands, and modify your repository. That makes transparency genuinely important - not just philosophically. Open-source licensing lets you read the code, audit its behavior, self-host without sending data to a third party, and customize it for your team's needs. Beyond trust, the practical advantages are real. Open-source agents are model-agnostic by design. They connect to whichever LLM you prefer - Claude, GPT, Gemini, DeepSeek, or a local model via Ollama - letting you optimize for cost and capability on a per-task basis rather than being locked to one pricing tier. OpenCode - The Closest Open-Source Drop-In for Claude Code OpenCode has emerged as the de facto open-source answer to Claude Code in 2026, crossing 161,000 GitHub stars under an MIT license. It connects to over 75 LLM providers via Models.dev - including local Ollama models - and lets you switch providers mid-session. Internally it uses a dual-agent architecture: a Plan agent handles task decomposition while a Build agent executes changes. LSP integration brings symbol resolution into the terminal. Multi-session support lets you run parallel agents on the same project simultaneously. OpenAI Codex CLI - Auditable and Sandbox-Fir

2026-06-25 原文 →
AI 资讯

CDK Update - April/May 2026

devtools #infrastructureascode #cdk #aws Index TL;DR Major Features Bedrock AgentCore — From Alpha to Stable Fn::GetStackOutput & Weak Cross-Stack References Validations Framework Performance Improvements CloudWatch PromQL Alarms CLI Improvements New L2 Constructs Service Enhancements Community Highlights Community Content & Resources How Can You Be Involved Hey CDK community! Here's an update covering everything that shipped in April and May 2026. TL;DR Bedrock AgentCore graduated to stable — production-ready AI agent infrastructure with semver guarantees. Cross-region references got a major upgrade with native Fn::GetStackOutput support and weak cross-stack references. The new Validations framework replaces policyValidationBeta1 with a richer plugin system. And file fingerprinting is ~33% faster with persistent asset caching. These features are available in aws-cdk-lib v2.247.0 through v2.257.0 and aws-cdk CLI v2.1116.0 through v2.1125.0. Full changelogs on GitHub Releases ( Library | CLI ). Major Features Bedrock AgentCore — From Alpha to Stable The @aws-cdk/aws-bedrock-agentcore-alpha module has graduated to aws-cdk-lib/aws-bedrockagentcore — stable APIs, semver guarantees, production-ready. If you've been building AI agents with Bedrock but held off on CDK because of the alpha label, it's time to upgrade. ( #37876 ) AgentCore provides the core infrastructure for building AI agents: runtimes, gateways, identity management, observability, and online evaluation. The Policy submodule remains in alpha as it continues to evolve rapidly. ┌─────────────────────────────────────────────────────┐ │ Bedrock AgentCore (Stable) │ ├─────────────────────────────────────────────────────┤ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │ │ Runtime │ │ Gateway │ │ Identity │ │ │ │ (L2) │ │ (L2) │ │ (L2) │ │ │ └────┬─────┘ └────┬─────┘ └────────┬─────────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │ │Observa- │ │Online │ │ Policy Engine │ │ │

2026-06-25 原文 →