Explica cómo las nuevas tecnologías, como los LLM y ChatGPT, pueden revolucionar las Interfaces de Programación de Aplicaciones (API) en el futuro. Pon un ejemplo de cómo podrían funcionar estas API.
Explain how new technologies, like LLMs and ChatGPT, may revolutionize Application Programming Interfaces (APIs) in the future. Provide an example of how these APIs might work.
As a kid, I loved watching the Jetsons. As I grew older and ended up writing software and creating & implementing architectures for systems, I thought I would never see the day when a Jetsons-like kitchen would be feasible.
GPT (ChatGPT, etc.) has changed my mind.

Contractual Obligations
As an architect, you kind of need to think like a lawyer. You define contracts (APIs) between systems or components. You monitor those APIs for abuse or misuse.

I would use Swagger editor to define those contracts, and I would write the APIs to match interactions implied in mock-ups. I would vet the design with the team, I would walk through scenarios to see if the API would fit the use case and would not introduce performance bottlenecks, and I would simulate and automate as much as I could along the journey.

I was very careful to get it right the first time. It was never perfect the first time, of course. So, I also had to consider how the API could evolve while minimizing costs/impact to the rest of the system. The API, once deployed, would become something I would guard, like an honest politician guards the #usconstitution. The team had to be careful with any change that impacted the API.

