In Part 1, I talked about Bangla vs English when working with LLMs.
In Part 2, I focused on how to write better prompts by giving the model enough context, clear requirements, and useful constraints.
Now let's put all of that into practice.
Instead of talking about prompt engineering as a theory, let's use a real example:
How would I actually use an LLM to build a website?
The important part is that I wouldn't start by saying:
"Build me a website."
I would build the idea step by step.
Step 1: Start With the Idea
Let's say I want to build a personal portfolio for a frontend developer.
My first prompt might be:
I want to build a personal portfolio website for a frontend developer.
The main purpose is to showcase projects, experience, and technical skills to recruiters and potential clients.
I want the website to feel modern, minimal, and professional. I don't want it to look overly flashy or full of unnecessary animations.
I'm planning to use Next.js, TypeScript, and Tailwind CSS.
Before writing any code, help me define a simple page structure and explain the purpose of each section.
Notice that I'm not asking for code yet.
At this point, I want the LLM to help me think through the product.
Step 2: Decide What the Website Actually Needs
The model might suggest something like:
- Navigation
- Hero
- About
- Skills
- Experience
- Projects
- Contact
- Footer
Now I can make decisions.
Maybe I don't need an About section because the hero already explains who I am.
Maybe I want Projects to get more attention.
Maybe I don't have enough experience for a separate Experience section.
This is important:
I don't have to accept everything the AI suggests.
The model can help generate options, but I'm still making the product decisions.
After reviewing the structure, I might say:
Keep the navigation, hero, skills, projects, experience, and contact sections. Remove the separate About section. The portfolio should stay focused and relatively short.
Now we have a clearer scope.
Step 3: Define the Visual Direction
Once the structure is ready, I would describe the visual direction.
For example:
I want the design to feel like a modern developer portfolio.
Use a dark theme with strong typography, generous spacing, subtle borders, and simple interactions.
Avoid excessive gradients, glassmorphism, giant decorative elements, and heavy animations.
The design should feel polished but still easy to read.
Keep accessibility and mobile responsiveness in mind.
This is where I try to explain the feeling I want.
Because "modern" by itself is too vague.
The extra details give the model a direction.
Step 4: Build the Hero First
Now I can start coding.
Instead of asking the model for the entire website, I start with one section.
My prompt could be:
Build the hero section for this portfolio.
It should include:
• My name
• My role as a frontend developer
• A short introduction
• A primary "View Projects" button
• A secondary "Contact Me" button
Use Next.js, TypeScript, and Tailwind CSS.
Keep the design consistent with the dark, minimal direction we defined earlier.
Make it responsive on mobile and desktop.
Use semantic HTML and accessible buttons and links.
Keep the component clean and reusable.
Now the task is manageable.
Step 5: Review Before Moving On
This is a step I think people often skip.
After the AI gives me the hero, I don't immediately ask for the next section.
I look at it.
Maybe the structure is good, but the text feels generic.
Maybe the heading is too large.
Maybe the spacing on mobile feels wrong.
So I give feedback.
For example:
The overall layout is good. However, the hero feels too generic and the heading takes up too much space on smaller screens.
Keep the existing structure, but:
• reduce the heading size on mobile
• make the supporting text shorter
• improve the spacing between the text and CTA buttons
• keep the visual style unchanged
This is much more useful than asking for a completely new hero.
Step 6: Build the Projects Section
Once the hero feels right, I move to Projects.
I might write:
Now build the projects section using the same design language as the hero.
Each project card should include:
• Project image
• Project title
• Short description
• Technology stack
• GitHub link
• Live demo link
Use reusable project data instead of hardcoding every card separately.
Make the layout responsive.
Keep the cards visually simple and avoid excessive hover effects.
This prompt does something important:
It doesn't only describe the UI.
It also describes how I want the code structured.
That matters when the project gets bigger.
Step 7: Give the Model Real Content
This is another thing that can make a huge difference.
Instead of asking the AI to invent everything, I can give it actual project information.
For example:
Project 1:
Name: TaskFlow
Description: A team task management app for small teams.
Stack: Next.js, TypeScript, PostgreSQL
GitHub: [link]
Live: [link]
Project 2:
Name: InsightBoard
Description: An analytics dashboard for tracking product usage.
Stack: React, Node.js, PostgreSQL
GitHub: [link]
Live: [link]
Now the AI is working with my real content rather than generating random placeholder text.
This usually makes the result feel much more personal.
Step 8: Build the Other Sections
The same process continues.
For the skills section:
Create a skills section that groups my skills into Frontend, Backend, Database, and Tools. Keep the design consistent with the projects section. Avoid showing skills as percentage bars because they don't represent meaningful measurements.
For experience:
Create a simple experience timeline. Keep it easy to scan and prioritize company, role, dates, and two or three meaningful contributions.
For contact:
Create a simple contact section with email, GitHub, LinkedIn, and a short CTA. Keep the form optional and don't make it visually dominant.
Again, the important thing is that each prompt has a clear purpose.
Step 9: Connect Everything
Once the individual sections are working, I would ask the model to review the page as a whole.
Something like:
Review the current portfolio page as a complete experience.
Check:
• spacing consistency
• typography hierarchy
• section transitions
• responsive behavior
• accessibility
• repeated styles
• unnecessary components
Do not redesign the page. Identify the highest-priority issues first and suggest focused improvements.
This is different from:
"Make the whole website better."
The second prompt gives the model too much freedom.
The first one gives it a checklist.
Step 10: Use the LLM as a Reviewer
At this stage, I don't only use AI as a code generator.
I also use it as a reviewer.
For example:
Review this component as a senior frontend developer.
Look specifically for:
• unnecessary re-renders
• accessibility issues
• poor responsive behavior
• duplicated logic
• unnecessary abstractions
Do not rewrite the component unless there is a real issue.
This is useful because generating code and reviewing code are two different tasks.
And I often get better results when I separate them.
Step 11: Ask for Small Improvements
Let's say the site works, but something still feels off.
Maybe the projects section looks too dense.
Instead of:
Redesign projects.
I might say:
The projects section feels visually dense compared to the hero.
Keep the current card design, but:
• increase vertical spacing between projects
• shorten the descriptions
• give project titles more visual priority
• make the technology tags smaller
Don't change the overall layout.
This is what I mean by iterative prompting.
At this point, I'm not asking the AI to invent.
I'm giving it directional feedback.
What If the AI Changes Too Much?
This happens.
You ask for a small change and suddenly the model rewrites half the page.
When that happens, I become very explicit.
For example:
Only modify the mobile navbar.
Do not change:
• desktop behavior
• typography
• colors
• component API
• existing navigation links
Return only the updated component.
That constraint makes the task much safer.
One Prompt I Would Avoid
I probably wouldn't use this:
Build my full portfolio website with amazing animations, responsive design, authentication, CMS, contact form, blog, database, SEO, dark mode, analytics, tests, and deployment.
It sounds productive.
But it's actually asking the model to solve too many different problems at once.
The result can become difficult to review.
Instead, I would break it down:
Plan → Structure → UI → Components → Data → Functionality → Review → Refinement
This makes the process much easier to control.
What This Workflow Really Changes
The biggest change is not technical.
It's the way I think about using AI.
Instead of:
"AI, build this for me."
The workflow becomes:
"Here is the problem. Here is the context. Here is what I want. Here are the boundaries. Let's solve it step by step."
That shift makes a big difference.
The LLM becomes less like a code vending machine and more like a development partner that I can guide.
But There Is Still a Limit
Even with good prompts, I wouldn't blindly trust the output.
AI-generated code can still have:
- bugs
- unnecessary dependencies
- poor architecture
- accessibility problems
- security issues
- incorrect assumptions
So after the AI generates something, I still test it.
I still read the code.
I still make the final decisions.
For me, that's one of the biggest lessons from using LLMs:
The better you understand development, the more useful AI becomes.
Because you can tell when an answer is good, when it needs refinement, and when it is simply wrong.
My Current Approach
If I had to summarize the way I now use LLMs for website development, it would be this:
First, explain the problem.
Don't start with code.
Then, define the result.
Tell the model what "good" looks like.
Set boundaries.
Tell it what not to change.
Build in small pieces.
Don't throw the whole project into one prompt unless there is a good reason.
Review every important output.
Don't blindly accept generated code.
Give specific feedback.
Tell the model exactly what is wrong.
Repeat.
The first output doesn't have to be perfect.
Final Thought
After spending more time with LLMs, I don't think prompt engineering is really about learning a collection of clever prompts.
It's about learning how to communicate with a system that doesn't know what you're thinking.
Whether I write that instruction in Bangla, English, or a mix of both becomes a secondary question.
The important part is whether I can clearly explain:
what I'm building,
why I'm building it,
what I need,
what I don't want,
and what a good result should look like.
Once that becomes natural, using an LLM becomes much less about "prompting" and much more about working with it.
And that's probably the part I find most useful.
The End of This 3-Part Series
We started with a simple question:
Should we talk to LLMs in Bangla or English?
But the deeper lesson turned out to be bigger than language.
Good results usually come from good communication.
And when that communication becomes clear, structured, and iterative, an LLM can become a genuinely useful part of the development workflow—not because it can replace a developer, but because it can help a developer move faster, explore ideas, and spend more time on the parts that actually require human judgment.