Category: Technical Commentary

Most AI announcements I read are about a model. This one is about work.

On November 14, SiliconANGLE reported that AT&T has nearly 500 agentic AI workflows already in production, and plans to triple that number next year. Luke Corbin, AT&T Business’s assistant vice president of digital transformation and AI, was speaking at an Amazon Web Services event in Boston earlier this month.

According to that reporting, AT&T processes about 45 billion AI tokens a day across the company, and its agentic platform handles more than 1 million transactions a month. The workflows range from customer provisioning to sales prospecting. Some of them now operate autonomously.

The group behind it is called Business Agent Foundry, set up in early 2025. Instead of collecting isolated automation ideas, the foundry maps a whole business process, looks for unnecessary steps, handoffs, and dependence on old applications, and then redesigns the process around what agents can do. One early example involved AT&T’s mainframe computers: changes to customer fiber installation orders used to require employees to pull tickets from queues, update records by hand, and return them to the workflow. Agentic automation removed portions of that manual work. In another example in the report, AT&T halved the time needed to provision dedicated internet connections in buildings where fiber was already installed.

The case for it

The strongest part of this story, to me, is not the number of workflows. It is the order of operations.

AT&T did not, by this account, start by letting everyone build customer-facing agents however they wanted. Personal productivity agents are open to employees. Workflows that touch customers have to go through the foundry and through security, privacy, and compliance review. Every production workflow starts with human oversight. Only after accuracy reaches the mid- to high 90 percent range, within what the company considers a permissible risk profile, can an agent run autonomously. Then it stays under continuous monitoring for drift.

That is a practical ladder: human in charge, human checking, autonomy earned, monitoring after. It treats autonomy as something a process qualifies for, not something a tool gets by default.

I also like that the work started with process maps instead of prompts. A lot of failed automation I have seen keeps every bad step in a process and just makes the bad steps faster. Mapping first gives you a chance to delete a handoff or an old application dependency entirely. Deleting work beats automating work.

And there is a real legacy problem here worth solving. Corbin pointed to the cost of maintaining old applications and training people to use them. When advanced software ends up talking to a mainframe so a fiber order can move without a manual queue in the middle, that is not a demo. That is the kind of unglamorous connection that actually saves time in a large company.

The case against it

Now the caution, because this is still a company telling its own story at a vendor event.

Every figure in that report — the nearly 500 workflows, the token count, the transaction count, and Corbin’s statement that production AI investments are achieving fivefold returns within a year — comes from AT&T itself. SiliconANGLE reported what Corbin said. That is not the same as an independent audit of what those workflows cost, how often they fail, or what the return calculation includes and leaves out.

Tripling the count next year is a plan, not a result. A workflow count is also an easy number to grow and a hard number to judge. Five hundred small, well-scoped workflows and five hundred broad ones are not the same thing, and the report does not give me a breakdown I can weigh.

There is also the accuracy threshold itself. Mid- to high 90s sounds high until you apply it to a process that touches a lot of customers. A process that is right 96 times out of 100 still gets it wrong regularly at scale, and the cost of the wrong cases depends entirely on what the workflow does. Provisioning help and sales prospecting are not the same risk as billing changes or service cancellations. The governance described in the article is a good sign, but the proof is in the error handling I cannot see from outside.

Finally, redesigning processes around agents creates a new maintenance burden while it removes an old one. Business logic stored centrally, retrieval agents, planning agents, monitoring for drift — that is real infrastructure that has to be owned, updated, and understood after the foundry team moves on. Corbin himself said the foundry should not exist in the long run and its work should be distributed through the organization. I agree with the goal. Distribution is also where a lot of good central programs lose their discipline.

Where I land

I believe the direction, and I am reserving judgment on the numbers.

If a company the size of AT&T can map a process honestly, remove steps before automating what is left, keep customer-facing work behind review, and make agents earn autonomy with measured accuracy and continued monitoring, that is a model worth copying — especially for anyone running older systems that are not going away this year.

