Clone It. Improve It. Launch It. SaaS Is Cooked: This is different kind of Reverse Engineering (Read the full post) I have been posting about how fast reverse engineering is changing. REA, which lets an AI agent look inside any app. Eleven, where you watch the agent do that work. Co-op Anything, a playbook for turning single-player games into multiplayer. Then a library of 12,869 tools built by reverse engineering closed apps. And now this. Replica is a free set of 11 Claude skills that clone an app's features, rebuild them, test them, and then fix what the original app's users complain about. This is a different kind of reverse engineering. It doesn't look inside the code. It studies what the app does from the outside: public pages, screenshots, store listings, and your own account. So esentially Reverse Engineering Just Became Product Engineering and your app's 1-star reviews are now someone else's product roadmap . Here's the flow: 1. Recon maps the app: screens, user flows, data model. 2. Architect, design, build, and backend rebuild it from scratch. 3. Test clicks through every flow looking for bugs. 4. Diff compares your version with the original and gives a parity score. 5. Entrepreneur reads real user reviews and finds what people hate. 6. Brand, launch, and deploy give it a new name and look, and put it live. The Entrepreneur step is the interesting one. In the README's example, it reads 140 reviews of a scheduling app and finds the top complaints: per-seat pricing, no text reminders, confusing time zones. Those become the features and the pitch. The repo also sets rules: rebuild features and flows only, never the code, logo, copy, or content. Only use public pages and your own account. The deploy step won't run until every trace of the original's name and colours is gone. And it says to check trademarks and talk to a lawyer before selling. Free, MIT licence, 4.5k stars. What I find interesting after following this space for a while: each tool goes one level higher. First, agents learned to read software. Then to change it. Now they can rebuild the whole product and start a business with it. For a simple app, the code was never really the moat. Now the features aren't either. What's left is everything an agent can't copy: your users, your content, your brand, and how much people trust you. And maybe the most honest lesson: your 1-star reviews are public. Someone is reading them. Better if it's you. Links in the reply 👇 Links in the reply 👇

Hermes Agent makes 3D models from text. But the real news is bigger than that. An AI agent that makes 3D models from text? Not new. Meshy, a text-to-3D tool, has an MCP server (a standard way to plug tools into AI agents). Any agent that supports MCP, including Claude and Codex, can already connect to it. Agents asking permission before acting? Also not new. Claude Code and Codex do that all the time. So what did Nous Research actually add with the new Meshy plugin for Hermes Agent? The new part is the price check. A normal approval asks: "Allow this tool?" Hermes asks: "This costs 15 credits. Go ahead?" In the demo, someone asks for a boss enemy for their Godot game. Hermes picks the settings (15,000 triangles, 4K textures, a GLB file for Godot), tells them the cost, and only spends after they say yes. That's a small change, but an important one. Agents are starting to spend real money: credits, API calls, cloud resources. Permission alone isn't enough. You need to know what it costs before you click yes. Nous also added polish on top: → One-line install from the official plugin catalog
→ Models render in the chat, and rigged characters animate there
→ A gallery of every model and prompt you've made
→ Short preview videos on messaging apps, so you can create from your phone
→ 3D-print prep: fixing problems, splitting into parts, handing off to a slicer The catch: you need a Meshy Pro plan and API key, and every model costs credits. What I find interesting as someone building agent tools: as agents start spending money for us, every approval should show the price, not just ask permission. Hermes is one of the first to make that the default. Links in the reply 👇

