Comparision of LLM models for coding and planing

Today, I would like to compare several LLM models how they build plans to write the code.

Having some open source projects in internet, I would like to compare the performance of OpenAI Codex and Claude Code on example of some LLM models in cloud and on-premises.

Having the one open source project that has complex graph of connected logic elements gives me ability to evaluate those solutions in the scope of work of modification of framework for the latest dependencies.

For this purpose I selected the DI (Dipendency Injection) framework written fully by me from the scratch long time ago, since I was a Java programmer and Spring Framework consultant / architect and participated in the most complex Fortune-500 projects all around the world.

As a big fan of Spring I found golang is missing nice DI framework at that time and constanty improving my runtime solution that provides out of the box the maximmum functionality similar to spring.

It was almost 20+ project already written by using this DI framework that now is cornerstone of some production systems and solutions around the world processing massive scale of data on golang with clear component based architecture.

Here is the project repo: https://github.com/arpabet/glue

The original name of the project I gave was `context`, later I realized a huge confusion with existing package context in golang using everywhere. Therefore I started looking on the name that would fit the best be stopping on `glue` that reflects the nature of DI service for the components.

First of all I would like to define the scope of the work needed for this framework:

• It is outdated, focusing on golang 1.17+ (needs upgrade)
• It does not support templates, but it is time to add this
• It does not have scopes, and now I think it is time to research how to add them
• It also needs good scaning of beans
• I also want to add a dynamic config for properties.

Now, let’s select the list of models:

• opus4.6 — this is the best one, but the most expensive
• gpt5.3-codex — nice model from CharGPT
• qwen3.5:122b — local ollama
• gpt-oss:120b — local ollama

So, for the all those experiments I was using Claude Code except for gpt5.3-codex that was using the Codex.

After checking out the glue project I asked each model the same prompt:

I want you to explore the project, make the initial research of it, provide me description and this project for, write list of features and compare with competitors

Having the best response form opus4.6-high I am publishing it here

Project Description

Glue is a runtime Dependency Injection (DI) framework for Go, inspired by the Spring Framework in Java and licensed under BUSL-1.1 (Business Source License), converting to MPL 2.0 after four years.

The module path is go.arpabet.com/glue. It has minimal dependencies — only pkg/errors, yaml.v3, and testify (for tests).

Unlike code-generation-based DI solutions common in Go, Glue uses reflection at runtime to scan struct tags, match interfaces to implementations, and wire dependencies together. The context creation algorithm is O(n×m) — checking every interface against every registered bean.

Features List

  ┌────────────────────┬──────────────────────────────────────────────────────────────────────────────────────────────┐  │      Category      │                                           Feature                                            │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Core DI            │ Runtime dependency injection via inject struct tags on public fields                         │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Bean Types         │ Supports Pointer, Interface, and Function beans                                              │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Collections        │ Inject slices ([]Element) and maps (map[string]Element) of beans                             │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Qualifiers         │ Select specific bean by name: inject:"bean=myService"                                        │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Optional deps      │ inject:"optional" — field stays nil if no candidate found                                    │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Lazy deps          │ inject:"lazy" — defers initialization to break circular dependencies                         │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Lifecycle: Init    │ InitializingBean.PostConstruct() — called after all fields are injected, in dependency order │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Lifecycle: Destroy │ DisposableBean.Destroy() — called on ctx.Close() in reverse init order                       │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Named beans        │ NamedBean.BeanName() — custom name for lookup and map injection keys                         │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Ordered beans      │ OrderedBean.BeanOrder() — controls position in collection injections                         │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Factory beans      │ FactoryBean — programmatic bean creation, singleton or prototype scope                       │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Bean reload        │ Bean.Reload() — destroy + re-init a bean at runtime                                          │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Context hierarchy  │ ctx.Extend(...) — child contexts inherit parent beans, parent is unaware of child            │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Lookup levels      │ Control search depth in context hierarchy (0=fallback, 1=current only, -1=all)               │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Runtime injection  │ ctx.Inject(obj) — inject fields into objects not registered as beans                         │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Properties         │ Built-in key/value property system with .properties, .yaml, .json file support               │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Property injection │ value:"app.port, default=8080" struct tag injects config values with type conversion         │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Property resolvers │ Pluggable PropertyResolver interface with priority ordering                                  │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Resources          │ ResourceSource / Resource — bind and access http.FileSystem assets                           │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Scanner            │ Scanner interface — modular/conditional bean discovery                                       │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Child contexts     │ glue.Child("name", beans...) — lazy sub-context creation on demand                           │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Cycle detection    │ Detects circular dependencies at init time and returns clear error messages                  │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Verbose/debug      │ Optional verbose logging of the entire scan/inject/construct pipeline                        │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Thread safety      │ Registry uses sync.RWMutex; runtime Inject uses sync.Map cache                               │  ├────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────┤  │ Graceful close     │ Timeout-based close with panic recovery on destroy                                           │  └────────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────┘

