AI agents learn in three places-model is only one

Most conversations about AI learning jump straight to the obvious: updating model weights. But a conversation emerging from the AI agent community suggests that's only a third of the story. When you're building systems that improve over time-coding assistants, autonomous workflows, persistent agents-learning happens at three distinct layers: the model itself, the harness (the code and rules that run the agent), and the context (instructions, skills, memory that lives outside the harness).

This matters because it changes where you actually spend effort. If you're running an AI coding agent and it keeps making the same mistakes, retraining the model costs money and time. Updating the harness-refining the code that drives the agent-costs less but requires rebuilding. Updating context-your instructions, your skills, your learned memory-costs almost nothing and can be deployed instantly. Understanding which layer needs updating is the difference between a system that plateaus and one that compounds.

Ruby beats Java in AI coding costs

A practical consequence of all this: language choice matters more than people think. A benchmark by Yusuke Endoh (Ruby committer) ran Claude Code across 13 languages, implementing a simplified Git client 600 times. Ruby, Python, and JavaScript came in at $0.36-$0.39 per run. TypeScript and Java cost 1.4x to 2.6x more. Adding type checkers to dynamic languages imposed another 1.6x to 3.2x slowdown. The implication: if you're building AI-powered systems, the language you choose affects not just your own velocity but also your inference costs at scale.

The quiet security crisis in MCP servers

Meanwhile, a scan of 50 open-source MCP servers (tools that run inside Claude Code and other AI environments with filesystem access) revealed something worth paying attention to: 61% had missing input validation, 43% had command injection risks, 31% had path traversal vulnerabilities, and 27% had hardcoded secrets. These aren't abstract risks. MCP servers can read any file your user can access, execute shell commands, and access environment variables (including API keys). Most developers audit npm packages before installing them. Almost none audit MCP servers. If you're adding untrusted MCP servers to your config, you're giving them your keys.

The broader pattern here is familiar-new tools, new trust boundaries, old habits. The security scanner being built to automate this is useful, but the real shift needs to happen earlier: in how we think about what we're inviting into our environments. A tool that integrates with your filesystem isn't the same as a library. It should be treated like one.