The Trap of “Just Make It Work” in CI/CD

Yesterday, another build blew up in CI. There it was in red, naturally: “poetry.lock is out of date.” If you’ve touched Python builds, you’ve probably watched that message ruin a good morning. It always seems to show up right in the middle of a flow.

You paste the error into your favorite AI assistant, hoping for a quick win. The suggestion comes back instantly: “Just run poetry lock in your build pipeline!” You feel that little rush—could it really be that easy, just one more step and everything goes green?

But then I paused. Isn’t the point of the lock file to keep builds deterministic?

I pushed back on the AI. Immediately, it flipped. “Oh! You’re right. You shouldn’t modify the lock file in CI.” No debate, just pure reversal.

That’s when it hit me. AI can explain the “how” all day long—but you have to Guide AI with constraints if you want it to respect the “should.” It’s happy to give you a fix that makes errors disappear, but it doesn’t check whether that fix actually respects the deal we’ve made with our system. Builds should be reproducible, period. It could write the code, sure. But it couldn’t tell whether the code should be written. That’s the real risk—if we don’t name our principles, the AI just mirrors our questions, not our constraints.

Why AI Defaults Undermine Contracts Unless We Set the Frame

When you feed a prompt to an AI, it isn’t reflecting or reasoning in the way people do. It’s simply playing autocomplete for code and advice, ranking what’s likely based on past patterns, not on your system’s deeper contracts or intent. That’s not reflection. That’s re-ranking. The model’s goal is to finish your sentence in a plausible way, whether or not it’s actually correct for your situation.

What’s wild is how fast it switches the moment you push back. Tell it “no, that breaks reproducibility,” and suddenly it offers the opposite guidance—because it’s not weighing system context or design principles behind the scenes. It just re-weights what completion looks like based on your objection.

That means our job changes. We can’t just ask questions and hope for best-practice answers. We have to state the principle first, outline the constraints, and clarify which tradeoffs are never acceptable. Then the AI can autocomplete within those guardrails, instead of wandering off into dangerous territory.

Let’s talk lock files—specifically poetry.lock in a CI/CD pipeline. The point isn’t just to avoid red builds. It’s to lock dependency versions so you get the exact same environment, every time, everywhere. That file was generated locally; it encodes the precise packages that worked together on someone’s machine. If you run poetry lock as an automated fix in CI, you’re silently telling the system to pull new dependencies or resolve fresh conflicts inside your build step. That breaks the contract and makes your builds fragile. Now, two pipelines might fetch different trees and produce different artifacts, all because the “fix” updated state in the wrong place. The lock file is the promise—violate it, and you lose trust in your pipeline.

So if we actually want to Guide AI with constraints and get solutions that honor them, not just plausible fixes, we need to start by encoding those invariants in our prompt. When you say what must not change, the model has a chance to help you keep the promise instead of quietly breaking it. That’s how principle-first prompting keeps your builds, and your trust, intact.

A Method to Guide AI With Constraints—So AI Suggestions Stay Trustworthy

Let me walk you through the guardrail method that changed how I work with AI in CI/CD. You start by stating your invariant upfront—what must always be true. Then you follow by listing specific constraints. Moves that are forbidden, shortcuts that will break your intent. Third, you spell out which tradeoffs you’re willing to flex, and set criteria for what makes a fix acceptable. The order matters.

If you start with what “should” happen, instead of only listing what “shouldn’t,” the AI is 27% more likely to match human preferences. Structure moves the needle. I’ve wasted time on prompts that were too vague, watching AI chase convenience over reliability. Framing the invariant first, then gating actions, then inviting alternatives—it’s the pattern that finally got suggestions to stick to principle instead of shortcuts.

The first step is to protect system invariants by naming the invariant as a hard requirement. For CI/CD with Poetry and Python, that means builds must be reproducible across environments, absolutely no network leaks during dependency resolution, and every change must be auditable. Honestly, I still forget this sometimes, especially when the pipeline error is loud and frustrating. But if I don’t declare “the environment must be deterministic,” the AI will hand me a fix that’s clever, not correct. You need to say it like there’s no room for negotiation.

Next, use constraint based prompting to spell out your constraints. Be blunt. For example, do not modify poetry.lock during CI or any automated build step. Don’t let dependencies upgrade implicitly. No “just add poetry lock!” or resolution recalculations on the fly. These are the moves that kill reproducibility and hide systemic drift.

Step three: describe the tradeoffs. This is where you clarify what can flex without crossing the line. You might allow skipping optional tests if time’s tight, or defer flaky test failures to preserve speed. But you never sacrifice deterministic builds for convenience. When you prompt the model, ask it to propose alternatives that uphold the invariant, even if everything else flexes. That way, you still get creative suggestions—but the core contract is preserved.

