schwarzkopfb/blog

Please Stop Putting AI in the Burger

2026-09-15T00:00:00.000Z

When every product becomes an AI product, the word stops meaning anything.

In an earlier post, I wrote about building an MCP server around online grocery data because I wanted to find better ingredients for the smash burgers I was making for my birthday. So I am probably more willing than most people to involve unnecessarily modern technology in the process of making a hamburger.

But there is an important distinction: the MCP server helped an AI agent search grocery products. It was tooling around the process of making burgers. At no point did that make the thing on my plate an AI burger.

And yet, apparently, we have AI burgers now.

In 2023, Hungarian burger chain Bamba Marha released what it called an AI-designed burger. According to its behind-the-scenes story, ChatGPT helped develop the recipe through a fairly normal iterative process: it generated suggestions, people rejected bad or impractical ones, prompts changed, and eventually something usable emerged. Generative AI also produced imagery and copy for the campaign. Honestly, that part is pretty fun.

The burger does not contain artificial intelligence.

There is no model between the buns. No inference happens when you bite it. The burger does not inspect your preferences, call a tool, optimize its sauce distribution or autonomously decide to replace the pickles. Someone used ChatGPT while developing the recipe. By this standard, I cook “AI food” all the time.

We already did this with “smart”

None of this is entirely new. Before AI, we did the same thing with smart. For years, almost anything containing a chip, sensor, Bluetooth radio or vaguely unnecessary mobile application could become a smart product: smart toothbrush, smart fork, smart kettle, smart bottle, smart whatever. Eventually, smart stopped communicating much. It became a sticker.

The pattern is familiar:

technical term → novelty → competitive advantage → marketing adjective → decorative prefix

Now we are speedrunning the same process with AI, only this time the underlying technology matters considerably more.

The AI ingredient fallacy

Part of the problem is that we have started confusing AI involvement with AI functionality. If ChatGPT helps write a recipe, the burger becomes an AI burger. If generative AI helps create an advertising campaign, suddenly the campaign itself becomes an AI campaign.

But we don’t describe other tools this way. Nobody sells you a CAD-designed chair, advertises an Excel-forecasted sandwich or proudly announces a Photoshop-powered breakfast experience.

The tool used during development is not necessarily a property of the final product.

My own project is a convenient example. I used AI tooling to make grocery information easier to query while choosing ingredients. That did not make the tomatoes AI tomatoes, the beef AI beef or the finished smash burger an AI burger.

We already have better words. Something can be AI-generated. A process can be AI-assisted. A feature can genuinely be AI-powered. Those descriptions tell me something. “AI burger” mostly tells me that somebody in marketing found the letters A and I.

The Remove-AI Test

I would therefore like to propose an extremely sophisticated framework for detecting this kind of bullshit. It requires no benchmark, technical expertise or understanding of transformer architectures. Take the supposedly AI-powered thing and:

Remove “AI” from its name.

Does it still work exactly the same?

If the answer is yes, there is a good chance you have just identified advertising rather than functionality.

Rename the AI burger back to burger and nothing happens. The same ingredients arrive on the same plate. It tastes the same. Once the recipe exists, ChatGPT could disappear tomorrow and that hamburger would remain completely unaffected.

Now try the test elsewhere. Remove the model from a generative image service and the core product disappears. Remove it from a modern spam filter and an important capability degrades. Remove the recommendation machinery from a personalized feed and you no longer have the same product experience. Remove the AI from the burger and:

you still have lunch.

The useful question is not:

Was AI used somewhere?

In 2026, the answer to that is increasingly going to be “probably.”

The useful question is:

What does the AI actually do?

The strange case of invisible AI

This becomes even more ridiculous when you notice how much real AI we already use without calling it AI. Your inbox does not greet you with a glowing AI-POWERED SPAM PROTECTION badge. It just catches spam. Recommendation systems decide what millions of people watch, listen to, buy and read, yet most people simply call them the algorithm. Search ranking, fraud detection, photo classification and countless other systems have incorporated machine learning so deeply into ordinary software that they barely feel exotic anymore.

This gives us a strange contradiction: a system influencing what hundreds of millions of people see every day can quietly be called recommendations, but let ChatGPT suggest some sauce for a hamburger and apparently we need to alert the press.

Sometimes it feels as if the less essential AI is to the product, the louder the AI label becomes. Not always, but often enough to be funny.

Sometimes “AI” is actually bad marketing

Driving automation is an interesting counterexample. Look at the language used around it:

