Reading Room

This is on your desk today because it is a clean gut check on how much of today's AI ambition is actually new. In October 1983, the Defense Advanced Research Projects Agency (DARPA, the US military's research arm) published a public plan to build what it called machine intelligence technology within ten years. This was not a leak or a document pried loose later. DARPA wrote it to be approved for public release, and it sits in the public archive under reference number ADA141982.

The plan runs about 110 pages and lays out a ten year roadmap. It budgeted roughly 600 million dollars for the first five years alone: 50 million dollars in fiscal 1984, rising to 150 million dollars by fiscal 1986, with later years left open depending on progress. The plan set out to build machine intelligence for autonomous vehicles, pilot assistance, and battle command, using the same building blocks, planning, reasoning, vision, speech, and natural language, that still define AI research today.

Two of the three demonstration projects show how specific the ambition was. The Autonomous Land Vehicle had to drive itself across 50 kilometers of open terrain at up to 60 kilometers an hour, reading digital maps and spotting obstacles without a driver. DARPA estimated it would need computing power of 10 to 100 billion operations per second, at a time when the fastest ordinary computers ran at 30 to 40 million operations per second: roughly a thousand times more power than existed anywhere in 1983. The Battle Management System, developed for the carrier USS Carl Vinson, was meant to generate hypotheses about an enemy's intent, propose several courses of action, simulate how each would likely play out, and explain its reasoning to a human commander who kept the final decision.

Historians Alex Roland and Philip Shiman, who wrote the definitive account of the program, found it produced real advances in parallel computing, chip design, and speech recognition, but fell well short of the machine intelligence goals this 1983 plan set out. The document itself instructs readers to treat its ambitions as DARPA's 1983 forecast, not as an account of what was actually built.

The value here is not whether DARPA was right or wrong. It is that a formal, funded, ten year plan for autonomous vehicles, pilot assistance, and battle command, using the same building blocks, planning, vision, speech, and language, that AI research still uses today, existed 43 years before this morning's AI headlines, and it still fell short of what it promised. That is a useful anchor the next time a plan or a pitch tells you a breakthrough is just a decade away.

This lands on your desk because you run a lot of decisions through Claude, and this is a sharp line on when it is fine to hand someone that output directly, and when it just offloads your job onto them.

A developer describes getting messages in Slack, in pull request feedback, and in WhatsApp arguments that are just "Claude said: [giant response verbatim]", pasted in whole with no editing. He calls the person doing this a "meat proxy": a human standing between him and the AI's answer, adding nothing, since he could ask Claude himself, get there faster, and control the context around the question.

His complaint is that reading AI output is real work. It is verbose, it can sound plausible while being wrong, and it is often dense with jargon. He gives an example line Claude gave him: "NATS control-plane events: stream leader election / R3 quorum re-form during pod churn," and says he had to look up almost every word to make sense of it.

His rule: prompt the AI all you want, but read the answer, understand it, check it, and then write your own reply in your own words. That rewriting step is the proof you actually did the first three, and it is the value you add that a straight paste does not.

He points to code review as the sharpest case. With Claude Code, you can now paste a ticket description straight into it, never read the code it writes, paste reviewer comments back in, and never read those either, repeating until it merges. His question: who actually did the implementation? The reviewers did, using Claude Code, with you as the meat proxy in between.

This is worth pausing on because you are trying to build a company that runs on AI agents, and it draws a sharp line between using AI to think less and using it to think better.

Most AI discussion, the writer says, is about better models, better prompts, productivity, and which jobs disappear. Those matter, but the bigger question is being skipped: how do we use AI to make people more capable, not just to make work go faster.

The argument is that new technology has never removed the need for expertise, it has only changed what expertise looks like. If AI takes over routine work, human value shifts toward judgment, creativity, leadership, ethics, and communication, plus a new skill: evaluating the AI's output itself. On this view, AI literacy should not just teach people prompts. It should teach people how to grow because of AI, cutting the busywork while keeping the thinking that actually builds skill.

The writer runs through who still needs to be the final check: doctors evaluating diagnoses, engineers evaluating designs, teachers evaluating learning, lawyers evaluating legal reasoning, scientists evaluating discoveries. As AI gets better, the person who asks the right question, understands the context, makes the hard tradeoff, and is accountable for the result becomes more valuable, not less.

The piece ends on an open question worth sitting with yourself: if AI keeps getting smarter, how do you make sure you are still building your own judgment, not just outsourcing it. A fair prompt for how you use Claude day to day, not just whether you use it.

Outside your usual reading: Bloomberg reports that as AI becomes part of daily life, disagreements over the technology are increasingly disagreements over values. Worth a beat since you are building something that depends on people getting comfortable adopting AI themselves.

A short piece asks how people can keep learning well in the age of AI without losing the ability to think for themselves. Worth a quick check since you are wiring AI deeply into how you work and learn every day.

You pay for AI subscriptions and trust the limits printed on the sign up page. This is a case study in what happens when a company changes those limits without saying so. A write up of complaints on the r/ArtificialInteligence forum found that Perplexity has cut its Pro plan's limits three separate times in eight months.

