තවත් භාෂාවලින්: English · தமிழ்
02. මෘදුකාංග ඉංජිනේරු විද්‍යාවේ නව පරිණාමය: Product Engineer යුගය
ප්‍රකාශිත 2026-09-14
ප්‍රධාන තේමාව: "මෘදුකාංග ඉංජිනේරු ක්ෂේත්‍රය තුළ හුදෙක් සින්ටැක්ස් (Syntax) ලියන 'සාමාන්‍ය කෝඩර්වරුන්ගේ' යුගය අවසන් වෙමින් පවතී. AI මගින් තත්පර කිහිපයකින් කේත ලියන යුගයක, සැබෑ මෘදුකාංග ඉංජිනේරුවෙකුගේ වටිනාකම මනිනු ලබන්නේ ලියන ලද කේත පේළි ගණනින් නොවේ. පාරිභෝගිකයාගේ සැබෑ වේදනාව හඳුනාගෙන, මූලධර්මවාදීව (First Principles) පද්ධති නිර්මාණ සැලැස්ම සැලසුම් කර, ඉංජිනේරු විශිෂ්ටත්වයේ දැඩි දොරටු 14 (14 Hard Gates) හරහා සම්පූර්ණ නිෂ්පාදනයක් නිම කළ හැකි Product Engineer කෙනෙකු බවට පත්වීමෙනි."
කේතකරණ සින්ටැක්ස් තවදුරටත් ප්‍රමුඛ කුසලතාවක් නොවන්නේ ඇයි?
දශක දෙකක් පුරා තොරතුරු තාක්ෂණ ක්ෂේත්‍රයේ සාර්ථකත්වය මනිනු ලැබුවේ ක්‍රමලේඛන භාෂාවක ව්‍යාකරණ කටපාඩම් කරගැනීම, LeetCode ප්‍රහේලිකා විසඳීම, සහ Jira ටිකට් පතක සඳහන් වූ දේ එලෙසම කේතගත කර එය "Resolved" ලෙස ලකුණු කිරීම මතය. මෙවැනි මට්ටමක සේවය කළ සේවකයන් හඳුන්වනු ලැබුවේ හුදෙක් කේත ටයිප් කරන්නන් (Code Monkeys) ලෙසයි.
2026 වන විට එම සාම්ප්‍රදායික ආකෘතිය සම්පූර්ණයෙන්ම කණපිට පෙරළී ඇත; ඊට හේතුව කුමක්දැයි වටහා ගැනීම අත්‍යවශ්‍ය වේ.
රූපය: The Demise of Syntax & The Rise of the System — ඉඩසර ඇකඩමිය (Idasara Academy)
මීට වඩාත්ම සමාන ඓතිහාසික නිදසුන වන්නේ ගණක යන්ත්‍රයේ (Calculator) පැමිණීමයි. ගණක යන්ත්‍රය පැමිණි විට ගණිතඥයන්ට රැකියා අහිමි වූයේ නැත; අහිමි වූයේ අතින් ගණිතමය ගණනය කිරීම් සිදුකළ "Human Computers" ලාට පමණි. ගණිතඥයා වඩාත් ඉහළ මට්ටමේ සංකීර්ණ ගැටලු විසඳීමට නිදහස් වූ අතර, ගණිත වෘත්තියේ වටිනාකම තවත් ඉහළ ගියේය.
අභාවයට යමින් පවතින්නේ කටපාඩම් කළ සින්ටැක්ස්, නැවත නැවත ලියන boilerplate කේත, Stack Overflow එකෙන් කොපි කිරීම, සහ LeetCode රටා කටපාඩම් කිරීමයි. AI විසින් ඒ සියල්ල මිනිසෙකුට වඩා අඩු දෝෂ සහිතව තත්පර කිහිපයකින් නිම කරනු ලබයි.
ඉහළ නගිමින් පවතින්නේ සැබෑ ගැටලුව නිවැරදිව හඳුනා ගැනීම (Problem Framing), පද්ධති සීමා නිර්ණය කිරීම (System Boundaries), දත්ත ආකෘති නිර්මාණය (Data Modelling), තත්ත්ව දොරටු බලාත්මක කිරීම (Quality Gates), සහ ව්‍යාපාරික වටිනාකම මැන බැලීමයි. මේවායින් කිසිවක් හුදු කේත ලිවීමේ කුසලතා නොවේ. ඒවා පද්ධතිමය චින්තනයයි (Systems Thinking) — එමෙන්ම මීට පෙර සින්ටැක්ස් සඳහා ඉහළ වැටුප් ගෙවූ නිසා මෙතෙක් නිසි ලෙස නොඉගැන්වූ මූලික කුසලතා වන්නේද ඒවාමය.
රූපය: The Pure Coder vs. The Product Engineer — ඉඩසර ඇකඩමිය (Idasara Academy)
| මානය | හුදු කෝඩර්වරයා (The Pure Coder) | නිෂ්පාදන ඉංජිනේරුවා (The Product Engineer) |
|---|---|---|
| ආරම්භක ලක්ෂ්‍යය | "මගේ Jira ටිකට් එකේ කියන්නේ මොකක්ද?" | "පාරිභෝගිකයාගේ සැබෑ වේදනාව කුමක්ද? (Why)" |
| සාර්ථකත්වයේ මිම්ම | කේතය compile වීම සහ ටිකට් පත Resolved වීම | පාරිභෝගිකයා ගැටලුවෙන් නිදහස් වී දිනපතා භාණ්ඩය භාවිත කිරීම |
| AI සමග සම්බන්ධය | කේත ලිවීමෙන් AI සමග තරඟ වැදී පරාජය වීම | AI නියෝජිතයන් (Agents) මෙහෙයවන ප්‍රධාන නිර්මාණ ශිල්පියා වීම |
| වගකීමේ සීමාව | "මගේ කොටස වැඩ කරනවා" | සැලසුම → නිමැවුම → මෙහෙයුම් (End-to-End Ownership) |
| වෙළඳපොළ වටිනාකම | ශීඝ්‍රයෙන් ශුන්‍යය කරා ගමන් කරයි | මෙතෙක් පැවති ඉහළම තලයට ළඟා වේ |
ඉහත වගුවේ තෙවන පේළිය මෙනෙහි කරන්න. කේත ලිවීමෙන් AI සමග තරඟ වදින කෝඩර්වරයා නිරත වන්නේ ජයගත නොහැකි මෙන්ම අනවශ්‍ය තරඟයකය. නමුත් Product Engineer වරයා එම AI නියෝජිතයන්ව මෙහෙයවයි. එහි තේරුම නම් ප්‍රබල කේතකරණ AI බිහිවීම හුදු කෝඩර්වරයාව විනාශ කරන අතරතුර Product Engineer වරයාගේ ශක්තිය තවත් තහවුරු කරන බවයි.
Product Engineer කෙනෙකුගේ කාර්ය රාමුව ප්‍රධාන පියවර තුනකින් සමන්විතය. සැලසුම (Design): ගැටලුව, දත්ත සහ පද්ධති සීමා නිර්වචනය කිරීම. නිමැවුම (Realise): AI නියෝජිතයන් මෙහෙයවමින් සැබෑ ක්‍රියාකාරී පද්ධතියක් ගොඩනැගීම. මෙහෙයුම් (Operationalise): සැබෑ පරිශීලකයන් අතට පත් කර, නිරීක්ෂණය කරමින් අඛණ්ඩව වැඩිදියුණු කිරීම.
කේත පේළියක් යනු එම සමස්ත ගමනේ එක් කුඩා අංශුවක් පමණි; හුදෙක් කේත පේළි පමණක් ලියූ සේවකයෙකු ලෙහෙසියෙන්ම ආදේශ කළ හැකි වූයේ එබැවිනි.
මූලධර්මවාදී චින්තනය: ගැටලුවේ ගැඹුරු "හේතුව" ප්‍රශ්න කරන්නේ කෙසේද?
Product Engineer කෙනෙකු සතු ප්‍රමුඛතම පුරුද්ද වන්නේ තමන් වෙත ලැබෙන අවශ්‍යතාවක් එලෙසම පිළිගැනීම ප්‍රතික්ෂේප කිරීමයි. අන් අය කළ දේ අනුකරණය කරනවා වෙනුවට, ගැටලුව එහි මූලික තර්කන පදනම (First Principles) දක්වා විසුරුවා හැරිය යුතුය.
රූපය: First Principles Thinking — ගැටලුවේ "Why" සහ "How" ගැඹුරින් ප්‍රශ්න කිරීම — ඉඩසර ඇකඩමිය (Idasara Academy)
"ඇයි" යන්න පස් වතාවක් ප්‍රශ්න කිරීම (The 5 Whys)
ව්‍යාපාරික පාර්ශ්වයෙන් මෙබඳු ඉල්ලීමක් පැමිණේ: "අපේ මොබයිල් ඇප් එකට Push Notifications දාන්න ඕනෙ."
සාමාන්‍ය කෝඩර්වරයා වහාම Firebase ලේඛන විවෘත කරයි. නමුත් Product Engineer වරයා ප්‍රථමයෙන් තර්කන වෘක්ෂය දිගහරියි.
අපට Push Notifications අවශ්‍ය වන්නේ ඇයි? පරිශීලකයන් නැවත ඇප් එක වෙත නොපැමිණෙන නිසාය. ඔවුන් නොපැමිණෙන්නේ ඇයි? ඔවුන් දත්ත පරීක්ෂා කරන්නේ මසකට වරක් පමණක් වන නිසාය. මසකට වරක් පමණක් බලන්නේ ඇයි? වාර්තා යාවත්කාලීන වන්නේ මාසිකව බැවිනි. වාර්තා මාසිකව යාවත්කාලීන වන්නේ ඇයි? දත්ත අතින් ඇතුළත් (Manual Upload) කරන නිසාය.
මෙහි සැබෑ ගැටලුව වූයේ නොටිෆිකේෂන් හිඟකම නොවේ. දත්ත නල පද්ධතියේ (Data Pipeline) ස්වයංක්‍රීයකරණයක් නොමැතිකමයි.
එහි ප්‍රතිඵලය විමසා බලන්න. සති දෙකක් ගත කර Push Notifications ව්‍යාපෘතියක් නිම කර තිබුණේ නම්, එය ඉල්ලූ ආකාරයටම වැඩ කළද පරිශීලක හැසිරීම කිසිසේත් වෙනස් නොවනු ඇත — මන්ද මාසයක් පැරණි දත්ත පිළිබඳ නොටිෆිකේෂන් ආ පමණින් කිසිවෙකු ඇප් එක විවෘත නොකරන බැවිනි. නමුත් දින තුනකින් දත්ත නල පද්ධතිය ස්වයංක්‍රීය කිරීමෙන් සැබෑ ගැටලුව සම්පූර්ණයෙන්ම විසඳේ.
සාමාන්‍ය කෝඩර්වරයෙකු සහ සැබෑ ඉංජිනේරුවෙකු අතර වැටුප් පරතරයට හේතුව මෙයයි: එක් අයෙකු ඉල්ලූ දේ තනන අතර, අනෙක් තැනැත්තා සැබෑ අවශ්‍යතාව සොයාගෙන එය නිර්මාණය කරයි. මෙම ප්‍රශ්න පහ විමසීමට මිනිත්තු දහයකට වඩා ගත නොවන අතර, කිසිදු තාක්ෂණික මෙවලමක් අවශ්‍ය නොවේ; අවශ්‍ය වන්නේ වැඩ ඇරඹීමට පෙර ප්‍රශ්න කිරීමේ අධිෂ්ඨානය පමණි.
ඉංජිනේරු විශිෂ්ටත්වයේ දැඩි දොරටු 14 (The 14 Hard Gates) මොනවාද?
රූපය: Engineering Excellence — The 14 Hard Gates — ඉඩසර ඇකඩමිය (Idasara Academy)
ආදර්ශනයකදී (Demo) පමණක් ක්‍රියාත්මක වන මෘදුකාංග සහ සැබෑ ලෝකයේ ජීවත්වන මෘදුකාංග අතර වෙනස සනිටුහන් කරන්නේ මෙම බිඳ දැමිය නොහැකි ඉංජිනේරු ප්‍රමිතීන්ය. මේවා හුදු අපේක්ෂාවන් නොව ඔබ පෞද්ගලිකව වගකියන පිරික්සුම් ලැයිස්තුවක් ලෙස සලකන්න:
දොරටුව 1: පද්ධති නිර්මාණ සංගතභාවය සහ වසම් සීමා (Architectural Cohesion & Domain Boundaries)
පද්ධතියේ ව්‍යාපාරික තර්කනය (Business Logic), දත්ත ස්ථරය (Data Layer), සහ පරිශීලක අතුරුමුහුණත (UI) කිසිවිටෙකත් එකිනෙක පැටලී නොතිබිය යුතුය. Clean Architecture මූලධර්ම අනුව එක් මොඩියුලයක සිදුවන වෙනසක් අනෙක බිඳ නොදැමිය යුතුය.
දොරටුව 2: පාලනය නොකළ දෝෂ ශුන්‍ය කිරීම සහ ආරක්ෂණ කේතකරණය (Zero Unhandled Errors & Defensive Code)
කිසිදු බලාපොරොත්තු නොවූ ධාවන කාල දෝෂයකින් (Runtime Exception) සර්වරය බිඳ නොවැටිය යුතුය. සෑම ශ්‍රිතයක් සඳහාම ආරක්ෂිත විකල්ප (Fallbacks) සහ වර්ගීකෘත දෝෂ ප්‍රතිලාභ (Result/Either patterns) තිබිය යුතුය.
දොරටුව 3: දැඩි දත්ත වර්ග ආරක්ෂාව සහ ගිවිසුම් බලාත්මක කිරීම (Strict Type Safety & Contract Enforcement)
any භාවිතය සහ ලිහිල් ටයිපින් සම්පූර්ණයෙන්ම තහනම්ය. පද්ධතියට ඇතුළු වන සහ පිටවන සෑම දත්තයක්ම දැඩි schema වලංගුකරණයකට ලක්විය යුතුය — TypeScript strict mode, Python Pydantic, හෝ Rust type system.
දොරටුව 4: ස්වයංක්‍රීය පරීක්ෂණ ත්‍රිත්වය (Automated Test Triad — Unit, Integration, E2E)
Unit tests පමණක් ප්‍රමාණවත් නොවේ. API endpoints සහ සැබෑ දත්ත ගබඩාව අතර Integration tests, සහ පරිශීලක හැසිරීම් අනුකරණය කරන Playwright/Cypress End-to-End tests ස්වයංක්‍රීය CI/CD නල මාර්ගය තුළ 100% ක් සමත් විය යුතුය.
දොරටුව 5: නිර්ණායක තත්ත්වය සහ එකම ප්‍රතිඵල නීතිය (Deterministic State & Idempotency)
ජාල දෝෂයක් නිසා එකම ගෙවීම් ඉල්ලීම දෙවරක් ලැබුණද, පාරිභෝගිකයාගෙන් අයවිය යුත්තේ එක් වරක් පමණි — Idempotency keys සහ දත්ත සමුදා ගනුදෙනු (Transactions) අනිවාර්ය වේ.
දොරටුව 6: උප-තත්පර ප්‍රමාද සීමාවන් (Sub-Second Latency Budgets)
සෑම API එකකම 95 වන ප්‍රතිශතක (p95) ප්‍රතිචාර කාලය මිලි තත්පර 200 ට වඩා අඩුවෙන් පැවතිය යුතුය. N+1 දත්ත සමුදා විමසුම් සහ අනවශ්‍ය ජාල පැනීම් ශුන්‍ය කළ යුතුය.
දොරටුව 7: දැඩි ආරක්ෂාව සහ Zero-Trust අනන්‍යතා පාලනය (Hardened Security & Zero-Trust Auth)
සෑම ඉල්ලීමක්ම සත්‍යාපනය (Authenticated) සහ අවසර ලත් (Authorized) විය යුතුය. OWASP Top 10 ආරක්ෂණ (SQL Injection, XSS, CSRF, BOLA) සම්පූර්ණයෙන්ම තහවුරු විය යුතුය.
දොරටුව 8: දැඩි රහස් කළමනාකරණය සහ Git කාන්දුවීම් ශුන්‍ය කිරීම (Strict Secrets Management & Zero Git Leaks)
කිසිදු API key, මුරපදයක්, හෝ ටෝකනයක් කිසිවිටෙකත් Git ගබඩාවකට එක් නොවිය යුතුය. Pre-commit hooks මගින් රහස්‍ය තොරතුරු නිරාවරණය වීම ස්වයංක්‍රීයව අවහිර කළ යුතුය.
දොරටුව 9: පූර්ණ නිරීක්ෂණතාව — ව්‍යුහාත්මක ලොග්, මෙට්‍රික්ස්, ට්‍රේස් (Full Observability)
දෝෂයක් ඇතිවූ විට, පාරිභෝගිකයා කතා කර දැනුම් දීමට පෙරම, ව්‍යුහාත්මක JSON ලොග් සහ OpenTelemetry ට්‍රේස් ආශ්‍රයෙන් අසාර්ථක වූ නිශ්චිත කේත පේළිය හඳුනා ගැනීමට ඉංජිනේරු කණ්ඩායමට හැකි විය යුතුය.
දොරටුව 10: අලංකාර පරිහානිය සහ ඔරොත්තු දීමේ හැකියාව (Graceful Degradation & Resilience)
බාහිර සේවාවක් (SMS Gateway, AI API) අක්‍රිය වුවද, සමස්ත පද්ධතිය කඩා නොවැටිය යුතුය; Circuit-breaker ආකෘතියක් මගින් පරිශීලකයාට සුදුසු විකල්පයක් හෝ නිවේදනයක් ලබා දිය යුතුය.
දොරටුව 11: යන්ත්‍ර කියවිය හැකි ලියකියවිලි සහ OpenAPI (Machine-Readable Documentation)
මිනිස් ඉංජිනේරුවන්ට මෙන්ම AI නියෝජිතයන්ටද පද්ධතිය තේරුම් ගත හැකි පරිදි ස්වයංක්‍රීයව යාවත්කාලීන වන OpenAPI/Swagger පිරිවිතරයන් පවත්වා ගත යුතුය.
දොරටුව 12: විශ්වීය ප්‍රවේශ්‍යතාව (Universal Accessibility — WCAG 2.1 AA)
ඕනෑම තිර ප්‍රමාණයක (320px දක්වා responsive), දුර්වල අන්තර්ජාල සම්බන්ධතාවල, සහ විශේෂ අවශ්‍යතා සහිත පුද්ගලයන්ට (Screen readers, Keyboard navigation) බාධාවකින් තොරව භාවිත කළ හැකි විය යුතුය.
දොරටුව 13: ආපසු හැරවිය හැකි සංක්‍රමණ සහ අක්‍රිය කාලය ශුන්‍ය කිරීම (Reversible Migrations & Zero Downtime)
දත්ත සමුදා වෙනස්කම් නිසා පද්ධතිය අක්‍රිය නොවිය යුතුය; නිකුතුවක දෝෂයක් ඇත්නම් තත්පර 30 ක් තුළ පෙර පැවති තත්ත්වයට කිසිදු අවදානමකින් තොරව Rollback කිරීමේ හැකියාව තිබිය යුතුය.
දොරටුව 14: අනිවාර්ය Dogfooding සත්‍යාපනය (Mandatory Dogfooding Verification)
ඉංජිනේරුවා තමන් ගොඩනැගූ නිෂ්පාදනය සැබෑ පරිශීලකයෙකු ලෙස, සැබෑ පරිසරය තුළ, තම දෛනික අවශ්‍යතා සඳහා අනිවාර්යයෙන්ම භාවිත කළ යුතුය — එහි ඇති සෑම ගැටලුවක්ම තමන්ගේ අත්දැකීමෙන්ම සහතික කළ යුතුය.
Important
දොරටු 14 සහ AI යුගයේ වගකීම: AI කේතකරණ නියෝජිතයන් කොතරම් වේගයෙන් කේත ලිව්වද, මෙම දොරටු කිසිවක් ලිහිල් නොවේ — ඒවා තවත් දැඩි වේ. මන්ද AI යනු අධික ආත්මවිශ්වාසයක් ඇති සීමාවාසිකයෙකි: එය නිවැරදි කේතය ලියන ආකාරයටම, ඒ හා සමාන ආත්මවිශ්වාසයකින් යුතුව ආරක්ෂක සිදුරු සහිත කේතද ලියයි. Production පරිසරයට යන සෑම කේත පේළියකම අවසන් වගකීම ඇත්තේ Merge බොත්තම ඔබන ඉංජිනේරුවා සතුව මිස AI සතුව නොවේ. එම වගකීම ක්‍රමවේදයකට අනුව ඉටුකිරීම සඳහා ඉංජිනේරුවා සතු බලකොටුව වන්නේ මෙම දොරටු 14 යි.
14 වන දොරටුව විශේෂ අවධානයක් ලැබිය යුතුය; මන්ද එය නිතරම මඟහැරෙන මෙන්ම ස්වයංක්‍රීය කළ නොහැකි එකම දොරටුව වන බැවිනි. සෙසු සියලු දොරටු ස්වයංක්‍රීය පරීක්ෂණ මගින් පරීක්ෂා කළ හැක. සැබෑ පරිශීලකයෙකු ලෙස තම නිෂ්පාදනය දිනපතා භාවිත කිරීම යනු කිසිදු පරීක්ෂණයකින් හසුනොවන සියුම් ගැටලු හසුකර ගන්නා දොරටුවයි — මීළඟ කොටසින් අප සාකච්ඡා කරන්නේ එයයි.
කේත වේගයෙන් නිපදවිය හැකි තරමට, සමාලෝචනය කළ යුතු කේත ප්‍රමාණය වැඩිවන අතර දොරටු වල වැදගත්කමද ඉහළ යයි. දොරටු රහිත වේගය යනු ඵලදායිතාව නොවේ; එය සත්‍යාපනය නොකළ අසම්පූර්ණ නිර්මාණ පරිශීලකයන් අතට පත්වීම පමණි.
තමන් තැනූ මෘදුකාංගය තමන්ම දෛනිකව භාවිත කිරීමේ (Dogfooding) වැදගත්කම කුමක්ද?
"Eat your own dog food" හෙවත් තමන් නිපදවන දේ තමන්ම භාවිත කිරීම යනු ඉංජිනේරු විශිෂ්ටත්වය මැනිය හැකි ඉහළම මෙන්ම ලාභදායීම මිනුම් දණ්ඩයි.
බොහෝ නවක කෝඩර්වරුන් තම කේතය පරීක්ෂා කරන්නේ ව්‍යාජ දත්ත (Dummy Data) මගිනි — test123, abc@gmail.com. සියල්ල සාර්ථකව ක්‍රියාත්මක වන බව දැක ඔවුන් එය භාර දෙයි. ව්‍යාජ දත්ත කිසිවිටෙකත් සැබෑ පරිශීලකයෙකු හැසිරෙන අයුරින් නොහැසිරෙන බැවින් පරීක්ෂණ සියල්ල සමත් වේ.
නමුත් සැබෑ Product Engineer කෙනෙකු එම මෘදුකාංගය තමන්ගේ දෛනික ජීවිතයට බද්ධ කරගන්නා අතර සැබවින්ම ඒ මත යැපෙයි. එහි ප්‍රතිඵලය නම්, අපහසු බොත්තමක්, මන්දගාමී පැටවීමක්, හෝ තේරුම් ගත නොහැකි දෝෂ පණිවිඩයක් හුදු ලේඛනයක සටහන්ව තිබෙන අයිතමයක් නොවී, අද දවසේ තමන්ගේම පෞද්ගලික ගැටලුවක් බවට පත්වීමයි. එය මෙතෙක් සොයාගෙන ඇති එවැනි ගැටලු නිරාකරණය කරගැනීමේ එකම ස්ථිර ක්‍රමවේදයයි.
Dogfooding ක්‍රමයට තැනූ මෘදුකාංගයක් භාවිත කිරීමේදී වෙනස්ම උසස් බවක් දැනෙන්නේ එබැවිනි. කිසිවෙකුට සුළු වැඩිදියුණු කිරීම් ඉල්ලා වාද කිරීමට සිදුනොවේ; ඉංජිනේරුවාටම ඒවා වෙනස් කිරීමට අවශ්‍ය විය.
පිරිවිතර මත පදනම් වූ සංවර්ධනය සහ බහු-නියෝජිත පද්ධති මෙහෙයවන්නේ කෙසේද?
නූතන Product Engineer තනිවම කේත ලියන්නේ නැත. ඔවුන් ක්‍රියාත්මක වන්නේ AI නියෝජිතයන් මෙහෙයවන ප්‍රධාන ඉංජිනේරු නායකයා (Engineering Lead) ලෙසය. ඒ සඳහා අවශ්‍ය වන්නේ වෙනස්ම මූලික කුසලතාවකි.
රූපය: Specification-Driven Development (SDD) & Multi-Agent Architecture — ඉඩසර ඇකඩමිය (Idasara Academy)
පළමු අදියර: පිරිවිතරය සකස් කිරීම (The Specification)
කිසිදු කේතයක් ලිවීමට පෙර, ඉංජිනේරුවා විසින් පද්ධතියේ දත්ත ආකෘති, API ගිවිසුම්, සහ ආන්තික අවස්ථා (Edge Cases) ඉතා නිරවද්‍ය Markdown ලේඛනයක් ලෙස සකස් කරනු ලබයි.
මෙහිදී සිදුවන්නේ අවුකන බුදුපිළිමය නෙළූ මූර්ති ශිල්පියා කළ දෙයමය: ගලට අත තැබීමට පෙර සමස්ත රූපය මනසින් සම්පූර්ණයෙන්ම ගොඩනැගීමයි. එමෙන්ම ඊට බැඳුණු දැඩි සත්‍යයක් පවතී — පිරිවිතරයේ ගුණාත්මකභාවය මඟින් නිෂ්පාදනයේ උපරිම ගුණාත්මක සීමාව තීරණය වේ. අපැහැදිලි පිරිවිතරයකින් ලැබෙන්නේ අපැහැදිලි ප්‍රතිඵලයක් පමණක් නොවේ; එය AI නියෝජිතයෙකුට වැරදි දිශාවකට දැඩි වේගයකින් බොහෝ දුරක් දිව යාමට පූර්ණ නිදහස ලබා දෙයි.
දෙවන අදියර: නියෝජිතමය ක්‍රියාත්මක කිරීම (Agentic Execution)
AI කේතකරණ නියෝජිතයන් එම පිරිවිතරයට අනුකූලව කේත ලියයි, පරීක්ෂණ ධාවනය කරයි, සහ දෝෂ තමන් විසින්ම නිරාකරණය කරගනියි. එක් නියෝජිතයෙකු කේත ලියන අතරතුර, තවත් නියෝජිතයෙකු පරීක්ෂණ ලියයි; තෙවැන්නෙකු ලියකියවිලි සම්පාදනය කරයි.
මෙහිදී ඉංජිනේරුවා තනිවම වාදනය කරනවා වෙනුවට වාද්‍ය වෘන්දයක් මෙහෙයවන ප්‍රධානියා බවට පත්වේ. මෙහිදී භාවිත වන්නේ පැහැදිලි උපදෙස් සහිතව කාර්යයන් පැවරීමේ හැකියාව වන අතර, එය හුදු තාක්ෂණික කුසලතාවකට වඩා කළමනාකරණ කුසලතාවකි.
තෙවන අදියර: පද්ධති නිර්මාණ සමාලෝචනය (Architectural Review)
අවසාන පාලනය සහ දැඩි දොරටු 14 හි පිරික්සුම අයත් වන්නේ Product Engineer ටය. Core Module 06 හි ඩිලොයිට් (Deloitte) ආයතනයේ පාඩම මෘදුකාංග ඉංජිනේරු ක්ෂේත්‍රයට අදාළ වන්නේ මෙතැනදීය: ප්‍රතිදානය කොතරම් විශිෂ්ට වුවද, කියවා, ප්‍රශ්න කර, සත්‍යාපනය නොකළ කිසිදු කේතයක් Production පරිසරයට මුදා නොහැරේ.
Tip
ප්‍රායෝගික පළමු පියවරක්: කුඩා ව්‍යාපෘතියකදී වුවද ඔබට අදම මෙය පුහුණු විය හැකිය. මීළඟ අංගය (Feature) කේතගත කිරීමට පෙර, එහි සම්පූර්ණ පිරිවිතරය (Inputs, Outputs, Edge Cases, Error Handling) Markdown ගොනුවක ලියන්න. ඉන්පසු එය AI නියෝජිතයෙකුට ලබා දී ඔබේම පිරිවිතරයට එරෙහිව ලැබුණු ප්‍රතිඵලය විගණනය කරන්න. සති කිහිපයකින් ඔබේ සැබෑ කුසලතාව ටයිප් කිරීමේ වේගය නොව චින්තනයේ පැහැදිලිකම බව ඔබට වැටහෙනු ඇත.
මෙම නිෂ්පාදන ඉංජිනේරු කුසලතාව ඉඩසර ඇකඩමිය හරහා ගොඩනගා ගන්නේ කෙසේද?
ඉඩසර ඇකඩමිය (Idasara Academy) වර්තමානයේ ගෝලීයව ඉහළම වටිනාකමක් ඇති Product Engineer භූමිකාව සඳහා අවශ්‍ය ප්‍රායෝගික පුහුණුව සපයයි.
නිෂ්පාදන ඉංජිනේරු ශිෂ්‍යත්ව පාඨමාලාව (The Product Engineer Masterclass) — මූලධර්මවාදී චින්තනය, පද්ධති නිර්මාණ සැලැස්ම සහ Domain-Driven Design පිළිබඳ ප්‍රායෝගික පුහුණුවක් ලබා දෙයි.
දැඩි දොරටු 14 ස්වයංක්‍රීය CI/CD ඇගයුම් එන්ජිම — ඔබේ කේත ගබඩාවන් සජීවීව විගණනය කර ඉහත ප්‍රමිතීන්ට අනුව ලකුණු ලබා දෙයි; එමගින් පිරික්සුම් ලැයිස්තුවක් මැනිය හැකි ප්‍රායෝගික පද්ධතියක් බවට පත්වේ.
නියෝජිත මෘදුකාංග කාර්ය ප්‍රවාහ (Agentic Software Workflows) — Cursor, Claude Code සහ බහු-නියෝජිත මෙහෙයුම් හරහා සැබෑ පද්ධති ගොඩනැගීමේ ප්‍රායෝගික වැඩබිම්.
සැබෑ ලෝකයේ Capstone Incubator — සෙල්ලම් ඇප් වෙනුවට සැබෑ මිනිසුන් දිනපතා යැපෙන මෘදුකාංග නිර්මාණය කිරීමේ අවස්ථාව; Dogfooding මූලධර්මය සැබවින්ම ඉගෙන ගත හැක්කේ එවැනි පරිසරයකදී පමණි.
මීළඟ පරිච්ඡේදයෙන් අප සාකච්ඡා කරන්නේ ගිණුම්කරණය සහ මූල්‍ය කළමනාකරණය තුළ සිදුවන දැවැන්ත AI පරිවර්තනයයි.