{"slug": "code-intelligence-has-escaped-the-code", "title": "Code intelligence has escaped the code", "summary": "BrokkAi released Bifrost v0.14.4, a code-intelligence tool that correlates Java configuration-accessor calls with entries in explicitly named .properties files, so that a call such as config.get(\"db.url\") is linked to the db.url entry in a declared document rather than to any matching string literal. The release expresses the relationship in RQL, pairing the :code side, which selects the accessor and binds arguments to its first parameter through proven call resolution, with the :configuration side, which selects property entries. Bifrost reports duplicate keys as \"ambiguous\" and returns incomplete diagnostics for unreadable documents, undecodable arguments, and keys built from constants or dynamic values, following what BrokkAi calls its \"honest incompleteness\" principle: an empty result with incomplete diagnostics does not establish that no relationship exists.", "body_md": "# Code intelligence has escaped the code\n\nA surprising amount of program behavior is defined by what is outside the program. Database URLs, feature flags, and library settings sit in configuration files or environment variables, while the code reading them may make some half-assed assumptions on what comes out on the other end. Strings are an example of a horrible \"anything\" type and should more often than not be encoded into more specific types, e.g., URL, semantic version class, etc.\n\nIf we want code intelligence to explain what an application does, those files become part of the question. For example, we might want to assert that, before deployment, every required configuration lookup must resolve to exactly one (valid) entry in the application’s declared production configuration file.\n\nFor example, [Bifrost v0.14.4](https://github.com/BrokkAi/bifrost/releases/tag/v0.14.4?ref=blog.brokk.ai) correlates Java configuration-accessor calls with entries in explicitly named `.properties` files. The recordings below use the public release:\n\nSuppose our application reads configuration through `AppConfig.get(String key)`:\n\n```\nvoid connect(AppConfig config, Audit audit) {\n    String url = config.get(\"db.url\");\n    String pool = config.get(\"db.pool\");\n\n    audit.get(\"db.url\");\n}\n```\n\nAnd we have this document:\n\n```\n# src/main/resources/app.properties\ndb.url=jdbc:postgresql://db/app\ndb.user=app\n```\n\nWe want to connect the first call to the `db.url` entry. We also want to explain why the other calls don’t qualify.\n\nSearching for the literal `\"db.url\"` finds it in both calls. Searching for methods named `get` finds those too. Neither tells us which method resolves to the configuration document we mean.\n\nThat would be an impressive amount of confidence (and coincidence) for two equal strings.\n\nInstead, let's express their relationship in [RQL](https://bifrost.brokk.ai/code-querying/?ref=blog.brokk.ai):\n\n```\n(correlate\n  :relation\n    (configuration-key\n      :documents [\"src/main/resources/app.properties\"])\n\n  :code\n    (call-input :parameter-index 0\n      (call-sites-to :proof proven\n        (enclosing-decl\n          (inside\n            (class (name \"AppConfig\"))\n            (method (name \"get\"))))))\n\n  :configuration\n    (configuration-facts\n      :format properties\n      :node-kind member))\n```\n\nThe `:code` side selects the accessor and asks for arguments bound to its first parameter through proven call resolution. The `:configuration` side selects property entries. The `:relation` connects a plain string-literal key to the matching entry inside the declared document.\n\nSo `config.get(\"db.url\")` pairs with `db.url=...`. The `\"db.pool\"` call has no matching entry in this file. `audit.get(\"db.url\")` resolves to a different method. An identically named property in another file stays outside the relationship unless we *explicitly declare that file*.\n\nThe result retains both locations and their provenance, giving us something we can inspect and navigate.\n\nThe important boundary or \"narrowing\" of the query is in supplying the document path. The query does not statically determine which file the application loads at runtime or which value wins after overrides.\n\nFor correctness-sake, duplicate keys result in an \"ambiguous\" outcome. Unreadable documents and arguments the relation cannot decode produce incomplete diagnostics. If the key comes from a constant or a dynamically constructed value, this first implementation cannot establish the same relationship.\n\nAn empty result accompanied by incomplete diagnostics tells us where the analysis stopped. It does not establish that no relationship exists.\n\nFor an agent, this makes a useful difference. It can follow an explicit relationship between a configuration read and an authored setting, inspect both sides, and carry the remaining uncertainty into its answer. This is part of Bifrost's \"honest incompleteness\" principle when determining a query result.\n\nFor the example in this blog, the `configuration-key` relation used here supports Java calls with plain string-literal keys and explicitly named `.properties` files. However, Bifrost also queries JSON, YAML, TOML and XML, with separate relations for other connections between code and configuration. As previously mentioned, the does not infer runtime file loading, framework binding or environment overrides.\n\nBifrost also powers [SlopCop](https://slopcop.com/?ref=blog.brokk.ai), where `slopcop check` (or its MCP equivalent) brings static analysis into a coding agent’s edit-and-check loop. A number of CVEs relating to vulnerable dependencies only trigger when certain configuration settings are enabled.\n\nFor example, [CVE-2022-22947](https://spring.io/security/cve-2022-22947/?ref=blog.brokk.ai) in Spring Cloud Gateway required the Gateway Actuator endpoint to be enabled, exposed, and unsecured. Log4j's [CVE-2021-45046](https://logging.apache.org/security.html?ref=blog.brokk.ai) involved a non-default Pattern Layout containing a Thread Context Lookup such as `$${ctx:loginId}`, combined with attacker-controlled context data. Without these pre-conditions in the application configuration, the affected dependency is dormant and not an immediate threat to the code that uses it.\n\nCode intelligence has escaped the code and, for now, it knows exactly which file it was allowed to visit.", "url": "https://wpnews.pro/news/code-intelligence-has-escaped-the-code", "canonical_source": "https://blog.brokk.ai/code-intelligence-has-escaped-the-code/", "published_at": "2026-11-06 16:00:00+00:00", "updated_at": "2026-11-06 16:19:17.493766+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-agents", "artificial-intelligence"], "entities": ["BrokkAi", "Bifrost", "Bifrost v0.14.4", "RQL"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/code-intelligence-has-escaped-the-code", "markdown": "https://wpnews.pro/news/code-intelligence-has-escaped-the-code.md", "text": "https://wpnews.pro/news/code-intelligence-has-escaped-the-code.txt", "jsonld": "https://wpnews.pro/news/code-intelligence-has-escaped-the-code.jsonld"}}