Source: https://mayphus.org/ai-assisted-systems-engineering/ Title: From hands-on operations to AI-assisted systems engineering Metadata: {"date":"2026-10-09","kind":"article","language":"en","locale":"en","route":"/ai-assisted-systems-engineering/","slug":"ai-assisted-systems-engineering","tags":["ai","systems-engineering","learning"],"type":"article"} # From hands-on operations to AI-assisted systems engineering I used to spend more of my time writing commands, working directly in Linux, and searching for technical answers. I now give more of that execution work to AI. That changes the skill I need to develop: describing a problem clearly, directing the work, understanding the result, and knowing when it is safe to use. **AI-assisted systems engineering** is a useful name for this direction. Here, it describes an ability I am developing: combining technical judgment with AI-assisted execution. It is a working description, rather than a claim to a new professional title. ## The experience I bring My earlier work gives this learning a practical foundation: - I delivered blockchain systems across cloud and on-premises environments, covering infrastructure planning and cost estimates, operating systems, networking, node synchronization, backend deployment, and Nginx. - I maintained physical servers, KVM virtual machines, and networks connecting multiple offices. - At Dahua, I diagnosed cameras and recorders, used UART and U-Boot, and recovered a camera through selective firmware reflashing without removing its flash chip. Other repairs included replacing BGA components. - In CI/CD support, I traced failures across delivery stages and read relevant implementation code to understand behavior. This was support and troubleshooting work on an existing platform. These experiences predate my current AI-assisted workflow. They are evidence of hands-on delivery and diagnosis. My personal publishing infrastructure and AI-assisted website work provide a current setting for applying those habits. My [profile](https://mayphus.org/profile/) records the background; [How I work with AI](https://mayphus.org/ai-workflow/) describes the workflow's development. ## Six abilities to develop ### 1. Frame the problem Define the observed failure, the desired behavior, the constraints, and the evidence that would count as success. “Fix the website” leaves too much open. “Restore this route, preserve its content, and verify the public response” creates a bounded task. ### 2. Keep a cross-layer model Trace the path through the system: client, network, proxy, process, application, and data. For an embedded device, follow power, bootloader, firmware, storage, network, and function. A healthy component does not establish that the whole path works. ### 3. Decompose and delegate Separate investigation from changes. Give AI a specific outcome, relevant context, and permission boundaries. Identify which files it may edit and which actions need approval. Independent checks can run in parallel; changes to shared state need coordination. ### 4. Test claims against evidence Read the actual output. Compare behavior before and after the change. Include a test that should fail, so the check demonstrates that it can detect the problem. An AI explanation is a hypothesis until observations support it. ### 5. Handle uncertainty and risk Distinguish what is observed, what is inferred, and what remains unknown. Prefer a small, reversible experiment. Stop when evidence conflicts, permissions are unclear, or the next step could expose private information or damage a working system. ### 6. Preserve recovery and understanding Record the starting state, the change, verification results, and recovery steps. Be able to explain the failed boundary and why the repair fits the evidence. If I cannot explain that connection, there is more to learn before relying on the result. ## Worked example: a local service returns 502 This is a hypothetical sandbox exercise, not a reported production incident. A local reverse proxy returns 502. AI suggests restarting the database. Before accepting that suggestion, collect evidence: 1. The proxy error log reports a refused connection to port 8000. 2. The application is listening on port 8001, where the same test request succeeds. 3. The proxy configuration points to port 8000. These observations support an upstream-port mismatch as the immediate failing boundary. They do not establish that every application feature or database operation is healthy. In this deliberately misconfigured sandbox, save the original configuration, change only the upstream port, validate the configuration, and repeat the request through the proxy. Then test an application operation that uses its mock data dependency. Record the configuration difference and results. A successful direct request and a successful end-to-end request answer different questions. ## Suggested practice These exercises are a proposed learning plan, not completed work. Use disposable local fixtures, synthetic data, and no production credentials. 1. **Diagnose one broken path.** Reproduce the proxy example. Ask AI for competing explanations before allowing edits. Keep a path sketch, observations, one minimal change, and before-and-after results. 2. **Check the checker.** Give AI a small mock API with a documented response contract. Review its tests, deliberately break one required field, and confirm a test fails. Restore it and retain both results. 3. **Rehearse recovery.** In a throwaway repository, make a small configuration change, verify it, and restore the starting version. Keep the diff and evidence that the restored behavior matches the baseline. ## A learning checklist - Can I state the problem without repeating the AI's diagnosis? - Can I trace the relevant path and locate the evidence? - Can I explain what each test proves and leaves untested? - Can I identify an unsafe or unsupported suggestion? - Can I recover the starting state? - Can I solve a slightly different version using what I learned? Progress means increasingly being able to answer these questions with evidence from actual work.