29 December 2025Implementation

Vibe Coding: Pragmatic Adoption for Professional Development

When I first heard about 'vibe coding' a few months ago, I was skeptical. The idea of letting AI write production code based on casual...

Executive Summary

Vibe coding really does speed teams up, but it has proven risks to security, technical debt and productivity. Using it professionally means picking the method that fits each use case.

56%

faster task completion with AI coding assistants versus traditional methods, per a Microsoft, GitHub and MIT controlled study

8x

increase in duplicate code blocks correlating with AI tool adoption, across 211M lines analysed by GitClear

-7.2%

delivery stability among teams using AI coding assistants, per Google’s 2024 DORA report

19%

slower completion for experienced developers using AI tools, while believing they were faster (a METR randomised controlled trial)

Core conclusions

  • The speed gains are real but uneven. Prototypes and internal tools gain the most. Live code and code where security matters need spec-driven discipline instead.
  • Unless security scans and code review are required, AI-written code picks up the security flaws in the code it was trained on. The C.L.E.A.R. review framework and automated SAST/DAST checks are non-negotiable.
  • Realistically, vibe coding takes three to six months to break even. Leaders should track the value delivered.

When I first heard about “vibe coding” a few months ago, I was skeptical. Letting AI write live code from casual prompts sounded like a recipe for disaster. But as someone running digital transformation work, I couldn’t ignore the buzz. So I dove into the research, tested it with my teams, and what I found surprised me.

Vibe coding means getting working code by giving plain-language prompts to large language models. It became one of the most divisive methods of 2025. Andrej Karpathy coined the term in February 2025, and it has sparked fierce debates among engineers. And both sides have valid points.

Vibe coding is a powerful tool that requires smart guardrails: treat the silver-bullet and disaster takes both as overstated. Here’s my take on how to use it responsibly, based on both the research and what I’ve seen in practice.

Understanding Vibe Coding

Here’s the key difference: traditional AI coding assistants (like GitHub Copilot) suggest code that you review and modify. With vibe coding, you accept AI-generated code with minimal inspection. Think of it as shifting from co-pilot to autopilot.

Your role changes from writing code to describing what you want. You tell the AI the outcome you need, and it handles the syntax, structure, and logic. Sometimes it works brilliantly. Sometimes… not so much.

This is a real break from how coding has been done. The developer focuses on outcomes (what the system must do) rather than how it is built. The AI reads the requirements, picks the frameworks, sets up what the code depends on, and produces working code, often within minutes.

Advantages

Velocity Improvements

A controlled study by researchers from Microsoft, GitHub and MIT found that developers using AI assistants finish tasks up to 56 per cent faster than those working the old way. Companies using it report coding cycles 40–60 per cent shorter, and some teams have tripled the story points they deliver per sprint. For quick prototypes and minimum viable products, timelines shrink from weeks to days or even hours.

The speed gains are real. I’ve seen teams build prototypes in hours that would have taken days before. But remember: fast code isn’t always good code.

Democratisation of Development

Vibe coding makes it easier for staff who are not engineers to build software. Government agencies have used it to let policy analysts, project managers and citizen service teams build their own applications without dedicated IT support. In companies, experts in finance, operations and customer success build their own tools to automate work and chart data.

This opening-up extends to infrastructure-as-code work, where platform engineers use plain language to generate Terraform configurations, Kubernetes manifests and scripts that set up cloud resources.

Innovation Acceleration

When AI writes the routine boilerplate code, engineers can spend their thinking on design decisions, user experience and strategic problems. Teams say they try new things faster, because testing a new idea now costs much less.

Challenges and Substantiated Risks

Security Vulnerabilities

AI models trained on public code pick up the security flaws in that code. Common flaws in vibe-coded applications include SQL injection, missing authorisation checks, path traversal exploits, weak login mechanisms and credential sprawl. A Sola Security analysis found three patterns that keep coming up: unrestricted access to resources, openings for prompt injection, and inputs that are never checked.

Without required security scans, vibe coding in effect becomes “Vulnerability-as-a-Service,” producing systems that work but are insecure at their core.

Technical Debt Acceleration

GitClear’s analysis of 211 million lines of code found an eightfold increase in duplicate code blocks, rising in step with the use of AI tools. AI-written code puts doing what the prompt asked ahead of sound design. It skips clean-up, mixes styles and leaves more to maintain. This debt grows exponentially, as teams use AI to patch problems AI created, piling complexity on complexity.

