symfrog

We have had LLMs for much longer than 3 years.

I would estimate that out of every 200 lines of code that Claude Code produces, I notice at least 1 issue that would cause severe problems in production.

In my opinion these discussions should include MREs (minimal reproducible examples) in the form of prompts to ground the discussion.

For example, take this prompt and put it into Claude Code, can you see the problematic ways it is handling transactions?

---

The invoicing system is being merged into the core system that uses Postgres as its database. The core system has a table for users with columns user_id, username, creation_date . The invoicing data is available in a json file with columns user_id, invoice_id, amount, description.

The data is too big to fit in memory.

Your role is to create a Python program that creates a table for the invoices in Postgres and then inserts the data from the json file. Users will be accessing the system while the invoices are being inserted.

---

The closer you get to releasing software, the less useful LLMs become. They tend to go into loops of 'Fixed it!' without having fixed anything.

In my opinion, attempting to hold the hand of the LLM via prompts in English for the 'last mile' to production ready code runs into the fundamental problem of ambiguity of natural languages.

From my experience, those developers that believe LLMs are good enough for production are either building systems that are not critical (e.g. 80% is correct enough), or they do not have the experience to be able to detect how LLM generated code would fail in production beyond the 'happy path'.

If you are trying to build something well represented in the training data, you could get a usable prototype.

If you are unfamiliar with the various ways that naive code would fail in production, you could be fooled into thinking generated code is all you need.

If you try to hold the hand of the coding agents to bring code to a point where it is production ready, be prepared for a frustrating cycle of models responding with ‘Fixed it!’ while only having introduced further issues.

On what basis are you making that prediction?

Any sufficiently complicated LLM generated program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of an open source project.

Windows' moat was not the operating system code, but that they were able to get distribution via IBM, and then grow an ecosystem of applications that were targeted at Windows, which created a snowball effect for further applications.

Was software ever a moat? Software typically only gave companies a small window of opportunity to turn a fleeting software advantage into a more resilient moat (network effects, switching costs etc.)

In what way is the long term impact of LLMs being underestimated? If anything, it seems that it has been overestimated in the past years and that something other than LLMs will be needed to reach the original scaled LLM hope of AGI.

If only that is what investors have figured out.

Unfortunately, it seems investors now think that all paid software will be replaced by AI generated software, somehow open source projects laundered through generative AI models should finally convince enterprise customers to go with free.

EXWM is great, having the same flow to manage X applications as for emacs buffers is a huge benefit. My only concern is if X11 will be maintained sufficiently into the future to keep using it, currently there is no Wayland support in EXWM.

I am talking about correctness, not style, coding isn't just about being able to show activity (code produced), but rather producing a system that is correctly performing the intended task

Do you have a link to some of the code that you have produced using this approach? I am yet to see a public or private repo with non-trivial generated code that is not fundamentally flawed.

We work with LLMs on a daily basis to solve business use cases. From our work, LLMs seem to be nowhere close to being able to independently solve end-to-end business processes, in every use case they need excessive hand holding (output validation, manual review etc.). I often find myself thinking that a use case would be solved faster and cheaper using other ML approaches.

LLMs for replacing work in its entirety seems to be a stretch of the imagination at this point, unless an academic breakthrough that goes beyond the current approach is discovered, which typically has an unknown timeline.

I just don't see how companies like Anthropic/OpenAI are drawing these conclusions given the current state.

Does Sam Altman have any relevant technical experience to make that assessment? Sounds like something someone would say that just lost their key technical team members.

Did you consider Kill Bill https://github.com/killbill/killbill ? I used it a few years ago for usage based billing.

There are active projects that I would categorize as frameworks (e.g. Fulcro)

This is one of the reasons that I usually use https://killbill.io/

Now that they are open sourcing even Delta table optimizations

Has Databricks recently open sourced additional Delta table features that were previously only available with a paid license? I can't seem to find a relevant announcement.

