How AI Coding Starts with a Work Problem

Nathaniel Whittemore's The AI Daily Brief is a daily show about AI news, tools, work, and policy. In the August 29, 2026 episode "How to Start AI Coding If You Haven't Yet," Whittemore makes a narrower case than "learn to become a programmer": knowledge workers should learn enough AI-assisted coding to turn recurring work problems into small software tools. 1

The practical value of the episode is its sequence. Find a task with a clear shape, choose what kind of change you want, build a small test, and decide how durable the result needs to be. The first project can be disposable. That lowers the cost of learning while preserving a path toward software that a team or a market can use.

Whittemore begins with a person who already uses several AI subscriptions and has moved much of their work into an AI-assisted routine. AI coding still feels foreign to that person because the phrase suggests professional software engineering. Whittemore argues that the more useful question is simpler: which parts of the job already involve repeated instructions, transformations, lookups, or explanations? 1

That question points toward six kinds of work: presentation, content, data, documents, inboxes, and administration. A recurring presentation may become an interactive page. A transcript may become a set of summaries or shareable excerpts. A repeated data analysis may become a dashboard with controls for new questions. A document process may involve filling templates, renaming files, converting formats, or finding specific details across many files.

The test is repetition plus a recognizable output. A vague wish to "use AI more" gives a tool no clear target. A weekly CSV export, a recurring status report, or a repeated explanation gives the builder something to compare against. The reader can tell whether the tool works because the old task already has an answer, a format, or a standard of correctness.

Whittemore divides projects into three build patterns. Each pattern changes the work in a different way.

Automation keeps the job and the output the same. A tool renames files, syncs lists, fills a template, or reworks an export. The recipient should receive the same result without seeing the manual steps behind it. This is a forgiving starting point because the builder already knows what a correct result looks like, and manual work remains available when the tool makes a mistake. 1

Upgrade keeps the job while changing the output. Whittemore's examples include turning a report into a live dashboard, a slide deck into a web application, or a status email into a self-serve page. The new format can make the work more useful, yet the project also creates a higher standard. A broken dashboard leaves a larger gap than a broken file-renaming script because the upgraded output has become part of how people consume the work. 1

Invention creates a new job and a new output. Whittemore points to interviewing every person in a large group, monitoring hundreds of sources, or testing thousands of copy variations. Manual work made those tasks impractical before software reduced their cost. Invention has the largest upside and the weakest evidence at the start. A new capability may turn out to be something nobody uses, so the builder needs permission to abandon it. 1

The same code can require very different work depending on who relies on it. Whittemore describes four delivery classes: prototype, personal software, production software, and product.

A prototype answers a question or tests an interaction. Speed and clarity matter more than polish, deep security, or a complete user experience. A personal software tool serves one person or a small team over time. The tool needs to perform its job reliably, while the builder can accept compromises in permissions, edge cases, or visual design when those compromises fit the use.

Production software serves people outside the builder's immediate circle. A failure can cost users time, money, access, or trust, so the project needs stronger security, access control, support paths, and behavior under realistic use. A product serves a broader market and carries the full burden of software for people the builder does not know.

The boundary between the classes can move. Whittemore describes building the AI Daily Brief's own content workflow as a progression: he first tested whether AI could extract themes from transcripts, then built a pipeline for his own website, then extended the work to a small team and automated social posts. A later sponsor-reporting system moved closer to production software. The sequence let each stage answer a question before the next stage took on more users and more responsibility. 1

The episode's advice becomes concrete when Whittemore lists places to look. Presentation work can become an interactive explainer, calculator, comparison tool, onboarding walkthrough, or status page. Content work can become an end-to-end pipeline that turns one source into summaries, headlines, or posts. Data work can combine a recurring report with controls that let a colleague ask follow-up questions.

Document work offers another clear path. If a person repeatedly fills the same fields, renames a batch of files, converts documents, or searches a folder for a specific fact, an AI assistant can handle one item at a time. A small program can then apply the same process across the whole set. Inbox and administrative work may offer similar opportunities, although Whittemore urges builders to check existing products first.

That last step protects the project from becoming an unnecessary maintenance burden. Whittemore describes finding a service called Typefully for automated posting rather than building direct integrations with the X and LinkedIn APIs. The lesson is practical: AI coding makes custom software cheaper, while an existing product may still be the better answer when it already handles the surrounding reliability and support work. 1

A sensible first experiment therefore has four properties: the task recurs, the desired result is visible, the first audience is small, and failure has a manageable cost. Start with a prototype that answers one question. If the prototype proves useful, keep the parts that matter and turn them into personal software. Move toward production software only when other people depend on the result.

Whittemore's framing shifts the learning target away from memorizing syntax. The builder still has to describe a problem, supply context, inspect outputs, and tell the coding tool what changed. The builder also has to recognize when an existing service solves the problem more completely. Those activities require knowledge of the work itself and a fast feedback loop.

That loop explains why relevance matters more than a generic tutorial. A person who builds a small tool for a real Friday task can compare each version with the manual process. The comparison supplies useful feedback: the output is correct, incomplete, too slow, or unnecessary. A tutorial project can teach mechanics, yet a work project teaches where software can change the job.

Choose one repeated task from a presentation, content, data, document, inbox, or administrative workflow. Describe the current input and the desired output. Decide whether the project should automate an existing result, upgrade the format, or create a new capability. Check for an existing tool before building. Then make the smallest prototype that can answer whether the idea deserves another hour.

Whittemore's permission to stop is part of the method. A project that proves unnecessary has still answered a useful question at low cost. The first goal is a working feedback loop around a real task; durability comes later.

Listen to the full episode on the official AI Daily Brief episode page.