The AI Revolution - Hype, Probability, and the Illusion of Thinking

When I hear companies like Anthropic make claims that they don’t know why AI comes to some conclusion, or they suggest that Claude somehow “resorted to blackmail” to prevent itself from being shut down as featured on 60 Minutes, it makes me both angry and a bit fearful all at once. AI marketing, at least as it exists at the time of this article's writing, is filled with disingenuous assertions that create marketing leverage and product branding. It invokes fear, confusion, and hype. There's an important distinction being blurred here. We may not be able to trace why AI produces a specific response to a given prompt at any given time because of the sheer magnitude of steps but that is quite different than saying we don't know how it works. IT systems can suffer from the same problem, but thankfully they are much easier to solve because they are much smaller. Conflating the two is, at best, imprecise and at worst, deliberate. For example, it may be true that Anthropic's latest model Mythos, announced in April 2026, can find and exploit system vulnerabilities but introducing it with doomsday theater benefits them.

I’ll state upfront that I’m not an AI researcher. I haven’t designed and built frontier models, nor am I anti-AI. But I’m AI-adjacent, having been in the tech industry for quite a while and having a pretty general idea of what’s going on. I’ve also written my own document classification tool (github:J8k3/document-sorter) back in the pre-AI coding era, taking a much smaller-scale approach to model training. I've revisited that tool recently using AI assisted development and though I wasn't incredibly far off at the time, refined that tool to be more effective.

AI is not a sentient entity, full stop. It has no continuous consciousness. It is not sitting there thinking about you between requests. It is a request and response between a client and server, the inference layer, that invokes a model on the backend. In between, there is idle capacity, not a self-aware or self-thinking model.

However, it can be run iteratively to provide what seems like reasoned output as it processes its own prior responses. Mix that with a strategy to break down input into relevant pieces, tokenization, retrieval, and recursion, and you’ve got something that can look a lot like thinking. When you ask AI to do some task, or answer some question, it uses a very large statistical model, called a Large Language Model (LLM), to predict the next most likely token based on the training corpus, a massive body of human-written literature and/or code, used in its development.

Turns out humans have written an enormous amount of content over the past several thousand years, and there are patterns in language and code that make it predictable enough that a tool like AI can make inferred predictions about what comes next in increasing increments: words, sentences, paragraphs, or whole documents. That prediction is probability without authority or verification, not understanding which is where hallucinations come from. With sampling and weighting, developers introduce a degree of randomness into what the model predicts so that outputs are varied instead of identical every time. This makes responses feel more natural and less mechanical.

That means the training data has a massive impact on what the model produces, and this is where bias comes into play. If you feed the model writings from a particular period, culture, or worldview, it's going to reflect the biases present in that material. AI developers inject safeguards to skew responses away from those biases. But even that is simply testing outputs, sometimes with and sometimes without humans in the loop, against rules representing socially accepted norms of the present day. This is done through processes like reinforcement learning, where the model produces a response, it's reviewed, ranked, and sometimes rejected. If you've ever seen a model show you two responses and ask you to pick the better one, that's an example of reinforcement learning being outsourced.

How does AI make these predictions? An enormous mathematical representation is put together that represents relationships of tokens in training data. A token is a unit of data (input/output) which can be a word, part of a word, punctuation, etc. OpenAI provides an example of how text is tokenized https://platform.openai.com/tokenizer. It learns that given "X" token, probabilistically, "Y" is the next token. The model takes your tokenized input and produces a response. Sampling introduces controlled variability so responses are not perfectly deterministic. That is what gives it personality. Not consciousness.

Moving from ChatGPT to Claude

I’ve been using ChatGPT and Codex for a while and I’m starting to evaluate Claude. No conclusions yet. Getting started was rough. The desktop app would look like it was working and then throw “unable to connect,” and when I tried to subscribe the Stripe payment page wouldn’t load at all. Claude also had an outage around the same time, which didn’t help, but even after recovery things were still inconsistent. The real issue turned out to be my Pi-hole.

