skydhash

> Claude was able to identify the approach that worked, and even the long Python command that was needed. In, yes, probably about 10 seconds.

> For me to figure that out myself, it probably would've taken something like a year of study. Of the entire stack of machine learning and all of the Python tooling associated with it

It wouldn’t take that long. Maybe a few days of playing around. It’s not like you’re trying to create a new model from scratch. No need to understand linear algebra fully to learn how to do a dot product.

Same thing here. I gave up on gaming all together because my library grew too much. As a kid, I didn’t even own a console, I had to borrow gameboy or go to my friend house and even then it was just an handful of cartridges. Even now, I plan to just focus on small sample of programming languages and ecosystems, and learn them inside out. There’s just too much stuff out there.

> AI is, apparently, very good at producing proofs.

Proofs of what? Defining the problem is the part that is hard, not the actual writing of the proof.

That also assumes that your axioms are correct and the verification code is also correct. It's also a lot of work to update your system, when assumptions are challenged.

> humans refuse to spend effort on writing more formal specifications.

Code is formal specifications. It's just that programming language semantics has no domain related value of correctness. So you overflow an unsigned integer variable and got a lesser number which does violate addition rules. Or increase account A without decreasing account B, which violates accounting rules (and all kind of closed systems).

So it's up to the programmer to encode all of those rules. While we do have some tooling like type checking and memory safety, they are nowhere near enough. And encoding such thing in a language like Lean or TLA is brittle in terms of maintenance (which you do need to do as the real world evolves).

I think those are mostly technical issues (accidental complexity) and those are either documented or there should be someone experienced with the technology on your team (even if that experience came from trying it out).

Critical thinking is essential for nailing down your essential complexity (the core solution of the problem). You can try to define invalid and edge cases alongside the happy path in the pseudo code diagrams version, even if it's a TODO comment.

It’s often wild that people not building something and people not using something are trying to design it. You can’t be surprised that it’s always governed by fads and hype.

Do those RFPs come from the users or the buyers?

We had RAD tools like Access and we still have Excel. Even if they do lack some capability, you can do implement most of the core ideas of whatever features you’re trying to prototype. Actual coding is then to translate that to another platform and solve some accidental complexity.

Those core ideas are what’s valuable and they do not change often over the lifetime of a business. If the software has a good architecture, maintenance cost can be quite low.

The thing is, if you’re good at designing and breaking down problems and coming up with a good system, code is not likely an hindrance.

You can take any idea and try to flesh it out with pseudo code. Once that’s done, try to convert it to real code and you’ll see that process is fairly mechanical. This is why people says that coding wasn’t an issue for ages. Coming up with the algorithm is the hard part.

People that have an issue with coding either are not familiar with the language/platform or is trying to think with real code instead of pseudocode or diagrams.

ADDENDUM

There are techniques to think with real code, moslty the Edit-Compile-Run workflow coupled with a good editor, or the REPL workflow (also helped by a good editor). Then add a good integration with a documentation system (manual pages?) and you’re golden.

But I’ve been on projects where a dev cycle relies on a 20 minutes local rebuild or one hour CI run. So it can be very hard to try to apply those workflows to legacy projects.

> I'm going to take the contrarian view and say that formalism without jargon, friction and gatekeeping is just natural language

Try to define a specific item like the closest cat to you so that anyone, just from reading the definition, can recognize that cat anywhere. You could write a whole book and not be done. Or you could stamp the cat with some id (symbols) in and refer to that. As long as that id is not repeated (rule), the system is ok.

Formalism is defining stuff, and add rigid rules that are consistent with each other. Once that done, it allows anyone to reach the same thinking location as the original person. Formalism is a knowledge transfer tool.

> My tech career was just converting specs from clients and employers into machine code, with extra steps.

If all you did was that, I’m quite sad for you as yourself should have automated your job to remove that tedium.

I would describe my job as designing a system that respect all the constraints of the situation. Some of them comes from specs, some comes from the technical platform, and some are just future possible interactions. The system is what I modify, coding is just how I do it.

When I see people abandon their work to AI, the other consequence is that they abandon their control of the system as well. They can’t explain how it works, what’s its reliability, and whether it can be improved (or part of it reused in another context).

That’s three examples of software that are way more complex than they should have been for the general use cases.

Yes, a lot of software do continuous development, but in a more stable manner, where they introduce some features, takes time to iron bugs out, and then release a new version. Meanwhile, the users only have to care about some small security fixes every now and then. When there’s no new features (especially when you’re not creating a kitchen sink), things can be calm for months and years.

> I have observed several samples where the business, when provided with a natural language configuration opportunity, will wind up staring blankly at the textarea until the original developer gives them a complete starting point.

