Why I Don't Start AI Projects With AI
A powerful technology isn't automatically the right starting point. Start with the outcome, understand the system, find the constraint, then choose the intervention.
I came to AI engineering from the business side.
Louis Scalise · AI implementation and systems engineering
More than 15 years in sales, marketing, finance and business operations, then formal study in AI engineering. My work sits where the two meet.
Where those two meet.
My background spans more than 15 years across sales, marketing, finance, customer acquisition and business operations. That work taught me something technology alone can't: a technically impressive system is useless if it doesn't work inside the reality of the business.
I later studied AI engineering at Maestro College, bringing software, data, automation and AI into the business experience I already had. Today my work lives at that intersection.
I want to understand two things: what the business needs to accomplish, and how to engineer the system that accomplishes it. That means understanding the people who use it, the process around it, the information it depends on, the technology it connects to, the constraints on it, and the evidence that will tell us whether it worked.
I don't believe every problem needs AI. I do believe every implementation needs clear thinking.
How I got here.
My background didn't begin in a computer science classroom. It began with customers, sales teams, operations, financial products and dealerships.
- Sales & marketing
- Customers, sales teams, customer acquisition and the marketing systems behind them.
- Finance
- Financial products, including mortgage.
- Automotive
- Dealerships, their processes, their targets and their real constraints.
- AI Engineering, Maestro College
- Four semesters of study, adding software, data, automation and AI to the business experience.
- Dealer Flywheel
- What I'm building now: a diagnostic system that finds where dealerships lose performance between their tools and people.
Business sense, engineering skill.
AI engineering gave me the ability to move from understanding operational problems to designing and building the systems that address them.
That combination shapes how I approach implementation. I don't want to build technology that looks impressive in isolation. I want to build systems that survive contact with the business: bad data, missing information, permissions, exceptions and human behavior.
Notes from the work.
Technology changes quickly. The principles for reasoning about systems last longer. This is where I write down what I'm learning, what I'm testing, and when experience changes my mind.
A Workflow Isn't a System
A workflow is a sequence. A system is everything that sequence needs to succeed: people, information, timing, ownership, exceptions and what happens downstream. Optimizing the workflow alone can just move the problem.
The First Build Should Test the Riskiest Assumption
An MVP shouldn't mean a bad version built quickly. Find the assumption carrying the most uncertainty and build something credible that tests it.
What guides my work.
- Understand before automating.
- Start with the outcome, not the technology.
- Separate symptoms from causes.
- Find the constraint.
- Make assumptions explicit, then build to test them.
- Use deterministic software where it's better, and AI where it adds real leverage.
- Keep people where their judgment matters.
- Design for failure, not just the happy path.
- Make the system observable.
- Measure what changed, and let evidence decide what comes next.