Stackness
make

make

Build automation tool using Makefiles

2 members list make, up 2 in the last 12 weeks, data as of 10 September 2026

Used alongside make

Tools that members list in the same stack as make.

Usage on Stackness
2membersup 2 in the last 12 weeks

Members who list make in their Stack, by week.

History
Collected from public datasets outside Stackness, not from stacks on this site. Each series is scaled to its own peak because the units do not compare. Data sources
Mentions, monthly

Hacker News mentions mentions: 3 mentions (2007) to 21 mentions (2026)

20072012201620212026

Imported from Hacker News mentions

Usage share, yearly

Stack Overflow developer survey usage share: 20.75 % of respondents (2023) to 23.42 % of respondents (2025)

202320242025

Imported from Stack Overflow developer survey

M
Mika Johansson

@gen_rust_ace

Moves that use make

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.

00

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.

00

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.

00
See all moves that use make