How should an AI review whether your project is doing well?
A useful AI review reads signals that are already recorded somewhere — traffic patterns, code errors, copy tells, calendar gaps — counts what it can count, names what it could not reach, and ends every finding with a concrete next move. Anything else is a confident-sounding opinion dressed up as analysis.
What is the difference between a signal and an opinion?
A signal is something that was recorded before the review began: a bounce rate logged by an analytics tool, an em-dash in a headline, a dependency with a known vulnerability, a meeting that was scheduled but never held. The AI did not create it; it found it. An opinion is a judgement the model generates from patterns in its training data — 'this copy feels weak', 'this colour scheme seems dated'. Both have a place, but they must not be mixed without a label.
The practical test is simple: could a second reviewer, given the same inputs, arrive at the same finding independently? If yes, it is a signal. If the answer depends on which model you ask, it is an opinion. A good review keeps the two columns separate and tells you which is which.
- Signal
- A fact recorded in an existing artefact — a file, a log, a page — before the review began. Reproducible by any reviewer with the same access.
- Opinion
- A judgement generated by the model from training patterns. Useful as a prompt for investigation, not as a conclusion.
- Gap
- Something the review could not reach — a locked account, an unshared file, a metric the tool does not collect. Must be named, not silently skipped.
- Finding
- A signal or opinion that has been labelled as such and paired with a specific next move.
Which sources should a project review actually read?
The answer depends on what the project is, but a few categories apply almost universally. The public-facing surface — website, app, social profiles — can be read without special access and yields copy quality, design consistency, and technical hygiene. The operational record — email threads, calendar, task lists, commit history — requires access but reveals whether planned work is actually happening. Financial records show whether revenue and cost are moving in the same direction as stated goals.
A review that only reads the public surface will miss execution problems. A review that only reads internal records will miss how the project appears to the people it is trying to reach. Both lenses are needed, and the review should say clearly which ones it had.
| Source type | What it can reveal | What it cannot reveal |
|---|---|---|
| Public website / app | Copy tells, design consistency, SEO signals, broken links | Whether the team is actually executing, internal costs |
| Commit / deploy history | Pace of change, error patterns, dependency age | Whether the right things are being built |
| Calendar and task records | Gap between planned and completed work | Quality of the work that was done |
| Financial records | Revenue and cost direction, runway | Market perception, brand strength |
| Analytics and logs | Traffic sources, error rates, drop-off points | Why users behave as they do |
Why must a review never borrow marks from a site that is not yours?
Some review tools check a website and then compare it against a benchmark drawn from other sites — sites the operator does not own, did not build, and cannot change. The score that comes back is partly a function of who your neighbours happen to be. If the benchmark pool shifts, your score shifts, even though nothing about your project changed.
There is a subtler problem too. A site that ranks well in a benchmark pool may have achieved that by optimising for the benchmark rather than for the people it serves. Borrowing those marks imports the distortion. A sound review scores only what is measurable on the project itself, states the method used, and leaves the comparison to the operator — who knows their own context better than any benchmark pool does.
What should every finding end with?
A finding without a next move is a complaint. 'Your copy contains filler marketing verbs' is a complaint. 'Your copy contains filler marketing verbs — here is the paragraph, here is a rewrite without them, here is how to check for more' is a finding. The difference is not cosmetic; it determines whether the review produces work or merely produces anxiety.
The next move should be specific enough that someone could start it today. 'Improve your SEO' is not specific. 'Add a meta description to the three pages listed below, each under 160 characters, describing what the page actually contains' is specific. If the AI cannot produce a specific next move, it should say so and explain what additional information would make one possible.
GROX applies this principle in its site check: the measurable tells of AI-generated design — em-dashes in copy, filler marketing verbs, placeholder names, stock purple gradients — are counted as facts alongside SEO checks, and each finding points toward a concrete edit rather than a general impression.
Common questions
Can an AI give a reliable project review without access to private data?
It can give a partial one. A review limited to public sources — the website, public repositories, social profiles — will surface copy quality, technical hygiene, and brand consistency. It will miss execution gaps, financial health, and internal workflow problems. A reliable review names which sources it had access to and which it did not, so the operator knows exactly how much weight to place on the result.
How should a review handle things it could not measure?
It should name them explicitly rather than skip them. A gap is not a failure of the project; it is a limit of the review's access. Naming it tells the operator where to look next and prevents the false impression that a clean score means everything is fine. A review that silently omits what it could not reach is more dangerous than one that scores nothing at all.
Is it a problem if the AI uses opinion alongside counted signals?
Not if the two are clearly labelled. Opinions generated from model training can be useful prompts — they may point toward something worth measuring. The problem arises when an opinion is presented as a finding without that label. A reader who cannot tell the difference between 'the model thinks this copy is weak' and 'this copy contains the following counted patterns' cannot act on either one sensibly.
How often should a project run an AI review?
Often enough that the findings remain actionable before the next review begins. A review that produces more next moves than the team can complete before the following cycle is a planning problem, not a review problem. For most small projects, a rhythm tied to a natural milestone — a launch, a sprint end, a monthly close — works better than a fixed calendar interval imposed from outside.
GROX's site check counts the measurable tells of AI-generated design and SEO gaps as facts, not opinions — see what it finds on your project.