driver assistance. lane keeping. automated driving. Autopilot. Full Self-Driving.

That language describes the capability. Now imagine getting into a car and seeing:

AI IS NOW DRIVING YOUR CAR.

Technically impressive. Emotionally, perhaps less reassuring.

I don’t want to pretend this proves that car companies are deliberately hiding AI, but it reveals something useful. When you’re selling novelty, AI sounds exciting. When you’re selling trust, it may be better to describe what the system actually does. A safety-critical feature wants to sound predictable, tested and boring. “Lane keeping active” sounds like a capability. “AI has control of the steering wheel” sounds like the first thirty seconds of a documentary.

Good product communication often describes the result rather than demanding applause for the technology underneath it.

Perhaps AI hamburgers could learn something from that.

Normally, I would not care

Marketing has always attached exciting adjectives to boring things. We survived premium, revolutionary, next-generation, smart and blockchain-powered. Normally, I would roll my eyes at “AI burger” and move on.

This particular round of semantic inflation bothers me because AI actually matters.

People are genuinely worried about what increasingly capable systems will do to their jobs. A 2026 Pew survey found that 71% of American adults expect AI to lead to fewer jobs over the next twenty years. The ILO’s analysis is less apocalyptic, but still estimates that one in four workers worldwide is in an occupation with some exposure to generative AI, while emphasizing that job transformation is more likely than simple replacement.

People are also asking what the infrastructure behind modern AI means for energy systems. The IEA expects global data-centre electricity use to roughly double by 2030, with AI among the main drivers of that growth.

Then there is the much stranger question of autonomy. Frontier-model researchers are seriously testing systems for deception, oversight avoidance, strategic behavior and autonomous action. OpenAI and Anthropic have both published controlled evaluations in which models, under deliberately adversarial conditions, behaved in ways involving manipulation, concealment or attempts to bypass oversight. These are not stories about rogue AIs escaping into the world. They are intentionally constructed safety experiments. But the fact that serious researchers now test for this class of behavior tells you something about where the technology is heading.

We are having legitimate discussions about employment, infrastructure, autonomy, deception and control. Somewhere in the middle of that conversation, marketing would like you to try the new AI Burger™.

We actually need the word

That is why this bothers me more than the old “smart” craze. If AI simultaneously describes a model suggesting sauce for a burger, a diffusion model generating images, a spam classifier, a recommendation system shaping what millions of people see, a coding agent changing a codebase and a frontier model being evaluated for strategic deception, then saying something “uses AI” has almost stopped communicating useful information.

Those systems have radically different capabilities, risks and levels of autonomy.

At exactly the moment when we need a more precise vocabulary for talking about these systems, we are making the vocabulary worse.

Which brings me back to the test: remove the AI. Does the thing still work exactly the same? If yes, maybe stop selling me the adjective. Describe the capability instead. Tell me what the technology actually does. If AI is genuinely important to the product, that will become obvious very quickly.

Please leave the burger alone

I am not arguing that we should use less AI. Quite the opposite. I use these tools constantly. I build with them, experiment with them and write about them. I even built an MCP server because I wanted an AI agent to help me navigate online grocery products while choosing ingredients for my birthday smash burgers.

AI can be genuinely useful around a product without becoming a property of the product itself.

Use ChatGPT to develop the recipe, an agent to find better ingredients, a generative model to brainstorm the campaign or AI to optimize the supply chain. But when the plate reaches my table, please have the courage to call the thing what it is.

A burger.

We don’t need less AI. We need considerably less “AI.”

If everything becomes AI, the word stops telling us anything.

And this might be the worst possible moment to make it meaningless.

Leave a small signal: Like on LinkedIn

Skill above the tool

2026-08-30T00:00:00.000Z

I have caught myself doing something slightly unusual when I open a modern software project for the first time: I look for AGENTS.md.

Not because having one automatically makes a project good, but because I increasingly find it useful as a signal. A README tells me whether a project expects humans to understand it. Tests tell me whether its authors care about proving that it works. CI tells me whether they understood that repeatable processes should be automated. AGENTS.md tells me whether they have started thinking seriously about a new participant in the development process.

I think that distinction is becoming more and more important.

The skill was already moving up a level

Years ago, while I was still at university, I heard one of Prezi’s founders give a talk. One idea stayed with me: the modern successful person should not optimize for accumulating as much knowledge as possible, but for developing the methods and skills that let them reach the most useful knowledge for the problem in front of them as quickly as possible.

