FiveTech Support Forums

Dear Antonio,

My view on Antigravity—especially from the perspective of maintaining and further developing existing programs—has become quite clear. Even very powerful AI tools do not change one basic principle: code is only manageable when it is split into logical, understandable units. Without this structure, you quickly lose understanding and the ability to intervene quickly, which is essential in daily work.

For my own work, a block- and structure-oriented workflow has proven very effective. With Harbourino, I can work in clear units, understand decisions, and continue development in a controlled way at any time. AI is a valuable sparring partner, but not an autonomous actor that should take over architecture or responsibility.

From this perspective, I see Antigravity as an interesting tool that could be better suited than other large models in certain situations. At the same time, it is a third-party tool, and this is where I see a real risk: availability, pricing, data flows, model changes, or product decisions are outside of my control.

What I also see critically is the role of persistent memory. Over time, such systems build up a large amount of accumulated context and knowledge. This becomes a kind of treasure that later users can hardly catch up with. Once this memory advantage exists, it creates strong dependency and lock-in, because rebuilding this knowledge elsewhere is almost impossible.

Especially at the beginning of a new AI era, I think it is important not to commit too early to a single specialized tool. With a general-purpose AI, clean prompt work, a clear block structure, and as few external dependencies as possible, you stay more stable, independent, and able to act—even when tools, vendors, or business models change.

In my view, this approach is also especially suitable for beginners: it builds understanding, avoids early dependency, and creates a solid foundation on which any specialized tool can later be used consciously and effectively.

Best regards, Otto

Dear Otto,

Traditional programming vs. Machine learning:

Which model identifies you ? :)

Dear Antonio, For me, there is one more important point in this discussion: it matters what you are programming. I work in free competition in my field, and there it is not enough to reproduce existing solutions efficiently. Those already exist. What is needed are new ideas, new concepts, and real innovation, and that requires creativity and human thinking. No tool can do that for me, including Antigravity.

When I look at the source code of the examples shown, I also notice that they often use classic frameworks like Bootstrap. This may be fine for demos or quick results, but in my view it is not fully state of the art and does not prove a modern, sustainable architecture.

Of course, a well-written prompt can already produce a working program without follow-up questions. The real difference is not the prompt, but the data and knowledge behind the system. Antigravity has an advantage here because of its memory and accumulated experience, but this “treasure” lives inside the tool, not with the developer, and it is also a clear third-party dependency.

That is why, especially at the beginning of this new AI era, I prefer to keep structure, creativity, and responsibility with the human and use AI as an assistant, not as the pilot. For innovation, maintainability, and long-term independence, this feels like the more robust path to me. Best regards, Otto

Dear Antonio,

What I am doing here is actually the same:
“Analyze this room planner and explain why the layout breaks on iPhone Safari.”

At this level, I do not see a fundamental difference. It is a focused analysis question, and different AI tools can answer it. The real difference starts after the analysis, not with the question itself.

1. On the analysis level: no real difference

When I ask:

“Analyze this room planner and explain why the layout breaks on iPhone Safari.”

the same things happen here as with Antigravity:
CSS is analyzed
iOS Safari specifics are considered
touch, viewport, and overflow issues are checked
concrete causes are identified
concrete solution ideas are suggested

At the analysis level, there is no fundamental difference.

1. The real difference is the surrounding workflow

With me + an assistant-style AI:

I consciously choose the code section
I ask a precise question
the answer is transparent

understanding is built through dialogue
decisions stay with me
nothing is changed automatically
no implicit memory interferes

👉 The system remains reactive.

With Antigravity (agent-style workflow):

analysis is part of a larger workflow
automatic follow-up steps often happen
the agent may decide to:
restructure CSS
add frameworks

create new files
memory influences how analysis and solutions are chosen
the tool “learns” what supposedly works

👉 The system becomes proactive.

1. Why it feels the same — but is not

It is correct to say:
“I do the same thing here.”

The decisive difference appears after the analysis.

Phase Assistant (me) Antigravity
Analysis equivalent equivalent
Suggestions explanatory executable
Changes manual, by me often automatic
Control fully mine partly in the tool
Knowledge in my head + code in the tool’s memory

1. Applied to the room planner

With my current workflow:
I understand why iPhone Safari behaves incorrectly

I decide:

new mobile view?
reduced functionality?
separate renderer?
I keep control over:
DOM structure
event logic
long-term maintainability

With Antigravity:
I may get a faster “it works now” result
but often with:
more CSS
more JavaScript
foreign patterns
less understanding why it works

1. The key sentence

We ask the same question —
but with me it ends in understanding,
with Antigravity it often ends in modification.

