The Front-End Engineer’s AI Playbook: Real workflows to build great Products.

Venkata Vemuri at UXDX Community: The AI Edge: Prototype Real, Ship Smarter. Video: https://youtu.be/nKNSqJudHHY

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Everybody thinks they can do everybody else's job

[00:00:08] Venkata: Before I go on: with the advent of AI, ChatGPT and all the coding tools like Claude Code, Codex and others, everybody starts to believe they can do everybody else's job. The product managers think they can write code and that they can also design. The designers, of course, who do most of the design anyway and know the product in detail, also believe they can do product management and start writing code.

[00:00:48] And as engineers, since we are writing the meat, the most important part of the product, we also sort of believe we can do business and also find some good design for the product. And the fact is that everybody is true. Give me one second. Yeah, the fact is that everybody is right to think that way. Why? Because of AI, because of the LLM models, the bar to do anything in technology, or anything at all, has become so, so low.

English is the new programming language

[00:01:32] Think of AI as another layer in the industry. If you think about how compute started in the world, we started with a transistor, and then we had the computer chip. The computer chip was like a wrapper of a transistor, and once the computer chip was here, nobody was going to go and validate whether the transistor was actually doing the right thing. Then, once the computer chip was here, we built assembly language, and then we built the C programming language.

[00:02:06] We had the C programming language for a very long time. It's a low-level language, and when you write code in C, nobody's checking whether the C compiler is doing the right thing or not. You're just debugging. If something fails, you try to write better code, maybe more efficient code, or write your algorithm better, and move forward. After C there was C++ and Java, but C++ and Java were very incremental improvements on whatever we had in C. Python was a significant improvement on the C language.

[00:02:41] At that time I thought Python was almost English. Anybody, even with a non-tech background, who never did computer science, would be able to pick up Python within a day or two. It's a very readable language. People thought this was it, and that's probably one of the reasons Python had so much popularity in the world.

[00:03:04] But after that, in the last two or three years since ChatGPT, the new language of code is English. Andrej Karpathy, the famous machine learning or AI engineer who built the initial versions of ChatGPT and was head of Tesla AI, wrote a tweet saying English is the new programming language. That is actually true. Just like we had C, Python and all these things until now, English is now that language. When you tell the model something in English, it is able to do whatever a compiler used to do maybe five or six years ago.

You don't need another prompt

[00:03:43] That's why everybody is coming up with all sorts of prompts to build web applications, or to make the AI do stuff for us. But I personally believe you don't need another prompt. In the last two or three years, everybody has come up with tricks for prompt engineering. But that changes so fast and so frequently, because the model is adapting to you faster than you adapt to the model.

[00:04:18] So if you don't need prompts, what should you do? I would just recommend everybody sit with ChatGPT, or any model you prefer, and stupidly talk to it for a very long time. Ask questions repeatedly. The good thing about AI is it never gets tired. It works for you 24/7, and it has no ego issues. You can bother the AI as much as you want and as many times as you want. So the limitation here is your persistence and your time. Those are the only two limitations today.

[00:04:55] Let's say you want to build a rocket with AI and all the tools around you. The limitation is not your talent or skill set or IQ. The limitation is the amount of time you have and how long you're willing to persist to learn how to build a rocket. As long as you have that and stupidly talk to a computer, you'll do a good job. And you don't need any of these fancy prompts, because, within a year, I've seen, and we use all sorts of models for our day-to-day engineering, the model is good at adapting to you, and quicker than you trying to adapt to the model.

[00:05:34] So when you start a conversation, the model will understand you better than you trying to learn another skill set like prompt engineering, the tips and tricks, all these books people write about how to talk to the agent. Just imagine the AI is another friend, and talk to your friend who knows pretty much everything, like God, and it'll probably give you most of the answers. Of course, you have to take it with a grain of salt, because not everything will be factual. The models do hallucinate, they are politically diplomatic, and all of those things.

