willempienaar

Phew, for a second there I felt bad for them!

Also, the “cell” in Generic Cell Rate Algorithm is an ATM cell. GCRA is 1990s telecom, the scheduling algorithm ATM switches used to check that 53-byte cells were arriving on the wire at the agreed rate.

Yes. Alt-tab makes MacOS actually usable

Cleric | https://cleric.ai | Staff SWE, AI | Staff SWE, Product | Founding Marketer | Staff Designer | SWE, Backend | SF Onsite (Designer Remote)

Engineers can't keep up with their production environments: dozens of services, dashboards everywhere, alerts firing constantly. The information to diagnose most issues already exists, but finding it takes longer than fixing the problem. And the more AI-generated code ships, the more services get deployed by people who won't be around to debug them.

Cleric connects to your existing observability stack, autonomously investigates production incidents, and tells engineers what's wrong. We're well funded with years of runway, a small team of AI and infrastructure veterans in SF, growing quickly. Stack: Python, Go, LLMs, Kubernetes.

Some of the problems we work on:

There's no test suite in production. When the AI says "the root cause is X," how do you verify that? You can't A/B test diagnoses. Ground truth labels don't exist. We build evaluation systems that track resolution outcomes over weeks and correlate fixes with diagnoses to build statistical confidence.

When something breaks, everything looks broken. Database latency spikes, five services throw errors, CPU goes up, logs explode. When an agent sees 47 anomalies at once, it needs to figure out which one is the root cause and which are symptoms, across systems with feedback loops, hidden dependencies, and non-obvious temporal relationships.

A single investigation might need six hours of metrics across 50 services, 10GB of logs, 10,000 distributed traces, the last 30 deployments, and the relevant runbooks. LLMs have finite context windows. What's relevant isn't known until you investigate. Getting retrieval wrong means wrong conclusions or exploding costs.

We're hiring:

- Staff Software Engineer, AI: You build the core agent. Reasoning, evals, self-improving feedback loops. You debug agent behavior by tracing reasoning and tool choices to understand why the agent made a specific decision. You build the systems that make a non-deterministic agent reliable, and push it to handle increasingly complex incidents.

- Staff Software Engineer, Product: You define what an AI SRE should actually be. When AI handles the reasoning, how do engineers stay sharp for cases it can't handle? How do you build trust when someone needs to verify agent conclusions at 2AM? You answer these by embedding with customers during real incidents, running experiments, and making the technical calls to ship what works.

- Software Engineer, Backend: You build and scale the investigation platform alongside our senior engineers. Integrations with Datadog, PagerDuty, and dozens of observability tools. Agent reasoning pipelines. Runtime systems that handle real-time data streaming at scale. You'll ship customer-facing functionality across the stack.

- Founding Marketer: Software engineers are allergic to AI hype. Our users already love the product. The challenge is reaching the next thousand teams without setting off their BS detectors. You build the marketing function from scratch: programs, pipeline, infrastructure. You need a technical foundation and the ability to hold a 30-minute conversation with a platform engineering lead without getting lost.

- Staff Designer (Remote): The interfaces for AI agents don't exist yet. How do you make autonomous reasoning legible without overwhelming? You own design across brand, product, and marketing, defining the visual language for a new category.

Apply: https://jobs.ashbyhq.com/cleric | Email: willem-hn@cleric.ai

Willem, Co-founder & CTO

Cleric | Staff SWE, AI | Staff SWE, Product | Head of Marketing | SF Onsite | $160K-$240K + Equity

Engineers can't keep up with their production environments: dozens of services, dashboards everywhere, alerts firing. The information to diagnose most issues exists, but finding it takes longer than fixing the problem. AI generated code is making this worse.

Cleric is an AI SRE that autonomously investigates production issues and surfaces findings to engineers. It connects to your existing tools, reasons through the evidence, and tells you what's wrong. We believe engineers should ultimately be accountable in production, and our goal is to help them go much faster.

The hard part is making agents reliable when there's no single right answer. We've built evals, memory systems, and feedback loops that improve with every incident. Gartner just named us a Cool Vendor, we are well funded with years of runway, and most importantly the engineers that use our product find it very sticky.

We're hiring the following roles:

- Staff SWE, AI: Build the reasoning engine. Design evals, debug agent behavior (not just code), expand what it can handle. You've built agents and operated distributed systems at scale.

- Staff SWE, Product: Define what AI SRE should be. Spend time with engineers during incidents, find gaps, decide what to build. You've owned products and know production pain.

- Head of Marketing: Engineers love the product but we need to reach more of them. Software engineers are allergic to AI hype, and you'll need to cut through it. Technical background required.

Apply: https://jobs.ashbyhq.com/cleric Or email me: willem-hn@cleric.ai

Willem, Co-founder & CTO

I kind of agree, but the message in this particular post does border on https://simonwillison.net/2024/Jul/13/give-people-something-...

Cleric | https://cleric.ai | Staff Software Engineer | Full-Time | $160K–$220K | Onsite (San Francisco)

Cleric is an AI Site Reliability Engineer (SRE) that autonomously root causes production issues for engineering teams. Our AI agent frees engineers from time consuming investigations and context switching by reliably diagnosing and fixing problems in production environments.

We’re hiring a Staff Software Engineer to help us build a future where AI handles on-call support. You’ll join a small team of AI and infrastructure veterans in our sunny San Francisco office, working closely with the founding team to meet fast growing customer demand. Cleric is live in production with multiple customers and backed by top tier AI and infrastructure investors.

What is an AI SRE? → https://cleric.ai/blog/what-is-an-ai-sre

