AI writes code. You keep the responsibility.
Generated code often looks finished. Quality arrives only through understandable changes, independent checks, and someone who can justify taking the change.
Read the German original
A plausible suggestion is not yet a solution
AI can help with drafting, explaining, and revising code — often surprisingly fast. A suggestion that looks plausible still does not answer whether the solution fits the application. That needs knowledge of the workflow, existing interfaces, and the people who will use or later change the result.
GitHub’s documentation on Copilot Chat notes that generated code can be incorrect and may contain security issues. Checking and testing therefore remain development tasks. For us that yields a simple rule: every change needs a person who understands its effect and can justify taking it. Speed without that person is only deferred work.
Phrase the brief so you can check it
Take a contact form: a clear brief describes which fields are required, how invalid input is handled, and which confirmation should appear after submit. It also states the change boundaries. A new form check should not quietly rebuild all of user management — however tempting the suggestion sounds.
Small, self-contained changes make review easier. Give the tool the project rules that apply, fitting examples, and the files actually needed. Ask for the purpose of any new dependency. Extra code means extra decisions about maintenance, updates, and operations. A useful review therefore also asks which parts already exist. Proven building blocks can shrink the change and later upkeep.
Check behaviour in context
Review is about real effect. What happens on a slow connection, a double click, or an expired session? Does input survive if submit fails? And does the visible confirmation match what the system actually did? Those questions connect technology with trust — the only capital an application keeps long term.
Google’s published review practice looks at design, function, complexity, and documentation among other things. We treat that whole-system view as essential with AI support too. An extra automated review can add hints. Its approval does not replace checking the business expectations.
Tests need their own expectations
If a tool generates implementation and tests from the same unclear assumption, both can politely confirm the same mistake. Expected results should therefore come from the requirements — not from the generated code. For the contact form, an important test might prove that a failed submission never triggers a success message and that entered content remains.
Choose checks by the change and its possible consequences. A test should fail on a relevant error and show clearly why. Surfaces also need a look in the browser: readability, keyboard use, and error messages can only be judged from source code to a limited extent.
Hand over the change so others can continue
A usable handoff describes the reason, the new behaviour, and the checks performed. Open limits belong there too. Anyone investigating a later bug must be able to reconstruct which decision was made. Clear names and a short explanation matter more than a long list of generated files.
Our measure for AI support is therefore the quality of the reviewed result: the application serves its purpose, the change can be explained, and further work stays possible. The volume of generated code barely helps that judgement — it only impresses briefly.
What does this look like in your work?
We can turn the idea into a sensible next step with you.
Software & web development