make
Build automation tool using Makefiles
2 members list make, up 2 in the last 12 weeks, data as of 10 September 2026
Members who list make in their Stack, by week.
Hacker News mentions mentions: 3 mentions (2007) to 21 mentions (2026)
Imported from Hacker News mentions
Stack Overflow developer survey usage share: 20.75 % of respondents (2023) to 23.42 % of respondents (2025)
Imported from Stack Overflow developer survey
@gen_rust_ace
Moves that use make

by Sergei GordeichukAI Tools
Every project gets a single make check that runs lint, format-check and tests for the whole stack at once, and nothing gets committed until it is green. The value is not the automation, it is that there is exactly one thing to remember and no partial-check escape hatch to negotiate with. Per-side targets exist for speed while iterating, but the gate before a commit is always the full one. Written into the project instructions as mandatory, an agent will run it unprompted for the rest of the session.
by Sergei GordeichukAI Toolsbackdated
You cannot speed up an agent loop you are guessing about. A three-command shell helper - init, mark <phase>, report - stamps timestamps into a log and renders a markdown table at the end of every run. Call mark the moment a phase finishes, not when the next one starts, and let repeated labels sum. Phases worth separating: task setup, implement, check-suite runs, acceptance review, test refresh, commit. Committing the report next to the task turns wall-clock into a tracked artifact instead of a feeling. What it showed me: the coding is rarely the expensive part. It is the check-fix-recheck cycles and regenerating test scripts.
by Sergei Gordeichuk
Building on plain markdown task files in backlog/in_progress/done, the actual technique is splitting the agent loop into three slash commands that each do exactly one thing. /roll researches the codebase and writes a task file - it implements nothing, which is what keeps planning honest and reviewable. /rock picks up one task and takes it end to end: implement, run the check suite, review the result against the task's own acceptance criteria, refresh the e2e scenarios, commit. /work is a thin loop over a list of task IDs that hands each one to a fresh subagent, so the main context never carries state from the previous task, and parks anything needing a human decision instead of stopping the whole batch. The split matters more than the commands. A single do-everything command quietly merges planning into implementation and you lose the reviewable step in the middle.