AI কোড লেখে জিনিয়াসের মতো। আর্কিটেকচার গড়ে গোল্ডফিশের মতো।

ডেমো অবিশ্বাস্য দেখানোর দুই সপ্তাহ পরে বিল্ড মেরামত-অযোগ্য হয়ে গেল। এক জায়গায় ভাঙা নয়, সর্বত্র ভাঙা, এমন ভঙ্গিতে যা একে অন্যের বিরোধী। জিরো-শট স্কেলিং আসলে এমনই দেখতে। অ-ডেভেলপার আর মাঝেমধ্যে কোড লেখা মানুষেরা ছাদে উঠে চিৎকার করছেন যে AI সেকেন্ডে পুরো অ্যাপ্লিকেশন বানাতে পারে। তারা জিরো-শট প্রম্পটিংয়ে জোড়াতালি দেওয়া একটি চকচকে, কার্যকর প্রুফ অফ কনসেপ্ট দেখে ধরে নেন সেটা প্রায় শেষ, একটি পণ্যকে তার শেষ অবস্থায় পরিমার্জিত করতে যে সত্যিকারের, ঘষে-ঘষে এগোনো কাঠামোগত সময় লাগে তা পুরোপুরি উপেক্ষা করে।

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

আর্কিটেকচার

Claude, GPT5, Gemini 3-এর মতো AI মডেল স্টেটলেস ভবিষ্যদ্বাণী ইঞ্জিনের মতো কাজ করে। একটি জটিল প্রজেক্ট তখনই টিকবে যখন তার অন্তর্নিহিত নলেজ বেস পাথরের মতো শক্ত। ভিত দুর্বল হলে সময়ের সঙ্গে পরিবর্তন দরকার হলে পণ্য নির্মাণ অনিবার্যভাবে বাগ আর অসংগতি ঢোকাতে শুরু করবে।

আপনি যদি একটিমাত্র প্রম্পট থেকে জিরো-শটে অ্যাপ্লিকেশন বানানোর আশা করেন, বা প্রতিটি কাঁচা প্রম্পটের পর জাদুকরী ফলের আশা করেন, তাহলে আপনি অন্তহীন লুপে চলতে থাকবেন, একটি সমস্যা ঠিক করতে গিয়ে গোপনে অন্য কোথাও নতুন সমস্যা তৈরি করতে থাকবেন। সিস্টেমের মানচিত্র আঁকতে গবেষণার পরিকল্পনা ও সংশ্লেষণ, তারপর লক্ষ্যভেদী প্রম্পটের একটি সীমাবদ্ধ ধারা, এটাই মূলত এমন কোডবেস বানানোর সেরা কৌশল যা টিকে থাকে। ঠিক এ কারণেই একটি কঠোর নলেজ বেস এত জরুরি।

এই হলো সুনির্দিষ্ট বিভাজনরেখা: একজন ভালো সফটওয়্যার ইঞ্জিনিয়ার AI-র ঢোকানো কাঠামোগত অসংগতি সঙ্গে সঙ্গে ধরে ফেলবেন, অন্যদিকে মাঝেমধ্যে কোড লেখা মানুষ তাঁর পদ্ধতিতে সম্পূর্ণ নির্ভার থাকতে পারেন, সুখে অজ্ঞ যে তিনি পরস্পরবিরোধী স্টেট লজিকের একটি সর্বনাশা জট মার্জ করছেন।

# Example: What a strong, constrained knowledge base looks like
/antigravity-base
├── apps
│   ├── web        (Astro 4 + Tailwind v4)
│   └── studio     (Sanity CMS)
├── packages
│   ├── ui         (Strict design tokens - AI CANNOT hallucinate)
│   ├── config     (Shared ESLint/TS - strict boundaries)
│   └── core       (Business logic boundaries)
├── knowledge      (Deep context and architectural decisions)
│   └── routing-rules.md
└── turbo.json     (Build constraints)

নির্মাণ

