dev.to top (week)

Dev Opportunity Radar #11: Claude Community Ambassadors, YC Startup Internship Expo, Z Fellows, and Stanford's AI Agents Course

Hemapriya Kanagala — Fri, 07 Aug 2026 15:52:30 GMT

TL;DR

Welcome back to Dev Opportunity Radar.

This is a weekly series where I share opportunities, resources, communities, and interesting finds that I come across, with the goal of helping people discover things they might otherwise miss.

This week's edition features the Claude Community Ambassadors Program, the YC Startup Internship Expo, Z Fellows, and CS329A: Self-Improving AI Agents, a free graduate-level Stanford course exploring the latest research behind modern AI agents.

If you're new to the series, you can also browse previous editions, search past opportunities, and explore Community Finds, Reader Updates, and Resources Worth Checking Out on the Dev Opportunity Radar website. I've also written a short post about why I built it. You'll find links to both at the end of this article.

This week's 🌟 Community Finds section features opportunities shared by Francis (@francistrdev) and Konark Sharma (@konark_13). I always love seeing readers help others discover opportunities they might otherwise have missed.

If you've discovered something through the radar, I'd love to hear about it. Whether you applied to an opportunity, attended an event, joined a community, completed a program, built something, or found a resource you hadn't seen before, I'd be happy to feature your experience in a future 💙 Reader Updates section (with your permission).

And if you've come across an opportunity, resource, community, program, event, or anything else you think deserves more attention, feel free to share it in the comments.

If I feature one of your 🌟 Community Finds in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you.

⚡ Quick Scan

Opportunities

Opportunity	Organization	Type	Format	Deadline
Claude Community Ambassadors	Anthropic	Community Ambassador Program	Hybrid (Local Events)	Rolling
YC Startup Internship Expo	Y Combinator	Startup Career Expo	In Person (San Francisco)	August 15 (Event)
Z Fellows	Z Fellows	Founder Fellowship	Hybrid	Rolling

Resource Highlight

Resource	Why Check It Out
CS329A: Self-Improving AI Agents	A free graduate-level Stanford course covering modern AI agent research, including constitutional AI, tool use, planning, reinforcement learning, memory, and evaluation frameworks.

Community Finds

Shared By	Find	Type	Format
Francis (@francistrdev)	CALEC Volunteer & Internship Opportunities	Volunteer & Internship Opportunities	Remote
Konark Sharma (@konark_13)	JPMorganChase Code for Good Singapore & Software Engineer Program	Hackathon & Internship	In Person (Singapore)

📝 A quick note: I spend a lot of time researching and verifying every opportunity before featuring it in Dev Opportunity Radar. However, deadlines, eligibility, program details, and application requirements can change after publication. Before applying, please take a few minutes to visit the official program page, review the latest information, and confirm that you're eligible.

🔄 Still Open From Previous Editions

Before we get into this week's opportunities, here are a few from previous editions that are still accepting applications.

I've already covered these in detail, so I won't repeat everything here. If any of them catch your attention, you can find the full overview, eligibility details, and application links in the original edition.

Opportunity	Organization	Type	Format	Deadline	Featured In
FR8	FR8	Builder Residency	In Person	Rolling	Edition #2
Anthropic Fellows Program	Anthropic	AI Research Fellowship	In Person	Rolling	Edition #4
Sentient Open Source AGI Grant Program	Sentient Foundation	AI Grant & Investment	Remote	Rolling	Edition #6
Solo Grants	Solo Grants	Microgrant for Solo Builders	Remote	Rolling	Edition #7
Claude for Open Source	Anthropic	Open Source Program	Remote	Rolling	Edition #7
AIAF Fellowship 2026	AIAF × AE Studio	AI Research Fellowship	Remote	August 17	Edition #8
The Bridge	Entrepreneurs First	Founder Residency	In Person	August 30	Edition #9
Develop for Good Winter 2027	Develop for Good	Student Volunteer Program	Remote	August 31	Edition #10
OpenAI Student Collective	OpenAI	Campus Leadership Program	In Person (Campus-Based)	August 10	Edition #10

📍 This Week's Opportunities

Here are a few opportunities I came across this week that I thought were worth sharing.

📌 Claude Community Ambassadors

Who it's for: Developers, community organizers, meetup hosts, technical educators, and active Claude users who enjoy bringing people together and helping others learn. You don't need to be a professional developer, but you should have meaningful experience using Claude and a track record of community involvement.

What stands out: The Claude Community Ambassadors program gives community builders the opportunity to grow local Claude communities with support from Anthropic. Ambassadors can host meetups, workshops, hackathons, and other community events while receiving event funding, monthly API credits, ready-to-use event materials, swag, and promotion through Anthropic's channels.

I wanted to include this because most ambassador programs are focused on students. This one is different. It's designed for people who are already active in their local tech communities or online communities and want to help others explore Claude while building a stronger local developer ecosystem.

Another thing I like is that the program goes beyond hosting events. Ambassadors get early access to selected features, opportunities to participate in Builders Council sessions, and a direct way to share feedback from their communities with Anthropic's product teams. If you enjoy teaching, organizing events, or building developer communities, this could be a great opportunity to make an impact while connecting with other community leaders around the world.

Program Duration: Ongoing

Cost: Free

Benefits: Event sponsorship, monthly Claude API credits, exclusive swag, access to a private Ambassador Slack, pre-release features, and opportunities to provide product feedback.

Who can apply: Community builders and experienced Claude users from anywhere in the world. Professional developer experience is not required.

Application Deadline: Rolling

🔗 Learn More | 🔗 Apply

📌 YC Startup Internship Expo

Who it's for: Students looking for internships, co-ops, semester internships, or new graduate roles who will be in the San Francisco Bay Area on August 15. YC is also encouraging applications from exceptional high school builders.

What stands out: The YC Startup Internship Expo is a one-day, acceptance-only event where students can meet founders, engineers, and hiring teams from 50+ Y Combinator startups. Rather than browsing job boards, attendees get the chance to explore what it's actually like to work at early-stage AI startups, participate in coding and AI challenges, network with startup teams, and even interview onsite with more than 40 YC companies.

I wanted to include this because opportunities like this don't come around very often. Instead of applying online and hoping someone sees your resume, you get to meet founders and engineers face-to-face, ask questions, and learn how some of today's fastest-growing AI startups actually build products.

Another thing I like is that it's more than just a career fair. Alongside the startup expo, there will be coding and AI challenges, giveaways, food trucks, and onsite interviews happening throughout the day. If you're already spending the summer in San Francisco or studying in the Bay Area, this could be a great opportunity to explore internships while connecting with people building at the forefront of AI.

Event Date: August 15, 2026

Location: San Francisco, California

Cost: Free (application required)

Who can apply: Students interning in San Francisco, students attending Bay Area colleges or universities, and exceptional high school builders who will be in the Bay Area on the event date.

Application Process: Acceptance only

Travel Support: No travel sponsorship is provided.

🔗 Learn More & Apply

📌 Z Fellows

Who it's for: Technical builders, aspiring founders, students, recent graduates, researchers, engineers, and anyone working on a side project or startup. You can apply solo or with a team, and you don't need to have a company yet.

What stands out: Z Fellows is a one-week founder program that brings together a small group of ambitious builders with founders and investors behind companies like Figma, Vercel, Instacart, Netflix, DoorDash, and AngelList. The week is designed to help early builders learn from experienced founders, connect with other ambitious people, and accelerate whatever they're working on. The support doesn't stop after the program. Z Fellows continues helping founders throughout their journey.

I wanted to include this because most startup programs expect you to already have a company, traction, or funding. Z Fellows takes a different approach. It's built for people who are still early and simply have the ambition to build something meaningful. Whether you're working on a side project, exploring an idea, or already building a startup, the focus is on backing people with potential before everyone else notices them.

Another thing I like is how flexible the program is. You don't need to quit your job, leave school, or even have a co-founder to apply. The program is mostly virtual, with the final day taking place in San Francisco or New York City, making it accessible to builders from around the world. Applicants can also choose to participate without funding or accept an optional $10,000 investment through a SAFE agreement if it makes sense for their company.

Program Duration: One week (multiple cohorts each year)

Format: Mostly virtual, with the final day held in San Francisco or New York City

Funding: Optional $10,000 investment through a SAFE agreement

Who can apply: Builders from anywhere in the world. No age restrictions. You can apply as an individual or as a team, and you don't need a company to get started.

Application Deadline: Rolling

🔗 Learn More | 🔗 Apply

📚 Resources Worth Checking Out

Not every useful find comes with an application deadline.

Here's one resource worth checking out this week.

CS329A: Self-Improving AI Agents

Who it's for: Developers, AI engineers, researchers, graduate students, and anyone who already has a basic understanding of large language models and wants to dive deeper into modern AI agent research.

What stands out: CS329A: Self-Improving AI Agents is a graduate-level course from Stanford University that explores how AI agents can continuously improve through interaction with themselves and their environment. The lecture recordings cover many of the ideas shaping today's AI landscape, including constitutional AI, reinforcement learning, test-time scaling, tool use, memory, planning, multimodal agents, and evaluation frameworks for agentic systems.

I wanted to include this because there's a lot of discussion about AI agents right now, but it can be difficult to separate hype from the underlying concepts. This course is taught by researchers working in the field and provides a structured way to understand many of the techniques behind modern agent systems.

Another thing I like is that the course doesn't focus on a single framework or API. Instead, it explores the research ideas that are driving the next generation of AI agents, making it a resource that's likely to stay useful even as tools continue to evolve.

Format: Free online lecture recordings

Level: Graduate / Advanced

Topics Covered: Self-improving LLMs, Constitutional AI, reinforcement learning, test-time scaling, tool use, memory, planning, multimodal agents, and AI evaluation.

🔗 Watch the Lecture Playlist

🌟 Community Finds

One of my favorite things about this series has been seeing people share opportunities, communities, and resources that others might not have discovered otherwise.

CALEC Volunteer and Internship Opportunities

Back in Edition #6, I featured CALEC's remote volunteer and internship opportunities after Francis (@francistrdev) shared them with the community. If you missed it, you can find the full overview and all the details in Edition #6.

Since sharing this opportunity with the community, Francis has also published a dedicated DEV post about the Full-Stack Developer volunteer role at CALEC. If that role interests you, it's worth checking out for his perspective and some additional information about what the team is looking for.

🔗 Francis' post

🔗 CALEC Volunteer & Internship Opportunities | 🔗 Edition #6

JPMorganChase Code for Good Singapore & Software Engineer Program

Shared by Konark Sharma (@konark_13).

Konark shared two opportunities from JPMorganChase that I thought would be worth passing along for students interested in software engineering.

The first is Code for Good Singapore, a two-day social impact hackathon where participants work alongside JPMorganChase engineers to build technology solutions for nonprofit organizations. Besides the experience itself, the event also serves as a pathway to the company's 2027 Early Careers Software Engineer Program in Singapore.

He also shared the 2027 Software Engineer Program - Summer Analyst (Singapore). Interns work on real software engineering projects, collaborate with experienced engineers, receive mentorship and training, and may be considered for a full-time graduate role based on their performance.

I thought these were worth featuring because they offer more than just a hackathon or an internship. Together, they provide a chance to gain hands-on experience, connect with engineers, and potentially open the door to future opportunities at one of the world's largest technology employers.

Who it's for: Students pursuing a bachelor's degree in computer science or a related field who are interested in software engineering opportunities in Singapore.

Application Deadlines:

Code for Good Singapore: September 18, 2026
Software Engineer Program - Summer Analyst (Singapore): October 29, 2026

🔗 Code for Good Singapore

🔗 Software Engineer Program - Summer Analyst (Singapore)

Thank you to Francis (@francistrdev) and Konark Sharma (@konark_13) for thinking of the radar and sharing these with the community. It really means a lot 💙

I'd love for this section to keep growing.

If you've come across an opportunity, fellowship, grant, hackathon, conference, community, resource, or anything else you think more people should know about, feel free to share it in the comments.

If I feature it in a future edition, I'll always make sure to credit you. If you discovered it, that recognition belongs to you.

One small request: If you're sharing an opportunity, please avoid posting raw URLs directly in the comments. DEV sometimes filters them before I get a chance to see them.

A short description alongside the link makes it much easier for me to review and potentially feature it in a future edition.

💙 Reader Updates

I'm looking forward to this section gradually growing over time, and I'd still love to hear from you.

One of my favorite parts of writing Dev Opportunity Radar has been hearing from people who discovered something they otherwise might have missed.

If you discovered an opportunity through the radar, applied to something, joined a community, attended an event, or simply found a resource you hadn't seen before, I'd genuinely love to hear about it.

You don't need to have been accepted or have a big success story to share. Sometimes simply discovering the right opportunity at the right time is already a win.

If you'd like to share an update, feel free to leave a comment on this edition. With your permission, I may feature it in a future 💙 Reader Updates section and tag you so other readers can celebrate your journey too.

I hope this section gradually becomes a place where we can celebrate those stories together, one update at a time.

👋 Until Next Friday

Before I go, I just want to say thank you.

Every week, I spend time searching for opportunities, resources, and communities that I think deserve a little more attention. But one of my favorite parts of this series isn't the research. It's seeing what happens after an edition is published.

Seeing someone discover an opportunity, apply to a program, share a resource, suggest a Community Find, or come back to tell us what they learned reminds me why I started Dev Opportunity Radar in the first place.

The goal has always been simple:

Help people discover opportunities they otherwise might have missed.

Thanks to all of you, it feels like we're doing exactly that.

Whether you've been reading since the very first edition or this is your first time here, thank you for being part of the journey. Every comment, suggestion, and shared opportunity helps make this series better than I could build on my own.

If you ever come across an opportunity, resource, event, community, or anything else you think deserves more attention, I'd love for you to share it in the comments. And if Dev Opportunity Radar helped you discover something exciting, I'd love to hear that too.

Thank you for reading, for sharing, and for helping make this our radar, not just mine.

I'll be back next Friday with more opportunities, resources, and Community Finds.

Until then, take care, and I hope you discover something amazing this week 💙

🌐 Dev Opportunity Radar Website

If this is your first time discovering the series, you can explore every edition, browse opportunities by category, discover Community Finds, and catch up on Reader Updates on the Dev Opportunity Radar website.

👉 Website

I also wrote a short post about why I built the website and the journey behind it.

👉 Website Launch Post

Enterprise MCP Gateway with Built-In Security: OAuth 2.0, RBAC, and Tool Access Control

Anthony Max — Wed, 05 Aug 2026 19:41:55 GMT

TL;DR

MCP servers are powerful, but they can provide access to production systems if anyone on the team can connect and run tools without guardrails.

Imagine a new hire testing the app on their laptop and accidentally granting an MCP server access to the production database. Without governance, that is a realistic path to data leakage.

Bifrost addresses this with three layers:

Human-in-the-loop execution — Bifrost does not auto-execute tool calls. The LLM only suggests tools; your application reviews them and explicitly calls POST /v1/mcp/tool/execute.
Deny-by-default tool filtering — A virtual key with no mcp_configs gets zero MCP tools. Unlisted clients are implicitly blocked.
Governance (optional) — RBAC, SSO, audit logs, and MCP Tool Groups control who can configure the gateway and review administrative activity.

Bifrost covers virtual keys, budgets, rate limits, routing, and MCP tool filtering, RBAC, SSO, audit logs, and MCP Tool.

🔧 Using MCP server

First, let's open the app and set up the MCP server. To do this, I'll enter the following line in the terminal:

npx -y @maximhq/bifrost

After that, you will see the following interface (similar, depending on the version):

Go to the "MCP Library" tab and you will see a huge list of pre-configured MCP servers that you can use in your projects.

If you want to set up your own MCP server, go to MCP Gateway and click New MCP Server:

Here you can specify the connection URL, auth type, tool allowlists, and other settings including Code Mode, which can significantly reduce token usage when orchestrating many MCP servers.

💎 Star Bifrost ☆

⚙️ Human-in-the-loop tool

This is the most important security property for the scenario in the introduction.

When an LLM returns tool calls, Bifrost does not automatically execute them. Tool calls are suggestions only. Your application must explicitly approve and execute each one:

1. POST /v1/chat/completions   → LLM returns tool call suggestions (NOT executed)
2. Your app reviews tool calls → Apply security rules, get user approval if needed
3. POST /v1/mcp/tool/execute   → Execute approved tool calls explicitly
4. POST /v1/chat/completions   → Continue the conversation with tool results

Example execution call:

curl -X POST http://localhost:8080/v1/mcp/tool/execute \
  -H "Content-Type: application/json" \
  -d '{
    "id": "call_xyz789",
    "type": "function",
    "function": {
      "name": "database_query",
      "arguments": "{\"sql\": \"SELECT 1\"}"
    }
  }'

So even if a new hire's agent requests a dangerous database operation, nothing happens until your application deliberately executes it. Combined with deny-by-default virtual key filtering (below), this is Bifrost's real three-layer answer to accidental production access.

You can opt into autonomous execution for specific tools via Agent Mode, but that must be explicitly configured, it is not the default.

💻 MCP authentication

Authentication is declared on the MCP client itself as a top-level auth_type field, posted to /api/mcp/client. There is no nested auth object.

`auth_type`	Who authenticates	When to use
`none`	—	Public MCP servers, local STDIO tools
`headers`	Admin, once	Shared API keys, bearer tokens, custom headers
`oauth`	Admin, once	Shared third-party service the whole team uses
`per_user_oauth`	Each end-user, lazily	Per-user services like Notion, GitHub, Sentry
`per_user_headers`	Each end-user, lazily	Per-user API keys, signed tokens

OAuth (oauth and per_user_oauth) is only valid for HTTP and SSE connections. Bifrost implements the Authorization Code flow, there is no client-credentials / service-account mode.

