In a conversation with DevOps trainer Rob Bos, the useful question is not whether an agent can type code faster. It is whether the team can specify, review, test, and ship the change without making its existing problems worse. Rob starts with what language models actually do, then moves through hands-on learning, technical debt, review pressure, prompt and context quality, and the resources consumed by AI-assisted work.
Learn the model's limits, give the agent a small and testable job, and judge the result across the whole delivery path. More generated code is not a gain if requirements are unclear, reviewers cannot absorb it, or production defects rise. Rob's preference for agent mode is a personal workflow; his stronger, more general advice is to preserve engineering judgment and make the work observable.
Watch the Full Interview
Credit: Rob Bos's observations and examples come from the interview and supplied transcript. The survey figures, extension status, and energy context below are checked against the original sources.
Understand the Model Before Trusting the Tool
Rob sees engineers oscillate between treating AI as magic and dismissing it after one poor answer (00:43). His introductory explanation is deliberately simple: a language model learns statistical relationships among tokens and uses the preceding context to generate a likely continuation. That is a useful mental model for prompting, but "just next-word prediction" is a teaching shorthand, not a complete description of every capability or failure mode in an agent system.
The practical consequence is that fluent code is not the same as correct code. A model can respond confidently to a vague request, guess the intended architecture, or agree with an engineer's wrong premise. You still need an explicit requirement, a way to inspect what the tool changed, and an independent check of the output. Rob's examples at 19:17 and 22:41 are a conceptual explanation, not a model-evaluation study.
Start Small, Then Use Agents Where They Help
Rob begins training with familiar changes: add a unit test, improve documentation, or carry a well-understood field through a few layers of an application (03:58). A developer sees what context matters and how to check the answer before moving to larger agent tasks. He also values pair programming because engineers learn from watching one another's prompt, correction, and review habits, not from a two-hour demonstration alone.
He now prefers agent mode over tab completion for many jobs (05:26), but says a trivial one-line fix may be faster to make by hand. That is a useful distinction: agent use is a choice about total effort, not a rule that every keystroke should become a prompt. In his blue-screen anecdote (40:50), an agent helps inspect Windows event logs and crash information. The transferable lesson is to delegate bounded investigation while verifying a proposed fix before granting access to alter the machine.
Faster Code Can Expose a Slower Delivery System
Rob's definition of the engineering job is broader than writing code: turn business needs into value for users (08:29). If an agent produces patches faster, the constraints may shift to deciding what to build, code review, test coverage, release safety, or technical debt. He asks teams to follow work from initial idea to production, including defects and performance, rather than measuring lines generated or time in the editor (11:02).
One interview statistic needs care. Rob describes research as showing engineers spend about two hours a day coding. The cited ActiveState 2019 Developer Survey reports that, among 1,250 respondents to its programming-hours question, 38.8% spent 2–4 hours programming on a typical day and 61.52% spent four hours or less. It does not establish a universal two-hour average, and it predates the present agent workflow. The wider point still stands as a question worth testing: what fraction of your team's delivery time is spent typing code, and where does work actually wait?
Rob's response to technical debt is concrete: keep local test commands, run automated checks, compare visual before-and-after states when a UI changes, and inspect the changed code (12:21). Those controls do not make an agent infallible; they make mistakes easier to catch. His customer example at 13:39 illustrates another bottleneck: faster developers cannot help if business analysts and product owners have not defined testable work.
Prompt Engineering Is Requirements Work
Rob contrasts a vague "fix this codebase" request with a bounded one that includes the error, likely files, and performance constraints (22:41). Better prompts are not secret words. They are clearer descriptions of intent, context, acceptance criteria, and permitted actions. The model can still be wrong, but the engineer has given it a direction that can be evaluated.
He estimates that it can take about six months of regular hands-on use for this style of work to click (24:20). That is his experience as a trainer and practitioner, not a universal learning-curve measurement. A more useful milestone is whether an engineer can choose a task, supply enough context, spot a bad assumption, review a diff, and explain why the result meets the requirement. Pairing with a colleague remains valuable even when AI is in the session (34:26).
The Engineer Still Owns the Decision
Rob imagines more time spent reviewing changes generated from clear stories (15:11). He is not saying reviewers can stop understanding the system. The human still decides what the software should do, whether a shortcut is acceptable, and whether the behavior fits security, performance, and user needs. Agent-written code requires the same ownership as human-written code.
That is also why his advice is tool-agnostic (37:33): use the IDE, terminal, or agent interface that lets you inspect and test the work well. He likes atomic commits and a GUI for reviewing changes, even while using an agent for investigation. The better habit is not allegiance to a particular product; it is a repeatable path from requirement to evidence.
Track Usage Without Inventing a Per-Prompt Footprint
Rob also wants engineers to see the resource side of agentic work: tokens, compute, electricity, cooling, and the tradeoff between a quick manual edit and a long agent run (41:47). He helped build a token-usage extension. The link in the video's references points to an older listing; the current project is AI Engineering Fluency, with source on GitHub. Its documentation says some token counts come from APIs while others are estimated from session logs, and optional cloud synchronization is a separate setting.
The interview mentions Rob's roughly 30-million-token month and illustrative carbon and water conversions (44:15). Those conversions are not independently verified measurements of his workloads; token count alone cannot establish exact emissions or water use. The IEA's energy analysis treats data-centre demand as a scenario with uncertainty, not a fixed impact per prompt. Model, hardware, output length, data-centre efficiency, electricity supply, and cooling all matter. Use a tracker to spot waste and ask providers for better reporting, but do not turn a rough estimate into a precise environmental claim. Running a model locally can be worth testing; it is not automatically lower-impact without measuring the hardware and electricity used.
A Two-Week Team Experiment
- Pick one recurring change type. A small bug fix, test addition, or documentation update with clear success criteria.
- Record the baseline. Note elapsed time, review time, rework, defects, and deployment outcome for comparable recent changes.
- Write the acceptance check first. Capture current failure, expected behavior, important constraints, and the commands that verify it.
- Pair and inspect. Have one engineer drive the agent while another questions assumptions and reviews the diff. Keep permissions narrow.
- Follow through to production. Count not only agent time but also waiting, review, CI, rollbacks, support and defects.
- Decide from evidence. Keep the workflow if quality and total effort improve; change it if generated output simply moves the burden to reviewers.
Video Chapters
| Time | Discussion |
|---|---|
| 00:00 | Introduction and Rob's premise |
| 00:43 | What engineers misunderstand about AI |
| 02:09 | How much model theory engineers need |
| 03:58 | Learning by pairing and small examples |
| 05:26 | Tab completion versus agent mode |
| 07:03 | The productivity debate |
| 08:29 | The engineering job beyond writing code |
| 09:14 | Programming hours and the wider workflow |
| 11:02 | Review pressure when code arrives faster |
| 12:21 | Tests, technical debt, and quality |
| 13:39 | The customer's requirements bottleneck |
| 15:11 | The engineer as reviewer and owner |
| 17:00 | Revisiting AI after a poor early experience |
| 19:17 | LLMs, semantics, and attention |
| 22:41 | Why prompt and context quality matter |
| 24:20 | Rob's six-month learning estimate |
| 26:18 | The challenge for long-time engineers |
| 29:30 | Thinking in systems |
| 31:26 | Will progress in AI tools slow? |
| 34:26 | Pair programming with AI still matters |
| 35:44 | Tribalism around tools |
| 37:33 | Foundations over a favorite tool |
| 39:40 | Where the IDE still helps |
| 40:50 | The Windows blue-screen investigation |
| 41:47 | Environmental cost and missing visibility |
| 44:15 | Token tracking and estimated impact |
| 45:47 | Local and edge models |
| 46:48 | Choosing slower or lower-impact compute |
| 47:05 | Closing |
Copyable Workflow Brief
Use this to turn Rob's advice into one reviewable coding task, with evidence beyond generated-code speed.
One change, tested end to end
Define intent, permissions, checks, and reviewer evidence.
Sources and Limits
Interview: Rob Bos's full conversation, supplied transcript, and Rob's profile. Checked references: ActiveState's 2019 survey; the current AI Engineering Fluency extension and source; and the IEA energy and AI analysis. The older tracker listing supplied with the video is deprecated. Survey and footprint caveats above are editorial checks, not claims made by Rob. Sources checked 19 October 2026; no independent productivity trial of Rob's teams was performed for this article.