It can be achieved with a zero-knowledge proof - there are many schemes, but in essence, they all allow you to prove something (e.g. your birthdate, validated by a government agency), without revealing who you are. You can prove to a third party "the government authenticated that I was born on 1970-01-01" without exposing who "I" is.
Some worthwhile reading on the topic if you're interested:
ZKP is better, but still not foolproof. Depending on the implementation, the government may now know that you have an account, or at least attempted to open an account on that service. You will have a hard time denying it in the future if the government asks to see your posts (as the US is currently doing at their borders).
I disagree. I can't think of an implementation mistake that would allow just the government to see what services you sign up for.
You could of course screw it up so everybody could see. If the government put a keylogger on your device then they could see. However broadly speaking this is not something that can be screwed up in such a way that just the government would be able to see.
The protocol wouldn't even involve any communication with the government.
"This is experimental software. While it has undergone external review, it has not yet received a formal security audit. Please use with caution and at your own risk in production environments."
> And you will never know code as well as a reader and you would have as the author for anything larger than a very small project.
This feels very true - but also consider how much code exists for which many of the current maintainers were not involved in the original writing.
There are many anecdotal rules out there about how much time is spent reading code vs writing. If you consider the industry as a whole, it seems to me that the introduction of generative code-writing tools is actually not moving the needle as far as people are claiming.
We _already_ live in a world where most of us spend much of our time reading and trying to comprehend code written by others from the past.
What's the difference between a messy codebase created by a genAI, and a messy codebase where all the original authors of the code have moved on and aren't available to ask questions?
> What's the difference between a messy codebase created by a genAI, and a messy codebase where all the original authors of the code have moved on and aren't available to ask questions?
The difference is the hope of getting out of that situation. If you've inherited a messy and incoherent code base, you recognize that as a problem and work on fixing it. You can build an understanding of the code through first reading and then probably rewriting some of it. This over time improves your ability to reason about that code.
If you're constantly putting yourself back into that situation through relegating the reasoning about code to coding agent, then you won't develop a mental model. You're constantly back at Day 1 of having to "own" someone else's code.
The key point is "relegating the reasoning". The real way to think about interfacing with LLMs is "abstraction engineering". You still should fully understand the reasoning behind the code. If you say "make a form that captures X, Y, Z and passes it to this API" you relegate how it accomplishes that goal and everything related to it. Then you look at the code and realize it doesn't handle validation (check the reasoning), so you have it add validation and toasts. But you are now working on a narrower level of abstraction because the bigger goal of "make a user form" has been completed.
Where this gets exhausting is when you assume certain things that you know are necessary but don't want to verify - maybe it let's you submit an email form with no email, or validates password as an email field for some reason, etc. But as LLMs improve their assumptions or you manage context correctly, the scale tips towards this being a useful engineering tool, especially when what you are doing is a well-trodden path.
I find this to be too rosy a story about using agentic coding to add to a codebase. In my experience, miss a small detail about the code and the agent may can go out of control creating a whole new series of errors that you wouldn’t have had to fix. And even if you don’t miss a detail, the agent eventually forgets because of the limited context window.
This is why I’ve constrained my use of AI agents to mostly “read-only and explain” use cases, but I have very strict conditions for letting it write. In any case, whatever productivity gains you supposedly “get” for its write scenarios, you should be subtracting your expenses to fix its output later and/or payments made for a larger context window or better reasoning. It’s usually not worth the trouble to me when I have plenty of experience and knowledge to draw from and can write the code as it should be myself.
So there’s another force at work here that to me answers the question in a different way. Agents also massively decrease the difficulty of coming into someone else’s messy code base and being productive.
Want to make a quick change or fix? The agent will likely figure out a way to do it in minutes rather the than hours it would take me to do so.
Want to get a good understanding of the architecture and code layout? Working with an agent for search and summary cuts my time down by an order of magnitude.
So while agree there’s a lot more “what the heck is this ugly pile of if else statements doing?” And “why are there three modules handling transforms?”, there is a corresponding drop in cost to adding features and paying down tech debt. Finding the right balance is a bit different in the agentic coding world, but it’s a different mindset and set of practices to develop.
In my experience this approach is kicking the can down the road. Tech debt isn't paid down, it's being added to, and at some point in the future it will need to be collected.
When the agent can't kick the can any more who is going to be held responsible? If it is going to be me then I'd prefer to have spent the hours understanding the code.
This is actually a pretty huge question about AI in general
When AI is running autonomously, where is the accountability when it goes off the rails?
I'm against AI for a number of reasons, but this is one of the biggest. A computer cannot be held accountable therefore a computer must never make executive decisions
The accountability would be in whoever promoted it. This isn't so much about accountability, as it is who is going to be responsible for doing the actual work when AI is just making a bigger mess.
The accountability will be with the engineer that owns that code. The senior or manger that was responsible for allowing it to be created by AI will have made sure they are well removed.
While an engineer is "it" they just have to cross their fingers and hope no job ending skeletons are resurrected until they can tag some other poor sod.
> In the current times you’re either an agent manager or you’re in for a surprise.
This opinion seems to be popular, if only in this forum and not in general.
What I do not understand is this;
In order to use LLM's to generate code, the engineer
has to understand the problem sufficient enough to
formulate prompt(s) to use in order to get usable
output (code). Assuming the engineer has this level
of understanding along with knowledge of the target
programming language and libraries used, how is using
LLM code generation anything more than a typing saver?
The point is an engineering manager is using software engineers as typing savers, too. LLMs are, for now, still on an exponential curve of capability on some measures (e.g. task duration with 50% completion chance is doubling every ~7 months) and you absolutely must understand the paradigm shift that will be forced upon you in a few years or you'll have a bad time. Understanding non-critical code paths at all times will simply be pointless; you'll want to make sure test coverage is good and actually test the requirements, etc.
> What's the difference between a messy codebase created by a genAI, and a messy codebase where all the original authors of the code have moved on and aren't available to ask questions?
Messy codebases made by humans are known to be a bad thing that causes big problems for software that needs to be maintained and changed. Much effort goes into preventing them and cleaning them up.
If you want to work with AI code systems successfully then you better apply these exact same efforts. Documentation, composition, validation, evaluation, review and so on.
You don't have much coding experience, do you. Everybody has a unique coding style that is pretty consistent across codebase, within given language lets say. Even juniors unless they all took it from either stackoverflow or llms (so same source).
Regardless how horrible somebody else's code is, there is some underlying method, or logic reflecting how given person forms mental model of the problem and breaks it down to little manageable pieces. You can learn that style, over time even ignoring it and seeing their code in same ways you see yours. llm code has none of that, if yes its by pure chance that won't repeat.
> What's the difference between a messy codebase created by a genAI, and a messy codebase where all the original authors of the code have moved on and aren't available to ask questions?
In my experience, the type of messes created by humans and the type of messes created by genAI are immensely different, and at times require different skill sets to dissect.
>We _already_ live in a world where most of us spend much of our time reading and trying to comprehend code written by others from the past.
In 1969 as a newly hired graduate working for the largest construction company in the country, one of my first assignments was to read through a badly formatted COBOL source code listing on paper, line by line, with 2 others. Each of us had a printout of a different version of the software, trying to discover where exactly the three versions were giving different outputs. Plus ça change, plus c'est la même chose
> What's the difference between a messy codebase created by a genAI, and a messy codebase where all the original authors of the code have moved on and aren't available to ask questions?
Very unskilled programmers can use generative AI to create complex code that is hard to understand.
Unskilled programmers on their own write simpler code with more obvious easy to solve mistakes.
On the other hand, all companies I have worked for tried to avoid have unmaintained code (with different levels of success). AI tech debt seems to be added on purpose pushed by upper management.
> We _already_ live in a world where most of us spend much of our time reading and trying to comprehend code written by others from the past.
We also live in a world where people argue endlessly about how we don't need to write documentation or how it's possible to write self documenting code. This is where we spend so much of our time and yet so few actually invest in the efforts to decrease that time.
I bring this up because it's a solution to what you're pointing out as a problem and yet the status quo is to write even messier and harder to understand code (even before AI code). So I'm just saying, humans are really good at shooting themselves in the foot and blaming it on someone else or acting like the bullet came out of nowhere.
> What's the difference between
More so, I must get misreading because it sounds like you're asking what's the difference between "messy" and "messier"?
If it's the same level of messiness, then sure, it's equal. But in a real world setting there's a continuous transition of people. One doesn't work on code in isolation, quit, and then a new person works on that code also in isolation. So maybe it's not the original authors but rather the original authors are a Ship of Theseus. Your premise isn't entirely accurate and I think the difference matters
Or shard it - divide your objects up based on some criteria (hash the name of the object, use the first N digits of the hash to assign to a shard), and distribute them across multiple redis instances. Yes, you then need to maintain some client code to pick the right redis instance to fetch from, but you can now pick the most $/memory efficient instance types to run redis, and you don't have to worry about introducing disk read latency and the edge cases that brings with it.
Edit: looks like redis has some built-in support for data sharding when used as a cluster (https://redis.io/docs/latest/commands/cluster-shards/) - I haven't used that, so not sure how easy it is to apply, and exactly what you'd have to change.
To add another anecdote to this thread, a few years ago, I picked up an old Consew 226R compound walking foot machine to do canvas work for a boat. That machine was a beast once I tuned it. Fast, powerful, smooth, quiet, and with a servo motor, had awesome slow and high speeds, would punch through anything. Its only real downside was the size, and it only did straight stitches. For canvas work, that was everything I needed.
I later picked up a Sailrite LSZ to do some zigzag work on sails. Compared to the Consew, the sailrite feels really clunky, even with the Sailrite servo motor upgrade. It's relatively rough and noisy compared to the Consew, and has less power. Main upsides are the size, and the zigzag stitch for sail work where you need some stretch.
I've ultimately kept the Sailrite because it's still pretty solid, and can be stored on the boat where I need it the most. If I was doing upholstery or canvas work in a permanent shop, I would've kept the Consew, hands down, it was a much more capable and pleasant machine.
The walking foot feature is very useful for heavy materials. I tried sewing light-weight materials on both of these machines and it was awful (bunching, tearing on the foot, can't use really fine needles, etc).
If you understand what it is doing, then you don't. But the layman will just see a computer that talks in language they understand, and will infer intent and sentience are behind that, because that's the only analog they have for a thing that can talk back to them with words that appear to make sense at the complexity level that ChatGPT is achieving.
Most humans do not have sufficient background to understand what they're really being presented with, they will take it at face value.
I think this is partly explained by most of the marketing and news essentially saying "ChatGPT is an AI" instead of "ChatGPT is an LLM."
If you asked me what AI is, I'd say it means getting a computer to emulate human intelligence; if you asked me what an LLM is, I'd say it means getting a computer to emulate human language. The word "language" does not imply truthiness anywhere near to the extent that the word "intelligence" does.
You could reasonably describe it as "human language emulator" back when people were using GPT-2 and the likes to compose text. But what we have today doesn't just emulate human language - it accepts tasks in that language, including such tasks that require reasoning to perform, and then carries them out. Granted, the only thing it can really "do" is produce text, but that already covers quite a lot of tasks - and then of course text can be an API call.
Interesting perspective. I'm still learning about what it really is, and I'm having trouble marrying the thoughts of a parent commenter with yours:
> ... does what it is engineered to do pretty well, which is, generate text that is representative of its training data following on from input tokens. It can't reason ...
versus
> ... doesn't just emulate human language - it accepts tasks in that language, including such tasks that require reasoning to perform ...
Maybe a third party can jump in here: does ChatGPT use reasoning beyond the domain of language, or not?
Nobody can definitely answer this question because we don't know what exactly is going on inside the model of that size. We can only speculate based on the observed behavior.
But in this case, I didn't imply that it's "reasoning beyond the domain of language", in a sense that language is exactly what it uses to reason. If you force it to perform tasks without intermediate or final outputs that are meaningful text, the result is far worse. Conversely, if you tell it to "think out loud", the results are significantly better for most tasks. Here's one example from GPT-4 where the "thinking" effectively becomes a self-prompt for the corresponding SQL query: https://gist.github.com/int19h/4f5b98bcb9fab124d308efc19e530....
I think the real point of disagreement is whether this constitutes actual reasoning or "merely completing tokens". If you showed the transcript of a chat with GPT-4 solving a multi-step task to a random person off the street, I have no doubt that they'd describe it as reasoning. Beyond that, one can pick the definition of "reason" that best fits their interpretation - there is no shortage of them, just as there is no shortage of definitions for "intelligence", "consciousness" etc.
> Most humans do not have sufficient background to understand what they're really being presented with, they will take it at face value.
Trust in all forms of media [1], and institutions [2], is at an all time low. I'm not sure why that distrust would go away, with reading the output from a company that's clearly censuring/fudging that output.
I think any "damaging" trust would, clearly, be a transitory phenomenon, since the distrust in media and institutions is from an ability to see BS. I don't think some sentences on a screen will be as destructive as some think, because people don't appear to be as stupid as some believe.
You always have the option of creating a map style and using Mapbox's Raster Tile API - although that does mean you probably can't dynamically adjust your raster images in time for a request to be served.
How are you using the Static Maps API currently where you would be able to send a POST request and display the image back to the user? Most use-cases for the Static Maps API involve the HTML <img> tag or something similar, which all send GET requests.
My company is in a similar situation - have large teams in several eastern European cities (primarily Minsk), and a few long-term remote teammates in Ukraine. A couple have fled (from Kyiv) with children, others are worried about being conscripted. It makes me want to vomit just thinking about it. I'm amazed many of them are still on Slack and making PRs.
We're fortunate some of our leadership has quite close ties to the area, so our company's response so far has been extremely understanding.
> “I'm amazed many of them are still on Slack and making PRs.”
I was talking with a friend yesterday about his teammates from Ukraine (we’re both outside Ukraine). They said that working is the only thing keeping them sane. This allows them to stop focusing every second at the war outside their homes.
Economics has also already given us lots of information on how much money people are prepared to sink into transportation - the owners of the self-driving cars/rental companies will attempt to extract that value.
I don't doubt there will be a shift in the overall economic picture, but it may not be as large for the car _user_ as we would hope. It will need to be better/cheaper in some dimension for it to get adopted, but the rent-seeking vultures are always circling, spoiling the utopia :-(
> For example,
an under-bark temperature of –37°C will
kill 50 per cent of a mountain pine beetle
population, even in mid-winter; however, a
low temperature of –20°C in the fall, be-
fore the beetles are prepared for winter,
or in the spring, when beetles are start-
ing to become more active, will also kill
beetles if it is preceded by temperatures
above 0°C. The relatively warmer temper-
ature causes the larvae to start to lose its
natural antifreeze.
Some worthwhile reading on the topic if you're interested:
https://en.wikipedia.org/wiki/Zero-knowledge_proof#Zero-Know...
https://en.wikipedia.org/wiki/Blind_signature
It should even possible to construct a protocol where you can prove that you're over 18 without revealing your birthdate.
Zero-Knowledge Range Proofs: https://eprint.iacr.org/2024/430
"Zero-knowledge range proofs (ZKRPs) allow a prover to convince a verifier that a secret value lies in a given interval."