Programmers and AI: Deciding What Should Be Built

The unfinished work before the first prompt

A fictional repair business asks its programmer for an AI-built appointment system. Generating a booking screen is only one task. Someone must decide whether customers can reserve the last available slot simultaneously, what a cancellation means and which staff member can override availability. Those choices determine whether the system serves the business.

GitHub's December 2025 report on interviews with 22 advanced AI users describes developers spending more attention on intent, architecture and verification. This is a qualitative account from a selected group of US-based developers, not a representative survey or a prediction that every programmer will follow the same path. [GitHub: The new identity of a developer: What changes and what doesn't in the AI era]

Turn a request into observable behaviour

NASA's requirements checklist offers a useful engineering discipline: distinguish the required outcome from its implementation, state assumptions, avoid ambiguity and make compliance verifiable. Its aerospace context is different from a small web application, but the questions provide a way to examine an incomplete brief. [NASA: Appendix C — How to Write a Good Requirement]

For our booking example, BELL RIVER suggests replacing 'make booking reliable' with a specific rule: once a slot is confirmed, a second customer cannot confirm that same slot. Write separate rules for cancellation and staff overrides. Ask the business owner to settle conflicting preferences before instructing an agent to implement them.

Choose boundaries and explain the tradeoff

Our editorial recommendation is to keep an explicit design note alongside the brief. Identify where appointment records live, which component may change them and how the interface learns that a booking failed. Sketch the path from a customer's click to the saved record, including the response when two requests compete.

An agent can propose several designs. The programmer should be able to explain the selected one to another maintainer: which requirement it satisfies, what complexity it adds and what would justify changing it. For this fictional business, adding another service without a clear operational need would create another component someone must maintain.

Practise translating between people and software

We expect these skills to remain useful wherever AI assists implementation: interviewing users, writing precise examples, understanding data consistency and comparing design alternatives. That is BELL RIVER's editorial assessment, not a hiring forecast. A junior programmer can practise on one feature without claiming the responsibilities or experience of a software architect.

A booking brief you can test

Create a fictional timetable with three slots. Write five acceptance examples, including two people requesting the same slot and a cancellation followed by a new booking. Draw the components, then ask a peer or an AI tool to identify missing decisions. Revise the brief and keep a record of what changed.

Your portfolio deliverable is the brief, diagram and decision note, with invented data clearly labelled. Explain one rejected design and why the chosen design fits this example. The exercise demonstrates reasoning about a small system; it does not establish readiness to design a large production platform.

Three practical first steps

• Choose one familiar feature and write its user outcome, constraints and unresolved questions before asking for code.
• Turn five important behaviours into acceptance examples and review them with someone playing the user.
• Sketch the data flow and record one design decision, its alternative and the evidence that would change your mind.

The GitHub interviews describe selected advanced users, not the whole profession. NASA's checklist supplies engineering principles, not evidence of AI adoption or local hiring. This guide promises neither employment nor a particular future task mix. Sources checked 13 October 2026.

Sources & editorial note

• GitHub: The new identity of a developer: What changes and what doesn't in the AI era — 8 December 2025
• NASA: Appendix C — How to Write a Good Requirement

This career guide distinguishes source-backed descriptions from BELL RIVER’s editorial suggestions. Learning exercises are illustrative, not employer requirements, certifications or promises of employment. Overseas examples do not establish demand or eligibility in the UAE.