Cheap Coding-এর যুগে, পার্ট ৩: What to Do Next

• Essay
• Video

আমাদের engineering loop বদলে গেছে। Code লেখা এখন একটা delegate করা step মাত্র — তার আগের আর পরের কাজগুলোই এখন human হিসেবে আমাদের আসল কাজ।

এটা “How to Keep Myself Relevant in the Age of Cheap Coding” talk-এর তৃতীয় পর্ব — what to do next। পুরো talk-এর slide-গুলো আছে এই deck-এ।

Watch the video ↗

আমাদের engineering loop বদলে গেছে

প্রথমেই যেটা বলতে চাই — আমাদের traditional development lifecycle, মানে আমাদের working style, অনেকখানি বদলে গেছে। শুনতে অনেক আগের কথা মনে হয়, কিন্তু আমি আসলে কয়েক মাস আগের কথাই বলছি।

আগে আমরা যা করতাম:

1. Requirement বুঝতাম
2. Design করতাম
3. Code লিখতাম
4. Debug করতাম
5. Test করতাম
6. Deploy করতাম
7. Operate করতাম — bug fixing আর অন্যান্য কাজ

এখন খেয়াল করে দেখুন, আমরা নিজের হাতে প্রায় কোনো code লিখছি না। তাহলে আমরা করছি কী? আমাদের pre-code phase-গুলো অনেক বেশি expanded, elaborated এবং অনেক বেশি important হয়ে গেছে।

শুধু বুঝলেই হবে না, intent specify করতে হবে

বোঝাটা আমার মাথার ভেতরে থাকে। সেটা যথেষ্ট না। We have to specify the intent — কোথাও লিখে রাখতে হবে আমরা কী চাই, কী চাই না, কেন চাই, কীভাবে চাই।

তারপর constraints। এটা হলে ওটা হবে না, ওটা হলে এটা হবে না। Rules, regulations, guardrails — don’t do this, don’t do that।

তারপর decompose। কাজ যত ছোটই হোক, যত ভালোভাবে আমরা সেটাকে ভেঙে নিতে পারব, কাজের quality তত বাড়বে।

“Hey, go and do this” বললে agent কাজটা করে দেবে ঠিকই। কিন্তু quality কখনোই সমান হবে না। তুলনা করুন সেই অবস্থার সাথে, যেখানে আপনি আগে নিজে বুঝেছেন কী করতে হবে, intent specify করেছেন, constraints লিখেছেন, তারপর agent-এর সাথে বসে codebase ধরে ধরে দেখিয়ে দিয়েছেন: “সম্ভবত এই file-গুলোতে এই change-গুলো হবে, আর এই event-গুলো লাগবে।”

এগুলো documented থাকলে agent চাইলেও ভুল রাস্তায় যেতে পারবে না।

Decomposing is very important nowadays. I cannot say it enough.

Delegate, তারপর নজর রাখা

এরপর delegate — “ঠিক আছে ভাই, এবার তুমি কাজটা করো।”

Agent যখন generate করছে, তখনও human হিসেবে আমাদের অনেক কিছু করার আছে। কাজের মাঝখানে সে কোনো ভুল করছে কিনা, অন্য দিকে চলে যাচ্ছে কিনা — এগুলো check করতে হয়।

Verify — এখানেই QA-এর গুরুত্ব

এরপর verify। Verification-এরও অনেক রকম ধরন আছে। Here comes the importance of QA।

QA বলতে আগে আমরা বুঝতাম একজন মানুষ, যিনি বসে বসে click, click, click করবেন। এটা verify না।

Verify মানে নিশ্চিত করা যে আমরা যা চেয়েছিলাম তা আছে, আর যা চাইনি তা নেই। Code, UI বা যে artifact-ই হোক, সেটা আমাদের চাওয়া পূরণ করছে।

এটাকে একটা proper verification process-এ আনতে হবে, যেন একটা script বা একটা command চালিয়ে বারবার verify করা যায়। মানুষের পক্ষে একই জিনিস বারবার করা কঠিন। এই কাজটা scripting-এর।

যারা আমাকে follow করেন তারা জানেন, আমি শুধু কথা বলি না, POC-ও share করি। যেমন QA-এর জন্য আলাদা skill নিয়ে আমার লেখাটা দেখে নিতে পারেন।

এরপর architecture inspect করা, এবং test adversarially। খুব rigorously test করতে হবে — কী হচ্ছে, কী হচ্ছে না।

