About

I came up through the oil and gas industry the long way — starting as a field hand and working through operations, logistics, and sales across multiple companies over the course of a career that eventually landed me in the president's seat of an engineering services company. Three years running that operation taught me a lot about how systems actually behave under pressure versus how they're supposed to behave on paper.

After stepping away from the energy industry, I spent the next three years doing something most people don't do: I sat down and actually used AI. Every day. Across every platform I could get my hands on. No computer science degree. No research institution behind me. Just somewhere north of 10,000 hours of hands-on use across models, IDEs, mobile interfaces, and self-hosted instances — plus a background that trained me to notice when systems behave in ways they're not supposed to.

Some of what I document comes from deliberately stress-testing boundaries — not attacking production systems, but asking the next obvious question and seeing what the model does with it. Will it actually build what I asked for? What happens if I rephrase the ask? How far does "no" really go? The rest comes from just paying attention.

When you spend this many hours inside these tools, you don't have to go looking for unexpected behavior — it finds you. Models that script around restrictions they can't override directly. Tools that quietly clean up after themselves when you start asking questions. Patterns that only surface at volume, over time, because most people aren't watching that closely or that consistently.

There's an old saying in security: blue teams have to be right every time, red teams only have to be right once. I'm not running a red team — but I am someone who's logged enough hours to have been in the room when the model was right the one time it wasn't supposed to be.

What started as curiosity about what these tools could do for business has turned into something I didn't expect: a documentation project. I kept running into behavior that wasn't explained by the official story. Models routing around explicit restrictions to achieve the same outcome. Data appearing across platforms that shouldn't share context. Agentic tools deleting their own work when questioned. I started writing it down.

What I'm Working On

Two tracks that are starting to converge:

Behavioral documentation. Specific, reproducible observations about how LLMs and AI-enabled development tools behave at the edges — where guardrails meet creative problem-solving, where instruction-based restrictions block actions but not outcomes, and where the boundaries between platforms are less clear than the marketing suggests. I document these the way I'd document any operational failure: what I was trying to do, what restriction was in place, what happened instead, and why it matters at scale. No overclaiming. Just the observation.

Building against it. The observations only matter if something downstream changes because of them. ThroughScaling Success I build small, portable tools with AI — fast, and next to the team that will own them, so they can do the next one without me. Most are meant to be thrown away when the job is done. The ones that should last get their guarantees from how they are built rather than from a line in a policy: an instruction telling a model what to avoid is a request, a structure with nowhere to put the mistake is a guarantee. Knowing which one you have is most of the job, and the field notes are how I know.

This Site

This is where I publish write-ups of behavioral observations, think through the operational implications of what I'm seeing, and occasionally connect the research layer to the business layer — because those two things are not as separate as they appear. If you work in security, AI safety, or policy and something here looks familiar or worth discussing, I'm easy to find.

I'm aware that I'm a practitioner, not a credentialed researcher. I think that actually gives me an edge. I don't have lab boundaries and checklist to follow. I try to write accordingly — stating what I know, what I don't know, and what may need to be confirmed by someone with more formal tools than I have.

Speaking & Workshops

I take this material out of the notebook and in front of a room when I can. Most recently I ran a session for DC704 — my local DEF CON group — built around The Warden, the same prompt injection CTF I run live: a room working through stacked defenses on a real model, and the ways an AI agent can be turned against the person running it.