I have been designing interfaces for banks and fintechs for over 10 years. Onboarding flows, approval screens, transaction dashboards, investment apps. I worked with product teams, engineering teams, project managers, and regulators. I went through usability reviews, accessibility audits, and presentations to stakeholders who do not understand why a button should say one thing and not another.
Over the last 6 months I built a complete trilingual blog with Claude as my coding partner. And in that process I adopted 6 professional practices that a decade in the industry never taught me. Not because AI is a better teacher than experience. Because AI forced me to do things that workplace culture had normalized skipping.
1. Asking twice as many questions as before
In a corporate environment, questions are limited to the scope of the project. What is the objective of the site? What features does it need? When is the delivery date? Operational questions that resolve the what but not the where to.
Working with AI, the questions expanded. I no longer ask only what the objective of the site is. I ask where that objective will evolve in 12 months. If that objective changes, will the architecture I am building support it or will it need to be rebuilt? Is the stack I am choosing a technical decision or a habit?
AI does not respond better to shallow questions. It responds better when you give it deep context. That forced me to develop deep context before every project. And that habit does not disappear when I work without AI. I now ask the same questions to clients.
2. Documenting as if someone else will read it
In the industry, documentation is an afterthought. It is written quickly, written generically, and written to meet a requirement, not for someone to actually understand it. I have heard the phrase "the code documents itself" dozens of times.
When I work with Claude, every instruction is documentation. If I do not explain what I want clearly, the output is incorrect. And explaining clearly means lowering the language to basic concepts. Not assuming the AI knows what I mean by "make it responsive" or "optimize the performance." It means specifying which breakpoints, which metrics, which tradeoff between speed and functionality.
The side effect is that I now document everything thinking that someone without my context will read it. Not because anyone asks me to. Because the habit of explaining for AI transferred to explaining for humans. My documentation improved because my most demanding audience is a machine that infers nothing.
3. Explaining what I do to non-technical people
My client reports used to be technical. "I implemented JSON-LD with 5 entities in @graph." "I optimized TTFB to 200ms." Correct. Incomprehensible to someone paying for a business result, not a technical metric.
Now I pass everything through a layer of explanation for non-technical audiences. Not because AI suggested it. Because the process of working with AI trained me in translating complex concepts into simple language. If I can explain to Claude what I want in one sentence, I can explain to a client what I did in one paragraph.
The practical result: I receive fewer messages from clients asking me to explain what I did. The reports explain themselves. That saves me hours per week I used to spend on clarification calls.
4. Justifying technical decisions with data, not habit
On a development team, technical decisions are often made by inertia. "We use React because it is what we use." "The framework is Laravel because the team knows it." "The database is PostgreSQL because it has always been PostgreSQL." These are reasonable decisions but rarely questioned.
AI confronts me with alternatives on every decision. When I tell it I am going to use a technology, it does not assume it is the correct one. It asks (or should ask, and if it does not, I ask) why that one and not another. What does the client specifically need that justifies that choice? Is there something simpler that solves the same problem?
This forced me to stop choosing technologies by familiarity and start choosing by fit to the problem. My blog runs on vanilla PHP not because I do not know frameworks but because I analyzed what I needed and a framework was unnecessary complexity for that case.
5. Expressing myself with precision, not approximation
In a work meeting, you can say "let us improve the user experience" and everyone nods. Nobody asks what exactly that means. Ambiguity is resolved through shared context and implicit assumptions.
With an AI, ambiguity produces ambiguous output. If I say "improve the UX," I get a generic list of best practices. If I say "reduce the time between the first interaction and the first completed action in the onboarding form for users over 60 years old," I get something useful.
That trained me in precision. If AI does not understand vague instructions, a human does not understand them either. The human just pretends to. AI returns the exact result of what I said, not what I meant. That is a mirror that workplace culture does not have.
6. Questioning whether something works or has simply not broken yet
In programming there is a phrase that repeats across every team: "if it works, do not touch it." It is a survival rule. Do not move what is not broken. But that rule also freezes knowledge.
When AI generates code, it sometimes uses a pattern I do not know. The first reaction is to ignore it if the output works. The second, the one I adopted over time, is to ask why it used that pattern and not the one I would have used. Just as addition is useful for one stage of life and then comes multiplication, in code the fact that something works does not mean something better does not exist.
The json_encode flags (JSON_UNESCAPED_SLASHES and JSON_UNESCAPED_UNICODE) were in my code because Claude put them there. They worked. I never questioned them. When Abbey from freeCodeCamp asked why they mattered, I discovered they were preventing silent bugs on a trilingual blog. They were not decoration. They were the difference between functional JSON-LD and one that broke with Spanish accent marks.
"If it works, do not touch it" became "it works, but why does it work this way and not another?"
What this says about the industry
None of these 6 practices is new. Asking deeply, documenting well, communicating for non-technical people, justifying decisions, being precise in expression, and questioning what works. These are fundamental practices that any senior professional should have.
But fintech and banking workplace culture does not prioritize them. It prioritizes delivery speed, requirement compliance, and stability over innovation. In that context, documentation gets sacrificed, deep questions are perceived as a waste of time, and "if it works do not touch it" is a virtue, not a vice.
AI did not teach me these practices. It forced me to adopt them because they are the only way to get quality output from a tool that does not infer, does not assume, and does not pretend to understand what you did not explain well.
That does not say something good about AI. It says something concerning about an industry that allowed a professional with 10 years of experience to get this far without them.