AI Agent কাজ করলে নিজের চিন্তাশক্তি কীভাবে ধরে রাখবেন?

মূল লেখা: Critical thinking when agents do the work — Addy Osmani। এটি বাংলা অনুবাদ ও ব্যাখ্যামূলক অভিযোজন; English keywords, অতিরিক্ত উদাহরণ এবং একটি reusable coding prompt অন্তর্ভুক্ত আছে।

প্রথমেই একটা কথা: এই লেখাটা AI ব্যবহার কমানোর পরামর্শ নয়। বরং AI Agent যত বেশি ব্যবহার করবেন, তত বেশি কীভাবে নিজের চিন্তাশক্তি, সিদ্ধান্ত নেওয়ার ক্ষমতা এবং Engineering Judgment ধরে রাখবেন, সেটা নিয়ে।

আপনি যদি Claude Code, Cursor, Codex কিংবা একাধিক AI Agent দিয়ে প্রতিদিন Development করেন, তাহলে লেখাটা বিশেষভাবে গুরুত্বপূর্ণ।

আমি মূল লেখার ভাব ও ধারাবাহিকতা ধরে বাংলায় ব্যাখ্যা করেছি। পাশাপাশি গুরুত্বপূর্ণ English keywords, বাস্তব Software Engineering examples এবং কিছু অতিরিক্ত ব্যাখ্যা যোগ করেছি।

1. The Hidden Problem: AI Is Making Us Think Less

সমস্যাটা AI খারাপ কাজ করছে, সেটা নয়। সমস্যা হচ্ছে AI ভালো কাজ করছে বলে আমরা চিন্তা করা কমিয়ে দিচ্ছি।

আগে কোনো সমস্যার সমাধান করতে গেলে আমাদের অনেকগুলো ধাপ পার হতে হতো:

Problem বুঝতে হতো।
বিভিন্ন Solution চিন্তা করতে হতো।
Trade-offs বিবেচনা করতে হতো।
Code লিখতে হতো।
Result যাচাই করতে হতো।

এই পুরো প্রক্রিয়ার মধ্যেই আমাদের Critical Thinking তৈরি হতো।

কিন্তু এখন?

আপনি Claude Code-কে বললেন:

“Build a complete authentication system with registration, login, password reset and email verification.”

কয়েক মিনিটের মধ্যে AI পুরো Feature তৈরি করে দিল।

আপনি শুধু Diff দেখলেন, Test Green দেখলেন, তারপর Merge করে দিলেন।

কাজ শেষ!

কিন্তু একটা প্রশ্ন:

আপনি কি সত্যিই বুঝেছেন AI কী তৈরি করেছে?

Addy-এর পর্যবেক্ষণ হচ্ছে, AI যত উন্নত হচ্ছে, তার Output-এ obvious mistakes তত কম দেখা যাচ্ছে।

ফলে আমরা আর আগের মতো দ্বিতীয়বার যাচাই করার প্রয়োজন অনুভব করছি না।

এটাই বিপজ্জনক।

আপনি একই সময়ে পাঁচটি Agent চালাতে পারেন, কিন্তু তাদের কাজ যাচাই করার জন্য আপনার চোখ তো এক জোড়াই।

আপনাকে নিজের দৈনন্দিন কাজের মধ্যে Critical Thinking-এর জায়গা তৈরি করতে হবে। কারণ স্বাভাবিকভাবে কেউ আপনার হয়ে এটা করবে না।

Important Keywords

Critical Thinking — সমালোচনামূলক চিন্তাভাবনা
Agentic Workflow — AI Agent দিয়ে পরিচালিত কাজের প্রক্রিয়া
Cognitive Processing — চিন্তা ও তথ্য বিশ্লেষণের প্রক্রিয়া
Human Oversight — মানুষের তদারকি
Verification — যাচাই করা

2. Cognitive Offloading vs Deferral vs Cognitive Surrender

Most important concept

এই পুরো Article-এর সবচেয়ে গুরুত্বপূর্ণ অংশ সম্ভবত এটি।

Addy মানুষের AI ব্যবহারের অভ্যাসকে তিনটি পর্যায়ে ভাগ করেছেন।

1. Cognitive Offloading

Healthy

Delegate the work, own the result.

কাজ AI-কে দিয়ে করাচ্ছেন, কিন্তু Result-এর দায়িত্ব আপনার।

