What a Fractional CTO Really Thinks About Vibe Coding, AI Prototyping, and the Future of Software

Jason Margolin wanted to build a website when he was thirteen, which in those days meant buying a book from WHSmith and teaching yourself HTML. That curiosity turned into a career: a local web agency in 2007, then agencies building systems for hedge funds and banks, then BP, then nearly a decade of applying to Meta before finally getting in as a technical program manager. He now works as a fractional CTO across a range of startups, including one putting AI on the phones at GP practices to end the 8am rush. In this episode he talks to Rob Woodhead about how far AI-assisted prototyping actually takes you, why a vibe-coded product is often harder to rebuild than to start again, why giving staff an AI tool rarely makes them more productive, and what it means to enter software engineering in a year when AI can do most of a junior’s technical work.

Key takeaways

• AI-assisted prototyping is genuinely valuable for de-risking an idea, and the output should be treated as disposable rather than as a foundation.
• A vibe-coded codebase is difficult to extend because nobody can explain why any decision was made, which is context a human team would have provided.
• Rebuilding from scratch is frequently faster than adapting generated code, because at least the building blocks go in correctly.
• Users cannot tell whether an app was vibe coded, so the security consequences land on people who never made the choice.
• Handing staff an AI tool without training rarely improves productivity, because people do not know what to ask it or connect it to.
• AI is a genuine multiplier for experienced engineers and a poor substitute for judgement in people who cannot evaluate the output.
• The value of an engineer is shifting towards architecture, systems context and business understanding, which the model cannot see.
• Long roadmaps are close to worthless when tooling changes monthly, so hold a single north-star metric and plan in short increments.
• Rebuilding an established SaaS product to avoid a small subscription usually produces something that looks similar and works considerably worse.

Episode chapters

• 00:57  Learning HTML at thirteen from a book
• 02:30  From a four-person agency to hedge fund clients in London
• 04:54  Why developers need soft skills, and how you actually get them
• 08:45  Ten years of applying to Meta
• 09:54  What a technical program manager does
• 12:21  Inside Meta: own tooling, time zones and town halls
• 14:50  Leaving corporate for fractional work
• 19:32  The process problems every early-stage business shares
• 20:39  Why giving staff AI tools does not make them productive
• 22:56  A bewildering market where tools disappear weekly
• 24:30  Building something you do not understand
• 25:04  The real-world risk of vibe-coded products
• 26:20  What to do if you already have a vibe-coded product
• 28:57  Why AI is a superpower only if you know what you are doing
• 30:03  Is it a bad time to become a software engineer?
• 31:38  How to plan when everything changes monthly
• 33:59  Model plateaus and the shift to agents
• 35:05  The tools he actually uses
• 36:23  Why you should not rebuild Monday.com in Lovable
• 40:40  AI on the phones at GP practices, and other client work

Where does vibe coding hit its limits?

At the point where the prototype has to become a product.

Jason is positive about the prototyping use case and unambiguous about the boundary: in his mind a vibe-coded build is a prototype, and a prototype is throwaway. If you are building a serious technology product, that is the moment to invest in someone who will get the building blocks in correctly, even if that person is using similar tools to do it.

The risk is not theoretical. He describes a case, widely reported, of an app popular with women that had been vibe coded and subsequently leaked highly personal user data. His point is about who carries the consequence. The users had no idea how the app was built. They downloaded something from an app store. The decision was made by a founder, and the cost landed on thousands of people who were never party to it.

His overall assessment is measured rather than alarmist. There is a lot of fear-mongering about these tools, and there is also real risk, because they are not yet mature enough to operate without human technical oversight.

What should you do if you already have a vibe-coded product?

Get someone technical to look at it before you do anything else.

Jason’s analogy is legal rather than technical: he would not have ChatGPT draft an employment contract, send it out and have someone sign it without a lawyer at least casting an eye over it. The same oversight applies to code, and for the same reason. The document may look entirely convincing and still be wrong in ways you are not equipped to notice.

Practically, he suggests finding a fractional CTO or technical advisor, searching those job titles on LinkedIn, approaching an agency offering this specifically, or asking an AI model for recommendations. What he advises against is blind trust in output nobody has reviewed.

Our Vibe Code Audit is exactly the check Jason describes: a look under the hood at security, structure and scalability before you build anything further on top. The Jekyll and Hyde of Vibe Coding covers the two distinct failure modes, and Nick Sales makes a similar argument about production-quality software in a separate episode.

Why is it hard to build on top of a vibe-coded prototype?

Because the context is missing, and context is most of what makes a codebase workable.

Jason describes the normal situation. You join a company as a developer, inherit a product, and there are people who can explain why the architecture is the way it is, what was tried before, and which decisions were deliberate. You understand the reasoning, then build on it.

With a million lines of generated code, that conversation is not available. You cannot ask why something was done that way, because nothing decided it. So modifying anything means working out the reasoning from scratch, and changes tend to surface bugs in unrelated parts of the system.

This is why his answer to make this work is often that he would rather rebuild it, knowing the foundations are right, than untangle what he calls a spaghetti mishmash.

Rob’s observation from running audits matches. Iterative prompting leaves enormous amounts of redundant code behind: a founder says move that button, or remove that function, and rather than the code being deleted the way an engineer would delete it, it simply stays. He also notes a side benefit of letting clients experiment for long enough. They start to feel how hard small changes are, which builds a useful intuition about why engineering takes time.

