Planning is essential but it doesn't survive contact with reality. However, AI makes contact with reality cheap! Why not use it to improve designs, by writing the design after a few implementations have already been made?

Only slightly tongue in cheek.

Here's an example. You updated the code that interfaced with the database. But you forgot to update the stored procedures within the database. As a result, the database is now being put in an inconsistent state with every transaction that uses your new code. That is the kind of thing that a software design doc can help you remember, because it is supposed to make you think through all the stuff.

And if you're going to say "Your business stuff shouldn't be able to get into an inconsistent state", well, there's a lot of businesses that have potential landmines laying around. You can say they shouldn't. You're right, in an ideal world. But in this world, they do, and you have to live and work in the world that we have.

Now, in fairness, a good AI check might turn up that the database was left in an inconsistent state... if it understood the constraints well enough. If. I wouldn't want to gamble my production database on the AI's understanding and testing of all the constraints, though.

It's orthogonal.

To be clear, I'm not suggesting blindly deploying an AI-written spike implementation to production, but rather using it to elicit information for better designs.

The fact that a probe that goes off and modifies tables X, Y and Z to achieve the feature gives information for an AI auditor to look for other uses of X, Y and Z, and discover things humans may miss, because with good guidance and a proper harness, AI is usually more persistent and thorough than people. It can turn search results into a checklist and the harness can track completion, and so on. I am far from convinced that your example would not be found via this route.

But if you're doing a spike, no, don't do a design document for it. How can you? You don't know what the design needs to be yet!

That means you could choose to try three (or more) genuine implementations and explore their tradeoffs, instead of making three proposals in a document with one recommended (and the other two usually only provided for contrast).

I do think the design is important to keep around - in particular, the constraints, the communication points, schema, tacit things that might not be clear in code. I am not certain that the design should precede the implementation for features below a certain size though.

Larger efforts need milestones and collaboration and will have multiple people doing implementation, so there's more need to agree schemas, APIs etc up front there.

Agree, but in my experience that doesn't change much about the design doc.

I think it's helpful to the author to be able to say to an AI agent, "Hey, put together this quick prototype," and that informs the design doc. But if the goal is to review the design decisions with the team, I don't see how you get around the design doc. I don't want a teammate to send me 10 KLOC of AI-generated code and ask me to review the design. Even if you told AI to try 10 different ideas and pick the best, I don't trust AI to make the same decisions as my human teammates.

I would try and get an understanding of design space by giving a good agent a high level goal and seeing what it does, then getting a summary of the approach.

When you do this several times, especially if you give it a steer on some non-functional requirement, you can compare and contrast different approaches.

The idea isn't to prototype so much as to gather information by doing. Prototype, to my mind, suggests other things; shortcuts, stubs, incompleteness. I would actually ask agents to do the whole thing, and find out the full scope. It can be particularly useful revealing side effects.

Pair it with code auditors wearing different hats, of course.

I get the impression that Fable, when well directed, is better than maybe 80% of SWEs. Maybe more.