এখন আমাদের হাতে agents আছে। Agent Playwright চালাতে পারে। Playwright সব page ঘুরে edge case-গুলোও check করতে পারে।

একটা উদাহরণ দিই। আমি Playwright দিয়ে drag-and-drop automate করেছি। আপনি ভাবতে পারেন, user drag-and-drop করছে এমন complex UI feature কি automate করা যায়? যায়, I did it। সেই script এখন প্রতিবার চলবে, আর প্রতিবার নিশ্চিত করবে যে আমার drag-and-drop এখনও কাজ করছে।

Operate, observe, learn, iterate

Operate আগের মতোই — observe করা, তারপর learn and iterate।

“Learn” বলতে আমি বোঝাচ্ছি: প্রথম loop-এ যে সমস্যাগুলো হলো, সেগুলো আমরা learning হিসেবে কোথাও লিখে রাখব, যেন পরের loop-এ একই সমস্যা আর না হয়।

তাহলে নতুন engineering loop-টা দাঁড়াচ্ছে এরকম:

1. Understand
2. Specify intent
3. Define constraints
4. Decompose
5. Delegate
6. Supervise
7. Verify
8. Operate and observe
9. Learn and iterate

অনেক কথা বললাম, কারণ slide পড়ে শোনানোর বদলে ব্যাপারটা ঠিকমতো ব্যাখ্যা করতে চেয়েছি। আশা করি বোঝা যাচ্ছে, এই নতুন loop-এ human হিসেবে আমাদের কত কিছু করার আছে।

আমাদের ছোট্ট একটা ভুলের কারণে AI garbage output তৈরি করা শুরু করতে পারে। তাতে token cost যায়, সময় যায়। আর সবচেয়ে বড় কথা, human হিসেবে আমাদের judgement প্রশ্নবিদ্ধ হয়। So don’t do that.

Scarce skills: আগে যেটা skill ছিল, এখন কী?

এবার আসি human-এর কথায় — আমাদের scarce skills।

তখন: typing speed

আমার স্পষ্ট মনে আছে, career-এর শুরুতে — 2010–11 সালের কথা বলছি — আমি নিশ্চিত করেছিলাম যে আমার typing speed 60 words per minute-এর বেশি।

কাউকে দেখানোর জন্য না। করেছিলাম যেন syntax লেখার সময় আমার brain-কে keyboard-এর দিকে মনোযোগ দিতে না হয়।

আমি চাইতাম আমার চিন্তা যত দ্রুত চলছে, screen-এ code লেখার গতি যেন তার সাথে তাল মেলাতে পারে। Brain-এর একটা অংশ যেন “কোন key, কোন key” খুঁজতে ব্যস্ত না থাকে।

মনে হতো হাত আলাদাভাবে নিজে নিজেই চলছে। আমি শুধু ভাবছি, আর code আপনাআপনি তৈরি হচ্ছে।

আমার সর্বোচ্চ ছিল 80+। ঠিক 85 না 95, সেটা নিশ্চিত না, কিন্তু 80-এর উপরে — এটা নিশ্চিত। অনেকদিন সেটা ধরে রেখেছিলাম। এখনও বসলে সম্ভবত 60+ সহজেই হবে।

So that was a good skill to have. What is it now?

এখন: specifically specifying what to build

এখন আমাদের শিখতে হবে — কী বানাতে হবে সেটা precisely specify করা।

যত precisely, যত elaborately আমরা specify করতে পারব, build quality, code quality, output quality তত ভালো হবে। এটাই এখন নতুন skill।

Smart syntax নয়, fundamentals

দুই-তিন বছর আগেও Node.js-এর latest API-গুলো মাথায় রাখতে হতো। API বলতে অনেকে শুধু web API বোঝেন; আমি বলছি library API, মানে যেকোনো function। মনে রাখতে হতো যে for loop না লিখে .filter() বা .map() ব্যবহার করা যায়, JavaScript বা TypeScript-এর smart syntax-গুলো কী কী।

এখন এগুলো important না, তা বলব না। কিন্তু তার চেয়ে অনেক বেশি important হয়ে যাচ্ছে fundamentals।

যেমন: কেন এভাবে query করা উচিত না? কারণ এই query database-এর সব data memory-তে টেনে আনবে। আমার মতে এটা একটা fundamental।

কারণ আপনি specify না করলে কোনো AI নিজে থেকে এটা বলবে না।

