If only the AI understands your code, then vendor lock-in and exposure to price hikes will be the least of your problems. I don't think that you will be able to add Claude as the Dev-On-Call to your pagerduty schedule. If you are in an industry that requires due diligence and you get sued for bugs that cause material damage and human suffering, then I don't think the "blame it on Claude" defense is going to land well in court. I cover these topics on https://www.exploravention.com/blogs/soft_arch_agentic_ai/ which is a blog I wrote recently.
Thanks for writing this blog. Others are also starting to notice these impacts and writing about them. I believe that it is important for more voices to be heard.
What resonated most for me was the "Finding Your Threshold" section. Your "Developers need the dopamine hit of creation." is memorable. I have also blogged about this phenomenon at https://www.exploravention.com/blogs/soft_arch_agentic_ai/ but I frame it more as how leaders can help the organization arrive at a healthy and sustainable balance between writing and reviewing code.
I am working on an app that uses old-school predictive AI (i.e. pytorch and scikit-learn) to predict professional sports outcomes in a way that is useful for DFS fans. Here is the landing page.
We seek to empower DFS fans through education about predicting professional sports athlete outcomes. We do that through strategy advice, hot player tips, optimized lineups, and pick’em style game-friendly player props. We're not trying to take away your control or do your thinking for you. We are just here to support you in making better decisions. Let the app do the number crunching so you can get back to competitive play that gets results and is also fun.
That's a type of fatigue that is not new but I hear you, context switching fatigue has increased ten fold with the introduction of agentic AI coding tools. Here are some more types of fatigue that have been increased with the adoption of LLMs in writing code.
There are plenty of articles on review fatigue including https://www.exploravention.com/blogs/soft_arch_agentic_ai/ which I published recently. The focus there is less about the impact on the developer and more about the impact on the organization as letting bugs go to production will trigger the returning to high ceremony releases and release anxiety.
The OP article talks about AI fatigue of which review fatigue is a part. I guess that I would sum up the other parts like this. The agentic AI workflow is so focused on optimizing for productivity that it burns the human out.
The remedy is also not new for office work, take frequent breaks. I would also argue that the human developer should still write some code every now and then, not because the AI cannot do it but because it would slow the process down and allow for the human to recover while still feeling invested.
1. Since the same AI writes both the code and the unit tests, it stands to reason that both could be influenced by the same hallucinations.
2. Having a dev on call reduces time to restore service because the dev is familiar with the code. If developers stop reviewing code, they won't be familiar with it and won't be as effective. I am currently unaware of any viable agentic AI substitute for a dev on call capability.
3. There may be legal or compliance standards regarding due diligence which won't get met if developers are no longer familiar with the code.
How are these libraries curated? I ask because Clojure Land includes Donkey https://clojure.land/?q=donkey which was abandoned a couple of years ago.
Not sure about your information architecture. What is the difference between the web frameworks and web server abstraction tags?
This next question is more for the Clojure community. From https://clojure.land/?tags=Web%20Frameworks we see 34 web frameworks. That seems like a lot to me. Why is there so much "scratching your own itch" because you don't like ring?
The conversation here seems to be more focused on coding from scratch. What I have noticed when I was looking at this last year was that LLMs were bad at enhancing already existing code (e.g. unit tests) that used annotation (a.k.a. decorators) for dependency injection. Has anyone here attempted that with the more recent models? If so, then what were your findings?
I used a graph database in https://www.exploravention.com/products/askarch/ because software architects typically need to understand the dependencies of a complex software system before they can suitably lead that technology. A dependency graph is a good data structure to use when reasoning about dependencies and a graph database is a natural choice for capturing dependency graphs. See https://www.infoq.com/articles/architecting-rag-pipeline/ for more details on the architecture of this AI product. The graph database works very well for this use case.
If you are considering the use of a graph database for AI based search and you are not already familiar with graph database technology, then you should be advised that graph databases are not relational databases. If you cognitively model nodes = tables and edges = joins, then you will be in for some nasty surprises. You should consider some learning, and some unlearning, to do before proceeding with that choice.
I agree. Permit me to rephrase. From this learning adventure https://www.infoq.com/articles/architecting-rag-pipeline/ I came to understand what many now call context rot. If you want quality answers, you still need relevance reranking and filtering no matter how big your context window becomes. Whether that happens in a search that is upfront in a one shot prompt or iteratively in a long session through an agentic system is merely an implementation detail.
Location: Bay Area of California
Remote: yes
Willing to relocate: no
Technologies: https://www.exploravention.com/services/
Résumé/CV: https://www.linkedin.com/in/gengstrand/
Email: https://www.exploravention.com/subscriptions/subscribe/
Like the rest of online mass media, HN covers generative AI a lot but there is still plenty of value in predictive AI. Both forms provide plenty of technical challenges to the AI engineer. I miss the days when you could get a stack trace to when debugging an issue.