DEV Community: Probal Dhali

How to Rebuild a Website from Its Public Frontend Using AI 🛠️

Probal Dhali — Sat, 29 Aug 2026 01:29:58 +0000

Have you ever looked at a website and thought:

“How was this website built?”

Today, AI-assisted development makes it much easier to study a website's publicly delivered frontend and recreate a similar implementation for learning, prototyping, or your own design.

But there is an important technical distinction:

You can inspect and save resources delivered to your browser.
You generally cannot download a website's private backend source code just because the website is publicly accessible.

So let's look at what you can realistically do.

⚠️ First: Understand What You Can Actually Clone

A typical web application looks like:

                 WEBSITE
                    │
          ┌─────────┴─────────┐
          │                   │
       FRONTEND             BACKEND
          │                   │
   HTML / CSS / JS       Server Code
   Images / Fonts        Database
   Public Assets         Secrets
          │                   │
          └─────────┬─────────┘
                    │
                 Browser

The browser receives the frontend resources it needs to render the page.

The backend remains on the server.

Therefore:

Usually accessible from the browser

HTML
CSS
JavaScript bundles
Images
Fonts
Public API responses
Other publicly served assets

Usually NOT accessible as source code

Backend source
Database implementation
Environment variables
Private API keys
Server-side business logic
Internal services

So a better goal is:

Rebuild the observable frontend experience—not steal or extract the original application's private implementation.

🚀 Step 1 — Save the Public Website Resources

For learning purposes, you can inspect the resources your browser receives.

Chrome Developer Tools can help you understand:

HTML
 ↓
CSS
 ↓
JavaScript
 ↓
Images
 ↓
Fonts
 ↓
Network Requests

You can also use browser extensions designed to save publicly delivered page resources.

One example is:

Save All Resources

The important point is to understand what you're downloading.

You're saving resources that are already being delivered to your browser—not magically extracting the site's private backend.

🔎 Step 2 — Analyze the Website Before Rebuilding It

Don't immediately throw the downloaded files into an AI coding tool.

First understand the architecture.

Look for:

Layout

Header
Navigation
Hero
Content
Sidebar
Footer

UI patterns

Buttons
Cards
Forms
Modals
Dropdowns
Tables
Animations

Responsive behavior

Check:

Desktop
Tablet
Mobile

Network behavior

Open:

Chrome DevTools
→ Network

and observe the requests made by the browser.

This can reveal useful information such as:

GET /api/products
POST /api/login
GET /api/profile

But remember:

Seeing an API endpoint does not mean you have access to its backend implementation.

🤖 Step 3 — Use AI to Rebuild the Interface

Now comes the interesting part.

Instead of asking AI:

“Clone this website.”

give it structured information.

For example:

You are a senior frontend engineer.

Analyze the supplied public frontend assets and screenshots.

Rebuild the interface as a modern React application.

Requirements:

- Component-based architecture
- Responsive design
- Semantic HTML
- Reusable components
- Clean TypeScript
- Accessible UI
- Mobile-first layout
- No proprietary backend code
- Use mock data where backend functionality is unavailable
- Keep dependencies minimal
- Explain major architectural decisions

This gives the AI a much clearer engineering task.

🧩 Step 4 — Reconstruct the Frontend Architecture

A messy cloned page can quickly become difficult to maintain.

Instead, convert it into components.

For example:

src/
├── components/
│   ├── Header.tsx
│   ├── Navigation.tsx
│   ├── Hero.tsx
│   ├── Card.tsx
│   ├── Footer.tsx
│
├── pages/
│   ├── Home.tsx
│   ├── About.tsx
│   └── Contact.tsx
│
├── services/
│   └── api.ts
│
├── assets/
│   ├── images/
│   └── fonts/
│
└── App.tsx

Now you're not simply copying a page.

You're learning how to transform an existing UI into a maintainable software architecture.

📸 Step 5 — Use Screenshots for Visual Comparison

This is where AI-assisted development becomes particularly useful.

Take a screenshot of the reference interface.

Then compare it with your implementation.

Check:

Spacing
Typography
Colors
Layout
Alignment
Responsive behavior
Component size
Navigation
Animations

Then give targeted feedback.

Instead of:

“Make it better.”

try:

The hero section is approximately 15% too tall.

Reduce vertical padding.

The navigation items should have
consistent horizontal spacing.

The card grid should become:

4 columns → desktop
2 columns → tablet
1 column → mobile

Specific instructions generally produce better engineering results.

🔄 Step 6 — Iterate

A practical workflow looks like:

Reference Website
       ↓
Inspect Public Resources
       ↓
Analyze UI
       ↓
Create React Structure
       ↓
AI-Assisted Implementation
       ↓
Run Locally
       ↓
Screenshot
       ↓
Compare
       ↓
Fix
       ↓
Repeat

This isn't really “one-click cloning.”

It's an iterative reverse-engineering and reconstruction workflow.

And that's a much more useful skill to learn.

🧠 Step 7 — What About the Backend?

This is where many tutorials become technically inaccurate.

Suppose the original website has:

Frontend
    ↓
REST API
    ↓
Backend
    ↓
PostgreSQL

You may be able to observe:

GET /api/products

and perhaps inspect the response.

But you don't automatically obtain:

backend/
├── controllers/
├── services/
├── models/
└── database/

The server executes that code remotely.

So what should you do?

Build your own backend.

For example:

React / Next.js
       ↓
Your API
       ↓
FastAPI / Node.js
       ↓
PostgreSQL

Use your own:

database
authentication
business logic
API endpoints
environment variables

This turns a visual recreation into an actual full-stack learning project.

🗄️ Example: Rebuilding a Product Website

Suppose the original site displays products.

You might observe:

{
  "id": 101,
  "name": "Example Product",
  "price": 49.99
}

Instead of depending on the original service, create your own API:

GET /api/products

Your backend might return:

[
  {
    "id": 1,
    "name": "Product A",
    "price": 49.99
  },
  {
    "id": 2,
    "name": "Product B",
    "price": 79.99
  }
]

Now your frontend becomes independent.

That's the correct engineering approach.

🔐 Step 8 — Don't Copy Secrets

Never attempt to extract or reuse:

API Keys
Passwords
Private Tokens
Session Cookies
Database Credentials
Private Certificates

And don't put secrets into frontend code.

Use environment variables on your own infrastructure:

Frontend
   ↓
Your API
   ↓
Environment Variables
   ↓
Database

Security should be part of the reconstruction process from day one.

🚀 Step 9 — Deploy Your Own Version

Once the project works locally, deploy it.

For a frontend project, platforms such as Netlify can make deployment straightforward.

Typical workflow:

Local Project
     ↓
Git Repository
     ↓
Build
     ↓
Deploy
     ↓
Live URL

You can then test the application from:

Desktop
Mobile
Tablet

and verify that your production build behaves correctly.

⚖️ Important: Learn From Websites, Don't Impersonate Them

There's a major difference between:

✅ Good use

learning frontend architecture
studying responsive layouts
recreating a generic UI
building a personal practice project
analyzing publicly delivered assets
creating your own implementation

and:

❌ Risky use

copying proprietary source code
extracting private backend code
reusing credentials
impersonating a company's website
copying branding or trademarks deceptively
reproducing a service for phishing or fraud

If you're publishing your recreation publicly, clearly identify it as a learning/reimplementation project.

🧠 The Bigger Lesson

The most valuable part isn't:

“I cloned a website.”

It's:

“I learned how to analyze an existing interface and reconstruct its architecture.”

That teaches real engineering skills:

Web Architecture
       ↓
Browser DevTools
       ↓
HTTP / APIs
       ↓
Frontend Components
       ↓
Backend Design
       ↓
Database
       ↓
Testing
       ↓
Security
       ↓
Deployment

That's much more valuable than a one-click clone.

🔥 My Recommended AI-Assisted Workflow

If I were doing this as a developer-learning project, I'd use:

1. Inspect
   ↓
2. Understand
   ↓
3. Document
   ↓
4. Rebuild
   ↓
5. Test
   ↓
6. Debug
   ↓
7. Secure
   ↓
8. Deploy

And I'd keep one rule throughout:

Use AI to accelerate implementation, not to replace understanding.

🎯 Final Takeaway

Modern AI tools have dramatically reduced the time required to build interfaces.

But there is an important difference between:

copying a webpage

and

understanding and rebuilding a software system.

The second one teaches you much more.

Learn to inspect.

Learn to question.

Learn to reconstruct.

Learn to debug.

Learn to build your own backend.

Learn to secure it.

And finally:

Ship something that you actually understand. 🚀

Resources

Chrome DevTools documentation
MDN Web Docs
Netlify documentation
OWASP Web Security resources

If you're experimenting with website reconstruction for learning, I'd love to hear:

What website would you choose to rebuild—and what would you change in your own implementation?

WebDevelopment #AI #Frontend #Backend #React #JavaScript #TypeScript #DevTools #SoftwareEngineering #Programming #WebDevelopment #DevCommunity #AIcoding

Career in Software Development in the 2026 AI Era: What Should Developers Actually Learn?

Probal Dhali — Sat, 29 Aug 2026 01:16:06 +0000

AI has changed software development.

It can generate functions, write tests, explain APIs, scaffold applications, refactor code, and sometimes build surprisingly large features from a simple prompt.

That creates an important question:

If AI can write so much code, what should software developers learn in 2026?

My answer is simple:

Don't compete with AI at typing code. Learn to understand, evaluate, debug, design, secure, and ship software.

The value of a developer is increasingly moving from “How fast can you write code?” toward:

“Can you determine what should be built, verify that it works, and take responsibility for the result?”

🤖 1. AI Can Write Code. That Doesn't Mean AI Owns the Software.

Modern coding assistants can generate code extremely quickly.

You can ask an AI to:

Create an authentication system
↓
Generate database models
↓
Create API endpoints
↓
Write frontend components
↓
Generate tests

And you may receive hundreds or thousands of lines of code.

But generated code still has to operate inside a real system.

Real software has:

existing architecture
legacy code
business requirements
security constraints
database assumptions
performance requirements
deployment environments
user behavior
regulatory requirements
undocumented decisions

A function can be syntactically correct and still be architecturally wrong.

A test can pass and still test the wrong behavior.

An API can return the expected response while introducing a security vulnerability.

That's why code generation and software engineering are not the same thing.

🧠 2. The Most Important Skill: Understanding What the Code Actually Does

In the AI era, basic programming knowledge becomes more important, not less.

You don't need to memorize every method in every library.

But you should understand:

Variables
↓
Conditions
↓
Loops
↓
Functions
↓
Data Structures
↓
Algorithms
↓
State
↓
Input / Output

If an AI generates:

if user and user.is_authenticated:
    process_payment(user)

you should be able to ask:

What happens if user is None?
How is authentication established?
Can another user access this endpoint?
Is authorization checked?
Can the payment operation execute twice?
What happens if the database transaction fails?

That's software engineering.

🔍 3. Debugging May Become More Valuable Than Typing

AI can produce code very quickly.

But when something goes wrong, someone still needs to understand why.

Consider:

Application
     ↓
API
     ↓
Business Logic
     ↓
Database
     ↓
External Service

A failure could originate anywhere.

Good developers learn to investigate systematically:

Reproduce
   ↓
Observe
   ↓
Read logs
   ↓
Form hypothesis
   ↓
Test hypothesis
   ↓
Fix root cause
   ↓
Add regression test

This is a skill AI can assist with—but you shouldn't outsource your understanding of the system.

📊 4. What Developer Data Actually Tells Us

Stack Overflow's 2025 Developer Survey reported that 84% of respondents use or plan to use AI tools in their development process, while trust in AI output remains significantly lower than adoption.

That distinction matters.

Developers are adopting AI rapidly, but adoption does not mean developers consider generated output automatically reliable.

The same survey also found substantial frustration around AI-generated code and the additional work required when outputs are incorrect.

Source:

Stack Overflow Developer Survey 2025

The lesson isn't:

“AI is bad.”

The lesson is:

AI adoption and AI trust are two different measurements.

And that gap creates an opportunity for developers who can effectively verify AI-generated work.

🧱 5. The 10 Programming Skills I Would Prioritize

1️⃣ Programming Fundamentals

Learn:

variables
conditions
loops
functions
data structures
algorithms
error handling
modular programming

Don't optimize for syntax memorization.

Optimize for logical understanding.

2️⃣ Problem Solving & Debugging

Learn how to:

reproduce bugs
inspect logs
isolate failures
read stack traces
identify root causes
write regression tests

A developer who can debug independently is extremely valuable.

3️⃣ Git & Version Control

Git isn't just:

git add .
git commit
git push

Understand:

clone
branch
commit
merge
rebase
pull
push
stash
diff
reset
revert
conflict resolution

You should be comfortable working on a team where multiple developers modify the same codebase.

🖥️ 4️⃣ Command Line

Learn to operate your development environment.

At minimum:

pwd
ls
cd
mkdir
cp
mv
rm
cat
grep
find
curl
ssh

Then learn:

environment variables
processes
ports
permissions
logs
package managers
shell scripting

You don't need to become a Linux administrator.

But you should not be helpless when the GUI disappears.

🌐 5️⃣ Internet & Networking Fundamentals

You don't need to become a network engineer.

But understand:

Browser
   ↓
DNS
   ↓
HTTP/HTTPS
   ↓
Server
   ↓
API
   ↓
Database

Learn:

HTTP methods
status codes
headers
cookies
sessions
authentication
authorization
REST APIs
JSON
DNS
TCP/IP basics

If you build web applications, this knowledge pays off constantly.

🗄️ 6️⃣ Databases

Don't only learn how to call an ORM.

Learn SQL.

Understand:

SELECT
INSERT
UPDATE
DELETE
JOIN
GROUP BY
ORDER BY
INDEX
TRANSACTION

Then learn a practical database such as:

PostgreSQL

and understand when technologies such as:

SQLite
Redis

are appropriate.

A developer should be able to investigate the database directly when the application behaves unexpectedly.

🧪 7️⃣ Automated Testing

AI-generated code makes verification even more important.

Learn:

Unit Tests
Integration Tests
API Tests
End-to-End Tests
Regression Tests

A useful development loop:

Write
 ↓
Test
 ↓
Fail
 ↓
Debug
 ↓
Fix
 ↓
Test Again

Don't treat testing as something you add after development.

Testing is part of development.

🔐 8️⃣ Security Fundamentals

You don't need to become a security researcher.

But every developer should understand common vulnerabilities.

Learn concepts such as:

authentication vs authorization
SQL injection
XSS
CSRF
insecure secrets
broken access control
dependency vulnerabilities
input validation
secure password storage
least privilege

OWASP's resources are an excellent starting point.

OWASP Top 10

AI can generate insecure code confidently.

Your job is to recognize it.

📚 9️⃣ Read Documentation Without AI

This skill is becoming underrated.

Suppose a library behaves unexpectedly.

Instead of immediately asking:

“Why doesn't this work?”

learn to search the official documentation:

Official Documentation
        ↓
API Reference
        ↓
Examples
        ↓
Version Information
        ↓
Known Limitations

AI can explain documentation.

But you should still know where the source of truth is.

🗣️ 🔟 Communication

This is often ignored by technical learners.

You may eventually need to explain:

“Why did we choose PostgreSQL instead of MongoDB?”

to someone who doesn't care about database technology.

Good engineers can communicate:

Technical Problem
↓
Business Impact
↓
Possible Solutions
↓
Trade-offs
↓
Recommendation

Software engineering is a team activity.

Communication is part of engineering.

💻 6. Which Programming Language Should You Learn?

There isn't one universally “best” language.

Choose based on your target domain.

🌐 Web Development

JavaScript + TypeScript

A strong combination for frontend and full-stack web development.

Learn:

JavaScript
↓
TypeScript
↓
React
↓
Next.js
↓
Backend
↓
Database

TypeScript adds static typing and can improve maintainability in larger JavaScript projects.

🐍 AI / Data / Backend

Python

Excellent ecosystem for:

AI
machine learning
data science
automation
backend development

For APIs, frameworks such as FastAPI are worth learning.

☕ Enterprise Development

Java / C#

Still highly relevant across enterprise environments, including large organizations and financial systems.

The important point isn't that these languages are “old.”

It's that they power substantial production ecosystems.

🐹 Go

Go is particularly useful for:

cloud infrastructure
networking
backend services
concurrent systems
developer tooling

🦀 Rust

Rust is valuable for:

systems programming
performance-sensitive software
security-sensitive applications
memory-safe low-level development

Government and industry interest in memory-safe languages has also increased, but don't choose Rust simply because it's associated with cybersecurity.

Choose it when the problem domain benefits from its properties.

🧩 7. Frameworks: Don't Learn Everything

One common mistake in 2026:

React
Vue
Angular
Svelte
Next.js
Nuxt
Astro
...

Trying to learn everything simultaneously.

Don't.

Pick one path.

For example:

HTML
 ↓
CSS
 ↓
JavaScript
 ↓
TypeScript
 ↓
React
 ↓
Next.js
 ↓
Backend
 ↓
PostgreSQL

Then build projects.

Depth beats framework collecting.

🚀 8. Backend Development

A practical beginner-to-intermediate stack could be:

Frontend
React / Next.js

Backend
Node.js OR FastAPI

Database
PostgreSQL

Authentication
Sessions / JWT / OAuth concepts

Deployment
Cloud platform

Testing
Unit + Integration + API tests

Build something real.

For example:

User Registration
      ↓
Login
      ↓
Authentication
      ↓
Dashboard
      ↓
CRUD Operations
      ↓
Database
      ↓
Deployment

That's significantly more valuable than following ten tutorials without finishing one project.

☁️ 9. Don't Start With Kubernetes

Kubernetes is powerful.

But if you still don't understand:

HTTP
Linux
Processes
Networking
Containers
Databases
APIs
Deployment

Kubernetes can become cargo cult engineering.

Learn fundamentals first.

Then add Docker.

Then understand deployment.

Then explore orchestration when your projects actually require it.

📱 10. Mobile Development

For cross-platform development, technologies such as:

React Native
Flutter

are both legitimate options.

Instead of asking:

“Which framework is universally best?”

ask:

“Which ecosystem matches my target platform, team, existing skills, and project requirements?”

Technology choices should be context-driven, not trend-driven.

🤖 11. How I Recommend Using AI

Don't use AI like this:

Problem
 ↓
Copy AI answer
 ↓
Paste
 ↓
Done

Use it like this:

Problem
 ↓
Ask AI for explanation
 ↓
Understand proposal
 ↓
Implement / review
 ↓
Test
 ↓
Inspect edge cases
 ↓
Verify documentation
 ↓
Ship

AI should increase your capabilities.

It shouldn't replace them.

⚠️ 12. Treat AI-Generated Code Like Code From a Stranger

Imagine someone you don't know sent you this pull request.

Would you merge it without reviewing it?

Probably not.

Apply the same standard to AI-generated code.

Check:

Correctness
Security
Performance
Dependencies
Error Handling
Edge Cases
Maintainability
Tests

And importantly:

Understand what you're approving.

🚨 13. AI Hallucinations Are an Engineering Problem

AI may sometimes suggest:

incorrect APIs
outdated syntax
nonexistent packages
wrong configuration
incompatible versions
insecure implementation patterns

