While taking Google's AI Fundamentals course, I ran into a topic that sounds simple but completely changes how you work with AI day to day: collaborative mindset.
Treating AI as a development partner means handing it context, direction, and technical feedback in order to get something useful back, the same way a junior teammate would need clear guidance to deliver good work.
I understood this in practice while building Quita, my tool that helps people interpret credit reports from Brazil's Central Bank (Registrato) and automatically generate formal complaints on Consumidor.gov.br, on top of real architectural and backend decisions. I want to share what I learned, with a stronger focus on how to specify requirements better and how I used collaboration with AI as part of my own technical learning.
The problem with talking to AI the wrong way
A lot of people treat AI like an oracle: they ask little, expect a lot, and get frustrated when the answer comes back generic, incomplete, or flat-out wrong. The issue usually isn't the tool, it's how the conversation was framed.
When I started building Quita, I noticed that the vaguer my prompts were, the vaguer the answers I got back. The turning point was realizing that collaborating with AI is a two-way process: I need to bring technical clarity, and only then can the AI bring precision.
A clear picture of what the system needs to do
Before asking for a single line of code, I needed to be able to describe Quita's data flow in technical terms, not in pitch-deck terms. The system receives a payload from a Registrato query, needs to normalize that data into a consistent internal format, identify inconsistencies between values reported by different institutions, and generate a structured text that follows the schema accepted by Consumidor.gov.br.
When I describe the flow this way, with clear input, transformation, and output, the AI stops filling gaps with assumptions and starts proposing solutions within the system's real constraints. A vague specification produces generic code. A technical specification, with an explicit data flow, produces a solution aligned with the architecture that already exists.
A defined audience is also a technical requirement
Quita is used by people with no familiarity with financial or legal jargon. That sounds like a UX detail, but in practice it becomes a technical requirement: API error messages, the text generated by AI inside the complaints, and even the structure of the JSON responses the frontend consumes all need to carry that consideration.
When I state this explicitly in prompts (for example, when asking for the structure of an endpoint that returns a credit analysis result), the suggestions for field naming, validation messages, and response format shift accordingly. A well-defined audience acts as a filter that narrows the AI's interpretation space at every layer of the system, from the database up to the interface.
A well-scoped problem is what cuts hallucination the most
This is the core point I already suspected before the course confirmed it: the more scoped the problem, the less room the AI has to invent a solution.
Asking "help me improve my credit system" is too vague. The AI will fill the gaps with assumptions, and assumptions produce hallucination. Asking "given the JSON returned by the Registrato query, with the fields already defined in my DTO, the system needs to identify inconsistencies between values reported by different institutions and generate a complaint text following the structure accepted by Consumidor.gov.br" is a problem with clear edges: known input, explicit comparison rule, defined output format. The AI has no reason to invent anything, because the response space is already shaped by the specification.
Knowing the basics of your stack isn't optional
This is something I only learned through practice: collaborating well with AI requires that I understand, at least at a basic level, every piece of what I'm building. Without that, there's no way to judge whether the answer I got is correct, or to ask for something more specific in the next round.
Quita's architecture today looks like this: a Java 21 backend with Spring Boot and Spring Security for JWT-based authentication, PostgreSQL with Flyway managing migrations, all running in production on Railway. The frontend is Next.js with TypeScript and Tailwind, deployed on Vercel, consuming the API through authenticated calls. The AI layer (Gemini and OpenAI) sits as an internal backend service, receiving already-normalized credit report data and returning the structured complaint text.
Understanding this architecture, even at the level of "what talks to what," is what gave me the autonomy to catch the AI's mistakes instead of accepting them. A few concrete examples:
- When configuring CORS between the frontend on Vercel and the backend on Railway, I got a suggestion that allowed origin
*alongsidecredentials: true, a combination the browser itself rejects. I only caught it because I already knew how CORS handles that combination. - In a suggested Flyway migration, the AI proposed altering a column without accounting for data already present in the production table, which would have broken the deploy. Understanding how Flyway versions and applies migrations is what made me review it before running it.
- In a Gemini API integration, I got a code example using a parameter from an outdated SDK version. Without knowing the basics of how that call should be structured, I would have copied and pasted it without noticing it wouldn't even compile.
None of these cases required deep expertise. They required just enough to be suspicious, test, and ask again. That "just enough" is exactly what a collaborative mindset assumes: you don't need to know everything, but you need to know enough to not accept an answer just because it sounds coherent.
This also changes the quality of the question I ask. Understanding the basics of authentication leads me to ask "how do I validate this JWT in the Next.js middleware without breaking server-side rendering," instead of simply "how do I build login." A more specific question produces a more specific answer, and a more specific answer leaves less room for hallucination.
Business context and external rules also guard against hallucination
It's not just code. Quita operates under rules that come from the outside: the Bacen data format, the structural requirements of Consumidor.gov.br. When I bring those rules explicitly into the conversation with the AI, not just the technical requirement, the chance of getting a solution that's technically correct but useless in practice drops significantly.
Using AI collaboration to learn while building
This was the most valuable takeaway from the whole process: a collaborative mindset can be used deliberately to learn, not just to ship faster.
There's a real technical difference between asking "implement JWT token validation" and asking "explain how JWT validation works in this middleware, then implement it." The first approach hands you a ready-to-paste solution. The second hands you the reasoning behind it, which lets me maintain, debug, and extend that code on my own afterward, without depending on going back to the AI for every adjustment.
That's how I picked up things while building Quita that I ended up applying directly to the architecture:
- Why Flyway versions migrations sequentially and treats them as immutable, and why altering a migration already applied in production is considered bad practice, which changed how I plan schema changes.
- Why a short-lived JWT access token is paired with a longer-lived refresh token, and how that balances security with user experience without forcing constant logins.
- Why browsers enforce the same-origin policy and exactly when CORS kicks in, which finally resolved the recurring errors in the Vercel-to-Railway integration.
- How to structure prompts for the Gemini API to get consistent JSON output, which required understanding a bit about how the model handles structured formatting versus free text.
Each of these started as a practical Quita problem and turned into knowledge I now carry into the next technical decision, even outside the project. It creates a loop: the more I understand, the better I frame the next question; the better the question, the more precise the answer; and the more precise the answer, the more I learn from it.
The risk in this process is learning shallowly, accepting code without understanding why it works. The way I guard against that is simple: before accepting any solution beyond the trivial, I ask the AI to explain the "why" behind the chosen approach, not just the "how" to implement it. If the explanation doesn't make sense to me, that's a sign I need to understand the concept better before putting that code into production.
Iteration is part of the process, not a sign of failure
Quita's design system, the "Da névoa à rota" (From the fog to the route) concept, built around glassmorphism and forest green as the primary color, didn't come out finished on the first try. It went through several rounds of adjustment with AI, each one refining the visual identity a little further. Understanding that the first answer is just a draft, not the final delivery, took the pressure off "getting it right on the first try" and actually improved the end result.
You're still the one in control
Collaborating doesn't mean delegating blindly. Every code suggestion, every generated text, every design decision the AI proposed for Quita went through my own review before reaching production. AI speeds up the process, but the responsibility for the final result still belongs to the developer.
Collaborative mindset as a working method
In the end, what I learned building Quita is that collaborating with AI looks a lot like guiding a talented junior teammate who doesn't know your context: you need to bring a clear specification, a defined audience, a scoped problem, real architecture, and at least a baseline of technical knowledge to recognize when something's off. In return, the payoff isn't just delivery speed, it's technical learning accumulated with every round of conversation.
Quita is in production today because each of these pieces, clear technical specification, defined audience, scoped problem, explicit architecture, human review, and continuous learning, worked together. Not because I asked the AI to "build a credit analysis system" and got a finished solution back.
Top comments (0)