আগে আমি ইচ্ছাকৃতভাবে একটু provocative করে বলতাম: Codex-এর জন্য TypeScript সেরা language। এখন আমি আরও নির্ভুলভাবে বলব। আমি যে ধরনের production frontend ও full-stack development করি, সেখানে TypeScript এমন environment যেখানে Codex-কে control, verify এবং যুক্তিসঙ্গতভাবে trust করা সবচেয়ে সহজ।
এখানে মূল শব্দ “TypeScript” নয়, control। AI coding agent খুব বিশ্বাসযোগ্য দেখায় এমন code লিখতে পারে। Production engineering-এ আরও বেশি দরকার: existing contract মানা, behavior অক্ষুণ্ণ রাখা, refactor সহ্য করা এবং assumption ভুল হলে দ্রুত fail করা। Plain JavaScript-এর তুলনায় TypeScript এই constraint-এর অনেক বেশি অংশকে machine-readable করে তোলে।
Codex আসলে codebase থেকে কী চায়
ভালো prompt কাজে লাগে, কিন্তু context-এর একমাত্র উৎস নয়। Codebase নিজেই task বোঝাতে পারে, আবার model-কে guess করতেও বাধ্য করতে পারে। বাস্তবে সবচেয়ে শক্তিশালী environment হলো যেখানে গুরুত্বপূর্ণ assumption স্পষ্ট এবং automatically checked।
- Function signature valid input ও output নির্ধারণ করে।
- Interface ও type domain object-এর shape স্পষ্ট করে।
- Union ও enum valid state সীমিত করে।
- Compiler edit-এর পর অনেক ভুল assumption-কে concrete error-এ পরিণত করে।
Contract ভাঙলেই codebase যদি প্রতিক্রিয়া জানায়, তাহলে AI agent-এর পুরো application নিখুঁতভাবে বোঝা দরকার নেই। Feedback loop যত ছোট, confident guessing-এর জায়গা তত কম।
Type শুধু documentation নয়, executable context
ভালো TypeScript মানুষের কাছে design intent বোঝায়। Automated workflow-এ এর বাড়তি সুবিধা হলো, সেই documentation machine দিয়ে verify করা যায়। যেমন:
type PaymentResult =
| { ok: true; receiptId: string }
| { ok: false; code: "declined" | "timeout" };
function getReceiptId(result: PaymentResult) {
if (result.ok) return result.receiptId;
return result.receiptId;
// TypeScript: Property 'receiptId' does not exist
// on the failure branch.
}JavaScript-এ একই ভুল branch runtime-এ না চলা পর্যন্ত reasonable মনে হতে পারে। TypeScript merge-এর আগেই assumption reject করতে পারে। Codex-এর কাছে compiler error শুধু editor-এর লাল দাগ নয়, model কোথায় ভুল বুঝেছে তার স্পষ্ট signal।
তাই আমি Record<string, any>-এর মতো broad structure-এর বদলে explicit domain type পছন্দ করি। Type reality যত ভালো describe করে, codebase developer ও AI—দুজনের জন্যই তত ভালো context হয়।
Compiler ভুলকে feedback loop-এ বদলে দেয়
“Codex-কে code লিখতে বলো এবং প্রথম answer গ্রহণ করো”—এই workflow আমি বিশ্বাস করি না। Reliable process iterative:
task → inspect → edit → typecheck → lint → test → review diffএটা boring sequence, আর সেটাই এর শক্তি। প্রতিটি meaningful change-এর পর environment response দেয়। Type error broken contract ধরবে, lint অন্য problem ধরবে, test এমন behavior যাচাই করবে যা type বলতে পারে না, আর final diff human review পাবে।
Smart prompt প্রথম attempt উন্নত করতে পারে। Strong verification loop প্রতিটি attempt উন্নত করে। Production-এ সেটাই বেশি গুরুত্বপূর্ণ।
বড় refactor-এ TypeScript-এর মূল্য সবচেয়ে বেশি
Small isolated edit প্রায় সব coding assistant-এর জন্য সহজ। কঠিন হলো এমন change যা কয়েক ডজন file-এ ছড়ায়: domain field rename, API response বদলানো, component props কঠোর করা, union split করা বা পুরোনো abstraction replace করা।
TypeScript-এ breaking change affected assumption-এর map তৈরি করে। Compiler দেখায় পুরোনো contract কোথায় এখনও ব্যবহার হচ্ছে। Codex সেই list ধরে কাজ করতে পারে এবং প্রতিটি pass-এর পরে আবার validation চালানো যায়। এতে refactor automaticভাবে correct হয় না, কিন্তু blast radius দৃশ্যমান হয়।
TypeScript কোথায় সাহায্য করতে পারে না
TypeScript guardrail, correctness proof নয়।
- ভুল business logic: perfectly typed code-ও ভুল result দিতে পারে।
- Runtime data: API, database, form বা third-party service compile-time assumption-এর বাইরে data দিতে পারে।
- Missing product context: compiler জানে না কোনো flow কেন আছে বা কোন edge case user-এর জন্য গুরুত্বপূর্ণ।
- Security ও architecture: valid type সঠিক authorization, caching, database boundary বা infrastructure guarantee করে না।
তাই runtime validation, tests, logging, observability ও review এখনও দরকার। Clean typecheck মানেই correct feature নয়।
AI-assisted change-এ আমার workflow
- Goal narrow রাখি। কী বদলাবে, কী বদলাবে না, acceptance criteria কী।
- Edit-এর আগে Codex-কে inspect করতে দিই। Existing type, call site, test ও neighboring module long prompt-এর চেয়ে বেশি useful হতে পারে।
- Smallest coherent change বেছে নিই। Focused diff unrelated rewrite-এর চেয়ে সহজ verify করা যায়।
- সঙ্গে সঙ্গে typecheck ও lint চালাই। Structural error change ছোট থাকতেই দেখা উচিত।
- Relevant test চালাই এবং behavior বদলালে test যোগ করি। Type contract validate করে; test behavior।
- Final diff নিজে review করি। Naming, architecture, duplication, edge case এবং original problem আসলেই solve হয়েছে কিনা।
কখন JavaScript যথেষ্ট
এটা JavaScript খারাপ—এমন কথা নয়। Small script, disposable prototype, simple automation বা কম shared state-এর code-এ TypeScript-এর অতিরিক্ত structure খুব বেশি value নাও দিতে পারে। Strong tests ও clear convention-সহ JavaScript project-ও AI-এর জন্য ভালো environment হতে পারে।
আমার claim আরও নির্দিষ্ট: codebase যত বড়, long-lived ও collaborative হয়, machine-checkable constraint-এর value তত বাড়ে। এবং ঠিক তখনই AI mistake-এর খরচও বাড়ে।
Codex-এর সঙ্গে TypeScript পছন্দ করার আসল কারণ
TypeScript Codex-কে smarter করে না। এটি environment-কে bad assumption-এর প্রতি কম tolerant করে।
Production-এ আমার শুধু creative agent দরকার নেই; এমন system-এর ভিতরের agent দরকার যা ভুল হলেই feedback দেয়। Type, compiler error, lint, test ও human review মিলেই সেই system তৈরি করে।
তাই TypeScript + Codex নিয়ে আমার বক্তব্য language fandom নয়। এটি fast, machine-checkable feedback-এর কথা: কম ambiguity, ছোট blast radius, safer refactor এবং verification সত্যিই করলে আরও reliable engineering speed।