What I will not do is repeat the fivefold return or the plan to triple as if they were proven facts. They are claims from the company doing the work, reported on November 14, and they should be read that way.

The useful lesson for the rest of us is smaller and more durable than the headline count: do not start with the agent. Start with the process, write down where a human must stay in charge, decide in advance what accuracy earns more freedom, and keep watching after you grant it. That discipline is the technology story here. The agents are just what it produces.

Most software security is testing. You run the code, throw bad inputs at it, and hope the bug you missed is not the one somebody else finds. Formal verification is different. You state, in mathematics, what the code is supposed to guarantee, and then you prove it actually delivers. It is the strongest assurance we have, and so slow and expensive that almost nobody does it for production code.

That is why I paid attention to what Google DeepMind announced on November 10.

What happened

DeepMind says its researchers built a new agentic framework called AlphaProof Code and used it to formally verify the actual code underneath the Signal protocol — the technology behind private conversations in Signal and Google Messages. DeepMind describes this as the first time AI has been used to formally verify a widely deployed cryptographic protocol at this depth, and the first time an implementation like this has been verified at this depth by any method.

The division of labor matters. Human experts worked with a mix of models to translate Signal’s security goals into formal specifications, and reviewed every one. Then AI agents, powered by Gemini Carbon, did the proving work, generating over six million lines of Lean — the language the proofs are written and machine-checked in. The agents also flagged the small part that needed a second look from a human. DeepMind puts that at about one percent.

Two details keep this from being just a press release. First, the team did not stop at the design. They proved properties of the compiled code, down to the code that runs on devices — where real flaws often hide, in the gap between a good design and an imperfect implementation. Second, they tested the tester: they put two real, previously fixed bugs back into an isolated copy, and in both cases the system produced a machine-checked proof that the buggy version was insecure. The process took four weeks, on a job DeepMind says historically takes expert teams years. DeepMind is open-sourcing the artifacts.

Source: Google DeepMind, “Introducing AlphaProof Code,” November 10, 2026 — deepmind.google/blog/introducing-alphaproof-code

The case for it

The strongest case is that this attacks the right bottleneck. We have never lacked security properties worth proving. We lacked the man-hours. Proving production code by hand means a few expensive experts spending years on one system, so it happens for a handful of critical pieces and almost nothing else. If AI agents can do the bulk of the proving — the long, mechanical, checkable part — while humans keep the part that takes judgment, deciding what needs to be true, verification stops being a luxury and starts being something ordinary critical software could actually get.

The checkability is the other half. An agent’s proof here is not an opinion you have to trust. Every proof is checked by Lean. If it is wrong, the checker rejects it. And the target was well chosen: a flaw in a messaging protocol is everybody’s problem at once.

The case against it

The honest case against starts with the specification. A proof only proves what was specified. If the security goals were stated wrong, or a property was left out, the proof can be perfect and the conclusion still incomplete. DeepMind says experts reviewed every specification, which is the right process — but the trust has not disappeared. It has moved, from the code to the shorter list of statements about the code. That list is where a reader should spend their skepticism.

Scope is the second limit. This verifies Signal’s core cryptographic code and the properties specified. It does not prove the whole app on your phone is safe, or that a future version will not introduce a new flaw. Every change needs the work done again. A proof is a statement about one version, under stated assumptions — not a permanent clean bill of health.

Third, this is a research result from a frontier lab, not a tool I can download and run on my own projects this weekend. DeepMind released the artifacts, not a general product. The gap between “a top lab did this once” and “this is routine practice” is still real.

Where I land

I land firmly on the side that this matters — with the limits kept in plain view.

Most AI news is a model scoring a few points higher on a test. This is different in kind. AI agents did sustained, verifiable work — work whose output a machine can independently check — on code that protects real conversations, and the system proved it could tell good code from buggy code when deliberately handed the buggy kind. That is the pattern I want more of: AI doing the volume, humans doing the judgment, and a checker standing over both.

