Transcript: Nadav Abrahami | Dazl | Who Builds the Product Now: PM or Developer?

Intro and meeting Nadav

Eyal David: [00:00] There aren’t any interesting details, in order. What’s up? What fun it was to do this. We’ve been looking forward to it for a long time, relatively speaking. Nadav, introduce yourself in a few words.

Nadav Abrahami: [00:12] Hi, I’m Nadav Aharonami. About 20 years ago, I co-founded Wix together with my brother Avishai and Gig, a friend of both of us. Four months ago, I split off from Wix to found Dazzle. At Wix I was always a bit less technical. Then I took it in a different direction within Wix, where there was basically an innovation lab that developed quite a few things. One of the things we dealt with a lot was code visualization, and in that space, with the wave-coding revolution, it suddenly made a lot of sense to go out and launch Dazzle. You don’t fully understand what was built for you and where you can take it and where you can’t take it; you’re not really a partner in that process.

Founding a company in the Wix era vs. the AI era

What Dazl builds and why vibe coding creates an understanding problem

Understanding technical complexity without reading all the code

Importing code, stacks, and the last 80/20 in AI tools

Eyal David: [05:55] And really the vision is—I think I know the answer, but the vision is basically that it will support applications built in Dazzle.

Nadav Abrahami: [06:01] Meaning I can’t just layer this over existing code, in a sense. We’ll definitely allow importing code from all kinds of places, but basically we’re working with standard code. A specific stack if I’m, let me steer you, technically the stack we work with best. Obviously we’ll want to bring in projects from many places and then open them up to this stack. Because we can give it the other capabilities, inspection, editing, and so on, and in the end we see people getting to like 80% and then struggling with the remaining 20%. They don’t succeed; they don’t succeed partly because they didn’t understand what was built, and partly because it simply doesn’t make sense to do some of the visual actions that way. That way isn’t the right way to prompt it.

Eyal David: [06:46] That’s it—give us a real example, for instance, something like that that wouldn’t pass now in a tool like Avala and Blue or something like that.

Nadav Abrahami: [06:53] Everything can pass—who can make it pass and in how many prompts? Let’s start there. I also worked with many of these tools, of course, to try them, test them, and so on; there are things that make it work better. Things that from the outset say this application will be more flexible, one example of that, and again, this is very technical, you can put the state of your app inside a visual component, and then if you decide to present it in a different visual component, you have a huge amount of code change to make. And you can keep that same state in something outside the visual component, in a place that ideally is even at the level of the whole application. Now these are decisions that are not exposed to you. There are things that also make no sense to surface to the context of the whole application. I mean, if you surface everything to the context of the whole application, in the end... The context becomes very large, and you pay for context with inaccuracy and with tokens, of course, so there is some flexibility you need here, but you’re not even aware when it’s here and when it’s there. I’m kind of listening and thinking, first of all I have a development background, so I can kind of follow this conversation, and our listeners as well, maybe I’m wondering.

Eyal David: [07:56] Today this isn’t a discussion that’s in pro mode, so it adds another layer of complexity; I’m adding another layer of conversation and suddenly, basically, we’ve also taken the episode there, I think. The change that’s happening in the product role and the R&D in development, for example. I’ll just, in baby steps, jump there—who do you think your audience is, who understands these two segments? In what size of, say, if it’s a solopreneur, is it even someone in a company, and it could also be product and R&D; what does that look like? I think at this stage there’s something to say: these distinctions are getting a bit blurred with its world.

Who Dazl is for and what happens to Product and R&D roles

