What my job became once AI started writing the code

    Zubair Afzel | Building LatticeRun with AIZubair Afzel | Building LatticeRun with AI · 4 min read

    I don't write code in the traditional sense, yet I run a portfolio of software products. Claude Code and a set of AI agents do the typing. I used to think that meant the hard part was handled. It turned out the hard part had simply moved.

    This is what the job looks like now, from the products I build and the mistakes that taught me where the work really is.

    The AI writes the code. I decide what it should do.

    A few days ago two of my scheduled posts looked as if they had failed to go out. They hadn't. They went out exactly on time, in New York time. I'm in London. The app showed 10:30 and I read it as my 10:30.

    The AI had written the scheduling code without a problem. What it could not know was how a person would read a bare time on a screen. That is a product decision, not a coding one, and it was mine to make. Every time in the app now carries its zone: 10:30 ET.

    Most of my days are made of moments like that. The code is rarely the question. The question is what the person on the other side will understand, expect and trust.

    Agents forget, so I built them a memory

    The first thing that went wrong when I started working with agents was not the code. It was memory. Every new session started from zero. The agent forgot what we had decided the day before, so I spent the start of every session explaining the project again.

    That is the problem LatticeRun exists to solve: a shared project plan and memory that my agents read before they start and update when they finish. Decisions get written down once. The next session begins where the last one ended, instead of with a recap from me.

    If you are thinking about putting agents to work in your business, ask one question first: where does the agent keep what it learned yesterday? If the answer is nowhere, you will be the one doing the remembering.

    Cheaper models are a decision, not a default

    Every AI call in my products costs money, so choosing models is part of the job too. I don't pick them on reputation or a price list. I test them on the real prompts my products send.

    This week I tested a small, fast model as a cheaper way to sort mentions and judge relevance in Prospel. On relevance it agreed with the model I already use 78 percent of the time. That sounds fine until you learn that my current model agrees with itself 92 percent of the time when asked the same thing twice. The saving would have been cents. The cost would have been worse decisions for users. It stays on the bench for now.

    The rule I follow when I do switch a model is simple: deploy the code first, then change the settings it reads. Do it the other way round and the old code meets a setting it doesn't understand.

    "Success" is a claim, so I check it

    This week I added one of my products to Prospel's Product Brain, the part that learns what each product does so posts about it stay accurate. The screen said the scrape was successful. Nothing showed up.

    The reason was small. The AI's answer had been cut off part way through, so there was nothing usable to save, and the code saved an empty product called "My Product" and reported success anyway. The fix was to give the answer more room, retry once, and fail out loud if it still can't be read. An honest error is far more useful than a false success.

    AI tools are very good at sounding finished. Part of my job is to look at what actually happened, not at what the message says happened.

    The rules I work by now

    • Decide what the user will see and understand before anything gets built.
    • Write decisions down where the agents can read them, not just in my head.
    • Test models on real work and compare the cost of a useful answer, not the price list.
    • Change code before the settings it reads, never the other way round.

    What this means if you run a business

    You no longer need a technical team to build a useful tool for your business. You still need someone who knows exactly what it should do, who it is for and what good looks like. AI makes the building fast. It does not make those decisions for you.

    If you are a coach, a consultant or a founder, the skills that matter here are ones you already use every day: knowing your customer, explaining clearly what you want, and checking the work before it goes out. Those are the skills that turn an AI tool from a toy into something your business can rely on.

    That part is the job now, and it is the part worth getting good at.

    Published with Prospel