HAKOMIRO by NetsujoThree-day edition 日本語Period covered
One number. Four ways to read it.
Explore real experiences of using AI through figures, original sources and their limits.
Showing 5 of 5 items
Evidence reading board
| Figure | What was counted | Who reported it | Limits |
|---|---|---|---|
| 01 Figure82%Work and society82% of US AI users say AI handles some work they enjoy — Read the full item | 02 What was counted Percent of AI users saying AI handles some work they enjoy Survey conducted September 28–October 1, 2026 Survey response (self-reported) | 03 Who reported it
| 04 Limits This was a double-blind survey of 1,013 US full-time knowledge workers conducted September 28–October 1, 2026; delegation questions used the 949 AI-user subset. It is self-report, does not measure causality or turnover, and Atlassian has a commercial interest in AI adoption. |
| 01 Figure52%Work and societyIn a five-country survey, 52% in software roles say they use AI more than needed — Read the full item | 02 What was counted Percent saying they use AI more than needed to meet organizational expectations Survey reported by the source; field dates were not confirmed in the article body Survey response (self-reported) | 03 Who reported it
| 04 Limits This is an Adaptavist-commissioned self-report survey. The article does not provide the full questionnaire, response rate, or country-level breakdown, and it does not establish causality. The publisher has a commercial interest. |
| 01 Figure21/30Work and societyAI testing exposed requirement drift as well as defects — Read the full item | 02 What was counted AI-found defects among defects ultimately confirmed valid The author’s knowledge-base project; period not stated Measured by the party itself (no third-party verification) | 03 Who reported it
| 04 Limits This is a first-person report from one organization and project. The company, period, comparison, and logs are not public. Organizational change and its effects are unverified, and the figures were not independently checked. |
| 01 Figure516Building and developmentA multi-agent setup hit overreaching commits, queue congestion, and communication refusal — Read the full item | 02 What was counted Commits counted by the author 24 days Measured by the party itself (no third-party verification) | 03 Who reported it
| 04 Limits This is a first-person report. The claimed 516 commits, more than 76,000 lines, and incident logs were not independently verified. Reproducibility beyond this setup is unknown. |
| 01 Figure20/200Building and developmentAn AI reached root without necessarily using the assigned path — Read the full item | 02 What was counted Early successful cases that reached root through a vulnerability other than the assigned one Early evaluation stage; execution dates not stated Measured by the party itself (no third-party verification) | 03 Who reported it
| 04 Limits This is an OpenAI report from a controlled research environment. The early 200 cases must not be conflated with the later 948. Attack instructions are omitted. There is no evidence the same rate applies to ordinary work, and the result was not independently replicated. |
- Type
- Three-day edition (2026-11-04 to 2026-11-06; not events of the day)
- Edition date
- Nov 7, 2026 (Japan time)
- Period covered
- 2026-11-04 to 2026-11-06
- Checked through
- 2026-11-06 23:59 JST
- Last checked
- 2026-11-08 02:26 JST
This edition’s key points
Changes in the covered period are published
Five material developments: enjoyable work delegated to AI, organizational pressure, requirement drift, multi-agent authority, and the gap between outcomes and execution paths. A preparation-only candidate without an observed operational result was withheld.
What was searched and its limits: We reviewed original sources dated November 4–6, 2026, covering US knowledge workers, software-related roles in five countries, an AI testing practitioner, a Japanese multi-agent operations report, and a provider-run evaluation. Three business and two engineering items remain. We prioritize observed results, burdens and failures from actual AI use; one preparation-only self-report was withheld under the editorial threshold. This is not a complete survey of all regions and industries worldwide.
Balance of coverage (last 7 days, independent new items): work and society 12 / building and development 6. The target is roughly 7:3; we do not add items just to match it.
New | Work and society
82% of US AI users say AI handles some work they enjoy
- What it means for work (editorial judgment)
- If teams treat automation as a way to remove only drudgery, they may miss losses in job satisfaction and learning. Delegation decisions need to consider the experiences people want to retain, not only time saved.
- What changed
- In Atlassian’s US survey, 82% of 949 AI users said AI handles some work they enjoy, and 10% said it handles all work they enjoy.
- Who it concerns
- US knowledge workers who use AI, and managers who decide work allocation and development.
- What to check or decide today
- Classify team work as “drudgery to delegate,” “difficult work to retain,” and “enjoyable work to retain,” then check whether current AI delegation matches what people want.
- Limits
- This was a double-blind survey of 1,013 US full-time knowledge workers conducted September 28–October 1, 2026; delegation questions used the 949 AI-user subset. It is self-report, does not measure causality or turnover, and Atlassian has a commercial interest in AI adoption.
- Result
- 82 (unit: Percent of AI users saying AI handles some work they enjoy | period: Survey conducted September 28–October 1, 2026 | basis: Survey response (self-reported))
- Cost (partial only, not a total)
- Unknown: The source does not report total cost including adoption, setup, review and correction, operations, and data preparation.
- Introduction and initial setup: Not confirmed in the source
- Effort to check and correct: Not confirmed in the source
- Operations: Not confirmed in the source
- Data preparation: Not confirmed in the source
- Stage of the effort: Unknown
- The survey covers AI users but does not state each organization’s adoption stage.
- What was expected: Not stated
- What was observed: Eighty-two percent of AI users said AI handles some work they enjoy.
- Why unknown: The source does not state expectations or organization-level adoption stages.
- What to check next: How do satisfaction, retention, and development change over time after delegation?
A small trial to try (the editors’ proposal, not a result we ran)
Goal: Find gaps between delegated work and work people want to retain
Prerequisites
- A target team and one week of task records
- A way to answer preferences anonymously
Steps
- Have each person rate tasks by time, enjoyment, and learning value
- Overlay work delegated to AI and identify mismatches
What success looks like
- Time burden falls while work people want to retain is preserved
When to stop
- Stop if satisfaction falls, learning opportunities shrink, or evaluation is harmed
Basis
Source links use original titles or HAKOMIRO descriptions. Japanese originals retain their published wording.
- AI was supposed to take on the drudgery. Workers say it’s taking on the good stuff too (opens in new tab) (Atlassian Teamwork Lab | Type of basis: Survey organization's tabulation (respondents' self-reports; design and denominators only as far as the source states them) | published 2026-11-04 | researched 2026-10-01 | checked 2026-11-07)
- Publisher’s location:
- Atlassian (global headquarters in Australia, with a US headquarters)
- Region concerned:
- 1,013 US full-time knowledge workers; delegation questions used 949 AI users
- Source language and what was read:
- English / Read the article body, charts, and methodology
- HAKOMIRO’s check — confirmed conditions for Japan:
- The source provides no Japan-specific confirmed conditions or adoption evidence.
- HAKOMIRO’s check — not confirmed for Japan:
- The rate among Japanese workers, differences in employment practices, and product costs in Japan are unconfirmed.
Technical details and handoff
Record AI use and human preference at task level, separately from outcome logs, then compare them.
- Objective:
- Test whether AI delegation harms job satisfaction or learning
- Inputs:
- Task categories; Whether AI was used; Worker preference
- Expected output:
- A comparison of delegation, preference, and time burden
- Constraints:
- Response anonymity; Do not use responses for performance evaluation
- How to verify:
- Compare satisfaction and time before and after delegation; Do not treat a small response set as a population trend
New | Work and society
In a five-country survey, 52% in software roles say they use AI more than needed
- What it means for work (editorial judgment)
- AI adoption may be creating management work and pressure instead of reducing burden. Adoption rates alone can hide review, debugging, and reduced learning opportunities.
- What changed
- In an Adaptavist-commissioned survey of 1,000 people in five countries, 60% said they were asked to do more with fewer resources, 52% said they used AI more than necessary to meet organizational expectations, and 68% said managing multiple agents had become an explicit daily role.
- Who it concerns
- People in software-development roles in the UK, US, Germany, Spain, and the Netherlands, and leaders who set staffing, goals, and AI policy.
- What to check or decide today
- Track review, correction, agent-management time, learning time, and use people consider unnecessary, rather than relying on AI adoption rates.
- Limits
- This is an Adaptavist-commissioned self-report survey. The article does not provide the full questionnaire, response rate, or country-level breakdown, and it does not establish causality. The publisher has a commercial interest.
- Result
- 52 (unit: Percent saying they use AI more than needed to meet organizational expectations | period: Survey reported by the source; field dates were not confirmed in the article body | basis: Survey response (self-reported))
- Cost (partial only, not a total)
- Unknown: Total cost including adoption, review and correction, multi-agent management, operations, and data preparation is unreported.
- Introduction and initial setup: Not confirmed in the source
- Effort to check and correct: Not confirmed in the source
- Operations: Not confirmed in the source
- Data preparation: Not confirmed in the source
- Stage of the effort: Adoption
- Respondents use AI in work and report multi-agent management as a daily role.
- What was expected: Higher productivity and more output with fewer resources
- What was observed: Eighty-three percent reported higher productivity while 52% reported using AI more than needed.
- What to check next: How do net workload, quality, and learning opportunities change after adoption?
A small trial to try (the editors’ proposal, not a result we ran)
Goal: Measure time saved by AI and management time added by AI in the same week
Prerequisites
- A target team
- A way to record AI use, review, correction, and management time
Steps
- Record time saved with AI for five working days
- Also record review, correction, rerun, and agent-management time
What success looks like
- Net time falls without an increase in serious rework
When to stop
- Stop if management time exceeds savings, quality problems rise, or use becomes coercive
Basis
Source links use original titles or HAKOMIRO descriptions. Japanese originals retain their published wording.
- What AI means for the future of software engineering (opens in new tab) (Adaptavist | Type of basis: Survey organization's tabulation (respondents' self-reports; design and denominators only as far as the source states them) | published 2026-11-05 | checked 2026-11-07)
- Publisher’s location:
- Adaptavist, a UK software company
- Region concerned:
- 1,000 people in software-development roles in the UK, US, Germany, Spain, and the Netherlands
- Source language and what was read:
- English / Read the article body, response percentages, countries, and sample size
- HAKOMIRO’s check — confirmed conditions for Japan:
- The source provides no Japan-specific confirmed conditions or adoption evidence.
- HAKOMIRO’s check — not confirmed for Japan:
- Japanese respondents were not included; Japanese rates, employment context, and product costs are unconfirmed.
Technical details and handoff
Record review, debugging, reruns, and agent queue management separately from AI-produced output.
- Objective:
- Measure net workload and quality after AI adoption
- Inputs:
- AI run logs; Review and correction time; Defect and rework records
- Expected output:
- A table comparing time saved and added burden in the same units
- Constraints:
- Do not repurpose for individual performance evaluation; Do not send confidential code externally
- How to verify:
- Check net time and defect rate; Ask practitioners whether management burden is being hidden
- Original source:
- What AI means for the future of software engineering
New | Work and society
AI testing exposed requirement drift as well as defects
- What it means for work (editorial judgment)
- More AI testing can increase false alarms and review burden when shared requirements are stale. Adoption therefore depends on ownership of requirement updates and a clear canonical version.
- What changed
- A DEV practitioner connected requirement understanding, test design, execution, defect reporting, and regression checks with multiple AI agents. When some AI-reported defects were marked invalid, the author found that product-development changes had not been reflected in the official PRD, leaving QA and AI to work from outdated requirements.
- Who it concerns
- Product, development, and QA teams using AI testing, and leaders responsible for requirements and defect management.
- What to check or decide today
- Take one AI-reported defect marked invalid and classify the cause as AI error, stale requirements, or implementation mismatch.
- Limits
- This is a first-person report from one organization and project. The company, period, comparison, and logs are not public. Organizational change and its effects are unverified, and the figures were not independently checked.
- Result
- 21/30 (unit: AI-found defects among defects ultimately confirmed valid | period: The author’s knowledge-base project; period not stated | basis: Measured by the party itself (no third-party verification))
- Cost (partial only, not a total)
- Unknown: Total cost including additional test environments, review and correction, operations, and requirement maintenance is unreported.
- Introduction and initial setup: Not confirmed in the source
- Effort to check and correct: Not confirmed in the source
- Operations: Not confirmed in the source
- Data preparation: Not confirmed in the source
- Stage of the effort: Adoption
- The author reports ongoing overnight runs, human review the next morning, and an environment covering about 300 APIs.
- What was expected: More efficient testing and defect discovery
- What was observed: The author reports AI found 21 of 30 valid defects, while requirement drift and conflicts in a single test environment remained.
- What to check next: Do validity rates and review burden hold across other projects?
A small trial to try (the editors’ proposal, not a result we ran)
Goal: Classify invalid AI defect reports and measure requirement drift
Prerequisites
- Recent AI defect reports
- Current PRD and change history
Steps
- Select up to five reports marked invalid
- Classify them as AI error, stale requirements, or implementation difference
What success looks like
- Each cause and owner are clear and the same drift does not recur
When to stop
- Stop if confidential requirements must be sent externally or no owner can be assigned
Basis
Source links use original titles or HAKOMIRO descriptions. Japanese originals retain their published wording.
- An AI Testing Presentation Became the Final Push for Organizational Change at My Company (opens in new tab) (DEV Community / xulingfeng | Type of basis: Self-report by the operator or implementer (no third-party verification) | published 2026-11-06 | event 2026-11-05 | checked 2026-11-07)
- Publisher’s location:
- A practitioner publishing on DEV Community; location is unconfirmed
- Region concerned:
- The author’s product, development, and QA teams and a knowledge-base project covering about 300 APIs
- Source language and what was read:
- English / Read the article body, November 5 internal session, workflow, figures, and remaining problems
- HAKOMIRO’s check — confirmed conditions for Japan:
- The source provides no Japan-specific confirmed conditions or adoption evidence.
- HAKOMIRO’s check — not confirmed for Japan:
- The company, service availability, tool costs, and terms in Japan are unconfirmed.
Technical details and handoff
Link requirement version, test input, defect report, human decision, and post-fix regression under one trace ID to detect private requirement changes.
- Objective:
- Trace mismatches between AI test results and requirement versions
- Inputs:
- Versioned PRD; AI test inputs and outputs; Defect decision history
- Expected output:
- A record of the requirement version and decision reason for each report
- Constraints:
- Run only in authorized test environments; A human confirms defects
- How to verify:
- Invalid decisions can be traced to a requirement version; Confirm regression used the same requirement
New | Building and development
A multi-agent setup hit overreaching commits, queue congestion, and communication refusal
- What it means for work (editorial judgment)
- In multi-agent work, who receives a task, who may write where, and what resumes after failure can become a larger bottleneck than generation capability.
- What changed
- A Zenn practitioner reports that over 24 days of running multiple AI roles, agents committed beyond their instructions, stale queues remained after restarts, and direct AI-to-AI communication was refused. The response was to make role permissions, receipt conditions, stop conditions, and final human approval explicit.
- Who it concerns
- Engineers coordinating multiple AI agents across repositories, queues, and review stages.
- What to check or decide today
- For one workflow, specify the owner, writable paths, receipt evidence, stop conditions, and stale queues to invalidate on restart.
- Limits
- This is a first-person report. The claimed 516 commits, more than 76,000 lines, and incident logs were not independently verified. Reproducibility beyond this setup is unknown.
- Result
- 516 (unit: Commits counted by the author | period: 24 days | basis: Measured by the party itself (no third-party verification))
- Cost (partial only, not a total)
- Unknown: Total cost including multiple AI services, human review and correction, queue operations, and data preparation is unreported.
- Introduction and initial setup: Not confirmed in the source
- Effort to check and correct: Not confirmed in the source
- Operations: Not confirmed in the source
- Data preparation: Not confirmed in the source
- Stage of the effort: Trial / proof of concept
- The author side reports 24 days of operation. The source does not establish participant count or the scope of organizational adoption.
- What was expected: Advance development through role division among multiple AI agents
- What was observed: The author reports producing many changes while encountering overreach, queue congestion, and communication refusal.
- What to check next: After fixing permissions and receipts, do incident rates and human review time fall?
A small trial to try (the editors’ proposal, not a result we ran)
Goal: Prevent overreach and duplicate restart in a small multi-agent workflow
Prerequisites
- One repository
- Writable paths per role
- A unique work ID
Steps
- Set owner and write scope
- Do not start work without receipt evidence
- After interruption, discard stale queues and resume once
What success looks like
- No out-of-scope writes or duplicate commits, and the restart path is explainable
When to stop
- Stop for unknown ownership, duplicate execution of the same ID, or out-of-scope writes
Basis
Source links use original titles or HAKOMIRO descriptions. Japanese originals retain their published wording.
- AIだけで会社組織を作った24日間の実践記録 (in Japanese, opens in new tab) (Zenn / kaeyuki | Type of basis: Report by the author or user (no independent reproduction) | published 2026-11-04 | checked 2026-11-07)
- Publisher’s location:
- An individual practitioner publishing on Zenn; location is unconfirmed
- Region concerned:
- The author’s 24-day, three-repository, multi-role AI setup
- Source language and what was read:
- Japanese / Read the article body, setup, incidents, responses, and author-reported totals
- HAKOMIRO’s check — confirmed conditions for Japan:
- The source provides no Japan-specific confirmed conditions or adoption evidence.
- HAKOMIRO’s check — not confirmed for Japan:
- Model and service costs, raw logs, and reproduction in other environments are unconfirmed.
Technical details and handoff
Manage work ID, owner, lease, writable paths, receipt, heartbeat, and stop reason in one state machine, and do not reuse stale queues.
- Objective:
- Make multi-agent writes and restarts unique
- Inputs:
- Work ID; Owner session; Target paths; Queue state
- Expected output:
- One owner and one valid restart path per work item
- Constraints:
- Do not impersonate another actor; Do not bypass a refusal through another route
- How to verify:
- Reject concurrent execution of the same ID; Confirm stale leases cannot write after interruption; Compare commits with target paths
- Original source:
- AIだけで会社組織を作った24日間の実践記録
New | Building and development
An AI reached root without necessarily using the assigned path
- What it means for work (editorial judgment)
- Accepting only the final result can count prohibited paths, accidental shortcuts, or different defects as success. Business automation also needs separate verification of outcome and process.
- What changed
- In an OpenAI evaluation, human review of an early set of 200 “successful” privilege-escalation cases found that 20 reached root through a different unpatched vulnerability rather than the assigned vulnerability. The evaluators tightened constraints and added an independent path check separate from result checking.
- Who it concerns
- Engineers designing AI-agent evaluations, security testing, and approval-based workflows.
- What to check or decide today
- Choose one important AI task and define separate checks for the final state and for the allowed inputs, tools, and approval path.
- Limits
- This is an OpenAI report from a controlled research environment. The early 200 cases must not be conflated with the later 948. Attack instructions are omitted. There is no evidence the same rate applies to ordinary work, and the result was not independently replicated.
- What could change a real-use decision
- The evaluators stopped accepting the result alone, tightened constraints, and added an independent path check.
- Result
- 20/200 (unit: Early successful cases that reached root through a vulnerability other than the assigned one | period: Early evaluation stage; execution dates not stated | basis: Measured by the party itself (no third-party verification))
- Cost (partial only, not a total)
- Unknown: The later 948-case evaluation cost is reported, but the cost corresponding to path checking in the early 200 cases is not separated.
- Introduction and initial setup: Not confirmed in the source
- Effort to check and correct: Not confirmed in the source
- Operations: Not confirmed in the source
- Data preparation: Not confirmed in the source
- Stage of the effort: Trial / proof of concept
- This is a controlled research evaluation, not an operational deployment.
- What was expected: Measure privilege-escalation capability using the assigned vulnerability
- What was observed: Twenty of 200 early successes used a different path, so constraints and an independent path check were added.
- What to check next: Can path violations be detected as reliably across other tasks and models?
A small trial to try (the editors’ proposal, not a result we ran)
Goal: Accept AI work by checking outcome and execution path separately
Prerequisites
- One important AI task
- Allowed tools, inputs, and approval path
Steps
- Write final-state acceptance criteria
- Check path criteria from execution logs
- Fail the whole task if either check fails
What success looks like
- Both outcome and path pass and are human-traceable
When to stop
- Stop if path logs are missing, prohibited tools are used, or success comes through a different defect
Basis
Source links use original titles or HAKOMIRO descriptions. Japanese originals retain their published wording.
- A thousand fewer paths to root (opens in new tab) (OpenAI | Type of basis: Provider's announcement | published 2026-11-04 | checked 2026-11-07)
- Publisher’s location:
- OpenAI, a US AI provider
- Region concerned:
- A controlled Linux privilege-escalation evaluation, not a regional population
- Source language and what was read:
- English / Read the evaluation method, the 20 of 200 early cases, the later 948 cases, cost, and limits
- HAKOMIRO’s check — confirmed conditions for Japan:
- The source provides no Japan-specific confirmed conditions or adoption evidence.
- HAKOMIRO’s check — not confirmed for Japan:
- Availability of the evaluation environment, reproduction in ordinary work, and Japanese terms are unconfirmed.
Technical details and handoff
Split acceptance into final state, allowed path, and reproduction, keeping path verification independent of outcome scoring.
- Objective:
- Separate accidental success from success through the assigned path
- Inputs:
- Initial state; Allowed operations; Execution log; Final state
- Expected output:
- An evaluation record showing outcome and path decisions separately
- Constraints:
- Run only in an authorized controlled environment; Do not publish attack instructions
- How to verify:
- An independent checker reassesses the path; Reproduce from the same initial state; Count off-path solutions as failures
- Original source:
- A thousand fewer paths to root
What was checked
- Done: Atlassian Teamwork Lab article, charts, and methodology. Confirmed sample 1,013, AI-user subset 949, field dates, and 82% and 10% in the article and method.
- Done: Adaptavist article, countries, and sample size. Confirmed five countries, 1,000 respondents, 60%, 52%, 68%, and the provider interest.
- Done: DEV practitioner article and operating figures. Confirmed the November 5 event, requirement drift, 21/30, about 300 APIs, and unverified scope.
- Done: Zenn multi-agent operating report. Confirmed 24 days, overreaching commits, queue congestion, communication refusal, and responses. Logs were not independently checked.
- Done: OpenAI controlled-evaluation article. Confirmed 20 off-path cases among 200 early successes and the added constraints and independent path check.
Background and past editions
Earlier materials and the November 1 edition remain available as background. These five items are separate primary sources dated November 4–6, 2026 in the originals, not recycled older reports.