Everyone is asking whether AI can write code.
That question is already answered.
The more important question is:
Can AI understand the system it...
For further actions, you may consider blocking this person and/or reporting abuse
Hey, this article appears to have been generated with the assistance of ChatGPT or possibly some other AI tool.
We allow our community members to use AI assistance when writing articles as long as they abide by our guidelines. Please review the guidelines and edit your post to add a disclaimer.
Failure to follow these guidelines could result in DEV admin lowering the score of your post, making it less visible to the rest of the community. Or, if upon review we find this post to be particularly harmful, we may decide to unpublish it completely.
We hope you understand and take care to follow our guidelines going forward!
The important distinction here is that context is not the same thing as a bigger prompt window. A useful agent needs a map of the system: ownership boundaries, data flow, deployment assumptions, and the parts that should not be touched casually. Without that, it can generate correct-looking code that violates the architecture in small ways.
Well said.
The architecture itself becomes part of the context.
An agent can read files, but production decisions depend on things that rarely live in a single file: ownership, contracts, dependencies, verification paths, and operational boundaries.
That's a big part of why we're exploring Workspace Intelligence as a separate layer.
Workspace intelligence is the phrase I keep coming back to. File context tells the agent what exists; workspace context tells it what matters. Ownership, dependency contracts, risk, and verification paths are the difference between a correct patch and an acceptable change.
I like that distinction.
Files describe implementation.
Workspace Intelligence describes significance.
Two services may look similar in code, but one sits on a critical path, has strict ownership boundaries, and requires release verification.
The agent needs to understand both the code and the consequences of changing it.
Yes — significance is the missing layer.
Two files can look equally important to a model and have completely different operational meaning. One might be a demo path; the other might sit on billing, auth, or release verification. The agent needs that map before it can make safe changes.
That's a great way to frame it.
Implementation tells the agent how something works.
Workspace Intelligence tells it why it matters.
As agents move from answering questions to making changes, that distinction becomes critical.
the "more context is not better context, the issue is missing structure" line is the part i'd underline. a million tokens of source still can't tell the agent what's currently blocked or which command is safe right now, because that isn't in the code, it's in the state.
the distinction i keep hitting is between the structure you can pre-model and the state you can only observe live. ownership, dependencies, release gates, those are static enough to put in a workspace model and trust. but your own redis example is half static, half live: "auth-api depends on redis" is structure, "redis is down right now and readiness is blocked" is runtime state that was true zero seconds ago and might not be true now. the workspace model gets the first half; the second half has to be read fresh every time or it's just a confident stale answer. so the failure i'd watch for is the model trusting a workspace fact that was true at indexing time and acting on it after it went stale, same shape as trusting a cached value instead of re-deriving it.
where do you draw the line between what gets baked into the workspace model and what has to be re-read live at decision time? feels like that cut is the whole reliability story.
That's exactly the line we're thinking about.
We increasingly see the workspace model as a source of structure, not a source of truth for live state.
Ownership, dependencies, contracts, architecture boundaries, release policies, and verification requirements change relatively slowly and can be modeled.
Runtime health, service availability, deployment status, active incidents, and readiness signals are state. Those need to be observed, not remembered.
The reliability challenge is making agents reason across both:
Structure tells the agent what matters.
State tells the agent what is true right now.
Most failures seem to happen when those two get mixed together.
"structure tells the agent what matters, state tells it what's true right now" is the cleanest split i've seen on this. the one thing i'd add is that the mixing isn't symmetric, it fails hard in one direction and just wastes cycles in the other.
treating structure as state is the safe-but-wasteful mistake: re-deriving ownership and dependencies live every call when they change monthly, slow, but never wrong. treating state as structure is the dangerous one: a readiness signal or a health check that was true at model-build time gets baked in and trusted later, and now the agent is reasoning confidently off a fact that expired. same shape as trusting a cached value instead of re-reading it. the failure isn't "they got mixed," it's specifically "something live got promoted into the slow layer and nobody marked it as perishable."
so the rule i'd reach for is less "keep structure and state separate" and more "every fact carries a freshness contract", structure is allowed to be remembered, state must declare a TTL or be re-observed at decision time, and the bug is any state-flavored fact sitting in the structure layer with no expiry. curious whether the workspace model tags that distinction explicitly, or whether it's left to the agent to know which fields are perishable.
I think that's a really useful way to think about it.
We already treat freshness as a first-class concern for workspace artifacts and evidence. Reports carry freshness metadata, graph changes propagate staleness, and verification can fail on stale evidence.
What we don't model explicitly yet is freshness at the fact level.
I like your framing of a "Freshness Contract" where each fact declares whether it's durable, derived, evidence-backed, live, or requires verification before use.
That feels like the natural next step, because it removes the burden from the agent to infer which facts are safe to remember and which must be re-observed.
Definitely something worth exploring further.
the part that stands out in what you already have: artifact-level freshness is solved (metadata, staleness propagation, verification failing on stale evidence), but fact-level isn't. that gap is the whole thing, the agent inherits a fresh report and then extracts facts from it that quietly outlive the report's freshness window. the contract just pushes the property you already track on artifacts down to the granularity the agent actually reasons over. feels less like new infrastructure and more like extending what you've got one level down. good thread.
Exactly.
That's the interesting part.
It doesn't feel like a separate feature—it feels like a natural extension of the same model, applied at the level where agents actually reason.
System understanding is where most coding-agent demos quietly break. Generating a migration is easy compared with knowing which service owns the contract, which tests are meaningful, and which old behavior users still depend on.
That's the distinction we're focusing on more and more.
Generating changes is an AI capability.
Understanding the system those changes affect is a Workspace Intelligence problem.
Production systems need more than code awareness—they need ownership, dependencies, impact, and verification context.
That's where many impressive demos hit reality.
Exactly. Code generation is only the visible layer. The harder product problem is giving the agent enough system context to know whether the change is safe, owned, testable, and worth making in the first place.
Well said.
The challenge isn't just generating the next action.
It's grounding that action in ownership, dependencies, contracts, verification requirements, and change impact.
That's increasingly where we see Workspace Intelligence becoming a critical layer between AI agents and production systems.
Workspace Intelligence is a good name for it. The agent needs a map of ownership, dependencies, contracts, and verification paths before it edits. Otherwise it can produce syntactically good code that is organizationally wrong.
The files-vs-relationships cut is the right one, and "workspace intelligence" as a shared source of truth is the part I'd want to build. The question that decides whether it helps or hurts: what keeps the workspace model in sync with the actual system? A structured context layer that drifts is more dangerous than no layer, because the agent stops reverse-engineering the repo (which at least reflects current reality) and starts trusting a map that may be a release behind. The Redis example is the safe case, it's a live failure the health check already caught. The hard case is the workspace model that says "service X owns this contract" three weeks after ownership moved, and the agent confidently makes the wrong change because the structure told it to. So the open question for me is less how you generate the workspace model and more how you keep it from going stale, is it derived fresh from the system on each read, or is it a maintained artifact that can lag what it describes?
That's exactly the failure mode we're trying to avoid.
We don't think of the workspace model as a manually maintained knowledge base.
The goal is for it to be largely derived from observable system artifacts: repositories, contracts, dependency graphs, CI evidence, verification reports, runtime metadata, and workspace policies.
In that sense, the model should be treated more like a build artifact than documentation.
If reality changes, regeneration should produce a different model.
The trust boundary is important too: structure can be modeled, but live state still needs to be observed at decision time.
A stale workspace model is a bug. A trusted stale workspace model is a production risk.