API Mesh... More like API mess!
APIs rely on APIs which rely on more APIs and libraries. Once a system gets large enough, that complexity becomes a bottleneck. Small changes can have a huge ripple effect. Some approaches (like federated #GraphQL) help manage this complexity nicely. But it still involves an API under which there can exist a lot of fragility. #Agile or not, developing a complicated web of APIs is complex, requires specialized skills, and is full of unforeseen challenges.

The Kitchen Conversation, ChatGPT-style
The Jetsons' kitchen involves a number of systems, each composed of various parts, sensors, hardware, inputs and outputs. Considering the complexity of interactions between independent systems in a kitchen, the fact that the Jetsons' kitchen components would come from various vendors or manufacturers, traditional API design would not be able to fulfill the vision. Not practical, at all.

Now, let's think about APIs and the Jetsons' kitchen, #chatgpt -style.

Let's keep it simple: pizza. You (or your robot) make a pizza from scratch.

The oven asks the refrigerator: "I see we have a pizza. Can you tell me if this is low-moisture mozzarella?"

Refrigerator: "That's not even mozzarella. This pizza must have Muenster cheese as that is all I had in me. And the human removed some of the contents 30 minutes ago, so the probability of Muenster cheese on that pizza is quite high."

A sensor from the kitchen who has eyes across the room chimes in at this point. Sensor: "Beware that the crust of this pizza is made of cauliflower. I agree with the video sensor's assessment regarding the type of cheese. No new cheese entered the kitchen recently."

Oven: "Anything else I should know?"

Sensor: "The temperature of the dough is 47F. This is cooler than the expert chef consensus of using room-temperature dough."

Oven: "Great. I know what to do. Since the dough is cool, I will start cooking with a temperature a little lower than the recipe specifies. Then I will increase the temp of bottom element so as to provide a nice crisp crust. I will keep a close eye on moisture and may use convection to mitigate any undesirable levels of moisture."

Where is the API that contractually binds the independent systems? APIs are not gone. For instance, the brain of the Oven will have myriad APIs (e.g. for interacting with temperature controllers and sensors, etc.). The key here is that the interface between systems is no longer a fixed, rigid API. No method signatures, no paths, no payload specifications. Instead, a conversation relating to senses and capabilities.

What "brain"?
Kence Anderson's book Designing Autonomous AI describes nicely how a complex system can be decomposed into a number of independent "brains." Each brain, in his book, can be independently developed and refined, with human guidance married with #datascience, #machinelearning and #dataengineering.

What's Cookin'?
I am excited for what the future holds. How architects rethink complex system design with regards to APIs is, in my opinion, something that is inevitable. And, as an amateur pizza maker, my taste buds are watering for the day I get some GPT help to make an even better #detroitpizza.
De niño, me encantaba ver los Jetsons. Cuando me hice mayor y acabé escribiendo software y creando e implementando arquitecturas para sistemas, pensé que nunca vería el día en que una cocina como la de los Jetsons fuera factible.
GPT (ChatGPT, etc.) me ha hecho cambiar de opinión.

Obligaciones contractuales
Como arquitecto, tienes que pensar como un abogado. Defines contratos (API) entre sistemas o componentes. Supervisas esas API para evitar abusos o usos indebidos.

Yo utilizaría el editor Swagger para definir esos contratos, y escribiría las API para que coincidieran con las interacciones implícitas en las maquetas. Verificaba el diseño con el equipo, recorría escenarios para ver si la API se adaptaba al caso de uso y no introducía cuellos de botella en el rendimiento, y simulaba y automatizaba todo lo que podía a lo largo del proceso.

Tuve mucho cuidado de hacerlo bien a la primera. Nunca era perfecto a la primera, por supuesto. Así que también tuve que considerar cómo podría evolucionar la API minimizando los costes/impacto en el resto del sistema. La API, una vez desplegada, se convertiría en algo que yo custodiaría, como un político honesto custodia la #constitucióndeEstadosUnidos. El equipo tenía que tener cuidado con cualquier cambio que afectara a la API.

Malla de API... ¡Más bien un lío de API!
Las API dependen de las API, que a su vez dependen de más API y bibliotecas. Cuando un sistema crece lo suficiente, esa complejidad se convierte en un cuello de botella. Los pequeños cambios pueden tener un enorme efecto dominó. Algunos enfoques (como el #GraphQL federado) ayudan a gestionar bien esta complejidad. Pero siguen implicando una API bajo la cual puede existir mucha fragilidad. #Ágil o no, desarrollar una complicada red de API es complejo, requiere conocimientos especializados y está lleno de retos imprevistos.

La conversación en la cocina, al estilo ChatGPT
La cocina de los Jetsons implica una serie de sistemas, cada uno compuesto de varias piezas, sensores, hardware, entradas y salidas. Teniendo en cuenta la complejidad de las interacciones entre sistemas independientes en una cocina, el hecho de que los componentes de la cocina de los Jetsons procederían de varios vendedores o fabricantes, el diseño tradicional de API no sería capaz de cumplir la visión. En absoluto práctico.

Ahora, pensemos en las API y la cocina de los Jetsons, al estilo #chatgpt.

Hagámoslo sencillo: pizza. Tú (o tu robot) preparáis una pizza desde cero.

El horno pregunta al frigorífico: "Veo que tenemos una pizza. ¿Puedes decirme si es mozzarella de baja humedad?".

El frigorífico: "Eso ni siquiera es mozzarella. Esta pizza debe tener queso Muenster, ya que es todo lo que tenía dentro. Y el humano ha sacado parte del contenido hace 30 minutos, así que la probabilidad de que haya queso Muenster en esa pizza es bastante alta".

Un sensor de la cocina que tiene ojos al otro lado de la habitación interviene en este momento. Sensor: "Cuidado, la masa de esta pizza está hecha de coliflor". Estoy de acuerdo con la valoración del sensor de vídeo sobre el tipo de queso. No ha entrado queso nuevo en la cocina recientemente".

Horno: "¿Algo más que deba saber?"

Sensor: "La temperatura de la masa es de 47F. Esto es más frío que el consenso de los chefs expertos de utilizar masa a temperatura ambiente."

Horno: "Estupendo. Ya sé lo que tengo que hacer. Como la masa está fría, empezaré a cocinar con una temperatura un poco más baja que la que especifica la receta. Luego aumentaré la temperatura del elemento inferior para que quede una bonita corteza crujiente. Vigilaré de cerca la humedad y puede que utilice la convección para mitigar cualquier nivel indeseable de humedad."

¿Dónde está la API que vincula contractualmente a los sistemas independientes? Las API no han desaparecido. Por ejemplo, el cerebro del Horno tendrá innumerables API (por ejemplo, para interactuar con los controladores y sensores de temperatura, etc.). La clave aquí es que la interfaz entre sistemas ya no es una API fija y rígida. No hay firmas de métodos, ni rutas, ni especificaciones de carga útil. En su lugar, una conversación relativa a sentidos y capacidades.

¿Qué "cerebro"?
El libro de Kence Anderson Designing Autonomous AI describe muy bien cómo un sistema complejo puede descomponerse en varios "cerebros" independientes. Según su libro, cada cerebro puede desarrollarse y perfeccionarse de forma independiente, con orientación humana combinada con #ciencia de datos, #aprendizaje de máquinas e #ingeniería de datos.

¿Qué se cuece?
Me entusiasma lo que nos depara el futuro. En mi opinión, es inevitable que los arquitectos se replanteen el diseño de sistemas complejos en relación con las API. Y, como pizzero aficionado, se me hace agua la boca esperando el día en que consiga ayuda de GPT para hacer una #detroitpizza aún mejor.
creative_writing
es