Nadav Abrahami: [08:39] I think Dazzle is aimed at people who want to hold the technical complexity of their project. Really, if you want to do something in Prompt 2 now, it will work great for you in Dazzle; it’s not that it won’t work, but that’s not what it’s for. I think when you come to build something a bit more complex and you want to really understand what you built, how it works, continue refining it further, both at the visual level and at the technical level, that’s what the tools we give provide. And at this point I’ll also go back to blur things a bit. I know a lot of product managers. Who hold the complexity of their system at the level of the big constants, at the level of “here I keep this and here there are many of those,” and they more or less know what the shape of the thing is; they don’t know the code that deals with it. But if they know, here store data like this and it contains this information, and here store data like that, and I have an action that adds here and there, they have a superpower. Okay, a product manager who doesn’t really have an understanding of the technical complexity of their system, neither in the group nor in vibe coding, has to keep asking all the time. Can this be done? How do you do it? How do you do it? A product manager whose superpower is that they come and say, I want it like this and like this and like this and like this—obviously it works, now give me the price. That’s a superpower. It’s the same thing, it’s not going to change, and it’s true in the world of AI product managers too. Their line and a developer’s line is going to blur a lot; expand on that, where do you think this is going. I think in the end the separation is going to be almost artificial. Who’s allowed to go into the code and see that it can be integrated into my product, and that too only until there’s some AI fidelity or some processes we’re sufficiently confident in. Of automatic experimentation, then checking the result, and so on, where you don’t need this vision of... Products like that are ultimately the vision of AI. That you’ll receive a feature request from a user. It did beta testing opened for this user tool with this feature, and if it’s good, maybe afterward it will open it to everyone. In marketing, for example, we already see things like this happening a lot; in complex products it’s still a bit far off.

Eyal David: [11:14] That’s it, so I want us for a second to, yes, look at this, stop here for a moment, park here for a moment—so what does it look like on your side? You mentioned before, so I understood that it’s basically a group that’s been running together already since Wix, right. What does it look like on your side? What do these roles look like on your side? There’s already quite a lot there, quite a lot.

How Dazl uses Dazl inside the team

Nadav Abrahami: [11:41] We have one Daazel tool that edits not only with the Yala, but visually too. And Daazel is built on Daazel’s stack, of course. I mean, we edit Daazel a lot visually in Daazel; Wix people and product people make changes. They add a feature with Front so that later it can go to people; we have the privilege that our product handles this very well, and our product too. It gives everyone on our team a much stronger superpower: they can really edit the product itself, make a feature, test it locally, see that it works properly for them, and all of that is done with Daazel on Daazel. That means the whole thing has become very blurred because of that, so I also say we have... We have people who develop, and we have a lot of technical work that is features that are not necessarily always user-facing. They’re also developed with AI; a lot of product managers will talk about the server monitors and decide to write code for them, no matter which platform you give them. So it’s clear that there is some kind of separation here, and it’s not just artificial; there really are a lot of things that need to be done that are just infrastructure and infra and so on. And a lot of complex systems that you don’t want everyone to touch, but those people are also, in a way, gatekeepers right now, because all those complex systems... Receive PRs from other people, receive the fact that a product manager can suddenly add a feature. We took one of our most technical people and made him Product Officer; that also helps blur this whole thing, because of course he’s pushing code in all directions. And not just him, also his people, and I think that’s very much the direction it should also continue to go in. There will always be features that you’re hesitant to touch; I’m not saying that in every organization, everyone should be pushing code into it. There need to be gatekeepers, mainly. But if it’s mainly gatekeepers, that doesn’t mean every feature, even in the most complex areas, should suddenly come only from them; anyone in the organization can suddenly sit down in a vibe code a feature.

Customer requests, long tail and pluggability in the AI era

Eyal David: [13:56] So maybe expand on that, because you also didn’t mention it for nothing regarding a request that comes from a customer, and in fact I heard you talking about it somewhere else on LinkedIn, so maybe expand for a moment on the issue of customer requests.

