এআই যখন আর্কিটেক্ট, আমরা তখন কে?
এআই দিয়ে আর্কিটেকচার তৈরি সহজ হলেও কেন হারাচ্ছে ডেভেলপারদের নিজস্ব চিন্তাশক্তি? এই স্কিল অ্যাট্রফি থেকে বাঁচার বাস্তব অভিজ্ঞতা ও সমাধান।
সেদিন বিকেলে অফিসের এক জুনিয়র ইঞ্জিনিয়ার (Junior Engineer) বেশ উৎফুল্ল মুখে ল্যাপটপ নিয়ে আমার ডেস্কে এলো।
"ভাইয়া, নতুন ফিচারটার (Feature) আর্কিটেকচার স্কেলিটন (Architecture Skeleton) রেডি! আপনি জাস্ট একবার চোখ বুলিয়ে দিন।"
স্ক্রিনে তাকিয়ে সত্যি বলতে ভেতরে একটা অস্বস্তি আর বিস্ময় একসঙ্গে কাজ করছিল। টেমপ্লেটটি (Template) নিখুঁত—ক্লিন আর্কিটেকচার (Clean Architecture), CQRS প্যাটার্ন (Pattern), আলাদা কমান্ড (Command) ও কোয়েরি হ্যান্ডলার (Query Handler), ডেকোরেটর (Decorator) দিয়ে ক্রস-কাটিং কনসার্ন (Cross-cutting Concern) আলাদা করা, এমনকি ডিস্ট্রিবিউটেড ক্যাশিংয়ের (Distributed Caching) ইন্টারফেসও (Interface) সাজানো। বছর কয়েক আগেও এই লেভেলের একটা আর্কিটেকচার দাঁড় করাতে আমাদের কয়েক দিন ধরে মিটিং আর ব্রেনস্টর্মিং (Brainstorming) করতে হতো।
আমি একটু থেমে জুনিয়রকে শান্তভাবে একটা সাধারণ প্রশ্ন করলাম:
"ডিজাইন দেখতে দারুণ। শুধু একটা জিনিস একটু বুঝিয়ে দাও—এখানে যে ব্যাকগ্রাউন্ডে (Background) ইভেন্ট সিঙ্ক (Event Sync) বসিয়েছ, ট্রানজেকশনের (Transaction) মাঝপথে যদি নেটওয়ার্ক ফেইল (Network Fail) করে, তাহলে ডেটার অসামঞ্জস্য কীভাবে হ্যান্ডেল (Handle) হবে? আর আমাদের এই মডিউলের (Module) জন্য লেটেন্সি বাজেট (Latency Budget) কত ধরা হয়েছে?"
জুনিয়র কিছুক্ষণ স্ক্রিনের দিকে তাকিয়ে থেকে ইতস্তত করে বলল, "ভাইয়া, প্রম্পট (Prompt) দেওয়ার পর ক্লদ (Claude) এটা সাজেস্ট (Suggest) করল। বেশ স্ট্যান্ডার্ড (Standard) মনে হলো, তাই রেখে দিয়েছি।"
বাইরে থেকে পুরো সিস্টেম (System) চকচকে এবং ইন্ডাস্ট্রি-গ্রেড (Industry-grade), কিন্তু ভেতরের মূল যুক্তিটাই নিখোঁজ।
বিপরীত যুক্তি: এআই (AI) কি আসলেও দোষী, নাকি এটা আমাদের বাস্তব বিবর্তন?
এখানে একটা নির্মোহ সত্য স্বীকার করা দরকার। এই পুরো ঘটনায় সব দায় কেবল এআই (AI) বা অলসতার ওপর চাপিয়ে দেওয়াটাও এক ধরণের একচোখা বিশ্লেষণ হবে। টেক ইন্ডাস্ট্রির (Tech Industry) একটা বড় অংশ কিন্তু খুব যৌক্তিকভাবেই অন্য কথা বলছে:
- ইঞ্জিনিয়ারিংয়ের সংজ্ঞা পরিবর্তন: একসময় মেমোরি ম্যানেজমেন্ট (Memory Management) নিজে হাতে না করলে কাউকে 'আসল প্রোগ্রামার' ভাবা হতো না। সি (C) বা অ্যাসেম্বলি (Assembly) ছেড়ে যখন জাভা (Java) বা সি# (C#) আসলো, তখনও বলা হয়েছিল ডেভেলপাররা মেমোরির বোঝাপড়া হারাচ্ছে। এআই-এর আগমন হয়তো সেই বিবর্তনেরই আরেকটি ধাপ। এখনকার দুনিয়ায় কম সময়ে ব্যবসা দাঁড় করানো আর দ্রুত আইডিয়েশন টেস্ট (Ideation Test) করাই মূল লক্ষ্য। সেখানে বয়লারপ্লেট (Boilerplate) আর প্যাটার্ন (Pattern) এআই লিখে দিলে সমস্যা কোথায়?
- প্রোডাক্ট ভেলোসিটি (Product Velocity) বনাম পারফেকশনিজম (Perfectionism): ব্যবসার জন্য দিনের শেষে কোডের সৌন্দর্য নয়, ভ্যালু ডেলিভারি (Value Delivery) আসল। একটি আর্লি-স্টেজ স্টার্টআপ (Early-stage Startup) বা ইন্টারনাল টুলের (Internal Tool) জন্য ছয় মাস ধরে আর্কিটেকচার না ভেবে, এআই দিয়ে তিন দিনে ফিচার রিলিজ (Feature Release) করে মার্কেট ফিডব্যাক (Market Feedback) নেওয়াটাই অর্থনৈতিকভাবে সবচেয়ে বুদ্ধিমানের কাজ।
- কোড লেখার শ্রম কমা মানেই চিন্তা বন্ধ হওয়া নয়: এআই আসার ফলে একজন ইঞ্জিনিয়ারকে শত শত লাইন রিডানড্যান্ট কোড (Redundant Code) টাইপ করতে হচ্ছে না। সে মুক্ত হচ্ছে সিস্টেমের ওভারঅল বিজনেস ভ্যালু (Overall Business Value) আর আউটপুট (Output) নিয়ে ভাবার জন্য।
তাহলে কি যারা এআই দিয়ে দ্রুত আর্কিটেকচার বানাচ্ছেন, তারা ভুল কিছু করছেন? একদমই না। তাদের গতি এবং প্রেগমেটিজম (Pragmatism) শতভাগ বাস্তবসম্মত।
বিশেষজ্ঞরা কী বলছেন? (ইন্ডাস্ট্রির দৃষ্টিভঙ্গি ও সোর্স)
এই টানাপোড়েন শুধু একটি টিমের নয়, বৈশ্বিক স্তরে সফটওয়্যার ইঞ্জিনিয়ারিংয়ের শীর্ষ চিন্তাবিদরাও এই রূপান্তর নিয়ে কথা বলছেন:
-
আন্দ্রেজ কার্পাথি (Andrej Karpathy - Former Director of AI, Tesla / OpenAI):
কোডিংয়ের এই ট্রেন্ডকে তিনি আখ্যা দিয়েছেন "Vibe Coding" হিসেবে। যেখানে কোডের ভেতরের জটিলতা পুঙ্খানুপুঙ্খ না জেনে কেবল প্রম্পট (Prompt) আর রেজাল্টের অনুভূতির ওপর ভিত্তি করে বিল্ড (Build) করা হয়:"I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works... It's not really coding, it's more like directing."
-
মার্টিন ফাউলার (Martin Fowler - Chief Scientist, Thoughtworks):
সফটওয়্যার আর্কিটেকচারের অন্যতম পথপ্রদর্শক মার্টিন ফাউলার মনে করিয়ে দেন যে কোড লেখার গতি বাড়লেই আর্কিটেকচার উন্নত হয় না:"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
এআই সেকেন্ডে হাজার লাইনের প্রি-ম্যাচিউর অ্যাবস্ট্রাকশন (Premature Abstraction) দিতে পারে, কিন্তু বিজনেস রুলস (Business Rules) আর কনটেক্সটের (Context) গভীরতা মডেলের নিজস্ব থাকে না। -
কেন ব্যাক (Kent Beck - Creator of Extreme Programming & TDD):
তিনি এআই-এর প্রভাবকে সরাসরি অর্থনৈতিক মূল্যের দিক থেকে দেখেছেন:"AI changes the economics of software development. It makes 90% of programming skills worth $0, and the remaining 10% (the architecture, domain modeling, and trade-off decisions) worth 1000x."
আসল ফাটলটা ঠিক কোথায়?
সমস্যাটা এআই ব্যবহারের মধ্যে নয়; সমস্যাটা তৈরি হয় যখন আমরা "টুল ব্যবহার করা" আর **"সিস্টেমের দায়িত্ব নেওয়া"**র মাঝের ফারাকটা ভুলে যাই। একে কগনিটিভ সায়েন্সে (Cognitive Science) বলা হচ্ছে Skill Atrophy বা Cognitive Offloading।
যখন আপনি না বুঝে এআই-এর জেনারেট করা হাই-এন্ড প্যাটার্ন (High-end Pattern) সিস্টেমে ঢুকিয়ে দিচ্ছেন, তখন আপনি সাময়িক স্পিড (Speed) পাচ্ছেন ঠিকই, কিন্তু সাথে ডেকে আনছেন এক অদৃশ্য 'আর্কিটেকচারাল ডেট' (Architectural Debt বা Technical Debt)।
যেখানে ১০০ জন ইউজারের জন্য একটা সাধারণ মনোলিথিক সার্ভিস (Monolithic Service) যথেষ্ট ছিল, সেখানে এআই সাজেস্ট করেছে বলে আপনি মাইক্রোসার্ভিস (Microservices) আর মেসেজ ব্রোকার (Message Broker) বসিয়ে দিলেন। যেদিন প্রোডাকশনে (Production) ডেটা করাপ্ট (Data Corrupt) হবে বা কনকারেন্সি ইস্যু (Concurrency Issue) দেখা দেবে, সেদিন প্রম্পট দিয়ে আর চটজলদি সমাধান মিলবে না। কারণ মডেলটি আপনার কোম্পানির বিজনেস রুলস বা ডেটাবেজ লকিংয়ের (Database Locking) গভীরতা নিজে ফিল (Feel) করে না।
আমরা যেভাবে ব্যালেন্সটা খুঁজে পেলাম
সেদিন আমি জুনিয়রের ওপর বিরক্ত হইনি। বরং তাকে ডেকে মনিটরটা স্লিপ মোডে (Sleep Mode) পাঠালাম।
বললাম, "ল্যাপটপটা একটু পাশে রাখো। এই সাদা কাগজ আর পেনটা নাও।"
আমরা খুব সাদামাটাভাবে পুরো ফিচারটার ফ্লো (Flow) নিজে হাতে আঁকা শুরু করলাম:
- ইউজার যখন রিকোয়েস্ট (Request) পাঠাবে, প্রথম ডেটাটা কোথায় জমা পড়বে?
- ব্যাকগ্রাউন্ড প্রসেস (Background Process) ফেইল করলে ব্যবহারকারী কী এরর মেসেজ (Error Message) দেখতে পাবে?
- এই টেবিল দুটোর রিলেশনশিপে (Relationship) সত্যিই কি কোনো থার্ড-পার্টি কিউ (Third-party Queue) দরকার আছে?
কাগজে পুরোটা আঁকার পর জুনিয়র নিজেই হেসে বলল, "ভাইয়া, আমরা তো মাত্র কয়েকশো ইউজারের একটা ফিচার বানাচ্ছি! এখানে CQRS আর ইভেন্ট বাস (Event Bus) ঢুকিয়ে কোড তো অহেতুক জটিল করে ফেলেছিলাম। একটা সিম্পল ট্রানজেকশন (Transaction) দিয়েই তো পুরো কাজটা অনেক দ্রুত আর ক্লিনভাবে হয়ে যায়!"
সেই আড্ডা থেকে আমরা তিনটি খুব সহজ কিন্তু কার্যকর বোঝাপড়ায় পৌঁছালাম:
১. আর্কিটেকচার মাথায়, কোডিংয়ে এআই (Design First, Prompt Later)
আর্কিটেকচারাল ডিসিশন (Architectural Decision) কোনো মডেল ঠিক করে দেবে না। সিস্টেমের ডোমেইন বাউন্ডারি (Domain Boundary) আর ডেটা ফ্লো (Data Flow) আগে ইঞ্জিনিয়ার নিজে বুঝবে, ড্রাফট (Draft) করবে। যখন পুরো লজিক নিজের মাথায় পরিষ্কার, কেবল তখনই দ্রুত কোড জেনারেটের (Code Generation) জন্য এআই-কে নির্দেশ দেওয়া হবে।
২. এআই-কে সহমতকারী নয়, প্রতিপক্ষ বানানো
এআই-কে বলবেন না আপনার হয়ে আর্কিটেকচার বানিয়ে দিতে। বরং নিজে আর্কিটেকচার ডিজাইন করে এআই-এর সামনে রাখুন এবং বলুন—
"Here is my design. Critique it ruthlessly. What edge cases, memory leaks, or race conditions did I miss?"
এতে নিজের ভাবনার দুর্বলতাগুলো দ্রুত ধরা পড়ে।
৩. 'ওনারশিপ' (Ownership) না থাকলে কোড প্রোডাকশনে নয়
কোড রিভিউয়ের (Code Review) সময় কোনো আর্কিটেকচার প্যাটার্ন বা লাইব্রেরি (Library) নিয়ে প্রশ্ন করলে উত্তর যেন কখনো এটা না হয়—"এআই দিয়েছিল।" দলমত নির্বিশেষে নিয়ম একটাই: আপনি যে কোড পুশ (Push) করছেন, তার প্রতিটি লাইনের দায় এবং কারণ ব্যাখ্যা করার ক্ষমতা আপনার থাকতে হবে।
এআই আমাদের শত্রু নয়, বরং ডেভেলপারদের পাওয়া এ যাবৎকালের সবচেয়ে শক্তিশালী লিভারেজ (Leverage)। কিন্তু এই সুবিধার বিনিময়ে যদি আমরা সিস্টেমের ভেতরের মেকানিজম (Mechanism) নিয়ে ভাবার কৌতূহল আর দায়িত্ববোধটাই হারিয়ে ফেলি, তবে প্রযুক্তি হয়তো এগোবে, কিন্তু ইঞ্জিনিয়ার হিসেবে আমরা ভেতর থেকে ফাঁকা হয়ে যাব।
টুলের গতি অবশ্যই নেব, কিন্তু ভাবনার স্টিয়ারিংটা (Steering) সবসময় নিজের হাতেই থাকা চাই।