DEV Community: Don

How to Vibe Code in Production Without Breaking Everything

Don — Thu, 07 Aug 2025 18:14:15 +0000

Erik Schulntz, a researcher at Anthropic focused on coding agents, is here to talk about a subject near and dear to his heart: vibe coding. If you’ve heard the term, you might associate it with engineers using AI tools like Cursor or Copilot for extensive code generation. But Eric, who remarkably had Claude write all his code for two months after breaking his hand, argues that’s not quite the full picture.

What is Vibe Coding, Really?
True vibe coding, according to Andre Carpathy’s definition, is when you “fully give into the vibes, embrace exponentials, and forget that the code even exists”. The crucial part? “Forget the code even exists”.

Initially, this concept brought excitement beyond the engineering world, allowing non-coders to suddenly build entire apps. It was revolutionary! However, this freedom came with downsides: people coding without knowing what they were doing, leading to issues like maxed-out API usage or bypassing subscriptions. The successful early cases of vibe coding were often low-stakes, like building video games or fun side projects where bugs were acceptable.

Why We MUST Care About Vibe Coding
So, why bother with something that seems suited only for “toy examples”? The answer lies in the exponential growth of AI capabilities. The length of tasks AI can handle is doubling every seven months. While an AI generating an hour’s worth of code might still allow for intimate human review today, what happens when it generates a day’s or even a week’s worth of work?

Eric emphasizes that to leverage this exponential growth, we cannot remain in “lockstep” with traditional review methods. We must find a way to “responsibly give into this”.

Learning to Trust: The Compiler Analogy
Think about compilers. In their early days, developers might have scrutinized the assembly output to ensure it matched their manual coding. But that approach doesn’t scale for complex systems. At some point, you simply have to trust the system.

The same applies to AI-generated code. The challenge for the software industry is: “how will we vibe code in prod and do it safely?”. The answer, Eric proposes, is to “forget that the code exists but not that the product exists”. Just as we build good software without understanding every line of assembly, we’ll need to do the same with AI-generated code.

Managing What You Don’t Understand: An Age-Old Problem
This isn’t a new problem for the business world. Consider:

A CTO managing an expert without being an expert themselves.
A Product Manager reviewing an engineering feature without reading all the code.
A CEO checking an accountant’s work without being a financial expert.
These problems, “as old as civilization,” have solutions. A CTO can write acceptance tests, a PM can use the product, and a CEO can spot-check key facts. The key is to find an “abstraction layer that you can verify even without knowing the implementation underneath it”. Software engineers, traditionally used to understanding the full depth of the stack, need to embrace letting go of some details to maximize productivity, much like managers do.

The Tech Debt Caveat and “Leaf Nodes”
Currently, there’s one significant caveat: tech debt. It’s hard to measure or validate tech debt without directly reading the code, unlike other systems where verification is possible at a higher level.

So, how do we proceed? Eric’s advice is to focus vibe coding on “leaf nodes” in your codebase. These are parts of the system that nothing else depends on-think end features or “bells and whistles”. It’s acceptable for these to have some tech debt because they’re unlikely to change or have further things built upon them. The core architecture (the “trunks and underlying branches”) still requires deep human understanding to ensure extensibility and flexibility. However, as models like Claude 4 improve, Eric anticipates we’ll gain more trust in them to write extensible code with less tech debt.

How to Succeed: Be Claude’s Product Manager (PM)!
The core advice for successful vibe coding is: “Ask not what Claude can do for you but what you can do for Claude”. When you vibe code, you are essentially acting as a product manager for Claude.

This means:

Think like a PM: What guidance, context, requirements, specifications, and constraints would a new human employee need to succeed?.
Provide rich context: Instead of quick back-and-forth prompts, spend time (15–20 minutes for Eric) collecting guidance into a single, detailed prompt. This often involves a separate conversation with Claude to explore the codebase, identify files, and build a plan that captures the essence of your goal and the patterns to follow.
Ask the right questions: Not everyone should vibe code in production systems, especially those who can’t effectively guide Claude or discern what’s dangerous or safe.
A Real-World Success Story: Anthropic’s 22,000-Line Change
Anthropic recently merged a 22,000-line change to their production reinforcement learning codebase, written heavily by Claude. How did they do this responsibly?