যখন আমি gekro.com বানালাম, তখন ফাঁকা প্রম্পট আর জিরো-শট সাফল্যের নির্বোধ আশা নিয়ে শুরু করিনি। আমি শুরু করেছি একটি কঠোর আর্কিটেকচারাল কাঠামো দিয়ে। সময়ের সঙ্গে আমি নিজের “Antigravity” টেমপ্লেট বানিয়েছি, যেগুলো অত্যন্ত পুনর্ব্যবহারযোগ্য এবং যেকোনো জটিল প্রজেক্ট খুব দ্রুত শুরু করতে AI-কে কঠোরভাবে বেঁধে রাখতে আমাকে সাহায্য করে। প্রতিটি গুরুতর প্রজেক্টের সূচনাবিন্দু হওয়া উচিত আপনার বর্তমান ও দীর্ঘমেয়াদি দৃষ্টিভঙ্গির ওপর দাঁড়ানো গভীর-শিকড়ের ভিত। সীমাবদ্ধতা চাপাতে ডেভেলপারদের নিজেদের নলেজ বেসকে টেমপ্লেট করতে শুরু করতে হবে।

# Initializing the environment from the core template
# Replace with your own base template repo
git clone https://github.com/your-org/your-base my-new-project
cd my-new-project
pnpm install

# Enforcing strict boundaries before AI touches anything
pnpm turbo run typecheck lint

Claude-কে দিয়ে নতুন ফিচার বানাতে হলে তাকে আমার বিদ্যমান টেমপ্লেটের কঠোর সংজ্ঞার ভেতরে কাজ করতে হবে। এজেন্টের সিস্টেম প্রম্পটে আমি যে কনফিগারেশন ব্লক ঢোকাই এটা ঠিক সেটাই, যাতে সে বেপরোয়া হয়ে এমন অসংগতি না ঢোকায় যা সবকিছু ভেঙে দেয়।

// Conceptual representation - actual rules live in your workspace system prompt / .cursorrules
// packages/config/base-agent-rules.ts
export const AgentConstraints = {
  allowAny: false,
  styling: "Tailwind v4 utility classes exclusively",
  state: "No local state for global data - use centralized store",
  components: "Astro islands for interactivity only",
  imports: "Use alias @repo/ui, never relative paths",
  knowledge: "Always refer to /knowledge/routing-rules.md before creating new endpoints"
} as const;

এতে নিশ্চিত হয় যে AI আন্দাজ করছে না স্টেট কীভাবে গঠিত। সে সীমাবদ্ধতাগুলো পড়ে, কোনো নির্দিষ্ট বিষয়ে গভীরতর কনটেক্সটের জন্য লক্ষ্যভেদী নলেজ বেসের সঙ্গে মিলিয়ে দেখে, আর পরিবর্তনটি অস্ত্রোপচারের মতো নিখুঁতভাবে করে।

আপনার নিয়মগুলো ধারাবাহিকভাবে একটি নিবেদিত নলেজ বেসের দিকে নির্দেশ করলে দুটি অত্যন্ত গুরুত্বপূর্ণ কাজ হয়: এজেন্ট একান্তভাবে বর্তমান কাজে অতি-মনোযোগী হয়, এবং আপনার মডেলের কনটেক্সট সীমা বেঁচে যায়, কারণ একটি মাত্র বাস্তবায়ন প্যাটার্ন বুঝতে এজেন্ট পুরো কোডবেসকে মেমরিতে টেনে আনে না।

এই শৃঙ্খলা উপেক্ষা করার ক্ষতি একেবারে হাড়ে হাড়ে টের পাওয়া যায়। হ্যালুসিনেট করা কম্পোনেন্ট আর সীমাবদ্ধ কম্পোনেন্টের মধ্যে সুনির্দিষ্ট পার্থক্য এই:

// What AI hallucinates without constraints:
import { Button } from '../../components/ui/Button'  
import { Card } from '../../../shared/Card'
import { theme } from './localTheme'  // invented, doesn't exist

// What AI generates with a constrained template:
import { Button, Card } from '@repo/ui'
import { tokens } from '@repo/config/tokens'

ওই একটি ডিফ কোনো ব্যাখ্যার এক শব্দ ছাড়াই পুরো যুক্তিটা জানিয়ে দেয়।

