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.

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.

Amazon Web Services (AWS) Certified Security Specialty (CSS) Beta Exam

*** NOTE: AWS has pulled this specific certification version, refunding those who took the original beta exam. ***

2026 Status Update: The AWS Certified Security - Specialty is now a mature, standard certification. While the beta period mentioned below ended years ago, the core focus on deep-dive security across IAM, Encryption, and Incident Response remains the primary objective of the current exam version.

I had the opportunity to take the AWS Certified Security Specialty Exam at re:Invent 2016. The exam was in a beta phase where questions were being tested, refined, and the exam pass line was being set. While I can't share actual exam questions, I can share advice for others interested in the certification path.

Preparation

I entered the exam cold, drawing only on my working knowledge of AWS and its services, so my perspective is an unbiased view of the exam's difficulty. While blueprints change, the foundational security pillars remain consistent.

Format

• Duration: ~3hr Exam Time
• Volume: > 100 Questions (Beta format)
• Style: Heavy focus on reading comprehension and identifying technical nuances.
• Service Focus: High concentration on services with direct security relationships:
  • Identity & Access Management (IAM)
  • AWS WAF & Shield
  • CloudFront & ACM (Certificate Manager)
  • Security Groups, NACLs, and VPC Architecture

My Exam Perspective

I found the questions to be very long, requiring significant reading comprehension to answer accurately. The possible answers were also lengthy, requiring careful differentiation to identify the most valid technical solution. There were substantial parallels to security-related questions found on the Professional-level Architect exams.