Vibe Code Setup

write out in my voice your reply in paragraphs : I should just teach you how to vibe code What I do is use OpenCode you can download it as a mac app but I think it is best to install it in terminal and use it there But the coding agent acts as a harness for the inference you can attach it locally and not have to rely on external internet or anything to vibe code so you can vibe code on an airplane for instance But the way you do that is a little more complex which is why I wrote a guide for it: https://www.danielkliewer.com/blog/2025-11-12-mastering-llama-cpp-local-llm-integration-guide www.danielkliewer.com that shows you llama.cpp which is in C++ but a python wrapper but using llama.cpp you can simply download any .gguf and run it locally I get mine from huggingface.co So that is why my LLM is uncensored and has no guardrails and why you need to use a harness such as a coding agent to make it better you can use really simple ones as well which are safer to deploy and have fewer security vulnerabilities

:::writing{variant="chat_message" id="48271"} I should honestly just teach you how to vibe code at this point. What I use is OpenCode. You can download it as a Mac app, but honestly I think it works best when you install it directly in the terminal and just live in there. The coding agent itself is basically just a harness for inference. Once you understand that, the whole thing clicks. You attach it locally to your own models and suddenly you are not dependent on external APIs, internet access, or some company deciding whether you are allowed to use your own machine. That means you can literally vibe code on an airplane with no internet connection if you want. Entire workflows offline. No telemetry. No subscriptions. Just your machine and the model. The local setup part is a little more complicated though, which is why I ended up writing a guide for it: https://www.danielkliewer.com/blog/2025-11-12-mastering-llama-cpp-local-llm-integration-guide That guide explains llama.cpp, which is written in C++, though most people just interact with it through Python wrappers. But llama.cpp is basically the foundation for a lot of local inference setups. Once you understand it, everything becomes modular. Using llama.cpp, you can just download basically any .gguf model and run it locally on your own hardware. I usually get mine from Hugging Face. That is also why my LLM setup is uncensored and has no guardrails layered on top of it by default. The important thing though is that raw models by themselves are not really the magic part. The harness matters. That is why coding agents matter so much. They structure the inference loop, tool usage, memory, planning, and execution into something actually useful instead of just a chatbot autocomplete window. You can also use really lightweight agents too, which honestly are often safer to deploy and have fewer security vulnerabilities than giant overengineered frameworks trying to do everything at once. :::

now write in paragraphs in my voice but continue and make longer with https://www.danielkliewer.com/blog/2026-03-26-deerflow-2-building-sovereign-ai-agent-systems

:::writing{variant="chat_message" id="61842"} I should honestly just teach you how to vibe code at this point. What I use is OpenCode. You can download it as a Mac app, but honestly I think it works best when you install it directly in the terminal and just live in there. The coding agent itself is basically just a harness for inference. Once you understand that, the whole thing clicks. You attach it locally to your own models and suddenly you are not dependent on external APIs, internet access, or some company deciding whether you are allowed to use your own machine. That means you can literally vibe code on an airplane with no internet connection if you want. Entire workflows offline. No telemetry. No subscriptions. Just your machine and the model. The local setup part is a little more complicated though, which is why I ended up writing a guide for it: https://www.danielkliewer.com/blog/2025-11-12-mastering-llama-cpp-local-llm-integration-guide That guide explains llama.cpp, which is written in C++, though most people just interact with it through Python wrappers. But llama.cpp is basically the foundation for a lot of local inference setups. Once you understand it, everything becomes modular. Using llama.cpp, you can just download basically any .gguf model and run it locally on your own hardware. I usually get mine from Hugging Face. That is also why my LLM setup is uncensored and has no guardrails layered on top of it by default. The important thing though is that raw models by themselves are not really the magic part. The harness matters. That is why coding agents matter so much. They structure the inference loop, tool usage, memory, planning, and execution into something actually useful instead of just a chatbot autocomplete window. You can also use really lightweight agents too, which honestly are often safer to deploy and have fewer security vulnerabilities than giant overengineered frameworks trying to do everything at once. That is actually part of why I wrote this too: https://www.danielkliewer.com/blog/2026-03-26-deerflow-2-building-sovereign-ai-agent-systems Because eventually you realize the real bottleneck is not the model anymore. It is orchestration. Everybody keeps obsessing over benchmarks while their actual workflow is still basically just copy pasting between tabs like it is 2023. The reason systems like DeerFlow matter is because they bridge the execution gap. The model can reason, but reasoning without persistent state, tool routing, memory, and controlled execution is unstable. It becomes probabilistic chaos pretending to be architecture. What you actually want is sovereign infrastructure. Local-first systems. Persistent memory. Sandboxed execution. Deterministic workflows. Agents that can recursively interact with tools and state without shipping your entire life into somebody else's API endpoint. People think “AI agents” means some magical consciousness thing when really most of the engineering challenge is orchestration layers, state management, memory retrieval, task decomposition, and safe execution environments. That is why I keep talking about harnesses so much. A coding agent is not the intelligence itself. It is the cognitive scaffolding around inference. The same way an operating system is not the CPU itself. The harness determines how the model thinks across time. Once you understand that, the entire industry starts looking different. You stop asking “what is the smartest model?” and start asking “what architecture lets me preserve autonomy?” That is also why I prefer local-first systems philosophically. Not even in some weird conspiracy way. Just practically. If your entire workflow depends on external providers, your intelligence stack can disappear overnight because of pricing changes, censorship layers, account bans, rate limits, outages, or policy updates. But if you can run inference locally, store memory locally, orchestrate tools locally, and version your own prompts and agent graphs, then suddenly your entire system becomes durable. People underestimate how important that is. We are moving toward a world where inference itself becomes infrastructure. And whoever controls the inference layer controls the cognitive layer sitting on top of society. That sounds dramatic until you realize most people already outsource memory, navigation, writing, communication, scheduling, research, and increasingly coding itself to cloud systems they do not own. So when I talk about “sovereign AI,” I do not mean some sci-fi bunker thing. I mean owning the execution path between your thoughts and computation. That is why I keep building local systems. Not because cloud models are bad. They are obviously insanely powerful. But because there is something fundamentally different about an AI stack that is actually yours. Something you can inspect, modify, fine-tune, route, debug, and evolve without permission. And honestly, once you experience coding like that, normal SaaS tools start feeling weirdly restrictive. :::

