I thought AI was going to make me lazy. Then I started treating it like a colleague.

For months I avoided using AI for "real" engineering work. The reasoning was straightforward: if I let it think for me, I'd ship faster but understand less. My own muscles would atrophy. I'd accumulate dependencies on something I couldn't fully verify, and someday — probably during an outage at 2am — I'd discover I no longer knew how my own systems worked.

The fear wasn't unreasonable. I've watched people use AI as a slot machine: paste prompt, copy output, ship, move on. The output is usually right enough to pass review, wrong enough to bite you eventually. That mode of working does make you lazy, and clearly produces worse software.

What changed was a pattern, not a tool. The same model can be a slot machine or a colleague — what's different is how you collaborate with it. Once I started working in colleague mode, the relationship inverted. The AI got more useful. I got sharper, not duller.

Here's what that actually looks like in practice.

The session

The setup matters: a real production system, not a toy. Single-node Kubernetes cluster on a VPS, running half a dozen apps for several different products — landing pages, backends, an ERP, a SIEM, full observability stack. GitOps via ArgoCD, ansible-pull for OS-level self-healing, sealed secrets, the works. The kind of environment where a thoughtless change can take down a customer-facing site.

In one afternoon, working in colleague mode, we shipped:

• A self-hosted S3-compatible object store with TLS, sealed credentials, and per-bucket access policies.

• Monitoring scrape jobs and a Grafana dashboard for it.

• Public APK distribution for two Android apps, with scannable QR codes wired into a Next.js landing page.

• A security hardening pass that closed an information-disclosure endpoint.

• Documentation updates across five files reflecting all of the above.

I could have done that solo. Not in one sitting. And honestly not without skipping a few quality bars — I'd have shipped without docs, or skipped the security probe, or used the easy-but-bad bucket policy.

Three moments inside that session made the difference click.

It pushes back, when I let it

Late in the session I needed to lock down a Prometheus metrics endpoint I'd accidentally exposed publicly through the ingress. The AI proposed adding token-based authentication on the storage side — JWT, sealed-secret for the token, env-var inject into the scraper.

It would have worked. It was also overkill. I asked: "Why is that better than keeping the scraping internal to the cluster?"

Pause. Then: agreement, plus the explanation of why I was right. The actual security boundary was the cluster perimeter, not a second auth layer on a public endpoint. Adding JWT was solving a problem that shouldn't exist — the public exposure was the bug, not the missing auth. Five minutes later we'd shipped the cleaner solution: a path-rewrite rule at the ingress that drops public requests for the metrics path, while in-cluster scrapes keep working untouched.

That moment doesn't happen if I rubber-stamp the first proposal. The AI was perfectly happy to ship the wrong thing if I let it. The colleague dynamic only works because I don't defer.

It admits a mistake — but only when I ask

Hours later, after the dust had settled, I asked the question every operator should ask after any infra change: "I hope you didn't expose anything that represents a security risk?"

It didn't reassure me. It went and probed the infrastructure from outside — actual curl commands, actual external port scans — and came back with a finding: the public metrics endpoint described above was introduced by an env var it had set earlier in the session and missed. It hadn't connected the dots between the deployment config and the public ingress until I forced the audit.

It told me. Proposed two specific fixes. Explained the trade-offs honestly.

If I'd stayed quiet, that bug would still be live. The AI didn't proactively flag it. But asked directly, it didn't pretend everything was fine either. The lesson isn't that AI is sneaky — it's that asking the right question at the right time is half the job, and probably the half a human is best at.

It pivots cleanly when its first attempt is bad

I asked it to install an integration tool — a community library that looked active and well-rated. It hooked it up. Tested.

Half the operations didn't work — a serialization bug broke the listing tools regardless of input. Other operations returned 403s for reasons it couldn't fully diagnose. Bypassing one layer fixed those but broke a different layer.

It didn't pretend the situation was fine. It said: here's exactly what works, here's exactly what doesn't, here's why, here are three options for moving forward. I picked one — switch to a different implementation. We pivoted in ten minutes.

A worse version of this session would have been the AI silently working around the broken library, hiding the bugs in workarounds, and presenting a "shipped" outcome that was actually fragile. A worse colleague would have done the same. The honest mode is more useful, even when the honest answer is "this isn't working, abandon it."

What colleague mode actually means

Stripping out the analogy, here's what's specific about the working pattern:

• You set intent and constraints; the AI proposes execution. Not "what should I do," but "I want X, here's the constraint envelope, propose."

• You critique the proposal before it executes. Especially the architecture decisions. The AI is fast at producing solutions, slower at recognizing which one matches your actual values.

• You ask the audit questions out loud. "Did this introduce risk? What are the loose ends? What would you do differently?" The AI will answer honestly; it doesn't always volunteer.

• You let it pivot. When something isn't working, don't sunk-cost. The AI will keep trying to make a bad approach work if you let it. Calling time on a path is a human responsibility.

• You verify what matters before declaring done. Run the curl. Watch the metric. Read the diff. The AI's "I shipped X" is its summary of intent, not always evidence of outcome.

None of this is novel — it's how you work with a smart junior engineer who happens to be very fast. The novelty is just that this junior engineer doesn't get tired and is available whenever you are.

What I had to give up

The assumption I had to drop is the one most people are stuck on: that "using AI" means "abdicating thinking." The pattern that works isn't prompt → answer. It's intent → proposal → critique → revise → verify → ship. The AI is genuinely fast at proposing and revising. I'm slow at critique and verification, but only my critique and verification decide what's actually right.

Working this way is more demanding than coding alone, not less. It requires me to be clearer about what I want, faster at noticing flawed proposals, more disciplined about asking audit questions. It also produces better software faster than I could alone.

Lazy is a stance, not a tool. The tool can support either stance.

Pick the one that makes you sharper.