{"id":36532,"date":"2026-08-28T11:21:06","date_gmt":"2026-08-28T18:21:06","guid":{"rendered":"https:\/\/www.podfeet.com\/blog\/?p=36532"},"modified":"2026-08-28T11:21:06","modified_gmt":"2026-08-28T18:21:06","slug":"vibe-coding-allister","status":"publish","type":"post","link":"https:\/\/www.podfeet.com\/blog\/2026\/08\/vibe-coding-allister\/","title":{"rendered":"My Experience with “Vibe Coding”"},"content":{"rendered":"

On episode 1009<\/a>, Allison spoke about her addiction to AI \u201cvibe coding\u201d<\/a>. She mentioned many of her friends were also doing the same. I am one of those friends, and this is the story of my experience.<\/p>\n

First, a little background. I have been a programmer for around 45 years. I have done it for fun that entire time and, around 6 years after I started at age 12, my skills were good enough that it got me my first job. That job was the only time I have had \u201cprogrammer\u201d in my job title, but I have been coding as a working tool ever since.<\/p>\n

In my personal life, I\u2019ve made various hobby projects over many years, from building a photo database with its own sector-level floppy disk format to hand-coding my first website in HTML, then converting it to use XML and XSLT<\/a>, and eventually writing my first iPhone app. In short \u2014 I know how to code.<\/p>\n

My first iPhone app was built in my Christmas break at the end of 2014. It was very, very simple, but I felt a great sense of accomplishment. I\u2019d had to learn Objective-C, but that wasn\u2019t the hardest part. No, the hardest part was the API<\/em>. Actually, the hardest part was the App Store submission process, but that doesn\u2019t serve this narrative.<\/p>\n

When I started programming, it was entirely practical to learn everything<\/em> about the computer<\/a> you were using. Today, that is an impossibility. I have no doubt that there is not a single person, perhaps not even a group of a dozen people, inside Apple, who have a true working knowledge of all of iOS. That has nothing to do with today\u2019s Swift language (which does have its own mysteries) but everything to do with the enormous number of possible API calls that exist and the stratospheric number of permutations of those.<\/p>\n

The greatest invention of Steve Jobs\u2019 second-act company, NeXT<\/a>, was NeXTSTEP<\/a>; a library of building blocks that developers could use to quickly build applications without having to know everything about the computer. It was revolutionary at the time and very successful. (The technology, not the company!) Those building blocks are what we call APIs \u2014 Application Programming Interfaces.<\/p>\n

NeXTSTEP was the foundation of Mac OS X and thence iOS. I shudder to think how much it has grown since the beginning. There are a bewildering number of APIs and, in many cases, several ways to do essentially the same thing. This would be a minefield of documentation to wade through, but it\u2019s not even that easy because much of the documentation is missing or, in some cases, may as well be.<\/p>\n

With comprehensive documentation, the macOS and iOS ecosystem would be an excellent platform for the working developer.<\/p>\n

The working<\/em> developer. I chose that word carefully.<\/p>\n

For we hobbyist<\/em> developers, the task is effectively magnitudes larger. Both because we have less time to devote to learning, but also because we spend less time repeating tasks to cement the learning.<\/p>\n

As I mentioned, I can code, and I have a knowledge of Swift<\/a> and SwiftUI<\/a>, but my mastery<\/em> of those languages is, well, not mastery at all.<\/p>\n

SwiftUI is an incredible technology, but it is still really in its formative years. Many things are simply not possible and many things only work if you construct them \u2018just so\u2019. SwiftUI only takes care of the user interface and interaction. Inevitably, you will have to write some Swift to create the logic of your application.<\/p>\n

Swift has its own foibles. It is a \u2018strongly typed language\u2019 which means you cannot, for instance, multiply a floating-point number by an integer. You have to turn one into the other first. You have to be explicit about everything<\/em>. The upside of this strictness is that compiled code is highly unlikely to crash. The downside is that your code is highly unlikely to compile!<\/p>\n

The internet is awash with so-called tutorials, but they are more accurately examples<\/em>. The only thing they teach is how to achieve the example. It\u2019s like if I taught you how to boil an egg \u2014 you\u2019d know how to boil an egg. Maybe you\u2019ll manage an egg salad, but it\u2019s not going to turn you into a cook, let alone a chef.<\/p>\n

I paid for a quite comprehensive developer course<\/a> that includes far more than just code and API usage. Again, however, the investment of time required is simply enormous. It is a superb resource and I have taken learnings from it, but I don\u2019t have the time to make the most of it. It\u2019s just as well I am happy for having supported the developer who created it.<\/p>\n

What I wished for, for many years, was an experienced companion who could guide me. I\u2019m usually OK if I get a good steer on a problem. I can go down the rabbit hole and often come out with a rabbit. The trouble is I\u2019m standing in a very large field with overgrown grass. I have trouble not only in choosing which hole to go down, but also finding them in the first place.<\/p>\n

And so we come to the use of AI. Much has been said about how AI will \u201cwrite code for you\u201d. If you\u2019re not a coder, that\u2019s an obvious value. The vastly<\/em> bigger value, however, lies in its ability to autonomously scour that field for holes and go down every one of them until it emerges from the correct one with the perfect rabbit. Well, mostly.<\/p>\n

My coding companion is Claude<\/a>, from Anthropic<\/a>. I started out using the free plan, which was absolutely fine, and got me a lot of the way to my first goal. But sometimes when you\u2019re in the flow and you run out of tokens or time, it can be frustrating. I now subscribe to the lowest of the paid plans. I still run out of time often, but I get a lot more done in a session.<\/p>\n

That first, very simple app I wrote a decade ago was on the App Store for free. It was so<\/em> simple, I wouldn\u2019t have felt right charging even pennies for it. It also became irrelevant pretty quickly. About a year later, I created another simple app. Both of these apps were built to solve a problem I<\/em> had.<\/p>\n

This leads me to my third app. Well\u2026 my third app idea<\/em>. This one included some fairly complicated maths and geometry. I managed to build a working prototype that got all that clever stuff working well. But the UI was\u2026 uhhh\u2026 terrible. I struggled with how to create what I thought would be a better user experience, because what I wanted was not possible with standard controls. I hit that barrier of not knowing where all the rabbit holes were. Eventually I just stopped trying.<\/p>\n

Some years later I got the energy to try again. This time I decided to start<\/em> with the interface. The technology had moved on and it was more achievable, though only with countless hours spent scouring the internet for many relevant examples I could try to leverage. I eventually got the interface close to what I thought it should be.<\/p>\n

I then set about integrating the old code to do the maths and\u2026 I got stuck again. This time, I was struggling with how to structure the application such that the relevant information could be passed back and forth between the interface and the maths logic. I got so stuck, I again eventually stopped trying.<\/p>\n

And so we come to 2026. Twelve years<\/em> after that first attempt, I had heard enough positive stories that spurred me to give Claude a try.<\/p>\n

I decided that I would let Claude do all<\/em> of the work. I would not give it any of my existing code to use.<\/p>\n

I started with what I thought was a fairly complete description of what I wanted to achieve, although I did deliberately leave out some of the more advanced concepts it would eventually need. Imagine my delight when it produced, at the first attempt, a working project that was a passable representation of what I had in mind. But, immediately, there were things that needed to be corrected.<\/p>\n

Some of the corrections were things it got wrong, but more were things I simply hadn\u2019t defined. The further I went, the more needed refining, and this is a key point.<\/p>\n

I was using my skills as a developer, having thought about<\/em> design and behaviour, to instruct the AI to build things the \u2018right\u2019 way. I said just now that I left some bits out of the initial prompt \u2014 that was done in the expectation that their absence would not fundamentally alter the required architecture.<\/p>\n

As I continued on, I suggested, or in some cases demanded, certain implementation details. For some others, I explicitly said I did not know how it should be implemented and Claude would either use (and describe to me) a best practice or give me two or three options with a rundown of their relative merits, with the final decision left to me.<\/p>\n

This is, in a very real sense, development. While purists might decry that the machine is doing all the work, it is likely that the first users of compilers had their detractors among those who still used machine code. In the end, it is just another level of tools to make use of and, if you know what you\u2019re doing, it lifts you up.<\/p>\n

I have looked at some<\/em> of the code Claude has generated. Where I did, it seemed to make sense. It didn\u2019t look horrible. I don\u2019t know if its technical architecture would be considered sound by those in the know. I do know that the fundamental architecture was<\/em> a topic of discussion throughout the exercise. I did tell you I was a developer, right? I know what architecture is and I know how to use and misuse it. Mostly.<\/p>\n

Speaking of topics in the conversation, at one point I did a bit of a review of what I had said to the AI. This was at iteration 54 where I had a perfectly functional, fully featured app.<\/p>\n

These numbers don\u2019t add up as not every prompt I gave covered a single topic. I would sometimes say \u201cfix this and add that\u201d. In 54 prompts, 10 were about functional change to the app, 10 were about design issues, 29 were addressing functional issues, and 11 were related to compiler errors.<\/p>\n

The most important number in that list was the 29 functional issues. These were what building the app was all about. It needed to look and feel intuitive, and to accurately represent the information the app was all about. These could be anything from the size of a button to what happens when a setting is changed that invalidates another.<\/p>\n

At around this build I engaged a small number of trusted outside testers. This resulted in feedback which in turn resulted in a further 17 iterations on the app with a similar mix of purposes, bringing the final total to 71. This was the version I submitted to the App Store.<\/p>\n

During this external testing phase, I had some spare time while waiting on app review and tester feedback, and by this time, I was paying for Claude. So I started another project.<\/p>\n

The second app was a Mac app and the process followed largely the same path. The main difference was that my initial prompt was far<\/em> more descriptive. I had become better at thinking of what I needed to define.<\/p>\n

It was while developing this second project that I realised something. The issues I spent the longest time addressing with Claude were exactly<\/em> the types of issues I know I would have spent a lot of time addressing if I was doing everything myself.<\/p>\n

A quick aside here. There has been only one occasion in my professional life where I have truly shocked a colleague. A project manager had the temerity to say, \u201cIt\u2019s just a file transfer\u201d. His shock came when, in a slightly heated tone, I described all of the variables and possible permutations of those, and all the things that could go wrong and the mitigations needed to address them. I bring this up because some might also say \u201cIt\u2019s just an image file\u201d, and I would have a similar response, particularly after this experience.<\/p>\n

My app\u2019s primary input and output<\/em> is image files. Imagine if you constrained yourself to only handling JPEGs. Rotation and colour space alone are problematic. Add in TIFF, HEIC, and PNG and it literally explodes in complexity. It took Claude and me over a dozen iterations to succeed on these two aspects of image handling. Along the way a third issue was introduced and solved, too! I can tell you there were some hilariously bad intermediate results.<\/p>\n

Curiously, this second app also took exactly 71 iterations before it was ready to release to the App Store.<\/p>\n

And so to a conclusion, and my point in writing this piece. Yes, AI can write code for you. Yes, it will do it whether you<\/em> know how to code or not. But I believe the biggest<\/em> value of AI coding assistance is, in fact, not for so-called \u201cvibe coding\u201d but as a force multiplier for developers. Claude didn\u2019t develop my two apps. I did. But I needed Claude\u2019s vastly superior \u201cexperience\u201d and research skills to navigate me around that large field, finding the right holes to dive down, in a short enough timeframe that I didn\u2019t lose interest and walk away.<\/p>\n

\n

Finally, if you\u2019re wondering about the two apps I have been mentioning, I\u2019ll give you a brief introduction.<\/p>\n

FocalTiger<\/a> is an iPhone and iPad app which visualises the depth of field created by a camera and lens system at varying settings. If you\u2019re trying to figure out how to ensure a whole subject, particularly one that is close, will be sharply in focus, FocalTiger is the tool you need. Set up your camera configuration and then play with the sliders until you see the solution working.<\/p>\n

PhotIdent<\/a> is a Mac app for watermarking photos. This is not about intellectual property, but branding. No watermark will stop a determined thief stealing your image, but a tasteful watermark can let the honest viewer know who you are and how to find more of your work. For the purposes of branding, a subtle<\/em> watermark tells them these things while also respecting that they want to see the photo without distraction. The trouble with subtle watermarks is that it is effectively impossible to create a single design and treatment that works on every photo in a batch. PhotIdent solves this by letting you choose and tune a watermark on each image, quickly.<\/p>\n

You can find links to these apps, and a couple more, over at OrangeMoth.NZ<\/a>. If you\u2019re wondering about those other two, they were originally built by me, by hand, but have subsequently been updated and enhanced with the help of Claude.<\/p>\n","protected":false},"excerpt":{"rendered":"

On episode 1009, Allison spoke about her addiction to AI \u201cvibe coding\u201d. She mentioned many of her friends were also doing the same. I am one of those friends, and this is the story of my experience. First, a little background. I have been a programmer for around 45 years. I have done it for […]<\/p>\n","protected":false},"author":29,"featured_media":33261,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[147],"tags":[2751,7144,1517,902,2657,5642,126,1104,176,7973],"class_list":["post-36532","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog-posts","tag-architecture","tag-claude-ai","tag-design","tag-develop","tag-developer-tools","tag-development","tag-ios","tag-macos","tag-programming","tag-vibe-coding"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"https:\/\/www.podfeet.com\/blog\/wp-content\/uploads\/2025\/03\/claude-logo-1040x520-1.png","_links":{"self":[{"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/posts\/36532","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/users\/29"}],"replies":[{"embeddable":true,"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/comments?post=36532"}],"version-history":[{"count":2,"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/posts\/36532\/revisions"}],"predecessor-version":[{"id":36558,"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/posts\/36532\/revisions\/36558"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/media\/33261"}],"wp:attachment":[{"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/media?parent=36532"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/categories?post=36532"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.podfeet.com\/blog\/wp-json\/wp\/v2\/tags?post=36532"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}