Nadav Abrahami: [14:11] Delivering a feature from there is something we’re working on at Daazel; we haven’t launched it yet. My belief is that today this is true for almost every product. I always heard the fight between people looking for the simplest version of the product and people looking to support the whole long tail of all the features, and in Wix with millions of features, you suddenly discover use cases you never imagined. I wouldn’t say just niche areas. Not everyone now needs, for their e-commerce store, a 3D editor for homes because they’re selling parts of homes; that’s niche. But it’s important now. Obviously, it’s impossible in a product to handle all those things and still have the product remain coherent for the user who comes to it; you can’t handle everything, but here, not only today, plugability entered the picture. That’s pretty much what allowed Wix to do verticals, actually. App market can handle far more user cases that otherwise it couldn’t handle, and yet every time they want to add plugability to a new place and a new product, I hear product managers saying: Who will use this? It’s not even developers. The people who use the product, 80% of them, those 20% are not committed enough; they won’t now learn our API and write a plugin. No one is going to make a plugin for that. Why develop it? And today the answer to that is simple: today it’s vibe coding. You can put your API into the context. You can now give a feature button in your product and let the user decide what the feature is. Of course, it’s not that simple: where does that connect in your product? Are you using vibe coding then, or are you connecting... If your product is not already vibe coding, then where do you bring that piece of vibe coding from? A million other things, but those are a bit the smaller questions here, because even if you say, okay, now take my plugin project example. Edit it in whatever other vibe coding tool you want and send it back to me, and you have a plugin. For the long tail of your very committed users who really need it, that’s enough; it’s no longer an all-day dependency. Editors don’t need to go look for a developer now to do it for them.

Eyal David: [16:34] You can give them something that’s much more tailored, and they can close the long tail for themselves. No, I completely agree. I’m still waiting for features in Wix somewhere to be written up and discussed, and so on. No, I’m joking, and it sounds great to me. I’ll ask you then, really, a question: let’s go back to builders and this world for a second. I usually ask here about product skills, okay? What do you think are the most important skills today for a builder?

The most important skills for builders today

Nadav Abrahami: [16:59] For a builder, I think the first thing is to know well what you want to do. It’s to know how to do the research, and I see a lot of startups, by the way. You go to them many, many times and you see that there’s something there that is about product-market fit. Most of the work to get to the point where there is viability at all—the work on that has become much easier today—but I think it’s true for every product builder. I see startups that came in more prepared and less prepared, and that’s very significant. That’s true. Understanding exactly what you want from it, from the user stories, doing the research for it well beforehand—I think that’s one of the most important skill sets. The second important skill set isn’t a skill; it’s patience. I think there’s something about sitting down and investing the time, whether it’s in research or in building, that makes it very easy today to fall into this of “I’m doing.” A prompt in five places, take what looks good, and I keep going with it. I didn’t think enough about what I’m doing now. I’m not saying there isn’t room for that—there is plenty of room for that. I remember an important stage, maybe part of the research. But it’s not like you start that way and continue that way. It’s more stages in the research, and I think that’s also the right way, by the way, when working with these tools—working in stages, knowing. To cut out a conversation, trim it, even say, save it for me in a file. Yes, I’ll talk about this conversation later; save this information for me. That’s how it works: this piece, I decided in the product, this piece of work—by the way, it’ll work for you on any platform in the world, probably. But the ability to do some internet and prototype, basically with patience, yes, go through these pieces. Yes, to do fine-tuning on these pieces before you continue with the rest of the development is super, super essential in this place; it also hides understanding the technical side of the product.

Eyal David: [19:17] I’m taking something from what you said; I’m also interested in what new skills maybe are needed regarding this, but in a world like this—we talked about a validation stage—but wait, I’m taking it one step further to ongoing work. In a world like this, where delivery becomes very fast, it’s more okay to make mistakes, right? There’s always some stage where I do take the time and pin down the problem, and as you describe it, that’s very much so. But on the other hand, now you can move much faster.

Speed, experiments and product bloat

Nadav Abrahami: [19:46] You can move fast; the question is where. Okay, I think it’s right to move fast in eight directions during the ideation stage, but I don’t think it’s right to move fast with eight features into production. Like I said before, there’s the issue of Blot; there’s a reason for it—X, there are many more than one editor. Whoever does everything in one editor, nobody understands it; the kind of product chaos that’s created by trying to do everything in one product. It works maybe if you did plug-ability and App Store before; if you didn’t do plug-ability and App Store, it’s better to add one good feature than eight mediocre features.

