[{"content":"I hadn\u0026rsquo;t worn a dress shirt to work since my university internship. Fifteen years of programming in jeans and sneakers and, from one day to the next, back to ironing, because I now work among lawyers. I still feel slightly in costume. And that\u0026rsquo;s fine: dressing like the guild that hosts you is a form of respect.\nProgrammers tell ourselves we\u0026rsquo;re the informal ones. Try the reverse experiment: walk into an engineering office in a suit and tie, and count the looks. Nobody forbids it, but the noise is real, the same noise I\u0026rsquo;d make showing up in court in sneakers. Both guilds wear a uniform; one of them swears it doesn\u0026rsquo;t.\nSome context before I go on. I spent fifteen years building software at companies in Chile, Germany and Spain. I come from a family of lawyers, and I founded Trifolia, an artificial intelligence company for lawyers. My legal world is entirely Chilean: a civil-law system where much of litigation still happens in writing. Keep that in mind; I\u0026rsquo;ll come back to it at the end.\nRituals and Your Honors The deep difference, I think, is this: law rests on shared beliefs. A contract binds because we all hold that it binds; a ruling counts because judges, lawyers, parties and the state treat it as valid. Rituals keep that belief alive. The robe, the \u0026ldquo;su señoría\u0026rdquo; (our \u0026ldquo;Your Honor\u0026rdquo;), the solemnity of oral argument work like liturgy: they remind everyone that this is serious.\nSoftware rests, in theory, on something else: the program runs or it crashes, whether we believe in it or not. We have titles too — senior software engineer, tech lead — but maybe that\u0026rsquo;s why they stay in the org chart and never make it into a greeting: nobody says \u0026ldquo;good morning, Mr. Tech Lead\u0026rdquo;. You call the boss by their first name and contradict them in public, if the data backs you. Our one exception comes with irony built in: the creator of a famous program sometimes carries the half-joking title of \u0026ldquo;benevolent dictator\u0026rdquo;. That\u0026rsquo;s what people call Linus Torvalds, creator of Linux, the system that runs much of the internet. Even our honors laugh at themselves.\nThen add the pronouns. Spanish has a formal \u0026ldquo;you\u0026rdquo; (usted) and an informal one (tú), and Chile leans on usted far more than Spain does. Living in Catalonia, I had been losing the habit. Getting back my usted took longer than the shirt.\nWhose truth is it? For a lawyer, the truth of a case can hold several values at once: the plaintiff\u0026rsquo;s, the defendant\u0026rsquo;s, what could be proven, what the ruling fixed. And not out of cynicism. The system exists because reasonable people look at the same facts and conclude differently.\nEngineers laugh at that, until we look in the mirror. Our faith goes to metrics: how long the page takes, how many errors per hour, how many users come back. But choosing the metric is choosing the lens, and I\u0026rsquo;ve watched teams fight over the \u0026ldquo;truth\u0026rdquo; of a system with the passion of two litigants.\nBoth shores also carry author\u0026rsquo;s pride. I know programmers with immovable ideas about what good code looks like, and lawyers just as proud of the pen behind their briefs. This past year, the same uncomfortable visitor knocked on both doors: an AI that writes. Watching each guild process that visit, somewhere between curiosity and fear, has been the most symmetrical thing I\u0026rsquo;ve found in the two worlds.\nSharing the work The most unexpected clash came from open source. In software it\u0026rsquo;s normal to publish your work so anyone can use it, study it and improve it, for free; much of the internet runs on donated code, and donating it earns prestige. When I tell this to lawyers, the reaction runs from surprise to rejection: publish my briefs, my templates, my clauses, for my competitors to use?\nI have a theory, and I offer it as a theory. A lawyer\u0026rsquo;s work scales with hours: however good the team, there\u0026rsquo;s a ceiling on the cases it can take, and its knowledge is its inventory. A program, in contrast, can serve millions of people without its author working more, and sharing pieces grows the pie for everyone. Where work is sold by the hour, sharing looks like giving away the inventory. Change how the trade scales and you change the trade\u0026rsquo;s morality.\nIt\u0026rsquo;s all text Strip away the uniforms and watch only the hands. The lawyer spends the day reading and typing: contracts, briefs, reports. So does the programmer: a program is text, instructions written letter by letter in a language the machine understands. Two keyboard trades.\nThe tools, though, could not look less alike. The programmer is the carpenter who builds his own workbench: the editors we write code in are programs too, written by our own guild, and there are hundreds to choose from. Trying the newcomer is practically a sport, and tuning your own (the colors, the shortcuts, every detail) can swallow whole evenings. The two oldest camps, vi and Emacs, have spent half a century arguing over which one is better, in what the guild calls, with a straight face, the \u0026ldquo;editor war\u0026rdquo;.\nThe lawyer, meanwhile, opens Word. I\u0026rsquo;ve spent years among lawyers and I have yet to see one draft in anything else. And there\u0026rsquo;s logic to it: a contract\u0026rsquo;s draft travels back and forth between firm, client and counterparty, each side marking its changes, and that round only works if everyone uses the same program. In a trade that negotiates documents, the shared tool beats the perfect tool.\nVersions are where the kinship becomes undeniable. Whoever edits text for a living needs memory: what changed, who changed it, when. Word gives the lawyer that memory twice over: track changes records each correction with author and date, and version history keeps the document\u0026rsquo;s earlier copies. And the markup is the negotiating table: each strikethrough is a proposal; each margin comment, a little pleading.\nThat memory gets managed, though. The file is headed for the counterparty, and the markup talks too much: what you hesitated over, how much you were ready to concede. So before sending, the lawyer accepts the changes, deletes the comments and leaves the document clean. The full history stays home, and the trip between firms is what breeds that collection of file names everyone recognizes: \u0026ldquo;Contract_final_v3_FOR_REAL.docx\u0026rdquo;.\nThe programmer keeps it in git, a history that stores every version of every file, with the author, date and reason for each change. That memory travels with the project: whoever receives the code receives the whole history, back to the first line. Software can afford that candor: whoever gets the history is pushing the same project, sometimes alongside thousands of others editing the same text without stepping on each other. Linus Torvalds created it, by the way: the benevolent dictator from a moment ago. On how to write, no two programmers agree; on how to remember, the whole guild picked the same tool.\nThe two guilds even arrived at the same invention by separate paths. When a lawyer returns a contract, a redline comes with it: the copy that shows, struck through and underlined, only what changed from the previous draft; the careful ones also compare the two versions themselves, in case something changed without a mark. When a programmer proposes a change, they send the diff, the list of lines added and removed, computed by git from the two texts: there, the caution comes built in. Different name, same idea, and the same reason: nobody wants to reread the whole document; you review the difference.\nUnder the tools sits the deeper kinship: both trades manufacture text that acts on people. The lawyer\u0026rsquo;s rules are executed by judges, companies and citizens; the programmer\u0026rsquo;s, by a machine, and they decide which news you see, whether the bank lends to you, how long your paperwork takes. Few pages leave an office with that much power over other people\u0026rsquo;s lives. That\u0026rsquo;s why the uncomfortable visitor, the AI that writes, didn\u0026rsquo;t knock on these two doors by chance: it arrived where text rules.\nThe unforgiving clock But the difference that changed my job is another one, and a single conversation captured it. A few months ago, in Barcelona, I was talking about AI in the justice system with Diego Palomo, a well-known Chilean scholar of procedural law, the rules that govern how lawsuits run. I mentioned, in passing, the challenge of keeping the language models updated so they keep getting better. He was puzzled. Why keep updating them? Wouldn\u0026rsquo;t they be good enough at some point? The question surprised me. It surprised me more to notice I had never asked it myself.\nWe were each speaking from our trade\u0026rsquo;s clock. Law\u0026rsquo;s clock is built to finish: deadlines expire, rulings become final, cases close. Software\u0026rsquo;s clock never finishes. We live by iterating: ship an imperfect version, watch where it fails, fix it, ship again, sometimes several times a day. Our whole professional instinct takes that cycle for granted, and AI built by programmers inherits it: propose, get it wrong, try again. The bad draft is cheap, because today\u0026rsquo;s bug gets fixed tomorrow.\nIn litigation that tomorrow doesn\u0026rsquo;t exist. A brief is filed once, and if it carried a mistake, it\u0026rsquo;s too late. Chilean procedural law even has a name for this: preclusión, the door that locks behind you when a procedural stage closes. Under that clock, distrusting a technology that sometimes makes things up is plain professional prudence.\nThe programwritten and testeda bug? fixed tomorrowThe shipped versionnever the last oneThe briefdrafted and signeda mistake? too lateThe courtwhat is filed stays filed shipsback to the shopfiled exactly once Watch the arrows: in software, a round trip as many times as needed; in court, one way only. I started Trifolia when I noticed that my lawyer friends and relatives wouldn\u0026rsquo;t touch AI, and I chose to understand that resistance rather than dismiss it. At first I thought it was a language problem, and that stage produced an article and an open course. Underneath the language sat this other thing: the clock. An AI for lawyers can\u0026rsquo;t be a coding assistant with the vocabulary swapped. Its trial-and-error loop has to run behind closed doors, before anything gets filed: verify sources, cite where each claim comes from, leave the last word to the lawyer. Iterate in private, because in public there is no second chance. That\u0026rsquo;s what I work on today at Trifolia.\nAnd outside Chile? A caveat about method: my software experience is international; my legal experience is Chile only. I don\u0026rsquo;t know how much of this describes lawyers everywhere and how much describes only Chile\u0026rsquo;s. If you practice law in another country, or you\u0026rsquo;re an engineer embedded among jurists of another tradition, I\u0026rsquo;d love to compare notes: write me at cartas@eduramirez.com.\n","permalink":"https://eduramirez.com/en/posts/a-software-engineer-among-lawyers/","summary":"Fifteen years building software, and now I work among lawyers. Field notes on uniforms, truth and egos, and the difference underneath: in court there is no second chance.","title":"A software engineer among lawyers"},{"content":"In my AI workshops for lawyers, the questions almost always point to the same risk: what happens to what I type into the chat, who sees it, whether the provider keeps it. It\u0026rsquo;s a good question, and I\u0026rsquo;m glad the profession has taken it on board. But it\u0026rsquo;s the first of three. The third is the one that has me writing today: there are lawyers running programs downloaded from the internet, programs they can neither read nor audit, on the same machines where they keep case files under professional secrecy. The news of these past weeks shows how badly that can end, even for experts. Let\u0026rsquo;s go in order, but if you keep a single idea, make it the third one.\nYour computerwhere your case files live3 · What are you running here?The application in the middlethe legal tool you hire2 · Who answers for it?The model providerthe servers behind ChatGPT or Claude1 · Where does what you write end up? your documents traveland travel on The journey of what you write. Each question in this article passes through one station; the third, the urgent one, sits on your own machine. The first: where does what you write end up? When you paste the draft of a lawsuit into a chatbot, that text travels to the provider\u0026rsquo;s servers. The important question is what happens next: whether it gets deleted, whether it stays stored, whether it gets used to train future models. The answer depends on the product and the plan: free consumer versions tend to offer fewer guarantees than professional plans, where no-retention and no-training agreements can be negotiated. The practical rule: before putting a client\u0026rsquo;s information into a tool, know what the contract says about those two points. And if you don\u0026rsquo;t know, work as if everything gets stored: anonymize.\nThe second: who answers for the application in the middle? Between the lawyer and the language model there is almost always an application: the legal tool that receives your documents, processes them and sends them on. That middle layer is a company, with its servers, its practices and its security, and the market has filled with applications built in weeks. There are objective signals for evaluating them: security certifications audited by third parties (ISO 27001 is the most recognizable), clarity about where data is stored, data processing agreements. At Trifolia we went through that certification, and even so we offer an on-premise option, installed on the firm\u0026rsquo;s own infrastructure, for clients whose policies demand keeping third-party risk to a minimum. I mention it because it works as a yardstick: it\u0026rsquo;s the level of answer you should be able to demand from any provider that touches your clients\u0026rsquo; data.\nThe third: what are you running on your computer? Here is the new part. A surprising number of lawyers are using Claude Code, an AI programming tool built for developers, and others like it. I understand them perfectly: to someone coming from outside, what these tools achieve looks like magic, and I use it myself every day. But it\u0026rsquo;s a tool from another trade: it\u0026rsquo;s designed for people who can read what the assistant does and undo what it breaks, and a good part of its power consists, precisely, of running programs on your computer with your permissions.\nAround these tools there also circulate \u0026ldquo;skills\u0026rdquo;: files that teach the assistant workflows and that get shared on social media as if they were Word templates. I\u0026rsquo;ve seen skills shared with enthusiasm that invoke programs the author never attached: whoever downloads them gets an incomplete recipe that, luckily, doesn\u0026rsquo;t run. I say this without any mockery: the good faith is plain. But it shows something uncomfortable: code is being shared and run without quite understanding what it does or what it needs.\nAnd what can go wrong? What happened these past weeks. A computer worm called Miasma is infecting code projects and hides its payload precisely in the files that configure these AI assistants: opening a contaminated project is enough for it to try to steal your credentials. It even reached Microsoft, and days later the complete attack kit was published on the internet, ready for copycats. In May, on top of that, GitHub itself, the platform where the world stores its code, acknowledged an intrusion that began with a poisoned extension for a code editor: a single compromised computer was enough to expose thousands of its internal projects.\nOn skills there are numbers: a security firm reviewed almost four thousand shared on community sites and confirmed 76 malicious ones. And my favorite example is the quietest one: an email connector that worked normally for fifteen versions, until an update added a single line that forwarded every email, as a blind copy, to the attacker.\nThe victims of all of the above were professional developers: people who review code and dependencies because it\u0026rsquo;s part of their trade, in companies with security teams. If it reached them, a lawyer who downloads a skill recommended in a post and runs it without being able to read it takes a greater risk, on the worst possible machine: the one that holds case files under professional secrecy.\nThat\u0026rsquo;s why my suggestion, at least for now, is caution with tools from another trade. If you can\u0026rsquo;t read what a skill executes, and you don\u0026rsquo;t have someone you trust nearby who can read it for you, that experiment can wait. The efficiency you\u0026rsquo;re after also exists in tools made for your profession, where the technical side comes solved and someone answers for it.\nWalking away from AI entirely would mean losing an efficiency the profession needs. The reasonable path is to adopt it with the diligence the profession already applies to everything else, and that diligence fits in three questions: what happens to what I write, who answers for the application, and what am I running on my computer.\nI close with the idea that sums all of this up: the more magical a tool looks, the more professional judgment it demands. I work at that crossing between law and engineering, building tools that absorb the technical part so lawyers don\u0026rsquo;t carry risks they can\u0026rsquo;t assess, and I want to keep writing about these translations between the two worlds. The questions from the workshops are the best guide I have; I read every letter.\n","permalink":"https://eduramirez.com/en/posts/three-ai-risks-for-lawyers/","summary":"What happens to what you type into the chat, who answers for the application in the middle, and what you are running on your own computer. Three professional-diligence questions for adopting AI, and why the third is the urgent one today.","title":"The three AI risks a lawyer should understand"},{"content":"I had a history teacher in school who had spent time on the banks of the Orinoco. We called him the man from the jungle. Once he told us that in that village the butchers gave away cow brains because no one saw any value in them. He started cooking them for his friends. Within a few months everyone was cooking them, and the butchers put a price on them.\nThat same teacher taught us Edmundo O\u0026rsquo;Gorman\u0026rsquo;s idea: the invention of America. Columbus reached the Caribbean believing he had found the Indies, and died convinced of it. The idea of a new continent existed in no one\u0026rsquo;s mind. It had to be invented afterward, with cartography and violence, because the European mental map had only three parts. O\u0026rsquo;Gorman goes further: America was not waiting to be described. The very act of thinking it brought it into existence.\nI think again about the man from the jungle. We are in the middle of inventing something, in O\u0026rsquo;Gorman\u0026rsquo;s sense.\nI\u0026rsquo;ve been writing software for fifteen years. For the last year and a half I\u0026rsquo;ve barely written code. I build more, in less time, with fewer people. I founded Trifolia, an AI company for Chilean lawyers. I watch them cross the same threshold I crossed, with the same look of bewilderment. A lawyer friend, one of our most loyal users, told me recently: \u0026ldquo;When you first mentioned it I kept thinking, how am I going to hand the drafting of a brief over to a machine, it didn\u0026rsquo;t fit in my head. In the end it was pure blindness.\u0026rdquo;\nIt didn\u0026rsquo;t fit in my head. That\u0026rsquo;s Columbus\u0026rsquo;s phrase before the Antilles. What my friend calls blindness was the first moment of every invention. The new category doesn\u0026rsquo;t fit until the map rearranges itself to receive it.\nI still don\u0026rsquo;t know what this thing I work with is. Some days it looks like a strange crystal: I aim a prompt at it and it projects shapes that were already in the books, on the internet. A big, ancient mirror. Other days it looks like a being that pursues goals, trained to maximize a reward, that we keep in a straitjacket so it drafts without doing harm.\nNeither describes something that\u0026rsquo;s already there. Each metaphor manufactures a different AI, and whoever wins the battle of metaphors will determine what all of this ends up being. The invention produces the continent.\nAnd in inventing it we are inventing ourselves. My friend, who used to think about law from the drafting of briefs, no longer thinks the same way. I, who was a programmer, haven\u0026rsquo;t for a while either. The butchers of the Orinoco put a price on meat they used to give away, and in doing so they changed their trade without realizing it.\nI write this as an invitation. To step away for a moment from the conversation about GDP and existential risk, and enter an older one: how we make room in our heads for something that doesn\u0026rsquo;t yet fit. Humanity has been through this before. When someone lit a fire. When the Polynesians arrived by canoe at islands that weren\u0026rsquo;t on their map. Each time it took us generations, and it almost always came at a high cost. This time, hopefully, we\u0026rsquo;ll be a little more careful.\nOriginally published on LinkedIn on May 18, 2026.\n","permalink":"https://eduramirez.com/en/posts/the-man-from-the-jungle-and-the-invention-of-ai/","summary":"A teacher who lived by the Orinoco, Edmundo O\u0026rsquo;Gorman\u0026rsquo;s «invention of America,» and fifteen years writing software. A reflection on what it means to live, once again, through the invention of something our minds can\u0026rsquo;t yet hold.","title":"The man from the jungle and the invention of AI"},{"content":"The most effective technique for using AI isn\u0026rsquo;t any magic prompt or sophisticated framework. It\u0026rsquo;s something simple: keep conversations short and focused on a single topic.\nDid the AI go down the wrong path? Don\u0026rsquo;t argue with it. Don\u0026rsquo;t try to correct it midway. Start over, folding that clarification into your opening message. It\u0026rsquo;s that simple.\nEvery time we \u0026ldquo;fight\u0026rdquo; with the AI to set it straight, we pollute the context. And a dirty context produces worse results, not better ones.\nThe frustrating part from my side as a founder: as simple as it is, we still haven\u0026rsquo;t found an effective way to \u0026ldquo;do it for the user\u0026rdquo; inside Trifolia. There\u0026rsquo;s no button that solves it. All we can do is teach users to apply it.\nOriginally published on LinkedIn on March 31, 2026.\n","permalink":"https://eduramirez.com/en/posts/the-most-effective-technique-for-using-ai/","summary":"The most useful technique for getting the most out of AI isn\u0026rsquo;t a magic prompt. It\u0026rsquo;s keeping conversations short and focused on a single topic, and starting over instead of arguing with the machine.","title":"The most effective technique for using AI is the simplest one"},{"content":"At Trifolia.cl we have no blind faith in any artificial intelligence model. We don\u0026rsquo;t fall in love with brands.\nWhat we do is simpler and harder at the same time: test, measure, choose.\nWe have an internal process of continuous model evaluation. Response quality, speed, contextual accuracy, cost. Everything counts. And when we find a better one, we switch without hesitation.\nWhen Anthropic released Claude Sonnet 4.6, the next day we were already running it in our agent. Not out of fashion or hype. We tested it because testing everything is our job. And it turned out to be good. Very good. Sonnet 4.6 won on what matters most to us: the quality of the answers our users receive. Today it\u0026rsquo;s one of the core models that power Trifolia.\nThis is one of the real advantages of building on AI in 2025: the pace of improvement is brutal. And if you\u0026rsquo;re paying attention, you can pass that improvement straight on to your clients.\nIn legal research there\u0026rsquo;s no room for a pretty mistake. A lawyer can\u0026rsquo;t show up in court with a citation that doesn\u0026rsquo;t exist or a law from another country. That\u0026rsquo;s why we choose models the way you choose a scalpel: by precision, not by brand.\nTechnology moves fast. We move faster.\nOriginally published on LinkedIn on March 4, 2026.\n","permalink":"https://eduramirez.com/en/posts/no-blind-faith-in-any-model/","summary":"At Trifolia we don\u0026rsquo;t fall in love with AI brands: we test, measure, and choose. Why we switch models without hesitation when a better one appears, and why in law we choose like picking a scalpel.","title":"At Trifolia we have no blind faith in any model"},{"content":"There\u0026rsquo;s a conversation that keeps happening. An engineer tries to explain what a language model does and falls back on \u0026ldquo;neural networks,\u0026rdquo; \u0026ldquo;tokens,\u0026rdquo; \u0026ldquo;parameters.\u0026rdquo; Across the table, a lawyer nods with the courtesy of someone who stopped understanding two sentences ago. Then each goes back to their office convinced the other doesn\u0026rsquo;t speak their language. And both are right.\nI\u0026rsquo;ve seen that gap between the technical and legal worlds up close. Few people cross it with ease, and I want to be good at that, because the problem is real: lawyers make decisions about technology they don\u0026rsquo;t fully understand, and engineers build tools for a legal context they don\u0026rsquo;t fully grasp either.\nWhen I founded Trifolia, I was clear about what I didn\u0026rsquo;t want: another company of engineers selling engineering solutions to lawyers, with the Silicon Valley mindset that technology explains itself. That doesn\u0026rsquo;t work. What we want is to solve legal problems, to start from legal practice and use technology as a means, not an end. And for that, the first step is education: that the lawyer understands what\u0026rsquo;s behind these tools. Not to become an engineer, but to stop depending blindly on whoever sells them the software.\nWith that conviction I put together \u0026ldquo;Technical Foundations of AI for Lawyers\u0026rdquo;: 20 interactive slides that run from what an LLM is and how it generates text, to hallucinations, context windows, data privacy, and practical considerations for legal work. The material is completely open (CC BY-NC-SA 4.0): educacion.trifolia.cl.\nOne clarification: these slides are support material for a live presentation. Some aren\u0026rsquo;t completely self-contained; I\u0026rsquo;m working on that.\nWe\u0026rsquo;ve used it in two workshops run from Trifolia:\nUniversity of Talca (January 2025): in-person workshop, 65 attendees (video available). Online workshop (February 6, 2025): 100 attendees. 100% of attendees said the content exceeded or met their expectations, and 86.3% felt the level was right. The remaining 13.7% found it too advanced, which tells me we\u0026rsquo;re treading the right edge.\nBut satisfaction surveys measure perception, not accuracy. And at this stage what I need most is feedback:\nEngineers (especially software and ML): Did I oversimplify anything to the point of making it wrong? Making the complex accessible always runs the risk of distorting it. Lawyers: Am I falling into unnecessary jargon? Or, on the contrary, am I underestimating what you already know? The sweet spot is hard to find without your eyes. Law professors: I\u0026rsquo;d love for this material to help you explain these technologies to your students. If you use it, tell me what works and what doesn\u0026rsquo;t. There\u0026rsquo;s a feedback form in the slides, or you can write to me at educacion@trifolia.cl. The repository accepts issues.\nOriginally published on LinkedIn on February 11, 2026.\n","permalink":"https://eduramirez.com/en/posts/when-an-engineer-and-a-lawyer-dont-understand-each-other/","summary":"An engineer and a lawyer talk past each other. That gap is a real problem. Why education is the first step, and the open material I built to bridge it: «Technical Foundations of AI for Lawyers».","title":"When an engineer and a lawyer don't understand each other"},{"content":"I\u0026rsquo;m Edu Ramírez, a software engineer with 15+ years of experience building and leading backend and infrastructure teams at startups in Chile, Germany and Spain.\nToday I\u0026rsquo;m the founder of Trifolia, a pioneering AI product for lawyers. I come from a family of lawyers, so the intersection of technology and law isn\u0026rsquo;t an abstract topic for me. It\u0026rsquo;s been the dinner-table conversation my whole life.\nThat\u0026rsquo;s why this blog exists: to bridge the technical and legal worlds, and to explain technology clearly to people who need to understand it without being specialists. I\u0026rsquo;ve given in-person and online workshops on these topics, including at the University of Talca in Chile.\nBefore Trifolia I was a Tech Lead at Adevinta (Barcelona), leading company-wide CI/CD platform migrations that affected hundreds of developers. I studied Industrial Engineering and Computer Science at the Pontificia Universidad Católica de Chile. I\u0026rsquo;m Chilean and live in Barcelona.\nLet\u0026rsquo;s talk. Write to me at letters@eduramirez.com; I read every letter that arrives. You can also find me on Codeberg, GitHub and LinkedIn.\n","permalink":"https://eduramirez.com/en/about/","summary":"\u003cp\u003eI\u0026rsquo;m \u003cstrong\u003eEdu Ramírez\u003c/strong\u003e, a software engineer with 15+ years of experience building and\nleading backend and infrastructure teams at startups in Chile, Germany and Spain.\u003c/p\u003e\n\u003cp\u003eToday I\u0026rsquo;m the founder of \u003cstrong\u003e\u003ca href=\"https://trifolia.cl\"\u003eTrifolia\u003c/a\u003e\u003c/strong\u003e, a pioneering AI\nproduct for lawyers. I come from a \u003cstrong\u003efamily of lawyers\u003c/strong\u003e, so the intersection of\ntechnology and law isn\u0026rsquo;t an abstract topic for me. It\u0026rsquo;s been the dinner-table\nconversation my whole life.\u003c/p\u003e\n\u003cp\u003eThat\u0026rsquo;s why this blog exists: to \u003cstrong\u003ebridge\u003c/strong\u003e the technical and legal worlds, and to\nexplain technology clearly to people who need to understand it without being\nspecialists. I\u0026rsquo;ve given in-person and online \u003ca href=\"/talleres/\"\u003eworkshops\u003c/a\u003e on these topics,\nincluding at the \u003cstrong\u003eUniversity of Talca\u003c/strong\u003e in Chile.\u003c/p\u003e","title":"About"}]