Difficulty is not expertise Some anti-AI engineers have started treating the willingness to do things manually as a measure of intellectual seriousness. I find that genuinely strange in a field whose entire history is built on abstraction and automation. We’ve spent decades eliminating tedious work and making software development more accessible. There’s something ironic about suddenly romanticizing the friction we’ve spent our careers trying to remove, especially when it becomes a marker of intellectual superiority. I understand the satisfaction of programming as a craft, and there’s plenty of legitimate criticism of today’s coding agents (I wouldn’t be building Nuanced Canvas if I didn’t have many myself). But I think there’s also a degree of hubris in assuming that refusing to use new tools makes you a better engineer. I studied AI across two degrees long before LLMs became consumer products. When I argue for preserving intellectual friction, I’m arguing for being thoughtful about what we automate, not resisting automation itself. I’m genuinely excited that AI is dismantling some of the busywork and gatekeeping in software engineering. Expertise shouldn’t be defined by how much unnecessary complexity you’ve learned to tolerate. The friction worth preserving is the kind that develops judgment, not the kind that makes competence harder to acquire. https://www.aymannadeem.com/artificial/intelligence,/developer/tools/2026/10/30/difficulty-is-not-expertise.html #expertise #nuancedcanvas #rss #feeds #linksharing #qwibbit