ধরুন আপনি বললেন “build me a list page”। সে list page বানিয়ে দেবে। তারপর বললেন “write the query”। সে database-এ গিয়ে SELECT * FROM table চালাবে, তারপর filter করবে application-এ। Table-এ দশ হাজার row থাকলে দশ হাজার row-ই memory-তে উঠে আসবে।

তাই fundamentals — know what you are doing, precisely।

Middleware, auth, useMemo

আরেকটা উদাহরণ, top of my head। API implement করার সময় middleware থাকে।

ছোট খেলনা project হলে AI নিজেই বুঝে নিতে পারবে কোথায় কী হবে। কিন্তু মাঝারি বা বড় project, যেটা কয়েক বছর ধরে চলছে এবং যেখানে complex middleware আছে, সেখানে authentication-এ কিছু বদলাতে চাইলে আপনাকেই জানতে হবে cookie, token, expiry কীভাবে কাজ করছে।

আপনাকে বুঝতে হবে middleware-টা আসলে কীভাবে চলছে। এখান থেকে error throw হলে সেটা কোথায় গিয়ে ধরা পড়ছে।

এটাকে Node.js-এর fundamental বলতে পারি।

React-এ আসুন। আপনি চাইলেই যেখানে-সেখানে useMemo বসিয়ে দিতে পারেন। কিন্তু কেন useMemo? কারণটা কী? useRef কেন ব্যবহার করছেন, সেটা কি জানেন?

AI কিছু code produce করছে, হয়তো ভালো code-ই। কিন্তু তার মানে এই না যে সে জানে সে কী করছে। সেই code আসলেই ভালো কিনা, সেটা নিশ্চিত করার দায়িত্ব আপনার বা আমার।

So the fundamentals become even more important.

Feature বানানো সহজ, system design-ই আসল কাজ

আগে feature implement করতে পারাটাই ছিল দক্ষতা। কোন feature mid-level engineer পারবে আর কোনটা senior-এর লাগবে — এভাবেই আমরা কাজ ভাগ করতাম।

এখন feature বানানো সহজ হয়ে গেছে। হাতে অনেক বাড়তি সময়। আমি নিজের ক্ষেত্রেও এটা বলতে পারি।

তাই এখন আমাদের দায়িত্ব হলো code quality, architecture, system এবং পুরো data flow-এর orchestration ঠিকঠাক balanced রাখা। ঘুরেফিরে আবার fundamentals-এই আসছে, কিন্তু designing systems এখন অনেক বেশি important।

হাতে testing নয়, script

Testing by hand, মানে monkey testing — না। আমরা যা যা test করতে চাই, সব script করতে হবে।

“UI অনেক complex, হাতে test করা ছাড়া উপায় নেই” — এই অজুহাত এখন আর চলে না। আমি নিজে এটা করছি, এবং trust me, সেগুলো বেশ complex system।

কোনো confusion থাকলে comment বা message-এ প্রশ্ন করুন।

Personal output নয়, people আর agents-কে multiply করা

আগে আমাদের skill মাপা হতো — কয়টা feature বানালাম, কত lines of code লিখলাম। সেটা ভালো ছিল।

এখন গুরুত্বপূর্ণ হলো আমাদের কাজের impact। আমার কাজ কতজন মানুষ আর কতগুলো agent-এর output বাড়িয়ে দিচ্ছে — সেটাই এখন মাপকাঠি।

Become exceptional at specification

আগেই বলেছি, specify করতে হবে। আপনি যথেষ্ট precise বা যথেষ্ট elaborate না হলে agent ভুল জিনিস বানাবে। শুধু token নষ্ট হবে।

নিজের লেখা spec নিজে আবার পড়ুন। নিশ্চিত হোন কী হওয়ার কথা আর কী হওয়ার কথা না।

A better specification gives better delegation. It also makes verification possible — কারণ কী হওয়ার কথা লেখা না থাকলে, কাজ করছে কিনা সেটা নিশ্চিত করবেন কীভাবে?

What আর How আলাদা রাখুন

System কী করবে (what the system must do) আর কীভাবে করবে (how the system may do it) — এই দুটো আলাদা করতে হবে, খুব precisely।

“What” হলো user behavior। যেমন: user dropdown-এ click করবে, data আসবে, chart দেখাবে, scroll থাকবে, একটা item select করলে তার উপর নির্ভর করে নতুন data load হবে। আর এটা-এটা হওয়া যাবে না।