For anyone not familiar, Pi-hole is a DNS-level blocker. It sits in front of your devices and blocks ads, trackers, and a lot of third-party domains by default. That’s the point, but it also means anything that depends on those domains can partially or completely break.

Claude depends on more than just claude.ai. It pulls in additional domains for payments, telemetry, and chat, and Pi-hole blocks a lot of that in ways that fail silently. Quick way to confirm: disable Pi-hole for 30 seconds and reload. If everything suddenly works, that’s your cause.

Instead of chasing domains one at a time, I built a working allow list and published it here: https://github.com/J8k3/blog-code/blob/main/pi-hole/claude.txt. Add it and move on.

The outage and the Pi-hole blocking overlapped just enough to make debugging harder than it should have been. Separately, the status dashboard shows a steady stream of incidents. For something positioning itself as a serious productivity tool, that reliability signal matters, and right now it is not great. By comparison, ChatGPT comes across as more polished in this setup. In practice it appears to rely less on scattered third-party dependencies, so it behaves more predictably in a filtered network.

More once I’ve actually used it.

Cartes Bancaires Support in AWS Payment Cryptography

 AWS announced support for Cartes Bancaires in AWS Payment Cryptography. You can read the official announcement here: https://aws.amazon.com/about-aws/whats-new/2026/02/payment-cryptography-cartes-bancaires/

I was not there for the final announcement, but I was heavily involved in the work that made it possible.

A large part of that work was audit readiness and making sure the implementation would satisfy the requirements for approval. Cartes Bancaires was still developing their audit program while we were going through the process, which added complexity.

I worked directly with Deloitte through the review and was on every vendor call covering progress, evidence, gaps, and what was needed to get across the finish line. Most of the work is not visible from the outside. It was documentation, evidence, validation, follow-up, and making sure assertions matched what could actually be defended during audit. That work is rarely visible, but it is what makes launch possible.

Good Engineering Managers Don’t Leave the Technology Behind

As a manager of software teams, I’ve been asked many times about the transition from building software to managing the people who build it. It’s an existential question for a lot of engineers as they think about career growth: Do I become a manager, or do I stay technical?

That framing has always bothered me, because it assumes something I don’t believe to be true: that managing and continuing to develop technical depth are mutually exclusive.

It’s certainly possible to manage a software project with only surface-level technical knowledge. Plenty of organizations do exactly that. But in my experience, truly understanding the systems your engineers are working on is invaluable, both to the team and to the outcomes they deliver.

What Changes When You Become a Manager

The real shift isn’t from technical to non-technical. It’s a shift in how and where your technical skills are applied.

As an engineer, your leverage comes from the code you write. As a manager, your leverage comes from the decisions you enable, the risks you surface early, and the technical tradeoffs you help your team navigate.

That requires more than vocabulary-level familiarity. It requires enough depth to ask the right questions, recognize when complexity is creeping in, and understand when a problem is architectural versus organizational.

Why Technical Depth Still Matters

Teams know very quickly whether their manager actually understands the work. Not at the level of “could I implement this myself,” but at the level of “do you understand why this is hard, risky, or worth doing.”

Technical depth enables better judgment calls:

  • When a deadline is unrealistic versus merely uncomfortable.
  • When an incident is a one-off versus a systemic design issue.
  • When adding people will help, and when it will slow everything down.

It also builds trust. Engineers are far more willing to accept hard tradeoffs when they believe those decisions are informed by real understanding rather than abstraction.

The False Choice

The idea that you must choose between management and technical growth is mostly a product of how organizations structure careers, not a law of nature.

Some managers stop developing technically because their role no longer demands it. Others continue learning because it makes them better at prioritization, architecture discussions, and long-term planning.

I’ve always believed that the best engineering leaders stay close enough to the technology to understand its constraints, even if they are no longer the primary authors of the code.

Where I Landed

For me, management was not a departure from engineering. It was an expansion of scope.

The tools changed. The feedback loops got longer. But the core skill, understanding complex systems and helping them work better, remained the same.