Human PM Role: Days of human work went into defining requirements and guiding Claude. They truly embraced their role as Claude’s product manager.
Focus on Leaf Nodes: The change was largely concentrated in leaf nodes where some tech debt was acceptable.
Heavy Human Review for Core Parts: Critical, extensible parts of the code still received heavy human review.
Designed for Verifiability: They carefully designed stress tests for stability and ensured the system had easily human-verifiable inputs and outputs. This allowed them to create “verifiable checkpoints” and measure stability and correctness without reading all the underlying code.
This allowed them to be as confident in the change as any other, but deliver it in a “tiny fraction of the time and effort”. It also fundamentally changed their engineering mindset, making them willing to tackle much bigger features because the “marginal cost of software is lower”.

The Future of Software Engineering and Learning
This shift begs the question: how do we learn and become better engineers when AI handles so much of the low-level coding? While there’s a valid concern about losing the “struggle in the grind”, Eric is optimistic. He finds he learns much faster with AI tools. Claude acts as an “always there pair programmer,” explaining libraries or design choices.

Furthermore, by collapsing the time it takes to implement large architectural changes (e.g., from two years to six months), engineers will be able to learn from four times as many lessons in the same calendar time, provided they put in the effort to understand.

Practical Tips for Responsible Vibe Coding
Balance Information: It depends on what you care about. For features where implementation details don’t matter, simply state your desired outcome. For familiar codebases, provide more depth, but avoid over-constraining the model. Treat Claude like a junior engineer you’re onboarding.
Security: For production systems, you need to understand enough context to identify dangers and guide Claude appropriately. Vibe coding fully offline systems, for instance, significantly reduces security concerns. Products and frameworks that are “provably correct” or provide sandboxed environments for AI-generated code could emerge to make vibe coding safer for a wider audience.
Test-Driven Development (TDD): TDD is “very, very useful” in vibe coding. Encourage Claude to write minimalist, end-to-end tests (e.g., happy path, error cases) that are general enough for you to understand, even without reading the implementation. Often, reviewing just the tests and ensuring they pass can give confidence in the code.
Managing Context: To avoid Claude “going off the rails” or creating new names for functions, compact your sessions when you reach a natural “stopping point” or “break”. This reduces the token count significantly.
Exploring New Codebases: Before writing features in unfamiliar areas, use Claude Code to explore the codebase. Ask it to identify relevant files, classes, or similar features to build a mental picture and ensure you’re not blindly vibe coding in critical areas.
Embrace the Exponential!
The models aren’t just getting better; they’re getting better faster than we can possibly imagine. Just as computers evolved from kilobytes of RAM to terabytes over 20 years, AI capabilities will advance millions of times over.

It’s okay not to vibe code today, but in a year or two, it will be a “huge disadvantage” if you insist on reading or writing every line of code yourself. You risk becoming the bottleneck, unable to leverage the powerful new wave of models. This is poised to be one of the biggest challenges-and opportunities-for the software engineering industry in the coming years.

By responsibly embracing vibe coding, focusing on verifiable abstraction layers, guiding AI like a product manager, and wisely choosing where to apply it, we can unlock unprecedented productivity and innovation in software development.

Originally published at https://slaxone.com

If Kubernetes Runs in F-16 Fighter Jets, Why Are You Still Scared to Use It in Your Business?

Don — Wed, 09 Jul 2025 21:43:17 +0000

Get ready for an absolutely wild story from the U.S. Department of Defense (DoD)! Imagine an F-16 fighter jet – one of the fastest, most powerful planes in the world – now running super-smart software thanks to some amazing technology you might not even know about: Kubernetes and Istio. This isn't just a cool gadget; it's a huge change for how the military builds and updates its technology, moving from slow, old ways to rapid, secure, and flexible methods.

The Old Way: Slow, Manual, and Risky!

Before this big change, building software for the DoD was like trying to build a giant Lego castle one brick at a time, perfectly, before moving to the next section. This was called the "waterfall model". If they found a problem at the end, they had to go all the way back to the beginning to fix it, which was super slow.

How slow? Software updates for important systems could take an astonishing three to ten years to get ready! Imagine waiting that long for an update to your favorite video game! Getting a "safety sticker" or "Authority to Operate" (ATO) for new software also took a very long time – anywhere from three months to a year.