“How” একটা আলাদা লেখা, আলাদা essay বলতে পারি। দুটো ভিন্ন জিনিস, আলাদা রাখাই উচিত।

Verification নিজেই একটা core skill

আগে প্রশ্ন ছিল: “Did you implement it?” উত্তর: “Yes।”

এখন প্রশ্নটা হওয়া উচিত: what evidence shows it works?

এখানেই আসছে evidence।

যারা QA হিসেবে শুধু monkey testing করতেন, সত্যি বলতে তাদের সেই কাজের আর ভাত নেই।

কিন্তু QA হিসেবে আপনি যদি সত্যিকারের insight তৈরি করে থাকেন যে verification process কীভাবে কাজ করে, তাহলে এটাই আপনার golden time। সেই idea-গুলো implement করার সময় এখন। কীভাবে পুরো system control করা যায়, automate করা যায়, verify করা যায়।

Script লিখুন, চালিয়ে দিন, আর আপনি ততক্ষণে YouTube দেখুন। না, YouTube না — বই পড়ুন। Just joking।

Slide deck-এ আমি অনেক রকম testing-এর নাম রেখেছি, শুধু reference হিসেবে। এটাই শেষ না, আরও অনেক আছে। নিজে খুঁজে দেখুন।

Senior engineer-এর advantage

আমরা যারা senior — বয়সে হোক বা বয়স কম হলেও experience-এ — আমাদের সামনে এখন নিজের work output amplify করার বিশাল সুযোগ।

আমরা সঠিক প্রশ্নগুলো করতে পারি, এবং সেগুলোর উত্তর system-এ implement করতে পারি। নিশ্চিত করতে পারি যে system নানা পরিস্থিতিতে কাজ করে, নানা constraint সামলায়, best practice মেনে চলে।

এগুলো আসে experience থেকে।

“10x বা 100x traffic এলে কী হবে?” — এই প্রশ্ন আমি একজন junior-কে করব না। সে Google বা AI থেকে একটা উত্তর এনে দিতে পারবে, কিন্তু তার কাছে এটা আশা করা unrealistic।

একজন মানুষ senior হন কারণ তিনি এই সমস্যাগুলো নিজে face করেছেন। Face না করে শুধু উত্তরটা mimic করলে সেটা senior হওয়া না।

আর এই অভিজ্ঞতাগুলোই আমরা এখন আমাদের system-এ, আমাদের spec আর constraint-এ, properly যোগ করতে পারি।

Experience contains patterns of failure. Slide deck-এর list-টা শুধু reference, এটাই শেষ না।

তাহলে কি coding করব না? অবশ্যই করব

এত কিছু বলার পর প্রশ্ন আসে — তাহলে কি আর coding করব না? অবশ্যই করব।

The purpose of coding changes। আগে আমরা code করতাম প্রচুর পরিমাণে, output-এর জন্য।

এখন: do not compete on typing speed. Keep coding to keep your intuition।

টুকটাক code করা, দেখা আসলে ভেতরে কী হচ্ছে। Like a pilot who still practices flying by hand।

গাড়ির autopilot-এর কথা ভাবুন। (আমার অমন গাড়ি নেই, don’t get me wrong।) Driving আমি autopilot-কে delegate করলেও মাঝে মাঝে নিজে একটু চালাতে হয়, জিনিসগুলো check করতে হয়, যেন ভুলে না যাই। Touch-টা রাখা, feel করা কী হচ্ছে।

Not because it is faster — because understanding still matters.

যে fundamentals এখন শিখতে হবে

“এটা করব না, ওটা করব না” অনেক বললাম। তাহলে করব কী? এই অংশটা আমি একটু বিস্তারিত বলতে চাই।

এগুলো আমি নিজেও চেষ্টা করছি, যতটা সম্ভব deep-এ যাওয়ার। সময়ও তো খুব বেশি পাই না।

Runtime internals

Developer হিসেবে career path steady রাখতে চাইলে, আপনি যে language-এই থাকুন — C#, Java, Node.js, Python, doesn’t matter — runtime internals জানতে হবে। Language-টা আসলে কীভাবে run হচ্ছে।

Syntax লিখতে হচ্ছে না বলে আমাদের অনেক সময় বেঁচে যাচ্ছে। Syntax মুখস্থ করার সেই সময়টা আমরা internals বোঝার পেছনে invest করতে পারি।

Database

আমাদের মধ্যে কয়জন database-কে সত্যিই মন থেকে important মনে করেন, আমি নিশ্চিত না।

