Vibe coding vs AI-assisted engineering

If you can build a working app with AI, a team that also uses AI should be able to explain what you would be paying them for: which work they take off your hands, and how you will know they did it.

Vibe coding is enough for an experiment you can afford to throw away. An app your business relies on needs more: proof that its important rules hold, someone who can change it safely, and an agreed response when it fails. That is the work AI-assisted engineering should cover.

You can do that work yourself if you have the skills and the time. Hire when a supplier fills a specific gap, such as testing your business rules or supporting the app after launch. The words "AI-assisted engineering" on a proposal do not tell you whether they will.

TL;DR Use vibe coding for an experiment you can discard. When people rely on the app and you cannot judge its condition, pay for a focused assessment first. Fund delivery against agreed requirements, acceptance evidence, and support terms. Buy an existing product when one fits, and rebuild only when an assessment shows the current app cannot practically meet a requirement.

What is the difference between vibe coding and AI-assisted engineering?

Addy Osmani distinguishes accepting generated code without deep review from using AI within a disciplined development process.

That distinction describes how the work is done. It does not tell you whether a particular supplier is worth a higher fee. For that, ask what the fee includes: which decisions they make, what they demonstrate before you accept the work, and what they support afterward.

Take an invoice approval tool. "Upload, approve, and export invoices" describes the screens, but it leaves the business rules open. Who may approve an invoice? Can the person who submitted it also approve it? What happens to an approval if the amount changes?

An engineering proposal should list those questions and agree how each answer will be checked. Your business still sets the approval policy. A developer can explain the consequences of each option and build the one you choose, but cannot work out your policy from a feature list.

What should an engineering proposal include?

Compare proposals against the same requirements. A shorter feature list with clear acceptance evidence can cover more useful work than a longer list that ends at a demo.

What you are paying for	Evidence to agree before work starts
Scope judgment	Required behavior, exclusions, open business decisions, and simpler alternatives
Correct implementation	Demonstrations and tests tied to your business rules, including the important exceptions
Future changes	Code and account access, written instructions, and proof that another developer can make a small change from them
Delivery ownership	A named person responsible for the agreed work, with milestones and acceptance criteria
Ongoing support	Covered systems, hours, response commitments, exclusions, and how extra work is priced

For the invoice tool, ask the supplier to show what happens when someone edits an approved invoice. The expected result comes from your agreed policy. "All tests passed" means little if no test covers that case.

AI can also write tests and review code. GitHub's own guidance says Copilot code review should supplement human review, and that its feedback needs checking. A second AI pass is useful input, but it does not prove your requirements were met. Neither does a person who approves changes without checking them against those requirements.

You do not need to read the code to accept the work. You do need to see the agreed outcomes demonstrated. If your team cannot judge the technical work, hire an independent reviewer for a defined scope.

How much work should you fund next?

If the question is whether anyone wants the workflow, keep the experiment cheap enough to throw away. For the invoice tool, test the screens with made-up invoices and no connection to your accounting system. Do not let that experiment quietly become the finance team's only way of working.

If people already rely on the app but you cannot judge its condition, pay for a focused assessment before approving a large budget. Agree what it delivers: findings tied to your business requirements, what was inspected, what remains unknown, and priced options for the next phase. An automated scanner report covers only part of that.

If the assessment finds a limited gap, fund that gap. Perhaps approval rules are enforced on some screens but not others, while import and export already work. Ask for the checks a prototype needs before production as part of that work. An app being AI-generated is not, by itself, a reason to replace it.

A rebuild needs a stronger case: which requirement the current app cannot practically meet, why a smaller change will not fix it, and how existing data and users will move across. Include the cost of moving data and re-checking every requirement. A new codebase has to meet the same requirements as the old one.

What will it cost to build and run?

Compare the first delivery and the ongoing work separately, over the same period and with the same usage assumptions.

The first delivery can include scoping, building, testing, deployment, data migration, and your own team's time answering questions and reviewing results. If AI makes the building faster, that should show up as less time, a lower price, or more work included. Ask the supplier which.

Ongoing cost includes hosting, software subscriptions, outside services, support, and changes. An app built with AI does not necessarily call an AI model once it is running, so the AI coding tools used to build it are not part of its running bill.

A promise to "stay on after launch" needs written terms. Does it cover outages, changes forced by a vendor, and new features? During which hours? A promise to reply to a problem is different from a promise to fix it. Put the ones your business needs in the contract.

Count your own team's work too. If you build it yourself, who stops their normal job to investigate a failure? If you hire someone, who answers business questions and approves changes? Either way, someone inside your business still makes those decisions. If the app needs continuous changes, compare an internal team with an ongoing partner.

When should you pay for neither approach?

If an existing product meets your requirements, compare it before paying for custom work. For the invoice tool, try your approval policy, accounting integration, and exports in the candidate product. Count setup, subscription costs, and any limits that would force you to change how you work.

Custom software keeps costing money after launch, so it needs a requirement that an existing product cannot meet. Decide whether to build or buy before choosing who builds it. An experiment that clarified your requirements was still worth doing, even if you retire it and buy a product.

Before approving the next proposal, ask the supplier to finish this sentence in concrete terms: "At the end of this phase, you will be able to verify..." Then check that the price covers that evidence and the support you need.

Sources

• Addy Osmani: Vibe coding is not the same as AI-assisted engineering
• GitHub Docs: Application card: GitHub Copilot Agents
• GitHub Docs: Using GitHub Copilot code review