Austin Python Meetup - Building Sensorimotor Intelligence in Public: From Research Code to Platform

Recently, I had the opportunity to present at the Austin Python Meetup regarding the engineering side of the project. It is now available online if you’re interested.

Over the past two years and dozens of releases, we have been evolving a research codebase toward a production platform. This talk is the engineering side of that journey.

We’ll cover why we chose to evolve the code in place rather than rebuild it. How a small team sets priorities with no revenue to guide decisions, only a specific end state to reach. And why deep class inheritance hierarchies are a misunderstanding of object-oriented programming, and what we do instead: composition, protocols, and a hard one-level-of-inheritance rule.

Along the way, we’ll share what we got out of Python typing, where performance forces architecture, and how LLMs fit into what we do and where they don’t.

If you write Python, you’ll find designs and choices to compare and contrast with. If you supervise, you’ll find a case study of steering a codebase without revenue feedback.

4 Likes

this is so helpful. thank you for posting.

1 Like

Nice presentation, it’s great to hear about the whole thinking process and reasoning that went into all of the decisions. You were even careful not to oversell it by saying “right now it’s more for the believers” :joy:

I like the explicit framing of adversarial collaboration. If you’re gonna spar, better put seniority aside, not hold back, and grow as a team from it.

The most interesting new info (from my perspective at least) was the internal LLM policy, which is quite a shrewd one, given industry trends.

I’m not too keen on having an agent write my code either. (Slightly ironic considering my username, although that choice of name is unrelated to LLMs :wink:) Even at my workplace, I don’t do much agentic coding, due to safety-critical requirements and proprietary architecture complexity.

My usage of LLMs is primarily pair programming. I explain what I’m trying to build and my initial ideas, asking for suggestions and stubs, which I then implement mostly myself, periodically going back and forth for advice and review. This seems to strike a good balance between “meat-modeling” and machine insight, and I learn a lot in the process.

I always raise an eyebrow when a software engineer says stuff like “I haven’t coded in 6 months, AI writes everything.” Being an engineer involves orienting and managing expectations, risk, and technical debt, all of which tokenmaxxing undermines simultaneously.

3 Likes

agreed on the “its for the believers”. This presentation gave me a lot more perspective on what is going on right now, and apparently its a wire-frame holding hopes and dreams together around a philosophical (and scientific) theory and that totally rocks.

The best part is it works and I think this talk undersells the degree to just how much it but Im probably a year away from showing it.

On LLMs: I have been coding for 15 plus years. I use Claude to do a lot of coding these days. When it comes to coding, before we would:

  • ask a question on stack overflow, and get ridiculed. Then never ask another question, and just start hoping a use case on the internet matched our own.
  • spend hours figuring out how to implement our findings in our own messy stupid code base
  • ship and act like you know everything

To be clear, I am no slouch: I deploy and manage Enterprise level applications in DMZ and behind firewalls every day for the government. Also, the following is not meant to be antagonistic in any sense of the word, I just an a professional computer programmer with a philosophy degree and I have some strong opinions! TO EACH THEIR OWN, but:

LLMs are good at one thing, building code. “Token maxing” is not the only way to use these things, and I have never let an agent run wild without me there to check it. I read and question every single output. I feel a little on the outside sometimes when I listen to other veteran coders who outright refuse to use it. Sure, no one should be subjected to code made by LLMs, but I personally have been subjected to plenty of handwritten code that people love and I find to be GARBAGE. Especially when it all lives in an object oriented world, you are literally having to wait for garbage collection cycles. R, C++, Python, are all pre-LLM ways to speak to the computer without having to fully understand it.

Additionally, I have legitimately lopped my daily work in half, and I get to spend that time making robots, audio plugins, video games, 3d printing… woodworking, songwriting, playing catch with my dog, skateboarding, and being a dad. I can build an app from my phone while i grill steaks. In my mind coders finally got their electric drill with LLMs, and yes there are still woodworkers out there, making a couple things a year with hand tools, shaking their fist at table saw and power router users who make 100. But that doesn’t matter to me because I have more pressing matters than sitting in front of my computer and checking my own spelling.

I have always found coding an ugly art form, as does Jaron Lanier, and the back in the day when I also had to sit on my butt and get ridiculed by basement-dwellers for asking a question about a 100 percent deterministic system was the insult to the injury.

I know exactly what goes into my code, because if I did not, Claude wouldn’t either. I think with the excellent progress on light, open source models, that restricting LLM code based solely on if LLMs were used will restrict hobbyists and in-their-spare-time contributors to a dope but admittedly under-developed system that also, to us believers, is genuinely the best angle of attack towards AGI. This is basically the same as a client rejecting a table I built because I used modern woodworking tools to make it in a quarter of the time as a hand-tool user… just as clean, still beautiful, holds stuff, but to some people in the community not the “right way to build a real desk.”

the whole idea that code used to be beautiful and now its not because of LLMs is laughable to me (no offense), and the term slop should only apply to art in my book. Code itself isn’t art. The thing that it runs is, and that’s how you can decide if it helped or was deleterious, which is the same as it always was: does it execute dependably in the time you need it to? If yes, it works!

Even though I said “not too keen”, it’s not an emotional decision, I look at it through the lens of engineering. For the kinds of things I have to deliver, especially as part of my profession, I simply conclude so far that the estimated downsides outweight the estimated upsides. Should the balance flip, I have no strong feelings holding me back from using them more.

I do generate code to some degree for internal tooling and certain aspects of my personal projects, where technical debt is of low concern, which also allows me to independently judge their current operational capabilities.

However… There will be a day when the upsides shall far outweigh the downsides.

The day that Monty overtakes LLMs, that is! :face_with_steam_from_nose:

1 Like

YES. that’s what i’m talking about! a code bot that remembers… yes please.

1 Like