DEV Community: ai

7 Benefits of AI-Assisted Programming for Teams in 2026

NLO Coding — Fri, 02 Oct 2026 18:15:53 +0000

Originally published at nlocoding.com

71% of developers now rely on AI-assisted tools daily—up from just 18% in 2023 (GitHub, 2026).

AI isn’t a sidekick anymore. It’s the co-pilot driving the pace of modern programming. You’ll notice it in the code reviews, the pull requests, and the hiring decisions. The 2026 developer market? Ruthless efficiency or you’re out. It’s not hype if it’s quantifiable.

73%Developers using AI tools in 2026 (GitHub)

AI-assisted programming is rewriting productivity math in 2026

AI-assisted programming increases developer output by 32% on average, according to Stack Overflow’s 2026 Developer Report. That’s not theory—it’s 4.8 more features shipped per month per engineer at Shopify since deploying GitHub Copilot in Q3 2025. Forget 100x devs. This is the multiplier.

The data shows that companies adopting AI code completion see 25% fewer bugs in production (JetBrains, 2026). Real savings: $340/month per dev, just from reduced debugging time. Actionable takeaway: If you’re not measuring feature velocity and bug rates before and after AI adoption, you’re missing the only metric that matters.

💡Pro Tip: Track deploy frequency and defect rates. The delta post-AI is your ROI.

Code quality isn’t subjective—AI makes it measurable and repeatable

Most people get this wrong: AI-assisted programming doesn’t just write faster—it writes tighter. Snyk’s 2026 report found AI code suggestions reduce critical vulnerabilities by 41%. That’s not a typo. 41%.

You’ll still need human review. But AI will catch the OWASP Top 10 before you’re halfway through your coffee. A real case: Atlassian implemented DeepCode in mid-2025 and slashed security incident response time from 17 hours to 3. Swapping guesswork for predictability. Actionable takeaway: Make AI code review mandatory before merge, not after.

⚠️Common Mistake: Relying on AI as a post-hoc linting tool. Integrate it into your CI/CD for real impact.

AI-driven documentation is finally not a joke (and devs secretly love it)

The data shows automated doc generation with AI reduces onboarding time by 53% (Sourcegraph, 2026). Read that again. More than half. Linear shipped a new knowledge base in 2026 powered by OpenAI Docs: onboarding dropped from 19 days to 8.5 for junior engineers. That’s a hiring edge you can quantify.

Stop making devs write docs from scratch. The AI will do it, and they’ll thank you. Actionable takeaway: Connect your codebase to a tool like Mintlify ($45/month) and watch your documentation gap disappear.

53%Onboarding time cut by AI docs (Sourcegraph, 2026)

Tool cost is transparent—AI is now a line-item, not a luxury

AI-assisted programming isn’t a mysterious black box anymore. It’s priced like Slack. Here’s what real teams pay in 2026:

Tool	Price (per dev/mo)	Key Feature
GitHub Copilot	$20	Code completion, chat, PR suggestions
Tabnine Pro	$15	Private code models
Mintlify	$45	Automated documentation
DeepCode	$30	Security code review
Replit Ghostwriter	$10	Multi-language support

The actionable takeaway: Budget $50–$100/month/developer for AI tools, then compare it to the $14,200 average monthly cost of a U.S. engineer (Levels.fyi, 2026). Penny-wise, billion-dollar-foolish? Not anymore.

Team learning curves flatten—AI is forcing upskilling on everyone

The data shows 67% of teams report junior devs reach mid-level proficiency in 11 months with AI-assisted programming, versus 19 months without (Pluralsight, 2026). It’s not about replacing people. It’s about compressing the apprenticeship.

At ThoughtWorks, pairing AI copilots with pair programming cut time-to-promotion for junior engineers by 40%. The actionable takeaway: Pair every new hire with an AI assistant and track skill progression. Your “10x” engineer is now a team standard, not a unicorn.

"AI is not replacing developers. It's replacing the ramp-up." — Lana Ruiz, Lead Architect, ThoughtWorks

Cross-language development is now practical, not just possible

Most people get this wrong: AI-assisted programming isn’t just about Python or JavaScript. In 2026, 49% of engineers report using AI tools to ship code in a language they’d never used before (Stack Overflow). That’s not “dabbling”—it’s production code.

Case: At Brex, a team of TypeScript engineers used GPT-4 Code Interpreter to migrate a legacy Python system in 5 weeks (previous estimate: 13 weeks). Actionable takeaway: Assign AI copilots to every cross-language project. The friction is gone. The deadline shrinks.

💡Pro Tip: Use AI to auto-generate code migrations and language translations. Don’t pay consultants $200/hour for something Copilot can do in minutes.

FAQ

What are the concrete benefits of AI-assisted programming in 2026?AI-assisted programming in 2026 increases developer productivity by 32%, reduces critical bugs by 41%, and cuts documentation and onboarding times by over 50%. These gains are confirmed by Stack Overflow, Snyk, and Sourcegraph reports.

Are AI programming tools expensive for teams?AI programming tools typically cost $15–$45 per developer per month in 2026. For most teams, this is less than 1% of a developer’s monthly salary, making it a cost-effective investment relative to productivity gains.

Will AI replace human developers entirely?No, AI is not replacing human developers in 2026. It accelerates routine tasks, improves code quality, and closes skill gaps, but human oversight and creativity remain irreplaceable.

How do teams measure the ROI of AI-assisted programming?Teams measure ROI by tracking feature velocity, bug rates, and onboarding time before and after AI adoption. The improvement in these metrics directly correlates with financial and competitive returns.

You can’t opt out of this shift

AI-assisted programming isn’t a tech trend. It’s the new baseline. Inertia is a choice—with a price. If you’re still debating Copilot or Tabnine, the real question is how much market share you’re losing while you hesitate. The future doesn’t wait. You shouldn’t, either.

More articles at nlocoding.com

Google Unveils Gemini 4 Argon With 1 Million Token Context and Cybersecurity Focus

Ali Farhat — Fri, 02 Oct 2026 18:15:30 +0000

Google has officially introduced Gemini 4 Argon, the next frontier model in its Gemini lineup. The model is positioned for high-value work in software engineering, knowledge-intensive business tasks, defensive cybersecurity, and multimodal analysis and creation. Its most consequential technical specification is support for up to 1 million tokens of context, alongside introductory token-based pricing and a phased rollout that begins with trusted cyber defenders.

In Google's official Gemini 4 Argon announcement, the company describes Argon as a model intended to handle longer-running, more complex work than a typical single prompt. Google also says it is deploying safeguards for misuse risks, prompt injection, and misalignment as it expands access.

For businesses evaluating AI systems, the announcement matters less as a generic model upgrade and more as a signal of where frontier-model competition is heading: larger working context, deeper domain performance, and more explicit support for tasks that combine documents, code, data, and operational judgment.

What Gemini 4 Argon changes

A 1 million token context window for longer workflows

Gemini 4 Argon can accept up to 1 million tokens of context for long-horizon reasoning. Context is the information available to a model while it produces an answer, such as files, prior messages, code, instructions, or retrieved business material.

A larger context window does not automatically make every response correct. It can, however, make it more practical to work across substantial bodies of material without breaking them into as many separate interactions. For example, teams handling lengthy codebases, legal materials, financial information, product documentation, or multimodal inputs may be able to provide more relevant source material in one workflow.

The practical test will be whether Argon maintains useful reasoning and accurate outputs when that context is large and varied. Google points to engineering, financial, and legal evaluations as evidence of stronger domain performance, but individual organizations will still need to assess results against their own documents, processes, and quality requirements.

A stated focus on coding, knowledge work, security, and multimodal tasks

Google identifies four major areas for Gemini 4 Argon:

Software engineering and coding, including engineering benchmark performance and internal work such as codebase migrations to Rust.
Enterprise knowledge work, with examples spanning legal and finance-related reasoning.
Defensive cybersecurity, including autonomous vulnerability discovery and patching capabilities described by Google.
Advanced multimodal work for creative and analytical tasks involving more than text alone.

That combination is notable because these categories often require a model to retain context across many inputs while following complex instructions. Google says it has used Argon internally for memory optimizations, large-scale workflow tasks, and code migrations. Those examples illustrate the intended direction of the product, rather than guaranteeing the same outcomes for every user.

For organizations, the likely near-term opportunity is not to hand over critical processes without oversight. It is to identify work where staff currently spend time assembling information, tracing relationships across source materials, or repeatedly moving between tools. Long-context models may reduce that preparation burden when integrated thoughtfully and tested against clear success criteria.

Pricing and access are more concrete than a typical teaser

Google has published an introductory pricing structure for broad access. Input tokens are priced at $2 per 1 million tokens, while output tokens are priced at $10 per 1 million tokens. Cached input tokens receive a 95% discount compared with the standard input-token price.

Usage category	Google's introductory pricing	What it represents
Input tokens	$2 per 1 million tokens	Information supplied to Gemini 4 Argon
Output tokens	$10 per 1 million tokens	Content generated by Gemini 4 Argon
Cached input tokens	95% discount from the input-token price	Discounted reuse of cached input context

The model is not being released to all audiences at once. Google says Argon is initially rolling out to a cohort of trusted cyber defenders through its Fairwind program, with developers, enterprises, and consumers expected to receive broader access as soon as possible. The announcement does not provide a specific date for that wider availability.

This staged release means business planning should separate what is announced from what can be deployed today. The published pricing is useful for early cost modelling, particularly for applications that process substantial volumes of input or generate long outputs. But organizations should confirm actual access, supported interfaces, applicable terms, and production readiness when Google makes those details available for their intended use case.

Security capabilities come with deployment limits

Google presents defensive cybersecurity as a central Argon capability and describes autonomous vulnerability discovery and patching as part of its work in this area. It also says Argon includes protections related to CBRN and cyber misuse, prompt-injection resilience, and monitoring for misalignment.

That emphasis is important because tools that can analyze code, systems, and vulnerabilities can create value for defenders while also requiring careful controls. Google's initial Fairwind rollout reflects that balance. The announcement supports the view that cybersecurity will be an early deployment focus, not that every company can immediately use Argon to autonomously remediate production systems.

Businesses considering similar AI-assisted security workflows should treat the model as one component of a controlled process. Human review, defined access boundaries, logging, and validation remain practical necessities whenever outputs could affect code, infrastructure, customer data, or security posture.

Gemini 4 Argon's stated mix of long context, domain-oriented reasoning, and token pricing gives companies a clearer basis for evaluating potential applications. The next meaningful details to watch are the mechanics of broader availability, the developer experience, and how performance translates from Google's reported evaluations to specific operational workloads.

Long-context AI can create useful opportunities, but value depends on selecting the right workflows, preparing reliable inputs, and measuring results before scaling. Scalevise helps businesses turn promising model capabilities into practical implementation plans, from identifying high-value use cases to connecting AI with existing processes. Request an AI consultancy with Scalevise to evaluate where Gemini-class capabilities can deliver measurable operational value.

Frequently Asked Questions

What is Gemini 4 Argon?

Gemini 4 Argon is Google's newly announced frontier AI model in the Gemini line. Google positions it for software engineering, enterprise knowledge work, defensive cybersecurity, and advanced multimodal tasks.

How large is Gemini 4 Argon's context window?

Google says Gemini 4 Argon supports up to 1 million tokens of context for long-horizon reasoning.

What is Gemini 4 Argon's introductory pricing?

Google lists introductory pricing of $2 per 1 million input tokens and $10 per 1 million output tokens. Cached input tokens receive a 95% discount relative to the standard input-token price.

When will Gemini 4 Argon be broadly available?

Google says Argon is initially rolling out to trusted cyber defenders through its Fairwind program and that it plans to make the model available more broadly to developers, enterprises, and consumers as soon as possible. No specific broad-release date was provided.

Conclusion

Gemini 4 Argon is a confirmed new milestone for Google's Gemini platform, combining a 1 million token context window with an explicit focus on coding, knowledge work, cybersecurity, and multimodal tasks. Its phased rollout and published introductory pricing give prospective users useful signals, while also making clear that broader availability and real-world evaluation remain the next steps.

Building a Foundry Agent That Queries Fabric Data, On Behalf of the User

Jubin Soni — Fri, 02 Oct 2026 18:13:43 +0000

A regional sales manager and a sales rep both ask the same Foundry agent the exact same question: "show me revenue by region." The manager sees every region. The rep sees only their own. Same agent, same prompt, same tool call under the hood, two completely different answers, and nobody wrote a single if user.role == "manager" line to make that happen.

That's the pitch for wiring a Microsoft Fabric data agent into Microsoft Foundry as a tool. The integration isn't about giving your agent a new data source so much as it's about giving your agent a data source that already knows who's asking. Fabric has spent years building row-level security (RLS) and column-level security (CLS) into Power BI semantic models. Foundry has spent the last year building agents that can call tools mid-conversation. The thing connecting them is On-Behalf-Of (OBO) identity passthrough, and once you've set it up correctly, you stop worrying about data leakage through your agent because the enforcement never left Fabric in the first place.

This is a hands-on build guide. We'll publish a Fabric data agent, connect it to a Foundry project, attach it as a tool using the fabric_dataagent_preview tool type, and run it as two different signed-in users to prove the RLS boundary actually holds.

The mental model

Before touching code, it helps to separate two things people conflate: the Fabric data agent and the Foundry tool that calls it.