If you’re an engineer facing this decision, my advice is simple: don’t assume you’re choosing between people and technology. The best managers I’ve worked with never did.

VPC Flow Logs: Use Them Intentionally

Note: I originally sketched this post years ago and never finished it. I’m publishing it now as a retrospective on how I think about VPC Flow Logs at scale.

VPC Flow Logs: Use Them Intentionally

For a long time, the default guidance in AWS environments was simple: enable VPC Flow Logs everywhere. At small to moderate scale, that advice is usually fine. At large scale, it becomes expensive, noisy, and often redundant.

There’s an inherent catch-22 with Flow Logs. If you don’t have them enabled, you miss historical data when you need it. If you enable them universally, you can generate massive volumes of duplicated traffic data that few teams ever analyze in a meaningful way.

At sufficient scale, AWS can perform network-level analysis across its infrastructure independent of whether an individual account is exporting Flow Logs. Because of that, Flow Logs are not always treated internally as a hard security requirement for every workload. I argued for that shift myself, mainly because the cost and operational overhead often outweighed the marginal benefit.

None of that makes Flow Logs pointless. It means they should be used deliberately.

Analysis vs. Compliance

I think of Flow Logs primarily as an analysis tool. If you have a compliance obligation that requires network traffic retention, or you have automated tooling that continuously analyzes Flow Logs for anomalies, they’re absolutely worth enabling.

If you don’t, you’re often collecting data “just in case,” with no realistic plan to review it. In that scenario, Flow Logs tend to become expensive cold storage rather than a security control.

Practical Guidance

  • If you’re unsure, enable them. When you’re actively troubleshooting or operating a high-risk environment, having the data is better than wishing you did.
  • Always manage retention. Don’t enable Flow Logs without S3 lifecycle policies. Expire or transition data aggressively. Thirty to ninety days is enough for most investigations.
  • Be honest about usage. If no one is looking at the data and no system is analyzing it, you’re paying for peace of mind, not security.

Used intentionally, VPC Flow Logs are valuable. Enabled blindly, they’re just another growing bucket of logs no one reads.

Amazon Web Services (AWS) Solutions Architect Professional Exam (SAP-C00)

Note: I originally wrote this post in 2017 but never published it at the time. Please note that the AWS certification landscape has changed significantly since then; this is provided strictly as a historical reference.

Another year another re:Invent. This year at re:Invent 2017, because my associate was up for renewal again, I decided to sit for the AWS Solutions Architect Professional Exam. The exam is in beta phase where questions are being tested, refined and the exam pass line is being set. I won't find out if I passed until March 2017 and I can't share actual exam questions but I can share advice for others that are interested in the exam in the future. Note that as of Jan 2017 the beta is currently closed as it's proved to be very popular.

Preparation:

I entered the exam cold, drawing only on my working knowledge of AWS and its services so my perspective should be an unbiased view of the exam. There is an exam blueprint but it's been pulled from the AWS website. 

Format:

  • ~3hr Exam Time
  • > 100 Questions
  • Reading Comprehension Questions
  • Question Nuances Where Important
  • Heavy Focus on Services and Service Components with Security Relationship:
    • IAM
    • WAF
    • CloudFront
    • ACM
    • Security Groups
    • NACLs
    • VPC
    • etc.

My Exam Perspective:

I found the questions to be very long, requiring significant reading and reading comprehension in order to answer questions. I also found the possible answers to be long and requiring reading comprehension. I had to read a number of questions at least twice to pickup on all of their nuances and be able to differentiate answer validity. The questions for the exam had some substantial parallels to security related questions on other exams.

AWS Payment Cryptography in Sydney and AS2805 Support

AWS announced AWS Payment Cryptography is now available in the Asia Pacific (Sydney) Region. You can read the official announcement here: https://aws.amazon.com/about-aws/whats-new/2025/12/aws-payment-cryptography-in-sydney/

This was a particularly difficult launch.