Google’s 2024 DORA report found delivery stability fell 7.2 per cent in teams using AI coding assistants, even though early development was faster.

Maintainability Degradation

Vibe-coded applications often have no documentation, name things inconsistently, and contain logic that the person who wrote them does not fully understand. Knowledge gets stuck with a few people, and defect rates go up. More developers leave, as engineers struggle with code they cannot maintain.

Productivity Paradox

Here’s the most surprising finding: experienced developers are often slower with AI tools. This shocked me when I first saw the data, but it makes sense when you think about it.

A METR randomised controlled trial found that developers using Cursor Pro with Claude 3.5 Sonnet were 19 per cent slower than the control group, yet believed they had been faster. This illusion stems from the dopamine response triggered by AI-generated output, which mimics the satisfaction of completion without the cognitive effort.

State of Software Delivery 2025 data shows that developers spend more time fixing AI-written code than they save when first writing it. I have lived a version of this personally: why a 4-day project took 4 weeks once AI got involved in the revision cycle.

What the studies measured

Measured effects of AI coding assistants on speed and stability

Task completion speedMicrosoft, GitHub and MIT controlled study56% faster
Experienced developers using AI toolsMETR randomised controlled trial, 202519% slower
Delivery stabilityGoogle DORA report, 20247.2% lower

Three separate studies measuring three different things, so the bars do not add up. The METR developers believed they had been faster. The GitClear finding of an eightfold rise in duplicate code blocks is not drawn here.

Framework for Professional Adoption

Using vibe coding responsibly needs steady controls that keep the speed gains while reducing the proven risks.

Spec-Driven Development

The industry is moving from loose “vibe coding” towards methods driven by specifications. In spec-driven development, a formal specification becomes a blueprint the AI can build from. GitHub’s Spec-Kit framework implements this through a structured workflow: Specify → Plan → Tasks → Implement.

This approach gets it right on the first attempt more than 80 per cent of the time. It does this by giving AI agents the full picture up front: the context, the design limits, the security requirements and the design system rules. The specification becomes a contract between what the human wants and what the machine does. It cuts down on explaining things again and keeps the work consistent.

Mandatory Code Review Framework

The C.L.E.A.R. review framework gives a clear method for reviewing AI-written code:

  • Context Establishment: Before judging the code, review the original prompt, whether it matches the requirement, how the code was generated, and where it connects to other systems.
  • Layered Review: Review in layers, across five areas: what the code does and whether it meets the requirement, whether the logic and data handling are correct, security and edge cases, performance and efficiency, and style and ease of maintenance.
  • Enhanced Scrutiny: AI-written code needs a different review focus from code written by people. Reviewers must check the logic is correct (AI often adds subtle logic errors), check how it connects to existing systems, and spot the insecure patterns AI models copy from their training data. All AI-generated code must undergo human review before merging. No exceptions.
  • Automated Security Controls: Static Application Security Testing (SAST) must run automatically in continuous integration pipelines, and block merges when critical flaws appear. Tools such as Semgrep, Snyk Code, and SonarQube catch insecure patterns early. Dynamic Application Security Testing (DAST) and API security scans check the running code, to confirm that AI-written endpoints behave securely in live use. Writing prompts with security in mind cuts risk at the source. Prompts should spell out that the code must check inputs, use parameterised queries, give only the access needed (least privilege), and handle errors properly.

Hybrid Implementation Strategy

Professional teams use vibe coding selectively, picking the method that fits each use case:

  • Vibe coding for exploration: Prototypes, proofs of concept, internal tools with little security exposure, and automating processes that are not critical.
  • Spec-driven for production: Applications customers use, mission-critical infrastructure, systems that handle sensitive data, and parts that must meet regulations.
  • Traditional development for complexity: Distributed systems that need careful coordination, high-security settings with strict audit rules, and code where speed is critical and tuning it is essential.
Mindmap of hybrid implementation strategy matching coding methodology to use case: Vibe Coding for prototyping, proof-of-concept, internal tools, and workflow automation; Spec-Driven for customer-facing applications, mission-critical infrastructure, sensitive data systems, and regulatory compliance; Traditional Development for distributed systems, high-security environments, and performance-critical code
The methodology is a use-case decision, not a team-wide policy. The same team can run all three at once, on different code.

Governance Architecture