A lot of people lack “system thinking” when they can break down something into a set of elements and describe the relation between them. Once that done though , they can understand a part and manipulate it.

For some “system thinking” is innate. It can also be learned. But it’s a required quality in engineering where you need to create a solution where there was none.

> however plenty of enterprise CRUD software can be easily tackled with such agentic runtimes

People love to make such claims, but the actual CRUD part of enterprise system, while it’s the primary interface, isn’t the actual value of that enterprise and most enterprise code I’ve seen rely already on frameworks to take care of the technicalities. Most of my time has been taken by what should happen when you do one the CRUD actions. The specs of that can be quite complicated to gather, easy to build, and difficult to verify.

> Very few developers look at the underlying “source code” that this SQL compiles into. Very few people even read the “source code” that tsc outputs.

Only because there’s a group of people that do understand database theory and know how to write a proper implementation and they have a track records of doing so. Themselves relies on compilers maintainers and OS developers, and this goes on down to the semiconductors where people do study how electricity interact with the materials.

Every layers of the tower of abstractions have people that understand the current layers, knows the safe semantics of the layer below, and can provide a safe foundation for the layer above.

> There’s some category of changes that are low risk and simple enough that a human reviewer isn’t needed

If something is low risk and simple enough then it can be quickly judged in 1 to 5 minutes. Not sure why someone can’t review it.

The art of electronics is something you keep as a reference. The secret life of circuits is more pedagogical, and reads more like someone kindly explaining stuff instead of sending diagrams and formulas your way.

Other similar book in tone are “The C Programming Language” and the IT Mastery series by Michael Lucas.

I love my reference books, but they’re not usually great for pleasant reading. And books that relies on projects often don’t motivate you on doing said projects. I’d rather something that makes my curiosity grew and make me explore on my own.

> Software doesn't have this scarcity dynamic

Time is finite. People’s problems that can be solved by software is also finite. There’s diminishing returns in improving software. Rewriting bash in rust, and then testing the result would barely help anyone. Also the real world (where inputs come from) is messy. You can have the perfect mechanism (memory safety), but that grain of sand (corrupted or unexpected data) can still make it behave erratically (wrong result).

> Humans also work because they've been trained on a massive corpus of materials,

Massive? My introduction to programming (from noob to beginner level) has been like only 10 books worth of content. Including some alternative pathways like 3D, security, system administration,... To this day, I don't think I've reached 50 books of materials. And If I counted everything it would be still small.

Human learning is very efficient (not time wise, but cost wise, and even training data wise).

> Do you know how elevators work now? Their safety mechanisms? Planes are 10x more likely to cause death.

There's something called safety regulation. An installed elevator is very likely to have passed all the verification necessary for it to clear the safety bar. Same with the other devices you listed.

As for general code, it's mostly based on trust. But I see practices endorsed by the AI providers and trust is very low on my end.

Yep a small changes is one computer screen of diff (36 to 48 lines) excluding generated changes (lock files, formatted files,…)

> Even before slop coding good code review was hard, because verification is a hard problem. But we have many tools at our disposal to increase confidence without having to go full-on mathematical proof. Human understanding has always been the bottleneck, and as long as the thing you are doing is for humans, humans will have good reasons to want to understand it, so they will remain the bottleneck.

When people rally agains AI, that is why. AI hypers think it’s about the actual coding. It is not. It’s about the understanding and what you built is logically sound, conceptually and concretely. The code aspect matters only for maintenance sake and verifying the logical structure.

Which is why good devs are burning out on this. The PR authors don’t care, management don’t care, so to not be between a rock and an hard place, you just LGTM the review. And then users are suffering with insane bugs.

> They can be TLA+ definitions, linters, cyclomatic complexity checkers, unit tests, integration tests, end to end tests etc.

That’s even more work than just writing the code, at least the latter is immediately useful. The reason we create complicated machinery is mostly because of industrial scale. Molds and factories help create thousand of pieces and the total value of the latter is way more than the cost of the former.

The reason we don’t write specs and other kind of docs extensively is usually that the time taken is way more than just writing the code. Yes, code do require formal thinking, and a training in syntax. But a lot of jobs require understanding some concepts and training in the jargon and techniques.

> No program will ever be perfect[0], but you need to get it good enough for the problem at hand.

The nicest thing about software is that some subproblems are nearly eternal. That’s why we reuse code and utilities. Also while some problems do evolve, it’s usually done slowly and in a way, predictably (as in how, not when). Taking care to solve it once well, usually is better, rather than solving it again and again.

