Loading…
Latest reads
Every post, summarised
Grounded summaries of engineering blogs, newest first. Each links to the original.
- 4,671 posts
- 20 companies
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Latest posts
Backstage with Lakebase, part 2
Part 2 shows how moving Backstage’s operational Postgres database to Databricks Lakebase brings security, auditing, masking, and cost controls under Unity Catalog. The proof of concept used Lakehouse Federation to expose the catalog as the lakebase_bs foreign catalog, replacing cross-service RDS investigations with Unity Catalog grants and system.access.audit records. Audit events identify OAuth users and source IPs, while billing attributed 31.6130 DBU to production and 0.0107 DBU to a dropped test branch. Branch-level attribute masking propagates automatically to feature, CI, and QA copies, while the post cites a Perforce report stating that 60% of organizations experienced breaches or theft in non-production environments. It also introduces LakebaseOps, with three agents and seven scheduled jobs, and Lakebase MCP, exposing 46 governed tools across four profiles, so DBAs can design policies and workflows instead of handling repetitive provisioning.
18 Social Media Holidays to Celebrate This June
June’s social media calendar presents 18 observances, combining lighthearted dates such as National Donut Day and National Take Your Dog to Work Day with causes including ocean conservation and blood donation. It positions the holidays as prompts for brands to engage online communities through polls, carousels, infographics, videos, challenges, and behind-the-scenes posts. Suggested hashtags and content ideas range from a childhood-memory question and donut personality poll to environmental restoration visuals, ocean-health graphics, blood-donation myth busting, and a collaborative summer playlist. June 21 carries several entries—Father’s Day, the first day of summer, International Yoga Day, National Selfie Day, World Music Day, and National Take Your Dog to Work Day—while later guidance covers sunglasses and Social Media Day content creation.
Operator: A look under the hood
Operator is a customer-operations Agent built to help teams understand, manage, and improve customer experience across workspaces. The post distinguishes a production Agent from a prototype that simply gives an LLM API access and a system prompt, describing more than 50 purpose-built tools and 10 skills for data retrieval, reporting, investigation, and operational tasks. Its intelligence layer combines semantic search tuned against millions of support conversations, workspace-specific attribute awareness, and encoded reasoning, while the action layer supports configuration and content changes through reviewable diffs requiring explicit approval. A hybrid conversational and graphical interface presents charts, dashboards, and structured proposals within the existing platform. The post argues that read-only custom tools can be built in weeks, but production reliability, safe actions, multi-tenant isolation, graceful degradation, and ongoing maintenance require substantially greater investment.
Meet Operator: An Agent for your customer operations
Operator is an agent for customer operations that works across Fin and the Intercom helpdesk, addressing the ongoing effort required to manage AI and human support work. It can analyze operational data and conversation samples, explain metric changes and root causes, maintain help-center content from briefs, and identify content gaps with localized drafts. Operator can also debug Fin conversations, propose configuration fixes, build Procedures and other automations, run simulation tests, and support incident response and rep management. Its purpose-built tools and proposal system present structured diffs for review, editing, and approval before changes go live; the announcement says more than 200 early users are trying it and that it is available in early access.
Scaling developer experience: How we improved Android Studio in a large monorepo
Grab’s passenger Android monorepo contains roughly 2,000 modules and 11 million lines of code, making Gradle-based Android Studio syncs increasingly slow and memory-intensive even though Bazel handles builds. A cold full sync could exceed 35 minutes, and a survey of 55 developers found that 82% wanted an option to exclude modules from syncing. The team built a custom Focus plugin that uses a dependency graph generated during migrateToBazel, avoids repeating Gradle’s configuration phase, and integrates with Android Studio through a one-click Select → Focus → Sync flow; a Groovy include-shadow technique avoids requiring teams to reorganize settings files. Typical focused syncs fell below two minutes, while reported results show reductions from 35 minutes to under one minute depending on module size, memory usage from 10 GB to 2 GB, and improved Compose preview updates, with broader IDE operations requiring expanded focus or full sync.
How the D. E. Shaw group powers high-cardinality observability at scale with ClickHouse
Inside D. E. Shaw group, a global investment and technology development firm, millions of compute workloads run monthly across its high-performance computing infrastructure. To support capacity planning and resource allocation, it collects task-level metrics for requested and utilized compute, producing millions of distinct time series that its previous observability platform could not accommodate. Engineers benchmarked databases on identical hardware and datasets; ClickHouse ingested approximately 3.5 million samples per second on one node versus roughly 480,000 for a competing solution, while similar queries completed in seconds instead of timing out. They retained InfluxDB line protocol, batched messages into ClickHouse, and built disk-based tooling to transform and stream historical data; the resulting four-server NVMe cluster stores about 68 TB compressed and sustains 530k records per second on average. Materialized views support capacity-planning dashboards, while OpenTelemetry tracing extends the platform to other observability workloads, with SQL migration and data modeling requiring engineering effort.
ClickHouse vs Prometheus for High Cardinality, Part 2: Cardinality in ClickHouse
Traditional time-series databases like Prometheus experience write amplification, memory overhead, and operational challenges when high-cardinality label combinations churn rapidly. ClickHouse alters these economics by abandoning dedicated series objects in favor of a wide events model, storing telemetry as rows in columnar tables with dynamic Map attributes and metric measurements. Dynamic attributes can be handled using sharded Map types alongside materialized columns and text indexes for frequently queried labels. This design trades ingestion overhead for query-time processing, relying on columnar compression, partition pruning, and parallel scans to compute aggregations on demand. ClickHouse avoids the ingest-side bottlenecks of high cardinality, though Prometheus remains preferable for moderate cardinality, native PromQL semantics, and single-series lookups.
Expanded interoperability with Unity Catalog Open APIs
Unity Catalog’s expanded Open APIs address data silos by letting organizations use multiple compute engines while retaining centralized governance and a single copy of data. In beta, Apache Spark, Apache Flink, and DuckDB can create, read, write, and stream to or from UC managed Delta tables, with catalog commits providing serialized commits, transactional safety, and auditability. Delta Kernel, an open source Java and Rust library, abstracts low-level protocol details, helping connectors integrate external writes with catalog-managed commits while Predictive Optimization continues to run on accessed tables. Credential vending, now GA for tables, issues short-lived, scoped cloud credentials and supports M2M OAuth plus automatic refresh; volume credential vending is in Public Preview for unstructured data. The roadmap includes functionality for fine-grained row- and column-level ABAC on external reads, while external managed-table access remains in beta.
From manual to autonomous: how AI agents are transforming electric grid operations
Electric utilities are facing rising demand, retiring generation, extreme weather, aging infrastructure, and fragmented operational data that manual processes cannot manage at scale. AI agents are presented as a human-centered alternative that synthesizes heterogeneous data, learns from outcomes, and progresses from human-approved recommendations to exception-based control and eventually autonomous operations within defined parameters. Hawaiian Electric used a Retrieval Augmented Generation proof-of-concept with Databricks AI Search, Unity Catalog, and Lakeflow Declarative Pipelines to query regulatory documents and provide page-specific citations. The system reduced response times from five minutes to five seconds and was implemented in two weeks, while the article describes broader potential for predictive maintenance, outage response, load forecasting, and customer service.
Granite Embedding Multilingual R2: Open Apache 2.0 Multilingual Embeddings with 32K Context — Best Sub-100M Retrieval Quality
Granite Embedding Multilingual R2 introduces two Apache 2.0 multilingual embedding models built on ModernBERT: a 97M-parameter compact model and a 311M full-size model. Both cover more than 200 languages, receive enhanced retrieval training for 52 languages and nine programming languages, and support context lengths up to 32,768 tokens, compared with 512 for the R1 models. The compact model scores 60.3 on MTEB Multilingual Retrieval, while the full-size model scores 65.2; the reported results place them among the strongest open models in their parameter ranges. R2 replaces the XLM-RoBERTa architecture with alternating attention lengths, rotary position embeddings, newer multilingual and code tokenizers, and Flash Attention 2.0 support, while the 311M model adds Matryoshka embeddings and both models provide ONNX and OpenVINO weights.
Piloting estimated earnings per kilometer on trip requests
Uber is piloting an estimated earnings per kilometer badge on trip requests in selected cities, giving drivers another way to compare potential trips alongside the upfront fare. The calculation starts with the upfront trip fare and divides it by the total estimated driving distance: from the driver’s acceptance location to pickup, plus from pickup to the final destination. It is intended as a benchmark that works across requests with different durations and excludes distance driven while waiting between rides. Drivers continue to be paid per trip based on the upfront fare, not per kilometer; the estimate is not a guarantee, can change when trip details change substantially, and may differ from actuals because the distance estimates depend on the driver’s location and request details.
Piloting estimated earnings per active hour on trip requests
Uber’s pilot, now ended, tested an estimated earnings per active hour badge on trip requests for some drivers in select cities. The badge appeared on Trip Radar and Exclusive requests, while drivers still received upfront fares and were paid per trip, not by the hour. Active time covered driving to pickup, waiting for the rider, and completing the trip, excluding time spent online between requests. The estimate divided the upfront fare by estimated pickup, one-minute average pickup wait, and trip time, then scaled the per-minute amount to 60 minutes. Uber described it as a comparison benchmark, but noted that timing estimates use historical data and traffic conditions, actuals can vary, and the figure is not a guarantee.
Beyond Prediction: Solving the Multiple Knapsack Problem at Scale: How Uber Optimizes Incentives
Uber’s Tarot platform frames incentive allocation as a Multiple Knapsack Problem (MKP), replacing FIFO contention handling and reactive budget management. It combines segmentation, budget pacing, uplift predictions, multi-objective value scoring, and a plug-and-play optimizer coordinated by an orchestrator. For each run, Tarot forms user-lever opportunities, predicts incremental ROI and cost, reconciles available budget, and selects assignments under team, business, and concurrency constraints before publishing them to domain services. The initial HiGHS linear programming approach took more than 24 hours to find a feasible solution for 100,000 users and one lever, while CP-SAT solved the same dataset in minutes and handled millions of users across multiple levers within stated SLA timeframes. The result is a production architecture that moves beyond heuristics by combining constraint programming with budget pacing, while future work targets automated exploration and model feedback.
From latency to instant: Modernizing GitHub Issues navigation performance
GitHub Issues addressed navigation latency by shifting workloads to the client using a local-first, stale-while-revalidate architecture. To evaluate perceived delays, the team tracked user transitions through Highest Priority Content thresholds, aiming for instant rendering in under 200 milliseconds. The core implementation added a persistent client-side cache using IndexedDB, paired with a synchronous in-memory tier to serve hot issue payloads without asynchronous overhead. A selective preheating mechanism resolves missing cache entries for high-intent links without overburdening backend capacity with redundant requests. Following broad rollout, the proportion of instant React soft navigations increased from 4% to approximately 22%, yielding an overall cache-hit ratio of around 33%.
ClickHouse vs Prometheus for High Cardinality, Part 1: Understanding the Problem
Observability systems frequently encounter high cardinality when metrics contain numerous unique label combinations across multidimensional cloud infrastructure. In Prometheus, every unique label combination instantiates an independent time series that incurs metadata overhead, requires in-memory memSeries registration, and continually expands inverted index posting lists. The ingestion engine stores samples in two-hour Head blocks using compressed 120-sample chunks with XOR-based encodings, but rapid series creation and elevated scrape frequencies multiply chunk allocations and memory consumption. When executing read operations, broad aggregations and regular expressions require intersecting expansive posting lists and decoding entire chunks sequentially because the engine cannot push value predicates directly into compressed storage blocks. Consequently, managing high-cardinality workloads in series-oriented architectures forces operational trade-offs between system stability and granular visibility into ephemeral components.
amazon.science
Promptimus: Improving already good LLM prompts with zero manual engineering
Enterprise applications rely on mature large language model prompts that incorporate intricate business logic and regulatory constraints, making further optimization and cross-model migration challenging. Promptimus automates prompt refinement through a four-step iterative loop that evaluates candidate prompts against decomposed metric checkpoints, diagnoses failure bottlenecks, and generates targeted improvement strategies. The system operates either via full prompt rewrites in standard mode or through surgical, programmatic find-and-replace edits in edit mode to preserve structured taxonomies and schemas. Tested across multimodal classification and code generation tasks, the framework achieves performance gains with small development datasets of 20 to 50 samples. Amazon is making the model-agnostic optimization system available through Amazon Bedrock to support enterprise generative-AI model migration without manual engineering.
New ways to agentically build and edit dashboards
Pre-configured monitoring templates often fail to meet organization-specific needs, forcing developers to manually build dashboards widget by widget. Sentry introduced AI-agent-powered dashboard creation and editing in open beta, alongside CLI management tooling and template revisions. Users can prompt an AI chat interface to build or adjust dashboards, duplicate and customize uneditable Sentry-built templates, or execute dashboard commands directly in their terminal. Dashboards leverage issue, tracing, and application metric data across frontend, backend, mobile, and framework-specific views like Next.js and Laravel. Edits made through the UI, CLI, or AI agent are automatically tracked in a revision history that supports one-click rollbacks.
Unlocking asynchronicity in continuous batching
Continuous batching improves GPU utilization with tightly packed batches, but its synchronous loop makes the CPU and GPU take turns, leaving the GPU idle while the CPU prepares each next batch. Profiling 8K-token generation with a batch size of 32 and an 8B model recorded 300.6 seconds, with the GPU idle for 24.0% of runtime. The post builds asynchronous batching by overlapping CPU preparation with GPU computation, using non-default CUDA streams, non-blocking transfers, and synchronization events to coordinate dependencies. In the same experiment, GPU activity rose to 99.4% and total generation time fell to 234.5 seconds, a 22% speedup, without new kernels or model changes while maintaining model accuracy.
You can't whisper at an AI agent
Stripe engineers ran roughly a dozen experiments to determine how to get AI agents to use current API versions, follow integration best practices, and load the Stripe skill. Passive hints, including SDK files, AGENTS.md guidance, and API warning responses, were largely ignored, while active prompts and distribution mechanisms performed better. A modular, progressively disclosed skill structure outperformed a monolithic file by roughly 10% and reduced token usage; a CLI login prompt led 30–35% of viewers to copy its install command, and explicit compatibility-mode errors prompted agents to correct version mismatches. The results suggest that agent-facing developer experience is primarily a distribution problem, with hard steering through errors and loaded instructions more reliable than soft hints agents may never encounter.
Postgres FDW: Pushdown is a negotiation
Postgres Foreign Data Wrapper extensions allow PostgreSQL to query external datastores like ClickHouse by delegating execution to remote engines. Engineering pg_clickhouse centers on pushdown decisions that determine whether SQL expressions run remotely or stream raw data back across the wire. Because pushdown depends on planner callbacks, deparser translations, and ClickHouse semantic compatibility, a single untranslated clause can block upper-level query pushdown entirely. Resolving pushdown barriers enables complex analytic queries to return hundreds of rows in milliseconds rather than pulling tens of millions of rows for local processing. Ultimately, pushdown development requires an iterative negotiation across differing SQL grammars, occasionally requiring the revocation of translations that fail to maintain strict equivalence.
Top topics
- Architecture834
- Performance816
- LLMs660
- Machine Learning622
- Open Source563
- AI Agents553
- AI470
- Developer Experience448
Weekly digest
The best engineering reads, once a week.