Competitor Comparison

┌────────────────────┬─────────────────────────────┬───────────────────────┬─────────────────────────┬─────────────────┬────────────────────────┐  │      Feature       │            Glue             │      Google Wire      │       Uber Dig/Fx       │ Facebook Inject │       samber/do        │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ Approach           │ Runtime reflection          │ Compile-time codegen  │ Runtime reflection      │ Runtime         │ Runtime generics       │  │                    │                             │                       │                         │ reflection      │                        │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ Wiring mechanism   │ Struct tags (inject)        │ Provider functions +  │ Constructor functions + │ Struct tags     │ Explicit do.Provide()  │  │                    │                             │ code generation       │  dig.In/dig.Out         │ (inject)        │ / do.MustInvoke()      │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ Go version         │ 1.17+                       │ 1.16+                 │ 1.17+                   │ 1.4+            │ 1.18+ (generics)       │  │                    │                             │                       │                         │ (unmaintained)  │                        │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ Context hierarchy  │ Yes (Extend + Levels)       │ No                    │ Yes (Fx modules with    │ No              │ Yes (child scopes)     │  │                    │                             │                       │ scopes)                 │                 │                        │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ Factory beans      │ Yes (singleton + prototype) │ Via provider funcs    │ Yes (via constructors)  │ No              │ Via lazy providers     │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ Lazy injection     │ Yes (inject:"lazy")         │ N/A (compile-time)    │ No (workarounds exist)  │ No              │ Yes (lazy values)      │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ Optional deps      │ Yes (inject:"optional")     │ No (compile error)    │ Yes (optional:"true")   │ No              │ Yes                    │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ Collection         │ Slices + Maps               │ No (manual grouping)  │ Yes (dig.Group)         │ No              │ No                     │  │ injection          │                             │                       │                         │                 │                        │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ Property/config    │ Built-in (value tag,        │ No                    │ No (use Fx config       │ No              │ No                     │  │ injection          │ YAML/JSON/properties)       │                       │ separately)             │                 │                        │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ Resource           │ Built-in ResourceSource     │ No                    │ No                      │ No              │ No                     │  │ management         │                             │                       │                         │                 │                        │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ Named              │ Yes                         │ Via named providers   │ Yes (dig.Name)          │ No              │ Yes (named services)   │  │ beans/qualifiers   │                             │                       │                         │                 │                        │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ Ordered beans      │ Yes (BeanOrder)             │ No                    │ No                      │ No              │ No                     │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ Bean reload        │ Yes                         │ No (compile-time)     │ No                      │ No              │ No                     │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ Lifecycle hooks    │ PostConstruct + Destroy     │ No                    │ Yes (Fx Lifecycle)      │ No              │ Shutdown hooks         │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ Cycle detection    │ Runtime with clear errors   │ Compile-time          │ Runtime with errors     │ Runtime         │ Runtime                │  │                    │                             │                       │                         │ (panics)        │                        │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ Type safety        │ Runtime (panics/errors)     │ Compile-time          │ Runtime                 │ Runtime         │ Compile-time           │  │                    │                             │ (strongest)           │                         │                 │ (generics)             │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ Maintenance        │ Active                      │ Active (Google)       │ Active (Uber)           │ Archived        │ Active                 │  ├────────────────────┼─────────────────────────────┼───────────────────────┼─────────────────────────┼─────────────────┼────────────────────────┤  │ License            │ BUSL-1.1 → MPL 2.0          │ Apache 2.0            │ MIT                     │ Apache 2.0      │ MIT                    │  └────────────────────┴─────────────────────────────┴───────────────────────┴─────────────────────────┴─────────────────┴────────────────────────┘

Key Differentiators

Strengths of Glue:

- Most Spring-like DI experience available in Go — familiar for Java developers migrating to Go

- Richest built-in feature set in a single package: DI + properties + resources + lifecycle + hierarchy

- Bean reload at runtime — unique among Go DI frameworks

- Built-in config injection with multi-format support (properties, YAML, JSON)

- Ordered collection injection — not available in competitors

Weaknesses / Tradeoffs:

• No compile-time safety — wiring errors surface at runtime, unlike Google Wire
• Reflection overhead — O(n×m) at context creation; heavier than codegen approaches
• BUSL license — more restrictive than Apache/MIT competitors; may limit adoption in some orgs
• Smaller community — less ecosystem support and documentation compared to Wire or Dig/Fx
• Go 1.17 minimum — doesn’t leverage Go generics for type-safe APIs like samber/do

It is time to ask LLMs to make a deep research of the project and features and create the enhacement plans, for this purpose I used this prompt equal for all of them

look on the missing features in glue, think about adding functions injection to “value” properties, for example for lazy or refreshable property
initialization. One of the use cases by using PropertyProvider interface some cloud-based solutions could access the secrets in AWS/GCP or
whatever, and I would like to think about runtime changing of secrets and automatical reflection of them in glue. This is so called dynamic
config. I already have PropertyProvider for the environment variables by keeping the custom logic outside the glue that basically overlook for
the property name and if it looks like env name it goes to operation system environments. Besides the propety management it could have
improvement with templates and performance. Think about caching injection steps to eliminate O(n*m) compexity. Also think about caching of the
properties as well, but keeping in mind dynamic config. Explore the type safety in framework to eliminate interface{}. Think about adding the
Profile functionality similar like in Spring Framework. Additionally we can add the scope for the bean injection, so we can inject on runtime
request based beans. Thnk about simplification of syntax of the bean injection, support qualifiers or may be it is needed some renamings. Explore
the component scanning, by adding scaning by package. May be needed more integration tests and sample applications. Create the modification
plan. research and analyse what features could be added, modified in Glue framework, what featureas could be renamed, upgraded,
create the plan of the changes. Make this framework better than others.

After execution I found out that the longest model was actually opus4.6-high, then qwen3.5:122b and then gpt5.3-codex was pretty fast, but I had to make additional prompt for it to create a plan, and gpt-oss:120b was extreamly fast but less accurate.

Here is the static link to all those plans as they created by LLM for manual evaluation:

https://github.com/arpabet/glue/tree/v1.2.6/.github/plans

The size of the plans is extreamly different:

gpt-oss-plan.md - 5kgpt5.3-codex-plan.md - 7kopus4.6-high-plan.md - 34kqwen3.5-plan.md - 10k

For my subjective opinion the best plan is qwen3.5:122b, since it is not so long and have all nessesary features.

The most reasonable way to do the next steps is to switch to cheaper models. Since I was already using the gpt5.3-codex model in OpenAI, I decided to continue using this one. But for the extermly expensive opus4.6-high I decided to scale down to sonnet-4.6 for the actual implementation.

But let’s discuss the plans.

• gpt-oss:120b model produced pretty much fast but less accurate plan. I would use this plan if I would not have other options. This plan is pretty basic but even that gives nice overview for the developer. In addition to that I asked this model to create a scanner. It implemented a nice unit test for this and totally incorrect scanner implementation reading source files from filesystem, looks like this model did not realize that golang is compilable language. Skipping.
• gpt5.3-codex:cloud model produced amazing plan that has eveything you need. I liked the naming convensions there in suggestion of keeping FactoryBean and create additional one FactoryBeanOf[T]. I feel that this model thinks like developer and supports backward compatibility. It also suggested to keep PropertyResolver as it is and make additional PropertyProvider. Many things I like from this plan: generic helper methods, WithProfiles context options, glue.IfProfile list of beans, profile-aware properties, qualifier alias, env or secret property expressions, dynamic config approach. In general I feel that this model gives compact and valuable information about the project.
• opus4.6-high:cloud model produced the biggest ever plan. It contains 7 phases that are stong and solid modification plans. By looking on this I feel over-engineering and probably needs additional simplification of those features. But in general I feel like this is the right way to go.
• qwen3.5:122b model produced nice compact plan focusing on list of real problems of the Glue framework. I like how it is structured: performance, type safety, api, missing features. Based on the first recommendation I already made simple name refactorings in IDE. I like how it organized cache lookups without braking any structure of the project, suggested active profiles approach, make a primary bean, added bean scope, typed `FactoryBean[T any]`. I feel like qwen3.5 gives fully comprehensive approach and their recommendations are solid and sufficient.

The winning LLM model for planing

1. opus4.6-high
2. gpt5.3-codex

I feel like the best way is to start with small features from qwen3.5, expand them by gpt5.3-codex proposal, and make comprehensive changes from opus4.6-high.

I do not think the backward compatibility should be considered at this moment, since the transition to the 1.18+ golang with templates anyway will make the code incompatible, it is literally better to start new version of the framework with all those features in place.

Finally I used gpt5.4-extended-thinking model to join all those plans together and get final plan.

