ব্লগে ফিরে যান
৩ এপ্রিল, ২০২৬Sergei Solod8 মিনিট পড়া

আমি কীভাবে Codex দিয়ে ১৫টি প্রজেক্ট রিভিউ করি, কিন্তু চূড়ান্ত নিয়ন্ত্রণ নিজের হাতে রাখি

১৫টি সফটওয়্যার প্রজেক্ট রিভিউ করা আগে মানে ছিল অসংখ্য পুনরাবৃত্তিমূলক চেকের মধ্যে ডুবে যাওয়া। Codex bug, test, SEO, translation, localization আর consistency অনেক দ্রুত পরীক্ষা করতে সাহায্য করে, কিন্তু আমি প্রতিটি AI finding-কে verdict নয়, lead হিসেবে দেখি এবং প্রতিটি পরিবর্তন নিজে verify করি।

CodexAI codingCode reviewSoftware testingDeveloper workflowLocalizationTechnical SEODeveloper productivity

কয়েক বছর আগে ১৫টি সফটওয়্যার প্রজেক্ট একই সময়ে সত্যিকারের গভীরভাবে review করার কথা আমার কাছে অবাস্তব লাগত। আমি ১৫টি repository খুলে একটু দেখে নেওয়ার কথা বলছি না। আমি real project বারবার bug, ভুল assumption, SEO issue, translation mistake, localization inconsistency, missing test, regression এবং system-এর বাকি অংশের সঙ্গে আর না মেলা পুরোনো code-এর জন্য পরীক্ষা করার কথা বলছি।

সীমাবদ্ধতা typing speed ছিল না। ছিল attention। প্রতিটি project-এর নিজস্ব history, convention, edge case এবং এমন code থাকে যা ভুল মনে হলেও ইচ্ছাকৃতভাবে রাখা হয়েছে। Careful review মানে পড়া, search, compare, check চালানো এবং তারপর সিদ্ধান্ত নেওয়া—আসলে কী বদলানো উচিত।

Codex এই repetitive work-এর cost আমার জন্য বদলে দিয়েছে। এটি repository-তে first pass করতে পারে, reference follow করতে পারে, related file inspect করতে পারে, suspicious pattern surface করতে পারে, test suggest করতে পারে এবং এমন area investigate করতে সাহায্য করতে পারে যা আগে আমাকে একটি একটি করে খুলতে হতো। Final decision automatic হয় না। Decision-এর আগের expensive অংশ দ্রুত হয়।

আমার সবচেয়ে গুরুত্বপূর্ণ rule সহজ: আমি Codex ব্যবহার করি না নিজেকে review loop থেকে সরাতে; আমি ব্যবহার করি review loop-এর reach বাড়াতে।

আসল bottleneck coding নয়, repetition

একটি project maintain করলে অনেক context মনে রাখা যায়। অনেক project হলে সেটা scale করে না। একই ধরনের কাজ বারবার আসে:

  • ভিন্ন component-এ similar bug খোঁজা;
  • refactor-এর পর পুরোনো call site রয়ে গেছে কি না দেখা;
  • behavior change-এর পর test review করা;
  • metadata, language logic, heading বা internal link inconsistency খোঁজা;
  • localization key এবং translated content compare করা;
  • missing error handling আর edge case খোঁজা;
  • “small” change প্রত্যাশার চেয়ে বেশি file touch করেছে কি না দেখা;
  • আলাদা আলাদা simple কিন্তু মোটে অনেক সময় নেওয়া diff পড়া।

এসব glamorous নয়। কিন্তু সব গুরুত্বপূর্ণ। একই review বহু codebase-এ repeat হলে cost খুব বড় হয়।

এখানেই AI coding agent আমার জন্য সবচেয়ে useful। এটি search space-এর repetitive অংশ নেয়, যাতে আমার attention judgment-এর জন্য থাকে।

আমি inspection দিয়ে শুরু করি, সব rewrite করার permission দিয়ে নয়

Bad result পাওয়ার সহজ উপায় হলো “পুরো project review করে সব fix করো” বলা। Efficient শোনালেও discovery, prioritization, architecture, implementation এবং validation এক uncontrolled task-এ মিশে যায়।

Stage আলাদা করলে result অনেক ভালো হয়।

inspect → explain findings → prioritize → change → validate → review diff

প্রথমে চাই agent relevant area বুঝুক এবং কী পেয়েছে ব্যাখ্যা করুক। Concrete file path, affected code, কেন suspicious, possible impact—এসব চাই। Change পরে।

