Why LLMs Matter
A developer's honest take — not hype, not fear. Just what I've actually observed.
It changed how fast I can move
I've been writing code since 2006. I've seen a lot of things get called "game changers" that weren't. AI actually is one — but not in the way most people describe it.
The change isn't that AI writes code for me. The change is that the gap between having an idea and having a working prototype has collapsed. Things that used to take a day of research and scaffolding now take an hour. That's not a productivity boost — it's a different mode of working entirely.
When I built Field Capture Client in Flutter — a stack I was learning — having an AI that could answer "why does Riverpod behave like this" in context, while I was mid-problem, meant I wasn't constantly breaking flow to read documentation. That matters more than most people realise.
It's a force multiplier, not a replacement
People who are worried AI will replace developers are mostly watching the wrong part of the picture. AI is exceptionally good at pattern completion and generating plausible-looking output. What it can't do is understand your system, your constraints, your tradeoffs, or whether the answer it gave you is actually correct for your situation.
That gap — between generated output and correct, contextual, maintainable code — is exactly where developer experience matters most. The people who will struggle are those who hand off that judgment. The ones who thrive are those who use AI to move faster while keeping their own understanding sharp.
I've seen generated code that looked perfect, passed a surface review, and quietly broke something downstream. Catching that requires actually understanding the system. AI doesn't remove that requirement — it raises the stakes for it.
Context is the hard problem
The biggest limitation I kept running into wasn't model quality — it was memory. Every new conversation started from zero. The AI didn't know my project, my conventions, my past decisions, or why something was done a certain way. That friction compounds fast on longer projects.
That's the problem I built AMCS to solve. It's an MCP server that gives AI agents persistent memory — thoughts, project context, learnings, files — so the agent has the background it needs without you restating it every session. Skills and guardrails per project mean you can shape agent behaviour consistently across tools and conversations.
The infrastructure around AI — how you store context, how you inject it, how you keep an agent's behaviour predictable — is where most of the real engineering work lives right now. It's not glamorous but it's what makes the difference between a demo and something reliable.
World models and the responsibility to understand
Concepts and world models will always be difficult for AI unless we can describe them well enough. I see the same problem in how people communicate: two people can use the same words while understanding completely different things. The consequences of that gap can be serious.
For some reason, we are often more willing to accept misunderstanding from an AI than from another person. But who is responsible for understanding: the speaker or the listener? My honest answer is both. The listener has to make an effort, but the speaker cannot assume that their meaning arrived intact simply because they said the words.
We cannot force a particular view into another person's mind. Everyone interprets new information through a world view shaped by their own experiences. That stability is both a benefit and a flaw: years of repetition can create deep expertise, but repetition alone does not guarantee learning. It can also reinforce assumptions that are difficult to question.
AI gives us a different opportunity. At this point in time, we can deliberately reshape its working world view by supplying context, defining terms, showing examples, and correcting bad assumptions. Applying this well means doing more than writing a clever prompt. We need to make our knowledge explicit, test whether the AI understood it, and treat every failure as feedback about either the model's reasoning or the way we communicated the problem.
What shifts when you take it seriously
Research time
Getting up to speed on an unfamiliar API, library, or language is dramatically faster. Dart and Flutter were new to me — I'd have spent weeks in documentation alone without AI assistance.
Boilerplate cost
The parts of development that were tedious but necessary — scaffolding, repetitive structure, first-draft tests — no longer consume serious time. That energy goes toward the interesting problems.
Solo capability
I can take on larger scope as a single developer than was realistic before. Not because AI does the work, but because it reduces the overhead on parts of the work that aren't the core of what I'm trying to build.
Judgment demand
The bar for understanding what you're building actually goes up. You see more output, faster — which means you need to evaluate it faster and more accurately. Sloppy review gets expensive quickly.
The honest limits
AI is confidently wrong often enough that you can't switch off your own understanding. It hallucinates APIs, misses edge cases, and sometimes produces code that looks correct until you run it against real data. The skill of knowing when to trust the output — and when to dig deeper — is not optional.
It also has no stake in your system's long-term health. It won't refuse to generate something that's technically correct but architecturally wrong for your codebase. That responsibility stays with the developer.
None of that makes it less useful. It just means the people getting the most out of it are the ones who treat it as a capable but fallible collaborator — not an oracle and not a threat.
Why it matters beyond the tools
The more interesting shift isn't in any specific tool — it's in what's now possible for a small team or a single developer with domain expertise. The leverage available now would have required a much larger team five years ago.
That changes who can build what, and how fast. For anyone building software — or relying on someone who does — that's worth paying attention to.