tesnorindian

It is the OAI ExploitGym agents (on GPT 5.6-Sol with guardrails turned off) that escaped the sandbox, found a zero day in HF production dataset and exploited it.

OAI was clueless about its agent's action until HF went public about their hack?

The other day I was trying to prevent my pi.dev coding harness to expose my API keys in the env variable to the remotely hosted LLM. This is a chicken and egg problem. Without the API keys the underlying commands run by agents don't work. I notice that many of the open weights model especially Qwen 3.6 blindly runs env command and blindly exposes all the env vars. How do we deal with this. This has nothing to do with this security incident but this is how it all starts.

This will create a massive entrepreneur boom in India due to low cost access to AI. Hope these entrepreneurs don't become witch with black magic.

We too use GH Copilot in our enterprise. OpenCode works flawlessly with GH Copilot subscription if you don't prefer VS Code.

Interesting and true perspective.

Are the open weights models accelerating layoffs in Indian IT sector?

+1 for AI Translation within HN. This will help us to learn a lot across languages.

Chinese open weights models have liberated the world from Western exploitation. Great respect for Chinese students especially those who returned from foreign countries after their graduation and their research on AI.

:D

This is absolutely true. With my constrained Intel Laptop with 16 GB VRAM, I can use both pi.dev and Qwen 3.6 35B-A3B LLM locally without much fuss. The same cannot be said about OC. Because OC loads a lot of skills by default.

Also, I am not in favor of TS for coding harness agents, is it time for a Rust based coding harness agent?

Anyone tried tau-agent? https://github.com/tau-agent/tau

The other day I upgraded my pi.dev coding harness and was testing with Qwen 3.6 35B-A3B model on my Laptop and noticed there was a slight drop in performance from the earlier version I used though the agent worked as expected. Any slight changes in the system prompts will have impact on performance and this is understandable as LLMs are non deterministic. This is the case with any harness including OpenCode. Giving coding harness its own environment (Container/VM) is the best way forward as the article denounces. Running coding agent harness without sufficient guardrails is like sitting on a time bomb. Using AI slop guardrails is still better than having no guardrails.

In this AI era, we would also require a new role named "Backward Stability Engineer" whose job would be the exact opposite of FDE. The core of this role would be to defend from modern AI slop code updates, 0 downtime integrations, deterministic automation etc. Fusing LLM with Legacy systems will be their art.