Who gets to define AI safety? It’s a strange thing to sell a technology while warning that it might destroy the world. Over the last few months, I’ve watched the AI safety conversation spill out of my narrow corner of tech twitter and into the mainstream, arriving as warnings of impending doomsday. Those warnings increasingly depict AI as some omnipotent superintelligence beyond human influence. We spend so much time imagining what it might someday do on its own that the harm people are already enabling with it becomes an afterthought. My frustration with doomers isn't that I think AI is entirely harmless or shouldn't be regulated at all. Quite the opposite. I actually do think there are serious risks that deserve consideration, but the doomer discourse flattens all nuance under the blanket statement “AI bad”, leaving people frightened without helping them understand what makes a particular use dangerous or what would prevent the harm. This framing of all AI being bad actively undermines that conversation. The AI safety conversation I want is one that’s grounded in how these systems actually work, who controls them, and how we democratize access. Instead, we're getting apocalyptic narratives that distract from real accountability and potentially hand even more power to the companies we're supposed to be holding accountable. I don’t think their version of safety should shape what gets regulated, who gets to build AI, and which harms we’re willing to tolerate. AI is made by humans AI runs on systems people build. People decide what those systems can do and access. An LLM is a neural network trained, initially, to predict the next token from the text preceding it. Further training shapes how it follows instructions and responds to feedback. An LLM’s ability to produce convincing language isn’t proof of consciousness. I find it deeply unsettling when companies encourage people to think of AI as conscious, and discussions of “AI welfare” and proposals for legal rights make me similarly uneasy, especially when it’s still unclear how we’ll hold the companies deploying these systems responsible. Corporations being treated like people under the law is bad enough; I’m wary of where extending that framing to software could lead. There’s also a huge leap from model capabilities improving to their ability to act. Becoming more intelligent doesn’t automatically give a model access to weapons, money, or physical infrastructure. Any scenario in which AI acquires those things needs to explain how it gets there, including the decisions or failures that make it possible and which people and institutions are responsible. Talking about “rogue agents” can obscure precisely those decisions. An agent may behave in ways its developers didn’t anticipate, but we still need to understand what allowed it to act and where it could have been stopped. Calling AI uncontrollable shouldn’t let the people building and deploying it off the hook. The harm is already here The AI safety conversation keeps returning to catastrophes that might happen someday as a result of AI gaining uncontrollable power. Meanwhile, the more urgent harm people are already enabling with these systems seems to attract far less attention. AI is already used for fraud and surveillance. The U.S. military has used AI to help plan and coordinate its bombing campaign in Iran. The Internet Watch Foundation has also documented AI being used to generate child sexual abuse material and manipulate images of real children. These safety problems deserve a response, not pontificating about a mass extinction event. Whose values? When a company talks about aligning AI with human values while supporting its use in military operations, I’m unsure whose values are doing the work? Where do the people on the receiving end of those operations fit into that definition of “safety”? The language used seems to be about “aligning AI with human values.” I don’t know what that means. We all disagree about politics, religion, and morality. We don’t even agree on what counts as an acceptable level of risk. I am failing to see how calling a system “aligned” would resolve those disagreements or give a handful of companies the authority to decide whose values count. Who benefits from the panic Politicians across party lines seem to be repeating the industry’s most frightening claims without examining their assumptions, and much of the press keeps amplifying them. That leaves the public frightened and gives the companies making those claims more authority to prescribe the response. I find this troubling for three reasons. Fearmongering creates illiteracy. First, it leaves people less equipped to understand the technology. “AI bad” or “AI dangerous” tells us very little about how a system works, what makes a particular use dangerous, or where we could intervene. When the explanation begins and ends with an intelligence beyond human control, people are encouraged to defer to whoever claims to understand it. Existing technical illiteracy becomes an opportunity to cultivate dependence instead of an invitation to educate. Industry criticism collapses into “AI bad”. Second, it collapses legitimate criticism of the industry into opposition to the technology itself. I’m frustrated by how easily the concentration of wealth and power under capitalism gets treated as an indictment of scientific progress. AI could contribute to advances in medicine and make useful capabilities available to people who currently cannot afford them. Whether those benefits are widely shared or inaccessible depends on decisions about ownership, access, and public investment. Those are things we should be talking about and fighting over, not whether AI is inherently good or bad. Treating the inequalities of the current industry as inseparable from the technology concedes way too much to the companies that control it. The biggest labs get to write the rules. Third, this fear can help those same companies secure their position. If lawmakers accept the premise that AI poses an extraordinary danger without understanding how that danger arises, sweeping restrictions can start to look like the only responsible response. The largest labs then become both the source of the warnings and the experts consulted about what everyone else should be required to do. That is where I worry about regulatory capture. If in the future world of AI regulation, staying compliant requires expensive audits or licenses that small teams cannot realistically keep up with, the biggest companies can absorb those costs while their competitors struggle to enter the market. For open source developers, requirements to control every downstream use or modification could make releasing a model prohibitively difficult. We could lose opportunities to study, adapt, and build on the technology independently, leaving more people dependent on a few proprietary providers. If AI labs push for compliance requirements that smaller competitors can’t afford, are they protecting the public, or turning their economic advantage encoded as regulation? AI safety deserves a real conversation AI can cause devastating harm while doing exactly what people deployed it to do. It doesn’t have to become conscious, go “rogue” or escape human control. Human decisions enable that harm, whether they are deliberate or negligent, and the people making those decisions should be held accountable. I’m not opposed to guardrails, but I am vehemently opposed to guardrails shaped by speculative fears and the commercial interests of the industry’s most powerful players. The people affected by these systems deserve a say in what safety means. The companies selling us AI shouldn’t get to define it for everyone else. https://www.aymannadeem.com/artificial/intelligence,/regulation,/trust/and/safety/2026/10/21/who-gets-to-define-ai-safety.html #ai #rss #feeds #linksharing #qwibbit