এটা জরুরি কারণ AI খুব confidence-এর সঙ্গে ভুল হতে পারে। Redundant মনে হওয়া code পুরোনো browser, payment edge case, migration path বা এমন business rule-এর জন্য থাকতে পারে যা একটি file থেকে বোঝা যায় না। Inspection ভুল assumption-কে giant diff হওয়ার আগে থামায়।

Finding-কে verdict নয়, lead হিসেবে দেখি

Good Codex review “১৭টি সমস্যা পেলাম” বলে শেষ হওয়া উচিত নয়। Number নিজে প্রায় অর্থহীন। Evidence দরকার।

Actionable finding হলে জানতে চাই:

  • problem কোথায়;
  • কেন problem;
  • কোন behavior fail করতে পারে;
  • conclusion-এ কত confidence রাখা উচিত;
  • কোন check confirm বা reject করতে পারে;
  • smallest safe fix কী।

Security, SEO এবং business logic-এ এটা বিশেষ জরুরি। Agent investigation-এর মতো জায়গা দেখাতে পারে, কিন্তু security-এর মতো শোনা explanation confirmed vulnerability নয়। SEO warning automatic ranking problem নয়। Strange condition automatic dead code নয়।

AI candidate খোঁজার cost কমায়। Verification ঠিক করে কোনটা real।

Validation loop workflow-কে trustworthy করে

Code generation AI-assisted development-এর visible অংশ, কিন্তু production usefulness আসে validation থেকে।

Change-এর পর codebase-এর response দরকার। Project অনুযায়ী থাকতে পারে:

  • TypeScript বা অন্য compiler/type checker;
  • lint;
  • unit এবং integration tests;
  • build check;
  • পুরোনো name বা call site-এর targeted search;
  • final diff manual review;
  • user-facing behavior manual verify করা।

Exact command-এর চেয়ে loop বেশি গুরুত্বপূর্ণ। Agent assumption করে, repository evidence দেয়, next decision evidence-এর ওপর হয়।

এই কারণেই AI-assisted work-এ strongly typed project আমার পছন্দ। আলাদা article-এ কেন TypeScript real software delivery-তে Codex-এর সঙ্গে ভালো কাজ করে লিখেছি: type অনেক wrong assumption-কে সঙ্গে সঙ্গে machine-readable feedback-এ বদলে দেয়।

কিছু review category AI-এর জন্য বিশেষ ভালো

Bug এবং regression

Agent file জুড়ে value follow করতে পারে, caller inspect করতে পারে, similar implementation compare করতে পারে এবং inconsistent branch খুঁজতে পারে। Symptom-এর source narrow করতে সাহায্য করে। Conclusion নেওয়ার আগে behavior reproduce বা verify করি।

Test

Behavior change হয়েছে কিন্তু matching test coverage নেই—এমন জায়গা খুঁজতে, edge case suggest করতে এবং existing test আসলে কী protect করে ব্যাখ্যা করতে AI useful। শুধু implementation detail test করা test-ও surface করতে পারে।

SEO

Technical SEO-তে consistency work অনেক: metadata, language alternate, indexability, internal link, template, sitemap generation, redirect এবং page-level convention। Agent বড় codebase-এ rules compare করতে পারে আমি manually প্রতিটি route খোলার চেয়ে দ্রুত। কিন্তু technical correctness এবং content সত্যিই rank করার মতো কি না—দুটি আলাদা প্রশ্ন।

Localization এবং translation

Multilingual product-এ সবচেয়ে repetitive areaগুলোর একটি। AI key compare, missing value find, wrong language detect, placeholder check এবং locale structure drift highlight করতে পারে। বড় translation object manually scan করার চেয়ে দ্রুত, যদিও important copy human judgment চায়।

Refactoring-এর পর consistency

Large refactor boring কারণে fail করে: old import রয়ে যায়, একটি route old field name ব্যবহার করে, একটি test fixture পুরোনো shape রাখে। Repository-wide search আর change intent বোঝা agent এখানে খুব useful।

Parallel work শুধু independent task হলে সাহায্য করে

অনেক agent চালিয়ে সবাইকে একই সঙ্গে change করতে দেওয়া tempting। Throughput বাড়তে পারে, কিন্তু conflict এবং inconsistent assumption-ও multiply হতে পারে।

