Tuesday
29 September 2026

When AI tools do more of the drafting and building, some work that people did along the way stops happening. Six pieces published between 25 and 28 September each name a part of that work, and suggest how a team can keep it. Five engineering pieces from 29 September cover teams of coding agents, architecture, a developer survey, earlier approvals and how junior engineers build judgement.

Jeff Reynar runs this+that, a start-up whose AI software handles the requests that arrive in a company's email and chat (29 Sep · 01). He writes about a randomised trial published on 17 September, in which 133 patent lawyers used an AI drafting assistant for three months. With the assistant, their work improved, most of all for the juniors. Tested without it afterwards, only the senior lawyers had become more skilled. Reynar argues that a company forgets in the same way when AI agents do its work, and that nothing it measures shows the loss.

Pavel Samsonov writes The Product Picnic, a newsletter on UX and product management (29 Sep · 02). He argues that AI tools make it easy to mistake a working prototype for a valuable product. Drawing on the chatbot pioneer Joseph Weizenbaum, he says a team should ask what it is trying to achieve before asking whether a computer can help. He praises a guide for business people who commission software: define the business rules first, and never hand a developer an AI prototype with the words "build this". His own advice is to keep any solution, AI included, out of a team's vision statement.

Maya Elise Joseph-Goteiner founded Velocity Ave, a user-experience agency, and writes the newsletter Nimble UX (29 Sep · 03). She observes that research teams increasingly direct and edit what AI tools produce, instead of creating the work themselves. She argues that editing AI output differs from editing a colleague's work, because no author stands behind it to explain an intention or push back. One leader her firm interviewed imagined a research team of one person and many AI agents. She says such a team would lose the colleague who disagrees and catches what was missed.

Guilherme Negreiros is building a design system on his own, in public, with AI agents doing much of the work (29 Sep · 04). A fix for Apple's Safari browser needed one colour written straight into the code, and three weeks later an automated check for such colours removed it. He restored it the same day, and now writes each rule and its exceptions in a short file that the agents read every session. The reasons behind each rule go in a separate record for people. Any rule that a script cannot check has a named person who can say no.

Nate B. Jones, who writes an AI newsletter, looks at teams where one person gets far more done with AI agents than everyone else (29 Sep · 05). The team still falls behind, because code arrives faster than anyone can review it, and prototypes arrive before anyone has agreed what they should do. The usual answer is to make the fast person teach everyone, which Jones says uses up the very capacity the team wanted. He proposes six principles instead, such as leaving work in a state that someone else can continue. The detail of his briefing is for paying subscribers, and this account comes from its open part.

Cristian Morales Achiardi, a design engineer at the design-systems firm Southleft, spoke with Shane P Williams for Design Systems Collective (29 Sep · 06). As the only designer at the company Enara, he built a design system whose code, design files and documentation are all generated from specifications that machines can check. When a result is wrong, he fixes the specification rather than the result. He also found that AI agents sometimes did better without extra instruction files, because more context can confuse them. Once the team built three to four times faster, he became the bottleneck, because design still needs time to explore ideas and discard most of them.

Jonah Turnquist is co-founder and chief technology officer of PropCode, which analyses planning regulations for Australian properties (29 Sep · 07). Running AI coding agents on several projects at once, he found himself passing messages between them so that they would not contradict each other. He now runs them as a team: a manager agent that only coordinates, one agent per feature, and a small agent that forwards review comments to the right owner. Written rules say which actions agents may take alone and which, such as merging and deploying, wait for him. The cost in his experience is his own time: "What you will feel is the review load."

Cate Huston, who wrote a book on engineering leadership, is the part-time chief technology officer of Twill (29 Sep · 08). Twill is a platform where members, candidates and recruiters each see the same data differently. Her team rebuilt Twill in four months by keeping the scope tight. She still paid for two costly pieces of architecture: a design system, and one central model of who may see what. She writes that neither would have been worth it before AI agents wrote code, and that both have since caused far fewer problems than expected. She argues that judging what will change remains a human job: "Agents talk about time, but they don’t experience it."

Agoda, the online travel booking company, surveys software developers and engineering leaders in India and six Southeast Asian countries each year, and published the findings of its second report (29 Sep · 09). Just over half have AI agents in production or broad use, but only 38 percent call their code ready for an agent that works fully on its own. Developers name cost as the main barrier, and the report finds that most of it lies in reviewing and checking the agents' work. Most still keep a person in charge: 79 percent require human approval before a production deployment. When an agent causes a problem, 42 percent hold the developer responsible and 2 percent blame the AI vendor. The survey is Agoda's own, and the post does not say how many people answered. Junior developers worry most about their jobs, and the report argues: "Access to AI tools is no longer the differentiator."

Rama Lingamgunta builds platforms on which AI agents take work from requirements through code, tests and deployment, and describes how that work is now approved (29 Sep · 10). The first approval step was one Approve button on the agent's finished change. Within a month a reviewer approved 1,400 changed lines in under two minutes, because the agent's own tests passed. Lingamgunta now asks named people to approve the plan, the design and the release separately, each from a short brief. A fixed list of risky changes always goes to a person. The list includes the approval rules themselves: "If an agent can edit the file that decides what needs approval, you don’t have gates, you have suggestions."

Mia de Búrca, a staff engineer at the online printing company Vistaprint, writes for LeadDev about how junior engineers learn judgement (29 Sep · 11). They used to learn it by struggling with unfamiliar code and explaining their reasoning to senior colleagues. She argues that AI assistants now smooth much of that away. She asks leaders to name critical thinking as part of the job. She also asks them to protect the practices that build it, such as incident reviews that ask what the team wrongly believed. She sums up the loss in two sentences: "Some friction was drag. Some friction was education."

Faster tools remove steps that people used to take along the way, and each author names one. The steps are practising a skill, deciding what to build, arguing over a draft, writing down why a rule exists and leaving work that someone else can pick up. Each author suggests a way for a team to keep doing that step on purpose.

Most of these pieces argue rather than report: they are essays, an interview and one person's solo project, and the one controlled trial studied patent lawyers. None of the six describes what happened when a product team adopted the practice it proposes.