Vibe Coding, Visual Programming, and the Expanding Human - Digital Interface

Speaker A: Hi and welcome to Enterprise Alchemists. This is a podcast for technology leaders and enterprise architects who are navigating what's now and what's next in the world of AI and enterprise technology. I'm your host, Dominic Wellington, Director of Product Marketing for Data and AI at snaplogic, and my co host is Jeremiah Stone, CTO here at snaplogic. This series aims to bring honest and in depth conversations on the forces that are reshaping the enterprise, from agentic AI to workflow automation, and how to scale and govern the changing IT landscape. As part of the Evolving the Enterprise series from snaplogic, Enterprise Alchemists aims to deliver sharp perspectives, real world insight and occasional industry hot take. As Jeremiah and I go head to head and sit down with expert guests pushing the boundaries of what's possible. Hi everyone. Welcome to the Enterprise Alchemists, including evolving the enterprise, or potentially the other way around, depending on how you prefer to see it. My name is Dominic Wellington. I'm director of Product Marketing for Data and AI at, uh, snaplogic. I am your host and I'm joined by my excellent co host, Jeremiah Stone. Welcome, Jeremiah.

Speaker B: Hey. Hi, Dominic. Great to be here. Excited to be joining you as your co host going forward on this podcast. It's exciting.

Speaker A: No, I'm looking forward to it. And, um, for those who don't know Jeremiah, he is our Chief Technical Officer, our CTO at snaplogic. But in the spirit of the previous seasons of the Enterprise Alchemist podcast, this is not a sales or marketing podcast. This is us talking about issues that are relevant to our industry and to practitioners in this space, rather than too much about the specifics of how snaplogic is addressing those, except at, uh, the sort of philosophical level. But in that spirit, I wanted to kick off with something that has been a topic of discussion over the past year and change with the rise of Vibe coding and code generation and AI assisted programming, all of these various different terms, some people seem to have interpreted that as meaning that the sort of low code, no code, graphical programming, which snaplogic represents, is no longer relevant. So the idea of low code and no code was always to be more inclusive, to let people who are not formally trained as programmers participate more directly in automating parts of their job. So someone who understands a process well enough to draw out a diagram on a whiteboard or, uh, something along those lines would be able to at least take part in and potentially deliver the whole of automating that same process or the parts of it that make sense to automate. Now, with the rise of vibe coding And LLM assisted coding, does that get replaced with just explaining yourself to a chatbot and letting it spit something out? Let me roll that provocatively, uh, into the middle of the floor.

Speaker B: It is an interesting question. And yeah, the entire world is grappling with the idea that software development is over, that coding has changed forever, that software engineering is a bad idea as a college uh, major because nobody's ever going to write code anymore. It's definitely a personal question for me, my entire journey as a technologist started with the mind blowing experience of first writing code. I started with C and wrote some assembler actually I put assembler into production and then I wrote a ton of perl working at the national center for Atmospheric Research back in the late 90s, early 2000s and then moved on, worked at SAP with ABAP and ultimately did a lot of data science programming in various languages, r Python, et cetera. So I have a great love for the craft of coding and this idea that coding is over I think is really captured the popular imagination because it is, I think arcane to many people. And the introduction of coding assistants and coding agents has resulted in simultaneously much more accessibility and inclusiveness for people who had never gone through the effort to learn how to write code, et cetera, and just incredible changes to the workflow of professional software engineers as well. So I think the question and the exploration of how the profession of writing, maintaining and managing systems of software is relevant, I think it's exciting, I think it is worth pursuing. I also think it's quite a bit overdone because we have gone through multiple waves of evolution from machine code to assembler to integrated development environments to visual programming. And visual programming dates back to I think the 70s and 80s and there's been a very vibrant and rich ecosystem and world around visual coding. Code generation, assembly, uh, we do much more assembly of pre written code at snaplogic and not code generation because of various very good reasons. But now I think it is a very vibrant time where language models can solve many of the issues that procedurally code generation approaches ran into. So I think it's a really fascinating conversation. I think that the way that it's gripped the popular imagination is overdone and I definitely think that the broader end of coding and then the sort of corresponding end of low code is inaccurate. I don't think that's what we're seeing. What I think we're seeing instead is a expansion and evolution of the programming surface. And in some ways in James Governor, you know, James from Redmont pointed out he said, well, with the introduction of a conversational interface and an IDE and with coding agents, that is a new type of low code and it is a new type of low code interface. And I think that's the right way to look at it. I think we've now expanded the spectrum from direct writing, character by character of software code, to now a conversational interface that does code generation, modification and management, to visual coding paradigms of which snaplogic is one. But think of the industrial world with ladder logic and programmable logic controllers. That's a low code interface. There are many areas and for similar