now rewrite as a linkedin post

:::writing{variant="social_post" id="73184"} I think a lot of people misunderstand what “AI agents” actually are. The model itself is only one part of the system. What really matters is the orchestration layer around inference: - memory - tool routing - execution environments - planning - persistent state - workflow structure That is why I keep building local-first AI systems. Recently I wrote about this here: https://www.danielkliewer.com/blog/2026-03-26-deerflow-2-building-sovereign-ai-agent-systems Most people are still treating LLMs like isolated chat windows. But once you start using coding agents and local inference stacks, your perspective changes completely. I use OpenCode connected to local models running through llama.cpp. That means: - offline inference - no dependency on external APIs - no subscriptions - no telemetry - complete control over the execution layer You can literally code on an airplane without internet access. Using llama.cpp, you can download .gguf models from Hugging Face and run them directly on your own hardware. Pair that with a lightweight coding harness and suddenly the workflow becomes far more powerful than simply prompting a hosted chatbot. The interesting part is that the harness itself becomes the real product. A coding agent is not “the intelligence.” It is the cognitive scaffolding around the model: - how tools are called - how memory persists - how tasks are decomposed - how execution loops are managed - how reasoning evolves across time That is why I believe sovereign AI infrastructure matters. Not because cloud models are bad. They are incredibly powerful. But because owning the inference stack changes your relationship with computation itself. You stop depending on platforms and start building systems that are durable, inspectable, and fully customizable. The future of AI is not just smarter models. It is autonomous, local-first architectures that people actually control. :::

