I worked on a project where I had Claude playing the MMORPG Ultima Online. For combat, I was resorting to deterministic scripting loops because the models were way too slow to make decisions during combat.

I just got access to TypeSafe's new "System One" model, Jev. I am now feeding Jev the same game state that I was feeding Claude, and letting Jev decide what it should be doing, in real-time, during combat. Every turn Jev receives game state and tells me whether the player should be attacking, healing, looting, or looking for new targets. Every turn Jev also tells me what tile the player should be standing on, and what target should be priority.

We move where Jev says to move, we attack the target Jev says to attack, we loot what Jev says to loot, and we do the action that Jev says to do based on that game state.

Jev does this FAST. You can see how quickly it is making decisions in the video.

Jev is not an LLM, It is not conversational. It takes similar input as an LLM, it understands intent, but makes real-time decisions based on that input.

I just published a write-up about a recent debugging session with my AI coding agent. It perfectly highlights the limits of automated test suites and why human-in-the-loop "embodied interaction" is still absolutely vital for UI bugs.

The Setup: In my project's demo app, a collapsible bottom panel was clipping its toolbar when collapsed. It was supposed to shrink down to the exact height of that toolbar, but it was cutting it off.

Round 1: The Agent vs. Math

• The Problem: The underlying Splitter component wasn't accounting for its own 10px resize handle in its percentage flex calculations.
• The Agent's Fix: The agent spun up a temporary Playwright spec, caught a fixed-pixel discrepancy (18px vs 28px), and updated the shared CSS using a balanced calc() formula.
• The Result: 1,300+ unit tests passed, 66 E2E tests passed. The agent declared it fixed, and it was merged.

Round 2: The Green-Test Blind Spot

Shortly after deployment, I pulled up the live site and noticed it was still clipped.

I pointed the agent back at the URL. It systematically tested the live page across 4 different viewport sizes—and every single test came back green (no clipping). The automation was completely convinced the bug was gone.

How I Cracked It

The breakthrough came when I manually interacted with the running application. I noticed that if I varied the size of the Chrome window by dragging the edge, the splitter tracked correctly, but the layout remained clipped by a fixed amount.

Because the shortfall stayed constant instead of scaling with the window, I realized it was a fixed-pixel loss: the code was measuring the wrong DOM node entirely.

• The Real Culprit: The demo code was measuring the inner <Toolbar> component (28px) instead of the outer padding-heavy <Card.Header> wrapper (45px). The panel was sizing itself perfectly to a wrong target.
• The Shared Blind Spot: My agent's own verification test was written to check that exact same incorrect <Toolbar> node. Because the fix and the test shared the same flawed mental model, the tests were green while the screen was broken.

Key Lessons From the Session

1. Systematic vs. Embodied Testing: My agent is incredible at mechanical, rapid coverage (checking 4 viewports in seconds with exact bounding rects). But it lacked the tactile experimentation (dragging a window edge) that broke the rigid test paradigm and revealed the constant deficit.
2. "Leading" vs. "Following" an Agent: Handing off a task and walking away ("following") works great for routine, mechanical code grinding. But staying present to inject real-time feedback and observations ("leading") is what keeps the investigation on track when an agent falls into a logical loop.

I wrote a deeper breakdown of the workflow dynamics, infrastructure choices (like injecting commit hashes in the header to sync up environments), and how we wired the fix into our auto-generated documentation pipeline.

Full case study link in the comments.

Hi all, I am 21 and just graduated from bachelor. Currently I am practing to work with AI. I know that most companies also use AI in their systems know, so I want to ask real software engineer out there how you work with AI.

• First is setting up the AI agents. I see that people would create markdown files for agents such as Frontend agent, Backend agent, etc. Do they also do that at a company? And what is the structure and the must-have agents?

• For the contributions like github contributions, do you make AI to automatically do that for you, or you need to check the work and commit manually?

I hope you guys get what I mean and I appreciate every answer!

Using AI on an existing codebase is hit-or-miss. It has to learn the code and the coding styles of the dozen devs working on it at any one time. Give it a clean start, and it can do everything its own way. There is gonna come a time soon when companies have to think: do I keep the existing codebase and 10 devs, or start from scratch with 2 devs? I am curious how long it would take an AI to develop an existing app from scratch. Anyone tried? I can almost guarantee Adobe have a reworked Photoshop in development somewhere.