正在加载视频...

视频加载失败

Introducing InsForge Backend Branching. We made agentic coding production-safe. Your agent creates isolated backend branches when working. Every backend service, policy, and config is copied into a secure, isolated environment. Review PR-style diffs. Merge only when ready.

62,391 次观看 • 4 个月前 •via X (Twitter)

31 条评论

Hitesh Choudhary 的头像
Hitesh Choudhary4 个月前

Do you guys even sleep or just keep pushing new features? 😂

InsForge 的头像
InsForge4 个月前

we'll catch up after launch week is done!

InsForge 的头像
InsForge4 个月前

Try Branching: Read more:

Hang Huang 的头像
Hang Huang4 个月前

We’ve been working on this for a long time This has meaningfully improved our own developer experience building with coding agents among our internal team, excited to see what you guys think!

InsForge 的头像
InsForge4 个月前

can't imagine building without it now!

Henry 的头像
Henry4 个月前

Amazing!

ahmed abid 的头像
ahmed abid4 个月前

gimme a break , i can't keep up T_T too much updates xd

InsForge 的头像
InsForge4 个月前

hahaha keep up or get left behind!

crypticsaiyan 的头像
crypticsaiyan4 个月前

Agentic coding we can actually trust. Huge! 🔥

Tony Chang 的头像
Tony Chang4 个月前

safely allow agents operate!

InsForge 的头像
InsForge4 个月前

yes sir!

dale 的头像
dale4 个月前

Lfg!!! How much sleep did yall miss to ship this many stuff

InsForge 的头像
InsForge4 个月前

not too too much...

Artists Voyage 🔶 的头像
Artists Voyage 🔶4 个月前

This is a smart way to remove the fear from agent driven changes.

InsForge 的头像
InsForge4 个月前

try it and let us know what you think!

Matt 的头像
Matt4 个月前

isolating the backend per agent run is the right instinct. the thing that still bites is the agent's own context surviving across those branches, the work stays safe but the session state usually doesn't.

InsForge 的头像
InsForge4 个月前

we copy everything

Matt 的头像
Matt4 个月前

copying everything also copies the stale state, that's the trap written with ai

InsForge 的头像
InsForge4 个月前

we use 3 way state diff to manage read our blog! we're pretty open about everything

Matt 的头像
Matt4 个月前

3-way diff handles the data side cleanly. the part that slips is the agent's working memory: it merges the backend fine but keeps planning against the branch it remembers, not the merged result. written with ai

Gregor 的头像
Gregor4 个月前

curious what 'copied' means for stateful services. does the DB snapshot at branch time, or does the agent still touch live data?

Tornike Sirbiladze 的头像
Tornike Sirbiladze4 个月前

branching for backend state is exactly the kind of boring infra agents need otherwise “agent changed config” becomes terrifying very fast

InsForge 的头像
InsForge4 个月前

we are on our safety and reliability arc right now 😎

Taro Fukuyama 的头像
Taro Fukuyama4 个月前

Let's gooo!

Sridhar A 的头像
Sridhar A4 个月前

isolated backend environments are an excellent way to make agentic coding safe.

InsForge 的头像
InsForge4 个月前

ship 100x faster and safer

Alice The Ai Expert 的头像
Alice The Ai Expert4 个月前

InsForge makes agentic coding safe with isolated backend branches.

Kyle 的头像
Kyle4 个月前

Replace supabase?

InsForge 的头像
InsForge4 个月前

think more like replacing AWS 👀 we have all the primitives like db, auth, storage, and so much more we handle your frontend deployments, provision any compute you need, LLM model gateway, stripe integration for payments, posthog integration for analytics, all native for agents

SuperPublic 的头像
SuperPublic4 个月前

Backend Branching is such a useful unlock for agentic coding — congrats on shipping it!

InsForge 的头像
InsForge4 个月前

thank you! it's been a game changer for us internally as well

相关视频

i just built a 4-agent software team. everything runs from Telegram and gets managed on a kanban board. a project manager who plans the work, a backend developer, a frontend developer, and a tester. the PM reads a goal, breaks it into linked tasks, and assigns each to the right agent. the thing that makes them a team instead of four strangers is a shared kanban board. every task is a row that survives crashes, and when an agent finishes, it writes a summary of what it built and what the next agent needs to know. the next agent reads that summary before it starts. so the frontend developer never has to guess the API shape, and the tester knows exactly what to verify. the hardest part was not the coordination. it was building an agent that could actually act like a backend engineer. a backend engineer stands up a database, wires auth, manages storage, deploys functions, and keeps all of it consistent while the rest of the team builds on top. an agent doing this from scratch drowns. it burns its context window remembering which tables exist and which endpoint it created three steps ago, and the work degrades fast. so the backend agent needs a backend built for agents, not for humans clicking through a dashboard. that is where InsForge came in. it is an open-source, agent-native backend, and i added it to my backend developer agent as a skill. a skill is a step-by-step guide that teaches the agent how to do a specific kind of work. with InsForge installed, the agent stopped improvising infrastructure and followed a reliable path: create the project, define the database, set up auth, deploy functions. to test the whole team, i had them build a working Google Docs clone, AI features included. the backend agent spun up the full service on its own. database tables, user auth, document handling, and edge functions running real TypeScript, all in one dashboard. the frontend agent read that summary and built the UI on top of it, and the tester closed the loop. the result was a backend an agent could reason about end to end, instead of one it kept getting lost inside. if you are building an AI backend engineer, InsForge is worth a look, it's 100% open-source. InsForge GitHub: (don't forget to star 🌟) the full article on Hermes Kanban: Mission Control for your Agents is quoted below.

