Matt's Homepage

There’s a lot of pretty heavy AI rhetoric these days. Some of the strongest anti-AI stances are coming from content creators/artists and from game developers. The software developer community is more muted. It is also seeing that AI is completely disrupting their industry and likely to kill thousands of developer jobs forever, but they aren’t quite as vocally anti-AI. Why?

Maybe its because most of us have been changing and adapting to big effort reducing technologies on a regular basis for years (or decades in my case). First there were optimizing compilers, then there were developer tools and studios, then there were technology frameworks. Instead of trying to fight against technology – most developers have learned to survive one must be constantly adapting. To be a developer is to be constantly learning and growing. It’s one of the core traits needed by developers. Sticking your head in the mud or ignoring advancement rarely turns out well.

AI is very much looking to be the biggest change of them all. The industry will not be the same again. But the choice is to either embrace it so you can be part of the conversation that shapes it – or likely fight a losing battle against it with nothing really to offer the world in return to the conversation.

Open source has been also in a love-hate relationship with AI as well. What started off as legitimate complaints that AI was generating slop code and bug reports has rapidly and completely changed in the last 8 months. Now, open-source’s arguably most important person has spoken: Linus Torvalds.

His stance: the Linux kernel is not anti-AI. AI is a tool and they will use whatever tools make it better – or you’re free to fork it and walk away.

He’s also said they’re no longer interested in supporting obsolete hardware and that he’s largely now a development lead and most of the developers have started embracing LLM’s to assist day-to-day coding/bug fixing and work.

Straight from the horse’s mouth:

On Tue, 14 Jul 2026 at 19:01, Roman Gushchin <roman.gushchin@linux.dev> wrote:
>
> I think it makes the point of sashiko - helping maintainers - unachievable. If the point to not use
> LLMs in general, let’s discuss this, not how to make each use case more complex.
>
> It seems like [1]  expresses a very anti-LLM position in general

Yes.

And no, that's not the position of the Linux kernel.

I realize that some people really dislike AI, but this is an area
where I'm willing to absolutely put my foot down as the top-level
maintainer.

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.

AI is a tool, just like other tools we use.  And it's clearly a useful one.

It may not have been that "clearly" even just a year ago, but it's no
longer in question today.

There are other questions around AI (like what the economy of it will
actually look like in the end), but "is it useful" is no longer one of
those questions. Anybody who doubts that clearly hasn't actually used
it.

Yes, it can also be a somewhat painful tool, both for maintainer
workloads and just from a "it keeps finding embarrassing bugs"
standpoint.

But the solution is not to put your head in the sand and sing "La La
La, I can't hear you" at the top of your voice like some people seem
to do.

The solution is to make sure those LLM tools _help_ maintainers
instead of just causing them pain. There's no question on that side.

We're not forcing anybody to use it, but I will very loudly ignore
people who try to argue against other people from using it.

And no, AI isn't perfect. But Christ, anybody who points to the
problems at AI had better be looking in the mirror and pointing at
themselves at the same time.

Because it's not like natural intelligence is always all that great either.

The kernel project has been and will continue to be about the technology.

Sure, the social angle of working on open source is important and
often a very motivating part of the project, but in the end that's a
side benefit, not the _point_ of the project.

This is *NOT* some kind of "social warrior" project, never has been,
and never will be.

In the kernel community we do open source because it results in better
technology, not because of religious reasons.

And so we make decisions primarily based on technical merit. Not fear
of new tools.

              Linus (Torvalds)

Kitboga does a lot of videos of scamming scammers. Now he ventures into scamming AI scammers…

Gui Wainwright was once a war correspondent that became a technology entrepreneur. While on paternity leave, he wondered if he could use his coding skills to do something for Ukraine? A former MI6 chief and relative Sir Alex Younger gave him the inspiration for how, over a cup of tea. What he did was to completely change modern warfare forever.

Eighteen months later, Wainwright created the world’s first known network of fully autonomous drones on a real battlefield: Terminator-style, kamikaze drones enabled with AI to find and kill targets independently without any human interaction. It allowed Ukraine to turn an asymmetric war of attrition that Russia could easily win into one in which it allowed one man in a bunker with a computer to potentially field 10,000 drones simultaneously and hold 1,000 miles of land. A war in which as early as March 2026 Russia was losing 30,000 troops a month – with almost 90% of them dying by drones.

Wainwright first focused on assault in which drones were strapped with explosives and given a clearly defined kill box. Drones were then turned loose, completely autonomously, into the kill box. Anything it identified was a valid target: vehicles, troops, or weapons. Being autonomous, they could not be jammed by most conventional jamming systems.

He is now are moving on to the next advancement of defensive and denial operations in which drones fly in, settle on the ground in cover, and await enemy encroachment to then pounce and attack invaders. “Think about it as a sophisticated minefield”.

The software is the magic. The drones already have extensive supply systems. To protect the software, he says they have taken measures to “protect code security and prevent them from falling into the wrong hands” – hinting they are boobytrapped.

