The Abstraction and Concretization Skills You Need to Work AI-Natively: Why Coding Agents Make You Faster but Not Your Organization, and How to Put Your Unease Into Words

Hello, this is Ryuta Hamamoto from TIMEWELL.

I keep hearing the same story from people who have started using coding agents: "My own work is clearly faster. But the team's deliverables are not coming out any sooner." Running AI-driven development programs for large companies and founders, I have seen this "the individual is fast, the organization is not" pattern many times. AI was supposed to make up for labor shortages. Why does it not show up in the organization's numbers? This article explains the cause using an old pair of words, abstraction and concretization, and describes the skill that people who work will really need from here.

The conclusion first. There are two causes. We speed up work that is not the bottleneck. And the more context we hand an AI, the more it drifts toward "the answer that is consistent within this context" and the less able it is to give an answer from one level up. For now, only humans can fill those two gaps. Concretely, that means the ability to notice that something is not working, and the ability to put that unease into words. If you want to check where you or your team stand first, the AI literacy check takes about five minutes.

Why "faster" does not make the organization more efficient

Let us start by measuring the gap between what people feel and what is measured.

In July 2025, METR, an AI evaluation organization, published a randomized experiment in which 16 experienced open-source developers had 246 real tasks assigned at random to "AI allowed" or "AI not allowed." The result: with AI, tasks took 19 percent longer. That is not the surprising part. Developers had predicted beforehand that AI would make them 24 percent faster, and even after being slowed down, they still believed it had made them 20 percent faster.¹ The feeling of being faster arises independently of the measurement.

METR published a follow-up in February 2026. In a second experiment that began in August 2025, more developers declined to participate because they did not want to work without AI, and 30 to 50 percent said they were withholding tasks they "did not want to do without AI," so METR writes candidly that the data became unreliable. The raw numbers pointed toward an 18 percent speedup for a subset of the original participants and 4 percent for new participants, but both confidence intervals straddle zero. METR's own conclusion is that developers are "likely" faster with AI in early 2026 but that its data is "only very weak evidence" of how much, and it announced a redesign of the experiment.²

What I want to draw attention to is the self-report survey METR published in May 2026. It asked 349 technical workers separately about the change in "speed" and the change in "value" from AI. The median speed change was 3x. The median value change was 1.4x to 2x.³ METR gives an example of why speed overstates value: a researcher uses AI to build a data dashboard quickly. Without AI it would have taken many times longer, but the dashboard is not important to the project.

That is the first thing this article wants to say. The work that got faster was not the bottleneck.

Manufacturing has an old idea called the theory of constraints. The throughput of a whole process is determined by its slowest step, the bottleneck. An hour lost at the bottleneck is an hour lost for the whole system, but an hour saved at a non-bottleneck does not add a minute of throughput.⁴ Computing has the same law: as Amdahl showed in 1967, as long as a part of the work can only proceed sequentially, parallelizing everything else runs into a ceiling.⁵

Translate that into office work. Suppose a proposal takes two hours to write and three days to approve. If an agent cuts writing to ten minutes, the time until the proposal starts moving is three days and ten minutes. The speed at which the organization's deliverables come out is set by the slow step, approval. And yet the person who wrote it feels twelve times faster, because two hours became ten minutes. METR's "speed 3x, value 1.4x" tells us this is happening all over the world.

One more number, at the macro level. A study by University of Chicago researchers linking large-scale surveys to administrative records in Denmark found that although most employers in exposed occupations had adopted generative AI and workers reported productivity benefits, the effect on earnings and recorded hours was a precise zero, ruling out effects larger than 2 percent two years after the launch of ChatGPT. What changed was the structure of work, with new tasks in AI oversight and integration.⁶ The gulf between individual perception and organizational numbers is not a Japanese phenomenon.

What abstraction and concretization are. Work is a loop

Let me define the words in the title.

Abstraction is pulling "what is this for" and "what structure is this a part of" out of a concrete event. From the task of writing a proposal, you climb one level at a time: "this proposal exists to get approval," "approval sits inside a three-day step," "the purpose of the whole process is next year's revenue." Concretization is the reverse: turning purpose and structure into "who does what, how, today." When you get down to "to cut approval from three days to one, put a summary of the three items the approver looks at first," that is concretization.

In his 1972 Turing Award lecture, the computer scientist Edsger Dijkstra said: "the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise."⁷ I think that sentence works as a technique for any job. People who are good at abstraction are not people who talk vaguely. They are people who can say, precisely and one level up, "the bottleneck in this deal is the approval step."

In Japanese, Isao Hosoya's book on the concrete and the abstract frames the back-and-forth between the two as the working of intelligence itself.⁸ I take the same view. People who are good at their jobs are not people who live at high abstraction or people who only do concrete tasks. They are people who make the round trip often and across a wide range.