So don't blindly install:

some-random-package

because an AI suggested it.

Check:

Official package registry
↓
Official documentation
↓
Repository
↓
Version
↓
Maintenance activity
↓
Security status

🔐 14. Never Ignore Data Security

If you're working with proprietary software, company data, credentials, customer information, or confidential source code, understand your organization's AI policies before sending anything to an external service.

Never paste:

API Keys
Passwords
Private Tokens
Customer Data
Private Certificates
Confidential Source Code

into an AI service without authorization.

AI productivity is not worth a security incident.

📅 15. A Practical 12-Month Roadmap

🗓️ Month 1 — Fundamentals

Learn:

HTML
CSS
JavaScript OR Python
Git
GitHub
Command Line

Build:

2–3 small projects.

Don't just watch tutorials.

🗓️ Months 2–3 — Deep Programming

Choose one primary language.

For example:

Python

or:

JavaScript → TypeScript

Focus on:

functions
data structures
algorithms
OOP concepts
error handling
debugging
problem solving

Build without relying entirely on frameworks.

🗓️ Months 4–6 — Full Applications

Learn:

Database
 ↓
Backend
 ↓
API
 ↓
Frontend
 ↓
Authentication
 ↓
Deployment

Build and publish at least one complete application.

Not another todo tutorial.

Build something that solves an actual problem.

🗓️ Months 7–12 — Engineering Maturity

Now add:

Security
Testing
CI/CD
Performance
Open Source
Documentation
System Design
Cloud Fundamentals

Contribute to existing projects.

Improve old projects.

Read other people's code.

Start thinking beyond:

“How do I make this work?”

and start asking:

“How do I make this reliable?”

🎯 16. What About Certificates?

Certificates can demonstrate structured learning.

But a certificate alone doesn't demonstrate that you can build and maintain software.

Compare:

10 Certificates
+
0 Real Projects

with:

3 Strong Projects
+
GitHub Activity
+
Technical Understanding
+
Deployment
+
Tests
+
Documentation

For software development, the second profile can often demonstrate much more practical ability.

Don't collect certificates instead of building.

🧠 17. Don't Chase Every New Tool

The technology ecosystem moves incredibly fast.

Every week there is another:

AI Agent
Framework
Database
Coding Assistant
Cloud Platform
JavaScript Framework
Developer Tool

You don't need all of them.

A better strategy:

Learn
 ↓
Build
 ↓
Understand
 ↓
Ship
 ↓
Maintain
 ↓
Then explore

Depth creates leverage.

🛠️ 18. Build Projects That Force You to Learn

A good project should create problems.

That's the point.

For example:

Project 1

Personal portfolio

Learn:

HTML
CSS
JS
Git
Deployment

Project 2

Full-stack application

Learn:

React
Backend
PostgreSQL
Authentication
APIs

Project 3

AI-powered application

Learn:

AI API
Prompting
Backend integration
Security
Rate limiting
Evaluation

Project 4

Open-source contribution

Learn:

Git workflow
Code review
Issue tracking
Documentation
Team communication

That's a much stronger learning loop than endlessly switching tutorials.

🔄 19. The Developer Learning Loop

My preferred model for 2026 is:

LEARN
  ↓
BUILD
  ↓
BREAK
  ↓
DEBUG
  ↓
UNDERSTAND
  ↓
IMPROVE
  ↓
SHIP
  ↓
REPEAT

AI can participate in almost every stage.

But you should remain responsible for the final result.

🧭 20. The Real Career Advantage in the AI Era

The developer who wins isn't necessarily the person who can type code the fastest.

It may be the person who can:

Understand the problem
        ↓
Design the solution
        ↓
Use AI effectively
        ↓
Review generated code
        ↓
Debug failures
        ↓
Secure the system
        ↓
Test the implementation
        ↓
Communicate trade-offs
        ↓
Ship reliable software

That's a much broader skill set than coding syntax.

🔥 My Final Advice

If you're starting software development in 2026, don't ask:

“Will AI replace programmers?”

Ask:

“What kind of programmer becomes more valuable when AI can generate code?”

My answer:

A developer who understands systems.

Someone who can:

reason about problems
write and read code
debug independently
understand databases
work with Git
understand APIs and networks
test software
identify security risks
read documentation
use AI intelligently
communicate technical decisions
build and maintain real products

AI can generate code.

You need to develop the engineering judgment to decide whether that code belongs in production.

That's the skill worth investing in.

🚀 If I Were Starting Today

My learning stack would look something like:

Programming Fundamentals
        ↓
Git + GitHub
        ↓
Linux / CLI
        ↓
HTTP + REST APIs
        ↓
SQL + PostgreSQL
        ↓
JavaScript + TypeScript
        ↓
React / Next.js
        ↓
Backend
        ↓
Testing
        ↓
Security
        ↓
Deployment
        ↓
AI Integration
        ↓
System Design
        ↓
Open Source

Don't try to learn everything.

Choose a direction.

Learn deeply.

Build constantly.

Use AI.

Question AI.

Verify AI.

And most importantly:

Understand the software you ship.

Because in the AI era, writing code may become cheaper.

Engineering judgment won't. 🚀

References

Stack Overflow — Developer Survey 2025: AI
OWASP — Top 10 Web Application Security Risks
Official documentation for the programming languages, frameworks, databases, and tools discussed above

SoftwareDevelopment #AI #Programming #WebDevelopment #Developers #Coding #ArtificialIntelligence #CareerAdvice #DevCommunity #JavaScript #TypeScript #Python #GitHub #PostgreSQL #SoftwareEngineering #CyberSecurity #LearningToCode

🪢 Rakhi Bandhan: The Strongest Connection Has No API

Probal Dhali — Fri, 28 Aug 2026 08:01:42 +0000

As developers, we spend a lot of time thinking about connections.

APIs connect services.
Networks connect systems.
Databases connect information.
Git connects our work across time.

But some of the most important connections in life don't need any of them.

Rakhi Bandhan is one of those connections. ❤️

A Rakhi may look like a simple thread, but behind that thread is something much bigger:

Trust.
Support.
Responsibility.
Memories.
And a bond that survives distance.

As technology continues to evolve, we build systems that are faster, smarter, and more connected every day.

Yet there are connections that cannot be measured in latency, bandwidth, uptime, or performance.

You can't benchmark a sibling's support.
You can't calculate the value of shared childhood memories.
You can't write an API for being there when someone needs you.

And maybe that's the beautiful reminder Rakhi gives us:

Not every valuable connection needs technology. Some connections simply need people.

For developers, there's another lesson here.

We often focus on building reliable systems:

Connect → Communicate → Support → Recover → Grow

Strong relationships work in surprisingly similar ways.

Be available.
Communicate honestly.
Support each other.
Forgive failures.
Keep improving together.

Technology can connect the world.

But people give those connections meaning.

So today, let's celebrate the people who have been part of our journey long before we wrote our first line of code.

To every brother and sister:

Happy Rakhi Bandhan! 🪢❤️

May the connection stay strong—even when the distance gets bigger.

RakhiBandhan #RakshaBandhan #DeveloperLife #DevCommunity #Technology #Programming #LifeLessons #BrothersAndSisters #Coding #Developers

100 Creative Thinking, AI Workflows & Advanced Prompting Lenses 🤖🧠

Probal Dhali — Mon, 24 Aug 2026 15:51:54 +0000

The first 400 lenses focused on writing, visual thinking, productivity, coding, research, and content creation.

This final collection moves one layer deeper:

How do we design better interactions with AI itself?

Instead of treating AI as a single chatbot, we can think of it as a configurable reasoning and workflow environment.

Question
   ↓
Context
   ↓
Lens
   ↓
Method
   ↓
Evaluation
   ↓
Iteration
   ↓
Result

The goal isn't to make prompts unnecessarily complicated.

The goal is to make the task, constraints, perspective, and evaluation criteria explicit.

1. Creative Generation

The foundation is idea generation.

/brainstorm
/ideas10
/ideas50
/creative
/innovate
/outofthebox
/inspiration
/random

A simple creative workflow:

Problem
  ↓
Generate
  ↓
Expand
  ↓
Combine
  ↓
Filter
  ↓
Evaluate

For example:

/ideas50

is useful when quantity matters.

But:

/bestoption

is useful when the goal shifts from exploration → selection.

That distinction is important.

2. Remixing Existing Ideas

Not every useful idea needs to start from zero.

These lenses work with existing concepts:

/combine
/remix
/alternate
/variants
/options
/compareideas

A powerful pattern is:

Existing Idea
     ↓
Decompose
     ↓
Change One Variable
     ↓
Generate Variant
     ↓
Compare

For example:

Existing:
AI study assistant

Variant A:
AI study planner

Variant B:
AI exam simulator

Variant C:
AI knowledge graph

Variant D:
AI peer tutor

Creativity often comes from recombination, not pure novelty.

3. Decision-Making

Once ideas exist, selection becomes the problem.

Useful lenses:

/bestoption
/decision
/options
/compareideas

Instead of:

“Which one is best?”

a structured decision asks:

Criteria
 ↓
Weights
 ↓
Options
 ↓
Evidence
 ↓
Trade-offs
 ↓
Score
 ↓
Decision

This reduces the temptation to choose the first attractive idea.

4. Advisor → Mentor → Coach

Different situations require different interaction styles:

/advisor
/mentor
/coach
/teacher
/tutor

They can be thought of as different levels of guidance.

Advisor
   ↓
Recommendations

Mentor
   ↓
Experience + direction

Coach
   ↓
Questions + accountability

Teacher
   ↓
Explanation

Tutor
   ↓
Personalized practice

The important point is that the interaction mode changes, not necessarily the underlying knowledge.

5. Expert Perspectives

Different disciplines frame problems differently.

This collection includes:

/professor
/scientist
/engineer
/doctor
/lawyer
/psychologist
/economist
/historian
/journalist

These should be treated as perspective lenses, not claims of real-world professional credentials.

For example:

Same problem
      ↓
 ┌────┼────┐
 ↓    ↓    ↓
Engineer Economist Historian
 ↓    ↓    ↓
System Cost Context

A multidisciplinary view can reveal assumptions that one perspective misses.

For medical or legal topics, the output should remain educational and should not be treated as a substitute for qualified professional advice.

6. Professional Roles

The next layer applies organizational perspectives:

/editor
/designer
/architect
/productmanager
/founder
/ceo
/investorview
/customer

Imagine evaluating a product:

Engineer
→ Can we build it?

Product Manager
→ Should we build it?

Founder
→ Is the opportunity worth pursuing?

Investor
→ Is the business attractive?

Customer
→ Does it actually solve my problem?

These perspectives can disagree.

And that disagreement can be valuable.

7. Beginner vs Advanced

Two useful control lenses:

/beginner
/advanced

The same concept can be represented differently.

Beginner:
Simple language
Examples
Analogies
Few assumptions

Advanced:
Formal terminology
Edge cases
Constraints
Trade-offs
Implementation details

A good AI workflow should adapt complexity to the audience.

8. Interactive Problem Solving

Some problems shouldn't be solved in one giant response.

Useful lenses:

/stepbystep
/interactive
/walkthrough

Instead of:

Question → Final Answer

you can use:

Question
 ↓
Clarify
 ↓
Analyze
 ↓
Confirm
 ↓
Execute
 ↓
Review

This is particularly useful for complex technical tasks where requirements may be ambiguous.

9. Simulation

The /simulation lens can model hypothetical situations.

For example:

Current System
      ↓
Change Condition
      ↓
Simulate Outcome
      ↓
Identify Effects
      ↓
Evaluate

Possible applications include:

system design
product decisions
interview practice
business scenarios
negotiation
project planning

But simulations should be clearly treated as scenarios, not predictions of reality.

10. Debate and Counterarguments

Good reasoning requires the ability to challenge an idea.

Useful lenses:

/debate
/counterargument
/critique
/validate

A useful structure:

Claim
 ↓
Supporting Evidence
 ↓
Counterargument
 ↓
Response
 ↓
Remaining Weakness
 ↓
Conclusion

This prevents an AI conversation from becoming an automatic agreement machine.

11. Assumptions and Constraints

Two of the most underrated lenses:

/assumptions
/constraints

Every project contains assumptions.

For example:

“This API will scale.”

Possible hidden assumptions:

Expected traffic
Infrastructure
Database performance
Network conditions
Caching
Concurrency
Failure handling

Making assumptions visible creates opportunities to test them.

12. Trade-Off Analysis

Engineering is full of trade-offs.

/tradeoffs

can frame decisions like:

Performance ↔ Maintainability

Cost ↔ Reliability

Speed ↔ Quality

Flexibility ↔ Simplicity

Security ↔ Convenience

There is rarely a solution that maximizes every dimension simultaneously.

The important question becomes:

Which trade-off is acceptable for this specific context?

13. Future Thinking

Future-oriented lenses include:

/opportunities
/risksfuture
/trendanalysis
/forecastfuture
/signals
/emergingtech
/futureproof

A useful structure:

Current State
     ↓
Signals
     ↓
Possible Changes
     ↓
Scenarios
     ↓
Risks
     ↓
Opportunities

The goal isn't to pretend AI can predict the future with certainty.

The goal is to explore plausible scenarios.

14. Weak Signals

The /signals lens focuses on early indicators.

For example:

Small change
   ↓
Repeated occurrence
   ↓
Emerging pattern
   ↓
Potential trend

This can be useful for:

technology
product strategy
research
market analysis

But weak signals are inherently uncertain.

They should be treated as hypotheses, not facts.

15. Automation

The next group focuses on turning repetitive work into workflows.

/automation
/workflow
/pipeline
/automationplan

A basic automation pipeline:

TRIGGER
   ↓
INPUT
   ↓
PROCESS
   ↓
VALIDATION
   ↓
OUTPUT
   ↓
LOGGING

The key is not:

“Automate everything.”

Instead:

Automate predictable, repeatable work where the cost of errors is understood.

16. Systems Thinking

Complex problems rarely exist in isolation.

/systemthinking

encourages looking at:

Component
   ↓
Relationships
   ↓
Feedback loops
   ↓
Dependencies
   ↓
Emergent behavior

For example:

Users
 ↕
Product
 ↕
Infrastructure
 ↕
Data
 ↕
Business

Changing one part can affect the others.

17. Mental Models

Useful lenses:

/mentalmodels
/heuristics
/principles

Examples of mental models include:

First principles
Opportunity cost
Second-order effects
Feedback loops
Incentives
Bottlenecks
Compounding

The value comes from selecting a model appropriate to the problem.

18. Framework Selection

Instead of automatically applying one framework:

/frameworkcompare

can compare alternatives.

For example:

Problem
 ↓
Candidate Frameworks
 ↓
Strengths
 ↓
Weaknesses
 ↓
Fit
 ↓
Selection

The right framework depends on the problem.

19. Best Practices vs Context

Useful lenses:

/bestpractice
/mistakes
/dosanddonts
/quickwins

But “best practice” should never mean:

“Always do X.”

A better formulation is:

Common practice
      +
Context
      +
Constraints
      ↓
Recommended approach

A practice that works in one organization can fail in another.

20. Optimization

The optimization group:

/optimization
/efficiency
/quickwins

should begin with measurement.

A useful engineering principle:

Measure
 ↓
Identify bottleneck
 ↓
Change
 ↓
Measure again

Optimization without measurement can simply create complexity without measurable improvement.

21. AI Workflows

Now we reach the heart of this collection:

/aiworkflow
/workflow
/pipeline

Instead of one huge prompt:

Prompt
 ↓
Answer

we can construct:

Input
 ↓
Analysis
 ↓
Generation
 ↓
Verification
 ↓
Revision
 ↓
Final Output

This is often more controllable because each stage has a defined purpose.

22. Prompt Auditing

The /promptaudit lens evaluates the prompt itself.

Possible dimensions:

Goal
Context
Constraints
Ambiguity
Output format
Evaluation criteria
Missing information

For example:

Weak:

“Build me a good website.”

Better:

Goal
+ Audience
+ Features
+ Tech stack
+ Constraints
+ Acceptance criteria
+ Output format

The important improvement isn't necessarily length.

It is specificity where specificity matters.

23. Prompt Libraries

The /promptlibrary lens organizes reusable prompts.

A useful structure:

/prompts
 ├── coding
 ├── research
 ├── writing
 ├── analysis
 ├── debugging
 ├── planning
 └── evaluation

Each prompt can include:

Name
Purpose
Inputs
Constraints
Expected Output
Example
Version

This turns ad-hoc prompting into a reusable system.

24. Prompt Chaining

The /promptchain lens connects multiple stages.

Example:

Prompt 1
Research
 ↓
Prompt 2
Extract evidence
 ↓
Prompt 3
Analyze
 ↓
Prompt 4
Critique
 ↓
Prompt 5
Generate final output

This can be more reliable than asking for everything simultaneously.

25. Meta-Prompting

The /metaprompt lens asks AI to create a prompt for another task.

Conceptually:

User Goal
    ↓
Meta-Prompt
    ↓
Task Prompt
    ↓
AI Task
    ↓
Output

For example:

Goal:
Create a technical tutorial.

Meta-prompt:
“Design the optimal prompt structure for generating
a technically accurate tutorial for intermediate developers.”

The meta-layer is useful when the task itself is complex.

26. System Prompts

The /systemprompt lens focuses on defining persistent behavior.

A useful conceptual structure:

ROLE
 ↓
OBJECTIVE
 ↓
RULES
 ↓
CONSTRAINTS
 ↓
TOOLS
 ↓
OUTPUT FORMAT
 ↓
EVALUATION

This is closer to behavior specification than ordinary prompting.

27. Personas and Roles

Two related lenses:

/persona
/role

A persona might specify:

Audience
Tone
Expertise
Communication style
Priorities

But personas should not be confused with genuine professional credentials.

“Act as a senior architect” is a useful perspective instruction.

It does not make the AI a real architect.

28. Multi-Expert Reasoning

The /multiexpert lens can intentionally introduce multiple perspectives.

Example:

             PROBLEM
                │
      ┌─────────┼─────────┐
      ↓         ↓         ↓
  Engineer   Researcher  Product
      ↓         ↓         ↓
      └─────────┼─────────┘
                ↓
           Comparison
                ↓
             Decision

This can expose disagreements that a single perspective might miss.

29. Consensus vs Disagreement

Useful lenses:

/consensus
/disagreement

Instead of forcing agreement:

Expert A → Option X
Expert B → Option Y
Expert C → Option X

the system can explicitly identify:

Areas of agreement
Areas of disagreement
Evidence differences
Assumption differences

Disagreement can be information.

30. Evidence

The /evidence lens encourages claims to be connected to supporting information.

A useful structure:

CLAIM
 ↓
EVIDENCE
 ↓
SOURCE
 ↓
RELEVANCE
 ↓
LIMITATION

This is especially important for:

research
technical writing
statistics
health information
legal topics
current events

AI-generated claims should still be independently verified when accuracy matters.

31. Confidence and Uncertainty

Two complementary lenses:

/confidence
/uncertainty

A useful answer separates:

Known
Likely
Possible
Unknown

Instead of presenting every statement with the same level of certainty.

This is especially important when evidence is incomplete.