Eyal David: [20:21] I agree; I’m taking a different direction. I’m saying, okay, we have the problem. Right now there are all kinds of ways I can propose solutions in; I can apparently sample those solutions and see what sticks best. I don’t have to pin down, thank you, be very right in the specific solution, because that’s the resource I have to put out, and I can’t dictate.

Nadav Abrahami: [20:41] I agree; I think you have a lot of resource here, but I mean, you have the very important resource that is your users in the end. If there are two solutions to a problem and you’re not sure between them, then an A/B test can be a great way to talk about it, and it really is cheap enough that you can go for it. But you also don’t want to expose them to 80 features that solve the same thing for the same user, so there’s some sensitivity there, of course.

Eyal David: [21:07] Yes, well, this is already the world of A/B testing and who gets exposed to it and how much traffic there is, so let’s move for a second to the new skills; that’s very interesting. What new skills do you think builders need today that they didn’t before? For example, you touched on it—developers suddenly need to understand the business logic. They need to understand the problem better; maybe there’s also an element of soft skills entering here—they suddenly need to interview people, like, I don’t know, I’m trying to think how I do validation.

The new skill: managing context for the LLM

Nadav Abrahami: [21:38] I think that once you take it in the direction of a builder, then first of all, of course, the connector. Everything a developer ideally needs to know, and everything a product manager ideally needs to know—so both of them have a ton of new skills, no doubt; developers who want to be good builders. And to take it into it, they need the soft skills; they’ll have to talk to people, no matter how much they don’t like it. And I think product managers don’t need to know how to write code, but their direction is to understand the product technically and more than that. To help them—the biggest problem of the kids today is context. You’ll hear it all the time, even if you’re in any one of the companies building these tools, you’ll hear this debate all the time of: More context versus less context—it’s very close to what we talked about earlier with features because they have it, it has. How much content it can consume before it starts to sweat and runs out of room, and so on—every tool you think of for them. Every prompt you think of for them, every piece of data you expose from the project to them, you pay for it; there are all these around-the-edge solutions, none of them are perfect. In the end, when a developer works with vibe coding tools, tools like Cursor, with v0, in agent mode. He does the same thing for specific files. He says, here I saved your provider; this thing looks like it, and here is your provider talking to the database, and here is that provider. He doesn’t let the AI waste time now searching for which provider it is, if it needs one, and so on; instead he very... carefully makes sure the provider was there; that’s the first step, of course, otherwise it doesn’t appear anywhere. It’s some kind of backing for AI processes that says, yes, this really covers what I want. And then he basically links that provider every time the conversation relates to it. The power of this power, of working like this, and basically building the content for the AI, is the strongest power in code editing, because the hardest problem is the context problem. If I can manage that context, I can generate the pieces of context that matter to me as pieces that later I will buy the data. This is one of the things that are very, very, very important. Now there are tools that do this better, worse, of course. We’re going to do it the best in the world. There’s already something there, but I think we’re going to improve it a lot. But there isn’t a tool you can’t tell now, in coding tools, “write this for me as a Markdown file, just for the project.” Basically some textual file that can later be referenced and read. There isn’t a single tool that won’t let you do that. And this is also very important because a conversation goes on, and on, and on. Here I suddenly save important topics in files that I reviewed, so it can’t get confused with the message before it was perfect, and also after, when I said to fix it again afterward. It looks at all of us the same way. Ideally, you don’t want the wrong messages in the context at all.

Eyal David: [24:35] I very much agree that this is the direction it’s going, and that you need to be much more technical. And I’m kind of thinking as I go, I’m briefly coming back to this—how do I get back to your team? It made me think for a moment how you avoid always having too many cooks in the kitchen. That suddenly everyone is basically a builder—how does democracy even work on your side? Is it democracy at all?

Managing a team when everyone can build

