AI-Assisted Software Development

This document records how I currently work as a software engineer. It is a practical account of how I handle requirements, design, implementation, quality checks, and operational support in real projects, rather than a general methodology.

1. Understanding Requirements Before Implementation

My upstream collaborators usually include product and design teams. Product provides a PRD, design provides mockups, and those are typically the inputs I receive.

Before coding, I work through a design phase to clarify the boundaries of the change. I focus on:

• Data models
• API and protocol boundaries
• The affected systems and workflows
• The core design
• Money and account flows in payment scenarios
• Stability during rollout

Once interfaces and database boundaries are set, many implementation details can change without much disruption. If those boundaries are unclear, even a polished implementation may require rework.

I therefore use multiple AI conversations to examine ambiguities and align my understanding. When a PRD is unclear, I try to surface that early. The goal is not just to produce a technical design: this process helps me understand the requirement myself.

2. Different Skills for Development

During implementation I separate my reusable AI instructions, or skills, by purpose.

2.1 Figma and Interface Work

A design mockup is not the same thing as a frontend implementation. Page types, viewport sizes, and information density require different approaches. I keep refining a Figma-related skill as I encounter new page types, adding what I learn after each implementation.

2.2 Frontend, Backend, and Storage

Frontend development, backend development, and storage design are the three core areas where I use these skills most often. I follow several rules:

1. Keep the impact of a change small instead of making an unnecessary broad refactor.
2. Match the repository's existing code style.
3. If the repository has no relevant example, look for a similar pattern in a related repository.
4. Add more standardized frontend, backend, or data-model guidance only within those constraints.

I use AI as a constrained engineering assistant. The aim is code that fits the existing system and behaves reliably, rather than code that merely looks novel.

3. Supporting Skills During Development

I also maintain skills for supporting tasks: development platforms, reading different storage systems, observing clusters and individual hosts, and other automation.

When a task is worth automating, I try to make the procedure reusable. The same capability can later help with verification, troubleshooting, and operations.

4. Quality Checks

I deliberately separate my understanding of the requirement from verification of the implementation.

4.1 Generating Test Cases

I generate a case list from the PRD without asking AI to refer to my technical design or code. A misunderstanding in the design could otherwise propagate into the tests, creating a closed loop that confirms the same mistake. Returning to the PRD gives the checks a more independent basis for deciding whether the requirement was met.