if you use coding agents every day, read this. this is probably the closest thing i've seen to a 2026 operating manual for working with them. some of these takes go pretty far: > use the best model available > give agents access to the whole SDLC > stop micromanaging context > make them prove their work > give them bigger async tasks > review high-blast-radius code, not every line > let them build tools to test multiple ideas at once there are a ton of little things in here that immediately make you rethink how much you're still gatekeeping your agents.

there's a simple way to make AI research WAY better and most people still aren't doing it... agents like Claude Code can spin up multiple sub-agents at the same time. most people use them to divide up random tasks. the better use is splitting research by SOURCE before the main model writes anything. give 4 sub-agents completely different jobs: agent 1: only use primary sources, company docs, research papers, filings, changelogs agent 2: search Reddit, X, forums + reviews for what actual users are saying agent 3: find competitors, alternatives + examples of how other people solved the same problem agent 4: actively look for evidence that the current idea is wrong, outdated or missing something important then make every agent return: > strongest findings > exact sources > anything uncertain > anything that contradicts another source > what they think is worth using now the main agent gets all 4 reports before it starts writing. it can compare official claims against what users actually experience. it can see what competitors are already doing. it can catch claims that fall apart once someone looks for counter-evidence. and it has sources attached to everything. then give the main agent one final job: read all 4 reports, resolve the disagreements, throw out weak evidence + build the answer from what survives. this works insanely well for: > market research > product decisions > competitor analysis > technical research > content > buying decisions > anything where one bad source can ruin the whole answer the quality jump comes before the writing even starts.

your customers are already telling you what to build all day. sales calls, support tickets, Slack, reviews, surveys. all of that feedback gets scattered across different tools before product ever sees the full picture. here's the product feedback system i'd build: ⁠1. send every customer-facing source into one feedback inbox. sales calls, support tickets, shared Slack channels, surveys, reviews + community posts all land there with the source link, date, customer/account, segment + the customer's exact words. ⁠2. split conversations into individual findings. one sales call can contain a bug, two feature requests + a completely separate complaint. save each one separately and keep the transcript excerpt or timestamp attached so anyone can jump back to the original conversation. ⁠3. keep the customer's wording next to the summary. save what they asked for, why they wanted it + what they were trying to accomplish. that context becomes important when five customers ask for slightly different versions of the same thing. ⁠4. merge requests that describe the same customer problem even when the wording is different. keep every customer, quote + source attached to the shared theme so one issue can show the full amount of demand behind it. ⁠5. tag each theme by product area, request type + the job the customer is trying to get done. this makes it much easier to see that 20 different requests are all coming from the same broken part of the product. ⁠6. attach account data. customer count, customer tier, ARR, open opportunity + deals that are blocked by the request. now you can see the difference between something 40 free users mentioned and something affecting several of your largest accounts. ⁠7. pull in product usage for the same customers. if people keep complaining about onboarding, look at what those accounts actually do during onboarding. if they ask for a feature, check whether they're using the surrounding part of the product at all. ⁠8. rank the themes using demand, revenue exposure, strategic fit, effort + confidence in the evidence. keep the raw customer evidence underneath the score so someone can challenge the ranking without digging through five different tools. ⁠9. keep one human triage step before anything reaches the roadmap. AI can extract requests, group duplicates + surface patterns, but someone should still review the evidence and decide whether the theme deserves discovery, gets parked or maps to work that's already planned. ⁠10. when a theme moves forward, link the supporting feedback directly to the project or spec. engineering should be able to see who asked, what they were trying to do + the exact conversations that caused the work to exist. ⁠11. sync the status back to the feedback system. when something moves from UNDER REVIEW → PLANNED → SHIPPED, the sales/support teams that logged those requests should know automatically. ⁠12. close the loop with the customers who asked for it. you already know exactly which accounts requested the feature, so when it ships you have the list of people who should hear about it first. every Friday, your product should be able to answer: what kept coming up? which customers are affected? how much revenue is attached? what does their product usage show? which themes need discovery next? once it can, you're set.

there is no moat. in AI, anything good gets copied fast. so the best thing you can build is an unfair learning advantage around yourself. ⁠1. pick one problem you want to understand better than almost anyone else and stay close to it. build around it, talk to users, read complaints, watch competitors + keep seeing the same problem from different angles. ⁠2. ship constantly. every launch, post, feature, sales call + failed idea gives you another piece of information. the person with 100 real reps sees things the person with 10 reps can't. ⁠3. write down the decisions that matter. what did you believe, what did you choose, what happened afterward? after enough cycles, you start noticing which signals were useful and which ones fooled you. ⁠4. keep the lessons that only came from experience. weird customer objections, tiny product details, pricing mistakes, distribution tricks, workflows that worked better than expected. this is the stuff that never shows up in generic advice. ⁠5. build relationships with people who are close to the problem. customers, builders, operators, researchers. good relationships give you information earlier, better context + people to test ideas with. ⁠6. publish what you're learning. explaining something forces you to sharpen it, attracts other people working on the same problems + gives you a public record of how your thinking is changing. ⁠7. use AI to run this loop faster. research deeper, compare more examples, summarize calls, challenge assumptions, prototype ideas + review what happened. the model is available to everyone. what you feed into it comes from your own reps. keep doing this for long enough and you start to understand stuff like: which customers to ignore, which feature requests are fake demand, which channels work and why, when to ship, when to wait, and which problems are worth chasing in the first place.