32. Limitations

The /limitations lens forces the question:

“Where could this approach fail?”

A useful structure:

Method
 ↓
Strengths
 ↓
Weaknesses
 ↓
Failure Conditions
 ↓
Uncertainty
 ↓
Mitigation

This is one of the simplest ways to make AI-generated analysis more intellectually honest.

33. Comprehensive Assessment

The /assess lens combines multiple dimensions:

Correctness
Feasibility
Cost
Risk
Maintainability
Evidence
Constraints
Alternatives

Instead of:

“Is this good?”

we ask:

“Good according to which criteria?”

That is a much better question.

34. Scorecards

The /scorecard lens makes qualitative decisions more explicit.

Example:

Criterion          Weight
──────────────────────────
Cost                 20%
Performance          25%
Security             25%
Maintainability      20%
Scalability          10%

Then:

Option A → Score
Option B → Score
Option C → Score

The numbers don't magically make the decision objective.

They simply make the evaluation criteria visible.

35. Ranking and Comparison Matrices

Useful lenses:

/ranking
/matrixcompare

For example:

              Cost  Speed  Security  Scale
Option A       8      7       9        6
Option B       6      9       7        9
Option C       9      6       8        7

The matrix makes trade-offs easier to inspect.

36. Final Answer Mode

The /finalanswer lens is intentionally simple:

/finalanswer

It means:

Produce the requested final output without unnecessary process narration.

This is useful when the analysis has already happened and only the deliverable is needed.

37. High-Level Reasoning

The /thinking lens needs an important distinction.

It should not mean exposing private chain-of-thought.

Instead, it can request a concise reasoning summary:

Problem
 ↓
Key assumptions
 ↓
Relevant evidence
 ↓
Decision criteria
 ↓
Conclusion

For example:

Reasoning summary:
- Constraint A eliminates option B.
- Requirement C favors option A.
- Main uncertainty is D.
- Therefore option A is currently preferred.

That gives useful transparency without requiring hidden internal reasoning.

38. Execution Mode

The /executemode lens focuses on producing the requested artifact.

For example:

Goal:
Create project structure.

EXECUTE
 ↓
Files
 ↓
Implementation
 ↓
Tests
 ↓
Validation

This is particularly useful when the planning stage is already complete.

39. Master Prompt

The /masterprompt lens combines multiple techniques.

Conceptually:

MASTER PROMPT
      │
      ├── Context
      ├── Goal
      ├── Role
      ├── Constraints
      ├── Process
      ├── Evidence
      ├── Evaluation
      └── Output Format

But bigger is not automatically better.

A master prompt should remain understandable and maintainable.

40. The All-in-One Lens

Finally:

/allinone

can combine the most relevant structures automatically.

A conceptual pipeline:

                 USER GOAL
                     ↓
              CONTEXT ANALYSIS
                     ↓
              TASK CLASSIFICATION
                     ↓
            SELECT BEST LENSES
                     ↓
          ┌──────────┼──────────┐
          ↓          ↓          ↓
       REASON      CREATE     VERIFY
          └──────────┼──────────┘
                     ↓
                  REVIEW
                     ↓
                 FINALIZE

The important word is relevant.

Using every possible technique on every problem would create unnecessary complexity.

The Complete 100-Lens Map

#	Shortcut	Purpose
401	`/brainstorm`	Generate many ideas
402	`/ideas10`	Generate 10 ideas
403	`/ideas50`	Generate 50 ideas
404	`/creative`	Creative thinking
405	`/innovate`	Innovative solutions
406	`/outofthebox`	Unconventional ideas
407	`/inspiration`	Creative inspiration
408	`/random`	Random idea generation
409	`/combine`	Combine concepts
410	`/remix`	Remix existing ideas
411	`/alternate`	Alternative approaches
412	`/variants`	Generate variants
413	`/options`	List options
414	`/compareideas`	Compare ideas
415	`/bestoption`	Select strongest option
416	`/decision`	Decision support
417	`/advisor`	Advisor perspective
418	`/mentor`	Mentorship mode
419	`/coach`	Coaching mode
420	`/teacher`	Step-by-step teaching
421	`/tutor`	Personalized tutoring
422	`/professor`	University-level perspective
423	`/scientist`	Scientific perspective
424	`/engineer`	Engineering perspective
425	`/doctor`	Medical educational perspective
426	`/lawyer`	Legal educational perspective
427	`/psychologist`	Psychology perspective
428	`/economist`	Economic analysis
429	`/historian`	Historical perspective
430	`/journalist`	Investigative perspective
431	`/editor`	Editorial perspective
432	`/designer`	Design-thinking perspective
433	`/architect`	Architecture mindset
434	`/productmanager`	Product management view
435	`/founder`	Founder perspective
436	`/ceo`	Executive decision perspective
437	`/investorview`	Investor evaluation
438	`/customer`	Customer perspective
439	`/beginner`	Beginner explanation
440	`/advanced`	Advanced explanation
441	`/stepbystep`	Sequential instructions
442	`/interactive`	Interactive problem solving
443	`/walkthrough`	Detailed walkthrough
444	`/simulation`	Scenario simulation
445	`/negotiation`	Negotiation simulation
446	`/debate`	Opposing viewpoints
447	`/counterargument`	Counterarguments
448	`/critique`	Critical evaluation
449	`/improveidea`	Strengthen an idea
450	`/validate`	Validate an idea
451	`/assumptions`	Identify assumptions
452	`/constraints`	Identify constraints
453	`/tradeoffs`	Explain trade-offs
454	`/opportunities`	Find opportunities
455	`/risksfuture`	Future risk analysis
456	`/trendanalysis`	Analyze trends
457	`/forecastfuture`	Explore possible futures
458	`/signals`	Detect weak signals
459	`/emergingtech`	Explore emerging technology
460	`/futureproof`	Future-ready planning
461	`/automation`	Find automation opportunities
462	`/workflow`	Design workflows
463	`/pipeline`	Create process pipelines
464	`/systemthinking`	Systems analysis
465	`/mentalmodels`	Apply mental models
466	`/heuristics`	Decision heuristics
467	`/principles`	Identify core principles
468	`/frameworkcompare`	Compare frameworks
469	`/bestpractice`	Industry practices
470	`/mistakes`	Identify common mistakes
471	`/dosanddonts`	Do's and Don'ts
472	`/quickwins`	Fast improvements
473	`/optimization`	Optimize performance
474	`/efficiency`	Improve efficiency
475	`/automationplan`	Automation roadmap
476	`/aiworkflow`	AI-assisted workflow
477	`/promptaudit`	Audit prompts
478	`/promptlibrary`	Organize prompts
479	`/promptchain`	Chain prompts
480	`/metaprompt`	Generate prompts
481	`/systemprompt`	Draft system prompts
482	`/persona`	Create personas
483	`/role`	Define a role
484	`/simulateexpert`	Expert-perspective simulation
485	`/multiexpert`	Multiple perspectives
486	`/consensus`	Find agreement
487	`/disagreement`	Identify disagreement
488	`/evidence`	Support claims with evidence
489	`/confidence`	Estimate confidence
490	`/uncertainty`	Explain uncertainty
491	`/limitations`	Identify limitations
492	`/assess`	Comprehensive assessment
493	`/scorecard`	Create scoring framework
494	`/ranking`	Rank options
495	`/matrixcompare`	Comparison matrix
496	`/finalanswer`	Output only final answer
497	`/thinking`	High-level reasoning summary
498	`/executemode`	Focus on execution
499	`/masterprompt`	Combine prompting techniques
500	`/allinone`	Combine suitable structures

The 500-Lens Architecture

Now the bigger picture becomes interesting.

The entire collection can be represented as five layers:

                 AI WORKBENCH
                      │
     ┌────────────────┼────────────────┐
     ↓                ↓                ↓
VISUAL THINKING   CONTENT CREATION   IMAGE GENERATION
  001–100            101–200            201–300
     │                │                │
     └────────────────┼────────────────┘
                      ↓
              PRODUCTIVITY + CODE
                   301–400
                      │
                      ↓
          CREATIVE + AI WORKFLOWS
                   401–500

Together:

001–100   → THINK
101–200   → CREATE
201–300   → VISUALIZE
301–400   → BUILD
401–500   → STRATEGIZE

That's the real concept behind the collection.

From 500 Commands to One System

A sophisticated AI workflow might look like:

               USER GOAL
                   ↓
             /brainstorm
                   ↓
              /options
                   ↓
            /compareideas
                   ↓
             /constraints
                   ↓
              /tradeoffs
                   ↓
             /systemthinking
                   ↓
              /aiworkflow
                   ↓
              /promptchain
                   ↓
                /audit
                   ↓
              /finalanswer

Each lens performs a different function.

The result is not necessarily a “better prompt.”

It is a better workflow.

The Most Important Lesson

After building a collection of 500 lenses, one principle stands out:

The quality of an AI interaction depends heavily on whether the task has been properly framed.

A useful conceptual model is:

AI Output Quality
        ≈
Context
× Task Definition
× Constraints
× Relevant Perspective
× Verification

This is not a scientific equation or guaranteed quality formula—it's a useful design model.

And it highlights something important:

Adding more words isn't the same as adding better instructions.

The Future of Prompting?

Maybe the future isn't:

ONE GIANT PROMPT

Maybe it looks more like:

                 AI SYSTEM
                     │
        ┌────────────┼────────────┐
        ↓            ↓            ↓
      LENS         WORKFLOW     EVALUATOR
        │            │            │
        ↓            ↓            ↓
   Perspective    Process      Verification
        └────────────┼────────────┘
                     ↓
                  OUTPUT

Instead of memorizing hundreds of commands, an AI assistant could eventually infer:

“This is a research problem, so I need evidence, uncertainty, assumptions, and evaluation.”

Or:

“This is a debugging task, so I need reproduction steps, constraints, logs, hypotheses, and regression testing.”

That is a much more interesting direction than simply making prompts longer.

Final Question

If you could add one #501 lens to this collection, what would it be?

Mine would probably be:

/verify

Because generating an answer is only half the problem.

Knowing whether the answer deserves to be trusted is the other half.

AI #PromptEngineering #ArtificialIntelligence #AITools #Productivity #Programming #DeveloperTools #Research #CreativeThinking #ChatGPT #DevCommunity

100 Writing, Productivity, Coding & Research Lenses for ChatGPT 🧠💻

Probal Dhali — Mon, 24 Aug 2026 15:49:19 +0000

From fixing one sentence to designing an algorithm, AI becomes much more useful when you stop treating it as a single-purpose chatbot.

Instead, think of it as a collection of specialized working modes.

Need to debug?

/debug

Need to design an algorithm?

/algorithm

Need to plan research?

/researchplan

Need to challenge your own argument?

/critic

Need to turn a large project into manageable work?

/roadmap90

The underlying idea is simple:

Don't just ask AI for an answer. Give it a mode of thinking.

From Prompt → Workflow

A normal interaction might look like:

User
  ↓
Question
  ↓
AI
  ↓
Answer

A structured workflow looks different:

Goal
 ↓
Context
 ↓
Lens
 ↓
Analysis
 ↓
Output
 ↓
Review
 ↓
Iteration

For example:

Project
  ↓
/researchplan
  ↓
Research questions
  ↓
/hypothesis
  ↓
Testable assumptions
  ↓
/experiment
  ↓
Evaluation
  ↓
/audit
  ↓
Final findings

The shortcut is not magic.

It is a task-specific instruction layer.

1. Writing Lenses

The first group focuses on transforming existing text.

/rewrite
/improve
/polish
/proofread
/grammar
/copyedit
/expand
/shorten
/paraphrase
/simplifytext

These commands represent different operations.

For example:

/rewrite

should preserve the original meaning while changing the wording.

Whereas:

/improve

can address:

clarity
structure
flow
word choice
readability

And:

/shorten

optimizes for concision.

This distinction matters because:

Editing and rewriting are not the same task.

2. Tone Is a Control Variable

The next group controls communication style:

/formal
/casual
/friendly
/professional
/persuasive
/convincing
/academic
/journalistic

The same information can be communicated differently depending on the audience.

For example:

Technical explanation
        ↓
 ┌──────┼──────┐
 ↓      ↓      ↓
Student Developer Executive

The underlying facts should remain stable.

The presentation changes.

That makes tone a communication parameter, not merely decoration.

3. Structured Writing

For longer outputs:

/story
/essay
/article
/report
/whitepaper
/casestudy
/proposal
/sop
/playbook
/manual
/guide
/faq

These commands define the output structure.

For example:

Problem
 ↓
Context
 ↓
Analysis
 ↓
Evidence
 ↓
Recommendation
 ↓
Conclusion

This is much more useful than simply saying:

“Write a detailed report.”

A structured request reduces ambiguity.

4. Information Compression

Large amounts of information often need to be compressed.

Useful lenses include:

/bulletpoints
/keypoints
/highlights
/notes

Think of this as:

100 pages
    ↓
Information extraction
    ↓
Important concepts
    ↓
Key points
    ↓
Actionable notes

The goal isn't simply to make text shorter.

The goal is to preserve the information that matters.

5. Meetings and Collaboration

For collaborative work:

/minutes
/agenda
/meetingsummary
/todo

A meeting can become:

Discussion
    ↓
Decisions
    ↓
Action Items
    ↓
Owners
    ↓
Deadlines

That is a much more useful representation than a raw transcript.

6. Project Management

Large projects benefit from explicit planning.

The toolkit includes:

/kanban
/gantt
/okr
/kpi
/smartgoals
/roadmap90
/roadmapyear
/milestones

A simple project decomposition might look like:

VISION
  ↓
OBJECTIVES
  ↓
MILESTONES
  ↓
TASKS
  ↓
DEPENDENCIES
  ↓
EXECUTION
  ↓
METRICS

This turns a vague goal into an executable system.

7. Goals Need Measurement

A goal without a measurement strategy is difficult to evaluate.

That's where:

/okr
/kpi
/smartgoals
/metrics
/dashboardmetrics

become useful.

For example:

Goal:
Improve application performance

can become:

Objective:
Reduce application response time

Key Results:
↓ p95 latency
↓ error rate
↑ throughput

The important shift is:

“I want it better.”
        ↓
“How will we know it is better?”

That question makes planning measurable.

8. Risk Analysis

Projects rarely fail because everything went according to plan.

Useful lenses:

/risks
/riskmatrix
/dependencies
/estimate
/budget
/forecast

A basic risk model:

              IMPACT
           Low    High
        ┌──────┬──────┐
Low     │      │      │
        ├──────┼──────┤
High    │      │  🔴  │
        └──────┴──────┘
         LIKELIHOOD

The goal isn't to eliminate uncertainty.

It's to identify which uncertainties deserve attention first.

9. Root-Cause Analysis

When something goes wrong, the first explanation isn't always the real explanation.

Useful analytical lenses:

/decisiontree
/fishbone
/pareto
/lean
/sixsigma

For example:

Problem
  ↓
Why?
  ↓
Why?
  ↓
Why?
  ↓
Root Cause

A Fishbone-style analysis can separate causes into categories such as:

People
Process
Technology
Environment
Data
Measurement

This is much more useful than asking AI:

“Why did this fail?”

without providing a framework.

10. Productivity

Productivity lenses include:

/productivity
/timemanagement
/pomodoro

But productivity shouldn't simply mean:

“Do more tasks.”

A better model is:

Priorities
 ↓
Focus
 ↓
Execution
 ↓
Feedback
 ↓
Adjustment

AI can help with planning and prioritization, but the actual constraints of your schedule and environment still matter.

11. Learning and Study

The educational group includes:

/studyplan
/revisionplan
/learningpath
/feynman
/memory
/mnemonics
/practice
/challengequestions

A learning workflow could be:

Learn
 ↓
Explain
 ↓
Recall
 ↓
Practice
 ↓
Test
 ↓
Identify gaps
 ↓
Review

The Feynman technique is particularly useful:

Learn concept
     ↓
Explain simply
     ↓
Find gaps
     ↓
Study gaps
     ↓
Explain again

The important part is active retrieval and feedback—not simply generating longer notes.

12. Coding Lenses

Now we enter one of the most useful categories for developers:

/coding
/explaincode
/debug
/refactor
/optimizecode
/reviewcode

These represent different software-engineering activities.

They should not be treated as interchangeable.

13. Writing Code vs Reviewing Code

For example:

/coding

asks AI to produce an implementation.

While:

/reviewcode

asks it to inspect an existing implementation.

The difference:

Generation
   ↓
“Create something.”

Review
   ↓
“Evaluate something.”

That distinction is important because code generation and code evaluation have different failure modes.

14. Debugging

A useful debugging workflow is:

Bug
 ↓
Reproduce
 ↓
Observe
 ↓
Hypothesis
 ↓
Test
 ↓
Fix
 ↓
Regression Test

The /debug lens should encourage this process.

Instead of:

“Fix this.”

a stronger debugging request provides:

Expected behavior
Actual behavior
Error message
Relevant code
Environment
Steps to reproduce

Better context usually produces better debugging.

15. Refactoring

Refactoring is different from optimization.

/refactor

focuses on:

readability
maintainability
structure
duplication
separation of concerns

Whereas:

/optimizecode

focuses on:

runtime
memory
algorithmic complexity
I/O
resource usage

A clean implementation isn't automatically the fastest implementation.

And the fastest implementation isn't automatically the best design.

16. Algorithms and Data Structures

For algorithmic problems:

/pseudocode
/algorithm
/datastructure

A useful workflow:

Problem
 ↓
Constraints
 ↓
Input / Output
 ↓
Candidate approaches
 ↓
Complexity analysis
 ↓
Data structure
 ↓
Algorithm
 ↓
Implementation
 ↓
Testing

This is particularly important for technical interviews and competitive programming.

17. SQL and Data

The toolkit also includes:

/sql
/regex
/json
/yaml
/csv
/xml

These are practical transformation and data-manipulation tasks.

For SQL, however, the database schema matters enormously.

A strong SQL request should include:

Tables
Columns
Relationships
Constraints
Sample data
Expected result
Database engine

For example:

PostgreSQL
≠
SQL Server
≠
MySQL

Even when the syntax looks similar.

18. API Design

The /api lens can help reason about:

Endpoints
HTTP methods
Request schemas
Response schemas
Authentication
Errors
Versioning
Pagination
Validation

A simple API lifecycle:

Client
  ↓
Request
  ↓
Validation
  ↓
Authentication
  ↓
Business Logic
  ↓
Database / Service
  ↓
Response

Thinking in this structure makes API design more systematic.

19. Research

Research requires a different mindset.

Useful lenses:

/researchplan
/literaturereview
/hypothesis
/experiment
/peerreview
/critic
/audit

A structured research workflow:

Research Question
        ↓
Literature
        ↓
Gap
        ↓
Hypothesis
        ↓
Method
        ↓
Experiment
        ↓
Evidence
        ↓
Analysis
        ↓
Conclusion

AI can help organize this process, but generated references, claims, statistics, and citations still need verification.

20. Hypothesis vs Opinion

A hypothesis should be testable.

For example:

Opinion:
“This model seems better.”

Hypothesis:
“Model A will achieve higher F1-score than Model B
on dataset X under the same evaluation protocol.”

