AI changes the cost of producing a draft. It does not remove the work of deciding whether that draft solves the right problem. A team can generate more code and still wait longer for review, miss an important error state or ship a slower page. The useful question is what happens between the first suggestion and an accepted, maintainable change.
Our approach is to use assistance where its output can be inspected, keep changes small and make the release evidence visible. That gives a project something more useful than a promise of a multiplier: a way to see where time is being saved, where it is being spent and whether the result is getting better.
Give AI a task with a checkable answer
Routine scaffolding, transformations between familiar data shapes and suggestions for test cases are reasonable starting points. The engineer supplies the constraints and checks the result. A request to design an entire product leaves too many decisions implicit; a request to draft a validator for a documented input has a boundary that somebody can evaluate.
| Task | Useful AI assistance | Engineering check |
|---|---|---|
| Routine implementation | Draft a small function or component from clear requirements. | Check behaviour, types, failure paths and the existing architecture. |
| Test planning | Suggest edge cases and candidate test data. | Confirm the expected results independently and cover the important risks. |
| Understanding unfamiliar code | Summarise a module or explain a pattern. | Read the source and follow its callers before making a decision. |
| Documentation | Draft a description from an already reviewed change. | Match it to the implementation and remove unsupported claims. |
The limits are practical. GitHub’s responsible-use guidance explains that generated suggestions can be incorrect or insecure and need review and testing. A plausible implementation is therefore input to an engineering process, rather than evidence that the work is complete.
Agree the boundaries before using the tool
At kickoff, establish which tools are allowed, what information may be shared and who reviews assisted work. Tool configuration, organisational policy and project sensitivity can change the answer. Use synthetic examples when real customer records are unnecessary, and do not paste credentials into a prompt. Where approval is absent, keep the task within the information already permitted for that tool.
This agreement should be specific enough that an engineer can use it without guessing. “We use AI responsibly” leaves every decision unresolved. An allowed tool, an allowed category of input, a named reviewer and an ordinary acceptance process are a much clearer starting point.
Reduce waiting as well as typing
A change spends time in several places: implementation, waiting for a decision, waiting for review, checking and rework. Faster drafting only affects one of them. If a large pull request waits three days for someone who can understand it, producing that request sooner has not solved the bottleneck.
01
Define one observable outcome
Write down the behaviour to change and the evidence that would demonstrate it. Identify the important error and empty states before implementation.
02
Build a small increment
Keep the change coherent enough for a reviewer to understand in one sitting. Use assistance for bounded tasks within that increment.
03
Review and check the result
An engineer reads the change, runs relevant tests and exercises the affected journey. Resolve uncertain assumptions with the product owner.
04
Demonstrate and record
Show the running result, record what was checked and make any remaining limitation visible before moving on.
Track the time from a ready task to an accepted change, the time waiting for review and the amount of rework. Compare similar work against the project’s own baseline. These measures are more useful than counting generated lines. Our engagement process describes the checkpoints and handover artefacts that make those decisions visible.
Make quality evidence independent of the draft
A test that repeats the implementation’s assumption can pass while the product is wrong. Start with the requirement and user journey, then choose the right level of check. A generated test is still a draft: somebody needs to verify the expected result, data setup and failure it is meant to catch.
- Use type checks, linting and a production build to catch structural mistakes early.
- Use focused unit or integration tests for rules and boundaries that should behave deterministically.
- Exercise critical browser journeys, including rejected input, unavailable data and recovery after an error.
- Review keyboard use, labels and focus behaviour alongside the visual result.
- Inspect authorisation, secret handling and dependency changes when the work touches those boundaries.
The balance depends on the change. A colour adjustment needs a visual check; a permissions change needs evidence across roles. Manual and exploratory QA supplies judgement about behaviour, while test automation keeps repeatable checks available for later changes. Neither should be expanded simply to create a larger number.
A release record should say what was checked, what remains uncertain and who accepted the result. That is useful whether the implementation was written by hand or drafted with AI.
Measure the speed your users experience
Delivery speed and page speed answer different questions. A rapid release can still send a large script to a phone on a weak connection. Start performance work with representative journeys and an agreed baseline; otherwise a score on one developer’s machine can become a substitute for the customer’s experience.
The Core Web Vitals guidance on web.dev distinguishes loading performance with Largest Contentful Paint, responsiveness with Interaction to Next Paint and visual stability with Cumulative Layout Shift. Use those signals alongside checks of the actual tasks visitors need to complete. Lab testing helps diagnose a change; field data, when available, shows what people experience.
For a marketing website, useful engineering choices often include rendering important content on the server, giving images explicit dimensions, loading decorative assets appropriately and avoiding scripts that do not support a user need. Motion should add feedback without hiding the heading or delaying an enquiry. Test the finished page at narrow widths, with keyboard input and with reduced motion enabled.
Leave the team with something it can own
The final check is whether another engineer can understand the work. Keep decisions near the code or in a short design note, explain unusual dependencies and leave tests that communicate the expected behaviour. Include instructions for running the product and a list of known limitations. The next person should not need the original prompt history to maintain the system.
If you are comparing delivery partners, ask to see how a change is reviewed and accepted, rather than how many AI tools they use. For a new build or an existing product, our web development service connects implementation with performance, testing and a usable handover. The outcome to aim for is steady progress that your team can verify.