Not because of one major issue, but because there were a lot of moving pieces all happening at once. Hardware deployment issues, firmware rollout problems, feature dependencies colliding near the finish line, compliance requirements, launch timing, and the normal reality that things rarely line up as cleanly in practice as they do on a plan.

A lot of the work near launch was simply making sure everything that needed to happen actually happened, in the right order, without creating new problems somewhere else.

Regional expansion for a service like this is never just turning something on in another place. Every assumption around hardware, operations, and readiness gets tested again.

Those are usually the hardest launches. Not one big failure, just constant pressure across a dozen important things at once.

Multi-Region Keys in AWS Payment Cryptography

AWS announced Multi-Region Keys in AWS Payment Cryptography. You can read the official post here: https://aws.amazon.com/blogs/security/multi-region-keys-a-new-approach-to-key-replication-in-aws-payment-cryptography/

This was a meaningful launch because it crossed one of the boundaries AWS takes very seriously: Region isolation.

Replicating payment cryptographic keys across Regions meant moving highly sensitive customer material across a boundary that is normally treated as a hard line. That required a lot of design review, security scrutiny, and approvals. Moving critical customer data across Regions is not something anyone treats casually.

One of my engineers handled much of the implementation while I drove execution, launch readiness, and stakeholder alignment. Because the launch was time-sensitive, I had to stay deeply involved in approvals, resolving concerns, and making sure decisions were happening fast enough to keep the work moving.

A lot of the real work was not writing code. It was proving the design, defending the security model, and making sure the operational path was something we were actually willing to own long term.

Those are often the hardest launches.

Author’s Note: This article reflects my personal professional experience and opinions. While my insights are informed by my professional history, these views are my own and do not represent the official position of my former employer.

About the Author: Jacob Marks is an engineering leader with over 20 years of experience, including a decade at Amazon Web Services (AWS) where he led teams in EC2 Core Platform and the development of the AWS Payment Cryptography service.

Labels

.NET .NET 10 .NET 3.5 Active Directory AD DS Adoption AI AI Ethics AI Hype Alerts Amazon Cognito Amazon DLM Amazon Q Anthropic AppDomain Architecture Artificial Intelligence Asia Pacific Sydney ASP.net ASPxGridView Audit Readiness Auto Recovery Automation AWS AWS Certified AWS Lambda AWS Payment Cryptography AWS SDK AWS Security Specialty Azure Azure DevOps Server Backup BIG-IP C# Career Growth Cartes Bancaires CB Certificate Bundle Certification Claude Cloud Cloud Certification Cloud Hosting Cloud Security CloudWatch CLR Content Query Cost Optimization Credentials Database Defense Industry Deloitte Developer Tools Developers DevEx DevExpress DevOps DISA Disk Space DISM Distributed Systems DoD DoD CC SRG EBS EC2 Engineering Engineering Leadership Engineering Management EnPasFltV2 Enterprise Event Receiver Exam F5 Federal IT FedRAMP Fintech FISMA GAC Generative AI GitHub gMSA GovCloud Government Compliance GridView Hardware Security Modules HSM IAM Identity Management IIS Infra Infrastructure as Code IT Tools Jacob Marks JavaScript jQuery Lambda Leadership Linqpad LLM lsass.exe LTM Memory Optimization Mentorship Microsoft Migration Multi-Region Keys NACL Native AOT Network Architecture Networking NIST ODBC Open Source Payment Cryptography Payments PCI Compliance Performance Platform Platform Architecture Power Tools PowerShell Python re:Invent Reachability Analyzer Redshift Relationships List Replace Root Volume SAA-C00 SAP-C00 Security Security Group Serverless SES SharePoint SharePoint 2010 Site Reliability SMTP Snapshot Software Engineering Solutions Architect Solutions Architect Professional SP 2007 SPAWAR SSL STIG Storage Strategy Sydney SysAdmin Team Foundation Server Team Utilities Tech Industry Technical Depth Technology TFS Tools Troubleshooting Upgrade Visual Studio VPC VPC Flow Logs Web Development WebPart WinDirStat Windows Server Windows Server 2025 WinForms