[00:06:13] But when you stick to engineering and you're able to ask repeated, clear questions, like an architect of a team would, you're probably taking critical decisions, and to take those critical decisions you have to repeatedly ask the right questions. So imagine you're the architect of your app and start asking those questions.

Do the basics right

[00:06:35] As I said, there are three parts to building a great product. There's product management, who come up with the initial PRD. Think of the PRD as the initial prompt to your web application: the initial instruction for how a web app is built, what needs to be enabled and what not. Then comes UX design. I'm sure the audience is leaning towards designers here. Designers, you know that when you build a product you ask all these clarifying questions. Now you can use AI to do the same thing.

[00:07:17] In the following slides I'll explain the specific ways to do it and how to leverage AI: how to think in terms of workflows. These are not prompts. I'm not offering you one more prompt; I just said prompts are useless. I'm just giving you thoughts, or ways to talk to the AI model, so that you can build a great, accessible product. And the third, last part is obviously the engineering part, where you do system design and all of those things.

[00:07:47] I used to play cricket when I was growing up, not in the top league, in one of the middle-level leagues in India. One of the coaches always used to tell me: playing cricket, being good at cricket, is all about doing the basic things right. Look at the ball, hit the ball. That's it. Those are the basic principles. No matter how good or bad you are at cricket, the basic fundamentals remain the same: look at the ball, hit the ball. And you can probably imagine, these are the three or four different variations of balls I would probably get, and this is how I'm going to handle them. Having said that, you just have to do the basics right.

[00:08:28] Even with the advent of AI, I would argue that engineers, product managers and designers can't be in their niche anymore. Everybody's considered a builder. If you think of yourself as a builder, and what you need to do to build a great product, I think that completely changes how you think about vibe coding and all these things. Of course, vibe coding is bad when there is no review.

[00:08:56] But if you know the basics and can do the basics right in product management, in design thinking and in the implementation of your software, and cover all the bases in terms of security and close all the gaps, I think you can build a really good product, on par with most industry products, while vibe coding it. But you need to understand each of those disciplines very well.

Starting with the PRD

[00:09:28] In terms of the product requirements document: whenever you want to build an app, a lot of people might have used Replit. Replit is an online coding tool. It's a place where you say, "Build me any idea you might have." Let's say I've always wanted to start a pizza place. If you go to Replit and say, "I have a pizza place and I want an online presence for it. I want people to be able to order pizza from a menu," and give a couple of requirements, within minutes it's going to pick a random design, unless you specify a certain design, and build the application for you.

[00:10:12] And that's pretty good for a pizza place. You don't need a highly secure web application. Nobody's going to hack a pizza place, so you don't need a high bar on your cybersecurity. But even then, if you want your pizza place website to go from maybe a four out of 10 to a nine out of 10, you don't need engineers or designers or product managers around you. You just need to ask the right questions. You need to do the basics right, as I said earlier.

[00:10:44] When you start, you should start with a PRD, a product requirements document. You have to ask these questions. You're not limited to these five, but they give you some boilerplate questions. Once you've asked these questions, you can obviously talk to the model and ask it to interview you for more questions, or any other requirements you might have missed.

[00:11:09] Let's start with the first one: what problem are you trying to solve, and does it actually exist? In our pizza place example, you have to write that down on a piece of paper, or open a notepad, and write down all the thoughts you have to answer that question. Then: who is this for? You need to identify who your user is. Who are you targeting? Are you targeting local customers in your own zip code, or a wider area, where anybody can order pizza from anywhere else? Because you have to think about those things. Somebody from India could order a pizza in the USA and scam you, and you don't want that to happen. You want to think of all these possible errors, gaps and requirements before you even start a product.

[00:12:08] What outcome should change? Once a pizza is ordered, what should it change? Should the number of steps to order pizza be fewer? Should the user be able to order with one click? Is there a popular pizza item that everybody buys, and do you want that to be a one-click order? Do you want users to save their credit cards on your website? If that's the case, you have to put a lot of investment into cybersecurity. All of those concerns come into play.