Role → https://jobs.ashbyhq.com/Cleric/131dd323-6d76-4d79-9cc5-f3b5...

Email → willem-hn@cleric.io

— Willem (Co-founder and CTO)

Cleric | https://cleric.io | Staff Software Engineer | Full-Time | Onsite (San Francisco)

Cleric is an AI Site Reliability Engineer (SRE) that root causes production issues at machine speed, using the same tools engineers use today. We help engineers quickly locate and fix problems in production environments.

We're looking for builders who want to create a future where AI handles on-call and they can get back to building software. You'll work closely with a team of veteran AI and infrastructure builders in our San Francisco offices. We're live in production at multiple enterprises and backed by leading AI and infrastructure investors.

Staff Software Engineer: https://jobs.ashbyhq.com/Cleric/131dd323-6d76-4d79-9cc5-f3b5...

Email: willem-hn@cleric.io

— Willem (Co-founder and CTO)

Cleric | https://cleric.io | Software Engineers, Platform & Product | Full-Time | Onsite (San Francisco)

Cleric is an AI Site Reliability Engineer (SRE) that diagnoses production issues at machine speed, using the same tools engineers use today. We're live in production at major enterprises and backed by leading AI infrastructure investors.

Our vision is to free engineers from operational toil entirely. Production systems have become too complex and fast-moving for human operators - we're building Cleric to handle this complexity autonomously, letting engineers focus on building products.

Roles:

- Software Engineer, Product: https://jobs.ashbyhq.com/Cleric/131dd323-6d76-4d79-9cc5-f3b5...

- Software Engineer, Platform: https://jobs.ashbyhq.com/Cleric/bf48c037-56dc-4237-bfe3-fe0c...

We're looking for builders who want to create a future where AI handles operations and engineers can get back to building. You'll join a team of veteran AI and infrastructure builders working closely out of our San Francisco office.

Email: willem-hn@cleric.io

— Willem (CTO, Cleric)

Cleric | Multiple Roles | San Francisco | Full-time | $160K-$200K + 0.5%-1.5% equity | Visa Sponsorship

At Cleric we're building an AI-powered agent that helps engineers quickly diagnose and resolve production issues, freeing them up from operational toil. We've raised a $4.3m seed from a leading AI VC and Silicon Valley angels.

The ideal candidate loves building tools for engineers, and is obsessed with generative AI. You'll join a team of AI, software, and infrastructure veterans working in-person from San Francisco.

Email me (CTO) at willem@cleric.io or apply at https://jobs.ashbyhq.com/cleric

While everyone is focusing on LLMs, the folks at Bytewax are quietly shipping tech that is both accessible and robust. Great to see.

Been following this project for a while. There's a reason why it's making waves in developer circles - You get a simple to use Python developer experience with a powerful distributed data processing framework that scales to enormous workloads. Plus its battle tested since it relies on Timely Dataflow under the hood.

It may be worth reading this article to get an idea of what feature stores are and how they are used https://feast.dev/blog/what-is-a-feature-store/

Co-author here. Happy to answer any questions!

I agree.

To add to that, GitOps as defined by Weaveworks and Kelsey Hightower is a technology agnostic approach.

Best bet to learn about our ML systems is at (and after) talks we do in Singapore.

Good point. I work on the Data Science team, but I will pass along your comment and suggestion to the relevant product team.

A side project of mine requires similar functionality in terms of copying and pasting text. I would like to see how you implemented it.

Working well, thanks!

Do you have any plans to release the source code?

It might not be viable as a means of facilitating transactions, but it can possibly survive as a store of value.

Did your symptoms ever manifest on your skin? If so, did the propranolol affect that at all?

Crawlers/indexers take JS into account to varying degrees. In my experience they will execute client side code, but AJAX calls are ignored. So at the very least you want to send down data for the initial load.

Firebase is great for getting up and running quickly.

If you want server side logic then you can use Firebase as a queue. So let the client request data through Firebase and then you have another service monitor the queue and fill requests.

I will second this.

Moving to Fastmail from Gmail was a massive improvement for me. Being able to quickly hook up custom domains to the same inbox is a big boon. Plus it costs less.

QBasic when I was 10 (on my own). Then I did some VB tinkering after that. Java in high school. In university the floodgates opened. C# / Python / C / C++ / JS / HTML & CSS.

It's always been about creating something.

Plain resume (I use LaTeX).

This also filters companies to an extent. I would rather work for a company that values the content of the resume over the presentation.

Resume: http://willem.co/cv/wp_resume_2016.pdf

Template (LaTeX): http://willem.co/cv/wp_resume_template.tex

Awesome Resume Templates (LaTeX): https://www.rpi.edu/dept/arc/training/latex/resumes/

I've seen this happen in a lot of industrial networks as well. At the end of the day the work needs to get done. If internet access is necessary for that, then somebody will plug in a mobile router or phone to this "isolated" network. This is especially common when remote vendors and support teams need access to this network to troubleshoot issues.

So now instead of centrally designed and managed IT infrastructure and remote access, you have something like a Teamviewer service enabling remote access through these rogue gateways.

"just as you'd be careful to bend at the knees when picking up a heavy box"

Wait, have I been doing this wrong?

I thought you were supposed to bend at the knees.

A friend of mine flies for Cathay Pacific. He makes a lot of money, but really dislikes the job. He yearns for an 8-5 job in an office.

I guess it depends on the person. I know I wouldn't want to be a commercial pilot.

Unfortunately I don't have another electronic key.

My model (2013 Polo Vivo Blueline) came with one electronic key/remote, and one mechanical key. So I can buy another electronic key, but I can't use the remote without VW programming it.