An anonymous reader shared this report from Gizmodo: It's been over a year since OpenAI cofounder Andrej Karpathy exited the company. In the time since he's been gone, he coined and popularized the term "vibe coding" to describe the practice of farming out coding projects to AI tools. But earlier this week, when he released his own open source model called nanochat, he admitted that he wrote the whole thing by hand, vibes be damned. Nanochat, according to Karpathy, is a "minimal, from scratch, full-stack training/inference pipeline" that is designed to let anyone build a large language model with a ChatGPT-style chatbot interface in a matter of hours and for as little as $100. Karpathy said the project contains about 8,000 lines of "quite clean code," which he wrote by hand — not necessarily by choice, but because he found AI tools couldn't do what he needed. "It's basically entirely hand-written (with tab autocomplete)," he wrote. "I tried to use claude/codex agents a few times but they just didn't work well enough at all and net unhelpful."

Read more of this story at Slashdot.

An anonymous reader shares a report: After acquiring GitHub in 2018, Microsoft mostly let the developer platform run autonomously. But in recent months, that's changed. With GitHub CEO Thomas Dohmke leaving the company this August, and GitHub being folded more deeply into Microsoft's organizational structure, GitHub lost that independence. Now, according to internal GitHub documents The New Stack has seen, the next step of this deeper integration into the Microsoft structure is moving all of GitHub's infrastructure to Azure, even at the cost of delaying work on new features. [...] While GitHub had previously started work on migrating parts of its service to Azure, our understanding is that these migrations have been halting and sometimes failed. There are some projects, like its data residency initiative (internally referred to as Project Proxima) that will allow GitHub's enterprise users to store all of their code in Europe, that already solely use Azure's local cloud regions.

Read more of this story at Slashdot.

Engineer Denis Stetskov, writing in a blog: The Apple Calculator leaked 32GB of RAM. Not used. Not allocated. Leaked. A basic calculator app is hemorrhaging more memory than most computers had a decade ago. Twenty years ago, this would have triggered emergency patches and post-mortems. Today, it's just another bug report in the queue. We've normalized software catastrophes to the point where a Calculator leaking 32GB of RAM barely makes the news. This isn't about AI. The quality crisis started years before ChatGPT existed. AI just weaponized existing incompetence. [...] Here's what engineering leaders don't want to acknowledge: software has physical constraints, and we're hitting all of them simultaneously. Modern software is built on towers of abstractions, each one making development "easier" while adding overhead: Today's real chain: React > Electron > Chromium > Docker > Kubernetes > VM > managed DB > API gateways. Each layer adds "only 20-30%." Compound a handful and you're at 2-6x overhead for the same behavior. That's how a Calculator ends up leaking 32GB. Not because someone wanted it to -- but because nobody noticed the cumulative cost until users started complaining. [...] We're living through the greatest software quality crisis in computing history. A Calculator leaks 32GB of RAM. AI assistants delete production databases. Companies spend $364 billion to avoid fixing fundamental problems. This isn't sustainable. Physics doesn't negotiate. Energy is finite. Hardware has limits. The companies that survive won't be those who can outspend the crisis. There'll be those who remember how to engineer.

Read more of this story at Slashdot.