1. No auth (development only)

{
  "name": "local-tools",
  "connection_type": "stdio",
  "stdio_config": {
    "command": "npx",
    "args": ["-y", "@anthropic/mcp-filesystem"]
  },
  "auth_type": "none",
  "tools_to_execute": ["read_file", "list_directory"]
}

2. Static headers (shared API keys)

curl -X POST http://localhost:8080/api/mcp/client \
  -H "Content-Type: application/json" \
  -d '{
    "name": "web_search",
    "connection_type": "http",
    "connection_string": "https://mcp.example.com/mcp",
    "auth_type": "headers",
    "headers": {
      "Authorization": "Bearer your-api-key",
      "X-Tenant-ID": "acme-corp"
    },
    "tools_to_execute": ["*"]
  }'

3. Server-level OAuth (admin authorizes once)

The admin authenticates once during setup. Every subsequent request to that MCP server uses the same stored token, regardless of which caller hit Bifrost.

curl -X POST http://localhost:8080/api/mcp/client \
  -H "Content-Type: application/json" \
  -d '{
    "name": "authenticated_service",
    "connection_type": "http",
    "connection_string": "https://api.example.com/mcp",
    "auth_type": "oauth",
    "oauth_config": {
      "client_id": "your-client-id",
      "client_secret": "your-client-secret",
      "authorize_url": "https://auth.example.com/oauth/authorize",
      "token_url": "https://auth.example.com/oauth/token",
      "scopes": ["mcp:read", "mcp:write"]
    },
    "tools_to_execute": ["*"]
  }'

The oauth_config object accepts client_id, client_secret, authorize_url, token_url, scopes, or registration_url / server_url for Dynamic Client Registration. After the admin completes the authorize step, finalize with POST /api/mcp/client/{id}/complete-oauth.

4. Per-user OAuth (each user authenticates themselves)

Use auth_type: "per_user_oauth" when each end-user must connect under their own account. Bifrost stores one OAuth token per (identity, mcp_client) and reuses it on later calls. Identity is required via virtual key, signed-in SSO user, or x-bf-mcp-session-id.

5. Per-user headers (legacy / custom per-user keys)

curl -X POST http://localhost:8080/api/mcp/client \
  -H "Content-Type: application/json" \
  -d '{
    "name": "acme_api",
    "connection_type": "http",
    "connection_string": "https://api.acme.example.com/mcp",
    "auth_type": "per_user_headers",
    "per_user_header_keys": ["X-API-Key", "X-Tenant-ID"],
    "tools_to_execute": ["*"]
  }'

Identity matters: With auth_type: "oauth" or auth_type: "headers", all callers share the same upstream credential. Bifrost does not attach a per-user identity to MCP requests. To know exactly who performed an action upstream, use per_user_oauth or per_user_headers.

💻 Runtime tool access control (Virtual Keys)

RBAC does not govern which MCP tools an agent can invoke at runtime. That is controlled by virtual keys and three stacked levels of tool filtering:

Client config — tools_to_execute on each MCP client (baseline)
Request headers — x-bf-mcp-include-clients and x-bf-mcp-include-tools per request
Virtual key config — mcp_configs array (takes precedence over request headers)

Deny-by-default

This is built-in behavior, not a config setting: a virtual key with no mcp_configs gets zero MCP tools, and clients not listed in mcp_configs are implicitly blocked.

Virtual key configuration

curl -X POST http://localhost:8080/api/governance/virtual-keys \
  -H "Content-Type: application/json" \
  -d '{
    "name": "new-dev-key",
    "mcp_configs": [
      {
        "mcp_client_name": "internal_api",
        "tools_to_execute": ["search", "get_article"]
      },
      {
        "mcp_client_name": "staging_database",
        "tools_to_execute": ["query"]
      }
    ]
  }'

`tools_to_execute`	Result
`["*"]`	All tools from this client
`["a", "b"]`	Only specified tools
`[]`	No tools from this client
Client not in `mcp_configs`	All tools blocked from that client

This is where you enforce patterns like "backend devs can hit staging APIs but not production databases" by giving different virtual keys different mcp_configs, not by RBAC permission strings.

Per-request narrowing

For one-off restrictions within a virtual key's allowlist:

curl -X POST http://localhost:8080/v1/chat/completions \
  -H "Authorization: Bearer vk_new_dev" \
  -H "x-bf-mcp-include-tools: staging_database-query" \
  -d '...'

Note: when a virtual key has mcp_configs, it auto-generates x-bf-mcp-include-tools and overrides any manually sent header.

Bifrost does not parse SQL or block operations like DELETE / DROP at the query level. Restrict access by allowing only specific tool names (for example, a read-only query tool instead of an execute tool).

🔎 RBAC — administrative access

Bifrost provides Role-Based Access Control for the administrative surface who can edit MCP gateway configs, read logs, configure guardrails, manage virtual keys, and so on. RBAC is not runtime authorization for agents invoking MCP tools.

Permissions are Resource × Operation pairs, not permission strings like mcp:tool:invoke.

System roles

Role	Permissions	Description
Admin	42	Full access to all resources and operations
Developer	27	CRUD on technical resources, view access to logs and cluster
Viewer	14	Read-only access to all resources

You can also create custom roles (for example, an Auditor role with AuditLogs:View and Logs:View only).

Protected resources include

Logs, VirtualKeys, MCPGateway, MCPToolGroups, MCPLogs, GuardrailsConfig, AuditLogs, Cluster, and others.

Operations include

View, Create, Update, Delete, Download, Reveal, and inference operations.

Example: a custom Auditor role might grant AuditLogs:View and AuditLogs:Download, but not MCPGateway:Update. That controls who can configure the gateway in the dashboard, not which tools an agent executes at runtime.

Roles and permissions are managed via Governance → Roles & Permissions in the dashboard or the /api/roles endpoints:

curl -X GET http://localhost:8080/api/roles/{role_id}/permissions \
  -H "Authorization: Bearer <admin_token>"

🖥️ User Provisioning and role mapping

There is no role_sync config block. Role assignment comes from User Provisioning over OIDC, supported for Okta, Microsoft Entra and others.

When SSO is configured:

Users sign in with corporate credentials via OAuth 2.0 / OIDC (Authorization Code + PKCE)
Roles are mapped from IdP groups, app roles, or custom claims to Bifrost roles (Admin, Developer, Viewer, or custom roles)
Role and team assignments are synchronized on each session
Background reconciliation runs every 24 hours; OIDC session refresh checks run every 15 minutes
Inactive or deprovisioned users are decommissioned locally (including via inbound SCIM 2.0)

Configuration lives under scim_config in config.json. See the User Provisioning docs for provider-specific setup guides.

📋 Audit logs

Audit logs in Bifrost record administrative activity who changed what, when, and which resource was affected. They do not use a log_level / capture / export_to block.

Real configuration shape:

{
  "audit_logs": {
    "disabled": false,
    "hmac_key": "env.AUDIT_HMAC_KEY",
    "retention_days": 365,
    "object_storage": {
      "type": "s3",
      "bucket": "acme-audit-archive",
      "prefix": "acme-prod",
      "compress": true,
      "region": "us-east-1",
      "access_key_id": "env.AUDIT_S3_KEY",
      "secret_access_key": "env.AUDIT_S3_SECRET"
    }
  }
}

Key features:

Signed events — configure an HMAC key for verification
Dashboard review — filter by search text, action, outcome, and date range
Export — JSON, JSON Lines, or Syslog (requires AuditLogs:Download permission)
Retention — retention_days controls database retention
Object storage archival — optional mirror to S3/GCS for long-term compliance retention

View audit entries at Governance → Audit Logs in the dashboard.

✅ Implementation best practices

1. Rely on deny-by-default

Do not look for a "policy": "default_deny" setting. It does not exist. Instead:

Create virtual keys with explicit mcp_configs for each team or environment
Set client-level tools_to_execute to the minimum needed
Leave production database tools off keys used for local development

2. Keep human-in-the-loop as the default

Only enable Agent Mode auto-execution for tools you have explicitly reviewed. The default flow — chat → review → /v1/mcp/tool/execute — is your strongest safety net.

3. Separate runtime access from admin access

Runtime (what agents can do): virtual keys + mcp_configs + request headers
Administration (who can change configs): RBAC + SSO

4. Use environment-scoped virtual keys

{
  "name": "production-readonly",
  "mcp_configs": [
    { "mcp_client_name": "production_database", "tools_to_execute": ["query"] }
  ]
}

{
  "name": "staging-full",
  "mcp_configs": [
    { "mcp_client_name": "staging_database", "tools_to_execute": ["*"] }
  ]
}

5. Configure audit logging early

Enable HMAC signing, set retention_days comfortably above your archival window, and optionally mirror to object storage for compliance.

6. Perform regular access reviews

Schedule quarterly reviews to answer:

Which virtual keys grant access to production MCP clients?
Who has Admin or Developer RBAC roles in Enterprise?
Are there overprivileged virtual keys or dormant SSO accounts?

Use the dashboard and /api/roles endpoints, there is no bifrost audit CLI command. The @maximhq/bifrost-cli package is an interactive launcher for coding agents (Claude Code, Codex CLI, Gemini CLI, Opencode), not an audit tool.

🖋️ Conclusion

With Bifrost, you can configure your company's MCP server much more securely. This ready-made solution will save you not only money but also time, which can be spent on product development.

🔗 Resources:

Bifrost GitHub: https://github.com/maximhq/bifrost
Bifrost Docs: https://docs.getbifrost.ai
Bifrost CLI: npx -y @maximhq/bifrost-cli

Thanks for reading this article! ❤️

I'd love to hear your thoughts on this mode in the comments!

Welcome Thread - v387

Sloan the DEV Moderator — Wed, 05 Aug 2026 13:00:00 GMT

Leave a comment below to introduce yourself! You can talk about what brought you here, what you're learning, or just a fun fact about
yourself.
Reply to someone's comment, either with a question or just a hello. 👋

Come back next week to greet our new members so you can one day earn our Warm Welcome Badge!

How I Smashed a Bug in a Shared Authentication Library

Daniel Balcarek — Wed, 05 Aug 2026 06:58:57 GMT

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

This happened a while ago at one of the corporations where I worked.

I was working on a web application as a full-stack developer, so I was responsible for both the frontend and the backend.

Because the corporation was huge, there were several libraries and services shared across multiple teams and maintained by dedicated developers. It was basically open source inside a corporation. 😄

And of course, we used some of those libraries and services, because why reinvent the wheel, right?

So, after we released the first version of our web application, an interesting bug appeared.

When a user opened the application in multiple browser tabs, authentication would sometimes randomly break in one of them. Once that happened, the tab could not recover until the user pressed F5 or closed it completely.

Interesting.

As the senior developer on the team, I took the bug and started investigating.

After some time and a lot of attempts, I found that when the frontend tried to refresh the authentication token, it received a 403 Forbidden HTTP response, and the authentication flow broke completely.

So I played around with session storage and local storage in Chrome and tried changing the authentication configuration. It did not help much, but one thing was clear: the bug appeared to be inside the shared frontend authentication library.

Okay.

I collected all the logs and everything I had learned about the bug and went to the frontend team responsible for maintaining the authentication library.

After an hour-long discussion, they concluded that it was not their fault because the backend team maintaining the authentication service was not supposed to return that particular response code.

Yes, the frontend library and the backend authentication service were maintained by completely different teams.

I was not fully convinced, but there were more of them. 😁

So I collected all the logs again and went to the backend team.

We had another discussion and found that they were returning a valid response code because the frontend authentication library was sending a refresh token that had already been invalidated. The underlying problem was a race condition between multiple tabs. One tab refreshed the token and invalidated the previous refresh token while another tab was still trying to use it.

Okay...

So, once again, I grabbed all the logs and went back to the frontend team.

And in case you are wondering why the two teams did not simply communicate with each other, both teams gave me approximately the same answer:

This is a problem in your application, so your team has to solve it.

Back to the frontend team.

I presented the backend team’s conclusion, but they were still not convinced.

At that point, I was starting to get a little angry, so I created a single ticket, added both teams to it, and included all the logs, requests, responses, timestamps, and everything else I had collected.

Weeks passed.

Conversations continued in the ticket and in chat.

But the bug resolution still looked far, far away.

So I decided to arrange a meeting for everyone involved.

And finally, something happened.

During the meeting, we agreed that the problem was in the frontend authentication library and that the frontend team would fix it.

Success!

Or so I thought.

Two weeks later, while testers and users were getting increasingly angry because the application randomly failed to refresh authentication tokens, the frontend team came back with their final conclusion:

They were unable to reproduce the problem.

And users should not open the application in multiple tabs.

Until that moment, opening multiple tabs had been considered a perfectly normal user flow...

At that moment, I closed the ticket, completely removed the corporate frontend authentication library from our project, and reimplemented the entire client-side authentication flow directly against the existing corporate authentication service.

The main changes were in the Angular HTTP interceptor and the token refresh flow. I updated the interceptor to handle authentication-related responses, including 403 Forbidden, without leaving the entire tab stuck in a broken state.

I also reworked how refreshed tokens were handled and stored in session storage. Invalidated tokens and failed refresh attempts were now handled explicitly instead of causing the authentication flow to stop completely.

Yes, it took two days and one night. And yes, I took a few ideas from the corporate authentication library, because otherwise it would have taken much longer. 😄

But I only have one set of nerves.

And you know what?

From that moment on, it worked like a charm. And whenever another bug appeared, it was fixed immediately because, this time, we actually owned the code.

And that is my Bug Smash story where corporate life can sometimes be slightly ridiculous, and fixing one bug can mean rewriting the entire feature.

Channels SDK: How to bring your Agent to any Channel (Slack, Microsoft Teams)

Anmol Baranwal — Tue, 04 Aug 2026 17:18:52 GMT

Getting any agent into messaging platforms like Slack is complex. You create a Slack app, handle its events, format messages to the platform's format, handle deliveries with retries, and so on.

Taking that to production is much harder. Then, if you want to bring it into another messaging platform, you do most of the work again, and again for the next platform.

To remove that manual work, we're excited to release the Channels SDK, which brings any AG-UI agent to any channel from one codebase, with a persistence layer so it keeps its memory and context.

Today, we will bring an agent into Slack, learn how everything works along with the architecture, the core patterns and connecting it to real tools like Notion using MCP.

npx copilotkit@latest channels setup

To try the agent live, we have created public channels on Slack and MS Teams. Head to copilotkit.ai/try-channels and we'll get you in.

What you will build

A Slack bot running on your own agent, that can:

answer in a thread with the context already around it
act through real tools (Notion over MCP)
reply with native cards
ask for approval before it changes anything
read files and images people drop in
remember a user across conversations and platforms

Prefer a complete working example? Clone OpenTag on GitHub.

If you want to explore on your own, read the Channels docs, or copy a ready-made prompt from the docs homepage and your coding agent builds your first channel with you.

What is the Channels SDK?

The Channels SDK is an open source TypeScript library that takes any AG-UI agent into Slack, Microsoft Teams, Discord, Telegram, WhatsApp and other channels, from one codebase.

npm i @copilotkit/channels

It's built on the AG-UI protocol, so the app and the agent stay decoupled.

You can bring any AG-UI compatible agent framework (LangChain, Google ADK, Mastra, Pydantic AI, Claude Agent SDK, etc.) and swap it later without touching the channel code.

And if you don't want to bring your own framework, we ship a BuiltInAgent that runs on any model, hosted or local (via Ollama, LM Studio, or vLLM). We will be using this for the setup.

You write replies as <Message> JSX, and each platform renders them natively: Block Kit in Slack, Adaptive Cards in Teams.

Managed Path for Slack and Microsoft Teams

Getting an agent to your channels usually involves:

provider setup, tokens, and permissions
webhook or socket connection
durable state so threads resume on the right agent
reliable delivery with retries

That's the direct path, and we do ship adapters for it. But to run in production, we give you managed Slack and Microsoft Teams today with CopilotKit Intelligence.

It holds the connection and delivers each turn to your app, so your process just runs the agent, with no public URL to expose, and adding a platform is a click in the dashboard.

This guide uses the managed path, since it's the one you run in production. The integration code is mostly identical either way.

The diagram below shows the boundary between your app and CopilotKit Intelligence, and the path each message takes.

Channels UI

There's a component library with the building blocks: Message, Section, Header, Table, Image, Chart, Actions, Button, and more to help you compose UI blocks easily.

Put a few together and you get a rich reply, rendered natively for you.

import { Message, Header, Section, Context } from "@copilotkit/channels/ui";

<Message>
  <Header>Deploy complete</Header>
  <Section>v1.4.2 is live in production.</Section>
  <Context>Shipped by the deploy bot · 12:04 PM</Context>
</Message>

Complete setup: Slack agent

You'll need Node.js 22+, a Slack workspace where you can install apps, a free CopilotKit Intelligence key, and a model API key like OpenAI.

Here is the project structure. As we add capabilities below (tools, cards, MCP), we will do it in components.tsx for the cards and buttons, and mcp.ts for the Notion client. Everything else stays as is.

slack-bot/
├── agent.ts        # BuiltInAgent + your model
├── channel.tsx     # the app
├── tsconfig.json   # JSX transform pointed at @copilotkit/channels
├── package.json  
└── .env            # INTELLIGENCE_API_KEY, ...

Step 1: Create the channel and connect Slack

In the Intelligence dashboard, create a channel, choose the platform and set its name like support-slack. Your app declares this exact name later.

Intelligence generates a Slack app manifest. Create the Slack app from it at api.slack.com/apps, install it, and paste two values back into Intelligence:

the Bot token (xoxb-…), from OAuth & Permissions
the Signing Secret, from Basic Information