Nadav Abrahami: [24:58] It’s not democracy. We have milestones that we plan, what will be in them, squads that develop the things. A lot of tasks come in on top of that—I won’t say they don’t—but most of the development... he reads like this: there’s a lot of vibe coding within these teams, a lot of product managers working with them on the team. The team has already turned the prototype into the product, or not into the product, or into the product but... directly on Dazl, or in the product as a separate prototype. And they’ll make the end of it for this thing, and from there they’ll write it. That’s basically how it works with us right now. There are a lot of small features that can come from the fact that our R&D lead, Wix, will come and make a prompt that adds some button, changes something. Or our product lead, Barak, sits down and makes a prompt that does something completely different, but that’s not most of the development.

Eyal David: [25:55] So, good, divide it like this, just—I’m saying, you connected 90 messages, for example. 10 things, 10 percent of things that basically go up to the installations, and there isn’t a critical path there.

Nadav Abrahami: [26:06] Of course, the critical path too—you know, it’s a very similar panel, it’s not very different. It’s just that we have a user request issue; first of all, that’s critical, these things basically go through in the end. Some of them are team milestones, and some of them are more, if we have free time, we manage... ...to add another one or two small tasks ourselves, people who aren’t part of the teams.

Eyal David: [26:29] Got it, good. So I’ll go back for a second. We’re kind of going back and forth because I’m trying to weave in questions that really, as we said, are a bit different—actually your teambuilding. We started there. First, if you can expand on that and on how you work with the roadmap, what it looks like, for example—do you have a goal that you’re driving toward, what does it look like?

Roadmap, milestones and what really changed in the process

Nadav Abrahami: [26:48] We have a roadmap, of course. From the roadmap, every time we cut out milestones of about a month to a month and a half. Which basically divides it; we have several squads in Berlin, Israel, and in the lab. How many people do you work with? 32, okay. I’m turning a little; tell me if I’m wrong. Got it, roughly. Those teams basically take it, they give us a demo, an update and a demo every week of their progress.

Eyal David: [27:24] I mean, you’re describing a pretty regular process. I’m trying to hear whether I’m seeing something a little different.

Nadav Abrahami: [27:29] I think the process hasn’t changed; the tools have changed, and its speed has changed. Meaning, the research and the content coming out—the research product manager to the teams—have changed completely, as has the way, and the output, which is often already an output of code inside the project. A lot of times it’s a separate prototype, but it’s always a functional prototype. That is, it’s something that obviously we didn’t have in the past: a functional prototype for every small feature. That’s a capability that only opened up thanks to the world of vibe coding. After that, I say it passes to the developers, but yes, the developers work with AI tools. Most of the code is written with AI. I think the biggest challenge right now in development teams, naturally... is the control over it—that’s exactly my problem, yes, I mean... You very much want to make sure that even if someone didn’t write the code, someone who reads the code at least understands the code. By the way, I very much see the need there. I see what we’re building. The more it reflects to me of the code and how it will save that time in the same review, and also, most of the thing is not reading the code—it’s understanding what the substantive change that really happened in the system is. It can be understood textually, but I think as a textual form.

Code control, tests and gatekeepers

Eyal David: [28:49] It does it a disservice; we talked about context. Where exactly was the focus? So he was talking exactly about that; that's what they do, and if we even go further in terms of, like, how it looks.

Nadav Abrahami: [29:01] In terms of because we have a team that does, like, we obviously also have all the automated tests. This team also builds automated tests to close this out; we use a lot there, by the way, of course, and there too the vibe coding does an excellent job. Sample MCP and you let them write the test, then you look and see that it makes sense; there's no doubt it sped up all the processes, but. The truth is that there is a real challenge here, mainly around control—how do you let everyone put code everywhere into the system. In the end it will still be a system, so how do you handle it on your side? So on our side right now it's still at that stage; this part is very traditional, this part is. Automated tests that make sure there are tests for all the pieces of the system. A human review process by another developer who goes through this code, and a lot of times you'll see there. Listen, bro, I wrote this with AI; you can see your tests are with AI—you didn't even go through it and gave it to me for review.

Eyal David: [30:03] You mentioned the gatekeepers all the time, actually, just now.