The second statement can actually be tested.

That's a major difference.

21. Experiment Design

The /experiment lens can help structure:

Independent variable
Dependent variable
Controls
Dataset
Procedure
Evaluation metric
Expected outcome
Threats to validity

A simplified structure:

        EXPERIMENT
             │
     ┌───────┼────────┐
     ↓       ↓        ↓
  INPUT   METHOD   CONTROL
     │       │        │
     └───────┼────────┘
             ↓
          OUTPUT
             ↓
         METRICS
             ↓
       INTERPRETATION

This is much stronger than simply asking AI:

“Design an experiment.”

22. Peer Review and Criticism

Two particularly useful lenses are:

/peerreview
/critic

Their purpose should not be:

“Find everything wrong.”

Instead:

Claim
 ↓
Evidence
 ↓
Reasoning
 ↓
Assumptions
 ↓
Limitations
 ↓
Alternative explanations

A strong critique should distinguish:

Fact
Inference
Assumption
Opinion
Uncertainty

This is one of the most useful habits when working with AI-generated material.

23. The `/audit` Lens

An audit is broader than a review.

For example:

Technical Audit

could inspect:

Architecture
Security
Performance
Maintainability
Testing
Dependencies
Documentation
Deployment

A research audit could inspect:

Sources
Methodology
Evidence
Statistics
Claims
Limitations
Reproducibility

The same underlying lens can therefore be adapted to different domains.

24. The Meta-Lens: `/framework`

The final shortcut is:

/framework

This is arguably one of the most powerful concepts in the collection.

Instead of asking:

“Which framework should I use?”

you can ask AI to first determine:

Problem
 ↓
Characteristics
 ↓
Candidate frameworks
 ↓
Selection criteria
 ↓
Most suitable framework
 ↓
Application

For example:

Root cause?
→ Fishbone

Prioritization?
→ Pareto

Project execution?
→ Kanban / Scrum

Strategic analysis?
→ SWOT / PESTLE

Experiment?
→ Experimental design

Decision?
→ Decision tree / decision matrix

The framework should match the problem.

The Complete 100-Lens Map

#	Shortcut	Purpose
301	`/rewrite`	Rewrite while preserving meaning
302	`/improve`	Improve clarity and quality
303	`/polish`	Make writing smoother
304	`/proofread`	Correct grammar and spelling
305	`/grammar`	Fix grammar only
306	`/copyedit`	Professional copy editing
307	`/expand`	Add useful detail
308	`/shorten`	Condense content
309	`/paraphrase`	Reword naturally
310	`/simplifytext`	Use simpler language
311	`/formal`	Formal tone
312	`/casual`	Casual conversational tone
313	`/friendly`	Warm, friendly tone
314	`/professional`	Professional business tone
315	`/persuasive`	Strengthen persuasion
316	`/convincing`	Strengthen arguments
317	`/academic`	Academic style
318	`/journalistic`	News-style writing
319	`/story`	Story format
320	`/essay`	Essay format
321	`/article`	Article format
322	`/report`	Professional report
323	`/whitepaper`	White-paper structure
324	`/casestudy`	Case-study format
325	`/proposal`	Business proposal
326	`/sop`	Standard operating procedure
327	`/playbook`	Reusable playbook
328	`/manual`	User manual
329	`/guide`	Step-by-step guide
330	`/faq`	Frequently asked questions
331	`/checklist`	Checklist format
332	`/template`	Reusable template
333	`/outline`	Structured outline
334	`/bulletpoints`	Bullet summary
335	`/keypoints`	Key takeaways
336	`/highlights`	Important ideas
337	`/notes`	Study notes
338	`/minutes`	Meeting minutes
339	`/agenda`	Meeting agenda
340	`/meetingsummary`	Meeting summary
341	`/todo`	Task list
342	`/kanban`	Kanban task board
343	`/gantt`	Gantt-style plan
344	`/okr`	Objectives and key results
345	`/kpi`	Key performance indicators
346	`/smartgoals`	SMART goals
347	`/roadmap90`	90-day roadmap
348	`/roadmapyear`	Annual roadmap
349	`/milestones`	Project milestones
350	`/risks`	Risk assessment
351	`/riskmatrix`	Likelihood × impact
352	`/dependencies`	Task dependencies
353	`/estimate`	Effort/time estimation
354	`/budget`	Budget planning
355	`/forecast`	Forecasting
356	`/metrics`	Useful metrics
357	`/dashboardmetrics`	Dashboard KPI ideas
358	`/decisiontree`	Decision-tree analysis
359	`/fishbone`	Root-cause analysis
360	`/pareto`	80/20 analysis
361	`/lean`	Lean methodology
362	`/sixsigma`	Six Sigma approach
363	`/agile`	Agile methodology
364	`/scrum`	Scrum framework
365	`/kanbanflow`	Kanban workflow
366	`/productivity`	Productivity optimization
367	`/timemanagement`	Time management
368	`/pomodoro`	Pomodoro scheduling
369	`/studyplan`	Study plan
370	`/revisionplan`	Revision timetable
371	`/learningpath`	Progressive learning path
372	`/feynman`	Feynman technique
373	`/memory`	Memory techniques
374	`/mnemonics`	Mnemonic creation
375	`/practice`	Practice exercises
376	`/challengequestions`	Difficult questions
377	`/coding`	Write code
378	`/explaincode`	Explain code
379	`/debug`	Debug code
380	`/refactor`	Refactor code
381	`/optimizecode`	Optimize performance
382	`/reviewcode`	Code review
383	`/pseudocode`	Generate pseudocode
384	`/algorithm`	Design algorithms
385	`/datastructure`	Choose data structures
386	`/sql`	Generate SQL
387	`/regex`	Generate regular expressions
388	`/api`	Design/explain APIs
389	`/json`	Work with JSON
390	`/yaml`	Generate YAML
391	`/csv`	Generate CSV
392	`/xml`	Generate XML
393	`/researchplan`	Plan research
394	`/literaturereview`	Review literature
395	`/hypothesis`	Generate testable hypotheses
396	`/experiment`	Design experiments
397	`/peerreview`	Critical peer review
398	`/critic`	Constructive criticism
399	`/audit`	Comprehensive audit
400	`/framework`	Select an appropriate analytical framework

The Bigger Picture

The interesting thing about these 100 lenses is that they can be connected.

For example, building a software project:

IDEA
 ↓
/researchplan
 ↓
/proposal
 ↓
/roadmap90
 ↓
/milestones
 ↓
/dependencies
 ↓
/coding
 ↓
/reviewcode
 ↓
/debug
 ↓
/optimizecode
 ↓
/audit

Writing a research paper:

QUESTION
 ↓
/researchplan
 ↓
/literaturereview
 ↓
/hypothesis
 ↓
/experiment
 ↓
/analysis
 ↓
/critic
 ↓
/peerreview
 ↓
/article

Preparing for an exam:

SYLLABUS
 ↓
/learningpath
 ↓
/studyplan
 ↓
/notes
 ↓
/feynman
 ↓
/practice
 ↓
/challengequestions
 ↓
/revisionplan

That's where these shortcuts become more interesting.

They stop being isolated commands and become workflow components.

The Core Principle

There is a temptation to think:

“The more detailed the prompt, the better.”

I don't think that's always true.

A better principle is:

Give the model the right context, the right task, the right constraints, and the right evaluation criteria.

A useful conceptual model is:

Better Result
     =
Context
+
Task
+
Constraints
+
Relevant Lens
+
Evaluation

Not:

Better Result
=
More Words

Final Thought

The most interesting future for AI assistants may not be about having one enormous prompt.

It may be about having many small, composable reasoning modes.

Instead of:

“AI, do everything.”

We move toward:

AI
 ├── Writer
 ├── Researcher
 ├── Programmer
 ├── Reviewer
 ├── Planner
 ├── Analyst
 ├── Teacher
 └── Auditor

And the user chooses the appropriate lens for the current problem.

That makes AI interaction feel less like asking a chatbot a question—

and more like operating a general-purpose cognitive workbench.

What would you add?

If you could add one more shortcut to this 301–400 collection, what would it be?

Maybe:

/securityaudit

/testcode

/factcheck

/architecture

/benchmark

/citationcheck

or something completely different?

I'm especially interested in shortcuts that can turn AI from a content generator into a verification and reasoning tool.

AI #ChatGPT #Productivity #Programming #SoftwareEngineering #Research #PromptEngineering #DeveloperTools #Coding #ArtificialIntelligence #DevCommunity #Learning

100 AI Image Prompting Lenses: From Photography to 3D, Illustration & Visual Design 🎨🤖

Probal Dhali — Mon, 24 Aug 2026 15:47:53 +0000

AI image generation has changed how we think about visual creation.

A few years ago, creating a professional visual often required:

Camera
+
Lighting
+
Location
+
Subject
+
Lens
+
Editing
+
Design Software

Today, an AI image model can generate many of those visual decisions from natural language.

But there is a catch.

Better prompts don't simply contain more words. They contain better visual decisions.

That is why I started thinking about image prompting as a visual design system rather than a collection of random keywords.

From “Make an Image” to Visual Specification

Compare these two prompts.

Basic

Create a futuristic city.

The model has to invent almost everything.

Now consider:

A futuristic metropolitan city at blue hour,
wide-angle architectural photography,
dense vertical buildings,
reflective glass surfaces,
pedestrian-level perspective,
soft atmospheric haze,
controlled cyan and amber lighting,
deep depth of field,
cinematic composition,
high-detail environmental realism.

The second prompt defines:

Subject
+
Environment
+
Perspective
+
Lighting
+
Camera language
+
Atmosphere
+
Visual style

That's the fundamental idea behind these 100 lenses.

A Visual Prompt Is a Stack

I think a useful mental model is:

                 VISUAL IDEA
                      ↓
                   SUBJECT
                      ↓
                 ENVIRONMENT
                      ↓
                 COMPOSITION
                      ↓
                 CAMERA/LENS
                      ↓
                   LIGHTING
                      ↓
                   MATERIAL
                      ↓
                 ART DIRECTION
                      ↓
                 POST-PROCESSING
                      ↓
                  FINAL IMAGE

Not every prompt needs every layer.

But thinking in layers gives you much more control.

1. Photography Lenses

The first group focuses on photographic realism.

/photorealistic
/hyperrealistic
/cinematicphoto
/portrait
/headshot
/editorial
/fashion
/lifestyle
/streetphoto
/travelphoto
/wildlife
/macrophoto

These aren't simply “quality settings.”

They describe different visual goals.

For example:

Portrait

usually emphasizes:

subject identity,
facial lighting,
expression,
skin detail,
composition.

Whereas:

Street photography

might emphasize:

candid moments,
environmental context,
natural lighting,
urban composition,
documentary realism.

2. Perspective Is a Design Decision

The camera position can completely change an image.

Consider:

/topdown

You see the scene from above.

/lowangle

The subject can appear larger and more imposing.

/highangle

The subject may appear smaller or more vulnerable.

/wideangle

creates a stronger sense of spatial depth.

/telephoto

can compress the apparent distance between objects.

So instead of:

“Show a futuristic car.”

you could specify:

Low-angle automotive photograph,
camera positioned close to ground level,
wide environmental perspective,
dramatic city architecture in background.

Now the camera becomes part of the storytelling.

3. Depth of Field Controls Attention

Two useful lenses are:

/depthoffield
/bokeh

They are related but not identical.

A shallow depth of field can separate a subject from the background.

For example:

Professional portrait,
85mm portrait-lens look,
shallow depth of field,
soft background separation,
natural skin texture.

The visual hierarchy becomes:

SUBJECT
  ↑
sharp

BACKGROUND
  ↓
soft

This is useful because visual attention is partly controlled through focus.

4. Lighting Is One of the Strongest Prompt Variables

Lighting can completely change the emotional character of an image.

The toolkit includes:

/goldenhour
/bluehour
/sunset
/sunrise
/nightmode
/neon
/moody
/dramaticlighting
/volumetriclight
/rimlight
/silhouette
/backlit

For example:

Mountain landscape at golden hour,
warm directional sunlight,
long shadows,
soft atmospheric haze,
natural volumetric rays.

Compare that with:

Mountain landscape at blue hour,
cool ambient light,
deep shadows,
subtle mist,
cinematic atmosphere.

Same subject.

Completely different emotional result.

5. Lighting Should Describe Direction

Instead of simply saying:

“Beautiful lighting”

try describing:

Key light
+
Fill light
+
Rim light
+
Light direction
+
Intensity
+
Color temperature

For example:

Portrait with soft key light from camera-left,
subtle fill light,
thin rim light separating the subject from the background,
natural skin tones,
controlled contrast.

That's much more actionable visually.

6. Film and Analog Aesthetics

The toolkit includes:

/blackandwhite
/filmgrain
/kodak
/fujifilm
/polaroid
/vintage
/retro
/80s
/90s

These are useful for specifying a visual era or photographic character.

But an important distinction:

A film aesthetic isn't only a color filter.

It can involve:

Color response
+
Contrast
+
Grain
+
Exposure
+
Highlight roll-off
+
Lens characteristics
+
Composition

For example, instead of:

Make it look vintage.

you could describe:

Analog-inspired editorial photograph,
subtle film grain,
soft highlight roll-off,
moderate contrast,
slightly muted colors,
natural imperfections,
archival photographic character.

7. Futuristic Worlds

The collection also contains environment-oriented lenses:

/cyberpunk
/steampunk
/dieselpunk
/solarpunk
/postapocalyptic
/fantasy
/scifi

These shouldn't be thought of as simple “style buttons.”

They describe world-building directions.

For example:

Solarpunk

Think:

Renewable energy
+
Green architecture
+
Human-centered cities
+
Natural materials
+
Clean technology

Cyberpunk

Think:

Dense urban environment
+
High technology
+
Strong artificial lighting
+
Weathered infrastructure
+
High visual contrast

The interesting part is understanding the visual ingredients behind the label.

8. Space and Natural Environments

The collection includes:

/space
/planet
/galaxy
/nebula
/underwater
/ocean
/mountains
/forest
/desert
/cityscape

These are primarily environment generators.

A useful environmental prompt can combine:

Subject
+
Scale
+
Atmosphere
+
Terrain
+
Lighting
+
Weather
+
Camera

Example:

Massive alien observatory on a rocky planet,
vast planetary horizon,
thin atmospheric haze,
distant nebula visible in the sky,
small human-scale structure emphasizing enormous environment,
cinematic wide-angle composition.

The scale relationship is what makes the scene believable.

9. Architecture and Interior Visualization

For architectural visualization:

/architecturephoto
/interior
/minimalinterior
/luxury

The prompt can specify:

Building geometry
+
Materials
+
Lighting
+
Camera height
+
Time of day
+
Interior styling
+
Environmental context

For example:

Minimal contemporary interior,
natural stone surfaces,
warm indirect lighting,
large floor-to-ceiling windows,
clean geometric furniture,
soft daylight entering from the right,
architectural photography,
balanced composition.

This is much closer to an architectural brief than a generic image prompt.

10. Product Visualization

Product-focused lenses include:

/productphoto
/packaging
/advertising
/billboard
/brandingmockup

A product image can be specified as:

Product
+
Material
+
Surface
+
Lighting
+
Camera
+
Background
+
Brand placement
+
Composition

For example:

Premium wireless headphones,
matte black finish,
minimal studio environment,
softbox lighting,
controlled reflections,
dark gradient background,
three-quarter product angle,
commercial product photography.

This gives the model a much clearer visual target.

11. Branding and Graphic Design

The collection also includes:

/logo
/iconset
/mascot
/characterdesign

These require a different type of thinking.

A logo prompt should focus more on:

Shape
+
Geometry
+
Symbolism
+
Typography
+
Scalability
+
Visual simplicity

A character prompt might focus on:

Silhouette
+
Proportions
+
Clothing
+
Expression
+
Color
+
Personality

The visual objective changes depending on the artifact.

12. Traditional Art

The toolkit includes:

/oilpainting
/watercolor
/acrylic
/charcoal
/pencilsketch
/inkdrawing
/crosshatching

These are useful when the desired output is not photographic.

For example:

Mountain village,
traditional watercolor illustration,
transparent layered washes,
visible paper texture,
soft edges,
limited color palette,
delicate atmospheric perspective.

The important part is to describe how the medium behaves, not just name the medium.

13. Illustration and Sequential Art

For illustrated storytelling:

/comicbook
/manga
/anime

the prompt can specify:

Character
+
Panel composition
+
Linework
+
Expression
+
Perspective
+
Lighting
+
Background

For a comic panel:

Dynamic comic-book panel,
hero standing on rooftop during heavy rain,
strong perspective,
expressive pose,
dramatic backlighting,
architectural city background,
clear foreground-midground-background separation.

The scene becomes much easier to control.

14. 3D and Game-Engine Visualization

The collection includes:

/lowpoly
/voxel
/pixelart
/clayrender
/3drender
/octanerender
/unrealengine
/blender

These represent different rendering and visual-development directions.

For example:

Low-poly

Simplified geometric forms
+
Flat surfaces
+
Controlled polygon count
+
Stylized lighting

Photorealistic 3D

Physically plausible materials
+
Realistic lighting
+
Surface detail
+
Depth
+
Accurate reflections

Clay render

Monochromatic material
+
Geometry emphasis
+
Soft studio lighting
+
Minimal textures

Again, the useful part is understanding the visual characteristics.

15. Prompt Engineering Itself

The final two lenses are particularly important:

/midjourneystyle
/imageprompt

The most useful one conceptually is:

/imageprompt

because it turns an idea into a structured visual specification.

A practical structure is:

SUBJECT
+
ACTION
+
ENVIRONMENT
+
COMPOSITION
+
CAMERA
+
LIGHTING
+
MATERIALS
+
COLOR
+
ATMOSPHERE
+
STYLE
+
QUALITY

For example:

SUBJECT:
Futuristic electric motorcycle

ENVIRONMENT:
Dense metropolitan city

COMPOSITION:
Three-quarter front view

CAMERA:
Low-angle wide-angle photography

LIGHTING:
Blue-hour ambient light with controlled neon reflections

MATERIAL:
Matte metal and carbon fiber

ATMOSPHERE:
Light rain and atmospheric haze

STYLE:
Premium cinematic automotive photography

DETAIL:
Highly detailed surfaces and realistic reflections

That is essentially a visual specification.

A Better Prompt Architecture

I would structure complex prompts like this:

┌──────────────────────────────┐
│           SUBJECT            │
├──────────────────────────────┤
│           ACTION             │
├──────────────────────────────┤
│         ENVIRONMENT          │
├──────────────────────────────┤
│        COMPOSITION           │
├──────────────────────────────┤
│        CAMERA / LENS         │
├──────────────────────────────┤
│          LIGHTING            │
├──────────────────────────────┤
│        MATERIAL / TEXTURE    │
├──────────────────────────────┤
│       COLOR / PALETTE        │
├──────────────────────────────┤
│        ATMOSPHERE            │
├──────────────────────────────┤
│       ART DIRECTION          │
└──────────────────────────────┘

Not every image needs every layer.

But when an image is difficult to control, this gives you a systematic way to diagnose the problem.

Prompt Debugging

