The same Tuesday, two desks away. Nobody here is deciding what gets built; here it gets built. The expensive part of the day is still not the typing. It is the ten minutes in which somebody does not know what was meant — and the day and a half that grows out of them when the guess is wrong and nobody notices it.
What follows is a working day with no alignment meeting in it. Not because meetings are bad, but because the questions that produce them have been answered where the answer stays put.
09:00
On the board sits an issue angajuu created. It carries exactly five fields: project, summary, description, issue type and priority. Nothing else — no labels, no components, no assignee. angajuu chose the type itself, from the kind of requirement: a product requirement becomes an Epic, a customer requirement a Story. That is not a setting somebody forgot to configure.
More telling than what the issue says is what has not happened to it since. It was created once and never touched again. If the sentence in angajuu reads differently today than it did three weeks ago, Jira still shows the old one. So the day starts with a jump back to the source.
For the team, that is the whole difference. No “got a minute?”, no ticket rewritten three days after it was filed because somebody had a second thought. The sentence was settled before it arrived here — which is why you can simply start at nine.
09:30
The question arrives while reading, the way it always does. “Archived” — gone from the list, or left out of the monthly report? For the person building it, that is the difference between a flag and a second query. A year ago it would have been a message in the team channel and, on a bad week, a meeting on Thursday.
Today it takes thirty seconds. The product requirement's sidebar lists the customer requirements hanging off it. He opens the first and reads the sentence the customer wrote, along with its source — who asked for this — and the project it came from. Title and description exist in both languages, and here the German half is the original. It says: archived and excluded from the monthly report. Question answered, nobody interrupted.
Two limits belong in the same breath. The sidebar lists linked requirements by title only; whether a link is confirmed, and how much it covers, lives in the coverage panel in refinement. And the requirement will not tell you who last edited its text — there is no field for that. The trail records state changes and handovers, “Status changed from … to …”, the Jira issue that was created; a plain edit to the wording leaves no entry at all. That moves the question you ask: not “who changed this?” but “what state is this sentence in?”. The state is kept, its changes are on the record, and the requirement page offers only the transitions that are legal from where it stands.
One thing stays open — whether the exclusion applies to running subscriptions too. So he writes the question as a comment on the requirement. An ordinary comment triggers nothing: no model answers, nobody is notified, and only a mention — @ai or @juujuu — starts a job. The question simply waits where it belongs, next to the sentence it is about.
11:00
The agent gets the sentence and the boundary: what to build, and what it must not touch. What such a brief has to look like is its own subject, linked at the end. The interesting part here is the hour afterwards.
At 11:40 there are eight hundred lines in front of him, and the question is not whether they compile but whether they do what the customer asked for. For that he uses a list he did not write. It comes out of the project's Product Requirements Document: introduction, scope, goals, the customer requirements ordered by priority, and per requirement a section called Acceptance Tests, where the model is asked for two to five lines on how you would know the requirement is met.
The value of those lines is their timing. They come out of the customer requirement in a second model pass, eight requirements at a time, before a line of code exists. A checklist written in the same breath as the implementation checks the implementation against itself; this one can no longer adapt to what was built.
The honest account, again. The boxes in front of the lines are characters, not controls: nothing to click, nothing saved when you read them. The list does not hang off the requirement either; it sits inside one document. It is produced in both languages, and both the PDF and the Markdown emit the English half only — the German stays in the app. And with no Claude key stored, this document is the one AI result that does not degrade quietly: it fails outright rather than coming back empty.
So he reads the lines himself, one after another, against what came back. Three hold, one does not: the agent built the archiving and not the exclusion from the report. Twenty minutes of rework — and they land today rather than in the demo.
This is where development work is quietly changing. Not less demanding, differently demanding: reading instead of typing, judging instead of trying. Do that without a brief that holds and you come out empty at the end of the day, without quite knowing why.
14:30
Merged. Now the part tools like to skip: what is true elsewhere now, without somebody typing it in a second time?
In Jira he drags the issue into the last column — his board, his rules. What angajuu makes of that is narrow, and switched off by default. Switched on, a service asks at a fixed interval, 15 minutes as standard, and reads four things: status, resolution date, the version stamped on the issue, and whether that version has been released. Status travels through a per-product mapping onto the product requirement's implementation state; there is no screen for that mapping, and anything unmapped lands quietly on In Progress. One state no sync will ever write: verified is refused in code, because verifying is a human judgement. And where Jira drifts from the plan, angajuu does not re-plan itself — the drift becomes a work queue for a person.
The implementation state shows up on the product page: four counters — Planned, In Progress, Implemented, Verified — and a column in the table below. None of them says whether the promise to the customer has been kept. That is not worked out in advance. It is worked out when somebody asks.
Which is why less happens this afternoon than “done” suggests. The confirmed link carries a degree of partial and counts 50; the customer requirement stays open even though the code runs. That is correct: the ask was archiving and the report, and what exists is the archiving.
Covered is not something anyone remembers. It is a figure that comes back from scratch every time.
| Requirement | Status | Coverage |
|---|---|---|
| Consolidated quarterly invoice | PARTIAL | |
| Dunning escalation levels | GAP | |
| DATEV document export | COVERED | |
| Customer portal login | UNASSESSED |
16:45
At 16:45 the Product Owner sees what changed since the morning — without asking, and without anyone sending her anything. On the report page — one scrolling page with four cards — the percentage sits in the gap matrix; the gap report beside it goes out as PDF or a spreadsheet and lists the customer requirements with not one confirmed link behind them. The requirements list adds a covered / uncovered filter, though that one only asks whether a confirmed link exists, not how much it covers.
Today's requirement is still open there, at 50 percent. That is no longer an argument, it is a row: a small, clear question for tomorrow morning instead of a misunderstanding that runs for a month.
Nobody asks “is it done?” when everyone can see the same answer.
One thing angajuu never said all day: who is working on what. There is no assignee field on a requirement, nowhere in the model, and the home screen prints exactly that in a line of its own rather than inventing an attribution. Who is holding the work is your board's business. angajuu knows which sentence applies, what state it is in, and how much of it is covered.
A day with no alignment meeting is not a cost-saving. It is what is left over once nobody has to spend time manufacturing the state of things everyone is about to talk about.
Why a brief an agent can build from is written before the prompt rather than inside it is in AI-driven development starts before the prompt. And the discipline behind this day's second question — not just “does it run?” but “is it what was asked for?” — is in VSDD — Verified Spec-Driven Development.