Are technical skills useless now that AI agents write the code?

By 1 November it had about 36,000 likes and 1,500 replies. In one reply, Hiten Shah said they had never been an engineer who writes code, yet were very technical after more than 20 years of shipping product with engineers. Thariq answered that technical people should be massively amplified, with so many ambitious problems still to solve, and called it "a big change in mindset". Both replies match what we saw while building Countstead.

The sadness has a real cause. Writing code was a big part of what technical people were paid for, and agents now write a lot of it. Countstead is our offline inventory app for iPhone and iPad. It went from first commit to the App Store in 58 days, and 391 of the 550 commits before launch name a Claude model as co-author. By version 1.9 the count was 1,789 of 2,229. Each piece of work started as a written plan that an agent worked from: 292 plans before launch and 481 by version 1.9.

If your work was mostly turning a clear specification into code, an agent now does much of it, faster than a person, and we do not expect that to reverse.

Offline first was settled in the specification, a day before the first app code was written. An agent will build an app that needs a connection or one that works without it, whichever you ask for. Picking the right one takes someone who knows what each choice will cost once the app has customers.

Separate agents reviewed the plans and the changes. In one October review, five reviewers raised about 90 findings on a set of plans, 11 of them blockers, before any code was written. Reviews like that are cheap to run now, and deciding which findings matter still takes someone who understands the system. In another case, a person spotted a problem, had the agents write a fix and asked for the fix to be reviewed. The first review round found two database operations that could deadlock each other, and that was fixed before the change merged.

Each release build had to pass the full automated test run first. Before version 1.0, that meant 901 Swift package tests, 1,313 app unit tests and 148 UI tests. A person then tested builds on a real iPhone through TestFlight, worked through each release's checklist, and either pressed Submit or approved the agent's request to do it, because the agents' permission check blocks App Review submissions. That routine is a large part of why we could ship ten updates in the seven weeks after launch.

When a non-technical founder wishes they were more technical, we think what they want most is a way to tell when the agent is wrong.

An agent does what the brief says. Give it a vague brief and it hands back an app that looks finished and fails the first time a customer does something unusual. Being technical with agents mostly means asking the questions a brief leaves out. What happens with no signal? What if two people edit the same item at once? What if a payment fails, or App Review rejects the build? It also means reading a plan or a test report and noticing what is missing.

Hiten Shah's reply shows that this skill can come from working alongside engineers, without writing code. Some of it can be learned faster. Our app requirements template lists what a brief should cover, including offline use and payments, and our questions to ask an app developer cover testing, code ownership and handoff.

Vibe coding, where you accept whatever the AI writes without reading it, is fine for a throwaway tool. For an app that holds customers' data, takes payments or goes on the App Store, someone who knows what to check should read and test the code. We made that case at more length in how long it took us to build an app with AI.

1. Write the brief before anyone writes code. Countstead's first commit was its specification, and every later plan referred back to it.
2. Read plans before code exists. That is where our October review caught 11 blockers, when fixing them meant editing a document.
3. Spend the time agents save you on tests and review. Agents produce code quickly, and every change still needs checking.
4. Take on bigger work. We shipped an offline iPhone and iPad app with subscriptions in 58 days and updated it ten times in the next seven weeks.