So what does it mean to work AI-natively? My definition: "a way of working that delegates part of the loop to AI while a human decides at which altitude to ask the question." Agents are very good at concretization. Say "make a three-item summary for the approver" and one appears in minutes. They can abstract too, if asked. Ask "where is the bottleneck in this workflow" and a plausible answer comes back. The problem is that the quality of that answer depends on the amount and quality of the context we gave the AI, far more than most of us assume.

AI can abstract. But the more context it holds, the more it drifts toward "the answer for this context"

"The more context you give the AI, the smarter it gets." Believing this, many people keep sessions running for hours, paste in entire documents, and carry over the whole history. Research shows this does not simply hold.

"Lost in the Middle," published in 2023 by researchers at Stanford and elsewhere, showed that model performance drops substantially when the relevant information sits in the middle of a long input. Information at the beginning and end gets picked up; the middle gets lost.⁹ NoLiMa, a 2025 study, is harsher: in retrieval where the question and the answer share no vocabulary, so that association is required, 11 of 13 models fell below half of their short-context performance at 32K tokens. Even GPT-4o, the strongest, dropped from 99.3 percent to 69.7 percent, and reasoning modes and chain-of-thought did not preserve performance.¹⁰

Chroma's July 2025 technical report "Context Rot" tested 18 models and confirmed that performance degrades non-uniformly as input grows. The result I find most important comes from LongMemEval, a task of answering questions from conversation history: focused inputs of about 300 tokens, containing only the relevant parts, consistently outperformed the full transcript.¹¹ Giving the model less produced better answers.

In a September 2025 engineering post, Anthropic calls this phenomenon "context rot," explains that models have an "attention budget" similar to human working memory that is depleted with every token added, and defines good context engineering as "finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome."¹² The same post says instructions should be written at "the right altitude," the zone between brittle over-specified instructions and vague ones that give no concrete signal. "Altitude" is a word about abstraction level.

Translate the research into symptoms you can see at work. In a long session with an agent, does this happen? You start at high abstraction, "I want to automate this process," and as the exchange goes on, concrete fixes pile up: "move this button," "clear this error." Before you notice, the agent only returns answers optimized for the most recent instruction. The one-level-up proposal, "do you even need this screen," stops appearing. That is what it means for an AI to drift toward "the answer for this context" the more context it holds.

Honestly, this happens to humans too. The longer a meeting runs, the harder it becomes to question its premises. But there is one difference between humans and AI. Humans can bring a "something is off" feeling in from outside the context. At least for now.

Noticing unease and putting it into words. What Toyota calls "human wisdom"

The Toyota Production System rests on two pillars. One is Just-in-Time. The other is jidoka. In Toyota's own words, jidoka is "automation with a human touch": when an abnormality occurs, whether in equipment, in quality, or as a delay, the machine stops itself, or the operator pulls the cord and stops the line.¹³ Because abnormalities are detected and the line stops, defects do not flow downstream and root causes can be fixed. The same page says that no matter how excellent machines, robots, or IT are, they cannot evolve on their own; only humans can implement kaizen.

I think the core of AI-native work is this idea of jidoka. Agents do not stop. They keep producing "almost right" answers without stopping. In Stack Overflow's 2025 developer survey, the biggest frustration with AI tools, cited by 66 percent, was "AI solutions that are almost right, but not quite," and 45 percent said debugging AI-generated code takes more time. Thirty-three percent trusted the accuracy of AI tools; 46 percent did not.¹⁴ When "almost right" piles up, the one who pulls the cord is a human.

So what does it take to pull the cord? Two things: the ability to notice unease, and the ability to put it into words. Noticing is nearly the same thing as abstraction. The realization "speeding up this task will not speed up the whole" cannot arise unless you look at where you are from one level up. While the agent is stacking concrete fixes, you raise your altitude for a moment and ask "what was this for again." That is noticing.

Putting it into words means turning the noticing into a sentence that can be tested. I recommend writing four lines.

Line	What to write	Example
One	The state you expected	Time from proposal to approval and kickoff is halved
Two	The actual state	Proposals take ten minutes, approval still takes three days
Three	The gap	What got faster was writing; the approval step was never touched
Four	What happens if left alone	Proposal volume grows to match writing speed, and the approval backlog grows with it

Once you can write line four, the unease changes from "something is off" to a judgment: "unless we touch the approval step, this will make things worse." And the four lines become the next instruction to the agent. "Change the format so a summary of the three items the approver looks at sits at the top of the proposal." That is concretization at the right altitude.

The order matters. When you feel unease, write the four lines yourself before asking the AI. If you ask the AI "what do you think the problem is," it will find a problem that is consistent with the context so far, and that problem will usually lie on the extension of the most recent work. Write the four lines first and hand them over, and the AI can start concretizing from one level up.

Five things you can do starting tomorrow

Let me bring this down to tomorrow's work.

First, before automating anything, draw the process on one sheet of paper. From the moment a proposal is born to the moment it reaches a customer: who does what, and how many days each step takes. Connect them with arrows and circle the longest one. That is the bottleneck. Decide what to hand to the agent after looking at the circle. Speeding up a step without a circle just reproduces METR's "speed 3x, value 1.4x" on your own desk.