Parallelism-কে coordination problem হিসেবে দেখি। Independent audit ভালো candidate: একটি project localization check হতে পারে, অন্যটি tests review হতে পারে, আলাদা repository একসঙ্গে inspect হতে পারে। Shared plan ছাড়া একই architecture দুই agent rewrite করা অন্য ব্যাপার।

Parallelism যত বাড়ে, boundary তত important: clear project, clear task, clear definition of done এবং separately reviewable result.

Goal maximum agent চালানো নয়। Goal useful, verifiable progress maximize করা।

যা blindly delegate করি না

  • Architecture decision: model option দিতে পারে, কিন্তু long-term trade-off repo-এর বাইরে context-এর ওপর depend করতে পারে।
  • Security conclusion: finding verification, threat context এবং প্রায়ই specialized tool চায়।
  • Business rule: code internally consistent হলেও wrong product behavior implement করতে পারে।
  • Large destructive refactor: huge diff বোঝা কঠিন এবং careless approve করা সহজ।
  • Production deployment: passing test operational risk সরায় না।
  • Final review: নিজের নাম দেওয়ার আগে কী বদলেছে জানতে চাই।

AI এসব area-এ useless বলে নয়, plausible wrong answer এখানে খুব expensive হতে পারে বলে।

AI review static analysis replace করে না

Codex-কে compiler, linter, test, scanner বা monitoring-এর replacement দেখি না। এগুলোর advantage আছে যা AI-এর নেই: narrow, deterministic, repeatable.

Strong workflow সব combine করে। Codex context reason করে কোথায় দেখতে হবে বলে। Static tool precise rule enforce করে। Test behavior verify করে। Log এবং monitoring reality দেখায়। Human review সব signal product intent-এর সঙ্গে connect করে।

Feedback system ছাড়া AI-কে বেশি নয়, কম trust করব।

সবচেয়ে বড় productivity gain হলো attention ভালোভাবে allocate করা

“Codex time save করে” বলা সহজ, কিন্তু আমার জন্য change-এর আসল অর্থ আরও বড়।

Software development-এ scarce resource keystroke নয়, high-quality attention। AI coding agent-এর আগে অনেক attention repetitive discovery-তে যেত: একই pattern search, similar file পড়া, reference follow, change সব জায়গায় গেছে কি না check, অন্য repository-তে একই audit repeat।

এখন first-pass work বেশি delegate করে attention রাখি difficult decision-এর জন্য: finding important? fix architecture-এ fit? UX improve? risk acceptable? আমি সত্যিই এটা ship করতে চাই?

তাই বহু project maintain এবং review করা এখন আলাদা লাগে। কম review করি না। অনেক ক্ষেত্রে বেশি করতে পারি কারণ mechanical part পুরো budget খায় না।

যে workflow আমি trust করি

  1. Narrow review goal define করা. Bug, test, SEO, localization, refactor বা specific concern.
  2. Edit-এর আগে agent inspect করবে. Evidence এবং affected location আগে চাই.
  3. Finding prioritize করা. সব theoretical issue change deserve করে না.
  4. Change bounded রাখা. Small coherent diff validate সহজ.
  5. Machine check চালানো. Typecheck, lint, test, build, search বা project-specific validation.
  6. Diff manually পড়া. Unnecessary rewrite, wrong assumption, missing edge case এবং scope-এর বাইরে change খোঁজা.
  7. Important behavior verify করা. বিশেষ করে users, money, security, SEO এবং production infrastructure.
  8. তারপর next project. Parallelism useful, কিন্তু unresolved uncertainty ছড়ানো উচিত নয়.

১৫টি project আর ১৫ গুণ review work মনে হয় না

Codex ১৫ project simple করেনি এবং responsibility সরায়নি। Scale এবং repetitive effort-এর relationship বদলেছে।

Deeper first pass, broader consistency check, বেশি test idea এবং systematic audit করতে পারি, নিজে প্রতিটি file-এ প্রতিটি minute search না করেও। Saved attention developer দরকার এমন decision-এ ব্যবহার করি।

এই AI-assisted development আমার কাছে valuable: autopilot নয়, blind trust নয়, “কিছু pass হওয়া পর্যন্ত code generate” নয়। Machine-scale inspection আর human-scale judgment-এর tighter loop.

আমার জন্য Codex-এর real leverage এটাই। Review remove করে না। Serious review এমন scale-এ possible করে যা আগে maintain করা অনেক কঠিন ছিল।