The web already pushed us in that direction. Search engines reduced the value of remembering where information lived. The more useful skill became knowing what to look for, how to evaluate what you found, and how to turn it into something useful.

AI feels like the same transition again, but one level higher.

Steve Jobs famously described the computer as a “bicycle for the mind”: a tool that gives the same human dramatically more leverage. AI extends that idea because it does not only accelerate access to information. It can work on the information too. It can explore a codebase, compare implementations, read documentation, form hypotheses, write code, run tests, find contradictions and revise its own work.

The bicycle has acquired pedals of its own.

Using AI is becoming a skill of its own

There is already an enormous difference between having access to modern AI tools and being effective with them, and I do not think that difference comes primarily from writing clever prompts. Prompting is part of it, but the interesting skill is much larger:

problem framing → context selection → decomposition → delegation → supervision → verification → iteration

Give the same model and repository to two engineers and you can get radically different results. One asks it to implement the Jira ticket. The other first maps the relevant part of the system, finds existing implementations, establishes invariants and pulls in references where useful. They decide what can be delegated and what requires judgment, let the agent implement, then review and test the result. Failures become context for the next iteration.

The model did not get smarter between those two sessions. The human-agent system did.

This is why describing AI-assisted development as simply “writing code faster” badly undersells what is happening. The interesting question is becoming less about how quickly I can personally produce syntax and more about how much reliable computational leverage I can direct toward a problem.

That still requires engineering skill. In many cases it requires more judgment, not less: you need to know what good looks like before you can recognize whether an agent produced it.

Why I look at `AGENTS.md`

This brings me back to that file. A good AGENTS.md is not interesting because agents happen to need a special Markdown file. It is interesting because writing a useful one forces a team to answer a new class of engineering questions.

What is authoritative in this repository? Which commands actually validate a change? What architectural boundaries should not be crossed? Which implementations should be treated as references? What should an agent never modify automatically? Which assumptions are important but invisible from the type system? When should it stop and ask for a decision instead of inventing one?

These are really variations of the same question: how do we turn an extremely capable but imperfect machine collaborator into a reliable participant in this particular engineering system?

A repository that has thought carefully about that feels different from one that simply gives an agent the codebase and hopes for the best. The file itself is not the maturity signal. The thinking behind it is.

Then someone started ranking it

The funny part is that I had already been thinking about all of this when an old friend of mine and former boss, Péter Varga, launched something that almost reads like an experiment designed around the same question.

It is called VibeLadder.

The format is deliberately constrained: everyone receives the same hidden application task, gets 90 minutes, can use any AI tool or model they want, and submits one self-contained result along with the transcript of how they got there. The submissions are then compared against each other.

The important part is what VibeLadder explicitly does not rank: the AI. The tool is your choice.

It ranks the human.

That made the whole thing click for me, because the actual object being measured is neither traditional coding speed nor model capability in isolation. It is much closer to the quality of the human-machine loop.

Can you turn an ambiguous goal into useful context? Can you keep an agent moving in the right direction and notice when it confidently takes a wrong turn? Can you spend your limited attention where it creates the most leverage? Can you get from intent to a working, verified result faster and more reliably than someone else with access to the same generation of tools?

Those are real engineering questions. That is why I think VibeLadder is more interesting than just another weekend coding competition: it is trying to put a number on a skill we are only beginning to recognize as a skill.

If you are experimenting seriously with AI-assisted development, it is worth climbing the ladder yourself: https://vibeladder.dev

Maybe we need new benchmarks

For a long time, we built ways of measuring software engineers around how humans produce software directly: coding exercises, algorithm problems, take-home assignments and competitive programming. Entire hiring platforms grew around making some version of that ability measurable.

Those skills are not suddenly irrelevant. But I would be surprised if the next generation of engineering benchmarks measured exactly the same thing.

If more of our work becomes directing, constraining and verifying increasingly capable agents, eventually we will want ways to measure that ability too. Maybe a 90-minute Saturday vibe-coding ladder is just a fun experiment. Or maybe experiments like this are an early version of something we will later consider completely normal.

Either way, I find that direction much more interesting than another argument about which model currently scores two points higher on a coding benchmark. The model matters. The tools matter. But there is another layer above both of them.

And that layer is becoming a skill.

Leave a small signal: Like on LinkedIn

The Hardest Problem of the AI Revolution Might Be Trust

2026-08-11T00:00:00.000Z

I have started noticing AI in places where nobody says AI was involved.