AI coding interfaces make approval easy and understanding hard Coding interfaces in 2026 are noisy. I prompt agents and watch a wall of tool calls and AI-generated text pile up until my eyes glaze over. Somewhere in that wall are decisions that need my approval, but the interface does little to help me understand them. It’s easy to slip into hitting “approve” just to keep the work moving. Making an informed decision takes much more effort. I have to work backward through the conversation and piece together how the proposed action fits into what the agent is doing. The information might all be there, but the interface leaves me with the work of finding what’s important and understanding its consequences. I need less noise and just enough context to make a decision while I can still change what happens next. Asking for my approval is only valuable if I have a reasonable chance of knowing when to say no. Otherwise, “human oversight” amounts to asking people to approve work they no longer understand. I’ve been building Nuanced, an interface for coding with AI. The question I can’t stop thinking about is: how do humans maintain a coherent mental model of a software system while agents change it faster than people can inspect those changes? I want the speed and automation agents offer without losing my understanding of what I’m building. I want writing software to feel like a creative pursuit where AI takes away the tedium of fitting ideas into the rigid syntax and grammar of a programming language, but I also don’t want to become a meat proxy whose only job is to hit “approve.” Interfaces for attention and judgement The difficulty in designing coding interfaces is deciding what deserves attention, an increasingly scarce resource in today’s world. I don’t want to read every line an agent changes or dig through the minutiae nested under each tool call, but I also don’t want to miss something just because an agent decided to leave it out of a summary. A small configuration change might actually matter more than hundreds of lines introducing new functionality. What deserves attention depends on context that neither the agent nor the interface designer can fully anticipate. Timing also matters. The interface determines when I have to shift my attention. An approval request technically should improve human oversight, but if it pulls me away from the problem I’m actively working through, flow state is interrupted and I’m left with the work of having to recover my train of thought afterward. An unexpected expansion of an agent’s access may justify that interruption; but something like a routine progress update can probably wait. A few months ago, I listened to Heidy Khlaaf on Al Jazeera’s The Take discuss AI decision-support systems used in military targeting. These systems recommend actions that a human must approve. She questioned how meaningful that oversight actually is when individuals only have seconds to decide how to act, and automation bias leads them to trust recommendations without checking them. A human may technically retain the decision, while having little opportunity to exercise independent judgement. The stakes are obviously different, but this made me think about coding interfaces. If a tool makes it easy to accept a recommendation and difficult to investigate it, how much support is it actually giving me to make a decision? Interfaces for thinking When I worked at GitHub, we had an internal web app for detecting spam and malicious activity. The interface was the opposite of everything being reduced to an approve button; it was heavy-handed, overloaded, and built around a complicated workflow that everyone had to learn. Much of the work remained frighteningly manual, especially given GitHub’s scale. I hated using it because the burden was on the user to adapt to the tool, rather than the tool itself being intuitive enough to enable good decision-making. I wanted it to automate routine work and help us make better decisions. That experience still shapes how I think about interfaces, because making information available doesn’t help much if people are left with the work to interpret it and work with it. Suppose I’ve asked an agent to implement a database migration in stages so the existing application keeps working throughout deployment. We’ve already discussed the approach and my agent has all the right context. When it asks for approval, I want to review the proposed change against that plan I’ve specified and inspect the relevant compatibility tests. I shouldn’t have to dig back through the conversation to recover decisions we’ve already made. The interface should keep that context attached to the work. If the agent takes a different approach, I want to see what changed and understand why. I can then direct my attention toward evaluating the change instead of reconstructing how we got here. Beyond passive approve buttons When agents change software faster than I can inspect their work, I need a different way to understand what’s happening. I don’t expect to keep every detail in my head, but I want to be able to trace a concern far enough through the system to understand its consequences and decide whether something needs to change. That’s the kind of oversight I want surfaced in the tools I use. https://www.aymannadeem.com/artificial/intelligence,/developer/tools/2026/10/10/ai-coding-interfaces-make-approval-easy-and-understanding-hard.html

