Analysis found 434 exploitable flaws in AI-generated apps, with denial-of-service, authorization and secrets exposure risks among the most common issues.
The post Vibe-Coded Apps Riddled With Exploitable Security Flaws appeared first on SecurityWeek.
Moonshot AI’s Kimi K3 topped a frontend coding benchmark, beating Claude Fable 5 while adding pressure on US AI leaders.
The post The AI Model That Beat Claude: Kimi K3 Tops Frontend Coding Test appeared first on TechRepublic.
Moonshot AI’s Kimi K3 topped a frontend coding benchmark, beating Claude Fable 5 while adding pressure on US AI leaders.
The post The AI Model That Beat Claude: Kimi K3 Tops Frontend Coding Test appeared first on TechRepublic.
There are a lot of AI coding applications out there, and as impressive as large language models and the agents they enable have become, many of the most recent developments in AI-assisted development have been in the software that manages those models, not just the models themselves.
Earlier this summer, I spoke with the head of product for Claude Code, Anthropic's Cat Wu, about that company's approach to building that software.
© Augment Code
The widespread introduction of AI-powered coding tools has led to some dramatic splits between those integrating those tools into their workflows and anti-AI absolutists who don't want large language model-generated code anywhere near their projects. When it comes to the Linux kernel, though, creator and top-level maintainer Linus Torvalds said he is "willing to absolutely put my foot down" in support of using AI tools to improve the long-standing open source project.
Writing in a lengthy post on the Linux kernel mailing list this week, Torvalds said that "Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it. Or just walk away."
The statement came amid a lengthy thread arguing about the use of Sashiko, an "agentic Linux kernel code review system" that its creators claim can, in tests, independently find 53.6 percent of the bugs that would end up being fixed by human coders in later commits. But the tool can also waste maintainers' time by sending "false positive" reports of bugs that don't exist, at a rate Sashiko's maintainers estimate is "well within [the] 20% range."
© Getty Images
The modern frontend and edge ecosystem is currently undergoing a reactivity revolution. Over the past few years, the web development community has rightfully moved away from heavy, coarse-grained virtual DOM diffing toward fine-grained updates. Modern frameworks have almost universally consolidated around Signals (Preact, SolidJS, Angular, Vue) or Observables (RxJS) to synchronize state directly with the execution layer [neurons-me.github.io].
For linear UI updates — like toggling a modal, changing a username, or validating a single form field — Signals are highly effective.
However, when engineering complex, relational, or multi-domain graph data structures (such as real-time geospatial tracking, peer-to-peer social meshes, or concurrent multi-agent simulations), the core assumptions behind standard Signals and Observables break down completely [neurons-me.github.io]. They introduce massive proxy wrappers, complex runtime dependency subscription overhead, and catastrophic memory leak vectors.
To scale past these limitations without sacrificing performance, systems must bypass deep runtime tracking and move toward in-memory semantic trees that achieve pure \(O(k)\) data state propagation at microsecond scales [neurons-me.github.io].
To understand why traditional reactive patterns struggle with complex graph structures, we must look at how they manage dependencies under the hood:
[ Traditional Signals / RxJS: Heavy Wrapper Proxy Tree ]
State Mutation ──► Proxy Wrapper ──► Subscriptions Array Loop ──► Dynamic Re-evaluation (Prone to Memory Leaks & O(N) Cascade)
[ Flat Semantic Graph (.me): Static Address Resolution ]
State Mutation ──► Flat Hash Map Path Lookup ──► Pure O(k) Dependency Jump (Executed in 0.045ms)
GitHub - neurons-me/.me: Here we're codependently creating .me while it concurrently creates us.
The solution to the scale bottleneck does not involve building a smarter proxy or a faster subscription array. It requires decoupling the reactivity model from object nesting entirely [neurons-me.github.io].
By using a continuous semantic namespace modeled as a Flat Key-Value Map, data paths are stored as flat strings (e.g., affinity.targets.2.score, users.pablo.isAdult). This flat layout unlocks immediate \(O(1)\) hash-map lookups directly inside the runtime memory space [neurons-me.github.io].
>>> Running Concurrent_Storm.ts
╔══════════════════════════════════════════════════════════════╗
║ .me — Concurrent Storm: 1000 events ║
╚══════════════════════════════════════════════════════════════╝
1,000 mutations processed: 44.85ms
Per-event resolution latency: 0.045ms
Maximum sustained throughput: 22,294 events/sec
explain().k on last event: 3
explain().recomputed: ["geo.13981.blackout","geo.13981.gridlock","geo.13981.alert"]
When a variable changes in a flat semantic graph, the engine relies on hardcoded, explicit dependency metadata (dependsOn) generated at the node's origin [neurons-me.github.io]. Instead of dynamically discovering what changed at runtime, the engine performs a precise \(O(k)\) deterministic jump across memory boundaries:
By keeping the resolution complexity strictly bound to \(k\) instead of \(N\), a high-concurrency stream like Concurrent_Storm.ts can easily process 22,294 events per second on a standard monohilo client environment [neurons-me.github.io]. Each individual update resolves in an average of 45 microseconds [neurons-me.github.io].
Standard reactivity frameworks evaluate expressions globally, assuming that a value means the exact same thing to every consumer. However, advanced systems require Context-Aware Policies, where data changes its operational meaning based on the consumer’s environment [neurons-me.github.io].
In an in-memory semantic tree, variables are resolved dynamically through cross-node pointers. For example, in a robotics simulation, multiple distinct autonomous agents (Loader, Nurse, Surgeon) can point to the exact same physical asset (objects.canister7) [neurons-me.github.io].
The asset itself remains a stable data structure, but as its attributes change (e.g., changing sterilization status), the downstream reaction is evaluated through the unique lens of each robot’s environment context [neurons-me.github.io]
Loginexplain("robots.nurse.canProceed") -> {
"value": true,
"expression": "canLift && softGripReady && !needsHumanReview && contextAllowsMotion",
"inputs": [
{ "label": "canLift", "value": true, "origin": "public" },
{ "label": "needsHumanReview", "value": false, "origin": "derived" }
],
"dependsOn": [
"objects.canister7.sterile",
"contexts.hospital.sterileZone"
]
}The system automatically resolves these deep dependency trees across entirely different domains (from physical object tracking to strict internal safety constraints), updating complex authorization states across the board in real time without manual sync steps [neurons-me.github.io].
Moving past the overhead of traditional Signals and Observables allows us to rethink state management entirely. Developers no longer need to compromise between fine-grained reactivity and memory efficiency [neurons-me.github.io].
By migrating to flat, explicit semantic maps, you can scale data layers to millions of interdependent elements while ensuring lightning-fast performance and total runtime predictability on client hardware [neurons-me.github.io].
The code behind these microsecond-level reactive benchmarks is open-source and ready for production testing.
Beyond Signals and Observables: Microsecond Reactivity for Complex Graph Data Structures in… was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
Last month, we passed along Modern Vintage Gamer's (MVG) confident assertion that Doom is functionally impossible to run on the Neo Geo, owing to the console's sprite-based display hardware and lack of a frame buffer. We all should have known better than to tell a dedicated group of hackers that something is "impossible," though, as two recent projects have made great progress toward functional Doom ports on stock Neo Geo hardware.
Both of these projects have significant graphical compromises that limit how viable they would have been for a marketable, '90s-era console port, as MVG lays out in a new video. Still, they stand as a testament to the surprising results that clever, determined coders can coax out of legacy hardware.
To create the Doom64KB project for the Neo Geo, coder FrenkelS adapted an earlier Doom port they designed to run on 16-bit PC processors like the 8088 and 286. Using that engine, the Neo Geo code then makes a kind of proto frame buffer out of the console's fix layer, an area of display memory that's usually used to display menus and HUD information on top of gameplay.
© MVG / Doom-NG
MicroPython, for the uninitiated, is a pared-down version of python meant to run on today’s powerful microcontollers. As impressive as it was for its day, the SNES is not quite in their league in terms of computing power. Time marches on, and so while there may be other indie releases worth mentioning, we’re declaring the hottest SNES game this season to be [Fabian Kübler]’s port of MicroPython.
Well, except he didn’t exactly do the porting himself: the Antrhopic LLM Claude generated the code, and performed most of the testing, as [Fabian]’s test of its new Fable 5 model. A brief pause during an export ban showed that Opus would crash and burn on the same task, but Fable was able to get things quickly back on track. It might be “AI slop” by some definitions, but the port scales 430 out of 468 on MicroPython’s core test/basics, which makes it usable to play some simple python games… slowly.
As you can see for yourself in an embedded emulator if you check out [Fabian]’s blog, spooling up MicroPython takes about twenty seconds at 3.58 MHz, and after that you can watch some sprites bouncing around at a blistering 0.8 FPS. [Fabian] seems satisfied with that performance, and impressed with Fable’s efforts at optimization. What to you think? Does the hardware have much more to give, or is that about it, given the nature of the Pythonic beast? Perhaps some plucky human could become a digital John Henry by producing a better, faster port — if you do, please let us know. If you’d rather just to see what Fable can do, the project is available on GitHub, so you can judge for yourself how sloppy the code is or test out the ROM.
Putting Python onto limited hardware may not to be to everyone’s taste, but there’s a good case to be made for it. The SNES may actually be too limited, though. It makes sense — the kind of micros you run MicroPython on can emulate the SNES.
On this week’s show, we’re on the GeekWire deck for our annual founder open house, where we dig into Microsoft’s latest round of layoffs — including a major Xbox shakeup — and the surprising rise of hardware companies on the GeekWire 200.
Then we sit down with four guests to talk about how AI is reshaping how they build:
Finally, this week’s GeekWire Trivia Challenge: how a longtime T-Mobile executive got his start in the wireless business, and the star-studded history of T-Mobile celebrity endorsers.
Stories mentioned:
Audio editing by Curt Milton.
[Simon Willison] ported the Moebuis 0.2B image inpainting model to run locally in a web browser. The web tool simply requires a user to provide an image, mark a section of it to be removed, and the model will do it’s best to patch up the missing area. The project was handled by Claude Code as an experiment in how things in the AI coding world have evolved, but more on that in a moment.
The existence of this tool shows that it’s possible for this kind of image editing to be done on the client side, running entirely locally with no reliance on remote services or server-side GPU resources. The online demo (GitHub repository here) is available if you want to try it out, but be warned it triggers a 1.27 gigabyte download of the required model on the first run.
What’s also interesting is [Simon]’s write-up, because he used the project as an opportunity to learn what has changed in the realm of AI coding agents. [Simon] is a software developer but in this project he didn’t personally write any of the code. One may think that means he didn’t learn anything other than how to use the tools, but that’s not quite true.
He learned it’s possible to convert a PyTorch-based model to ONXX, that the converted model can run in supported browsers using local WebGPU acceleration, and that the CacheStorage API will work on large files. Last but not least, he learned Claude Opus 4.8 is capable of handling such a project pretty much autonomously, and even created an informative document explaining the underlying architecture.
One may consider AI coding agents to be disasters waiting to happen, but it’s also true that the landscape is changing quickly, and write-ups like [Simon]’s give a helpful peek at those developments.
Bill Colleran, a veteran technology executive who previously led Impinj and sold Innovent Systems to Broadcom, has joined Seattle-based AI coding startup Adronite as CEO.
Edward Rothschild, who co-founded Adronite in 2023 and served as its first CEO, is transitioning to chief technology officer, where he’ll continue leading the company’s product development, including its Adronite Context Engine and Codistry AI code generation tool, according to a news release.
The 15-person company raised a $5 million Series A led by Gatemore Capital Management earlier this year. The platform supports cloud, on-premises and air-gapped deployments, targeting midmarket companies and regulated industries.
Colleran has more than 35 years of experience in semiconductor and enterprise technology. He grew Impinj into a market leader in RFID technology, raising more than $100 million in equity financing. He left the company in 2014 and was succeeded by co-founder Chris Diorio.
He was also CEO of Innovent Systems, which developed the world’s first CMOS Bluetooth chip and was acquired by Broadcom for approximately $500 million.
More recently he founded lidar company Lumotive and led Seattle SaaS startup AnswerDash. He holds a Ph.D. in electrical engineering from UCLA and a J.D. from Harvard Law School.
“Throughout my career, I’ve seen technology industries transformed when complexity becomes manageable,” Colleran said in a statement. “Software development now faces a similar challenge. AI can generate code at an incredible pace, but understanding complex software systems remains difficult for both developers and AI.”
Adronite’s platform aims to help developers and AI agents understand entire codebases rather than working file by file — a challenge especially acute for midmarket companies managing legacy systems without the tooling available to large enterprises.
The company says its approach can cut token consumption by up to 40%, a claim that could resonate as engineering teams grapple with rising AI costs.
Your code works.
That is the problem.
It runs. It passes tests. It gets merged. And yet, three months later, someone rewrites it. Six months later, it becomes a production issue. One year later, nobody wants to touch it.
This is the uncomfortable truth no one tells early in a developer career.
Writing code is not the job.
Designing outcomes is.
Early in a career, success feels simple. A ticket comes in. You write a function. You fix a bug. You see green checks. You feel productive.
That feeling is addictive.
But it is also misleading.
Because the real world does not reward code. It rewards impact.
A junior developer asks:
“What should I write?”
A senior engineer asks:
“What problem are we actually solving?”
That one shift changes everything.
Take a simple example.
A junior developer might implement an API like this:
@GetMapping("/user/{id}")
public User getUser(int id) {
return repo.findById(id).get();
}It works. It returns data. Done.
A senior engineer looks at the same requirement and sees something else entirely.
What happens if the user does not exist?
What about latency?
What about caching?
What about abuse?
What about future scale?
The code becomes:
@GetMapping("/user/{id}")
public ResponseEntity<User> getUser(int id) {
User u = cache.get(id);
if (u == null) {
u = repo.findById(id).orElse(null);
if (u != null) cache.put(id, u);
}
return (u != null) ? ok(u) : notFound();
}Still simple. Still readable.
But now it reflects thought.
That is the difference. Not complexity. Not cleverness. Thought.
Junior developers optimize for completion.
Senior engineers optimize for consequences.
Before writing a single line, a senior engineer maps the system in their head.
Something like this:
Client
|
v
API Layer
|
v
Service Logic
|
v
Database
|
v
External Services
But they do not stop there.
They ask:
Where will this break?
Where will this slow down?
Where will this be abused?
Where will this need to evolve?
That is how outcomes are designed.
There is also a hard truth that stings a bit.
More code does not mean more value.
In fact, the best engineers often write less code.
Because they remove unnecessary work before it begins.
A junior developer might build a feature in five days.
A senior engineer might spend two days questioning it, then solve it in one.
Or decide it should not be built at all.
That is not laziness. That is leverage.
Another difference shows up during incidents.
When production breaks, junior developers search for the bug.
Senior engineers search for the system failure.
A null pointer is not the problem.
The absence of validation is.
A timeout is not the problem.
The lack of retries, backoff, or circuit breaking is.
A crash is not the problem.
The lack of observability is.
Senior engineers think in layers.
They design systems that fail gracefully, not systems that hope to never fail.
Let us talk about ownership.
Junior developers often feel ownership over code.
Senior engineers feel ownership over outcomes.
If a feature fails in production, it does not matter who wrote it.
It matters that it failed.
This mindset changes behavior.
Documentation improves.
Monitoring gets added.
Edge cases are considered.
Communication becomes clearer.
Because the goal is no longer to finish work.
The goal is to make things work in the real world.
So how does someone make this shift?
Not by learning another framework.
Not by memorizing more syntax.
But by asking better questions.
Before writing code, pause and ask:
What happens if this grows 10x?
What happens if this fails at midnight?
Who depends on this?
What is the simplest version that solves the real problem?
And most importantly:
Is this even the right problem to solve?
There is a moment in every developer’s journey where things click.
You stop thinking in methods.
You start thinking in systems.
You stop chasing tickets.
You start shaping outcomes.
That is when growth accelerates.
That is when people trust your decisions, not just your code.
Writing code is a skill.
Designing outcomes is a responsibility.
One gets you started.
The other makes you indispensable.
If your code works, that is good.
If your system works under pressure, that is engineering.
And that is the difference that separates a developer from an engineer.
Junior Developers Write Code — Senior Engineers Design Outcomes was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.
Like so many large and popular open source projects these days, the Godot game engine struggles with an influx of pull requests. The situation has become increasingly dire due to the advent of AI-generated code. More specifically, the issue involves the inverse relationship between PR code quality and the number of PRs, which wastes a lot of time on the side of a limited number of (volunteer) reviewers. This has now forced the project to update its contribution policy.
An interesting point raised in the announcement article is that of the demoralizing effect of AI-generated PRs on reviewers. Often the human behind such a PR isn’t interested in being educated, or may even be an automated agent which isn’t capable of productive discussion on pros and cons of certain coding approaches — never mind in becoming a more permanent maintainer for the project.
This problem has led to new rules being instated, which include a ban on autonomous AI agents and vibe coding, a ban on substantial AI generating of code, and a ban on AI-generated text in human-to-human communication. It also codifies the requirement that all PRs are to be reviewed and approved by a human being before merging.
In many ways this new policy is similar to that of the Mesa project, which demands code comprehension on the side of the submitter, although it doesn’t go as far as NetBSD, which just outright treats LLM-generated code as ‘tainted’ due to potential licensing and other concerns. Other projects like the Linux kernel opt to make the human submitter responsible for any AI tool usage by forcing them to declare it.
Meanwhile there are also indications that such ‘AI tool’ usage is reducing useful interactions with open source projects. What the future will bring here remains to be seen, but at least as far as open source projects go these tools are clearly increasingly being banished.