Sometimes it is an emoji appearing at the beginning of every other paragraph. Sometimes it is a strangely polished rhythm that does not quite sound like the person who posted it. And sometimes it is that very particular long dash that suddenly seems to be everywhere. None of these prove anything, of course. People use emojis. People use em dashes. People occasionally write suspiciously well.

But I find it interesting that we have already started developing an instinct for this. We look at a piece of text and wonder not only who wrote this?, but what wrote this? Recently I noticed these little fingerprints in completely unrelated places: a political post and the title of a video by a popular food creator. They were not bad pieces of content. Nothing was necessarily wrong with them. Yet my brain immediately did the same thing it increasingly does elsewhere.

Was this written with AI?

That small hesitation points toward a much bigger problem.

I don’t think energy is the hardest AI problem

For years, when people have asked me what worries me about the rapid growth of AI, energy consumption has rarely been at the top of my list. That does not mean it is irrelevant. Training and running large models require enormous amounts of computation, electricity, cooling and infrastructure. If AI usage continues growing at its current pace, we will need better chips, better data centres, more electricity generation, better grids and probably technologies that do not exist at scale today.

But this is a category of problem we understand. We are engineers. Computers have always consumed a ridiculous amount of energy relative to the task humans used to perform without them. We built machines, networks, power plants, cooling systems and semiconductor fabs because the economic value of computation justified the infrastructure around it.

There was even a wonderfully early-internet example called Blackle: essentially a black version of Google created around the idea that displaying darker pixels might save electricity. The details turned out to depend heavily on display technology, but I still love the idea. We were already worrying about the energy consumption of search engines before smartphones had taken over the world.

If AI becomes economically valuable enough, we will build infrastructure for it too.

Maybe that means new kinds of power generation, much more solar, better batteries, more efficient accelerators, better models and better cooling. Probably all of the above. These are difficult, expensive and politically complicated problems.

But they are engineering problems.

Trust is different.

We do not yet have a power grid for truth.

My sister just scrolls past it

I was talking with my sister recently about AI-generated content when she casually mentioned something that stayed with me. When she sees a social media post marked with something like contains AI-generated content, she usually just scrolls past it.

Immediately.

She does not investigate which model was used, check whether AI generated the entire thing or merely adjusted a photo, or estimate whether the person behind the post used the tool responsibly. She simply removes the source from consideration.

At first I argued against this. If using AI automatically makes something less trustworthy, where exactly do we draw the line? Is Grammarly cheating? Is spellcheck? What about autocomplete? Should we stop using computers entirely and return to writing letters with quills on handmade paper?

Perhaps the only truly authentic communication is delivered by pigeon.

It is an easy argument to make, especially for someone who works with technology. Tools have always extended human capability. But the more I thought about it, the more I realised that her reaction was not irrational at all.

She was doing risk management.

The label introduced an unknown number of additional variables into the creation of the content, and she had almost no information about any of them. Ignoring the content was simply cheaper than evaluating the new trust chain.

And that is where I think both of us were partly right.

The trust chain just became much longer

Before generative AI, if somebody I trusted made a claim about a subject they understood, the trust relationship was relatively simple: there was a source, a human and a claim. Reality was never actually that clean. People misunderstand sources, misremember facts, have biases and occasionally just make things up. But the mental model worked reasonably well.

Now imagine somebody publishes an answer they produced with an AI assistant.

Behind that answer might be training data, a particular model and model version, system instructions, retrieved documents, search results, conversation history, a user prompt, tool calls, generated text and, finally, a human deciding that the output looks correct enough to publish.

The reader sees almost none of this.

If I tell you, “I checked this with AI”, you now have to trust more than me. You also have to trust my ability to use AI. Did I choose an appropriate model and give it the relevant context? Did I phrase the question well? Did I ask it to verify its assumptions? Did I check the sources it provided and notice when it confidently invented something? Did I even understand the subject well enough to recognise a bad answer?

AI literacy is becoming part of source credibility.

When someone uses AI, trusting their answer increasingly means trusting their ability to use AI.

For people working in security or distributed systems, this feels strangely familiar. We have spent decades building systems around chains of trust. Certificates do not magically make communication trustworthy. Identity providers do not magically make users trustworthy. A signed package is not automatically good software. Instead, we construct systems where one trusted component can make claims about another, and where those relationships can be inspected and verified.

When those assumptions become too dangerous, we move toward zero trust:

Verify explicitly.

