Navigating the New Software Development Paradigm

At Shopify we notably had an early mandate to use AI, and towards the end of my time there my adoption of AI was progressing, but was focused on AI-assisted programming: Using the Copilot autocomplete in my editor, using Claude to ask for suggestions, help, or ideas, or letting it work on tasks that were repetitive in projects where the interfaces were well established, much of which I had written myself first.

Since joining Mark OS in December last year, almost all code I've "written" has been the work of agents.

Now that code is cheap, there's an onus to move even faster when you're building something new. You're able to deliver things for your users or clients in days that might have taken weeks. It brings new opportunities to the table, and lets you be much more reactive, allowing you to meet the moment. It makes sense that startups would jump headfirst into using it to speed up the process. After all, you don't yet have the scale to hold you back.

I've always enjoyed programming. It's how I got into all of this, spending late nights in my teens making my own websites, IRC bots, and other applications. But with the advent of LLMs and where they are now, spending time programming is becoming hard to justify. Using LLMs to quickly build software is now table stakes.

I feel some loss from not doing implementation anymore, and I often think about how my skills may atrophy.¹ This is a theme I pick up from friends too. What hasn't changed yet is that we still need to think about the problems; it's still relevant to be an architect. The knowledge we've gained over the years isn't a wash. We're in an industry of change and advancement. We've always had to adapt and learn to stay relevant; this is a flavor of that—but we're changing how we build and what we build with.

By default, agents may not write code to the quality bar we hold ourselves to, but building up that harness is another skill we learn to guide them. Agent skills, AGENTS.md, guardrails, all work in service of guiding the agent towards what we find acceptable at a pace we wouldn't match. It is often as easy as telling it to write these things up when the problems are made clear. I've found that I get pretty good results with this in addition to following a brainstorm → spec → plan → implementation flow and a heavy lean into active documentation generation.

The needle is moving all the time. You should use loops. No, graphs. Curtains for Zoosha? There's a lot of talk about building agent factories, deferring most of the work in parallel straight to a pipeline of agents that take your specs and run with them from there. Such systems may allow your non-developer teammates to ship, too.²

We're running a marathon right now, but I do find enjoyment in navigating these new paradigms and working to be ahead of the curve.