Writings, Regrets, and Re-skillings during the AI Revolution

Author: Professor Lamb

  • ChatGPT at Work 5: Verify Before You Act

    ChatGPT can assist with consequential work, but it cannot assume responsibility for the result. Check important facts, calculations, citations, assumptions, privacy risks, and recommendations before using an output. Document verification when the stakes are high.

    Do not upload confidential, regulated, or personally identifiable information unless the organization has approved the tool and the handling process. For an IT example, before using ChatGPT to prioritize security incidents, verify the severity calculations, protect names and device identifiers, check the supporting evidence, and require a qualified analyst to approve any action that would isolate a device, disable an account, or reset credentials.

    Human review is not a ceremonial final click. A person remains responsible for decisions affecting customers, employees, money, access, compliance, or business operations. Good governance means deciding in advance what the AI may recommend, what it may draft, what it may never do on its own, and who is accountable for checking the result.

  • ChatGPT at Work 4: Turn Good Prompts Into Workflows

    A successful prompt is useful once. A documented workflow can be useful every week. Turn repeatable ChatGPT work into a process that specifies inputs, steps, quality checks, outputs, ownership, and the points where a person must review or approve the result.

    An IT service team, for example, could create a weekly ticket-triage workflow that imports de-identified support records, checks required fields, groups tickets by affected service, counts recurring issues, flags possible security incidents, drafts a manager summary, and routes urgent items using an approved template and review checklist. Projects, skills, templates, and approved business tools can help another team member run the same process consistently.

    The real productivity gain comes from improving the whole workflow, not merely generating text faster. Measure time saved, error reduction, consistency, and output quality. If the workflow saves ten minutes but creates an hour of verification work, it is not an improvement. A repeatable AI process should make the work more dependable as well as faster.

  • ChatGPT at Work 3: Start With the Business Question

    Uploading a spreadsheet is not the same as defining an analysis. Start with the business question, then provide the relevant spreadsheets, reports, PDFs, logs, or customer feedback. Ask ChatGPT to inspect data quality, identify patterns, calculate appropriate results, create useful visualizations, and explain the evidence in plain language.

    For an IT example, upload a de-identified spreadsheet of monthly help-desk tickets by service, location, priority, resolution time, and reopen status. Ask ChatGPT to flag missing or inconsistent values, calculate month-over-month changes, identify services with rising ticket volume or repeat incidents, create two suitable charts, and produce a one-page briefing with three evidence-based actions.

    Require a useful deliverable—a cleaned table, dashboard outline, executive summary, or prioritized action list—rather than a collection of observations. Then spot-check the calculations and make sure the analysis does not confuse correlation with cause. Useful analysis connects data to a business decision without pretending that the data says more than it does.

  • ChatGPT at Work 2: Make It Show Its Sources

    Research with ChatGPT should begin with current, trustworthy sources. Ask it to identify publication dates, authors or issuing organizations, methods, versions, and limitations. Request citations or links, distinguish established facts from interpretations, and compare conflicting evidence rather than forcing a single conclusion.

    This discipline is especially important in IT, where vendor documentation, product versions, vulnerabilities, and recommended configurations change. Suppose a manager is deciding whether to replace an on-premises file server with a cloud document platform. Ask ChatGPT to compare current vendor documentation, government security guidance, and independent technical analysis; identify which claims come from vendors; explain where the sources disagree; and list the questions that still require a pilot or local test.

    The goal is not a pile of links. The goal is a decision-ready summary that explains what is known, what remains uncertain, why the differences matter, and what action the evidence actually supports.

  • ChatGPT at Work 1: Define the Job

    A useful ChatGPT prompt starts by defining the job. State the goal, audience, context, source material, constraints, and desired output before asking ChatGPT to begin. Describe the work in concrete terms, provide relevant background and reference samples, and specify requirements such as length, tone, format, deadline, evaluation criteria, and prohibited content. Explicit constraints reduce guesswork and avoidable revisions.

    That matters in IT because a vague request can conceal important operational choices. Instead of asking, “Write an MFA rollout plan,” ask, “Create a 60-day MFA rollout plan for a 150-person company using Microsoft 365. Use the attached device inventory and support-hours schedule. Include pilot users, communications, enrollment support, exception handling, rollback steps, owners, deadlines, and success metrics. Do not assume that every employee has a company-owned phone.”

    The longer prompt is not automatically better because it is longer. It is better because it tells ChatGPT what problem it is solving, what evidence it may use, what boundaries it must respect, and what a usable result looks like.

  • Before and After Networks 10: The Telephone, From Circuits to Packets

    To close this series, the deepest example I know: the telephone. For its first hundred-plus years — from Bell’s patent in 1876 — it worked one way, called circuit switching. Then, in about fifteen years, it quietly became something else entirely. It is my favorite before-and-after story because you can put dates on the flip.

    Circuit switching meant one dedicated path, reserved end to end for the whole call. The first commercial exchange opened in New Haven in 1878 with human operators plugging that path together by hand; Almon Strowger’s automatic switch (1891) mechanized them away, and by 1951 you could dial long distance yourself. The 1962 T1 carrier digitized the trunks: every call got a guaranteed 64 kbps channel in each direction, held even while nobody was speaking. Capacity equaled circuits — when the trunks filled, you got a busy signal — and long distance was priced by miles times minutes, which is why an earlier generation called after 7 p.m. to save money. A phone number was a place on a wall.

    Packet switching inverted all of it. The idea dates to the early 1960s (Kleinrock, Baran, and Davies, who coined the term); the ARPANET carried its first packets on October 29, 1969; TCP/IP was designed in 1974 and became the rule on January 1, 1983. The 1984 breakup of AT&T cracked the pricing model, and dial-up modems spent the 1990s smuggling data over voice circuits. Then the smuggling reversed: commercial VoIP arrived in 1995, Skype in 2003, and VoLTE around 2012 — meaning the “phone call” on your cell phone today is literally packets. Carriers are now retiring the copper circuit network itself, with AT&T aiming to shut most of it down by 2029. Distance is nearly free, a number follows a person instead of a place, and voice is just one app among many.

    The design bet underneath is the whole story. Circuits reserve capacity: guaranteed quality, wasteful in every silence, and a flat refusal — the busy signal — when full. Packets share capacity: radically efficient, best-effort, degrading gracefully instead of refusing. Best effort won because sharing is cheaper by orders of magnitude and smart endpoints can paper over the rough edges with buffers and codecs. Intelligence moved from the core of the network to its edge, and that single inversion is why the wire that once carried one conversation now carries everything. My entire intro networking course is, in a sense, a footnote to that trade.

  • Before and After Networks 9: When Things Break

    Failure used to be local. That was not a design achievement — it was a side effect of disconnection.

    Before networks, problems and outages often took longer to fix, but their effects were usually limited to one place or one organization. A crashed system was somebody’s bad day, not everybody’s.

    Now, because systems are connected, one outage, software failure, or cyberattack can affect millions of people at once. A single bad update can ground airlines and close pharmacies on the same morning.

    The links that share resources also share failures — coupling is the price of connection. Resilience used to come free with isolation; now it has to be designed in deliberately, with redundancy, backups, and people who think about failure for a living. This is a large part of why network engineers exist.

  • Before and After Networks 8: The Pace of Life

    Waiting used to be a normal, unremarkable part of everyday life. It was built into everything.

    Before networks, messages, information, purchases, and decisions simply took more time. People were accustomed to waiting days or even weeks, and life was arranged around those delays.

    Now people expect immediate answers, rapid delivery, and constant access. The convenience is real, and so are its byproducts: distraction, impatience, and pressure to be continuously available.

    We engineered the waiting out of our systems, and some of the patience out of ourselves. The latency of ordinary life fell from days to milliseconds, and expectations fell with it. I ask my students whether instant is a feature or a treadmill; the honest answer is usually both.

  • Before and After Networks 7: Getting Around

    Planning a trip used to start days before you left, with paper.

    Before networks, travelers used paper maps, contacted travel agents, and consulted printed bus, train, and airline timetables. Getting lost often meant stopping to ask a stranger for directions.

    Now GPS apps provide turn-by-turn directions, live traffic reports, real-time transit updates, and instant travel reservations. The route recalculates before you have finished missing the exit.

    A paper map is a snapshot; a navigation app is a live feed. Navigation became a real-time data service, and the map now updates faster than the road does. The quiet cost is that we outsourced our sense of direction to the network — when it is down, we are more lost than our grandparents ever were.

  • Before and After Networks 6: Entertainment

    Entertainment used to run on schedules and shelves. You showed up when the program did.

    Before networks, people watched programs according to printed television schedules, rented movies from video stores, and owned physical media — VHS tapes, records, DVDs. Missing the broadcast meant waiting for the rerun.

    Now streaming services, online games, podcasts, and social media provide entertainment on demand, almost anywhere. The Friday night trip to the video store has been replaced by the infinite menu.

    The scarcity was never natural. Channels, time slots, and shelf space were technical constraints, and when networks dissolved them, the gatekeepers went too. Anyone can publish a show now. The hard part — and the new business — is getting anyone to watch it.