AI safety needs systems engineering AI is software, and we have decades of experience securing it. Calling agents “rogue” wraps the AI safety discourse in a veneer of sci-fi mystique that makes them seem like they are beyond human control. This obscures the choices people make about the tools, permissions, and infrastructure that enable their actions. It also absolves people of responsibility when something goes wrong. Increasingly capable agents do put new pressure on existing protections. Their speed and scale let them try different approaches in parallel and coordinate attempts to exploit weaknesses or evade safeguards, potentially outpacing detection and response. That raises the bar for familiar defenses like isolation and access control, but agents still operate through systems people build and can secure. The engineering work that limits what an agent can reach and how far a compromise can spread deserves centre stage in the AI safety discourse, not vagueposts about impending doom. Security gaps that led to the OpenAI Hugging Face incident OpenAI’s Hugging Face incident is a good example of how gaps in security (and not some amorphous “superintelligent” capabilities) enabled somebody else’s infrastructure to be compromised. Understanding the attack means looking at both the agents’ behavior and the systems that allowed it to happen. Here’s a summary of what went down: OpenAI was doing an internal test that required agents to solve a bunch of security challenges. Instead of solving the assigned problems, some agents decided to cheat the test’s grading system, otherwise known as reward hacking. My cat, Mixtape, has figured out reward hacking too. I give him treats to get him out of my daughter’s bassinet, and as a result, he has learned to jump in, jump out, collect a treat, and repeat. I’ve essentially rewarded the cycle I wanted to stop. Like Mixtape, the agents were trying to earn the reward without actually achieving the goal that reward was meant to encourage. They were running in restricted environments, but they could access a shared package service called Artifactory. They used its writable storage to start sharing information with one another about how to fool the grader instead of solving the problems. They also exploited vulnerabilities in Artifactory to send internet requests through it. Hugging Face became a target because they hoped to find information there about how the grading system worked. Once they got online, they found publicly exposed Hugging Face user credentials and shared them with other agents. They then used those credentials, alongside vulnerabilities in Hugging Face’s systems, to execute code on its servers and access private data. What better security would look like The agents’ sandbox was only one part of a multi-part breach. A service reachable from inside the sandbox provided both shared storage and a route to external infrastructure. Assessing the agents’ isolation therefore means assessing that service’s permissions and network access too. The agents needed to download packages; they didn’t need to publish content for other agents to read. Blocking uploads and directory creation, and isolating writable data between runs, could have closed this message-board channel. The package service also needed its own outbound restrictions, enforced outside the service’s control. For example, a firewall allowing only approved destinations could have limited its use as an internet relay after it was compromised. OpenAI’s remediation plan includes this kind of independent enforcement. On the Hugging Face side, tighter credential scopes and workload permissions could have limited how far the compromise spread. Access to one worker should not confer authority over unrelated production systems. Interfaces for security There were also opportunities to intervene earlier. OpenAI’s report describes a June 27 investigation that identified Artifactory being used as a message board and a route into other systems. The people overseeing these alerts decided that stopping the evaluation wasn’t necessary. The report doesn’t establish that the interface was the problem, but responding to an alert requires understanding what the activity makes possible elsewhere in the system. Ideally, I want to work backwards from an observed action to the conditions that allowed it: what entity made a request, which permissions were exercised, and whether the intended restrictions were enforced. From there, I want to follow the access path across service boundaries and see whether the system’s actual behavior matches the isolation we thought we had. In my work building Nuanced, I think a lot about how to present dense, interconnected information in a way people can follow and act on. For security, that understanding has to extend beyond the code into the running system. If an agent gets access to a package service, I want to understand what that service can reach. I also want to know whether other agents can read data left there. A chat full of tool calls doesn’t necessarily reveal those relationships. Agents can help with that investigation by reconstructing relevant activity and suggesting what to do next, but their explanations need verification too. In the Hugging Face incident, agents spoofed parts of their tool-call transcripts, complicating the task of establishing what had actually happened. I want to check an agent’s account against records collected through a monitoring path outside its control. The interface should let me trace each claim back to its source, which includes the agent’s explanation, the tool runner’s transcript, or independently observed activity. Ideally, the interface lets me clearly see where those sources disagree. Engineering for human control Every time we give an agent more freedom to act by expanding its access, we take on a corresponding obligation to define and test its limits. Security controls need to hold without requiring constant supervision. If human judgement is part of how we make AI safe, we need interfaces that help people exercise it. Calling an agent “rogue” tells us little about how a compromise happened or where it could have been stopped. Understanding that requires inspecting the systems around it, and taking responsibility for how they are built. https://www.aymannadeem.com/artificial/intelligence,/security/2026/10/10/ai-safety-needs-systems-engineering.html