I watched two developer conversations this week that described the same problem. AI makes it possible to build almost anything, and very capable programmers keep making to-do apps, agent harnesses and personal video editors. One developer let his product list grow for a while before cutting it back to the one or two areas where he had a real advantage.1
I do this too. After a weekend, I can turn an annoying piece of software into something that looks enough like a product for me to imagine a business around it. I then have to find out how many other people share the annoyance, whether they will change what they use and whether they will pay me.
McQueen Analytics does not need another general market-research SaaS product simply because agents make one possible. We have more than twenty years of research, a large question database and quantitative methods shaped by real studies. I want agents to help us do better research and make those methods available to more people and industries.
a working prototype says less about demand than it used to
Software used to be expensive enough that an idea had to survive several decisions before it reached a customer. Someone had to pay for a developer and keep funding the build. Companies had to choose which ideas were worth that cost.
Agents remove much of that cost. A working prototype once represented a larger investment than it does now. I can build one over a weekend and have no evidence that anybody wants the product.
I will keep building small tools because they solve annoyances and teach me something useful. I get into trouble when I treat the working version as market research. I can make a to-do app that fits the way I work and find out nobody else wants it.
Both conversations also discussed the attention and mental-health effects of constant building. I do not want to use a clinical term for ordinary enthusiasm, and the creator surveys they cited are not population studies. I know what happens in my own work: another build postpones the harder decision about which work McQueen Analytics should sell.
our head start is twenty years of research
Our advantage comes from more than twenty years of writing questions and using quantitative methods in real studies. We have seen where respondents misunderstand a scale, where a segment changes the decision and where a statistically interesting result is useless to the person who has to act.
We also have a question database shaped by real studies, quantitative methods tested against real decisions, and enough old work to recognize when a clean new answer repeats an old mistake. Agents can help us search that history and bring the right piece into a new study.
I want software to make a tested question easier to find, bring a strong method into an industry that could not previously support a custom research team, and reduce the manual work between raw evidence and a decision.
human-written code was never uniformly clean
Dan Jeffries recently made a blunt argument on X that the conversation about “AI slop” can romanticize the human work that came before it. The post he was responding to said people drastically overestimate the quality of pre-AI human code.2
I have enough old work inside my own company to understand the argument. Some of it was clever, some of it got an important job done, and some of it carries every compromise that appears when a person writes quickly on a deadline. Documentation was postponed, repeated work took slightly different paths, and the next urgent request arrived before anyone had time to clean up the system.
AI produces bad code when the job is vague or the first plausible answer gets accepted. In my work, agents often produce cleaner code because they have time to trace another dependency, rerun a check, document an exception and compare the output with the source. I have to put those standards into the job and check the result.
At McQueen Analytics, that can move checks and documentation out of the “when there is enough time” column. Our method has to tell the agent which checks belong in the work and when the easy check is not enough.
Asana's five-sentence prompt came after years of work
Asana's Enzyme migration gives one concrete example. The company says a five-sentence prompt launched work that completed the remaining migration in roughly a week and a half. It also says the migration had started in 2022 and that the repository already contained years of conventions, examples, test helpers, type checking, linting and continuous-integration checks.3
The prompt was short because most of the instructions were already in the repository. Examples showed the agent the local pattern, while tests, type checks, linting and continuous integration rejected bad changes. Asana also estimated about $12,000 in model and infrastructure cost against roughly $6 million of manual effort. The account discloses a partnership with OpenAI, and the cost comparison is Asana's counterfactual rather than an audited result.
OpenAI's own harness-engineering account describes putting repository knowledge where agents can read it, creating fast feedback loops, and enforcing architectural rules.4 OpenAI and Asana both have an interest in agent software, so I am reading these as company reports. In both accounts, people documented the standards and built tests before the agent run.
what I want agents to do in our research
An agent checking a study needs the questionnaire, the data and the decisions around them. It needs to know who answered, why we used that method and what would make us limit or change the conclusion.
I want agents checking those details on every study. They can compare a question with earlier waves, rerun a calculation and keep each claim tied to its source. They can also leave a record of how we reached the result, especially when deadlines are tight.
When we adapt a study for a new industry, the agent can show us where the questionnaire or method changed. We can use that record for the next client instead of building another one-off version.
We need to do market research on our own offer. Some parts of the question database and methods may belong inside a custom service. Others may work as a repeatable research package or a tool used with an expert. We are testing those choices with clients before building a market-research SaaS.
we are researching how to sell the work
I will judge the tools by whether they help us do better research.
Programmers need to build where their knowledge gives the agent a useful job. At McQueen Analytics, twenty years of research tells the agent where studies usually go wrong, which method fits the decision and what a client needs before acting on a result.
We will build software at McQueen Analytics. Some of it may become a product, and some of it will stay inside the research. I do not need a subscription page around every useful tool. I want to test the offer with clients before deciding which tools to sell separately.
Videos and company accounts
- Protecting Your Energy in the Age of AI discusses the attention and product-focus problem among developers using AI coding tools.
- The True Cost of AI Coding includes the account of narrowing a large product list toward areas where the developer had relevant expertise.
- Asana's Enzyme migration account describes the prompt, repository preparation, checks and company-estimated cost comparison.
- Harness engineering describes OpenAI's internal approach to repository knowledge, feedback loops and enforceable architecture.
Source notes
- The two linked videos are public developer conversations rather than representative research about all programmers. The specific product examples and the decision to narrow toward one or two areas come from the discussion of Aaron Francis's account in Syntax and the response on ThePrimeTime.
- Dan Jeffries's August 2026 X post and the Isaac post it quotes are public arguments, not empirical estimates of code quality. I use his claim that deadline-driven human work was never uniformly clean; I do not repeat the post's numerical claims about AI or driving.
- Asana's August 7, 2026 engineering account says the company began migrating from Enzyme in 2022 and completed the remaining work in roughly a week and a half after the agentic run began. Its cost comparison is identified here as Asana's estimate, and its disclosed partnership with OpenAI is relevant context.
- OpenAI's February 11, 2026 harness-engineering account is an internal company report about a Codex-built product. It supports the description of OpenAI's process and stated design choices, not an independent estimate of general software productivity.
Earlier read: completing more and carrying more responsibility