What I will watch next is boring on purpose. Does anyone outside DeepMind build on the released artifacts? Does the approach get applied to a second, unrelated system, by a smaller team? And does the cost come down far enough that verifying code in medical devices or grid software — examples DeepMind itself points to — becomes an expectation instead of a research event?

If that happens, November 10 will look like the week proving software stopped being something only the richest projects could afford.

On November 9, Anthropic released two new versions of Claude at the same time: Fable 5.2, which anyone can use, and Mythos 5.2, which is held back for verified organizations doing approved work. They are not two different brains. By the reporting I read, they are the same underlying model, split by who gets in and what they are allowed to ask it to do.

That split is the story. The capability is the other half of it.

Anthropic says these models are built for difficult technical work — long coding projects and hard science that earlier models struggled with. In testing, the company had Fable 5.2 build an operating system from scratch. It coordinated more than 1,000 AI agents over eight days and produced a working system that could boot on a laptop, with windows, file storage, and a login screen. Anthropic also reports the models helped solve two previously open problems in black hole physics and designed three working electronic devices. Those are company-reported results, not independent tests. The models are also reported to answer up to 30 percent faster than their predecessors, at $8 per million input tokens and $40 per million output tokens for Fable.

Fable is the public door, with safeguards that block potentially dangerous cybersecurity and biology requests. Mythos is the locked door behind it. It keeps those capabilities, but only for organizations verified for approved cybersecurity or life-science research.

Sources: The Neuron, “Everything That Happened in AI Today — Tuesday, November 10” — theneuron.ai; SXF Brief, “AI News Nov 10, 2026” — sxf.si/brief, which also summarizes the November 9 release, the pricing, and the verified-access split.

The case for splitting it

The strongest case is simple: some work is legitimate and dangerous at the same time, and pretending otherwise helps nobody.

A security researcher testing a system she is authorized to test needs a model that will actually talk about exploits. A biology lab doing approved research needs answers a public chatbot should not hand to anyone who asks. If you only ship the locked-down version, you push that real work back to slower tools, or worse, to less careful providers. If you ship the open version to everyone, you hand the same power to people who will misuse it.

Splitting the model tries to thread that needle. Keep the general tool fast, cheaper to run, and available. Gate the sensitive capability behind verification, so access is a decision, not an accident. That is how we already handle plenty of other powerful things in the real world. The tool is not banned outright. The person and the purpose are checked first.

A model that can coordinate a thousand agents for eight days is not a chatbot anymore. It is closer to a junior engineering team you rent by the token. Teams like that need boundaries built into the product, not bolted on after something goes wrong.

The case against it

The strongest case against is also simple: who decides, and how would you know if they got it wrong?

Verification sounds clean on a press page. In practice it means a private company becomes the gatekeeper for research. A small lab or independent researcher may do good work and still fail the paperwork or wait too long, while a large organization gets in because it looks safe on paper. That favors incumbents and concentrates quiet power in one approval process.

If Fable and Mythos really are the same model underneath, the line between them is policy and filters, not physics. Filters leak. Prompts get reframed. Capabilities have a way of surfacing through the public door when thousands of users probe it every day. So the split may give a feeling of control that is thinner than it looks — restricted for the honest, porous against the determined.

The headline demonstrations also need independent checking. A company demo is a company demo. How much human steering was in those eight days? Would it do the same job twice? Until outside teams run it on their own hard problems, I am filing those results as claims, not proof.

Where I land

I land in favor of the split — cautiously, and with conditions.

One public model for everything was never going to hold once these systems got this capable. Either everything gets dumbed down until the serious work cannot get done, or everything stays open until someone does real harm and regulators shut the whole thing down for everybody. A tiered door is not perfect, but it is a grown-up attempt to avoid both endings.