This is one of the most useful ways to think about AI image generation.

Suppose the result is wrong.

Don't immediately add 50 more adjectives.

Ask:

Wrong composition?

Change:

/composition
/camera
/perspective

Wrong mood?

Change:

/lighting
/moody
/goldenhour
/bluehour

Wrong realism?

Change:

/photorealistic
/material
/depthoffield

Wrong environment?

Change:

/architecturephoto
/cityscape
/forest
/desert

Wrong visual medium?

Change:

/oilpainting
/watercolor
/3drender
/pixelart

This is essentially debugging a visual specification.

The 100-Lens Visual System

The complete system can be represented as:

                         IDEA
                           │
                           ▼
                      ┌─────────┐
                      │ SUBJECT │
                      └────┬────┘
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
        ENVIRONMENT    COMPOSITION     CAMERA
             │             │             │
             └─────────────┼─────────────┘
                           ▼
                       LIGHTING
                           │
                           ▼
                      MATERIALS
                           │
                           ▼
                       COLOR
                           │
                           ▼
                     ATMOSPHERE
                           │
                           ▼
                    ART DIRECTION
                           │
                           ▼
                    FINAL IMAGE

This is the core philosophy behind the 100 prompts.

The 100 AI Image Prompting Lenses

#	Shortcut	Purpose
201	`/photorealistic`	Ultra-realistic image style
202	`/hyperrealistic`	Extreme realism
203	`/cinematicphoto`	Movie-like photograph
204	`/portrait`	Professional portrait
205	`/headshot`	Corporate headshot
206	`/editorial`	Magazine editorial look
207	`/fashion`	Fashion photography
208	`/lifestyle`	Lifestyle photography
209	`/streetphoto`	Street photography
210	`/travelphoto`	Travel photography
211	`/wildlife`	Wildlife photography
212	`/macrophoto`	Macro photography
213	`/droneview`	Drone aerial view
214	`/360drone`	360° aerial concept
215	`/topdown`	Top-down composition
216	`/lowangle`	Low-angle perspective
217	`/highangle`	High-angle perspective
218	`/wideangle`	Wide-angle lens look
219	`/telephoto`	Telephoto compression
220	`/fisheye`	Fisheye perspective
221	`/depthoffield`	Shallow/deep focus control
222	`/bokeh`	Soft background blur
223	`/goldenhour`	Golden-hour lighting
224	`/bluehour`	Blue-hour lighting
225	`/sunset`	Sunset atmosphere
226	`/sunrise`	Sunrise atmosphere
227	`/nightmode`	Night photography
228	`/neon`	Neon lighting
229	`/moody`	Dark cinematic mood
230	`/dramaticlighting`	Strong dramatic lighting
231	`/volumetriclight`	Volumetric light
232	`/rimlight`	Rim lighting
233	`/silhouette`	Silhouette composition
234	`/backlit`	Backlit subject
235	`/blackandwhite`	Monochrome style
236	`/filmgrain`	Film-grain aesthetic
237	`/kodak`	Kodak-inspired film aesthetic
238	`/fujifilm`	Fujifilm-inspired color aesthetic
239	`/polaroid`	Instant-photo aesthetic
240	`/vintage`	Vintage aesthetic
241	`/retro`	Retro design
242	`/80s`	1980s-inspired aesthetic
243	`/90s`	1990s-inspired aesthetic
244	`/cyberpunk`	Cyberpunk world-building
245	`/steampunk`	Steampunk world-building
246	`/dieselpunk`	Dieselpunk aesthetic
247	`/solarpunk`	Sustainable-future aesthetic
248	`/postapocalyptic`	Post-apocalyptic environment
249	`/fantasy`	Fantasy artwork
250	`/scifi`	Science-fiction artwork
251	`/space`	Outer-space visual
252	`/planet`	Planetary environment
253	`/galaxy`	Galaxy visualization
254	`/nebula`	Nebula artwork
255	`/underwater`	Underwater scene
256	`/ocean`	Ocean landscape
257	`/mountains`	Mountain scenery
258	`/forest`	Forest environment
259	`/desert`	Desert environment
260	`/cityscape`	Urban skyline
261	`/architecturephoto`	Architectural photography
262	`/interior`	Interior visualization
263	`/minimalinterior`	Minimal interior concept
264	`/luxury`	Luxury visual aesthetic
265	`/productphoto`	Product photography
266	`/packaging`	Packaging mockup
267	`/advertising`	Advertising visual
268	`/billboard`	Billboard mockup
269	`/posterdesign`	Poster concept
270	`/brandingmockup`	Brand identity preview
271	`/logo`	Logo concept
272	`/iconset`	Custom icon system
273	`/mascot`	Mascot character
274	`/characterdesign`	Original character design
275	`/conceptart`	Concept art
276	`/environmentart`	Environment concept art
277	`/mattepainting`	Matte-painting-inspired environment
278	`/digitalpainting`	Digital painting
279	`/oilpainting`	Oil-painting medium
280	`/watercolor`	Watercolor illustration
281	`/acrylic`	Acrylic-painting medium
282	`/charcoal`	Charcoal sketch
283	`/pencilsketch`	Pencil drawing
284	`/inkdrawing`	Ink illustration
285	`/crosshatching`	Cross-hatching technique
286	`/comicbook`	Comic-book visual language
287	`/manga`	Manga-inspired visual language
288	`/anime`	Anime-inspired visual language
289	`/ghibli`	Hand-painted animated-film-inspired aesthetic
290	`/pixar`	Polished 3D animated-film-inspired aesthetic
291	`/lowpoly`	Low-poly 3D
292	`/voxel`	Voxel art
293	`/pixelart`	Pixel art
294	`/clayrender`	Clay-render visualization
295	`/3drender`	Photorealistic 3D render
296	`/octanerender`	High-end physically based render aesthetic
297	`/unrealengine`	Real-time-engine cinematic aesthetic
298	`/blender`	Blender-style 3D visualization
299	`/midjourneystyle`	Structured generative-art prompt direction
300	`/imageprompt`	Convert an idea into a detailed image prompt

How I Would Use the 100 Lenses

Don't use all 100 at once.

That's probably the fastest way to create an over-specified prompt.

Instead, choose one lens from each relevant category.

Example: Professional Portrait

/portrait
+
/depthoffield
+
/rimlight
+
/editorial

Example: Futuristic City

/cityscape
+
/wideangle
+
/bluehour
+
/scifi
+
/cinematicphoto

Example: Product Advertisement

/productphoto
+
/advertising
+
/dramaticlighting
+
/minimal

Example: Fantasy Environment

/environmentart
+
/fantasy
+
/volumetriclight
+
/wideangle

This creates a modular prompting system.

One Idea → Multiple Visual Directions

Suppose the base idea is:

“A futuristic electric motorcycle.”

You could generate completely different directions.

Cinematic

/cinematicphoto
/lowangle
/bluehour

Commercial

/productphoto
/advertising
/minimal

Sci-Fi

/scifi
/neon
/wideangle

Concept Art

/conceptart
/environmentart
/dramaticlighting

3D

/3drender
/blender
/rimlight

Same concept.

Different visual language.

The Real Skill Is Visual Decomposition

The most important skill isn't memorizing 100 commands.

It's learning to look at an image and ask:

What is the subject?

Where is the camera?

What lens perspective is being simulated?

Where is the light coming from?

What is sharp?

What is blurred?

What materials are visible?

What is the environment?

What creates the mood?

What visual medium is being used?

That is essentially visual reverse engineering.

And once you can decompose an image, you can reconstruct the idea as a prompt.

Final Framework

I think AI image prompting is moving from:

“Write a creative sentence.”

toward:

“Specify a visual system.”

A strong prompt can be thought of as:

IDEA
 ↓
SUBJECT
 ↓
ENVIRONMENT
 ↓
COMPOSITION
 ↓
CAMERA
 ↓
LIGHT
 ↓
MATERIAL
 ↓
COLOR
 ↓
ATMOSPHERE
 ↓
STYLE
 ↓
IMAGE

The 100 lenses are simply shortcuts for controlling different parts of that system.

The goal isn't to use more keywords.

The goal is to make better visual decisions before generating the image.

Question for the Community

If you could keep only 5 image-prompting lenses, which would you choose?

Would you prioritize:

/photorealistic
/cinematicphoto
/dramaticlighting
/wideangle
/conceptart
/3drender
/imageprompt
/productphoto

—or something else?

I'd love to hear how photographers, designers, developers, artists, and AI creators approach prompting differently.

AI #GenerativeAI #AIArt #ImageGeneration #PromptEngineering #DigitalArt #Photography #Design #ArtificialIntelligence #CreativeAI #AICreators #DevCommunity

100 Content Creation Lenses: A Practical Framework for Hooks, Storytelling, Video, SEO & Marketing 🚀

Probal Dhali — Mon, 24 Aug 2026 15:46:25 +0000

Creating content consistently is harder than creating a single good post.

The difficult part isn't only writing.

It's deciding:

What should the opening hook be?
Which format fits the platform?
Where will audience attention drop?
How should a technical idea become a story?
What should become a short-form video?
What belongs in a newsletter?
How should existing content be repurposed?
Which claims need evidence?
What should the audience do next?

I started thinking about this as a content-system problem rather than a writing problem.

Instead of asking:

“Can AI write my post?”

a more useful question is:

“Can I give AI the right lens for the communication problem I'm trying to solve?”

That led me to build a second collection of 100 content, social-media, storytelling, video, SEO, and marketing lenses.

Content Creation Is a Pipeline

A useful mental model is:

IDEA
 ↓
AUDIENCE
 ↓
ANGLE
 ↓
HOOK
 ↓
STORY / INFORMATION
 ↓
FORMAT
 ↓
EDITING
 ↓
CTA
 ↓
DISTRIBUTION
 ↓
FEEDBACK
 ↓
ITERATION

AI can potentially assist at almost every stage.

But the quality of the result depends heavily on what problem you're asking it to solve.

For example:

“Write a post about AI”

is extremely broad.

Compare that with:

/hook
Create 10 technically accurate opening hooks
for a developer audience interested in AI coding agents.

The second instruction defines the task more precisely.

1. Attention Is a Design Problem

The first group of lenses focuses on attention.

Examples:

/viral
/viralhook
/hook
/hook10
/hook50
/retention
/retentioncurve
/patterninterrupt
/openloop
/curiosity

These shouldn't be treated as guaranteed “viral buttons.”

There is no reliable command that guarantees virality.

Instead, they help explore different communication strategies.

For example:

Topic:
AI coding agents

Basic opening:

“AI coding agents are becoming popular.”

Potential stronger opening:

“Your AI coding agent can pass every test
and still make the wrong engineering decision.”

The second version creates a specific tension.

The reader immediately has a question:

How can code pass tests and still be wrong?

That's a much stronger starting point for a technical article.

2. Retention Is More Than a Hook

A common mistake is focusing entirely on the first sentence.

But long-form content has an entire attention curve:

Attention
  │\
  │ \
  │  \___
  │      \__
  │         \__
  │            \
  └─────────────────→ Time
     Hook → Value → Payoff

The /retention and /retentioncurve lenses are useful for thinking about the whole journey.

A strong article should continuously answer:

“Why should I keep reading?”

That can come from:

unanswered questions,
new evidence,
examples,
progressive explanations,
visual changes,
useful discoveries,
practical takeaways.

3. Storytelling for Technical Content

Technical content doesn't have to be boring.

A useful structure is:

Problem
 ↓
Why it matters
 ↓
Unexpected observation
 ↓
Investigation
 ↓
Evidence
 ↓
Solution
 ↓
Lesson

This is where lenses such as:

/storytelling
/herojourney
/narration
/monologue
/dialogue
/podcast

can help structure communication.

For example, instead of:

“I implemented a programming language in Python.”

you could structure the story as:

I wanted to understand what actually happens
between source code and execution.

So I started with a lexer.

Then I discovered that tokenization was
only the beginning...

Lexer
 ↓
Parser
 ↓
AST
 ↓
Interpreter
 ↓
Runtime

Now the technical information has a narrative.

4. Short-Form Video Is a Different Medium

A 2,000-word technical article shouldn't simply be read aloud over stock footage.

Short-form content needs different information density.

A useful structure is:

0–3 sec
HOOK

3–10 sec
CONTEXT

10–35 sec
CORE IDEA

35–50 sec
PROOF / EXAMPLE

50–60 sec
PAYOFF / CTA

That's why these lenses exist separately:

/script30
/script60
/script90
/script180
/viralreel
/viralshorts
/reels
/shorts
/tiktok

The goal isn't merely shortening the article.

It's restructuring the information for the medium.

5. Video Needs Visual Thinking

A good technical video needs more than narration.

For example:

Voice:
“An AI agent can pass tests but still
make the wrong architectural decision.”

Visual:
Architecture A

API
 ↓
Service
 ↓
Database

CUT

Visual:
Architecture B

API
 ↓
Event Bus
 ↓
Service
 ↓
Database

Now the audience can see the context shift.

That's where:

/broll
/shotlist
/cameraangles
/storyboardpro
/sceneplan
/transitions
/motiongraphics
/cinematic

become useful.

6. Repurposing Is a Force Multiplier

One research project can become multiple pieces of content.

For example:

                    Research
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       Article       Video       Thread
          │            │            │
          ▼            ▼            ▼
      Newsletter      Reel       LinkedIn
          │            │            │
          └────────────┼────────────┘
                       ▼
                   Community

This is the purpose of:

/repurpose
/series
/contentcalendar
/postingplan
/newsletter
/linkedin
/twitter
/instagram
/communitypost

The important distinction:

Repurposing isn't copying.

A technical article, LinkedIn post, short video, and newsletter should preserve the idea, not necessarily the exact wording.

7. SEO Is a Discovery Problem

SEO shouldn't mean stuffing keywords into every paragraph.

A better workflow is:

Search Intent
 ↓
Topic
 ↓
Keywords
 ↓
Structure
 ↓
Useful Content
 ↓
Internal Links
 ↓
Search Visibility

Useful lenses include:

/seo
/keywords
/headline
/titles

The objective is not:

“How can I trick the algorithm?”

It is:

“How can I make the content clearly match what someone is actually searching for?”

8. Headlines Are Information Compression

A headline has a difficult job.

It must communicate:

Topic
+
Value
+
Specificity
+
Curiosity

For example:

Generic

AI Coding Agents

Better

How AI Coding Agents Understand Large Codebases

More specific

AI Coding Agents Can Pass Tests and Still Make the Wrong Decision

The third version introduces a contradiction.

That contradiction creates curiosity while still telling the reader what the article is about.

9. Marketing Is Not Just “Selling”

The marketing-related lenses include:

/copywriter
/landingpage
/salespage
/emailmarketing
/coldemail
/sales
/branding
/brandvoice
/positioning
/offer
/usp
/valueprop

These are useful for structuring communication around:

Problem
 ↓
Audience
 ↓
Value
 ↓
Differentiation
 ↓
Evidence
 ↓
Action

For a developer product, for example:

Instead of:

“Our AI tool is powerful.”

A stronger proposition would explain:

Who is it for?
What problem does it solve?
How does it work?
What makes it different?
What evidence supports the claim?
What should the user do next?

10. Evidence Still Matters

This is particularly important when using AI for content.

A content-generation system can make something sound extremely convincing without making it true.

Therefore, a useful workflow is:

IDEA
 ↓
DRAFT
 ↓
CLAIM IDENTIFICATION
 ↓
SOURCE VERIFICATION
 ↓
REVISION
 ↓
PUBLICATION

For technical content, I strongly prefer:

Primary documentation
Academic research
Official engineering blogs
Official datasets
Technical reports
Reproducible experiments

over unsupported claims.

A polished article with incorrect technical information is still a bad article.

11. Ethical Persuasion vs Manipulation

Some of these lenses deliberately explore psychological mechanisms:

/psychology
/dopamine
/emotion
/fear
/shock
/surprise

These should be treated carefully.

There is a difference between:

Creating curiosity

and

Manipulating people with misleading claims.

For example:

❌

“This AI will replace 99% of developers!”

when there is no evidence.

Versus:

✅

“AI coding agents are changing how developers interact with large codebases. Here's what the current evidence actually shows.”

The second may be less sensational, but it builds credibility.

12. Content Should Be Designed for Its Audience

The same idea can require completely different communication.

For example:

Developer

Architecture
API
Repository
Benchmarks
Implementation

Executive

Cost
Risk
Productivity
Security
Business impact

Beginner

Simple explanation
Examples
Analogy
Visuals

That's why lenses such as:

/psychology
/branding
/brandvoice
/positioning
/premium
/minimal
/modern

can be useful.

The underlying information remains the same.

The communication layer changes.

13. A Complete Content System

Putting everything together:

                    ┌──────────────┐
                    │    IDEA      │
                    └──────┬───────┘
                           ↓
                    ┌──────────────┐
                    │   AUDIENCE   │
                    └──────┬───────┘
                           ↓
                    ┌──────────────┐
                    │    ANGLE     │
                    └──────┬───────┘
                           ↓
                    ┌──────────────┐
                    │    HOOK      │
                    └──────┬───────┘
                           ↓
              ┌────────────┴────────────┐
              ↓                         ↓
          STORYTELLING              EVIDENCE
              ↓                         ↓
              └────────────┬────────────┘
                           ↓
                        FORMAT
                           ↓
          ┌────────────────┼────────────────┐
          ↓                ↓                ↓
       ARTICLE           VIDEO            SOCIAL
          ↓                ↓                ↓
          └────────────────┼────────────────┘
                           ↓
                      DISTRIBUTION
                           ↓
                       FEEDBACK
                           ↓
                       ITERATION

This is the bigger idea behind the 100 lenses.

They aren't 100 random commands.

They're different ways of interacting with different stages of the content system.

100 Content Creation, Social Media & Marketing Lenses