if your competitor is hiring aggressively, you can usually figure out what they're building months before they announce it. before a company launches a new product, moves upmarket, changes pricing or enters a new category, they leave the same public clues everywhere. and almost nobody tracks them together: ⁠1. start with the careers page. new roles tell you where money is being committed before the product ever ships. several enterprise AEs, solutions engineers + security hires probably means enterprise is becoming a priority. a cluster of payments, billing + tax roles can point toward international expansion or a new monetization push. ⁠2. save the job descriptions, not just the titles. companies casually mention new products, customer segments, internal initiatives, technologies + problems the person will be working on. sometimes the roadmap is basically sitting inside the responsibilities section. ⁠3. compare hiring month to month. one role can be noise. a whole new team appearing around the same problem is much harder to ignore. track what was added, what disappeared + which departments suddenly started growing. ⁠4. check the changelog next. a steady stream of SSO, permissions, audit logs, admin controls + compliance work paired with enterprise hiring gives you a much clearer picture than either signal by itself. ⁠5. watch the docs. new API pages, integrations, SDKs, navigation changes + documentation for features that barely exist yet can show where the product is heading before the launch post does. ⁠6. save pricing pages over time. new tiers, usage limits, annual plans, enterprise CTAs + packaging changes tell you how the company plans to make money from whatever it's building. ⁠7. if they're open source, watch GitHub. new repositories, dependencies, contributors, issues + repeated work around one area can expose another piece of the roadmap. you don't need to understand every commit. look for activity clustering around the same thing. ⁠8. read their customers at the same time. G2, Reddit, GitHub issues, support forums + X replies show the complaints and requests the company keeps hearing. when hiring and product work start lining up with one repeated complaint, you can usually see which weakness they're trying to remove. ⁠9. follow the founders and product leads. people start talking about problems before their companies start announcing solutions. one post means very little, but the same subject coming up repeatedly alongside hiring + product changes is worth paying attention to. ⁠10. watch partnerships too. a new cloud partner, CRM integration, marketplace listing, payment provider or distribution deal can tell you where the company wants to go next. ⁠11. keep one simple table: SIGNAL, WHAT IT COULD MEAN, EVIDENCE, CONFIDENCE, WHAT WE SHOULD DO. every new clue either strengthens the prediction or kills it. ⁠12. then act before the announcement. if they're clearly moving enterprise, strengthen your enterprise offer. if they're entering your category, start publishing the comparison content while the search results are still empty. if they're fixing a weakness you've been selling against, find the next reason customers should choose you. your competitor can spend months hiring, building + preparing for a major move. you can watch a surprising amount of it happen in public before the launch ever arrives.

before you ship a landing page, feature, ad, email or launch, run it through this once. give your AI agent whichever you pick + who it's for, then have it review the same thing from 4 different perspectives: CUSTOMER: read this like the exact person we're trying to sell to. tell me where you get confused, what feels irrelevant, which claims you'd question + what would make you leave. COMPETITOR: pretend you work for our strongest competitor. tell me where we're weak, what you'd attack, where our positioning is easy to copy + what sounds exactly like everyone else. SKEPTIC: assume every claim needs proof. flag anything vague, exaggerated, unsupported or missing the evidence someone would need to believe it. CONVERSION: read it from top to bottom and find every point where someone has to stop, think, search for context or figure out what they're supposed to do next. then give it one final instruction: combine all 4 reviews into the 5 changes that would improve this the most. don't rewrite the whole thing. tell me exactly what you'd change, where you'd change it + why. you can run the same review on landing pages, pricing pages, launch emails, ads, sales decks, onboarding, product announcements + pretty much anything customers are about to see.

if you use AI to grow on 𝕏, this is a must read. “11 Grok Bots helped me generate ~2M impressions in my first two weeks.” and he gave away the entire team, setup, and prompts. read it, bookmark it, and tag Grok Bot to build yours.

I know a 10m+ views post when I see one

before you jump into Claude Code, before you build content workflows or use Grok Bot... there's ONE thing you should do first. give the AI references. seriously, this fixes an absurd amount of bad AI output. AI gets dramatically better when it can see what "good" looks like before it starts. here's how to use it: before asking AI to write a landing page, give it 2-3 landing pages you love. before asking it to write an X post, give it 5 posts with the tone, structure, hook, + pacing you want. before asking it to design something, give it screenshots of interfaces that look good to you. before asking Claude Code to build a new page or component, point it at the closest thing in your own codebase that's already done well. before asking it to write an email, give it a few emails that you drafted yourself and would like to send more of. and do the same thing with bad examples as well. show it: > wording you hate > layouts you don't want > hooks that feel AI > code patterns you don't want repeated > designs that are too busy etc... you don't need some giant prompt explaining your taste every time. just show the model what good looks like before asking it to create something.

if you write content for a living, this is a must read “once you know what the feed is doing to your brain, it changes how you think about every post you write.” read it, bookmark, and go write your next post