"Recent attacks show that hackers keep using the same tricks to sneak bad code into popular software registries," writes long-time Slashdot reader selinux geek, suggesting that "the real problem is how these registries are built, making these attacks likely to keep happening." After all, npm wasn't the only software library hit by a supply chain attack, argues the Linux Security blog. "PyPI and Docker Hub both faced their own compromises in 2025, and the overlaps are impossible to ignore." Phishing has always been the low-hanging fruit. In 2025, it wasn't just effective once — it was the entry point for multiple registry breaches, all occurring close together in different ecosystems... The real problem isn't that phishing happened. It's that there weren't enough safeguards to blunt the impact. One stolen password shouldn't be all it takes to poison an entire ecosystem. Yet in 2025, that's exactly how it played out... Even if every maintainer spotted every lure, registries left gaps that attackers could walk through without much effort. The problem wasn't social engineering this time. It was how little verification stood between an attacker and the "publish" button. Weak authentication and missing provenance were the quiet enablers in 2025... Sometimes the registry itself offers the path in. When the failure is at the registry level, admins don't get an alert, a log entry, or any hint that something went wrong. That's what makes it so dangerous. The compromise appears to be a normal update until it reaches the downstream system... It shifts the risk from human error to systemic design. And once that weakly authenticated code gets in, it doesn't always go away quickly, which leads straight into the persistence problem... Once an artifact is published, it spreads into mirrors, caches, and derivative builds. Removing the original upload doesn't erase all the copies... From our perspective at LinuxSecurity, this isn't about slow cleanup; it's about architecture. Registries have no universally reliable kill switch once trust is broken. Even after removal, poisoned base images replicate across mirrors, caches, and derivative builds, meaning developers may keep pulling them in long after the registry itself is "clean." The article condlues that "To us at LinuxSecurity, the real vulnerability isn't phishing emails or stolen tokens — it's the way registries are built. They distribute code without embedding security guarantees. That design ensures supply chain attacks won't be rare anomalies, but recurring events."BR> So in a world where "the only safe assumption is that the code you consume may already be compromised," they argue, developers should look to controls they can enforce themselves: Verify artifacts with signatures or provenance tools. Pin dependencies to specific, trusted versions. Generate and track SBOMs so you know exactly what's in your stack. Scan continuously, not just at the point of install.

Read more of this story at Slashdot.

An anonymous reader quotes a report from TechCrunch: Google is bringing its AI coding agent Jules deeper into developer workflows with a new command-line interface and public API, allowing it to plug into terminals, CI/CD systems, and tools like Slack -- as competition intensifies among tech companies to own the future of software development and make coding more of an AI-assisted task. Until now, Jules -- Google's asynchronous coding agent -- was only accessible via its website and GitHub. On Thursday, the company introduced Jules Tools, a command-line interface that brings Jules directly into the developer's terminal. The CLI lets developers interact with the agent using commands, streamlining workflows by eliminating the need to switch between the web interface and GitHub. It allows them to stay within their environment while delegating coding tasks and validating results. "We want to reduce context switching for developers as much as possible," Kathy Korevec, director of product at Google Labs, told TechCrunch. Jules differs from Gemini CLI in that it focuses on "scoped," independent tasks rather than requiring iterative collaboration. Once a user approves a plan, Jules executes it autonomously, while the CLI needs more step-by-step guidance. Jules also has a public API for workflow and IDE integration, plus features like memory, a stacked diff viewer, PR comment handling, and image uploads -- capabilities not present in the CLI. Gemini CLI is limited to terminals and CI/CD pipelines and is better suited for exploratory, highly interactive use.

Read more of this story at Slashdot.

Anthropic's Claude Sonnet 4.5 ran autonomously for 30 hours to build a chat application similar to Slack or Teams, generating approximately 11,000 lines of code before stopping upon task completion. The model, announced today, marks a significant leap from the company's Opus 4 model, which ran for seven hours in May. Claude Sonnet 4.5 performs three times better at browser navigation and computer use than Anthropic's October technology. Beta-tester Canva deployed the model for complex engineering tasks in its codebase and product features. Anthropic paired the release with virtual machines, memory, context management, and multi-agent support tools, enabling developers to build their own AI agents using the same building blocks that power Claude Code.

Read more of this story at Slashdot.