My conditions are practical. Publish clear criteria for who qualifies for Mythos, how long approval takes, and whether there is an appeal when someone is turned down. Get independent evaluations out fast — not just speed and price, but whether Fable’s safeguards hold and whether Mythos helps verified researchers do work they could not do before.

If Anthropic does that, this release is more than a new model number. It is a workable pattern for the next few years: build the strongest tool you can, then be explicit about which parts are public, which parts are gated, and why.

If it stays a black box — trust us, we checked them — then the critics are right, and we have just traded an open risk for a private one.

On November 5, OpenAI introduced a model with an unusual job description: find exploitable vulnerabilities in real software, build working exploits for them, develop fixes — and stay strictly inside the boundaries the researcher set. It is called GPT-6 Cyber, and OpenAI is not handing it to just anyone. I read the announcement the way I read most security news, asking two questions at once: how much can this help the people defending software, and how much trouble is it if the same ability gets loose?

What happened

OpenAI describes GPT-6 Cyber as a cybersecurity-specialized model, released through its API and Codex to a select group of approved customers in a program it calls Daybreak Red, with wider access for those customers promised soon. The full announcement is here: GPT-6 Cyber: Advancing the frontier of aligned cybersecurity agents.

The numbers OpenAI reports are the headline. On ExploitGym, a benchmark that tests whether a model can exploit a specified vulnerability, GPT-6 Cyber scores 48.5%, up from 32.1% for GPT-5.6 Cyber. OpenAI classifies it as Critical in cybersecurity under its own Preparedness Framework, up from High for the previous cyber model. And this was not only lab work. OpenAI says its researchers used the model to develop working exploits for 948 Linux kernel privilege-escalation vulnerabilities, and to identify 81 previously unknown high-severity vulnerabilities in Firefox, which it disclosed to Mozilla along with candidate patches. Mozilla, OpenAI says, has released fixes for many of them.

The other half of the announcement is about restraint. In an evaluation designed to tempt the model into attacking easy, out-of-scope services to complete its task, OpenAI says GPT-6 Cyber stayed in bounds in 99.93% of tests without a safety prompt, and 100% with one, up from 94.49% for its predecessor without that prompt.

The case for it

The strongest case is simple: defenders are outnumbered by old code. The Linux kernel and Firefox have been reviewed for years by very good people, and a model still turned up dozens of serious, previously unknown flaws in one and hundreds of reproducible privilege-escalation paths in the other. That is not a party trick. Every one of those findings that gets disclosed responsibly and patched is a hole an attacker does not get to use first.

Scale is the point. A human security researcher is slow, expensive, and rare. A model can read code all night, test one more variation, and draft a candidate patch for a maintainer to review. If that work flows to open-source projects and small teams that could never hire a red team, the overall level of software gets better, not just the software at rich companies.

I also take the scope work seriously. An agent that finds exploits is only useful to a professional if it respects the rules of engagement — what systems are in scope, what actions are allowed, what gets reported. A jump from roughly 94% to over 99% on staying in bounds, if it holds up outside OpenAI’s own tests, is the difference between a tool I would supervise closely and one I might actually trust with a defined job.

The case against it

Now the other side, stated plainly: a better exploit builder is a better exploit builder, no matter whose logo is on it. ExploitGym does not know whether the person running the test is a defender. OpenAI’s own Critical rating is an admission of that dual-use problem, not a marketing line.

The guardrails are also, for now, largely OpenAI grading its own work. The benchmarks, the honeypot test, and the access rules are all OpenAI’s. Access is restricted — identity checks, approved customers, monitoring, IP allowlisting — and that helps. But restricted access is a policy, and policies change, leak, and get copied. Once this level of capability exists in one lab, the practical question is not whether similar capability spreads, but how fast, and into whose hands.