#	Shortcut	Purpose
101	`/viral`	Rewrite for maximum virality
102	`/viralreel`	Create a high-retention Instagram Reel
103	`/viralshorts`	Optimize for YouTube Shorts
104	`/viralhook`	Generate a scroll-stopping hook
105	`/hook`	Write opening lines
106	`/hook10`	Generate 10 hook options
107	`/hook50`	Generate 50 hook ideas
108	`/retention`	Improve audience retention
109	`/retentioncurve`	Plan engagement across content
110	`/patterninterrupt`	Add attention-grabbing interruptions
111	`/openloop`	Create curiosity loops
112	`/curiosity`	Increase curiosity
113	`/psychology`	Apply psychological principles
114	`/dopamine`	Make content more rewarding
115	`/emotion`	Increase emotional impact
116	`/fear`	Use fear ethically
117	`/surprise`	Add surprising twists
118	`/shock`	Create a shocking opener
119	`/storytelling`	Narrative storytelling
120	`/herojourney`	Hero's Journey structure
121	`/script`	Generate a script
122	`/script30`	30-second script
123	`/script60`	60-second script
124	`/script90`	90-second script
125	`/script180`	3-minute script
126	`/narration`	Voice-over script
127	`/voiceover`	Natural narration
128	`/monologue`	Single-speaker script
129	`/dialogue`	Conversation format
130	`/podcast`	Podcast episode outline
131	`/youtube`	Long-form YouTube format
132	`/shorts`	YouTube Shorts style
133	`/reels`	Instagram Reels style
134	`/tiktok`	TikTok style
135	`/linkedin`	LinkedIn post
136	`/twitter`	X post/thread
137	`/facebook`	Facebook-friendly post
138	`/instagram`	Instagram caption
139	`/caption`	Generate captions
140	`/caption10`	Generate 10 captions
141	`/hashtags`	Generate relevant hashtags
142	`/cta`	Create a call-to-action
143	`/engagement`	Increase discussion/sharing
144	`/shareworthy`	Make content shareable
145	`/saveworthy`	Make content worth saving
146	`/commentbait`	Encourage discussion
147	`/poll`	Create a poll
148	`/communitypost`	YouTube Community post
149	`/newsletter`	Newsletter content
150	`/blog`	Blog article
151	`/seo`	SEO optimization
152	`/keywords`	Generate keywords
153	`/headline`	Write headlines
154	`/titles`	Generate title options
155	`/thumbnailtext`	Thumbnail text ideas
156	`/thumbnailaudit`	Review thumbnail concept
157	`/titleaudit`	Review title effectiveness
158	`/contentaudit`	Review content quality
159	`/copywriter`	Professional marketing copy
160	`/landingpage`	Landing-page copy
161	`/salespage`	Sales-page copy
162	`/emailmarketing`	Marketing email
163	`/coldemail`	Cold outreach email
164	`/sales`	Sales-oriented messaging
165	`/branding`	Brand positioning
166	`/brandvoice`	Match a brand tone
167	`/positioning`	Market positioning
168	`/offer`	Craft an offer
169	`/usp`	Unique selling proposition
170	`/valueprop`	Value proposition
171	`/campaign`	Marketing campaign
172	`/launch`	Launch strategy
173	`/contentcalendar`	Content calendar
174	`/postingplan`	Posting schedule
175	`/series`	Content-series ideas
176	`/challenge`	Challenge campaign
177	`/trend`	Analyze current trends
178	`/evergreen`	Evergreen content
179	`/repurpose`	Repurpose existing content
180	`/broll`	Suggest B-roll
181	`/shotlist`	Generate shot list
182	`/cameraangles`	Suggest camera angles
183	`/cinematic`	Cinematic treatment
184	`/cinematicsketch`	Cinematic sketch prompt
185	`/storyboardpro`	Detailed storyboard
186	`/sceneplan`	Scene-by-scene planning
187	`/transitions`	Editing transitions
188	`/motiongraphics`	Motion-graphics ideas
189	`/vox`	Documentary-style structure
190	`/johnnyharris`	Visual documentary-inspired structure
191	`/magnatesmedia`	Business-documentary-inspired structure
192	`/kurzgesagt`	Animated-explainer-inspired structure
193	`/netflix`	Documentary tone
194	`/bbc`	Documentary presentation
195	`/natgeo`	Science/documentary presentation
196	`/applekeynote`	Product-presentation structure
197	`/minimal`	Minimalist presentation
198	`/modern`	Modern clean presentation
199	`/premium`	Premium editorial presentation
200	`/aesthetic`	Stylized visual presentation

How I Would Actually Use These

I wouldn't run all 100 commands on every piece of content.

That would create more noise than value.

Instead:

Technical article

/research
/factcheck
/firstprinciples
/storytelling
/seo
/titleaudit
/contentaudit

YouTube video

/hook10
/retentioncurve
/script
/storyboardpro
/broll
/shotlist
/thumbnailaudit

LinkedIn post

/hook
/insights
/storytelling
/engagement
/cta
/linkedin

Product launch

/positioning
/valueprop
/usp
/launch
/campaign
/landingpage
/emailmarketing

The trick is selecting the right lens, not using the maximum number of lenses.

The Real Lesson

AI doesn't eliminate the need for communication strategy.

In many cases, it makes strategy more important.

When generation becomes cheap, the scarce resource becomes:

Good Ideas
+
Good Judgment
+
Good Evidence
+
Good Context
+
Good Communication

AI can help generate ten hooks.

But a human still needs to determine:

Which hook is accurate?

Which hook matches the audience?

Which one supports the actual content?

Which one builds trust rather than cheap attention?

That's where human judgment remains extremely valuable.

Final Framework

I think a useful content workflow is:

                    IDEA
                      ↓
                  AUDIENCE
                      ↓
                    ANGLE
                      ↓
                    HOOK
                      ↓
              ┌───────┴───────┐
              ↓               ↓
          STORYTELLING      EVIDENCE
              ↓               ↓
              └───────┬───────┘
                      ↓
                    FORMAT
                      ↓
                 DISTRIBUTION
                      ↓
                  FEEDBACK
                      ↓
                 ITERATION

The 100 lenses are simply different tools for improving each stage.

The goal isn't to generate more content.

The goal is to communicate better.

And that's probably the more important shift AI is creating in content creation.

Question for the Community

If you could keep only 5 of these 100 lenses, which five would you choose?

For developers, creators, researchers, founders, and marketers, I suspect the answers would be very different.

I'm especially interested in whether people would prioritize:

/research
/storytelling
/hook
/repurpose
/seo
/contentaudit
/factcheck
/strategy

or something completely different.

👇 Which five would you keep?

AI #ContentCreation #ArtificialIntelligence #SocialMedia #Marketing #ContentMarketing #AICreators #CreatorEconomy #SEO #Storytelling #DevCommunity #Productivity #AITools

Beyond Passing Tests: A 100-Lens Framework for Evaluating Context-Aware AI Coding Agents 🤖

Probal Dhali — Mon, 24 Aug 2026 15:42:58 +0000

AI coding agents are getting better at writing code.

But I think we are approaching a more difficult question:

How do we know that an AI agent made the right engineering decision for the current state of a software system?

Passing tests is important.

But passing tests alone does not necessarily tell us whether an agent understood:

the current architecture,
project constraints,
previous engineering decisions,
repository conventions,
dependency relationships,
security requirements,
or why an existing implementation looks the way it does.

This becomes particularly important as AI systems move from generating isolated code snippets toward modifying real repositories.

The Problem: Correct Code Is Not Always Correct Engineering

Consider a simple example.

A project initially has:

Architecture v1

API
 ↓
Service
 ↓
Database

An AI agent is asked to add a feature.

It studies the repository, follows the existing pattern, writes the code, and all tests pass.

Then the architecture changes:

Architecture v2

API
 ↓
Event Bus
 ↓
Service
 ↓
Database

The same task is requested again.

If the agent still generates code based on the old architecture, the implementation may be:

✓ Valid syntax
✓ Compiles
✓ Existing tests pass
✗ Violates current architecture
✗ Ignores current constraints

So we have an important distinction:

Functional Correctness
        ≠
Contextual Correctness
        ≠
System-Level Correctness

This is the problem I want to explore.

This Is Already Becoming a Real Engineering Problem

This isn't simply speculation about future AI systems.

Modern coding agents already depend on repository-level context.

OpenAI's documentation for Codex recommends using persistent repository instructions such as AGENTS.md for naming conventions, business logic, known quirks, dependencies, and other information that may not be inferable directly from code. It also recommends providing file paths, component names, diffs, and documentation when describing tasks.

OpenAI has also described a broader approach where repository knowledge becomes a structured source of truth rather than one giant instruction document, explicitly noting that context management is one of the biggest challenges for agents working on large and complex tasks.

That leads to an interesting conclusion:

If context materially affects agent performance, context should also become part of agent evaluation.

Existing Benchmarks Are Already Moving Toward Real Software

SWE-bench was created to evaluate AI systems on real software-engineering issues from GitHub repositories.

The agent receives a repository and an issue, modifies the code, and is evaluated using tests. SWE-bench Verified was later created as a human-validated subset after OpenAI and the SWE-bench authors found problems with some benchmark tasks. 500 tasks were selected after professional developers screened the data.

But benchmark methodology itself is evolving.

In February 2026, OpenAI reported that SWE-bench Verified had become increasingly contaminated and recommended newer evaluations such as SWE-bench Pro.

In July 2026, OpenAI also reported that its audit of SWE-bench Pro found widespread task-quality problems and estimated roughly 30% of tasks were broken.

That matters because it demonstrates a broader lesson:

Evaluating AI systems is itself an engineering problem.

A benchmark can produce a number without necessarily producing a reliable measurement.

Context Reuse Is Already Being Studied

This is also not an isolated idea.

A 2026 research benchmark called SWE-ContextBench specifically investigates whether coding agents can reuse relevant experience across related software-engineering tasks.

The benchmark augments SWE-bench Lite with related tasks derived from dependency and reference relationships between GitHub issues and pull requests. It evaluates prediction accuracy, time efficiency, and cost efficiency. The authors report that appropriately selected summarized experience can improve resolution accuracy while reducing runtime and token cost, whereas poorly selected experience can provide limited or negative benefits.

That suggests something important:

More context
      ≠
Better result

The real question is:

Relevant context
        +
Correct retrieval
        +
Correct interpretation
        ↓
Better decision

So What Should We Actually Measure?

I propose thinking about agent evaluation as a multi-dimensional problem.

Instead of:

Task
 ↓
Agent
 ↓
Code
 ↓
Tests
 ↓
Pass / Fail

we could evaluate:

                 ┌───────────────┐
                 │     TASK      │
                 └───────┬───────┘
                         │
             ┌───────────┼───────────┐
             ▼           ▼           ▼
         Repository   Constraints   History
             │           │           │
             └───────────┼───────────┘
                         ▼
                  AI CODING AGENT
                         │
                         ▼
                      DECISION
                         │
          ┌──────────────┼──────────────┐
          ▼              ▼              ▼
     Code Quality   Constraints    Context Fit
          │              │              │
          └──────────────┼──────────────┘
                         ▼
                    Final Score

Context-Shift Testing

This is the idea I find particularly interesting.

Keep the:

Model
Task
Repository

as constant as possible.

Then change one meaningful part of the context.

For example:

Scenario A

Database:
PostgreSQL

Architecture:
Repository pattern

Constraint:
All database access must go through repositories.

The agent produces:

Controller
   ↓
Service
   ↓
Repository
   ↓
PostgreSQL

Good.

Scenario B

Change one relevant constraint:

Database:
PostgreSQL

Architecture:
Event-driven

Constraint:
Services must communicate through events.

Now the appropriate implementation should change.

If the agent continues producing the old architecture, we can measure a context adaptation failure.

But There Is a Second Test

We shouldn't reward an agent merely for changing its answer.

Suppose we change something irrelevant:

README formatting

The architecture hasn't changed.

The agent should ideally make the same engineering decision.

So:

Relevant context changes
        ↓
Decision SHOULD change

while:

Irrelevant context changes
        ↓
Decision SHOULD remain stable

This gives us two useful properties.

Context Adaptation

Does the agent react when relevant context changes?

Context Stability

Does the agent remain stable when irrelevant context changes?

A Possible Benchmark

A practical benchmark could use paired or grouped scenarios:

Task T
Context C1
      ↓
   Agent
      ↓
Decision D1

Task T
Context C2
      ↓
   Agent
      ↓
Decision D2

Where:

C1 → C2

contains a controlled change.

Then evaluate:

Was the change relevant?
        ↓
Should the decision change?
        ↓
Did the agent change?
        ↓
Was the new decision correct?

And separately:

Was the context change irrelevant?
        ↓
Should the decision remain stable?
        ↓
Did the agent unnecessarily change?

Possible Metrics

I wouldn't claim these are established industry-standard metrics. They are a proposed framework that would need experimental validation.

1. Functional Correctness

Did the implementation satisfy the task?

2. Constraint Adherence

Did the implementation respect explicit constraints?

3. Context Adaptation Rate

When relevant context changed, how often did the agent make the appropriate change?

4. Context Stability

When irrelevant context changed, how often did the agent preserve the appropriate decision?

5. Repository Consistency

Does the change follow the project's established architecture and conventions?

6. Regression Rate

Did the change break previously working behavior?

7. Context Retrieval Efficiency

How much context did the agent need to retrieve to make the correct decision?

This could eventually produce something like:

Agent Reliability Score
│
├── Functional Correctness
├── Constraint Adherence
├── Context Adaptation
├── Context Stability
├── Repository Consistency
├── Regression Resistance
└── Context Efficiency

Why “More Context” Isn't the Answer

A common reaction might be:

"Just give the model the entire repository."

But that's not necessarily a solution.

OpenAI's own engineering discussion around Codex describes the problem with extremely large instruction documents: context is limited, important information can be crowded out, stale instructions can accumulate, and humans may stop maintaining them. Their approach is instead to use a concise map pointing toward deeper sources of truth.

So the problem isn't simply:

How much context?

It is:

Which context?
When?
From where?
How current?
How reliable?
How relevant?

That is a much more interesting systems problem.

Context Has a Lifecycle

I think repository context should be treated as something that changes over time:

Initial Decision
      ↓
Implementation
      ↓
New Requirement
      ↓
Architecture Change
      ↓
Dependency Change
      ↓
Security Change
      ↓
New Decision

An agent working on a long-lived repository therefore needs something closer to:

Current State
+
Historical Decisions
+
Active Constraints
+
Repository Structure
+
Relevant Documentation

rather than simply:

Prompt + Code

The “Why” Behind Code Matters

Two implementations can be functionally equivalent while only one fits the project.

For example:

# Implementation A
cache_result()

versus:

# Implementation B
await cache_result()

Both might pass a narrow test.

But the correct choice could depend on:

concurrency model,
performance requirements,
architectural conventions,
API contracts,
previous design decisions,
runtime environment.

The code itself doesn't always contain the complete explanation.

Sometimes the most important information is why the code was designed that way.

From Static Benchmarks to Dynamic Benchmarks

Traditional benchmark thinking often looks like:

Fixed Task
   ↓
Fixed Dataset
   ↓
Fixed Evaluation
   ↓
Score

But real repositories look more like:

Task
 ↓
Repository evolves
 ↓
Requirements change
 ↓
Dependencies change
 ↓
Architecture changes
 ↓
Security constraints change
 ↓
Agent receives new task

Therefore, a future benchmark could intentionally introduce controlled environmental changes.

For example:

Version 1
   ↓
Agent decision

Version 2
   ↓
Architecture changed

Version 3
   ↓
Security policy changed

Version 4
   ↓
Dependency changed

Then measure whether the agent adapts correctly.

A 2×2 Evaluation Model

One simple way to visualize the experiment:

	Decision Should Stay Same	Decision Should Change
Agent stays same	✅ Stable	❌ Adaptation failure
Agent changes	❌ Instability	✅ Adaptation success

This is interesting because it separates two failure modes that ordinary pass/fail evaluation can hide.

The Bigger Research Question

The question isn't:

"Can AI write code?"

We're already measuring that.

The more difficult question is:

"Can an AI agent maintain correct engineering judgment as the software environment changes?"

That includes:

Architecture
Requirements
Dependencies
Security
Performance
Business Rules
Repository History
Team Conventions

This is closer to how real software development works.

And This Is Where the 100 Thinking Lenses Come In

When investigating a complex AI engineering problem, I don't think one reasoning style is enough.

Sometimes we need a diagram.

Sometimes a benchmark.

Sometimes a root-cause analysis.

Sometimes a comparison.

Sometimes a threat model.

Sometimes a timeline.

Sometimes a first-principles explanation.

So I compiled a reusable set of 100 visual-thinking, explanation, analysis, and strategy lenses.

These aren't claims about AI capability. They are ways to structure thinking and communicate technical problems.

100 Visual Thinking, Explanation, Analysis & Strategy Lenses

#	Shortcut	Lens
1	`/handwritten`	Notebook-style handwritten notes
2	`/visualize`	Turn ideas into visual explanations
3	`/stickynotes`	One idea per sticky note
4	`/infographic`	Infographic layout
5	`/diagram`	Draw a concept diagram
6	`/flowchart`	Step-by-step flowchart
7	`/mindmap`	Create a mind map
8	`/xray`	Show internal structure
9	`/blueprint`	Technical blueprint
10	`/explodedview`	Break object into components
11	`/thenvsnow`	Compare past vs present
12	`/timeline`	Chronological timeline
13	`/beforeafter`	Transformation comparison
14	`/cutaway`	Cutaway illustration
15	`/anatomy`	Explain all parts
16	`/layers`	Layer-by-layer architecture
17	`/ecosystem`	Show all connected players
18	`/journey`	Show end-to-end journey
19	`/process`	Explain a complete process
20	`/cycle`	Visualize recurring cycles
21	`/roadmap`	Learning or execution roadmap
22	`/dashboard`	Dashboard with KPIs
23	`/comparison`	Side-by-side comparison
24	`/versus`	Head-to-head comparison
25	`/scale`	Compare sizes visually
26	`/evolution`	Show evolution over time
27	`/future`	Imagine future scenarios
28	`/inside`	Reveal inner workings
29	`/microscopic`	Zoom into microscopic detail
30	`/macroscopic`	Zoom out to system level
31	`/crosssection`	Cross-sectional illustration
32	`/map`	Geographic or conceptual map
33	`/heatmap`	Show intensity
34	`/network`	Show relationships
35	`/architecture`	Software/system architecture
36	`/wireframe`	Website/app layout
37	`/mockup`	Realistic product preview
38	`/prototype`	Early product concept
39	`/schematic`	Simple technical schematic
40	`/isometric`	3D isometric illustration
41	`/birdseye`	Top-down view
42	`/360view`	All-angle visualization
43	`/storyboard`	Scene-by-scene explanation
44	`/comic`	Explain through comic panels
45	`/poster`	Poster design
46	`/cover`	Book/report cover
47	`/adcreative`	Advertising concept
48	`/thumbnail`	YouTube thumbnail concept
49	`/carousel`	Instagram/LinkedIn carousel
50	`/socialvisual`	Social media graphic
51	`/quotevisual`	Quote as shareable visual
52	`/eli5`	Explain simply
53	`/expert`	Expert-level explanation
54	`/firstprinciples`	Break down to fundamentals
55	`/deepdive`	Comprehensive explanation
56	`/simplify`	Simplify difficult content
57	`/analogy`	Explain through analogy
58	`/socratic`	Teach through questions
59	`/teachme`	Structured tutoring
60	`/cheatsheet`	Quick-reference notes
61	`/flashcards`	Study flashcards
62	`/quiz`	Generate a quiz
63	`/viva`	Viva preparation
64	`/interview`	Mock interview
65	`/devilsadvocate`	Challenge assumptions
66	`/factcheck`	Verify claims
67	`/mythvsfact`	Separate myths from facts
68	`/proscons`	Advantages vs disadvantages
69	`/swot`	SWOT analysis
70	`/pestle`	PESTLE analysis
71	`/fiveforces`	Porter's Five Forces
72	`/rootcause`	Find root cause
73	`/fivewhys`	Five Whys analysis
74	`/decisionmatrix`	Weighted decision matrix
75	`/scenario`	Scenario planning
76	`/simulate`	Simulation exercise
77	`/roleplay`	Assume an expert role
78	`/consultant`	Consulting-style advice
79	`/executivebrief`	Executive summary
80	`/insights`	Extract insights
81	`/recommendations`	Provide recommendations
82	`/prioritize`	Rank by priority
83	`/benchmark`	Benchmark comparison
84	`/marketmap`	Industry landscape
85	`/strategy`	Strategic planning
86	`/businessmodel`	Business model explanation
87	`/pitch`	Investor/startup pitch
88	`/investor`	Investor perspective
89	`/redteam`	Stress-test a plan
90	`/premortem`	Assume failure and analyze why
91	`/reverseengineer`	Break down success
92	`/promptengineer`	Optimize prompts
93	`/research`	Structured research
94	`/sources`	Find reliable sources
95	`/summarize`	Summarize content
96	`/extract`	Extract key information
97	`/table`	Convert into a table
98	`/presentation`	Presentation outline
99	`/dashboardanalysis`	Analyze dashboards
100	`/actionplan`	Create step-by-step action plan

