AI đang thay đổi cách lập trình viên Oracle APEX làm việc

AI đang thay đổi rất nhanh cách lập trình viên xây dựng phần mềm. Với Oracle APEX và PL/SQL, sự thay đổi này không chỉ nằm ở việc AI có thể gợi ý vài dòng code nhanh hơn. Điều đáng chú ý hơn là AI bắt đầu có khả năng hỗ trợ tạo ra những phần code tương đối lớn, miễn là nó được cung cấp đủ ngữ cảnh, đặc tả rõ ràng và các pattern chuẩn của dự án.

Điều này tạo ra một thay đổi quan trọng trong vai trò của lập trình viên APEX. Developer không chỉ là người viết từng dòng PL/SQL, từng câu SQL hay từng Dynamic Action. Developer ngày càng giống người thiết kế hệ thống, chuẩn hóa ngữ cảnh, đặt ra ràng buộc, kiểm tra kết quả và đảm bảo code AI tạo ra phù hợp với kiến trúc ứng dụng.

Nói cách khác, trong kỷ nguyên AI, năng lực quan trọng không chỉ là “prompt hay”. Năng lực quan trọng hơn là biết chuẩn bị môi trường, metadata, đặc tả, pattern và checklist để AI có thể tạo ra kết quả đáng tin cậy hơn.

AI không chỉ cần prompt, AI cần context

Một hiểu lầm phổ biến là chỉ cần viết một prompt thật dài thì AI sẽ tạo ra code tốt. Thực tế, prompt chỉ là một phần nhỏ. Với các ứng dụng Oracle APEX và PL/SQL, AI cần hiểu cấu trúc dữ liệu, mối quan hệ giữa các bảng, quy tắc nghiệp vụ, chuẩn viết code và những pattern đã tồn tại trong dự án.

Nếu bạn chỉ nói “hãy viết procedure xử lý đơn hàng”, AI sẽ phải đoán rất nhiều. Nhưng nếu bạn cung cấp DDL, constraints, comments, đặc tả nghiệp vụ, ví dụ package hiện có và quy tắc coding của dự án, AI sẽ có nhiều cơ sở hơn để tạo ra code phù hợp.

Metadata database là nền tảng rất quan trọng

Với lập trình viên APEX, database schema không chỉ là nơi lưu dữ liệu. Schema còn là nơi mô tả rất nhiều quy tắc nghiệp vụ. Tên bảng, tên cột, constraint, foreign key, check constraint và comment đều giúp AI hiểu hệ thống tốt hơn.

Một schema tốt nên có:

• Tên bảng và tên cột rõ nghĩa.
• Primary key và foreign key đầy đủ.
• Check constraint cho các giá trị trạng thái nếu phù hợp.
• NOT NULL constraint cho các cột bắt buộc.
• Unique constraint cho natural key hoặc dữ liệu không được trùng.
• Comment cho bảng và cột quan trọng.

Ví dụ, một cột tên STATUS_CODE có check constraint gồm DRAFT, SUBMITTED, APPROVED, REJECTED sẽ giúp AI hiểu đây không chỉ là một chuỗi ký tự, mà là một phần của workflow.

Đây cũng là điều developer APEX nên làm kể cả khi không dùng AI. AI chỉ làm cho giá trị của metadata tốt trở nên rõ ràng hơn.

Đặc tả không phải việc phụ, đặc tả chính là công việc

Nhiều developer có cảm giác rằng nếu phải viết đặc tả chi tiết cho AI, thì tự viết code luôn có khi còn nhanh hơn. Nhưng trong các dự án nghiêm túc, đặc tả là thứ bạn nên có dù có dùng AI hay không.

Đặc tả giúp:

• Business user xác nhận bạn hiểu đúng yêu cầu.
• Developer nhìn thấy rule và edge cases trước khi code.
• Tester có cơ sở viết test cases.
• AI có ngữ cảnh rõ ràng để sinh code.
• Team có tài liệu để bảo trì về sau.

Với AI, đặc tả càng rõ thì output càng tốt. Một đặc tả tốt nên mô tả:

• Mục tiêu của chức năng.
• Các bảng và package liên quan.
• Input và output mong muốn.
• Business rules.
• Validation rules.
• Edge cases.
• Thông báo lỗi cần trả về.
• Quyền truy cập và ràng buộc bảo mật.

