Moving Fast

Software has changed dramatically in the last few years. Was it 2022, when ChatGPT first came out? Was it 2023 when people realized this thing can write your code snippets for you and you can paste it back into your code-base instead of relying on more “general” code snippets from stack overflow that you couldn’t turn your brain off and paste back into your code without modifications? (not saying it was impossible, lots of blind copy pasting happened, but it wasn’t as prominent for less general functions or small one line param changes in a function call or config change)

We (everybody, not just devs) have gained this unholy ability to create software and programs incredibly fast. Although I am not fond of saying we gained the ability to do exactly that, I would much prefer to frame it as we gained the ability to spit code out fast, this code could be used to count the number of files you have on your desktop, create a presentation for your pitch deck, or write a semi complex personal expenses tracking software you always needed. No matter how obvious and apparent it is, it still is controversial to believe that, we haven’t gained the ability to spam out software, we’ve gained the ability to spam out code. Is there a difference?

The Distinction

Believe it or not, that is a very clear and meaningful distinction. I know the VCs dont like to hear it, neither do the AI course sellers. But we have gained the ability to churn out code very fast yes, but coding was always a very very small part of creating software. As cliche as that sounds, I tell you that for a fact. Converting business logic into deterministic machine commands, was never, ever the most complicated part. Infact think about it, if you’ve ever done basic math, as a non-dev, its the same as converting:

Ali has 3 apples. Ali went to the market and bought 3 more, but 2 were rotten. How many apples does Ali have now?

to this:

Taking x as the total count of apples.
x => 3
x + 3
x => 6
x - 2
x => 4

Thats all programming ever was, but rather than for a narrowly scoped arithmetic problem (not that thats all math is, but thats what most people’s familiarity of math is), it was for more general business workflows and logic.

Now that I’ve given you an analogy with Math, I could show you the same in computer programming. It would look like this:

Check if this is a new user who signed up to the website. If so, redirect him to the pricing page, and show him the new user offer. If user clicks on it, take the chosen plan from the user’s selection, apply the offer on it, open the card transaction page. If the transaction completes, apply the plan on the user’s account and redirect them to the dashboard.

This would be a very random but common flow that most programmers have had to write. Writing this was NEVER the hard part. Infact, if you’ve ever written a high level language like python, writing this logic out would almost be identical to English barring a few intricacies. I’ll generate a function that does this, using an LLM and show you the result.

from fastapi.responses import RedirectResponse

async def handle_new_user_flow(user, selected_plan=None, payment_success=False):

    # Existing user → dashboard
    if not user["is_new"]:
        return RedirectResponse("/dashboard")

    # New user but no plan selected yet
    if not selected_plan:
        return RedirectResponse("/pricing?offer=new-user")

    # Apply offer discount
    discounted_price = int(
        selected_plan["price"] * 0.5  # 50% offer
    )

    # Payment not completed yet
    if not payment_success:
        return {
            "redirect_to": "/card-payment",
            "amount": discounted_price,
            "plan": selected_plan["name"]
        }

    # Payment success → activate plan
    user["plan"] = selected_plan["name"]
    user["is_new"] = False

    return RedirectResponse("/dashboard")

That’s what ChatGPT gave me, and barring a few infrastructural dependencies, thats a pretty solid representation of what an intern or junior dev would be writing pre AI. LLMs have largely eliminated this kind of work. This kind of work did take some time to do though, that kept hiring and demand for juniors and interns going, and that kept hiring going, and thus the industry. But a developer that knew how to write this function, was never going to be able to build out the software your team was working on anyway, even if we had a 100 of them.

100s Of Them

Thats what an LLM is. Its like having this dev, but with a blank mind that doesn’t remember anything. And also kind of a braindead version of this dev, that doesnt learn your tendencies, take your feedback to improve long term, has to be hand held to get the right things out of them. That’s why having an LLM is like having a 100 of these devs, the output is similar to having 100 such devs, you fire off each isolated task to one of them and they give you the code (albeit much much faster!).

Progress is being made in this direction with what we call “agent harnesses”, basically the programs (claude code, codex) that are built around LLM help LLMs “remember”, or “improve”, “take in context of the task”. Although its all a facade, but results have been decent. An LLM cannot remember, an LLM cannot improve with your feedback or instructions. We’re trying to make it seem that way, but its all bandaids on the wounds. The improvements in the last year or so have been marginal, its almost like we’ve been psyopped into believing things are improving, but thats beside the point. The thing is fundamentally, its all a bandaid solution, things realistically are not going to get fundamentally better here. But lets talk about how thats impacting us.

Understanding For Speed

This brings me to what I want to talk about, all things considered, the speed up of having 100 interns or junior devs was never really going to be much. Ask any serious engineer you know, having 100 juniors under him instead of 2-3 is not the amazing concurrent work benefit you think it is. We are humans, building as humans, humans have NEVER really meaningfully benefitted from collaboration on a shared intellectual artifact. If that statement hurts you, please reread carefully and consider every word I said in that. That is not a blanket statement, its a very carefully worded and specific assertion.

If I had a 100 developers under me, just waiting to spit out code, I could, “technically” get faster, if I started optimizing for keeping them busy rather than building the software. The parameter we are optimizing for changes here, we build fast yes, the output increases yes, but does the software get built faster? We produce more code, we don’t build the software faster, no we do not.

All this discourse on “speed”, is just about what you define speed as. Is more output, more code produced the factor you’ve always been optimizing for? If so we could perhaps technically be sped up with 100 junior devs under us, but then why didn’t massive software companies just have a 100x engineer somewhere in SF and about a 100 best interns from the hundreds of thousands of engineering graduates in India? This would be a dirt cheap setup for 100x productivity, and similar to the current situation. What would be the value of the code produced if the production was owned by a single person? Why wasn’t it done so far? What is the value of the code produced in similar environments, through LLMs? Does it provide any value other than run/build successfully, pass all existing tests successfully and band aid implement “features” that pretend to work? Even that happening isn’t a default, it has to be enforced as a feedback loop for the agent.

Is this setup even valuable? What is the value of all this code without explicit human supervision, oversight and here’s the key word: understanding?