Totally agree on this. It has delivered a substantial value for me in my projects. The models are always going to give back results optimized for using minimal computing resources in the provider's infrastructure. To overcome this I see some using/suggesting, running the AI in self correction loops, the pro being least human intervention.
However, personally I have got very good results by taking the approach of using the AI with continuous interaction and also allowing implementation only after a good amount of time deliberating on design/architecture. I almost always append 'do not implement before we discuss and finalize the design' or 'clarify your assumptions, doubts or queries before implementation'.
When I asked Gemini to give a name for such an interaction it suggested 'Dialog Driven Development' also contrasted it against 'vide coding'. Transcript summary and AI disclaimer written by Gemini below
The models are mostly I believe capable of executing however as you rightly indicated 'lazy'. This 'laziness' I think is to conserve resource usage as much as possible as given the current state of AI market the infrastructure is being heavily subsidized for the user. This leads to perhaps the model being incentivized to produce an optimum result that satisfies the user by consuming the least amount of resources.
This is also why most 'vibe' coding projects fail as the model is always going to give this optimum ('lazy') result by default.
I decided to adopt AI assisted coding for a recent project. Not sure what defines 'vibe coding' but the process I ended up was a iterative interaction at a measured pace.
I used Gemini AI studio for this and I was very pleased at the result and decided to open source it. I have completely captured and documented the development transcript. Personally it has give me considerable productivity boost. My only irritation was the unnecessarily over politeness that AI adopts in My take is
AI yields good ROI when you know exactly what you want at the end of the process and when you want to compare and contrast decision choices during the process.
I have used it for all artifacts of the project:
- Core code base
- Test cases
- Build scripts
- Documentation
- Sample apps
- Utilities
Since AI code is inherently bound to face a critical review, we have kept the goal of security at the top. We have taken the following steps for it.
- 1. Code execution is sandboxed
- 2. Access to all built in modules of NodeJS is prevented, with option to whitelist using the server configuration
- 3. Platform APIs which access system (within the sandbox) also need to be whitelisted with explicit permission grants
Yes, we would like to make it ever more secure, with the help of the community and feedback from our customers. Like with any code human or ai there is bound to be bugs, the issue list of even the most popular, major projects out there is a testament to it. We intend to ever make it better for ourselves and for our customers.
Yes this is exactly what it is. I think there is so much haze built around it for last 15 years because corporates started using OSS as a means of viral marketing. Individual developers on the other hand saw it as a status enhancer. In this, the original principle of FSF, 'Free as in Freedom, not Free as in Free Beer' was forgotten completely. This in principle is what you have stated above.
The freedom to choose, not the entitlement to demand was the original promise of OSS
I dont think Zoho was ever acquired. They were and are still are a private company with no external investments. Interestingly the confusion seems to be with Zimbra and here is a blog post on Zimbra acquisition by Zoho themselves.
BASIC was my door to programming and computers. I experienced it in my 7th grade in the late 80s when I had the fortune of one of my friends owning a Commodore 64. What a thrill it was, so many weekend afternoons vanished into thin air...
4GL was a buzz word in the late nineties when I entered software profession. It was pushed by ERP (Enterprise Resource Planning) software majors of that era such as SAP & BaaN.
Even though such software are the core of an enterprise today. Many technologies that they pioneered did not gain mainstream adoption after the entry of Internet software companies such as Google/Facebook/Amazon.
Take for example what is now a buzz "Low code No code", it is a poor ghost of Model Driven Architecture (MDA) - https://www.omg.org/mda/ . Enterprise software always wants to push software to the realm of standard components and modules. That cycle was broken around 2010 due distraction from the smart phone wave.
Other techs of that era - ESB, WSDL, SOAP, SOA, UDDI, BPM, Business Rules, EDI, Data Mapping (all are almost but forgotten). Many of them are getting re-bottled e.g. Microservices
Enterprise software has not had any major breakthroughs since. Glamour of new tech from Internet giants who invent it for their specific purpose is pushed more often than not, on to enterprise systems by other software vendors/consultants pouting it as the new and best. This has made standardization almost impossible and hence kept software always in the "handicraft" mode.
Model-Based Software Engineering still pops up in some environments, like LabVIEW or whatever that Matlab one is (they use it at NASA on some of the critical code, name escapes me). I've done some pretty cool things with Model-Driven Testing but never had a chance to use it as part of my job. GraphWalker [0] for example lets you build a model of an application where nodes are states and edges are actions to get 100% automated coverage (not No Code, but Cool Code). I used it to test HackerNews once in my free time combining it with the Page Object Model in Selenium which worked surprisingly well. You still need to build the framework and now an additional model, but you get all the tests for free.
Matlab Simulink, probably. It's actually pretty neat, but I haven't touched it in over a decade now. It was useful for our embedded systems to have an executable model versus a prose specification document, and then it did get used to feed into the testing routine. Since the models were simpler to understand, confidence in them was higher. Differences in test results could be readily determined to be problems in the system and not the model after a quick analysis of the model ("Yep, that's supposed to be X, not Y" or "Nope, Y is correct, that's an error in the model here.").
I have come to view religions as organisms in an eco-system. The behavior is very analogous. The goal for both is survival and propagation. As within an eco-system, organisms evolve and adopt survival strategies. Religions do the same too. Organisms evolve due to genetic aberration, Religions evolve due to social aberration. In any eco-system, the young organisms are known to adopt harsher survival strategies, in religions you find the younger religions (Abrahamic, at this point of time in history), adopt strategies of violence and coercion. The more tougher to get out of a religion is directly proportional to how young it is. The principles are hard wired for survival, hence more emphasis on mandatory daily/weekly rituals for all in the religion, unlike in older ones where rituals in general are more often than not a domain of the priests. The older religions on the other hand are less virulent and more susceptible to younger challengers. Some organisms in nature beat this challenger possibility by adopting a more distributed structure, there by surviving in spite of assault from challengers. Young religions on the other hand prefer a centralized control structure which helps in keeping the line discipline. As within an eco-system, strategies of some organisms might be damaging to the eco-system as a whole. When it comes to religion, the ecological balance can be obtained only when damaging survival strategies are identified and discarded by the said organism, in other words it just needs to grow up...
It is funny to observe that even a religion is itself the product of, and subject to, and actively conducting evolution exactly the same as biology.
All evelotion is is the axiom or truism "That which works, works."
That statement can't be denied or escaped, and regardless what your mystical feelings are about how unbelievable it is that an eyeball just evolved by itself because that would be magic and magic is impossible but gods are magic that is possible or maybe gods aren't magic...I'm so confused...anyway no matter what you think about all that, there is no way around such a basic statement. You can't not-believe it.
And everything else ultimately flows from that. You can avoid considering it and imagine that there is some unknown other stuff between that and evolution and eyeballs, but you can't actually produce that unknown other stuff if you are ever forced to consider it.
And so it is with any self-oganizing self-modifying system, including organized religions and religious ideas.
You are right that they evolve strategies to perpetuate themselves. That which works, works. If someone had a religious idea to only accept seekers but keep themselves secret and never advertise, not even to their own offspring, that religion would cease to exist within a generation. Anyone still in it after that would have to be in some new religion resulting from a mutation that it's ok to bring in at least some new people by some means or other.
However, personally I have got very good results by taking the approach of using the AI with continuous interaction and also allowing implementation only after a good amount of time deliberating on design/architecture. I almost always append 'do not implement before we discuss and finalize the design' or 'clarify your assumptions, doubts or queries before implementation'.
When I asked Gemini to give a name for such an interaction it suggested 'Dialog Driven Development' also contrasted it against 'vide coding'. Transcript summary and AI disclaimer written by Gemini below
https://gingerhome.github.io/gingee-docs/docs/ai-disclaimer.... https://gingerhome.github.io/gingee-docs/docs/ai-transcript/...