Bạn có thể viết đặc tả bằng Markdown để dễ đọc, dễ version control và dễ đưa vào công cụ AI. Markdown cũng phù hợp để ghi chú thêm các chỉ dẫn kỹ thuật cho AI mà vẫn giữ tài liệu gọn.

AI làm tốt hơn khi có pattern mẫu

AI thường tạo code tốt hơn nhiều nếu nó được xem các pattern đã tồn tại trong dự án. Thay vì yêu cầu AI tự nghĩ từ đầu, bạn có thể chỉ cho nó một hoặc hai procedure được xem là chuẩn, rồi yêu cầu nó áp dụng cùng phong cách cho chức năng mới.

Ví dụ, nếu dự án của bạn đã có một pattern xử lý upload Excel:

1. Upload file vào APEX collection.
2. Dùng APEX_DATA_PARSER để đọc dữ liệu.
3. Validate từng dòng và ghi lỗi.
4. Cho người dùng review dữ liệu đã validate.
5. Import dữ liệu hợp lệ vào bảng chính.

Khi cần tạo chức năng upload mới, bạn không nên chỉ yêu cầu AI “viết procedure upload”. Hãy đưa cho AI procedure upload cũ và nói rõ: hãy giữ cùng pattern, cùng cách log lỗi, cùng cách validate, nhưng áp dụng cho nghiệp vụ mới.

Cách này giúp code AI tạo ra gần với phong cách dự án hơn, dễ review hơn và ít lệch chuẩn hơn.

AGENTS.md giúp AI hiểu quy tắc của dự án

Một file AGENTS.md trong repository có thể đóng vai trò như tài liệu hướng dẫn cho AI coding agent. File này mô tả những quy tắc mà AI cần tuân theo khi tạo hoặc sửa code.

Nội dung AGENTS.md có thể bao gồm:

• Luôn dùng %TYPE và %ROWTYPE khi phù hợp.
• Ưu tiên logic set-based thay vì loop từng dòng nếu có thể.
• Dùng APEX_STRING, APEX_JSON, APEX_DEBUG khi phù hợp.
• Không hard-code schema name.
• Không dùng dynamic SQL nếu không cần thiết.
• Nếu bắt buộc dùng dynamic SQL, phải dùng bind variables và validate identifier.
• Luôn log lỗi bằng APEX_DEBUG hoặc package logging của dự án.
• Quy tắc format SQL và PL/SQL.
• Cấu trúc thư mục trong repository.
• Các package hoặc procedure mẫu cần tham khảo.

Nếu không có file hướng dẫn, AI thường tạo code theo phong cách chung chung. Nếu có hướng dẫn rõ ràng, AI có cơ hội tạo code gần với chuẩn dự án hơn.

Developer vẫn chịu trách nhiệm cuối cùng

Dù AI có thể tạo ra code rất nhanh, developer vẫn là người chịu trách nhiệm cuối cùng. Không nên commit code chỉ vì nó trông có vẻ hợp lý. Bạn cần hiểu code đó làm gì, nó xử lý trường hợp nào, nó bỏ sót trường hợp nào và nó có phù hợp với kiến trúc ứng dụng hay không.

Với PL/SQL và Oracle APEX, một lỗi nhỏ có thể ảnh hưởng trực tiếp đến dữ liệu thật. Vì vậy, các phần sau vẫn phải do developer kiểm tra kỹ:

• Business logic có đúng không?
• Validation có đủ không?
• Transaction có an toàn không?
• Exception handling có hợp lý không?
• Có nguy cơ SQL Injection không?
• Authorization có được kiểm tra ở server-side không?
• Performance có ổn khi dữ liệu lớn không?
• Code có dễ bảo trì không?

AI có thể giúp viết nhanh hơn, nhưng không thể thay thế trách nhiệm review.

Security không nên giao cho AI tự quyết định

AI có thể hỗ trợ phát hiện vấn đề bảo mật, nhưng không nên là lớp bảo mật duy nhất. Trong APEX, bạn vẫn cần kiểm tra thủ công các điểm quan trọng:

• Authentication Scheme.
• Authorization Scheme.
• Page Access Protection.
• Session State Protection.
• Item Protection.
• Public pages.
• File upload/download.
• Dynamic SQL.
• REST APIs.
• Escaping trong report và dynamic content.

Nếu AI tạo procedure cập nhật dữ liệu, bạn nên kiểm tra lại quyền truy cập bên trong package. Không nên chỉ dựa vào việc UI đã ẩn button hoặc menu.