কাঠামোগত বয়লারপ্লেটের বাইরে, রিপোজিটরির মূলে “চলতে চলতে নথি করো” ওয়ার্কফ্লো, সিদ্ধান্ত-লগ আর ইস্যু ট্র্যাকার চালু করলে প্রচুর সাহায্য হয়। এজেন্ট কাজ করার আগে যা যাচাই করে এমন একটি জীবন্ত, পাঠযোগ্য কনটেক্সট বানিয়ে আপনি AI-কে একই সমস্যা দুবার সমাধানের চেষ্টায় চক্কর খাওয়া থেকে সক্রিয়ভাবে ঠেকান। আপনি আসলে আপনার ফাইল সিস্টেমের মধ্যেই নিজস্ব স্থানীয় MCP (Model Context Protocol) সার্ভার তৈরি করছেন। একটি সুস্থ রেপোর জন্য কঠোর ফাইল সংগঠন, এজেন্টের নিয়মে সরাসরি ঢোকানো কনটেক্সট, এবং সঙ্গে একটি শক্ত README, অপরিহার্য।

যেমন, এজেন্ট কোথায় লজিক রাউট করবে তা স্পষ্টভাবে মানচিত্রে ফেললে আর্কিটেকচারাল সম্মতির নিশ্চয়তা মেলে:

# Agent Prompt: Organization Enforcement
"Generate the new 'Analytics' feature. Follow the established file organization:
- Place all UI components strictly in `packages/ui/src/analytics/`
- Place all business state logic in `packages/core/stores/analytics.ts`
- Do NOT generate local component state. Review the `/knowledge/routing-rules.md` file first and automatically enforce these routing rules."

একটি জটিল প্রজেক্টের জন্য অ্যাপ্লিকেশন কোডের একটি লাইন লেখার আগে আমার মানক ওয়ার্কফ্লো হলো বিষয়টি নিয়ে একটি গভীর গবেষণা-নিবন্ধ চালু করা। আমি সেই আর্কিটেকচারাল গবেষণা সংশ্লেষণ করি, তারপর আমার প্রম্পট কৌশলের রূপরেখা আঁকতে শুরু করি, সেই গবেষণার ফলাফল একটি বিচ্ছিন্ন আর্টিফ্যাক্ট ফোল্ডারে Markdown ফাইল হিসেবে সংরক্ষণ করে। স্পষ্ট আর্টিফ্যাক্টের উল্লেখসহ সুপরিকল্পিত, ভারী গবেষণানির্ভর প্রম্পট কৌশল, জিরো-শটের ব্যর্থতার প্রতিক্রিয়া দেখিয়ে সেগুলো ঠিক করতে চক্কর খাওয়ার চেয়ে অসীমভাবে ভালো।

তা ছাড়া, এভাবে বানালে বিপুল খরচ-নিয়ন্ত্রণ মেলে। আপনার ইতিমধ্যে মাল্টি-প্রোভাইডার সেটআপ থাকলে এই কৌশল সবচেয়ে ভালো কাজ করে, যা অ্যাবস্ট্র্যাকশন লেয়ারের কল্যাণে সহজ হয়ে যায়। আপনার ব্লুপ্রিন্ট ও কাঠামোগত সংশ্লেষণ উপলব্ধ সবচেয়ে সক্ষম ফ্রন্টিয়ার মডেল দিয়ে বানানো উচিত, যেমন Gemini Pro বা Claude Opus। কঠোর আর্কিটেকচারাল সীমানা ঠিক হয়ে গেলে, Flash-এর মতো দ্রুততর, সস্তা মডেলকে নথিবদ্ধ ব্লুপ্রিন্ট কার্যকর করতে দিন। স্থানীয় কোড জেনারেশন শেষ হলে, বেস টেমপ্লেটের বিপরীতে কঠোর সামঞ্জস্য নিশ্চিত করতে উচ্চতর স্তরের মডেলকে দিয়ে পুল রিকোয়েস্ট পর্যালোচনা করান। দীর্ঘমেয়াদে এতে বিপুল অর্থ বাঁচে।