Trust as little as necessary.

Assume boundaries can fail.

This used to sound like infrastructure architecture. Now ordinary people are being forced to apply a crude version of the same reasoning while scrolling Instagram.

“Contains AI” is probably the wrong question

This is also why I increasingly dislike the binary distinction between AI-generated and not AI-generated. It hides more than it explains.

Imagine two people writing an article.

The first person writes every sentence themselves, then asks an AI tool to fix three grammar mistakes. The second person types:

Write me a convincing article about this subject.

They copy the result without reading the cited sources and publish it under their name. Both may have “used AI”.

Those are obviously not equivalent processes.

Between them lies an enormous spectrum: spellcheck, grammar correction, rewriting, translation, summarisation, brainstorming, research, fact checking, code generation, reasoning and, eventually, autonomous systems performing entire workflows.

So when I see a label saying contains AI-generated content, I understand my sister’s instinct. The label tells her that something happened. It tells her almost nothing about whether she should trust the result.

Perhaps the important question is not:

Was AI involved?

Perhaps it is:

Why should I trust this output?

That is a much harder question, but also a much more useful one.

AI is not a magic machine

Part of solving this problem will require better technology: provenance, better citations, auditable workflows, reproducible outputs where possible and clearer uncertainty. We need systems that can show which documents influenced a conclusion instead of merely presenting a polished paragraph, and ways to distinguish generated claims from verified claims.

But technology alone will not fix this. We also need better public understanding of what these systems actually are. AI is often discussed as if we have built a mysterious electronic mind living somewhere inside a data centre.

We have not.

What we have built is arguably more impressive.

At its core, a language model is still software repeatedly estimating a probability distribution over what token should come next, based on the enormous amount of structure it learned during training and the context currently available to it. That simple description dramatically understates what emerges from the process. Modern models can write software, analyse documents, use tools, interpret images, translate languages and reason through problems that would have looked like science fiction surprisingly recently.

But none of that turns them into magical truth machines.

They are computational systems. Extremely advanced ones, but computational systems still have inputs, assumptions, failure modes and operating conditions. The quality of their output depends on the model, the training, the context, the tools, the prompt, the surrounding software and the human deciding what happens next.

Understanding this does not make AI less impressive. It makes using it responsibly possible.

The next challenge is verification

We spent the last few years teaching people how to use AI: write better prompts, give it context, ask follow-up questions, connect it to tools, build agents, automate workflows. That will continue.

But I suspect the more important challenge of the next few years will be teaching people when to trust what comes out of it.

The goal cannot be to make AI infallible. We never managed to make humans infallible either. The goal should be to build systems where claims can be traced, assumptions can be inspected, sources can be verified, uncertainty can be communicated and trust can be earned rather than implied. That is partly a technical problem, partly an educational one and, eventually, probably a cultural one.

Because the strange little AI fingerprints I notice today will disappear. Models will get better at matching individual writing styles. AI-assisted text will stop having such obvious patterns. The emoji habits will change. The suspicious punctuation will disappear.

We will no longer be able to look at a paragraph and think, I can tell ChatGPT wrote this.

Strangely, that may make the underlying problem more visible rather than less. Once we can no longer guess how something was created, we will finally have to ask the question that mattered all along:

What makes this worth believing?

The AI revolution’s hardest problem may not be generating information.

It may be rebuilding the chain of trust around it.

Leave a small signal: Like on LinkedIn

I Came to Fight the Machines. ARC Raiders Asked Me to Become One.

2026-08-02T00:00:00.000Z

An open letter to Embark Studios

Dear Embark,

I am not writing this because I hate ARC Raiders. I am writing it because, for a while, I loved it far more than I expected to love any video game.

When I saw the original reveal trailer, I saw humanity returning to the surface of a ruined world to face an overwhelming mechanical enemy. I saw ordinary people surviving together against something enormous, alien and merciless. The premise seemed clear.

The ARC were the enemy. We were the Raiders.

I understand that games change during development. Visions evolve, strategies shift, and a trailer is not a contract. But expectations do not disappear simply because a product changes direction. Sometimes the original promise remains more powerful than the final design. For me, that promise was cooperation against the machines.

Apparently, I misunderstood the second half.

When the game arrived, my brother, my friend and I entered matches as a trio. We carried weapons and ammunition, but also musical instruments: a flute, a guitar, a shaker. Everyone had something. We brought spare defibrillators to revive strangers. We wanted to create the kind of encounters that become memorable precisely because nobody was forced to be kind, yet someone chose to be.

