Bryan Friedman

The Evolving Technologist: Adventures of a Recovering Software Generalist

Made With AI, Not By AI

My wife and daughter are both social media managers for various organizations (as well as for themselves, of course). They both have good marketing instincts, and they know something about how the algorithms work and how to maximize engagement. One thing I've heard them complain about more and more is the prevalence of AI-generated flyers.

One reason my daughter runs about six different school clubs’ social media accounts is to keep AI flyers out of those feeds. Not just because she hates them, but because people scroll right by them. So she wants to make sure that every story or reel about an upcoming school fundraiser or performance matches the right branding and doesn't look like it was made by robots.

And it's pretty obvious when the images were made with AI. There are usually stars or hearts, the font is predictable, and there are brush-stroke underlines and busy backgrounds.

It's a strange moment we're in. Using AI really isn't optional anymore, especially in the workplace, where agents are now just part of the workflow. We're supposed to use AI. Except a lot of effort also goes into making sure that the result doesn't look like we did.

So everybody's using AI, but nobody wants to look like they're using AI. Which means we have to figure out what the identifying characteristics are of "AI slop" so we don't get "caught" using AI. But the tells are different for images than they are for writing. And then there's all the code that agents are producing. Do we need to de-AI-ify that too?

# Find the Flyer

To give my girls some credit, it does feel like the AI flyers are rampant on social media feeds. Though I said that people don't want to look like they're using AI, the people who post these flyers can't possibly think they're hiding it. They are so easy to spot!

As with any new tool, it takes some practice before you can use it well, and until then, it shows. With AI, it's garbage in, garbage out. Or more accurately, nothing in, garbage out.

If you just ask it to “make a flyer for the spring concert,” you’re going to get the most generic flyer possible, because that’s all it has to go on. It’s basically giving you the average of every flyer it’s ever seen. But if you give it something to work with, like the club’s colors, the logo, an actual photo from last year’s show, and some real direction about what you want, the results greatly improve. The more descriptive your prompt is, the better the result will be.

You also don't need to take the first thing it gives you as the final draft. In fact, you shouldn't just use whatever it spits out based on your first prompt.

Instead, use it like you would Canva or Photoshop, and build things out iteratively, trying some things, discarding them, and trying something else. In other words, don't let it build the whole thing and walk away.

