DEV Community: Robert Keller

Beyond "It Works on My Machine": The Quest for Calm, Predictable Development Environments

Robert Keller — Wed, 06 Aug 2025 07:36:16 +0000

Have you ever heard of "environmental determinism"? It's an old theory from geography, popular in the late 19th and early 20th centuries. The idea was that a region's physical environment—its climate and landforms—was the main force shaping human culture and society. Geographers like Ellen Churchill Semple argued that people from northern Europe were "energetic, provident, serious" because of the harsh climate, while those in the tropics were lazy because life was too easy.

Thankfully, this theory was largely abandoned. It was criticized for being overly simplistic and for justifying some pretty ugly colonial attitudes. It failed to account for the most powerful force of all: human creativity and our ability to shape our own destiny.

So why am I, a software engineer, giving you a history lesson?

Because as developers, we grapple with our own version of environmental determinism every day. The difference is, our goal isn't to predict a flawed outcome. Our goal is to master the environment so that it becomes completely predictable. We seek to build systems where the environment has zero unexpected influence on our code's behavior.

In computer science, a deterministic system is one that, given a particular input, will always produce the same output. It’s the opposite of chaos. It's the property that makes a bug reproducible, a test reliable, and a deployment predictable. The challenge we face is non-determinism: the subtle differences in library versions, operating systems, and network configurations that lead to that soul-crushing phrase: "But... it works on my machine".

This isn't about limiting creativity; it's about building a stable foundation so our creativity can flourish. This is the story of how we can create development environments so predictable that we are free to build anything we can imagine.

Docker: A Sanctuary from Chaos

For most of us, the first big breakthrough in this quest was Docker. I still remember the days before containers, burning hours debugging issues that only happened on one specific machine. The culprit was often a subtle difference in library versions or OS configurations between a developer's laptop and the production server. It was maddening.

Docker came along and offered a brilliant solution: package the application with its environment. The Dockerfile became a recipe that defined the base OS, system libraries, language runtime, and all dependencies. The resulting container image is a self-contained, portable artifact. That image, when run, will behave identically whether it's on my laptop, your laptop, a CI server, or a production node.

Docker solved the immediate "works on my machine" problem by creating a deterministic environment for the application itself. It put a protective shell around our code and its direct dependencies.

But that predictability ends at the container's edge.

Your containerized microservice doesn't run in a vacuum. It needs to talk to a database, be exposed via a load balancer, and have permission to access other services. All of these external components make up the rest of the environment. If that world is configured manually, you've just moved the problem. The phrase "it works on my machine" becomes "it works in the dev cluster but fails in staging." The complexity is still there; it's just one layer out.

Docker gives us a deterministic seed, but the soil it's planted in can still be a chaotic mess. To achieve true environmental calm, we need to codify the soil itself.

Enter Infrastructure as Code: Codifying the Entire Environment

This is where we level up from containerization to full-blown Infrastructure as Code (IaC). IaC is the practice of managing and provisioning your entire infrastructure using definition files, rather than manual processes. It’s how we bring the same discipline and automation we apply to our application code to the infrastructure that runs it.

There are two main approaches to IaC: imperative and declarative.

Imperative ("How"): This is like giving a chef a step-by-step recipe. You write scripts that execute a sequence of commands: "Create a VM," "Install Nginx," "Configure this firewall rule."
Declarative ("What"): This is like showing the chef a picture of the final dish. You define the desired end state of your infrastructure in a configuration file: "I want one VM of this size and one database with these specs." The IaC tool figures out how to make it happen.

For achieving true determinism, the declarative approach, championed by tools like HashiCorp's Terraform, is a game-changer. With Terraform, you write your infrastructure definition in a simple language. When you run terraform apply, the tool compares your code (the desired state) with what currently exists (the current state) and creates a plan to make them match.

This model is inherently self-correcting and incredibly powerful for preventing configuration drift—the slow divergence of an environment's actual state from its intended configuration due to manual tweaks and "quick fixes".