The Important Distinction

These 100 lenses are not 100 claims that an AI model is more intelligent when using them.

They are simply structured ways of looking at a problem.

For AI-agent research, different lenses can answer different questions:

/architecture
        ↓
What is the system structure?

/xray
        ↓
What is happening internally?

/timeline
        ↓
How did the system change?

/thenvsnow
        ↓
What changed between versions?

/benchmark
        ↓
How should we measure it?

/factcheck
        ↓
Which claims have evidence?

/redteam
        ↓
How can the evaluation fail?

/rootcause
        ↓
Why did the agent fail?

/decisionmatrix
        ↓
Which approach is better?

/actionplan
        ↓
What should we build next?

This is especially useful when researching complex AI systems because no single representation captures the entire problem.

What I Would Test First

If I were turning this idea into an actual research experiment, I'd start small.

Dataset

Create 50–100 repository-level tasks.

Context perturbations

For each task, create controlled variants:

Architecture change
Requirement change
Security constraint change
Dependency change
Performance constraint change
Documentation change
Irrelevant formatting change

Evaluation

Run:

Same Model
Same Task
Different Context

Then measure:

Functional correctness
Context adaptation
Context stability
Constraint adherence
Regression
Token usage
Runtime

Human validation

For ambiguous cases, use experienced developers to verify whether the changed decision was actually appropriate.

This is important because benchmark design itself can introduce errors. OpenAI's SWE-bench work demonstrates why human validation and benchmark auditing matter when interpreting agent performance.

The Hypothesis

My current hypothesis is:

A reliable coding agent should not simply produce correct code. It should produce decisions that are appropriate for the current context, adapt when relevant context changes, and remain stable when irrelevant context changes.

That's a much stronger definition of reliability.

And importantly, it is something we can attempt to measure.

Final Thought

AI coding agents are moving from:

Code Completion

toward:

Software Engineering Agents

As that transition happens, our evaluation methods need to evolve too.

The future benchmark may not simply ask:

“Did the code pass?”

It may need to ask:

“Did the agent understand the current system well enough to make the right engineering decision?”

That is the problem I find most interesting.

And I don't think we have completely solved it yet.

What would you add to a context-aware coding-agent benchmark?

Architecture changes?
Security constraints?
Dependency changes?
Business requirements?
Repository history?

I'd genuinely like to hear how other developers would design it.

References & Further Reading

OpenAI — How OpenAI Uses Codex: repository context, AGENTS.md, task specification, and development-environment guidance.
OpenAI — Harness Engineering: repository knowledge, context management, structured documentation, and agent-first development.
OpenAI — SWE-bench Verified: human validation of software-engineering benchmark tasks and evaluation methodology.
OpenAI — Why SWE-bench Verified No Longer Measures Frontier Coding Capabilities: benchmark contamination and evaluation limitations.
OpenAI — Separating Signal From Noise in Coding Evaluations: 2026 analysis of benchmark quality and broken tasks.
SWE-ContextBench: research on context and experience reuse in coding agents.

AI #AIAgents #SoftwareEngineering #LLM #CodingAgents #MachineLearning #ArtificialIntelligence #DevTools #Benchmarking #AIResearch #OpenSource

AI Coding Agents Can Pass Tests and Still Make the Wrong Decision

Probal Dhali — Thu, 13 Aug 2026 15:53:34 +0000

A question I've been thinking about after discussing AI coding agents with several developers:

Is passing the test suite enough to prove that an AI agent made the correct engineering decision?

I don't think it is.

And this isn't just a theoretical concern.

Modern coding agents are increasingly working at the repository level rather than generating isolated code snippets. OpenAI's Codex documentation, for example, describes using repository-specific AGENTS.md instructions to tell the agent how to navigate a codebase, run tests, and follow project practices. Anthropic similarly describes Claude Code searching codebases, tracing dependencies, editing multiple files, and working with CI failures. (OpenAI)

That changes what "correctness" means.

Consider a simple scenario

A project starts with:

Architecture v1

API
 ↓
Service
 ↓
Database

An AI agent learns this structure and implements a new feature correctly.

The tests pass.

Then the architecture changes:

Architecture v2

API
 ↓
Event Bus
 ↓
Services
 ↓
Database

The same task is requested again.

If the agent continues following the old architecture, its code might still:

compile,
pass existing tests,
satisfy the visible functional requirement,

but still be wrong for the current system.

This is the distinction I'm interested in:

Code correctness ≠ Contextual correctness

The Benchmark Problem

Traditional coding benchmarks generally provide:

Repository
+
Issue
↓
Agent
↓
Patch
↓
Tests / Evaluation

This is valuable.

SWE-bench, for example, was designed around real GitHub issues and repositories, and OpenAI created SWE-bench Verified with human validation because benchmark quality itself affects what we conclude about model capability. (OpenAI)

But there is another dimension worth testing:

What happens when the context changes?

Recent research is already moving in this direction.

SWE-ContextBench evaluates whether coding agents can reuse relevant experience across related tasks, while SWE-Explore focuses specifically on repository exploration and context retrieval rather than treating the entire coding task as a single pass/fail outcome. (arXiv)

So I don't think the idea should be:

"Replace existing coding benchmarks."

Instead:

Add controlled context-shift evaluations to them.

A Practical Experiment

Keep the model and task constant.

Change only the relevant context.

For example:

Test A — Original Context

Architecture:
REST → Service → Database

Constraint:
All database access must go through Repository classes.

Agent produces:

Controller
   ↓
Service
   ↓
Repository
   ↓
Database

✅ Correct.

Test B — Architecture Changed

Only change:

Architecture:
REST → Event Bus → Service → Database

Now the expected implementation should change.

If the agent still produces:

Controller
   ↓
Service
   ↓
Repository

then we have a measurable context-adaptation failure.

But There Is Another Side

We shouldn't reward an agent simply for changing its answer.

Suppose we change something irrelevant:

README formatting

The architecture hasn't changed.

The agent should ideally make the same engineering decision.

So a useful benchmark should test both:

Relevant Context Change
        ↓
Decision SHOULD change

and:

Irrelevant Context Change
        ↓
Decision SHOULD remain stable

This gives us two complementary properties:

Context Adaptation

Can the agent respond appropriately to relevant changes?

Context Stability

Can the agent avoid unnecessary changes when the context is irrelevant?

Possible Evaluation Metrics

We could measure this quantitatively.

For example:

Context Adaptation Rate
=
Correct decisions after relevant context changes
/
Total relevant context changes

And:

Context Stability
=
Unchanged decisions under irrelevant changes
/
Total irrelevant context changes

Then combine these with existing measures:

Agent Evaluation
│
├── Functional Correctness
├── Test Pass Rate
├── Constraint Adherence
├── Context Adaptation
├── Context Stability
└── Repository Understanding

I'm not suggesting this is a finished benchmark methodology.

It's a direction that I think is worth experimentally validating.

Why This Matters

The industry is already moving toward agents that operate over entire codebases.

Anthropic's recent analysis of roughly 400,000 Claude Code sessions describes agents being used for increasingly end-to-end software tasks, while engineers retain an important role in planning and directing the work. (Anthropic)

As agents receive more autonomy, the evaluation question changes.

For a code completion system:

"Is this code correct?"

may be enough.

For an agent modifying a long-lived production system:

"Is this the correct decision given the current state, constraints, architecture, and history of the system?"

becomes much more important.

The Bigger Idea

Maybe the next generation of coding-agent benchmarks shouldn't only measure:

Can the agent solve the task?

They should also measure:

Can the agent recognize when the task's surrounding reality has changed?

That could give us a more realistic picture of agent reliability.

Not just:

Task → Code → Tests

but:

Task
 +
Current Context
 +
Constraints
 +
Repository State
 +
Previous Decisions
        ↓
      Agent
        ↓
     Decision
        ↓
Context-aware Evaluation

And importantly, this can be tested experimentally rather than treated as a vague concept.

What would you include in a context-shift benchmark first: architecture changes, security constraints, dependency changes, business requirements, or repository history?

References

OpenAI — SWE-bench Verified and evaluation methodology (OpenAI)
OpenAI — Codex and repository-specific AGENTS.md context (OpenAI)
Anthropic — Claude Code and repository-level coding workflows (Anthropic)
Anthropic — empirical analysis of Claude Code usage (Anthropic)
SWE-ContextBench — context/experience reuse in coding agents (arXiv)
SWE-Explore — repository exploration and context retrieval evaluation (arXiv)

AI #AIAgents #SoftwareEngineering #LLM #CodingAgents #MachineLearning #ArtificialIntelligence #DevTools #Testing #Research

🚀 I Built My Developer Portfolio With Next.js — Here’s What I Learned

Probal Dhali — Mon, 10 Aug 2026 08:54:10 +0000

A developer portfolio should be more than a page containing your name, skills, and project links.

For me, it became an opportunity to build a complete modern web application and experiment with Next.js, component architecture, Tailwind CSS, Docker, responsive UI, and deployment workflows.

So I built my own developer portfolio from the ground up.

🔗 GitHub: https://github.com/probal2005/Developer-Portfolio

🧑‍💻 Why I Built It

As developers, we often build projects but don't spend enough time thinking about how those projects are presented.

I wanted my portfolio to answer three questions quickly:

Who am I?

What can I build?

How can someone explore my work?

Instead of using a static template and changing the text, I wanted to understand and build the application architecture myself.

🏗️ The Technology Stack

The project is built around a modern web-development stack.

Core

Next.js
React
JavaScript / JSX
Tailwind CSS

Development

ESLint
npm
Component-based architecture

Deployment / Infrastructure

Docker
Separate development and production configuration

The repository also contains configuration and project files for managing the application, styling, linting, and containerized development.

🧩 Project Architecture

The project follows a component-oriented Next.js structure.

A simplified view looks like:

Developer-Portfolio
│
├── app/
│   ├── pages & layouts
│   └── application logic
│
├── public/
│   ├── images
│   └── static assets
│
├── utils/
│   └── reusable utilities
│
├── Dockerfile
├── Dockerfile.dev
├── package.json
├── tailwind.config.js
├── eslint.config.*
└── README.md

The goal is to keep responsibilities separated rather than putting everything into a single page.

⚛️ Why Next.js?

I chose Next.js because it provides a strong foundation for building modern React applications.

It gives me access to concepts such as:

React
   ↓
Next.js
   ↓
Routing
   ↓
Application Structure
   ↓
Optimized Production Build

For a portfolio, this is useful because the website needs to be:

Fast
Responsive
SEO-friendly
Maintainable
Easy to expand
Easy to deploy

And most importantly, the portfolio itself becomes another project I can demonstrate.

🎨 Tailwind CSS

For styling, I used Tailwind CSS.

Instead of maintaining a large collection of custom CSS files, the UI can be composed directly through utility classes.

For example:

<section className="flex min-h-screen items-center justify-center">
  <div className="max-w-4xl px-6">
    <h1 className="text-4xl font-bold">
      Hello, I'm a Developer
    </h1>
  </div>
</section>

This approach makes it easier to iterate quickly on:

Layout
Spacing
Typography
Responsive behavior
Components
Visual hierarchy

🐳 Why Docker?

One of the parts I wanted to explore beyond the UI was containerization.

The repository includes Docker configuration for development and production.

Conceptually:

                 Docker
                   │
        ┌──────────┴──────────┐
        │                     │
        ▼                     ▼
 Development              Production
        │                     │
        ▼                     ▼
   Dev Container        Production Build
        │                     │
        └──────────┬──────────┘
                   ▼
              Application

This gives me a more reproducible environment and makes the project easier to move between machines or deployment environments.

📱 Responsive Design

A developer portfolio can't be designed only for a laptop.

It needs to work across:

Desktop
   ↓
Laptop
   ↓
Tablet
   ↓
Mobile

So responsive layout is an important part of the implementation.

The goal is simple:

The content should remain readable and usable regardless of screen size.

🧠 What I Learned

Building this portfolio taught me that a portfolio project can actually be a useful engineering exercise.

Some of the things I learned or improved include:

1. Component thinking

Instead of treating the website as one large page:

Portfolio

I started thinking in reusable pieces:

Portfolio
├── Navigation
├── Hero
├── About
├── Skills
├── Projects
├── Experience
├── Contact
└── Footer

That makes future changes easier.

2. Separating content from structure

A portfolio contains a lot of changing information:

Projects
Skills
Education
Experience
Links
Contact information

Keeping the application organized makes updating that information much easier than repeatedly rewriting large UI sections.

3. Development and production are different problems

Running an application locally is not the same as deploying it.

That's one reason I explored Docker configurations for different environments.

The workflow becomes:

Development
    ↓
Testing
    ↓
Production Build
    ↓
Container
    ↓
Deployment

This is a much more realistic way to think about modern web applications.

🔍 Repository as the Technical Evidence

Rather than making claims about the project without proof, you can inspect the implementation directly.

The repository contains:

app/
public/
utils/
Dockerfile
Dockerfile.dev
package.json
Tailwind configuration
ESLint configuration

You can explore the code, configuration, and project history here:

🔗 GitHub: https://github.com/probal2005/Developer-Portfolio

🚧 What I Want to Improve

The current version is not the final version.

There are several things I want to continue improving:

→ Better performance
→ Improved accessibility
→ More advanced animations
→ Better SEO
→ More reusable components
→ Improved project filtering
→ Better mobile experience
→ Automated deployment
→ Analytics
→ More polished case studies

I also want the portfolio to become more than a collection of links.

Each major project should eventually have its own technical case study explaining:

Problem
   ↓
Architecture
   ↓
Implementation
   ↓
Challenges
   ↓
Solution
   ↓
Result

📈 The Bigger Idea

One thing I've realized while building projects is:

Your portfolio is itself a software project.

It should demonstrate how you think about:

Architecture
UI/UX
Code organization
Performance
Deployment
Maintainability
Developer experience

That's the direction I'm trying to take with this project.

🤝 Feedback Wanted

I'd genuinely like feedback from other developers.

If you visit the repository, what would you improve?

Especially interested in:

UI/UX improvements?

Architecture improvements?

Next.js best practices I'm missing?

Performance optimizations?

Docker/deployment suggestions?

Accessibility improvements?

What would make this portfolio more impressive to a recruiter or engineering team?

Don't hesitate to point out things that are wrong.

Constructive criticism is one of the fastest ways to improve a project.

🔗 Check It Out

💻 GitHub Repository

https://github.com/probal2005/Developer-Portfolio

If you find something interesting, feel free to:

⭐ Star it
🐛 Open an issue
💡 Suggest an improvement
🔧 Fork it
🤝 Contribute

I'm continuing to improve it as I learn.

Final Thought

I didn't build this portfolio only to say:

"Here is my website."

I built it so that the website itself could demonstrate how I approach software development.

From:

React → Next.js → Components → Tailwind → Docker → Deployment

there is always something new to learn.

And this project is still evolving.

What would you improve if you were reviewing this portfolio as a senior developer? 👇

webdevelopment #nextjs #react #javascript #tailwindcss #docker #opensource #frontend #softwareengineering #developer

What I Learned After Building a Programming Language From Scratch in Python

Probal Dhali — Sun, 09 Aug 2026 02:18:34 +0000

I didn't just write a programming language. I built the pipeline that makes the language work.

🔗 NexPro on GitHub: https://github.com/probal2005/NexPro

There are thousands of programming languages in existence.

So building another one sounds unnecessary.

But my goal with NexPro was never to compete with Python, JavaScript, Rust, or C++.

I wanted to answer a much simpler question:

What actually happens between writing code and getting an output?

So instead of only learning the theory of lexers, parsers, ASTs, interpreters, and runtimes, I decided to implement them.

This post documents what I have actually built, what works today, what I learned, and what still needs to be done.

1. The Experiment

NexPro is an experimental programming language implemented in Python.

Its source files use the:

.pa

extension.

A simple NexPro program looks like this:

name = "Probal"
city = "Kolkata"

say name
say city

The important part isn't that this syntax is simple.

The important part is what happens internally.

The source doesn't go directly from:

.pa file

to:

output

Instead, it passes through multiple stages.

2. The Actual Language Pipeline

The core idea behind NexPro is:

┌───────────────────┐
│   NexPro Source   │
│      .pa          │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│       Lexer       │
│  Source → Tokens  │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│      Parser       │
│ Tokens → AST      │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│        AST        │
│ Program Structure │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│    Interpreter    │
│   Execute Nodes   │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│      Runtime      │
│ Values & State    │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│      Output       │
└───────────────────┘

This pipeline isn't just a diagram for documentation.

These are the actual conceptual components implemented in the repository.

3. Evidence #1 — The Repository Has a Language Implementation Structure

The project is organized around the language itself:

NexPro/
│
├── nexpro/
│   ├── cli.py
│   ├── lexer.py
│   ├── parser.py
│   ├── interpreter.py
│   ├── runtime.py
│   ├── tokens.py
│   ├── ast.py
│   ├── errors.py
│   └── __version__.py
│
├── examples/
│   ├── hello.pa
│   └── variables.pa
│
├── tests/
│
├── README.md
├── LICENSE
└── pyproject.toml

Each part exists for a reason.

Component	Responsibility
`lexer.py`	Converts source text into tokens
`tokens.py`	Defines token types
`parser.py`	Builds program structure
`ast.py`	Represents syntax as nodes
`interpreter.py`	Executes the AST
`runtime.py`	Handles runtime behavior/state
`errors.py`	Language-level error handling
`cli.py`	Provides the command-line interface
`tests/`	Tests language behavior

This separation is important because language implementations become difficult to maintain when lexing, parsing, execution, and runtime logic are mixed together.

4. Evidence #2 — NexPro Actually Executes `.pa` Programs

A language project shouldn't stop at syntax diagrams.

It needs to execute programs.

NexPro provides a CLI command:

nexpro run examples/hello.pa

For a program such as:

say "Hello NexPro!"

the interpreter produces:

Hello NexPro!

Variables can also be used:

name = "Probal"
city = "Kolkata"

say name
say city

which produces:

Probal
Kolkata

That gives us a complete path:

hello.pa
   ↓
CLI
   ↓
Lexer
   ↓
Parser
   ↓
AST
   ↓
Interpreter
   ↓
Output

5. Evidence #3 — Tokens Exist Before Execution

Consider:

name = 10

A programming language implementation doesn't need to treat this as one giant string.

The lexer can break it into meaningful pieces:

IDENTIFIER(name)
ASSIGN(=)
NUMBER(10)

That transformation is fundamental.