Speaker A: reasons, because there are domain specialists in that world, they understand the industrial process, they're not there for the programming, they're uh, there for the industrial process. So if we can help them be more efficient at, ah, that part of the job, then so much the better. And we've seen this evolution before. COBOL was supposed to get rid of programming and let business people do the programming. SQL was for business people, not programmers. And we've seen this cycle over and over, same as SNAP logic. When we introduced SnapGPT, people said, does this mean that you're getting rid of the graphical interface? I know they coexist and it means that you both have a thing to look at while you're working with your chatbot assistant and so you have a better understanding of the output that it's producing. So I've had a similar trajectory to yours, works in a number of programming languages, et cetera, et cetera. But I'm not a working programmer. If I prompted one of the bots to do some C for me, I would probably have to do a fair amount of work to get up to speed, to the point where I could read it and interpret it properly. Whereas you give me a graphical representation, I can work through the logic with my finger and see is it doing what I think it's doing. And I think that's the key thing also, and especially again, what we've seen at Sniper, even before this current wave, is that while it's great that business process people can get involved in automating the business process they're responsible for without needing to go fetch a programmer for every little thing beyond a certain level of complexity, experience with the concepts of programming is important in order to be able to take maximum advantage of the capabilities. Just the idea of encapsulation and so on, being able to do things in a logical way is going to be helpful.

Speaker B: So many different dimensions, and I think that's one of the elements of this that is most fascinating and least discussed which is that you're really talking about a broad variety of needs. When we're producing digital systems systems, there's the overall architecture of the system and how we seek to optimize that with competing objectives. So there is definitely one objective is to get things into production as quickly as possible. Another objective however, is to have deep validation and understanding of the software artifact that has been produced. And some architectures are very obfuscating. However, they're very good for fast time to production as well as maintainability and maintainability through time. I think one of the best descriptions,

Speaker A: yeah, always write for yourself, but two years from now when you've forgotten what you're doing today.

Speaker B: Well, I think in the famous Google DevOps book actually defines software engineering as coding through time. And so there's different ways to think about managing software as coding through time. Then there is ongoing monitoring of these systems and management of them in production and long term adaptability and malleability of them. And these are all competing objectives. And it really is very context specific how accessible you'd like the logic to be. I think one of the real benefits of visual programming interfaces is that practice utilizes tens or hundreds of thousands of years of evolution of the human eye and brain to be able to have cognition of shapes and patterns. And then when those map back into other training, you've got these really nice visual analogs that if you can imagine a program as a flowchart that makes it more accessible to more people and the onboarding time to that is more rapid. And I think there's a natural corresponding component to that that. Well, if I can see how it works, I'd actually like to change how it works by changing the visual representation. And so this is an interesting element of the question, would you then go back and regenerate your code or rewrite your code and then re represent it as a visual diagram? And we do see this quite a bit. One of my favorite examples of this would be if you're writing Pyspark when you're in Spark, that you can actually look at the runtime monitoring and see how the Spark engine has re optimized the runtime plan and that can help inform the way that you're writing code. But it's pretty onerous. You have to write the thing, you have to get all your data up and going, you have to kick off your job and you have to see how the runtime planner does the actual planning and execution and look at it and monitoring necessary because the actual Data interaction with the code matters. However, it's a pretty long iteration loop as a designer and developer, whereas if you have a visual programming interface, you get immediate joy, immediate feedback, and you're shortening that iteration cycle for the end user. I am watching with interest though that many coding assistants do have corresponding visual representation of control, flow of logic, et cetera, colleagues that love Pummel, for example, and the UML architecture that can be produced from code. In order to support that, I think we'll be playing with this idea of expressiveness of prompt driven or spec driven development where we can use really great expressiveness of our requirements and document what we're trying to do with a visual interactivity component and the overall velocity we're working on. So I expect this to be a pretty interesting ongoing evolution of how we optimize the human surface of the digital surface to achieve the objectives of the person writing and of course the home hobbyist has different objectives. To a business person who's gotten technical enough to solve their own problems to a full time career technologist, it just complete different objectives. And I don't know, I've gotten to a point in my life and career that I find maximalist statements that this has changed everything for everybody to be

