Skip to main content

Idea pipeline (top 25)

Filter by idea status

Filter by product

1986 Ideas

Robert Jan de Nie
Thinkwise blogger
Robert Jan de NieThinkwise blogger

Make Software Factory metadata available to AI so I can generate SQL templates from my IDEOpen

I want to use generative AI to draft the bulk of my SQL templates, directly from my own IDE (e.g., VS Code) together with tools like GitHub Copilot. For this to work reliably, the AI needs first-class context from the Thinkwise Software Factory (SF): the application’s model metadata and relevant UI information. The SF already maintains a rich, structured model of tables, columns, and references; exposing that to the AI is the missing piece.Why this metadata is essential for AI-assisted SQL When the AI understands my model, its output stops being generic and becomes project-specific:Tables, columns, PK/FKs – enable correct JOINs, WHERE clauses, and integrity-awareness. The SF’s data model explicitly defines these entities and relations, which the AI can use to pick the right join keys, respect cardinalities, and avoid hallucinated columns. Domains (user-defined data types) – domains act as abstract data types that drive constraints and UI defaults. Sharing domains helps the AI choose correct data types, casts, default values, and validation logic in generated SQL. UI semantics – properties like control type or visibility can guide the AI to prefer filtered queries (e.g., hide inactive rows by default) or to shape parameter prompts and WHERE clauses that match what end-users actually see. Template description & intent – short, descriptive text per template (purpose, invariants, edge cases) gives the AI the business intent it needs to generate more accurate and consistent code.How I propose to make this work Expose a compact model export for use in VS Code MVP scope: tables, columns (incl. nullability), primary keys, foreign keys, domains (name, base type, constraints). Optional scope: UI hints (visibility, control), default filters, and template descriptions. Delivery options (any of these would work): Indicium OData endpoint that surfaces a read-only view of the SF model (Indicium already provides an open API and can expose SF branches when configured). CLI/export task that writes JSON files into a repository (consumed by VS Code). VS Code extension that authenticates to the endpoint and injects the model as inline context for Copilot prompts. Use the model export as AI context in the IDE In VS Code, I want to select a template and have the AI read the JSON/endpoint to generate the initial SQL ready for review and refinement. Expected resultsSpeed: AI drafts 70–90% of the SQL, I focus on edge cases. Quality: Consistent use of keys, domains, and defaults; fewer “missing join” or “wrong column” errors. Discoverability: As Thinkwise continues to add AI-powered features (e.g., model enrichments and support for storing LLM embeddings), a model-aware export aligns with that trajectory. Future fit: Community use cases already show value in combining Thinkwise models with LLMs (e.g., natural-language search using embeddings), reinforcing the need for structured model access. 

Robert Jan de Nie
Thinkwise blogger
Robert Jan de NieThinkwise blogger

Bring back quicksearchPlanned

In previous iterations of the Thinkwise GUI you could perform an action called quicksearch. How it worked:Bring focus to a specific column (in the grid) Type what you want to search  First match of your search gets selected/highlighted. Can we please have this back?Why Quicksearch is valuable (and missed)1. Strong productivity gain for keyboard usersQuicksearch enabled fast, uninterrupted workflows:No mouse interaction requiredNo modal dialogs or filter configurationImmediate feedback while typingFor users who work with data grids all day, this shaved seconds off every lookup — which adds up quickly.2. Ideal for exploratory and ad‑hoc searchingQuicksearch was perfect when:You don’t know the exact valueYou just want to jump to something that looks rightYou don’t want to define a full filter for a one‑off checkCurrent alternatives (filters, column search fields) feel heavier for this use case.3. Lower cognitive load than filteringQuicksearch required almost no mental overhead:Focus columnTypeFirst match selectedCompared to:Opening filtersChoosing operatorsApplying / clearing filtersThis made it especially useful during conversations with users or while debugging data.4. Excellent for large datasetsIn grids with many rows:Scrolling is inefficientSorting doesn’t always helpFilters can be overkillQuicksearch acted as a “jump to value” mechanism, not a data‑reduction mechanism — a subtly different but very useful interaction.5. Consistency with legacy behavior & muscle memoryMany long‑time Thinkwise users built muscle memory around this feature.Its removal:Breaks established workflowsIncreases friction when moving to Universal UIMakes Universal UI feel like a regression in this specific area, despite its overall improvements6. Complementary, not a replacement, to filteringQuicksearch didn’t replace filters — it complemented them:Filters = structured, intentional selectionQuicksearch = fast navigation and orientationBoth serve different user intents and can coexist.