Kubevisor (https://www.kubevisor.com/) | Remote (South Africa)

We are looking for senior DevOps engineers based in South Africa to join our team.

You should have a detailed understanding of building end-to-end systems on Linux/Kubernetes, including:

- 2+ years work experience in DevOps (especially Kubernetes and AWS)

- Experience in managing, scaling and migrating data in the context of relational database (preferably PostgreSQL)

- Able to use a major programming, preferably Java/Go

- Experience building/operating highly available relational database clusters

- Experience using Linux

- Combination of deep technical skills and business savvy enough to interface with all levels and disciplines within an organization

- Demonstrable track record of dealing well with ambiguity, prioritizing needs, and delivering results in a dynamic environment

Please get in touch at jobs@kubevisor.com

Kubevisor (https://www.kubevisor.com/) | Remote (South Africa)

We are looking for senior DevOps engineers based in South Africa to join our team.

You should have a detailed understanding of building end-to-end systems on Linux/Kubernetes, including:

* 2+ years work experience in DevOps (especially Kubernetes and AWS)

* Experience in managing, scaling and migrating data in the context of relational database (preferably PostgreSQL)

* Able to use a major programming, preferably Java/Go

* Experience building/operating highly available relational database clusters

* Experience using Linux

* Combination of deep technical skills and business savvy enough to interface with all levels and disciplines within an organization

* Demonstrable track record of dealing well with ambiguity, prioritizing needs, and delivering results in a dynamic environment

Please get in touch at jobs@kubevisor.com

Kubevisor (https://www.kubevisor.com/) | Remote (South Africa)

We are looking for senior DevOps engineers based in South Africa to join our team.

You should have a detailed understanding of building end-to-end systems on Linux/Kubernetes, including:

* 2+ years work experience in DevOps (especially Kubernetes and AWS)

* Experience in managing, scaling and migrating data in the context of relational database (preferably PostgreSQL)

* Able to use a major programming, preferably Java/Go

* Experience building/operating highly available relational database clusters

* Experience using Linux

* Combination of deep technical skills and business savvy enough to interface with all levels and disciplines within an organization

* Demonstrable track record of dealing well with ambiguity, prioritizing needs, and delivering results in a dynamic environment

Please get in touch at jobs@kubevisor.com

Kubevisor (https://www.kubevisor.com/) | Remote (South Africa)

We are looking for senior DevOps engineers based in South Africa to join our team.

You should have a detailed understanding of building end-to-end systems on Linux/Kubernetes, including:

* 2+ years work experience in DevOps (especially Kubernetes and AWS)

* Experience in managing, scaling and migrating data in the context of relational database (preferably PostgreSQL)

* Able to use a major programming, preferably Java/Go

* Experience building/operating highly available relational database clusters

* Experience migrating large JVM applications to Kubernetes and AWS

* Experience using Linux/Unix

* Combination of deep technical skills and business savvy enough to interface with all levels and disciplines within an organization

* Demonstrable track record of dealing well with ambiguity, prioritizing needs, and delivering results in a dynamic environment

Please get in touch at jobs@kubevisor.com

Kubevisor (https://www.kubevisor.com/) | Remote | Contractors

We are looking for senior data engineers on a contract basis to join an ongoing project from the start of January.

You should have a detailed understanding of building end-to-end data pipelines on AWS, including:

* 5+ years relevant work experience

* Scala/Python (preference in that order) on Spark

* Experience with processing large datasets with Spark on AWS (primarily EMR and S3)

* Experience in data modelling, ETL development, and data warehousing.

* Experience building/operating highly available, distributed systems of data extraction, ingestion and processing large data sets

* Experience using Linux/Unix to process large data sets

Ideally you are in the GMT to GMT+4 timezone.

Please get in touch at jobs@kubevisor.com

Kubevisor | Remote | Contractors

We are looking for additional senior ML engineers on a contract basis for an ongoing project.

You should have a detailed understanding of the ML lifecycle, including:

* 5+ years relevant work experience

* Python to process data for modelling

* Experience working with a wide range of predictive and decision models, including tools (primarily PyTorch)

* ML workflow tools (e.g. Kubeflow/MLflow)

* Developing end-to-end software projects

* Experience using Linux to process large data sets

* Experience with Kubernetes

* Experience with AWS

Ideally you are in the GMT to GMT+4 timezone.

Please get in touch at jobs@kubevisor.com

Kubevisor | Remote | Contractors

We are looking for senior ML engineers on a contract basis for a project starting mid-October.

You should have a detailed understanding of the ML lifecycle, including:

* 5+ years relevant work experience

* Python to process data for modelling

* Experience working with a wide range of predictive and decision models, including tools (primarily PyTorch)

* ML workflow tools (e.g. Kubeflow/MLflow)

* Developing end-to-end software projects

* Experience using Linux to process large data sets

* Experience with Kubernetes

* Experience with AWS

Ideally you are in the GMT to GMT+4 timezone.

Please get in touch at jobs@kubevisor.com

Kubevisor | Remote | Contractors

We are looking for senior data engineers on a contract basis for a project starting mid-September.

You should have a detailed understanding of building end-to-end data pipelines on AWS, including:

* 5+ years relevant work experience

* Scala/Java/Python (preference in that order) on Spark

* Experience with processing large datasets with Spark on AWS (primarily EMR and S3)

* Ideally you have hands-on experience with Drools (preferably in conjunction with Spark), or other rules engines

* Experience in data modelling, ETL development, and data warehousing.

* Experience building/operating highly available, distributed systems of data extraction, ingestion and processing large data sets

* Experience using Linux/Unix to process large data sets

Ideally you are in the GMT to GMT+4 timezone.

Please get in touch at jobs@kubevisor.com

Kubevisor | Remote

We are looking for senior data and ML engineers for a project starting mid-April.

You should have a detailed understanding of the ML lifecycle, including:

* 5+ years relevant work experience

* Python to process data for modelling

* Experience working with a wide range of predictive and decision models, including tools

* ML workflow tools (e.g. Kubeflow/MLflow)

* Experience with Cloudera

* Developing end-to-end software projects

* Experience using Linux/UNIX to process large data sets

* Experience with Hadoop/Kubernetes

Ideally you are in the GMT to GMT+4 timezone.

Please get in touch at jobs@kubevisor.com

OpenShift is Kubernetes, just like RHEL is a Linux distribution with support for enterprises. OpenShift makes an opinionated choice about what they bundle (distribute) with vanilla Kubernetes. For example, Istio was chosen as the service mesh distributed with OpenShift 4.

In theory, you could replace the CNI on worker nodes, but is that something that is practically useful (when it can't be done on master nodes in EKS) and supported? How would the kube-apiserver, for example, communicate to the metrics-server if it is not connected to the Calico network?