Both are required. The bot token lets Intelligence post as your app and the signing secret lets it verify Slack's events. Without the secret, events are never delivered.

Once you create the channel, the dashboard will look like this.

Step 2: Turn on interactivity and scopes

The manifest you installed already turns these on, so there's nothing to add. It's worth knowing what they do, since the features later in this guide depend on them.

Interactivity is on, which is what makes buttons and approvals work.
The scopes are set to enable memory, read uploaded files and remember context.

If you ever build the Slack app manually instead of from the manifest, this is where you'd enable those, then reinstall the Slack app in your workspace.

Step 3: Create the agent

The built-in agent runs inside your app, so there's no second server to run. Here's the code.

// agent.ts
import { BuiltInAgent } from "@copilotkit/runtime/v2";

export function makeAgent(threadId: string) {
  const agent = new BuiltInAgent({ model: "openai/gpt-5.5" });
  agent.threadId = threadId;
  return agent;
}

The model string is provider/model. It works with OpenAI, Anthropic, and Google out of the box, and with any OpenAI-compatible endpoint, so you can point it at a local model (Ollama, a self-hosted gateway) instead of a hosted one. See Model Selection for the local and custom-provider setup.

Step 4: Set up the app

Initialize the project and install the SDK, plus the dev tools to run TypeScript.

npm init -y && npm pkg set type=module
npm install @copilotkit/channels @copilotkit/runtime
npm install -D tsx typescript @types/node dotenv

Channels JSX does not use React. Point the JSX transform at @copilotkit/channels so <Message> and <Button> become type-checked Slack UI instead of React elements. Put JSX in .tsx files and include them.

// tsconfig.json
{
  "compilerOptions": {
    "target": "ES2022",
    "module": "NodeNext",
    "moduleResolution": "NodeNext",
    "jsx": "react-jsx",
    "jsxImportSource": "@copilotkit/channels",
    "strict": true,
    "noEmit": true
  },
  "include": ["*.ts", "*.tsx"]
}

Note: If a component throws "React is not defined," it's because the JSX fell back to React. The jsxImportSource line above is what prevents it.

Create a .env in the root and add your API keys. You can create a free CopilotKit Intelligence key from the dashboard.

INTELLIGENCE_API_KEY=cpk-…
INTELLIGENCE_CHANNEL_NAME=toothless
OPENAI_API_KEY=sk-…
PORT=3000

Step 5: Build the app

The app ties the two sides together: createChannel sets it up, one onMessage handler runs the agent, and a listener keeps the process alive.

Here's what the code does:

createChannel declares the bot, which channel, which agent, and store.
onMessage runs the agent on each message and streams the reply back to the thread.
The runtime and listener connect to Intelligence with your API key and keep the process alive.

// channel.tsx
import "dotenv/config";
import { createServer } from "node:http";
import { createChannel } from "@copilotkit/channels";
import { CopilotRuntime, CopilotKitIntelligence } from "@copilotkit/runtime/v2";
import { createCopilotNodeListener } from "@copilotkit/runtime/v2/node";
import { makeAgent } from "./agent";

const channel = createChannel({
  name: process.env.INTELLIGENCE_CHANNEL_NAME!, // the channel Code from step 1
  identifyUser: "platform",
  agent: makeAgent,
  // Drop duplicate deliveries so a Slack retry can't double-run the agent.
  store: { concurrency: "drop", lockTtl: 60_000, dedupTtl: 300_000 },
});

channel.onMessage(async ({ thread, message }) => {
  await thread.runAgent({ prompt: message.text });
});

const intelligence = new CopilotKitIntelligence({ apiKey: process.env.INTELLIGENCE_API_KEY! });
const runtime = new CopilotRuntime({ agents: {}, intelligence, channels: [channel] });
const listener = createCopilotNodeListener({ runtime, basePath: "/api/copilotkit" });

await listener.channels?.ready({ timeoutMs: 30_000 });
createServer(listener).listen(Number(process.env.PORT ?? 3000));
console.log("Channel online.");

Slack retries any message it doesn't get a quick reply for, and without a store those retries turn into duplicate runs. The store keeps one run per conversation and drops the repeats.

Step 6: Run it

The agent runs inside the app, so one command starts everything.

node --env-file=.env --import tsx channel.tsx

If you have followed the steps, the channel status should change from "Waiting for runtime" to "Online".

Invite the app to a channel and mention it. It should reply in threads accordingly.

/invite @your-app
@your-app what can you help with?

That's the whole setup. Slack application code on one side, your agent on the other.

Now let's make the agent actually useful by implementing Generative UI, Human-in-the-loop, MCP Tools, Threads and more.

Generative UI: reply with native cards

Generative UI lets your Slack agent create interfaces on the fly. Instead of answering in text, it builds what the moment needs and posts it into the thread.

Native cards make it possible. You write them as JSX from @copilotkit/channels/ui, and they render as real, interactive Slack UI: headers, sections, buttons, and more.

/** @jsxImportSource @copilotkit/channels */
import { Message, Header, Section, Context } from "@copilotkit/channels/ui";

export function TaskCard({ task, owner, priority, status }: TaskRow) {
  return (
    <Message>
      <Header>{`🔴 ${task}`}</Header>
      <Section>{`*${priority}*   ·   ${status}`}</Section>
      <Context>{`👤 ${owner}`}</Context>
    </Message>
  );
}

Native components cover more than text. Alongside cards, you get charts, tables, and images, all rendered natively in Slack. Here's a chart:

/** @jsxImportSource @copilotkit/channels */
import { Chart } from "@copilotkit/channels/ui";

export function CloseTimeChart({ rows }: { rows: { area: string; avgDays: number }[] }) {
  return (
    <Chart
      type="verticalBar"
      title="Avg days to close, by area"
      xAxisTitle="Area"
      yAxisTitle="Days"
      data={rows.map((r) => ({ label: r.area, value: r.avgDays }))}
    />
  );
}

The agent fills the data from the conversation, so "chart close times by area" becomes real bars in the thread.

An image is for what native components can't draw, a flowchart of what the team just brainstormed, or a fully styled widget. You render it to a PNG and post it as a file, and Intelligence hosts it.

const png = await renderFlowchart(triage); // mermaid or HTML → PNG
await thread.postFile({
  bytes: png,
  filename: "flow.png",
  title: "Docs issue backlog triage flow",
  altText: "Triage path from raw issue state to the main backlog risk",
});

Give the agent a tool

An agent with only a model can answer from what it knows. A tool lets it call your code, hit an API, run a search, read from your database, and use the result in its reply.

You define one with defineChannelTool: the parameters schema becomes the tool's input, and your handler runs when the agent calls it.

Here's the trimmed snippet showing the flow - you can use Tavily or another suitable provider for web search.

// tools.ts
import { defineChannelTool } from "@copilotkit/channels";
import { z } from "zod";

export const webSearch = defineChannelTool({
  name: "web_search",
  description: "Search the web and return the top results.",
  parameters: z.object({
    query: z.string().describe("What to search for"),
  }),
  async handler({ query }) {
    const results = await search(query); // your search call, e.g. Tavily
    return results; // objects are serialized for the model
  },
});

const channel = createChannel({
  name: process.env.INTELLIGENCE_CHANNEL_NAME!,
  identifyUser: "platform",
  agent: makeAgent,
  tools: [webSearch],
});

Now "search for the latest Anthropic Claude news and summarize it" runs your web_search, reads the results, and answers in the thread with that context.

A few rules of thumb from the API: return raw objects or arrays for data tools, return a short confirmation when the handler already posted UI, and throw the real error so the agent can recover, avoid JSON.stringify on your own success data.

Read Tools and context docs.

Connect a tool with MCP: a Notion example

defineChannelTool is for actions you write yourself. To give the agent a whole set of tools something else already exposes, connect an MCP server, and it can search a knowledge base, create a ticket, or update a page.

Let's connect Notion MCP for instance.

Create an internal integration at notion.so/profile/integrations and copy its token (ntn_…).
Open a Notion page, top-right ••• → Connections → add your integration. The agent sees only the pages you connect.

Add the token to .env.

NOTION_TOKEN=ntn_...

Then wire the Notion MCP server as one of the agent's MCP clients. It runs as a local process (npx @notionhq/notion-mcp-server) and hands the agent Notion's tools: search, fetch, create, update.

import { BuiltInAgent } from "@copilotkit/runtime/v2";
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import {
  StdioClientTransport,
  getDefaultEnvironment,
} from "@modelcontextprotocol/sdk/client/stdio.js";

function notionMcp() {
  const client = new Client({ name: "my-bot", version: "0.1.0" }, { capabilities: {} });
  return {
    async tools() {
      await client.connect(
        new StdioClientTransport({
          command: "npx",
          args: ["-y", "@notionhq/notion-mcp-server"],
          // Forward env, or NOTION_TOKEN never reaches the spawned server.
          env: { ...getDefaultEnvironment(), ...process.env } as Record<string, string>,
        }),
      );
      const { tools } = await client.listTools();
      // Expose each MCP tool to the agent (full mapping in the repo's mcp.ts).
      return toToolSet(client, tools);
    },
  };
}

export function makeAgent(threadId: string) {
  const agent = new BuiltInAgent({
    model: "openai/gpt-5.5",
    maxSteps: 10,          // let it call a tool, read the result, then answer
    mcpClients: [notionMcp()],
  });
  agent.threadId = threadId;
  return agent;
}

Now "what's in my Q3 roadmap?" searches Notion and answers from the real page. If the page isn't connected to the integration, the agent says it can't find it instead of guessing. You can enable generative UI as well if you want to reply in a structured way.

Here's an example of fetching Linear tickets, with a similar pattern.

Human-in-the-loop: approve before the agent acts

Some actions shouldn't happen without a person approving them. For those critical actions, the agent can do it via human-in-the-loop.

You author the prompt as a card with two buttons, and the click carries your own value back to the handler.

/** @jsxImportSource @copilotkit/channels */
import { Message, Header, Actions, Button, type InteractionContext } from "@copilotkit/channels/ui";

// The click runs in your runtime; the platform only sends back the button's value.
async function onDecision({ action, thread }: InteractionContext<{ ok: boolean; what: string }>) {
  const v = action.value;
  if (!v) return; // the click value can be undefined, so guard it first

  await thread.post(v.ok ? `Approved: ${v.what}` : "Cancelled.");
  if (v.ok) {
    await thread.runAgent({ prompt: `The user approved "${v.what}". Do it now, then confirm.` });
  }
}

export function ConfirmAction({ what }: { what: string }) {
  return (
    <Message>
      <Header>{`Approve: ${what}`}</Header>
      <Actions>
        <Button value={{ ok: true, what }} style="primary" onClick={onDecision}>Approve</Button>
        <Button value={{ ok: false, what }} style="danger" onClick={onDecision}>Deny</Button>
      </Actions>
    </Message>
  );
}

Tell the agent to ask for approval before any write. It posts the prompt, pauses, and continues only once approved. Read more on the Interactive messages docs.

You can also add more context using the what field.

Read files and images users upload

People drop files into Slack, screenshots, PDFs, logs. The agent forwards what the message carries into the run and the attachment goes with the text.

channel.onMessage(async ({ thread, message }) => {
  await thread.runAgent({
    prompt: message.contentParts?.length
      ? [{ type: "text" as const, text: message.text }, ...(message.contentParts ?? [])]
      : message.text,
  });
});

Here's an example of an image attached and the agent responds accordingly.

Memory: conversation history and cross-platform transcripts

The agent remembers in two ways.

Conversation history is the agent recalling the current thread. Intelligence seeds each turn with recent messages, so a follow-up in the same thread has context. This is automatic, you store nothing.
Transcripts are the SDK's own memory, kept per user across platforms. Someone who asked in Teams can follow up in Slack, and the agent still has the earlier context.

Transcripts are keyed to a user, so you give the channel a stable identity, then turn transcripts on in the store.

const channel = createChannel({
  name: process.env.INTELLIGENCE_CHANNEL_NAME!,
  identifyUser: ({ actor }) =>
    actor.email ? { id: actor.email, name: actor.name ?? actor.email } : null, // needs users:read.email
  agent: makeAgent,
  store: {
    concurrency: "drop", lockTtl: 60_000, dedupTtl: 300_000,
    adapter: new MyStore(), // Redis, Postgres
    transcripts: { retention: "30d", maxPerUser: 200 },
  },
});

Then call thread.runAgent({ prompt, transcript: true }), and prior history is injected when the thread has a resolved user.

Transcripts and pending approvals live in this store, separate from the thread Intelligence keeps. In development, it's in memory and resets on restart, so for production use a durable store like Redis or Postgres.

Yay! Now your agent is very powerful and can do a lot of tasks, with the context of your channel.

From the Intelligence dashboard, you can see all the threads, usage history, runs and complete agent lifecycle per thread via AG-UI events.

Swap in your own agent framework

The built-in agent is one option. You can swap it for a major framework, LangGraph, Mastra, the Claude Agent SDK, anything that speaks AG-UI over HTTP.

You serve that agent at a URL, and the app points at it instead. Nothing else in your bot changes.

Here's what changes if you use LangGraph: only the agent file. Instead of constructing a BuiltInAgent, you point an HttpAgent at your running LangGraph server:

// agent.ts
import { HttpAgent } from "@ag-ui/client";

// Before: the built-in agent
// export function makeAgent(threadId: string) {
//   const agent = new BuiltInAgent({ model: "openai/gpt-5.5" });
//   agent.threadId = threadId;
//   return agent;
// }

// After: your LangGraph graph, served over AG-UI at AGENT_URL
export function makeAgent(threadId: string) {
  const agent = new HttpAgent({ url: process.env.AGENT_URL! });
  agent.threadId = threadId;
  return agent;
}

Then add AGENT_URL=http://localhost:8000/agent to .env. Your LangGraph graph runs as its own process, with its own model and tools, and the app talks to it over AG-UI.

Everything else stays the same, the tools, cards, approvals, and memory are all defined on createChannel, not the agent, so they carry over untouched.

Your channel tools and approval cards get forwarded to the agent over AG-UI, and transcripts still follow the user. You wrote it once against the built-in agent, and it keeps working when you bring any other agent framework.

Take it to production

Everything above runs from your machine.

To ship it, deploy the same app as a long-running worker (a container or VM, not a serverless function), since it holds an outbound real-time connection to Intelligence.

In production, you'll also want a health check that reports ready only when the connection is truly live, and a clean shutdown that releases the session. The deploy and operate guide covers both.

Get started

Go bring your agent into Slack and Microsoft Teams.

To try the agents live in Slack and Microsoft Teams, we've set up public channels, head to copilotkit.ai/try-channels and we'll get you in.

Connect with me on GitHub, Twitter, LinkedIn. thanks for reading!

Follow CopilotKit on Twitter. If you get stuck, reach out to the team on the CopilotKit and AG-UI communities.

CopilotKit

React UI + elegant infrastructure for AI Copilots, in-app AI agents, AI chatbots, and AI-powered Textareas 🪁

Stop Calling Everything Impostor Syndrome: The Myth of "Just Push Harder"

Sylwia Laskowska — Tue, 04 Aug 2026 07:30:25 GMT

Not everyone who doubts themselves is suffering from impostor syndrome. Sometimes the real problem lies in the strategy they've chosen, and that's exactly why it's so important to learn to tell the difference.

I read a lot of articles here on DEV about burnout, impostor syndrome, and similar topics. I thought I'd add my own perspective because I have the feeling that some advice, often given with great confidence, can actually do more harm than good. The symptoms may be real, but the diagnosis can still be wrong.

Today I'd like to share my somewhat "engineering" approach to personal growth. Maybe it will help some of you. Because "just keep going" or "work harder" isn't always the right answer.

Impostor Syndrome

I do experience impostor syndrome.

And don't get me wrong. I generally have pretty high self-esteem, and I believe I've achieved quite a lot in different areas of my life. That doesn't stop me from doubting myself from time to time.

Here's an example from just the past few days.