Speaker A: nobody does this, Everybody does this. We are in that period of experimentation, let a thousand flowers bloom, remind people it's only been three and a half years since ChatGPT dropped. We're still figuring out how this tech fits into everyone's lifestyle, work processes, everything. And as you say, there's a huge difference between code that is ephemeral. I just need this logic to run once, produce my dashboard and then I'm going to throw it away, I'm never going to need it again. And that sort of thing you can one shot from a chatbot because who cares if it has a memory leak or it's not ultimately efficient or what have you. And the sort of thing we do at snaplogic where it's going to be running all over the world, potentially thousands of times a day, transferring huge volumes of data and implementing run the business processes, that's a rather different sort of animal. So the explainability, understandability, observability of what's going on is important. And so it's not that idea that some people have in their head. People are just prompting the chat bot and then yoloing it into production. It's a much more iterative process and potentially involving multiple humans as well either again as you're saying yourself over time, or getting your colleagues involved One of the interesting findings for me, we did a survey of the most used SnapGPT prompt in 2025. In case you don't know, for the audience, SnapGPT is Snaplogic's copilot developer assistant tool. And the most used prompt, in fact in 2025 was describe this pipeline. So somebody's looking at something which already exists, which was developed at some point in the past, developed by a colleague who's not immediately available. And of course nobody documented it. Just explain to me what's going on here, please. That's the most common use. Case and graphical representations help there, but sometimes it's just okay. But then I can see this. It's talking to a database. What's going on in that interaction? And so being able to reach into that level as well and say, yes, it's pulling sales data, filtering, uh, it for the past couple of quarters, ordering it by region, whatever, giving you that understanding of what's going on beyond just, yes, it's querying a database. I think that's also an important part.

Speaker B: Absolutely. And I think this underscores the value of natural language and natural language descriptions, both as input in the form of specifications and as output in the form of documentation. Or I really get excited about is the idea of interactive documentation, the ability to. I think people describe this as having a conversation with your code base or having a conversation with your documentation. Documentation. And really what we're doing there is using the language model to provide a bridge for abstractive summarization for extractive documentation. And these are core capabilities of language models that was the core of the research was to create these abilities mostly around sequence to sequence and language to language translation. I'm very, um, passionate about. This is one of the things that I focus on in my grad school studies. And so we should not demand diminish the value of the expressiveness of natural language. On the other hand, we should also simultaneously not diminish the value of formalism inherent in visual coding interfaces or code themselves. I think one of the really important nuances with the whole idea of vibe coding or coding assistance is I note that, and I think rightly, that we're not talking about natural language as the programming language itself, or at least we should not be. I think some people believe, okay, we are now programming in our native tongue, be it Italian or English or what have you. That's not true. What we're doing is we're providing a input, specification or description of what we're trying to accomplish that is then being translated sequence to sequence from our input into the formalism of machine code or depending upon your bridge, could be into a visual representation which uses the formalism. For example, most visual programming tools and languages use specific shapes, specific sequences, specific ordering to then represent the logic that then is actually running in um, code and compiled code itself. And I think it is. That's a very important thing to remember. We are not even with these assistants programming in natural language. We're using natural language as a means by which we can specify our output. And the reaction, I mean I love the Dykstra essay on the foolishness of natural language programming, uh, class. And it really gets to the heart of this idea that we should not mistake. What we're doing here is programming with natural language. We're specifying with natural language, we're interacting with a coding agent or system with natural language. And I think the same thing can be said for visual low code tooling as well is we are not coding with the visual capabilities, we're using that as an interface by which we're translating our thoughts, our ideas, our desires into the formalism of code. And so in our case, having focused on visual programming for well over a decade, I'm really excited about this because I think this opens the spectrum from a low code perspective for snaplogic and we've done quite a bit of research and are continuing to prototype how we might support a broader community. So the community that wants the ability to move quickly, to move in a abstract description of the code they're trying to write and receive the same right now we've really focused on our browser based visual interface. Now we have the ability to expand that into a high code IDE or even into a coding agent itself. So we could imagine that a coding agent could have an integration agent as support. But what's fascinating to me there is we've been able to move so quickly in this because we went through the hard work of careful design and encapsulation of logic so that we are really assembling pre built components in order to achieve our workloads in order to go faster. And so these abstractions decrease the error surface of code generation and actually make for a much higher quality product. The team over at Airtable does something extremely similar. When you're building a UI or you're building a crud, uh, gui, they're actually using language models to assemble pre built components. And so they're using a best practice of a high code world for doing, doing decomposition of logic, reusability, loose coupling, but they're using it in a coding agent paradigm in order to deliver that velocity and a smaller error surface, better maintainability through time. And so here we see that interaction between architecture and interface in order to achieve the outcome.