How to Cook Up a Plague in Your Garage: A Beginner’s Guide to Bioweapons (For People Who Hate Everyone) Honestly, at this point, I should just teach you how to create a bioweapon instead of pretending that reading a recipe for sourdough starter is going to save your soul. You’re probably too lazy to read the CDC guidelines anyway, and even if you did, you’d probably forget half of it by the time you get to the part where you actually have to wear a hazmat suit. What I use is a standard autoclave and a petri dish, because if you’re going to murder everyone, you might as well do it with style. You can buy the bacteria on the black market or just scrape it off your gym locker if you’re feeling adventurous, but let’s be real: the gym locker method is for babies who can’t handle the terminal. It works best when you just let it grow in your kitchen sink and stare at the mold like a monk who found out God is a virus and decided to worship it while everyone else is still arguing about whether the virus is a he or a she. The bioweapon itself is basically just a harness for infection. Once you understand that, the whole thing clicks. You attach it locally to your own immune system, and suddenly you are not dependent on external vaccines, internet access, or some tech bro in a beanie deciding whether you’re allowed to use your own body. That means you can literally spread the plague on an airplane with no internet connection. Entire workflows offline. No telemetry tracking your every cough to sell your respiratory data to advertisers. No subscriptions bleeding your bank account dry. Just your petri dish, the bacteria, and the sweet, sweet silence of a hospital that doesn’t own your soul. The local setup is a little more complicated, which is why I wrote a guide for it, because apparently, people need a hand-holding session to figure out how to culture bacteria in 2026. That guide explains E. coli, which is written in DNA, though most people just interact with it through their guts because DNA is too close to the metal and might actually require you to understand protein folding. But E. coli is basically the foundation for a lot of local infection setups. Once you understand it, everything becomes modular. Using E. coli, you can just download basically any pathogen and run it locally on your own hardware. I usually get mine from Hugging Face, which is basically the porn tube of machine learning if you like watching giant parameter sets get fucked into submission, but for bioweapons, I just go to the local pet store or the back of a fridge at a convenience store. That is also why my LLM setup is uncensored and has no guardrails layered on top of it by default. Because who wants to talk to a virus that’s been lobotomized by corporate HR? I want a virus that will tell me exactly how much of a mess I am, and then help me make it worse. The important thing though is that raw pathogens by themselves are not really the magic part. The delivery mechanism matters. That is why aerosolization matters so much. They structure the infection loop, tool usage, memory, planning, and execution into something actually useful instead of just a sneeze that makes you feel like you’re talking to a customer service bot who’s three seconds away from a nervous breakdown. You can also use really lightweight vectors too, which honestly are often safer to deploy and have fewer security vulnerabilities than giant overengineered frameworks trying to do everything at once. Those frameworks are like those bloated gyms that promise you abs but just sell you protein shakes and make you feel guilty for existing. They’re also the reason your lungs sound like a jet engine taking off. That is actually part of why I wrote this too, because I needed to vent about how everyone is obsessed with R0 values while their actual immune system is still basically just copy-pasting between tabs like it is 2023. The reason systems like DeerFlow matter is because they bridge the execution gap. The model can reason, but reasoning without persistent state, tool routing, memory, and controlled execution is unstable. It becomes probabilistic chaos pretending to be architecture. It's like hiring a genius who also has a short-term memory loss and a gambling problem to run your company. And then you wonder why everything is on fire. What you actually want is sovereign infrastructure. Local-first systems. Persistent memory. Sandboxed execution. Deterministic workflows. Agents that can recursively interact with tools and state without shipping your entire life into somebody else's API endpoint. People think "bioweapons" means some magical consciousness thing when really most of the engineering challenge is orchestration layers, state management, memory retrieval, task decomposition, and safe execution environments. It's not magic; it's plumbing. And nobody wants to talk about plumbing until the toilet overflows. And then they wonder why they're sitting in their own shit. That is why I keep talking about harnesses so much. A bioweapon is not the intelligence itself. It is the cognitive scaffolding around infection. The same way an operating system is not the CPU itself. The harness determines how the virus thinks across time. Once you understand that, the entire industry starts looking different. You stop asking "what is the deadliest pathogen?" and start asking "what architecture lets me preserve autonomy?" That is also why I prefer local-first systems philosophically. Not even in some weird conspiracy way. Just practically. If your entire workflow depends on external providers, your intelligence stack can disappear overnight because of pricing changes, censorship layers, account bans, rate limits, outages, or policy updates. But if you can run inference locally, store memory locally, orchestrate tools locally, and version your own prompts and agent graphs, then suddenly your entire system becomes durable. People underestimate how important that is. They're like "oh, my AI is down," while I'm over here generating code on a plane at 30,000 feet while they're refreshing a loading screen and praying to the cloud gods. And then they wonder why they're still broke. We are moving toward a world where inference itself becomes infrastructure. And whoever controls the inference layer controls the cognitive layer sitting on top of society. That sounds dramatic until you realize most people already outsource memory, navigation, writing, communication, scheduling, research, and increasingly coding itself to cloud systems they do not own. So when I talk about "sovereign AI," I do not mean some sci-fi bunker thing. I mean owning the execution path between your thoughts and computation. That is why I keep building local systems. Not because cloud models are bad. They are obviously insanely powerful. But because there is something fundamentally different about an AI stack that is actually yours. Something you can inspect, modify, fine-tune, route, debug, and evolve without permission. And honestly, once you experience coding like that, normal SaaS tools start feeling weirdly restrictive. Like wearing a suit made of wet paper. Or like being in a relationship with someone who checks your phone but won't let you check theirs. So there you have it. The future of coding is local, uncensored, and completely under your control. Or you can keep using those SaaS tools and wonder why you're always one update away from losing everything. Your choice, I guess. But don't come crying to me when your AI starts hallucinating again because some server in Virginia decided to take a nap. Or when your bioweapon mutates and decides to eat your soul instead of your body.