You could have it just get you started and spit out a PSD so you can finish it up in Photoshop. Or just keep telling the agent how to fix what it gives you until you get it how you want it. (Though all that iteration isn't free, which is one more reason to give it more to work with up front.)

By the way: none of this is about art, and that's a bigger conversation than I'm having here. I'm talking about everyday personal and business use, like a club flyer, website copy, or a blog post. I have a lot of respect for real artists, and nothing here replaces what they do.

# Does Anyone Care Who Wrote the Code?

In tech and enterprise software, agents are writing most of the code now, if not all of it. But again, it comes down to how you use the tool. When I'm hacking together a prototype or a demo with Claude Code or Copilot, I'm usually fine with whatever it writes, as long as it works.

But code review exists for a reason. Imagine if "it works" were the bar for human-written code! And as I've admitted before, I can't really call myself a software engineer anymore, so I won't be catching the subtle bugs lurking under the surface.

For code that ships to production, there are still (or at least there should be) capable engineers behind the keyboard, designing the architecture and steering the agent where it needs to go. Without that, it's pretty easy to tell when an agent wrote the code. Sometimes it takes shortcuts, like changing a test to match the code instead of fixing the code to pass the test (or just quietly skipping the test altogether). Other times it overcomplicates things, with more defensive checks than you'd ever need and an architectural pattern way fancier than the problem called for.

And agents love comments.

They will write whole paragraphs of them, sometimes explaining something useful in too many words, and sometimes just filling space. Even with an engineer driving, some of these tropes will stick around.

def is_even(number):
    """
    Determines whether a given number is even.

    Args:
        number (int): The number to check.

    Returns:
        bool: True if the number is even, False otherwise.
    """
    # Check if the remainder is zero
    is_number_even = number % 2 == 0
    return is_number_even

But does it matter if code looks AI-written? If agents are the ones maintaining it, and fewer and fewer people ever actually read it, does code quality even matter? For now, I think it still does. Agents have to work with whatever's already there, and messy code can trip them up just like it trips up people. All the usual code smells make the next change harder, no matter who (or what) is making it.

Maybe that matters less over time, as agents get better and humans do less and less of the maintenance. But I don't see architecture and design going the same way anytime soon. Figuring out how a system should fit together, and why, is still likely to need a lot of human input. Then again, maybe the AI overlords will take over completely and prove me wrong at some point.

# Does This Sound Like AI to You?

For me, writing is the trickiest because there are so many different styles, personal preferences, and unique voices. You can have AI write a first draft and then edit it to sound more like a person wrote it, or you can write a stream-of-consciousness draft yourself and ask AI to clean it up. Either way, you don't want it to sound like AI, so you feed it back to the agent and ask whether it sounds too much like AI.

It's the same move as having one agent review the code another agent wrote. That's a real practice, and it's proven useful to a degree. But where does it get us if we're just using AI to solve the problems AI created?

I made this point on LinkedIn with a Project Hail Mary reference. Astrophage is the thing eating the sun, but it's also the fuel that gets Ryland Grace close enough to stop it. The problem and the solution are the same stuff. That tracks.

# Bryan Slop

Here's the part that bugs me most, though. Even when I write something completely from scratch, it's starting to sound like AI.

I'm sure some of that is overexposure. I read so much AI-generated text in a day that its rhythms are leaking into mine. But it cuts both ways, since the things AI does were human habits first. It learned all its favorite writing tricks from us: the list of three, the this-not-that pattern, the em-dash.

Oh, the em-dash! How I loved using the em-dash. Now nobody can use one without someone assuming a robot wrote it. So we're editing our own habits out of our writing to avoid sounding like the thing that copied them from us. And what do you do when an em-dash really is the right punctuation? Use a colon? A comma? We're bending grammar rules in the name of AI avoidance. It's great news for the semicolon though.

"Human Made" by Tom Fishburne, marketoonist.com

Of course, sometimes my from-scratch writing is just bad (which was true before AI too). Instead of AI slop, it's Bryan slop. Maybe it's too wordy (me? never!) or repetitive. Or I've buried the lede somewhere deep in the piece in favor of a clever opening hook that barely works. (Is this getting too meta?) My own writing needs edits and several revisions before it's any good, same as anything an agent hands me. Writing it myself isn't a guarantee of quality. It just means the mistakes are mine.

Which has made me realize we have to be careful about confusing "AI slop" with "AI-written." People use them like they mean the same thing, but I'm not sure that's true. AI can write well, sometimes even better than I do on a first pass. Those brush-stroke underlines on the Instagram flyers aren't slop because AI made them. They're slop because nobody bothered to fix them.

Let's face it, people were making slop long before AI came along. AI just lets us make more of it, faster.

# Give It Something to Work With

In my last post, I wrote about a teacher at my daughter's back-to-school night who has his students do all their writing on paper. His reasoning is that you can't judge what AI produces if you never learn what good looks like. I still believe that. But even when you do know what good looks like, it's still hard.

So which way of writing with AI is better? Do you edit an AI draft, or does AI edit yours? I find that when I'm stuck, an AI draft gets me moving faster than a blank page, but when I already know what I want to say, I start myself and let AI edit. Either way, we're all still figuring out our own AI workflows, and they'll probably keep changing just like the tools do.

Regardless, it's the same lesson as the flyers: nothing in, garbage out. In the case of writing, though, the voice is the branding. When I write with AI, I'll often point it at this blog as a reference so it can try to pick up my tone. That only works if this is the voice I'm going for, though. What about at work, where the writing isn't supposed to sound like us? Website copy or marketing material is supposed to sound like the company. So the agent needs the writing version of the company's "colors and logo," so to speak. Maybe that's a style guide, or past copy to give examples of what you're looking for.

Whatever the workflow, whoever's voice it is, the most important part is that last pass. No matter how you start, AI can get you most of the way there. But at the end of the day, somebody who knows what good looks like still has to review it before it goes out. And even then, it's getting harder and harder to tell who wrote what.

So, was this post written with AI? Some of it, sure. Did I write a rough draft and have AI clean it up, or did AI hand me a draft that I tore apart? My wife and daughter will probably let me know.


Haven't We Seen This Movie Before?

I hadn't used it in a bit, but I randomly opened ChatGPT on my Mac the other day, and for a second, I thought I was in Claude.

The whole UI was different from how I remembered it, and it was styled much more like Claude's interface. They both always had the sidebar and the chat window, but now it seemed like ChatGPT even switched to using a similar font and color palette. I did a double take and realized that it was indeed ChatGPT.

When I started at Moderne, I was copy-pasting things in and out of ChatGPT all day. Then as I used Claude more and more at work, I switched to using it at home too. So I only open ChatGPT once in a while, but while I was gone it apparently redecorated to look like the place I moved to.

# Good Artists Copy

If you're of a certain age, this feels familiar. Remember Mac vs. Windows? I was a little bit too young to follow it while it was going on, but that's okay because it was made into one of my favorite TV movies of all time: Pirates of Silicon Valley. The movie dramatizes how Apple built its graphical interface after a famous visit to Xerox PARC. As Noah Wyle's Steve Jobs puts it in the film, "Good artists copy, great artists steal."

But then of course, Microsoft built Windows after Bill Gates visited Apple, and that quote about artists came back to bite Steve Jobs. This leads to probably my favorite scene in the film: when Steve accuses Bill Gates of ripping off the Mac, and Bill Gates says it was more like they both had a rich neighbor named Xerox, and Steve says that Apple has better stuff, and Bill Gates says "You don't get it, Steve. That doesn't matter!" (I don't know if it quite went down exactly like this in real life, but the Anthony Michael Hall and Noah Wyle version is my reality anyway.)

Feels like OpenAI and Anthropic are following a similar pattern, "stealing" from each other back and forth. Claude shipped Artifacts, so ChatGPT shipped Canvas. ChatGPT shipped Deep Research, then Claude shipped Research. Claude Code came out, and then Codex. Concepts within the apps like projects, memory, voice, connectors, computer control...take your pick of features, and you're bound to see the other one either has it or is about to. When OpenAI rolled out its new desktop "superapp" this summer, PCWorld's headline put it bluntly: "The new ChatGPT superapp takes aim at Claude Desktop." (ChatGPT even started naming their models using a theme, like Anthropic does, instead of the confusing names they had before.)

And there's more than just two players in the market. Microsoft has Copilot, Google has Gemini, and in the software coding space it gets even more crowded with the coding version of each of those plus Cursor, Windsurf, Amp, the list goes on.

Sure, I understand this is how business works. Apple's rivalry didn't stop with Microsoft, as years later it had Samsung in its sights from the iPhone vs Android fight. The cloud providers all do it too, with each of them having equivalent versions of products they've copied over the years. It's not even limited to software or technology, either. Long before any of this, there was Nike vs. Adidas, Ford and Ferrari, and the ever-present question: Coke or Pepsi? So it's nothing new, but it's noteworthy because of the moment we're in. (More on that later.)

But for all the sameness on the surface, like any tech, underneath the hood, no one can agree on much. For instance, there are so many places to put instruction files to tell an agent how to behave in your project: Claude Code reads CLAUDE.md, but GitHub Copilot reads .github/copilot-instructions.md, and Google even has GEMINI.md. Cursor has its own rules folder too. So of course the problem got solved in the most xkcd way possible: the AGENTS.md standard.

# So Which One Should You Use?

This is not a comparison piece, so I'm not going to get into details, but the answer to a question like that is usually: "it depends." For me, the landscape looks something like this:

  • Claude. At this point it's my default. I've found it to be the most reliable for all of the various things I do. I use it almost exclusively at work to write, code, and answer dumb questions. At home, it's helped me build complex spreadsheets, plan house projects, design web sites, and...answer dumb questions.
  • ChatGPT/Codex. The original. It got me started both at home and at work. Even when I started using Claude at work, I stuck with ChatGPT at home, thinking it would be a good split. I even used Codex for coding projects at home. Now I've migrated to using Claude most of the time, even at home. I've kept ChatGPT around mostly for historical purposes. It was sort of my pseudo-doctor/therapist well before Claude came around, so I still use it for that sometimes, since it "knows me."
  • GitHub Copilot. This is the other go-to option at work for me, and I like using it for coding work sometimes, if I've maxed out my Claude usage, or if it's annoying me. It can use both OpenAI and Anthropic models, or switch between them, and it will sometimes even decide for you, depending on the task. It's also got great integration with tools I already use.
  • Gemini. I experimented with Antigravity for a bit, and occasionally reach for Gemini within Google Docs or something. But I really haven't used Gemini much at work. I try to "search" (or ask those dumb questions) with AI, but I still end up Googling some things (old habits die hard), so I'll often end up using the AI Overview feature of Google and finding myself almost unwittingly inside of Gemini.

What are people using? Most everyone I know, at least in the consumer space, is pretty much sticking with the horse they rode in on and using ChatGPT for everything. My family mostly does that, but I've also converted a few friends and family over to the Claude side. (The government contract stuff helped.)

I know some folks swear by one choice for writing (ChatGPT) and another for images (Gemini). Lots of people are probably just using whatever their company pays for, or (like I sometimes do) whatever shows up at the top of Google. Some folks use one at work and a different one at home. I kind of do that too, except with two Claudes.

So how does anyone decide? Remember what Bill Gates said (in the movie): it doesn't really matter.

# The Model Is Only Part of the Story

Most AI conversations focus on the model, but the model is only one layer. The other is the harness: the software wrapped around the model that decides what context it sees, which tools it can use, how its work is structured, and when it stops.

That's where a lot of the variability lives. Remember all those instruction files? We write them carefully, spelling out which tool to use for which job. Sometimes the agent follows them perfectly, and sometimes it reads them, nods, and does something else. (Kind of like my kids.) It's tempting to blame the model, but often the harness is the one deciding how much weight those instructions get, or whether they're still in context at all. And when a new version drops (of the model or the harness), a workflow that was reliable at one point may all of a sudden behave totally differently.

This is something I'm seeing a lot of at work, as we try to steer agents to use the right tools for the job, and often find them colliding with other tools, or the instincts of the agent in general. But if anything, that's given me even more appreciation for deterministic tools that do exactly the same thing every time you run them. (Like the ones we build at Moderne, of course!)

# Who's Paying for All These Tokens?

The other thing that's happening right now is that the economics are completely upside down.

Most of us pay for AI like a gym membership: flat monthly fee, all you can eat, within limits. That means the heaviest users get the best deal, but "within limits" also keeps getting redefined. Five-hour windows, weekly caps, pricier plans...it all seems to be a slow slide toward paying per token. GitHub Copilot already moved to usage-based billing back in June because a quick chat question and a multi-hour autonomous coding session was potentially costing the same amount for the user.

And while it's true that the price of a token will continue to fall, agents are chewing through tokens at a faster and faster clip, so even if the gas is getting cheaper, it's like we're driving a bigger truck.

It reminds me of the cloud provider race-to-zero pricing from the early 2010s. I don't know how this ends and if we'll settle into something more sane, or if it just keeps getting cheaper and cheaper while we keep using more and more?

# Paper First

I recently had back-to-school night for my daughter's high school, and one of the teachers told us that all writing for his class happens in the room and on paper. No homework, no laptops.

At first that sounded insane to me. No laptops? It's 2026! And we can't ignore AI. It's here!

But his explanation made sense to me. He's not anti-AI. In fact he thinks there's a place for these tools and that his students will use them. He just doesn't think kids at this age are ready to use them responsibly yet, and more importantly, they need to build the underlying skill first. You can't tell whether AI wrote something good if you've never learned what good looks like. And that applies to the rest of us too.

It's the same conversation engineering teams are having about junior and senior developers in the age of AI. A senior engineer can look at what an agent produced and spot the problem fast, because they've made that mistake before. A junior engineer might not see it at all. I notice this in my own work. When an agent's draft of a doc is off, I can usually tell how and guide it a different way or change it myself. When it writes Java, though, I'm a lot less sure, because it's been a long time since I was a real software engineer. (My skill level for coding is good for prototypes, but not so much production-ready code.)

# Which Movie Are We In?

I get why this feels existential for a lot of people. Bill Gates (the real one, not Anthony Michael Hall) just published a long essay about it, and it isn't exactly reassuring. He writes that AI "could stunt our kids' development and replace human relationships," that the jobs most at risk are entry- and mid-level, and that even under the best circumstances, this will be "one of the most turbulent times in human history." (Turns out, maybe it does matter?)

It's not a perfect analogy, but the current moment reminds me a bit of the rise of the internet. Email changed how we worked, and the web changed the concept of what a business even was. But Gates argues that this is different from past technology shifts, because it substitutes for human thinking itself and it's happening over a decade instead of generations.

So is this really a Pirates of Silicon Valley story, or is it more the AI version of The Social Reckoning? As a big Aaron Sorkin fan, I'm excited about that movie coming out, but less excited about the fact that it's based on a true story. Maybe it's not so much Mac vs. Windows after all, because the question isn't "who's going to win?" so much as "do we all lose?"

I don't know which movie we're in yet. It's probably too soon to say. Either way, AI is here, so there's no ignoring it. AI apps will continue looking more and more like each other, the features will keep leapfrogging, and which logo you align with will matter less than whether you recognize good output when you see it. Whichever one we use, we have to learn to write on paper first.


My Kind of Type

A favorite joke of mine that I remember from the wall of my computer lab in college goes "There are 10 types of people in this world: those who understand binary, and those who don't." (Get it? "10" in binary is 2. Okay, moving on.) Of course, there are many more types of people than that. (It's just a joke.) There are also many more than two types of types. Blood type. Type A personality. Type 1 diabetes. "He's not really my type." Dog people or cat people. Coffee or tea. Types upon types, but really they all just come down to the simple question: what kind of thing is this?

In software development, we learn early on that "type" means something very specific — a data type. Most people have heard of string and integer, and maybe they know about float and boolean. But you can also make up your own kind of types: ShoppingCart, BlogPost, Dinosaur. You get the picture.

For you non-developers out there, you might be surprised to find that in programming circles, the topic of "types" can sometimes come with strong opinions. Just how strict you should be about types is one of those things that can really get people going. Think tabs and spaces, or text editor holy wars. To everyone outside of tech, this sounds like nonsense. When my wife and kids ask me at the dinner table "what do you actually do, Dad?" and I try to explain the importance of types, they stare at me blankly. So this post is really for them, but maybe you'll learn something too.

I'll try to explain it by using a trick that a colleague once taught me: the "Five Whys." Like a toddler, you just keep asking "but why?" until you hit the bottom of something. So we'll start simple and go a little deeper at each step. Stay with me now...

# Why do we have types?

A type is just a label for what kind of thing a piece of data is: a number, a word, a date. Some programming languages make you label everything, while others let you skip it. To see why that matters, think about the difference between cooking and baking. (See, girls? We're starting with food. You're going to be fine.)

When you're sautéing something, you can wing it with a pinch of salt, a glug of oil, a handful of whatever's in the fridge. This is how my wife cooks: fast, furious, and leaves a trail of bowls, utensils, and a countertop mess in her wake.

My wife in the kitchen

That's like JavaScript, a "loosely typed" language. You can put anything anywhere, and it'll even let you add the number 5 to the word "banana." Instead of stopping you, it happily hands back "5banana" like it did you a favor.

Baking is a different story, though, because baking is chemistry. The wrong amount or a missing ingredient, and your bread doesn't rise or your cake is a brick, and you won't know until it's done and too late to fix. This is more my style of cooking: measure everything, read the whole recipe first, lay it all out before I start. I'm slower, and it's less exciting, but at least I know what I'm going to get.

That's more Java, "strictly typed." You declare what kind of thing goes where, up front, and the language holds you to it before it will even compile.

The tradeoff is real, and it's the same one my wife and I negotiate over when cooking dinner. Winging it is faster and easier sometimes, right up until the moment precision actually matters. With types, you catch your mistake during prep, but without them, you don't catch it until you open the oven, which, in software, means production.

(Because it confuses so many people I talk to, I have to just quickly clarify that Java and JavaScript are not the same thing. In fact, they're not even related. JavaScript just borrowed the name to ride Java's popularity back in the '90s, and we've been correcting people about it ever since.)

# Why would anyone care?

I sort of gave this away already, but the reason this matters is that types let you catch your mistake before anyone else does.

Years ago, as a product manager, the engineering team came to me to declare that they would be migrating our JavaScript codebase to TypeScript (a flavor of JavaScript that is indeed typed). This would take up half of our next several sprints, so I wasn't thrilled about it. It was that situation where you have to spend potentially months of engineering time that would produce exactly zero things you can put on a roadmap slide. (See: technical debt.)

But I did understand why they wanted to migrate. Without types, the only way to know if we'd broken something was to run the code and wait to find out. But with them, the compiler would tell us before ever shipping. And sure enough, it saved us several times down the line, when a problem got caught in code review instead of turning into a customer issue.

It's all those times that someone changes something small and deep in the codebase, the kind of change that quietly ripples out and touches things all over the place. The moment they make the change in a typed system, the code lights up and points you to every single spot that broke.

So that's what those months actually bought us: fewer bugs, and the ability to know things about the code without having to run it first.

# Why isn't just knowing the type enough?

During the COVID years, I jumped on the sourdough bread bandwagon (like so many). It didn't last long because my patience ran thin, but while I was doing it, I learned that not all flour is created equal. All-purpose flour is not bread flour is not cake flour, etc. With sourdough bread, the bread flour was superior. All-purpose might work, but it never came out as good because when you're baking, knowing which flour matters.

One of my few semi-successful loaves

Okay, so I'm stretching this metaphor a bit, but I'm trying to extend it to help explain type attribution. This is when you have to work out all of the specific types within your code. Developers have long done a version of this by hand using their code editor, where they can easily click on any object and jump straight to where it came from. They can follow the trail back through each file until they find where something was really born. That "click to follow the path" trick only works because the tool has quietly worked out what everything actually is. That's type attribution.

Remember all those types of types? This is where they can come back to bite you. You might have two different Customer types that share the exact same name but have nothing to do with each other. One might be a custom version that an internal team wrote, and the other may have been pulled in from some library. Attribution is the work of pinning down which Customer this actually is, where it was defined, and what it connects to. Now multiply that across millions of lines of code, and you've got a genuinely hard problem. (Are you still with me now? Hang in there.)

So why bother? Say you want to find every place in a giant codebase that handles sensitive data. You could just search for a word, the way you'd hit Ctrl+F in a document. But plain text search has no idea what anything means. Search for "log" and you'll get tons of hits (comments, typos, blogs, log in) but not all of them are what you're looking for. But with real attribution, you can find every place that a specific and exact kind of sensitive data flows into a specific and exact logging tool, and get back just those results. Types turn a codebase from a pile of text into something you can actually ask questions of.

# Why aren't they all my types?

No cook grows their own wheat or churns their own butter. They buy ingredients that somebody else made and then assemble them. Software works the same way. If you're picturing someone building an application by typing out all of the code, that's not quite what happens. (Especially not anymore with coding agents.) Modern software development is maybe 5–10% custom code that you actually write, and 90–95% code other people wrote and open-sourced (gave away for free).

One of my favorite xkcd comics: "Dependency" by Randall Munroe, xkcd.com (CC BY-NC 2.5)

That borrowed code has a name — dependencies — and they're the pre-made ingredients of software. Nobody writes their own code for the well-solved stuff anymore, like talking to a database or handling dates or doing encryption. And just like those store-bought ingredients for cooking, they're made up of ingredients of their own. Bread came from flour, which came from a mill, which bought wheat from a farm. A typical project pulls in dozens of libraries directly, and then those quietly pull in hundreds more underneath. (We call those transitive dependencies.)

It's a daunting task to track our food's supply chain, and it's the same with interconnected systems. We take our food for granted, and many developers take their dependencies for granted too. Understanding your code now means understanding everyone else's code too.

# Why does any of this matter?

Types tell you what everything is and dependencies tell you where it came from. When you put them together, you've got a sort of digital master cookbook, with every dish listed out, every ingredient included, and every source traced back to the shelf it came from.

And once you have a cookbook like that, you can do things that are otherwise impossible, like swapping an ingredient across ten thousand recipes at once, or finding every dish that used a batch that just got recalled, instead of opening jars one by one and hoping. Remember, we're talking about every kitchen and meal all at once. (That's called scale.)

So, it took quite a long build up and a lot of stretched analogies to get here, but at last, maybe my family will understand a little bit of what I actually do all day. I work with a tool called OpenRewrite which runs on something called recipes. (There's the payoff for that overused metaphor.) An OpenRewrite recipe is a little set of instructions that reaches into all that code and makes a change: find this, upgrade that, replace those, fix this one bug everywhere it appears. The only reason a recipe can do that safely, across the millions of lines of code in enterprise customer environments, is that it isn't just reading the code as text, it's working from the cookbook. (We call it the Lossless Semantic Tree, or LST). It knows the types, it knows the dependencies, and it knows what every ingredient is and where it came from. You could say, it measures before it bakes. Just like I like to do. So now maybe the next time someone asks my girls what their Dad does all day, they can say I help computers cook.