It’s more important to worry about the solution to a specific problem (in terms of concept), than to worry about code. Coding was not, and will never be the primary problem. Any experienced developer knows this, which is why most will says they spend very little time thinking about code and writing it.

And often, it's not the code that is the issue. You understand the code perfectly fine and can edit it easily. The main issue is always finding out the "why" so you do not remove any Chesterton's fence while coding for a new change request.

> What it boils down to is that the future of coding is more about creating the mold where the code is poured in and knowing how exact of a mold is "good enough" for the problem at hand.

> When the mold is done, you let the agent pour in the code in any format you like. It can create a Swift version, Rust version and a web assembly version in "half a soda" as you put it =)

Unless you use code, that mold is at best a formless bag.

The reason people use software is because there's a need to manipulate some data/information, transfer it, and interact with it (input or output). All those actions needs to be done correctly, and if not possible the error should be reported. To get to that level of correctness, we need to be formal with how we express the process, which means essentially going from a non-zero amount of ambiguity (natural language) to zero (programming language).

Using AI to translate specs/prompt to code is just asking it to randomly resolve any ambiguity found in the specs. And as any experienced dev knows, some of those are just tradeoffs where there no right or wrong answers, just contextual ones that evolves over time and space.

> Before I had to dig specs of an application out of a client's mind and try to form them into software with a full-ass team. Now we can pretty much "just" give them Claude and teach them to describe what they want and iterate to get something that maybe resembles an MVP

I wonder if there's actually been conversation with the client before? Where you use some prototyping tools like RAD or Sketch to resolve UI issues, get in touch with the actual domain experts,... or was it just a telephone game full of politics?

I was watching the most recent Rich Hickey talk[0] and at the start, he talks about correctness and the difference between the internal machinery of your software (which can be finely specified) and handling the external world (which will always be messy).

Good Architecture will try to isolate the two. You got the internal logic which is either the business domain abstracted away. And you got the highly volatile part (request from frontend, new integration, new drivers, deps update,....).

If you've done that, migration/refactoring, unless it entails some unlikely core changes, will not take that long. It's just a matter of dropping that part and replacing it (like changing a car's brake pads or steering wheel). But the actual core mechanism will hardly change over the years.

To go with the thread flow: It's a stone core wrapped by clay.

[0]: https://www.youtube.com/watch?v=P5eO7BNyJao

ADDENDUM

In regards to separation, one of the best example in mind is the OpenBSD kernel code. The OS concepts are in /kern, while each architecture lives in /arch. There's an horizontal separation between machine independent code (core idea of Unix) and machine dependent code (The hardware platform). It can also be found in the various subsystem like audio (the concept of a sound card) and implementation like uaudio (usb interface) and azalia (Intel's HD Audio).

This is the dependency list of the just command runner

https://github.com/casey/just/blob/master/Cargo.lock

And the helix editor

https://github.com/helix-editor/helix/blob/master/Cargo.lock

Compare them to the dependencies of gnu make (pretty sure it’s only posix)

https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/m...

And vim

https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/c...

###

Downloading the internet to build a smallish software is always bad in my opinion.

> you couldn't afford to spend weeks or months learning the idiosyncrasies of your new codebase especially when it came to state management. That's the main problem frameworks and libraries were solving.

Not really. Frameworks are usually created to avoid boilerplate and provide some nice scaffolding to support you while you’re coding the business layer. And a lot of them do smooth over accidental complexity, even though the architecture is generic and may hinder you in the future.

But the learning curve still exist, as most of what you interact with is custome codes, modules and components.

> Reactivity is updating the DOM whenever the underlying data is updated. That's one of the most basic reason for existence of all js frameworks.

Most web apps and websites do not have that much state variables (even though it may be a lot of data). So while React may offer a small dev speed boost, it’s consumed by the need to build stuff and a whole deploy pipeline to nurse.

Libraries like HTMX and Alpine can take care of most the boilerplate for old style imperative patterns. And backend frameworks like Rails, Phoenix, Laravel donhave their own implementation for data updates.

> React is actually pretty good for any kind of reactive interface,

It’s a different interface and the axiomatic layers are not the same.

React expects a tree of nodes that will map to the UI and build on that to add reactivity. And that’s what the major GUI platforms do offer (QT, the web dom, Android, iOS,…).

The terminal is a grid of characters modfied by the cursor concept. It is also modal (although most TUI uses one mode). What the cursor can do, and how the grid is rendered is terminal dependent (even though most current ones try to follow xterm-256color).

Using React on top of that is a technical bad idea.

> Anthropic is down to two 9s (aha) and people still use them. There is a github ci failure post on here like every other day.

Anthropic and GitHub’s consumers are software teams. I wonder what would happens if something like SolidWorks was that unreliable.