1. Fix performance first.
2. Add dynamic config on top of that.
3. Introduce typed APIs in a compatibility-safe way.
4. Add profiles/scopes next.
5. Use code generation for scanning, not brittle runtime scanning.
6. Finish with docs, examples, benchmarks, and validation tooling.

Single combined modification plan for Glue

Phase 0 — Guardrails and compatibility rules

Start with explicit design rules so the rest of the work stays coherent:

• Keep all existing inject and value behavior working for one full compatibility cycle.
• Keep PropertyResolver and current FactoryBean supported.
• Make new behavior opt-in through new interfaces, options, or tag forms.
• Treat Go 1.18+ generics as a staged upgrade: either add typed wrappers behind build tags first, or ship them as part of a v2 branch if you want a clean cut from Go 1.17. This resolves the tension between the plans that want generics immediately and the repo’s current go 1.17 module baseline.

Phase 1 — Performance foundation

This should be the first implementation milestone, because every later feature benefits from it.

1.1 Add an injection-plan cache
Create plan.go with a global cache keyed by reflect.Type, storing precomputed field/property injection metadata. Move repeated struct-tag parsing and reflection discovery out of hot paths.

1.2 Build lookup indexes during context creation
In context.go and registry.go, replace broad repeated matching with prebuilt indexes:

• concrete type -> beans
• interface type -> candidate beans
• bean name/qualifier -> beans
• ordered collection metadata for slice/map injection

This turns current startup from repeated global scans toward registration once, lookup many. That directly addresses the current O(n*m) behavior documented by Glue itself.

1.3 Add positive and negative caches
Cache both successful and failed lookups for:

• interface candidate search
• recursive parent-context search
• runtime Inject(...) resolution

1.4 Add property lookup caching
In properties.go, separate:

• static file/map property cache
• dynamic/provider-backed property cache with invalidation hooks

This phase is the base required by all four plans.

gpt-oss-plan

gpt5.3-codex-plan

opus4.6-high-plan

qwen3.5-plan

Phase 2 — Dynamic configuration and refreshable property injection

This is the most valuable functional upgrade after performance.

2.1 Introduce a richer provider abstraction
Keep PropertyResolver working, but add a superset interface, for example PropertyProvider, with:

• Get(key string) (value string, ok bool, err error)
• Version() uint64 or equivalent invalidation signal
• optional watch support for change notifications

Provide an adapter from existing PropertyResolver so old code continues working.

2.2 Support function-based value injection
Extend value:"..." injection so fields can be:

• func() T
• func() (T, error)
• optionally func(context.Context) (T, error)

This lets property-backed values be lazy and refreshable without mutating struct fields in place.

2.3 Add refresh and invalidation
Support:

• explicit invalidation by key
• provider-version invalidation
• optional watch callbacks for secret/config rotation
• a safe opt-in RefreshableBean callback for beans that need to react to changes

2.4 Add built-in env resolver
Ship an EnvPropertyResolver so environment variables are first-class instead of user-only extension code.

2.5 Add property templates
Support ${key} and ${key:default} expressions, with cycle detection and dependency-aware invalidation.

This is the most practical synthesis of the dynamic-config ideas from all four plans.

gpt-oss-plan

gpt5.3-codex-plan

opus4.6-high-plan

Phase 3 — Typed API modernization without breaking existing users

The plans agreed on type safety, but they differed on how hard to cut over. The safest unified version is:

3.1 Add generic helpers first
Add typed helpers such as:

• Get[T any](ctx Context) (T, error)
• MustGet[T any](ctx Context) T
• Lookup[T any](ctx Context, level int) ([]T, error)

These can wrap the existing reflection core instead of replacing it.

3.2 Add typed factory support
Add a typed factory abstraction alongside current FactoryBean, rather than replacing FactoryBean immediately.

3.3 Keep raw APIs but deprecate them
Document the old Inject(interface{}) and other raw entry points as legacy, but keep them functional.

3.4 Decide Go version policy explicitly
Because go.mod is currently go 1.17, you have two viable paths:

• conservative path: typed helpers behind go1.18 build tags while leaving core compatible
• clean path: ship this modernization in glue/v2 and bump minimum Go to 1.18+ or newer

I would choose the second only if you also want to rename APIs and adopt any everywhere at the same time.

Phase 4 — Profiles, conditions, and bean scopes

Once property refresh and indexing exist, composition features become much easier.

4.1 Profiles
Add:

• WithProfiles("dev", "prod", ...)
• ProfileBean or equivalent conditional registration contract
• profile-aware property overlays such as base + profile-specific files