The combination of Docker and Terraform is where the magic really happens. They aren't competing; they're a perfect partnership. A typical modern workflow looks like this:

Your CI/CD pipeline builds a deterministic Docker image and pushes it to a registry.
The same pipeline then runs terraform apply to provision all the necessary infrastructure (e.g., a Kubernetes cluster, a database, security groups).
As part of that apply, the configuration is updated to deploy the new Docker image.

The entire stack, from the lowest-level network rule up to the application code, is defined as code, stored in Git, and managed through a single, predictable workflow.

The Real Payoff: Speed, Sanity, and Savings

Adopting this deterministic approach isn't just an academic exercise. The payoff is tangible, immediate, and impacts everything from team morale to the company's bottom line.

Benefit 1: Onboarding at Lightspeed

Think about the traditional onboarding for a new developer. It's often a week-long process of installing tools, getting credentials, and trying to follow an outdated README.md. It's frustrating and a huge waste of time.

Now, imagine this: A new developer joins. Their Day 1 tasks are:

Clone the project repository.
Run docker-compose up and terraform apply.

By lunchtime, they are writing and testing code in a perfect replica of the production environment. This is what a deterministic, code-defined setup enables. You've transformed onboarding from a demoralizing chore into an empowering experience.

Benefit 2: Effortless Consistency and an End to Drift

Because your entire environment is just code in a Git repository, you can spin up a perfect, isolated copy of it whenever you want. This unlocks powerful workflows:

Dynamic Preview Environments: A developer opens a pull request. The CI pipeline automatically creates a temporary, fully-featured environment to test that exact branch. When the PR is merged, the environment vanishes without a trace.
Flawless Disaster Recovery: If your primary region goes down, recovery isn't a frantic scramble. It's running terraform apply with a different region variable.
Debugging Past Versions: Need to investigate a bug from six months ago? Check out the Git tag for that version, apply the corresponding Terraform code, and you have a perfect replica of the exact environment from that time.

This is the ultimate solution to configuration drift. There is no "staging" environment that's almost like "prod." Every environment is generated from the same version-controlled source of truth.

Benefit 3: Cost Efficiency by Design

This is the part that makes your manager and the finance department happy. Managing infrastructure manually is expensive. IaC turns cost optimization into an automated, proactive strategy.

When all your resources are defined in code, you gain superpowers:

Total Visibility: You have a definitive record of every piece of infrastructure that should be running, making it trivial to find and eliminate orphaned resources.
Intelligent Automation: You can codify cost-saving patterns, like automatically shutting down all non-production environments overnight and on weekends, potentially cutting their costs by over 70%.
Strategic Optimization: Want to switch a whole class of services to cheaper AWS Spot Instances? It's a change to a few lines of code, not a hundred manual clicks.

Here’s a quick look at how these strategies play out in practice:

Strategy	Description	How IaC Enables It
Ephemeral Environments	Temporary environments for testing PRs, destroyed automatically.	Terraform can apply an environment when a PR is opened and destroy it on merge.
Resource Scheduling	Automatically shutting down non-production resources outside of work hours.	Automation scripts can trigger Terraform to scale or destroy resources at scheduled times.
Right-Sizing & Spot Instances	Using the most cost-effective instance types and discounted spot capacity.	Resource definitions are in code, making it easy to change instance types. Spot instance configurations can be codified and reused.
Waste Prevention	Identifying and removing orphaned resources no longer in the IaC definition.	Running `terraform plan` periodically will show any resources that exist in the cloud but not in the code.

The Next Frontier: Determinism for the AI Gold Rush

Just as we were getting a handle on things, the AI and LLM wave arrived, introducing a new layer of complexity with massive models, specific GPU drivers, and complex Python dependencies. This is where the principles of determinism become more critical than ever for reproducible experiments and reliable deployments.

