Patent-backed commerce attribution SaaS with identity graph, AI customer scoring, 11 ad integrations, and production Cloudflare infrastructure. YC 2026 Ready.
Among the many forgotten might-have-beens of the games console world, the Atari Jaguar occupies a special place. It was the final gasp of Atari Corporation, the Jack Tramiel-era incarnation of the …
Blog PostsOn Vibe Forks2026-06-29People Management in the Age of AI2026-05-14Coding on a Phone: What I Learned Building Software on Mobile in the Last Three Weeks2026-01-14Autopilot, Copilot, and Software Developers2025-10-12Degrees are merely proof of the money you've spent on a course...2025-06-25The AI Remote Has Arrived: Let Go of the Knob2025-05-27Developer Tooling in the age of LLM2024-07-03Developer Agents & The Future of Software Development2024-03-09Team Values2021-08-16J.A.R.V.I.S. for Developers2018-03-09Screens, Windows, Distractions, Focus, and Work"2017-04-15'Mini-Servers' for 'Micro-Services'2017-03-31A few Billion Lines of code Later: Using Static Analysis to Find Bugs in the Real World2016-04-18API Mapping using Text Mining2015-10-10Tricorder: Building a Program Analysis Ecosystem2015-09-30When, How, and Why Developers (Do Not) Test in Their IDEs2015-09-23Hello World!2015-09-21 On Vibe Forks 2026-06-29 LLM code generation enthusiasts are pushing the boundaries of what’s feasible with vibe coding. What started as ghost-text line completion moved to function generation, then to file completion, and now we’re all pushing for whole-project generation. These advances have made a new phenomenon possible: vibe forking. I define a vibe fork as a reimplementation or forked extension of an existing project using vibe coding. It’s a deliberately broad definition. At one end it covers the startups and incumbents forking VS Code to compete for the coveted AI-IDE crown. At the other, it covers solo developers prompting their way to glory, recreating existing software from scratch in a clean-room environment. However, for the purpose of this post, I will focus on the latter. As an example of the latter, Nicholas Carlini at Anthropic set sixteen Claude agents loose on a shared repo to build a C compiler from scratch: over nearly 2,000 Claude Code sessions and $20,000 in API costs, the agent team produced a 100,000-line compiler that can build Linux 6.9 on x86, ARM, and RISC-V. It is worth taking a moment to consider how impressive this is before we add it to the pile of bazillion other amazing things that AI can do. A hundred thousand lines, three architectures, a booting kernel, a 99% pass rate on the GCC torture suite, and it even compiles DOOM. This is not a toy. Neither is it a drop-in replacement of the C compilers for production-ready use cases. This is somewhere in the uncanny valley. The dizzying pace of the advancement of LLM code generation capabilities and the whiplash among developers in terms of their changing role in this new reality forms a fertile ground for wildly varying and imaginative extrapolation of the future: some utopian, some dystopian. When anyone with a decent token budget can vibe code a clean-room implementation of the software that folks put years of their life into, it is only natural for builders and maintainers to worry.1 The strongest version of the worry is real, and I’ll grant it up front: if the cost of reimplementation collapses toward zero, then any project whose only moat was its source code is genuinely exposed. But I feel, while the source code is a necessary condition for a project’s success, it is not a sufficient one. The sucess of software is a function of many factors. Here is my thinking on why I am not yet concerned about vibe forks. In scarcity, features matter; in abundance, curation matters. Today developers are empowered to prompt their way to glory. And when anyone can prompt a C compiler or a PTY implementation or a toy OS to existence, the artifact stops being the scarce thing. Judgment about the artifact becomes scarce: which of the thousand generated compilers is correct, is maintained, is safe to depend on? Answering that is itself labor, and it doesn’t fall out of a model. Rather it accrues as reputation, over time. The app stores are a great lens to look at this. Cloning cost there is already near zero and the barrier to listing is low, so the stores are flooded with clones. A hundred habit trackers, a thousand flashlight apps. The clones exist. They just don’t seem to go the distance. What drives the winner in a category from the mountain of clones is never the feature list. It’s the discovery (the editorial featuring, the reviews, the ranking, the brand, the trust) that separates genuinely useful apps from the pile of clones. Trust and real deployment are the moat, and feature parity is not enough to get past. A drop-in replacement carries a real, hard-to-quantify switching cost. If it ain’t broke, you don’t fix it. You certainly don’t swap a battle-tested dependency for a freshly minted clone that does the same thing. People do switch, but only when the new thing is not equivalent but better by a wide margin. Look at the AI-IDE forks: nobody abandoned VS Code because someone shipped a pixel-identical copy; they moved for Cursor and Windsurf because the AI integration was a genuine step-change. Parity doesn’t move anyone. Slope does. And the very property that makes vibe forking possible works against it here. A widely deployed software has been pulled into the training data and into context windows many times over; the model is good at it precisely because the world has already hit its corner cases and written them down. Zero history of a freshly minted vibe-fork may result in varying mileage of LLM-based coding depending on how far the APIs have deviated from the original project. The LLM is, in a real sense, better at maintaining the incumbent than at sustaining its replacement. The same way Carlini’s compiler leaned on GCC to get over the line. Support is a long-tailed, deeply human task. Agentic greenfield projects can go swimmingly, but brownfield work is where real perseverance is tested. Every project carries essential and accidental complexity, and much of software engineering is the slow work of reducing the accidental part over time. If your program uses only a narrow slice of C, a custom compiler clone may look attractive. The harder question is whether you are willing to maintain that personalized artifact for the full life of the system. Anyone can prompt a prototype in an afternoon. Sustaining it through years of issue triage is still unproven and very debatable. Finally, if everyone is going to set tokens ablaze, a little organization about where we burn them goes a long way. There is little glory in n people pushing their models to the same solution and comparing who got the answer fastest. There is real progress in n people solving n distinct problems in service of one larger goal. These are two extremes and reality sits somewhere in between, but the incentives mostly push away from the wasteful end: economic pressure and plain human pride rarely permit a thousand identical forks to all survive. Ask how many vibe-forks of C compilers are currently out there and how many of them you have actually used. Footnotes Some of these are reminiscent of the “recent” licensing wars: the fights that went mainstream when hyperscalers operationalized OSS as cloud services and developers fought back with more restrictive licenses. The outcome of that bloody, tooth-and-nail battle is still debatable. For instance, RedMonk’s analysis found no meaningful change in financial outcomes from the relicensing. And here is the thing worth remembering before we panic about vibe forks: copyleft was, at bottom, a copyright defense; it governed linking and distribution. The clean-room vibe fork reproduces behavior without copying expression, and walks straight around that defense. That is the genuinely new and unsettling property. But the licensing wars already taught us something deflating: even the defenders who had the copyright weapon and used it saw the revenue needle barely move. The wall everyone is now afraid of losing turns out, on inspection, to have been fairly short all along. ↩
I posted about an earlier version of this project here a few years ago. I always wanted to continue it, but life happened: house, kids, work, and suddenly project time disappeared. The old version worked, but it was five-year-old code, so I did what most people think about doing when they look at old code - I started from scratch. The project is called Vanchor. It is a different kind of robot than what is usually posted here, but still a robot :) Vanchor is an open-source GPS anchor/autopilot system for smaller boats using cheap electric trolling motors. The target is small fishing boats, kayaks, and other small boats with trolling motors (focused on bow mounted currently). The idea is to turn a cheap trolling motor into a simple autonomous boat-control system. Main functions: Hold position, similar to spot-lock Hold heading Follow waypoints Follow a shoreline Follow a depth contour Move between fishing spots Work around an island or structure Drift or orbit around an area Follow APB data from a plotter Test behaviour in simulation before using real hardware It is not meant to replace OpenCPN, chartplotters, or proper marine navigation. It is more focused than that: small-boat control for fishing and DIY automation. The new version has among a lot other features: Python-based controller Local web UI for phone/tablet use Simulator based on Fossen’s 3-DOF marine craft model GPS/IMU hardware support Driver system for custom hardware Location and heading from phone sensors through the PWA app, where supported Depth contours Catch logging GPX waypoint import Several fishing-focused control modes Early PCB designs Early 3D-printable servo/control models One thing I wanted to fix from the old version was the wiring. The boat setup quickly turned into a crow’s nest of wires, and debugging loose connections in a boat is not fun. Especially when you just want to catch some perch. So this version also has early PCB designs for a cleaner setup, plus 3D-printable servo/control models. The simulator is one of the more useful parts right now. It makes it possible to test control behaviour without having the boat, water, GPS, IMU, and motor driver available at the same time. The project is still early, but it is now at the point where outside feedback would be useful. Any feedback is appreciated. Especially feedback on the PCB. It looks fine when I inspect it, but it has been years since I designed my own, much simpler, PCB. And yes, even the 3D models and PCB designs were created with Fable. Without it, I would never have found the time to pull this together. So far, I am quite impressed by it. https://preview.redd.it/5u1eld6qlwbh1.png?width=3708&format=png&auto=webp&s=daa0ec1e2f3685177b538af5c972931e268b6c0a Repos: Main project: https://github.com/AlexAsplund/vanchor PCB designs: https://github.com/AlexAsplund/vanchor-pcb CAD models: https://github.com/AlexAsplund/vanchor-cad submitted by /u/aasplunds [link] [Kommentare]
The clip shows a dual-arm rig autonomously arranging flowers into a glass vase at 1x speed, fully autonomous, with three simultaneous camera angles in the corners so the full workspace is visible. Robbyant has released LingBot-VLA 2.0, a VLA model trained on roughly 60,000 hours split as 50,000 hours of real-robot data across 20 embodiments plus 10,000 hours of egocentric human video. The action space covers whole-body control to include head, waist, mobile base, and dexterous hands up to Unitree G1 and Fourier GR-2. On the authors' own GM-100 eval, where pi-0.5 and GR00T figures are also self-reported, Agilex Cobot Magic reaches 34.4% success and Galaxea R1 Pro 15.6%, with several tasks at 0%. The paper notes the model often makes partial progress then fumbles final precise placement or release, and OOD performance degrades sharply. Relative joint actions increased average success from 33.7% to 55.0% in ablations. submitted by /u/Feeling_Till_7418 [link] [Kommentare]
Tried creating same pick and place simulation with a few different models. The recurring pain point was resolving XML issues after the initial generation. Gave Drift a try for the same task. I spent more time iterating on the scene itself instead of chasing configuration errors. If anyone is looking for the exact prompt I used: Create a MuJoCo scene using a Franka Panda arm, place it on a table and a cube in front of it with a target pad. submitted by /u/AxBodiSpray [link] [Kommentare]
How Microsoft Kin Helped Bankrupt Sharp Electronics Preface: Everything in this story is hearsay, told to me by someone who was directly involved in the events but who sometimes embellished around the edges. Also there were many contributing factors to the downfall of Sharp Electronics, however the events that transpired sure didn’t help things along. Sins Of The Father Microsoft Band 2 needed a curved screen. Circa 2014 only 2 companies made curved screens, Samsung, and Sharp. Samsung, who at the time had a competing product to Band, offered to sell us a 1.3 in screen for only $35 per unit. I asked the guy in charge of sourcing what options we had. “Well, we called up Sharp, but they literally won’t pick up the phone for us anymore. That is our fault.”
We call upon the UK Government to reject any calls or lobbying that propose to restrict or ban the use of virtual private networks ("VPNs") for children, because of the impact this would have on other VPN users.
The system already shapes what people believe.