3 Perspectives on AI and Vibe Coding
Getting the perspectives of our technical, and non-technical, staff members.
I was talking with a friend recently, and he detailed how he used Claude Code to write custom software that would allow his Raspberry Pi Zero to control a vintage audio setup he owned so he could use it with devices over Bluetooth and connect it to his gaming PC. Claude even went so far as to outline the adapters, modules and cables he’d need and organized the options by cost and ease-of-setup. This is someone who comes from a non-technical work background, has little interest in programming, and is only tech-savvy to the point of troubleshooting his PC. However, this experience inspired him to make more software that solved problems specific to him—like a small app that updates Discord’s “Now Playing - Music” status when using Apple Music on Windows—and now he’s cautiously optimistic about AI coding.
This was almost too-perfect of a scenario, and one that major AI companies will have you believe is going to be ubiquitous: a non-technical person using AI to fulfill their software needs with bespoke apps made just for them. In this case, though, my friend was already curious about, and exposed to, the world of software engineering through friends and family who work in technical roles, with one even setting him up with these tools in the first place.
It felt like fate, then, when I was talking to some of the Lickability team and learned how another non-technical member of staff had recently used AI to solve a problem for him. While listening to his experience, I realized I should leverage the unique opportunity I have working for a software studio: to get perspectives from as many backgrounds as possible. Is AI turning people from non-technical backgrounds into vibe coding solo founders overnight? If it’s solving problems for non-technical users, is that inspiring them to build more or pivot their career trajectory? Are software developers bitter over the prospect of AI “making their jobs less-valuable?” Is there any fun left to be had as a software developer in 2026?
Thomas DeVuono, Director of Client Partnerships — A non-technical member of staff using AI for technical problem solving.
First off, what’s your current position and background experience in coding (if any)?
“In short, I own and lead all sales efforts and deal structuring and represent Lickability as a major public face during any industry events we’re hosting or participating in. As for prior experience? As close to zero as you can get. I took one coding class back in college, but have a working understanding of software structure, development pipelines, etc. due to working alongside engineers and representing a software company!”
What prompted you to dive into vibe coding in the first place? Did you have a desire to build skills, or just had a problem that needed solving?
“A few years ago, I made my own silly little personal site messing around with a tool called ‘Bento’, which was essentially a drag-and-drop website builder. After they were acquired by Linktree, who sunsetted it, I was left back at square one. Thankfully, through Lickability, I have access to a ton of talent. I asked Jillian, who introduced me to the Astro framework and some really similar ‘Bento-style’ templates, and was coached through initial setup during our company retreat in 2025. I got set up with Warp Dev, dusted off my GitHub account, and started using Warp + ChatGPT to build my site. A lot of these AI tools lean into giving non-technical folks the advice of ‘don‘t worry about asking, just say yes!’ mb explicitly warned against me doing that; not just from a safety standpoint, but because of potentially out-of-control token cost…”
Did this experience inspire you to start making more of your own stuff?
“It all comes down to taste. Even though I could make my own stuff using these tools, I really prefer using things that are made by professionals who have a passion for it. For example: I have no idea if my personal site adheres to accessibility guidelines. I don’t know how to check that, and didn’t consider in the moment telling ChatGPT to take that into consideration. I also think, while solo development is admirable and cool, that bringing lots of different perspectives into the mix is usually beneficial. I think it’s great that AI is giving people the ability to build, but I almost think of it like cooking: I know how to cook, and I feed myself decent food, but just because I can cook doesn’t mean I could walk into a 3 Michelin star restaurant, go into the back and recreate their menu. And to a certain extent, I don’t want to!”
So if vibe coding didn’t turn you into an overnight solo entrepreneur, did it at least make you wish you’d gone down a more technical path with your career?
“Not really. Developing software was never in my career goals. Around the time I started with Lickability, I spent a lot of time in Swift Playgrounds so I could get a better grasp on what our engineers actually do. That experience prompted me to go to them with questions, and I vastly prefer talking with experts than using AI to teach me. On that note, a lot of the software we use every day doesn’t teach you when it solves a problem, or explain how it solves it; it just solves it. I like working out that part of my brain. Having these skills has probably helped me be better at sales because I know our capabilities and services better, but I don’t have a passion for the technical aspect.”
Coding isn’t your passion, got it. Then have you liked using AI tools for the work you enjoy doing, or not?
“Honestly? I’d say ‘having’ to start using them is a little more accurate. Using these tools has essentially allowed me to do more than I previously could by offloading a little of my work. I mainly use the tools for helping with “data and figures” communication; for example, I send a lot of emails that have to be very lengthy and thorough, with a lot of fine details regarding pricing, dates, agreements, etc. It’s useful for fact-checking against my notes, or editing for efficiency’s sake, since you have to balance getting out a ton of information while also keeping people’s attention. I’ve enjoyed using it for writing where I don’t need a ‘personal voice.’ When it comes to RFP requests, scope and feature timelines, things like that? All hand-made.
I really dislike how pervasive the influence of AI-assisted writing in personal settings has become. Case in point: I use an app called GroupMe for organizing trips with my golf group. On several occasions, it’s auto-generated responses to jokes, observations, or even opinions. It’s even “vibe checked” previous messages and given me suggestions based on ‘vibe’ … I want to use these tools for efficiency in my working life so I have more time to communicate with friends, not automate that away!”
Ashli Rankin, iOS Engineer — A technical member of staff using AI for non-technical problem solving.
What’s your role at Lickability, and do you find yourself leveraging AI in your daily workflow?
“I’m one of Lickability’s iOS Engineers, but funnily enough: not really. The main things I’m working on lately are internal tools and apps we’re creating for ourselves and, eventually, others. This means I’m usually doing a lot of experimentation and trying to integrate cutting edge features that don’t have much description outside of Apple’s developer documentation. I’ve found it more of a hindrance to try and have LLMs tackle this kind of problem solving, since I want to come up with elegant solutions and really understand the best ways to take advantage of these new features. A lot of LLMs aren’t as well-versed or trained as deeply on these newer libraries and development documentation, too.
That isn’t to say I’m staunchly against the idea, and I know these tools will get better over time. One thing that’s been fun is giving two different models a problem and seeing how each of them choose to try and solve it.”
So if vibe coding isn’t part of your daily workflow, are you using AI for anything else?
“In personal projects and communications, mostly. I’m not the most confident in my writing, and it’s nice to use it for editing grammar and clarity. I’ve also used it when playing around with personal programming projects, since it’s nice to mock up working examples or drafts and have something to go off of. I don’t have a deep passion for creative writing, but even then I don’t want AI to speak for me. I just use it as a tool to help pare down and organize my thoughts.”
Michael Liberatore, Staff Engineer — A technical member of staff using AI for technical problem solving.
Have you found AI more useful from a creation standpoint (code completion, giving it problems to solve and letting agents work on something, etc.), from a point of automating “busy work” (version management, pull requests, merging codebases, etc.), or a bit of both?
“A lot more of the former, though AI and LLMs can be useful in both contexts, and things have changed over time for me as well. When initially dipping my toes in, it was easy to get started by using modern development environments that offer smart code completion made possible by AI. Letting an LLM suggest the rest of the current line you’re typing builds some confidence and trust in the tools, and shows that they’re actually capable of doing what you want a lot of the time.
It snowballed from there, and I think that experience is common for folks like me, who have tried to cling to the idea of ‘code as craft,’ with a lot of initial skepticism around LLMs. Next, you write a function signature and have it fill out the implementation. You check the results, maybe change a few things. From there, you start to feel comfortable just describing features, detailing how you’d like the code to be written in a broad sense, and refining the results. Then as the tools get better, and as agents, MCPs, and plugins mature, you can task them with broader problems, learn the quirks of individual models, and figure out the best way to steer the technology from a high level to produce the results you want. Suddenly, you find yourself typing into Claude Code or Codex more than Xcode and Visual Studio Code, but now I’m editing its work more than it’s editing mine because I trust my final judgment more than I trust its.”
As someone with a clear passion and skill for computer science and programming, is there any sadness in spending less time problem solving? Have you had to wrestle with prioritizing efficiency over quality at any point?
“Profound sadness! I’m proud of a lot of the code I’ve written in my career, and I mean that literally: talking strictly about the code, line by line, how it’s organized, its cleanliness, creative ways I tackled limitations, a new pattern I introduced, not just the shiny end-user result. Any code that I submit for review still has a large, human-crafted element to it, but that’s been slipping away over time for a lot of people, and I’ll mourn it if I have to give it up to remain competitive in the industry. As for problem solving, there are now classes of problems that I used to enjoy puzzling out that just don’t make sense to spend any time on anymore. For example, I’m pretty good at applying 2D and 3D geometry principles to solve tricky drawing and animation problems, but that’s a walk in the park for an LLM. Does that free me up to work through more important things? Sure, but I liked solving those math problems, and I would feel a sense of pride in reaching a solution! That era feels pretty much over with these tools at our disposal.”
Do you have a personal ethos when it comes to your own AI usage? Thresholds you won’t go past? Things you don’t trust it enough to rely on it doing?
“Yes to all. I know I talked about building trust in using the tools and how, over time, you can relax in certain areas and just let them ‘do their thing,’ but that trust is qualified by a lot of oversight, adaptability as new models are released that introduce new quirks, and hard-and-fast rules. First and foremost, a lot of the projects we work on are for clients that have hired us. If I’m working with an engineering team that has its own processes around what acceptable AI usage looks like, I’m following those very carefully. That can be something as small as ‘don’t let LLMs train on our code,’ or ‘we use Claude, not ChatGPT,’ or something as strict as ‘IT has forbidden the use of AI.’ As for personal thresholds, I’ve thus far been unwilling to remove myself as a bottleneck for shipping code. Every line of code I submit for review, whether originally written by me or by an LLM directed by me, is carefully checked over before I’m comfortable letting others review it for merging. If I’m doing my job correctly, any code I submit that an LLM wrote should look indistinguishable from code that I wrote myself, the only difference being the speed and method by which it was delivered. I expect I’ll need to ease up on this meticulousness as the technology improves and expectations around timelines change as a result, but while I’m still able to, I won’t budge on that meticulousness. If I’m working on a personal project, sure, I’ll let an agent take over and fix bugs, submit pull requests, etc. Just not at work with our clients, where that meticulousness is paramount.”
What’s been the most obvious net-positive thing about AI for your job? Maybe something that just purely took time and no creative thought you can now automate.
“One thing I bemoan is writing throwaway code while iterating on a production UI. This comes up a lot when I’m working on the frontend and another team is building the backend. Inevitably we won’t be working in lockstep, and I’ll want to test an interaction that depends on a variety of backend behaviors that aren’t working yet. Yes, we’re writing automated tests where we can fake data all we want, but as I’m iterating it really helps to manually interact. In that case, I turn to temporary throwaway code which, for example, glues pieces of a UI together, spawns test interfaces for triggering specific permutations, or skips past a required step that’s currently returning an HTTP 500. Tomorrow that broken API may work, but today I just want to make sure my UI makes sense and feels good. In days past, I’d debate with myself whether it was worth spending any time rigging things together versus context switching to a new problem while I wait to be unblocked. Today, it’s as simple as writing a prompt or two. The quality of the code doesn’t matter as long as it works. It’s created as quickly as it’s destroyed, and no one ever needs to see it. I no longer have that internal debate, and I can feel confident in what I’m delivering without spending my time writing code that I know will be deleted.”
