AI in Software Engineering: A Workflow You Can Review

AI in software engineering means using an assistant to help with requirements, implementation, testing, and review while people remain responsible for what ships. A useful workflow produces small changes and evidence you can inspect, rather than treating a convincing explanation as proof that the software works.

Tools like fenbs keep project context and human decisions outside the coding conversation, so another assistant can continue from the same agreed requirements. Start with a bounded task: a broken search filter, an unclear error message, or a missing test. You can judge the result more clearly when the starting problem is specific.

Where does AI help across the engineering process?

An assistant can propose an implementation plan, explain unfamiliar code, suggest edge cases, or draft a change. Those are different jobs, and success in one does not establish success in another. An accurate explanation of a function does not prove that a proposed replacement preserves its behavior.

GitHub documents that Copilot code review can miss problems and produce false positives, and advises human review and testing of generated suggestions. That makes it an additional source of feedback, rather than a release authority. See GitHub’s responsible-use guidance↗ (opens in a new tab) for the product’s stated limitations.

What context should you provide before asking for code?

Provide the user-visible problem, the expected outcome, the relevant code, and the rules that constrain a solution. Include the exact error or a reproducible example when you have one. Ask the assistant to identify missing information before choosing an approach that depends on it.

• Goal: what a person should be able to do after the change.
• Current behavior: what happens now, with an example input and result.
• Boundaries: files or systems the task may change and actions that need approval.
• Project rules: supported platforms, permission requirements, and compatibility expectations.
• Verification: how someone can observe that the requirement is satisfied.

For example, a search filter task might require archived records to stay excluded and access restrictions to remain enforced on the server. Those conditions belong in the task before implementation. Otherwise, an assistant may improve the visible search result while breaking an important rule elsewhere.

The guide to context engineering for AI assistants explains how to select useful input without burying the task in unrelated material. Keep the approved constraints in fenbs project context, so the next session can read them too.

How do you turn a request into a controlled change?

Use a sequence that lets you inspect the reasoning before the change becomes large. For a new codebase, begin with a read-only pass: ask where the behavior lives, which tests already cover it, and what nearby code depends on it. Confirm those locations against the repository.

1. Write acceptance examples. Describe a normal case, an invalid input, and a case the change must preserve.
2. Ask for a short plan. Resolve questions about data, access, or scope before implementation.
3. Make one bounded change. Inspect the changed files and remove unrelated edits.
4. Run the relevant checks. Record commands, results, and anything that could not be exercised.
5. Review against the examples. Approve the change only after the remaining uncertainty is acceptable.

Say a team needs a clearer message when a document upload fails. Changing the message, adding a targeted behavior check, and confirming the screen is a reasonable unit of work. Replacing the upload service at the same time makes it harder to know which change caused a regression.

Set approval boundaries before granting an assistant write access or command execution. The AI approval workflow covers that separate question in detail; your engineering task should name the particular actions that require a person’s decision.

How do you check generated code and tests?

Read the change as if a colleague submitted it. Check whether it implements the requirement, handles invalid input, respects existing access rules, and introduces a dependency or behavior you did not request. A small change makes that review practical.

Review tests separately from the implementation. A test that repeats the new code’s assumptions may pass while the requirement remains broken. For a bug fix, establish that the test or reproduction exposes the original problem, then confirm the change addresses it.

Choose checks that match the risk. A wording change may need a screen inspection; a permission change needs attempts by allowed and refused users; a data conversion needs representative inputs and a recovery plan. Ask the assistant to distinguish checks it ran from checks it merely recommends.

Security work belongs throughout development. NIST’s Secure Software Development Framework↗ (opens in a new tab) describes practices that can be integrated into a development process. Using an assistant does not replace your existing security review, dependency checks, or release requirements.

What should survive when the assistant or engineer changes?

Save the outcome, the evidence, and the next action. “Implemented, but not checked on a phone” is actionable. “Finished” loses the most important qualification. Include the relevant change reference and explain whether a blocked check needs access, a device, or a person’s decision.

Keep human choices distinct from assistant proposals. If the team chooses to preserve an older file format, record the choice and its reason. A later assistant should not silently remove compatibility because it prefers a simpler implementation.

Record continuing instructions in fenbs Decisions and rules. People make the decisions; assistants can record them and read them before starting work.

How to do this with fenbs

1. Create a free account, free for one person with no credit card, and add a project for the software you are changing.
2. Add one task with the current problem, acceptance examples, implementation plan, and verification approach.
3. Record the decisions a person has made and any rules that must continue to apply. Leave unresolved choices open.
4. Connect a supported coding assistant using the integration guides, and ask it to read project context before editing.
5. Save task progress, checks performed, and Where we left off before stopping. Ask the next assistant to explain the next action from that record.

fenbs is not the right fit for compiling code, running a test suite, or hosting your repository. Keep those jobs in your development tools; use the shared work record when requirements and progress need to survive across people and assistants.

How can you tell whether the workflow is helping?

Review a few completed tasks. Did someone need less time to reconstruct the requirement? Were the changes understandable? Did the recorded checks match what actually ran? Track review corrections and escaped defects alongside speed, so faster drafting does not hide slower cleanup.

Use your normal workflow for iterative work to keep tasks small. For a different discipline, the AI research workflow covers source gathering; this engineering workflow stays focused on changing and verifying software. More practical guides are in AI at work.