support@technetguy.site Remote IT Services · Worldwide · Get a Quote →
AI-Assisted Engineering

What AI Can Actually Do Here

Not a chatbot that answers questions about infrastructure. A system that reads logs, forms a hypothesis, and is careful about what it changes.

This page is not hypothetical

Every case study in this engineering log — the home lab observability stack, the cloud fleet's Ansible playbooks, the business app's finance module, the VPN rollout — was built working with an AI coding agent doing real, hands-on work: reading actual logs, running real commands over SSH, editing real config files, and testing the result against real (disposable) data before calling anything done.

The hardening pass that secured this exact website is the cleanest example: before any fix was applied, the agent pulled nginx access logs, SSH auth logs, and application logs to find out who was actually using what, read exposed config files to check whether real secrets were at risk, and only then decided what to change — and how to change it without breaking a workflow a real person depends on.

The judgment calls that actually matter

01

Verify current state, don't trust memory

Infrastructure moves — hosts get replaced, services get migrated. A written record of "how it worked last time" is a starting hypothesis, not a fact, until it's checked against what's actually running right now.

02

Root-cause before you patch

A symptom fixed without understanding its cause tends to come back, or breaks something else. Read the logs first. Form a hypothesis. Confirm it. Then fix it.

03

Back up before you touch anything live

Every production change gets a reversible checkpoint first — config files, databases, whole directories — pulled to somewhere outside the box being changed, before the first edit happens.

04

Test against disposable data, verify back to baseline

Real systems get tested with clearly-marked throwaway records, and every round ends by confirming the system is back to its exact starting state, not just "looks fine."

05

Know the limits of automated testing

Calling backend functions directly isn't the same as a real user clicking through a browser. Some bugs only exist at that boundary — that's exactly where they hid, twice, until real interaction testing was made the standard.

06

Scope discipline, not one agent doing everything

Different domains — home lab infra, a specific web app, a specific employer's network — get handled by clearly-scoped, separate work, instead of one system with blurry boundaries touching everything.

What this is not

This isn't "AI replaces engineering judgment." Every decision on this page — what to fix, what to leave alone, what to flag rather than silently change, what credentials need rotating versus what's already fine — still gets made deliberately, with a human in the loop for anything that touches money, other people's accounts, or an irreversible action.

What changes is the leverage: a multi-hour investigation across a dozen log files, several config edits, and a full functional test pass, done carefully and in one sitting, instead of spread across a week of context-switching. The discipline is still the engineer's. The agent just does more of the legwork, faster, without skipping the parts that matter.