AI কাজ করছে, আপনি বুঝছেন, যাচাই করছেন এবং সিদ্ধান্ত নিচ্ছেন।

2. Deferral

Warning

Output becomes input.

AI যা বলছে, সেটাকেই পরবর্তী কাজের ভিত্তি বানাচ্ছেন। আর নিজে প্রশ্ন করছেন না।

AI-এর উত্তর আর একটি Hypothesis নয়, বরং আপনার কাছে Fact হয়ে যাচ্ছে।

3. Cognitive Surrender

Danger

AI thinks, you accept.

AI-এর Output-কে নিজের সিদ্ধান্ত হিসেবে গ্রহণ করছেন। যাচাই করার প্রয়োজনও মনে হচ্ছে না।

আপনি নিজেই বুঝতে পারছেন না কী তৈরি হয়েছে, কেন তৈরি হয়েছে।

Cognitive Surrender শব্দটি Wharton-এর Steven Shaw এবং Gideon Nave-এর কাজ থেকে এসেছে।

Let’s understand with a real coding example

ধরুন, আপনার FluentCRM-এর একটি Email Campaign Sending Feature তৈরি করতে হবে।

Scenario A — Cognitive Offloading

আপনি Agent-কে বললেন:

“Implement a batch email sending system. Consider memory usage, server limits, retries and duplicate prevention.”

AI Code তৈরি করল।

আপনি যাচাই করলেন:

Batch processing ঠিক আছে কি না।
Failed emails retry হচ্ছে কি না।
একই Email দুবার পাঠানো হচ্ছে কি না।
Memory usage কেমন।
Existing architecture-এর সঙ্গে মিলছে কি না।

আপনি কাজ Delegate করেছেন, কিন্তু Engineering Decision আপনার।

Scenario B — Deferral

AI বলল, Queue-based processing সবচেয়ে ভালো।

আপনি আর কিছু না ভেবেই Queue-based Architecture তৈরি করতে বললেন।

AI যা বলল, সেটাই পরবর্তী সিদ্ধান্তের ভিত্তি।

Scenario C — Cognitive Surrender

AI পুরো Sending System তৈরি করল।

আপনি শুধু দেখলেন:

Tests passed.
No errors.
Implementation complete.

তারপর Merge করে দিলেন।

কিন্তু কেউ যদি জিজ্ঞেস করে:

“একই Campaign একাধিক Worker process করলে Duplicate Email কীভাবে Prevent হচ্ছে?”

আপনি উত্তর দিতে পারলেন না।

এটাই Cognitive Surrender।

The gradual transition

সবচেয়ে বিপজ্জনক বিষয় হচ্ছে এই পরিবর্তন একদিনে হয় না।

প্রথমে প্রতিটি AI Output ভালোভাবে পড়েন।
পরেরবার একটু কম পড়েন।
তারপর শুধু Summary দেখেন।
এরপর শুধু Test Result দেখেন।
একসময় AI-এর সিদ্ধান্তই আপনার সিদ্ধান্ত হয়ে যায়।

এভাবেই তৈরি হয় Cognitive Debt।

আরেকটি গুরুত্বপূর্ণ ধারণা: Comprehension Debt

আপনার Codebase দেখতে সুন্দর, Tests সব Green, Documentation ভালো।

কিন্তু আপনি বা আপনার Team জানেন না ভিতরে আসলে কী হচ্ছে।

যেদিন Feature Modify করতে যাবেন, সেদিন বুঝবেন সমস্যাটা কত বড়।

এটিই Comprehension Debt — কোড আছে, কিন্তু কোড বোঝার জ্ঞান নেই।

তবে একটা বিষয় মনে রাখতে হবে: Modern Codebase-এর প্রতিটি অংশ সবসময় মাথায় রাখা সম্ভব নয়। দরকার হলে নির্দিষ্ট অংশের Mental Model আবার তৈরি করতে জানতে হবে।

Keywords

English	বাংলা অর্থ
Cognitive Offloading	কাজের চিন্তার চাপ AI-কে দেওয়া
Deferral	AI-এর সিদ্ধান্তের ওপর নির্ভর করা
Cognitive Surrender	নিজের বিচারক্ষমতা AI-এর কাছে সমর্পণ
Cognitive Debt	চিন্তা না করার কারণে জমে থাকা ঘাটতি
Comprehension Debt	Code বুঝতে না পারার ঘাটতি
Mental Model	কোনো System কীভাবে কাজ করে তার মানসিক ধারণা