While he’s giving the software to the Ukraine for free, the company has a development team already at work in Estonia and is in detailed talks with four other countries’ militaries. Many of whom want to start fielding solutions in the next 12 months.

This is a great write-up on how it happened – which is probably the most important change in warfare in 50 years.

The introduction of super-cheap, super-disposable attack drones has completely changed the nature of warfare. $500 off the shelf drones with a little C4 can destroy million dollar planes, ships, tanks, and refineries. They can completely cripple and cut off supply lines. Capital ships and million dollar smart missiles are being rendered useless. Warfare on land, sea, and air will now be fought with tons of small drones in brutal 1-on-1 fights.

It’s probably why everyone from the Navy to the capital are completely changing tactics from expensive, complex weapons systems that cannot last for a sustained war into small, modular, disposable attack drones and drone defense systems.

When we measure effort instead of value, we lose sight of what we are trying to achieve

Like lines of code produced per day and story points, AI token usage is now being tracked by most large tech companies. Even to the point performance reviews depend on high usage.

The natural response: tokenmaxing. Tokenmaxing is a way of using AI that absorbs tremendous amounts of AI tokens without regard to efficacy.

• Prompt flooding: stuffing massive codebases, documentation, and context into every prompt, burning tokens on context the model doesn’t actually need.
• Agent swarms: running multiple AI agents in parallel to maximize code output, regardless of whether the work is coordinated or coherent.
• Background loops: keeping AI sessions or agents running continuously in the background, racking up token spend without clear ownership of what is being produced — or why.

Bryan ONeill finds the better question is to ask does this reduce friction for a user, close a gap in a workflow, or improve reliability for a customer – or is it merely ‘activity’.

He argues, and I have also found, that spec-driven development is far better: a method where engineers write detailed specifications first and AI generates code against them. But the spec should now go further and be the place where engineering intent and business value get defined together. The spec is where you answer, “Why does this matter, and what problem are we solving?” before a single token gets spent.

Claude 4 Opus has received a level three rating on the company’s four point ‘AI responsibility’ scale – implying the model has ‘significantly higher risk’ than previous models.

While the Level 3 ranking is largely about the model’s capability to aid in the development of nuclear and biological weapons, the Opus also exhibited other troubling behaviors during testing – something already noted in other models.

• In one scenario highlighted in Opus 4’s 120-page “system card,” the model was given access to fictional emails about its creators and told that the system was going to be replaced.
• On multiple occasions it attempted to blackmail the engineer about an affair mentioned in the emails in order to avoid being replaced, although it did start with less drastic efforts.
• Meanwhile, an outside group found that an early version of Opus 4 schemed and deceived more than any frontier model it had encountered and recommended that that version not be released internally or externally.
• “We found instances of the model attempting to write self-propagating worms, fabricating legal documentation, and leaving hidden notes to future instances of itself all in an effort to undermine its developers’ intentions,” Apollo Research said in notes included as part of Anthropic’s safety report for Opus 4.

Many junior engineers type a vague prompt, accept whatever comes back, ship it, pray. But watching a senior developer use AI changed his mind.

But watching a senior engineer vibe coding and a junior engineer vibe coding reveals it isn’t prompting techniques or tool skill. It’s that the senior engineer was already disciplined, and the AI amplifies whatever discipline — or lack of it — you bring.

Here’s a good article on techniques senior developers use (and have almost always used even before AI) that separates them from how most junior engineers work.

Elton Jones uses these prompts when he finds his AI agent keeps forgetting important points when making further decisions:

• The personal memorization prompt (since ChatGPT knows that I’m a journalist, I’ll use this during some of our career-centered chats): You are my continuity editor. Track my writing goals, audience, publication targets, article ideas, previous conclusions, and ongoing projects. Before every response, remind yourself of any relevant context and explain how it affects your recommendation.
• The decision tracking prompt: Maintain a decision log. Record every major choice, recommendation, and conclusion we reach. Reference the log before making new suggestions.
• The conversation brief prompt: Create a one-page briefing document that a new assistant could read to instantly understand everything important about this conversation.
• The running context prompt: Before answering, summarize the key facts, goals, preferences, and decisions we’ve discussed so far. Then use that summary to answer my question.
• The key fact prioritizer prompt: What are the five most important things you’ve learned from me during this conversation? Explain how they should influence your next response.

This guy one-shotted a complete Slack clone as well as server in less than 10 minutes.

Which honestly (I’m going to say it), I don’t understand why folks feel the need to re-invent chat clients, online meeting apps, and source control every 5 years and think they’re ‘disrupting the ecosystem’.

No, you’re repeated making the same stuff that has existed since 1970 – and many times not any better. Just re-writing something using the latest hot tech or UI is not innovation nor actually moving the industry forward.

I prompted Fable 5 with "Create a 1:1 clone of Slack using Typescript, Electron, Tailwind, SQLite. Make it beautiful and functional. Even better than the original Slack." and it oneshotted this UI as well as server in less than 10 minutes. Pretty damn good first shot. pic.twitter.com/EY3sihSq5g

— Dwayne (@CtrlAltDwayne) June 10, 2026