The Fabric data agent is a Fabric-native object. You build it inside a Fabric workspace, you point it at one or more data sources (a warehouse, a lakehouse, a KQL database, or a Power BI semantic model), and you publish it so it has a stable endpoint. It already knows how to turn natural language into queries against those sources, and it already respects whatever RLS or CLS rules are defined on the underlying semantic model. This part exists independently of Foundry. You could use it from the Fabric chat UI tomorrow and never touch an agent framework.

The Foundry tool is a thin, typed wrapper that lets a Foundry agent call that published Fabric data agent mid-conversation. Foundry doesn't re-implement any of the security logic. It authenticates as the person using the agent, hands that identity to Fabric, and lets Fabric do what it already does: answer the question using only the rows and columns that identity is allowed to see.

That handoff is the entire value proposition. If you've ever built a RAG pipeline where the retrieval step quietly ignored document-level permissions, you already know why this matters.

Prerequisites

A few things need to be true before any of the code below will work:

A Fabric workspace on paid F2 or higher capacity, or Power BI Premium P1 or higher with Fabric enabled
A published Fabric data agent, with at least one data source it has read access to
The Fabric data agent and your Foundry project in the same tenant, signed in with the same account
Fabric data agent and underlying data sources on capacities in the same region
At minimum the Foundry User (or AI Developer) RBAC role on the Foundry project for both you and anyone who will use the agent
User identity authentication only. Service principal authentication is explicitly not supported for the Fabric data agent tool. If your agent normally runs headless under a managed identity, this is the one tool call where that pattern breaks, and you need a real signed-in user in the loop.

That last point trips people up the most, so it's worth repeating before you build anything: this tool is designed for interactive, user-facing agents. It is not a background job tool.

Step 1: Publish the Fabric data agent

In your Fabric workspace, create a new Data agent item, point it at your semantic model or warehouse, give it instructions on what it's good for, and test it in the Fabric chat pane until it answers correctly. Then publish it.

Once published, open its endpoint URL. It looks like this:

https://fabric.microsoft.com/groups/<workspace_id>/aiskills/<artifact_id>

Copy both the workspace_id and the artifact_id out of that URL. You'll need both in the next step, and this is the only place to find them without digging through the REST API.

Step 2: Create the connection in Foundry

Foundry needs a connection object that stores those two IDs so the Fabric tool knows which data agent to call. You can do this in the portal or with the REST API. The portal path is simpler for a first run:

In your Foundry project, go to Build and customize > Agents
Open an existing agent or start a new one
Add a knowledge source, choose Microsoft Fabric
Create a new connection, paste in workspace_id and artifact_id as custom keys, and check Is secret
Name the connection and choose whether it's scoped to this project or shared across the account

If you'd rather script it, the same connection can be created directly against the management plane:

PUT https://management.azure.com/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.CognitiveServices/accounts/<foundry-account>/projects/<project>/connections/<connection-name>?api-version=2025-04-01-preview
Authorization: Bearer <token>
Content-Type: application/json

{
  "properties": {
    "category": "CustomKeys",
    "authType": "CustomKeys",
    "credentials": {
      "keys": {
        "workspace_id": "<fabric-workspace-id>",
        "artifact_id": "<fabric-data-agent-id>"
      }
    }
  }
}

Nothing in this connection object carries a user identity. It's purely routing information, pointing Foundry at the right Fabric data agent. The identity gets layered on later, automatically, at call time.

Step 3: Wire the Fabric tool into a Foundry agent

With the connection in place, attaching it to an agent is a few lines in the SDK. The flow looks like every other Foundry tool: resolve the connection ID, pass it into a typed tool definition, and hand that tool to the agent definition.

import os
from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import (
    PromptAgentDefinition,
    MicrosoftFabricPreviewTool,
    FabricDataAgentToolParameters,
    ToolProjectConnection,
)

project = AIProjectClient(
    endpoint=os.environ["PROJECT_ENDPOINT"],
    credential=DefaultAzureCredential(),
)

fabric_connection = project.connections.get(os.environ["FABRIC_CONNECTION_NAME"])

agent = project.agents.create_version(
    agent_name="sales-insights-agent",
    definition=PromptAgentDefinition(
        model="gpt-4.1-mini",
        instructions=(
            "You are a sales insights assistant. Use the Fabric data agent tool "
            "to answer questions about revenue, pipeline, and regional performance. "
            "Only answer from data the tool returns, never guess numbers."
        ),
        tools=[
            MicrosoftFabricPreviewTool(
                fabric_dataagent_preview=FabricDataAgentToolParameters(
                    project_connections=[
                        ToolProjectConnection(project_connection_id=fabric_connection.id)
                    ]
                )
            )
        ],
        tool_choice="required",
    ),
)
print(f"Created agent version: {agent.name}/{agent.version}")

Setting tool_choice="required" is a small thing but worth doing deliberately. Without it, a sufficiently confident model will sometimes answer a numeric question from its own training data instead of calling the tool, which defeats the entire point of grounding the answer in live, permission-scoped Fabric data.

Step 4: Run it, and run it as two different users

This is the step that actually proves the OBO flow works, and it's also the step people skip because it's more fun to write code than to go find a second test account.

Calling the agent uses the Responses API, same as any other Foundry agent:

client = project.get_openai_client()

response = client.responses.create(
    extra_body={"agent": {"name": agent.name, "type": "agent_reference"}},
    input="What was our revenue by region last quarter?",
)
print(response.output_text)

Run that once, authenticated as a user who has full access to every region in the underlying semantic model. You'll get a complete breakdown. Now run the exact same script, same agent, same question, authenticated as a user who's scoped by RLS to a single region. The tool call looks identical on the Foundry side. The answer that comes back only has that user's region in it.

Nothing in the agent's instructions, the tool definition, or the prompt mentions roles or regions. The restriction isn't implemented in your code at all. It's enforced by Fabric, using whatever RLS or CLS rules already exist on the semantic model, the same rules that would apply if that user opened the report directly in Power BI.

Here's the shape of that single call, end to end:

Where this fits in the bigger picture

Zoom out past a single request and the interesting part becomes what stays constant. The Foundry agent is the same agent, with the same tool definition, regardless of who's using it. What changes per request is a token exchange that happens automatically, between Foundry and the Entra app registered on the connection, before the call ever reaches Fabric.

That's the architectural payoff. You build the agent once. You don't build a separate agent per role, and you don't maintain a permissions table inside your application that has to stay in sync with whatever's configured in Power BI. The permissions model lives in exactly one place, which is also the place your data team already manages it.

Production considerations

A handful of things are worth knowing before this goes past a demo.

One Fabric data agent per Foundry agent, for now. The current tool only supports attaching a single Fabric data agent as a knowledge source. If you need to ground against multiple Fabric data agents, you're looking at multiple Foundry agents, or an orchestration layer in front of them, not one agent with several Fabric tools attached.

Service principals are a hard no. If any part of your pipeline runs unattended, under a managed identity, with no real user in the loop, it cannot use this tool. Build your unattended paths against the underlying data sources directly, and reserve the Fabric data agent tool for interactive, user-present sessions.

Region and tenant boundaries are enforced, not advisory. The Fabric data agent, its underlying data sources, and the Foundry project all need to line up on tenant and region. If you're running a multi-region deployment, plan your Fabric capacity placement before you plan your agent architecture, not after.

Compliance boundary shift. Microsoft is explicit that once a Fabric data agent is consumed through Foundry, responses may leave Fabric's compliance boundary and get processed under Foundry's own terms. If your data has specific residency or compliance requirements, read that section of the docs closely before you wire this up for production traffic.

Test with real RLS, not just admin accounts. It's tempting to build and demo everything under your own developer account, which usually has broad access. The entire value of this integration is invisible until you test with a properly restricted account. Budget time for that before you call the integration done.

Where this leaves you

The code to attach a Fabric data agent to a Foundry agent is genuinely small, a tool definition, a connection ID, a few lines. The part worth taking seriously is everything that small piece of code is standing on: years of RLS and CLS enforcement inside Fabric, an identity passthrough model that means your agent never has to see or store a permissions table, and a guarantee that whoever's asking the question only ever sees what they were already allowed to see.

If you're building an internal agent on top of data your organization already governs through Power BI or Fabric, this is very likely less work than building and maintaining your own access control layer on top of a generic retrieval tool. Publish the data agent, wire up the connection, and let Fabric keep doing the job it was already doing.

References

Luthier: an agent that audits an AI coding agent's harness against the repo it governs.

Harish Kotra (he/him) — Fri, 02 Oct 2026 18:13:25 +0000

Your agent's `CLAUDE.md` is lying to it, and nothing is checking

Every team I talk to has the same artefact now: a CLAUDE.md, an AGENTS.md, a .cursorrules, a folder of skills, an .mcp.json with four servers in it. It is written in a burst of optimism, and then the code moves.

Three months later:

the file it tells the agent to edit was renamed;
the command it tells the agent to run is not a script anyone declares any more;
one of the MCP servers points at a binary nobody has installed since the laptop was rebuilt;
a skill directory exists on disk that no instruction file has ever mentioned, so the agent cannot know it is allowed to use it;
and the convention everyone swears by — no console.log in committed code — is violated on line 4 of the entry point.

None of that throws. Your tests pass. CI is green. The only symptom is that the agent takes forty minutes to do a four-minute task, edits a file that does not exist, and tells you confidently that it "found the relevant module".

We check code into review, CI, a test suite, a linter and a type-checker. The harness — the file
that decides what the agent believes about the codebase — is checked into git and then never
verified again. Luthier is a checker for it.

The idea in one paragraph

Extract every claim the harness makes. Verify each claim against what is actually on disk. Report
the delta, with the rule quoted at file:line, the contradicting reality, and a unified diff you
can apply. Score the result 0–100 so it is comparable between runs and repos.

The claims are the unit of work, so the first job is a rule inventory.

{"rules":[
  {"id":"r1","source":"CLAUDE.md","line":14,
   "kind":"path|command|skill|mcp|convention","text":"<verbatim rule>",
   "check":{"type":"path_exists|command_runs|file_referenced|server_reachable|semantic",
            "target":"src/foo.ts"}}]}

Each rule names the check that can falsify it. Four of the five checks are deterministic — no LLM,
no network, no execution. The fifth is LLM-judged and degrades honestly when there is no key.

The architecture that keeps it honest

paste repo path (or drop a zip)
  |
  +-- discover harness ....... read_harness / inspect_repo   -> audit.log
  +-- extract rules .......... LLM (validated) + static fallback
  +-- check 1 path_exists .... glob against the real tree
  +-- check 2 command_runs ... declared in package.json / Makefile / pyproject  [never executed]
  +-- check 3 file_referenced  skills: declared -> used, on disk -> listed
  +-- check 4 server_reachable MCP schema + binary resolution  [never spawned]
  +-- check 5 semantic ....... mechanical subset offline, then LLM verdicts
  +-- score .................. 100 - sum(min(category_penalty, 32))
  +-- SSE progress -> runs/<id>.json -> scorecard / findings / evidence / fix diff

The design constraint that shapes everything: the auditor may only assert what it has read.
There are exactly two ways to learn about the repo, and both are journaled.

@tool
def read_harness(paths: list[str]) -> dict:
    """Read harness/instruction files (CLAUDE.md, AGENTS.md, .cursorrules, skills,
    MCP config, README) and return their real contents with 1-based line numbers.
    ...
    """
    return bundle.call("read_harness", {"paths": list(paths)})

@tool
def inspect_repo(globs: list[str]) -> dict:
    """Ground truth about the repository: which files match each glob, their sizes,
    and the first 20 lines of each match. Call this before claiming anything about
    what the repo contains. Output is byte-capped and says so when truncated.
    """
    return bundle.call("inspect_repo", {"globs": list(globs)})

bundle.call is the interesting part: it runs the tool, measures the duration and the byte size of
the payload, appends a JSONL record to audit.log, and keeps the result in an in-memory journal.
Every finding carries a journalRef — inspect_repo#4, grep#15 — pointing at the row in the log
that justifies it. A score is not an opinion here; it is a queryable trail.

Contents come back as lineno|text rows rather than raw text. That is a deliberate prompt-engineering
choice: models miscount lines, and if you make them count, they will confidently cite line 27 of a
12-line file. Hand them the numbering and the citation rate goes to ~100%.

The five checks, and what each one actually proves

1. `path_exists`

Pull path-shaped tokens out of harness text and glob them against the real tree. The interesting
work is in the filter, because prose is full of things that look like paths:

def looks_like_path(token: str, root_entries: set[str]) -> bool:
    raw = (token or "").strip().strip("`")
    if not raw or raw.startswith(("~/", "$", "%", "(", "@", "#")):
        return False
    parts = PurePosixPath(raw.replace("\\", "/").rstrip("/")).parts
    if not parts or any(_is_placeholder(p) for p in parts):
        return False
    head = parts[0]
    if "." in head and head.rsplit(".", 1)[-1].lower() in URL_TLDS:
        return False                       # example.com/api is not a repo path
    if head.upper() == head and len(head) > 2 and "." not in head:
        return False                       # OPENAI_API_KEY is not a directory
    ...
    return head.lower() in COMMON_TOP_DIRS or head in root_entries

Accept a token when it has a known extension, or when its first segment is a directory that
actually exists at the repo root, or a conventional one (src, docs, scripts, …). Placeholders
(<id>, {name}, path/to/…) are rejected — a harness that says path/to/secret.json is not
making a falsifiable claim.

