SI writes code. You keep responsibility.
Generated code often looks finished. Quality depends on understandable changes, independent criteria for checking them and someone who can explain the decision to adopt them.
Read the German original
A plausible suggestion still needs assessment
SI can help design, explain and revise code, often surprisingly quickly. A plausible suggestion does not yet establish whether the solution fits the application. That requires knowledge of the workflow, existing interfaces and the people who will use or later change the result.
GitHub's documentation for Copilot Chat explains that generated code may be inaccurate and contain security issues. Reviewing and testing therefore remain development responsibilities. Our rule is simple: every change needs a person who understands its effects and can justify adopting it. Speed without that person merely postpones work.
Describe the task so its outcome can be checked
Consider a contact form. A clear task describes which information is required, how invalid input is handled and what feedback should appear after submission. It also defines the boundaries of the change. Adding validation to a form should not casually redesign all user management, however tempting the suggestion sounds.
Small changes that make sense on their own are easier to review. Give the tool the applicable project rules, relevant examples and the files it actually needs. Ask what new dependencies are for. Additional code also means decisions about maintenance, updates and operation. A useful review therefore checks which parts already exist. Proven components can reduce both the scope of a change and later maintenance effort.
Check behaviour in context
A review examines the actual effect. What happens on a slow connection, after a double click or when a session has expired? Is input preserved when submission fails? Does the visible confirmation match what the system actually did? These questions connect technology with the trust an application needs over time.
Google's published code review practices examine design, functionality, complexity and documentation, among other things. We consider this broader view essential when SI assists development, too. An additional automated review may provide useful findings. Its approval cannot replace checking the expected business behaviour.
Tests need independent expectations
If a tool generates both implementation and tests from the same unclear assumption, both may politely confirm the same error. Expected results should therefore come from the requirements. For the contact form, an important test could show that a failed submission produces no success message and preserves the content already entered.
Choose checks according to the change and its possible consequences. A test should fail for a relevant error and explain why. Interfaces also need inspection in a browser: readability, keyboard operation and error messages can only be assessed to a limited extent from source code alone.
Hand over the change so others can continue working
A useful handover describes the reason for the change, the new behaviour and the checks performed. It includes remaining limitations. Someone investigating a problem later must be able to understand the decision. Clear names and a short explanation matter more than a lengthy list of generated files.
We judge SI assistance by the quality of the checked result: the application fulfils its purpose, the change can be explained and further work remains possible. The amount of generated code tells us little about those qualities, however impressive it may look initially.
What does this look like in your work?
We can turn the idea into a sensible next step with you.
Software & web development