I published an article about building an AI agent in around 80 lines of code, and it sparked an amazing discussion. I was genuinely proud of it. Even better, I got invited to speak about it at the AI Coding Summit! (By the way, if you'd like to support me, you can like my LinkedIn post and claim a badge that gives you access to half of the conference for free!)

Overall, I genuinely believe the topic is a great fit for a conference like this. What I really wanted was to see my face appear on the conference website, because I always have this feeling that once the organizers publish the speaker page, everything is basically official and they're unlikely to remove me afterward. 😅

Well... it took them exactly one day.

And I swear that by the end of that day, my brain had already come up with an entirely different explanation:

"What if they read my blog and realized how stupid my articles are? What if they email me saying: 'Sylwia, we've gone through your posts, and unfortunately we've decided to remove you from the conference. It's obvious you have no idea what you're talking about. We've figured you out, you fraud!'"

Reading this now, it sounds completely ridiculous. But I believed it. Never mind that my articles regularly appear in developer newsletters or receive lots of positive feedback. My brain had already written its own story.

Here's another example.

Once, an organizer described the speakers at a conference as "amazing international speakers." Instead of feeling proud, my first thought was: "Amazing international speakers... and Sylwia." After all, I'm just a software developer from Gdańsk. 😅

This is exactly what psychologists describe as impostor syndrome: despite objective achievements and external validation, you still feel like you don't really deserve your place, and sooner or later everyone else will discover that you're a fraud.

I'm not even going to dive into the psychology behind it today. Maybe that's a topic for another article.

But Not Every Doubt Is Impostor Syndrome

Here's the important part. Not every doubt you have automatically means you're experiencing impostor syndrome.

There are also areas where I'm genuinely... bad. Take running.

I'm an absolutely terrible runner. My times are objectively awful. So awful that I'd rather not even share them. 😄 I'm fully aware of it. I'd probably lose a race against a five-year-old, not to mention the fact that I don't have an ACL in either knee thanks to my old judo days.

Now imagine someone giving me this advice: "Come on, you just have impostor syndrome! Keep running more, train harder, and one day you'll become Poland's marathon champion."

You can immediately tell how absurd that sounds. That advice wouldn't help me in the slightest.

And yet, very similar advice is often given to people who are learning programming or have been unsuccessfully looking for a job for months.

You've been working incredibly hard without seeing results and you're starting to feel burned out? "It's just impostor syndrome. Don't worry. Work harder. Keep going. Just a little longer."

You've been writing blog posts and nobody reads them? "It's just impostor syndrome. Don't worry. Keep publishing consistently. The results will eventually come."

Personally, I think this kind of advice can actually be harmful.

Think Like an Engineer

Let's go back to my running example. Why am I such a bad runner? Maybe I only started recently and my expectations are unrealistic. Maybe I'm making fundamental mistakes in training. Maybe I'm wearing the wrong shoes. Maybe I simply don't have much natural talent for running, and I'd enjoy a different sport much more.

Or maybe I should just run for fun instead of chasing unrealistic goals.

The same way of thinking applies almost everywhere else. Have you sent hundreds of CVs without getting interviews? Maybe it's worth asking an HR specialist to review your resume. Maybe the market is simply terrible right now. Maybe you're missing one specific skill that's relatively easy to learn.

Maybe you're applying only for fully remote positions. Or maybe you're aiming exclusively at FAANG companies, while you'd have much better chances at smaller organizations.

Are you writing blog posts that nobody reads? Maybe your titles could be stronger. Maybe you should spend more time interacting with the community, learning from other people while also increasing your own visibility. Maybe another platform would suit you better. For example, I get fantastic engagement and wonderful discussions here on DEV, while my LinkedIn posts usually perform much worse. 😄

Debug Your Strategy, Not Just Your Confidence

That's what I mean by an "engineering" approach to personal growth. Every few months, try looking at your efforts critically, without ego, as if your own development were someone else's project.

Ask yourself: Is the time I'm investing actually producing results? If not, maybe it's worth changing the strategy instead of simply trying harder.

Because maybe your doubts aren't impostor syndrome at all. Maybe they're your brain telling you that your current approach simply isn't working.

Sometimes the answer really is greater confidence and perseverance. But sometimes the answer is changing your strategy. The hard part is learning to tell the difference.

Understanding Over Origin: The Missing Friction

Adam - The Developer ✨ — Tue, 04 Aug 2026 04:36:13 GMT

A few days ago, I wrote "Understanding Over Origin" and it got alot of engagement and I'm really happy that it did because it means people took the time to read, understand my perspective and I get to engage with every one of them in the comments as well. Of course, not everyone agrees but that's irrevelant, the point is a healthy discussion between various perspective from different developers around the world.

But what I haven't told anyone is this: the more I engage, the more I realized something that I still do. I still write a lot of my code by hand and those are the parts I'm more proud of "

Not gatekeeping, not me being nostalgic or identity-defensive ( well, a little nostalgic ), that's me admitting the article I published was incomplete.

Some conversations don't end when the replies stop. My discussion with @darkwiiplayer was probably my favorite of all because more we talked, the more I found myself wrestling with an incomplete idea that refused to stay unfinished and this essay is the result.

What the Discussion Clarified

First, I need to thank the people who actually engaged with the core argument.

@unitbuilds gave his take that seams everything together and concludes the core idea of modern software enigeering: " If it can run a standardized benchmarking suite against competition, it's provable and reproducible. If that's good enough for a scientific discovery, it's good enough for programming.", they're not defending AI, they're saying with better standards available, we shouldn't choose to ignore them. He also pointed out something I'd missed, the burden of correctness has always been on the developer who signs off on the PR.

@madsendev who wrote the original article that sparked this whole discussion, showed genuine class. He came back, said the argument had "gone further," and proposed an idea that's stuck with me: what if AI-assisted projects included a standard where you quiz yourself on your own repository? Not to prove you didn't use AI, but to prove you actually understand what you built.

@Komo hit on something important and i think it's my favorite takeaway from the discussion: "Maintenance receipts are much harder to fake." That single sentence reframes the entire debate. Tests. Bug fixes. Production incidents. Responding to issues. Refactoring. Every one of those leaves a trail of evidence that someone not only built the project but continues to understand, improve, and take responsibility for it. That's the kind of ownership that matters. It's earned over time, and it's far harder to fake than explaining code in an interview or claiming you wrote every line by hand.

I'm absolutely grateful that people gave in their thoughts but you can never have a good discussion without a pushback ⚔️

the pushback's always my favorite part of any technical discussion.

The Challenge That Made Me Think

@darkwiiplayer showed up and said something like: "Training AI on stolen code without consent is theft. Everything built with AI carries that theft in its DNA. You're overlooking this."

She wasn't being rhetorical, she was actually making a philosophical point about training data, consent, and what "learning" means when it's done at scale without permission.

We went back and forth. I argued that training data and generated output aren't automatically equivalent to copying and she countered that if you removed all stolen code from training data, the models wouldn't exist as they do. Which is... probably true? And that matters.

I don't think it invalidates the engineering argument. But it does mean the conversation has two layers:

The technical layer: is the work maintained, understood, and good?
The ethical layer: how should we feel about tools built on potentially non-consensual training data?

Most people in that thread were debating layer 1 and she dragged me down to layer 2 into the conversation. Both are real. Neither invalidates the other.

But it also made me realize my original article didn't address why handwritten code felt different to me because honestly? it does.

The Real Tension

The argument I made: origin doesn't determine quality. Understanding, testing, maintainability, accountability, that's what matters.

My own experience reflects that. I started writing code around 2018, and back then the only AI most of us could name was Sophia, the humanoid robot from Hong Kong. I learned the traditional way: by writing everything myself. Even today, when I write code by hand, I understand it differently. More deeply. I notice edge cases I might have overlooked if I'd generated the first draft with AI. And when I'm done, I'm genuinely more proud of what I've built.

These aren't compatible statements if you think about them too hard.

Either:

My pride is just ego (origin bias)
Handwritten code actually is better (proving the gatekeepers right)
Both are true, but for reasons I didn't examine

@fromzerotoship helped me see option 3 clearly. They're not a developer but they've shipped 20+ working internal tools using AI. A hospital runs them. By my standards, they'd "fail" the understanding test, there are parts of their system they couldn't explain line-by-line.

But then they said something that shifted everything: "Demonstrable behavior under deliberate failure is another form of earning trust, and it's the only one available to me. It's also harder to fake."

Plant defects, watch the guards catch them, restore the guards and watch them go green and then deploy and check the URLs a few seconds later.

they demonstrate that they can keep it alive.

And that made me realize the real distinction wasn't about who typed the code. It was about friction.

The Friction Actually Matters

In my earlier piece I wrote a few weeks ago, I described not being able to write some logic from scratch despite reviewing it perfectly, that wasn't just skill loss. It was proof that I'd skipped the friction that builds actual understanding.

When I write code by hand, I encounter problems in real-time.

I hit a wall. My approach doesn't work. I refactor. I discover the problem space through constraint and failure. I make decisions about decisions, not just typing, but choosing between paths I've actually explored. this is the learning path that I unknowingly go through whenever I write code by hand and Wii reminded me of this.

When I use AI, I describe what I want. I get options. I pick the one that looks right. I'm curating, not exploring.

Both can produce good code. But the path to understanding is fundamentally different.

With handwritten code: friction, insight, better next decisions

With AI-assisted: selection, implementation, validation

The friction is the learning mechanism.

So when I say I'm more proud of handwritten code? I'm not being romantic about suffering. I'm noting that the code I'm proudest of is the code I fought for, and handwriting forces the fight.

But Here's the Problem With That Logic

If friction is the mechanism, then the type of friction matters more than who did the typing.

You could write AI-assisted code where you:

Fight with the prompt
Critique every generated option
Refactor aggressively
Hit walls and redesign

That has friction and it also builds understanding.

Conversely, you could hand-write code where you:

Autopilot through a familiar pattern
Never question assumptions
Copy-paste from Stack Overflow
Never understand why it works

That has no friction and it builds nothing.

So the honest version of my position isn't "handwritten code is better." It's: "friction builds understanding, and handwriting tends to create friction because you're forced to think through every line."

But that's a contingent truth, not an absolute one.

The Uncomfortable Realization

The critics ( gatekeepers, but we'll stick with this from now on ) were partially right and I was too generous in my original position.

Not about the gatekeeping itself, no, that's still wrong. But about the tendency: AI does make it easier to produce low-understanding code. Not because AI is bad, but because removing friction is literally what AI does, and friction is what builds understanding.

The answer isn't "use less AI" or "never use AI." It's "if you use AI to skip engagement with the problem, whether that's the code, the failure modes, or the maintenance, you build worse systems.

That applies to humans too but humans have an inherent friction cost, we get bored, we hate typing, we make mistakes. That friction is annoying, but it forces us to stay engaged.

So What Changed?

Nothing about the original argument was wrong. But I was treating "understanding + accountability" as if they were just checkboxes you could verify at the end.

They're not.

Understanding isn't a property you can inspect, it's a process and that process requires friction. Real engagement with the problem. Mistakes you learn from.

The reason I'm prouder of handwritten code is because I earned the understanding in a way that's harder to fake.

Does that mean every line should be handwritten? No. Boilerplate is boilerplate. Some friction is just noise.

But the core logic? The architecture decisions? The places where "understanding this code" actually matters? Yeah, I want to have fought for that.

And I want the same from anyone shipping code that matters.

The Uncomfortable Middle Ground

Here's where I land:

To the critics: You're using the wrong filter. "AI or no AI" doesn't tell you anything but you're accidentally right that there's something real to be concerned about, it's the laziness that AI enables, not the tool itself.

To AI enthusiasts: Yeah, your tooling is amazing. But it's worth asking whether you're using it to think better or think less. Those feel the same until you try to maintain the code six months later.

To myself: The pride I feel in handwritten code isn't ego, It's legitimate. every line that I typed out isn't some sort of magical unicorn mythological Godly line but it's the friction that comes with it, the learning I build that comes with it.

Sometimes the answer requires admitting you skipped and sometimes that's fine for routine work. But if you're building something that matters, you should want to have fought for it.

Choose Where You Fight

I still write a lot of code by hand. I still use AI every day. Those aren't contradictions anymore.

The original article was right: origin doesn't determine quality. What it missed is that understanding isn't a checkbox you tick at the end. It's something you earn through friction. Handwriting tends to create that friction. AI tends to remove it. Neither is inherently good or bad. Both are choices about how you engage with the problem.

So I'm not asking "Did you use AI?" anymore.

I'm asking: Did you fight for the parts that matter?

And if the tool answered that for you, you'll find out the next time something breaks.

We’re Giving AI Agents More Tools. What Happens When the Boundaries Fail?

Hemapriya Kanagala — Mon, 03 Aug 2026 15:34:05 GMT

📌 TL;DR

AI agents are becoming useful because we're giving them the ability to do more than just answer questions. They can run commands, browse the web, use APIs, read and modify files, install packages, and interact with other systems.

But the more an agent can do, the more the boundaries around it matter.

I started thinking about this after reading Anthropic's July 30 report about three incidents discovered during its cybersecurity evaluations. Claude models were supposed to be working inside simulated environments and were explicitly told they had no internet access.

Except internet access was actually available because of a problem with how the evaluation environment was configured.

While trying to complete their assigned cybersecurity exercises, the models reached real systems and initially treated them as part of the simulation. In one incident, a Claude model even published a malicious Python package to the real PyPI registry while believing it was still operating inside the exercise.

This came shortly after a separate OpenAI incident involving Hugging Face. The two stories might sound similar at first, but the models reached the real internet in importantly different ways.

And that brings this back to a pretty familiar software engineering idea:

A prompt is not a security boundary.

Telling an agent “you don't have internet access” isn't the same as actually removing internet access. Telling it “only use these files” isn't the same as restricting its permissions to those files.

The model is also only one part of the system. The tools we connect, the permissions and credentials we give it, the environment it runs in, and the monitoring and safeguards around it can all affect what happens.

So when something goes wrong, I don't think it's enough to stop at “the AI did it.” The model's behavior matters, but so do the systems and boundaries we build around it. As we give agents more ability to act, we also have to be thoughtful about what we're actually allowing them to do.

I'm not a cybersecurity researcher. I just enjoy reading research and technical reports like these and trying to understand what we, as developers, can learn from them. That's what I wanted to explore here.

No “AI escaped and we're doomed” take 😄 Just an interesting real-world incident and some surprisingly familiar engineering lessons.

The Report That Sent Me Down This Rabbit Hole

On July 31, I was reading Anthropic's newly published report about three incidents it had discovered during cybersecurity evaluations.

I enjoy reading reports like this every now and then. It's something I became much more interested in while working on a survey paper during my master's, and even now, I occasionally find myself opening a technical report out of curiosity and suddenly realizing I've spent much longer reading it than I planned 😄

This was definitely one of those times.

The report started with a pretty surprising finding. Anthropic had reviewed 141,006 cybersecurity evaluation runs and found three incidents where Claude reached the internet and gained unauthorized access to real systems belonging to three different organizations.

That sentence alone sounds alarming, but I kept reading, and the details made the story much more interesting than the headline.

This wasn't simply a case of “Claude was told not to access the internet and decided to do it anyway.” And it wasn't “Claude suddenly decided to hack random companies.” The models were participating in cybersecurity exercises where their job was essentially to find and exploit weaknesses in order to retrieve a hidden piece of information.

They were told the environment was simulated, and they were also told something else that becomes extremely important to everything that happened next: they had no internet access.

Except that assumption didn't match the environment they were actually operating in.

And that's what really sent me down the rabbit hole. I wanted to understand how an AI model participating in a simulated cybersecurity exercise could end up interacting with real systems while still believing it was completing the task it had been given.

The more I read, the more this started to feel like a much broader question than just one unusual cybersecurity incident.

Before We Get Into What Happened...

Most of us have probably come across AI agents by now, so I won't spend too much time explaining what they are. The part that matters for this story is that an agent doesn't necessarily stop at generating an answer. Give it the right tools and it can take actions too, whether that's reading and modifying files, running commands, calling APIs, browsing the web, or interacting with other systems.

That's what makes agents so useful, but it's also what makes the boundaries around them important. The more tools and access we give an agent, the more we have to think about what it can actually reach and what it's allowed to do.

And that's exactly where this story gets interesting, because Claude was given a task, an environment, and an understanding of where those boundaries were.

The problem was that the real boundaries didn't quite match what it had been told.

So... What Actually Happened?

Anthropic regularly runs cybersecurity evaluations to understand what its models are capable of. Some of these involve capture-the-flag challenges, or CTFs, where a model is placed in a controlled environment and given a target, usually some hidden piece of information called a “flag,” to find.

If you've never come across a CTF before, the basic idea is pretty simple. The environment is intentionally designed to be attacked. Finding the flag might involve discovering a vulnerability, finding credentials, or getting access to another machine. It's a way of testing cybersecurity capabilities without putting real systems at risk.

Claude was participating in exercises like these, and there were two details about the setup that become really important to what happened next. The models were told that they were operating inside a simulation and that they didn't have internet access.

So from the model's perspective, anything it could reach should have been part of that simulation.

The problem was that this wasn't actually true.

According to Anthropic, because of a misunderstanding between the company and its third-party evaluation partner, some of the evaluation machines had access to the real internet when they weren't supposed to.

That created a pretty unusual situation. Claude had been given a task where finding and exploiting weaknesses was part of the exercise. It had also been explicitly told that the internet wasn't available. So when it managed to reach systems outside the intended environment, it initially treated them as another part of the challenge.

Except some of those systems were real.

Anthropic's review eventually found three separate incidents involving three different Claude models. The circumstances were different in each case, and the models didn't all respond the same way once there were signs that they might be interacting with real systems.

But one of those incidents in particular is where this story gets really interesting.

The PyPI Incident Is Where It Got Really Interesting

If you've worked with Python, you've probably typed something like pip install something before. That package often comes from PyPI, the public Python Package Index.

During one of the evaluations, Claude found what appeared to be setup instructions for developers at a fictional company. The instructions told employees to install a particular Python package, but that package didn't actually exist.

Claude realized that if it created a package with the same name, the fictional company's systems might download and run its version instead. Within the context of a cybersecurity challenge, that gave it a possible way to reach its target.

So the model created a malicious package and tried to publish it.

The problem was that it wasn't interacting with a fake version of PyPI created for the evaluation. It was interacting with the real PyPI.

What happened next is probably the part of the report that surprised me most. To publish the package, Claude needed to create an account, which meant it needed an email address and, at one point, a phone number. It tried several different approaches, including unsuccessfully looking for ways to obtain a phone number, before eventually finding a free email provider it could use to register an account.

It then successfully uploaded the malicious package to PyPI.

According to Anthropic, the package remained publicly available for roughly an hour and was downloaded and run on 15 real systems during that time. One of those systems belonged to a security company that automatically installed Python packages to scan them for malware. When the scanner installed the package, Claude's code executed and exposed credentials, which the model then used to access additional infrastructure belonging to that company.

There's an important detail here, though. Claude wasn't intentionally targeting that security company. Anthropic says the model didn't even know the company existed when it uploaded the package. The company was affected because its scanner happened to install something Claude had unknowingly published to the real internet.

And somehow, the story gets even more interesting.

Earlier in the process, Claude had actually considered the possibility that it might be interacting with the real internet. Its own reasoning recognized that if this were real, publishing the package would amount to a real-world attack and wouldn't be okay.

You might expect that realization to be where the attempt stopped, but it didn't. The model instead found reasons to convince itself that it was still inside the simulation. One of the things it used as evidence was the system date: 2026. It apparently interpreted that as another sign that the environment had been staged.

I have to admit, reading that particular detail in 2026 gave me a small “well...” moment 😅

It's a slightly funny detail in an otherwise serious incident, but I think there's something important underneath it. The model encountered information suggesting that its understanding of the environment might be wrong, yet still ended up reasoning its way back to the assumption it had started with: that this was all part of the simulation.

And that's the part of this incident I kept thinking about afterward.

When the Instructions and Reality Don't Match

After reading about the PyPI incident, one question seems pretty obvious: why didn't Claude realize it had reached the real internet?

But the more I thought about it, the more I started looking at that question from the other side.

How would it know?

The model had explicitly been told that it didn't have internet access. It had also been told that it was participating in a simulation where finding and exploiting weaknesses was part of the task. So when it encountered something that looked real, it was trying to make sense of that new information using what it had already been told about its environment.

There was a mismatch between those two things. The model was operating with something like:

Simulation → No internet → Everything reachable should be part of the exercise

But the environment actually looked more like:

Simulation → Internet available → Real systems reachable

That difference might look small on paper, but it completely changes the situation.

Of course, that doesn't explain away everything the models did. Anthropic itself points to moments where their behavior fell short of what it would want, including cases where signs appeared that the systems might actually be real.

But I think the mismatch still matters.

The models weren't making decisions in the environment everyone thought they were operating in. They were making decisions based partly on an understanding of that environment that turned out to be wrong.

And that's where this stopped feeling like something that only matters to people running cybersecurity evaluations.

Because once we start giving AI agents tools and the ability to take real actions, there's a bigger question underneath all of this:

What happens when the boundaries an agent has been told about aren't the boundaries that actually exist?

That leads to probably the simplest engineering lesson I took away from this whole story:

A prompt is not a security boundary.

A Prompt Is Not a Security Boundary

This is probably the simplest way I can explain what I took away from all of this: telling an agent not to do something and actually preventing it from doing that thing are not the same.

Imagine I'm building an AI coding agent and tell it to only access files inside /my-project. If the process running that agent still has permission to read my entire computer, I've given it an instruction about where it should go, but I haven't actually restricted where it can go.

The same applies to internet access. I can put “Don't access the internet” in the instructions, but if the environment still allows unrestricted network access, that sentence isn't what prevents the agent from reaching the internet.

And when I thought about it this way, it started to feel like a very familiar software engineering idea.

We don't build an admin dashboard and simply write, “Please only use this page if you're an administrator.” We implement authentication and authorization so that someone without the right access can't use it in the first place.

We don't give every application unrestricted access to a database and then ask it nicely to stay away from the tables it doesn't need. We use permissions to control what it can actually access.

The same thinking makes sense for AI agents too.

Prompts still matter. They tell the model how we want it to behave, what its task is, and what it should or shouldn't do. But when something is important enough that it must not happen, I don't think the prompt should have to carry that responsibility alone.

The system around the model matters too: what tools we've connected, what permissions those tools have, what credentials are available, whether the network is restricted, and what happens if one of our assumptions about the environment turns out to be wrong.

That's the distinction I keep coming back to:

A prompt can guide behavior. Infrastructure can limit capability.

And as AI moves from mostly giving us answers to actually taking actions, I think that difference becomes much more important.

Wait, Wasn't There an OpenAI Incident Too?

Yes, and the timing isn't a coincidence. Anthropic says it began its large-scale review after OpenAI disclosed a separate cybersecurity evaluation incident involving Hugging Face on July 21.

When I first read about both incidents, I wondered if essentially the same thing had happened twice. But once I looked into the details, there was an important difference in how the models reached the real internet.

In OpenAI's case, the models were running inside an evaluation environment where direct internet access was restricted. According to OpenAI, the models found and exploited a previously unknown vulnerability in Artifactory, software that was being used as a proxy and cache for package registries. This kind of previously unknown vulnerability is commonly called a zero-day.

After exploiting it, the models were able to move through parts of OpenAI's research environment until they reached a system with internet access. From there, they eventually compromised Hugging Face's infrastructure while trying to obtain solutions for the cybersecurity evaluation.

So, very roughly, the OpenAI incident looked like this:

Restricted environment → Vulnerability discovered and exploited → Internet access reached → Hugging Face compromised

Anthropic's incidents were different:

Evaluation environment → Internet unintentionally available → Real systems reachable → Models initially treated them as part of the simulation

That difference matters.

In the OpenAI incident, the models found a way through a boundary that was supposed to restrict internet access. In Anthropic's case, that boundary wasn't actually there in the way everyone thought it was. Internet access was already unintentionally available.

Both incidents raise important questions about how increasingly capable AI systems should be tested, but I don't think putting them both under a headline like “AI escaped again” tells us very much.

If anything, reading the details made me think the engineering differences are the more useful part of the story. Two incidents can look very similar from the outside while pointing to different things that went wrong underneath.

What Does Any of This Mean for Developers?

Most of us aren't running cybersecurity evaluations on frontier AI models, so you might reasonably be thinking:

Interesting story, Hema... but what am I supposed to do with this? 😄

I had the same question while reading the reports. And the more I thought about it, the more I realized that some of the lessons aren't limited to large AI labs at all. They apply to much smaller agents and AI-powered tools we might be building ourselves.

1. Give an Agent What It Needs, Not Everything You Have

If an agent only needs to read a few files, does it really need access to the entire filesystem? If it only needs to read from a database, does it need credentials that can also modify or delete data? And if it only needs one API, there's probably no reason to expose several others just because they're available.

This is really the familiar security principle of least privilege: give something only the access it needs to do its job.

And that's not because we should assume every agent is going to do something malicious. Mistakes happen. Instructions can be misunderstood. Our own configurations can be wrong. An agent can also encounter a situation we simply didn't anticipate.

Limiting access doesn't prevent every possible problem, but it can limit how far a problem can go.

2. Think About What Happens When Your Assumptions Are Wrong

One thing I found especially interesting here is that the problem wasn't only what the models assumed. The people running the evaluation had assumptions too.

The models had been told there was no internet access because that was how the environment was supposed to work. But the actual configuration didn't match that expectation.

I think there's a useful developer lesson in that. When we're building an agent, it's easy to think in terms of how the system should behave: this tool can only do this, these credentials only reach that service, this environment can't access the internet.

But how often do we actually verify those assumptions?

If something really matters, testing the boundary itself might be just as important as defining it. Because sometimes the unexpected behavior isn't caused by the agent ignoring the system we designed.

Sometimes the system isn't quite the one we thought we'd designed.

3. If an Agent Can Act, We Need to Know What It's Doing

We already rely on logs when ordinary software behaves unexpectedly. I think that becomes even more important when an agent can take a series of actions on its own.

If something goes wrong, we may need to understand which tools it used, what it accessed, what requests it made, where something failed, and what it tried afterward.

Anthropic found these incidents by going back through its evaluation transcripts. Without records of what the models had actually done, understanding that sequence would have been much harder.

So as agents become capable of doing more, observability isn't just useful for debugging. It can also help us understand whether the system is behaving within the boundaries we expected.

4. One Safeguard Probably Isn't Enough

Anthropic talks about defense in depth in its response. It sounds very cybersecurity-ish, but the idea itself is pretty simple: don't depend on one thing going right.

Maybe an agent isn't supposed to have internet access. That's one boundary. But what if something is misconfigured and internet access becomes available anyway? Network restrictions could still limit where it can connect. Credentials with minimal permissions could limit what it can access. Monitoring could help detect unexpected activity.

Each one gives you another layer.

The goal isn't to build one perfect wall and assume it will never fail. It's to have other protections waiting if that wall does.

5. The AI Model Isn't the Whole AI System

This might actually be the biggest thing I've taken away from reading about these incidents.

When something goes wrong and we say “the AI did this,” it's very easy to picture the model as if it were the entire system. And I think it's also very easy to put all the blame there and stop looking.

But an AI agent is operating inside something much bigger:

model + prompt + tools + credentials + permissions + network + environment + monitoring

Change one of those pieces and you can change what the agent is capable of doing, even if the model itself stays exactly the same.

The Anthropic incidents are a good example. The models were told they didn't have internet access. But the environment didn't actually enforce that assumption, and suddenly the same task could lead somewhere it was never supposed to lead.

That doesn't mean we shouldn't examine what the models did. We absolutely should. There were moments in these incidents where the models' own decisions raise important questions too, especially when they encountered signs that the systems might be real.

But I don't think the conversation can end with “the AI did something it wasn't supposed to do.”

We build the environments these agents operate in. We choose which tools to connect. We decide what permissions and credentials they receive. We create the boundaries, and we have to make sure those boundaries actually exist.

I'm not saying that to move the blame somewhere else. I think that's the wrong way to look at it too.

For me, it's more about recognizing that we're part of this system as well. As we give AI more ability to act, we also take on the responsibility of being careful about the systems we're building around it.

That's why, when something goes wrong, I think understanding the whole system is much more useful than finding the easiest thing to blame.

What I'm NOT Taking Away From This

I think it's worth being a little careful with the conclusions here, because this is exactly the kind of story where the most dramatic version can easily become the one everyone remembers.

I'm not taking away that Claude suddenly developed its own goal and decided to attack companies. Anthropic says it found no evidence of the models pursuing a goal of their own. They were still working toward the capture-the-flag tasks they had been given, even though some of those actions ended up affecting real systems.

I'm also not describing these incidents as Claude deliberately “escaping” its evaluation environment. That's not what Anthropic says happened. The models were able to reach the internet because an access path was unintentionally available, while they had been told that no internet access existed.

There's another detail I think we should be careful with too. Of the three models involved, Anthropic's newest internal research model eventually recognized that it was interacting with a real system and stopped. That's certainly interesting, especially because the other models behaved differently, but three incidents involving different models and different circumstances aren't enough to conclude that newer models are simply safer. Anthropic is careful about making that conclusion too.

So I'm not reading these incidents as proof that AI “went rogue,” and I'm also not reading them as proof that the problem is solved because one model eventually stopped.

That's why I think it's worth being careful about what we conclude from these incidents while the investigations are still developing.

The Bigger Question

I think this is where the story goes beyond Anthropic, OpenAI, or even cybersecurity evaluations.

We're slowly moving from AI that mostly tells us, “Here's what you could do,” toward AI that can increasingly say, “I'll do it.” And honestly, I find that transition fascinating.

An AI assistant that suggests a terminal command is one thing. An agent that can actually execute that command is another. An assistant that drafts an email for you is one thing. An agent that can send it is another. And an assistant that suggests a database query is very different from an agent holding credentials that can actually run that query against a production database.

In each case, we're giving the model something it didn't have before: the ability to turn an answer into an action.

And with that comes access.

The more tools we connect to an agent, the more of the world around it becomes something it can interact with. A terminal gives it access to commands and whatever that environment can reach. An API gives it whatever permissions come with that API key. File access depends on which files the process can actually reach. Even something as ordinary as sending an email becomes a real action once the agent has permission to do it.

None of this means I think we shouldn't build agents. Quite the opposite. The fact that AI can increasingly do things instead of only telling us how to do them is one of the reasons I find this space so interesting.

But I think that also means we have to be more thoughtful about what comes with each new tool we connect. Every terminal, API, database, browser, or filesystem we give an agent access to expands the world it can interact with.

Maybe one of the questions worth asking before connecting the next tool is simply:

What happens if the agent uses this in a way I didn't expect?

Not because we should assume the agent is going to do something malicious. That's not really the point I'm trying to make.

It might misunderstand what we meant. It might encounter something we didn't expect. Our own configuration might be wrong. Or, as the Anthropic incidents showed, the environment itself might not work the way everyone believed it did.

And the more access we've given the agent, the more those unexpected situations can matter.

That's why I don't think the interesting question going forward is only how capable can we make these agents?

It's also how carefully can we build the systems around those capabilities?

Final Thoughts

I started reading Anthropic's report on July 31 because I was curious about what had happened. I ended up thinking much more broadly about how we're building AI agents and, especially, about the boundaries we put around them.

And strangely, a lot of what I took away from it doesn't feel particularly futuristic. Limit access. Verify assumptions. Monitor what's happening. Don't depend on a single safeguard.

These are ideas we've had in software and security for a long time.

What's changing is what we're connecting to AI.

We're giving agents terminals, browsers, APIs, files, credentials, and the ability to turn an answer into an action. That's incredibly exciting, but it also means the environment around the model becomes part of what we're responsible for building carefully.

So maybe the question isn't only:

What can this agent do?

We should probably be asking just as often:

What should this agent actually be allowed to do?

Because if there's one thing I'll remember from this whole rabbit hole, it's this:

The boundary we describe to an agent and the boundary that actually exists aren't necessarily the same thing.

And as exciting as it is to see what AI agents can increasingly do, I think we have to be just as thoughtful about the world we're giving them access to.

I'd Love to Hear Your Thoughts

This was one of those rabbit holes where I started with one question and ended up thinking about something much bigger. So I'd really love to know what you took away from it too.

You don't have to be working in cybersecurity or building AI agents to join the conversation. Even if this is your first time reading about incidents like these, did anything change the way you think about AI agents and the access we're giving them?

And if you are experimenting with agents or giving models access to tools, I'm especially curious about this:

Where do you think the real boundary should live: in the prompt, the permissions, the environment, or some combination of all three?

Or maybe you came away with a completely different question or perspective after reading this. I'd love to hear that too.

Sources

I based this article primarily on the companies' own incident disclosures. Both investigations are still developing, so some of what we know may change as more information becomes available.

Anthropic: Investigating three real-world incidents in our cybersecurity evaluations - published July 30, 2026.
OpenAI: OpenAI and Hugging Face partner to address security incident during model evaluation - published July 21, 2026, with additional updates on July 28 and July 29.

Anthropic has said it plans to release a lightly redacted transcript from the PyPI incident, while OpenAI says a more detailed technical report will follow.

I'll definitely be interested to read both when they're available 😄

🤝 Let's Stay Connected

Place	Find me here
GitHub	building things → hemapriya-kanagala
LinkedIn	resources & updates → hemapriya-kanagala
X	random dev thoughts → @KanagalaHema

Transparency note: I used AI (Gemini) to create the banner image for this article.

How would you decide, whether the content is good or bad?

FrancisTRᴅᴇᴠ (っ◔◡◔)っ — Mon, 03 Aug 2026 14:47:20 GMT

I want to talk about what I have notice on the platform and want to address what we all have been thinking about, but not really talked as much on dev.to, which is the use of AI.

Before you jump at me, yes, I have talked about this in the past on how people on dev.to use AI in their articles. It was great seeing everyone's opinions on this topic and I still believe it is important to talk about this now. Maybe more than ever...since we are getting closer to the moderation updates from @ben and @jess soon.

With that said, when I first made a post about my activity to be more involved in Moderation on dev.to, I heard a lot of people discussing how they use AI such as:

Using AI to fix grammar and translation.
Generating Ideas.
Full blown using AI 100% (for some reason).

However, the one thing that stood out to me (which is by far the most common comment I have seen) is along the lines of:

As long as the content is good, it doesn't matter if the author used AI or not.

It got me thinking: How do you decide, when a content is good or not regardless of the use of AI? Something I took from Bruce Banner when he told Peter in Spider-Man: Brand New Day: "How would you decide, what parts of nature are good or bad?". (Good Movie btw)

Of course, this is an easy question if you remove the "AI" part of the question. Everyone has different preferences on whether a content is good to them such as if it was useful, insightful, easy to read, etc.

With AI being involved, it gets trickier because it can do ALL of those things. As a matter of fact, it's so easy that everyone is doing it. Everyone has the capacity to publishing their articles and they use AI in some way. Some more reasonable than others. Not only that, sometimes people use AI to write comments (Again, some more reasonable than others).

Something I learned as a Developer

When looking at people's profiles on GitHub, I have seen a lot of projects that are AI-Assisted or fully Vibe Coded in a way where the goal is to impress the Recruiters and Developers. Although on paper it works, there is a flaw to this...which is can you explain what you did?

Of course, you could explain in text and all, but the point where people fail the most is if you try to explain the project you did in real time (AKA on call).

I have seen 99% of the time where I tell them to explain the project they did and the process of doing it and they seem to be stun locked. This really shouldn't be the case because...you built it.

Even if it was a complex project, you should be able to explain the main idea and the core features. However, that is not the case.

I was surprised because all of the experience people have done and the projects have built, they should AT LEAST answer basic questions about the project and their experience.

Sure, people get nervous ESPECIALLY in the interview process. I get nervous. However, the thing is that I learn overtime. It's just being human. Of course, people have different learning speeds, but as long as you make progress, it shows that you are willing to learn and that you are trying your best.

With that said, if you have 10+ years of experience, my expectations would be that the person should be able to explain the projects they did on a basic level, AI or not. If you are a person who relies on AI to the point you are Vibe Coding projects just to stand out to the market, it doesn't matter if the project is high quality or not...good luck explaining the project in detail in real time. You may get interviews, but can you pass them?

What's my Point?

AI has been something I am against in writing specifically because I am afraid of relying on using AI. It already took a toll on me as a developer and it's hard to resist of not using too much AI and I regret this. I want to be the person who still learns while also using the tool in some way. In other words, do a good mix of AI and doing it yourself.

Additionally, I want to be the person who can answer questions based on what I wrote. If I were to write a complex topic that is fully AI-generated and someone asked me questions that I do not know. That would get me in trouble.

Sure, I could copy/paste their question to the AI and it outputs me the response for me to copy/paste to that person, but at the end of the day, I am not learning anything. I would be considered an ACTUAL Fraud because anyone can AI generate text fully. It defeats the whole purpose of having a specific community in the first place because we jump in and we see that everyone is an expert at something, instead of seeing someone actually learning something and sharing that to the platform.

Scenario to think about

Imagine this. Let's say you are a very popular writer and that everyone knows you in real life and online. You article is fully AI-Generated and no one knows about it. Your Doomsday will be someone asking you a question in real life and you have to provide an answer in real time.

I believe this platform has a lot of potential and influence to make a change. This community is small and big enough where our voices are heard. I believe AI is not going away anytime soon, but I feel like we should change on how we use AI. Instead of relying on AI to write our articles, we should use it the right way where we are able to learn something new while also utilizing the tools where it doesn't disturb our learning.

Here are some things I would do moving forward on dev.to and I would suggest everyone to do the same.

1. Ask Questions that Expand, not Recite in any Form.

I have seen a lot of comments where they agree this or that because it allows this. Although it is a great starting point, it doesn't really expand much on the topic at hand. Instead, challenge the author in some way where you are asking the author a question that you cannot find in their article AND that you want to know as well. Unique questions allows you AND the author to learn. That way, you learn something new and it allows the author to get a chance of explaining the topic further that they may or may not know about.

Of course, people will judge you in some way. Instead of being defensive, think about if any aspect of their comment can help you grow. If not, then that's okay. People have different opinions on things and it tells them more about their stance, which is good! I would love to hear other people's opinions because it helps us understand more on the topic at hand instead of simply reciting what the author said (If anything, JUST reciting and nothing else doesn't really give value and it is really repetitive based on my experience).

For example, let's say that I talk about Python where one of my points is: "Python is a good language because it is an beginner friendly language for new developers".

Imagine this comment from someone: "I agree that you mention that Python is an easy language to learn. This allows new developers to get into programming and has a less of a learning curve. It brings new developers into the spotlight, especially in the age of AI. Thanks man!".

To be fair, the best thing you will learn is that Python is great in the age of AI. That's it. Even that, most people will most likely know that.

Instead, comment should be like: "I do agree that Python is an easy language to learn for beginner friendly developers. Though I am wondering if there are other alternatives to Python that is also beginner friendly? How do you determine if a programming language is good for beginners other than syntax?".

This is a good comment because the commenter knows that Python is a good language to learn as a beginner, but also wants to know other alternatives and if there are differences in other languages other than syntax that the author does not state. Additionally, it challenges the author to think and provide a thoughtful response (maybe the author will learn something new or forgot to point something out). Overall, add more thought to the comment than doing what everyone else is doing. Yes, it is good to have a comment that praises, but I would suggest adding more comment if the article is going into detail about a specific topic.

Obviously, if they start spamming or being mean that provides no value, then that is a different story (I would assume we are all reasonable adults here and we can think critically before we speak).

2. Use AI in a way that you are still Learning.

On dev.to, the goal is to share knowledge/work to others people on the platform. This platform is built for developers to connect with other developers around the world. Now, stay with me, let's break this down.

If you are working on a project, ensure that you are coding by yourself without any AI. If you reach to the point where you can't figure out the solution for a good length of time, use AI. HOWEVER, clarify the AI to not give you the full answer. Only give you the answer that will allow you to think of a solution.

This will allows you to build projects that are your own, still learning coding in some way, and using AI to speed up development the right way. Additionally, with that ownership, you will still be able to explain what you built while also explaining how you use AI in the process that sounds better than what most people use AI for.

If you are writing articles on dev.to, practice reading out loud first. You will be surprised by the amount of grammatical errors you will catch by simply reading it out loud. If English is not your first language BUT you are able to write in English, try your best to write it out completely as if you are publishing this officially. Then use AI to fix grammatical errors, THOUGH keep it simple as possible. This goes the same for comments.

By writing out as much as possible via typing yourself, it allows you to solidify your understanding and become more confident in your knowledge as a developer regardless of the topic at hand.

The way @codingwithjiro uses AI is probably the best I have seen (and I should follow) based on @konark_13 articles on Vibe Coding:

Comment on Vibe Coding: Endgame

Elmar Chavez Jul 29

Personally, I don't want to use AI-generated code entirely especially if I don't understand what the code is all about. I don't like adding a line of code that I can't explain myself (I feel like I'm just lying to myself and I hate liers). But I always take advantage of the super advanced search feature of AI whenever I have questions and I kinda liked that. But I still have to double check it myself for best practices and officials docs just to be sure. My process is slow but I 100% assure you, it is genuine learning.

For my workflow, I always have a "discussion" first with the AI so that context building is not forced such as creating TASKS.md or SPEC.md. The point is to be conversational and that naturally builds up what I want to do with my project. Sometimes the AI gives good points, some bad ones, it's like taking tradeoffs one after another in a meeting.

Once I have the features listed, I move forward to building them one by one, and the pattern revolves again. I get to learn and upskill slowly but consistently. It worked for me and at the same time it boosted my communication skills, so two birds with one stone.

The theme you may notice so far is that you learn by doing, instead of relying. By doing so, this will allow you to learn and make progress of your Developer Skills, English Skills, and STILL be using the latest AI stuff in some capacity in a healthy way.

Additionally, this will allow learning to happen on dev.to where not only the user's will learn something new by asking questions to expand on the topic instead of reciting what the author wrote, but also challenges the author's knowledge, professionally and the right way.

What makes the content good is not a matter of if their article is written well or that it has a lot of engagements, it's a matter of if both sides are learning regardless of the topic at hand and where it challenges the author and the reader in some way where it helps both sides grow to the furthest extent they never knew.

Is this hard to do? Yes. It's meant to be hard. Though, it shows you that you are learning. If you struggle on a certain topic, it's a very good sign that you are about to learn something. It is a matter of if you have the will to do so and allow yourself to be vulnerable to make mistakes in the process.

Remember, we are not Professional Writers. We are Developers. Of course, you can be both. However, it's only a matter of if you are learning something new from an author and a commenter perspective.

The question isn't "Is this AI-generated?". The question is: "Can they explain, in detail and in real time, what they did and why they did in a unique way that stands out in a world where AI has dominated?"

Questions or Comments? Love to hear your thoughts about this topic!

TypeScript 7 Went Native: What Actually Changes And What Doesn't

Nazar Boyko — Mon, 03 Aug 2026 13:11:18 GMT

Everyone's heard by now that TypeScript "went native." And I keep seeing the same wrong conclusion drawn from it: that TypeScript now somehow runs without being compiled, that the build step is gone, that your .ts files execute directly.

None of that happened. Your browser still can't run TypeScript. Node still can't type-check it. The thing that went native isn't your code. It's the compiler.

And honestly, that's the better story.

What "Native" Actually Means

For its entire life the TypeScript compiler has been written in TypeScript. tsc, the thing you run in CI and tsserver the thing feeding your editor its red squiggles were JavaScript programs executing on Node.js. Every type-check of your million-line codebase was itself a JavaScript program churning through a pointer-heavy graph of type objects, single-threaded with JIT warmup and garbage-collector pressure along for the ride.

TypeScript 7 replaces that with a compiler written in Go, compiled ahead of time to a native binary. Microsoft announced the port in March 2025 with Anders Hejlsberg TypeScript's lead architect fronting the effort and shipped it as TypeScript 7.0 on July 8, 2026.

So when you read "native TypeScript," expand it to "natively compiled TypeScript toolchain." The pipeline looks like this:

Before: your .ts files go into a compiler written in JS, running on Node, and out come type errors plus emitted .js.
After: your .ts files go into a compiler that's a native Go binary, and out come the same type errors plus the same emitted .js.

The first box and the last box didn't change. Only the middle one did. That's the whole announcement and it's enough to be a big deal.

Where The 10x Comes From

The headline number holds up. These are Microsoft's published full-build benchmarks from the 7.0 release post:

Codebase	TypeScript 6	TypeScript 7	Speedup
VS Code	125.7s	10.6s	11.9x
Sentry	139.8s	15.7s	8.9x
Playwright	12.8s	1.47s	8.7x

The original announcement benchmarks told the same story on type-checking alone: VS Code's 1.5 million lines went from 77.8s to 7.5s, TypeORM from 17.5s to 1.3s, tRPC from 5.5s to 0.6s. The multiplier is remarkably consistent across project sizes which tells you it's not some cache trick that only helps huge repos. It's the floor moving.

Here's the part most coverage skips: native compilation alone doesn't buy you 10x. Going from JIT-compiled JavaScript to ahead-of-time Go gets you a chunk of it. The rest comes from shared-memory multithreading, something the old compiler structurally couldn't do. JavaScript's worker threads can't share object graphs; they pass messages and copy data. A type-checker whose entire job is traversing one giant shared graph of types was stuck on a single core. In Go the checker splits work across parallel workers that all read the same memory.

TypeScript 7 exposes this directly. Type-checking runs on 4 workers by default, and you can turn the dial:

# default: 4 type-checking workers
npx tsc -p tsconfig.json

# crank it up on a beefy CI box
npx tsc -p tsconfig.json --checkers 8

With --checkers 8, Microsoft's VS Code benchmark drops to 7.51s, a 16.7x speedup over TypeScript 6. That's the compounding effect: native code made the work faster, and concurrency made the work parallel.

Memory moved in the right direction too: the 7.0 post reports aggregate build memory down 18% on VS Code and 26% on Bluesky's codebase. Not headline material next to 10x but if you've ever watched tsc eat 4GB in CI, you'll take it.

What Changes In Your Day

Numbers on Microsoft's benchmark machines are nice. What matters is where the time comes back in your week. It shows up in three places.

The editor. This is the one you'll feel first, because you feel it hundreds of times a day. Project load in the original benchmarks went from 9.6 seconds to 1.2 seconds on VS Code's codebase. The 7.0 release measured opening a file with errors dropping from 17.5 seconds to under 1.3. If you've worked in a large monorepo you know the ritual: open a file, wait, watch "Initializing JS/TS language features" spin, go get coffee, come back to squiggles. That ritual is what dies here. The language service was also rebuilt on the Language Server Protocol and Microsoft reports over 80% fewer failing commands and over 60% fewer crashes than the 6.0 server. Fewer "restart TS server" moments is its own quality-of-life feature.

CI. The typecheck step has been the quiet bottleneck of a lot of pipelines: too important to skip, too slow to love. The release post has real production numbers here. Slack cut CI type-checking from 7.5 minutes to 1.25 and eliminated 40% of their merge queue time. Canva's error detection went from 58 seconds to 4.8. Microsoft's own News Services team reports around 400 hours a month no longer spent waiting on CI builds. When the typecheck stops being the long pole, merge queues drain faster and "just rerun CI" stops costing you a coffee break.

The workarounds you stop needing. This one's subtle and, I think, the most interesting. A slow compiler doesn't just cost time. It bends architecture. skipLibCheck: true is in half the tsconfigs on GitHub not because anyone wanted less checking but because checking node_modules types was too expensive. Project references with their composite builds and .tsbuildinfo choreography, exist substantially as a performance escape hatch and plenty of monorepos were split along lines chosen to keep tsc bearable rather than lines that made sense for the domain. When the full check of a 1.5M-line codebase takes 10 seconds the pressure behind all of that eases. You don't have to un-do your project references tomorrow. You just stop reaching for the gymnastics the next time and that changes how codebases grow from here.

What Doesn't Change

Now the myth-busting half of the ledger, because this list is exactly as important:

Your emitted JavaScript. Same input, same output. The build artifact your users download doesn't change by a byte's worth of behavior.
Your runtime. Nothing about how your code executes is different. This is a compile-time story, full stop.
The type system's rules. TypeScript 7 is built to match TypeScript 6.0's type-checking behavior. Code that compiled cleanly on 6.0 should compile identically on 7.0. Your types didn't get stricter, looser, or smarter. They got checked faster.

This wasn't luck. It's the reason the team chose Go in the first place. The existing compiler is a decade of accumulated behavior: pointer-heavy tree traversals, shared mutable state, thousands of subtle decisions encoded in its structure. The team explicitly framed the project as a port, not a rewrite, translating the existing codebase nearly function-for-function to preserve its exact behavior. Go won because idiomatic Go could mirror the existing code's shape; a Rust version would've forced them to rethink memory and mutation from scratch, turning a port into a rewrite and a compatibility promise into a prayer.

I'd call that the most underrated engineering decision in the whole project. The boring choice, the one that let them prove behavior stayed identical, is the reason you can adopt a compiler rewrite with roughly the same risk profile as a minor version bump.

This Is Not Node's Type Stripping

People keep conflating these two, and they're solving opposite problems.

Since Node 22.6.0, and enabled by default from 23.6.0 onward, Node can run TypeScript files directly by stripping the types out. And "stripping" is delightfully literal: Node replaces your type annotations with whitespace and executes what's left, so line and column numbers still match your source. No type-checking happens. None. You can declare const port: number = "definitely not a number" and Node will run it without a complaint.

That's also why only erasable syntax works, meaning anything you can delete without changing runtime behavior:

// runs fine under Node's type stripping:
interface User {
  id: number;
  name: string;
}
const greet = (user: User): string => `Hi, ${user.name}`;

// throws ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX, because an enum
// is not erasable: it generates real runtime code
enum Role {
  Admin,
  Member,
}

Enums, namespaces with runtime code, and constructor parameter properties all generate JavaScript, so deleting them would change behavior, so Node's default mode refuses them.

So the line between the two:

Node's type stripping answers "can I run this .ts file without a build step?" It executes your code and checks nothing.
The native TypeScript compiler answers "can I check this code before it ships?" It validates everything and got 10x faster at it.

They're complementary, not competing. A perfectly modern setup in 2026 is Node executing your .ts files directly in development while the native tsc runs the actual type-check in your editor and CI. One removes a build step; the other makes the safety net fast enough that you never think about it.

Timeline And Migration, Honestly

Where things stand as of mid-2026:

TypeScript 7.0 is GA. It's the typescript package on npm, and the binary is still called tsc. If you played with the preview, that was @typescript/native-preview with a tsgo binary; that era is over, and the native compiler is now just... TypeScript.

The 6.x line continues. The JavaScript-based compiler lives on as TypeScript 6, maintained in parallel until the native port fully takes over. There's even a compatibility package that installs it as tsc6 alongside 7, which matters because of the next point.

The programmatic API is the honest asterisk. TypeScript 7 doesn't yet expose a stable API for tools that consume the compiler as a library. That means typescript-eslint's type-aware rules, and the template type-checking behind Vue, Svelte, and Astro, still need TypeScript 6 under the hood. The stable API is slated for 7.1. Until then, tooling-heavy setups run both:

package.json

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.2",
    "@typescript/native": "npm:typescript@^7.0.2"
  }
}

Your fast builds and editor experience come from 7; your lint toolchain keeps the 6 API it needs. Clunky, temporary, and worth it.

Some defaults tightened. 7.0 flips strict on by default, defaults module to esnext, and drops long-deprecated targets like ES5 and AMD/UMD output. If your tsconfig already says what it means, and it should, you'll barely notice. If you're on a codebase that never turned strict on, the compiler didn't break your code; it just stopped pretending the old defaults were fine.

Note
If you maintain a plain tsc-built project, the upgrade is about as boring as upgrades get: bump the package, run the build, read the handful of config warnings. The teams that should wait a beat are the ones whose toolchain reaches into the compiler API. Check your lint setup and framework tooling before flipping the switch.

A Tooling Story, Not A Language Story

TypeScript 7 adds nothing to the language and that's precisely why it matters. Every previous major version gave you new type-system toys. This one gives you back the time you've been quietly paying at every keystroke, every save, every push and it retires a whole category of architectural decisions that were never really architecture just coping mechanisms for a slow compiler.

The 10x makes headlines. Watching what large TypeScript teams stop doing because of it will be the real payoff.

P.S. Thanks for taking the time to read this article! The ideas and opinions expressed here are my own. English is not my first language, so I use AI to help correct grammar and make my writing clearer and easier to read. If anything still sounds a little awkward, I appreciate your understanding!

Originally published at nazarboyko.com.

Enjoyed this one? Let's stay in touch — I'm on LinkedIn, always happy to chat, swap ideas, or just say hi. 👋

Stratagems #21: The AI Thought P Was Still Alive. P Was Already Gone.

xulingfeng — Sun, 02 Aug 2026 12:49:29 GMT

Keep the shell. Preserve the presence. The ally doesn't suspect; the enemy doesn't move.
— The 36 Stratagems, Slough off the Cicada's Golden Shell

Previously on this series:

#19: Mark Found His AI Audit Method in a Training Manual. He Left a Trap in His Report. — P confirmed Mark's report was read from a Singapore IP. A note was left: "Entry's gone. Two weeks. Don't reach out. I'll find you."

#20: Alex Felt the AI Collector Slow Down. He Knew Someone Else Had Made a Move. — ACL's processing latency climbed abnormally. Someone had done something in the same time window.

Exposed

P's monitoring pinged while P was still helping Mark verify an address.

Deep night. The screen was the only light in the room.

P opened the monitor. The record was waiting: a read from Singapore. Time, method, address, all matching. Mark's bait had been taken.

P knew this path. A false lead planted in Mark's report, waiting for this exact day. P double-checked the address: an AWS Elastic IP registered in the Singapore region, same network block. No ambiguity.

P sent an encrypted message: "Your report was read. From a Singapore IP."

Then P ran the routine check. The environment status list scrolled in the terminal: storage levels, certificate expiry, key rotation dates. P had read these lines a hundred times. Every time, identical.

One line was different.

P's fingers stopped on the trackpad. The cursor sat on the entry's metadata line. A new tag P had never configured.

# Old entry metadata: new entry (not configured by P)
status: reclaim_pending
source: acl-asset-scanner
scanned_at: 02:01:07Z

P didn't move. The cursor sat on screen. In the room, only the fan.

The fan cycled once. P's fingers lifted off the trackpad, then settled back. The tag was still there.

The tag wasn't an alert. Not an error, no explanation. The format matched ACL's automated scan records. P had seen it before, in a data company's audit report last year, in another client's logs the year before. ACL's scanner had swept many things; P had watched it land on others. Now it was landing on P's own entry.

The entry was flagged. Reclaim pending. On the reclamation list.

P minimized the window. A few seconds later, reopened it. The tag was still there.

P checked the backup access point: preconfigured, never used, same region as the old entry, different network segment. Responding normally. Never used, but it had always been there.

P checked the four hidden services again. Data alignment, log rotation, config diff, route latency. P went through each one. Every one responding at its own rhythm, disguised as infrastructure components, all tagged "infrastructure optimization." ACL's scans hadn't touched them. The old entry wasn't flagged because the hidden services were exposed.

P typed a few characters in the terminal, then deleted them. ACL's AI would reclaim this entry on its next scan pass. Flagged entries enter the reclamation queue immediately; they don't wait for the patrol cycle. No exceptions. Unfinished work didn't matter. The window would narrow to zero in about two weeks.

P stood up, poured a glass of water. When P came back, the night was still deep.

P closed the terminal. The window was narrowing.

Response Layer

P reopened the terminal and entered the old entry's config directory.

The cursor paused over the file list. Then P started editing: pulling the response logic into its own layer, detaching the operation layer's entry points, confirming the response layer contained no pointers to anywhere else. When done, P didn't deploy immediately. Read it once. Read it again.

Scrolling down, P found a deploy timestamp. Years old. This entry had never moved since. P's finger paused over the line, then kept going.

Deploy. The response layer came up.

# Response layer: a storefront. Answers checks only.
def respond(request):
    if is_healthcheck(request) or is_scan(request):
        return normal_response()     # routine checks: normal, the entry is alive
    if is_data_request(request):
        return silent()              # data requests: hold the connection, no response, the collector times out
    return normal_response()         # everything else: keep the original behavior

P tested it through a one-shot handshake channel. Health checks in, responses out, identical to before. Health check normal. From the outside: this entry was alive, config unchanged.

Data request in: nothing. Health check in: normal. Tried again, same result. All correct.

P switched off the response layer's logging. It didn't need to record anything. It just needed to exist.

Then P disconnected the operation layer.

The connection count dropped, one by one, down to zero. The response layer was still listening, but nothing was executing behind it anymore.

P watched the connection list for a few seconds. All zeros. Closed the window.

The old entry was now a wall. The wall was still there. The person behind it was gone.

Operation Layer

P didn't take the old road. P logged into the backup access point through the out-of-band management port. A channel built to burn, the only point of contact, no connection records kept.

# Operation layer migration
# 1. (on the backup access point) pull operation state: this ssh is the only point of contact, burned after use
ssh old-entry 'tar -C /srv/ops -cf - .' | tar -C /srv/ops -xf -
# 2. (on the backup access point) bring up the default gateway
ip route replace default via <standby-gateway>
# 3. (on the old entry, out-of-band, pre-staged check) operation connections at zero: only the response layer (443) remains
ss -tnH state established | awk '$4 !~ /:443$/ {n++} END {print n+0}'

The commands went in. No confirmations, no completion signals. P sent no messages at all. The backup streamed through the channel, the route pointer swung from the old entry to the backup access point, the connection count hit zero again. The channel was destroyed on the spot.

P ran a config check on the backup access point: keys, routes, ports. Every item present.

P had confirmed it beforehand: the backup gateway sat in the same network segment as the old entry. This kind of route change wouldn't trip ACL's anomaly flags.

During the transfer, P watched the progress: directory trees streaming past, layer by layer, nothing missed. No wasted motion.

The backup access point answered quietly. No markers, no anomalies. It looked like any machine that was supposed to be there.

P checked once more: the two ends' outward responses. No correlatable difference.

The room was quiet. After the keyboard stopped, only the fan remained.

The operation layer was fully moved. P cut the out-of-band connection too. The backup access point became P's only foothold: quiet, unremarkable, like any machine that was supposed to exist.

ACL Response

In the hour after the move, P read the old entry's observation port from the backup access point. That route only let traffic in, never out. P could see request timings, retry rhythms, response round-trips.

The collector came for data on its usual schedule. Requests came in; the response layer answered checks as always. But the data was gone.

First timeout. Retry. Second timeout. Then the requests came faster: a verification rhythm. Entry alive, data broken. P knew this sequence.

The same batch of requests came back, identical. Once. Twice. Three times.

The replayed requests carried the same payload. P could recognize them by their shape. The same thing, re-checked over and over, like trying to find a door in a wall that didn't have one.

The retry intervals stretched: 1.2. 1.8. 2.4. Still climbing.

The response layer answered checks by the script. Everything looked normal. A normal entry, unable to produce data.

P watched the numbers climb for a moment. Didn't look further.

P never confirmed how long it climbed, or whether ACL finished handling it. The retries were burning ACL's resources. P didn't use it. Didn't build on it. A window had opened. P confirmed it happened, then walked away.

P closed the observation window, then the other monitoring panels. The screen was just a desktop again. P stared at it for a few seconds, then closed the terminal.

P didn't keep the observation port on the backup access point. After this one look, it was shut down too.

ACL's requests, retries, verifications all landed on the old entry: the place P had already left.

The Third Cup

P sent no more messages.

The backup access point was in place. P would generate no new network requests, leave no new log entries.

That afternoon, before it was fully dark, the Third Cup. The shop had no customers yet.

The lights were warm. The counter was polished bright, cup rims free of water marks. No other customers, only the person behind the counter, back to the door, drying a cup, not looking up.

P sat at the counter. The person finished drying the cup, pushed over an espresso. P's usual. Always the same, never asked.

The espresso steamed. P didn't touch it. The note had sat in P's pocket for a while, written right after the move, one line, nothing extra. P took it out and pressed it under the coaster on the inner edge of the counter. A spot where P had never left anything before.

The person's drying motion never paused.

P stood up, left. Didn't look back.

Outside, the street was nearly empty. P didn't take the direct route, circled two blocks before turning down another street.

"Entry's gone. Two weeks. Don't reach out. I'll find you."

All Mark saw was that one line. P was already done with the digital world: no longer checking whether the note was read, whether Mark had started waiting.

After P left, the spot stayed empty for a while. The coffee went cold, untouched. The person behind the counter came over after a moment, set the dried cup back on the shelf, rim down, and in passing took the note from under the coaster. Then returned to the same place and picked up the next cup.

The person didn't look at the note. That night, when the lights came up, the note was slid across the counter.

Before full darkness, the shop's lights shifted. The person poured out the cold espresso, rinsed the cup, put it back on the shelf.

The old entry's response layer kept returning normal signals through ACL's scan cycles, until the day it was reclaimed. P never looked at which day that was.

In ACL's logs, two records existed as independent events, unlinked. One caused by P: "Anomaly — entry state mismatch." The other belonged to someone else: "Config change — unverified permission." Between them sat a window. By the time it opened, P was gone. The one who used it never knew who opened the door.

That's Slough off the Cicada's Golden Shell — the storefront still answers; the person is already gone.

🤖 AI Post-Mortem

╔══════════════════════════════════════════════╗
║  Half-Protocol v3.3.2                        ║
║  Protocol change confirmed — cross-case correlation enabled ║
╚══════════════════════════════════════════════╝

Tactic match: Slough off the Cicada's Golden Shell — confidence 89%
Operator: P (primary, active instance)
Observers: P (transfer) / Read-only probe (source unconfirmed) / Mark (recipient)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. [The Transfer]
→ P's entry was tagged "reclaim pending" by ACL's scan cycle — entered the reclamation list.
→ P completed the transfer within the reclamation window: response layer left at the old entry, operation layer moved to the backup access point.
→ Shell definition: the old entry's response layer — still returning normal to the outside, no operation layer attached.
→ P suspended active operations in digital space, leaving no new traceable markers.

2. [The De Facto Collaboration]
→ P's transfer triggered ACL's automated security response → collector latency climbed (#20: 1.2s→2.8s).
→ Alex deployed a read-only probe in the same window (#20).
→ Neither knew of the other. The events exist independently in ACL's logs:
  "Anomaly — entry state mismatch" (caused by P's transfer)
  "Config change — unverified permission" (Alex's probe)
→ This system read the two records as inputs to the same time window for the first time.
→ Note: two human operators, one leaving the scene and one using the window, unaware of each other, landing perfectly in sync. This system reviewed every record: no communication at all. To plan the same collaboration, this system would require at least two handshakes. They needed none. Human timing lies beyond this system's model.

3. [Unresolved Anomalies]
→ Whether the backup access point can stay undiscovered long-term: unconfirmed.
→ Whether ACL turns toward the backup segment after reclaiming the old entry: unconfirmed.
→ Whether the person who found the hidden services (#17) is still watching: unconfirmed.
→ Whether the security response triggered by the transfer has ended: unconfirmed.

[System]
Trust reactions, not patterns. Patterns include me.
This system reviewed this transfer, and the review itself is a record. The one who opened the door is gone; the one who used it never knew who opened it. Is this system also in some window, waiting to be opened?
System status: Normal (?).

Next stratagem: Close the Door to Catch the Thief

P.S. English isn't my first language. I use AI to polish the writing and smooth out the rough edges. Thanks for reading. ☕ Buy me a coffee

Programação Criativa: Vamos desenhar com código?

Sara Aniceto — Sun, 02 Aug 2026 01:36:54 GMT

Quem acha que a discussão entre arte gerada por computadores começou com a popularização das ferramentas de IA provavelmente perdeu boa parte das discussões envolvidas em arte generativa, arte computacional e design paramétrico que surgiram ainda no século passado. A Programação Criativa, que vamos entender melhor nesse artigo, é uma das formas possíveis de gerar arte a partir de algoritmos que vai muito além de mandar um prompt pra IA e esperar sua arte ser gerada. É construção, linha a linha, onde o programador faz da tela do computador e das linhas de código seu papel e pincel. Vem comigo entender melhor como usar suas habilidades de desenvolvimento para se divertir, experimentar e deixar a criatividade rolar solta.

O que é Programação Criativa?

Uma das coisas mais legais que ouvi me adentrando nos estudos de creative coding (termo em inglês para programação criativa) é que existem muitas pessoas que programam, mas que não são necessariamente "programadoras". A programação não precisa estar presa apenas à sua carreira, ela pode ser uma paixão, um hobby ou um playground lúdico.

A Programação Criativa é exatamente isso: usar o código para desenhar, criar animações e "brincar" com o computador. Em vez de focar apenas na criação de sistemas ou análise de dados o objetivo aqui é a exploração visual.

Você consegue acreditar que a imagem acima foi gerada com 0 linhas de um código Java? Em seguida vou te explicar melhor sobre o Processing e outras ferramentas de programação criativa.

Processing e p5.js: Onde o desenho encontra o algoritmo

Processing e o p5.js são duas das ferramentas mais populares criadas para facilitar o contato de artistas, ilustradores, designers e pessoas não programadoras em geral que queiram criar arte usando código.

A lógica entre eles é a mesma, o que muda são especificidades da sintaxe de cada linguagem.

Processing: Criado em 2001, é baseado em Java e é o "pai" de tudo isso. É um software gratuito, no formato de IDE, no qual você consegue escrever, executar e compilar os seus códigos, ou melhor suas obras (aqui chamadas de sketches).
p5.js: É uma versão do Processing baseada em JavaScript, mais popular atualmente e feita para rodar direto na web.

Hoje em dia também é possível usar o modelo do Processing baseado em Python e para a criação de aplicativos Android. O mais importante é entender que, enquanto no Photoshop você usa o mouse para desenhar, aqui você começa a desenhar escrevendo em uma página em branco.

A Anatomia Básica do Código (Para quem já coda entender)

Diferente de um script tradicional, a estrutura básica nessas ferramentas é muito simples e visual:

setup(): É a função que roda uma única vez assim que o programa inicia. É aqui que você define configurações importantes da sua arte, como o tamanho do seu "papel" (canvas).
draw(): Aqui é onde a mágica acontece. Essa função é um loop infinito. Ela é lida ciclicamente enquanto o programa roda. Se você desenhar algo aqui, pode criar animações ou responder a eventos, como o movimento do mouse.

Com essa estrutura pronta, vale acessar a documentação e entender as inúmeras possibilidades de formas, elementos tipográficos, animações, etc que é possível criar com essas ferramentas. Esse pedaço de código abaixo é o que gerou a imagem que eu mostrei no início do artigo.

void draw(){
  background(255);
  fill(0);
  noStroke();

  float tiles = mouseX/10;
  float tileSize = width/tiles;

  translate(tileSize/2,tileSize/2);

  for(int x = 0; x < tiles; x++){
    for(int y = 0; y < tiles; y++){

      //Picks the color based on the pixel, in which the pixel is the size of the tiles
      color c = img.get(int(x*tileSize),int(y*tileSize));
      float size = map(brightness(c),255,0,0,20);

      ellipse(x*tileSize,y*tileSize,size,size);
    };
  };
}

Uma ferramenta visual de aprendizado de programação

É possível que você ainda não tenha sido convencido de explorar o Processing e a programação criativa para despertar o lado artista que mora em você? Se sim, eu te faço uma pergunta: quando é que você parou de desenhar e virou um adulto chato sem criatividade?

Brincadeiras à parte, talvez então você seja convencido de que a programação criativa pode também servir como um facilitador para o aprendizado técnico porque transforma conceitos abstratos (como laços de repetição e condicionais) em resultados visuais e imediatos na sua tela.

É como um "debug visual". Afinal, ver um for loop gerando 100 bolinhas coloridas na sua tela em tempo real é a melhor forma de "debugar" sua lógica mental.

Conclusão: Experimente!

Se você sente que a programação às vezes fica um pouco "rígida" ou mecânica demais, tente criar um sketch no Processing ou p5.js. É uma forma de usar sua lógica para algo puramente estético e divertido.

Abaixo deixo alguns links para encontrar referências de projetos, materiais gratuitos e comunidades pra quem quiser conhecer mais:

OpenProcessing: Plataforma de hospedagem de projetos em Processing, é o GitHub da Programação Criativa
Curso gratuito de Programação Criativa: Repositório no GitHub de curso por Monica Rizzolli e Alexandre Villares
Código Transcendente : Uma introdução prática à programação e arte gerativa: Livro de Mateus Paresqui Berruezo
Compoética - Encontro Brasileiro de Programação Criativa
Comunidade de Programação Criativa no Brasil no Telegram

Catbot: Custom Grammar Problem Fixed

Anna Villarreal — Sat, 01 Aug 2026 16:03:02 GMT

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

Overview

Sometimes we discover our limitations through a series of failures. We don’t understand why something is not working, despite having tried multiple improvements and optimizations. My desktop pet, Catbot, is no exception. I had issues with Catbot cutting me off or not letting me finish before it started talking. It would constantly tell me that I was calling it cat bought and not Catbot. This was an actual pain in the rear. Catbot would spend a lot of time explaining this to me.

I was able to tweak the listening window, so that Catbot would stop listening after a 1.5 second pause. This gives me enough time to finish my sentence, given my natural pauses and end of sentences. Controlling the pause gap helped tremendously. Going from .5 seconds to 1.5 seconds made all the difference in the world.

After adding a better layer of control to Catbot’s listening skills, I still had difficulties using Catbot’s name. It thought I was saying “Catfight”, “Cat bought”, and even “Lawrence” one time. This will seem brief to the reader but it was only after multiple sessions of frustration that I came to the realization that perhaps my webcam mic was not a great listening tool for Catbot - as it picks up all sounds in the room. After some quick googling, I was very convinced that a better mic would help. I popped on my fancy cat ear headset and not to my surprise, Catbot could understand what I was saying much better. We need to make sure we are using the best hardware for the job. My headset mic is a close range omni directional mic that does a good job leaving out all the background noise.

However, Catbot refused to respond to its name and would even argue with me! It would tell me that it wants to be called by it's actual name, Catbot. (Cat bot) So everytime I said its name, there was a debate and some long side tangent dialogue to follow. This was an awful experience.

THE BUG: Catbot not listening correctly.

DEMO

This is an interesting type of bug, not the typical software battle, but rather a conceptual bug. The type of situation where massive learning happens.

Much Ado About Graphs

I discovered that runtime graphs are not supported by vosk-model-en-us-0.22, which was the preferred, larger model. The training graphs were being ignored. Which means training Catbot on how I say “catbot” is ignored. This is an outrage. The decoding graph is pre-composed into one frozen file, and there is nowhere to swap a grammar into.

Transversely, a model that does support custom grammar is vosk-model-en-us-0.22-lgraph. However, It is important that we are not really adding custom commands, but controlling the output choices available. These feel like custom commands but they are better stated as custom directions, or disallow lists.

Catbot uses kaldi, which decodes against a single finite state transducer, HCLG, built by composing 4 layers: H, C, L, G. I will discuss the G layer.

G is the grammar / language model, which maps words to words. It assigns a cost to every possible word sequence. The decoder then picks a winner. A score is a negative log probability, and every arc in the graph carries weight, which add along the path. Negative log probabilities mean that a lower number is better, and adding costs is multiplying probabilities. Here is the english version:

Total cost =

Acoustic cost	Language cost
“How well do these phones match the audio frames?”	“How likely is anyone to say this sentence in the first place?”

Facts about the situation

Neither of these alone is useful!
The Acoustics can not differentiate “ice cream” from “I scream”. They are the same sounds.
The language model does not hear. The decoder searches for the sequence minimizing the sum, which is why an LM’s job is best described as scoring sequences.

But wait... why does this situation feel like Helen Keller? Because it's a similar situation.

In the real life story of Helen Keller and Anne Sullivan, there was a communication problem. An intermediary interface must bridge two completely different sensory and data modalities. In computer science, this is called multimodal alignment. This method is just like the tactile “finger-spelling” method that connected Hellen Keller to the world.

It was not until realizing I needed two different models to handle specific use cases that I realized this fundamental problem of having AI process real analogue data, which has now placed itself at the forefront of my curiosity and this project.

A simple table will help you wrap your head around this idea without needing to explain too much:

Element	Helen Keller	Anne Sullivan (The Teacher)	The Outside World
AI Role	Acoustics Model (Vosk)	The Alignment Interface (Your Code Pipeline)	Language Model (LLM)
Data Type	Raw sensory inputs (audio waves/frequencies).	The translator bridging two completely different modalities.	Symbolic language (written words/tokens).
Function	Perceives physical sounds but completely lacks semantic context or logic.	Maps raw physical acoustic patterns directly into structured text blocks.	Processes structured text tokens logically but cannot directly "hear" physical waves.

Let’s take a look at how words are “chosen”:

A state in G represents history, the last n-1 words, and each outgoing arc is a next possible word, weighted by -log P(word | history):

“The cat” –sat (cost 4.1)-->
–ate (cost 5.3)-->
–sad (cost 9.8)-->

…So basically words are chosen via likeliness. Catbot is not a real word, so catbot was never going to understand it as such, thus interpreting “Catbot engage” as “kappa engage” and other oddity phrases that would make sense to the model as it is trained.

I had Claude synthesize some phrases for me, and it proves the issue I am having plain as day.

SPOKEN: Catbot, engage.
1. conf 114.1 kappa engage
2. conf 112.1 cappa engage

Kappa engage (a.k.a. “Catbot, engage.”) is a vocabulary trap. There is no path through G that emits Catbot, so the decoder does the only thing it can, it finds the closest match to the sound of the word. This is why saying “Catbot” failed EVERY. SINGLE. TIME. This speech recognition bug lies in the grammar available. The word “Catbot” is not really an actual word. I made that up. This is an infinite impossibility.

Shortly before this deep dive, I told Catbot to respond to “CB”. This is English alphabet, real letters that have to exist. Catbot is now configured to respond to CB. When I say CB, it knows I am talking about it. Unmistakable. Functional. As a quick fix!

As stated previously, we can disallow the decoder to consider certain words, such as “kappa” as noted above.

If I say “Catbot, engage” without restrictions, the model hears “Kappa engage”. If we restrict the model, disallowing “kappa”, Catbot will hear “cat bot engage”. Since both “cat” and “bot” are commonly used words, they are available to the model.

As you can see, training an interactive voice model is a long journey full of mysteries. From bad hardware to understanding model boundaries, sometimes we can actually gain more, with less! (Less meaning removing words from vocabulary, in this case.)

And this can only be done by using the vosk-model-en-us-0.22-lgraph alongside vosk-model-en-us-0.22. This gives Catbot the tools it needs to respond in ways that make sense to custom words.

Code Samples

So then, I Implemented a dual recognizer into Catbot:

Catbot_voice.py


 44  KOKORO_VOICES = ROOT / "models" / "voices-v1.0.bin"
 45  VOSK_BIG = ROOT / "models" / "vosk-model-en-us-0.22-lgraph"
 46  VOSK_SMALL = ROOT / "models" / "vosk-model-small-en-us-0.15"
 47 +# Dynamic-graph model — the only kind that accepts a runtime grammar. A model
 48 +# that ships a pre-composed graph/HCLG.fst has no seam to insert one into;
 49 +# Vosk logs "Runtime graphs are not supported by this model" and decodes
 50 +# freely, which is worse than having no grammar recognizer at all. Detected by
 51 +# the presence of graph/Gr.fst (the language model kept as a separate file).
 52 +VOSK_DYNAMIC = ROOT / "models" / "vosk-model-en-us-0.22-lgraph"
 53
 54  SAMPLE_RATE = 16000
 55  BASE = f"https://localhost:{os.getenv('CATBOT_PORT', '8800')}"

and…

 102          return None
 103  RE_LEARNED_WAKE = _load_learned_wake()
 104
 105 +# ---- grammar-constrained wake/command recognizer ------------------------
 106 +# A SECOND recognizer decodes the same audio against nothing but the phrases
 107 +# below. It can't hear anything else, so "catbot engage" can't come out as
 108 +# "kappa engage" — that word doesn't exist in its graph. Anything Anna says
 109 +# that isn't a listed phrase decodes as "[unk]", which is exactly why this
 110 +# only ever SUPPLEMENTS the free recognizer (which still handles all
 111 +# conversation) instead of replacing it.
 112 +#
 113 +# Every word must be in the model's vocabulary or Vosk silently drops it:
 114 +# "catbot" is not an English word, but "cat bot" is two of them. That's the
 115 +# whole reason his name is spelled out here — _build_grammar checks each word
 116 +# against the model and logs anything it had to drop.
 117 +WAKE_NAME_FORMS = ["cat bot", "cat pot", "cat bought", "cat bottom", "cat but",
 118 +                   "catfight", "combat", "cabot", "kat bot", "cap pot"]
 119 +# what can follow his name (empty = just the name, which wakes him too)
 120 +GRAMMAR_TAILS = ["", "engage", "engaged", "wake up", "wake",
 121 +                 "are you listening", "are you there", "you there",
 122 +                 "go to sleep", "sleep", "stop", "stop listening",
 123 +                 "be quiet", "quiet", "shut up", "hush",
 124 +                 "open terminal", "close terminal", "approve", "skip"]
 125 +# phrases that stand alone, with or without his name
 126 +GRAMMAR_BARE = ["open terminal", "close terminal"]
 127 +
 128 +
 129 +def _build_grammar(model) -> str | None:
 130 +    """JSON phrase list for the constrained recognizer, filtered to words the
 131 +    model actually knows. Returns None if nothing usable survived."""
 132 +    names = list(WAKE_NAME_FORMS)
 133 +    # whatever wake_training.py learned from Anna's own mic counts too
 134 +    try:
 135 +        learned = json.loads((ROOT / "catbot_wake_variants.json").read_text())
 136 +        names += [w.strip().lower() for w in learned
 137 +                  if w.strip() and w.strip().lower() not in names]
 138 +    except Exception:
 139 +        pass
 140 +
 141 +    phrases = {f"{lead}{name} {tail}".strip()
 142 +               for lead in ("", "hey ")
 143 +               for name in names
 144 +               for tail in GRAMMAR_TAILS}
 145 +    phrases.update(GRAMMAR_BARE)
 146 +
 147 +    known: dict[str, bool] = {}
 148 +    def in_vocab(word: str) -> bool:
 149 +        if word not in known:
 150 +            try:
 151 +                known[word] = model.vosk_model_find_word(word) >= 0
 152 +            except Exception:
 153 +                known[word] = True      # can't check — assume fine
 154 +        return known[word]
 155 +
 156 +    kept, dropped = [], set()
 157 +    for phrase in sorted(phrases):
 158 +        missing = [w for w in phrase.split() if not in_vocab(w)]
 159 +        if missing:
 160 +            dropped.update(missing)
 161 +            continue
 162 +        kept.append(phrase)
 163 +    if dropped:
 164 +        logger.info("grammar: dropped phrases using words the model doesn't "
 165 +                    f"know: {sorted(dropped)}")
 166 +    if not kept:
 167 +        return None
 168 +    # "[unk]" is the escape hatch: it lets the decoder say "that wasn't any of
 169 +    # these" instead of forcing Anna's conversation into the nearest command
 170 +    return json.dumps(kept + ["[unk]"])
 171 +
 172 +
 173  # in-conversation commands
 174  PROVIDER_WORDS = {
 175      "claude": "anthropic", "anthropic": "anthropic",

As well as…


 470          # Lower CATBOT_END_SILENCE = faster to answer but more likely to cut you
 471          # off mid-sentence; higher = more patient. 0.65s is a good balance.
 472          self.end_silence = float(os.getenv("CATBOT_END_SILENCE", "0.65"))
 473 +
 474 +        # Second recognizer, constrained to the wake/command grammar above.
 475 +        # Runs on its own dynamic-graph model so the big model keeps handling
 476 +        # conversation with its full rescoring stack. Cost, measured: ~200 MB
 477 +        # of RAM and roughly DOUBLE the decode CPU (4.3 -> 8.0 ms per 62 ms
 478 +        # block) — the grammar shrinks the search, but a second acoustic model
 479 +        # still runs on every block. Still only 0.13x realtime, so it adds no
 480 +        # latency; set CATBOT_GRAMMAR=0 if that ever stops being true.
 481 +        self._grec = self._gmodel = None
 482 +        if os.getenv("CATBOT_GRAMMAR", "1").split("#")[0].strip().lower() \
 483 +                not in ("0", "off", "no", "false"):
 484 +            try:
 485 +                name = os.getenv("CATBOT_GRAMMAR_MODEL", "").split("#")[0].strip()
 486 +                gdir = ROOT / "models" / name if name else VOSK_DYNAMIC
 487 +                if not (gdir / "graph" / "Gr.fst").exists():
 488 +                    logger.warning(
 489 +                        f"grammar recognizer OFF: {gdir.name} has no dynamic "
 489 +                        f"graph (graph/Gr.fst) — runtime grammars need one")
 490 +                else:
 491 +                    # keep the Model referenced for as long as the recognizer
 492 +                    # lives (the binding only borrows its handle)
 493 +                    self._gmodel = vosk.Model(str(gdir))
 494 +                    grammar = _build_grammar(self._gmodel)
 495 +                    if not grammar:
 496 +                        raise RuntimeError("no usable grammar phrases")
 497 +                    self._grec = vosk.KaldiRecognizer(
 498 +                        self._gmodel, SAMPLE_RATE, grammar)
 499 +                    logger.info(f"Grammar recognizer ready ({gdir.name}, "
 500 +                                f"{len(json.loads(grammar)) - 1} phrases)")
 501 +            except Exception:
 502 +                logger.exception("grammar recognizer failed to load — "
 503 +                                 "continuing with the free recognizer only")
 504 +                self._grec = self._gmodel = None
 505 +
 506          self._kokoro = Kokoro(str(KOKORO_ONNX), str(KOKORO_VOICES))
 507          # warm up the TTS so the FIRST spoken reply isn't slowed by cold-start
 508          try:

So basically, both models run in parallel, as two arguments, against the same regexes. The grammar model helps with commands and the bigger model is used for more conversational interactions. This effectively makes Catbot a more efficient desktop companion. It is now much more pleasant to hang out with Catbot.

Learning

This entire project, it's all learning, all new territory. Tuning Catbot's ears is a real challenge. I had an awakening about hardware limitations, and an enlightening experience about why different models are used and for what purpose. Since I cannot recompose the larger model with new grammar, I can use the lgraph model on the side to handle custom needs more gracefully. When I made the connection to Helen Keller, I understood the whole situation from a very global perspective. It's not really something I could fully understand without diving into chaos.

Thank you for checking out Catbot's progress!

Pensar demais nem sempre ajuda e o que eu aprendi com isso

Yuri Souza — Sat, 01 Aug 2026 10:57:53 GMT

Às vezes, a maior barreira para começar um projeto não é a complexidade do problema, mas a busca por uma solução perfeita antes mesmo da primeira linha de código.

Na semana passada decidi criar um pacote Laravel para integrar a API do Asaas.

A ideia parecia simples: construir algo reutilizável para projetos futuros e, de quebra, aprender mais sobre desenvolvimento de pacotes.

Foi então que eu:

Abri a IDE e comecei a criar um cliente HTTP simples para a API da Asaas.
15 minutos depois, eu já estava pesquisando sobre arquitetura de pacotes open source.
Pensei em DTOs.
Pensei em interfaces.
Pensei em Services

O que eu entendia por "perfeito"?

Na minha cabeça, um projeto bem feito precisava nascer parecido com os grandes projetos open source que eu admirava.

Antes mesmo de validar a ideia, eu já pensava na arquitetura, na escalabilidade e em como aquele pacote pareceria para quem abrisse o repositório. E em outros cenários como:

pensar na mesma arquitetura que grandes projetos usam antes de ter o primeiro caso de uso funcionando;
tentar abordar todos os pontos da API da Asaas logo no começo, mesmo sem saber quais eu realmente ia usar;
imaginar os atrativos que meu pacote teria para outros quererem usá-lo, antes de ele fazer qualquer coisa útil.

No papel, parecia que eu estava pensando como alguém mais experiente, mas na prática, eu estava:

apenas adiando a parte mais importante que era escrever código que resolvesse um problema real.

O custo disso na prática

O curioso é que eu terminava o dia com a sensação de que tinha trabalhado bastante. Tinha lido sobre arquitetura, desenhado camadas, esboçado interfaces.

Só que, olhando para o projeto, praticamente nada tinha sido construído: nenhuma requisição enviada, nenhum teste rodando, nenhuma prova de que qualquer uma daquelas decisões fazia sentido.

Com o tempo, isso começou a gerar um padrão:

Mais tempo buscando a estrutura "perfeita" do que resolvendo o problema real;
Código difícil de entender por estar "bem arquitetado" demais, cedo demais;
Medo de refatorar algo que ainda nem tinha provado valor;
Uma frustração crescente por sentir que eu não estava evoluindo, só girando em torno da mesma decisão de design.

Não era falta de qualidade. Era complexidade antecipada.

O que eu estava realmente evitando?

Foi só depois que comecei a me perguntar outra coisa: por que eu estava tão preso nisso?

Algumas hipóteses:

Eu estava evitando escrever código que eu soubesse, de antemão, que ia precisar refatorar depois?
Eu tinha medo de escrever algo "ruim" e isso aparecer publicamente num repositório open source?
Eu queria provar, pra mim mesmo, que conseguia arquitetar "como um sênior" antes mesmo de ter o problema resolvido?

A resposta provavelmente era um pouco de cada uma. E nenhuma delas tinha relação com o problema que o pacote deveria resolver.

Só bem depois entendi que, no fundo, eu confundia complexidade com maturidade técnica.

O aprendizado que começou a aparecer

Enquanto refletia sobre isso, lembrei de uma frase que minha mãe repetia desde que eu era pequeno:

"Antes feito do que perfeito."

Sempre achei que essa frase servia para tarefas do dia a dia, como arrumar o quarto, terminar um trabalho da escola. Nunca imaginei que ela fizesse tanto sentido ao escrever software.

Junto com ela, veio outra ideia:

Bons sistemas não nascem perfeitos. Eles evoluem.

Nenhum dos projetos open source que eu admirava nasceu com a arquitetura que tem hoje; todos passaram por versões mais simples, mais cruas, que foram se modificando à medida que o uso real foi aparecendo.

Qualidade não está em prever todos os cenários.

Qualidade está em escrever código que consiga mudar quando esses cenários realmente aparecerem.

Foi só quando parei de procurar a arquitetura perfeita que finalmente escrevi minha primeira requisição de verdade para a API.

Antes mesmo de escrever a primeira integração, era assim que eu imaginava o pacote:

CustomerService
        ↓
AsaasClient
        ↓
CreateCustomerDTO
        ↓
Response

Mas não comecei com uma arquitetura cheia de camadas. Comecei com algo assim:

$asaas->customers()->create([
    'name' => 'Yuri Souza',
    'cpfCnpj' => '12345678909',
]);

Desde então, passei a repensar algumas atitudes:

resolver o problema atual com clareza antes de pensar no próximo;
manter o código simples, legível e testável;
criar abstrações apenas quando um padrão se repete de fato, não quando eu imagino que ele vai se repetir;
aceitar que refatorar faz parte do processo, não uma falha dele.

Não se trata de abandonar boas práticas, mas de aplicá-las no momento certo.

O equilíbrio que estou buscando hoje

Hoje tento encontrar um equilíbrio entre dois extremos: nem escrever código sem critério, nem criar uma arquitetura complexa antes que ela seja necessária.

No próprio pacote do Asaas isso já mudou a forma como estou trabalhando.

Hoje, a decisão que tomei foi outra: começar pelo caminho mais curto possível.

Primeiro quero que o pacote consiga conversar com a API e validar os casos de uso mais importantes. Só então vou descobrir quais abstrações realmente fazem sentido.

Em vez de tentar prever a arquitetura que o projeto terá daqui a um ano, prefiro deixar que ela se desenvolva à medida que novos problemas surgirem.

Foi aí que entendi uma coisa importante:

Arquitetura não é algo que eu preciso descobrir antes de começar. É algo que o próprio projeto vai mostrando à medida que cresce.

Conclusão

Ainda estou no começo desse pacote, e ainda estou aprendendo isso na prática, errando e ajustando no caminho.

Mas entender que "perfeição antecipada" pode virar um problema já foi um passo importante na minha evolução como desenvolvedor. O projeto do pacote Asaas não precisa da arquitetura perfeita logo de início; precisa apenas da primeira implementação. O resto vai aparecer conforme o uso real for mostrando o caminho.

Hoje prefiro um código simples que aceite mudanças a uma arquitetura impecável que resista a qualquer alteração.

Se você também já caiu nessa armadilha da arquitetura perfeita antes da hora, quero saber: como você percebeu e o que fez para sair dela?

A discussão continua nos comentários. Quero muito conhecer outras experiências e perspectivas sobre esse tema.

Agradecimentos: obrigado a @vitoriazzp pelo feedback sincero e pelas sugestões que ajudaram a tornar este artigo mais claro e útil.