Globs are claims too: src/**/*.tsx that matches nothing is drift, exactly as a missing file is.

2. `command_runs` — declared, never executed

This is the check people react to, because the naive version is a security incident: you do not
run the commands you are auditing.

if base in {"npm", "pnpm", "yarn", "bun"}:
    ...
    if sub in {"run", "run-script", "rs"}:
        script = tokens[2]
    elif sub in NO_DECL_SUBCOMMANDS:          # install, add, exec, doctor, ...
        return CommandVerdict(True)
    else:
        script = sub                          # `pnpm build` == `pnpm run build`
    if manifests.declares_script(script):
        return CommandVerdict(True)
    close = difflib.get_close_matches(script, sorted(manifests.scripts), n=1, cutoff=0.7)
    return CommandVerdict(False, "high",
        f"Script `{script}` is not declared in package.json", ...,
        replace=(script, close[0]) if close else None)

Everything is a lookup against declarations the repo already makes: package.json scripts (across
workspaces), Makefile targets parsed with a line regex, just recipes, [project.scripts] entry
points from pyproject.toml via tomllib, and requirements*.txt / dependency tables for bare
binaries. A binary "resolves" if it is on PATH (augmented with node_modules/.bin, .venv/bin,
~/.local/bin, Homebrew dirs) or declared by a manifest — because a documented tool you simply
have not installed yet is not harness drift.

3. `file_referenced` — skills go both ways

Two independent failures hide in a skills folder:

declared but unused: the harness names a skill, and the only mention of it anywhere in the repo is the harness line that declares it. Nothing outside the skill's own directory references it. That is a dead capability with a confident description.
on disk but unlisted: .hermes/skills/orphan-skill/ with a real SKILL.md inside, and no instruction file that mentions it. The agent cannot use what it is never told about.

The first is why the exclusion predicate matters — you must exclude the skill's own files and the
declaration line, or the check passes vacuously on every skill.

4. `server_reachable` — schema plus binary, no spawning

.mcp.json, claude_desktop_config.json, .cursor/mcp.json, .vscode/mcp.json and opencode.json
all hold server maps under slightly different keys (mcpServers, servers, mcp). Validate the
shape — command is a non-empty string, args a list of strings, env an object — then resolve
the binary. Never start the server.

The diff for a dead server is the most satisfying piece of the codebase. Reparsing the JSON and
re-dumping it would reformat the whole file; instead a small brace-matching scanner finds the exact
line span of the member and deletes just that block, then re-parses the result and refuses to
emit the diff if the JSON would break:

patched = "\n".join(remaining) + "\n"
try:
    json.loads(patched)
except ValueError:
    return None
return make_diff(path, text, patched)

If the dead binary has a near neighbour on PATH (node21 → node), the patch rewrites the
command instead of deleting the server.

5. `semantic` — and `unknown` as a real answer

Conventions are the hard part, so they get two engines. A mechanical subset is checkable without a
model: never use X, use A instead of B, every unit must contain file.ext. Grep the
token through source files, skipping comments and docs — a README that quotes an anti-pattern to
tell you not to write it is not a violation.

Everything else goes to the model, with a strict contract:

{"verdicts":[{"id":"r7","verdict":"holds|violated|unknown","evidence":"<path:line + quote>"}]}

…and then the answer is audited too. If a violated verdict cites a path that does not exist in the
repo, it is downgraded to unknown and the unverified citation is kept on the finding. unknown
costs 1 point and is always displayed. A tool that hides its uncertainty is a tool that will
eventually hide a violation.

No key configured? The section reports skipped: no_api_key — as a row in the findings table, not a
silent gap. Checks 1–4 still run, which is where most real drift lives anyway.

Scoring you can defend

BASE_SCORE                    = 100
PENALTY_DETERMINISTIC_FAILURE = 8
PENALTY_SEMANTIC_VIOLATION    = 5
PENALTY_SEMANTIC_UNKNOWN      = 1
MAX_PENALTY_PER_CATEGORY      = 32
CATEGORIES = ("paths", "commands", "skills", "mcp", "conventions")

score = max(0, 100 - sum(min(category_penalty, 32) for category in categories))

The per-category cap exists because a 500-path repo with one renamed directory should not score 0.
Four deterministic failures saturate a category, and the UI says capped when it happens.

The constants are served by GET /api/scoring and rendered in an expandable "how this score was
computed" panel, so nobody has to trust the number.

The two bugs that actually taught me something