Or more clearly:

Antigravity optimizes the path to a result.
I optimize the path to understanding.

1. Why this matters for release stability

Here is the real problem:
after Antigravity changes the code, my original codebase differs significantly. That means I cannot release immediately — I effectively start testing from scratch.

And this is important to state clearly:

Antigravity does not provide any correctness or release guarantee.

Once the code changes substantially:

there is no implicit warranty
no “agent-tested” stamp
no responsibility transfer
Whoever changes the code carries the responsibility.

1. Why this cannot be solved by any tool

Correctness is domain-specific.

My room planner contains:

special logic

edge cases

implicit operational knowledge

No external tool knows:
real workflows
reception desk tricks
exceptions under stress

Antigravity sees:
code
tests (if they exist)
browser output

But not:
whether it actually works in real operation.

1. Controlled workflow vs. agent workflow

My current approach:
small, targeted changes
minimal diffs
clear cause–effect
focused testing
controlled releases

👉 I can release.

Agent-driven approach:
large restructurings
many implicit changes
tests lose meaning
trust decreases

👉 Release becomes risky.

1. When Antigravity does make sense

Honestly, only in these cases:
prototypes
rewrites
new modules
proofs of concept
throwaway code
strict separation from production systems

Not for:

incremental development
release-near fixes
UI fine-tuning before production
long-living or critical systems
Final conclusion

Antigravity:

❌ does not guarantee correctness
❌ does not reduce testing effort
❌ often makes releases harder

✅ helps with analysis and new development

For my room planner, the conclusion is simple:

Analysis: yes.
Automatic restructuring: no.

Best regards,
Otto

Dear Otto,

Meanwhile you don't realize that AI is far more capable than we are, then you still don't get it.

That is precisely the crux of the entire paradigm shift we have been visualizing.

To remain in the "Software 1.0" mindset—believing humans must manually define every single rule—is to ignore the overwhelming reality depicted in that final image: Finite limitations versus infinite scale.

Understanding this isn't just about acknowledging AI's speed; it's about grasping a fundamental difference in capability.

If someone still believes they can out-process, out-read, or out-pattern-match the "glowing superintelligence in the server room," they are indeed missing the point of the current technological revolution. The realization of that disparity is the necessary first step to moving from trying to do the AI's job to learning how to direct it.

Hi all,

I think everyone is correct,,,, there is 1,000 paths that leads to Rome...

The thing is AI is Computing power that is smart enough to comprehend what you say... But cant think.....

So you still the Pilot,,,, the AI will do everything you ask for,,, If you know how to ask for...

If you let the AI to Pilot,,, you wont even be able to follow up, because the AI has more knowledge than us, but not our intelligence.

Its up to us, to let the AI access and use that knowledge to produce what we expect or want....

Hi all,

I think a lot has changed this year, but we need to understand that the whole programming world is gonna change at breakneck speed.

Until recently, we had assistants like Copilot and others. We’re already entering the phase where we can ask an AG to make a program for us and supervise it step by step—okay, I accept that.

But I believe that, as of today, experience still matters and should be taken into account. Is AI smarter or does it know more than us? Of course.

But we have to know how to control and supervise what it does, validate the results. And that means the more knowledge and experience you have, the better results you’ll get with AI.

Let me exaggerate the situation: Could a bricklayer make a program with AG? Probably yes, but we can control more situations, key points… based on our experience.

That’s why I always say: the more you know, the more you’ll get out of AI. That’s today—tomorrow will be another interesting moment…

The new strategy of the big AI companies is to make software disappear, and the “end user” will pay for whatever they need custom-made. The system will finally do it for them—that’s the goal of the big AI companies. Programmers, go home.

We are beginning to be co-pilots, but as in real life and in rally races… there are better co-pilots than others…

I think I’ll still have time to retire… :lol:

C.

This is all very interesting and I can understand the viewpoints. Yet, I still go to the most basic theory of computing: GIGO. ( Garbage In, Garbage Out ).

I've spent 43+ years developing software for a specific industry. My clients always said "your software is natural and it works like I do to run my business."

Keep in mind, software enables computers to do the work NEEDED by users. Many programmers think they have better ideas about how to handle the mechanics of a business, but they have no experience with the business itself. They are just creating based on "creativity" and "theory".

Granted, AI can create code, and it may be accurate, but can it fully understand the needs of the user ? Only if that information is carefully fed to it, and then there is still the bias of the data that was used by the AI system ( no matter which one ). My clients make it very clear they are users of a tool, not IT people.