Docker is stepping up with a fascinating new tool: the Model Context Protocol (MCP) Toolkit. MCP is an open standard that acts as a "universal adapter," allowing AI systems to securely connect to the tools and data they need. Instead of complex, one-off integrations, you can now package AI tools and services as containerized MCP servers.

This is powerful because it allows you to define your entire AI infrastructure—the connections between LLMs and various tools—using simple configuration files, like YAML. You're essentially applying the principles of Infrastructure as Code to the AI stack itself. By codifying these connections, you can build fast, reproducible AI setups. This ensures that your AI applications, and the complex environments they depend on, are just as deterministic and manageable as the rest of your infrastructure. It’s about building reliable, predictable foundations for the new AI frontier.

The Real World: A Tale of Two Projects

Now, all of this sounds amazing in a blog post. But what's it like in the real world? As a team lead, I live with a foot in two worlds: my clean, modern personal projects, and the complex systems of my day job.

The Ideal Start (My Personal Project)

Starting a new project with these principles is pure joy. The first commits to the repo aren't application code; they're a Dockerfile and a main.tf file. The entire infrastructure is codified before I write a single feature.

The real magic happens when I come back to that project after six months. I barely remember how it works. But I don't have to. I check out the repo, run docker-compose up and terraform apply, and the entire stack materializes before my eyes, working perfectly. The environment is "frozen" in time by the code, waiting patiently for my return. It's the most liberating feeling in software development.

The Real-World Journey (My Day Job)

Retrofitting IaC into a large, existing enterprise system is a different story. It's less of a blank slate and more of a gradual transition. The challenges are as much cultural as they are technical.

The Learning Curve: IaC has a learning curve, and you have to convince an organization to invest in training and accept a temporary slowdown to pay down this technical debt.
Existing Infrastructure: You have to import hundreds of existing, manually-created resources into Terraform's state, which can be a detailed process.
The Human Element: The biggest hurdle is often helping people adapt to new workflows. It requires a shift to a DevOps mindset where developers own their infrastructure and operations engineers become platform enablers.

The journey is worth it, but it requires a strategic, supportive approach. Here are some common hurdles and how to clear them:

Challenge	Why It Happens	Practical Solution
Complexity & Learning Curve	IaC requires new skills. Teams are used to GUIs.	Start small with a non-critical service. Provide training, use pair programming, and establish a knowledge-sharing group.
Configuration Drift	Manual, out-of-band changes are made for "quick fixes," breaking the IaC source of truth.	Implement automated drift detection. Have a clear policy: all changes go through code review and the IaC pipeline.
Integrating Legacy Systems	Older systems may lack APIs, making them difficult to manage with modern IaC tools.	Use a combination of tools. Terraform for cloud resources, and perhaps Ansible for configuring legacy components. Abstract complexity behind modules.
Security Risks	IaC templates can contain hardcoded secrets or define insecure configurations.	Use a dedicated secrets manager. Integrate static analysis security testing (SAST) tools into the CI/CD pipeline to scan IaC files before they are applied.

Conclusion: Your Environment is Code. Treat It That Way.

Our journey to create calm, predictable environments is a story in two acts. First, we used Docker to tame the immediate environment of our application. But that wasn't enough. We then used Infrastructure as Code with tools like Terraform to tame the entire world our application lives in.

Achieving this level of predictability is a profound shift. It's about finally treating your infrastructure with the same seriousness and discipline as your application code. You must version it, review it, test it, and automate it.

The path isn't always a straight line, especially when navigating existing systems and habits. But the destination is worth the journey. It's a world with less time wasted on frustrating environment issues and more time spent on building great software. It's a world of faster deployments, happier developers, lower costs, and radically more reliable systems. It’s a world where you, the developer, are truly in control.

Vibecoding: The Antipattern We Didn't See Coming (and How to Dodge It) 🤦‍♀️

Robert Keller — Thu, 24 Jul 2025 06:00:15 +0000