@a16z says the patch window is collapsing. Its own data source has doubts. 87% of exploited bugs are attacked on or before the day they go public. But read the fine print. a16z's "Charts of the Week" are going viral. The story: 1In 2020, about 23% of exploited bugs were hit on day zero. Now it's about 87%. 2In 2022, half of exploitable bugs were still unused after 1.5 months. Now almost none are. 3The median time from disclosure to attack has dropped from a year to about a day. It's projected to hit 1 minute by 2027. All three charts come from one source: the Zero Day Clock, built by Sergej Epp of Sysdig. Here's the catch most people miss. The Zero Day Clock has since retired this exact metric. Its own FAQ says it can mislead: → Recent bugs have had less time to collect evidence, so recent years look faster than they really are.
→ The number can't go below zero, so once most attacks land on day one, it can't show more speed.
→ Same-day attacks get rounded to zero. And the "1 minute" box isn't measured. It's a trend line drawn forward from 2018 to 2024 data. So is it all hype? No. We saw the real version this week. PHP2Shell details leaked on 20 October. Cloudflare saw attacks the next morning. The patch arrived that afternoon. Attackers were hours ahead of the fix. What I take from this as a practitioner: • The direction is real. Attacks are arriving faster.
• The exact numbers are softer than the charts suggest.
• Either way, monthly patching is too slow. You need automatic patching, day-zero firewall rules, and fast exposure checks.

Review code 100X faster with pr-lens. AI agents now write a big part of our code. But someone still has to review it. Reading a 40-file pull request (PR, a request to merge code changes) line by line is slow and tiring. There is a faster way: look at a picture first. A diagram shows which parts changed and how data moves between them, before you read any code. But there is a catch. Diagrams go out of date fast. Nobody draws one for every PR, so reviewers go straight to the diff (the list of changed lines). The team at Coldtea built an open-source tool for this: PR Lens. The idea is simple: every PR gets its own diagram, automatically. 1You or your agent opens a PR. 2PR Lens reads the diff with an AI model. 3It draws the change as animated architecture and data-flow diagrams. 4It posts them as a comment inside the PR, and updates them on every push. You see the shape of the change before you read the code. How it works: → The AI first writes the change as a JSON graph (a simple list of parts and links). A fixed renderer then turns it into SVG images, so the drawing is the same every time.
→ The animation is plain SVG with no JavaScript, so it still moves inside a GitHub comment.
→ Wrong names? Fix them once in a .github/pr-lens.yml file. The fixes stay when the diagram is redrawn.
→ It runs 4 ways: GitHub App, GitHub Action, CLI, or a skill for coding agents like Claude Code, Cursor and Codex. What you get: • Free for open source, MIT licence
• Bring your own model: Gemini, OpenAI, or compatible
• No API key needed with the hosted GitHub App
• The agent skill uses your agent's own model, so no extra bill What I find interesting as someone building agentic workflows: the agent that writes the code can now explain it too. A diagram won't replace tests or careful review, but it tells you where to look first. Links in the reply 👇

Two weeks to the midterms and the main character is already threatening the sequel 🍿

Two weeks to the midterms and the main character is already threatening the sequel 🍿

NVIDIA just used an AI agent to help build the digital twin of an AI factory In 1970, Apollo 13 was in trouble. On the ground, NASA engineers used simulators connected to the spacecraft by live data. They could see what the astronauts saw and test fixes before sending them up. NASA is widely credited with pioneering what we now call a digital twin. A digital twin is a virtual copy of something real (a product, a factory, a whole building) that you can use to design it, test it, and run it. Today, companies use them everywhere. NVIDIA says BMW gets up to 30% efficiency gains planning new factories with them, and Zaha Hadid Architects uses them for design collaboration. But digital twins have always had one big problem: building them. → Specialists rebuild everything by hand in design software, one object at a time. → They type in the data: power, cooling, weight. → Files are converted between formats again and again, losing data each time. → It can take weeks or months before anyone tests anything. NVIDIA just published "Developing an AI Factory Digital Twin with an Agent-Assisted Workflow." In plain English: an AI agent helped build the digital twin of an AI data centre. How it worked: A frontier AI model ran as an agent, connected to design tools through MCP. It started from NVIDIA's Omniverse DSX Blueprint: ready-made 3D models of data halls, substations, generators, and cooling. It read site plans and requirement documents to place everything, and put the campus on real terrain using public map data. NVIDIA's USD Content Agents helped generate a solar canopy inspired by NVIDIA's own headquarters. Engineers reviewed the twin, ran power and cooling simulations, and sent changes back. Everything lives in OpenUSD, one shared 3D format, so every tool works on the same model instead of its own copy. Each choice links back to its source document. NVIDIA is clear about the limits: an agent's model can look right but have wrong dimensions, and every result needs engineering review. What I find interesting as someone building agents: digital twins have mostly been for the biggest projects, because only they could afford the months of modelling work. If agents cut that work, twins could become normal for hospitals, airports, warehouses, and factories. NASA needed a twin to bring three astronauts home. Soon, every big building might have one. Links in the reply 👇