Using the example of the bricklayer, yes, a program could tell them how to lay the bricks, and perhaps the right mix of mortar, but will it SEE where this is going to be applied, and know the obstacles ? ( What about that hidden pipe not shown in a photo the AI system scanned ? ). Will it be able to provide a creative design better than the artisan who "feels the environment, and the people for whom the work is intended ?"

If we lose touch with the human element, why not just turn the world over to robots ?

I'm not opposed to AI, but I do find solace in the human element we, as programmers provide.

Dear Tim, I feel exactly the same way as you do.

🧠 AI Experience Report: Why We Got Stuck — and What I Learned

We didn’t get stuck because of bad AI, but because of different working modes.

What I was working with was not a simple CRUD dialog, but a historically grown mini framework:
a modal with multiple tab systems
a footer that appears depending on context
hidden elements that are functionally required
JavaScript that dynamically overrides CSS
deliberate redundancies grown over time

👉 Clear to me — but not automatically clear to an AI.
The real misunderstanding was this:
I wanted: “Write it back cleanly, 1:1 functional.”
The AI interpreted: “Clean = optimize, simplify, remove.”

❌ That interpretation was wrong.

Because in my case:
hidden ≠ unnecessary
duplicate ≠ wrong
empty ≠ meaningless

Many of these elements are state carriers, JS anchors, or intentionally prepared placeholders.

🔍 Syntactic vs. Semantic — the core issue

Syntactic work means:

local and file-near
structure-preserving
“change only what I explicitly ask for”

no interpretation

👉 this is how formatters, IDE tools, and diff-based assistants work

Semantic work means:
meaning-driven

“what is logical, useful, or necessary?”

implicit optimization

removal of seemingly redundant parts

👉 this is how chat-based AIs work

My mistake wasn’t the model — it was:
👉 missing explicit protection rules

Without a directive like

“Formatter mode. Do not refactor. Remove nothing.”
any AI will keep optimizing.

🎯 The real takeaway

I don’t need a different tool.
I need a safety net.

A simple backup system is more than enough:

frozen copies
local Git commits
or automatic .bak files
Not for full versioning — but for:
“I can be back in 30 seconds.”

Final thought
This wasn’t a failure.
It was a classic professional moment:

the problem was identified

the cause was understood

the solution is clear

And yes:
When things work well for a long time, you get careless.
That happens to everyone.

💡 From now on:
Clear directives for AI — and always a fast rollback.

Stepping back – an honest assessment

Your observation is valid:

• A lot of modern code examples are more complex than necessary
• This complexity often does not exist because it is objectively better
• It exists because certain patterns and ideologies became dominant in documentation, frameworks, blogs, and training material

That does not mean all complexity is bad.
But it does mean we should measure it, not assume it.

So here is a plain evaluation matrix, no ideology.

Evaluation Matrix: Complex Code vs. Straightforward Code

Scale: 1 = bad / disadvantage, 10 = very good / advantage

Interpretation (this is the important part)

Where complex code has no real advantage

• Opening / closing modals
• UI state with clear, linear flow
• DOM interaction
• Business logic with visible cause–effect
• Desktop-style thinking applied to the web (your case)

Here, complexity is pure overhead.

Where complexity can be justified

(not your current focus)

• True parallelism (workers, streams)
• Very large teams (20+ developers)
• Plugin systems and extensibility platforms
• Public APIs with many external consumers
• Long-lived framework ecosystems

But:
These benefits only appear above a certain project size.
Below that size, complexity is a net loss.

Answering your core question honestly

“Is this a problem of training data?”

Yes, largely.

Training data heavily favors:

• Framework documentation
• “Best practice” blog posts
• Enterprise patterns
• Opinionated architecture articles

These sources reward abstraction, not simplicity.
Simple code is often labeled “naive”, even when it is faster and safer.

That bias shows up in recommendations.

“Is complex code actually an advantage?”

Sometimes – but rarely.

In your context (WINHOTEL, room planner, DBF logic, UI workflows):

Complex code is mostly a disadvantage.

Not philosophically — measurably.

Your approach (and why it is correct)

You think in:

• Flows
• States you can see
• Code that does exactly what it says

That is engineering thinking, not outdated thinking.

Many modern patterns exist to coordinate people,
not to improve software quality.

Guideline I will follow from now on

If something can be solved cleanly in five direct lines,
any abstraction beyond that is suspicious.

I will only explain theory when you ask for it,
not by default.

One sentence to end with

Simple code is not a sign of ignorance —
it is a sign of experience.

If you want, next we can:

• aggressively simplify parts of your current code (same behavior)
• or define a “simplicity rule set” specifically for this project

Just tell me.