I use AI-assisted tools in my work, and their effect depends on the scope. They can help with familiar implementation and drafts, while product decisions, complex debugging and verification still need experienced attention. What follows is what I have observed, not a benchmark or a fixed delivery-time promise.
The useful question is which parts of a project suit this workflow, and which still need careful human judgment.
Where AI assistance can help
- Familiar implementation. When requirements and project conventions are clear, AI can help me draft routine forms, API clients, migrations and similar code. I still check that it fits the product.
- Reading unfamiliar code. AI-assisted tools can help me map a codebase and frame one question. A focused senior diagnosis covers one agreed question for one hour (€300); a full audit has a separate scope.
- Tests. AI can help draft test cases. I still decide which behavior matters and check that the tests cover it.
- First drafts. A draft gives me something to review, but it still needs editing, product context and validation.
- Working across stacks. AI can help me navigate backend or infrastructure code. Domain knowledge, system constraints and review still matter.
What still needs experienced judgment
- Deciding what to build. Models do not know your customers or constraints; product decisions still need evidence and judgment.
- Long-term architecture. A proposal can fit today’s task while making later changes harder. Experience and review help expose that trade-off.
- Hard-to-reproduce bugs. Models can suggest leads, but concurrency, memory or device-specific defects still need careful investigation and confirmation.
- Taste and product fit. A model can offer variations, but people decide whether an interaction and its language work for the product.
- Coordination. Drafts can move faster; agreement between people still takes communication.
How to review AI-generated app code before release
Use a small, reviewable change rather than accepting a whole feature in one pass. Write the expected user action, the data it may read or change, and one condition under which the change must stop. Then compare the patch with the existing architecture and the real behavior of the app.
- Scope and ownership. Identify changed screens, backend endpoints, data migrations and dependencies. Keep credentials on the server and enforce account access there; hiding a button is not authorization.
- Failure behavior. Check an expired session, missing permission, a failed request and a repeated tap. Verify that loading ends, useful errors appear and a retry does not create a second purchase, record or message.
- Evidence. Run checks that exercise the changed behavior, then inspect the relevant release build on its intended devices. A passing unit test does not establish that a permission prompt, keyboard or payment callback works in the shipped app.
- Recovery. Name the person who decides whether to release, what signal triggers rollback and how existing data remains usable if the feature is disabled.
Worked example: a generated change to a save button
Consider an illustrative profile editor, not a client result. The draft saves a profile and shows a success banner. Review it with a slow connection and two taps: there should be one intended update, a clear pending state and no premature success. Repeat after the session expires: the server should reject the write, the UI should explain how to sign in again, and the edited text should remain available where the product permits it. Record the tested build and observed result before approving the patch.
For inherited code, start with the technical due-diligence checklist. For the implementation and maintenance of an app, see Flutter development. For team workflows and review responsibilities, use the AI adoption service. These are different scopes; agree the deliverable before estimating the work.
Project conventions. Generated suggestions may not fit the architecture or patterns already in use. I check them against the codebase before they become part of it.
How juniors learn. I do not yet know whether this is a problem. I do know that understanding gained by getting stuck is not automatically replaced by a quick answer.
What this means for what you are buying
If a supplier says AI makes them 10× faster and therefore your project takes a tenth of the time, ask what work and evidence that estimate covers. It may describe a narrow task rather than the whole project.
In my experience, AI-assisted workflows can speed some implementation and drafting, while discovery, decisions and validation remain. How much changes depends on scope, the codebase, constraints and the verification required.
For companies in Catalonia, the 2026 ACCIÓ technology-exploration call closed on 21 September 2026. It offered 75% of eligible costs, up to €30,000. I keep the grants guide current from official agency publications; a future call is listed only after ACCIÓ publishes it. The 2026 call reference remains historical.
The question to ask a supplier
Not "do you use AI?" Everyone will say yes.
Ask: "how do you verify what it produces?" The answer tells you whether you're buying compressed delivery or compressed diligence. One of those is worth paying for.
And if you're inheriting a codebase built this way, the audit checklist matters more than it used to, not less.