This slow process was a big problem. Other countries were making their software better and faster, and the DoD risked falling behind. Plus, slow updates meant that if there was a security weak spot, it would take a long time to fix, leaving important systems open to attacks.

The New Way: Super-Fast, Super-Safe DevSecOps!

In 2018, Nicolas Chaillan, who was the Chief Software Officer for the U.S. Air Force, teamed up with Peter Ranks from the DoD to fix this. They launched the DoD Enterprise DevSecOps Initiative. Think of it as a new, super-powered plan to build software. This plan made it mandatory to use special open-source tools like Kubernetes and Istio. The goal was to make everything faster, more secure, and allow constant updates, especially for important areas like Artificial Intelligence (AI), Machine Learning (ML), and cyber defense.

Here's how they did it, using some amazing "secret weapons":

Smart Managers for Programs (Kubernetes): They picked Kubernetes because it's like a brilliant orchestra conductor for computer programs. It makes sure programs run smoothly, can be easily updated, and even fix themselves if something goes wrong. It also helps them avoid being stuck with one company's tools.
Built-In Security Guards (DevSecOps with Istio): The "Sec" in DevSecOps means security isn't an afterthought; it's built-in from the start. They use Istio like a super strict security guard that makes sure only allowed programs can talk to each other, stopping threats and making it harder for bad guys to get in.
Always Approved (Continuous ATO): Instead of waiting months or a year for software to get that "safety sticker," if a team follows the DoD's new rules, their software gets a "continuous Authority to Operate" (ATO). This means it's always being checked and approved, allowing for constant updates.

The F-16 Breakthrough: Impossible in 45 Days? Not for Them!

To show everyone that this new way of doing things really worked, Nicolas Chaillan picked a super tough challenge: getting Kubernetes to run on an F-16 fighter jet. Why a jet? Chaillan said, "I tackled the weapon systems so General Officer and Senior Executives will pay attention, and that’s where you usually end up getting the funding". He knew that if they could do it on a jet, it would prove it could be done anywhere.

The SoniKube team at Hill Air Force Base was given the mission: get Kubernetes running on an F-16's existing, older hardware in just 45 days. They couldn't change the jet's physical parts – it had to run on "legacy hardware". The biggest challenge was making sure the system could boot up from scratch with all the new software running in just two minutes if something went wrong. This "two-minute boot" is a key safety requirement for the jet.

In an amazing 45 days, the team succeeded! They showed that the F-16 could run modern programming languages like Go, Java, and Python – a huge step up from the older language used before. This wasn't just a trick; it showed that the jet could run three separate Kubernetes clusters at the same time. This proved that the new cloud-native way brings high availability, resiliency, and speed. Now, pilots can get new AI and ML tools very quickly to help them in battle. The team even built cool simulators to test updates before they went on the actual jet, making sure it would behave the same way on the real jet.

Beyond the Jet: A DoD-Wide Revolution!

The F-16 project was just the beginning. The DoD is now moving its daily business systems, space systems, nuclear systems, and cyber defense systems to these modern, cloud-native environments. Already, 37 teams are building applications using Kubernetes.

This is a massive undertaking! The DoD needs to train 100,000 people on these new DevSecOps principles and tools. It's a huge cultural shift, moving from a very closed way of working to an open, collaborative model.

The DoD's bold move shows that these modern, cloud-native practices are not just for tech companies; they are essential for national security and can be a blueprint for any complex industry around the world.

Ready to Transform Your Business?

Look, the U.S. military just proved the impossible: they put cutting-edge tech, the same stuff driving Silicon Valley, right onto a freaking F-16 fighter jet! They did it in 45 days! They broke free from the slow, old ways and embraced speed, security, and smart automation.

If the DoD can completely change how they build and deliver critical software – moving at light speed, securing everything to military standards, and training 100,000 people – what's your excuse?

This isn't just about jets; it's about transforming your reality. It's about taking your business from "stuck in the past" to "leading the future." The principles they used—embracing open source, building with flexibility, and automating security—are your blueprint for unstoppable growth.

Don't wait for your competitors to fly past you. The future of business is fast, secure, and always evolving. At SlaxOne, we bring you stories of breakthroughs like this, showing you exactly how the biggest players are winning.

Your business deserves this level of innovation. The question is: are you ready to take flight?