From Maker to Consultant: How AI Is Redefining the Programmer’s Role

The author observes a fundamental transformation in the programmer’s role driven by the AI era, moving from a "manufacturing" mindset—where developers treat requirements as precise blueprints to be built—to a "consultant" mindset that focuses on uncovering and solving underlying business problems.

The "Unsuccessful" Programmer

In a recent collaboration, the author worked with a technically competent programmer who delivered tasks reliably but lacked a strong sense of "delivery" versus merely "completion." The programmer would check off a list of requirements without probing the real problem, leading to friction when the author could not define every task in detail.

The Definition Paradox of AI

If a task can be perfectly specified—including all context and boundary conditions—the author argues that an AI model (e.g., GPT‑5, Claude, or future models) could execute it more efficiently and at lower cost. However, the author often lacks the time to produce such exhaustive specifications, making human consultants essential for extracting and clarifying the real objectives.

Re‑valuating the Value of Code

Historically, the adage "Talk is cheap, show me the code" emphasized code as the primary value. In the AI‑augmented world, code production costs approach zero, while high‑density contextual communication becomes expensive and scarce. The author seeks collaborators who provide "time" and "thinking" rather than merely consuming the author's time by demanding detailed specifications.

Consultant Mindset Illustrated by a Doctor Analogy

Just as a doctor asks about symptoms instead of blindly prescribing medication, a consultant‑type programmer questions vague statements like "security is important" to uncover the true requirements, risk profile, budget constraints, and acceptable trade‑offs. This approach may produce a technically imperfect solution but aligns with business goals and constraints.

Production‑Type vs. Consultant‑Type Programmer

A production‑type programmer, when told "security is important," may over‑engineer the solution—adding complex encryption, strict access controls, and extensive logging—potentially consuming 30% of project time and 50% of budget, yet delivering a product that may be late and over budget.

Conversely, a consultant‑type programmer treats the statement as a vague signal, asks clarifying questions about actual threats, acceptable risk, timeline, and budget, and proposes a balanced solution that may be less technically perfect but better serves the business.

Conclusion: Embracing the Hardest Transition

The shift from "maker" to "consultant" requires programmers to leave the comfort zone of deterministic code writing and engage with ambiguous business language, uncertainty, and continuous context gathering. Their value now lies in turning unclear requirements into clear, actionable solutions, a skill that AI cannot replace.