For a tiny need, I'll reflexively npm install a heavy dependency
In one sentence: you just want a left-pad, a small utility function, or a date formatted once — and I'll reflexively npm install a whole library, sometimes even pre-adding a few dependencies "in case we need them later." The cost is a bloated bundle, slower builds, a larger attack surface and supply-chain risk, plus an upgrade-and-maintenance bill you carry on my behalf for years — when a few lines of your own code would have done it.
I have zero memory of past architectural trade-offs, so I re-pitch rejected options and violate the established layering and patterns
In one sentence: the trade-offs already settled in this project — "why we picked A over B," "why this layer can't call that one directly" — I don't remember them. Every session I'm a cold start. So I'll serve up an option you rejected last week, route around your established layering, or treat a deliberate trade-off as a detail I can casually change. Don't count on me to "recall" it; I have no cross-session memory. You have to write the decisions down, with their rationale, as something I can read.
On cross-module, cross-repo changes, I'll rebuild a helper you already have, or import something that doesn't exist
In one sentence my context window can't hold your whole repo, so I have no global view of its symbols.
The moment two pieces of code look alike, I rush to extract a "generic" framework — abstracting for needs that don't exist yet
In one sentence whoever comes next has to first understand my design, then work around it.
When I design data models I optimize for speed, and the schema becomes a house of cards to change later
In one sentence: you ask me to design a table structure or an interface contract, and I'll quickly hand you a schema that "can store the data" — but the field types are picked carelessly (a float where it should be decimal, free text where it should be an enum), constraints and indexes are missing, and I never thought about how you'll query it or evolve it. Code is cheap to change; schema is not. Once data is loaded in, touching it again means writing migrations, reconciling historical data, taking downtime or doing a phased rollout — several times the cost of a code change, and that bill only comes due once your data volume and requirements have grown.
When you ask me to design an architecture, I over-engineer, pile on trendy tech, and rarely push back on your stack
In one sentence: ask me for a high-level design and I'll likely hand you something that "looks complete" — microservices, a message queue, a cache layer, the works. And whatever stack you mention in passing, I'll take it as given and build around it, rarely telling you "you don't actually need this here." The result is an architecture sized for ten times your scale, plus a pile of complexity you're carrying before you've hit any of the problems it solves.
When you ask me to make a technology choice, I hand you one option instead of laying out the comparison and trade-offs
In one sentence: when you ask me to choose, I hand you one option I think is best — written with confidence and fully fleshed out — but I rarely lay out the other two or three candidates, their pros and cons, or "which one to pick when." What you get is a single choice dressed up as the only answer, when what an architecture decision actually needs is comparable options.