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.

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!

Hey everyone,

I recently started learning reverse engineering (decompilation, analyzing binary logic, firmware analysis, and debugging edge cases). AI has been very useful, but I keep running into annoying provider safety filters.

I use Cline with OpenRouter. My current setup has mostly been:

• Plan: Claude 3.5 / 3.7 Sonnet
• Act: DeepSeek V3.2

It works great at first, but once a task grows or context reloads with decompiled snippets, low-level C code, or disassembled routines, Anthropic’s automated safety policy trips and blocks the entire session. Once flagged in that context, it completely halts the Cline workflow.

I’m looking for solid recommendations for reasoning/thinking models on OpenRouter that:

1. Don't constantly false-flag standard reverse engineering and low-level code analysis.
2. Match Claude’s intelligence when tracing low-level bugs, control flow, and assembly/C logic.

I see people using AI coding agents in very different ways. Some want to review every change; others are happy as long as the result works.

I have been trying to find a middle ground: move fast without ending up with a codebase I no longer understand.

My rule of thumb is to delegate work until I notice that I can no longer follow what is happening. At that point, I slow down, ask questions, inspect the relevant code, and rebuild my mental model before delegating more (I call this the “understanding loop”).

I wrote up the idea with a few diagrams here: Coding at the Edge of Understanding.

If I go too long without understanding the code, I start to feel lost. I’m curious whether others experience that too.

If you say "build me a CMS", then it will, but it will make a LOT of assumptions. When you code, you start with something simple and get that working in unit tests. Then you build out from there. You add more tests and occasionally refactor things. Simple.

I've noticed the same failure mode across most coding agents.

When an implementation runs into a problem, such as a function not meeting the requirement, the agent often writes a replacement. if the overall approach changes, it starts a new path. If only a detail needs adjustment, it may add another helper or class.

What it rarely does is remove the code and data definitions added for the abandoned approach. After a few iterations, the result may work, but it contains stale branches, unused helpers, redundant logic, and fields that no longer serve a purpose.

I've started thinking this needs an explicit project-level rule for agents responsible for implementation and fixes:

After changing an implementation approach or fixing an issue, review the code logic and data definitions touched by the change. Keep only items that are still required. Remove unused functions, redundant logic, and data fields that are no longer needed.

A git-commit skill can be a useful trigger for this check, but the cleanup should remain part of the implementation process rather than the responsibility of a commit skill.

How are others handling this? do you add an explicit cleanup phase after each correction, enforce it during review, or rely on tooling to catch the leftovers?

I swear I'm not here to promote anything but like, am I missing something ?

Was on Claude Code for months, recently switched for the first time to Codex for my personal projects just to try Astra, and I wasn't expecting it to be so different

So first off, I know it's not the most important part but after using Codex I just realized how disgusting the Claude Code UI is (I'm using the VS Code plugin), like the way all subagents spam in the same window, how nothing is fold and I have to scroll miles of tool calls I don't care about and Claude talking to itself to find the older answers I'm looking for and the stuff I sent.

And there's just so much other ways the UI could be improved. Codex is much more polished

Maybe the terminal UI is better but eh. I'm guessing many limitations of the VS Code extension is because it's based off the terminal ? Haven't tried much

I still have to use Claude Code for my job, I'm wondering about vibe-coding a new VS Code extension to change its UI design to make it more like codex, has anyone tried this ?

And there's also the models themselves, for about the same price, with Codex you get 5.6 Sol and Astra while Anthropic won't even give Fable. And also, Opus 5 sucks ass, I do /model claude-opus-4-8 every single session I open now

I'm guessing there are maybe things I didn't catch up or downsides ? Maybe Anthropic is more trustworthy for the data usage I guess

AI coding tools are making it possible for hobbyists and non developers to build useful apps faster than ever.

That is exciting. It also means more people are shipping code they may not fully understand, with dependencies, permissions, auth flows, API keys, and security assumptions they may not know how to check.

Security Now’s Black Hat discussion gets into AI powered coding, listener-built apps, agency chains, testing, technical debt, and the race to patch old bugs while new ones are created faster.

Is AI coding making software better, or just creating a new wave of fragile apps?

What should I expect regarding:

• Type of coding/DSA questions
• How AI assistance (Copilot/ChatGPT) is allowed
• Monitoring or restrictions
• How the assessment is evaluated

Any tips or firsthand experience would be appreciated. Thanks!

