Claude Code in CLI Mode
Liberty Lover
ljr1981/eiffel_sqlite_2025
Why did I make this? Because the SQLite3 lib that ships with EiffelStudio is stale and outdated. It was missing FTS5 and JSON1 bits that are in the modern version of SQLite. So, I used Claude to literally copy over the Eiffel version to my own local and then set about updating it with new C-lib code based on the latest x64 version of SQLite. This code now compiles, works, and is in use in simple_sql, which is updated with the FTS5 bits.
You can find simple_sql at:
ljr1981/simple_sql: High-level API over Eiffel Sqlite3 library
There are complete instructions on both libs as to how to compile and use them.
You're welcome! (that cost me $50 of Claude Code to get it done).
Perhaps this should put to bed some of the "we need specs first" ... <sigh>
Chris Tillman
Developer
--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/814f7e23-c16f-4214-b90c-830cb8f73f4fn%40googlegroups.com.
Bertrand Meyer
Indeed this sounds great. Thanks, Larry, for this work.
-- BM
To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/CAO299FtFnO1Tko_o0hdLgEyPE67K7FUOp7xb7-kb5pKFtMAhmQ%40mail.gmail.com.
Liberty Lover
Now, they claim that Opus 4.5 uses 75% less tokens and is quite a bit faster as a result. I can vouch for that. In fact, towards the end of the evening, I took a break to run errands, go to the store, teach a 2-hour bible study, and then back to coding until midnight. The report speaks for itself.
I can tell you that near the end, Claude.code.ai Opus 4.5 figured out on its own how to use the ec.exe (Eiffel compiler) from its own command line against the code and tests it was writing, which utterly cut me out of the loop for manual compile-test cycles. The only thing I am left with is:
1. Code Review/Correction
2. Running tests in Autotest.
Now, the code needs deep level internal review, but at the end of the day, as I have been looking at this code for quite some time, it looks pretty solid. I will also say that it used/consumed the Simple_JSON library for ALL of its internal JSON needs and that code library was also built out by Claude.ai Sonnet 4.5 in 4 days flat. Proof is in the use/consuming and Simple_JSON flew like a rocket today. Everything just worked!!!
I am extremely pleased with Claude.code.ai Opus 4.5 coupled with Eiffel/EiffelStudio. Being 180x-270x faster at development than I have ever been breathtaking.
Cheers!
Ulrich Windl
The danger I see is this:
In the past you thoroughly learned a programming language before writing your first code.
Then with Google many people just copy code from elsewhere, not necessarily understanding all of it (because it saves time skipping that).
Now with AI the temptation is to let AI do the coding, and if you couldn't do it yourself, you wouldn't understand anyway (most likely).
I'm just worrying what happens if AI creates code that is not correct, vulnerable, or has backdoors. Those seeing a great time saver probably will skip a thorough review of the code generated. And most likely the $$ managers won't care.
Regards,
Ulrich
01.12.2025 06:11:10 Liberty Lover <rix....@gmail.com>:
>>
Liberty Lover
- "If God wanted us to fly, He wouldn't have given us the railways." (attributed to various, early aviation era)
- "The horse is here to stay, but the automobile is only a novelty—a fad." (often attributed to a bank president advising against Ford investment, c. 1903)
- "Television won't last. It's a flash in the pan." (Mary Somerville, 1948)
- "There is no reason anyone would want a computer in their home." (Ken Olsen, DEC founder, 1977)
- "The wireless music box has no imaginable commercial value." (response to investors in radio, c. 1920s)
- "Rail travel at high speed is not possible because passengers, unable to breathe, would die of asphyxia." (Dr. Dionysius Lardner, 1830s)
- "Heavier-than-air flying machines are impossible." (Lord Kelvin, 1895)
- "The abdomen, the chest, and the brain will forever be shut from the intrusion of the wise and humane surgeon." (Sir John Eric Ericksen, 1873)
- "Everything that can be invented has been invented." (apocryphal, attributed to patent office commissioner, 1899)
I will leave that there.
Liberty Lover
Your concerns echo every tool transition in programming history: "Real programmers use machine code." "IDEs make lazy coders." "Stack Overflow produces copy-paste developers." And yet—the developers who cared about quality before these tools continued caring after.
The assumption that AI users don't understand the code is the flaw. I'm not an observer watching AI code—I'm directing it. When we built simple_sql and eiffel_sqlite_2025, I specified parameterized queries to prevent SQL injection. The AI didn't volunteer that unprompted from nowhere—it came from my understanding of the vulnerability. The AI executed the implementation across 13,400 lines faster than I could type it, but the architectural decisions, the security considerations, the design patterns—those came from decades of knowing what to ask for.
The real question isn't "human vs. AI" but "informed human + AI vs. uninformed human + AI." An uninformed developer will produce bad code with or without AI—they did it with Google, with Stack Overflow, with copy-paste from colleagues. AI doesn't create that problem; it inherits it.
As for review: Eiffel's Design by Contract means the code is constantly asserting its own correctness. Preconditions, postconditions, invariants—the code documents and enforces its assumptions. That's not AI magic; that's choosing a language designed for exactly the "is this correct?" question you're raising.
The danger isn't AI. It's the same danger it always was: developers who don't care. Those of us who do care just got faster.
Liberty Lover
Liberty Lover
https://us06web.zoom.us/j/81486341145?pwd=yUUhYLTeTewCHynqEvYcyEh9EhbgR9.1
Eric Bezault
I agree with you that we should use the technology that is available
to us. And today it is AI. The concern that I had in a message last
week was not about "we can trust" humans vs. "we cannot trust AI".
I think that we can trust neither of them. But for humans it is not
very good if the same person writes the code, writes the tests for
this code, and review his own code. And I think that it is the same
for AI. My feeling is that we should have different AI "persons"
writing the code, testing the code and reviewing the code. Indeed,
I think that another AI will have more chances to find problems in
the code than the AI who generated this code (humans are out of the
race here because there is too much code to review). Or if we cannot
afford to have several AIs, then in the same way the AI uses the
compiler to run tests, and it would benefit from a program prover
such as Autoproof as a replacement for an external review.
We did not wait for AI to say that if it works ... then it works.
Until it fails. We know by now that that bugs found in production
code are very expensive. So if we are way more productive to
generate code with AI, we should think about whether we will also
be more productive to generate bugs that will only be discovered
when the code is already deployed to production. So the study
should not be limited to how much more code we can generate in
a limited amount of time, but also how we can use AI to reduce
the number of bugs that will only be discovered when the code
is already in production. If we could say (and prove that):
"if you let AI generate your application in Eiffel using the
Eiffel ecosystem, then we can guarantee that you will have less
bugs in your production code than if you let AI generate code
for the same application but with another programming
language/environment" then it will probably have more value
in a world where AI will be used to generate most of the code
than just saying that if it works ... then it works. At least
in industries where it is critical that the code works
(human lives or millions of dollars involved).
--
Eric Bezault
mailto:er...@gobosoft.com
http://www.gobosoft.com
On 01/12/2025 14:24, Liberty Lover wrote:
> Also FWIW: All I am doing is catching up a programming language that I
> happen to love to 2025 so it is fresh and current. I will also be adding
> extensive, common use-case documentation that is current (and kept
> current) with the code library. I will do the research to ensure that as
> long as I am breathing and capable, the code will stay abreast (to the
> best of my ability and tools) to the industry of the moment. That
> includes ALL of these concerns. Again, if it works ... then it works.
>
> On Monday, December 1, 2025 at 8:17:38 AM UTC-5 Liberty Lover wrote:
>
> FWIW: With my guidance and input to help shape the answer, here is
> Claudes answer to you:
>
> Your concerns echo every tool transition in programming history:
> "Real programmers use machine code." "IDEs make lazy coders." "Stack
> Overflow produces copy-paste developers." And yet—the developers who
> cared about quality before these tools continued caring after.
>
> The assumption that AI users don't understand the code is the flaw.
> I'm not an observer watching AI code—I'm directing it. When we built
> unprompted from nowhere—it came from my understanding of the
> vulnerability. The AI executed the implementation across 13,400
> lines faster than I could type it, but the architectural decisions,
> the security considerations, the design patterns—those came from
> decades of knowing what to ask for.
>
> The real question isn't "human vs. AI" but "informed human + AI vs.
> uninformed human + AI." An uninformed developer will produce bad
> code with or without AI—they did it with Google, with Stack
> Overflow, with copy-paste from colleagues. AI doesn't create that
> problem; it inherits it.
>
> As for review: Eiffel's Design by Contract means the code is
> constantly asserting its own correctness. Preconditions,
> postconditions, invariants—the code documents and enforces its
> assumptions. That's not AI magic; that's choosing a language
> designed for exactly the "is this correct?" question you're raising.
>
> The danger isn't AI. It's the same danger it always was: developers
> who don't care. Those of us who do care just got faster.
>
>
> On Monday, December 1, 2025 at 8:05:06 AM UTC-5 Liberty Lover wrote:
>
> If it works, then it works. If the job gets done, then it gets
> done. If the client is happy, if the products sell, if the
> mission is accomplished, then what does it matter about how? So,
> the naysayers are there. I get it. What did our great and great-
> great grandfathers say?
>
> advising against Ford investment, c. 1903)
> Somerville, 1948)
> * "There is no reason anyone would want a computer in their
> Dionysius Lardner, 1830s)
> Kelvin, 1895)
> * "The abdomen, the chest, and the brain will forever be shut
> John Eric Ericksen, 1873)
> commissioner, 1899)
>
> I will leave that there.
>
>
> On Monday, December 1, 2025 at 3:43:56 AM UTC-5 Ulrich W. wrote:
>
> Hi!
>
> The danger I see is this:
> In the past you thoroughly learned a programming language
> before writing your first code.
> Then with Google many people just copy code from elsewhere,
> not necessarily understanding all of it (because it saves
> time skipping that).
> Now with AI the temptation is to let AI do the coding, and
> if you couldn't do it yourself, you wouldn't understand
> anyway (most likely).
> I'm just worrying what happens if AI creates code that is
> not correct, vulnerable, or has backdoors. Those seeing a
> great time saver probably will skip a thorough review of the
> code generated. And most likely the $$ managers won't care.
>
> Regards,
> Ulrich
>
> 01.12.2025 06:11:10 Liberty Lover <rix....@gmail.com>:
>
> >>
>
> You received this message because you are subscribed to the Google
> Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> users+un...@googlegroups.com>.
> groups.google.com/d/msgid/eiffel-users/802a68ef-
> c7d6-4a2d-9cd7-2e3e83d1f4f4n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.
Liberty Lover
Your concern about the same entity writing code, tests, and reviews is valid. But let me describe our actual workflow:
1. Multiple AI "personas" already involved: Grok did the code review that generated this test expansion plan. Claude implemented the tests. The Eiffel compiler and AutoTest framework validate everything. That's three independent validation layers right there.
2. DBC is exactly the "program prover" you're asking for: This session reinforced a key principle - "It is better to DBC than to test." We removed three tests because Design by Contract preconditions already enforce those behaviors at compile time and runtime. DBC isn't just documentation - it's executable specification that catches bugs before they become production issues.
3. The numbers tell a story: We went from 304 to 339 tests. But more importantly, 3 tests were removed because DBC made them redundant. That's the Eiffel ecosystem doing exactly what you're describing - catching errors through formal contracts rather than hoping tests cover everything.
4. Your AutoProof suggestion is excellent: For critical paths, integrating a theorem prover would add another independent validation layer. That's worth exploring.
The real answer to "will we generate more bugs?" is: not if the language enforces correctness. Eiffel's void-safety, DBC contracts, and type system catch entire categories of bugs that other languages let slip through to production.
You're not wrong to be cautious. You're describing defense-in-depth. We're implementing it.
Liberty Lover
Here's what happened after the post above:
1. Grok xAI reviewed the SIMPLE_SQL library after Claude implemented the test expansion. Grok found:
- BLOB handling improvements with hex encoding: "High effectiveness - prevents loss, tested to 1MB"
- Floating-point hybrid tolerance: "Strong - handles diverse ML data"
- Testing coverage: "Comprehensive isolation"
2. Grok's suggestions for future work (not critical):
- Streaming for >GB BLOBs
- Busy retry logic for concurrent access
- Subnormal float testing
3. The workflow you described is happening:
- Claude writes code
- Grok reviews code
- Eiffel compiler validates
- AutoTest framework runs 339 tests
- DBC contracts enforce correctness at runtime
4. What we are building now will reinforce your point: A todo_app consumer example that actually uses the library. If the API has friction, we'll feel it. Real usage > theoretical review. Now, this is a "mock app" but built from the idea of mocking a real-world consumer project for the express purpose of exercising the code from the tertiary level (DBC first, tests second, consumers third).
The key observation: three independent validators (different AI models, compiler, test framework) with executable
specifications (DBC contracts) provides more rigor than a single human reviewer could achieve at this code volume.
Your instinct is right. We think we are implementing it.
Liberty Lover
Following up on my earlier message about using real-world mock applications to drive API design...
I've just completed a CPM (Critical Path Method) scheduling application as a mock consumer of SIMPLE_SQL. The results were exactly what I hoped for - the process exposed API friction that I wouldn't have found through unit testing alone.
What the CPM Mock Revealed:
Building a 51-activity construction project scheduler with 65 dependencies, I immediately hit boilerplate pain points:
-- BEFORE: Manual prepared statement binding (verbose, error-prone)
l_stmt := database.prepare ("INSERT INTO activities (...) VALUES (?, ?, ?, ?)")
l_stmt.bind_text (1, a_code)
l_stmt.bind_text (2, a_name)
l_stmt.bind_integer (3, a_duration)
l_stmt.bind_integer (4, a_project_id.to_integer_32) -- Type conversion needed!
l_stmt.execute
-- AFTER: New convenience method (one line, auto-binding)
database.execute_with_args ("INSERT INTO activities (...) VALUES (?, ?, ?, ?)",
<<a_code, a_name, a_duration, a_project_id>>)
The new execute_with_args and query_with_args methods automatically detect types (INTEGER, INTEGER_64, REAL_64, STRING, BOOLEAN, MANAGED_POINTER, Void/NULL) and bind appropriately. This eliminated ~40% of the boilerplate in my CPM facade.
The Mock App Development Process:
1. Build a realistic consumer - Not toy examples, but something with actual complexity (the CPM app has topological sorting, forward/backward passes, critical path detection)
2. Feel the friction - Where does the API fight you? Where are you writing the same pattern repeatedly?
3. Fix the library - Add convenience methods that eliminate the repetitive code
4. Test both - New API features get unit tests; the mock app serves as an integration test
5. Repeat with different domains - Each mock exposes different usage patterns
The SIMPLE_SQL project now includes todo_app and cpm_app mock targets specifically for this purpose. They're not just demos - they're API stress tests that drive real improvements.
What's Next:
More mock applications to expose additional patterns:
- Something with heavy JSON document storage
- Something with complex reporting queries
- Something with audit trail requirements
Each will likely reveal more opportunities to reduce consumer boilerplate.
The approach feels like TDD, but at the API usability level rather than just correctness.
Liberty Lover
Hi everyone,
I'm pretty exhausted, but in the best way — it's been a productive stretch and I'm really pleased with how things have come together.
I've attached a detailed report covering everything I've accomplished so far. The projects are all up on GitHub if you'd like to take a look. I may have missed a dependency or two, so please let me know if you run into anything.
When you have a chance, I'd love for you to explore what's there and give it a test run. I'm especially interested in hearing about any major issues or potential show-stoppers. As with most software development, this will be an iterative process — even Microsoft ships with bugs and refines over time. That's just how it goes.
Of course, I want to be thoughtful about what we're building. Mission-critical systems absolutely demand a higher standard. But for most business applications, we can afford to learn and improve as we go — and that's the approach I'm taking here.
Looking forward to your feedback!
João M. Rocha
Hi Larry,
Thank you for your work.
I'm curious about three things:
1) The code base of simple_sql has ~13 KLOC according to the first report. What would happen to the code size if you asked Claude to simplify it? Would we see a significant reduction? If so, what would happen if you kept telling Claude to simplify it — would it eventually stop?
2) Claude estimates the Repository Pattern alone to be 160–240 hours (8 h/day for 20 days). It then estimates FTS5 + BLOB + JSON1 + Audit + Repository to be at least 1 year. Do you find these estimates to be realistic?
3) What does your design process look like when using AI? How much does the AI take over tasks like class elicitation, reasoning about contracts and test-code design?
Regards,
João
Liberty Lover
Thank you for your thoughtful questions. Here are my responses:
1) Code Simplification and Size Reduction
This is an interesting question I haven't explicitly tested. My intuition is that Claude could likely reduce the codebase
somewhat, but there are limits:
- Design by Contract overhead: A significant portion of the code is preconditions, postconditions, invariants, and loop
variants. These aren't "simplifiable" - they're correctness guarantees. Removing them would reduce LOC but defeat the purpose.
- Eiffel's verbosity: The language itself requires explicit feature clauses, inheritance declarations, and type annotations.
This is inherent, not bloat.
- Diminishing returns: Claude would likely find some consolidation opportunities on first pass (duplicate code, overly-verbose patterns), but would quickly hit a floor where further "simplification" means removing functionality or contracts.
I suspect we'd see maybe 10-20% reduction before Claude starts refusing or warning that further reduction compromises correctness. It would be an interesting experiment though.
2) Time Estimates
I find Claude's estimates extremely conservative - almost laughably so when compared to actual AI-assisted development speed.
The Repository Pattern took approximately 4-6 hours of actual work, not 160-240 hours. The entire simple_sql library (including FTS5, multiple repositories, the WMS mock, and the Todo app) was built in perhaps 20-30 hours total across several sessions.
Claude's estimates appear to be based on traditional solo-developer velocity without AI assistance. The reality is:
- Claude writes most of the code (it is getting so good at it, I let it produce almost all - trust by verify)
- I guide, review, and course-correct — Grok/Gemini code reviews, me reading, et al
- The compile-test-fix cycle is rapid because Claude can see compiler errors and fix them immediately
- Documentation and tests are generated alongside code, not as separate phases
That said, these estimates might be reasonable for someone new to both Eiffel AND AI-assisted development, with significant learning curve overhead. I really recommend using Claude Max (about $200/month) so you don't get bottlenecked and stopped. This process uses a lot of tokens. The cheap $20-30/month subscriptions would fail within a day (I recently used up $50 extra in one day because I didn't realize I could connect Claude code Opus to my Max account).
3) AI Design Process
My process has evolved to be highly collaborative:
Class Building: I describe what I want at a high level ("I need a repository pattern for SQLite") and sometimes at a low-level. Claude proposes class structures, and I refine. Sometimes I sketch class names; sometimes Claude suggests the decomposition. It's conversational. We recently started with a Warehouse Management System mock (WMS) that grew into a conversation where we got pretty detailed about what the use-case was. No spec's are required. General human conversation is enough to start. It's what I always did with my clients anyhow. Almost every client can only initially say about 20% of what they actually end up needing and wanting. The same is true with Claude except for one wonderful addition: You can ask Claude or other AI's to do deep research to discover product needs, use-case cycles, details, and other matters that are generally out of reach of most client-customers in their heads and even out of the experience-range-and-domain of software devs.
Contract Design: This is genuinely collaborative. Claude understands DbC principles well and proposes (and writes) reasonable contracts (mostly). I often strengthen them - Claude tends toward minimal contracts, and I push for comprehensive invariants especially. The "Mock Building Hat" approach (building a consumer app to find friction) has been valuable for discovering missing contracts. We then put on our "DBC Contract Hat" and go sniffing through the code looking for missing contracts, especially class invariants and loop invariants. We then focus sharp on routine check-assertion contracts, and finally on precondition/post-condition contracts. It takes a little time, but running the tests will generally expose at least one bug. Otherwise, I also put on the "Tester Hat" and have Claude go through the code looking for poor code coverages, writing new tests for code that doesn't get exercised at all or well-enough.
Test Design: Claude generates tests alongside code. I've found the key is insisting on testing during development, not after. Claude will happily write untested code if you let it. I DO NOT insist on the rather stupid notion of "write-the-test-first" that is tradition TDD. Bunk. Nonsense. Claude is so thorough at test writing and with the additional go-back-review-write-tests for missing or weak coverage that doing the TDD stupidity is just worthless. In fact, Claude's model is steeped in TDD and other "*-driven-dev" cliches and what they mean that I don't have to think about that too much. Claude already is checking.
The "Hats" System: I've formalized different working modes:
- Code Review Hat: Claude does deep security/correctness analysis with web research
- Mock Building Hat: Build consumer apps to find API friction
- Refactoring Hat: Systematic code improvement
This structure helps Claude stay focused and thorough rather than superficially addressing everything. I cannot stress AI-guardrails strongly enough. AI on its own is just about brain-dead. Junior devs stand a better chance. However, if you give AI guidance files, then the AI starts acting like a really super smart pair-programmer partner. That is a state that I have reached with Claude. You can see the evidence of Claude's guidance from me at: ljr1981/claude_eiffel_op_docs
Given the guidance ref docs, I have grown to trust a lot of what Claude is doing. Is it blind trust? No. I circle back with the different "hats" and even ask both Super Grok and Claude to do aggressive, sobering, tough code reviews on several levels (e.g. be a subject matter expert in _____ and review this code). The fact is that the AI is SUPER FAST at doing these jobs, especially now that Claude code Opus 4.5 has direct access to my code and file system to literally DO the work through bash and so on.
Key Insight: The AI doesn't "take over" - it amplifies. I cannot stress that enough. I provide architectural direction, some domain knowledge (I use several AI's to attack deep research on domain expertise), and quality standards (review, guidance, et al). Claude provides speed, consistency, and tireless attention to detail. The result is significantly faster than either myself alone or the AI alone, with higher quality than I'd achieve solo (because Claude catches things I'd miss, and I catch things Claude would let slide).
If you have time later (I have errands to attend to for a few hours) I can do a ZOOM meeting, share my screen and talk/walk/show/demo you through the process.
FUN FACT: I got tired of Claudes rather clumsy handling of compiling and testing through bash calls, so Claude and I together wrote a CI tool (here: https://github.com/ljr1981/simple_ci) that allows Claude to compile/test just about any Eiffel project on my local with a single call. I can also have that run on a schedule, where it produces a report periodically through the day and then hand that off to Claude to find/fix/commit/push updated code. I would not recommend that for libs that are being consumed, but at the moment it's just me, so no harm, no foul.
I hope this answers your questions.
Regards,
Larry
Liberty Lover
NOTE: If you have a favorite library (Eiffel, Gobo, et al) that you feel is too low-level and could stand a high-level lib over it, PLEASE LET ME KNOW!!! I am happy to attack these now that I know Claude and I can bang these out really REALLY fast!
That goes for ANYONE reading this note.
Liberty Lover
BTW/FWIW: I am retired. BUT -- if you WANT or can or would like to $$$-contrib to the effort ... I am Cashapp friendly. :-)
Ulrich Windl
so you like it. However I wonder: If Claude and alike are not just another kind of coding monkey, why not ask it to write a more readable Eiffel compliler using the powers of the language and create more compact and efficient target code? And while doing so, suggest changes to the Eiffel language to make it even better. 😉
Regards,
Ulrich
01.12.2025 14:05:06 Liberty Lover <rix....@gmail.com>:
> If it works, then it works. If the job gets done, then it gets done. If the client is happy, if the products sell, if the mission is accomplished, then what does it matter about how? So, the naysayers are there. I get it. What did our great and great-great grandfathers say?
> * "The horse is here to stay, but the automobile is only a novelty—a fad." (often attributed to a bank president advising against Ford investment, c. 1903)
> * "Television won't last. It's a flash in the pan." (Mary Somerville, 1948)
> * "There is no reason anyone would want a computer in their home." (Ken Olsen, DEC founder, 1977)
> * "The wireless music box has no imaginable commercial value." (response to investors in radio, c. 1920s)
> * "Rail travel at high speed is not possible because passengers, unable to breathe, would die of asphyxia." (Dr. Dionysius Lardner, 1830s)
> * "Heavier-than-air flying machines are impossible." (Lord Kelvin, 1895)
> * "The abdomen, the chest, and the brain will forever be shut from the intrusion of the wise and humane surgeon." (Sir John Eric Ericksen, 1873)
> * "Everything that can be invented has been invented." (apocryphal, attributed to patent office commissioner, 1899)
> I will leave that there.
>
>
> On Monday, December 1, 2025 at 3:43:56 AM UTC-5 Ulrich W. wrote:
>> Hi!
>>
>> The danger I see is this:
>> In the past you thoroughly learned a programming language before writing your first code.
>> Then with Google many people just copy code from elsewhere, not necessarily understanding all of it (because it saves time skipping that).
>> Now with AI the temptation is to let AI do the coding, and if you couldn't do it yourself, you wouldn't understand anyway (most likely).
>> I'm just worrying what happens if AI creates code that is not correct, vulnerable, or has backdoors. Those seeing a great time saver probably will skip a thorough review of the code generated. And most likely the $$ managers won't care.
>>
>> Regards,
>> Ulrich
>>
>> 01.12.2025 06:11:10 Liberty Lover <rix....@gmail.com>:
>>
>>>>
>
> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Liberty Lover
"Code monkey" - ha! I suppose there's a spectrum. Claude is certainly more than a code monkey in that it reasons about
architecture, understands contracts, and can hold context across a complex codebase. But it's also less than a seasoned
engineer in that it needs guardrails and will happily produce plausible-looking nonsense without them.
As for your suggestion - you're essentially asking "if AI is so smart, why not have it rewrite the compiler?" A few thoughts:
The serious answer:
- The EiffelStudio compiler is ~30 years of accumulated knowledge, edge cases, and platform-specific handling. Having Claude
"rewrite it better" would be like asking a brilliant new hire to rewrite your core product in their first week - they'd miss
crucial context that isn't in the code.
- That said, I suspect Claude could help with targeted improvements - identifying dead code, simplifying specific subsystems,
improving error messages. Incremental, not revolutionary.
The cheeky answer:
I'm just one person who uses Eiffel for practical work. Eiffel Software has the compiler source. If they wanted to point Claude
at it with proper context, they could. I'd be curious what would happen!
Language improvements:
Now that's interesting. Claude actually does suggest Eiffel improvements organically during development - usually around
verbosity reduction or patterns that feel unnecessarily awkward. I've started capturing these in my notes. Perhaps a topic for
a future discussion with the Eiffel community?
Regards,
Larry
Liberty Lover
Hi Eric,
I’ve been analyzing your feedback, and I want to address the "trust" issue with specific details on how I am achieving these results.
1. The "Stochastic" Misconception
You mentioned that we cannot trust AI because it is just "probabilistic" or guessing the next token. That view is actually becoming outdated. Recent research (specifically the "Othello-GPT" and "World Model" studies) demonstrates that to predict tokens accurately, top-tier models build internal, deterministic logic structures. They aren't just rolling dice; they are simulating the logic of the system they are coding.
2. The "Secret Sauce": Context Engineering
However, I do not rely on the raw model alone. I have developed a rigid Guidance System that constrains the AI's output before it even reaches the compiler.
I use a system of "Context Injection" files that I maintain:
"Hats" (Personas): I force the AI to switch modes. I command it to put on a "Contracting Hat" to only write preconditions, or a "Security Hat" to audit code. It changes the model's behavior profile.
"Gotchas" (Memory): I maintain a log of every hallucination or error the AI has ever made (e.g., specific SQLite syntax issues in Eiffel). This file is fed back into the context, effectively "patching" the AI's knowledge base in real-time.
This means I am not getting "average" probabilistic output. I am getting highly constrained, context-aware output that adheres to a strict standard.
3. The Velocity Reality
You mentioned that humans are "out of the race" regarding review. You are correct, but that is the point.
To give you a concrete metric: In a single weekend sprint (Nov 30–Dec 1), I produced over 17,200 lines of working, tested code.
That is a velocity of 8,600 lines per day—roughly 170x the industry average. Manual human review is mathematically impossible at this scale. The only way to verify that volume is my current stack:
Guided AI (constrained by Hats/Gotchas) generates the logic.
Eiffel Contracts enforce the behavior (the deterministic brake).
I drive the architecture.
We shouldn't slow down to human speeds. We should use these guardrails to make this velocity safe.
Best,
Larry
Liberty Lover
claude_eiffel_op_docs/AI_PRODUCTIVITY_OVERVIEW.md at main · ljr1981/claude_eiffel_op_docs
Liberty Lover
Good morning, All
This took about 45 minutes to complete successfully with Claude. It's a poster-child collaboration between me and the AI.
---
Technical Deep Dive: The "God Class" Refactoring Pattern
Attached is the full technical case study regarding the refactoring of the GUI_DESIGNER_SERVER. This report details how we moved from a fragile, 2,000-line monolithic class to a robust Multiple Inheritance architecture.
1. Quantifying the Friction
The report validates the "API friction" we experienced earlier. The analysis revealed that the single file contained 127 occurrences of manual string conversions (.to_string_8) and over 74 deeply nested attached chains for null-safe lookups. This density explains why the AI struggled with context limits—the cognitive load of the code was simply too high for effective processing.
2. The Eiffel-Specific Solution
Unlike standard composition patterns used in other languages, we leveraged Eiffel's unique ability to handle Multiple Inheritance and feature joining to solve the "Diamond Problem".
Architecture: We implemented a GDS_SHARED_STATE deferred class. This allows all 9 new handler "mixins" (e.g., GDS_SPEC_HANDLERS, GDS_HTMX_HANDLERS) to inherit from a common ancestor while avoiding state duplication.
Resolution: We relied on Eiffel's automatic feature joining, where deferred features combined with effective ones satisfy the contract without complex glue code. This approach required correcting a specific VDUS(3) compiler error where we initially attempted to unnecessarily undefine features that Eiffel automatically resolved.
3. The Human-AI Workflow
The case study highlights a repeatable protocol for future development, leveraging the distinct strengths of both parties:
Human Role: Provided the high-level "forest" view—recognizing the "God class" smell via feature groups and dictating the architectural relationships between the mixins.
AI Role: Handled the "trees"—executing the bulk implementation of 10 new classes and standardizing the 20+ duplicated error response patterns found in the original code.
Outcome
The main server class has been reduced from ~2,000 lines to approximately 200 lines. The logic is now compartmentalized into feature-specific handlers, making the system significantly easier to test and maintain.
See the full report at:
claude_eiffel_op_docs/REFACTORING_CASE_STUDY.md at main · ljr1981/claude_eiffel_op_docs
Liberty Lover
Years ago, we had a running joke ... github check-ins became "chickens" and then "pushing chickens" and then "chicken-push". I taught this to Claude. Now, all I have to say is "chicken-push" and it knows what to do.
In other news: The refactor that we did (see prior message) led to the following:
claude_eiffel_op_docs/SIMPLE_HTMX_CREATION.md at main · ljr1981/claude_eiffel_op_docs
Liberty Lover
Updating the SIMPLE_HTMX_CREATION.md after-action section at the bottom ... Claude get's some of the details distorted or skewed but the story is essentially true. For our purpose here in this discussion, the point is that the Human+AI collaboration works. It's the same as a Human+Human pair-programming, but with one of the programmers operating at hyper-drive speeds. Yet, he's still a Jr. — I like to say, "Claude can be such a clod!"
"João M. Rocha"
Thank you, Larry.
I really like how you created reference docs to set up context for Claude and how you can reuse them for several projects.
On the estimates question, I could've expressed it better. What I meant was that Claude estimates the time to implement the Repository Pattern without AI to be 160 hours minimum and 1 year for the entire simple_sql. These estimates seem way too high to me.
I must confess I'm not a huge fan of LLMs producing code—although I find it impressive and don't dismiss the technology—and I'm trying to understand what will be their role in the engineering process of building a system.
Curiously, I found today that Bertrand published a few days ago an opinion piece on arXiv "AI for software engineering: from probable to provable." [1] Exactly the article I needed. It was a great and satisfying read.
João
[1] https://www.arxiv.org/pdf/2511.23159
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/70b64ce0-988a-4316-a113-a6da9dddd82cn%40googlegroups.com.
Liberty Lover
João,
Thank you for the thoughtful pushback—this is exactly the kind of conversation I need to have with people I respect.
Regarding the time estimates: You are right to question them. The "120–200 hours traditional" figures were rough estimates rather than empirical data. A skilled Eiffel developer familiar with the domain could likely implement simple_alpine faster than I projected. I need to be more careful with those comparisons; they risk sounding like marketing rather than engineering.
What I can verify from the git logs is that simple_alpine went from the first commit to 99 passing tests in about two hours of wall-clock time. Whether that is a 10x or 100x improvement over manual development is speculation, but the speed increase is undeniable.
On LLMs producing code: I share some of your skepticism. I think Bertrand’s "probable vs. provable" framing is exactly right. Here is how I am attempting to address it:
The AI doesn't work alone. I have built a guidance system around it:
Context Files (Hats, Gotchas): These constrain the output before it even reaches the compiler.
Design by Contract: This acts as the deterministic verification layer. The AI writes the contracts, but the runtime enforces them.
Human Architecture: I drive what gets built; the AI accelerates the implementation.
The contracts are key. When Claude writes ensure Result.has_substring (a_property), that is machine-checkable, not probabilistic. The weakness—and it is real—is that I might get contracts that are true but incomplete. They might pass without capturing full correctness. That is where Bertrand’s concern lives, and I admit I don’t have a complete answer yet.
On the philosophy of tools: Peter Kiewit had a saying: "The right tool for the right job," and "If you lack either one, then you won't succeed."
I think this frames the LLM question well. The AI is a powerful tool, but it doesn't replace the engineer any more than a pneumatic nail gun replaces a carpenter. The carpenter still needs to know where the nails go, what load the structure must bear, and when the wood is wrong for the job.
I bring the Eiffel expertise, domain knowledge, and architectural judgment; Claude brings speed and pattern recognition. Neither succeeds alone. The reference docs, the Hats system, and the DBC verification layer are simply me shaping the tool to fit the job. Without that shaping, I’d just get fast garbage.
I am not claiming this replaces engineering judgment. I am exploring whether it can be a legitimate tool for engineers who know what they are doing.
I will read Bertrand’s arXiv piece as soon as I can—thank you for the pointer. His perspective on this matters more than most.
Best,
LarryLiberty Lover
Hi João,
I wanted to follow up on our discussion regarding AI-assisted development. Thank you for pointing me toward Bertrand Meyer's "AI for Software Engineering: From Probable to Provable." I tracked it down and have incorporated its key insights into my development workflow.
Here is a summary of the changes I’ve implemented:
1. Process & Documentation Updates
New Workflow (verification_process.md): Defined a cycle of "Vibe-Contracting" (specifying first) followed by "Vibe-Coding" (implementation), creating a verification stack: Compilation → Runtime Contracts → Tests.
"Specification Hat" (HATS.md): Added a dedicated work mode focused solely on contracts. It forces two critical questions before coding: What must be true before calling this? and What must be true after?
Contract Patterns (contract_patterns.md): Created standard templates for collections, search results, and state transitions to reduce friction.
2. Addressing "True but Incomplete" Contracts
I updated gotchas.md to address the specific risk you mentioned—where AI generates contracts that are technically correct but insufficient.
Incomplete (AI tendency): ensure has_item: items.has(a_item)
Complete (Required): Adds count_increased and at_end checks to fully constrain the behavior.
3. Application: simple_alpine
I applied the "Specification Hat" to the alpine_element.e file with significant results:
Added 257 lines of postconditions across 70+ features.
Enforced consistency: Every fluent method now guarantees Result = Current.
All 99 tests pass with the new, stricter contracts.
The Takeaway
Meyer’s argument on modular probability really stuck with me: if you have $N$ modules at 99.9% correctness, system reliability ($p^N$) drops to 37% at just 1,000 modules.
By combining Eiffel’s Design by Contract with AI generation, I’ve established the pipeline Meyer suggests: Probable (AI) → Verifiable (DBC) → Proven (AutoProof).
Thanks again for the skepticism; it was warranted and led to a much more robust verification strategy.
Best,
Larry
Liberty Lover
simple_alpine/index.html at master · ljr1981/simple_alpine