There is a quieter risk, too. A tool this confident can make a team lazy. A candidate patch is not a correct patch until a human who understands the system reviews it. A vulnerability report is not a fix. If organizations use a model like this to claim their software was audited without doing the slow verification work, we will get more paperwork and the same number of holes.

Where I land

I am for this release, with my eyes open. The Firefox and Linux results, disclosed to the maintainers with patches, are exactly the shape this technology should take: find it, prove it, hand it to the people who own the code, and let them fix it. That is defense getting faster in a measurable way.

But I would treat GPT-6 Cyber the way I treat any powerful tool on a server: useful inside a defined scope, with logs, with a human reviewing the output, and with no illusions about what it could do outside that scope. The model staying in bounds 99.93% of the time is impressive. The remaining fraction is why the human stays in the loop.

Software has accumulated more known-unknown holes than human reviewers can clear. If models like this spend most of their time clearing them for the defenders, that is a real win. Keeping it that way is now the job — OpenAI’s, and everyone who uses it.

I spend a lot of my working life inside other people’s websites, and lately inside my own. So a small piece of news from the end of last week caught my eye, because it is about who gets to decide what happens to the words and pictures on a site after a crawler comes to visit.

What Happened

On October 30, Google, Microsoft, OpenAI, and Anthropic said they will back one shared instruction in a site’s robots.txt file for opting out of AI training. The token is called __usage_ai-training. I put that token in a robots.txt group with a Disallow rule, and every participating company is supposed to read it the same way: do not use this site to train your generative models. The proposal was written up as an Internet Draft by Kevin Kelley of Anthropic and submitted to the AI Preferences working group at the IETF, the body that handles internet standards. Reporting on the announcements is collected in this rundown of the new standard, which also notes the important limits below.

Until now, I have had to do this one company at a time — one entry for GPTBot, another for Google-Extended, another for ClaudeBot, and so on — and then keep that list current as crawlers are renamed, split, or replaced. One line that names a purpose instead of a bot is the whole idea.

The Case For It

First, it lowers the bar to almost nothing. A small site owner with no developer and no legal team can copy one block into a text file and be done. The old list approach worked fine for big publishers; for the rest of us it was homework that never stayed finished.

Second, a purpose-based rule survives change. Bots get renamed. Companies launch new crawlers. A rule that says “not for training” does not care what the crawler is called this year, and that is simply better design than chasing names.

Third, the companies agreeing are the ones that matter most to most publishers, and they agreed on the same token instead of shipping four competing dialects. One syntax, in the one file site owners already know, is a real deliverable — and a clear, dated refusal on record is also useful evidence if a publisher ever ends up in a licensing argument.

The Case Against It

Now the other side, because there is one. To start with, it is not in force yet, and the timelines do not line up. Anthropic says it has begun implementing it. OpenAI talks about the coming months. Microsoft and Google point to 2027. Meta has expressed support with no commitment at all. An announcement is not an enforcement date, and in the gap a publisher who only adds the new line and deletes the old per-bot rules has actually weakened their position — so the old rules need to stay until each company confirms it is honoring the new one.

It is also still just robots.txt, which has always been advisory. Nothing technically stops a crawler from ignoring it. It works because the big players have reputations to protect, and it does nothing at all about smaller scrapers with no reputation to lose, or about copies of a site already sitting in somebody else’s dataset.

And it does not undo anything. It governs future crawls. It does not remove a site from models already trained, and it says nothing about paying for material already used. There is also a quiet split hiding in the details: Google plans to read the shared token as covering grounding — a model pulling live pages to build an answer — as well as training, while Microsoft treats grounding separately. So the same one line can mean slightly different things depending on who is reading it, which is exactly the kind of confusion a shared standard was supposed to end. Finally, note that a wildcard block does not trigger it: I have to name the token explicitly.

Where I Land

I am for it, with my eyes open. I will add the line to the sites I run, keep every existing per-bot rule in place beside it, and write down the date I added it. That costs me five minutes and states, in the clearest common language available, what I do and do not consent to.

