I’m feeling increasingly defeated by AI, and I think the source of that frustration is the gap between what I believe AI can do and what I can actually rely on it to do.
There is no question that modern AI is capable.
An LLM can read and organize emails, analyze information, create presentations, examine a software system, produce an architecture map, build a website, and write thousands of lines of functioning code. In many cases, it can probably get 80–90% of the way toward an impressive result.
My problem is that I’m increasingly interested in the remaining 10–20%.
That is where reliability, consistency, architecture, maintainability, and trust live.
Understanding something is not the same as implementing it
One of the strangest things I have encountered is that I can have an excellent architectural discussion with an LLM.
It can examine a system and explain how its components relate. It can identify duplication. It can recommend reusable components. It can explain software-development best practices. It can create a diagram showing exactly how the system should work.
Then I ask it to implement that architecture.
And somehow the architecture disappears.
The resulting software may function, but underneath the interface I can end up with duplicated logic, inconsistent naming, unnecessary code, disconnected components, or implementations that don't follow the standards we just discussed.
Even stranger, I can then ask the AI to review the code it just produced, and it will correctly identify many of those problems.
That creates a bizarre circular relationship:
The AI understands the problem.
The AI proposes the correct architecture.
The AI implements something different.
The AI reviews its implementation.
The AI correctly explains why its own implementation is poor.
Then we try again.
The problem becomes worse when iterating
Creating the first version of something is often surprisingly easy.
Changing it is where things become difficult.
I can ask AI to build a website and get something recognizable very quickly. But then I might say, “That is the wrong logo. Replace logo X with logo Y.”
It replaces one instance but leaves another.
Now the visual problem is obvious and relatively easy to correct. The architectural problem is not.
Why were there two independent references to the logo in the first place? Should they have referenced the same asset? Did the correction remove the old asset or simply add another one? Is there now redundant code or data sitting behind the interface?
I don't know unless I inspect the implementation.
That matters because I am deliberately using AI so that I don't have to become the software engineer responsible for inspecting thousands of lines of code after every change.
I want to operate primarily at the level of architecture, design, functionality, requirements, and validation.
If I have to inspect every implementation decision the AI makes, I haven't really delegated software development. I have simply moved myself into quality assurance for a programmer whose work I don't completely trust.
Functional isn't necessarily good
This has become one of my biggest concerns.
AI can make something work.
But “it works” and “it was engineered well” are very different standards.
A button can perform the correct function while being implemented badly. A form can save data correctly while duplicating logic that already exists elsewhere. A module can look identical to five existing modules while using completely different internal structures.
I may not discover any of this because I am validating what I can see:
Does the button work?
Does the information save?
Does the interface look correct?
Does the workflow behave properly?
Those are important tests, but they don't tell me whether the underlying system is becoming progressively harder to maintain.
The danger is that every successful iteration may actually be adding technical debt.
Eventually something breaks.
Then I have to trust the same AI that created the tangled implementation to understand the tangled implementation well enough to repair it without creating another problem somewhere else.
Consistency is surprisingly difficult
This is especially frustrating when something has already been established.
Suppose five interfaces use the same font size, save behavior, table design, sorting behavior, keyboard shortcuts, and window structure.
When I ask AI to create the sixth interface, my expectation is that it will recognize those existing patterns and reuse them.
Instead, it may invent another implementation.
It is like training someone at a restaurant to make several burgers using the same buns and then asking them to make another burger, only to discover they went to the store and bought completely different buns because nobody explicitly told them not to.
Technically, the result is still a burger.
Architecturally, it makes no sense.
This is where the predictive nature of an LLM becomes important. An LLM is not necessarily treating the existing implementation as an authoritative system that must be extended. It is generating what appears to be an appropriate solution given its current context and instructions.
That distinction is enormous.
The obvious solution creates another problem: more rules
My response has been to create more structure.
Define standards.
Define terminology.
Define UI rules.
Define architecture.
Define reusable components.
Define validation procedures.
Define governance.
Tell the AI that tables should behave a certain way. Tell it how Save works. Tell it what a header means. Tell it what a modal means. Tell it not to create a second implementation when an existing implementation already provides the capability.
This improves control.
But eventually I have to ask:
At what point am I simply writing an enormous manual explaining how to build the software?
I wanted AI because I am not a professional software engineer.
If I have to understand software architecture deeply enough to specify every implementation constraint, anticipate every possible mistake, define every reusable component, and validate every architectural decision, the value proposition starts becoming questionable.
The AI is supposed to supply some of that expertise.
Instead, I sometimes find myself using the AI to help me write instructions telling the AI how to behave like the expert I thought it already was.
That is an uncomfortable loop.
More control also means more work
I have discovered one method that produces much better results: make the iterations extremely small.
Build one thing.
Test it.
Correct it.
Approve it.
Build the next thing.
Test it.
Correct it.
Approve it.
This dramatically reduces the opportunity for errors to compound.
It also consumes an enormous amount of my time.
Instead of AI accelerating development, I can spend hours prompting, reviewing, testing, correcting, validating, and repeating.
The process works, but only because I am supervising it intensely.
That is not the kind of automation I originally imagined.
The deeper problem is trust
This is ultimately less about whether AI can code and more about whether I can trust what it creates.
A human developer can make mistakes. Of course they can.
But a developer working inside a system should know that a particular variable already exists, that a particular component is reused elsewhere, that a particular service is authoritative, and that changing one piece requires considering its dependencies.
Those things create continuity.
With an LLM, I am never entirely certain how much of that continuity actually exists.
A model may understand a rule today and interpret the same instruction somewhat differently tomorrow. The model itself can change. Context can change. The generated solution can change.
That means natural-language governance has an uncomfortable weakness: the thing interpreting the rules is also probabilistic.
I can write:
Never create a second implementation when an authoritative implementation already exists.
That sounds perfectly clear to me.
But I still need some mechanism that guarantees the rule was actually followed.
Otherwise it isn't really a rule.
It's an instruction.
This is what I was trying to solve
The system I have been building was intended to address exactly this problem.
I wanted to move from:
Discuss → Decide → Capture → Deliver
I wanted to be able to have a natural conversation with an LLM about an idea, make explicit decisions, translate those decisions into a structured implementation package, hand that package to an AI coding system, and then record what happened.
Ideas could begin in a parking lot.
Decisions would become persistent.
Implementations would have history.
Iterations would be recorded.
Relationships and dependencies would be visible.
Eventually, I should be able to ask:
“If I change this, what else will it affect?”
And the system should have enough structured knowledge to answer.
The larger vision was a bridge between human language and machine implementation.
The LLM could provide reasoning, discussion, creativity, and expertise. The surrounding system would provide persistence, structure, authority, relationships, and control.
I still think that idea is important.
What I no longer know is how much of the control can actually be delegated to the LLM.
The question I am left with
I started this believing that better prompts, better context, better governance, and better architecture would progressively make AI development more reliable.
Now I am wondering whether there is a boundary I have been trying to solve with language that cannot actually be solved with language.
Maybe some things should not be instructions to the AI.
Maybe they need to become deterministic parts of the system itself.
Perhaps an AI shouldn't merely be told to reuse an existing Save implementation. Perhaps the architecture should make creating another Save implementation impossible.
Perhaps the AI shouldn't be expected to remember which component is authoritative. Perhaps the system should explicitly identify it.
Perhaps the LLM should be responsible for reasoning and proposing changes, while deterministic software controls what it is actually allowed to change.
That would substantially change how I think about AI-assisted development.
The challenge may not be figuring out how to make an LLM perfectly obedient.
It may be figuring out which decisions should belong to the LLM at all.
And that is where I am now.
I still see enormous potential in AI. I can see what it can do every day.
But I am beginning to understand that capability and reliability are different things.
AI can generate.
AI can analyze.
AI can reason.
AI can produce remarkable first drafts of almost anything.
What I am struggling to build is something different:
a system in which I can trust AI to participate in an evolving piece of work without gradually losing control of the thing we are building together.