IEEE Spectrum ranks the popularity of programming languages — but is there a problem? Programmers "are turning away from many of these public expressions of interest. Rather than page through a book or search a website like Stack Exchange for answers to their questions, they'll chat with an LLM like Claude or ChatGPT in a private conversation." And with an AI assistant like Cursor helping to write code, the need to pose questions in the first place is significantly decreased. For example, across the total set of languages evaluated in the Top Programming Languages, the number of questions we saw posted per week on Stack Exchange in 2025 was just 22% of what it was in 2024... However, an even more fundamental problem is looming in the wings... In the same way most developers today don't pay much attention to the instruction sets and other hardware idiosyncrasies of the CPUs that their code runs on, which language a program is vibe coded in ultimately becomes a minor detail... [T]he popularity of different computer languages could become as obscure a topic as the relative popularity of railway track gauges... But if an AI is soothing our irritations with today's languages, will any new ones ever reach the kind of critical mass needed to make an impact? Will the popularity of today's languages remain frozen in time? That's ultimately the larger question. "how much abstraction and anti-foot-shooting structure will a sufficiently-advanced coding AI really need...?" [C]ould we get our AIs to go straight from prompt to an intermediate language that could be fed into the interpreter or compiler of our choice? Do we need high-level languages at all in that future? True, this would turn programs into inscrutable black boxes, but they could still be divided into modular testable units for sanity and quality checks. And instead of trying to read or maintain source code, programmers would just tweak their prompts and generate software afresh. What's the role of the programmer in a future without source code? Architecture design and algorithm selection would remain vital skills... How should a piece of software be interfaced with a larger system? How should new hardware be exploited? In this scenario, computer science degrees, with their emphasis on fundamentals over the details of programming languages, rise in value over coding boot camps. Will there be a Top Programming Language in 2026? Right now, programming is going through the biggest transformation since compilers broke onto the scene in the early 1950s. Even if the predictions that much of AI is a bubble about to burst come true, the thing about tech bubbles is that there's always some residual technology that survives. It's likely that using LLMs to write and assist with code is something that's going to stick. So we're going to be spending the next 12 months figuring out what popularity means in this new age, and what metrics might be useful to measure. Having said that, IEEE Spectrum still ranks programming language popularity three ways — based on use among working programmers, demand from employers, and "trending" in the zeitgeist — using seven different metrics. Their results? Among programmers, "we see that once again Python has the top spot, with the biggest change in the top five being JavaScript's drop from third place last year to sixth place this year. As JavaScript is often used to create web pages, and vibe coding is often used to create websites, this drop in the apparent popularity may be due to the effects of AI... In the 'Jobs' ranking, which looks exclusively at what skills employers are looking for, we see that Python has also taken 1st place, up from second place last year, though SQL expertise remains an incredibly valuable skill to have on your resume."

Read more of this story at Slashdot.

After the nonprofit Ruby Central removed all RubyGems' maintainers from its GitHub repository, André Arko — who helped build Bundler — wrote a new blog post on Thursday "detailing Bundler's relationship with Ruby Central," according to this update from The New Stack. "In the last few weeks, Ruby Central has suddenly asserted that they alone own Bundler," he wrote. "That simply isn't true. In order to defend the reputation of the team of maintainers who have given so much time and energy to the project, I have registered my existing trademark on the Bundler project." He adds that trademarks do not affect copyright, which stays with the original contributors unchanged. "Trademarks only impact one thing: Who is allowed say that what they make is named 'Bundler,'" he wrote. "Ruby Central is welcome to the code, just like everyone else. They are not welcome to the project name that the Bundler maintainers have painstakingly created over the last 15 years." He is, however, not seeking the trademark for himself, noting that the "idea of Bundler belongs to the Ruby community." "Once there is a Ruby organization that is accountable to the maintainers, and accountable to the community, with openly and democratically elected board members, I commit to transfer my trademark to that organization," he said. "I will not license the trademark, and will instead transfer ownership entirely. Bundler should belong to the community, and I want to make sure that is true for as long as Bundler exists." The blog It's FOSS also has an update on Spinel, the new worker-owned collective founded by Arko, Samuel Giddins [who Giddins led RubyGems security efforts], and Kasper Timm Hansen (who served served on the Rails core team from 2016 to 2022 and was one of its top contributors): These guys aren't newcomers but some of the architects behind Ruby's foundational infrastructure. Their flagship offering is rv ["the Ruby swiss army knife"], a tool that aims to replace the fragmented Ruby tooling ecosystem. It promises to [in the future] handle everything from rvm, rbenv, chruby, bundler, rubygems, and others — all at once while redefining how Ruby development tools should work... Spinel operates on retainer agreements with companies needing Ruby expertise instead of depending on sponsors who can withdraw support or demand control. This model maintains independence while ensuring sustainability for the maintainers. The Register had reported Thursday: Spinel's 'rv' project aims to supplant elements of RubyGems and Bundler with a more modular, version-aware manager. Some in the Ruby community have already accused core Rails figures of positioning Spinel as a threat. For example, Rafael FranÃa of Shopify commented that admins of the new project should not be trusted to avoid "sabotaging rubygems or bundler."

