AI agents have two layers. One layer is frozen. That is the model. For most teams, the weights sit behind an API. You do not change them. The other layer is yours. That is the skill, the system prompt, the instruction file, the agent memory, the procedural guide that tells
A developer installs a package. Maybe it came from npm. Maybe it came from a README. Maybe it came from a tool an AI coding agent pulled into the workflow because it needed to get a test passing. Everything looks normal. The install finishes. The project builds. The terminal goes
A developer asks an AI agent to fix a failing test. The agent reads the error, opens a few files, edits some middleware, runs the test again, installs a package, changes a config value, and eventually gets everything green. The pull request looks fine. The diff is not huge. The
AI agents are changing shape. A year ago, most engineering teams still thought about AI as something that lived in the editor: autocomplete, chat, maybe a refactor when you asked nicely. Useful, sometimes surprising, but still mostly bound by the developer sitting in front of it. That boundary is getting
Most agent setups today are stuck in a weird local maximum. They have good tools. They can read code, run commands, open files, and get a surprising amount done. But every session still starts from zero. Every task begins with the same re-onboarding loop. The agent rereads the repo, relearns
A developer asks an AI assistant for a simple API endpoint. The model writes it in seconds. The query is vulnerable. The auth check is missing. The response includes fields that should never leave the server. Nobody notices at first because it looks close enough, the diff is small, and
AI is changing how software gets built. That part is no longer up for debate. Agents are already writing code, editing files, wiring together features, installing packages, and moving through projects with a speed that would have felt ridiculous a year ago. The interesting question now is not whether this
AI agents are getting more capable by the week. They write code, manage infrastructure, browse the web, and run shell commands on your behalf. That is useful. It is also a new attack surface. One of the clearest examples is the skill file: the markdown instructions that tell an agent
Software is changing faster than most teams realize. Not incrementally. Structurally. Here is a data point that caught my attention recently: a team at OpenAI shipped an internal beta built with zero lines of manually written code link. It reached daily use, grew to roughly a million lines of code
We're building Sandstrike, a machine-learning classifier that scans newly published npm and PyPI packages for supply-chain malware. Every 15 minutes, it pulls the latest packages from both registries, extracts features, and runs inference. Suspicious packages get flagged to Slack. The model is good, but it's not
Something fundamental is changing in how software gets built. For decades, the loop looked basically the same: humans write requirements, humans write code, humans test it, humans deploy it. AI has been nibbling at each step for years, with autocomplete here and a generated test there. But what’s showing
If you have spent any time with AI coding agents, you already know the obvious wins: scaffolding projects, writing glue code, churning out boilerplate. I wanted to push on something different. So I built REPLICATE, a digital museum of the history of self-replicating code, spanning seven exhibits from 1949–1988.
AI coding is fast. Security feedback is usually not. Most SAST runs after the code is written, committed, and pushed. With Claude Code, that gap gets painful because the model can generate vulnerabilities just as quickly as it generates features. We wanted the tightest possible loop: write code → scan it
News
This is Turen Labs Blog, a brand new site by Tom Bowyer that's just getting started. Things will be up and running here shortly, but you can subscribe in the meantime if you'd like to stay up to date and receive emails when new content is