Think about this: The worst AI you will ever use is the AI you use today.
Every couple of months something new comes out in my world - today it’s mostly with AI but whether it’s a new frontier model, new framework, language, or a new cloud system - it’s always evolving. We adapt - learn it, build it into how we work, makes us less efficient for a minute while we learn it before we gain expert competency to get more efficient with it and capable of deploying it to our clients. Then two months later it happens again, rinse and repeat.
That’s why I’m focused on the next few months, not an entire 2027 wish list. We have our longer term goals and plans, but today 1-year is what 5-years used to be.
Finding the shiny new thing is easy. Having the discipline to ask whether you actually need it and whether it is important right now is the hard part.
Our team is spread out across the country (and world), so getting everyone in one room takes some planning.
We used to do our big in-person event at the end of the year, but too many people travel then. So we moved it to the summer. Plus a summer in Chicago, unbeatable in my opinion.
This year we had people come in from about ten different states for a pizza making class in Chicago with Cooking with Cass. She just opened her business and we were her very first event. She was wonderful.
Her place is right by Wrigley, so afterward I walked everyone a block over to Murphy's Bleachers. The Cubs were on the road, unfortunately, but as a Cubs fan I wasn't going to pass up a little after party at Murphy’s.
Thanks to everyone who traveled in, and to Cass and team for a great night.
A year-old system in software development is a hundred releases behind.
And oftentimes, companies don't realize how close they are to that line until something new comes out and they can't use it.
The gap between a system that can adopt new technology and one that can't doesn't happen overnight.
There's a specific point where that becomes a real problem, and by the time it shows up, the options for fixing it have already narrowed considerably.
If you give an AI the same credit application twice, should you have to wonder whether it will reach the same decision?
That question shapes how we’re building CreditMind.
It’s tempting to put an applicant’s financials, credit history, and supporting documents into Claude or another LLM, with appropriate security and privacy controls in place, provide a skill file outlining your underwriting policy, and ask it to reach a conclusion.
But written instructions leave room for interpretation, even when you explicitly tell the model to follow them exactly. Tighter instructions help, but they don’t turn an LLM into a deterministic rules engine. The same policy can still be applied differently from one application to the next. It’s also generally faster and less expensive to execute those rules in code than to have an LLM work through the same policy on every application.
That’s why we still write conditional rules. The familiar “if this, then that” logic of traditional software.
If a required document is missing, request it. If an application falls outside an approved threshold, route it for review. If an exception requires approval, enforce that approval.
With the same inputs and the same version of the rules, the logic produces the same result. We can test it, track changes, and show which conditions drove the outcome.
We use AI to help build those rules. It can help translate underwriting policies into proposed logic, which engineers and credit leaders then validate and approve. Once approved, the rules run the decisioning.
AI can also help interpret documents, organize information, and flag concerns. But those inputs need validation too. A consistently applied rule is still wrong if it’s working from an incorrectly extracted number.
Some applications will require judgment. Those should go to someone with the authority to make the call and document why.
Three years later, when someone asks why an application received a particular outcome, we want to be able to show the inputs, the rules in effect, and any approved exception.
For me, that’s a big part of building AI into lending responsibly. Use it where it helps, and be deliberate about which decisions you allow it to make.
How are you deciding where to use AI judgment and where to keep fixed rules?
Reports were supposed to make my job easier. They can.
But honestly, a hundred reports just means a thousand things I (or someone) now has to go deal with.
As a business leader, I've got hundreds of reports - both dashboards and emailed reports, just like many of you.
But they require me taking action - I have to analyze them, work out what they're telling me, then go do something about it. In a way, reporting is still very necessary because it means you’ve got data organized and have a lot of thought to what is important. However, reports alone are now table stakes.
The actions you need to take is what you should be thinking about automating with AI. Imagine if your agents are reading the reports, doing the analysis, taking the necessary actions, and then only notifying you when escalation is required.
We've built that and embedded it into Sparkflow and DataConsole and can do the same for you - time to get your AI agents doing the work and start being proactive with your data instead of reactive.
We can get you there and faster.
When I started doing interviews 20+ years ago, I remember having a mindset that I had to sell candidates on why they should work here, instead of the opposite - them selling me.
Jon Morris changed that for me 10+ years ago.
He told me that when he did interviews, he was purposefully telling them how it is, including the ugly truth - even if it could scare them. The job is going to be very demanding. There are going to be long hours, weekends sometimes, and some days you're really going to hate it.
Some days you're really going to love it, and you're going to learn a lot along the way.
I thought that was great advice and adopted a lot of it.
A few people have passed after hearing it, and I'd rather that happen in the interview than in month three. The demanding part isn't a figure of speech - mission critical systems we build for clients require mission critical responses, which sometimes means somebody gets called on a Saturday.
The ones who say yes anyway tend to stick.
To me those long hours are part of the fun - it means the systems we're working on are widely used and actually matter. Beats the alternative of working on things that don't.
Traditional reports look useful on the surface, and that's exactly the problem.
You still have to read them, interpret them, and decide what matters before anything really happens.
The better model puts an agentic workflow on top of the data instead. Agents are continuously reviewing the information, running the analysis, and taking action on it.
What you get back might just be an exception report for the ten percent it couldn't handle on its own. This is what we've built into both Sparkflow and DataConsole.
Are we giving skills and experience too much weight when hiring?
I think we often do. And as AI puts more technical capability at our fingertips, the way someone thinks and approaches their work matters even more.
You can teach someone a framework, a tool, or a process. You can give them opportunities to build experience. It’s much harder to develop motivation, ownership, and the willingness to work through a difficult problem when those qualities aren’t already there.
Those are also harder to spot in an interview.
Can someone work through a problem they haven’t seen before? Do they ask thoughtful questions? Challenge an assumption? Keep going when the first answer doesn’t work?
I pay attention to whether someone is willing to put in the effort when the work gets difficult. Do they take responsibility for figuring it out, or wait for someone to hand them the answer?
People like to make this a generational conversation. I haven’t found that particularly useful. I’ve seen drive and complacency across every age group.
Give me someone who thinks critically, solves problems creatively, and wants to get better over someone with a long résumé and little motivation. Especially in software, the skills we need keep changing. The ability and willingness to learn are what make someone valuable over time.
Some of the best people I’ve hired weren’t the most experienced candidates. They were the ones who kept asking questions, took ownership, and learned what they needed to get the job done.
Training matters. But you can’t count on training to create drive.
What do you look for in an interview that a résumé can’t tell you?
Coding was never the bottleneck in building software. Even before AI.
So the idea that AI eliminates it and everything speeds up equally isn't quite what happens.
Traditionally, coding was only about twenty-five to thirty-five percent of the time it takes to build something - and that share is usually smaller once you’re past initial MVP and inside a production system.
The rest lived in architecture, requirements, review, QA, and implementation. If you take coding all the way down to zero, you're only saving that thirty-five percent at most and in the beginning only.
I did a big analysis on this for a client last week and the pattern held. AI makes you more efficient, and you can genuinely do more in less time - I talk about it all the time - and it’s only getting better.
But it hasn't replaced anyone. It's just moved where the effort goes.
What actually happens is that time shifts. Review wasn't taking that long before, but now it has to. You have to scrutinize everything much more closely, and architecture ends up taking more time, not less.
Skip the planning and the architecture to chase speed, and you're amplifying chaos instead of removing it. That plays out fine on a small personal project.
On an enterprise system a lot of people depend on, it gets hard to unwind.
The most surprising thing about AI in client conversations is the expectation that complex work should now happen almost instantly.
I have that same expectation half the time, and I have to ground myself back in reality. AI throws ten thousand pieces of information at me that I have to analyze, and I have to figure out what's completely wrong because it made a thousand assumptions I told it not to make.
I always think of Jurassic Park. They're reconstructing DNA, but they don't have enough, so they fill the gaps with something like frog DNA to complete the chain. AI does something similar. It gives you answers in a very confident manner, and where it can't fill the gaps, it just makes something up.
For most complex systems, AI is an amplifier. A little bit of chaos in the process gets amplified right along with everything else.
Clients tell us to use AI and get it done tomorrow. What happens instead is that my time shifts from creation to review and correction, and that takes just as long sometimes.
If you're taking AI's first response, it’s safe to say that most of the time, you're probably not using it well enough.
A lot of AI projects start with the wrong question.
People ask: Where can we use AI?
The better question is…Where is work harder than it needs to be?
If you’re a CTO, look for manual processes, repeated emails, people copying data between systems, chasing information, or waiting on reviews.
This is where AI can help remove friction.
Forcing AI into everything just to say you’re using AI tends to create noise and sometimes amplify bad patterns.
The AI news cycle is exhausting. And I think it's making leaders worse at making decisions.
It's just headline after headline. Did you see this? It can do this, it can do that. Terminators by tomorrow. And after a while it becomes genuinely anxiety-inducing, which is the opposite of useful when you're trying to make grounded decisions for your business.
My approach is to keep two separate feeds.
One for the moonshot hype, one for the grounded takes.
You need both, quite honestly, because the hype tells you what people are excited about and the grounded view tells you what's actually worth paying attention to.
What I've found is that if something shows up every single day for two months straight, there's probably some truth to it. But if it's a one-week headline, let it go. Come back to it.
The job of a leader is to live in the present while planning three years out. And you can't do that if every new model announcement sends you back to the drawing board.
A CFO building a business case around AI tools needs signals that are current, and the discipline to read them without letting every new announcement send you back to the drawing board.
Those two things are easy to confuse right now.
AI creativity is one of the most misunderstood parts of this technology.
Once someone explains the mechanics behind it, you can't see it the same way again.
Ask a model to finish the sentence "the sky is" and there are a thousand options sitting in its training data. What determines the answer coming back has far less to do with imagination than people assume.
Understanding how that selection works changes how you read every creative output these systems produce, and it's simpler than the marketing suggests.
Run the same automation a thousand times, and you get the same answer a thousand times over.
Run AI a thousand times, and you might get seven hundred and fifty different answers.
Deterministic is black and white automation. Probabilistic is how AI runs, and that's a feature of it working properly. The mistake people fall into is reaching for AI on problems that need the same result every single time.
From a governance standpoint, understanding the technology well enough to control that is where a lot of teams come unstuck.
Companies will spend years tolerating disconnected systems, then try to implement AI and realize they can't automate what's fundamentally broken.
The gaps were always there… AI just makes them impossible to ignore.
I think a lot of organizations operate in a state where things technically function only because people learned how to compensate over time.
And this isn’t something intentional. People just figure out how to get the work done and keep moving.
Not everything looks broken at first glance.
Work still moves through. Customers still get what they need. Reports still show up when expected.
From the outside, everything feels fine enough, so the friction never really gets named.
What I see most often is people tolerating small inefficiencies because they’ve become familiar with them.
Extra steps get absorbed into the day. Checks happen out of habit. Workarounds turn into routine.
After a while, no one remembers that it wasn’t always supposed to feel this way.
The reality is that those quiet gaps don’t stay harmless forever. They will sit there and hold until something like volume increases or timelines tighten. Then pressure shows up, and it feels sudden even though it’s been building for a long time.
When I’m trying to understand how an operation really works, I usually come back to one simple question:
What workarounds have become so normal that no one questions them anymore?
Those tolerated frustrations tend to point to the places that have been waiting for attention longer than anyone realized.
Nobody has ever asked me to fire their whole team and replace them with AI.
Though expectations sometimes get high enough that we have to bring them back down to reality.
Autonomously it can handle very repetitive things well. Decision-making is where you still want a human in the loop. Architecture matters more now than it ever has, and there's all sorts of governance you've got to put on top of any AI solution.
Any CTO scoping this out needs to understand its strengths, its weaknesses, and how it should be used.
The best version of a business often shows up when pressure forces sharper choices and faster execution.
Acquisitions create that pressure whether you’re ready or not.
Things can run well for a long time, and that’s usually the goal. You’re executing, hitting targets, and the business is moving the way it should.
Then an acquisition happens, and everything gets tested.
The strategy may be right, but now you have new systems, new expectations, new people, and new problems to solve.
What I’ve seen is that this kind of challenge forces a different level of thinking.
You start operating sharper.
You make decisions faster.
You pay closer attention to how things actually work.
I don’t know if you ever really look for disruption, but when the right kind shows up, it tends to bring out a better version of how you operate.
And I think that’s where a lot of growth actually comes from.
Hiring more underwriters isn't a scaling strategy. It's a cost strategy.
Real scale comes from codifying the decision, not the person making it.
Build the model. Document the framework.
Then your best underwriter's judgment lives in the process, not just in their head.
That's how you go from 50 decisions a month to 500 without doubling headcount.
There's a lot of conversation right now about AI replacing jobs.
Before getting too caught up in the headlines, I look at one signal.
Hiring.
The major AI companies are still growing their teams. If the narrative were true, that AI is eliminating work across the board, you'd expect those organizations to shrink as the technology matures.
They aren't.
That tells you something. The technology still requires people. There's still a lot of work happening behind the scenes that doesn't make it into the headlines.
The same pattern shows up inside companies exploring AI.
Some experiments won't pan out. That's not a failure, that's how new technology gets figured out. Teams try things, learn what works, and move on from what doesn't. That learning has real value even when a specific project doesn't go anywhere.
The problem isn't experimentation. It's when the experiments never connect back to the business.
Exploration without a tie to real decisions or measurable outcomes just drifts. At some point, a series of disconnected pilots isn't a strategy, it's activity.
The organizations getting real value from AI aren't the ones with the most projects. They're the ones who know what problem they're solving before they start.
The AI conversation is obsessed with capability, but the real constraint is power, cost, and infrastructure.
If you run IT, this is why the future may look like many cheap specialists instead of one giant system.
I think a lot of the AI conversation is centered around these massive, all-purpose models.
But when you really think about how businesses operate, that’s not usually what they need.
A lot of companies don’t need AI to do everything. They need it to work within their specific workflows and solve specific problems.
So the shift I see happening is toward more specialized systems.
Smaller, more focused, and a lot more practical to actually use and scale.