Writing

  • From Typing Code to Orchestrating Tools

    Not long ago, being a software engineer meant knowing the language, the framework, and the libraries. We spent most of our time translating intent into syntax: constructing loops, handling edge cases, naming variables, shaping data structures. Our value was in how well we could type the machine into behaving.

    But something subtle is happening now.

    Code is still essential. Syntax still matters. Yet more and more of the mechanical part of programming—the keystrokes, the transformation of intent into structure—is no longer the bottleneck.

    The real work is shifting upstream.

    What’s shifting (in practice)

    Instead of writing code line by line, we are increasingly:

    • Directing agents instead of acting as one
    • Debugging reasoning instead of just logic
    • Describing outcomes instead of step-by-step instructions
    • Composing systems of tools rather than writing every part ourselves
    • Spending more energy on clarity of intent than correctness of syntax
    • Evaluating output rather than producing all of it by hand

    We are moving from builders to conductors. From typists to orchestrators.

    This isn’t about laziness. It’s about leverage.

    A developer who can guide AI with precision, validate results with discernment, and architect systems instead of merely implement them becomes a force multiplier.

    Typing fast won’t matter as much as thinking clearly. Memorizing APIs won’t matter as much as understanding constraints. The engineer who thrives next isn’t defined by keystrokes, but by judgment, abstraction, and the ability to steer complexity.

    The keyboard isn’t going away. Its purpose is changing.

    This doesn’t diminish the craft. It expands it.

    We’re not just coding anymore. We’re orchestrating intelligence.

  • Even a Plateau Would Reshape Engineering for 20+ Years

    Every conversation about AI seems to hinge on velocity. How fast models are improving. How quickly new capabilities arrive. How long until we hit “AGI.”

    But I think the more interesting question—and the one with real career implications—is this:

    What if progress slowed far more than we expect?

    What if LLMs plateaued near where they are today?

    I don’t think the outcome would be stagnant at all. I think the consequences would unfold for decades.

    We’ve seen this pattern before

    Software development didn’t stop evolving once we got C. Or Java. Or the cloud.

    Each shift changed who could build, what they could build, and how much leverage a single engineer could generate—not because the tools improved forever, but because the baseline moved permanently.

    LLMs have already moved the baseline.

    The ripple effects still take decades

    Even if models never become meaningfully “smarter” than GPT-5, the ripple effects alone would take us twenty years to absorb:

    • The primary interface becomes natural language, not syntax
    • Debugging shifts from typing fixes to evaluating reasoning
    • Apprenticeship looks less like memorizing APIs and more like orchestrating systems
    • Teams shrink or specialize; one engineer may guide five software agents
    • Documentation and code literacy matter more than code volume
    • The ownership boundary between human and machine changes shape

    Plateau is not stagnation. Plateau is the new floor.

    From that floor, an entire generation of workflows, roles, and products will emerge.

    Progress isn’t required for disruption. Absorption is.

    We are still at day zero of that absorption curve.

  • Do LLMs Have “Peak Hours”? And Should We Be Asking for SLAs?

    Have you ever wondered what a service-level agreement for an LLM would even look like?

    The other day, I was using Microsoft Teams and noticed an option to try GPT-5. When I clicked it, a disclaimer popped up saying results might vary depending on when the request is made. I don’t remember the exact wording, but it definitely made me pause—because I’ve heard this same idea come up again and again.

    Plenty of developers swear that model quality dips during “prime time,” like Wednesday afternoons, compared to early Saturday mornings. Anecdotes aren’t data, but the consistency of these stories is hard to ignore.

    Personally, I’d rather wait a little longer and get the same quality every time.

    Why variability might be real

    What’s interesting is how little the major providers say about quality variability. My hunch—and something I’d genuinely love to test—is that API usage (where you pay per call) may give you more consistent results.

    But flat-rate services like Copilot, ChatGPT Plus, or Claude’s paid plans may group you into a shared-capacity pool.

    A plausible mechanism (no inside info required)

    Under the hood, these systems tokenize your prompt, run it through layers of neural computation, and look for the most relevant patterns they can find within a set compute budget.

    “Thinking harder” basically means the model gets to take more inference steps. If usage is high, it may not take those extra steps. It just settles faster, which can feel like a dip in quality.

    A lot of this is based on general principles of how these systems work rather than inside information, but the clues are piling up.

    Where this may be headed

    I suspect we’re heading toward a world where enterprises start asking for real SLAs around model consistency.

  • Ever Wish ChatGPT Came With a Help Button?

    I felt that way when I first started using it. No manual, no guide, just a blank box and a blinking cursor. It reminded me of the early days of the Internet when bookstores sold “how to get online” books that were somehow more confusing than just clicking around.

    Generative AI changes the idea of documentation. The official docs still matter, but these tools can also explain how they see their own abilities in real time.

    Sometimes the simplest way to learn how to use AI… is to ask the AI.

    What to ask (and why it helps)

    If you want to know how to work with AI tools like ChatGPT, just ask:

    • Does it understand a language, library, or framework you’re using?
    • Does it know a technique you’re considering?
    • Where does it struggle, and what kinds of tasks does it do poorly?

    A quick example

    While working on a 3D model, I noticed both ChatGPT and Claude struggling with spatial-reasoning tasks. I asked why, and they each confirmed that this is an area where they’re not strong. That quick check saved me a lot of back-and-forth.

    And it goes even further. If you want to write better prompts, the model can help you write better prompts. It feels odd, but it works.

    These tools can even reflect on their own output. If they write code or a paragraph, you can challenge them: “Is that the best way?” More than once, they’ve admitted my suggestion was better and rewritten the solution.

  • Why Your AI Partner Gets Foggy the Longer You Talk

    One of the stranger things about using large language models is that they never actually tell you when they’re running out of room to think. There’s no pop-up saying, “Hey, you’ve hit the limit.” Instead, the model just quietly gets worse.

    Answers get fuzzier. Details get dropped. Logic starts bending.

    If you’ve ever wondered why, it comes back to something called input context.

    What input context is

    Input context is how much information a model can consider at one time. It’s measured in tokens: tiny pieces of text, usually a few characters each.

    Every word you type, every code block you paste, and every part of your ongoing conversation all eat into that limit.

    What happens when you hit the limit

    Once you reach the edge of that limit, older parts of the conversation get internally compressed so everything still fits inside the context window.

    Think of it like summarizing your entire chat into a smaller and smaller space each time. That’s context collapse, and it’s why the model slowly feels like it’s forgetting things or getting “dumber.”

    Older models hit this wall quickly. Newer ones have much larger windows, but even with a million tokens, it’s still possible to overflow them with long conversations and big codebases.

    Practical tips to keep things sharp

    • Reset the conversation when answers start drifting
    • Re-paste the key context you want the model to use
    • Keep prompts focused and avoid unnecessary history
    • Send large codebases in smaller, purposeful chunks

    Understanding input context won’t stop context collapse entirely, but it will help you recognize it—and help your AI partner stay sharp instead of quietly unraveling at the edges.

  • Why AI Sometimes Feels Random, and Why That’s Actually a Feature

    Why does an AI model give different answers every time? And honestly, why does it sometimes feel downright random?

    In classic computing, everything was deterministic: same input, same output, every time. That’s how traditional information systems worked (and still work). But large language models operate in a probabilistic world. Instead of following a fixed path, they’re essentially rolling weighted dice.

    That’s not a bug. It’s the magic.

    Why the “randomness” helps

    This probabilistic behavior lets models fill in the gaps, because even when we think we’re giving complete information, we really aren’t.

    Humans do this all the time. If my wife asks me to go buy lettuce, she doesn’t need to tell me what car to drive, which grocery store we prefer, or even what type of lettuce we usually buy. I fill in the holes effortlessly.

    LLMs do the same thing. If I ask for help designing an API and forget to describe a key piece, the model will often say, “I’ll assume your method signature looks like X…” and just like that, it fills in exactly the detail I didn’t know I forgot.

    The downside: hallucinations

    Of course, this is also one way we get hallucinations. When the holes are too big, the model invents an entire story to connect them.

    So how do we get more predictable output?

    That’s where the very un-fancy term prompt engineering comes in.

    The more structure, clarity, and constraints you give—outlines, formats, priorities, exclusions—the more deterministic the contours become, while still letting the model stay flexible where it needs to.

    Hopefully this wasn’t too dicey of a topic.

  • What “Context” Really Means in Generative AI

    If you spend any time with tools like ChatGPT, Claude, Gemini, or Grok, you’ve probably noticed the word context pop up everywhere.

    And if you’re a nerd (I am), you may have wondered where the term came from. Surprisingly, it’s rooted in a Latin weaving term—literally about threads woven together. Linguists picked it up in the early 20th century, computer scientists ran with it in the 1950s, and if you’ve been around Windows long enough, you might remember when the right-click menu was actually called a “context menu.”

    Why this matters: in generative AI, “context” is a real constraint, and it shows up in a few different ways.

    In large language models, it generally breaks down into three uses:

    • Input context
    • Output context
    • Model Context Protocol (MCP)

    1) Input context

    Input context is how much information a model can consider when producing an answer. This limit is measured in tokens, tiny pieces of text that average a few characters each.

    Older models like GPT-3.5 would hit that limit quickly, leading them to summarize or drop details. Newer models have far larger windows—Gemini Pro can take in around a million tokens—but limits still matter, especially with big codebases.

    2) Output context

    Output context is simply how long the model’s response is allowed to be. A model might understand a massive amount of information but still only be able to output 8K tokens.

    That’s why answers sometimes cut off mid-stream.

    3) Model Context Protocol (MCP)

    Finally, MCP is a newer mechanism for supplying additional structured information—something I’ll cover in a future post.

    Understanding these flavors of context helps you get sharper, more reliable results, and keeps your AI companion from losing the thread (see what I did there?).