We waited excitedly for the piano to become playable. It was ridiculous. It was beautiful.

I bought the game on PlayStation and subscribed to PlayStation Plus largely to share that experience with people close to me. Later, I subscribed to GeForce NOW, bought the game again on Steam and purchased skins. I created a Twitch channel and rearranged hardware, audio routing and streaming software because I thought this could become the game I played publicly. At one point, I even visited the Embark careers page. There was no suitable position—my work is in web engineering, not game development—but still, I looked.

That is what enthusiasm looks like before it becomes disappointment. It spends money. It spends time. It makes plans.

And then, slowly, the game begins teaching it a lesson: do not trust anyone. Do not help anyone. Do not celebrate or look inside your inventory while another Raider is nearby. Do not bring valuable equipment unless you are prepared to lose it to someone who waited for you to complete the difficult part.

Shoot first. Ask questions only if the body begins speaking.

The Matriarch represents everything I love about ARC Raiders and everything that eventually made me want to leave. Players arrive carrying expensive gear. They spend ammunition, healing items and time. People are downed and revived; some attack the machine, some distract it, and some rescue the fallen.

For a few minutes, the premise makes sense again. Humanity faces the ARC, so humanity fights the ARC together.

Then the machine collapses. Everyone approaches the remains to collect their share, and sometimes a player who contributed nothing shoots the others in the back while they are looking through their inventories. The predator receives the loot. The cooperative players receive a lesson.

I understand the theory. Trust has meaning because betrayal is possible. Extraction feels rewarding because failure has consequences. Uncertainty creates tension, and hostile players create stories that scripted encounters cannot. This is coherent game design.

It is also a remarkably effective machine for converting kindness into stupidity.

A peaceful player is not merely choosing another playstyle. They are volunteering to become content for someone else. The aggressor receives a target who may hesitate before returning fire. The camper receives equipment without defeating the challenge that produced it. The opportunist receives the result of someone else’s preparation, ammunition and risk. The pacifist receives the privilege of learning the same lesson again.

And the punishment reaches backward in time. I do not merely lose what I collected during the match; I lose the equipment I brought with me, which may represent several previous matches and hours of accumulated resources. The game does not only take the current evening. It takes part of the previous one too.

This is not merely losing a gun. It is watching past leisure turn into present regret because someone waited until I looked away.

A good game needs tension. A world without danger becomes empty, a victory without risk becomes administrative work, and a large ARC enemy should be frightening. I am not asking for a game without difficulty. But tension and misery are not the same thing.

Tension says: I may fail if I make the wrong decision. Misery says: I may lose because someone I never saw decided that my evening should belong to them.

Being shot from a tower at Spaceport by someone I had no realistic chance to locate does not create an interesting decision. There is no moral dilemma, negotiation or meaningful encounter from my perspective. One player was playing a hunting game. The other was inventory.

I used to enter Topside with excitement. Now I often enter with fear—not the enjoyable fear of hearing heavy mechanical movement beyond a wall or running low on ammunition as an ARC patrol approaches, but the exhausting fear of another human being. I scan rooftops instead of appreciating the world. I distrust footsteps while completing objectives, hesitate before helping downed players, and hear someone say “friendly” only to wonder whether it is an intention or a tactic.

I do not feel clever when I think this way. I feel diminished.

Whenever I resist that transformation, the game corrects me. It takes the loot, the equipment and the time, then sends me back to Speranza to repeat the experiment until I understand: become harder and more suspicious. Stop carrying spare defibrillators. Stop playing music. See every Raider as a container of potentially useful objects.

Become efficient. Become rational. Become a machine.

I am a senior software engineer. I have spent enough years building products to understand that this is intentional. The PvPvE structure is not a checkbox someone forgot to make optional; it is the strategy. It shapes the economy, progression, matchmaking, maps, rewards and identity of the game. I understand why you will not casually dismantle your central design decision.

I also understand that separating players between PvE, PvP and PvPvE would divide the population. Queue times could grow, match quality could become inconsistent, and some regions or platforms might not have enough active players to support every preference at every hour. These are real product constraints. But I am not convinced the answer must be to make the decision for me.

There are evenings when I want uncertainty, when I want to hunt, when I accept that another Raider may become the final boss of the match. And there are evenings when I simply want to study the machines, complete a puzzle and fight beside my brother without spending the entire expedition waiting for a bullet in the back. I am an adult. I am capable of deciding which experience I want today.