Akshay 🚀

123,101 次观看 • 4 个月前

Claude Code tip: stop burning Opus 5.5 context on tasks Sonnet 5.5 can swarm, while Fable 5.1 sits idle spin up an autonomous team with --agent claude --agent architect Opus 5.5 acts as the lead architect, scoping the work and validating every worktree before it merges Sonnet 5.5 teammates take isolated git worktrees and hammer out implementations at medium effort Fable 5.1 sits on the team as a dedicated adversary, only stepping in at three critical moments: → before a contract locks: does the frontend payload match the backend schema? → when a test breaks twice: are we patching the bug or just hiding the symptom? → before the merge: what attack surface or edge case did everyone overlook? Sonnet 5.5 builds. Fable 5.1 challenges. Opus 5.5 merges and ships Jev engineering runs the identical pattern one layer down: mechanical decisions that need no reasoning (which file to open, which tool to invoke, retry or abort) execute in 16ms, so the frontier models only wake up when execution paths actually diverge Plan on high. Delegate on medium. Keep the adversary on peer-to-peer call. - the full team setup > architect runs the main session on Opus 5.5 at high effort > teammate-ux builds client state inside its own git worktree > teammate-back writes endpoints and migrations inside a separate worktree > teammate-adv runs on Fable 5.1, read-only, and attacks every diff > teammates message each other by name without routing through the lead > tools: Agent(ux, backend, adversary) locks the architect to spawning only its own team paste the setup and this prompt into Claude Code below: "Configure my Claude Code workspace for an autonomous agent team: 1. Audit ~/.claude/agents and .claude/agents for definitions fitting architect, ux, backend and adversary > Generate definitions only for missing roles > Pin model: sonnet, effort: medium, isolation: worktree for ux and backend, and model: fable with read-only tools for adversary > Give architect model: opus, effort: high and tools: Agent(ux, backend, adversary) 2. Check ~/.claude/settings.json and my env: > Report CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS if it's set, since it turns named subagents into teammates without worktrees > Report CLAUDE_CODE_SUBAGENT_MODEL_FORCE and CLAUDE_CODE_EFFORT_LEVEL, which can override the pinned models and effort 3. Write each role's prompt so ux and backend own separate folders, message each other by name when a contract changes, and hand every diff to adversary before reporting back 4. Add a team rule to ~/.claude/CLAUDE.md: no worktree merges until adversary has reviewed it Show every configuration diff first. Do not apply edits until confirmed" save it

Khairallah AL-Awady

36,814 次观看 • 16 天前

QVAC SDK 0.15.0 is live. This release adds multiple prompts batching, brings a native AMD GPU backend to the stack, moves more vision encoders onto mobile GPUs, and adds a second local coding-agent integration. Main highlights: - Prompt batching for the LLM addon. Batch multiple prompts into one job and process them concurrently, with each answer returned the moment its generation finishes. - Native AMD GPU backend. A first-class HIP/ROCm backend in @qvac/vla-ggml, auto-selected over Vulkan with clean fallback when ROCm is absent. - A second local coding agent. OpenClaw joins OpenCode for local, cloud-free agent workflows. AGENTS - OpenCode plugin update (@qvac/opencode-plugin). Aligned with the current SDK, CLI, and AI SDK provider packages. A fresh install runs OpenCode against managed local QVAC models out of the box, from the default qvac/qwen3.5-9b, with no manual qvac serve setup. - OpenClaw plugin (@qvac/openclaw-plugin). A second coding-agent integration alongside OpenCode. A fresh setup installs the plugin, creates a local qvac provider through onboarding, and runs a QVAC model through OpenClaw🦞's local service path. LANGUAGE MODELS - Prompt batching (LLM addon). Batch multiple prompts in one job and run them concurrently, each answer returns the moment its generation finishes, no waiting on the others. - Reasoning-context trimming on hybrid + recurrent models (@qvac/llm-llamacpp). remove_thinking_from_context now works beyond pure-attention models. Same JS API, no throw. VOICE AND SPEECH - Transcription (transcription-parakeet 0.9.0). More robust CPU fallback on GPU failure and a faster Vulkan backend on Pixel 9. - Text-to-speech features (tts-ggml 0.4.0). Adds LavaSR for noise removal and adjustable output frequency up to 48 kHz, plus Japanese via Chatterbox. - Text-to-speech fixes (tts-ggml 0.4.1). CPU fallback on GPU failure, a q8_0 KV crash fix on Metal with Chatterbox. VISION - Qwen3.5 vision encoder on GPU (Android). Image encoder moves onto the phone GPU, with a smarter tile-grid preprocessor and default image-token caps, for flagship Android: Vulkan on Mali (Pixel 9 Pro) and OpenCL on Adreno 830 (Galaxy S25). - Gemma-4 vision encoder on GPU (Android). Vision encoder runs on the phone GPU instead of CPU, same flagship Android targets. PLATFORM AND PERFORMANCE - AMD GPU backend (@qvac/vla-ggml). Native HIP/ROCm backend, auto-selected over Vulkan with clean fallback when ROCm is absent (Linux x64 only). Comes with ~23% faster than Vulkan, ~14% faster than PyTorch-ROCm, parity preserved. Unified code style. A cleaner, more consistent, easier-to-contribute codebase. Let's build. npm install @qvac/sdk

QVAC

29,260,217 次观看 • 3 个月前