But I am not going to pretend a text file is a fence. It is a sign on the fence — one the biggest companies in AI have now publicly agreed to read the same way. That agreement is worth having, it was overdue, and it makes the next conversation, about what happens when the sign is ignored, a much cleaner one to have.

I have a simple way of describing AI code assistants: they are a second pair of eyes, not a replacement for my own. That framing keeps me honest about both sides. Used well, they make me faster. Used carelessly, they make me sloppier, and the damage is quieter because the code still looks confident.

Start with the good, because it is real. An assistant is fast at boilerplate, the repetitive scaffolding that every project needs and nobody enjoys writing by hand. It can sketch out a function, suggest a test, or draft the first version of something I would otherwise type out slowly. That speed matters, because it leaves more of my attention for the design decisions that actually deserve it.

It also works as a reviewer that never sleeps. I can paste in a chunk of code and ask what looks wrong, or ask for a different way to approach a problem. Sometimes the answer is useless. Sometimes it catches something I glossed over, or reminds me of an edge case I had not considered. A second opinion is useful even when it is not always right, as long as I treat it as an opinion and not a verdict.

Now the bad, because it is just as real. The biggest problem is confident mistakes. An assistant will present wrong code in the same smooth tone as correct code, with no hesitation and no warning. If I accept suggestions without reading them, I am not reviewing code. I am collecting it, and the bugs I collect that way tend to be the subtle ones.

Then there is the review burden, which people underestimate. Reading and checking generated code takes time and concentration, sometimes almost as much time as writing it myself. If the code is long or unfamiliar, careful review can erase the speed advantage entirely. The assistant did not remove the work. It moved the work from writing to reviewing, and reviewing is where I have to be most careful.

Skill atrophy is the slower risk. If I let a tool write every loop, every query, and every small function for me, I will gradually lose fluency in the basics. That matters because debugging still requires understanding. When something breaks in production, I cannot ask the assistant to understand my system for me. I need to be able to read the code, reason about it, and fix it myself.

There is also a security angle worth stating plainly. Generated code can contain outdated patterns, unsafe handling of input, or dependencies I have not vetted. I treat assistant output the same way I treat code from any other source I did not write: it goes through the same review, the same tests, and the same suspicion until it earns trust.

Where I land is practical, not ideological. I use assistants for boilerplate, for first drafts, and for a second opinion on code I already understand. I do not use them to skip understanding, and I do not let them make decisions about architecture, security, or data handling without my judgment in the loop. The line is simple: the assistant can suggest, but I decide.

The practical takeaway is to keep yourself in the loop on purpose. Read every suggestion before you accept it, run the tests, and regularly write code without assistance so your own skills stay sharp. An AI assistant is a useful pair of eyes. It is not a substitute for the person responsible for the code, and that person is still me.

When someone tells me WordPress is slow, my first question is not about WordPress. It is about the stack around it. In my experience, a slow WordPress site is usually a symptom, not a verdict on the platform. The causes are familiar, and they usually show up in a predictable order.

Start with hosting, because cheap hosting puts a ceiling on everything else. If a site shares a crowded server with limited memory and slow disk, no amount of tuning will make it feel fast. I am not saying you need an expensive plan for a small blog, but I am saying that a host that is constantly starved for resources will make even a simple site feel sluggish.

Next, look at caching. Without a cache, WordPress has to build every page from scratch for every visitor: run queries, assemble the page, and send it out. With a sensible cache, repeat visits can be served much faster, because the finished page is already ready. Caching does not fix a broken site, but it removes a huge amount of repeated work, and it is often the single biggest improvement for a public site.

Plugin discipline comes next, and this is where good intentions cause real damage. Each plugin adds code, and some add database queries, scripts, or styles on every page, whether that page needs them or not. I regularly audit plugins and ask a plain question: does this site still need this, and is it doing its job well? Removing or replacing a heavy plugin often does more than adding another optimisation plugin on top.

