Using AI for the Boring Parts

I have been thinking a lot lately about where AI actually fits into my real work, not the flashy demo version of work. The useful version for me is not asking it to be a genius or pretending it can replace knowing the business. The useful version is much more boring than that. I have Encompass work, mortgage workflow problems, reporting needs, status updates, follow-ups, and enough little administrative tasks that I can lose a whole day doing things that feel necessary but do not feel like building anything.

The pattern that is working best right now is using AI before I write code. I do not mean having it immediately generate a bunch of files and hoping the result is good. I mean using it to slow me down long enough to describe the problem correctly. If I need to build something around Encompass, reporting, loan data, or some weird mortgage workflow edge case, I will talk through what I know, what I think the business actually needs, what data is available, what the output should look like, and what parts I am unsure about. Then I use AI to turn that messy explanation into a smart prompt or a working spec before I start coding.

One thing people do not realize is that a good prompt is often just a better version of your own thinking. If I cannot explain what I want the code to do, AI is not going to magically fix that. It might generate something that looks impressive, but that is not the same thing as solving the right problem. The useful part is when it asks me to define the inputs, outputs, assumptions, failure cases, and the boring business rules I was trying to keep in my head. By the time I have a decent prompt, I usually understand the implementation better too.

That has been especially useful with mortgage work because the hard part is rarely just the code. The hard part is knowing what the workflow actually means. Encompass has its own way of organizing the world. The mortgage process has statuses, documents, timing issues, people waiting on other people, and a lot of small rules that are obvious only after you have been around them long enough. If I am building a report or an automation, I need to capture that context first. Otherwise I end up with code that technically runs but does not match how people actually work.

The Standup report is a good example of the kind of thing I mean. I am not trying to make AI own the report. I am using it to help me think through the shape of the report, what questions it needs to answer, what data probably matters, and how to describe the logic before I start wiring everything together. That is where AI has been most useful for me. It helps me get from a loose business problem to something concrete enough that I can build against it. Then I can spend my actual attention on the part I care about: making the thing work, making it useful, and making sure the output makes sense.

The other piece I have been using more is a Markdown file called reality. The idea is simple. I do not want status tracking to depend on me remembering to document everything after the fact. I do not want to finish a coding session and then have to reconstruct what happened from memory. Reality is meant to be a living document that keeps track of the current state: what is done, what is not done, what changed, what I tried, what failed, what needs follow-up, and what assumptions are still floating around.

This sounds small, but it changes the way I work. One thing people do not realize about documentation is that the problem is not usually writing one big document. The problem is keeping it alive after the first version. Nobody wants to stop every thirty minutes and write a polished update. I definitely do not. But if AI can help maintain the running status while I work, then documentation becomes part of the workflow instead of a separate chore at the end. It is not "document, document, document" anymore. It is more like keeping a shared scratchpad honest.

That matters because mortgage and Encompass work can have a lot of state. There are requests that started one way and turned into something else. There are reports where the first version answers one question and the second version needs to answer the question people actually meant to ask. There are status updates that are boring to write but important when someone asks where things stand. If reality is current, I can come back later and know what happened without rereading every message, every commit, and every half-finished note.

I am trying to use AI for the mundane parts that I do not want to spend my best energy on. Summarize where a task stands. Turn a messy explanation into a prompt. Keep the status file current. Help me notice the open questions. Draft the boring update. Compare what I said I was going to build against what I actually built. None of that is the fun part for me, but all of it matters if I want the fun part to move faster and have fewer loose ends.

The important distinction is that I still want to own the judgment. I do not want AI deciding what the mortgage workflow should be. I do not want it inventing business rules. I do not want it pretending to know Encompass details that I have not given it. I want it to handle the scaffolding around the work so I can spend more time on the work itself. That means better prompts, better notes, better status, and fewer moments where I am staring at a blank file trying to remember what I was doing yesterday.

That is probably the most practical version of AI in my day-to-day work right now. It is not replacing the interesting part. It is taking pressure off the annoying part. If I can use it to keep reality current, turn conversations into useful prompts, and help me move from mortgage workflow problem to actual implementation faster, then that is a win. I get to spend less time babysitting the process and more time building the parts I actually enjoy building.