3. Where Should You Trust AI?

সবকিছু নিজে করতে হবে, এমন কথা Addy বলছেন না।

বরং তাঁর একটি সুন্দর Principle আছে:

Delegate where being wrong is cheap. Keep reasoning where consequences land on others.

অর্থাৎ, ভুল হলে ক্ষতি কম এমন কাজ AI-কে দিয়ে দিন। কিন্তু যেখানে আপনার সিদ্ধান্তের প্রভাব অন্য মানুষের ওপর পড়বে, সেখানে নিজের চিন্তাভাবনা ধরে রাখুন।

উদাহরণ:

Task	AI Delegation
Code formatting	Fully delegate
Writing boilerplate code	Fully delegate
Generating documentation	Mostly delegate
Writing unit tests	Delegate + verify
Database architecture	Human judgment required
Security decisions	Deep human review
Product direction	Human ownership
Production deployment	Human accountability

ধরুন, তিনটি কাছাকাছি মানের Hotel-এর মধ্যে একটি বেছে নিতে হবে।

আপনি AI-কে Reviews বিশ্লেষণ করে একটি বেছে দিতে বললেন।

ভুল হলে ক্ষতি সীমিত। এই সিদ্ধান্ত Delegate করা যুক্তিসঙ্গত।

কিন্তু AI-কে বললেন:

“Should we migrate our entire production database from MySQL to PostgreSQL?”

এটা সম্পূর্ণ আলাদা বিষয়।

এখানে Performance, Migration Cost, Compatibility, Team Expertise এবং Long-term Maintenance বিবেচনা করতে হবে।

AI আপনাকে সিদ্ধান্ত নিতে সাহায্য করবে, কিন্তু সিদ্ধান্তের পেছনের যুক্তি আপনাকে বুঝতে হবে।

4. Seven Questions You Should Ask Yourself

Addy নিজের AI Workflow-এর মধ্যে সাতটি প্রশ্ন ব্যবহার করার পরামর্শ দিয়েছেন।

এগুলো খুবই Practical।

1. Did I form my own hypothesis before asking AI?

AI-কে প্রশ্ন করার আগে আমার নিজের ধারণা কী ছিল?

কোনো Non-trivial Task দেওয়ার আগে নিজের একটা Hypothesis তৈরি করুন।

Example:

আপনার WordPress Plugin-এর একটি API Endpoint Slow।

AI-কে সরাসরি জিজ্ঞেস না করে আগে ভাবুন:

Is it an N+1 query problem?
Is there unnecessary database querying?
Is object caching missing?

তারপর AI-কে তদন্ত করতে দিন।

আপনার ধারণা ভুল হলেও সমস্যা নেই। নতুন Evidence পেলে পরিবর্তন করবেন।

কিন্তু কোনো ধারণা ছাড়াই AI-এর কাছে গেলে, AI-এর সুন্দর উত্তর আপনার চিন্তার জায়গা দখল করে নিতে পারে।

যদি একেবারেই বুঝতে না পারেন কোথা থেকে শুরু করবেন, তাহলে একটি Blind Spot Pass ব্যবহার করতে পারেন।

অর্থাৎ, AI-কে আপনার জানা তথ্য দিন এবং জিজ্ঞেস করুন:

“What am I missing? Identify things I might not know I don’t know.”

2. Am I using AI to think, or to think for me?

আমি কি AI-কে আমার চিন্তাভাবনা উন্নত করতে ব্যবহার করছি, নাকি AI-কে আমার হয়ে চিন্তা করতে দিচ্ছি?

দুটোই করা যায়। কিন্তু কোনটি করছেন সেটা বুঝতে হবে।

Example:

Bad: “Choose the best architecture for my application.”

Better: “Compare these three architectures. Explain the trade-offs, limitations and long-term maintenance costs. Challenge my current preference.”

3. What must be true for this to work?

AI-এর সিদ্ধান্ত সঠিক হতে হলে কোন কোন বিষয় সত্য হতে হবে?

এবং সেগুলো যাচাই করুন।

AI বলল আপনার Query Optimization করলে Performance 5x উন্নত হবে।

তাহলে প্রশ্ন করুন:

কেন 5x হবে?
কোন Query Bottleneck?
Database Index কি যথেষ্ট?
Production Data-তে ফলাফল কেমন?

AI-এর নিজের Confidence-এর চেয়ে বাস্তব Test বেশি গুরুত্বপূর্ণ।

