# AI made building easy. Knowing what to build just got expensive. **Author:** Ivan Misic **Published:** 2026-02-19 **URL:** https://ivanmisic.net/blog/ways-of-working/ai-made-building-easy-knowing-what-to-build **In plain English** AI made more ideas cheap enough for me to test, but this project does not prove that software costs are approaching zero or that one small team replaces every larger one. The harder skill is defining the user, outcome, constraints, evidence, and stopping condition clearly enough to test whether the work matters. Published productivity results vary by task and worker context. Start with one repeated piece of work, specify the expected result, let AI produce a version, and check whether it met the conditions. AI makes execution cheaper, but it also exposes weak decisions faster. I [built this website](/blog/ai-tools/how-i-built-this-site-with-claude-code) with AI as my primary engineering partner. It includes a design system, CMS, content tools, and the normal plumbing behind a working site. Work that I would once have scoped as a small agency project took me weeks. That proves the change for this project. It does not prove that every three-person team can now replace fifteen people, or that software costs are approaching zero. The task, people, quality bar, and operating model still matter. What changed for me is simpler: more ideas are now cheap enough to test. That moves the bottleneck from “can we build it?” to “should we build it, and can we explain what good looks like?” ## Cheap prototypes create more demand I have watched organizations run important processes through spreadsheets because a proper tool was too expensive to justify. Operations teams reconcile data by hand. Product teams copy the same information between systems. A small internal need waits behind a large platform roadmap. When a prototype becomes cheap enough to test in days, more of those processes become candidates for a small purpose-built tool. That does not mean every workaround deserves software. Cheap building can also produce more tools nobody needs. The old budget acted as a brake, even if it was a frustrating one. Stakeholders had to align because getting the decision wrong consumed real money and months of work. AI weakens that brake. You can now be wrong faster. Anthropic's [2026 agentic coding research](https://resources.anthropic.com/hubfs/2026%20Agentic%20Coding%20Trends%20Report.pdf) found that some AI-assisted engineering work covered tasks that otherwise would not have been done. I think that direction matters more than one headline productivity multiplier. Lower execution cost creates demand for work that previously stayed below the priority line. ## Building got cheaper. Thinking did not. “Improve onboarding” is not a specification. Neither is “build what our competitor has.” Both leave the important decisions hidden inside a short sentence. Someone still needs to define: - which user has the problem - what should change for that user - which constraints the solution must respect - how the team will know whether it worked - what would make the idea not worth continuing AI can help explore those questions, but it cannot own the decision. If the brief is vague, the output can look complete while solving the wrong problem. > The bottleneck is moving from “can we build it?” to “can we define and test the right thing?” The cost of one bad prototype may be small. The cost grows when teams mistake quick output for evidence, add it to production, and create another thing to support. ## The split I see in teams One group uses AI to execute the same work a bit faster: better first drafts, quicker analysis, more autocomplete. Useful, but the workflow stays the same. Another group starts from the system and outcome. They ask which work should disappear, which decision needs better evidence, and which repeated process could become a tool. AI is part of the implementation, not the goal. There is usually a messy phase between the two. People get access to a capable tool and create everything they can think of. The first prototype feels productive because something exists. But output is not value. Generating ideas is easy. Choosing which one deserves time is the real work. This split does not follow seniority. Experience helps with judgment, but only if the person is willing to change the process around that judgment. A senior title does not make a vague instruction clearer. ## Specification is becoming a general work skill Engineers have spent years turning fuzzy intent into testable work through acceptance criteria, tests, and definitions of done. Other knowledge work can use the same discipline without pretending every job is software development. A financial model has inputs and assumptions. A market-entry plan has conditions that would make it fail. A contract review has standards and exceptions. A campaign has an audience, a hypothesis, and a result that can be measured. The skill is making the intent clear enough that someone else can act on it and check the result. If the output can only be judged by “looks good,” the work is hard to improve and easy to overrate. Vibes do not scale. ## My meeting-budget idea Large organizations spend a lot of time coordinating themselves. Status decks, alignment calls, approval rounds, and people added to meetings because someone may need them for five minutes. I have a personal fantasy that meetings should have a visible budget. Thirty minutes with a senior architect would debit the department. Adding a vice president would increase the price. The numbers would be illustrative, but the cost would no longer be invisible. Would every meeting survive if the organizer had to spend a real budget on it? I doubt it. AI can reduce some reporting and note-taking, but organization design still sets the amount of coordination needed. If a company becomes leaner, some handoff work disappears. Other work remains because smaller teams still need decisions, context, and accountability. If a meeting or handoff takes five people's time, it should earn that time. ## What actually helps ### Define the outcome Replace “make it better” with a result someone can observe. Name the user, current problem, expected change, and constraint. ### Build a way to prove yourself wrong Engineers write tests. A strategy needs the same kind of honesty: sources, assumptions, checkpoints, and a condition that would make you stop. Work that can be checked can be trusted. Work that cannot be checked is opinion with a nice font. ### Build systems, not recurring deliverables A quarterly report consumes time every quarter. A system that collects the inputs and exposes the decision may need your judgment only when something changes. The report can still exist, but it becomes an output of the system instead of the work itself. ### Check where your value sits Ask what remains if the routine execution becomes much cheaper. Customer judgment, prioritisation, risk, domain knowledge, and accountability do not disappear because a draft arrives faster. If most of the role is moving information between people, that is worth examining. Not panicking about. Examining. ## Do not assume one productivity multiplier Published results are mixed because the work is mixed. The [Stanford AI Index 2026](https://hai.stanford.edu/assets/files/ai_index_report_2026_chapter_4_economy.pdf) summarizes productivity gains, but it also covers [one 2025 study](https://arxiv.org/abs/2507.09089) in which experienced open-source developers were 19% slower with early-2025 AI tools. The report notes that the result was not later replicated. That is closer to what I see than the idea that every team becomes five times faster. AI helps when the task, context, and verification fit the tool. When they do not, faster output can create more review and rework. Start with one piece of work you do repeatedly. Specify the outcome more exactly than usual. Let AI produce a version, then test whether it met the conditions you set. Run that test once. You will learn more from it than from another prediction about the future of work. ## Sources - [2026 Agentic Coding Trends Report](https://resources.anthropic.com/hubfs/2026%20Agentic%20Coding%20Trends%20Report.pdf), Anthropic. Reports that about 27% of AI-assisted work consists of tasks that would not otherwise have been done. - [AI Index Report 2026: Economy](https://hai.stanford.edu/assets/files/ai_index_report_2026_chapter_4_economy.pdf), Stanford Institute for Human-Centered Artificial Intelligence. Summarizes measured productivity gains and the limits around one early-2025 developer slowdown result. - [Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity](https://arxiv.org/abs/2507.09089), METR. Supplies the specific 19% slowdown result and the narrow setting in which it was measured.