So you think CodeSpeak by the creator of Kotlin will fail, pure and simple? https://codespeak.dev
Yes.
A sufficiently detailed spec is code
281–290 of 376 posts
Re: A sufficiently detailed spec is code
#282This is relatable. I did a side project with a non-technical co-founder a year ago and every time he told me what he wanted, I made a list of like 9 or 10 logical contradictions in his requirements and I had to walk him through what he said with drawings of the UI so that he would understand. Some stuff he wanted me to do sounded good in his head but once you walk through the implementation details, the solution is e…
He wanted seven perpendicular lines ?
Re: A sufficiently detailed spec is code
#283If you think of yourself as a "programmer" or "coder" I think it's fair to say you might have incorrectly defined your role already. Your job is to design and implement software solutions that are reliable and compliant, and make business processes more efficient. Writing code should really be a relatively small piece of the puzzle, and arguably if you're spending a lot of time writing code, you're wasting time.
Writing code has always been a means to an end of getting the job done, and I consider being really interested in the practice of coding to be a bit odd. It's as if a carpenter got really into manual saws and got upset about an electric power saw because he "loves manual saws". Whether or not an AI spec is "code" really shouldn't matter if you're a software professional. You are designer/engineer of software systems, not a "coder".
Re: A sufficiently detailed spec is code
#284[dead]
Re: A sufficiently detailed spec is code
#285Earlier quoted context omitted.
The hard bit of programming has never been knowing the symbols to tell the computer what to do. It is more difficult to use a completely unknown language, sure, but the paradigms and problem solving approaches are identical and thats the actual work, not writing the correct words.
Saying that the paradigms of Python and Haskell are the same makes it sound like you don’t know either or both of those languages. They are not just syntactically different. The paradigms literally are different. Python is a high level duck typed oo scripting language and Haskell is a non-oo strongly typed functional programming language. They’re extremely far apart.
They’re both turing complete, which make them equivalent.
Code is a description of a solution, which can be executed by a computer. You have the inputs and the outputs (we usually split the former into arguments amd environment, and we split the latter into side effects and return values). Python and Haskell are just different towers of abstraction built on the same computation land. The code may not be the same, but the relation between inputs and outputs does not change if they solve the same problem.
Re: A sufficiently detailed spec is code
#286If you think of yourself as a "programmer" or "coder" I think it's fair to say you might have incorrectly defined your role already. Your job is to design and implement software solutions that are reliable and compliant, and make business processes more efficient. Writing code should really be a relatively small piece of the puzzle, and arguably if you're spending a lot of time writing code, you're wasting time. Writ…
From 2011, a timeless classic: https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
Re: A sufficiently detailed spec is code
#287Earlier quoted context omitted.
The main thing they cannot do is be held accountable for any decisions, which makes them not trustworthy.
This is not correct. They can say "sorry" which makes them as accountable as ordinary developer.
LLM based solutions don’t need to stay dry and warm at night, with a full belly, possibly with their sexual partner with whom they have a drive to procreate.
Re: A sufficiently detailed spec is code
#288Earlier quoted context omitted.
Most of the economically valuable software written is pretty unique, or at least is one of few competitors in a new and growing niche. This is because software that is not particularly unique is by definition a commodity, with few differentiators. Commodity software gets its margins competed away, because if you try to price high, everybody just uses a competitor. So goes the AI paradox: it's really effective at writ…
Could you give some examples? I can only imagine completely proprietary technology like trading or developing medicine. I have worked in software for many years and was always paid well for it. None of it was particularly unique in any way. Some of it better than others, but if you could show that there exists software people pay well for that AI cannot make I would be really impressed. With my limited view as softwa…
Everything I’ve ever worked on has been entirely greenfield in domains that had very limited prior development. Industrial applications of software (and data science).
Google Maps, Twitter, and AirBnb occupy a tiny fragment of the possible domain applications of software.
Re: A sufficiently detailed spec is code
#289Earlier quoted context omitted.
Neither can humans, but the industry has decades of experience with how to instruct and guide human developer teams using specs.
Usually, you don't want your developers to be coding monkeys, for good results. You need the human developer in the loop to even define the spec, maybe contributing ideas, but at the very least asking questions about "what happens when..." and "have you thought about...". In fact, this is a huge chunk of the value a developer brings to the table.
This is very much my experience from working with outsourced development. Almost by design, they tend to lack domain expertise or an intimate understanding of the cultures and engineering values of the company they're contracted out to.
This means that they will very quickly help you discover all the little details that seemed so obvious to you that you didn't even think to mention them, but were nonetheless critical to a successful implementation. The corollary to that is, the potential ROI of outsourcing is inversely proportional to how many of these little details your project has, and how important they are.
So far I've found LLM coding to be kind of the same. For projects where those details are relatively unimportant, they can save me a bunch of effort. But I would not want to let an LLM build and maintain something like an API or database schema. Doing a good job of those requires too much knowledge of expected usage patterns working through design tradeoffs. And they tend to be incredibly expensive to change after deployment so it pays to take your time and get your hands dirty.
I also kind of hate them for writing tests, for similar reasons. I know many people love them for it because writing tests isn't super happy fun times, but for my part I'm tired of dealing with LLM-generated test suites being so brittle that they actively hinder future development.
Re: A sufficiently detailed spec is code
#290If you think of yourself as a "programmer" or "coder" I think it's fair to say you might have incorrectly defined your role already. Your job is to design and implement software solutions that are reliable and compliant, and make business processes more efficient. Writing code should really be a relatively small piece of the puzzle, and arguably if you're spending a lot of time writing code, you're wasting time. Writ…
Not quite.
Let’s first agree that code is the final output of a software engineer, and that a wooden object is the final output of a carpenter.
A correct analogy would be, if a software engineer’s AI assisted output is reduced to assembling auto generated code snippets into a workable product, a carpenters is assembling ikea furniture.
The only missing piece is liability. The engineer and carpenter are both hired to assemble something, so they better damn well fully understand what they are delivering because they are being paid to own the liability if anything fails.