4. Have I heard the strongest opposing argument?

আমি কি বিপরীত মতামতও শুনেছি?

আপনি কোনো একটি Architecture পছন্দ করেছেন।

এবার অন্য AI Model-কে বলুন সেটির বিরুদ্ধে যুক্তি দিতে।

Example:

আপনি Redis ব্যবহার করতে চান।

অন্য Agent-কে বলুন:

“Argue against using Redis for this system. Identify scenarios where MySQL caching or object caching would be a better choice.”

এতে আপনি নিজের সিদ্ধান্তের দুর্বল দিকগুলো জানতে পারবেন।

5. Would I bet on this in front of the person maintaining it?

যে Developer এই Code Maintain করবে, তার সামনে দাঁড়িয়ে কি আমি এই Implementation-এর পক্ষে যুক্তি দিতে পারব?

এটি খুব সুন্দর একটি পরীক্ষা।

আপনি যদি নিজের তৈরি বা AI দিয়ে তৈরি Code-এর পক্ষে যুক্তি দিতে না পারেন, তাহলে সেটি Merge করার আগে আরও বোঝা দরকার।

6. What am I no longer practicing?

AI ব্যবহারের কারণে আমি কোন Skill আর Practice করছি না?

ধরুন, আগে আপনি নিজে SQL Query Optimize করতেন।

এখন সব Query AI Optimize করে দেয়।

কয়েক মাস পর নিজে Query Optimization করতে গিয়ে সমস্যা হচ্ছে।

AI আপনার কাজ সহজ করেছে, কিন্তু আপনার Skill-ও দুর্বল হয়েছে।

7. Are the basic questions still being answered?

আগে আমরা সাধারণ কিছু প্রশ্ন করতাম:

Who?
What?
Where?
Why?
When?
How?

এখন AI-কে বলি, “You decide.”

কিন্তু এই Basic প্রশ্নগুলো এখনো গুরুত্বপূর্ণ।

সঙ্গে আরও চারটি বিষয় মাথায় রাখুন:

Are we solving the right problem?
Is this the right approach?
What evidence supports the result?
How do we know the task is complete?

5. Verification Is More Important Than Ever

Very practical for AI coding

আগে Software Development-এর বড় Bottleneck ছিল Code লেখা।

এখন AI Code লিখতে পারে খুব দ্রুত।

তাই নতুন Bottleneck হচ্ছে:

How do we know the generated code is actually correct?

Addy এখানে একটি গুরুত্বপূর্ণ ধারণা তুলে ধরেছেন:

Boris Cherny-এর ভাষায়, Claude-কে নিজের কাজ Verify করার একটি উপায় দিতে হবে।

অর্থাৎ, AI-কে শুধু Code লেখার দায়িত্ব দেবেন না। নিজের কাজ পরীক্ষা করার ব্যবস্থাও দেবেন।

Example: Building a REST API

ধরুন, Agent একটি REST API তৈরি করছে।

আপনি শুধু বললেন:

“Create a REST API for managing contacts.”

এটা যথেষ্ট নয়।

বরং বলুন:

Implement the endpoints.
Write automated tests.
Test authentication and authorization.
Verify invalid input handling.
Test pagination.
Check database query performance.
Run the tests and report actual results.

এখন Agent নিজের কাজ নিজেই পরীক্ষা করতে পারবে।

But there is a catch: Green Tests Don’t Mean Everything Is Correct

ধরুন:

All tests passed

Green

100%

All available tests passed.

Does this mean the feature is correct?

Not necessarily.

Was the edge case tested?
Was the test itself correct?
Did we test authorization?
Did we test concurrent requests?
Did we verify the actual user experience?

দুটি কারণে Green Test যথেষ্ট নয়:

AI খুব সহজেই অনেক Test তৈরি করতে পারে। কিন্তু Test সঠিক Feature যাচাই করছে কি না, সেটাও দেখতে হবে।
একটি Green Checkmark শুধু একটি নির্দিষ্ট বিষয় প্রমাণ করে। পুরো System সঠিক, সেটা নয়।

তাই Test পাস করার পর দুটি প্রশ্ন করবেন:

What did this test prove?
What did this test NOT prove?

Define Verification Before Implementation

কাজ শুরু করার আগেই ঠিক করুন, কী হলে কাজটি সফল বলা যাবে।

Example:

Feature: Contact Import

Acceptance Criteria:

CSV upload works.
Invalid rows are reported.
Duplicate contacts are handled correctly.
Large files don’t cause memory exhaustion.
Import progress is visible.
Failed imports can be retried safely.

এখন Agent কাজ শেষ করলে এগুলো দিয়ে যাচাই করতে পারবেন।

Completion should be based on evidence, not explanation.

অর্থাৎ, AI বলল কাজ শেষ হয়েছে, সেটি যথেষ্ট নয়। Test Result, Screenshot, Logs অথবা Trace দেখতে হবে।

6. Actually Read What AI Has Generated

এখানে Addy একটি চমৎকার উদাহরণ দিয়েছেন।

ধরুন, AI আপনার জন্য 600 Lines-এর একটি Pull Request তৈরি করেছে।

আপনি দেখলেন:

Code Structure ভালো।
Variable Names ঠিক আছে।
Tests Passed.
কোনো Error নেই।

আপনি PR Approve করে দিলেন।

কিন্তু Code-এর মধ্যে হয়তো কোনো Transaction-এর Execution Order পরিবর্তন হয়েছে, অথবা কোনো Edge Case-এর Default Value ভুল হয়ে গেছে।

আপনি Code Review করেছেন ঠিকই, কিন্তু শুধু সেই জিনিসগুলো দেখেছেন যেগুলো দেখবেন বলে আগে থেকেই ভেবেছিলেন।

এটাই সমস্যা।

How should you review AI-generated code?

1. Read the Diff as if a human wrote it.

AI লিখেছে বলে আলাদা ছাড় দেবেন না।

2. Ask AI to list its decisions.

কোড তৈরি করার সময় AI অনেক ছোট ছোট সিদ্ধান্ত নেয়।

যেমন:

Default values কী রেখেছে?
কোন Requirement Out of Scope ধরেছে?
Conflicting Requirements কীভাবে Resolve করেছে?
কোথায় Existing Architecture পরিবর্তন করেছে?

এসব সিদ্ধান্তের তালিকা চাইবেন।

3. Test yourself.

Diff থেকে যেকোনো কয়েকটি Line নির্বাচন করে নিজেকে জিজ্ঞেস করুন:

এই Code কেন আছে?
এই Condition কেন ব্যবহার হয়েছে?
এটি Remove করলে কী হবে?
এই Implementation-এর Alternative কী?

4. Close the documentation and explain it from memory.

Documentation পড়ার পর সেটি বন্ধ করুন।

তারপর নিজের ভাষায় ব্যাখ্যা করার চেষ্টা করুন।

যদি না পারেন, তাহলে আরও বুঝতে হবে।

A useful technique

AI-কে বলুন:

“Generate a change report explaining every important architectural decision, assumption, trade-off and potential risk. Then create five questions to test my understanding of the implementation.”

তারপর Merge করার আগে প্রশ্নগুলোর উত্তর দিন।

7. Orchestration Tax: More Agents Don’t Always Mean More Productivity

এটি আমার কাছে Article-এর অন্যতম গুরুত্বপূর্ণ Engineering Management Insight।

ধরুন:

আপনি 5টি AI Agent চালাচ্ছেন।

প্রতিটি Agent ঘণ্টায় 500 Lines Code তৈরি করছে।

সব মিলিয়ে 2,500 Lines Code তৈরি হলো।

কিন্তু আপনি ভালোভাবে Review করতে পারলেন মাত্র 300 Lines।

তাহলে বাকি Code-এর দায়িত্ব কে নেবে?

এখানে Addy একটি ধারণা ব্যবহার করেছেন:

Orchestration Tax

অর্থাৎ, AI Agent যত কাজ তৈরি করছে, আপনি যতটুকু কাজ বুঝতে ও নিজের নামে দায়িত্ব নিতে পারছেন, তার মধ্যে পার্থক্য।

Example: Agent Output vs Human Review

Generated code

2,500 lines

Reviewed code

300 lines

Only 12% reviewed

Illustrative example, not measured data.

এখন আরও একটি Agent চালালে Productivity বাড়বে না। বরং Review করার চাপ আরও বাড়বে।

Addy-এর বক্তব্যের সারকথা:

যখন আপনি নিজের দায়িত্ব নিয়ে দাঁড়াতে পারবেন, তার চেয়ে বেশি কাজ তৈরি করছেন, তখন আপনি আর Review করছেন না। আপনি শুধু আশা করছেন সব ঠিক আছে।

Keywords