সবশেষে, প্রতিটি নতুন ফিচারের জন্য এজেন্টকে সব সময় একটি টেস্ট স্যুট বানাতে বাধ্য করুন। নিশ্চিত করুন এর নির্দেশ ওয়ার্কস্পেসের নিয়মে বা README-তে স্পষ্টভাবে থাকে, যাতে প্রতিটি বড় প্রম্পট চক্রে পরীক্ষা বাধ্যতামূলক হয়, পরের ভাবনা না হয়ে।

# Agent Prompt: Test Suite Mandate
"Whenever you create or modify a component, you MUST simultaneously generate/update the exact corresponding `vitest` suite in the `packages/core/tests/` directory to cover the failure cases. Do not ask for permission, just include the test in the PR."

সমঝোতা

টানাপোড়েনটা পুরোপুরি টেমপ্লেট বানানোর অগ্রিম খরচ আর কাঁচা প্রম্পটিংয়ের প্রতারণাময় গতির মধ্যে। পুনর্ব্যবহারযোগ্য টেমপ্লেট রক্ষণাবেক্ষণে সপ্তাহান্তের এমন ঘণ্টা যায় যা আমি ফিচার বানাতে কাটাতে চাইতাম। তা ছাড়া, কোনো অন্তর্নিহিত ফ্রেমওয়ার্কের নতুন মেজর সংস্করণ এলে টেমপ্লেট মৌলিকভাবে ভেঙে যায়। তার ওপর ভিত্তি করে পরবর্তী প্রতিটি AI জেনারেশনে ভিত মেরামত না হওয়া পর্যন্ত ভারী হাতে নির্দেশনা দিতে হয়।

আরেকটি সমঝোতা আছে যা আমি সমাধান করিনি, আর আমি নিশ্চিত নই কেউ করেছে কি না। মেমরি এখনও দুর্বল বিন্দু। ভালো মেমরি লেয়ার, বিবেচনাসম্মত স্কিল সেটআপ এবং একসঙ্গে সমন্বয় করা কয়েকজন এজেন্ট থাকা সত্ত্বেও, একটি বড় প্রজেক্ট এখনও নিঃশব্দে এমন জিনিস ফেলে দেয় যা সেটি জানা একজন মানুষ কখনও ফেলত না। তাই আপনাকে নিজেকে পুনরাবৃত্তি করতে হয়। এই ওয়ার্কফ্লোর এই অংশটাই আমাকে সত্যিই বিরক্ত করে, আর যত টেমপ্লেটিংই করি এটা ঠিক হয় না।

আগামী দিনে

আমি কী ভুল ভেবেছিলাম সেটা বলা দরকার। আমি ভাবতাম AI কোড জেনারেশন নেহাত বাগপ্রবণ: সে না বুঝে আত্মবিশ্বাসে লেখে, আর কোনো কনটেক্সটই তাকে উদ্ধার করে না। যে মডেলগুলোর ওপর আমি মত গড়েছিলাম তাদের জন্য সেটা ন্যায্য পাঠ ছিল। বর্তমান মডেলগুলোর জন্য সেটা ন্যায্য পাঠ নয়। তারা অনেক দূর এগিয়েছে, আর আমি যতটা অনুমোদন করতাম তার চেয়ে অনেক বেশি তাদের ওপর ভরসা করা যায়, কিন্তু কঠোরভাবে ততটাই যতটা কনটেক্সট আপনি তাদের হাতে তুলে দেন, আর এই লেখার পুরো যুক্তিই সেটা।

আমরা কোডের জন্য মডেলকে প্রম্পট করা থেকে সরে এসে আর্কিটেকচারাল সম্মতির জন্য মডেলকে প্রম্পট করার দিকে যাচ্ছি। ব্যক্তিগত টেমপ্লেটের মধ্যে AI-কে সীমাবদ্ধ করা তাকে নির্ভরযোগ্য ইঞ্জিনিয়ারিং সঙ্গী হিসেবে গণ্য করার পূর্বশর্ত, ধীরে ধীরে আপনার প্রোডাকশন কোডবেস ধ্বংস করা কোনো বিশৃঙ্খল সত্তা হিসেবে নয়।