একটা request এলে connection pooling কীভাবে কাজ করে? MongoDB-তে performance বোঝার অনেক ratio আছে — read/write ratio, কত document scan হলো বনাম কত return হলো, কত key examine হলো। এগুলো কেন আছে, কীভাবে কাজ করে?

এগুলো fundamentals। যত বেশি জানব, তত ভালো।

“Search করলেই তো পাওয়া যায়”

আপনি বলতে পারেন, এগুলো তো search করলেই পাওয়া যায়। সত্যি। কিন্তু search তো আগেও ছিল।

ব্যাপারটা search করে পাওয়ার না। কাজের সময় আমাদের হাতে সময় থাকে না। তখন গিয়ে database-এর বই পড়ে আসার সুযোগ নেই।

“ফয়জুল ভাই, এই কাজটা করে দিন।” — “আচ্ছা, আগে database-টা পড়ে আসি।” এভাবে তো কাজ হয় না।

আমরা university-তে নেই। পড়াশোনাটা করতে হয় কাজের ফাঁকে বা কাজের পরে। আমি যা বলতে চাইছি: এখন যেহেতু আমরা বেশি সময় পাচ্ছি, আর AI আছে helper হিসেবে, এই বিষয়গুলোতে আমাদের deep-এ যাওয়া উচিত।

যেন AI-কে যখন instruct করি, তখন আমরা what, why, এমনকি how-ও জানি।

যদি একটা trade-off নিতেই হয়, যেন জেনে-বুঝে নিই, অজান্তে না। “তুমি এটা কী করেছ? এটা তো ভুল!” — এই অবস্থায় আমরা পড়তে চাই না।

That’s where our knowledge matters, our quality matters, and our money comes।

The closer you are to the fundamental constraints, the harder it is to replace understanding with prompting.

তিনটা জিনিস জানতেই হবে

সবকিছু হয়তো আপনার লাগবে না। কিন্তু কোনো একটা দিয়ে শুরু করুন।

Feature developer হলেও এই তিনটা জানতেই হবে: runtime internals, database, networking।

ধরুন আপনি জানেনই না localhost আর 127.0.0.1-এর পার্থক্য কী। একটা নাম থেকে IP কীভাবে খুঁজে পাওয়া যায়, DNS lookup কীভাবে হয়।

How are you even a web developer if you don’t know this type of thing?

Security

Security আরেকটা খুব important বিষয়, এবং এখন আগের চেয়েও বেশি। কারণ AI দিয়ে এখন যেকোনো system-এ automated attack চালানো সহজ হয়ে গেছে।

AI magical programmer না — আমার engineering toolkit-এর একটা অংশ

Operate AI as an engineering system।

আমরা হয়তো ভাবি AI একটা magical programmer। না। এটা আমার engineering toolkit-এর একটা অংশ। সবকিছু orchestrate করবে আমার knowledge, আর AI-কে আমি ব্যবহার করব আমার মতো করে।

এখানে মূল কাজ হলো একটা probabilistic system-এর চারপাশে reliable process তৈরি করা। Probabilistic system-কে কীভাবে deterministic-এর কাছাকাছি আনা যায় — এটা human হিসেবে আমাদের কাজ।

Prompting is not the moat

Prompting is not the moat। Prompting আসলে সবচেয়ে basic জিনিস।

আসল কাজগুলো হলো:

• Problem decomposition
• Specification
• Architecture
• Verification process
• System thinking — system কীভাবে চলে, flow কীভাবে চলে, security কীভাবে কাজ করে, performance কোথায় tune করা যায়, bottleneck কোথায়
• Domain knowledge এবং operational judgement

কে ঝুঁকিতে, কে লাভবান হবে

Who is at risk

আপনার বা আমার কাজ যদি হয় শুধু ticket implement করা — ticket এলো, copy-paste, commit, push, merge, goodbye — তাহলে আপনার career ঝুঁকিতে আছে।

Who will gain

যিনি outcome-এর মালিকানা নেন, end to end। যিনি বারবার জিজ্ঞেস করেন “কেন? কীভাবে এটাকে আরও ভালো করা যায়?” এটা বুঝলে আমরা আরও এগিয়ে যাব।

আর যিনি একা একটা ছোট team-এর কাজ deliver করতে পারেন। আগে DevOps-এর জন্য একজন, AI-এর জন্য একজন, ML-এর জন্য একজন লাগত। এখন একজন মানুষ agents নিয়ে এর অনেকটাই করতে পারেন।