Read more of this story at Slashdot.

An anonymous reader quotes a report from TechCrunch: While many vibe-coding startups have become unicorns, with valuations in the billions, one area where AI-assisted coding has not yet taken off is on mobile devices. Despite the numerous apps now available that offer vibe-coding tools on mobile platforms, none are gaining noticeable downloads, and few are generating any revenue at all. According to an analysis of global app store trends by the app intelligence provider Appfigures, only a small handful of mobile apps offering vibe-coding tools have seen any downloads, let alone generated revenue. The largest of these is Instance: AI App Builder, which has seen only 16,000 downloads and $1,000 in consumer spending. The next largest app, Vibe Studio, has pulled in just 4,000 downloads but has made no money. This situation could still change, of course. The market is young, and vibe-coding apps continue to improve and work out the bugs. New apps in this space are arriving all the time, too. This year, a startup called Vibecode launched with $9.4 million in seed funding from Reddit co-founder Alexis Ohanian's Seven Seven Six. The company's service allows users to create mobile apps using AI within its own iOS app. Vibecode is so new, Appfigures doesn't yet have data on it. For now, most people who want to toy around with vibe-coding technology are doing so on the desktop.

Read more of this story at Slashdot.

Writing in Communications of the ACM, former Go tech lead Russ Cox warns we need to keep improving defenses of software supply chains, highlighting "promising approaches that should be more widely used" and "areas where more work is needed." There are important steps we can take today, such as adopting software signatures in some form, making sure to scan for known vulnerabilities regularly, and being ready to update and redeploy software when critical new vulnerabilities are found. More development should be shifted to safer languages that make vulnerabilities and attacks less likely. We also need to find ways to fund open source development to make it less susceptible to takeover by the mere offer of free help. Relatively small investments in OpenSSL and XZ development could have prevented both the Heartbleed vulnerability and the XZ attack. Some highlights from the 5,000-word article: Make Builds Reproducible. "The Reproducible Builds project aims to raise awareness of reproducible builds generally, as well as building tools to help progress toward complete reproducibility for all Linux software. The Go project recently arranged for Go itself to be completely reproducible given only the source code... A build for a given target produces the same distribution bits whether you build on Linux or Windows or Mac, whether the build host is X86 or ARM, and so on. Strong reproducibility makes it possible for others to easily verify that the binaries posted for download match the source code..." Prevent Vulnerabilities. "The most secure software dependencies are the ones not used in the first place: Every dependency adds risk... Another good way to prevent vulnerabilities is to use safer programming languages that remove error-prone language features or make them needed less often..." Authenticate Software. ("Cryptographic signatures make it impossible to nefariously alter code between signing and verifying. The only problem left is key distribution...") "The Go checksum database is a real-world example of this approach that protects millions of Go developers. The database holds the SHA256 checksum of every version of every public Go module..." Fund Open Source. [Cox first cites the XKCD cartoon "Dependencies," calling it "a disturbingly accurate assessment of the situation..."] "The XZ attack is the clearest possible demonstration that the problem is not fixed. It was enabled as much by underfunding of open source as by any technical detail." The article also emphasized the importance of finding and fixing vulnerabilities quickly, arguing that software attacks must be made more difficult and expensive. "We use source code downloaded from strangers on the Internet in our most critical applications; almost no one is checking the code.... We all have more work to do."

Read more of this story at Slashdot.