Companies need clear governance in place before they roll it out:

  • Usage Guidelines: Set the approved use cases, state which codebases allow AI help, and set up approval steps before generated code goes live.
  • Quality Gates: Require automated testing in CI/CD pipelines, set a minimum test coverage for AI-written code, and make security scans a checkpoint no one can skip.
  • Accountability Structures: Assign ownership. Developers remain accountable for all AI-written code committed under their name. Require documents that explain design decisions (even when AI suggests them). Log each rejected AI suggestion with the reason, and feed that back.
  • Training Investment: Train teams in prompt engineering with a focus on security and quality. Teach them where AI models fall short and how they commonly fail. Build internal prompt libraries that carry your organisation’s standards. The specific principles worth training on are ones I have documented from direct experience.
Mindmap of governance architecture for enterprise vibe coding adoption: Usage Guidelines covering approved use cases, permitted codebases, and approval processes; Quality Gates covering automated testing, test coverage thresholds, and security scanning; Accountability Structures covering developer accountability, architectural decisions, and rejected suggestions; Training Investment covering prompt engineering training, AI model limitations education, and internal prompt libraries
None of these four require slowing adoption down. They’re the difference between vibe coding as a practice and vibe coding as a habit nobody’s tracking.

Metrics for Measuring Success

Track measures in numbers to see whether vibe coding is working:

  • Velocity metrics: Story points per developer per sprint, time from feature request to live release, and how time splits across writing specs, building and debugging.
  • Quality metrics: Defect density (bugs per thousand lines of code), how long code reviews take and how often code is approved, and how fast technical debt builds up.
  • Security metrics: How often security incidents happen and how serious they are, time to find and fix flaws, and compliance audit results.
  • Operational metrics: Mean time to recover from incidents, how fast infrastructure is set up (for IaC use cases), and how well cloud resources are used (cost per transaction).

Realistic Expectations

Evidence suggests it realistically takes three to six months to break even, with large productivity gains from year two onwards. Early phases may involve:

  • Time spent on training,
  • Building a library of templates, and
  • Fine-tuning processes, all of which slow teams down for a while.

Leaders should avoid judging productivity only by lines of code written or how often code is committed. When AI produces bloated, repeated code, more code often means worse results. Focus instead on value delivered: features that go live, customer problems solved, and real gains in how efficiently operations run.

Conclusion

After months of research and experimentation, here’s where I’ve landed: vibe coding is a tool, a powerful one that can deliver real value when you use it intelligently, well short of the revolution some evangelists claim and nowhere near the disaster the skeptics fear.

My advice? Don’t jump on the bandwagon blindly, and don’t dismiss it out of fear. Take the middle path:

  • Use vibe coding for prototypes, internal tools, and exploratory work
  • Apply strict governance and mandatory code review for production systems
  • Maintain human oversight, always
  • Focus on outcomes, not lines of code

If you’re running a digital transformation, the question is how to bring in vibe coding responsibly, not whether to adopt it. The organisations that get this right will combine AI speed with human judgement and careful checking.

The future of software development is hybrid, combining AI capabilities with human expertise. Vibe coding, when properly constrained and intelligently deployed, is part of that future.

What’s your experience with AI-assisted coding? Are you seeing the productivity gains or hitting the pitfalls I’ve described? Drop a comment. I’d love to hear what’s working (and what’s not) in your organisation.

Evidence & Methodology

Two of the studies below point in opposite directions on speed. That is not a contradiction I am hiding. It is the actual state of the research, and it is why the framework above is about matching the tool to the task, not picking a side.

ClaimSourceGrade
AI coding assistants complete tasks 56% fasterMicrosoft, GitHub, and MIT, a controlled study (Peng et al., 2023)Measured
Experienced developers were 19% slower with AI tools while believing they were fasterMETR, 2025, a randomised controlled trialMeasured
Duplicate code blocks rose eightfold in 2024, correlating with AI tool adoption, across 211 million lines analysedGitClear, 2025Measured
Vibe coding pays back in three to six monthsMy own read from client engagements, not tied to a cited studyMy call

Cite this article

Kok, T. (2025, December 29). Vibe Coding: Pragmatic Adoption for Professional Development. terencekok.com. https://terencekok.com/blog/vibe-coding-pragmatic-adoption-professional/

Apply this in your organisation.

Work with Terence Kok — enterprise AI strategy, governance, and deployment.

Book a Session