# fidelitas.io

A technology blog covering distributed systems, performance engineering, developer tools, and the bleeding edge of software craft.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Reciprocal knowledge elicitation: when the interview goes both ways

DevFeed: [Reciprocal knowledge elicitation: when the interview goes both ways](<https://devfeed.tech/articles/reciprocal-knowledge-elicitation-when-the-interview-goes-both-ways-38797.md>)

Original publisher: [Read original article](<https://fidelitas.io/2026/05/reciprocal-knowledge-elicitation/>)

Author: fidelitas.io

Published: 2026-05-18T21:30:00Z

Content type: opinion

Language: en

Sources: [fidelitas.io](<https://devfeed.tech/sources/fidelitas-io.md>)

Topics: [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [Matter](<https://devfeed.tech/topics/matter.md>)

Tags: [agent](<https://devfeed.tech/tags/agent.md>), [ai](<https://devfeed.tech/tags/ai.md>), [human-ai-collaboration](<https://devfeed.tech/tags/human-ai-collaboration.md>), [interview](<https://devfeed.tech/tags/interview.md>), [interviews](<https://devfeed.tech/tags/interviews.md>), [knowledge-management](<https://devfeed.tech/tags/knowledge-management.md>), [tacit-knowledge](<https://devfeed.tech/tags/tacit-knowledge.md>)

### AI overview

The article explains reciprocal knowledge elicitation, an approach in which humans and AI jointly extract, refine, and validate expert knowledge. It argues that targeted follow-ups, summaries, contradiction detection, and gap-finding can better capture tacit knowledge than one-way interviews or forms.

### Source excerpt

Traditional knowledge elicitation is a one-way street: an expert talks, a system listens. A new wave of human-agent research is rewriting that contract. Here's what reciprocal knowledge elicitation actually means, why it matters for capturing tacit knowledge, and how to design one without losing the plot.

## Why cURL is a practical debugger for HTTP problems

DevFeed: [Why cURL is a practical debugger for HTTP problems](<https://devfeed.tech/articles/a-love-letter-to-curl-the-world-s-most-underrated-debugger-38794.md>)

Original publisher: [Read original article](<https://fidelitas.io/2026/05/a-love-letter-to-curl/>)

Author: fidelitas.io

Published: 2026-05-17T08:15:00Z

Content type: opinion

Language: en

Sources: [fidelitas.io](<https://devfeed.tech/sources/fidelitas-io.md>)

Topics: [cURL](<https://devfeed.tech/topics/curl.md>), [debug](<https://devfeed.tech/topics/debug.md>), [Command-line interface](<https://devfeed.tech/topics/cli.md>), [Unix](<https://devfeed.tech/topics/unix.md>)

Tags: [curl](<https://devfeed.tech/tags/curl.md>), [debugging](<https://devfeed.tech/tags/debugging.md>), [headers](<https://devfeed.tech/tags/headers.md>), [http](<https://devfeed.tech/tags/http.md>), [tooling](<https://devfeed.tech/tags/tooling.md>), [unix](<https://devfeed.tech/tags/unix.md>)

### AI overview

This opinionated developer article argues that cURL is especially useful for debugging HTTP problems in production and remote environments where graphical clients may be unavailable. It contrasts cURL's debugging role with GUI clients' strengths in exploration, sharing, onboarding, and code generation, and introduces commonly useful command-line flags.

### Source excerpt

Postman is great. Insomnia is great. But the moment something goes wrong in production, the tool I reach for first is the one that's been on every Unix box since 1996.

## Performance engineering as a habit, not a project

DevFeed: [Performance engineering as a habit, not a project](<https://devfeed.tech/articles/performance-engineering-as-a-habit-not-a-project-38796.md>)

Original publisher: [Read original article](<https://fidelitas.io/2026/05/performance-engineering-as-a-habit/>)

Author: fidelitas.io

Published: 2026-05-16T16:00:00Z

Content type: tutorial

Language: en

Sources: [fidelitas.io](<https://devfeed.tech/sources/fidelitas-io.md>)

Topics: [Benchmark](<https://devfeed.tech/topics/benchmark.md>), [ci](<https://devfeed.tech/topics/ci.md>), [Code](<https://devfeed.tech/topics/code.md>), [systems](<https://devfeed.tech/topics/systems.md>)

Tags: [benchmark](<https://devfeed.tech/tags/benchmark.md>), [benchmarks](<https://devfeed.tech/tags/benchmarks.md>), [build](<https://devfeed.tech/tags/build.md>), [ci](<https://devfeed.tech/tags/ci.md>), [cloud](<https://devfeed.tech/tags/cloud.md>), [code-review](<https://devfeed.tech/tags/code-review.md>), [engineering-practice](<https://devfeed.tech/tags/engineering-practice.md>), [git](<https://devfeed.tech/tags/git.md>), [hardware](<https://devfeed.tech/tags/hardware.md>), [latency](<https://devfeed.tech/tags/latency.md>), [observability](<https://devfeed.tech/tags/observability.md>), [performance](<https://devfeed.tech/tags/performance.md>), [performance-engineering](<https://devfeed.tech/tags/performance-engineering.md>), [regression](<https://devfeed.tech/tags/regression.md>), [runner](<https://devfeed.tech/tags/runner.md>), [slo](<https://devfeed.tech/tags/slo.md>)

### AI overview

The article argues that teams should treat performance engineering as a recurring engineering habit rather than a temporary project. It recommends measuring every pull request, comparing results with the previous day, and making performance regressions fail the build as part of CI.

### Source excerpt

Most performance work is reactive: the bill goes up, the dashboard turns red, somebody opens an investigation ticket. Here's how to make it boring instead.

## Your event-driven architecture is a distributed monolith -- and that's fine, if you measure it

DevFeed: [Your event-driven architecture is a distributed monolith -- and that's fine, if you measure it](<https://devfeed.tech/articles/your-event-driven-architecture-is-a-distributed-monolith-and-that-s-fine-if-you-measure-it-38795.md>)

Original publisher: [Read original article](<https://fidelitas.io/2026/05/event-driven-distributed-monolith/>)

Author: fidelitas.io

Published: 2026-05-15T10:30:00Z

Content type: opinion

Language: en

Sources: [fidelitas.io](<https://devfeed.tech/sources/fidelitas-io.md>)

Topics: [event driven](<https://devfeed.tech/topics/event-driven.md>), [Messaging](<https://devfeed.tech/topics/messaging.md>), [Structured-data](<https://devfeed.tech/topics/structured-data.md>), [Traces](<https://devfeed.tech/topics/traces.md>), [interface](<https://devfeed.tech/topics/interface.md>)

Tags: [architecture](<https://devfeed.tech/tags/architecture.md>), [coupling](<https://devfeed.tech/tags/coupling.md>), [decoupling](<https://devfeed.tech/tags/decoupling.md>), [distributed-systems](<https://devfeed.tech/tags/distributed-systems.md>), [event-driven-architecture](<https://devfeed.tech/tags/event-driven-architecture.md>), [messaging](<https://devfeed.tech/tags/messaging.md>), [observability](<https://devfeed.tech/tags/observability.md>), [schemas](<https://devfeed.tech/tags/schemas.md>), [services](<https://devfeed.tech/tags/services.md>), [traces](<https://devfeed.tech/tags/traces.md>)

### AI overview

This opinion article argues that event-driven systems can become distributed monoliths when message brokers hide rather than remove coupling. It focuses on explicit, versioned, validated schemas and traces as ways to reveal dependencies and diagnose failures.

### Source excerpt

Async messaging didn't decouple your services; it hid the coupling. Here's how to find the seams again with traces, schemas, and a healthy fear of fan-out.