Nadav Abrahami: [30:07] Right, because there's an issue there; depending on what system you're building and how complex it is, how much you need that and how many people are involved in building it, that's also important. But the more complex the system is, the more architectural oversight you want. And the more you want to understand that things are being built in the right direction—that's one thing; the second thing. It's very good at generating unnecessary code; the problem is that its context window is too small and it doesn't hold the whole project at any given moment. Without a doubt, and it requires a lot on the technical side. Right now, I feel like we're lacking product.

Onboarding, architecture and the complexity of large systems

Eyal David: [34:45] This product is no longer enough; there are fewer and fewer features flowing through. I'm basically trying to understand why—why not take one of the developers and make them product, for that matter, from today on. First of all, he comes from Wix, so okay, he comes with some kind of product experience, right? But why not use that if everyone is basically builders?

Nadav Abrahami: [35:08] I think not everyone. Some of them want to, and I said "prompt"—I'm not necessarily saying to hire from outside or from inside. Right now, the way I see it, and I looked at the people we have besides you, there’s one I can say is really one or two who are developers, but... Who right now want to be product more than they want to be developers, I don't see that we have a lot. On them, I can't give up where they're developers. And developers there too—they're builders, if there are any. They also care about product, without a doubt. Meaning, to say they suddenly aren't developers because of that, only product, of course not. What I want more than that are people like, say, our Alexey, who manages the team at Leviv. He's happy that I have a product for any piece he wants in the product—I truly trust him, great that I have that too. But he's also a team manager at Leviv; I can't see that as a reason.

Juniors in a world of vibe coding

Eyal David: [36:10] So hold on, I'm going back to the juniors, because we really talked about it—where do you see it? What should juniors do now in a world like this? How do they actually fit into this whole builder world?

Nadav Abrahami: [36:21] The first thing is that for juniors, there's a much more fun world to become seniors in. Let's start there. I started programming with visual parts, predecessorores... From that, I could do designs; I have no more drawings, more games from that, and then I started adding interaction—interaction and the interaction—and a little bit more logic, and recipes. These tools are tools that help learning in an unbelievable way, a superpower I didn't have there until I started. A lot of these things I had to invent myself, or even find on the internet—I couldn't really. And today, really, I think the first thing I'd recommend to anyone who wants to be a developer... Is simply to build things. It's super easy now—you can go to tools that do a lot of the work for you, and they'll also explain what they did, just ask. They can break it down for you, explain how the project is built, what's in it, why they made those choices. It won't always be right, but it'll teach you a lot. That means that suddenly, the main thing I can say is a junior who, in one day, has a résumé of vibe-coded projects... I wouldn't take. I have Barak, the developer who is now a Product Officer with us; he opened for him not too long ago, actually he's a builder. When he came to the interview at Wix, it was after a year of building at home a synthesizer application. Some incredibly sophisticated system of synthesizers with capacitors, and to build a real synthesizer app that you build yourself—you see the Barak. But you see a person who came super motivated to learn; the interview was super. I asked him, are you sure you've only been programming for a year? I think today, a person who doesn't make that extra effort...

Eyal David: [38:31] That means... Ramon, in Barak's story, amazing—let's lean into that even more, okay? As mentioned, now everyone will use this tool; everyone is creating some kind of portfolio for themselves. I’ll point out where the emphasis should be. We have, if we said there are two ends, there's the technical one—the technical mindset—and there's, for example, you can now go use Cursor to write my code, and I'm going to Base or Lovable to write my code, but also Dazzle. Also Dazzle, definitely—that was the continuation of the sentence. But on the other hand, I can go and really focus on the business side of the thing and go to Dazzle. I'm asking about this: what do you look at more? What impresses you more in an interview like that?

What to look for today in builders, PMs and developers

Nadav Abrahami: [39:13] Listen, in a PM interview, I think understanding why you do the feature is more important than how the feature looks. Understanding what user stories... That come with the feature, understanding why.

Eyal David: [39:29] It's very easy to ask for features in the world of juniors, where basically, you know, it's almost impossible right now to get into the doing. Let's say we're looking for, you know, someone who's an assistant, an assistant. Let's say if he's a junior or she's a junior, then we probably don't expect too much in terms of background or, like... Let's look at it as a builder, for that matter.