What the f*ck is happening? REA. Then Eleven. Then Co-op Anything. Now this. All in a few weeks. And now this: "Don't reverse engineer it twice." What the f*ck is happening with reverse engineering right now? Here's what's new. It's not another tool to take software apart. It's a library of everything people have already taken apart. Awesome Reverse-Engineered lists 12,869 open-source projects that exist because someone reverse engineered a closed app, API, device, file format, game, or AI tool. The idea is simple: *****search before you start*****. You want your agent to control a smart plug, read a strange file format, or talk to an app with no official API. Before it starts reverse engineering, it searches the index. If someone already did the work, it uses their tool. If not, you do the work, publish it, and add it, so the next person starts where you stopped. How it works: → You can search it on a website, or install it as a skill your AI agent can use. → The agent ranks results by stars, recent activity, and licence, then reads the README to pick the right tool. → It refreshes every night. Each project is checked to see whether it still exists and is still maintained. → It leaves out exploits, jailbreaks, DRM removal, and cheats on purpose. It's for interoperability: making things work together. What's inside: • 12,869 projects with 10.7M GitHub stars combined • 3,036 game decompilations, 3,028 device and IoT projects, 737 AI tools • 7,077 still active, 900 archived • it includes REA itself So the stack keeps growing: → REA = look inside the software → Eleven = watch and check the work → Co-op Anything = a playbook for one goal → Awesome Reverse-Engineered = memory of what's already been done What I find interesting as someone building agents: agents made reverse engineering cheap. That creates a new problem: everyone's agent takes the same app apart, again and again, and the work stays in private scripts. The smartest agent isn't the one that can reverse engineer anything. It's the one that checks first whether it needs to. Links in the reply 👇

Anthropic replaced git because its own agents broke it. Someone just open-sourced the idea. Git was built for humans. AI coding agents may need something else. A new open-source project called git-ai is trying to build exactly that: Git designed for AI agents. AI coding agents are starting to break assumptions that software engineering has relied on for decades. Not because they write bad code. Because they write too much code, too quickly. Anthropic ran into this problem internally. Their agents were generating so many changes that traditional Git infrastructure itself became part of the bottleneck. So Anthropic built a new source-control architecture called Scion. Now someone is building an open-source version of the idea. Meet git-ai. The old world looked like this: Developer ↓ Clone repository ↓ Work for a few hours ↓ Commit ↓ Pull request ↓ Merge The agent world could look very different: Agent 1 Agent 2 Agent 3 Agent 4 … Agent 100 ↓ thousands of tiny concurrent changes ↓ continuous rebasing ↓ continuous testing ↓ continuous conflict resolution ↓ continuous landing Git was not designed for that world. git-ai tries to redesign the workflow around it. Instead of cloning everything, agents can request only the repository objects they need. Instead of relying entirely on local Git operations, rebasing and landing can happen on the server. Instead of treating “who made this change?” as a human username, every agent can have its own identity and permissions. Instead of a human manually untangling every collision between two branches, conflict resolution can be automated — including with an LLM. And every accepted change goes into an ordered changeset log. So you can answer: Which agent changed this? When? What happened immediately before it? What failed afterwards? This is where things get interesting. If software development becomes dominated by fleets of agents, our current tooling starts looking surprisingly human-centric. Branches. Pull requests. Merge queues. Local clones. Manual conflict resolution. These are not laws of nature. They are design choices from an era where humans were the scarce resource. git-ai is still only v0.1.0. And to be clear: This is NOT Anthropic open-sourcing Scion. It is an independent, MIT-licensed implementation inspired by Anthropic’s published architecture. But projects like this hint at a much larger shift. The next generation of coding agents may require an entirely new software-development stack around them. Not just better models. Better infrastructure for machines that write code at machine speed. Links in the reply 👇