[edit: Yes, I'm maybe baiting other users, but I want to know your honest opinions on this.]

If I tell a senior SWE that I'm creating a Discourse-like discussion forum, and I want users to have three options for selecting an avatar: (1) import from Gravatar, (2) upload a JPG or SVG or PNG or GIF, or (3) let the user draw their avatar on a canvas, the LLM will happily go and design that and write a 5 KLOC implementation, whereas a good SWE would push back and say, "That's like 10x the complexity of just allowing JPGs. How about we simplify it to say that in v1, the only option is to upload a JPG."

I've tried working with Fable/Sol and saying, "Look for features that we can simplify to reduce complexity," and they don't understand. They'll guess at features we can cut entirely, but they fail to see how to capture the essence of the feature without the complexity.

I've noticed this a lot with Fable recently. Like I'll say, "Show an error message in the web UI if X fails," and Fable comes back with this like 800 LOC error message generator that has switch-cases and combines inputs from three different sources when all I wanted was something like, "Update failed: database is locked."

I agree, but I think we're still a long way away from being able to trust AI to manage all software complexity for us. For one, LLMs frequently get tripped up by their own complexity. But even if the complexity didn't make LLMs more error prone or expensive to run, you still often need a human in the loop to understand what the system does.

I think of it kind of like compilers. Compilers do a good enough job that 99% of developers don't understand code at the bytecode or machine instruction level, but if we lost that last 1% of programmers who understand CPU instructions, we'd be in serious trouble.

You build in safeguards, redundancy, defense in depth, recovery systems. You build models of the system and prove characteristics about it.

Software is fundamentally automation. LLMs enable automating the construction of software itself. They're much faster and cheaper than people, and they're more unreliable. (People are unreliable too!)

The immediate challenge of these times is figuring out how to reliably construct reliable software in the large, over the longer term, reliably. This is an engineering challenge, and the only way we'll get to the other side of it is by trying to do it. Things will be rough, there will be a Cambrian explosion of techniques, most approaches will fail, and many more won't survive as models improve on quality and capability. But we'll figure it out.

Making things by hand, as in the time before agentic coding, can be engineering too, but it is not the core challenge of these times, and it will soon be a hobby, or possibly a kind of luxury good. You will no more want hand-written software than you'll want a hand-made car. It will not have the precision, performance or reliability of machine-made software.

It does require a different kind of ego/abilities than before. My (negative) framing of the whiplash effect is that it’s a reckoning of “process fetishism”/a bad kind of careerism in the tech hiring market (because for the labor market to work, candidates need to be evaluable and sortable by businesses, and many people build an identity/optimize for legibility around “best practices” or very particular “technologies” which might get them a job).

Ultimately, you need to know and learn/be responsible for stuff, and be able to help people with your labor, not be “a type of person” that isn’t effective at the task of helping. But at the same time knowing things and being able to take accountability/help people remains critical, especially because that’s what people will want to pay for even as “time spent typing it in” decreases.

Personally, I think it will be a good thing because software and “tech” will become a more strongly domain-driven/enabling medium for real-world or specialized things. IE it is the end to “software for its own sake” or “willingness to type it in and play with Jira/jenkins/frameworks” and the beginning of something that is more applicable or knowledge-building rather than “being the X for Y at Z”. Harder but more fun :)

LLMs have very little to do with engineering, unless you let a pair of dice decide how you build a house.

Cars are not built by AIs, they're built by extremely precise robots, over precise instructions.

I'd VERY much want a hand-made car over an LLM-made car, thank you.

Because I do want the precision, reliability and performance that an LLM-made car won't ever be able to guarantee.

As long as you can verify/test and take accountability for the thing you put your name on there’s no reason not to treat it as a process or search problem rather than one you assemble yourself by hand. The only problem is that it’s ironically much harder and more engineering than most “software engineers” are willing or able to do.

I spent several years working on permutation testing/experimentation and creating e2e verification of infrastructure because at scale, or when reliability/correctness are critical, you cannot rely on a single person’s mental model, or for the world to not drift around a system as it works now. That kind of system is what allows you to use LLMs or engineers who don’t know everything about it to improve or change it. It’s more science than art, which is often (but not always) what you want

You wouldn't want to decide what's worth training on and what isn't manually, so there is almost certainly an automated pipeline to do so (certainly at least for the free accounts and those that dont opt out of training).

Then there's the question if this pipeline only sorts through the data or also transforms it and to what degree. E.g. for removing personal details, locations, medical information and so on. The data that comes out of this pipeline might have VERY little information left in it a human could connect to the original input. Even worse, since we're talking about companies specializing in sota statistics, the input data could have been transformed into a representation that is very well suited to represent all the novel and interesting parts, but is awful at modelling all the things that could end up identifying where the data comes from (or causes legal liabilities otherwise).

In the end the only thing a potential whistleblower might even have a chance at observing in the first place, is whether a company's data enters such a pipeline or not. And I have my suspicions that the major AI companies operate at a scale and level of automation, that absolutely nobody has a chance at figuring out where anyone's data is at any point in time and what any specific piece of equipment is currently busy with.

So the only place to figure out whether data is trained on that shouldn't be trained on is by looking at whatever configurates every single system that could take a peek at some customer's data or the systems themselves while processing the data.

The latter would be such a huge violation of a customer's rights, no whistleblower is going to attempt that or admit to doing it.

And the configuration for the former could live just about anywhere, from regular config files to the CI/CD pipeline, pre-compiled libraries, kernel modules, modified vendor firmware, the compiler itself ... and probably plenty other scenarios you'd have to train an LLM on the ramblings of a crackhead to come up with.

So I'd say a whistleblower is pretty out of luck even becoming one.

Besides reporting on search sources you can also run the same queries on multiple LLMs closed book mode, and judge their distribution as well. It helps a lot if models are more aware of their knowledge holes. Scale it up for billions of topics if you have the pockets, the DR data is copyright free.