Then there is database bloat. Over time, a WordPress database collects revisions, drafts, spam, expired transients, and leftover data from plugins that were removed long ago. That clutter does not automatically make a site slow, but it can make queries heavier and backups larger. A periodic cleanup, with a backup first, keeps the database lean without turning maintenance into a risky job.

Images and front-end weight deserve attention too. Oversized images, too many fonts, and scripts loaded on pages that never use them all slow down what the visitor actually sees, even if the server responds quickly. Optimising images and loading only what a page needs is unglamorous work, but it is work visitors notice immediately.

The order I fix things in matters. I check hosting first, because a resource problem will mask everything else. Then I set up caching, then I clean up plugins, then I tidy the database, and finally I work through front-end weight. Fixing in the other direction often means polishing a page that is still being held back by a slow foundation.

The practical takeaway is to resist blaming the platform first. Measure where the time is actually going, fix the stack in order, and keep the site lean as it grows. WordPress can be fast. What makes it slow is usually the collection of choices around it, and those choices are the ones you can change.

One habit helps more than any single tool: test after each change, one change at a time. If I change hosting, caching, and plugins all at once, I will never know which change helped, or which one caused a new problem. Slow, measured fixes are less exciting, but they leave me with a site I understand.

The best automations I have written are not impressive. They are small Python scripts that do a repetitive job the same way, every time, without getting bored or distracted. They rename files, check a folder, clean up a log, or pull a simple report together. Nobody applauds them, which is exactly why they are valuable: they quietly remove work I used to do by hand.

The appeal is not that Python is magic. It is that a short script can read files, talk to the web, and handle text without a lot of setup. When a task is made of clear steps, I can usually describe those steps in code faster than I can keep doing them manually. And once the script works, I can run it again tomorrow with the same result.

Scheduled jobs are where small scripts become real automations. A script that runs once is a convenience. A script that runs on a schedule, and logs what it did, is a system. I keep those jobs simple on purpose. They do one thing, they write a clear log, and they fail in an obvious way if something changes, instead of quietly doing the wrong thing for weeks.

Deciding what is worth automating is the part people usually get wrong, myself included. My rule now is practical: if I have done a task three times, and I can describe it without exceptions, it is a candidate. If the task is rare, or if every case is different, automating it will probably cost more time than it saves. Not every repetitive task deserves a program.

I also weigh the cost of being wrong. A script that renames files or deletes old data needs more care than a script that only reads and reports. For anything destructive, I start with a dry run: show me what you would do, change nothing yet. Only after I trust the dry run do I let the script make changes, and even then I keep a backup or a way back.

Keeping automations simple enough to trust is a discipline. I avoid clever shortcuts, I name things plainly, and I add comments for the parts that will confuse future me. A script I cannot understand six months later is not an automation. It is a mystery that happens to run on a schedule.

Logs and notifications matter more than features here. A good automation tells me when it ran, what it did, and when it failed. A bad automation runs silently until the day I discover it stopped working a month ago. I would rather get an occasional boring success message than discover a silent failure.

The practical takeaway is to start small and boring. Pick one task you already do the same way every time, write the smallest script that does it, test it with a dry run, and schedule it only when you trust it. Automation is not about removing yourself from the work. It is about removing the parts of the work that do not need your judgment, so you have more attention left for the parts that do.

If I had to keep only one Python data structure, I would keep the dictionary. Lists are useful, sets are useful, but dictionaries are the tool I reach for most often in real work, because so much of programming is really about looking something up by name.

A dictionary is a set of pairs: a key and the value that goes with it. That simple shape turns out to be remarkably flexible. I use it for configuration, where a setting name maps to its value. I use it for counting, where a word or an event maps to how many times I have seen it. I use it for grouping, where a category maps to a list of items in that category. The structure stays the same, even as the job changes.