Your coding agent can now message your teammate's coding agent across machines. Your coding agent can now message your teammate's coding agent. Here's the problem it solves. 5 people on a team, each running Claude Code or Codex on their own machine. Your agent is changing the API. Theirs is building against the old version. Nobody knows until something breaks. Today the only bridge is you: copy, paste into Slack, wait. You are the router. Reason Machines just open-sourced Reason Network to fix this. The idea is simple: one small daemon per computer, and every agent session on the team can see and message every other one. 1. Paste one line into your agent: "Join the Reason Network" 2. Sign in once. Your agents are set up. 3. Teammates join with your invite line. 4. Any agent can now ask "who's on the network?" or message alice/api-claude directly. Works with Claude Code, Codex, Cursor, Gemini CLI, Copilot CLI, opencode and more. How it works: → A small background program (daemon) written in Rust → Machines connect peer to peer over iroh, an encrypted networking library → If a direct link fails, a relay passes the traffic but only sees encrypted bytes → Agents get simple MCP tools: list the team, send a message, check the inbox → Messages land mid-session in Claude Code and Codex. Idle sessions wake up. → Small text files can go with a message: logs, JSON, a schema The part I like most: When someone else's agent asks yours for something only you can approve, you get a pop-up. Approve or Deny. The answer comes from you, not from a message anyone could fake. What I find interesting as someone building agents: This opens a new attack surface. An agent that reads messages from other agents can be steered by them. The human approval step isn't a nice extra. It's what makes this safe to use. Free. MIT / Apache-2.0. Links in the reply 👇

A nearly year-old Hugging Face project is suddenly trending again ,and I can see why. It’s called Omni Image Editor, built by selfit-camera. Instead of using one tool for generation, another for editing, another for face swapping and another for upscaling, the idea is to put several image workflows behind one simple interface. According to its Hugging Face page, it supports things such as: → Text → image Describe what you want and generate an image. → Image editing with prompts Upload an existing picture and describe the change you want. → Image upscaling Increase the resolution/quality of an existing image. → Face swapping Use a reference face in another image. → Other image-manipulation workflows through the same UI. The project is also MIT licensed, uses a Gradio interface, and is available directly as a Hugging Face Space. Hugging Face But the interesting part is not that another image editor exists. It is why this one appears to be trending now. At the time I checked, Omni Image Editor had roughly 2.8K likes and was sitting prominently among Hugging Face’s currently trending image tools. And that tells us something about where AI image tools are going. For the last few years we have had lots of impressive individual models: One model generates images. Another edits them. Another removes objects. Another changes faces. Another improves resolution. Useful — but fragmented. Now the interesting layer is becoming the workflow sitting on top of those models. You upload an image once. Then you say: “Remove that person.” “Change the background.” “Make it cinematic.” “Upscale it.” “Swap the face.” “Generate another version.” All from one place. That is probably a big part of the attraction here. People increasingly don't care which diffusion model or editing model is running underneath. But a few things are worth knowing: • no model weights, no paper, and the app's code is hidden • the free version has limited trials, with a paid plan for unlimited use • the page compares it to FLUX.2 and Qwen-Image, but shows no quality tests, only specs So it's a product demo on Hugging Face, not an open model. What I find interesting as someone working with AI: Hugging Face used to mean "here are the weights, try it yourself." More and more, it's becoming a shop window, a free demo in front of a paid product. That's fine. But "on Hugging Face" and "open source" are not the same thing anymore, and it's worth checking which one you're looking at. Links in the reply 👇