Nadav Abrahami: [39:55] It doesn't have to be a developer or a product by definition. I completely understand, but I'll say it like this: I still hire for those roles separately. Is that right? Yes and no. There's a gray area; there are places where it doesn't matter, and as I say, in the end there are developers who are also the product and the developer. And today I call them developers, but they're builders, and of course we have a few more like that who would love to build the next thing they'll get to use in that sense. But I still hire separately. Also because the passion is a bit different; that is, there's friction in being a developer that's a different kind of friction. It's a different way of life than still being a product manager, unless you're in a small company or in some role of building everything yourself. There is still some separation in what you're expected to deal with. I expect my product manager to know the market; I expect them to know what's happening outside, why a user is asking for something, what they meant. Which user stories are related to going with a feature, which user stories from the things users asked for and so on are related to this, and so on. There’s a ton of research that needs to be done, and a lot of passion on that side. It’s on their side to discover what users need and then design the flows from that. There’s another side. The other side is much more of a product manager role, much closer to the builder side: taking it and now really planning what this thing looks like in fine detail, what this feature looks like. That’s already much more somewhere in the world of builders. The clearest boundary I’d known in the industry before was between PM and UX, so I admit this already competes with that. If I’m talking about this builder, then what’s most important there is understanding the clay you’re working with. It’s your project; the type of technology in this world doesn’t mean knowing how to write the code, but it does mean knowing what’s possible, what isn’t, what’s easy, what isn’t. To steer it correctly, and in development there’s the other side of friction, the other side beyond the builder. Their side is making sure it works without edge cases. Passing tests, matching code standards, not creating duplication with any code elsewhere in the project, maybe laying the groundwork for similar features that will be needed in the future and are already known. There’s a lot, a lot of thinking there that also needs to happen, a lot of work that needs to happen. There are cases where people do both sides brilliantly and then they ship features end to end and that’s amazing, and I’m not saying otherwise, but I can’t hire only those people. Among other things because what I’ve seen is that sometimes they don’t have patience for all the polishing. More tedious in some tasks, at least in development.

Eyal David: [42:52] And I have to say, as we say, I’m glad we opened these parentheses; what we’re, okay, the juniors will forgive us, but what we understand is that right now there is this difference. I don’t know how long it took, but meanwhile it’s written and written, so if we go back to the cooks thing, then right now there is. A clear distinction, in fact, between the sides.

Nadav Abrahami: [43:16] In most cases, yes, in most cases there is a clear distinction, and I also hear, on the one hand, I hear developers telling me. You’re telling me to build a feature and you’re not giving me a product—what do you want me to do? I mean, there are still developers who don’t accept this blurring somewhere. Above all, in my opinion, they just don’t want the evidence to be a decision based on the product.

Eyal David: [43:39] That’s very true; let’s do it this way. Overall, it was very successful from my perspective. We also covered a lot of the questions people asked in the community. If there are more questions, of course write them in WhatsApp and we’ll pass them along, and Nadav will try to answer—Nadav, regarding your product. You’re so open, you can sign up, so maybe tell us briefly who this is most suitable for in the first steps, what’s the easiest thing you can build with it that will provide value.

Who Dazl is a fit for and where to start

Nadav Abrahami: [44:08] You can build everything with it; that’s part of the problem with these tools. I mean, it’s hard for me to tell you that you can’t build it. Because with enough prompts, probably anything that exists on the web you can build, but let’s start with this: you can build anything that exists on the web. From a prototype to a full application, connecting external services—those who understand a bit more technically really get a backend there, meaning you can connect to any service you want. I think our strongest power is in the inspection tools, in their tools, to really understand what’s being created for you with AI. You’re welcome to play with them; it’s under the Dev Tools. A button on the right side and the visual editing tool, which allows you to fine-tune the visual output much more precisely. Great.

Eyal David: [44:56] I hope you come back to us in a year and tell us how you’ve progressed. It was a pleasure. Bye bye.