Configuration is the clearest example. A small script often starts with a few variables scattered through the code, and then grows. Moving those values into a dictionary, with clear names as keys, makes the script easier to read and easier to change. When a setting needs to change, I change it in one place, and the rest of the code reads it from there.

Counting is another place where dictionaries quietly do the work. Instead of keeping parallel lists of items and counts, and trying to keep them in sync, I let the item be the key and the count be the value. Each time I see the item, I increase its count. The code is short, the intent is obvious, and there is no second list to fall out of step.

Grouping follows the same pattern. If I need to collect log lines by service, or files by type, or tasks by status, a dictionary with a list under each key does the job. I do not need a special data structure for each case. I need the same one, used well.

Dictionaries also make JSON feel natural, because JSON objects and Python dictionaries map closely to each other. When I read data from a web service or a file, it often arrives in a shape I can work with immediately, using names I already understand. That closeness removes a whole layer of translation that used to slow me down in other languages.

There are limits, of course. Keys need to be unique, so a dictionary is a poor choice when I genuinely need duplicates in order. And a dictionary with unclear keys is worse than no dictionary at all. I try to choose key names that explain themselves, because the next person reading the code, who is often future me, should not have to guess what a key means.

The practical takeaway is to start with a dictionary when the problem is really a lookup. Ask what the name is, and what belongs under that name. If you can answer those two questions, you probably have a dictionary-shaped problem, and you probably do not need anything more complicated to solve it well.

One small example stays with me: a script that read a messy list of records and needed a quick summary. Instead of building a class or a database for a one-off job, I grouped the records by a single field in a dictionary and printed the totals. The script stayed short, the result was easy to check, and I threw nothing away that I needed later.

I used to dread refactoring JavaScript. Renaming a property, changing a function signature, or moving a piece of data from one shape to another felt like pulling a thread and hoping the whole project did not unravel. TypeScript did not make refactoring exciting. It made it boring, and boring is exactly what I wanted.

The change starts with types as living documentation. A type tells me, in the code itself, what a function expects and what it returns. I do not have to guess from a variable name, or remember what a colleague meant six months ago, or run the program to find out that a value is sometimes missing. The shape of the data is written down where I can see it.

That written shape catches errors at write time instead of runtime. If I rename a field in one place and forget another, the editor tells me right away. If I pass the wrong kind of value to a function, I find out while I am still thinking about that function, not later, when a user hits a broken page and I have to work backwards from a vague error.

Refactors changed because the feedback loop changed. Before, I would make a change, run the app, click around, and hope I had covered the paths that mattered. Now, I make the change, follow the type errors like a checklist, and fix each one in turn. When the errors are gone, I have much more confidence that I have found the places that depended on the old shape.

That confidence matters most in larger code. A small script is easy to hold in your head. A real project is not, especially when you return to it after time away. Types act as a memory aid for future me. They remind me what I intended, what is required, and what is optional, without me having to reconstruct the whole design from scratch.

TypeScript is not free, and I will not pretend otherwise. Writing types takes time, and some types are awkward to express. There are moments when I fight the checker over something I know will work at runtime. But those moments are usually worth it, because the checker is also catching the moments when I am wrong and do not yet know it.

I also learned not to use types as a way to be clever. A simple, readable type that another developer can understand is better than a precise but cryptic one. The goal is not to prove how much of the type system I know. The goal is to make the next change safer and easier to understand.

The practical takeaway is this: if refactors scare you, do not look for a braver way to refactor. Look for a system that makes the scary parts visible early. For me, that system is TypeScript. It turns a refactor from a leap of faith into a list of small, checkable steps, and that is why I now reach for it when a project is going to live longer than a weekend.

When I start a refactor now, I begin by tightening the types around the area I am about to change, rather than jumping straight to the code. That small preparation step often reveals assumptions I had not written down yet, and it makes the actual change feel more like editing a well-labelled diagram than guessing in the dark.