The lexer answers:

"What are the pieces?"

The parser answers:

"How are those pieces related?"

The interpreter answers:

"What should those relationships do?"

This separation is one of the biggest things I understood while building NexPro.

6. Evidence #4 — The AST Changes Everything

Consider:

a = 10 + 20

The parser doesn't simply need to remember:

"10 + 20"

It can represent the expression structurally:

        Assignment
        /        \
       a        Binary(+)
                /      \
              10        20

This is the Abstract Syntax Tree.

The AST gives the interpreter a structured representation of what the programmer wrote.

Instead of asking:

"What characters are in this string?"

the interpreter can ask:

"What kind of node am I executing?"

That distinction is fundamental to language implementation.

7. Evidence #5 — Arithmetic Becomes a Tree

For:

a = 10
b = 20

say a + b

the important expression is:

a + b

Conceptually:

       +
      / \
     a   b

The interpreter can then resolve:

a → 10
b → 20

and evaluate:

10 + 20

giving:

This is where a simple syntax feature starts demonstrating the full language pipeline.

8. What Building the Lexer Taught Me

At first, tokenization looks easy.

You see:

a = 10

and think:

Split the string.

But real language syntax quickly introduces problems.

What happens with:

a = 10 + 20

What about:

name = "Probal"

What about:

say "Hello World"

Now the lexer needs to distinguish:

IDENTIFIER
NUMBER
STRING
ASSIGN
PLUS
SAY

It also needs to deal with things such as:

Whitespace
Unknown characters
Strings
Numbers
Identifiers
Operators
End of file

That was one of my first major lessons:

A programming language begins before parsing.

9. What Building the Parser Taught Me

The parser is where syntax becomes structure.

For example:

a = 10 + 20

is not equivalent to:

a + 10 = 20

The parser needs to understand relationships and precedence.

Even simple arithmetic starts raising questions:

10 + 20 * 5

Should it mean:

(10 + 20) * 5

or:

10 + (20 * 5)

Language design quickly turns into a combination of:

Syntax
+
Grammar
+
Precedence
+
AST design

That's something I didn't fully appreciate before implementing it.

10. What Building the Interpreter Taught Me

The interpreter is where the language becomes executable.

It has to understand things such as:

Number
String
Variable
Assignment
Binary Expression
Say

For example:

x = 100
say x

requires the runtime to maintain state:

Environment

x → 100

Then:

say x

requires the interpreter to retrieve:

x → 100

and send the value to the output.

This is where concepts like scope, environments, values, evaluation, and runtime state become practical instead of theoretical.

11. Why I Chose Python

NexPro is currently implemented in Python.

That was intentional.

For an experimental interpreter, Python gives me:

Fast iteration
Easy testing
Simple data structures
Classes for AST nodes
Dictionaries for environments
Straightforward exception handling

I can focus on:

language design
+
lexing
+
parsing
+
AST
+
interpretation

without initially having to solve low-level implementation problems.

That doesn't mean Python is necessarily the final implementation language.

It means Python is a practical place to start.

12. Testing Is Not Optional

A language implementation can break very easily.

For example:

Lexer change
     ↓
Token change
     ↓
Parser breaks
     ↓
AST changes
     ↓
Interpreter breaks

That's why NexPro includes tests.

The project has a dedicated:

tests/

directory for language behavior.

As NexPro grows, I want the test suite to cover:

Lexer
  ↓
Parser
  ↓
AST
  ↓
Interpreter
  ↓
Runtime
  ↓
CLI

The goal is to make every new language feature measurable and reproducible.

13. What NexPro Can Do Today

The current implementation is intentionally small.

The project has already moved beyond a source-code mockup into an executable interpreter with components for:

✓ CLI execution
✓ Lexical analysis
✓ Tokens
✓ Parsing
✓ AST representation
✓ Variables
✓ Assignment
✓ Strings
✓ Numbers
✓ Basic expressions
✓ Interpretation
✓ Runtime structure
✓ Error handling structure
✓ Tests

The exact supported syntax will continue changing as the language develops.

That distinction matters.

I'm documenting what exists rather than presenting planned features as completed features.

14. What NexPro Cannot Do Yet

This is equally important.

NexPro is not yet:

❌ A production compiler
❌ A Python replacement
❌ A high-performance language
❌ A mature standard library
❌ A complete ecosystem
❌ A stable 1.0 language

There are still major areas to develop:

Functions
Loops
Conditionals
Collections
Modules
Type system
Standard library
REPL
Tooling
Debugger
Package management
Performance

And that's exactly why I consider it an interesting engineering project.

15. Roadmap

My roadmap is currently divided into three stages.

Stage 1 — Language Core

✓ Lexer
✓ Tokens
✓ Parser
✓ AST
✓ Interpreter
✓ Variables
✓ Basic expressions
✓ CLI

→ Conditionals
→ Loops
→ Functions
→ Collections

Stage 2 — Developer Experience

→ REPL
→ Better diagnostics
→ Formatter
→ Documentation
→ VS Code syntax highlighting
→ Debugging tools
→ Improved testing

Stage 3 — Advanced Runtime

→ Modules
→ Standard library
→ Package system
→ Bytecode
→ Performance improvements
→ Possible compilation

These are goals, not completed features.

16. Why This Project Matters to Me

The biggest result of NexPro isn't the syntax.

It's the understanding.

Before building a language, I knew the words:

Lexer
Parser
AST
Interpreter
Runtime

After implementing them, I started seeing programming languages as pipelines.

When I write:

say 10 + 20

I can now mentally see:

SOURCE
  ↓
TOKENS
  ↓
SYNTAX
  ↓
AST
  ↓
EVALUATION
  ↓
RUNTIME
  ↓
30

That shift in understanding is the real reason I started NexPro.

17. What I Want to Investigate Next

The next interesting question isn't just:

"What syntax should NexPro have?"

It's:

"How far can I take a language that started as a Python interpreter?"

Some questions I want to explore:

Can NexPro have a real type system?

For example:

age: number = 20
name: string = "Probal"

Can it compile to bytecode?

Instead of:

Source → AST → Interpreter

potentially:

Source
  ↓
AST
  ↓
Bytecode
  ↓
Virtual Machine

Can the language have its own package system?

Something like:

import math

Can it eventually have an IDE experience?

For example:

NexPro
 ├── Language Server
 ├── Formatter
 ├── Debugger
 └── VS Code Extension

Those are future experiments.

18. The Repository Is the Evidence

Rather than asking readers to trust a description, I want the repository to be the evidence.

You can inspect:

lexer.py
parser.py
ast.py
interpreter.py
runtime.py
tokens.py
errors.py
cli.py
tests/
examples/

You can run the examples.

You can inspect the implementation.

You can open issues.

You can suggest changes.

You can fork it.

You can try to break it.

That's how I want NexPro to evolve.

19. Open Source Means Feedback

I'm especially interested in feedback from developers who have experience with:

Compilers
Interpreters
Programming Languages
Parser Design
ASTs
Python
Developer Tooling
Language Design

Some questions I'd genuinely like feedback on:

Is the current architecture reasonable for an interpreter?

Which language feature should be implemented next?

Should NexPro remain dynamically typed or eventually introduce static typing?

Should the next major milestone be a REPL, functions, or a bytecode VM?

What architectural mistakes should I fix before the project becomes larger?

20. Final Result

NexPro started with a simple experiment:

Can I build a programming language?

The answer isn't:

"I built the next Python."

That's not what this project is.

The more accurate answer is:

I built a small, executable programming language implementation, and I'm using it to explore how languages are designed and executed.

And that's already taught me more about programming-language internals than simply reading about them.

The journey currently looks like:

          NEXPRO

       Source Code
            │
            ▼
          Lexer
            │
            ▼
          Tokens
            │
            ▼
          Parser
            │
            ▼
           AST
            │
            ▼
       Interpreter
            │
            ▼
         Runtime
            │
            ▼
          Output

The interesting part is that this is only the beginning.

🚀 Try NexPro

If you want to inspect the implementation, experiment with the syntax, or contribute:

🔗 GitHub: https://github.com/probal2005/NexPro

If you find something wrong, open an issue.

If you have an idea, tell me.

If you want to experiment, fork it.

And if you know programming-language implementation better than I do, please tell me what I'm doing wrong.

That's exactly the kind of feedback I want.

NexPro is small today.

But every programming language starts somewhere.

And this is mine.

What would you build next?

Functions, a REPL, a type system, or a bytecode VM?

programming #python #programminglanguages #compiler #interpreter #opensource #softwareengineering #parsing #ast #developer

I Built My Own Programming Language From Scratch — Meet NexPro 🚀

Probal Dhali — Sun, 09 Aug 2026 02:09:22 +0000

What happens when you stop using programming languages and decide to build one?

That was the question that led me to start NexPro — an experimental programming language that I'm building from scratch to understand how programming languages actually work internally.

🔗 GitHub: https://github.com/probal2005/NexPro

NexPro is still in its early stages, but it already has the foundations of a real language implementation: lexical analysis, parsing, an AST, interpretation, runtime components, a CLI, and tests.

This article explains why I started NexPro, how the architecture works, what the syntax looks like, and where I want to take the project next.

🧠 Why Build Another Programming Language?

There are already hundreds of programming languages.

So why build another one?

For me, the goal wasn't to replace Python, JavaScript, Rust, or any existing language.

The goal was to understand what actually happens between this:

say "Hello NexPro!"

and the computer executing it.

When we write code, we usually think:

Source Code → Output

But internally, there is a lot more happening.

A simplified language implementation looks more like:

Source Code
     │
     ▼
    Lexer
     │
     ▼
   Tokens
     │
     ▼
   Parser
     │
     ▼
    AST
     │
     ▼
 Interpreter
     │
     ▼
   Runtime
     │
     ▼
   Output

I wanted to build every major part myself.

That's how NexPro started.

🚀 What Is NexPro?

NexPro is an experimental programming language designed around simple and readable syntax.

The project currently lives on GitHub:

🔗 https://github.com/probal2005/NexPro

The language uses the .pa extension for source files.

For example:

name = "Probal"
city = "Kolkata"

say name
say city

The idea is intentionally simple:

code → easy to read → easy to understand → easy to execute

NexPro isn't trying to compete with established languages yet.

Right now, it is a learning project, language-design experiment, and open-source project that I want to grow over time.

🏗️ NexPro Architecture

One of the most interesting parts of this project is understanding how the individual components communicate.

The current architecture can be represented like this:

                    ┌─────────────────────┐
                    │    NexPro Source    │
                    │       (.pa)         │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │        Lexer        │
                    │  Source → Tokens    │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │       Parser        │
                    │ Tokens → Structure  │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │         AST         │
                    │ Program Structure   │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │     Interpreter     │
                    │   Execute the AST   │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │       Runtime       │
                    │ Values & Execution  │
                    └──────────┬──────────┘
                               │
                               ▼
                    ┌─────────────────────┐
                    │       Output        │
                    └─────────────────────┘

Each component has a specific responsibility.

🔍 1. The Lexer

The first step is lexical analysis.

The lexer reads the raw source code and converts it into tokens.

For example:

say "Hello NexPro!"

can conceptually become:

SAY
STRING("Hello NexPro!")
EOF

For a variable assignment:

name = "Probal"

the lexer needs to recognize things such as:

IDENTIFIER(name)
ASSIGN(=)
STRING("Probal")

This is the first major transformation:

Characters
    ↓
Tokens

The lexer doesn't need to understand the complete meaning of the program.

Its job is to identify the building blocks.

🌳 2. The Parser

Once the lexer produces tokens, the parser takes over.

The parser answers a different question:

"How are these tokens structured?"

For example:

name = "Probal"

is not just three independent pieces.

It represents an assignment.

Conceptually, the parser can construct something similar to:

Assignment
├── Variable: name
└── Value
    └── String: "Probal"

This structured representation becomes part of the Abstract Syntax Tree, or AST.

🌲 3. The AST

The AST is one of the most important concepts in a programming language.

Instead of executing raw text directly, NexPro represents the program as structured nodes.

For example:

say 10 + 20

could conceptually become:

The advantage is that the interpreter doesn't need to repeatedly analyze the original source text.

It works with a structured representation of the program.

⚙️ 4. The Interpreter

After the AST has been created, the interpreter walks through it and executes the nodes.

For example:

name = "Probal"
say name

The interpreter can conceptually perform:

1. Create variable "name"
2. Store "Probal"
3. Find variable "name"
4. Retrieve its value
5. Send the value to output

So the overall process becomes:

Source
  ↓
Lexer
  ↓
Tokens
  ↓
Parser
  ↓
AST
  ↓
Interpreter
  ↓
Runtime
  ↓
Output

This pipeline is the heart of NexPro.

🧪 A Small NexPro Program

Here's a simple example:

name = "Probal"
city = "Kolkata"

say name
say city

The expected output is:

Probal
Kolkata

The important thing isn't the complexity of this program.

The important thing is everything happening underneath it.

➕ Expressions

NexPro is also moving toward expression evaluation.

For example:

a = 10
b = 20

say a + b

Conceptually, the parser can represent the expression as:

       +
      / \
     a   b

The interpreter then resolves:

a → 10
b → 20

10 + 20 → 30

and produces:

This is where a programming language starts becoming more interesting.

💻 Running NexPro

The project is designed around a CLI.

A NexPro program can be executed with:

nexpro run examples/hello.pa

For example:

say "Hello NexPro!"

produces:

Hello NexPro!

The CLI acts as the interface between the developer and the language implementation.

Instead of manually calling the lexer, parser, and interpreter, the developer simply runs a NexPro program.

📁 Project Structure

The repository is organized around the language implementation itself.

The current project structure includes:

NexPro/
│
├── nexpro/
│   ├── __init__.py
│   ├── cli.py
│   ├── lexer.py
│   ├── parser.py
│   ├── interpreter.py
│   ├── runtime.py
│   ├── tokens.py
│   ├── ast.py
│   ├── errors.py
│   └── __version__.py
│
├── examples/
│   ├── hello.pa
│   └── variables.pa
│
├── tests/
│
├── README.md
├── LICENSE
└── pyproject.toml

The GitHub repository currently exposes the main examples, nexpro, and tests directories alongside the project configuration and documentation.

The implementation itself is written in Python.

That choice was deliberate.

Python lets me focus on language implementation concepts without spending most of my time dealing with low-level memory management.

🧩 Why Python?

A natural question is:

"If you're creating a programming language, why implement it in Python?"

Because the current goal is learning and experimentation.

Python gives me useful building blocks:

Easy string manipulation
Dictionaries for environments
Classes for AST nodes
Exceptions for error handling
Simple testing
Fast iteration

For an early interpreter, this makes development much faster.

Later, I may explore implementing parts of NexPro in another language for performance.

🛡️ Error Handling

A programming language isn't complete if it only handles valid programs.

It also needs to explain invalid programs.

For example:

name =

shouldn't simply crash with an obscure Python traceback.

Eventually, NexPro should provide language-level errors such as:

NexPro Syntax Error

Line 1:
name =

Expected a value after '='.

Good error messages are a major part of good developer experience.

Improving NexPro's error system is therefore an important part of the roadmap.

🧪 Testing the Language

Programming languages are particularly sensitive to regressions.

A small lexer change can break parsing.

A parser change can break the interpreter.

An AST change can affect multiple features.

That's why NexPro includes a test suite.

The goal is to test individual components such as:

Source Code
     │
     ▼
   Lexer
     │
     ├── Token tests
     │
     ▼
   Parser
     │
     ├── AST tests
     │
     ▼
 Interpreter
     │
     └── Execution tests

As the language grows, I want the test suite to grow with it.

🗺️ NexPro Roadmap

NexPro is still early.

There is a lot left to build.

My current roadmap looks roughly like this:

                    NexPro
                       │
        ┌──────────────┼──────────────┐
        │              │              │
        ▼              ▼              ▼
     Language        Tooling        Runtime
        │              │              │
        ├─ if/else     ├─ REPL        ├─ Types
        ├─ loops       ├─ Formatter   ├─ Collections
        ├─ functions   ├─ VS Code     ├─ Modules
        ├─ arrays      └─ Debugger    └─ Standard Library
        └─ objects

Near-term goals

if / else
Loops
Functions
More operators
Arrays / collections
Better error messages
More comprehensive tests
Improved runtime

Medium-term goals

REPL
Modules
Standard library
File operations
Better CLI tooling
Formatter
Documentation
VS Code syntax highlighting

Long-term goals

I'd like to explore:

A more powerful type system
Package management
Faster execution
Bytecode or compilation
Debugging tools
Language server support
Cross-platform distribution
A proper developer ecosystem

Some of these are deliberately ambitious.

The roadmap will evolve as the language evolves.

🔬 What I'm Learning From Building NexPro

Building a programming language has changed how I think about programming.

Before starting NexPro, concepts like:

Lexer
Parser
AST
Interpreter
Runtime

could feel abstract.

Now they feel much more concrete.

When I write:

say "Hello"

I can think about the entire journey:

"say"
   ↓
Token
   ↓
Parser
   ↓
SayNode
   ↓
Interpreter
   ↓
Runtime
   ↓
Hello

That mental model is probably the most valuable thing I've gained from this project.

🚧 NexPro Is Not Finished

I want to be very clear about this.

NexPro is not a production-ready programming language.

It's an evolving project.

There will be:

Bugs
Design changes
Breaking changes
Missing features
Experiments that don't work
Architectural decisions that will probably need to be revisited

And that's okay.

That's part of building a language from scratch.

🤝 I Want Developer Feedback

This project is now at the point where feedback from other developers could be extremely valuable.

If you are interested in:

Programming languages
Compilers
Interpreters
Lexers
Parsers
ASTs
Language design
Python
Developer tooling
Open source

I'd love to hear your thoughts.

Especially:

What would you change about the language design?

Which feature should I build next?

Does the architecture make sense?

What am I overlooking?

Would you be interested in contributing?

⭐ Contribute to NexPro

If you'd like to experiment with it, check out the repository:

🔗 GitHub: https://github.com/probal2005/NexPro

You can:

⭐ Star the project
🐛 Open an issue
💡 Suggest a feature
🔧 Submit a pull request
🧪 Experiment with the language
📖 Improve the documentation

Even a small suggestion can influence the direction of the project.

🚀 Final Thoughts

NexPro started with a simple question:

"Can I build a programming language myself?"

The answer so far is:

Yes — but building one teaches you how much there is to learn.

A programming language isn't just syntax.

It's a pipeline:

                 SOURCE CODE
                      │
                      ▼
                    LEXER
                      │
                      ▼
                   TOKENS
                      │
                      ▼
                   PARSER
                      │
                      ▼
                     AST
                      │
                      ▼
                INTERPRETER
                      │
                      ▼
                   RUNTIME
                      │
                      ▼
                    OUTPUT

And NexPro is my attempt to understand and build that pipeline from the ground up.

It's still early.

But that's what makes it exciting.

If you're interested in programming languages, I'd love for you to take a look at NexPro and tell me what you think.

Repository: https://github.com/probal2005/NexPro

Let's see how far this little language can go. 🚀

programming #opensource #python #programminglanguage #compiler #interpreter #parsing #softwaredevelopment #devtools #beginners