The most valuable AI in my engineering stack never writes code. How I use AI for research, writing, design, and ops as a CTO shipping Flutter apps.
The coding assistant is the most overrated model in my stack, and I say that as someone who ships Flutter for a living. Every AI demo you've seen films the same scene — a prompt goes in, a pull request comes out — and that's the exact part of my week the technology barely touched.
Here's the uncomfortable truth after a year of running a Dubai startup on this stuff. The AI that actually changed how I spend my days never writes a single line of Dart. It reads the vendor contract I don't have time to read, drafts the investor email I've been avoiding for three days, sketches five onboarding layouts I'd never have thought of, and turns a vague "why is our churn up" into a real analysis before I finish my first coffee. As a CTO and a founder, my bottleneck was never typing code fast enough. It was everything wrapped around the code.
If you're an engineer trying to figure out where AI actually earns its keep in real work — not in a staged demo — this is the single reframe that mattered most for me: point the model at your weaknesses, not your strengths. Everything below is how that plays out across a real week of building software and running a small company.
I'm an engineer. When a new tool shows up, my first instinct is to point it at the thing I already know how to measure: does it make my code better and faster? So for the first few months, that's all I did. I judged these models like a linter with opinions. Some days it saved me twenty minutes, some days it confidently invented a Firebase API that doesn't exist and cost me thirty. Net neutral, honestly.
The bias is obvious in hindsight. Code is the part of my job I'm already good at and already fast at. Handing it to an AI is like hiring a world-class assistant and asking them to do the one task you enjoy and excel at, while you keep doing the ten tasks you're mediocre and slow at. You feel productive because you're watching a machine do something, but you've optimized the wrong end of the funnel.
The real leverage is the inverse. Point the model at the work where you're slow, reluctant, or out of your depth. For me that's research, writing, design exploration, and the endless glue-ops of running a small company. Once I flipped the frame, my usage roughly tripled and almost none of it was code.
There's a name for the trap I fell into: automating the fun part instead of the expensive part. Engineers do it constantly. We reach for AI where we already have competence because that's the domain we can evaluate. The uncomfortable move is aiming it at the work we quietly avoid — the reading, the writing, the decisions with no clean unit test.
The single biggest unlock has been turning research from passive reading into an interrogation.
Old workflow: I need to understand, say, whether to move our push notifications off a third-party service. I open fifteen tabs. I read pricing pages that hide the real cost, docs written by people who assume you already know the answer, three outdated Stack Overflow threads, and a Reddit argument. Half a day gone, and I still have to hold it all in my head.
New workflow: I dump the constraints and ask directed questions. "We send about 400k notifications a month, mostly Android, budget is basically zero, we're already on Firebase. Compare FCM against the paid options. Where does FCM actually fall short at our scale? What breaks first?" Then I follow up. "You said delivery reporting is weak — weak how, specifically? Show me what the data looks like."
The trick is that I'm not asking it to decide. I'm using it as a research analyst who has already read the fifteen tabs and can be cross-examined. I still verify the load-bearing facts — anything about money or limits I confirm at the source — but the model gets me from zero to a sharp, specific set of questions in minutes instead of hours.
That push-notification question was real, by the way. The interrogation talked me out of the migration in about twenty minutes. FCM's delivery reporting is genuinely thin, but at our volume and our budget — which is to say, we keep our Firebase bill pinned at zero on purpose — nothing the paid alternatives offered was worth a cent, let alone the switching cost. A year earlier I'd have spent a full afternoon reaching the same conclusion, and I'd have been less sure of it.
A few rules I've settled on for using an LLM as a technical research assistant:
This is the workflow I'd hand to any engineer evaluating a vendor, a library, or an architecture decision. You're not outsourcing the judgment. You're outsourcing the reading — the fifteen open tabs — and buying back the hours you'd have spent skimming.
I don't hate writing. I hate starting. The blank page is where an hour disappears while I rearrange the same opening sentence.
So I stopped starting from blank. For anything that isn't this blog — investor updates, a tricky Slack message to a client, a job description, release notes, an incident post-mortem — I give the model the bullet points in my head, my rough tone, and let it produce a competent first draft. Then I do the part I'm actually good at: cutting, sharpening, and making it sound like a human wrote it.
This matters more than it sounds. The cognitive cost of editing is a fraction of the cost of generating. Staring at a bad draft and thinking "no, the real point is X" is easy. Conjuring X from nothing at 11pm is hard. The AI eats the activation energy, and I keep the judgment.
Two honest caveats about using AI as a writing tool:
For the writing that is my voice — this blog, anything with my name on it as an opinion — I use it more as an editor than a ghostwriter. "Here's my draft, where does the argument sag, what did I over-explain, what's the weakest paragraph, where am I repeating myself?" That's a far better use than "write me a post," which never produces anything I'd sign. The distinction is worth internalizing: AI as ghostwriter flattens you; AI as editor sharpens you.
I'm not a designer. I have taste, but I don't have range. Left to myself I'll build the same tidy, slightly boring card layout I've built a hundred times because it's in my hands and I can ship it by lunch.
This is where the multimodal models earn their place. I describe a screen — an onboarding flow, an empty state, a pricing page, a settings panel — and ask for several distinctly different directions, not one polished answer. Then I react. "Direction 3 has the right energy but it's too busy, strip it back. What if the primary action moved here?"
I'm not shipping AI-generated designs. I'm using them to break my own defaults. On a recent onboarding revamp, the model suggested collapsing three setup screens into one progressive form with the fields revealing as you go. I'd have never proposed it — my instinct was to keep the screens separate and "clean." It was right. Fewer drop-offs, and it took a five-minute conversation to get the idea instead of a week of me not having it.
Same story with microcopy and UX writing. Button labels, empty-state text, error messages, onboarding tooltips. I ask for ten options for a given moment, throw away eight, and keep the two that are sharper than what I'd have written. Cheap, fast, and it raises the floor on the small text that users actually read. Nobody notices great microcopy, but everybody feels a confusing error message — and that's exactly the low-stakes, high-volume work where an LLM shines.
The pattern across research, writing, and design is the same: the model is a divergence engine. It's excellent at widening the set of possibilities and terrible at picking the one that fits. Which is fine, because picking is my job.
This is the quiet one, and maybe my favorite. A startup is a thousand small data questions and one-off chores, and each one is too small to be worth a proper tool but too annoying to do by hand.
I used to either grind through these manually or write a careful little script and feel bad about the time. Now I describe the shape of the data and the answer I want, and I get a working script or a direct analysis in a couple of minutes. The bar is different for throwaway work: it doesn't need to be maintainable, tested, documented, or pretty. It needs to run once and be correct once. That's exactly the sweet spot where I don't care that the model isn't a great software engineer.
# The kind of thing I'd never have bothered to write by hand,# now a 30-second ask: audit which screens read the most from Firestoregrep -rho 'collection([^)]*)' lib/ \ | sort | uniq -c | sort -rn | head -20
The one place I stay careful: anything that writes. A read-only analysis that's wrong wastes a minute. A one-off Firestore migration that's wrong corrupts production data. So the rule I hold is simple — let the model draft the destructive scripts, but I read every line before it runs, and I run it against a copy or a dry-run flag first. Generation is cheap; a bad batch.commit() is not.
Half of what I "delegate" here I'd previously have just not done — left the question unanswered because it wasn't worth the friction. Lowering the cost of a small analysis to near-zero means I ask a lot more small questions, and small questions compound into better decisions. That compounding is the real return, not the minutes saved on any single script.
Here's the line I won't cross. The model is fast at producing options and terrible at knowing which one matters.
It can draft the investor update, but it doesn't know which metric to lead with because it doesn't know which conversation I had last week. It can propose five designs, but it can't feel that direction 3 is "too clever for our users." It can compare four databases, but it can't weigh that our team already knows Firestore cold and switching costs a month we don't have.
Taste is the accumulated context of your specific situation, and that's the part that's still entirely mine:
I've started thinking of it as: the AI expands the space of options, I collapse it. If I let it do the collapsing, I get generic, safe, forgettable output — the statistical average of everything it's ever seen. The whole value of a founder, or an engineer with a point of view, is being non-average on purpose.
Not theory. A rough map of a normal week, and how much of each task the AI actually owns versus where I stay in the loop:
| Task | What I use it for | Who decides |
| --- | --- | --- |
| Vendor / architecture research | Cross-examine tradeoffs, surface what breaks first | Me |
| Investor & team updates | First draft from my bullets | Me (heavy edit) |
| This blog | Editor and sparring partner, not ghostwriter | Me |
| UI direction | Break my defaults, generate options | Me |
| Microcopy & UX writing | 10 options, keep 2 | Me |
| One-off data questions | Script + analysis, run once | Me (sanity check) |
| Actual production code | Occasional autocomplete, small scaffolds | Me, mostly by hand |
Notice how far down the list production code sits. On a typical week it's maybe 10% of my AI usage, and it's the part I trust least without reading every line. The research, writing, design, and ops rows — the ones where no code is written — are where the hours actually get saved.
The point of all this isn't "do more things." It's "spend your rare, expensive human attention on the parts only you can do."
As a CTO of a small team, my scarce resource was never keystrokes. It was judgment, context, and the handful of decisions a week that actually move the company. Every hour I spent reformatting a CSV, fighting a blank page, or reading a pricing table was an hour stolen from that. Offloading the generation and the grind bought that time back and pointed it at work that can't be delegated.
The mental shift, concretely:
The engineer in me still finds it faintly insulting that the coding is the least valuable thing the AI does for me. But that's the job now.
The best model in my stack never writes a line of code — and it's not close.