Why does giving staff AI tools rarely improve productivity?

Because a licence is not a capability.

Jason describes a pattern he keeps seeing: a company rolls out Copilot licences, a chatbot appears on everyone’s desktop, and then nothing much changes. People know mechanically how to use it, they type and press enter. What they do not know is what to ask, or what it could plausibly do for their particular job.

The second half of the problem is connection. The tool is not wired up to where the files live, or the email, or any real data source, so it cannot do the thing that would actually save time. Faced with that, people revert to reading every email themselves, and the efficiency gain never materialises.

Rob adds the other half of the picture. Adoption often starts as shadow usage, with individuals paying for their own tools because they have found something that works, and companies only later trying to formalise it. Both agree the diffusion is likely to be gradual and social, one person working something out and telling colleagues, much as spreadsheets spread.

Is it a bad time to start a career in software engineering?

Jason thinks it is a tricky time, and says so plainly rather than reassuring anyone.

His reasoning is that AI can now do most of the technical work that would traditionally have been given to a junior engineer, which raises an uncomfortable question about where the value sits.

His answer is that it moves upwards. What a model cannot see is the whole system: how services interact, what the business actually does, which tools are already in use, where there are quick wins or opportunities to consolidate. An engineer who understands all of that can direct the AI and evaluate what comes back. He characterises that as the current way of working, where a few years ago the same person would have written the code themselves.

The uncomfortable corollary is that someone who enjoys programming but cannot yet supply the architectural or business context is offering something the tools already cover. Rob makes the related point that experienced engineers are becoming dramatically faster while newer ones cannot yet judge whether generated code is any good.

Jason is emphatic about that asymmetry. For someone with experience, he describes AI as a genuine superpower that lets him take on more work than would otherwise be possible. For someone without it, the same tool produces output they cannot evaluate.

How should startups plan when the tools change every month?

In short increments, against one metric that does not move.

Jason is sceptical of long roadmaps, and his evidence is from the largest possible environment. At Meta they would build six-month roadmaps, and a month in, the remaining five would have changed entirely. If that happens there, it will happen at a startup using tools that are replaced weekly.

What he recommends instead is holding a clear business goal, a single north-star metric, and letting the route to it change. Trying many things is fine. Committing to a six-month sequence of them is not.

He also flags a specific risk that AI has made worse. Adding a feature is now nearly frictionless: you ask, and it appears. The question that gets skipped is at what cost. Every addition has trade-offs, and it is easy to end up with a product that has quietly become more complicated to use, one effortless feature at a time.

On the near future, he expects model capability to plateau somewhat, with incremental gains rather than a step change, partly because training data is running short. The shift he does expect is towards agents that go away, complete something and report back, rather than the current pattern of chatting and copying output out.

Should you rebuild a SaaS product to avoid the subscription?

Almost never, and Jason sees people try surprisingly often.

The pattern is a reluctance to pay twenty dollars a month for a tool, followed by an attempt to clone it. He mentions people asking Lovable to build them a Monday.com equivalent and expecting to run their task management on it.

His objection is not about the technology being incapable. It is that these companies are worth what they are worth because of the time and money invested in the product, most of which is invisible. A clone can look strikingly similar and simply not work as well, and the gap shows up in exactly the situations where you needed it to hold.

For what it is worth, his own stack is unremarkable and deliberately so: Cursor for building, Fathom for meeting notes, a ChatGPT subscription for email. He is clear he is a fairly typical AI user rather than someone running an elaborate agent setup, and that he avoids accumulating subscriptions.

About the guest

Jason Margolin is a technology leader with over fifteen years of experience scaling products and engineering teams across technology, finance and healthcare. He was previously a technical program manager at Meta, and before that led teams at BP. He now works as a fractional CTO and advisor across startups and scale-ups spanning AI, cloud and data strategy, including an AI product handling first-line phone triage for around a hundred UK GP practices, a Commonwealth scholarships non-profit, and an HR training tool built around a conversational video avatar. He can be found on LinkedIn and at xeweb.net.

About the host

Rob Woodhead is a co-founder of Old St Labs, a London-based software agency building web and mobile products for startups and innovators, with a delivery team in the Philippines. He also runs Tech Startups in the Pub, a monthly London gathering of founders.

Frequently asked questions

Is vibe coding safe for a real product?

Not without technical review. Jason Margolin treats vibe-coded output as a prototype to be discarded rather than a foundation. Serious products need someone experienced to establish the architecture, security and scalability properly before they go anywhere near users.

What should a non-technical founder do with a vibe-coded app?

Have someone technical review it before building further or launching. That means a fractional CTO, a technical advisor, or a dedicated code audit. The comparison is having a lawyer read a contract before you send it, even one that reads perfectly well.

Can you turn a Lovable prototype into a production app?

Sometimes, though rebuilding is often faster. Generated codebases carry no record of why decisions were made, so modifications are slow and tend to break unrelated parts of the system. Redundant code from iterative prompting compounds the problem.

Why is our AI tool not making the team more productive?

Usually because people were given access without training, and because the tool is not connected to their files, email or data. Knowing how to type into a chatbot is not the same as knowing what to ask it or what it could do for a specific role.

Is AI making junior developers obsolete?

It is making entry harder. Much of the work traditionally given to juniors can now be generated, so value shifts towards understanding architecture, systems and business context, then directing and reviewing the output rather than producing it.

‍