Personal strategy

এটা আমি personally follow করি, বা করার চেষ্টা করি। এগুলো কোনো rule না, আমার strategy। Slide deck-এ এটা reference হিসেবে রাখা আছে; নিজের study আর judgement দিয়ে ঠিক করুন।

Agent architecture শিখুন

এটা নতুন শেখার জিনিস, skip করার জিনিস না। AI নিয়ে কাজ করলে জানতে হবে কীভাবে smartly, efficiently এবং সস্তায় কাজ করা যায়।

AI agents আর harness-গুলো কেন এবং কীভাবে কাজ করে, সেটা বোঝা দরকার। যারা আমাকে follow করেন, তারা Claude Code-এর কথা জানেন। আমি একটা skill বানিয়েছি — session audit — যেটা আপনার পুরো session history analyse করে বলে দেয় কীভাবে আরও ভালো করা যায়। এটা দিয়ে আমি কী শিখেছি, সেটা লিখেছি এখানে।

বাকিগুলো

• টুকটাক coding চালিয়ে যাওয়া
• System architecture — অনেকবার বলেছি
• Verification — অনেকবার বলেছি
• Teaching and writing

Teaching and writing কেন important

এই যে আমি কথা বলছি, এটাও একটা practice। গুছিয়ে কথা বলার practice — garbage talk না।

আমরা যত এভাবে চিন্তা share করব, আমাদের thought process তত sharp হবে। তখন আমরা AI এবং অন্য মানুষ, দুই পক্ষের সাথেই পরিষ্কারভাবে লিখে communicate করতে পারব।

আমি কিছু লিখলে text-টা কয়েকবার পড়ি। দেখি message-টা ঠিকমতো convey হচ্ছে কিনা, পড়তে সহজ কিনা, কোনো visual লাগবে কিনা।

Teaching তুচ্ছ কিছু না

Teaching মানেই “তাবিজ বিক্রি” — এভাবে ভাববেন না। যারা এমন বলেন, শুনলে মেজাজ খারাপ হয়। তবে হ্যাঁ, বাংলাদেশে তাবিজ বিক্রেতা যে নেই তা না। অনেক fraud আছে।

আমি বলছি honest জায়গা থেকে। আমরা যারা honest থাকার চেষ্টা করছি, তারা teaching-কে negligible মনে করি না।

Knowledge is a sacred thing; we should not demonize it। Teaching বন্ধ হয়ে গেলে knowledge-এর flow বন্ধ হয়ে যাবে, আর তাতে humanity-রই ক্ষতি।

Slide-এর সংখ্যাগুলো important না, অনুপাতটা important। একদিনে সব করে ফেলতে হবে তা না। Think and do properly.

“তাহলে আপনি নিজে কী করছেন?”

শেষ প্রশ্ন। “ভাই, অনেক কথা বললেন, অনেক সময় দিলেন। ঠিক আছে — আপনি নিজে কী করছেন?”

Node.js deep dive। আগেও টুকটাক পড়েছি, কিন্তু এখন যতটা deep level-এ যাওয়া সম্ভব, পড়ছি। আর সেটা নিয়ে লেখার চেষ্টা করছি — visuals আর animation সহ, এই blog-এই। যেমন event loop আর libuv নিয়ে লেখাটা। It’s fun to read, I hope।

AI clone। এটা বানানোর চেষ্টা করছি। Speech-to-text আর text-to-speech দিয়ে একটা project, যেখানে মনে হবে আপনি আমার সাথে কথা বলছেন, কিন্তু আসলে আমার সাথে না। আমার non-human AI version। এখনও কিছু POC করছি, we’ll see।

Write and share। একটু আগে যা বললাম — knowledge enhances by sharing।

শেষ কথা

আজ এ পর্যন্তই। লম্বা আলোচনা হলো। আশা করি কিছু important বিষয় আপনাদের সাথে share করতে পেরেছি।

কোনো question, comment বা suggestion থাকলে, বা এমন কোনো area থাকলে যেটা আমি cover করিনি, জানাবেন। আলোচনা করব, অথবা নতুন লেখা বা video বানাব।

See you in the next one. Thank you. Assalamu alaikum.

এই লেখাটা যে talk থেকে, তার পুরো slide deck দেখতে চাইলে: How to Keep Myself Relevant in the Age of Cheap Coding — slides।