Agentic AI: Good Upfront Design Pays You Back Later

A developer building DumbQuestion.ai added a new 'Startup Roast' feature that roasts startup pitches with market-aware context. The feature was implemented quickly because the codebase used configurable constants and isolated reusable components like web search, demonstrating that upfront design pays off in iteration speed.

I spend a lot of time preaching architecture and constraints, so it is always nice when a side project gives me receipts. Adding this new feature to DumbQuestion.ai was a good reminder that a well-structured first version lets you spend your next iteration on value, not repair. Below, you will find a few relatively simple challenges and how thoughtful, upfront design made the changes effortless. To vibe or not to vibe ... Many developers jump right in and just rip out an app, ship fast, let the coding agent sort it out, come back and deal with it later. To be fair, that absolutely can get you to first release faster. But even on a solo project, a little proper SDLC discipline pays back later when you want to extend the product without turning every feature into a rescue mission, which is a theme that already runs through how I have been building DumbQuestion.ai. Extend this to the enterprise and you turn a little upfront effort into potential huge savings on token spend Roasting starup pitches for sport ... The core idea for Startup Roast was simple enough: take a startup pitch, roast it, and add a reality-check section so the output is not just mockery for mockery’s sake. To illustrate and avoid just vaguely describing the feature I picked a random but highly upvoted pitch from Product Hunt: Vida https://www.producthunt.com/products/vida-5 . Vida, which pitches itself as an “AI clone” that learns how you work, remembers what matters, and becomes a “second you,” with early use cases like Reply Rescue, Prompt Rescue, Resume Rescue, Workspace Cleanup, and Daily Wrap. This is a pretty common target use case of agentic AI making it a solid candidate. If you want to skip ahead, here's an example roast https://dumbquestion.ai/q/roast-my-startup-7XHTxqyD?utm source=roastdev for Vida. Combining a preliminary web "market search" into the content yielded a result that was not just sarcastic, but informed. The roast hit the obvious AI-clone positioning, questioned whether the product was really a clone versus a macro suite, and then turned the market context into a sharper Reality Check about integration bugs, weak retention, and the risk of becoming yet another chat-wrapper-style productivity startup. DumbQuestion.ai originally dealt with a short question < 100 characters . The startup roast feature deals with a whole pitch, which is a very different shape of input, with more context, more structure, and more ways for the prompt to get noisy. The Vida example alone is long enough to make that obvious. This is where boring code quality decisions start paying rent, something likely caught in a code review: use configuration or constants insead of hardcoded literals. If prompt limits, prompt assembly, and related values are already treated like configurable extension points instead of scattered magic numbers, adapting to longer input becomes an iteration problem instead of a rewrite problem. This was an instant code and unit test change . This led to an even better refactor to make the limit parametric instead of constant. A generic roast is funny once. A roast that feels aware of the market is a better product artifact. In the Vida example, adding in a quick prelminary web search using search phrases like “top competitors to AI work clone or AI agent that learns your habits startup” and “reasons AI personal assistant or productivity agent startups fail,” were added to the context to shape the final output. It moved the result to something more specific than just "ha ha, another AI startup.” To support that, I added a preliminary LLM pass to extract search phrases as a JSON array, then routed those through my existing multi-provider web search capability and used the results to prefill the final LLM prompt. The point here is not that this was especially hard. The point is that it was not hard because search was already isolated as a reusable feature instead of buried inside one specific interaction path. The pay back was immediate . If search is a first-class capability, a new feature can borrow it immediately. The architectural work already happened earlier. The new work is mostly deciding how to apply it. Once the responses got richer, plain text stopped being enough. Roast plus Reality Check wants structure. The Vida output is a good example because it has a clear voice shift from mockery into analysis, and that reads much better when the response can preserve formatting cleanly. Different models chose different formats and whether or not to pepper in emojis. Again, this is where earlier organization matters more than raw cleverness. If your HTMX partials and rendering boundaries are reasonably clean, adding markdown support is much lower impact than it would be in a tangled UI layer. Pull in a Go lib dependency, apply it in a single, small partial, update a focused unit test and very few tokens were needed to wrap up this feature. Quiet structural decisions like that are what let a new feature stay contained. A key lesson here for sure : nearly all first runs with a coding agent generate "balls of mud" in the UI instead of well organized components. Nip this one in your first code review if not sooner. The moment you let people paste startup pitches into an LLM tool, you are no longer just handling simple, earnest user input. You are also handling jokes, garbage, hostile instructions, and people trying to be clever because of course they are. That was already true in DumbQuestion.ai, but longer, richer pitch inputs make it even more relevant. I already had prompt injection handling in place, but Startup Roast needed the tuning adjusted. Because the detection and response behavior were already parameterized instead of hard-coded into a pile of special cases, tuning it became a smaller, more contained change. Better thresholds, better handling, smaller git diff, fewer tokens. Startup pitches are a different input class than dumb questions, so I wanted to re-test model speed, quality, and instruction adherence under longer prompts and a different tone. Luckily, I had already built an eval harness for comparing models, so adding startup-pitch cases was an easy extension instead of a new side quest. This was already incorporated into my unit, e2e and integration tests so even for a solo project , this paid off. The persona side worked out the same way. Because the personas were already packaged to be open for extension , adding new instructions and persona-specific CTAs was low impact. That let me spend time tuning tone and usefulness instead of untangling brittle prompt logic. For the curious, here's the same pitch roasted across the four personas: Weary https://dumbquestion.ai/q/roast-my-startup-7XHTxqyD?utm source=roastdev , Overqualified https://dumbquestion.ai/q/roast-my-startup-1HLevhkf?utm source=roastdev , Compliant https://dumbquestion.ai/q/roast-my-startup-MhGjmxvh?utm source=roastdev , REDACTED https://dumbquestion.ai/q/roast-my-startup-wQvl2qK4?utm source=roastdev . I always like the insane positivity The Compliant brings to the table. Focus on value add Good upfront design changes what kind of work you get to do next. It lets you spend your energy on product judgment instead of repair work. It turns feature additions into focused passes on value: better prompts, better search context, better output formatting, better guardrails. Design efficiency = Token efficiency It also makes coding agents more useful and more efficient. AI coding agents are great at implementation, but they are much more effective when the system already has clean extension points, isolated responsibilities, and tunable behavior. A prompt-length constant is an extension point. Multi-provider search reuse is an extension point. Modular rendering is an extension point. Parametric prompt-injection tuning is an extension point. Those are not giant innovations. They are just design decisions that compound later. Team of One / Team of Many That is why I still believe even solo projects deserve at least a little SDLC respect. Not enterprise ceremony. Not fifty approval gates. Just enough thought, structure, and code quality that future-you is allowed to work on the interesting part. If it pays off a little for a team of one, it can pay off a lot for a team of many. For this feature, the interesting part was not fighting the code. It was thinking about how to make the roast more specific, more grounded, and more shareable. The Vida example was a nice reminder that good architecture really does buy that freedom later.