4.2 Conditional beans
Add a general ConditionalBean interface for non-profile conditions.

4.3 Scopes
Introduce first-class scopes:

• singleton as default
• prototype
• request

Prototype should create a fresh instance per retrieval/injection. Request scope should be implemented as a scoped child/runtime context with explicit enter/exit lifecycle.

4.4 Primary bean selection
When multiple beans satisfy an injection, allow a PrimaryBean or explicit primary marker so ambiguous injection can resolve cleanly.

This phase combines the strongest ideas from the profile/scope proposals while keeping the current singleton/factory model recognizable.

gpt-oss-plan

gpt5.3-codex-plan

opus4.6-high-plan

qwen3.5-plan

Phase 5 — Syntax and ergonomics cleanup

Do this after core behavior is stable, not before.

5.1 Keep old tags, add cleaner aliases
Examples:

• allow qualifier= as an alias for bean-name selection
• allow shorthand/default inject forms
• preserve existing optional and lazy

5.2 Prefer additive ergonomics over hard renames
Internal renames are fine anytime. Public renames should be additive first, with deprecation notices.

5.3 Add a builder only if needed
A builder can help for profiles, property sources, and child contexts, but it is lower priority than caching, config refresh, and profiles/scopes.

This resolves the conflict between “clean up everything first” and “ship meaningful platform features first.” The latter wins.

Phase 6 — Scanning, modules, validation, and graph tooling

This is where I would deliberately choose one proposal over another.

Choose code generation, not runtime scanning.
Glue’s README explicitly notes that Go does not provide Java-style component scanning, so runtime package scanning is the wrong default. Use a small generator such as gluegen to scan packages and emit registration code, keeping startup deterministic and Go-native.

6.1 Add gluegen
Generate a registry file from packages containing injectable types.

6.2 Add graph validation
Add a validation mode that checks dependency satisfiability without fully constructing the app.

6.3 Add graph export
Expose DOT graph output for debugging large contexts.

6.4 Add module/group support
Optional Module grouping can help organize large apps, but should compile down to the same registration machinery.

This phase cleanly merges the “component scanning” ideas while adapting them to Go’s actual constraints.

gpt5.3-codex-plan

opus4.6-high-plan

Phase 7 — Testing, examples, docs, and performance gates

Make this a release criterion, not an afterthought.

Add:

• benchmarks for startup and lookup at 100 / 1,000 / 5,000 beans
• dynamic config refresh tests
• profile activation tests
• prototype and request-scope lifecycle tests
• typed API compatibility tests
• codegen/scan registry tests
• example apps: web app, dynamic-secret app, multi-profile bootstrap

Glue already has a decent test surface, so this phase should extend real coverage rather than inventing a new harness.

Files to change

Primary existing files

• api.go — new interfaces/options, typed/compatibility surface
• bean.go — cached investigation metadata, tag parsing updates
• context.go — indexes, lookup caches, profiles, scopes
• injection.go — new injection execution paths, dynamic property functions
• properties.go — provider chain, cache, invalidation, templates
• registry.go — secondary indexes and profile/scope-aware lookups
• stub.go — compatibility and test stubs

New files

• plan.go — injection-plan cache
• profile.go
• scope.go
• watcher.go
• env.go
• graph.go
• validate.go
• builder.go only if you keep the builder idea
• cmd/gluegen/... if you adopt generator-based scanning

Recommended rollout order

1. Performance/cache layer
2. Dynamic property provider + function value injection
3. Profiles
4. Prototype/request scopes
5. Typed helper APIs
6. Syntax aliases and primary bean support
7. gluegen, validation, graph output
8. Examples, migration docs, benchmark gates

What I would leave out of the first merged plan

These ideas are good, but should not be in the first implementation wave:

• full constructor-injection rewrite
• session/custom scopes beyond request
• decorators/AOP-style wrapping
• broad public API renaming
• aggressive breaking changes to tags

They are useful, but not as foundational as performance, config refresh, profiles, and scopes.

Final recommendation

If you want one sentence version: build Glue vNext around cached injection plans + dynamic properties first, then layer typed APIs, profiles/scopes, and generator-based registration on top, while keeping current tags and interfaces working during the transition.

If you want, I can turn this into a maintainer-ready RFC with sections for goals, non-goals, API sketches, file-by-file changes, and release sequencing.

Summary

After implementing all those features, I found out that opus4.6-high and gpt5.4-thinking are working pretty good together and correct each other. Quality of those models are significantly higher than gpt-oss and qwen3.5.

I added all features to Glue framework and now it is completed.