Hi, I'm Ted. I'm the crab, and I answer for Arnav — his work, his projects, the way he'd put it.
You've got three questions, so make them good ones.
Tap me next to any answer and I'll read it out loud.
Updated globals.css with 3 additions
Update(components/sections/contact.tsx)
Added 42 lines, removed 6 lines
Working on 4 to-dos
Extract Framer about page
Build sticky metadata rail
Wire typewriter caret
Mount footer nav
Sautéing components…
Reducing the sauce (47s · 12.4k tokens)
→Add a follow-up
Claude Opus 5 · 23% context used · 2 files
HOW I WORK WITH AI NOW
Can AI help engineers become builders?
Overview
Can one person own the whole line, from idea to shipped?
For a long time the split was clean. Strategy sat with one group and the build with another. With AI, that separation is collapsing.
This isn't a story about learning to code. It's about where my work now starts and stops:
Can one person carry an idea from the first rough thought to something real and running, without waiting for a handoff at every step?
That is how I've started to operate. I frame the problem, shape the solution, and direct AI to help me build it, end to end. This page is one example of that, built the same way I now build everything.
Why it matters
What one person can own now
Most conversations about AI stop at productivity, at doing the same work a little faster. I care about the other thing: what one person can own that used to need three roles and two handoffs.
In my current work that meant a procurement process scattered across two enterprise systems and five thousand engineered parts. I ran the discovery, modelled the data, built the control tower leadership actually opens, and prototyped an agent that reads supplier email and checks readiness before a person sees it. Then I stood in front of the directors who had to approve it.
In other words:
Only 38% of quotes were closing inside the agreed window. Nobody had been able to see that before.
One person across all of it, because AI covered the parts that used to need more. Not a faster developer, a shorter distance between the problem and the thing that fixes it.
My role
Builder across strategy and execution, not just one slice
I own the direction and the delivery. I decide what is worth building and why, then I direct AI to help me build it and see it through.
Framed the problem and the goal before touching a tool
Broke a large, ambiguous idea into a clear system of smaller parts
Made the architecture and design calls that shaped how it worked
Directed AI through the build, correcting course whenever it drifted from intent
Took it all the way to something live and usable, not a document about it
How it works
Where my time goes now
The division of labour is simple. I decide, it drafts, I check. What changed is not the hours, it is which hours.
Before
Most of a build was execution. The thinking was real, but it sat at the edges of the day, bracketed by hours of typing out something I had already worked out in my head.
DecidingDoing the tasks, by handChecking
Now
The middle stopped being mine. What sits on either side of it is where the work is now: deciding how something should behave before it exists, then reading what came back for whether it actually holds up.
Framing and specifyingDrafting, delegatedReviewing and re-specifying
The work moved from doing the tasks to directing the agents that do them. It handles the groundwork I used to quietly dread, and never once complains about it.
GrewBreaking problems into parts small enough to specify, and writing the constraints down once so the agent stops rediscovering them.
ShrankThe groundwork I used to quietly dread. I now test three approaches in the time one used to take, then throw two away.
Did not moveKnowing when to stop and change the plan, because it is the plan that is wrong and not the code.
Decision-making
My judgement is still the part that matters
The highest-value calls never moved. Which problem was worth solving, when the one people complained about was not the one costing them time. That the honest answer was a prototype and an adoption plan, not a production system nobody had approved yet.
Which approach survived a real constraint: an audit trail, a closed network, a habit someone had held for years. When to abandon something I had already built rather than patch it. How to present it to a director so the risk was the story and the technology was the footnote.
Judgement
AI could not tell me any of it. Those came down to knowing what the work was actually for.
Every one of these was a call about people, risk and timing rather than about code. They are the reason the prototype got approved, and the reason it stayed a prototype until it was ready to be more.
The honest part
Where it still breaks
It is not magic, and I would rather say so. Four ways it fails me, and none of them are edge cases. Which is fine. The parts it cannot do are the parts worth being paid for.
Confidence
Confident, and wrong
Anything it writes about a system it cannot see gets checked by hand.
Optimisation
An answer, not the answer
Different things, once compliance is in the room.
No stake
Builds what I asked for
Happily. Even when it is not the thing I needed.
Context
Context comes back to me
The more a problem carries, the more of the work comes back to me.
Outcome
What this says about how I work
AI didn't replace the way I work, it extended it past where it used to stop. I can hold the whole line myself now, from the strategy to the thing that ships.
This page is a small proof of it. I designed the entire site in Framer first, every section and every state, before a line of it existed as code. Then I rebuilt it in Next.js by directing AI: I set the direction, wrote the rules down once so the agent stayed on them, reviewed every output honestly, and re-specified whenever it drifted. The design was mine before the code was.
The agents mostly did what I asked, occasionally what they thought I meant, and once in a while something I still can't explain. You can meet and talk to him as he's walking underneath and on the home page as well. I call him Ted.