Hey there, fellow code slingers and AI whisperers! I'm back on dev.to, and today we're tackling a topic that's been buzzing louder than my energy drink-fueled brain on a Monday morning: Vibecoding. ⚡️🥤

A quick heads-up before we dive in: This article isn't about handing you a bunch of copy-paste, ready-to-use AI prompts. Nope! My goal here is far more valuable: to equip you with the mindset and methodology to craft your OWN killer prompts. In my humble opinion, the single most important step in truly leveraging AI is to go through that iterative process yourself. That's how you'll genuinely understand how to make the AI do exactly what you want it to achieve. So, let's get those thinking caps on! 🧠✨

Now, before you reach for your pitchforks, let's be clear: AI-driven development is a game-changer. It's like having a super-powered intern who never sleeps, complains, or steals your last biscuit. 🍪 But, as with any shiny new toy, there's a dark side. And that dark side, my friends, is when we start treating our AI pair programmers like magic eight balls, hoping for a "Yes, definitely" on our half-baked ideas. 🎱

What in the Distributed Computing Hell is Vibecoding? 🤯

Imagine this: You're staring at a blank screen, a vague idea for a new feature swirling in your head. You fire up your AI assistant, type in "Build me a cool app," and then proceed to "iterate" by saying things like, "Hmm, no, make it more... vibey." Or, "Can you just... feel what I'm going for here?" 🤷‍♀️

That, my friends, is vibecoding in its purest, most unholy form. It's the digital equivalent of trying to explain quantum physics to a goldfish. 🐠 We're relying on intuition, vague notions, and a hope that the AI will magically pluck the perfect solution from the ether. And let me tell you, the ether is a messy place. 🧹

The Problem with "Discussing" with Your AI 🗣️

We've all been there. You get an AI-generated snippet, and it's almost right, but not quite. So, what do we do? We start a "discussion." We give feedback like, "Make it more performant," or "Less blue, more... zen." 🧘‍♂️

This is where we go wrong. Think about it: when you're working with a human junior developer, do you just say, "Make it zen"? No! You provide concrete requirements, architectural guidelines, and context. Why would it be different with an AI, which, let's be honest, doesn't have a concept of "zen" unless you define it in excruciating detail? 📝

Instead of feedbacking, think interactive prompt improvement.

Let's say the AI gives you a function for calculating the sum of an array, but it's not handling null values. Instead of saying, "It's buggy, fix it," you'd refine your prompt: "Generate a JavaScript function calculateSum that takes an array of numbers, handles null or undefined elements by skipping them, and returns the total sum. Provide JSDoc comments." 🧑‍💻

You're not "discussing" the bug; you're specifying the desired behavior more clearly. 🎯

Tweaking Prompts, Not Temper Tantrums 😡

The beauty of AI-driven development isn't in endless back-and-forths, it's in the precision of your input. If the output isn't what you want, don't iterate by "discussing." Instead:

Tweak your prompt: Add more constraints, define data structures, specify desired output formats. 📏
Refine your context: Provide relevant code snippets, architectural patterns, design principles. For example, if you're building a microservice, tell the AI it's a "Spring Boot microservice using Lombok and Spring Data JPA, adhering to REST principles." 🏛️
Select a different model: Sometimes, a different model (e.g., one optimized for code generation vs. natural language processing) might yield better results for specific tasks. 🧠

This is where the "senior developer" hat really comes in handy. Your experience allows you to break down complex problems into smaller, well-defined components that an AI can process. 🧩

The Junior Dev Analogy: Context is King (and Queen, and the Entire Royal Family) 👑

Imagine you hire a brilliant junior developer or a highly skilled freelancer. They've got deep foundational technical know-how – they can code in any language, understand algorithms, and debug like a champ. But they know absolutely zero about your specific project. 🧑‍💻

Would you walk up to them and say, "Build my cool app"? Of course not! That's like asking a master chef to "make me something yummy" without mentioning dietary restrictions, preferred cuisines, or even if it's for breakfast or dinner. 🍽️