[00:12:37] When you start answering all these questions, the good thing about AI is that you don't need to have the answers. You can ask for more questions. Let's say, "What are the trade-offs of having credit card information on your website?" You talk to the AI, and it will give you three or four reasons why you should or shouldn't, or what the cost is when you invest in a credit card exchange.

[00:13:05] Off the top of my head, the basic rule is that if you have a stored credit card, there's a higher chance of people buying pizza. If there's no credit card, it decreases the number of people who buy pizza. But at the same time, you have to invest a lot in cybersecurity so that nobody can hack into your database and grab all that credit card information, which is vital to your product. So you need to ask these basic questions. Again, going back to my previous point, it's doing the basics right.

[00:13:37] I just want to check the time. Okay, I'm 15 minutes in. Sorry about that; I just wanted to check how much time I have left. Once you jot down all those PRD requirements, and it doesn't have to be in a structured format, just simple raw text, and give those inputs to the AI and ask it to generate a PRD, it will generate a very good PRD. It goes wide. When you start generating the PRD, you want more breadth. You want to hit every bar, all the different parts of a good PRD document, and all the different questions it asks. You have to answer all those questions.

[00:14:20] Once you've filled in those questions, you go into depth. You go to each section and add more and more information. If it offers you a solution, ask the AI, "Can you offer me multiple solutions, and what are the pros and cons?" And then you just have to be the judge in answering each of those questions. Ask the AI what the success metrics are, and then decide whether you agree with them or not. If you don't agree, ask why, and what else you can do.

[00:14:48] And here's a trick: once you complete all of it and have built this great PRD, the primary document for your web app, just change the model, or go to a different model, share the same PRD, and ask, "What are the gaps in this PRD?" It will give you a new perspective. You can do that A/B testing and come up with a very good PRD, and I think you'll be on par with most product managers in the country or in the world. It won't be the top 5 percent, but it will be pretty good. And you did that in a day, or if you're fast enough, maybe in an hour or two.

Proof of concept and design

[00:15:29] That is what I'm talking about. Once you have that PRD, give it to ChatGPT or whatever model you're using and ask it to generate the web app. It builds the basic web app by vibe coding. This is not the actual production website; this is a POC. It will generate some bad code, but it doesn't matter, because you're trying to do a POC. You're trying to work out the user experience, ask more questions, iterate and get to a final point. Maybe you initially thought a drop-down would make sense, but then you realize that instead of a drop-down you can give four buttons, and that will be easier to pick than a drop-down. Things like that. All the things you hadn't thought of initially can be thought of by the end of your POC, and you put all that information into your PRD.

[00:16:11] Once you've done the PRD, you move to the design phase. I don't have to preach to the choir here. Sorry, I think you can still see the screen. In the design phase, you need to ask the basic questions. There are certain fundamentals in design: atomic design, what does this mean to the user, how does the information flow across the multiple pages of the website, is there redundancy, are there multiple buttons doing the same thing? Stuff like that.

[00:16:47] The great thing about AI is that if I see other pizza places with great design, I can give my model that design and say, "I really like this certain part of a certain page. I really like this workflow; let's use it for our purposes." Then it can update your PRD and your designs based on that.

[00:17:13] But again, one of the big things designers know by heart is that when you build a good design, you need to think in systems, not in screens. Twenty screens doesn't mean you have a great pizza place website. Even if it's one or two screens and it does most of the job for you, minimalism is the best way to attract users. Make sure it's responsive on all devices, and stuff like that.

[00:17:47] There's a famous quote from a designer I worked with at my previous company. As a front-end developer, he always used to tell me: the litmus test of a great design is whether the decisions are constructed as a system of decisions and not a collection of screens. So, just a hack: if you go to a designer and they throw a couple of screens at you, they're not the right designer for you. That's my take on it, but anyway, let's move on. Once it generates the initial designs, you can talk to the AI, map the data flow, and make sure everything works well.

Engineering: plan, review, execute

