• Vibe hacking

    Kevin Collier reporting for NBC News on how a hacker vibe hacked their way into various industries. This information comes from Anthropic’s Threat Intelligence Report for Aug’25.

    …one of Anthropic’s periodic reports on threats, the operation began with the hacker convincing Claude Code — Anthropic’s chatbot that specializes in “vibe coding,” or creating computer programming based on simple requests — to identify companies vulnerable to attack. Claude then created malicious software to actually steal sensitive information from the companies. Next, it organized the hacked files and analyzed them to both help determine what was sensitive and could be used to extort the victim companies.

    The chatbot then analyzed the companies’ hacked financial documents to help determine a realistic amount of bitcoin to demand in exchange for the hacker’s promise not to publish that material. It also wrote suggested extortion emails.

    The chatbot then analyzed the companies’ hacked financial documents to help determine a realistic amount of bitcoin to demand—What the…!

    Since I have started following AI news, I read about how you should break down your problem statement into smaller chunks for AI, setup a plan, do periodic reviews of code generated, and then accept the changes. I never thought this approach would be effective in hacking also.

    Filed under
  • Nuclear batteries

    Today I learned that we have something called nuclear batteries. For more than 50 years. James Blanchard talks about the genesis of these batteries, why don’t we use them anymore, what are its current applications, and more.

    In 1970, surgeons in Paris implanted the first nuclear-powered pacemaker, and over the next five years, at least 1,400 additional people received the devices, mostly in France and the United States. Encased in titanium, the batteries for these devices contained a radioactive isotope—typically about a tenth of a gram of plutonium-238—and could operate for decades without maintenance. The invention provided relief to a population of people who previously needed surgery every few years to change out their pacemaker’s chemical battery.

    Technically, they are not nuclear. They are radioisotopes.

    The term “nuclear batteries” may evoke images of tiny nuclear reactors, but that’s not how they work. Nuclear batteries don’t split atoms with neutron bombardment. Instead, they capture energy in the form of radiation that’s spontaneously released when atomic nuclei decay.

    Most research groups developing nuclear batteries are focused on harnessing energy from radioactive isotopes of nickel and hydrogen. In many nuclear battery designs, adjacent semiconductors absorb the radiation released by the radioisotopes’ nuclei and convert it to an electric current, much like a solar cell does. In other designs, thermoelectric devices convert the heat produced by the emitted radiation to electricity. So “radioisotope power source” is a better descriptor than “nuclear battery,” but for ease of language, I’ll use these terms interchangeably.

    Filed under
  • What if AI isn’t a bubble?

    Craig McCaskill gives multiple example of bubbles and how they ultimately burst. But what if AI isn’t a bubble? What if this is the real deal?

    The AI revolution is real, transformative, and probably unstoppable. Whether it unfolds through sustainable growth or boom-bust cycles depends largely on the choices we make in the next few years. The early signs (including voices like Altman’s warning about overexcitement) suggest we might actually be learning from history.

    The AI bubble’s human impact could be fundamentally different. Previous bubbles destroyed jobs when they burst. AI might destroy jobs while it’s still inflating. If AI actually delivers on its automation promises, we could see the first bubble that eliminates more employment during its rise than its fall.

    This creates an unprecedented social risk: a technology bubble that succeeds in its goals might cause more disruption than one that fails. The Railway Mania gave Britain train networks and industrial jobs. The dot-com bubble gave us e-commerce and digital careers. The AI bubble might give us unprecedented productivity and fewer jobs. That’s a social equation we haven’t solved.

    Filed under
  • AGI. Are we there yet? Part 2

    Dwarkesh Patel arguing why he doesn’t think AGI is right around the corner.

    But the fundamental problem is that LLMs don’t get better over time the way a human would. The lack of continual learning is a huge huge problem. The LLM baseline at many tasks might be higher than an average human’s. But there’s no way to give a model high level feedback. You’re stuck with the abilities you get out of the box. You can keep messing around with the system prompt. In practice this just doesn’t produce anything even close to the kind of learning and improvement that human employees experience.

    The reason humans are so useful is not mainly their raw intelligence. It’s their ability to build up context, interrogate their own failures, and pick up small improvements and efficiencies as they practice a task.

    How do you teach a kid to play a saxophone? You have her try to blow into one, listen to how it sounds, and adjust. Now imagine teaching saxophone this way instead: A student takes one attempt. The moment they make a mistake, you send them away and write detailed instructions about what went wrong. The next student reads your notes and tries to play Charlie Parker cold. When they fail, you refine the instructions for the next student.

    This just wouldn’t work. No matter how well honed your prompt is, no kid is just going to learn how to play saxophone from just reading your instructions. But this is the only modality we as users have to ‘teach’ LLMs anything.

    Filed under
  • Who’s making money in AI right now?

    Dave DeGraw ranting about his frustration with vibe coded PRs and asking the most important question.

    Is anyone making money on AI right now? I see a pipeline that looks like this:

    • “AI” is applied to some specific, existing area, and a company spins up around it because it’s so much more “efficient”
    • AI company gets funding from venture capitalists
    • AI company give funding to AI service providers such as OpenAI in the form of paying for usage credits
    • AI company evaporates

    This isn’t necessarily all that different than the existing VC pipeline, but the difference is that not even OpenAI is making money right now.

    Ha!

    Filed under
  • Acknowledge and repair

    Matheus Lima highlighting a lesser known—but important—skill for managers.

    Let me tell you something that will happen after you become a manager: you’re going to mess up. A lot. You’ll give feedback that lands wrong and crushes someone’s confidence. You’ll make a decision that seems logical but turns out to be completely misguided. You’ll forget that important thing you promised to do for someone on your team. You’ll lose your temper in a meeting when you should have stayed calm.

    The real question isn’t whether you’ll make mistakes; it’s what you do after.

    You acknowledge and repair. I can personally vouch for this.

    Filed under
  • Software engineering vs traditional engineering disciplines

    This comment from potatolicious on Hacker News about how AI has removed the deterministic expectations.

    …I was trained as a classical engineer (mechanical), but pretty much just write code these days. But I did have a past life as a not-SWE.

    Most classical engineering fields deal with probabilistic system components all of the time. In fact I’d go as far as to say that inability to deal with probabilistic components is disqualifying from many engineering endeavors.

    Process engineers for example have to account for human error rates. On a given production line with humans in a loop, the operators will sometimes screw up. Designing systems to detect these errors (which are highly probabilistic!), mitigate them, and reduce the occurrence rates of such errors is a huge part of the job.

    Likewise even for regular mechanical engineers, there are probabilistic variances in manufacturing tolerances. Your specs are always given with confidence intervals (this metal sheet is 1mm thick +- 0.05mm) because of this. All of the designs you work on specifically account for this (hence safety margins!). The ways in which these probabilities combine and interact is a serious field of study.

    Software engineering is unlike traditional engineering disciplines in that for most of its lifetime it’s had the luxury of purely deterministic expectations. This is not true in nearly every other type of engineering.

    If anything the advent of ML has introduced this element to software, and the ability to actually work with probabilistic outcomes is what separates those who are serious about this stuff vs. demoware hot air blowers.

    Filed under
  • Reverse and forward engineering with AI

    Birgitta Böckeler explaining how AI has changed reverse and forward engineering.

    I say AI-accelerated reverse engineering and then AI-accelerated forward engineering, where the reverse engineering only includes a description of the application, not actually building it, so the forensics kind of. You do forensics on the existing application and the existing code to recreate a good description of what it does. Because we can now use generative AI in the forward engineering, there’s a new incentive for us to actually create this description in textual form in a lot of detail.

    In the past, maybe we wouldn’t even do it at that level of detail. We would still, in the forward engineering, maybe have stories as the placeholder for a conversation because we want to build a new, fresh application. Now that we can use AI for the forward engineering, there is an incentive there to have very detailed descriptions. It maybe even changes the equation of cost benefit when we think about feature parity. That’s also one of the hypotheses. That with AI-accelerated reverse and forward engineering, feature parity might become less of a sticking point.

    Filed under
  • Replacing junior programmars

    Matt Garman—Amazon’s CEO—talking about why firing all your junior programmers for AI is a bad idea.

    With Kiro and part of what we’ve done in Agentic coding first kind of mentality is that you actually start with a spec of the thing that you want to build and then you work with the tool to actually go and build parts of that spec and as you’re vibe coding you it it can automatically change parts of that spec but you still have that spec as the core thing you can always go back to and change aspects of it or functions of it or whatever it is. Um, and we have seen the light bulb go on because it actually one of the cool things about that is that you can actually guide more junior developers as to like what are great coding practices, how do we think about this? 

    […]

    I was at a group a leadership group and people were telling me they’re like we think that with AI we can replace all of our junior people in our company. I was like that’s the like one the dumbest thing I’ve ever heard. like they’re probably the least expensive employees you have. They’re the most leaned into your AI tools and like how’s that going to work when you go like 10 years in the future and you have no one that has built up or learned anything. Um and so it’s you know I I my view is like you absolutely want to keep hiring kids out of college and teaching them the right ways to go build software and decompose problems and think about it um just as much as you ever have.

    Filed under
  • AGI. Are we there yet?

    A very pessimistic take by Marcus Hutchins on the current state of AI. The author touches upon a variety of topics which I have read independent of each other.

    A logical problem I previously used to tests early LLMs was one called “The Wolf, The Goat, And The Cabbage”. The problem is simple. You’re walking with a wolf, a goat, and a cabbage. You come to a river which you need to cross. There is a small boat which only has enough space for you and one other item. If left unattended, the wolf will eat the goat, and the goat will eat the cabbage. How do you get all 3 safely across?

    The correct answer is you take the goat across, leaving behind the wolf and the cabbage. You then return and fetch the cabbage, leaving the goat alone on the other side. Because the goat and cabbage cannot be left alone together, you take the goat back, leaving just the cabbage. Now, you can take the wolf across, leaving the wolf and the cabbage alone on the other side, finally returning to fetch the goat.

    Any LLM could effortlessly answer this problem, because it has thousands of instances of the problem and the correct solution in its training data. But it was found that by simply swapping out one item but keeping the same constraints, the LLM would no longer be able to answer. Replacing the wolf with a lion, would result in the LLM going off the rails and just spewing a bunch of nonsense.

    This made it clear the LLM was not actually thinking or reasoning through the problem, simply just regurgitating answers and explanations from its training data. Any human, knowing the answer to the original problem, could easily handle the wolf being swapped for a lion, or the cabbage for a lettuce. But LLMs, lacking reasoning, treated this as an entirely new problem.

    Over time this issue was fixed. It could be that the LLM developers wrote algorithms to identify variants of the problem. It’s also possible that people posting different variants of the problem allowed the LLM to detect the core pattern, which all variants follow, allowing it to substitute words where needed.

    This is when someone found you could just break the problem, and the LLM’s pattern matching along with it. Either by making it so none of the objects could be left unattended, or all of them could. In some variants there was no reason to cross the river, the boat doesn’t fit anyone, was actually a car, or has enough space to carry all the items at once. Humans, having actual logic and reasoning abilities could easily identify the broken versions of the problems and answer accordingly, but the LLMs would just output incoherent gibberish.

    But of course, as more and more ways to disprove LLM reasoning were found, the developers just found ways to fix them. I strongly suspect these issues are not being fixed by any introduction of actual logic or reasoning, but by sub-models built to address specific problems. If this is the case, I’d argue we’re moving away from AGI and back towards building problem specific ML models, which is how “AI” has worked for decades.

    Bonus: Check the wikipedia page of Marcus Hutchins.

    Filed under