You'd sit them down and provide:

Architectural overview: "We're building a microservices architecture using Kubernetes, with our front-end in React and our backend in Go. Data is stored in PostgreSQL and Redis." 🏗️
Domain context: "This app manages customer orders for bespoke artisanal cheese. An order has a status, a list of cheese items, and a delivery address." 🧀
Specific requirements: "The 'checkout' microservice needs an endpoint /api/orders that accepts a POST request with the customer's cart details. It should validate the items, calculate the total, and initiate a payment process with our Stripe integration." 🛒
Technical constraints: "Ensure all API endpoints are idempotent, handle concurrency gracefully, and have appropriate error logging using Splunk." 🔒

Nobody would expect to get what they want if you just say "build my cool app." One task, a million ways to solve it. And guess what? An AI is even more reliant on this level of detail. It doesn't have the implicit knowledge of best practices, your company's coding standards, or your specific business logic. You have to give it to them. 🎁

When Rebuilding Replaces Refactoring: A Common Pain Point 🚧

Let's talk about a painful truth that many of us have experienced. Before AI became our trusty sidekick, we often found ourselves in situations where we were rebuilding instead of refactoring. Imagine a scenario where you have a significant web application built with an older framework version – let's say Vue 2. If you wanted to upgrade it to a newer, more modern version like Vue 3, it often wasn't a simple refactor. It was a complete, tear-down-and-start-from-scratch kind of job. The amount of manual effort involved in migrating complex components, state management, and routing was just astronomical. 🤯 We've been there, pulling all-nighters just to get a basic migration off the ground!

With AI, this narrative could change. Imagine an AI that, given the entirety of your older codebase and a detailed understanding of the newer framework's breaking changes, could suggest or even perform the bulk of the migration. 🪄

Example:

Instead of manually rewriting an older framework component with its Options API to a newer framework component with its Composition API, you could prompt:

"Given this component using an older framework's Options API (paste component code here), refactor it into a newer framework's Composition API. Ensure data is converted to ref or reactive, methods are exposed as functions, and computed properties use the new computed utility. Also, ensure proper lifecycle hook mapping (e.g., mounted to onMounted)."

This isn't vibecoding. This is comprehensive prompting. You're giving the AI a blueprint, a target, and the instructions to get there. 🗺️

My Personal Prompting Playbook: Structured Context is Your Superpower 🚀

This brings me to my secret weapon, my personal tip for getting the most out of AI-driven development: a dedicated folder filled with structured files just for your AI agent (or your human teammates!). Think of it as your project's brain dump, meticulously organized.

Here's what goes in there:

Architectural Description: A high-level overview of your system, how components interact, and the core design principles.
Role Definition: What is the AI's role in this task? Are you expecting it to write full-stack code, just a backend service, or perhaps a tricky frontend component?
Keypoints for Frontend: Specific UI/UX guidelines, component libraries used, state management patterns.
Keypoints for Backend: Preferred language/framework, API design principles, authentication/authorization requirements.
Keypoints for Database: Schema designs, ORM choices, performance considerations.
History of Your Prompts: This is crucial. Keep a log of every significant prompt you've used. This not only helps you track progress but also serves as a fantastic learning resource for future projects.

This upfront investment in context pays dividends. It's like giving your AI a comprehensive onboarding packet before it writes a single line of code.

The Phoenix Approach: Recreate, Don't Rehabilitate (Especially When Building New) 🔥

This is a big one, especially when you're trying to build something completely new with AI. It's tempting to try and "fix" what the AI failed on the first go. Resist that urge!

Instead of trying to patch up a messy initial output, start again. Improve your prompt and context based on what went wrong, and then hit "generate" from a clean slate.