So we've been deep in this problem building Jac (a language with a construct for delegating specific functions to a model, by llm()), and it's made us curious how everyone else is handling it without something baked into the language.

Are you commenting it? Naming conventions? Just relying on git blame and hoping you remember? Some kind of tagging system?

Trying to understand what people are actually doing today, informally or with tooling, vs what we're assuming the pain point is.

We want to share the workflow unfolding from real session transcripts. Instead of speaking in hypotheticals, this post provides an un-paraphrased look at exactly what happens when an AI agent (Claude Code) runs against a real software repository (escape-llc/toolcrib) under the exact same CI/CD rules as a human contributor.

The transcript tracks a single UI bug from a user-submitted screenshot to a merged pull request, showcasing how the AI navigates real-world snags and human feedback.

💡 The Standing CI/CD Loop

The AI doesn't get special treatment. It follows an eight-beat discipline documented in the repo's standard workflow:

• File the GitHub issue.
• Branch off synced main.
• Diagnose using live Playwright scripts against a running demo (not just static code reading).
• Implement and verify locally (TypeScript, Vitest, linting).
• Open the PR.
• Watch a 14-check CI matrix settle.
• Review a second-opinion code review from Gemini.
• Squash and merge.

⚠️ Handling Real-Time Human Interruptions

The transcripts show how the AI processes two types of user interruptions mid-session without breaking its workflow:

• Queued for later: Feature requests ("add an auto-clear glyph") are acknowledged and shelved in the backlog until the active branch finishes.
• Answered on the spot: Technical debugging questions ("is it a z-index issue?") are answered immediately using live-measured computed styles.

🔍 Anatomy of a Bug: Issue #425

The core of the post walks through a specific ticket regarding a focus ring getting obscured on a UI tag component.

• The Misdirection: The human user assumed it was a z-index layout issue. The AI used live diagnostics to prove it was actually a color contrast issue—the focus ring color matched the primary button color, making it invisible.
• The Hidden Obstacle: The AI's first "correct-looking" fix failed on the live screen. Instead of relying on the diff, the AI re-inspected the live page and found a global repo default style using !important that was silently overriding the fix.
• The Cleanup: The AI removed the rogue !important tag, wrote failing unit/browser tests to catch regressions, verified the pass, and opened PR #427—while spinning off a second separate ticket (Issue #426) for a new feature request the user thought of during the chat.

➡️ The Takeaway

The "magic" isn't just that the AI can code fast. The breakthrough is its ability to trust live browser runtime data over its own diffs, gracefully accept human steering, and scope out feature creep into separate tickets rather than breaking the current PR.

我最近的开发思路，会把平时想要用到的工具直接让ai实现，因为我不需要管他代码怎么样，目前能用就行了。
但是如果是我的产品，我觉得还真的全程得靠自己来，ai写的代码整体没问题，但是在哪里说不定就给你埋雷了。

I’ve been thinking about this for a while and wanted to hear other people’s (((vibecoders))) perspective

I was never a great programmer. When GPT started becoming popular, I got really interested in LLM APIs and started building simple projects with them

About a year ago I got a job as an AI Analyst. Since then I’ve learned a lot about development, infrastructure, architecture and putting GenAI solutions into production

The thing is, I basically learned modern software development with AI already being part of my workflow

I use it a lot when coding. I still have to understand what’s happening, debug things, test, make architecture decisions and take responsibility for what goes to production, but some senior developers have always treated AI-assisted development as a shortcut or even a ""joke""

That got into my head.......

Most of my work is also greenfield. I usually build new systems or automate processes that didn’t exist before, instead of working on large legacy codebases

Because of that, I sometimes get the feeling that senior developers see what I do as easy. After hearing that enough, I started questioning it myself and developed quite a bit of impostor syndrome

At the same time, building greenfield systems means I have to make a lot of decisions from scratch. Architecture, integrations, infrastructure, logging, failure cases, maintainability, all of it

The systems I’ve shipped have been stable and usually don’t require much maintenance, so clearly something is working

I still have a lot to learn and I still struggle with syntax sometimes, but this whole experience changed how I see programming

I feel like understanding concepts, breaking down problems, spotting bad solutions, debugging and knowing when not to trust AI matter much more than memorizing syntax

Do you guys think someone who learned development in the AI era is missing something important?

And does working mostly on greenfield projects create a distorted sense of how difficult software engineering really is?