[00:18:27] Once you have the designs and the PRD, that's pretty much 90 percent of the work done. Before ChatGPT and the Codex models, that was only 10 or 20 percent of the work. But now, because most of the implementation is automated, or reasonably automated, and since you are very clear in your PRD and your designs are very clear and have been iteratively designed and mocked up, you give that information to the same model and say, "Now build an application." If you're not a programmer, you can say, "Ask me about all the architectural decisions you're taking, and if I need to make a choice, explain the options to me."

[00:19:14] When you build a great front-end product, there are certain basic system design things you do need to know. The first one is state management. Before you even go to state management: how do you build the design? Does the web application have multiple pages or just a single page? If it's a single page, there are different trade-offs you have to make, and if it's multiple pages, you have to persist data across pages, and how does that work? If you don't know, ask these questions to ChatGPT or the model, and it will actually give you better answers than you would imagine.

[00:19:54] Ask all the questions. Ask it to give you a good architecture for the implementation plan. Read through the implementation plan. If you have credit cards being pumped in for authentication, ask if it's secure enough. You should be worried about security in a lot of things. This is all planning and architecting.

[00:20:17] Once you're done, the code itself will figure out the right package to install, the right hooks, how to make the API calls, how to configure the database, how complex the database should be, how future-proof your system is, and all of those things. All those decisions will happen based on your basic architecture diagram.

[00:20:39] Just like what I did for the PRD and UX, once the initial code is generated, your job is to build the plan, review the plan and execute the plan. Sometimes, when it's a really large web application, it might take a long time to execute. Then you should probably ask it to spawn multiple AI agents and do it in parallel. You'll be a glorified QA. Everybody calls it human in the loop, but you'll just be a glorified QA [?]. You can do all of this within a couple of hours. Earlier, it used to take months and weeks to complete a simple POC and get everything right. Now it will take you just a couple of hours to get to the same place.

Accessibility, testing and telemetry

[00:21:32] Then accessibility. This is a passion project for me. I'm an active member of the W3C accessibility group. Only 4 percent of all the websites on the internet are accessible; 95 percent of websites fail on basic accessibility. That's primarily because it's a lot of cost to engineering when you want to be compliant. It is very expensive, and you need a lot of resources to implement it. But with the advent of AI, 90 percent of that is automated. You just have to worry about certain modals, or certain overlapping animation issues, where you have to be more particular, but most of your code can be accessible. So now you're building an accessible website as well.

[00:22:17] Then you should ask it to write all the testing for the web application. There are four or five kinds of testing. You just ask it: every component should be unit tested. There should be integration testing, where one component talks to another component well. And there should be regression testing, where whenever you make a change, the UI design remains the same, with not even a pixel of difference. Then you can write all the automation.

[00:22:44] All of this can happen within a day if you really do it. Once you build the entire application and everything checks out, ask it to have 100 percent code coverage for all these tests, and everything will work. You'll have to go through multiple rounds to get it to 100 percent. Maybe it's 70 or 80 percent, and if you're happy with 80 percent, this will do a great job.

[00:23:07] Once you've built the application and your requirements are met, you want to add a lot of telemetry. Telemetry is just adding bugs, like listening bugs, to your application, so you can have some data and make more decisions based on that data. Let's say a particular page is visited more, or a button is clicked more often than not. Earlier, implementing this was a very, very complex process. Now, with the advent of ChatGPT, all of this can be implemented within a day or two. Something that used to take months, a lot of questions and a lot of thinking can now be done significantly faster.

[00:23:43] Going back to my talk, all I'm saying is that one person can build the entire application if you do the basics right. As long as you understand the basics of product management, and you don't need a degree for that, you just need to read some standard articles on Medium or any of those blogging sites about what a great product manager is and what processes a great product manager follows. Or if you don't even want to read it, copy it, give it to your model, and it'll figure it out and ask you the right questions.

[00:24:17] As long as you do the basics right in each of the disciplines and learn how to do it, you can build a great product. All you need to know is whether you're hitting all the bars, and whether your bar is nine out of 10, which was very, very hard to do previously. So yeah, that's my time. I'm open for questions.