Long-time Slashdot reader robinsrowe shared this report from the Register: The C++ standards committee abandoned a detailed proposal to create a rigorously safe subset of the language, according to the proposal's co-author, despite continuing anxiety about memory safety. "The Safety and Security working group voted to prioritize Profiles over Safe C++. Ask the Profiles people for an update. Safe C++ is not being continued," Sean Baxter, author of the cutting-edge Circle C++ compiler, commented in June this year. The topic came up as developers like Simone Bellavia noted the anniversary of the proposal and discovered a decision had been made on Safe C++. One year ago, Baxter told The Reg that the project would enable C++ developers to get the memory safety of Rust, but without having to learn a new language. "Safe C++ prevents users from writing unsound code," he said. "This includes compile-time intelligence like borrow checking to prevent use-after-free bugs and initialization analysis for type safety." Safe C++ would enable incremental migration of code, since it only applies to code in the safe context. Existing unsafe code would run as before. Even the matter of whether the proposal has been abandoned is not clear-cut. Erich Keane, C++ committee member and co-chair of the C++ Evolution Working Group (EWG), said that Baxter's proposal "got a vote of encouragement where roughly 1/2 (20/45) of the people encouraged Sean's paper, and 30/45 encouraged work on profiles (with 6 neutral)... Sean is completely welcome to continue the effort, and many in the committee would love to see him make further effort on standardizing it." In response, Baxter said: "The Rust safety model is unpopular with the committee. Further work on my end won't change that. Profiles won the argument." He added that the language evolution principles adopted by the EWG include the statement that "we should avoid requiring a safe or pure function annotation that has the semantics that a safe or pure function can only call other safe or pure functions." This, he said, is an "irreconcilable design disagreement...."

Read more of this story at Slashdot.

Microsoft is now prioritizing Anthropic's Claude 4 over OpenAI's GPT-5 in Visual Studio Code's auto model feature, signaling a quiet but clear shift in preference. The Verge reports: "Based on internal benchmarks, Claude Sonnet 4 is our recommended model for GitHub Copilot," said Julia Liuson, head of Microsoft's developer division, in an internal email in June. While that guidance was issued ahead of the GPT-5 release, I understand Microsoft's model guidance hasn't changed. Microsoft is also making "significant investments" in training its own AI models. "We're also going to be making significant investments in our own cluster. So today, MAI-1-preview was only trained on 15,000 H100s, a tiny cluster in the grand scheme of things," said Microsoft AI chief Mustafa Suleyman, in an employee-only town hall last week. Microsoft is also reportedly planning to use Anthropic's AI models for some features in its Microsoft 365 apps soon. The Information reports that the Microsoft 365 Copilot will be "partly powered by Anthropic models," after Microsoft found that some of these models outperformed OpenAI in Excel and PowerPoint.

Read more of this story at Slashdot.

An anonymous reader quotes a report from TechCrunch: Carla Rover once spent 30 minutes sobbing after having to restart a project she vibe coded. Rover has been in the industry for 15 years, mainly working as a web developer. She's now building a startup, alongside her son, that creates custom machine learning models for marketplaces. She called vibe coding a beautiful, endless cocktail napkin on which one can perpetually sketch ideas. But dealing with AI-generated code that one hopes to use in production can be "worse than babysitting," she said, as these AI models can mess up work in ways that are hard to predict. She had turned to AI coding in a need for speed with her startup, as is the promise of AI tools. "Because I needed to be quick and impressive, I took a shortcut and did not scan those files after the automated review," she said. "When I did do it manually, I found so much wrong. When I used a third-party tool, I found more. And I learned my lesson." She and her son wound up restarting their whole project -- hence the tears. "I handed it off like the copilot was an employee," she said. "It isn't." Rover is like many experienced programmers turning to AI for coding help. But such programmers are also finding themselves acting like AI babysitters -- rewriting and fact-checking the code the AI spits out. A recent report by content delivery platform company Fastly found that at least 95% of the nearly 800 developers it surveyed said they spend extra time fixing AI-generated code, with the load of such verification falling most heavily on the shoulders of senior developers. These experienced coders have discovered issues with AI-generated code ranging from hallucinating package names to deleting important information and security risks. Left unchecked, AI code can leave a product far more buggy than what humans would produce. Working with AI-generated code has become such a problem that it's given rise to a new corporate coding job known as "vibe code cleanup specialist." TechCrunch spoke to experienced coders about their time using AI-generated code about what they see as the future of vibe coding. Thoughts varied, but one thing remained certain: The technology still has a long way to go. "Using a coding co-pilot is kind of like giving a coffee pot to a smart six-year-old and saying, 'Please take this into the dining room and pour coffee for the family,'" Rover said. Can they do it? Possibly. Could they fail? Definitely. And most likely, if they do fail, they aren't going to tell you. "It doesn't make the kid less clever," she continued. "It just means you can't delegate [a task] like that completely." Further reading: The Software Engineers Paid To Fix Vibe Coded Messes