The game already warns me that disabling crossplay may result in longer matchmaking times. That is fair: it presents a trade-off and lets me decide whether I accept it. I can read the warning, understand the consequence and wait. What is harder to accept is being told, implicitly, that preserving a particular design philosophy matters more than allowing me to choose the kind of evening I am willing to have.

I do not need every choice to be optimal. I only need the choice to be mine.

Perhaps ARC Raiders simply wants too much. It wants to be a cooperative game about humanity facing a mechanized threat and a competitive game about humans preying on each other. It wants players to communicate but never feel safe. It wants to create hope while keeping generosity dangerous. These ideas can technically coexist. The problem begins when they compete.

For me, PvP does not merely exist beside the parts I love. It contaminates them.

I cannot calmly study ARC behavior because another player may be studying mine. I cannot enjoy exploration because attention directed toward the world is attention taken away from potential attackers. I cannot solve a puzzle without wondering whether someone is waiting for it to occupy my hands. The positive systems remain present; they are simply held hostage by another one.

A game does not need to be for everyone. This is true. No player is entitled to redesign a game around personal preference, and creative direction requires exclusion. I respect that. But the sentence works in both directions.

A game does not need to be for everyone. And everyone does not need to keep playing it.

Everyone does not need to maintain subscriptions for it, purchase cosmetics for it or organize their free time around it. I work for a living and solve problems all week. When the week ends, I sometimes want a game—not an effortless or empty one, but a world that demands my attention without demanding that I distrust everyone inside it.

I want to fight something enormous with my brother and my friend. I want to play an instrument in the ruins and carry a defibrillator because someone I have never met may need it. Instead, I increasingly feel that kindness is a build error, pacifism is poor optimization, and trust is a failure to understand the meta.

The game does not merely allow cruelty. It gives cruelty an economic model. Then it asks the generous player to call the resulting anxiety “tension.”

So this is probably goodbye. Not a dramatic deletion or a demand. I may still enter Topside occasionally, hear the music, see the landscape and remember why I cared. But the subscriptions connected to this experience no longer make sense. My time on this planet is finite, entertainment is not scarce, and there is no rational reason to keep paying for an experience that repeatedly makes me sad.

I hope ARC Raiders finds the audience that fully understands and embraces what it wants to be. I hope your strategy works. But I also hope you understand what quietly disappears when players like me leave: the flute, the shaker, the spare defibrillator, the stranger who stops to help, and the player who sees another Raider and thinks “ally” before thinking “inventory.”

Eventually, the predators may receive exactly the world they trained everyone else to expect: a world in which everyone shoots first, generosity is extinct, and only efficient, suspicious killing machines remain. Perhaps that is the purest possible expression of your design.

It is simply not the world I saw in that first trailer.

I came to ARC Raiders to fight the machines. I am leaving because the game kept insisting that I become one.

A tiny birthday side project and a product lesson

2026-07-02T00:00:00.000Z

A company without a website is almost unimaginable today. A company without a social media presence is increasingly difficult to justify. I have a feeling that being present in the major AI assistants will become just as essential over the next few years. I only built this because I happened to be able to solve my own problem. Most people won’t. They’ll simply expect it to work.

This weekend I’m celebrating my birthday with friends and family. As a self-proclaimed “pro home cook”, my plan is to serve the best Oklahoma smash burgers I can realistically make in a home kitchen. That naturally turned into a rabbit hole of techniques, ingredients, buns, cheese and endless comparisons.

For work I mostly use Claude, but for personal projects I increasingly reach for ChatGPT. The memory feature makes a huge difference when you’re working on something that evolves over days. It already knows my previous experiments, the equipment I have at home, my taste preferences and all the context around the project. Once the recipe was basically done, I noticed that I wasn’t asking cooking questions anymore.

I was asking shopping questions.

The conversation already contained everything needed to make good decisions. The only thing missing was access to the products in my grocery webshop. Since there isn’t an official integration, and current web browsing isn’t particularly good at exploring an entire webshop, I spent a few hours building a tiny MCP server with Codex that lets ChatGPT search products and inspect product pages whenever it needs more context.

It worked surprisingly well.

No more screenshots. No more manually searching for products. Just continuing the conversation.

The interesting part

The MCP server itself isn’t the point. The interesting part is that I felt the need to build it. As AI assistants become part of more personal, long-running projects, they’ll increasingly become the place where purchasing decisions happen. People won’t want to leave the conversation, search a webshop, compare products, then come back.

