Idea #1
Intent engineering — the skill of precisely communicating what you want to an agent — becomes more important as LLMs get more capable, not less. The mechanism is straightforward: as models handle the code-writing middle entirely, the only remaining bottleneck is the quality of the specification they receive. A more powerful model executing a vague brief produces better-written code that still misses the point; a more powerful model executing a precise, well-referenced specification produces exactly what you need. This means the return on investing in intent-specification skill grows proportionally with model capability. The practical implication is that the developer's role shifts entirely upstream (planning, specifying, providing references) and downstream (validation), with the code-writing layer fully delegated. The concrete example: building a 3D game with Claude Opus 5.5 inside a sophisticated autonomous software factory failed five or six times because the intent was underspecified — vague language about 3D graphics produced technically correct but wrong results. The breakthrough came from giving the agent a screenshot reference from Legend of Zelda: Breath of the Wild and instructing it to continuously compare its output against that visual target. Same model, same harness, same task — the only change was a precise reference replacing a verbal description, and the result finally matched the actual goal.
Idea #2
The 'reverse engineer anything' class of agent tasks is a special case that does not generalize to most software work, and overgeneralizing from it leads to a wrong conclusion about what agents can already do autonomously. The reason reverse-engineering agents work so exceptionally well is that the application being reverse-engineered literally is the intent: the target output already exists in concrete, inspectable form, so the agent can validate its own work against the ground truth at every step with 100% reliability. There is no ambiguity to resolve, no mind to read. This is structurally different from building something new, where intent starts as an abstraction in someone's head that must be progressively externalized before an agent can reliably pursue it. The GitHub repo 'reverse engineer anything' (which went viral and prompted claims that coding is 'solved') demonstrates this: its quick-start is a trivially simple prompt, yet it produces impressive results — not because agents have become general-purpose autonomous builders, but because reverse engineering eliminates the intent-specification problem entirely. Most real software projects don't start with a finished reference; they start with an idea. For those, the developer must construct the reference — through documentation, PRDs, examples, side-by-side validation setups — before the agent can operate reliably.
Idea #3
Being a 'meat proxy' — receiving a request, forwarding it verbatim to a coding agent, and passing the output back unmodified — produces output you are still fully responsible for but have added no value to, and it reliably fails for any non-trivial task. The failure mode is not that AI writes bad code; it writes technically competent code. The failure is that the agent doesn't understand the nuances of what you actually needed, because no one translated the original intent into a precise specification. The person who assigned the task may as well have gone to the agent directly. The extreme version of this pattern is replying in Slack with 'Claude said:' followed by a raw AI response — this offloads the comprehension work onto the requester while contributing nothing. The practical implication is that value in an AI-augmented workflow is entirely concentrated in the quality of the specification you produce and the quality of the validation you do at the end. Skipping both means you have automated your own irrelevance. The framing that fixes this: if the agent makes a mistake, treat it as a communication failure on your side, not a model failure — that attribution forces the developer to invest in the upstream work that actually prevents the mistake.
Idea #4
A practical test for deciding which skills are still worth investing time in: ask whether the skill matters more or less if the next model is twice as good. Skills that matter less as models improve include prompt engineering micro-tricks, manually crafting elaborate rule files, and teaching the LLM general software engineering principles — these were load-bearing a year or two ago and have since become mostly irrelevant as models internalized them. Skills that matter more (or at minimum, the same) are those at the two bottlenecks that remain: planning and specification before the agent writes code, and validation after. Concretely: harness engineering (sub-agents, hooks, orchestration, autonomous validation loops), intent engineering (providing references, building PRDs, grilling the agent with clarifying questions before it starts), and the judgment to know when a reference exists versus when you need to construct one yourself. The test reframes the question productively — it's not 'is coding worth learning' but 'which specific layer of the software-building stack will remain irreducibly human work at any model capability level.' The answer points consistently to the boundary between the human's mental model and the agent's executable understanding of it.
Source: Is Learning to Build Software Still Worth It with AI? (My Honest Take) (Cole Medin)
Text summarized and optimized using Anthropic’s models and reviewed by a human.