Practically, I enforce constraints in prompts, requiring sources or logs to justify a fix. But I bind those evidence points to constraints. So if the AI references Stack Overflow or a GitHub issue, it has to say “does this method honor deterministic environments?” It can show the “how,” but must prove it respects the “should.” If it can’t, we scrap the fix. That’s how you get contract-preserving answers, even when the problem looks routine.

Principle-First Prompting Across Everyday Engineering Choices

When you’re pushing a database migration, the core problem is keeping data safe. Integrity is non-negotiable. Your system has to keep working for users even as the data model shifts. The trick is to build out your migration plan in stages, verify each step, and include a rollback path in case something goes sideways. You can actually run a migration with zero application downtime if the plan is stitched together right source. That’s what you need to ask for—a prompt that covers the “how” and the precautions.

Caching and performance are where tradeoff thinking gets real, and this is the spot engineers mess up most. It seems easy—stick a cache in front of something slow, and watch the speeds go up. But every shortcut invites trouble if the cache gets out of sync, serving stale data or, worse, poisoned values that break the system in subtle ways. I’ve been bitten by this enough times that I now ask the AI to spell out what correctness means before it even suggests a caching strategy—how will it avoid stale reads, bad invalidation, or accidental cache busts? If the answer is “add a cache here for speed,” I know something’s missing. Performance matters, but not if it trades away correctness.

Infrastructure as code brings it all together. The invariant here is declarative truth. Your configuration should match your actual cloud state, no matter what. Any AI suggestion must keep reproducibility front-and-center. No silent drift, no hidden changes baked into the CI step. So I always prompt for plans that reconcile state without side effects, making sure the build pipeline stays a source of truth instead of a vector for surprise. If the model tries to slip in a quick fix without that guarantee, I reject it just like I would with a poetry.lock update in CI.

I used to think that process was only worth it for the high-risk stuff—migrations, infra, things that could take down production. But even the “minor” decisions, like dependency management, can unravel everything if you let seemingly safe automation slide. That poetry.lock headache from earlier keeps coming back to remind me.

Each example boils down to principle driven AI prompts: start with your principle—the “should”—before inviting the AI to fill in the “how.” It feels slow at first, but it’s the only way I’ve found to make AI advice reliable when trust, safety, and correctness hang in the balance.

Handling Doubts, Building Confidence—Principle-First Prompting in Practice

I get the pushback all the time—’Avoid convenience fixes’ feels like it will slow us down. “Won’t all this upfront framing just slow us down?” Let’s be real—sometimes it feels that way. When another build fails, you want the fix, not a drawn-out best practice debate. But here’s the thing: every minute you spend clarifying invariants before prompting is a minute you save hunting bugs and patching brittle pipelines later. I’ve seen teams scramble to hotfix issues caused by convenient “just make it work” hacks, burning hours in rework that never should have been needed. Framing cuts down back-and-forth, speeding the whole cycle. Speed and safety aren’t a tradeoff—they’re a multiplier, if you get the framing right at the start.

Another doubt that comes up is whether AI can actually handle all the real-world nuance. It can automate the “how,” but it still relies on you for the “should.” The more you restate tradeoffs, build in checklists, and get explicit with constraints, the closer the AI gets to reliably protecting your intent—especially compared to generic prompts that chase surface-level fixes.

Want to put these principles to work without theory overload? Start with a short invariant statement—one or two sentences, written right into your workflow. “Lock files must never be modified in CI. Builds must match local, byte-for-byte.” That’s your contract.

Then keep a constraints-and-checklist template handy, somewhere visible. “No in-place dependency upgrades, no interactive fixes, verify against production logs.” Every time you incorporate an AI suggestion, measure results in your build pipeline history. Track how many rollbacks you’ve needed, how often the build stays green, how frequently you dodge “one-off” hot fixes. It only took me two weeks of logging these stats before I saw a clear drop in chaos—fewer emergency patches, fewer weird environment mismatches, and a lot more confidence in what made it to production.

Full disclosure: I still second-guess myself sometimes. There are days where someone asks, “Can’t we just patch the lock file quickly in CI if it’s blocking the pipeline?” And even though I know the answer should be no, I pause. The pressure to keep things moving is real, especially when deadlines get tight. The discipline it takes to say “let’s fix the root, not paper over it” is something I’m still working on.

No secret sauce needed. I keep my invariant and constraint outlines tucked in my repo or as CI comments, and refer back whenever I troubleshoot, especially if AI is in the loop. It’s a process you can start today and refine over time—each incident teaches you how to tighten the template, add new edge-case checks, and improve how you phrase the guardrails. We don’t need perfect—just a little more repeatability in what AI gives back.

So the next time your poetry.lock explodes in CI, don’t just reach for “how do I fix the error”—start with “what should never change?” Frame your principle, state your contract, and let the AI fill in the details. You’ll see the guidance shift, and you’ll build a reputation for shipping systems that people can actually trust.