But don’t worry bud, instead of the authorities going after actual corporations admitting to actual crimes, we’ll just ban CloudFlare IP addresses for everyone during La Liga games to battle piracy.

The labyrinth symbol, as a decoration or motif in ancient Greek artifacts, isn't generally a maze, but the labyrinth of myth is. Theseus had to use thread, given to him by Ariadne, to find his way back out.

The problem with your argument is that it's a universal argument against performance. And if an argument is universal, then it doesn't have any information value.

No, this is something that nuanced. The title is wrong because musl isn't going to prevent you from writing fast software.

Whatever benefit there is to a different libc, is absolutely miniscule compared to do actual optimizations like avoiding allocations.

I'll give you real numbers: if you put allocations of short vectors of a dozen floats in a hot loop, when you lift the allocations out your program is going to instantly get about 10x faster. The allocation is no longer going to be the bottleneck, it will be marginal and then a faster allocator isn't going to matter at all.

If someone gets an easy speedup from using a different libc that's great, but the vast majority of time it isn't going to matter and isn't going to be where any real speedups come from. The difference is a small percentage speedup vs orders of magnitude.

The amounts to the title being wrong, using musl or a small standard library just doesn't prevent a program from running fast. It is a tiny difference and even that tiny difference can be changed from things like better allocators which you would do anyway with a standard libc.

Also Austria, perhaps Italy, but I have less direct experience there.

In other countries Revolut is popular for the friends and family bill splitting, in places like Sweden they have a PayPal-like solution offered by local banks. There’s an upcoming initiative by Brussels to bring all these national initiatives under one umbrella, which would definitely hurt PayPal’s German revenue in future.

I have, but never use, a 'credit card'. The thing I use every day is a 'debit card', where the money comes straight from my account. But it still has 16 digits and Visa written on the front.

Since then MasterCard has tried to force banks into dropping GiroCard, by refusing to work with smaller banks that still support GiroCard, and by offering better conditions to larger banks that drop GiroCard.

This has increased the number of Germans with Visa/MasterCard, but it's still below 50%.

If the supplier goes out of business / fails to deliver, the bank/credit card company is equally liable. A Section 75 claim is allowed for purchases between £100 and £30,000.

https://www.financial-ombudsman.org.uk/consumers/complaints-...

https://en.wikipedia.org/wiki/Switch_(debit_card)

All the traditional large ones seem to have AFAIK.

Off topic but I really hate N26 and its ilk. They don't really follow the German laws that say that German residents can have bank accounts, so they refuse people that are still on work visas, which is a pain in the fucking ass when you have a startup and the young employees are telling the immigrants "get N26" or something else, but the immigrants can't have it and only learn after submitting lots of docs to N26.

They check during the KYC process via mobile phone camera, and will reject people without a residence permit (Aufenthaltserlaubnis, Blue Card, etc), and they claim several things, from "we don't accept work visas" to "I never saw this document in my life".

Legally, a work visa is an Aufenthaltserlaubnis according to § 4 AufenthG, so N26 is classifying it wrongly here.

But it gets worse because they're breaking § 31 ZKG, which says they're obligated to provide an account for everyone here legally. We have formally complained to BAFIN about it.

Just copied the above law paragraphs from an HR discussion, btw, this is a recurring issue...

And I know this from helping several others, since I'm the startup ecosystem. I'm European, but not German.

My Girocard has Maestro integration, so I can use it overseas, but no number. Apparently this is gonna go away.

The Girocard naturally has ApplePay, which is what I use daily.

People used to use Paypal because they have only debit cards. But with better card security and alternatives like SEPA and Wero there is way less need.

Many Germans don't have credit cards (I don't), so PayPal is pretty convenient as it can withdraw directly from a SEPA account and enables online shopping.

Google Pay cannot do SEPA, but allows adding PayPal as a payment method, so PayPal also gets you into the Google purchase ecosystem.

Revolut with its virtual CCs has been making some inroads lately, though.

Small commits can often be tested faster, since irrelevant tests don't need to run.

Small commits are less risky. The smaller the delta of change, the lower the probability that something breaks.

Small commits get merged sooner; big commits take time to build up. Merging early front-loads your integration risk; merging later puts integration risk just before delivery.

Breaking a big feature into small commits means using feature flags to control whether a feature is enabled or not (since control paths will generally be incomplete). This means you separate the delivery of the code from the delivery of the feature, and has the added benefit that you can turn off a feature that has a problematic rollout without needing to redeploy code.