I spent a year building a 300k‑line production platform alone using AI‑assisted engineering. It worked — but only when AI was cheap and predictable. As model behavior shifted and costs rose, the entire system began to break in ways most teams haven’t experienced yet.
This essay is a field report from operating at the edge:
• how deterministic workflows collapse under model churn
• why reasoning‑first models break text‑pattern assumptions
• why AI engineering economics now resemble aviation, not cloud
• what architecture survives when the foundation keeps moving
If you’re building AI‑native systems, this is a look at the failure modes that are coming for everyone.
I’m not offended — just to clarify the context.
I’m not a native English speaker, so I sometimes use AI to help with phrasing or structure. The ideas, experience, and arguments are mine; AI just helps me express them more clearly for an English‑speaking audience.
I don’t see anything wrong with that. For many non‑native speakers it’s simply a tool that removes friction and lets us focus on the actual content instead of grammar. The engineering work and the analysis in the article are based on real experience, not generated text.
If you disagree with the conclusions, I’m happy to discuss them — that’s why I posted it.
I've always been skeptical of the celebrity engineering managers/software entrepreneurs like Graham, DHH, Atwood, Spolsky [1], etc. Just because you made and marketed one or even two successful products doesn't mean you have any useful generalizable advice.
Today people who made something with AI think they have something profound to say about their experience but they don't.
All the projects I do now have a significant amount of input from AI assistants but I am going to post "Show HN: my heart rate variability biofeedback webapp"
and not add "... that i vibe coded" because the latter one codes me as yet another NPC.
(e.g. if I am more successful as AI-assisted developer than some people it is not because I know anything about AI-assisted development which is interesting or generalizable, but it is because of the toolbox I've been using in a lifetime of software development!)
[1] Carmack is a true genius who is the exception that proves the rule
I’m not trying to present myself as a guru or a celebrity engineer. My background is in product and technical leadership, not in being the “hero coder.” I didn’t build an AI system — I built a real production platform where AI was one of the tools in the workflow.
The article isn’t meant to be profound. It’s just a practical report from someone who pushed AI‑assisted development into a full product environment and saw where it helped and where it broke. I shared it because some of these patterns might be useful to others, and because I’m also interested in learning from people who’ve taken different approaches.
If your experience is different, I’d genuinely like to compare notes — that’s the whole point of posting it here.
I spent a year building a 300k‑line production platform alone using AI‑assisted engineering. It worked — but only when AI was cheap and predictable. As model behavior shifted and costs rose, the entire system began to break in ways most teams haven’t experienced yet.
This essay is a field report from operating at the edge: • how deterministic workflows collapse under model churn • why reasoning‑first models break text‑pattern assumptions • why AI engineering economics now resemble aviation, not cloud • what architecture survives when the foundation keeps moving
If you’re building AI‑native systems, this is a look at the failure modes that are coming for everyone.
you apparently also built an AI-written article. rolling my eyes rn
I’m not offended — just to clarify the context. I’m not a native English speaker, so I sometimes use AI to help with phrasing or structure. The ideas, experience, and arguments are mine; AI just helps me express them more clearly for an English‑speaking audience.
I don’t see anything wrong with that. For many non‑native speakers it’s simply a tool that removes friction and lets us focus on the actual content instead of grammar. The engineering work and the analysis in the article are based on real experience, not generated text.
If you disagree with the conclusions, I’m happy to discuss them — that’s why I posted it.
I've always been skeptical of the celebrity engineering managers/software entrepreneurs like Graham, DHH, Atwood, Spolsky [1], etc. Just because you made and marketed one or even two successful products doesn't mean you have any useful generalizable advice.
Today people who made something with AI think they have something profound to say about their experience but they don't.
All the projects I do now have a significant amount of input from AI assistants but I am going to post "Show HN: my heart rate variability biofeedback webapp" and not add "... that i vibe coded" because the latter one codes me as yet another NPC.
(e.g. if I am more successful as AI-assisted developer than some people it is not because I know anything about AI-assisted development which is interesting or generalizable, but it is because of the toolbox I've been using in a lifetime of software development!)
[1] Carmack is a true genius who is the exception that proves the rule
I’m not trying to present myself as a guru or a celebrity engineer. My background is in product and technical leadership, not in being the “hero coder.” I didn’t build an AI system — I built a real production platform where AI was one of the tools in the workflow.
The article isn’t meant to be profound. It’s just a practical report from someone who pushed AI‑assisted development into a full product environment and saw where it helped and where it broke. I shared it because some of these patterns might be useful to others, and because I’m also interested in learning from people who’ve taken different approaches.
If your experience is different, I’d genuinely like to compare notes — that’s the whole point of posting it here.
[dead]