Second, before handing anything to the agent, write the purpose in one line. "To cut approval from three days to one, create a summary format for the approver." That one line sets the altitude of the instruction. If you cannot write it, that is a signal you have not abstracted yet, so go back to the sheet instead of starting work.

Third, ask questions that require abstraction in an empty context. Asking "is this design right in the first place" in the middle of a long session gets you the answer for that context. Open a separate session, hand over a few hundred characters summarizing the current state, and ask "where is the bottleneck in this process." Chroma's finding that focused inputs of about 300 tokens beat the full transcript is the evidence for this practice.¹¹ The operational details, such as splitting work into subagents and carrying over only summaries, are in Operating AGENTS.md, Skills, Hooks, and cron as an organization.

Fourth, keep an unease log. Once a week, write three instances of unease in the four-line format. A week when you cannot write any is a week when you had no time to raise your altitude. The log becomes a record of your abstraction skill, and reading it six months later shows you which level of unease you have become able to catch.

Fifth, as an organization, reward stopping. Just as Toyota does not blame the worker who pulls the cord, treat the person who said "automating this as is will not speed up the whole" as someone who stopped waste, not someone who stopped progress. This is the job of management. Measure not the number of agents deployed or the hours saved, but how many days the bottleneck shrank. If the measurement does not change, only the feeling of being faster will grow.

In the AI-driven development programs we run for large companies and founders, we run these five steps on participants' real work. We spend more time drawing the process sheet and writing four lines than teaching how to operate coding agents. Operation can be learned in days; the habit of moving up and down in altitude only comes with repetition. The program structure is on the WARP page.

Summary

Coding agents make work faster. That is true. But the feeling of being faster and the organization's numbers diverge. In METR's experiment, developers believed they were 20 percent faster while measuring 19 percent slower; the 2026 survey found speed 3x and value 1.4 to 2x; Danish administrative records show no effect larger than 2 percent on earnings or hours. The causes are speeding up steps that are not the bottleneck, and AI drifting toward the answer for its context the more context it holds, becoming less able to answer from one level up.

So what people who work will need from here is the ability to run the abstraction-concretization loop themselves, and, in the middle of the loop, to notice "something is off," write it in four lines, and pull the cord. AI does not stop. People do the stopping.

If you do one thing tomorrow, take one task you currently hand to an agent and write one line: "Which step of the process is this, and is that step the bottleneck?" If you cannot write it, that is your first unease. If you want to design this loop for your own operations together, let's talk.

Footnotes

1. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (METR, July 10, 2025). Randomized controlled trial with 16 developers and 246 tasks. Forecast 24 percent faster, post-hoc belief 20 percent faster, measured 19 percent slower ↩

2. We are Changing our Developer Productivity Experiment Design (METR, February 24, 2026). Selection effects in the second experiment and raw estimates (-18 percent for original participants, -4 percent for new ones, both with confidence intervals straddling zero) are from this post ↩

3. Measuring the Self-Reported Impact of Early-2026 AI on Technical Worker Productivity (METR, May 11, 2026). Survey of 349 technical workers, February to April 2026. Median value change 1.4 to 2x, median speed change 3x ↩

4. Eliyahu M. Goldratt and Jeff Cox, The Goal (North River Press, 1984). The original text on the theory of constraints ↩

5. Validity of the single processor approach to achieving large scale computing capabilities (Gene M. Amdahl, AFIPS 1967) ↩

6. Still Waters, Rapid Currents: Early Labor Market Transformation under Generative AI (Anders Humlum and Emilie Vestergaard, NBER Working Paper 33777, May 2025, revised March 2026). Previously circulated as "Large Language Models, Small Labor Market Effects" ↩

7. The Humble Programmer (Edsger W. Dijkstra, 1972 ACM Turing Award Lecture, EWD340) ↩

8. Isao Hosoya, Gutai to Chusho (The Concrete and the Abstract) (dZERO, 2014, Japanese) ↩

9. Lost in the Middle: How Language Models Use Long Contexts (Nelson F. Liu et al., arXiv:2307.03172, TACL 2024) ↩

10. NoLiMa: Long-Context Evaluation Beyond Literal Matching (Ali Modarressi et al., arXiv:2502.05167, 2025) ↩

11. Context Rot: How Increasing Input Tokens Impacts LLM Performance (Chroma, Kelly Hong et al., July 14, 2025) ↩ ↩²

12. Effective context engineering for AI agents (Anthropic, September 29, 2025). "Context rot," "attention budget," and "right altitude" are the post's own terms ↩

13. Toyota Production System (Toyota Motor Corporation global site). Describes jidoka as "automation with a human touch," stopping on abnormalities, and kaizen as something only humans can do ↩

14. 2025 Developer Survey: AI (Stack Overflow, 2025). "Almost right, but not quite" 66 percent, "debugging is more time-consuming" 45 percent, trust in accuracy 33 percent, distrust 46 percent ↩