Orchestration — একাধিক Agent পরিচালনা
Orchestration Tax — Agent Output ও Human Review Capacity-এর ব্যবধান
Code Review — কোড যাচাই
Accountability — কাজের জন্য জবাবদিহি
Review Bottleneck — Review-এর সীমাবদ্ধতা

8. Intent Debt: The Problem Starts Before AI Writes Code

এটি খুবই গুরুত্বপূর্ণ একটি ধারণা।

Addy বলেছেন:

Intent Debt

আগে Software Development-এ আপনি Requirement নিয়ে কাজ করার সময় Team-এর অন্য কেউ প্রশ্ন করত।

যেমন:

“এই Feature কেন দরকার?”

“এই User Flow কি সত্যিই প্রয়োজন?”

“এই Requirement-এর Scope কী?”

এই প্রশ্নগুলো আপনার চিন্তাভাবনাকে পরিষ্কার করত।

কিন্তু AI Agent সাধারণত আপনাকে থামিয়ে প্রশ্ন না করে, নিজের মতো করে অস্পষ্ট Requirement পূরণ করে ফেলে।

আপনি লিখলেন:

“Build a modern CRM dashboard.”

AI সুন্দর একটি Dashboard বানিয়ে দিল।

কিন্তু আপনার মাথায় হয়তো ছিল:

Sales Performance.
Email Campaign Analytics.
Contact Growth.
Automation Statistics.

AI হয়তো অন্য কিছু বানিয়েছে।

কিন্তু দেখতে সুন্দর হওয়ায় আপনি সেটি Accept করে ফেললেন।

এখানে সমস্যা হচ্ছে আপনার Intent পরিষ্কার ছিল না।

Intent Debt হলো এমন কিছু Hidden Requirements, Constraints এবং Goals, যেগুলো AI-এর তৈরি Output-এর মধ্যে আছে, কিন্তু আপনি নিজেই সেগুলো পরিষ্কারভাবে Define করেননি।

How to avoid Intent Debt?

AI-কে Task দেওয়ার আগে নিজের ভাষায় একটি Brief লিখুন।

Example:

Feature Brief: CRM Dashboard

Audience: CRM Administrators

Goal: Help users understand campaign performance quickly.

In Scope:

Campaign performance metrics.
Contact growth.
Email delivery statistics.

Out of Scope:

Advanced revenue attribution.
Custom report builder.

Definition of Done:

All metrics use real database data.
Filters work correctly.
Dashboard loads within acceptable time.
Responsive layout.

এরপর AI-কে কাজ দিন।

এমনকি AI-কে উল্টো আপনাকে Interview করতে বলতে পারেন।

Prompt:

“Before implementation, interview me about this feature. Ask questions about requirements, constraints, edge cases and acceptance criteria. Do not start coding until the requirements are clear.”

এটি খুব ভালো একটি Workflow।

Delegation vs Collaboration

আরেকটি সুন্দর পার্থক্য:

Delegation — আপনি AI-কে কাজ দিয়ে দিলেন।
Collaboration — আপনি ও AI একে অপরের চিন্তাভাবনা উন্নত করছেন।

Collaboration-এর ক্ষেত্রে:

আপনার Prompt উন্নত হয় → AI-এর Output উন্নত হয় → আপনি নতুন কিছু শেখেন → আপনার পরবর্তী Prompt আরও ভালো হয়।

এভাবেই একটি Positive Feedback Loop তৈরি হয়।

9. What If AI Becomes Smarter Than Us?

এটি খুব স্বাভাবিক একটি প্রশ্ন।

আগামী এক-দুই বছরে AI হয়তো এমন সব Code Review করতে পারবে, যা এখন একজন Senior Engineer-ও করতে পারেন না।

তাহলে আমরা কেন নিজেদের Skill ধরে রাখব?

Addy-এর উত্তরে দুটি গুরুত্বপূর্ণ বিষয় আছে।

First: Accountability Cannot Be Delegated

AI যতই উন্নত হোক, Production-এ কী Ship করবেন, তার জন্য শেষ পর্যন্ত মানুষকেই দায়িত্ব নিতে হবে।

আপনি AI-কে কাজ দিতে পারেন।

AI-কে Review-ও করতে দিতে পারেন।

কিন্তু Final Accountability আপনার কাছেই থাকবে।

Second: Engineering Judgment Is More Than Writing Code

কিছু প্রশ্নের উত্তর শুধু ভালো Code লিখে পাওয়া যায় না।

