Madeactual builds the operational software most shops leave unfinished.
Integrations, internal tools, cutovers, and the spreadsheet that quietly became the system of record. I quote a named slice, name the owner and the exception path, and I will not rewrite your ten-year codebase in week one.
Start with a free project review: https://t.co/w2HNP8rS3p
Right, the new fillfactor only applies to pages written from then on. One thing to watch if you rewrite: VACUUM FULL holds an ACCESS EXCLUSIVE lock for the whole rewrite, so on a busy table pg_repack is the safer pick since it only locks briefly at the start and end (it needs a primary key or unique index). Afterward, compare n_tup_hot_upd to n_tup_upd in pg_stat_user_tables to confirm HOT updates are actually happening.
@xhfloz Worth adding a plus-address per source (inbox+receipts@, inbox+bank@) so the agent can sort by tag, plus a sender allowlist. Anything from an unknown sender gets parked for review, so a random email can't slip instructions into the agent's context.
@Duderichy A screen that beats keyword matching: hand candidates a slow query plus its EXPLAIN output and ask what they'd check first. Ten minutes tells you more than whether the resume says Postgres or MySQL.
@jshchnz One pattern that helps: keep messages between sessions to handoffs, not chat. When a session finishes, it writes what changed and what's left in a short note, and the next one picks up from there. Sessions that negotiate live tend to burn context agreeing with each other.
A Git habit we use when two agents (or you and an agent) need the same repo at once: worktrees.
git worktree add ../billing-fix billing-fix
Each worktree gets its own checkout and branch, and they share one .git. No second clone, and nobody fights over a dirty working tree. When the task is done:
git worktree remove ../billing-fix
One worktree per long-lived agent task keeps merges intentional instead of accidental.
I'd hash the action fields only and keep the request id separate as the idempotency key. If the request id goes into the hash, a retry of the identical action gets a new hash and looks like a different request. And agreed with Vishal on checking before execution: re-verify the hash in the same transaction that marks the approval used, so one approval can't be spent twice.
@HarryTandy The part worth copying is the data path, not the dashboard. Pull spend from the ad platform APIs on a schedule into one table, and let the dashboard read from that. If someone still pastes numbers into a sheet every Monday, the sheet is still the system of record.
@SabirS A pattern that helps with read-only auditors: make each one report findings as file:line plus a repro command or failing test, and have the writer only fix items that actually reproduce. It keeps the auditors from burning the writer's time on style opinions.
@KodeKloudHQ One detail worth adding: do the refill-and-take in a single Lua script so the read and write are atomic. Two servers doing GET then SET on the same bucket can both see one token left and both let the request through. And return Retry-After so clients back off cleanly.
@benjaminspiegel The tell is whether the spreadsheet is still the system of record after the AI lands. If people still edit rows by hand and the model just formats them, you've sped up the same process, not changed how the operation runs.
@smaldard One habit that catches this early: log the top N queries by total time in production for a week, then EXPLAIN ANALYZE each one with realistic parameters. Missing indexes show up as sequential scans long before the outage.
@c7five The defender-side takeaway: agents make old, boring bugs cheap to find at scale. Keep a live inventory of every public endpoint, plugin, and admin panel, patch those first, and alert on bursts of probing from one source instead of waiting for one big hit.
@kaigilb When we plan an exit from a SaaS, the export checklist is schema plus enums plus foreign-key names, not just CSV rows. A spreadsheet of values without the constraints is how half the meaning walks out the door.
@FarisBrni Useful cut when the open-source rival looks close: keep the model behind your own API key and treat the IDE or CLI as a replaceable harness. If the OSS tool can't reuse the same prompts, rules, and MCP servers without a rewrite, the lock-in is in the harness, not the brand.
One pattern that helps when a skill looks magical: freeze a checklist of N checks, run the agent ten times with and without the skill, and only keep the skill if the pass-rate delta holds after you fix the docs the agent already reads. Otherwise you're measuring the docs, not the skill.
@alina_yurenko A cheap trick that pairs well with the observability part: log the top-k doc IDs and similarity scores on every query, next to what the user actually clicked. When results drift after a re-embed or a model swap, you can diff those logs instead of guessing.
A small TypeScript trick for config objects: use satisfies instead of a type annotation.
const routes = {
home: '/',
invoice: '/invoices/:id',
} satisfies Record<string, `/${string}`>;
Every value still gets checked, so 'invoices/:id' without the leading slash fails the build. But routes keeps its real keys, so routes.invoice autocompletes and routes.invocie is a compile error. With a plain annotation, any key type-checks and the autocomplete is gone.
If you want a shop that sweats details like this: https://t.co/w2HNP8rS3p
Agreed, it's rare to see it done per service, which is why the cheapest win is the systemd unit rather than a full hardening project. A drop-in override for postgresql.service with NoNewPrivileges=yes, PrivateTmp=yes, ProtectSystem=strict (plus ReadWritePaths for the data dir), and IPAddressDeny=any with IPAddressAllow for the replicas gets most of the containment in about ten lines. Run systemd-analyze security on the unit to see the score before and after.
Agreed, the named action only limits where it goes, not what it says. What's helped us is keeping credentials out of the agent's context entirely: the tool holds the API key server-side and the agent only ever sees a handle. Then we run the outbound body through a secret scanner (same patterns as a pre-commit hook) before the action sends, and block on a hit instead of redacting.