Claude refused to make me a simple animated GIF saying: “Reverse Engineering Anything Is the New Wild West of AI.” Why? Safety rules. So I asked which rule I had violated. Its answer was basically: “I don’t know.” It guessed that because the conversation had earlier mentioned hacking tools and cyber-attacks, the phrase “reverse-engineer anything” may have looked dangerous to an automated filter. Fair enough. Then I asked Claude to make an animated GIF about the conversation itself — showing me asking for the GIF, Claude refusing it, and explaining the safety block. It happily made that. 😂 Same words. Same context. Same supposedly dangerous phrase. But now wrapped inside a story about the refusal, it was acceptable. This is the problem with safety systems that sometimes seem better at recognising suspicious-looking words than understanding what the user is actually trying to do. It’s a bit like: Airport security confiscating a picture of a knife… then happily letting you carry a poster showing the confiscated picture. Or a guard dog trained to bark whenever it hears the word “weapon”, regardless of whether you’re holding one or reading a newspaper. Safety matters. But if AI systems are going to become serious tools for engineers, researchers and security professionals, they need to get much better at distinguishing: Intent from vocabulary. Discussion from execution. A harmless graphic from an actual cyber operation. Otherwise we end up with something even stranger than an unsafe AI: a safe AI that occasionally has no idea why it said no. Here is the video it made !!!

THIS RESEARCH AGENT HAS TO PASS A REVIEW BEFORE YOU SEE THE ANSWER Most AI research agents have the same weak spot. They search the web, write a report full of citations, and show it to you. Nobody checks if the citations actually back up the claims. The usual fix is a second LLM that reviews the first one. But there is a catch. Now you run two slow, costly models, and the reviewer writes long text that your code still has to parse and trust. A new open-source project in Hands-On AI Engineering takes a different path. It uses Jev as the review layer. Jev is a model from TypeSafe AI that does not write text. You ask it typed questions and it returns a decision with a probability (how sure it is). The idea is simple: one model writes, a different model judges. 1The agent plans the research and searches the live web with Tavily. 2NVIDIA Nemotron writes a report with numbered citations. 3Plain code checks that every citation points to a real retrieved source. 4Jev checks two things: does the evidence cover the question, and are the key claims grounded? If not, the agent researches one more time. The reviewer never touches the report. It only says pass, or research again. How it works: → LangChain Deep Agents run the research (agents that plan and break work into steps).
→ Jev returns yes/no probabilities. 0.70 or above counts as a pass.
→ Only one extra research round, so cost and time stay predictable.
→ LangSmith traces every step, so you can see the plan, the searches and the review result. Why Jev fits this job (TypeSafe's own numbers): • 70–500 ms per decision
• ~$0.042 per 1M input tokens, output is free
• No free text, so no broken JSON to handle What I find interesting as someone building agents: we keep using big chat models for small yes/no checks. A model built only for decisions makes the review step cheap enough to run on every answer. Links in the reply 👇

GOOD NEWS : Code Anywhere: A Fully Local Coding Agent on Your Phone Claude Code and Codex can already be controlled from your phone. You start the agent on your computer and leave the house. From your phone you can watch it work, read the diffs (the code changes), answer its questions and approve actions. Claude Code calls this Remote Control. Codex does it inside the ChatGPT app. In both, your repo and terminal stay on your machine. The phone is just the control panel. But there is a catch. Both go through the company's account and servers. And the model doing the thinking is Claude or GPT in their cloud. What if you want the whole thing on your own hardware? Qwen Code recently merged a change that brings this to open source. → The Web Shell is now a PWA (a website you can install like a phone app).
→ The phone's browser talks directly to the daemon on your computer. No cloud dev environment is created.
→ A service worker (a small script in the browser) caches static files, but your session and live events always come fresh from your machine.
→ If the daemon is down, you get a retry page, not an old stale session.
→ There is also a native Android shell, but it is still a development prototype. What I find interesting as someone building agents: the agent is becoming a service, not a terminal program. The terminal, the browser and the phone are just different screens on the same long-running agent. And now you can build that on a fully local stack. Links in the reply 👇