The future of AI-native work / 2026 / Blog / Anand Chowdhary<br>🤖💼🔮

I had a chance to reflect at the past half year we’ve been building the team and culture at Sycamore after a friend asked me what AI-native development actually feels like these days.

I think my answer would have sounded absurd to me even a year ago: I spend a lot less time writing code, I spend a lot less time reviewing code line-by-line, and I feel more responsible for the software.

The lazy version of the AI coding story is that engineers stopped caring and let models spray slop into production. I don’t think this is what’s happening in the best teams.

Token time

At FirstQuadrant, I lived in the world of tab autocomplete. I was one of those people who tried to squeeze every possible ounce out of Cursor. I even got a little Tab key from them for being in the top 5% of tab users, which is a pretty funny thing to be proud of and also, apparently, something I am still proud of. But this was the world of 2023.

That world was still recognizably software engineering. I had the codebase in my head. We had about 200,000 lines of code after two and a half years of building and rebuilding. I knew where everything was. If something broke, I could usually imagine the path from the frontend event to the database write without opening the repo.

Now, at Sycamore, the scale feels different. A small team can produce in a couple of weeks what used to take literal years. You walk into the office and see someone with a monitor split between Codex, Claude Code, review agents, logs, terminals, and docs. While I was on this call sharing these details with my friend, I had three agents running in the background. Two were stuck in review loops, which meant I knew they would not need me for a while.

This changes the unit of work.

In the old world, engineering time and human time were basically the same thing. Sri said he wanted the team to spend 20% of our time on observability, that meant roughly one day a week. Monday to Friday, somewhere in there, I would give observability a day of my attention.

That sentence means something else now. Now, he said, we want to spend 20% of our token time.

If I have five agents running, 20% of my token time can go to observability while 99% of my human time stays on new product work. One agent can spend the week crawling through the codebase, adding instrumentation, writing tests, opening PRs, and going through reviews. My job is not to personally type every log line. My job is to make sure the agent has the right spec, the right context, the right constraints, and the right definition of done.

That is the first new concept I keep coming back to: token time.

The spec is where the coding moved

When I was writing most of the code myself, I discovered edge cases while building. I would start with a rough idea, write the first version, hit a weird state, adjust the abstraction, notice the UI needed another empty state, change the API, then keep going. The thinking and the typing were tangled together.

With agents, that stops working.

If you give an agent a vague spec, it will happily produce a precise implementation of your vague thinking. That is worse than doing nothing because it looks like progress. The PR exists, the tests may even pass, but the shape will be wrong.

So the work moves earlier. You spend real time with the model before implementation. You ask it to attack the spec, you ask it to find missing states, to list every edge case, compare approaches, self-grill. You make the hidden assumptions visible.

A good spec becomes a contract. If the model implements it perfectly, the result should be right.

This is the part that still feels unintuitive to a lot of very good engineers. They are used to carrying architectural responsibility through direct contact with the code. They want to touch every line because they know they will be on the hook later.

I get that. I felt that.

But I have changed my mind. The models are good enough now, especially inside a good harness, that the bottleneck is less often "can it write better code that I can?" (hint: yes) and more often "did I explain the work well enough, and did I build the right guardrails around it?"

Reviewing the reviewer bots

At some point, reviewing every line stops being a serious plan. If the output volume is high enough, human line-by-line review becomes theater. You pretend you looked carefully while catching the obvious thing and missing the important thing because your brain was not designed to diff thousands of model-generated lines every day.

So we changed the loop.

A coding agent opens a draft PR, and multiple review agents review it. Different models have different personalities, which is weird but very real. One is pedantic about types, the other is better at security, while a third is annoyingly good at noticing product inconsistencies. They leave comments, and the coding agent decides what to accept, making the changes and triggering...