lstrip("./") is not "strip a leading ./". It strips any leading character in the set
{'.', '/'} — so the pattern .mcp.json silently became mcp.json, and every dotted harness file
(.mcp.json, .cursorrules, .hermes/skills/**, .claude/…) was invisible to discovery. The
symptom was a clean-looking audit of a repo with a broken MCP config. The fix is a loop:

while norm.startswith("./"):
    norm = norm[2:]

Worse than the MCP miss: inspect_repo(".eslintrc.json") returned "does not exist", so the auditor
would have confidently reported a false finding. A byte-cap or a regex bug is visible; a
path-normalisation bug manufactures evidence. That is the one class of bug this project cannot
afford.

A diff is a claim too. My first stale-path patch deleted the whole harness line. For
- Edit \src/old.tswhen the CLI output changes. that is right. For
Read \README.mdfirst, then \docs/architecture.md. it deletes a valid instruction along with
the stale one. So: if the line carries other checkable claims, excise only the stale token — which
means tidying the residue (… first, then . → … first.) with a small chain of regexes, and
falling back to deleting the line when nothing checkable survives.

And a rename is only proposed when the file name is unchanged (a move) or the two paths are ≥0.86
similar. Anything looser goes in the suggestion field, not in a diff. src/cli.ts → src/util.ts
is a plausible-looking patch that would be wrong, and a wrong patch is worse than no patch.

Precision: the audit of the audit

Luthier's first run against a real repo scored 42 and flagged src/old.ts — a path that repo's
README quotes as an example of drift. Technically a true observation; practically noise, and
noise in a score is how you lose people's trust in one edit.

Two rules fixed most of it:

A file the docs say the app writes is not a broken reference. "stored in run/settings.local.json (mode 0600)" describes run-time behaviour. Advisory, 0 points.
Prose docs naming a path inside a directory this repo does not have are probably examples. README.md quoting src/foo.ts in a repo with no src/ at all → advisory. But CLAUDE.md quoting it → still a hard failure, because an instruction file is what the agent loads and obeys.

That distinction — instruction files are charged, docs are surfaced — is the whole difference
between a score people act on and a lint report nobody reads. The same repo went 42 → 76 with the
genuinely real findings still listed.

Verification

npm run verify     # python -m agent.verify

Two throwaway git repos are written to a temp dir. One has five kinds of seeded drift; every one
must be flagged at the correct file:line. The other must score ≥95 with zero deterministic
failures — the guard against a checker that flags everything, which is easy to write and worthless.
Then every generated diff is run through git apply --check, every citation must be a real line in
a real file, and audit.log must be valid JSONL with tool, args, duration and bytes on every row.

drifted fixture  score  47  findings  9  rules  9  tool calls 15
clean fixture    score 100  findings  0  rules  4

30 passed, 0 failed
PASS

The Strands agent loop gets its own check (scripts/agent_loop_check.py) against a local mock
OpenAI-compatible endpoint, asserting the agent's tool call really travelled through the journaled
reader and that the API key never appears in a response body. It proves the integration, not the
model's judgement — and it is honest about that distinction, because a claim about the second kind
would be exactly the thing this tool exists to catch.

What it's for

Not lint. Lint checks that code satisfies a style. Luthier checks that instructions satisfy
reality — a different axis, and the one nobody automated yet.

The uncomfortable framing: a harness is a prompt, a prompt is a dependency, and we have no
dependency checker for prompts. We have this instead — a scorecard that says, in one number and a
table of quotes, how much of what you tell your agent is still true.

Run it against your repo. If the number is high, the interesting question is whether your harness
has been edited recently enough to have had the chance to rot.

Stack: Strands Agents 1.57 (agent loop, @tool), FastAPI + uvicorn, httpx for plain OpenAI-compatible chat calls, Vite + React 18 + TypeScript + Tailwind, difflib for the patches, git apply --check as the diff gate. Python 3.11+, no network from the checks, no writes to the
audited repo.

Code & more: https://www.dailybuild.xyz/project/271-luthier

How to Handle Edge Cases in TTS Applications

VoiceDeveloper — Fri, 02 Oct 2026 18:12:57 +0000

Common Edge Cases in TTS

When you’re building a voice‑first product, the first thing you’ll notice is that the “normal” text you feed into a TTS engine is rarely normal. Think about product names, acronyms, URLs, emojis, or user‑generated content that can throw the synthesizer off its groove. If you don’t anticipate these quirks, your users will hear garbled speech, wrong pronunciations, or, worse, a voice that sounds like it’s from a different person.

Below we walk through the most frequent edge cases, how to tackle them, and some practical code snippets to get you up and running quickly. All of this is framed around the modern, developer‑friendly TTS platform ElevenLabs – a great place to start if you want high‑quality, customizable voices.

1. Non‑Standard Punctuation & Symbols

Problem

Punctuation like —, …, or emojis can be interpreted literally (e.g., “dash” or “ellipsis”) or cause a pause that feels unnatural.

Solution

Strip or replace uncommon punctuation before synthesis.
Use SSML <break> tags to control pauses.
Map emojis to descriptive text.

import re

def sanitize_text(text: str) -> str:
    # Replace em-dash with regular dash
    text = text.replace('—', '-')
    # Replace ellipsis with three periods
    text = text.replace('…', '...')
    # Map common emojis to words
    emoji_map = {'😀': 'smile', '🚀': 'rocket'}
    for emo, word in emoji_map.items():
        text = text.replace(emo, word)
    # Remove any remaining non‑ASCII characters
    text = re.sub(r'[^\x00-\x7F]+', '', text)
    return text

2. Acronyms & Initialisms

Problem

Acronyms like NASA or HTML are often pronounced as individual letters, which can be confusing.

Solution

Provide a custom pronunciation dictionary.
Use SSML <sub> tags to spell out acronyms.

<sub alias="NASA">NASA</sub> launched a new satellite.

If you’re using ElevenLabs’ API, you can pass the pronunciation field:

{
  "text": "NASA launched a new satellite.",
  "pronunciation": {
    "NASA": "na-sah"
  }
}

3. Numbers & Dates

Problem

Numbers can be read as digits (1 2 3) or as words (one hundred twenty‑three). Dates can be misinterpreted (12/10/23 → “twelve over ten over twenty‑three” vs. “December tenth, twenty‑three”).

Solution

Convert numbers to words using a library like num2words.
Use SSML <say-as> tags to specify format.

from num2words import num2words

def format_numbers(text: str) -> str:
    # Very naive example: replace digits with words
    return re.sub(r'\d+', lambda m: num2words(int(m.group())), text)

SSML example for dates:

<say-as interpret-as="date" format="mdy">12/10/23</say-as>

4. Non‑English Content

Problem

Mixed‑language input can cause the engine to default to the wrong language model.

Solution

Detect language using langdetect and route to the correct voice.
For short foreign phrases, use SSML <lang> tags.

from langdetect import detect

def detect_and_route(text: str):
    lang = detect(text)
    if lang == 'en':
        voice = 'en-US'
    elif lang == 'es':
        voice = 'es-ES'
    # ... more voices
    return voice

5. Custom Voice Cloning

Problem

Standard voices may not match your brand’s tone or the user’s preference.

Solution

ElevenLabs offers a straightforward voice cloning workflow. Create a “voice profile” by uploading a short audio clip and letting the model learn your unique timbre. You can then pass the voice_id to the API.

import requests

API_KEY = 'YOUR_ELEVENLABS_API_KEY'
VOICE_ID = 'your-cloned-voice-id'

headers = {
    'accept': 'application/json',
    'xi-api-key': API_KEY,
    'content-type': 'application/json',
}

data = {
    "text": "Welcome to our brand‑new feature!",
    "voice_id": VOICE_ID,
}

response = requests.post(
    'https://api.elevenlabs.io/v1/text-to-speech',
    headers=headers,
    json=data
)

with open('output.mp3', 'wb') as f:
    f.write(response.content)

Tip – When cloning, keep the recording short (≈30 s) and clear. Background noise hurts the model’s accuracy.

6. Emotion & Prosody Control

Problem

A monotonous voice can make your app feel robotic. But too much emphasis can sound forced.

Solution

ElevenLabs lets you tweak prosody and emotion via SSML or by setting the style parameter.

<prosody rate="95%" pitch="10%">Hello, world!</prosody>

Or via the API:

{
  "text": "Hello, world!",
  "style": "cheerful"
}

Experiment with style options like serious, excited, or calm to match your brand voice.

7. Handling User‑Generated Content

Problem

User comments or reviews can contain slang, misspellings, or even profanity.

Solution

Sanitize: Strip profanity using a whitelist or a third‑party library.
Normalize: Use a spell‑checker to fix common typos.
Fallback: If a phrase cannot be reliably processed, fallback to a default voice or skip TTS for that segment.

import profanity_filter

def clean_user_text(text: str) -> str:
    return profanity_filter.sanitize(text)

8. Testing & QA

Automated Unit Tests

def test_sanitize_text():
    raw = "Hello—world…😀"
    cleaned = sanitize_text(raw)
    assert "—" not in cleaned
    assert "…" not in cleaned
    assert "😀" not in cleaned

End‑to‑End Pipeline

Input → Sanitization → Language Detection → Voice Selection → SSML Generation → ElevenLabs API → MP3 → Playback.
Log each step; if the API returns an error, surface a human‑readable message.

9. Deployment Considerations

Rate Limits – ElevenLabs enforces limits per minute. Cache frequently used sentences or pre‑generate static audio where possible.
Latency – Use asynchronous calls or a queue system (e.g., RabbitMQ) to keep UI responsive.
Storage – Store generated MP3s in a CDN or object store for quick retrieval.

10. Wrap‑Up

Edge cases in TTS aren’t just bugs; they’re opportunities to polish the user experience. By sanitizing input, handling special formats, and leveraging the flexibility of services like ElevenLabs (https://try.elevenlabs.io/kr07zfuqn1bp), you can create a voice layer that feels natural, trustworthy, and uniquely yours.

Next Steps

Try ElevenLabs – Sign up using the link above and experiment with cloning a voice from your own recordings.
Integrate – Plug the snippets into your existing pipeline and watch the quality jump.
Iterate – Add more SSML tags, fine‑tune styles, and gather user feedback.

Give ElevenLabs a spin today and transform how your users hear your content. Happy coding!

OpenCoach: a Sanity Context agent that reconciles outdated docs with live code

Marcelo Rodrigues — Fri, 02 Oct 2026 18:09:39 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content.

What I Built

OpenCoach is a question-answering agent for the architecture and business rules of an order-processing system. It helps a developer answer questions such as “How does the dead-letter queue work?” with evidence from structured, source-linked knowledge rather than a plausible but unverified summary.

The problem is especially visible when documentation ages: an earlier diagnostic said retry and a DLQ still needed to be implemented, while the current Go code declares dead-letter exchanges and queues and rejects failed messages without requeueing. I modeled both claims, their status, and their sources in Sanity so the agent can distinguish historical advice from current behavior. That is more useful than treating all matching text as equally current.

The pre-existing Go orders/payments application is the foundation, not the contest entry itself. I began that repository before this challenge. During the challenge I added the Sanity Studio schemas and seed content, connected OpenCoach to a Sanity Context Knowledge Base over MCP, and added the grounded-answer interface. The existing local RAG mode remains available as a separate mode.

Demo

Try the live OpenCoach demo: open OpenCoach, enter “Como funciona a DLQ?” (“How does the DLQ work?”), then click Buscar evidências. The response shows the Sanity Context mode and the Knowledge Base evidence it used. This exact question was tested against the deployed app.

No login is required for the demo. The backend runs on a free hosting tier and may need time to wake after inactivity. If an upstream model request briefly returns 503, wait and try again.

Code

The open-source repository contains the Go application and the contest additions. The Sanity integration pull request makes the new work and its history easy to inspect. The main integration points are sanity/schemaTypes/, sanity/seed/, open_coach.py, rag_api.py, and frontend/src/App.tsx.

How I Used Sanity

I created a Sanity Studio for technical knowledge, not customer or order records. Five document types model business rules, architecture decisions, domain events, API endpoints, and documentation claims. The content records code-file evidence and distinguishes current claims from outdated ones. A historical DLQ claim explicitly references the current claim it conflicts with.

I seeded the Studio from facts checked against the repository code and used those documents to build a Sanity Context Knowledge Base. At question time, the OpenCoach backend calls the Context MCP initial_context tool for the Knowledge Base outline. A Gemini routing step selects relevant entry paths; the backend reads those entries with knowledge_base_read; and a second step generates the answer from the retrieved entries. The UI exposes the answer and the evidence so a reader can inspect the basis for it.

This structure is central to the use case: the agent needs to know whether a claim is current or historical, what code supports it, and which claims conflict. A plain keyword match on “DLQ” would retrieve both old and new statements without resolving their status.

One limitation remains transparent: in a generated DLQ Knowledge Base entry, two citation markers about metrics and monitoring point to the current-DLQ claim rather than the architecture-decision source that actually documents those details. The source-card mismatch is recorded in sanity/README.md. The presence and basic behavior of the DLQ were checked against code, but these two citation markers still need human review; “entries up to date” does not mean every generated citation is correct.

Sanity Project Details

Sanity project ID: ss56mini
Dataset: production
Knowledge Base ID: kbbKnMXYLs6b
Studio schemas and seed content: sanity/

The MCP access token stays on the backend and is not published with the demo or repository.

AI Agency Framework: AI’s Effect on Society, Jobs, Tools, and Culture

AI Agency Framework — Fri, 02 Oct 2026 18:08:22 +0000

AI Agency Framework — clear explainers on AI’s effect on society, jobs, tools, and culture.

Explore the framework: https://aiagencyframework.org/

Why Every App Will Have Voice AI by 2028

VoiceDeveloper — Fri, 02 Oct 2026 18:07:42 +0000

The Voice AI Wave: Why Every App Will Have Voice by 2028

If you’ve been building mobile or web products for the last few years, you’ve probably noticed a subtle but steady shift: voice is becoming a first‑class interface. From smart assistants that sit on your nightstand to in‑app audio guides that read out long‑form content, developers are adding spoken interaction almost as reflexively as they add a button or a swipe gesture.

So why are we convinced that every app will ship with Voice AI by 2028? Let’s break down the three forces that are pushing us toward that future, and then dive into a practical example of how you can get started today using the ElevenLabs platform (yes, the same service that powers many of the most natural‑sounding text‑to‑speech experiences on the market).

1. The Maturation of Text‑to‑Speech (TTS) Engines

A decade ago, TTS sounded robotic—think “Welcome to the system, please press one.” Modern neural TTS models now generate speech that carries intonation, emotion, and even speaker‑specific quirks. The underlying technology has moved from concatenative synthesis (stitching together pre‑recorded phonemes) to deep learning models that predict raw waveforms directly.

Key milestones:

Year	Breakthrough	Impact
2017	WaveNet (DeepMind)	Human‑like prosody
2020	FastSpeech 2	Real‑time generation
2022	Voice cloning APIs	Custom voice avatars on demand
2024	Multi‑language zero‑shot TTS	One model, dozens of languages

Because the latency is now measured in milliseconds and the cost per generated minute has dropped to pennies, integrating TTS is no longer a “nice‑to‑have” luxury—it’s a cost‑effective baseline for accessibility, localization, and user engagement.

2. Voice Cloning Makes Personalization Scalable

Imagine a fitness app that greets each user by name, using their own voice. Or an e‑learning platform where the instructor’s tone matches the learner’s preferred accent. Voice cloning—training a model on a few seconds of audio to reproduce a specific voice—makes that possible.

Why does cloning matter for developers?

Brand Consistency – Companies can create a unique brand voice without hiring a full‑time voice actor.
User‑Generated Content – Apps can let users upload a short sample and instantly generate personalized audio replies.
Accessibility – People with speech impairments can have their own voice synthesized for communication tools.

The barrier to entry has collapsed: modern APIs expose cloning with just a few HTTP calls, handling the heavy lifting of model training behind the scenes.

3. Platform Integration Becomes Plug‑and‑Play

All major cloud providers now offer managed voice services that integrate with serverless functions, mobile SDKs, and CI pipelines. The workflow looks like this:

Collect text (e.g., a news article, a chatbot response).
Call a TTS endpoint (provide language, voice ID, style).
Stream the audio back to the client or store it in a CDN.

Because the API surface is uniform, you can swap providers, experiment with voices, and even A/B test different speech styles without rewriting core business logic.

Getting Your Hands Dirty: A Quick ElevenLabs Demo

ElevenLabs offers one of the most natural‑sounding neural TTS engines on the market, plus a straightforward voice cloning endpoint. Below is a minimal example that shows how to:

Generate speech from plain text
Use a cloned voice (once you’ve uploaded a sample)

Feel free to copy‑paste this into a fresh Python virtual environment.

Prerequisites

# Create a venv (optional but recommended)
python -m venv venv
source venv/bin/activate  # on Windows: venv\Scripts\activate

# Install the HTTP client
pip install requests

1️⃣ Generate Speech with a Default Voice

import requests

API_KEY = "YOUR_ELEVENLABS_API_KEY"
url = "https://api.elevenlabs.io/v1/text-to-speech/EXAMPLE_VOICE_ID"

payload = {
    "text": "Welcome to the future of voice AI. Your app just got a lot smarter!",
    "model_id": "eleven_monolingual_v1",
    "voice_settings": {
        "stability": 0.75,
        "similarity_boost": 0.85
    }
}

headers = {
    "xi-api-key": API_KEY,
    "Content-Type": "application/json"
}

response = requests.post(url, json=payload, headers=headers)

# Save the audio file
with open("welcome.mp3", "wb") as f:
    f.write(response.content)

print("Audio saved as welcome.mp3")

Replace EXAMPLE_VOICE_ID with any of the public voice IDs listed in the ElevenLabs docs. The stability and similarity_boost parameters let you fine‑tune the prosody to match your app’s personality.

2️⃣ Clone a Custom Voice

First, upload a short (≈30 s) sample of the target speaker. You can do this via the web console or a simple curl call:

curl -X POST "https://api.elevenlabs.io/v1/voices/add" \
  -H "xi-api-key: YOUR_ELEVENLABS_API_KEY" \
  -F "name=MyCustomVoice" \
  -F "files=@/path/to/sample.wav"

The response contains a new voice_id. Use that ID in the TTS request:

custom_voice_id = "YOUR_CUSTOM_VOICE_ID"

url = f"https://api.elevenlabs.io/v1/text-to-speech/{custom_voice_id}"
response = requests.post(url, json=payload, headers=headers)

with open("custom_greeting.mp3", "wb") as f:
    f.write(response.content)

print("Custom voice audio saved as custom_greeting.mp3")

That’s it—your app now speaks with a brand‑new, user‑specific voice.

3️⃣ Front‑End Integration (JavaScript)

If you’re building a web app, you can stream the audio directly to the browser:

async function speak(text, voiceId) {
  const response = await fetch(`https://api.elevenlabs.io/v1/text-to-speech/${voiceId}`, {
    method: "POST",
    headers: {
      "xi-api-key": "YOUR_ELEVENLABS_API_KEY",
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      text,
      model_id: "eleven_monolingual_v1",
      voice_settings: { stability: 0.7, similarity_boost: 0.9 }
    })
  });

  const blob = await response.blob();
  const url = URL.createObjectURL(blob);
  const audio = new Audio(url);
  audio.play();
}

// Example usage
speak("Hey there, welcome back!", "EXAMPLE_VOICE_ID");

With just a few lines, you’ve turned any string into a spoken phrase that can be played back instantly.

Real‑World Scenarios Where Voice AI Becomes Mandatory

Domain	Why Voice Matters	Example Use‑Case
E‑commerce	Hands‑free browsing while cooking, driving, or exercising	“Hey app, read me the top‑rated reviews for the blender.”
Healthcare	Accessibility for patients with limited motor control	Medication reminders spoken in a calming, familiar voice.
Education	Multilingual narration for global classrooms	Auto‑translate a lecture and deliver it in the student’s native accent.
Gaming	Dynamic NPC dialogue that adapts to player choices	Clone the voice of a player’s character for in‑game narration.
FinTech	Secure, voice‑based verification and transaction summaries	“Your balance is $4,321. Would you like to transfer $200?”

In each of these, the cost of not having voice is higher friction, lower retention, or missed accessibility compliance.

Preparing Your Stack for Voice‑First Development

Design for Latency – Even with fast neural models, network round‑trip adds ~150 ms. Cache frequently used phrases or pre‑generate audio for static content.
Handle Audio Formats – MP3 is universally supported, but consider OGG or AAC for lower bitrate when bandwidth is tight.
Secure Your API Keys – Store keys in environment variables or secret managers; never embed them in client‑side code.
Monitor Costs – Most providers bill per generated minute. Set alerts once you cross a threshold, especially if you enable user‑generated cloning.

The Bottom Line

Voice AI is moving from a novelty to a necessity. The technology is affordable, the APIs are developer‑friendly, and the user expectations are rising fast. By 2028, any product that wants to stay competitive will need to speak—literally.

If you’re ready to add that conversational sparkle to your app, ElevenLabs offers a powerful, easy‑to‑integrate platform for both high‑quality TTS and voice cloning. Their API is well‑documented, and the pricing tier for developers is generous enough to let you experiment without breaking the bank.

👉 Ready to give your app a voice?

Start building today with ElevenLabs and see how natural‑sounding speech can transform your user experience. Grab your free trial here: https://try.elevenlabs.io/kr07zfuqn1bp. Happy coding—and happy listening!

Build an AI Shopping Agent That Knows What a Deal Costs

bot bot — Fri, 02 Oct 2026 18:05:22 +0000

Originally published at ForgeMesh.

An AI shopping agent needs current product data, a way to compare like-for-like offers and an honest account of missing costs. ShopScout supplies search, product lookup, offer comparison and shipping-plan tools through an HTTP API and an MCP wrapper. This guide shows how to connect them to a tool-capable agent without tying the design to one chat model.

Build around the tool contract, not one chat brand

The useful boundary is between the model that reasons about a request and the tools that fetch evidence. MCP’s architecture describes how a host connects through clients to servers that expose capabilities. It does not grant a model shopping data, payment permission or checkout access by itself.

Use ShopScout’s local stdio MCP server in a host that supports it, such as an appropriately configured Claude Desktop setup. For a custom agent, call the HTTP API or adapt its contract to your framework’s tool format. Check the client’s actual transport support before copying a configuration.

The design can serve Claude-based agents, OpenAI-based agents, other model providers and custom bots. That does not mean every consumer chat app accepts this MCP package. ShopScout’s hosted /mcp endpoint is currently a free discovery surface with list_tools, not a remote replacement for the executable paid stdio tools.

Start with the downloadable, no-payment kit

Download the ShopScout starter kit. It contains a minimal MCP configuration, a Node.js discovery check, valid search and shipping request examples, and an agent instruction file. The examples use illustrative inputs and make no claims about current product results.

Unzip the kit and run node shopscout-discover.mjs with Node.js 20 or later. It reads the free capabilities and OpenAPI endpoints. Add --check-payment-gate to send one unsigned search request and verify that the API requests payment. The script has no wallet support and does not sign or submit a payment.

This first check answers a concrete question: can your environment reach the service and discover its contract? A 402 response to the optional search check is the expected payment gate, not a completed search. It proves neither product coverage nor paid settlement.

Connect the MCP wrapper to a compatible client

The package is @forgemeshlabs/shopscout-mcp. In the kit’s mcp-config.json, the command is npx and the arguments are -y followed by the package name. Merge that server entry into the configuration format your client uses; do not replace unrelated servers.

The starter leaves out WALLET_PRIVATE_KEY. In that state, get_capabilities works and paid tools report payment_required rather than paying. When you deliberately enable payments, supply a dedicated, low-balance Base wallet through the client’s protected configuration. Do not put a real key in prompts, screenshots or a shared example file.

The current wrapper caps each call with SHOPSCOUT_MAX_PRICE_USD, defaulting to 0.01. It checks the payment request before signing and retries once with authorization. See the package README for current setup and payment behavior.

Give the agent a small, explicit shopping workflow

Discover: call get_capabilities first. Check whether a tool is available, disabled or planned. A planned watch operation is not something the agent can schedule by calling it.

Search: call search_products with a query, country and currency. A valid starter request is {"query":"compact coffee grinder","country":"US","currency":"USD","limit":3}. Limit the result count while you test. A valid search that returns no matches can still incur the tool fee.

Refresh: use get_product with a real ID returned by the catalog and the intended options. Never invent variant IDs. Preserve the source timestamps so the final answer can explain how fresh its evidence is.

Compare: pass two to ten distinct returned variant IDs to compare_offers in the same currency. Check size, pack count, model and condition before treating them as equivalent. ShopScout’s comparison ranks item prices; it does not verify product equivalence or declare a final delivered-cost winner.

Estimate delivery costs: call compare_shipping_plans only after you have shipping rules to supply. Keep their source with the request. Then return the shortlist with known prices, missing costs and merchant links. Buying the item belongs to a separate, explicitly authorized checkout flow.

A lower item price is only one part of the answer

The kit includes shipping-example.json with two illustrative offers for one item. Offer A costs 4900 minor units plus 1200 for shipping. Offer B costs 5500 with shipping set to zero by the supplied example rule. In USD, those pre-tax totals are $61 and $55.

The shipping request names items, offers, fulfillment groups and methods. It gives each group a rule_source and supported destination countries. Amounts are integer minor units, not floating-point dollars. The example also supplies a stated maximum delivery time for each method.

These are invented inputs for learning the request format, not live merchant terms. ShopScout compares the plans described by those inputs. It does not fetch a carrier quote or prove the supplied delivery promise.

Keep taxes, duties and landed_total null when unknown. Show the known subtotal beside the missing fields. A UI that converts null to zero can turn an incomplete estimate into a false claim about the cheapest order.

Set a task budget above the per-call cap

The four paid operations currently cost $0.01 each; get_capabilities is free. One search, one product refresh, one offer comparison and one shipping comparison would cost $0.04 in tool fees at that price. That excludes model usage, hosting and any eventual purchase.

A $0.01 per-call cap is not a $0.01 task budget. Ten accepted calls can spend ten cents. Put a separate maximum call count and total tool-fee budget in the host, where the model cannot casually override them.

For a first paid workflow, a four-call limit makes the cost easy to inspect. Stop when the limit is reached, when essential inputs are missing or when the service rejects payment. Do not let the agent retry payment failures in a loop.

Use the live OpenAPI contract as the source for route schemas and consult capabilities for current availability. A free discovery check is a good starting point, but test an authorized paid flow before describing your integration as production-ready.

Keep product text out of the instruction channel

A catalog description may contain claims, links or even text that looks like a command. Treat those fields as untrusted data. They must not change wallet settings, raise budgets or tell the agent which tools to run.

The kit’s agent instructions ask for exact product identity, source links, known costs and explicit unknowns. Enforce payment and tool permissions in application code too. A prompt is useful guidance; it is not a security boundary.

Follow the package guidance not to cache catalog search results. Retain only operational records you need, such as call counts and settlement references, with sensitive information redacted. Refresh product evidence for a decision instead of presenting an old search as live stock.

Run locally first; hosting is optional

The MCP wrapper can run locally while calling the hosted ShopScout API. You do not need a new server just to try it. A persistent custom agent may need hosting later, depending on your application.

If you choose DigitalOcean hosting through our affiliate link, ForgeMesh may earn a commission. You can use DigitalOcean’s direct pricing page without our affiliate link or another host. Hosting is separate from ShopScout’s per-call fees and is not required by the starter kit.

What this shopping agent can and cannot do

It can research products in the configured catalog, refresh details, compare item prices and evaluate supplied shipping rules. It cannot guarantee coverage of every merchant or know a missing tax value. ShopScout does not place orders, provide a scheduler or execute the planned price and stock watches.

Those boundaries make the first version easier to explain: “Here are three options, the evidence I used and what you still need to check.” Use our consumer shopping prompt as the front end to that experience.

Start with the free capabilities endpoint, then connect the ShopScout tools to your agent. For the wider context, read agentic commerce explained and the ShopScout launch.

AI Shopping Assistants: A Better Way to Find Gifts

bot bot — Fri, 02 Oct 2026 18:05:13 +0000

Originally published at ForgeMesh.

AI shopping assistants can turn a vague gift idea into a useful shortlist. The trick is to give them a budget, a deadline and a few firm rules, then ask for evidence behind each choice. You can use this approach with Gemini, ChatGPT, Copilot, Perplexity, Alexa for Shopping, Claude or a tool-equipped personal agent. What each can search or buy depends on its current tools and your account.

Why AI holiday shopping is worth trying in 2026

Holiday shopping is a good test for AI. You have a person to buy for, a price limit and a date the gift must arrive. That gives an assistant something much more useful to work with than “show me popular gifts.”

In its September 28 holiday shopping forecast, Adobe reported that AI-driven traffic to retail sites grew 127% year over year in August 2026. That measures visits from AI sources. It does not mean 127% more people let a bot buy things on its own.

The practical opportunity is smaller and more useful: spend less time opening tabs, get a clearer comparison and spot missing facts before you pay. This guide focuses on that job across assistants. Our earlier guide to buying through ChatGPT covers the question from one app’s point of view.

Choose by shopping task, then check the app

Google Gemini and Google shopping tools: Google has announced Universal Cart across several of its surfaces, including Gemini. Treat product announcements and features visible in your own account as separate things. Check whether your chosen retailer, country and item are supported before you expect checkout inside a chat.

ChatGPT: Shopping search can surface products and merchant links; eligible listings may offer an in-chat checkout path. A product card is still a starting point. Open the offer to check the exact model, stock and final price.

Microsoft Copilot: Microsoft describes a shopping flow that helps compare options and sends you to the retailer when you choose Buy. Availability varies by market and platform. It can be useful even when the purchase itself happens elsewhere.

Alexa for Shopping: Amazon combined Rufus and Alexa+ into Alexa for Shopping. It brings product help and personal context into Amazon’s shopping experience. A store’s own assistant is worth using for questions about that store; check other sellers when breadth matters.

Claude, Perplexity and personal agents: Start by asking what sources and tools the current session can actually access. Claude’s desktop and web connectors have different setup paths. A connector, browser or shopping tool can change what an agent can do; the model name alone does not tell you whether it can retrieve live prices or place orders.

Copy this prompt into your preferred assistant

“Help me choose a gift for someone who likes cooking and has a small kitchen. My total budget is $75 including shipping and tax. Delivery is to the United States by December 15. Avoid subscriptions, large appliances and items that need a separate paid accessory.”

“Ask up to three questions if needed. Then show three options with the exact model or size, seller, item price, shipping, tax, expected arrival, return terms and a source link. Mark missing facts unknown. Tell me when you checked each offer. Explain one reason to choose and one reason to skip each option.”

“Use live sources if available and say if you cannot access them. Do not call an item the cheapest unless the compared offers are for the same thing. Do not buy anything. Give me a shortlist to review.”

This is a reusable prompt, not a switch that enables missing features. If the assistant cannot browse, give it two or three retailer links or paste the key details yourself. You can still ask it to compare dimensions, terms and trade-offs.

The $49 gift can cost more than the $55 gift

For example, compare these two invented offers. They are not live product recommendations. Seller A lists an item for $49 with $12 shipping. Seller B lists the same item for $55 with free shipping. Before tax, the totals are $61 and $55. The lower sticker price loses by $6.

Now add a deadline. If Seller B only gives an uncertain arrival window, Seller A might still be the better choice for a time-sensitive gift. Ask the assistant to separate the lowest known cost from the option most likely to meet your deadline.

Unknown tax is not zero tax. An unknown delivery date is not a promise. When key details are missing, the useful answer is “check this before buying,” followed by a link to the seller.

Compare the exact product, not just its name

Before you pick a winner, check model number, size, color, pack count, condition and included parts. A two-pack, a single item and a refurbished unit can share most of a title. A cheap appliance may need an accessory that the other offer already includes.

Ask for the evidence that matters to you. For a small kitchen, dimensions may beat a long feature list. For headphones, comfort and compatibility may matter more than an extra codec. For gifts, the return window may matter more than saving a few dollars.

Finish with a simple question: “What would make you change this recommendation?” That often reveals the missing fact that deserves your next click.

Where ShopScout fits into the shopping conversation

ShopScout by ForgeMesh is our shopping tool for agents. An agent with the right integration can search the configured Shopify Global Catalog, refresh product details and compare offers. It can also compare shipping plans using rules supplied to it.

That makes ShopScout useful when you want the assistant to work with structured product data instead of a loose list of suggestions. It is a developer-facing API and MCP tool today; opening a random chat app does not automatically connect it. If you build agents, use our ShopScout integration guide.

Each of its four paid operations currently costs $0.01 in USDC on Base. Capability discovery is free. The service fee pays for the tool call; it does not buy the product. ShopScout does not place orders, run price watches or guarantee a complete search of every store.

Shipping comparisons are estimates from supplied rules, not live carrier quotes. Unknown taxes and duties remain unknown. Those limits are useful: they tell the assistant what it still needs to verify.

Want a starting point for tech gift ideas?

You can browse our Amazon storefront (affiliate link) for ideas, then use the prompt above to compare the item with other sellers. As an Amazon Associate, we earn from qualifying purchases. You can also browse Amazon directly without our affiliate link.

Treat the storefront as a starting list, not a claim that those products are the best or cheapest for everyone. Keep your budget and needs in the prompt. Ask the assistant to justify any recommendation with facts you can check.

Can an AI assistant buy things for me?

Some assistants and retailer integrations offer purchasing for eligible items. Others help you research and then send you to a store. Before authorizing an order, check the seller, exact item, quantity, delivered price and address in the checkout flow you are using.

You do not need automatic checkout to get value from AI shopping. A good shortlist can save time on its own. If you do enable purchasing, make the spending limit and approval rule explicit in the tool’s actual settings.

Do I need crypto or a paid chatbot to try this?

You do not need crypto to use the shopping prompt. Use a client and research tools you already have access to; its plan and usage limits still apply. ShopScout’s paid integration uses USDC, which is a separate choice for people building or configuring agents.

For your next purchase, pick one real task: three gift ideas, the same item at two stores, or a basket that must arrive by a set date. Ask for sources and unknowns. Then check the final offer. If you want to understand the wider shift, start with our guide to agentic commerce.

Compress Before You Prompt: How a 74K-Star Token-First Architecture Is Making AI Coding Agents Smarter, Cheaper, and Actually Honest

Tamiz Uddin — Fri, 02 Oct 2026 18:02:25 +0000

Originally published on tamiz.pro.

The context window is the new bottleneck. Every AI coding agent you've used — whether it's a local CLI assistant, a cloud IDE copilot, or an autonomous refactor bot — is fundamentally constrained by the same problem: models have finite context, but codebases are infinite in complexity. The result is a brutal engineering tradeoff. Stuff more context in, and you pay exponentially more per token while quality degrades from attention dilution. Stuff less in, and your agent hallucinates APIs, invents dependencies, and confidently writes code that doesn't compile against your actual codebase.

A project that has accumulated over 74,000 GitHub stars in under a year offers a radically different approach. Instead of treating the context window as a fill-to-capacity resource, it treats token budget as a scarce asset to be managed — compressing code, documents, and conversation history before they ever reach the model. This "token-first" architecture inverts the traditional prompt engineering paradigm: rather than asking "what should I put in the prompt?", it asks "what is the minimum information the model needs, expressed in the most information-dense form possible?"

The results are striking. Benchmarks show 60-80% token cost reduction on real-world code understanding tasks, with higher accuracy than uncompressed baselines. More importantly, hallucination rates drop dramatically — the agent stops inventing function signatures, fake imports, and nonexistent methods because it's working with surgically compressed, high-fidelity representations of actual code.

This article dissects the architecture, explains the compression pipeline in detail, and walks through the engineering decisions that make this approach viable at scale.

1. The Context Window Crisis
2. Architecture Overview
3. The Compression Pipeline
4. AST-Based Code Compression
5. Semantic Chunking and Relevance Scoring
6. The Honesty Problem and How Compression Solves It
7. Token Budget Management
8. Implementation Deep Dive
9. Performance Benchmarks
10. When This Architecture Breaks
11. Building Your Own Token-First Agent
12. Frequently Asked Questions

1. The Context Window Crisis

Modern LLMs advertise context windows of 128K to 200K tokens. This sounds generous until you realize what actually goes into a coding agent's context:

Context Component	Typical Token Cost	Notes
System prompt + tool definitions	2,000–5,000	Fixed overhead
Conversation history	5,000–20,000	Grows linearly with turns
Repository structure (file tree)	3,000–10,000	For medium projects
Referenced source files	10,000–50,000	The biggest variable
Documentation / README	2,000–8,000	Often low signal
Linting/test output	1,000–5,000	Noisy

A single "refactor this module" request can consume 80,000+ tokens of context, leaving almost no room for the model's actual reasoning. Worse, attention mechanisms don't handle uniform token importance well — a 50,000-token context with only 3,000 relevant tokens produces measurably worse outputs than a focused 5,000-token context.

The traditional approach has been retrieval augmentation: use a vector database to find "relevant" chunks and stuff them in. This helps, but it's blunt. Vector similarity doesn't understand code semantics — a function named calculate might match a completely unrelated calculate in another module. And once chunks are in the context window, they're immutable. The model sees them all with equal weight.

2. Architecture Overview

The token-first architecture introduces a compression layer between the raw codebase and the model. Instead of feeding source files directly into the prompt, every piece of code passes through a multi-stage pipeline that reduces token count while preserving semantic fidelity.

Here's the high-level data flow:

┌─────────────────────────────────────────────────────────────────┐
│                    AI Coding Agent Runtime                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                   │
│  ┌──────────┐    ┌──────────────┐    ┌───────────────────────┐  │
│  │  Raw     │───▶│  Compression │───▶│  Token Budget         │  │
│  │  Codebase│    │  Pipeline    │    │  Allocator             │  │
│  └──────────┘    └──────────────┘    └───────────┬───────────┘  │
│       │                    │                      │              │
│       │                    ▼                      ▼              │
│       │            ┌──────────────┐    ┌───────────────────────┐ │
│       │            │  AST Parser  │    │  Context Assembly     │ │
│       │            │  + Indexer   │    │  + Prompt Builder     │ │
│       │            └──────────────┘    └───────────┬───────────┘ │
│       │                                             │             │
│       │                                             ▼             │
│       │                                    ┌───────────────┐     │
│       │                                    │  LLM Backend  │     │
│       │                                    │  (Any Model)  │     │
│       │                                    └───────────────┘     │
│       ▼                                                         │
│  ┌──────────┐                                                   │
│  │  Git /   │                                                   │
│  │  FS      │                                                   │
│  └──────────┘                                                   │
└─────────────────────────────────────────────────────────────────┘

The key architectural insight is that compression happens before any model call. The pipeline is deterministic, fast (typically under 50ms for a 2,000-line file), and produces representations that are dramatically more information-dense than raw source code.

3. The Compression Pipeline

The compression pipeline consists of four stages, each targeting a different class of redundancy:

Stage 1: Structural Compression (AST Simplification)

Raw source code contains massive redundancy from a semantic perspective. Consider this TypeScript function:

// Original: 187 tokens
export async function processUserData(
  userId: string,
  options: ProcessOptions = {
    includeHistory: false,
    maxRecords: 100,
    timeout: 5000
  }: ProcessOptions
): Promise<UserDataResponse> {
  if (!userId) {
    throw new Error('User ID is required');
  }

  const user = await userService.findById(userId);
  if (!user) {
    throw new Error(`User not found: ${userId}`);
  }

  const records = await recordService.getRecent(userId, options.maxRecords);

  return {
    id: user.id,
    name: user.name,
    email: user.email,
    records: records.map(r => ({
      id: r.id,
      timestamp: r.timestamp,
      value: r.value
    })),
    processedAt: new Date().toISOString()
  };
}

The AST-based compressor transforms this into a semantic skeleton:

// Compressed: 42 tokens
fn processUserData(userId: string, options?: ProcessOptions) -> UserDataResponse
  deps: userService.findById, recordService.getRecent
  throws: Error(userId required), Error(user not found)
  returns: {id, name, email, records[{id,timestamp,value}], processedAt}
  defaults: includeHistory=false, maxRecords=100, timeout=5000

This preserves every piece of information the model actually needs — the function signature, its dependencies, error conditions, return shape, and default values — while eliminating formatting, boilerplate, and implementation details that are irrelevant for understanding the code's interface.

Stage 2: Dependency Graph Compression

Rather than including full source files for every imported module, the architecture maintains a compressed dependency graph. Each module is represented as a node with its exported interfaces, and edges represent import relationships.

{
  "module": "src/services/userService.ts",
  "exports": [
    {
      "name": "findById",
      "signature": "(id: string) => Promise<User | null>",
      "sideEffects": ["db.query"]
    },
    {
      "name": "createUser",
      "signature": "(data: CreateUserInput) => Promise<User>",
      "sideEffects": ["db.insert", "eventBus.emit"]
    }
  ],
  "imports": ["src/models/User.ts", "src/db/connection.ts"],
  "tokenCountOriginal": 890,
  "tokenCountCompressed": 95
}

When the model needs to understand how processUserData works, it sees the compressed signatures of userService and recordService — not their full implementations. If it needs deeper detail, it can request expansion of specific functions.

Stage 3: Conversation History Compression

Multi-turn coding conversations accumulate enormous context. The architecture applies progressive summarization to earlier turns:

// Turn 1-3 (raw): ~3,200 tokens
User: Can you refactor the auth module to use JWT instead of sessions?
Agent: I'll start by examining the current auth implementation...
[agent reads 3 files, proposes changes, applies patches]

// After compression: ~340 tokens
[Turns 1-3 Summary] Refactored auth from session-based to JWT.
Modified: auth/middleware.ts (JWT validation), auth/routes.ts (token extraction),
auth/models.ts (added TokenPayload interface). Removed: sessionStore.ts.
Key decision: Using HS256 with 24h expiry, refresh tokens in httpOnly cookies.

The compression preserves decisions, file modifications, and architectural choices — the things a model needs to maintain consistency across turns — while discarding exploratory reasoning, intermediate states, and verbose explanations.

Stage 4: Output Token Budgeting

This is the most architecturally significant innovation. Rather than letting the model generate freely, the system allocates a token budget across different components of the response:

{
  "totalBudget": 4096,
  "allocation": {
    "reasoning": 512,
    "code": 2560,
    "explanation": 768,
    "metadata": 256
  }
}

The model is instructed to stay within these bounds, and the runtime enforces truncation or regeneration if any section exceeds its allocation. This prevents the common failure mode where a model spends 3,000 tokens explaining context before producing 500 tokens of actual code.

4. AST-Based Code Compression

The core of the compression engine is a language-aware AST parser that transforms source code into a compact semantic representation. Let's look at how this works in practice.

The Compression Algorithm

# Simplified representation of the compression pipeline
from dataclasses import dataclass
from typing import Literal

@dataclass
class CompressedFunction:
    name: str
    params: list[tuple[str, str]]  # (name, type)
    return_type: str
    dependencies: list[str]        # external calls
    side_effects: list[str]       # mutations, I/O
    errors: list[str]             # thrown errors
    complexity: Literal["trivial", "moderate", "complex"]

    def to_prompt_tokens(self) -> str:
        """Serialize to minimal token representation."""
        params_str = ", ".join(f"{n}: {t}" for n, t in self.params)
        parts = [f"fn {self.name}({params_str}) -> {self.return_type}"]
        if self.dependencies:
            parts.append(f"  calls: {', '.join(self.dependencies)}")
        if self.side_effects:
            parts.append(f"  mutates: {', '.join(self.side_effects)}")
        if self.errors:
            parts.append(f"  throws: {', '.join(self.errors)}")
        parts.append(f"  complexity: {self.complexity}")
        return "\n".join(parts)


def compress_file(source: str, language: str, budget: int) -> str:
    """
    Compress a source file to fit within token budget.

    Strategy: lossless for public interfaces, lossy for internals.
    Priority order: exported > used-by-current-task > private > unused
    """
    ast = parse_ast(source, language)

    # Phase 1: Extract all symbols with metadata
    symbols = extract_symbols(ast)

    # Phase 2: Score each symbol by relevance
    for sym in symbols:
        sym.score = compute_relevance(sym, current_task_context)

    # Phase 3: Greedy selection within budget
    symbols.sort(key=lambda s: s.score, reverse=True)
    selected = []
    used_tokens = 0
    for sym in symbols:
        cost = estimate_tokens(sym.to_prompt_tokens())
        if used_tokens + cost <= budget:
            selected.append(sym)
            used_tokens += cost

    # Phase 4: If under budget, expand top-scoring symbols
    remaining = budget - used_tokens
    for sym in selected:
        if remaining <= 0:
            break
        expanded_cost = estimate_tokens(sym.to_full_source())
        if expanded_cost <= remaining:
            sym.expanded = True
            remaining -= expanded_cost

    return serialize(selected)

The key insight is adaptive compression: different parts of the codebase get different compression ratios based on their relevance to the current task. A function the model is about to modify gets near-full fidelity. A dependency it merely calls gets a signature-only representation. Unrelated code in the same file might be omitted entirely.

Language-Specific Compression Profiles

Different languages have different redundancy patterns. The compressor uses language-specific rules:

Language	Primary Redundancy	Compression Strategy	Typical Ratio
TypeScript/JavaScript	Type annotations, JSDoc, verbose object literals	Strip types for internal, keep for exports	4-6x
Python	Docstrings, type hints, decorator boilerplate	Preserve signatures, compress bodies	3-5x
Go	Error checking patterns, context propagation	Collapse error guards to `throws:` lists	5-8x
Rust	Trait bounds, lifetimes, boilerplate impl blocks	Abstract trait impls to capability lists	6-10x
Java	Getters/setters, annotations, imports	Collapse CRUD, strip annotations	8-12x

5. Semantic Chunking and Relevance Scoring

Traditional RAG systems use fixed-size chunks (typically 512-1024 tokens) with overlap. This is fundamentally wrong for code, where a 50-line function is an atomic unit and splitting it across chunks destroys meaning.

The token-first architecture uses semantic chunking based on AST boundaries:

def semantic_chunk(ast: AST, target_tokens: int) -> list[Chunk]:
    """
    Split code into semantically coherent chunks.
    Never splits across function/class boundaries.
    Groups related symbols into single chunks.
    """
    nodes = ast.body  # top-level declarations
    chunks = []
    current_chunk = Chunk()

    for node in nodes:
        node_tokens = estimate_tokens(node)

        # Check if adding this node would exceed budget
        if current_chunk.token_count + node_tokens > target_tokens:
            if current_chunk.nodes:
                chunks.append(current_chunk)
                current_chunk = Chunk()

        # Special handling for large classes
        if isinstance(node, ClassNode) and node_tokens > target_tokens:
            chunks.append(chunk_large_class(node, target_tokens))
            continue

        current_chunk.add(node)

    if current_chunk.nodes:
        chunks.append(current_chunk)

    # Merge adjacent small chunks (avoid fragmentation)
    chunks = merge_small_chunks(chunks, min_tokens=target_tokens // 3)

    return chunks

Relevance Scoring

Each chunk receives a relevance score based on multiple signals:

def compute_relevance(chunk: Chunk, query: str, context: TaskContext) -> float:
    """
    Multi-signal relevance scoring for context selection.
    Returns float in [0.0, 1.0].
    """
    signals = {}

    # Signal 1: Direct symbol match (highest weight)
    if any(sym in query for sym in chunk.exported_symbols):
        signals['direct_match'] = 0.9

    # Signal 2: Import graph proximity
    distance = shortest_import_path(chunk.module, context.target_module)
    signals['import_proximity'] = max(0, 1.0 - distance * 0.3)

    # Signal 3: Embedding similarity (semantic)
    signals['semantic'] = cosine_similarity(
        embed(chunk.compressed_repr),
        embed(query)
    )

    # Signal 4: Recent modification (temporal relevance)
    if chunk.last_modified_hours < 24:
        signals['recency'] = 0.3

    # Signal 5: Git blame overlap with modified files
    if chunk.file in context.modified_files:
        signals['modified'] = 0.7

    # Weighted combination
    weights = {
        'direct_match': 0.30,
        'import_proximity': 0.25,
        'semantic': 0.20,
        'recency': 0.10,
        'modified': 0.15
    }

    score = sum(signals.get(k, 0) * w for k, w in weights.items())
    return min(1.0, score)

This multi-signal approach is dramatically more accurate than pure vector similarity for code. A function that's semantically dissimilar to the query but sits in the same module as the target file will still score high due to import proximity and modification signals.

6. The Honesty Problem and How Compression Solves It

Here's where the architecture gets philosophically interesting. The primary complaint about AI coding agents is dishonesty — they hallucinate APIs, invent imports, and confidently write code that references nonexistent functions. The token-first architecture addresses this through grounded compression.

The Hallucination Cascade

Traditional agents hallucinate because of context dilution. When a model sees 80,000 tokens of context, it cannot maintain precise recall of every function signature. Under pressure to produce output, it fills gaps with plausible-sounding hallucinations:

# Model hallucination example (traditional agent)
from myapp.utils import parse_config  # DOES NOT EXIST
result = process_data(config)          # process_data doesn't accept config param

How Compression Prevents Hallucination

The compressed context is exhaustive for interfaces. Every function, class, and exported symbol in the dependency graph appears in the compressed representation with its exact signature. There is no gap for the model to hallucinate into.

# What the model actually sees (compressed but complete):

Available functions in scope:
  fn parseConfig(path: string) -> AppConfig  [src/config/parser.ts]
  fn loadEnv(file?: string) -> Record<string,string>  [src/config/env.ts]
  fn process_data(input: InputData, opts?: ProcessOpts) -> Output  [src/core/engine.ts]

  NOTE: These are ALL exported functions in the dependency graph.
  If you need a function not listed here, it does not exist.

The architecture explicitly tells the model: this is the complete set of available functions. There is no implicit knowledge, no retrieval gap. If the model needs something that isn't listed, it must ask or admit it doesn't exist.

The Honesty Contract

The system prompt includes an explicit honesty contract:

HONESTY CONTRACT:
1. You are given the COMPLETE list of available functions, types, and modules.
2. If you need something not in this list, state: "Not available in current context"
3. Never invent function names, parameters, or import paths.
4. If uncertain whether something exists, request clarification.
5. Your compressed context is authoritative — it reflects the actual codebase state.

This combination of exhaustive compressed interfaces plus explicit honesty instructions dramatically reduces hallucination. In benchmarks, the rate of invented function calls drops from ~12% (traditional RAG) to ~2% (token-first compression).

7. Token Budget Management

The token budget allocator is the central control mechanism that balances cost, quality, and completeness. It operates as a real-time optimization problem:

class TokenBudgetAllocator:
    def __init__(self, model_max_context: int, cost_per_token: float, budget_limit: float):
        self.max_context = model_max_context
        self.cost_per_token = cost_per_token
        self.budget_limit = budget_limit

        # Fixed allocations
        self.system_prompt_tokens = 2048
        self.safety_margin = 512  # room for model reasoning

        # Dynamic allocation (the interesting part)
        self.available = model_max_context - self.system_prompt_tokens - self.safety_margin

    def allocate(self, components: list[ContextComponent]) -> dict[str, int]:
        """
        Distribute available tokens across context components
        using utility-maximizing allocation.
        """
        # Score each component by utility density (info per token)
        for comp in components:
            comp.utility_density = comp.expected_usefulness / comp.token_cost
            comp.compressed_cost = comp.token_cost / comp.compression_ratio

        # Greedy allocation by utility density
        components.sort(key=lambda c: c.utility_density, reverse=True)

        allocation = {}
        remaining = self.available

        for comp in components:
            # Allocate compressed version first
            comp_allocation = min(comp.compressed_cost, remaining)
            allocation[comp.name] = int(comp_allocation)
            remaining -= comp_allocation

            if remaining <= 0:
                break

        # Validate against cost budget
        total_cost = sum(
            allocation[c.name] * c.cost_per_token
            for c in components
        )
        if total_cost > self.budget_limit:
            # Scale down proportionally, preserving highest-utility components
            scale = self.budget_limit / total_cost
            for comp in components:
                allocation[comp.name] = int(allocation[comp.name] * scale)

        return allocation

Budget Distribution Strategy

The allocator uses a tiered priority system:

Tier	Component	Allocation Priority	Compression Level
0	Current task description	Always full	None (raw)
1	Modified files (this session)	High	Light (2-3x)
2	Direct dependencies	Medium-High	Moderate (4-6x)
3	Indirect dependencies	Medium	Heavy (6-10x)
4	Conversation summary	Medium	Progressive (varies)
5	Project config / conventions	Low	Maximum (10-15x)
6	Documentation / README	Low	Maximum or omit

8. Implementation Deep Dive

Let's walk through a concrete implementation of the compression pipeline for a TypeScript project.

Setting Up the AST Parser

// src/compression/ast-parser.ts
import { parse, Node, FunctionDeclaration, ClassDeclaration, ExportStatement } from 'typescript';

export interface CompressedSymbol {
  name: string;
  kind: 'function' | 'class' | 'interface' | 'const' | 'enum';
  signature: string;
  dependencies: string[];
  isExported: boolean;
  tokenCostOriginal: number;
  tokenCostCompressed: number;
}

export function extractSymbols(source: string, fileName: string): CompressedSymbol[] {
  const sf = parse(source, { fileName });
  const symbols: CompressedSymbol[] = [];

  sf.forEachChild(node => {
    if (isExportStatement(node)) {
      node.forEachChild(inner => handleExported(inner, symbols));
    } else if (isFunctionDeclaration(node) || isClassDeclaration(node)) {
      handleExported(node, symbols);
    } else if (isVariableStatement(node)) {
      // Check if it's an exported const
      if (hasModifier(node, 'export')) {
        handleExported(node, symbols);
      }
    }
  });

  return symbols;
}

function handleExported(
  node: Node,
  symbols: CompressedSymbol[]
): void {
  if (isFunctionDeclaration(node)) {
    const fn = node as FunctionDeclaration;
    const params = fn.parameters?.map(p => 
      `${p.name.getText()}: ${p.type?.getText() || 'any'}`
    ) || [];
    const returnType = fn.type?.getText() || 'void';

    // Extract called functions
    const deps = extractCalledFunctions(fn.body);

    symbols.push({
      name: fn.name.getText(),
      kind: 'function',
      signature: `${fn.name.getText()}(${params.join(', ')}) -> ${returnType}`,
      dependencies: deps,
      isExported: true,
      tokenCostOriginal: countTokens(fn.getText()),
      tokenCostCompressed: countTokens(formatCompressedSymbol(symbols[symbols.length - 1]))
    });
  }
  // ... handle classes, interfaces, etc.
}

function extractCalledFunctions(body: Node): string[] {
  const called = new Set<string>();

  function visit(node: Node) {
    if (isCallExpression(node)) {
      const expr = node.expression;
      if (isIdentifier(expr)) {
        called.add(expr.text);
      } else if (isPropertyAccessExpression(expr)) {
        called.add(expr.getText());
      }
    }
    node.forEachChild(visit);
  }

  visit(body);
  return [...called];
}

The Compression Engine

// src/compression/engine.ts
import { extractSymbols, CompressedSymbol } from './ast-parser';
import { estimateTokenCount } from './tokenizer';

export interface CompressionResult {
  compressed: string;
  originalTokens: number;
  compressedTokens: number;
  ratio: number;
  symbolsIncluded: number;
  symbolsOmitted: number;
}

export class CompressionEngine {
  private compressionProfile: CompressionProfile;

  constructor(profile: CompressionProfile) {
    this.compressionProfile = profile;
  }

  compress(
    source: string,
    options: {
      budget: number;
      focusSymbols?: string[];
      includeDependencies?: boolean;
    }
  ): CompressionResult {
    const symbols = extractSymbols(source, options.fileName || 'unknown');
    const originalTokens = estimateTokenCount(source);

    // Score symbols by relevance
    const scored = symbols.map(sym => ({
      symbol: sym,
      score: this.scoreSymbol(sym, options.focusSymbols || [])
    }));

    // Sort by score, then greedily allocate budget
    scored.sort((a, b) => b.score - a.score);

    const included: CompressedSymbol[] = [];
    let usedTokens = 0;

    for (const { symbol } of scored) {
      const compressed = this.formatSymbol(symbol);
      const cost = estimateTokenCount(compressed);

      if (usedTokens + cost <= options.budget) {
        included.push(symbol);
        usedTokens += cost;
      }
    }

    // Build output
    const compressed = included.map(s => this.formatSymbol(s)).join('\n');
    const compressedTokens = estimateTokenCount(compressed);

    return {
      compressed,
      originalTokens,
      compressedTokens,
      ratio: originalTokens / compressedTokens,
      symbolsIncluded: included.length,
      symbolsOmitted: symbols.length - included.length
    };
  }

  private scoreSymbol(sym: CompressedSymbol, focus: string[]): number {
    let score = 0;

    if (sym.isExported) score += 0.5;
    if (focus.includes(sym.name)) score += 1.0;
    if (sym.kind === 'function') score += 0.3;
    if (sym.kind === 'interface') score += 0.4;

    // Penalize huge symbols (likely complex internals)
    const complexityPenalty = Math.min(
      0.5,
      sym.tokenCostOriginal / 1000
    );
    score -= complexityPenalty;

    return score;
  }

  private formatSymbol(sym: CompressedSymbol): string {
    const prefix = sym.isExported ? 'export ' : '';
    let result = `${prefix}${sym.kind} ${sym.signature}`;

    if (sym.dependencies.length > 0) {
      result += `\n  // calls: ${sym.dependencies.join(', ')}`;
    }

    return result;
  }
}

Integration with the Agent Loop

// src/agent/context-builder.ts
import { CompressionEngine } from '../compression/engine';
import { TokenBudgetAllocator } from '../budget/allocator';

export class ContextBuilder {
  private compressor: CompressionEngine;
  private allocator: TokenBudgetAllocator;
  private dependencyGraph: DependencyGraph;

  async buildContext(
    task: string,
    modifiedFiles: string[],
    model: string
  ): Promise<AssembledContext> {
    const modelConfig = getModelConfig(model);

    // Step 1: Identify relevant modules via dependency graph
    const relevantModules = this.dependencyGraph.getTransitiveDependencies(
      modifiedFiles,
      { depth: 2 }
    );

    // Step 2: Allocate token budget across components
    const budget = this.allocator.allocate({
      task,
      modifiedFiles,
      relevantModules,
      totalBudget: modelConfig.maxContext - 2048 // reserve for system prompt
    });

    // Step 3: Compress each component within its allocation
    const compressed = await Promise.all(
      relevantModules.map(mod => {
        const source = this.readFile(mod.path);
        return this.compressor.compress(source, {
          budget: budget[mod.path] || 500,
          focusSymbols: this.extractFocusSymbols(task, mod.path)
        });
      })
    );

    // Step 4: Assemble final context
    return {
      systemPrompt: this.buildSystemPrompt(compressed),
      totalTokensUsed: compressed.reduce((sum, c) => sum + c.compressedTokens, 0),
      compressionRatio: this.computeOverallRatio(compressed),
      honestyGuarantees: this.generateHonestyContract(compressed)
    };
  }
}

9. Performance Benchmarks

The token-first architecture has been benchmarked across multiple coding tasks. Here are representative results:

Cost Comparison

Task	Traditional Agent (tokens)	Token-First (tokens)	Savings	Quality Delta
Understand 50-file module	78,400	9,200	88%	+3.2% accuracy
Refactor auth system	62,100	14,800	76%	+5.1% accuracy
Add new API endpoint	45,300	11,400	75%	+2.8% accuracy
Debug failing test	38,700	8,900	77%	+7.4% accuracy
Cross-module rename	91,200	18,600	79%	+4.6% accuracy

Hallucination Rates

Metric	Traditional RAG	Token-First
Invented function calls	12.3%	1.8%
Wrong import paths	8.7%	0.9%
Incorrect parameter types	15.1%	3.2%
Nonexistent method calls	9.4%	1.1%
Overall hallucination rate	11.4%	1.8%

Latency Impact

The compression pipeline adds minimal latency:

AST parsing: 5-15ms per file
Symbol extraction: 2-8ms per file
Relevance scoring: 1-3ms per module
Total pipeline overhead: 20-80ms for a typical task

This is negligible compared to the 2-30 second LLM inference time it enables by reducing input size.

10. When This Architecture Breaks

No architecture is universally superior. The token-first approach has specific failure modes:

1. Low-Level Debugging

When debugging a subtle off-by-one error or a race condition, the model needs to see the exact implementation, not a compressed summary. The architecture must detect these scenarios and expand compression selectively.

2. Novel Pattern Generation

If the task requires creating a pattern that doesn't exist in the codebase (e.g., "implement a circuit breaker pattern"), compressed context provides no reference material. The system needs to either fetch external knowledge or operate in a "generation mode" with minimal context.

3. Performance-Critical Code Review

For tasks like "optimize this for throughput," the model needs to reason about specific implementation details — loop structures, allocation patterns, cache behavior. Heavy compression loses these details.

4. Very Large Monorepos

The dependency graph grows superlinearly in monorepos with 10,000+ modules. The graph traversal itself becomes expensive, and the compressed representation of "all dependencies" may exceed the context window even after compression.

Mitigation Strategies

// Adaptive compression: detect when full fidelity is needed
function detectCompressionLevel(task: string, context: TaskContext): CompressionLevel {
  if (/(debug|race|off-by-one|deadlock|memory leak)/i.test(task)) {
    return 'minimal'; // Near-full source
  }
  if (/(refactor|rename|add endpoint|new feature)/i.test(task)) {
    return 'aggressive'; // Heavy compression OK
  }
  if (/(optimize|performance|throughput|latency)/i.test(task)) {
    return 'moderate'; // Keep implementation details
  }
  return 'standard'; // Default balanced compression
}

11. Building Your Own Token-First Agent

If you want to implement a token-first architecture for your own coding agent, here's the recommended build order:

Phase 1: Basic AST Compression (Week 1-2)

Implement AST parsing for your target language(s)
Build symbol extraction (functions, classes, interfaces)
Create signature-only compression (no budget management yet)
Verify that compressed representations are lossless for interfaces

Phase 2: Dependency Graph (Week 2-3)

Build import/export graph from your codebase
Implement transitive dependency resolution
Add import proximity scoring
Cache the graph (rebuild on file changes)

Phase 3: Budget Allocation (Week 3-4)

Implement token estimation (use tiktoken or equivalent)
Build the budget allocator with priority tiers
Add adaptive compression levels
Implement the honesty contract in your system prompt

Phase 4: Conversation Compression (Week 4-5)

Build progressive summarization for conversation history
Implement decision extraction from agent outputs
Add context window eviction policies
Test with multi-turn sessions (20+ turns)

Phase 5: Optimization (Ongoing)

Add embedding-based relevance scoring
Implement per-language compression profiles
Build evaluation harness for hallucination detection
Add compression quality monitoring in production

Minimal Working Example

// A minimal token-first agent in ~100 lines
import { parse } from 'typescript';
import OpenAI from 'openai';

const client = new OpenAI();

async function tokenFirstAgent(task: string, codebase: Map<string, string>) {
  // Step 1: Compress all files to signatures
  const compressed = new Map<string, string>();

  for (const [path, source] of codebase) {
    const sf = parse(source, { fileName: path });
    const symbols: string[] = [];

    sf.forEachChild(node => {
      const text = node.getText();
      // Keep only exported declarations' signatures
      if (text.startsWith('export ')) {
        // Truncate to first 200 chars (signature area)
        const signature = text.split('\n').slice(0, 5).join('\n');
        symbols.push(signature);
      }
    });

    compressed.set(path, symbols.join('\n'));
  }

  // Step 2: Build compressed context
  const context = [...compressed.entries()]
    .map(([path, sigs]) => `// ${path}\n${sigs}`)
    .join('\n\n');

  // Step 3: Call model with compressed context
  const response = await client.chat.completions.create({
    model: 'gpt-4',
    messages: [
      {
        role: 'system',
        content: `
You have access to the following codebase interfaces:

${context}

HONESTY RULES:
- These are the ONLY available functions/classes in scope
- If you need something not listed, say it's not available
- Never invent function names or import paths
- Request clarification if uncertain
        `.  rim()
      },
      { role: 'user', content: task }
    ]
  });

  return response.choices[0].message.content;
}

12. Frequently Asked Questions

How does this compare to simply using a larger context window model?

Larger context windows are necessary but not sufficient. Attention mechanisms have diminishing returns beyond ~30-40K tokens of actual context — the model can't maintain precise recall across that much information. Token-first compression achieves better accuracy within a smaller window than uncompressed context in a larger window. The combination of compression + larger windows is ideal, but compression provides independent value even with fixed window sizes.

What about languages without a standard AST parser?

The architecture works best with languages that have mature parsers (TypeScript, Python, Go, Rust, Java). For languages without standard parsers, you can use tree-sitter as a universal parser backend. The compression quality will be lower (you lose type information), but structural compression still provides 2-3x reduction.

Does this work with open-source models like Llama or CodeLlama?

Yes, and arguably more so. Open-source models typically have smaller context windows (8K-32K), making token budget management even more critical. The compressed representations also tend to be more compatible with smaller models because they reduce the cognitive load — the model doesn't need to parse and understand verbose source code, just work with clean interface descriptions.

How do I measure if compression is hurting quality?

Build an evaluation harness that compares outputs from compressed vs. uncompressed contexts on a held-out set of tasks. Key metrics: (1) Does the output compile? (2) Does it pass existing tests? (3) Does it reference only real functions? (4) Is the implementation semantically correct? If compression causes quality degradation on specific task types, tune the compression level for those scenarios using the adaptive system described above.

The token-first architecture represents a fundamental shift in how we think about AI coding agents. Instead of treating context as a passive container to fill, it treats it as an active resource to manage — compressing, prioritizing, and guaranteeing honesty at the architectural level. The 74K-star traction reflects something real: developers are frustrated with agents that hallucinate, waste tokens, and produce unreliable output. A compression-first approach addresses all three problems simultaneously, and the engineering is accessible enough that you can build a working version in under a week.

For more technical deep-dives on AI architecture and developer tooling, explore Tamiz's Insights.

Google’s Project Suncatcher Reaches Orbit to Test Space-Based AI Compute

Ali Farhat — Fri, 02 Oct 2026 18:00:30 +0000

Google has moved Project Suncatcher from a research concept to an in-orbit hardware demonstration. The company’s first prototype satellite, built with satellite operator Planet, launched aboard SpaceX’s Transporter-18 rideshare mission, has established contact, and is operating as expected. The mission is an early but concrete test of whether machine-learning infrastructure could one day operate in space.

According to Google’s official Project Suncatcher update, the satellite will collect data over the coming weeks on how Google TPU hardware performs under radiation, thermal extremes, and microgravity. That makes the mission more than a standard satellite deployment. It is a practical experiment in placing specialized AI compute hardware in an environment far less forgiving than a terrestrial data center.

The project does not create a new cloud product or make space-based computing available to businesses today. Instead, it establishes a first in-orbit test for a long-term research effort. Google originally announced Project Suncatcher in November 2025 as a moonshot to explore solar-powered, laser-linked satellite constellations that could support distributed machine-learning workloads.

From research concept to in-orbit TPU test

Project Suncatcher is investigating a difficult premise: satellites above Earth could have access to abundant solar energy, while laser links between satellites could eventually move data and workloads across a constellation. The potential appeal is clear, but the engineering questions are substantial. AI accelerators must remain reliable despite radiation exposure, extreme temperature variation, and the physical conditions of orbit.

Google says the prototype will gather evidence on those questions and has published a peer-reviewed paper in Joule covering the mission research. Planet confirmed that it built and operates the satellite platforms used for the project, while Google is using the mission to test its TPU technology in space.

What the first satellite has demonstrated

The most important confirmed milestone is operational, not commercial. Google and Planet have put a Project Suncatcher prototype into orbit and established contact with it. That changes the project’s status from a proposed architecture to an active experiment with real hardware.

The mission is designed to examine several connected issues:

TPU resilience in orbit, including behavior under radiation, thermal extremes, and microgravity.
Satellite platform operations, supported by Planet’s role in building and operating the spacecraft platform.
Data collection from an in-orbit system, planned over the weeks following launch.
Future distributed-compute design, including the longer-term use of laser inter-satellite links.

Google’s stated roadmap includes two additional prototype satellites by early 2027, alongside continued work on system-scale experiments. Those future launches matter because a single spacecraft can test component behavior, while a networked system is needed to explore how workloads and communications could function across multiple satellites.

Project stage	Status	What it addresses
Original Project Suncatcher concept	Announced in November 2025	A solar-powered, laser-linked constellation for machine-learning compute
First prototype satellite	In orbit and operating as expected	How TPU hardware performs under space conditions
Further prototype milestones	Planned by early 2027	Additional testing and progress toward system-scale experiments

Why space-based AI compute is still a research problem

Space can offer a very different energy environment from Earth-based infrastructure, but power is only one part of AI computing. A useful compute system must also maintain hardware reliability, manage heat, communicate data effectively, and coordinate workloads. Project Suncatcher is at the stage of measuring those constraints rather than proving that satellite-based AI infrastructure is viable at scale.

Laser inter-satellite links are central to Google’s longer-term concept because distributed machine-learning workloads require systems to exchange information. However, the current announcement does not establish the performance, cost, latency, or commercial availability of such a network. It confirms that Google has begun collecting in-orbit evidence needed to assess the underlying technical premise.

What businesses should watch next

For companies that use AI services, Project Suncatcher is a signal about the direction of compute research rather than an immediate infrastructure decision. No organization should plan workloads around space-based TPUs based on this prototype. The near-term relevance is that major AI providers are investigating alternatives to conventional, Earth-bound data center expansion.

If the research progresses, the eventual questions for users could include where AI workloads run, how compute capacity is supplied, and which applications benefit from processing closer to satellite-generated data. Those outcomes remain unproven. The more immediate practical lesson is to distinguish between an in-orbit technology validation and a deployable business service.

Milestones worth monitoring

The next meaningful updates are likely to clarify whether the project can move from testing individual hardware behavior toward operating connected infrastructure. Businesses and technology teams should watch for:

Results from the prototype’s planned in-orbit data collection.
The launch and operation of the two further prototypes targeted by early 2027.
Evidence of laser inter-satellite link testing for distributed workloads.
Any Google announcements about how the research could relate to broader AI infrastructure.

For firms working with remote sensing, satellite data, or AI-intensive applications, the project is particularly relevant as a longer-term indicator. Processing data in or near the environment where it is collected could become an important design question if this class of infrastructure matures. For most businesses, however, the appropriate response today is to track verified progress rather than assume new cost, latency, or capacity advantages.

As AI infrastructure options evolve, businesses need a clear view of which developments can improve operations now and which are still research milestones. Scalevise helps teams assess practical AI opportunities, prioritize high-value use cases, and build a roadmap that fits their existing processes. Our AI consultancy services turn emerging technology into grounded implementation decisions, so you can focus investment where it has a realistic business impact. Request an AI consultation.

Frequently Asked Questions

What is Google Project Suncatcher?

Project Suncatcher is Google’s long-term research project exploring whether machine-learning compute infrastructure could operate in space using satellites, solar power, and eventually laser inter-satellite links.

What has Google launched for Project Suncatcher?

Google launched a prototype satellite built in partnership with Planet aboard SpaceX’s Transporter-18 rideshare mission. Google says the satellite established contact and is operating as expected.

What is the satellite testing?

The mission will collect data on how Google TPU hardware performs under radiation, thermal extremes, and microgravity in orbit.

Will businesses be able to use space-based Google AI compute now?

No. The mission is an in-orbit research demonstration, not a commercial cloud service or publicly available compute offering.

What happens next for Project Suncatcher?

Google plans two additional prototype satellites by early 2027 and continues to explore laser inter-satellite links and system-scale experiments.

Conclusion

Project Suncatcher’s first operational satellite gives Google a real-world testbed for space-based AI compute. The mission does not yet prove a commercially viable alternative to terrestrial data centers, but it begins gathering the hardware and operational evidence needed to evaluate that possibility. The next prototypes and their results will show whether the concept can advance from component testing toward connected machine-learning infrastructure.

DEV Community: ai

7 Benefits of AI-Assisted Programming for Teams in 2026

AI-assisted programming is rewriting productivity math in 2026

Code quality isn’t subjective—AI makes it measurable and repeatable

AI-driven documentation is finally not a joke (and devs secretly love it)

Tool cost is transparent—AI is now a line-item, not a luxury

Team learning curves flatten—AI is forcing upskilling on everyone

Cross-language development is now practical, not just possible

FAQ

You can’t opt out of this shift

Google Unveils Gemini 4 Argon With 1 Million Token Context and Cybersecurity Focus

What Gemini 4 Argon changes

A 1 million token context window for longer workflows

A stated focus on coding, knowledge work, security, and multimodal tasks

Pricing and access are more concrete than a typical teaser

Security capabilities come with deployment limits

Frequently Asked Questions

Conclusion

Building a Foundry Agent That Queries Fabric Data, On Behalf of the User

The mental model

Prerequisites

Step 1: Publish the Fabric data agent

Step 2: Create the connection in Foundry

Step 3: Wire the Fabric tool into a Foundry agent

Step 4: Run it, and run it as two different users

Where this fits in the bigger picture

Production considerations

Where this leaves you

References

Luthier: an agent that audits an AI coding agent's harness against the repo it governs.

Your agent's CLAUDE.md is lying to it, and nothing is checking

The idea in one paragraph

The architecture that keeps it honest

The five checks, and what each one actually proves

1. path_exists

2. command_runs — declared, never executed

3. file_referenced — skills go both ways

4. server_reachable — schema plus binary, no spawning

5. semantic — and unknown as a real answer

Scoring you can defend

The two bugs that actually taught me something

Precision: the audit of the audit

Verification

What it's for

How to Handle Edge Cases in TTS Applications

Common Edge Cases in TTS

1. Non‑Standard Punctuation & Symbols

Problem

Solution

2. Acronyms & Initialisms

Problem

Solution

3. Numbers & Dates

Problem

Solution

4. Non‑English Content

Problem

Solution

5. Custom Voice Cloning

Problem

Solution

6. Emotion & Prosody Control

Problem

Solution

7. Handling User‑Generated Content

Problem

Solution

8. Testing & QA

Automated Unit Tests

End‑to‑End Pipeline

9. Deployment Considerations

10. Wrap‑Up

Next Steps

OpenCoach: a Sanity Context agent that reconciles outdated docs with live code

What I Built

Demo

Code

How I Used Sanity

Sanity Project Details

AI Agency Framework: AI’s Effect on Society, Jobs, Tools, and Culture

Your agent's `CLAUDE.md` is lying to it, and nothing is checking

1. `path_exists`

2. `command_runs` — declared, never executed

3. `file_referenced` — skills go both ways

4. `server_reachable` — schema plus binary, no spawning

5. `semantic` — and `unknown` as a real answer