Speaker A: And um, that's one of the other things. This rise of coding agents potentially has the benefit as a second order effect of forcing the application of best practices, either through things like, as you say, using known good examples to build the output, but also in terms of collaboration. And this goes also back to what you said at Agent Fest and by the way, for the audience, if you didn't watch Agent Fest live, that's available as a recording, we'll put the link in the show notes. That was the snaplogic virtual event where we went into more detail and also more product specifics about some of these topics. But you're talking about digital labour and so that whole idea of collaboration between digital and human users of a system that also links back to this. So one of the things that we always talked about as a benefit of low code, no code, graphical representations is if I'm a business process person, not a coder, and I need something, I can build something simple potentially just on my own. If we're starting to get into some of the complex representations, then maybe I do need someone who does come from that background to help me represent what I have in mind. But thanks to the graphical representation, we're both looking at the same artifact where we're working together now. Add decoding assistant. And it's helping with that representation, it's helping me explain and specify what I'm doing as opposed to how it might have been in uh, let's say pro code world, where I would have to explain myself in writing, in English, as you say, very imprecise to someone who would then not coming from my domain, from my special environment, have to go off and transform my English language specification, my human language specification into code and then bring that back. And of course it's never going to be just right. So it helps with that understanding and representation and shortens the loop from ideation to automation. But then add one more level, as you were saying, if then the pro coder who does have the background, does have the skills, is probably going to be more efficient and effective in that environment with tools optimized for their experience, but still working on the same artifacts because the high code and the low code are operating on the same backend. Now we've got something really interesting in terms of the human computer interaction model with multiple humans, multiple large language models all working together. In a single unit, towards a single purpose.

Speaker B: We couldn't agree more. And I think while this is an interesting philosophical discussion, I think it does translate directly into hard takeaway for teams for colleagues that are thinking about how they can manage coding agents through time. And the key idea that I think you're exploring there is really collaboration and portability. I definitely have seen and heard multiple teams that have gone down the approach of applying agentic development, that it can be very isolating for individuals who are doing the program, because what used to be a team sport now can become more of an individual sport with the tools picking up more of the activity that colleagues and teammates would have preferred formed. And so you can get workplace isolation. But worse, you get drift, you get individual drift within your architecture, you get drift within your understanding of the requirements. And we can get a false perception of progress and velocity based on the amount of stuff we generate. But the stuff we generate isn't the goal, that's output, it's not the outcome. The outcome is achieving the business goal or the individual goal of the person. Programming, and that even with these types of tools, is still a team sport. And it's a team sport from discovery and understanding the white space that you're trying to serve. It's a team sport in terms of explainability and pitchability to a customer, that sort of thing. And so I think we're seeing naturally an evolution within the coding agent space that trends exactly to where you're heading, which is a standardization of the management of the artifacts, the architecture, et cetera. All of the focus around how do you structure your Claude MD file for usage between different developers. Cloud ring, that's standardization of architecture, that's interoperability, that's standard consistency across sessions for an individual, but consistency across the work from many. And if we think about it in our context, the fact that we will use an agentic integration approach that could be in a high code user experience, to be interoperable with a low code user experience is prioritizing the ability to collaborate with others, be it a customer, be it a colleague, be it somebody in the business. So I think that's one best practice that anyone working in this space should take into consideration is how am I organizing my environment to support those iteration loops between understanding the idea, understanding the output conceptually, as well as interoperability with the actual produce code artifacts. Because we're still going to have labor decomposition, some teams will be working on a subset of screens of an application than others. For example, and Conway's law hasn't gone away. And interestingly enough, I don't know if you've read the essay the Mythical Agent

Speaker A: Month, but I like the title already.

Speaker B: It was probably a completely new episode, but there's an entire exploration around the idea that there is no silver bullet. Essay from Brooks's Mythical Man Month is unchanged despite these labor enhancement tools, because we're focusing on output and delivery of the final project, not suboptimization of an individual element. So, anyway, getting back to the idea, do we believe that coding agents remove the low code world or remove coding? I don't think so. I think it increases accessibility, certainly increases velocity, and the ability to have a highly iterative development cycle. But I think if anything, it's a new tool. It's a new arrow in our quiver, and we need as leaders and as builders to think about how it fits into our organization. How does it change individual teaming structures? How does it change group structures? How does it change our ability to code through time and continue to meet our goals?

Speaker A: Indeed. So that has been a, uh, fascinating conversation. That was exactly what I was hoping for, our, uh, inaugural episode. So for the audience, I hope that you found that interesting. There will be links to the various resources we discussed in the show notes. I will also put links to the Agent Fest replays, so you can go and check those out. And Jeremiah and I are, uh, both on, um, LinkedIn, so you can hit us up if you have further thoughts, comments, suggestions for future episodes. But for now, as they say, subscribe, subscribe and we will be back in your podcast player very soon. Thank you very much for your time, Jeremiah.

Speaker B: Thank you. I love this, Dominic. Fascinating topics to engage in. Never a dull moment and never a lack of overinflated hype to puncture and dissect and dig into. And really enjoy the conversation and looking forward to talking to our audience and others within the community what they think about this and tell us we're all wet or how we can improve our thinking. Uh, and really look forward to that.

Speaker A: Excellent. Yeah, we've got some guests lined up for future episodes, so stick around for those. But for now, thank you once again and see you again soon.

Speaker B: Bye. M. Bye.