Read more of this story at Slashdot.

In July 791 professional coders were surveyed by Fastly about their use of AI coding tools, reports InfoWorld. The results? "About a third of senior developers (10+ years of experience) say over half their shipped code is AI-generated," Fastly writes, "nearly two and a half times the rate reported by junior developers (0-2 years of experience), at 13%." "AI will bench test code and find errors much faster than a human, repairing them seamlessly. This has been the case many times," one senior developer said... Senior developers were also more likely to say they invest time fixing AI-generated code. Just under 30% of seniors reported editing AI output enough to offset most of the time savings, compared to 17% of juniors. Even so, 59% of seniors say AI tools help them ship faster overall, compared to 49% of juniors. Just over 50% of junior developers say AI makes them moderately faster. By contrast, only 39% of more senior developers say the same. But senior devs are more likely to report significant speed gains: 26% say AI makes them a lot faster, double the 13% of junior devs who agree. One reason for this gap may be that senior developers are simply better equipped to catch and correct AI's mistakes... Nearly 1 in 3 developers (28%) say they frequently have to fix or edit AI-generated code enough that it offsets most of the time savings. Only 14% say they rarely need to make changes. And yet, over half of developers still feel faster with AI tools like Copilot, Gemini, or Claude. Fastly's survey isn't alone in calling AI productivity gains into question. A recent randomized controlled trial (RCT) of experienced open-source developers found something even more striking: when developers used AI tools, they took 19% longer to complete their tasks. This disconnect may come down to psychology. AI coding often feels smooth... but the early speed gains are often followed by cycles of editing, testing, and reworking that eat into any gains. This pattern is echoed both in conversations we've had with Fastly developers and in many of the comments we received in our survey... Yet, AI still seems to improve developer job satisfaction. Nearly 80% of developers say AI tools make coding more enjoyable... Enjoyment doesn't equal efficiency, but in a profession wrestling with burnout and backlogs, that morale boost might still count for something. Fastly quotes one developer who said their AI tool "saves time by using boilerplate code, but it also needs manual fixes for inefficiencies, which keep productivity in check." The study also found the practice of green coding "goes up sharply with experience. Just over 56% of junior developers say they actively consider energy use in their work, while nearly 80% among mid- and senior-level engineers consider this when coding."

Read more of this story at Slashdot.

"I'm still teaching at Princeton," 83-year-old Brian Kernighan recently told an audience at New Jersey's InfoAge Science and History Museums. And last month the video was uploaded to YouTube, a new article points out, "showing that his talk ended with a unique question-and-answer session that turned almost historic..." "Do you think there's any sort of merit to Rust replacing C?" one audience member asked... "Or is this just a huge hype bubble that's waiting to die down...?" '"I have written only one Rust program, so you should take all of this with a giant grain of salt," he said. "And I found it a — pain... I just couldn't grok the mechanisms that were required to do memory safety, in a program where memory wasn't even an issue!" Speaking of Rust, Kernighan said "The support mechanism that went with it — this notion of crates and barrels and things like that — was just incomprehensibly big and slow. And the compiler was slow, the code that came out was slow..." All in all, Kernighan had had a bad experience. "When I tried to figure out what was going on, the language had changed since the last time somebody had posted a description! And so it took days to write a program which in other languages would take maybe five minutes..." It was his one and only experience with the language, so Kernighan acknowledged that when it comes to Rust "I'm probably unduly cynical. "But I'm — I don't think it's gonna replace C right away, anyway." Kernighan was also asked about NixOS and HolyC — but his formative experiences remain rooted in Bell Labs starts in the 1970s, where he remembers it was "great fun to hang out with these people." And he acknowledged that the descendants of Unix now power nearly every cellphone. "I find it intriguing... And I also find it kind of irritating that underneath there is a system that I could do things with — but I can't get at it!" Kernighan answered questions from Slashdot readers in 2009 and again in 2015...

Read more of this story at Slashdot.