After my experiments with code generation, graph traversal for outside-in prompting, and combined development time and runtime, I was really taken with graph traversal.

But I realised I didn’t need my custom graphs to traverse code – I was working in TypeScript, and its compiler already understands the code as a syntax tree.

Project 2 was orchestrating outside-in graph traversal for code generation, using syntax trees of your existing code to find entry points for generable software. In this approach, an entry point is identified and described briefly with a special type that extends a custom Generable type, a VS Code extension detects and implements Generables, and a tiny custom dependency injection framework injects them at runtime.

You can use code you didn’t write yet and let the system implement in the background. No need to write special graphs – if you’re writing code, you’re already writing a graph. What a great design language for engineers! If you can get the system to use the same type-based delegation recursively, maybe you can specify pretty challenging high-level Generables in a high-level orchestration layer, and use it while it gets implemented underneath you.

But developments in agentic approaches made me feel that I was still undershooting the future – that this would be superseded by an agentic, general purpose software engineer, even though that is a much harder version of the problem to solve! And I wasn’t ready to let go of combining development time and runtime.

More on those spaces and how they influenced my work in the next post 🙏 Including some specific tools I have enjoyed, for people who want to try things out.

I want to share a story that challenged my most basic ideas about software engineering.

Months ago, as part of my first new AI project, I designed a DSL for expressing software designs. I found a pretty friendly way to describe a pseudo-graph of operations and data. You send it to my server, with a target node.

My server builds outside-in to reach the target node. At each node, it prompts a model to implement a suitable function, with the code for already-implemented consumers (the node’s parents in the graph) and a plain English description (from the DSL) supplied as system instructions. Engineers who work outside-in and consumer-first might already know why this is a useful approach for AI.

You can design and run complex things neatly and correctly – take-home programming exercise level stuff. Though I’m working on something else now, I still love that project. I’m proud of two decisions in particular.

First decision: Pass the graph you want to execute and a target node in at runtime and get the result synchronously – not the software, but the result of running it, providing inputs as the outermost edges of your graph. The server doesn’t build software for you, it computes for you, with software that it builds incidentally to get your result. This means there is no separation between software development and operation – only latency and caching.

It is a shock to work with something that does lots of your job at runtime. Our code is usually so precious to us. Think of the care we take in its production, testing, and deployment. What a strange feeling, to suddenly think of it as so trivial that it might not even be worth caching!

Second decision: Let the client patch their graph – just keep adding to it in separate HTTP calls, specifying whatever parts are needed, referencing parts specified earlier, all while targeting a node in each call to get results.

I used it super-iteratively, designing software with a tight feedback loop between my requests and the resulting responses and software until I had a system I liked. At that point, I could delete the graph and any code, because my requests essentially were my software. Everything after design was incidental – generable at runtime. I could use my honed set of graph-segment-and-target-node patch requests like endpoints to operate the system, even if the system didn’t exist yet. It was a Keanu “woah” moment for me.

I thought deeply about this paradigm we are swimming in – where software must be developed and deployed well in advance of being executed. It felt like seeing water.

We could have a dynamic runtime where models run code ad-hoc to achieve their goals. Code can be used, rather than developed, deployed, and executed, collapsing the space between development and runtime as my project did. There’s no technical obstacle, really. We just need time, compute, and creativity.

That glimpse of the future was really impactful for me, and I took the lessons in my following work.

I’m lucky to have been able to throw myself headfirst into AI since leaving SadaPay, but almost everybody I know in-industry is still building traditional software. There’s a lot happening. I’m working on my fourth AI project now, and I’m so excited by the work we’re doing in this space. You’re going to see a whole new generation of user experiences. I’ll try to pause and share back sometimes, from now on.

Sometimes when I talk with people about AI, all they can share is that they aren’t impressed with ChatGPT. To me, that reaction seems like seeing electricity power the first electric light bulb, and not being able to imagine an air conditioner, a television, an electrified subway system – or maybe not even a better lightbulb – and thereby concluding that candles aren’t going anywhere.

It’s not that skeptics are wrong, it’s that they’re missing the forest for the trees by evaluating a fundamentally new form of compute – an enormous foundational breakthrough – as if it were a product, based on the first product(s) they have seen it power.

We have some form of intelligence on demand now, like electricity, but electricity required a lot of work to go from the first lightbulb to the massively electrified society we have today. We are building a whole new ecosystem in massive parallel, from chips to user-facing software, and we are really just getting started, but it’s coming faster than you might think.

We talk a lot about the best ways to work, but we don’t talk very much about how to move our organisations toward them.

As a former consultant, I grappled with this every day. Even with a clear idea of some alternative way of working, a large team of people ready to teach it and good executive support, it is still very difficult. One reason for this is that we hastily squander a powerful resource – pressure. 

When a problem impacts our business, organisational pressure is created. We all want to relieve that pressure and that shared desire is a special thing – we can harness it to effect positive change. Unfortunately, many organisations react reflexively and take the path of least resistance. That is how pressure differences work, after all. We look for quick fixes like overworking “temporarily” or juggling more WIP. But quick fixes are not always good fixes.

What if we are only moving the impact somewhere less obvious? E.g. we have started a critical piece of work to placate stakeholders, but the resulting increase in WIP is causing inefficiencies across all work? What if we are only changing the timescale of the impact so that instead of being hurt a little every day, we get hurt a lot all at once? E.g. we are overworking somebody and it will blow up in our face when they quit.

Our quick fixes may actually leave us in a worse place than before. The root problem is still not solved and there is little pressure left to drive improvement. We wasted our chance. 

It’s important that we not reflexively relieve pressure. Pressure helps us grow and change if we channel it wisely. We may need to use some of that pressure to make the immediate impacts of our problems manageable, but to build a great and enduring business we must direct as much of that pressure as we can into lasting solutions to our deepest problems. So spend your pressure wisely and don’t rush relieve it entirely. To improve continuously we need pressure and with no pressure, we can easily get stuck.

If you want a fleshed-out example, you can read my article about adopting trunk-based development. It’s an approach that offers some benefit at each stage, while still leaving or creating enough pressure to drive us toward the next one. 

If you want to be a better competitive swimmer, you don’t ask for feedback on your lap times and trophies – you focus on improving your technique and know that results will follow. 

Most software developers are preoccupied with the properties of good code, but knowing what it looks like is not the same as knowing how to write it. A good critic isn’t automatically a good creator. 

How does the length of your red-green-refactor cycle impact your results? Does working outside-in or inside-out change your solution? Do different pairing styles lead to different outcomes? Do you get simpler code by thinking through the problem in advance, or by being deliberately naive? Does writing failing tests instead of passing ones impact your implementation? Do your team members work through problems in different ways and if so, what are the advantages and disadvantages of their approaches?

If you can explain SOLID principles but you can’t answer these questions, forget about *what* for a second and start thinking about *how*. 

Pair with your teammates. Let them show you their way of thinking and working and the next day, ask to show them yours. Set aside time together to reflect on your experience and discuss what you want to do differently next time. Do experiments together and share the results with your team. 

Focus on technique.