I've tried this extensively with simple app ideas. My cycle became: Improve Prompt -> Recreate Project -> Evaluate Result -> If Flawed, Repeat. I iterated these cycles until I got my architecture, project structure, and the core functionality right on the very first "shot" of the generation. It felt counter-intuitive at first, but it saves immense time in the long run compared to debugging AI-generated spaghetti code.

The Model Matchmaker: Finding the Right AI for the Job 🤝

As soon as you feel you've nailed your prompt – meaning you consistently get good results with one model – take a moment to compare AI models and their settings, and then document your findings. This is where the time you saved on vibecoding really pays off.

My personal experience with "Windsurf" (a hypothetical platform for switching AI models, much like you might switch between cloud providers) has shown me that it's an ease to toggle between a wide range of models. And here's the kicker: not every model performs the same for every tech stack.

For instance, one model might be a wizard at generating Python Flask APIs, while another shines when it comes to React components with TypeScript. Some excel at database schema generation, others at complex algorithms. Experiment! Document which models work best for which tasks or tech stacks in your prompt history folder. This knowledge becomes invaluable for future projects and optimizes your AI development workflow significantly.

Securing Our Future: Comprehensive Prompting and Architectural Planning 🛡️

The key to unlocking the true power of AI in development, and avoiding the pitfalls of vibecoding, lies in two core pillars:

Comprehensive Prompting: Treat your AI not as a mind-reader, but as an incredibly powerful, albeit literal, executor of your instructions. The more detailed, constrained, and context-rich your prompts are, the better the output will be. Think of it as writing highly specific user stories for your AI. ✍️
Real-World Software Architecture Planning: Before you even think about prompting, do your architectural homework. Design your systems, define your interfaces, establish your data models. This upfront work, just like with human developers, provides the essential framework for the AI to build upon. It ensures that the generated code fits into a larger, well-structured ecosystem. 🏗️

The takeaway? AI is a tool, not a magic wand. It amplifies your capabilities, but only if you wield it with precision and a deep understanding of what you're trying to achieve. Let's leave the "vibes" for our favorite music playlists and bring the precision to our prompts. 🎶➡️🎯

Happy coding, and may your AI-generated code be bug-free and architecturally sound! 🚀✨

Dad, Developer and continuously learning ?

Robert Keller — Wed, 02 Jun 2021 20:17:35 +0000

The hassle is real - it can't be easy to combine a great rising career as a developer and a new grown family at once, or could it ?

If you expect to find the answer here - Sorry - got ya, you won't.

It is not as easy as a single answer or solution, and it is exactly what I'm currently experiencing.

How everything changed

At the 13th of march this year my first son was born.
It is the greatest gift and completes my family.

Now after some amazing but also confusing weeks I'm getting back to work life and answering myself more questions than ever before.

How goals transform habbits

I'm working as a developer now for some years and tried to increase my knowledge day by day.
I liked the cliché of the nerdy developer that is isocialized and lives in his own world. And - I kinda was one of this strange nerds.

During university, we didn't know about day - night cycle.
Whenever we created our side project, we created it until it was finished.
It was exactly like I thought developer life would be - long nights, no sleep, energy drinks and coding.
When I joined my company I tried to keep this habbits but with around 60% employees which have families it wasn't the same.
Now I did most of the learning and side projects at myself at home, and it was ok.

I always knew that one important habbit for guys in the tech industry - especially devs - is learning, learning, learning ...

And now I knew that all is about learning ...

New goals need old habbits

Now with a son and a wife, my complete view on my future changed:

Currently we live in the city in a flat - but I want my son to grow and rise out of the city with a house and a garden
I want to spend as much time with my son - not with hobbies and learning
But for my wanted future I need a save job
The save job is being a developer - because this is what I live for
And being a good developer is all about learning, learning, learning...

And there it is : a strange loop with, it seems, no solution ?

The Solution ?

Currently, I'm not sure about the solution and trying to use sleeping time of my family to keep learning.

I will keep you up to date, and maybe I could develop the number one recipe for being a great dad and a always evolving and learning dev.