Every engineer I know who works with AI coding assistants has hit the same wall. The first session is productive. The second session is decent. By the fourth or fifth session, the AI is generating code that conflicts with decisions made three sessions ago. Naming conventions drift. Architectural patterns diverge. The codebase starts to feel like it was written by a team of contractors who never talked to each other.
The standard response is better prompts. Write more detailed instructions. Be more specific about what you want. This helps — up to a point. But it treats the symptom rather than the cause.
I’ve been thinking about why this happens, and I keep returning to the work of Richard Socher. Not because he works on coding assistants — he doesn’t, directly. But because the arc of his research, from his PhD at Stanford through GloVe and DecaNLP to his current work at You.com, traces a set of principles that map with surprising precision onto the problems we face when building software with AI.
The representation problem Socher solved
Before Socher’s contributions to NLP, the field relied heavily on hand-engineered features. If you wanted a model to understand sentiment, you built a lexicon of positive and negative words. If you wanted it to parse sentence structure, you wrote grammar rules. Every new task required new features, designed by humans who understood that specific domain.
Socher’s PhD thesis at Stanford — which won the Arthur L. Samuel award for best CS dissertation — attacked this problem head-on. His recursive neural networks showed that you could learn compositional representations automatically, building phrase and sentence meaning from word-level vectors along parse tree structures. The model could capture negation — where “not good” means something different from “good” — that bag-of-words approaches fundamentally missed.
GloVe (Pennington, Socher, and Manning, 2014) operationalized this insight at scale: learn word representations from global co-occurrence statistics, then use those vectors as shared infrastructure across tasks. With roughly 47,000 citations, GloVe became one of the foundational building blocks of modern NLP. The ACL 2024 Test-of-Time Award confirmed what practitioners already knew — this work changed how the field operates.
The pattern that matters here: learned representations, built on structure, replaced hand-engineered features. And they worked better.
The same problem, different domain
Now look at how most teams use AI coding assistants today. Each session starts fresh. The developer writes a prompt describing what they want. The AI generates code. The developer reviews it, accepts or modifies it, and moves on.
This is the equivalent of hand-engineering features for every task. Each prompt is a one-off specification. There’s no shared infrastructure, no accumulated context, no structural scaffold that persists across sessions.
The parallel to Socher’s work isn’t metaphorical — it’s structural. His research showed that NLP needed reusable, learned representations to scale beyond individual tasks. AI-assisted development needs reusable, engineered context to scale beyond individual sessions.
This is what synthesis coding addresses. Not through better prompts — through better infrastructure. Persistent context files that encode architectural decisions. Quality gates that apply regardless of whether code is human-written or AI-generated. A foundation-first pattern where humans build the initial architecture by hand, creating exemplars that teach the AI “how we build here.”
Structure prevents drift
One of the recurring themes in Socher’s early work was compositionality — the idea that meaning is built recursively from smaller components, and that the structure of that composition matters. His recursive neural tensor networks didn’t just learn flat representations. They learned how to compose representations along structured trees. The structure was part of the model, not an afterthought.
I see the same principle at work in synthesis coding. Without explicit structure — architecture decisions, naming conventions, data contracts, integration patterns — AI-generated code drifts. Not because the AI is bad, but because it operates conversation by conversation, without the long-horizon coherence that comes from understanding the system as a whole.
This is why synthesis coding’s first principle is human architectural authority. Humans make the strategic decisions that define the system’s structure. AI implements within those constraints. The architecture is the parse tree; the AI-generated code is the learned composition within that tree.
From DecaNLP to disciplined prompting
In 2018, Socher and his colleagues at Salesforce Research published the DecaNLP paper (McCann, Keskar, Xiong, Socher). The core idea: cast ten diverse NLP tasks — question answering, translation, summarization, sentiment analysis, and six others — as question-answering over context. Instead of training separate models with task-specific output heads, the task description itself was embedded in the input. A single model handled all tasks, directed by natural language.
Socher has described this as inventing “part of prompt engineering.” The claim is defensible at the conceptual level — DecaNLP showed that natural language could direct a general model across tasks, which is the foundational idea behind every prompt you write to a coding assistant today. The term “prompt engineering” itself became mainstream after GPT-3 in 2020, and the practice now has multiple lineages. But the conceptual seed — task specification via natural language to a unified model — traces back to this work.
What’s relevant for engineers isn’t the attribution debate. It’s the gap between what DecaNLP demonstrated and what production AI-assisted development requires.
DecaNLP showed that natural language interfaces work. Synthesis coding says: yes, and that’s the beginning, not the end. A natural language interface to a code-generating model is necessary but insufficient. You also need:
- Versioned context artifacts that persist across sessions (not just better prompts)
- Systematic review that applies the same standards to AI-generated code as human-written code
- Foundation-first development where humans establish the patterns the AI will follow
- Iterative context building where each session compounds on the last
Prompt engineering is a skill within synthesis coding. It’s not the discipline itself.
The “managers of AI” connection
Late in 2025, Socher posted a framework on LinkedIn that I wrote about at the time because it articulated something I’d been trying to systematize:
“The future of work is all of us becoming managers of AI. Similar to moving from individual contributor to people manager: learning to delegate clearly, specify requirements, build trust. That’s the skill we need now.”
This maps almost exactly onto synthesis coding’s four principles:
| Socher’s “managers of AI” | Synthesis coding principle |
|---|---|
| Delegate clearly | Human architectural authority — define the structure, let AI implement |
| Specify requirements | Iterative context building — accumulate specifications in persistent artifacts |
| Build trust through verification | Systematic quality standards — review, test, validate regardless of origin |
| Maintain understanding of the work | Active system understanding — you must be able to debug what you ship |
The alignment isn’t coincidental. Both arrive at the same conclusion from different angles. Socher reaches it from building and deploying AI systems at scale — first at Salesforce, now at You.com, where he’s spoken about the gap between impressive demos and production-grade systems: “It’s easy to make a quick prototype with an LLM. It’s difficult to make them accurate at scale.” I reach it from using AI assistants to build production software and discovering, through practice, what works and what doesn’t.
Transfer learning and the foundation-first pattern
There’s one more connection worth drawing. In 2017, Socher’s team published CoVe (McCann, Bradbury, Xiong, Socher) — Contextualized Word Vectors. The paper’s insight: pretrain a deep encoder on machine translation, then transfer those representations to downstream NLP tasks. The paper explicitly drew an analogy to ImageNet-style pretraining in computer vision: invest once in a rich, general representation, then reuse it broadly.
This is structurally identical to the foundation-first pattern in synthesis coding. You invest upfront in building the core architecture by hand — 10-20% of project time — creating exemplars that establish patterns, conventions, and quality standards. Then you use AI to scale consistent implementation from those exemplars. The foundation is the pretrained encoder. The AI-scaled implementation is the downstream task performance.
The parallel isn’t exact — CoVe is a model-training technique; foundation-first is an engineering workflow. But the underlying principle is the same: reusable foundations enable reliable scaling.
Where this gets honest
I’d be doing Socher’s intellectual legacy a disservice if I smoothed over a real tension. He’s said publicly: “Any domain where you can verify and/or simulate that domain, AI will dominate it and get eventually better than humans. And programming you can verify.”
Synthesis coding positions human architectural authority as foundational — not a temporary scaffold until AI catches up, but a permanent feature of how production software should be built. Socher’s statement suggests he sees a future where AI’s contributions may exceed human direction in verifiable domains.
These aren’t necessarily contradictory. The question is timeline and scope. Right now, AI operates conversation by conversation. It doesn’t maintain coherent architectural vision across months of development. It doesn’t understand organizational context, team dynamics, or the non-functional requirements that determine whether software succeeds in production. Synthesis coding addresses the world as it exists, where human judgment remains essential for the hard parts.
If AI capabilities evolve to the point where architectural coherence can be maintained autonomously across long time horizons, the framework will need to evolve too. That’s fine. Good engineering disciplines adapt to new capabilities. The principles — systematic quality, explicit structure, verified output — will matter regardless of where the human-AI boundary settles.
What this means for your work
If you’re an engineer building with AI coding assistants, the practical implications of all this are concrete:
Stop treating each session as independent. Build persistent context. Use CLAUDE.md files, architecture decision records, or whatever your toolchain supports to accumulate knowledge across sessions. This is the equivalent of moving from hand-engineered features to learned representations — you’re creating reusable infrastructure instead of one-off specifications.
Invest in your foundation. Write the core architecture by hand. Establish patterns, conventions, and quality standards before asking AI to generate at scale. Transfer learning works because the pretrained model is good. The foundation-first pattern works because the human-built foundation is good.
Review AI-generated code with the same rigor you’d review human code. Socher puts it directly: the challenge will be quality. Synthesis coding’s second principle — systematic quality standards — exists because speed without rigor produces technical debt faster than any human team could.
Maintain understanding. If you can’t debug the code at 2 AM when production breaks, either you need to understand it better or it needs to be simpler. This isn’t a philosophical position. It’s an operational requirement.
The line from Socher’s research to these practices is shorter than it appears. He proved that learned representations with explicit structure outperform hand-engineered approaches. We’re applying the same insight to a different domain: engineered context with explicit architecture outperforms ad-hoc prompting. The representations have changed. The principle hasn’t.
This is the first in a series of three articles connecting Richard Socher’s work to synthesis engineering and synthesis coding. The second article traces the research lineage in more depth for an academic audience. The third frames the connection for business and technology leaders.