In November 2025, Perplexity quietly rerouted which underlying model handled some Pro requests, sending users a cheaper model without telling them, then called it "an engineering bug" once people noticed. In February 2026, Deep Research (a mode that runs many searches and reads many pages before writing an answer) was cut from about 600 runs a day down to about 20 runs a month. In May 2026, plain Pro search itself was halved to 100 searches a week, and the cut applied mid subscription, hitting people who had already paid for a full year.

The complaints back this up. Posts about running into limits (113 of them) and posts about price versus value (121) are by far the biggest complaint clusters on the subreddit, and many include screenshots and raw responses from Perplexity's own systems as proof, not just claims. Everyone the write up could find defending the pricier Max tier turned out to run heavy AI agent workloads themselves, meaning the plan works for building with AI but not for the plain search Pro was originally sold on. Even the most vocal defender admitted search was not really his use case.

The plan's public ratings tell two different stories depending on where you look: Google Play shows 4.6 stars from 2 million ratings, while Trustpilot shows 1.5 stars with 82 percent one star reviews. The write up notes both are true, just measuring different doors, likely casual mobile sign ups versus people who went looking specifically to complain or cancel. Perplexity's own pricing page publishes no numbers for Pro, which is part of why the cuts could happen quietly in the first place. The author has posted the full method and the open dataset for anyone who wants to check the math.

For you, the real lesson isn't about Perplexity specifically, it's about reading subscription terms as living documents rather than fixed contracts. If you rely on a paid AI tier for real work, especially something like Deep Research, it's worth five minutes checking what your plan actually gives you today against what you signed up for.

You look for a fast read on what's actually gaining traction in AI coding and agent tools, and this saved LinkedIn post is that: 20 GitHub projects (GitHub is where most software code is stored and shared), sorted into five categories, each with its star count, a rough measure of how many developers have flagged the project as useful.

The AI coding agents group leads with OpenClaw at 278,000 stars, then Opencode at 118,000, Claude Code (Anthropic's own coding agent) at 75,000, a project called Superpowers at 73,000, and Codex at 63,000. OpenClaw has more than double Opencode's count and nearly four times Claude Code's, though a star count alone measures attention, not proven quality.

The agent engineering and tools group covers plumbing developers use to build with these agents: Firecrawl (89,000 stars), Context7 (48,000), Scrapling (25,000), Agent Browser (19,000), and Symphony (8,900). The AI infrastructure group sits underneath that: Open WebUI (126,000), llama.cpp (97,000, software for running AI models on your own computer instead of a company's servers), Daytona (63,000), and Zeroclaw (24,000).

Rounding it out, a learning and tutorials group (Awesome LLM Apps at 100,000 stars, AI Agents for Beginners at 53,000, Prompt Engineering at 32,000, Hello Agents at 25,000, and Hermes Agent at 200,000) and one curated meta list, System Prompts of AI Tools, at 129,000 stars. The post itself is only names, links, and star counts, with no description of what any tool actually does, so treat it as a shortlist to go check yourself rather than a verdict on what's best. Claude Code sitting at 75,000 stars, in the middle of the pack rather than the top, is the one detail here worth a second look.

Outside your usual reading: a nice change of pace from AI headlines, a story about patient, hands on engineering. A 15 year old posted on Hacker News (a link sharing site popular with engineers) that he designed and 3D printed his own cycloidal gearbox (a compact gear design that uses a wobbling disc instead of standard teeth to get a big speed reduction in a small space), and wrote his own program to generate the gear shapes. The post reached 181 points and 51 comments.

He built three versions. The first was hand cranked, built only to test whether his gear generating program produced valid geometry, with a gear ratio of 1 to 9, meaning the output shaft turns once for every 9 turns of the input. The second tried to shrink the design down to the footprint of a common small stepper motor called a NEMA 17, but the tolerances needed were too tight for a home 3D printer, so it did not work. The third gave up some of that compactness for looser tolerances, and became the first version that actually ran.

His python script, based on a published tutorial on building cycloidal drives, takes a handful of inputs: the number and radius of the outer stationary pins, how far off center the input shaft sits, the radius of the roller pins, and a tolerance offset added specifically to leave clearance for 3D printing. Anyone can run it: clone the repository, open the free CAD program Fusion 360, load the script through its Scripts and Add-ins menu, and generate the parts.

The finished version is 9 centimeters across, runs on a NEMA 17 stepper motor, is printed in standard PLA plastic, and holds together with four M3 screws and two bearings. It takes the motor's own turning force of 0.21 newton meters and turns it into 1.3 newton meters, at a measured efficiency of 66 percent, meaning about a third of the motor's power is lost to friction inside the gearbox.

He has already flagged the next fixes: swapping the housing's pins for small ball bearings to cut friction and raise efficiency, and replacing the output pins with metal sleeved screws to make the whole thing stiffer and able to handle more torque. It's the kind of iterative, measure and rebuild process that's easy to forget when you only ever see the finished product, and a good one to remember, maybe worth showing my daughter someday.