Does vibe coding have a place in the world of professional development?

I’ve been experimenting with generative AI lately – both in my day job and on personal projects – and I thought it was time to jot down some reflections. Not a deep think piece, just a few observations about how tools like Copilot and ChatGPT are starting to shape the way I work.

In my professional life, I’ve used AI to draft meeting agendas, prepare documents, sketch out presentation outlines, and summarise lengthy reports. It’s a co-pilot in the truest sense – it doesn’t replace me, but it often gives me a head start. That said, the results are hit and miss, and I never post anything AI-generated without editing. Sometimes the AI gives me inspiration. Other times, it gives me American spelling and questionable grammar.

But outside work is where things got interesting.

I accidentally vibe coded

It turns out there’s a name for what I’ve been doing in my spare time: vibe coding.

First up, I wanted to connect a microcontroller to an OLED display and to control the display with a web form and a REST API. I didn’t know exactly how to do it, but I had a vague idea. I asked ChatGPT. It gave me code, wiring instructions, and step-by-step guidance to flash the firmware. It didn’t work out of the box – but with a few nudges to fix a compilation error and rework the wiring, I got it going.

Then, I wanted to create a single-page website to showcase a custom GPT I’d built. Again, ChatGPT gave me the starter template. I published it to Azure Static Web Apps, with GitHub for source control and a CI/CD pipeline. All of it AI-assisted.

Both projects were up and running quickly – but finishing them took a lot more effort. You can get 80% of the way with vibes, but the last 20% still needs graft, knowledge, or at the very least, stubborn persistence. And the 80% is the quick part – the 20% takes the time.

What is vibe coding?

In short: it’s when you code without fully knowing what you’re doing. You rely on generative AI tools to generate snippets, help debug errors, or explain unfamiliar concepts. You follow the vibe, not the manual.

And while that might sound irresponsible, it’s increasingly common – especially as generative AI becomes more capable. If you’re solving a one-off problem or building a quick prototype, it can be a great approach.

I should add some context: I do have a Computer Studies degree, and I can code. But aside from batch scripts and a bit of PowerShell, I haven’t written anything professionally since my 1992/93 internship – and that was in COBOL.

So, yes, I have some idea of what’s going on. But I’m still firmly in vibe territory when it comes to ESP32 firmware or HTML/CSS layout.

The good, the bad, and the undocumented

Vibe coding has clear advantages:

  • You can build things you wouldn’t otherwise attempt.
  • You learn by doing – with AI as your tutor.
  • You get to explore new tech without wading through outdated forum posts.

But it also has its pitfalls:

  • The AI isn’t always right (and often makes things up).
  • Debugging generated code can be a nightmare.
  • If you don’t understand what the code does, maintaining it is difficult – if not impossible.
  • AI doesn’t always follow best practices – and those change over time.
  • It may generate code that’s based on copyrighted sources. Licensing isn’t always clear.

That last pair is increasingly important. Large language models are trained on public code from the Internet – but not everything online is a good example. Some of it is outdated. Some of it is inefficient. Some of it may not be free to use. So unless you know what you’re looking at (and where it came from), you risk building on shaky ground.

Where next?

Generative AI is changing how we create, code, and communicate. But it’s not a magic wand. It’s a powerful assistant – especially for those of us who are happy to get stuck in without always knowing where things will end up.

Whether I’ve saved any time is up for debate. But I’ve definitely done more. Built more. Learned more.

And that feels like progress.

A version of this post was originally published on the Node4 blog.

Featured image by James Osborne from Pixabay.

Postmortem: deploying my static website with Azure Static Web Apps (eventually)

This all started out as a bit of vibe coding* in ChatGPT…

Yesterday, whilst walking the dog, I was listening to the latest episode of WB-40. Something Julia Bellis said gave me an idea for a simple custom GPT to help people (well, mostly me) eat better. ChatGPT helped me to create a custom GPT – which we named The Real Food Coach.

With the GPT created, I asked ChatGPT for something else: help me build a one-page website to link to it. In minutes I had something presentable: HTML, styling, fonts, icons – all generated in a few minutes. Pretty slick.

When it came to hosting, ChatGPT suggested something I hadn’t used previously: Azure Static Web Apps, rather than the Azure Storage Account route I’d used for hosting in the past. It sounded modern and neat – automatic GitHub integration, free SSL, global CDN. So I followed its advice.

ChatGPT was great. Until it wasn’t.

A quick win turns into a slow burn

The proof of concept came together quickly – code committed to GitHub, site created in Azure, workflow generated. All looked good. But the deploys failed. Then failed again. And again.

What should have taken 10 minutes quickly spiralled into a full evening of troubleshooting.

The critical confusion

The issue came down to two settings that look similar – but aren’t:

  • Deployment source – where your code lives (e.g. GitHub)
  • Deployment authorisation policy – how Azure authenticates deployments (either via GitHub OIDC or a manually managed deployment token)

ChatGPT had told me to use GitHub for both. That was the mistake.

Using GitHub as the authorisation method relies on Azure injecting a secret (AZURE_STATIC_WEB_APPS_API_TOKEN) into GitHub, but that never happened. I tried regenerating it, reauthorising GitHub, even manually wiring in deployment tokens – all of which conflicted with the setup Azure had created.

The result? Deploys that failed with:

“No matching Static Web App was found or the API key was invalid”

Eventually, after several rounds of broken builds, missing secrets, and deleting and recreating the app, I questioned the advice ChatGPT had originally given. Sure enough, it confirmed that yes – the authorisation policy should have been set to Deployment Token, not GitHub.

Thanks, ChatGPT. Bit late.

The right setup

Once I created the app with GitHub as the deployment source and Deployment Token as the authorisation policy, everything clicked.

I copied the token from Azure, added it to GitHub secrets, updated the workflow to remove unnecessary build steps, and redeployed.

Success.

Custom domain and tidy-up

Pointing my subdomain to the Static Web App was easy enough. I added the TXT record for domain verification, removed it once verified, and then added the CNAME. SSL was provisioned automatically by Azure.

I now have a clean, simple landing page pointing to my custom GPT – fast to load, easy to maintain, and served via CDN with HTTPS.

Lessons learned

  • ChatGPT can take you far, fast – but it can also give you confidently wrong advice. Check the docs, and question your co-pilot.
  • Azure Static Web Apps is fantastic for a simple website – I’m even using the free tier for this.
  • Authorisation and deployment are not the same thing. Get them wrong, and everything breaks – even if the rest looks correct.
  • Start again sooner – sometimes it’s faster to delete and recreate than to debug a half-working config.
  • DNS setup was smooth, but your DNS provider might need you to delete the TXT record after verification before you can create a CNAME).

Where is this website?

You can check out The Real Food Coach at realfood.markwilson.co.uk – and chat with the GPT at chat.openai.com/g/g-682dea4039b08191ad13050d0df8882f-the-real-food-coach.

*Joe Tomkinson told me that’s what it is. I’d heard of vibe coding but I thought it was something real developers do. Turns out it’s more likely to be numpties like me…