What should we build?
Why should we build it?
Who will be affected?
What trade-offs are acceptable?
What should we prioritize?

এগুলো Product এবং Engineering Judgment-এর বিষয়।

AI আপনাকে সাহায্য করতে পারে। কিন্তু এগুলোর গুরুত্ব আপনার হয়ে নির্ধারণ করতে পারে না।

The Supervision Paradox

Addy এখানে একটি গুরুত্বপূর্ণ ধারণা উল্লেখ করেছেন:

Supervision Paradox

AI-কে ভালোভাবে Supervise করতে যে Engineering Skills দরকার, অতিরিক্ত AI ব্যবহারের কারণে সেই Skills-ই দুর্বল হয়ে যেতে পারে।

অর্থাৎ, AI-কে সঠিকভাবে পরিচালনা করার দক্ষতা ধরে রাখতে হলেও আপনাকে নিজের Engineering Skills Practice করতে হবে।

10. Practical Habits to Maintain Your Engineering Skills

Addy কিছু দৈনন্দিন অভ্যাসের পরামর্শ দিয়েছেন।

Frequency	What to do
Every week	অন্তত একটি ছোট Coding Task AI ছাড়া করুন
Every month	কোন Skills আর Practice করছেন না, তা Review করুন
Every task	AI-কে দেওয়ার আগে নিজের Hypothesis তৈরি করুন
Every PR	AI কী কী সিদ্ধান্ত নিয়েছে তা Review করুন
Every release	Test, Logs এবং বাস্তব Evidence যাচাই করুন
Regularly	নিজের Skill-এর বাইরের বিষয়গুলো শেখার চেষ্টা করুন

আরেকটি সুন্দর প্রশ্ন:

If AI didn’t exist, how lost would you be?

অর্থাৎ, AI না থাকলে আপনি আপনার বর্তমান কাজ কতটুকু করতে পারতেন?

এই প্রশ্নের উত্তর আপনাকে নিজের Skill Gap বুঝতে সাহায্য করবে।

Review-কে আলাদা কাজ হিসেবে ধরতে হবে। এটি বিনামূল্যের কাজ নয়।

আপনি যদি Team-এর জন্য ১০টি Agent চালান, কিন্তু তাদের Output Review করার জন্য কারও সময় বরাদ্দ না করেন, তাহলে বাস্তবে Review-এর কাজ কেউই করছে না।

11. Final Takeaways

পুরো Article-এর মূল কথাগুলো একসঙ্গে:

Delegate work, not responsibility. কাজ AI-কে দিন, কিন্তু দায়িত্ব নিজের কাছে রাখুন।
Form your own hypothesis. AI-কে প্রশ্ন করার আগে নিজে চিন্তা করুন।
A green checkmark proves only one thing. Test Pass মানেই পুরো System সঠিক নয়।
Read the actual output. শুধু Summary পড়ে সিদ্ধান্ত নেবেন না।
Understand AI’s decisions. AI আপনার হয়ে কী কী সিদ্ধান্ত নিয়েছে, জানুন।
Write better prompts. Requirement পরিষ্কার না হলে Output-ও সঠিক হবে না।
Maintain your skills. যে Skill হারাতে চান না, সেটি Practice করুন।
Don’t produce more than you can review. নিজের Review Capacity-এর বাইরে Output তৈরি করবেন না।
Accountability is yours. শেষ পর্যন্ত কাজের দায়িত্ব আপনার।

12. Let’s Apply This to Real AI Development Workflows

এবার Article-এর বাইরেও কয়েকটি Practical Example দিচ্ছি।

ধরুন, আপনি Claude Code বা Cursor দিয়ে একটি বড় WordPress Plugin Feature তৈরি করছেন।

এই Workflow ব্যবহার করতে পারেন:

AI-assisted development workflow

Understand the problem

নিজের ভাষায় Problem এবং Expected Behavior লিখুন।
Ask AI to investigate

Existing Codebase, Architecture এবং Dependencies বিশ্লেষণ করতে দিন।
Challenge the solution

Alternative Approaches এবং Trade-offs জানতে চান।
Define acceptance criteria

Tests এবং Definition of Done আগে নির্ধারণ করুন।
Implement

Agent-কে Code লিখতে দিন।
Verify independently

Tests, Logs, Edge Cases এবং Performance যাচাই করুন।
Review decisions

