Click the Subscribe button to sign up for regular insights on doing AI initiatives right.
Agents demystified
Don't you hate it when someone tries to make you feel stupid by wrapping a simple concept in layers of manufactured complexity?
Case in point these days: AI Agents. Oh, Large Language Models (LLMs) are so 2024. But 2025 is the year of agents. Agentic AI this, Agentic AI that. You better sign up for all these Gartner webinars or, better yet, pay a million bucks to Accenture to build you a custom proof-of-concept project (true story). Don't miss out, or they'll be coming for you and your business!
Here, I lay out the simple logical steps that take you from an LLM to an Agent:
Step 0: The LLM as a chat bot
That's the ChatGPT and co we all know. We type in our query and get an answer back.
Step 1: Integration: Calling the LLM from another program
My to-do app has a feature that takes a large task and uses generative AI to break it down into smaller steps. Behind the scenes, the to-do app just posts a well-crafted question to the LLM and uses the answer to provide that functionality.
Step 2: Workflows
Like step 1, but with more complexity in the control logic, and with more than one call to the LLM involved. Includes examples like:
Using one call to an LLM with one set of instructions to create some output and using another call with another set of instructions to critique or improve that output
Posing the same question to multiple LLMs, then aggregating their responses
Asking one LLM to break down a larger query into multiple steps, then feeding those steps to specialist LLMs
Step 3: Agents
In the previous step, we hard-coded the control logic. In this step, we hand the reins over to the LLM. In addition, we provide access to tools:
An extra layer around the LLM checks its output for special commands where the LLM says that it wants to do something, like search the web, check something in your database, or run some code.
Part of the prompt involves telling the LLM what tools it has access to and how it should invoke them.
Then you just let it do its thing.
And that's the whole secret. Let's end with a quote from the excellent article by Anthropic on Building effective agents, because it fits so well with our general theme of simplicity:
Consistently, the most successful implementations weren't using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns.
AI content and fake hair
“All toupées look fake; I’ve never seen one that I couldn’t tell was fake.”
This is the Toupée Fallacy, and I was reminded of it by the endless stream of social media posts that want to teach you how to spot AI-generated content:
Watch out for fancy punctuation—like the em-dash. Who even writes like this?
Suspicious words: Let's rather not delve into those.
🚀 Too 👏 many 💠 emojis.
However, the biggest tell of bad AI-generated content is that it's so bland and formulaic.
But if someone were to use AI to
brainstorm
critique
point out gaps
suggest additional examples
iteratively edit their writing
and then incorporates that feedback in their own words, you could never tell that they used AI. It would be like figuring out if I used a calculator when answering 12 x 12 = 144.
Shouldn't we instead focus on quality? The main problem with lazily generated AI content is that it is bland, generic, and tepid. But so is lots of 100% free-range human-created content.
If a text is genuinely inspiring and insightful, and the author crafted it with the help of AI, all the power to them. Isn't a significant promise of generative AI that it elevates our creative powers?
I'd be curious to hear if you've had particularly bad (or awesome) experiences with AI-generated content.
Disfluency
In last week's post about the Underpant Gnomes, one example point was
"Connect your documents and data to an AI chatbot so you can talk to your data."
For example, you could ask your AI, "Hey, what were last quarter's sales numbers in Europe?" and get a nice report without manual clicking and digging. This seems like an obvious use case for Generative AI. Why wouldn't you want to make your data more accessible?
Because easier isn't always better. In Smarter, Faster, Better, Charles Duhigg writes about a concept he calls disfluency:
Sometimes, deep insights can only develop if you have to wrestle with the data. He gives the example of teachers who had access to all sorts of fancy dashboards about student performance. It wasn't until they ditched all that for handwritten notes on stacks of index cards that they made important discoveries about how to help each student.
To use AI to its fullest potential, we'll want to dig deeper and think beyond using it to make access to raw information easier and instead use it to generate insight:
Don't just dig up numbers for me that I could easily dig up myself. Tell me what I'm missing!
Don't just summarize a document. Tell me what's actionable.
Don't just list customer complaints. Identify trends and suggest fixes to improve satisfaction.
Don't just extract key metrics from reports. Flag emerging patterns that signal future opportunities or risks.
Don't just compile meeting notes. Highlight unresolved issues and recommend next steps for resolution.
Figuring out how to connect the raw information to the actual insight is the crucial Phase 2 in using AI productively.
What’s your Phase 2?
Season 2, Episode 17 of the animated TV Series South Park introduces us to the Underpants Gnomes. At night, they sneak into children's bedrooms and steal their underpants. Eventually, they are confronted by the kids, who want to know what the gnomes do with all those underpants.
Their explanation has become pop culture history:
Phase 1 - Collect underpants
Phase 2 - ???
Phase 3 - Profit
Those silly gnomes. But it serves us well to remember that the temptation to gloss over the details, that pesky Phase 2, is all too strong. We assume that a certain input activity should eventually lead to profit (or other good things).
Replace phase 1 with any of the following, and it's all too common that our mind leaps straight to phase 3.
Build a shiny mobile app.
Hire the "best" people.
Publish a thought leadership article.
Invest in the latest AI tools.
Launch a social media campaign.
Raise venture capital.
Connect your documents and data to an AI chatbot so you can talk to your data.
What's your Phase 2
To be fair, the examples above make more sense than collecting underpants. There is probably a way to profit with a great team, a great product, lots of resources, etc. It's just that you still have to do the strategic work to connect those inputs to the desired outcome.
Ask yourself: What's my phase 2?
AI approaches for the data tiers
In the previous post, we looked at the five tiers of data for AI, and now we'll see an interesting tradeoff:
Data in the top tier (structured data) works with just about any ML an AI model.
Data in the fourth tier (just one step above physical paper) will only work with fancy "multi-modal" (that is, text and vision) models.
The decision we have to make is:
Do we use complex data transformations to move our data to a higher tier so that we can use a simpler ML model?
Or do we keep our transformations simple so that we can throw a more complex model at it?
Modern multi-modal models (GPT-4o, for example, or Gemini 2.0) can take in a PDF, even with images, and extract a surprising amount of information. Still, the results are less predictable and guaranteed than if you had a more purpose-built extraction pipeline that would let you use a specialized ML model (or no ML model at all, which would be great for cost and reproducibility).
Some guidelines around making this choice:
Do a bit of prototyping and experimentation directly on the low-tier, raw data. How far can you push GPT, Gemini, etc?
How crucial is it that nothing gets missed? Are we looking for the general gist, or do we need to look for information line by line? The latter might require getting down and dirty with the data.
How far is the lift from the current to the desired tier? Going from a Word doc to a fully structured format is more manageable than going from a scanned PDF to a semi-structured document.
In the spirit of growing a complex system from small seeds the easiest way to get a functioning end-to-end system off the ground might indeed involve feeding your low-tier data into a top-shelf AI model. Then, once you can observe it in production, you can slowly add transformation steps that improve your data quality.
If you're currently wrestling with your data pipeline and your systems, we'd love to hear from you! What have you tried, what has and hasn't worked?
The 5 tiers of data for AI
The last few posts were a bit more philosophical, so let's get nitty and gritty.
Say you have an idea for solving a problem related to processing documents, and from our AI Checklist, you found that AI should be a good fit. What's next? Next comes the data engineering part, data science's under-appreciated cousin.
The data readiness model
Your options and approach depend very much on the format that your data exists in.
Tier 5: Physical paper
True story: At a previous employer, a client wanted to explore whether quantum computing could help his business run more effectively. When asked about the existing process (to have a baseline against which to compare), it was revealed that everything ran on paper. That is one hard lift! Before you can even begin to use AI, you need to have your data in digital form. Some services will digitize your paper documents for you, but if your business runs on paper and keeps generating more of it, that whole process needs to get digitized first with a modern workflow.
Tier 4: Scanned PDFs
If your documents are available in some scanned format, that's better than nothing, but unless the actual data we're interested in is an image, we need to get our hands on the text that's contained in the document. Optical Character Recognition (OCR) has been around for a while, so this isn't a dramatically hard lift, but it leads us to the next challenge.
Tier 3: Text-first PDFs
These PDFs are what you get if you export, say, a Word document to PDF, or apply OCR to a scanned PDF: The text you see on the screen is also represented, as text, in the document. That sounds good, but there's a catch: The PDF format only knows layout and formatting, with no concept of structure and semantics. This is mildly annoying when you want to extract the main body of text and pesky footers such as "Page 23" get mixed in, but it becomes a real pain when dealing with tables. A PDF doc will just say, "Okay, put some text here, put this other text here, put some vertical lines here and there."
Tier 2: Word documents (aka semi-structured)
Finally, we're dealing with structured text formats. You can ask for the document's paragraphs and not get a garbled mess. It might even include information such as "This here is a top-level heading" and "This here is a subheading", which may be relevant for your AI tool. I call them semi-structured because there's no clear separation between content semantics and content layout/styling, but at least we can readily extract the data that's there.
Tier 1: Fully structured content
The gold standard for any ML and AI application would be any format that is semantics first or otherwise highly structured.
Relational (SQL) databases
CSV files or Excel sheets
Structured document formats such as JSON or XML (as long as the keys or tags provide useful structuring information), possibly returned by an API.
NoSQL databases (MongoDB, Cassandra, etc), as long as the data is structured appropriately
Much of data engineering is about getting your data, no matter where and in what form it's coming from, to one of these formats so that any downstream application doesn't have to worry about the messiness of the lower tiers.
In a future post, we'll see how current AI models fare with the various tiers, and the tradeoffs involved in moving between the tiers versus using models that can deal with the lower tiers.
Exponential Shrinking
In Computer Science, we classify problems based on the relationship between input size and program runtime.
Maybe doubling the input size doubles the runtime. That's a linear problem and considered easy.
But maybe adding just a single item to the input already doubles the runtime. That's an exponential problem and considered hard.
A quick example
Just so we have something concrete to talk about, imagine a problem where the input is a bunch of items, and you need to find the best combination of items (with some measure of what good and best mean)
For one item, we either pick it or we don't, so that's two choices to evaluate.
For two items, we can pick neither, both, one, or the other for four choices.
Each additional item doubles the number of choices.
For 10 items, we're already at 1024 choices.
For 20 items, we're at over a million.
For 100 items, we've got a one with thirty zeros.
Look at the reverse!
The standard way of looking at exponential problems is pessimistic: Woe to us! Any little addition to the input makes the problem so much harder! How can we possibly cope?
But look at it the other way round: With exponential problems, each time you take an item off the table, you cut the problem in half. In other words, it's the complex problems where simplifying things gives you the most bang for your buck. Whereas with a linear problem, you only get a 1:1 return on your simplification efforts, with exponential problems, you get an exponential return.
Concrete Applications
Code Review – Performing ten reviews of a hundred lines of code each is drastically easier than performing one review of a thousand lines of code.
Machine Learning – Reducing a dataset by filtering out low-impact features can make training a machine learning model exponentially faster.
Team Size – Splitting a large team into smaller, autonomous units cuts coordination overhead dramatically.
Company Growth – Empowering smaller decision-making groups prevents bureaucracy from scaling out of control.
Processes – Removing a single key bottleneck can halve the complexity of an entire workflow.
Product Focus – Trimming unnecessary offerings simplifies operations and reduces decision fatigue for customers.
I'd love to hear if you've seen this principle in action in your line of work! Reply to this email and let me know.
Burn and Scrape
Picture Gordon Ramsay in "Kitchen Nightmares", visiting a struggling diner to help turn it around. As he gets a tour of the premises, the owner explains: "Here's our breakfast station. This is where we toast the bread, and here's where we scrape it."
Ramsay is puzzled: "Scrape?"
"Yeah, you know how toast always has this black, burnt layer? Before we can serve it, we have to scrape that off."
"...well, obviously we have to get rid of the scraping step!"
"Are you crazy? We can't serve burnt toast!"
Here are two quick takeaways:
1. Quality assurance cannot be an afterthought; it must be integrated into the process from the beginning.
2. To simplify a system, consider which components exist solely to address issues that shouldn’t be occurring in the first place.
Complex Systems Come From Simple Systems
A common thread in the last few posts could be the saying, "Simplicity is the ultimate sophistication." Whether it's the tech stack, approach to project management, or AI model development, keeping it simple (but not simplistic) is the key to success.
But of course, not everything can stay simple forever. If the underlying problem that we try to solve is complex, i.e., intrinsic complexity is high, our solution might have to be complex as well. Enter Gall's Law.
“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. ”
Fifty years ago, as of today, there are the seeds of Agile (Minimum Viable Product!), Lean Startup, Evolutionary Design, and many more related ideas.
Simple and Working
Let's dwell on one nuance of this quote: ...a simple system that worked. It is not enough to break a larger design down into individual components, get those individual components to work, and then reassemble them in hopes that the total system will work. That way lies the despair of last-minute integration issues, or, in the case of the Mars Climate Orbiter, total failure.
The point of evolving a complex system out of a simple system is to have a simple system that is fully realized and stand-alone:
A simple web app should have frontend and backend, as well as infrastructure, no matter how minimal the functionality.
A simple product should completely solve a customer problem (see Jason Cohen's article on Simple, Loveable, Complete).
A simple team process should align priorities, even if it’s just a shared Google Doc, before implementing a full-fledged agile framework.
A simple AI model should deliver useful predictions, even if it’s just a rule-based system, before adding deep learning or fine-tuning.
New Vs Improved
Do you love shiny new things? So do I. I'm always excited trying out new tools, IDEs, plugins, frameworks, languages. And often, there is a clear value add by going from an old model to a new one.
But sometimes, evolution isn't as straightforward. Let's look at examples!
Databases
NoSQL databases like MongoDB, Cassandra, and Redis are evolutions of relational databases like MySQL or PostgreSQL. But that does not mean you should use MongoDB as a drop-in replacement for all your database needs. NoSQL databases are vastly superior to relational databases in the use cases they were meant to cover, and vastly inferior in those they weren't.
Web frameworks
Single-page application (SPA) frameworks like React were developed to manage complex client-side states while decreasing network traffic. They are more modern than template-based web frameworks that send HTML back and forth from a server, like Django, and have become the de-facto standard for most frontend devs. "Nobody ever got fired for picking React", as they say. But for applications that don't need to track complex client-side states, HTML with a bit of JavaScript sprinkled in would turn out completely fine, at much lower complexity.
AI models
It all started with basic statistics...
Then we got machine-learning models like
logistic regression
support vector machines
k-means clustering etc.
Then we got deep neural networks (NNs) with varying architectures:
Multi-layer perceptrons for generic data
Convolutional NNs for image recognition
Recurrent NNs for analyzing sequences (like text, or time-series data)
The mighty transformers that turned out much better at dealing with sequences, though they still needed to be special-purpose trained on the task at hand
And finally, we made the transformers and the training sets we exposed them to so incredibly large that we got our Large Language Models (LLMs) with incredibly general capabilities. The same model will write you a poem about your cat, explain a section of the tax code in plain English, or write you some Python code.
Still, an LLM should not be thought of as the default go-to just because it is the largest, most powerful model. In fact, the question should always be: What's the least complex, least advanced, plain simplest thing we can throw at our problem that might actually work?
Further Reading
AI as Taste Multiplier
Here's another mental model I found helpful when engaging with AI: You use your taste and discernment to guide its generation while letting the AI do the grunt work of filling in the blanks.
The AI can churn out lots of content far quicker than you can type. But, if left to its own devices, that content will be bland, generic, and useless. This is most painfully obvious with jokes:
Oh, ChatGPT. You tried.
Come on, ChatGPT. What does that even mean? Instead, let's lean into our sentiment and taste. Without getting too political, the situation is somewhat absurd. I'm thinking John Oliver would probably have some good lines about it:
That's better.
In further iterations, we could tell it to make it even snarkier, and that it's not about giving away free stuff, really. What matters though is that we have a human in the loop guiding the general direction with their good taste.
What's great about this way of working is that it lets you, as the driver, stay at a higher level of thinking without getting distracted by the lower-level task of typing it all out. And in the case of image generation, you might not even have that underlying skill in the first place.
AI is levelling the playing field in terms of creation, and so the importance of knowing what "good" looks like has skyrocketed.
AI - Your Overeager Intern
Some developers love AI Coding Assistants. Others find them useless. Other professions may experience the same split. Why is that, and what can it teach us?
What's bad
Most complaints about AI tools for coding revolve around a few common themes.
Hallucinations. The AI might suggest using a library that doesn't exist.
Bugs due to improperly handled edge cases.
AI forging ahead but misunderstanding the task, not aligning with the context or overarching guidelines
What's good
Fans of AI tools find that it's great at
Writing unit tests from a high-level specification
Creating small incremental functionality that satisfies a given test
Filling in gaps in
The secret
Current AI assistants fail when the initial ask is too large. That's when they start hallucinating libraries, going off the deep end for some rabbit hole, or committing some very basic mistakes. They shine when given small, clearly defined, asks, like writing a single unit test, or creating a small piece of functionality.
In short: To get AI coders to produce good code, you do the same thing you'd do to get a human coder to produce good code:
Break down features into small, incremental steps.
Cycle back and forth between tests and code that makes the test pass.
AI as the overeager intern
AI coding tools have been likened to "over-eager junior programmers who can type fast." It's a simplification, but it gives us a good mental handle on how to get the most out of our AI tools:
How would we delegate this task to a generally capable junior employee who might need a few guard rails so they stay on track?
Marketing – Instead of asking AI to "write a full campaign strategy," prompt it to "draft three headline variations for a product launch post targeting tech enthusiasts."
Legal – Instead of asking AI to "draft a full contract," guide it with "generate a confidentiality clause for a partnership agreement between two tech startups."
Product Design – Instead of asking AI to "design a full mobile app UI," prompt it to "generate three layout ideas for a login screen with a modern, minimal aesthetic."
Anti-tradeoffs
Engineering is full of tradeoffs.
Rust is more performant than Python but also more complex.
A large language model is more powerful than a small, special-purpose one but costs more to host and run.
A single-page application (SPA) has nicer interactivity than a static website but has longer load times and is harder to maintain.
This is so pervasive that we often assume tradeoffs even in cases where there are none. For example:
Quality vs Speed
Writing shoddy software is faster than writing good software. At first. There comes a point, very soon, where the poorly constructed code will slow down any future development. A great article exploring this in more depth can be found here. The only way to go sustainably fast for a long period is to invest in quality. Good design, frequent refactoring, and solid test coverage. As the Navy SEALS say, "Slow is smooth and smooth is fast".
Speed vs Stability
Just as rushing the development process in hopes of gaining speed is doomed to fail, so is throttling the release process in hopes of guaranteeing quality. Here's a quote from Luca Rossi's Substack newsletter, Refactoring:
The counterintuitive truth is that, in software, there is no trade-off between speed and stability.
In fact, speed creates a virtuous cycle:
Fast releases → allow for frequent releases
Frequent releases → allow for small releases
Small + fast releases → create lower risk and faster recovery from mistakes.
Team Size vs Impact
Adding manpower to a late software project makes it later. — Brook's Law
The reasons cited for this (slightly simplified) law are
Communication overhead
Ramp up time
Indivisibility of many tasks
The converse of the law, then, is that small teams can deliver faster and with higher impact than large teams because they avoid overhead, hand-overs, and coordination as long as they actually possess the capabilities required by the project.
Many large companies have realized this and shifted their organization to loosely coupled groups of small, competent teams, with OpenAI among them.
Final thoughts
There are bound to be many more such anti-tradeoffs in the world, where common wisdom or first appearances suggest a tradeoff when, in reality, there exists synergy. In other instances, we could engineer things to transform a tradeoff into a synergy. A quick example that comes to mind is that a password manager enhances both security and convenience. The next time you face an either-or decision, consider why it can't be both!
“Can we take a step back here?”
A colleague once brought in this gem of a book, 100 Tricks to Appear Smart in Meetings, poking fun at business speak and meeting habits. They're spot on for the most part, but this one has always irked me:
Now, I don't know about you, but I have seen countless situations where that question was sorely missing from the conversation. We have a bias to jumping right into actions, solutions, and activities when it wouldn't hurt to first articulate the desired outcome:
Job postings going out and candidates being interviewed without anyone articulating what the desired outcome of the hire would be
Splashy business initiatives fizzling out because it was never articulated what they were supposed to achieve.
The dreaded reorg to "shake things up"
Great technological undertakings (migrations, rewrites) wasting time and not moving any business-relevant needle
Don't just do something; stand there
For a great breakdown of the right way to plan a project versus the typical way, here is David Allen, author of Getting Things Done, giving a TED Talk about Natural versus Unnatural Planning
Ideally, of course, you’d ask that question right at the beginning, and not after much time has already been wasted.
On ChatGPT Wrappers
While we're on the topic of GenAI use cases, let's talk about wrappers.
As soon as ChatGPT was released, builders started making tools that did nothing else under the hood than passing a user request through to ChatGPT and producing the answer back to the user, maybe with a bit of prompt engineering in the middle.
These tools faced much derision from software engineers ("what are you even doing?") and investors ("what's your moat?") alike. The messaging: If you're not doing anything fancy under the hood, or even training your own model from scratch, get out of here!
But as we've seen before, we shouldn't care about the fancy stuff. Instead, we want to know if an actual problem is being solved.
Bad wrappers
Anything I can replicate directly with minimal effort in ChatGPT or Claude's chat interface would make for a lousy product. I may need to use features like custom instructions or think carefully about the way I prompt the model, but those are solvable problems.
You don't need a special Professional Email tool, you just ask ChatGPT to "Make it sound professional."
You don't need a special Legalese-to-Plain-English tool, you just ask ChatGPT to "Explain this legal document like I'm a normal person."
Tools like that are not more than an attempt at a quick cash grab and indeed deserve the scorn of developers, investors, and users.
Good wrappers
These provide seamless integration and specialized interfaces to help you achieve a task:
Maybe the prompt itself is straightforward, but it would be an unreasonable disruption to your workflow to open a chat window for it.
The underlying AI output could be part of the inner workings of a larger workflow.
Just like with any other technology, a good app would have all the relevant integrations into an existing system.
The amount of extra domain knowledge and context is not easily available to me as a non-expert.
I was inspired by something like https://sommelier.bot (no affiliation) which, on the GenAI side, is not much more than a wrapper around ChatGPT. However, because it integrates into each vendor's own product database and inventory and has been fine-tuned with language around wine recommendations, it works in a way that I cannot simply replicate by going straight to ChatGPT.
This makes it a unified tool that solves an actual pain point and it just so happens that generative AI is the underlying enabling technology.
A question for you
Have you come across a remarkable example of a tool that uses generative AI under the hood? Hit reply and let us know!
Where new tech fits in, and the GenAI use case checklist
If Press-Release Driven Development based purely on hype is not the way to go, what does a sensible approach to exciting new tech look like? A shortcut for thinking about GenAI uses cases comes at the bottom of this post, but first, some background.
If you look around your organization, you will no doubt find a whole bunch of problems. Things you'd like to be different. For each problem, answer this: Why hasn't it already been solved? Why is it still a problem?
Most of your answers will have nothing to do with tech.
It's not that much of a pain.
There's no political will to tackle this issue / it would step on someone's toes
We don't trust that a technological solution would actually stick.
For those problems, once the non-technical objections have been removed, the technical solution is often quite simple.
In some cases, the answer might be:
We looked into it and found it costs too much to solve the problem.
In a very few select cases, the answer might be:
It's just not technologically possible right now.
These last two answers are good pointers for problems where new technology can make a difference. It might lower the cost of solving a problem compared to previous tech or enable solving the problem in the first place.
Example with GenAI
Generative AI and large language models (LLMs) are exciting because they plausibly promise to address both the cost and feasibility issues. It is (often) cheaper to run inference on a well-prompted LLM than to perform custom training on a concrete model, and for some tasks, it's the only way to solve them at the required level.
The GenAI use case checklist:
Is it beyond simple rules-based automation or pattern recognition?
Does it require an understanding of non-standardized input material?
⚠️ Does it not require expert-level taste and judgment?
These three criteria put the LLM right in the middle of a spectrum between a standard computer program (or classical machine learning) on one side and a human expert on the other side:
If you can get away with the simpler program, this is absolutely the way to go. It will be cheaper to run and more reliable, too.
If you absolutely need an expert's judgment, offloading it to an LLM will come with nasty surprises.
For those problems that fall into the middle, absolutely go ahead and give GenAI a try. Or talk to us and we’ll try it with you!
Beware Press-Release-Driven Development
Software developers are big on what's driving development. We have all sorts of DDs:
TDD: Test-Driven Development
BDD: Behaviour-Driven Development
DDD: Domain-Driven Development
There's also Resume-Driven Development, in which an engineer absolutely, positively, and vehemently insists that the system must be rewritten in the latest framework or language, mostly because it will help them land a better job.
The company-wide version of that is Press-Release Driven Development. Does your project really need quantum computing, blockchain, augmented reality or generative AI, or are you just doing it because it will make you and your company look cool?
It's fantastic that companies want to explore how emerging technologies can help their businesses. However, that exploration must be evaluated against real business problems, not vice versa. The problem statement must come first; otherwise, you will endlessly chase the latest fad.
There's a good chance new technology, especially AI, can help your business in amazing ways, but those might be non-obvious and rather subtle, and you can only uncover them if you start from the actual pain you are trying to solve, rather than a shiny piece of tech. Do you know what's cooler than GenAI and the Metaverse combined? Solving a problem people care about!
To keep it simple: Ask yourself if you'd still do the thing if you couldn't tell anybody about what's under the hood. If yes, chances are you are focused on the problem!
Balancing complexity
Everything should be made as simple as possible, but not simpler -- Albert Einstein.
Jumping off our discussion of tools, a critical job of our tools is to reduce our cognitive load, which is just a fancy way of saying that they should make our lives easier.
You might think, "Well, duh." But we often tolerate tools that don't live up to their promises: You know exactly what you want to do, but here you are, fighting the shell, the AWS Console, or Rust's borrow checker.
What's happening here is a mismatch between two types of complexity: Intrinsic versus extrinsic.
Intrinsic complexity is the complexity inherent to the problem. When you have made everything as simple as possible, but not simpler, this is what remains.
Extrinsic complexity is the complexity of everything else: The complexity of the tools you use to tackle the problem, the complexity of the language used to describe the problem or communicate the solution, and so on.
Our goal in designing almost everything is to reduce extrinsic complexity to zero, and this is where good tools can make all the difference!
The two ways it can go wrong
Einstein's quote at the top hints at two ways we can go wrong:
We didn't make it as simple as possible because we used an approach that was too complex for the problem:
React/Next for a simple landing page.
Microservice architecture for an internal tool with a low load and only two maintainers.
Scaled Agile Framework (SAFE) for... just about anything 🤷♂️.
We made it simpler than possible:
Hand-rolled HTML, CSS, and VanillaJS for a large SaaS product.
Non-containerized monolith on an EC2 instance for a high-load application with many moving parts.
Rock-and-roll, no-structure team approach for a project with many interlocking dependencies.
Why one or the other of these happens and how to spot and avoid it will be a story for another day.
When it goes right
It feels almost magical when the complexity of your approach matches that of the problem. Anything superfluous melts away and lets the underlying issues crystallize. With no other distractions pulling at your mind, the solution is then much more attainable.
Let's end with another quote which perfectly encapsulates what good design in software, AI, projects, teams etc really means:
Simplicity is the ultimate sophistication -- Leonardo DaVinci
It IS the tools
Last time, we observed that minor differences, no matter how fiercely debated, have little to do with a project's success or failure.
But it's indisputable that tools make a tremendous difference in productivity, developer experience, and, because of that, project outcome. So what's going on?
No tool will fix a broken strategy, but the right tool within your chosen strategy can amplify momentum when things are going well. Look for tools that
reduce friction
lighten the cognitive load
preserve optionality
Let's talk about the first one today.
Fast is better than slow.
Friction is the silent killer of projects, a death by a thousand paper cuts. Prioritize tools that do the same thing but faster, with fewer context switches and minimal setup. These tools might cost more upfront, but the savings in avoided mistakes and reclaimed time often outweigh the price tag.
This principle applies across every phase of a project:
Your IDE should make finding what you need quick and seamless.
Your test/build pipeline: The faster it runs, the less likely you lose focus or momentum while waiting for results.
Your code review process: Keep it swift. Bottlenecks from slow reviews can kill progress. Better yet, use non-blocking reviews whenever possible.
Your project management approach: It should make deciding what to work on next fast and intuitive, without endless meetings
Your MLOps setup: Rapid feedback is critical. Tools that streamline training, model evaluation, and deployment save hours of manual work and debugging.
Your CI/CD system: Deployments should be fast and reliable so you can focus on delivering value instead of firefighting pipelines.
Your data workflows: ETL pipelines that are slow or opaque make exploring data and iterating on features an uphill battle. Invest in tools that make it easy to preprocess and validate data.
Your communication tools: Team collaboration should be fast and frictionless. A slow or cumbersome chat, documentation, or ticketing system can sap time and energy.
As engineers, we’re encouraged to be scrappy and do more with less. That’s laudable, but if it makes us spend time on things tangential to the problem we’re solving, it’s a false economy.
It’s not the tools!
Many AI initiatives fail from the start. Some sources put the number at 80% or higher. We'll talk plenty about the why and how in this newsletter, but today, I want to talk about one thing that's not it: the tools.
Practitioners in any discipline have strong opinions about their preferred tools and tech stacks at just about any altitude:
Which editor/IDE is best?
AWS, GCP or Azure?
MySQL or PostgreSQL?
Pytorch versus Tensorflow
React versus Angular versus whatever the new sexy frontend framework is (Svelte?)
Our engineering mindset encourages us to look for the elusive "optimal" choice, but...
Here's the thing
There is often an inverse relationship between the fierceness of the debate over which tool is best and its ultimate impact on the project outcome. That's because the things that matter can be discussed (relatively) objectively. The critical decision lies in the category:
Microservices or monolith
Relational database or NoSQL
Classical ML, special-purpose neural network, or GenAI LLM?
Once those have been made, the rest does come down to personal preferences and tastes.
Keep it simple
Your project won't go up in smoke just because you selected Django over Ruby on Rails, your infrastructure runs on Azure rather than AWS, or you picked TensorFlow instead of PyTorch. So choose one, move forward, and concentrate your energy on the choices that truly matter.