Test là phần không thể bỏ qua

AI có thể giúp tạo test cases, nhưng không thể thay thế việc chạy test. Với code PL/SQL do AI hỗ trợ tạo ra, bạn nên có checklist test tối thiểu:

• Happy path.
• Dữ liệu thiếu bắt buộc.
• Dữ liệu sai trạng thái.
• Dữ liệu trùng.
• User không có quyền.
• Record không tồn tại.
• Transaction rollback khi có lỗi.
• Dữ liệu lớn hơn bình thường.
• Edge cases về null, date, number, special characters.

Nếu có thể, hãy yêu cầu AI tạo test script cùng lúc với code. Nhưng developer vẫn cần đọc, chỉnh và chạy test.

Checklist cho code AI tạo ra

Trước khi đưa code AI tạo ra vào repository, bạn có thể dùng checklist sau:

• Đã cung cấp DDL, constraints và comments cho AI chưa?
• Đã có đặc tả rõ business rules và edge cases chưa?
• AI có tham khảo procedure/package mẫu của dự án chưa?
• Code có tuân thủ AGENTS.md hoặc coding standard không?
• Có dùng bind variables khi cần không?
• Có tránh dynamic SQL không cần thiết không?
• Có exception handling và logging không?
• Có kiểm tra authorization ở server-side không?
• Có test happy path và edge cases không?
• Có kiểm tra performance cơ bản không?

Checklist này giúp bạn không bị cuốn vào cảm giác “AI viết xong rồi”. Với code production, viết xong chỉ là bước đầu. Review và test mới quyết định chất lượng.

Vai trò của lập trình viên APEX đang thay đổi

Khi AI ngày càng mạnh hơn, lập trình viên APEX sẽ ít dành thời gian hơn cho những đoạn code lặp lại, và dành nhiều thời gian hơn cho việc thiết kế hệ thống, chuẩn hóa dữ liệu, viết đặc tả, kiểm soát kiến trúc và review kết quả.

Vai trò mới của developer có thể bao gồm:

• Thiết kế schema rõ ràng để cả người và AI đều hiểu được.
• Viết đặc tả nghiệp vụ đủ tốt để AI có thể hỗ trợ.
• Xây dựng pattern code chuẩn cho dự án.
• Quản lý AGENTS.md và coding instructions.
• Review code AI tạo ra.
• Thiết kế test strategy.
• Đảm bảo security và maintainability.

Nói cách khác, developer không mất vai trò. Vai trò trở nên cao hơn: từ người chỉ viết code sang người thiết kế, điều phối và kiểm soát chất lượng hệ thống.

Không phải mọi thứ đều nên để AI làm

AI rất hữu ích, nhưng không nên dùng nó một cách mù quáng. Có những phần bạn vẫn nên tự làm hoặc ít nhất là tự kiểm soát rất kỹ:

• Quyết định kiến trúc tổng thể.
• Thiết kế security model.
• Xử lý transaction quan trọng.
• Review quyền truy cập dữ liệu.
• Thiết kế database schema cốt lõi.
• Quyết định rule nghiệp vụ có tác động lớn.
• Phê duyệt code production.

AI nên là trợ lý tăng tốc, không phải người quyết định cuối cùng.

Kết luận

AI đang tạo ra một thay đổi lớn trong cách lập trình viên Oracle APEX và PL/SQL làm việc. Nhưng điểm mấu chốt không chỉ nằm ở prompt. Chất lượng output phụ thuộc rất nhiều vào ngữ cảnh: database metadata, constraints, comments, đặc tả nghiệp vụ, coding patterns, AGENTS.md, test cases và quy trình review.

Nếu schema rõ ràng, yêu cầu rõ ràng và dự án có pattern nhất quán, AI có thể hỗ trợ tạo code nhanh hơn và gần với chuẩn dự án hơn. Nhưng developer vẫn phải hiểu, kiểm tra, test và chịu trách nhiệm với kết quả cuối cùng.

Trong kỷ nguyên AI, lập trình viên APEX giỏi không chỉ là người biết viết PL/SQL. Đó còn là người biết thiết kế ngữ cảnh tốt để AI hỗ trợ đúng cách, đồng thời giữ vững vai trò kiểm soát chất lượng, bảo mật và kiến trúc của hệ thống.