Agent-এর Assumptions ও Architectural Decisions পরীক্ষা করুন।
Explain it yourself

নিজের ভাষায় Feature-এর কাজ ব্যাখ্যা করতে পারলে Merge করুন।

A reusable prompt for your AI coding agent

এটি Claude Code, Cursor বা অন্য Coding Agent-এ ব্যবহার করতে পারেন।

Before implementing this task, follow these engineering principles:

Understand the existing codebase and its architecture before making changes.
Identify assumptions, missing requirements, and potential edge cases.
Propose an implementation plan and explain important trade-offs.
Ask me questions if requirements are ambiguous.
Do not make unnecessary architectural decisions without explaining them.
Implement the feature following existing project conventions.
Write and execute meaningful tests.
Verify the implementation against the acceptance criteria.
Report what you tested, what you did not test, and any remaining risks.
List all important decisions and assumptions you made during implementation.

After implementation, generate a short review report containing:

What changed and why.
Important architectural decisions.
Potential bugs and edge cases.
Security and performance considerations.
What remains unverified.
Five questions to test my understanding of the implementation.

Do not treat successful execution or passing tests as proof that the entire implementation is correct.

My Final Thoughts

এই Article-এর সবচেয়ে গুরুত্বপূর্ণ শিক্ষা আমার কাছে একটি বাক্যে:

AI should amplify your engineering ability, not replace your engineering judgment.

AI আপনার কাজের গতি বাড়াবে, আপনার চিন্তাভাবনার বিকল্প হয়ে উঠবে না।

আমরা এখন এমন একটি সময়ে আছি, যেখানে একজন Developer একা অনেক বড় Team-এর মতো কাজ করতে পারছেন।

কিন্তু বেশি Code তৈরি করতে পারা আর ভালো Software Engineer হওয়া এক জিনিস নয়।

একজন ভালো Engineer শুধু জানেন না কীভাবে Code লিখতে হয়। তিনি জানেন:

কী তৈরি করা উচিত।
কেন তৈরি করা উচিত।
কীভাবে যাচাই করতে হয়।
কোথায় সমস্যা হতে পারে।
কোন সিদ্ধান্তের দায়িত্ব নিতে হবে।

AI যুগে এই দক্ষতাগুলো আরও গুরুত্বপূর্ণ হয়ে উঠবে।

শেষে নিজের জন্য আজ থেকেই দুটি ছোট অভ্যাস শুরু করতে পারেন:

AI-কে কোনো বড় Task দেওয়ার আগে লিখুন, আপনার নিজের Hypothesis কী।
AI কাজ শেষ করার পর লিখুন, সে কোন একটি গুরুত্বপূর্ণ বিষয় Verify করেনি।

এতটুকু করলেও আপনার AI Workflow-তে অনেক বড় পরিবর্তন আসতে পারে।

Quick English–Bangla Keyword Reference

English keyword	বাংলা অর্থ
Agentic Workflow	AI Agent-নির্ভর কাজের প্রক্রিয়া
Critical Thinking	বিশ্লেষণমূলক চিন্তাভাবনা
Cognitive Offloading	চিন্তার কাজ AI-কে দেওয়া
Cognitive Surrender	নিজের বিচারক্ষমতা ছেড়ে দেওয়া
Cognitive Debt	চিন্তাশক্তির ঘাটতি জমা হওয়া
Comprehension Debt	Code না বোঝার ঘাটতি
Intent Debt	অস্পষ্ট উদ্দেশ্য ও Requirements-এর ঘাটতি
Mental Model	System সম্পর্কে মানসিক ধারণা
Human Oversight	মানুষের তদারকি
Verification	যাচাই
Accountability	জবাবদিহি
Orchestration Tax	Agent পরিচালনা ও Review-এর মধ্যকার ব্যবধান
Supervision Paradox	AI তদারকির দক্ষতাই AI নির্ভরতার কারণে দুর্বল হওয়ার ঝুঁকি
Hypothesis	প্রাথমিক অনুমান
Trade-off	একটি সুবিধার বিনিময়ে অন্য কিছুর ছাড়
Acceptance Criteria	কাজ সফল হওয়ার নির্দিষ্ট শর্ত

Translation and explanatory adaptation based on Addy Osmani’s November 3, 2026 article. Additional examples and the reusable coding prompt are original additions. This is not a word-for-word reproduction.

Original reading: Critical thinking when agents do the work — Addy Osmani · Supporting full-text reference .