gengstrand

I am currently focused on an educational site https://www.higherscoresdfs.com/dfs/spa/welcome/ that helps Daily Fantasy Sports fans improve their DraftKings and FanDuel gameplay. We offer strategy advice, player tips, optimized lineups, and player props. We now support both classic and showdown games and have recently added a section offering game outcome predictions for those who do sports trading on prediction markets. We currently support the NFL, NBA, and MLB leagues.

For me, CQL will always mean Cassandra Query Language https://cassandra.apache.org/doc/4.0/cassandra/cql/

From the article.

The French government did not provide a specific timeline for the switchover, or which distributions it was considering.

Got to be Mandrake right?

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.

https://www.higherscoresdfs.com/dfs/spa/welcome/

Here is the pitch.

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.

Good question. Several reasons.

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.

I have blogged about this recently at https://www.exploravention.com/blogs/soft_arch_agentic_ai/

Using AI to predict professional sports outcomes.

https://www.exploravention.com/products/sports/

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/

I am currently building a lot of AI models for predicting both individual athlete and team based performance for https://www.higherscoresdfs.com/dfs/spa/welcome/

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.

It is true that there are significant benefits to monorepo but it comes at a cost. Managing a monorepo is more expensive than polyrepo. For the details behind that claim, check out https://www.exploravention.com/blogs/monorepo/

The question is this. Do the costs of monorepo justify the benefits for your situation? The answer is not always yes.

Kotlin does not lock you in and has not locked you in to IntelliJ. About a year ago, I coded up a Kotlin service using VS Code. See https://glennengstrand.info/software/coding/csharp/kotlin for my description of that including how nice the developer experience was under VS Code. The plugin I used was https://github.com/mathiasfrohlich/vscode-kotlin which works like a charm.

I recently released an AI software architect chat app.

https://www.exploravention.com/products/askarch/

It is an interesting discovery journey on extracting relevant information from both code and documentation with a sufficient density to stay within the context window and extracting efficient criteria from arbitrarily phrased questions.

I really appreciate the overall gist of this blog and find value in the mech suit vs human replacement analogy. The "near zero time" observation is not consistent with my own findings which I have blogged about at https://glennengstrand.info/software/llm/migration/java/type... and covers a more specific use case of service migration. Using LLMs did cut the heads down coding time by two thirds but certainly not to zero.

I recently blogged about the developer experience with server-side Kotlin at https://glennengstrand.info/software/coding/csharp/kotlin so you should know that the IntelliJ folks offer a community edition of their IDE that works great with Kotlin. You don't even need the IntelliJ IDE at all. I was able to code up that Kotlin service using VS Code which was also a great experience. Nothing felt limited or dummied down at all.

I am currently testing the hypothesis that RAG can reduce the likelihood of LLM hallucination when it comes to software architecture (existing or proposed enhancements or tech debt reduction) of complex systems. To that end, I recently launched a web spa https://www.exploravention.com/AskArchitect/ where you can ask the software architect questions about various popular open source projects. I hope that you participate in this experiment.

While I was working on this piece about using LLMs to migrate code https://glennengstrand.info/software/llm/migration/java/type... I experienced a first hand encounter of review fatigue. One of the lines of code in the middle of a LLM generated block was gibberish but not gibberish enough to be caught by the compiler. I study the code before accepting the change but just had a complete blind spot on that line. It was the linter that eventually caught it.

I went with a more clinical approach and used models that were available a half year ago but I also was interested in using LLMs to write unit tests. You can learn the details of that experiment at https://www.infoq.com/articles/llm-productivity-experiment/ but the net of what I found was that LLMs improve developer productivity in the form of unit test creation but only marginally. Perhaps I find myself a bit skeptical on the claims from that Assembled blog on significant improvement.

Has anyone here tried out https://github.com/freeedcom/ai-codereviewer which I suspect is something similar only in GHA form?

This piece reminds me of something I did earlier this year https://www.infoq.com/articles/llm-productivity-experiment/ where I conducted an experiment across several LLMs but it was a one-shot prompt about generating unit tests. Though there were significant differences in the results, the conclusions seem to me to be similar.

When an LLM is prompted, it generates a response by predicting the most probable continuation or completion of the input. It considers the context provided by the input and generates a response that is coherent, relevant, and contextually appropriate but not necessarily correct.

I like the crowdsourcing metaphor. Back when crowdsourcing was the next big think in application development, there was always a curatorial process that filters out low quality content then distills the "wisdom of the crowds" into more actionable results. For AI, that would be called supervised learning which definitely increases the costs.

I think that unbiased and authentic experimentation and measurement of hallucinations in generative AI is important and hope that this effort continues. I encourage the folks here to participate in that in order to monitor the real value that LLMs provide and also as an ongoing reminder that human review and supervision will always be a necessity.

Interesting blog. It seems to be a compendium of advice for all kinds of folks ranging from end user to integration partner. For a slightly different take on how to use LLMs to build software, you might be interested in https://www.infoq.com/articles/llm-productivity-experiment/ which documents an experiment where the same prompt was given to various prominent LLMs asking to write two unit tests for an already existing code base. The results were collected, metrics were analyzed, then comparisons were made. No advice on how to write better prompts but some insight on how to work with and what you can expect from LLMs in order to improve developer productivity.

Whatever happened to ring or donkey?

True but the big selling point for mermaid is the github integration and you can audit the changes to the diagrams via git log -p

https://www.infoq.com/podcasts/architecture-advice-process/ is a follow up interview of the author behind that article.

So the publishers behind IEEE Software asked the authors of The Golden Age of Software for any advancements in software architecture that had occurred in the 2.5 years since they published that book. Mostly, they talked about platform thinking, SOA, OOP, and quality metrics. This was fourteen years ago. Since then, I believe that software architecture has advanced a lot in terms of process and methodology. https://martinfowler.com/articles/scaling-architecture-conve... does a good job of covering these advancements.