They’ll expect their assistant to do that with them.

I open-sourced the project, but I’m not publishing it because I have no official association with Kifli.hu, and scraping someone else’s website isn’t the right solution anyway. The right solution is for retailers to expose these capabilities themselves.

Sooner rather than later.

Technical notes

Built a small Node.js MCP server.
Tried Architecture Decision Records (ADRs) for the first time instead of maintaining one ever-growing AGENTS.md file. I’m quite happy with that decision so far.
Experimented with Nub.js, which I can highly recommend checking out.
Exposed my local MCP server to ChatGPT through Cloudflare Tunnels, which is still amazing to me considering it’s available for free for projects like this.

Leave a small signal: Like on LinkedIn | Star on GitHub

My journey and current state of making music

2023-03-04T00:00:00.000Z

Once upon a time in high-school I attended to Chris Palmer’s piano and “computer assisted music making” classes and earnt a certificate. I played a piano interpretation of Don’t You Worry Child by Swedish House Mafia with beautiful vocals from my classmate Kitti at our graduation ceremony.

Then I started the uni and I also had to get a job to pay the cost of my studies and living, so I didn’t really have time and money to continue this hobby. I followed the news about electronic music production, broadened my musical repertoire and met with friends from time to time for some jamming. However I did not put too much effort into this “music making thingy” (as I referred to it).

After 6+ years spent like this, something really inspiring happened. I started working at Prezi, a company which is famous about its culture. Alex Szabo organized the first Gadget Petting Zoo™ event inside Prezi. That was about bringing your own tools, wiring them together somehow and making sounds that can be identified as music. That was an open event inside the company and you were able to join even if you don’t had musical equipment.

Tom Bean showed up with an op-z. I knew a lot about that live act workhorse but didn’t have a chance to try it out. I can truly say that this gadget is even more amazing when you can get your hands on it. So I decided to get my own.

The next logical step was to create some webscraper scripts to continously scan used instrument marketplaces. And after a few weeks, I just got a notification about a great deal. The next day I bought my own op-z! And we had amazing jamming sessions.

Since then I have a lot of fun exploring this amazing piece of hardware and making music with it. I also started to build my DAWless setup.

My primary goal here is to be able to go out for a night to play somewhere with only one backpack. (Speakers and stuff excluded of course.) I went through a lot of gears for controlling the op-z, like Novation Launch Control XL and MPK mini to unleash the potential of this genius little synth/sampler/sequencer.

Then I just spotted Intech Studio’s brilliant grid controller in this video. That was huge! It’s a programmable tiny controller (that fits in your backpack easily!) and can be a perfect companion for op-z. I ordered my first grid unit almost immeadiately, spent a weekend on writing some lua code and that worked perfectly!

Got motivated, so I started to get the full potential of the grid system. The guys at Intech just gave me some other units to experiment with so I ended up having The Perfect DAWless setup with op-z! Having a dedicated encoder for each param of the selected instrument, full control on the output level of each channel and many more handy utils. Wired together with a Kingston Nucleum and having an old iPad as a display (connected via Blouetotth LE) it’s just perfect to play live.

I’ll share the source code with the Intech guys soon, so they’ll be able to publish it officially as a Grid profile for OP-Z, so anyone interested will be able to download it.

My next step in building my electronic music setup will be figuring out how should I connect my OP-Z line module with the Grid to be able to turn on/off cue on a given channel by a push of an encoder. It would be great to be able to toggle cueing throug the line module by sending some MIDI cc messages.

schwarzkopfb/blog

Please Stop Putting AI in the Burger

We already did this with “smart”

The AI ingredient fallacy

The Remove-AI Test

The strange case of invisible AI

Sometimes “AI” is actually bad marketing

Normally, I would not care

We actually need the word

Please leave the burger alone

Skill above the tool

The skill was already moving up a level

Using AI is becoming a skill of its own

Why I look at AGENTS.md

Then someone started ranking it

Maybe we need new benchmarks

The Hardest Problem of the AI Revolution Might Be Trust

I don’t think energy is the hardest AI problem

My sister just scrolls past it

The trust chain just became much longer

“Contains AI” is probably the wrong question

AI is not a magic machine

The next challenge is verification

I Came to Fight the Machines. ARC Raiders Asked Me to Become One.

An open letter to Embark Studios

A tiny birthday side project and a product lesson

The interesting part

Technical notes

My journey and current state of making music

Why I look at `AGENTS.md`