Q&A

[00:24:43] Host: Excellent, thank you, Venkat. That was a very thorough review of the full end-to-end process. I know there was a lot to take in there for people watching, but I guess that's the beauty of these online talks: you can go back, rewind and rewatch a section.

[00:24:58] Venkata: Yeah. I realized halfway through that I shouldn't have taken the first minutes as long as I did. If I could have saved a few minutes there, the second part would have been much slower.

[00:25:13] Host: But no, the content was great. If anybody has any questions out there, please do write them in on whichever platform you're watching this on. I see that Diana said, "Great talk," and thank you for Stephanie's comment too. So if you have any questions, please write them in. I'm going to start with my first question, and you kind of addressed it as you went on, because you talked about testing, traceability, observability and all of those elements. But I guess the biggest concern would be what Stephanie said: she thought it was great, and then she had a developer look at it, and they said, "This code is terrible. The variables are hard-coded in there," things like that. Is there any advice you have for somebody like Stephanie who's saying, "Where do I even start? Is there a cheat sheet?"

[00:26:10] Venkata: There's no cheat sheet. Maybe for programmers it's a little easier, because our thinking is very structured and we do know what's happening behind the screens, behind the web application. We can tell what's going on. But for a non-programmer, the best thing is to ask more questions. Just ask something like, "I got feedback from a teammate that my code is all rubbish, with a lot of hard-coded values. Can you review my entire code base and apply all the best design principles and the best coding implementations?" It will figure it out and do all of those things. You just have to ask it to refactor.

[00:26:55] The problem is not that she did step one wrong. The problem is that she stopped at step one. She should not stop at step one. She should go to step two and say, "Refactor my code. Identify any gaps." And again, the best way to do it is to ask a different model to do the same job, because the current model already generated the code, so it might have some bias. Even in the same conversation, if you just change the model and say, "It looks like there's a lot of messy code. Can you refactor it, make it clean, make it efficient, make it minimal?", it'll go and identify the issues. You just have to talk in English.

[00:27:34] I would say you should not get confused and think in terms of technicality, but just as an architect. If you're the architect of this thing and an engineer writes bad code, you'll say, "This is bad code. Go and refactor it again." So go to step two. Step two will be significantly better than step one. Then go back and submit it to your teammate. If they say it's still bad, they'll point out a couple of things that are still bad, and you just iterate. You might not be as good as the top engineer. I'm not arguing that vibe coding will get you there, but it'll come pretty close, and that is good enough for 95 percent of the web applications in front of you.

[00:28:21] Host: Excellent. I've just seen a question come in, so I guess you have 30 seconds, because we're almost at time. Ravitesh Reddy has asked: how do I ensure code generated by AI is scalable and doesn't become a problem when integrating with other systems?

[00:28:40] Venkata: Ask that question, just like this, after you've generated it. Again, it depends on what model you're using. If you're using something like the ChatGPT interface to do it, it'll maybe be a little hard. But if you use the Codex desktop app or Claude Code, it's like $20 a month, which is not a lot if you're building a scalable web application. Those applications are built for software engineers; it's not a regular chatbot. They will be able to answer those security issues and how you scale. It'll say, "These are the reasons it can or cannot scale. These are the gaps. Can we fill the gaps?" And then you make the decisions and let it do the implementation.

[00:29:31] Host: Brilliant. I have that exact same experience: just keep asking. I also like the idea of "Where are my gaps? Scan the code base and tell me. Ask me, interview me."

[00:29:43] Venkata: That's right. Maybe the first time you build this web application, it'll take you five days. But the second time, you already know all the bars. With the second application you build, you understand the gaps and you know how it's thinking, so now you know, "We missed this last time." You can have a tracking document and a learning document as well. A lot of people do this: when you build your first app, it writes all the learnings and all the misses to that document. The second time, you say, "These are all the misses. Don't repeat those mistakes." It'll go read it and not do it. It's adaptable.